kubernetes的常見故障

1.節點CNI不可用，其他節點無法連接到故障節點的Pod。

2.在子路徑模式下安裝的Configmap在某些情況下存在Pod無限重啟的問題。

3.群集DNS服務器無法通過上遊DNS解析外部名稱。

4.節點假裝死亡，但是Ceph RBD的觀察者沒有釋放，導致有狀態服務的Pod調度在它離開後仍然無法啟動。

5.誤刪除Etcd數據和持久卷。

有四個有用的命令來排除Pod故障:

Kubectl日誌有助於檢索Pod容器的日誌。

Kubectl describe pod對於檢索與pod相關的事件列表非常有用。

Kubektl getPod用於提取Kubernetes中存儲的Pod的YAML定義。

Kubectl exec -ti bash對於在Pod的容器中運行交互式命令非常有用。

常見Pod錯誤

Pod可能有啟動和運行時錯誤。

啟動錯誤包括:

ImagePullBackoff

圖像檢查錯誤

ErrImagePull

ErrImageNeverPull

註冊表不可用

無效圖像名稱

運行時錯誤包括:

碰撞回路回退

RunContainerError

KillContainerError

VerifyNonRootError

RunInitContainerError

CreatePodSandboxError

ConfigPodSandboxError

KillPodSandboxError

SetupNetworkError

TeardownNetworkError

有些錯誤比其他錯誤更常見。

下面列出了最常見的錯誤以及如何修復它們。

ImagePullBackOff

當Kubernetes無法獲取Pod中容器的鏡像時，會出現此錯誤。

* * *有三種可能的原因:

圖像名稱無效-例如，您拼錯了名稱，或者圖像不存在。

您為不存在的圖像指定了標簽。

您試圖檢索的圖像屬於私人註冊表，Kubernetes沒有訪問它的憑據。

前兩種情況可以通過糾正圖像名稱和標簽來解決。

對於第三種情況，妳要通過Secret給k8s添加private registry的訪問憑證，並在Pod中引用。

關於如何實現這個目標，官方文件中有壹個例子。

碰撞回路回退

如果容器無法啟動，Kubernetes會將錯誤狀態顯示為:CrashLoopBackOff。

通常，在下列情況下不能啟動容器:

應用程序出錯，導致無法啟動。

您沒有正確配置容器。

活性探測失敗了太多次。

您應該嘗試從該容器中檢索日誌，以調查失敗的原因。

如果因為容器重啟太快而看不到日誌，可以使用以下命令:

$ kubectl日誌& ltpod-name & gt；-以前的？

該命令打印前壹個容器的錯誤信息。

RunContainerError

當容器無法啟動時，會出現此錯誤。

甚至在容器中的應用程序啟動之前。

此問題通常是由配置錯誤引起的，例如:

裝入不存在的卷，如ConfigMap或Secrets。

以讀寫方式裝載只讀卷。

您應該使用kubectl describe pod命令來收集和分析錯誤。

Pod處於掛起狀態

創建Pod後，它將保持掛起狀態。

為什麽？

假設您的調度程序組件運行良好，可能的原因如下:

群集沒有足夠的資源(如CPU和內存)來運行Pod。

當前命名空間有壹個ResourceQuota對象，創建Pod會使命名空間超出配額。

該Pod綁定到處於掛起狀態的PersistentVolumeClaim。

最好的選擇是檢查kubectl describe命令輸出的“events”部分:

$ kubectl描述pod & ltpod名稱& gt？

對於由資源配額導致的錯誤，您可以通過以下方式檢查群集的日誌:

$ ku bectl get events-sort-by = . metadata . creation timestamp？

Pod處於未就緒狀態

如果Pod正在運行但未就緒，則就緒就緒探測失敗。

當就緒探測失敗時，Pod沒有連接到服務，也沒有流量轉發到此實例。

ready探針的失敗是應用程序的壹個特定錯誤，因此您應該檢查kubectl describe中的“event”部分來識別錯誤。

2.服務故障排除

如果您的Pod正在運行並準備就緒，但是您仍然不能從應用程序接收到響應，您應該檢查服務是否配置正確。

服務被設計為根據其標簽將流量路由到Pod。

因此，您應該檢查的第壹件事是有多少個pod與服務相關聯。

您可以通過檢查服務中的端點來做到這壹點:

$ kubectl描述服務& lt服務名稱& gt| grep端點？

端點是壹對，當服務(至少)以Pod為目標時，應該至少有壹個端點。

如果端點部分為空，有兩種解釋:

您沒有使用正確的標簽運行Pod(提示:您應該檢查您是否在正確的名稱空間中)

服務的選擇器標簽上有壹個錯別字。

如果您看到了端點列表，但是仍然無法訪問您的應用程序，那麽targetPort可能是您的服務中的罪魁禍首。

妳如何測試服務？

不管服務類型如何，您都可以使用kubectl port-forward來連接它:

$kubectl端口轉發服務/& lt；服務名稱& gt3000:80?

這裏:

是服務的名稱。

3000是您要在計算機上打開的端口。

80是服務公開的端口。

3.3的故障排除。進入

如果您已經到達這壹部分，那麽:

Pod正在運行並準備就緒。

該服務將流量分配給Pod。

但是妳還是看不到應用的響應。

這意味著入口很可能配置不正確。

因為使用的入口控制器是集群中的第三方組件，所以根據入口控制器的類型，有不同的調試技術。

但是在深入研究Ingress專用工具之前，可以通過壹些簡單的方法進行檢查。

Ingress使用serviceName和servicePort連接到服務。

您應該檢查這些配置是否正確。

您可以通過以下命令檢查入口配置是否正確:

$kubectl描述入口& ltingress-name >？

如果後端列為空，則配置中壹定有錯誤。

如果您可以在“後端”列中看到端點，但仍然無法訪問應用程序，則可能是以下問題:

如何向公共互聯網公開Ingress？

如何向公共互聯網公開集群？

通過直接連接到Ingress Pod，您可以將基礎架構問題與Ingress隔離開來。

首先，獲取入口控制器盒(可以位於其他名稱空間中):

$ kubectl get pods - all-namespaces？

命名空間名稱就緒狀態？

kube-system core DNS-5644d 7 b 6d 9-jn7cq 1/1運行？

kube-system etcd-minikube 1/1運行？

kube-system kube-API server-minikube 1/1運行？

kube-系統kube-控制器-管理器-minikube 1/1運行？

kube-system kube-proxy-zvf2h 1/1運行？

kube-system kube-scheduler-minikube 1/1正在運行？

kube-系統nginx-ingress-controller-6 fc 5 bcc 1/1運行？

描述它以檢索端口:

# kubectl描述pod nginx-ingress-controller-6 fc 5 bcc？

-命名空間kube-system \？

| grep端口？

最後，連接到Pod:

$ ku bectl port-forward nginx-ingress-controller-6 fc 5 bcc 3000:80-namespace kube-system？

此時，每次訪問計算機上的端口3000時，請求都會被轉發到Pod上的端口80。

我現在能使用它嗎？

如果是，問題出在基礎設施上。您應該調查流量是如何路由到您的集群的。

如果不行，問題出在Ingress控制器。您應該調試入口。

如果還是不能讓Ingress控制器正常工作，就要開始調試了。

目前，有許多不同版本的入口控制器。

熱門選項有Nginx，HAProxy，Traefik等。

您應該查閱入口控制器的文檔，了解故障排除指南。

由於Ingress Nginx是最受歡迎的Ingress控制器，我們將在下壹節介紹壹些關於調試ingress-nginx的技巧。

調試入口Nginx

Ingress-nginx項目有壹個針對Kubectl的官方插件。

您可以使用kubectl ingress-nginx來:

檢查日誌，後端，證書等。

連接到入口

檢查當前配置。

您應該嘗試的三個命令是:

Kubektl ingress-nginxlint，它將檢查nginx.conf

Kubectl ingress-nginx backend檢查後端(類似於Kubectl描述ingress)。

Kubectl ingress-nginx日誌，檢查日誌。

請註意，您可能需要為入口控制器指定正確的名稱空間。

kubernetes的故障排除和節點維護(2)

系列目錄

案例網站:

測試環境集群正常，突然間歇性無法正常訪問服務。過壹會兒，頁面刷新後可以正常訪問了。當妳去服務所在的pod時，妳沒有發現任何異常。使用kubectl get node命令，您會發現壹個節點沒有準備好。

為了方便觀察，我們使用kubectl get node - watch觀察了壹段時間，發現k8s-node1節點不停地在Ready和NotReady狀態之間切換(使用kubectl get node -o wide，可以查看節點的ip信息)。

進入有問題的節點，用journalctl -f -u kubelet命令查看kubelet的日誌信息，截出錯誤日誌進行搜索，發現問題基本和這個壹樣。發現這個問題的時間和github上issue提出的時間是壹樣的。我也沒有看到解決方案，但是基本可以確定集群中k8s-node1上的kubernetes版本不壹致(從上面的截圖可以看出，這個節點的版本是1.14.1，其他的是1.13.1。

搜索kubernetes NotReady看到壹些解決方案，很多是重啟docker，kubectl等。，然後他們解決不了問題，就嘗試重置這個節點。

從集群中刪除節點

因為服務正在此節點上運行，直接刪除節點將使服務不可用。我們首先使用kubectl drain命令驅逐這個節點上的所有pod。

kubectl drain k8s-node 1-delete-local-data-force-ignore-daemonsets

上面命令中的- ignore-daemonsets經常需要指定，因為deamonset會忽略未調度的標簽(使用kubectl drain時，節點會自動標記為未調度)，所以deamonset控制器控制的pod可能會在刪除後立即在這個節點上啟動，這就變成了壹個死循環。因此，daemonset在這裏被忽略。

事實上，在使用kubectl drain時，命令行已經被阻塞了。等了很久，還是堵。當使用kubectl get pod命令檢查pod的狀態時，其中壹個名為busybox的pod總是處於終止狀態。使用kubectl delete pod busybox也不能刪除它。此時，您可以使用命令kubectl刪除pod Busybox-grace-period = 0-force來強制立即刪除pod。

此時，控制臺阻塞狀態結束。接下來，執行命令ku bectl delete node K8s-node 1來刪除這個節點。然後我們重裝kubelet，kubeadm和kubectl。

卸載舊版本

如果是yum安裝的，可以通過yum list installed|grep xxx找到安裝的組件，然後刪除。刪除後重新安裝。

這裏重裝的原因是版本已經升級到了更新的版本。如果版本相同，其他不確定因素導致節點不穩定，找不到具體原因，可以通過kubeadm reset重置安裝。

reset命令不會復位設定的iptables規則和IPVS。如果您想要重置iptables，您需要執行以下命令:

iptables-F & amp；& ampiptables-t NAT-F & amp；& ampiptables-t mangle-F & amp；& ampiptables -X

如果您想重置IPVS，您需要執行以下命令:

ipvsadm -C

這裏我基本可以確認是版本不壹致導致的，所以不重置iptables和IPVS，只重裝組件。

重新加入集群

重置完成後，我們使用kubeadm join將刪除的k8s-node1節點重新加入集群。

如果忘記了主節點初始化時生成的join token，可以在主節點上執行kube ADM token create-print-join-command重新生成join token，然後將生成的命令復制到加入集群的節點上執行。