Kubernetes 是最流行的容器編排和部署平臺。它的強大功能特性，可以保障在生產中可靠地運行容器化應用程序。

然而，有靈活性的同時也帶來了復雜性，在本文中，我們將探討許多團隊遇到的 10個常見 Kubernetes 陷阱。能夠識別并避免這些挑戰將提高應用程序的可擴展性、可靠性和安全性，同時讓你更好地控制集群及其部署。

1.使用 latest Tag 部署容器

可以說，Kubernetes 最常被違反的最佳實踐之一就是在部署容器時使用latest標簽。這將使我們面臨無意中接受重大變更的風險，而這些變更可能影響系統穩定性。

每個人使用 latest 標簽的方式各不相同，但大多數人都會將 latest 指向其項目的最新版本。例如，今天使用 helm:latest 將提供 Helm v3，但在v4版本發布后，重啟就會更新到v4，但是我們可能還認為系統運行的是 v3 版本，從而引發不可預知的風險。

2.不使用Liveness和Readiness 探針

探針可以使我們的應用程序更具彈性。它們會告知 Kubernetes Pod 的健康狀況。

當容器出現問題時，比如內存溢出，Liveness探針請求超時，那么Liveness探針會通知 Kubernetes 重啟容器。

有時候應用會暫時性地無法為請求提供服務。例如，應用在啟動時可能需要加載大量的數據或配置文件，或是啟動后要依賴等待外部服務。在這種情況下，既不想殺死應用，也不想給它發送請求。Kubernetes 提供了Readiness探針來發現并緩解這些情況，容器所在 Pod 上報還未就緒的信息，并且不接受通過 Kubernetes Service 的流量。

下面是一個包含有效性和就緒性探針的簡單 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. 缺少節點選擇器導致調度效率低下

集群的整體性能取決于 Pod 是否被正確調度到合適的節點上。許多集群包含多種類型的節點，例如用于標準應用程序的小型 2 CPU/4 GB節點和用于密集后端服務的較大8 CPU/16GB節點。

如果Pod無法可靠地調度到我們想要的節點池，那么集群利用率將會很低。例如即使有未充分利用的較小節點，也會強制創建不必要的新的較大節點，從而增加集群的成本。通過在節點上設置標簽，然后使用節點選擇器將每個 Pod 分配給兼容的節點來避免此問題：

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

此 Pod 只會調度到設置了標簽的節點node-class: 2c4g

使用命令在匹配的節點上設置標簽：kubectl label

設置適當的調度規則將最大限度地提高節點利用率并保持穩定的集群性能。

4.破壞 Pod 親和性/反親和性規則

Pod 親和性和反親和性規則允許指示 Kubernetes 哪個節點最適合部署Pod。規則可以以節點級特征（例如標簽）或已在節點上運行的其他 Pod 的特征為條件。

親和性規則將Pod吸引到 Node，使得 Pod 更有可能調度到特定Node上，而反親和性則具有排斥作用，降低了調度的概率。Kubernetes 會評估每個可用于調度的可能節點的 Pod 親和性規則，然后選擇最合適的一個。

親和力系統能夠支持復雜的調度行為，但也很容易錯誤配置親和力規則，Pod會意外地調度到不正確的節點，或者拒絕調度。

比如一個服務的兩個副本，應該調度在兩個Node上，這樣如果一個 Node 節點發生故障時，可以保證服務的另一個副本可用，如果規則設置不正確都調度到一個Node 上那么會導致服務不可用。

5. 沒有監控/記錄

當在Kubernetes 中擴容應用程序時，了解集群資源利用率、應用程序錯誤和實時性能數據至關重要。內存消耗激增、Pod 驅逐和容器崩潰都是我們應該了解的問題，但標準 Kubernetes不具備任何可觀測性功能，以便在故障發生時發出告警。

要啟用對集群的監控，我們應該部署可觀測性平臺，例如 Prometheus、夜鶯。這會從 Kubernetes 收集指標，同時在Grafana查看相關數據指標。同時也有告警機制。

6. 標簽選擇器不匹配

部署和服務等對象依賴正確的標簽選擇器來識別 Pod 及其管理的其他對象。選擇器與實際分配給對象的標簽之間的不匹配將導致部署失敗。

示例：

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

以上文件部署會拋出selector does not match template labelsspec.selector.matchLabelsspec.template.metadata.labels要解決此問題，請調整清單的 和 字段，使它們具有相同的鍵值對

7. 服務端口不匹配

同樣，確保Service將流量路由到Pod上的正確端口也很重要。不正確的端口定義可能會使 Pod 看起來像是發生了故障，而實際上流量根本沒有到達該 Pod。

以下清單包含此問題的示例。該Service監聽9000端口并將流量轉發到其 Pod上的8080端口 ，但容器實際上端口是80，所以流量無法到達。

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. 意外部署到錯誤的命名空間

Kubernetes命名空間將一組服務邏輯分組在一起，在集群中提供一定程度的隔離。為每個團隊、應用和環境創建命名空間可以防止名稱沖突并簡化管理體驗。

使用命名空間時，請記住為每個服務和Kubectl命令指定目標命名空間。否則，將使用默認命名空間default。如果服務沒有部署在合適的命名空間下，會導致相關服務器請求不可達。

以下清單為Istio Ingress轉發配置，此文件部署在seg空間下，然后根據/dp-manager請求，轉發到seg空間下的dp-manager-backend服務，如果dp-manager-backend不在 seg空間下，那么會導致請求異常。

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. 沒有資源請求和限制的 Pod

正確的資源管理對于保持集群的穩定性至關重要。Pod默認沒有任何資源限制，除非我們對其進行配置，因此這可能會導致Node節點CPU 和內存耗盡。

在所有 Pod 上設置適當的資源請求和限制以減少資源爭用。請求Kubernetes為我們的 Pod 預留特定數量的資源，防止其調度到無法提供足夠容量的節點上。Limits設置Pod可以使用的最大資源量；超過 CPU 限制的 Pod 將受到限制，而達到內存限制則會提示內存不足 (OOM) 從而終止 Pod 允許。

請求和限制在 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 請求100m（1000m等于1核）CPU 時間和 1Gi 內存。它只會調度到可以提供足夠資源的節點上。Pod 還設置了內存限制，最大可以申請2Gi 內存。最佳實踐是將 Pod 的內存限制設置為等于其請求。通常不需要 CPU 限制，因為 Kubernetes 會按比例限制超出其請求的 Pod。

10. 集群自動擴容錯誤

選擇Kubernetes原因之一就是它的彈性擴容。正確配置可以使Kubernetes在需求高峰時自動添加新的 Pod 和節點，從而動態的水平和垂直擴容。但是不幸的是，很多團隊它們的自動擴容是不可預測的。

因此定期檢查集群的利用率，以檢查它是否仍然適合您的工作負載。使用負載測試工具（例如Locust）測試自動擴縮規則，將多余的流量引導至集群。這可以使我們更早地發現問題，確保Pod 在實際流量到達時能夠無縫擴容。