本文將幫助你釐清在Kubernetes中除錯 deployment的思路。下圖是完整的故障排查思路，如果你想獲得更清晰的圖片，請在公眾號後臺（RancherLabs）回覆“troubleshooting”。

當你希望在Kubernetes中部署一個應用程式，你通常需要定義三個元件：

• Deployment——這是建立名為Pods的應用程式副本的方法

• Serivce——內部負載均衡器，將流量路由到Pods

• Ingress——可以描述流量如何從叢集外部流向Service

接下來，我們通過圖片快速回顧一下。

在Kubernetes中，你的應用程式通過兩層負載均衡器暴露：內部和外部。

內部負載均衡器稱為Service，而外部負載均衡器則稱為Ingress。

Pod未直接部署，因此，Deployment建立Pod並監視它們。

假設你想部署一個簡單的Hello World應用程式，那麼對於此類應用程式，其YAML檔案與以下類似：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /
 

這個定義很長，容易忽略元件之間的相互關係。

例如：

• 你什麼時候應該使用80埠，什麼時候使用埠8080？

• 你是否應該為每個服務建立一個新埠，以免它們衝突？

• 標籤（label）名稱重要嗎？是否應該每一處都一樣？

在進行debug之前，我們先來回顧一下這三個元件之間的關係如何。

首先，我們從Deployment和Service開始。

連線Deployment和Service

實際上，Deployment和Service根本沒有連線。相反，該Service直接指向Pod，並完全跳過Deployment。所以，你應該關注的是Pod和Service是如何與彼此關聯的。你應該記住三件事：

1. Service selector至少與Pod的一個標籤匹配

2. Serivce targetPort應該與Pod內的容器的containerPort相匹配

3. Serviceport可以是任何數字。多個Service可以使用同一個埠，因為它們已經被分配了不同的IP地址

以下圖片總結了如何連線埠：

考慮由Service暴露的pod

當你建立一個pod，你應該在你的Pod中為每個容器定義埠containerPort

當你建立一個Service時，你能夠定義一個port和一個targetPort。但你應該將哪一個連線到容器呢？

targetPort與containerPort應該能夠匹配

如果你的容器暴露埠3000，那麼targetPort應該與該數字相匹配。

如果你查看了YAML，標籤與ports或targerPort應該匹配：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    any-name: my-app

那麼在Deployment頂部的track: canary標籤呢？也應該匹配嗎？

那個標籤屬於deployment，並且Service selector不使用它來路由流量。換言之，你可以安全地將其移除或者給它分配不同的值。

那麼matchLabelsselector呢？它需要與Pod標籤匹配並且Deployment使用它來跟蹤Pod。

假設你做了一個正確的更改，你應該如何測試它呢？你可以使用以下命令檢查Pod是否擁有正確的標籤：

kubectl get pods --show-labels

或者如果你有屬於多個應用程式的Pod：

kubectl get pods --selector any-name=my-app --show-labels

其中any-name=my-app是標籤any-name: my-app。依舊存在問題？你也可以連線到Pod。你可以在kubectl中使用命令port-forward連線到Serivce並測試連線。

kubectl port-forward service/<service name> 3000:80

其中：

• service/<service name>是serivce的名稱——在當前YAML中，是“my-service”。

• 3000是你希望在你的電腦上開啟的埠

• 80是Service在port欄位中暴露的埠

如果你能夠連線，那麼設定就是正確的。如果你無法連線，你很有可能弄錯了標籤或者埠未匹配。

連線Service和Ingress

暴露應用程式的下一步是配置Ingress。Ingress必須知道如何檢索Service，然後檢索Pod並將流量路由到它們。Ingress通過名稱和暴露的埠來檢索正確的Service。

在Ingress和Service中應該匹配兩件事：

1. Ingress的servicePort應該與Service的port匹配

2. Ingress的serviceName應該與Service的name相匹配

以下圖片將總結如何連線埠：

你已經知道該服務暴露了一個埠

Ingress有一個名為servicePort的欄位。

Serviceport和IngressservicePort應該相匹配

如果你決定分配埠80給該service，你應該同時更改servicePort為80

實際操作中，你需要檢視這些命令列：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: my-service
        servicePort: 80
      path: /

你應該如何測試Ingress是否正常執行呢？你可以使用和之前相同的策略，即kubectl port-forward，但不是連線到service，而是連線到Ingress controller。

首先，使用以下命令為Ingress controller檢索Pod名稱：

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

驗證Ingress Pod（可能在不同的名稱空間）並且描述它以檢索埠：

kubectl describe pod nginx-ingress-controller-6fc5bcc \
 --namespace kube-system \
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

最後，連線到Pod：

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此時，每次你在你的電腦上訪問埠3000，請求就會被轉發到在Ingress controller Pod上的埠80。

如果你訪問 http://localhost:3000 ，你應該能找到提供網頁的應用程式。

簡單回顧一下

現在，我們來快速回顧一下什麼埠和標籤需要匹配：

1. Service selector應該匹配Pod的標籤

2. ServicetargerPort應該匹配在Pod內容器的containerPort

3. Service 埠可以是任意數字。多個Service可以使用同個埠，因為它們已經分配了不同的IP地址

4. Ingress的servicePort應該匹配在Service中的port

5. Service的名稱應該匹配在Ingress中的serviceName的欄位

瞭解如何構造YAML只是開始。那麼，出了問題時會有什麼表現？Pod可能無法啟動，或者直接崩潰。

3步排查K8S Deployment故障

在我們深入研究有故障的deployment之前，必須有一個明確定義的模型，以瞭解Kubernetes的工作方式。

既然在每個deployment中都有那三個元件，你應該從底層開始按順序除錯它們。

1. 你應該確保你的Pod正在執行

2. 著重關注使Service將流量路由到Pod

3. 檢查Ingress是否正確配置

你應該從底層開始排查Deployment故障。首先，檢查Pod是否準備就緒並且正在執行

如果Pod已經準備就緒，你需要檢查Service是否可以將流量分配到Pod。

最後你應該檢查Service和Ingress之間的連線。

1、 故障排查Pod

在大多數情況下，問題出現在Pod本身。所以你應該確保Pod正在執行並準備就緒。應該如何檢查呢？

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

以上部分，只有最後一個Pod是正在執行並且準備就緒的，而前兩個Pod既沒有Running也沒有Ready。那麼，你應該如何定位是什麼出了問題呢？

這裡有4個十分有用的命令可以幫助你排查Pod的故障：

• kubectl logs <pod name>能夠幫助檢索Pod的容器日誌

• kubectl describe pod <pod name>能夠有效地檢索與Pod相關的事件列表

• kubectl get pod <pod name>對於提取儲存在Kubernetes中的Pod的YAML定義十分有用

• kubectl exec -ti <pod name> bash可以用於在Pod其中一個容器中執行一個互動式命令

你應該使用哪一個呢？實際上，沒有一種命令是萬能的，你可以根據實際情況結合使用。

常見的Pod錯誤

Pod可能會出現啟動和執行時的錯誤。

啟動錯誤包括：

• ImagePullBackoff

• ImageInspectError

• ErrImagePull

• ErrImageNeverPull

• RegistryUnavailable

• InvalidImageName

執行時錯誤包括：

• CrashLoopBackOff

• RunContainerError

• KillContainerError

• VerifyNonRootError

• RunInitContainerError

• CreatePodSandboxError

• ConfigPodSandboxError

• KillPodSandboxError

• SetupNetworkError

• TeardownNetworkError

這些錯誤中，有些比其他錯誤更為常見。以下是最常見的錯誤以及如何修復它們：

ImagePullBackOff

當Kubernetes無法檢索Pod其中之一的容器映象時，將出現此錯誤。

有三種常見原因：

• 映象名稱無效——例如，你錯誤拼寫名稱或映象不存在

• 你給這一映象指定了一個不存在的tag

• 你所檢索的映象是私有倉庫的，並且Kubernetes沒有訪問它的憑據

前兩個原因可以通過更正映象名稱和tag解決。最後一個，你需要將憑據新增到“Secret”中的私有映象倉庫中，並在Pod中引用它。

官方文件可以讓你更加清楚：

https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

CrashLoopBackOff

如果容器無法啟動，Kubernetes狀態將顯示CrashLoopBackOff訊息。

通常情況下，容器在以下場景中無法啟動：

• 應用程式中存在錯誤，導致無法啟動

• 你錯誤配置了容器

  https://stackoverflow.com/questions/41604499/my-kubernetes-pods-keep-crashing-with-crashloopbackoff-but-i-cant-find-any-lo

• Liveness探針失敗次數太多

你應該嘗試並檢索該容器的日誌以確定出現故障的原因。

如果由於你的容器重啟過快而無法檢視日誌，你可以使用以下命令：

kubectl logs <pod-name> --previous

它將從之前的容器中列印錯誤資訊。

RunContainerError

容器不能啟動時出現錯誤，甚至在容器內的應用程式啟動之前就無法啟動。

這個問題通常由於錯誤配置導致的，如：

• 安裝一個不存在的volume，如ConfigMap或Secret

• 將只讀volume安裝為可讀寫

你應該使用kubectl describe pod <pod-name>來收集和分析錯誤。

Pod處於Pending狀態

當你建立一個Pod時，Pod保持在Pending狀態。這是為什麼呢？假設你的排程元件運行了解，那麼有以下幾個原因：

• 叢集沒有足夠的資源來執行Pod，如CPU和記憶體

• 當前名稱空間有一個ResourceQuota物件並且所建立的Pod會使該名稱空間超過資源額度

• Pod與一個Pending狀態的PersistentVolumeClaim繫結。

那麼，最好的選擇是使用命令kubectl describe檢查事件：

kubectl describe pod <pod name>

對於由於ResourceQuotas造成的錯誤，可以使用以下方法檢查叢集的日誌：

kubectl get events --sort-by=.metadata.creationTimestamp

Pod不處於Ready狀態

如果Pod正在執行但是不Ready，這意味著Readiness探針出現故障。當Readiness探針出現故障時，Pod無法附加到Service上，並且流量無法轉發到例項上。

Readiness探針故障是特定於應用程式的錯誤，因此使用kubectl describe來檢查事件部分，以驗證錯誤。

2、 排查Service故障

如果你的Pod正在執行並且準備就緒，但是你依舊無法接收來自應用程式的響應，你應該檢查Service是否配置正確。

Service旨在根據pod的標籤將流量路由到Pod。所以第一件事，你需要檢查Service target多少個Pod。可以通過檢查Service中的Endpoint來完成此步驟：

kubectl describe service  <service-name>  |  grep Endpoints

一個endpoint是一對`

如果“Endpoint”部分是空的，那麼有兩種解釋：

1. 任何正在執行的Pod沒有正確的label（提示：你需要檢查以下你是否在正確的名稱空間內）

2. 在Service的selector標籤中有錯別字

如果你看到了endpoint列表，但依舊無法訪問你的應用程式，那麼你的Service中的targetPort可能是罪魁禍首。

你應該怎麼測試Service？無論Service型別是什麼，都可以使用kubectl port-forward連線到它：

kubectl port-forward service/<service-name> 3000:80

其中：

• `<service-name>是Service的名稱

• 3000是你想要在電腦上開啟的埠

• 80是由Service暴露的埠

3、 排查Ingress故障

如果你走到了這個部分，這意味著：

• Pod正在執行並且準備就緒

• Service可以分發流量給Pod

但你依舊無法接收app的響應。那麼這很有可能是Ingress配置出現錯誤。

由於使用的Ingress controller是叢集中的第三方元件，那麼根據Ingress controller的型別會由不同的除錯技術。但是在深入研究Ingress特定的工具之前，你可以使用一些簡單的方法檢查。

Ingress使用serviceName和servicePort連線Service。你應該檢查那些是否正確配置。你可以使用以下命令檢查Ingress是否正確配置：

kubectl describe ingress <ingress-name>

如果Backend列是空的，那麼配置中肯定存在錯誤。

如果你能在Backend列中看到endpoint，但依舊無法訪問應用程式，那麼可能是以下問題：

• 你將Ingress暴露於公網的方式

• 你將叢集暴露於公網的方式

你可以通過直接連線到Ingress Pod將基礎設施問題與Ingress隔離開來。

首先，為你的Ingress Controller檢索Pod（可能位於不同的名稱空間中）：

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

描述它以檢索埠：

kubectl describe pod nginx-ingress-controller-6fc5bcc
 --namespace kube-system \
 | grep Ports

最後，連線到Pod：

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此時，每次你在電腦上訪問埠3000，請求將會轉發到Pod上的埠80。

那麼，現在能夠正常運行了嗎？

如果正常工作，問題就出在基礎設施。你應該檢查流量如何路由到你的叢集。

如果無法正常工作，問題就在Ingress controller。你應該除錯Ingress。

如果仍然無法使Ingress controller正常工作，則應該開始對其進行除錯。市場有許多不同版本的Ingress controller。比較流行的包括Nginx、HAProxy、Traefik等。

你應該查閱Ingress controller的文件以查詢故障排查指南。

既然Ingress Nginx是最流行的Ingress controller，那麼在下一個部分我們將介紹一些相關的技巧。

除錯Ingress Nginx

Ingress-nginx有kubectl的官方外掛，你可以訪問以下網址檢視：

https://kubernetes.github.io/ingress-nginx/kubectl-plugin/

你可以使用kubectl ingress-nginx來進行以下操作：

• 檢查日誌、Backend、證書等

• 連線到Ingress

• 檢查當前的配置

你還可以嘗試以下三個命令：

• kubectl ingress-nginx lint這是用來檢查nginx.conf

• kubectl ingress-nginx backend來檢查Backend（與kubectl describe ingress <ingress-name>類似）

• kubectl ingress-nginx logs來檢查日誌

請注意，你需要使用--namespace <name>來指定正確的名稱空間。

總 結

如果你毫無頭緒，那麼在Kubernetes中進行故障排除可能是一項艱鉅的任務。

你應該永遠記住以從下至上的順序解決問題：現檢查Pod，然後向上移動堆疊至Service和Ingress。

而本文中的debug技術在其他地方也是通用的，例如：

• 出現故障的Jobs和CronJobs

• StatefulSets和DaemonSets

希望大家都沒有bug