?Kubernetes 是業(yè)界最流行的用于容器編排的開源平臺(tái)，可以讓我們與容器相關(guān)的很多工作變得自動(dòng)化。公司使用它來解決與部署、可伸縮性、測(cè)試、管理等相關(guān)的問題。然而，Kubernetes是復(fù)雜的，需要一個(gè)陡峭的學(xué)習(xí)曲線。在本文中，我們將介紹大多數(shù)公司都會(huì)遇到的一些常見的Kubernetes陷阱。這些是許多擁抱Kubernetes的公司在擴(kuò)大業(yè)務(wù)規(guī)模時(shí)所面臨的問題。在討論這些問題的同時(shí)，我們還將強(qiáng)調(diào)如何避免或解決這些問題。最終，我們將討論如何在不面對(duì) Kubernetes 復(fù)雜性的情況下最大限度地發(fā)揮其作用的最佳解決方案。

下面，讓我進(jìn)入正題。

1.不正確使用Label和Selector

初學(xué)者經(jīng)常犯的錯(cuò)誤之一是在配置中不正確地使用標(biāo)簽（Label）和選擇器（Selector）。標(biāo)簽是與諸如 Pods、Services 等對(duì)象相關(guān)聯(lián)的鍵/值對(duì)。選擇器允許您識(shí)別用標(biāo)簽標(biāo)記的對(duì)象。不匹配的選擇器將部署資源置于不受支持的狀態(tài)，您可能會(huì)看到與不正確的標(biāo)簽和選擇器相關(guān)的錯(cuò)誤。下面的例子說明了這個(gè)概念。注意，標(biāo)簽是區(qū)分大小寫的。確保在 YAML 文件中使用了正確的標(biāo)簽和選擇器，并仔細(xì)檢查是否有拼寫錯(cuò)誤。

#這是個(gè)錯(cuò)誤示范，來自StackOverflow，問題在于其中第13行app的值與第18行的值不匹配
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: App1
  template:
    metadata:
      labels:
        environment: production
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9

2.忽視健康檢查

在 Kubernetes 部署服務(wù)時(shí)，健康檢查在維持服務(wù)方面發(fā)揮著至關(guān)重要的作用。在Kubernetes中，健康檢查的使用率很低。通過健康檢查，你要密切關(guān)注Pod及其容器的健康狀況。Kubernetes 有三種主要的健康檢查工具。Startup 探測(cè)確認(rèn)是否在沒有問題的情況下啟動(dòng)和創(chuàng)建了Pod。Liveliness 探測(cè)將告訴您應(yīng)用程序是否處于活動(dòng)狀態(tài)。Readness 探測(cè)確保應(yīng)用程序能否成功接收請(qǐng)求。

3.一直使用默認(rèn)名稱空間

名稱空間（namespace）允許您對(duì)不同的資源進(jìn)行分組，例如部署（Deployment）和服務(wù)（Service）。當(dāng)多個(gè)團(tuán)隊(duì)在同一個(gè)產(chǎn)品或基于微服務(wù)的應(yīng)用程序上工作時(shí)，名稱空間是必不可少的。在開發(fā)環(huán)境中，使用默認(rèn)名稱空間可能不是問題，但是如果在執(zhí)行命令時(shí)不提及名稱空間，則可能會(huì)導(dǎo)致生產(chǎn)問題。請(qǐng)記住，如果您沒有提到任何名稱空間，您將不會(huì)看到錯(cuò)誤，但是服務(wù)或部署將應(yīng)用于默認(rèn)名稱空間，而不是您想要的名稱空間。請(qǐng)看下面的例子。

#錯(cuò)誤，沒有指定命名空間
kubectl apply -f deployment.yamlKubectl application-f loyment.yaml

#正確，使用--namespace指定了命名空間
kubectl apply -f deployment.yaml --namespace production-apiKubectl application-f

4.使用“l(fā)atest”標(biāo)簽

許多用戶認(rèn)為“ latest”標(biāo)簽（Tag）總是指向鏡像的最新推送版本，但事實(shí)并非如此。“l(fā)atest”標(biāo)記并不總是部署您認(rèn)為是最新的版本。在部署（Deployment）上使用的“l(fā)atest”，您將無法回滾到之前的版本。

使用顯式版本標(biāo)記將確保始終部署正確的版本，同時(shí)允許您的團(tuán)隊(duì)使用以前已知版本的標(biāo)記來控制回滾。

5.缺乏監(jiān)測(cè)和日志

建立 Kubernetes 的一個(gè)陷阱是忽視適當(dāng)?shù)谋O(jiān)測(cè)和日志。您應(yīng)該設(shè)置一個(gè)日志聚合服務(wù)器和監(jiān)視系統(tǒng)來監(jiān)視您的應(yīng)用程序。這不僅可以幫助您看到系統(tǒng)中的各種瓶頸，還可以幫助您測(cè)量和優(yōu)化 Kubernetes 集群的性能。健全的監(jiān)控系統(tǒng)包括各種資源指標(biāo)的警報(bào)和通知。正如前面提到的，Kubernetes 是復(fù)雜的，因此您需要適當(dāng)?shù)谋O(jiān)視和日志記錄來排除故障并解決不同的問題。

采用一個(gè)健全的監(jiān)測(cè)系統(tǒng)對(duì)于順利運(yùn)作和積極管理您的Kubernetes系統(tǒng)是必不可少的。由于原生監(jiān)視工具缺乏許多有用的特性，如日志聚合、跟蹤審計(jì)事件和警報(bào)通知，因此最好使用第三方工具進(jìn)行日志記錄和監(jiān)視。

6.Pod與Service端口映射錯(cuò)誤

如果您看到“連接被拒絕”或“容器沒有回復(fù)”的錯(cuò)誤，那么這可能是映射到服務(wù)（Service）的容器端口不正確的問題。這是因?yàn)榉?wù)中的兩個(gè)參數(shù)彼此相似。一個(gè)是“ Targetport”，另一個(gè)是“port”，很容易弄混它們而導(dǎo)致這個(gè)問題。

請(qǐng)注意，您的服務(wù)（Service）的“targetPort”是 Pods 中的端口，服務(wù)轉(zhuǎn)發(fā)流量的目標(biāo)端口。下面的圖片說明了這一點(diǎn)。而“port”參數(shù)指的是服務(wù)自己向訪問端公開的端口。

7.Crashloopbackoff 錯(cuò)誤

Kubernetes 另一個(gè)經(jīng)常出現(xiàn)的錯(cuò)誤是Crashloopbackoff。這種情況發(fā)生在Pod運(yùn)行時(shí)，但其中一個(gè)容器由于終止運(yùn)行而不斷重新啟動(dòng)。因此，容器不斷陷入啟動(dòng)-崩潰-啟動(dòng)-崩潰的循環(huán)。

出現(xiàn)此錯(cuò)誤的原因有很多?？赡苁桥渲梦募械暮唵屋斎脲e(cuò)誤、內(nèi)存不足、配置不正確等等。您需要檢查Pod描述和日志，以排除故障并修復(fù)根本原因。?