集群故障處理之處理思路以及健康狀態檢查(三十二)

2021-09-25 23:25:42 字數 2421 閱讀 8260

總之,出現問題不要慌,先根據異常、故障症狀初步推敲問題的所在,然後結合相關命令、工具、日誌推敲出具體問題。其中,具體的日誌內容是關鍵,請務必獲得相關異常的詳細日誌進行診斷,而不是被表象所迷惑,或者根據表象問題(比如「***x」pod崩潰了)去猜、搜尋或者請教他人。總體上,思路如下圖所示:

如果問題實在無法解決或者無法確定是**的配置以及操作不當引起的,可以試著重置節點以及重置集群。

如果出現問題,我們應該怎麼去分析和解決問題呢?下面,筆者將分享一些思路和經驗:

健康狀態檢查——初診

首先,我們需要根據表象進行初步診斷,以便沿著線索按圖索驥。

使用命令:

kubectl get componentstatus

kubectl get cs
健康情況下如下圖所示:

kubernetes元件(外掛程式)部分預設基於systemd執行,比如kubelet、docker等,我們需要使用以下命令確保其處於活動(active)狀態:

而大部分的kubernetes的元件則執行在命名空間為「kube-system」的靜態pod 之中(參見「kubeadm init」一節),我們可以使用以下命令來檢視這些pod 的狀態:

k8s元件主要分為master元件和節點元件,master元件對集群做出全域性性決策(比如排程), 以及檢測和響應集群事件。如果master元件出現問題,可能會導致集群不可訪問,kubernetes api 訪問出錯,各種控制器無法工作等等。而節點元件在每個節點上執行,維護執行的pod並提供 kubernetes執行時環境。如果節點元件出現問題,可能會導致該節點異常並且該節點pod無法正常執行和結束。

因此,根據不同的元件,可能會出現不同的異常。

kube-apiserver對外暴露了kubernetes api,如果kube-apiserver出現異常可能會導致:

etcd用於kubernetes的後端儲存,所有的集群資料都存在這裡。保持穩定的etcd集群對於kubernetes集群的穩定性至關重要。因此,我們需要在專用計算機或隔離環境上執行etcd集群以確保資源需求。當etcd出現異常時可能會導致:

kube-controller-manager和kube-scheduler分別用於控制器管理和pod 的排程,如果他們出現問題,則可能導致:

kubelet是主要的節點**,如果節點宕機(vm關機)或者kubelet出現異常(比如無法啟動),那麼可能會導致:

coredns(在1.11以及以上版本的kubernetes中,coredns是預設的dns伺服器)是k8s集群預設的dns伺服器,如果其出現問題則可能導致:

kube-proxy是kubernetes在每個節點上執行網路**。如果它出現了異常,則可能導致:

我們可以使用以下命令來檢查節點狀態:

其中,「ready」表示節點已就緒,為正常狀態,反之則該節點出現異常。節點出現問題,則pod無法無法排程到該節點。

kubectl get pods -o wide
如果存在命名空間,需要使用-n引數指定命名空間。如上圖所示,pod為「running」狀態才是正常。

如果pod執行正常,但是又無法訪問(集群內部、外部),這時,我們需要檢查service是否正常,可使用以下命令:

docker+ kubernetes已成為雲計算的主流(二十五)

容器化之後如何節省雲端成本?(二十六)

了解kubernetes主體架構(二十七)

使用minikube部署本地kubernetes集群(二十八)

使用kubectl管理k8s集群(二十九)

使用kubeadm建立k8s集群之部署規劃(三十)

使用kubeadm建立k8s集群之節點部署(三十一)

Kafka集群故障處理細節

leo 指的是每個副本最大的offset hw 指的是消費者能讀到的最大的offset,isr佇列中最小的leo。hw 上圖消費者最多能讀到12,因為假如說leader掛掉了,那麼消費者讀到的話,肯定是讀整個集群中offset最小的那個.這個offset最小就意味著所有機器的offset肯定大於等於...

window集群故障處理1

平台 window server2016上的集群,由一組域控與兩個集群節點組成。故障 ip位址資源,集群位址被用占用,導致集群不可用。如下圖 群集ip位址資源 群集 ip 位址 無法聯機,因為已在網路上檢測到重複 ip 位址。請確保所有 ip 位址都是唯一的。原因查詢 通過檢視群集日誌發現,最初的報...

服務端解決故障的處理思路

簡單記錄一下解決伺服器故障的思路,以便今後迅速定位問題。1 出錯一般來說是兩種情況 1 邏輯出錯了 2 傳入引數出錯了 2 在上述情況都正確的情況下,那麼業務邏輯可能是正常執行了。這時錯誤可能就是其他原因 1 出錯的 在別的地方 2 rpc呼叫超時 3 盡可能搞清楚問題的前因後果,不要一下子就扎到伺...