Kubernetes 是最流行的容器編排和部署平臺(tái)。它的強(qiáng)大功能特性，可以保障在生產(chǎn)中可靠地運(yùn)行容器化應(yīng)用程序。

然而，有靈活性的同時(shí)也帶來(lái)了復(fù)雜性，在本文中，我們將探討許多團(tuán)隊(duì)遇到的 10個(gè)常見(jiàn) Kubernetes 陷阱。能夠識(shí)別并避免這些挑戰(zhàn)將提高應(yīng)用程序的可擴(kuò)展性、可靠性和安全性，同時(shí)讓你更好地控制集群及其部署。

1.使用 latest Tag 部署容器

可以說(shuō)，Kubernetes 最常被違反的最佳實(shí)踐之一就是在部署容器時(shí)使用latest標(biāo)簽。這將使我們面臨無(wú)意中接受重大變更的風(fēng)險(xiǎn)，而這些變更可能影響系統(tǒng)穩(wěn)定性。

每個(gè)人使用 latest 標(biāo)簽的方式各不相同，但大多數(shù)人都會(huì)將 latest 指向其項(xiàng)目的最新版本。例如，今天使用 helm:latest 將提供 Helm v3，但在v4版本發(fā)布后，重啟就會(huì)更新到v4，但是我們可能還認(rèn)為系統(tǒng)運(yùn)行的是 v3 版本，從而引發(fā)不可預(yù)知的風(fēng)險(xiǎn)。

2.不使用Liveness和Readiness 探針

探針可以使我們的應(yīng)用程序更具彈性。它們會(huì)告知 Kubernetes Pod 的健康狀況。

當(dāng)容器出現(xiàn)問(wèn)題時(shí)，比如內(nèi)存溢出，Liveness探針請(qǐng)求超時(shí)，那么Liveness探針會(huì)通知 Kubernetes 重啟容器。

有時(shí)候應(yīng)用會(huì)暫時(shí)性地?zé)o法為請(qǐng)求提供服務(wù)。例如，應(yīng)用在啟動(dòng)時(shí)可能需要加載大量的數(shù)據(jù)或配置文件，或是啟動(dòng)后要依賴等待外部服務(wù)。在這種情況下，既不想殺死應(yīng)用，也不想給它發(fā)送請(qǐng)求。Kubernetes 提供了Readiness探針來(lái)發(fā)現(xiàn)并緩解這些情況，容器所在 Pod 上報(bào)還未就緒的信息，并且不接受通過(guò) Kubernetes Service 的流量。

下面是一個(gè)包含有效性和就緒性探針的簡(jiǎn)單 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: probes-demo
spec:
  containers:
    - name: probes-demo
      image: nginx:latest
      livenessProbe:
        httpGet:
          path: /
          port: 80
      readinessProbe:
        httpGet:
          path: /
          port: 80        

3. 缺少節(jié)點(diǎn)選擇器導(dǎo)致調(diào)度效率低下

集群的整體性能取決于 Pod 是否被正確調(diào)度到合適的節(jié)點(diǎn)上。許多集群包含多種類型的節(jié)點(diǎn)，例如用于標(biāo)準(zhǔn)應(yīng)用程序的小型 2 CPU/4 GB節(jié)點(diǎn)和用于密集后端服務(wù)的較大8 CPU/16GB節(jié)點(diǎn)。

如果Pod無(wú)法可靠地調(diào)度到我們想要的節(jié)點(diǎn)池，那么集群利用率將會(huì)很低。例如即使有未充分利用的較小節(jié)點(diǎn)，也會(huì)強(qiáng)制創(chuàng)建不必要的新的較大節(jié)點(diǎn)，從而增加集群的成本。通過(guò)在節(jié)點(diǎn)上設(shè)置標(biāo)簽，然后使用節(jié)點(diǎn)選擇器將每個(gè) Pod 分配給兼容的節(jié)點(diǎn)來(lái)避免此問(wèn)題：

apiVersion: v1
kind: Pod
metadata:
  name: pod-node-selector-demo
spec:
  containers:
    - name: nginx
      image: nginx:latest
  nodeSelector:
    node-class: 2c4g

此 Pod 只會(huì)調(diào)度到設(shè)置了標(biāo)簽的節(jié)點(diǎn)node-class: 2c4g

使用命令在匹配的節(jié)點(diǎn)上設(shè)置標(biāo)簽：kubectl label

設(shè)置適當(dāng)?shù)恼{(diào)度規(guī)則將最大限度地提高節(jié)點(diǎn)利用率并保持穩(wěn)定的集群性能。

4.破壞 Pod 親和性/反親和性規(guī)則

Pod 親和性和反親和性規(guī)則允許指示 Kubernetes 哪個(gè)節(jié)點(diǎn)最適合部署Pod。規(guī)則可以以節(jié)點(diǎn)級(jí)特征（例如標(biāo)簽）或已在節(jié)點(diǎn)上運(yùn)行的其他 Pod 的特征為條件。

親和性規(guī)則將Pod吸引到 Node，使得 Pod 更有可能調(diào)度到特定Node上，而反親和性則具有排斥作用，降低了調(diào)度的概率。Kubernetes 會(huì)評(píng)估每個(gè)可用于調(diào)度的可能節(jié)點(diǎn)的 Pod 親和性規(guī)則，然后選擇最合適的一個(gè)。

親和力系統(tǒng)能夠支持復(fù)雜的調(diào)度行為，但也很容易錯(cuò)誤配置親和力規(guī)則，Pod會(huì)意外地調(diào)度到不正確的節(jié)點(diǎn)，或者拒絕調(diào)度。

比如一個(gè)服務(wù)的兩個(gè)副本，應(yīng)該調(diào)度在兩個(gè)Node上，這樣如果一個(gè) Node 節(jié)點(diǎn)發(fā)生故障時(shí)，可以保證服務(wù)的另一個(gè)副本可用，如果規(guī)則設(shè)置不正確都調(diào)度到一個(gè)Node 上那么會(huì)導(dǎo)致服務(wù)不可用。

5. 沒(méi)有監(jiān)控/記錄

當(dāng)在Kubernetes 中擴(kuò)容應(yīng)用程序時(shí)，了解集群資源利用率、應(yīng)用程序錯(cuò)誤和實(shí)時(shí)性能數(shù)據(jù)至關(guān)重要。內(nèi)存消耗激增、Pod 驅(qū)逐和容器崩潰都是我們應(yīng)該了解的問(wèn)題，但標(biāo)準(zhǔn) Kubernetes不具備任何可觀測(cè)性功能，以便在故障發(fā)生時(shí)發(fā)出告警。

要啟用對(duì)集群的監(jiān)控，我們應(yīng)該部署可觀測(cè)性平臺(tái)，例如 Prometheus、夜鶯。這會(huì)從 Kubernetes 收集指標(biāo)，同時(shí)在Grafana查看相關(guān)數(shù)據(jù)指標(biāo)。同時(shí)也有告警機(jī)制。

6. 標(biāo)簽選擇器不匹配

部署和服務(wù)等對(duì)象依賴正確的標(biāo)簽選擇器來(lái)識(shí)別 Pod 及其管理的其他對(duì)象。選擇器與實(shí)際分配給對(duì)象的標(biāo)簽之間的不匹配將導(dǎo)致部署失敗。

示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo-app
  template:
    metadata:
      labels:
        # Label does not match the deployment's selector!
        app: nginx-demo-application
    spec:
      containers:
        name: nginx-demo-app
        image: nginx:latest

以上文件部署會(huì)拋出selector does not match template labelsspec.selector.matchLabelsspec.template.metadata.labels要解決此問(wèn)題，請(qǐng)調(diào)整清單的 和 字段，使它們具有相同的鍵值對(duì)

7. 服務(wù)端口不匹配

同樣，確保Service將流量路由到Pod上的正確端口也很重要。不正確的端口定義可能會(huì)使 Pod 看起來(lái)像是發(fā)生了故障，而實(shí)際上流量根本沒(méi)有到達(dá)該 Pod。

以下清單包含此問(wèn)題的示例。該Service監(jiān)聽(tīng)9000端口并將流量轉(zhuǎn)發(fā)到其 Pod上的8080端口 ，但容器實(shí)際上端口是80，所以流量無(wú)法到達(dá)。

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  labels:
    app: demo-app
spec:
  image: nginx:latest
  ports:
    - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: demo-service
spec:
  ports:
    - port: 9000
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-app

8. 意外部署到錯(cuò)誤的命名空間

Kubernetes命名空間將一組服務(wù)邏輯分組在一起，在集群中提供一定程度的隔離。為每個(gè)團(tuán)隊(duì)、應(yīng)用和環(huán)境創(chuàng)建命名空間可以防止名稱沖突并簡(jiǎn)化管理體驗(yàn)。

使用命名空間時(shí)，請(qǐng)記住為每個(gè)服務(wù)和Kubectl命令指定目標(biāo)命名空間。否則，將使用默認(rèn)命名空間default。如果服務(wù)沒(méi)有部署在合適的命名空間下，會(huì)導(dǎo)致相關(guān)服務(wù)器請(qǐng)求不可達(dá)。

以下清單為Istio Ingress轉(zhuǎn)發(fā)配置，此文件部署在seg空間下，然后根據(jù)/dp-manager請(qǐng)求，轉(zhuǎn)發(fā)到seg空間下的dp-manager-backend服務(wù)，如果dp-manager-backend不在 seg空間下，那么會(huì)導(dǎo)致請(qǐng)求異常。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: dp-manager-vs
  namespace: seg
spec:
  gateways:
    - dp-manager-gateway
  hosts:
    - control-dpmanager.test.com
  http:
    - match:
        - uri:
            prefix: /dp-manager
      route:
        - destination:
            host: dp-manager-backend
            port:
              number: 80

9. 沒(méi)有資源請(qǐng)求和限制的 Pod

正確的資源管理對(duì)于保持集群的穩(wěn)定性至關(guān)重要。Pod默認(rèn)沒(méi)有任何資源限制，除非我們對(duì)其進(jìn)行配置，因此這可能會(huì)導(dǎo)致Node節(jié)點(diǎn)CPU 和內(nèi)存耗盡。

在所有 Pod 上設(shè)置適當(dāng)?shù)馁Y源請(qǐng)求和限制以減少資源爭(zhēng)用。請(qǐng)求Kubernetes為我們的 Pod 預(yù)留特定數(shù)量的資源，防止其調(diào)度到無(wú)法提供足夠容量的節(jié)點(diǎn)上。Limits設(shè)置Pod可以使用的最大資源量；超過(guò) CPU 限制的 Pod 將受到限制，而達(dá)到內(nèi)存限制則會(huì)提示內(nèi)存不足 (OOM) 從而終止 Pod 允許。

請(qǐng)求和限制在 Pod 清單的 字段中定義：spec.container.resources

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container
      image: nginx:latest
      resources:
        requests:
          cpu: 100m
          memory: 1Gi
        limits:
          memory: 2Gi

以上Pod 請(qǐng)求100m（1000m等于1核）CPU 時(shí)間和 1Gi 內(nèi)存。它只會(huì)調(diào)度到可以提供足夠資源的節(jié)點(diǎn)上。Pod 還設(shè)置了內(nèi)存限制，最大可以申請(qǐng)2Gi 內(nèi)存。最佳實(shí)踐是將 Pod 的內(nèi)存限制設(shè)置為等于其請(qǐng)求。通常不需要 CPU 限制，因?yàn)?Kubernetes 會(huì)按比例限制超出其請(qǐng)求的 Pod。

10. 集群自動(dòng)擴(kuò)容錯(cuò)誤

選擇Kubernetes原因之一就是它的彈性擴(kuò)容。正確配置可以使Kubernetes在需求高峰時(shí)自動(dòng)添加新的 Pod 和節(jié)點(diǎn)，從而動(dòng)態(tài)的水平和垂直擴(kuò)容。但是不幸的是，很多團(tuán)隊(duì)它們的自動(dòng)擴(kuò)容是不可預(yù)測(cè)的。

因此定期檢查集群的利用率，以檢查它是否仍然適合您的工作負(fù)載。使用負(fù)載測(cè)試工具（例如Locust）測(cè)試自動(dòng)擴(kuò)縮規(guī)則，將多余的流量引導(dǎo)至集群。這可以使我們更早地發(fā)現(xiàn)問(wèn)題，確保Pod 在實(shí)際流量到達(dá)時(shí)能夠無(wú)縫擴(kuò)容。