前言

容器作為一種新的資源類型，已經應用于各大公司，G行也不例外。容器的輕量化特性使得它能夠在故障發生時快速進行重建，將對業務的影響降到最低，我們通常稱它為自愈。在Kubernetes中，自動重建的邏輯是什么？為什么我們經常說到Pod自愈而不是容器自愈？如何判定Pod狀態，Pod都有什么狀態？重啟策略都有什么，是什么推動重啟？對于不同的重啟資源需求，G行如何實現？下文將一一講述。

圖1 Kubernetes架構

一、容器自愈

談到容器自愈，為什么說是通過Pod自愈實現的呢？Pod是一組（一個或多個）容器，這些容器共享Pod的存儲、網絡、以及運行容器的聲明。且Pod是K8s（即Kubernetes）的最小部署管理計算單元。K8s是CNCF（Cloud Native Computing Foundation）的畢業項目之一，是目前市場使用最廣泛的自動化部署、擴展和管理成千上萬容器化應用程序的開源系統，也是G行采用的容器管理工具。Pod運行在被稱作是Node的節點中，節點既可以是物理機，也可以是虛擬機。當K8s判定Pod出現問題且需要被殺死的時候，會在運轉正常且資源充足的Node節點重建完成，從而完成自愈。

圖2 CNCF的畢業項目和孵化中的項目

二、Pod狀態判定

應用程序可能因多種原因而變得不可靠，例如：暫時失聯、配置錯誤、應用程序錯誤、硬件故障、資源緊張等。那么如何檢測運行著應用程序的pod健康狀態是好還是壞呢，K8s是通過探針來檢查的，探針有三種：ReadinessProbe、StartupProbe及LivenessProbe。

 ReadinessProbe（就緒）探針：用于判斷容器服務是否可用（即是否為ready狀態），只有Ready狀態的Pod才可以接收服務請求。

StartupProbe（啟動）探針：適用于應用程序啟動緩慢、網絡訪問延遲等場景，相應造成容器啟動緩慢的情況。

LivenessProbe（存活）探針：用于判斷容器是否存活①（即是否為running狀態），如果探針檢測到容器不健康，則Kubelet將殺死這個容器，并根據容器的重啟策略（重啟策略后面會說）做相應的處理。

G行通過同時使用ReadinessProbe（就緒）探針和LivenessProbe（存活）探針來判定Pod的狀態。

K8s提供了5個控制這些探針的選項：

圖片

而這三種探針均可以通過以下三種方式②實現：

HTTPGetAction

通過容器的IP地址、端口號及路徑調用http get方法，如果相應的狀態碼大于等于200且小于400，則認定容器是健康狀態。

TCPSocketAction

通過容器的IP地址和端口號執行tcp檢查，如果能夠建立tcp連接，則表明容器健康。

ExecAction

在容器內部運行一個命令，如果返回碼為0，則表示容器健康，否則表示不健康。

 G行使用HTTPGetAction和TCPSocketAction兩種方式查看連接情況。

運維人員可以使用Kubectl命令行客戶端或Yaml部署模板來配置探針和IP地址、端口號、路徑連接方式。下面是以LivenessProbe探針、HTTPGetAction連接方式為例，編寫的Yaml文件：

圖片

三、Pod重啟策略

知道如何檢查Pod的健康狀態了，如果不健康，該如何進行重啟呢？這里就需要說到Pod的重啟策略（restartPolicy）了。

重啟策略應用于Pod內的所有容器，由Pod所處的Node上的Kubelet進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時，Kubelet會根據重啟策略的設置進行相應的操作。

Pod的重啟策略有Always、OnFailure、Never三種，Default為Always。

Always：當容器失效時，由Kubelet自動重啟該容器

OnFailure：當容器終止運行且退出碼不為0時，由Kubelet自動重啟該容器。

Never：不論容器運行狀態如何，Kubelet都不會重啟該容器。

圖3 示例Pod在G行Prometheus的可視化平臺Grafana上的重啟情況，紅線為閾值

Pod如何重啟

重啟策略明確了，那么是靠誰來完成重啟的呢？是靠控制器來實現的。

在講述控制器之前，先考慮這樣一個場景：Pod沒有副本，如果這個Pod出現問題，上面跑的容器應用也就無法運轉了，服務也就中斷了。所以在K8s中，在創Pod之初，就是以多副本的形式創建的。這種負責Pod副本的創建、Pod重啟、調度及全生命周期自動控制的組件叫做控制器（也叫工作負載，即workload）。

控制器根據不同的功能分為Replicaset與Deployment、 DaemonSet、StatefulSet、Job和Cronjob幾種。這幾種控制器G行都有使用，并且在G行自建的容器統一管理平臺進行了部署。這個平臺融合管理了云上所有的應用相關容器資源，提高了運維效率。

圖4 G行容器統一管理平臺登錄首頁

Replicaset與Deployment  

圖片

圖5   Deployment控制器下兩種Pod滾動升級方式，分別是Recreate和Rolling update，各適用于大版本和小版本

 ReplicaSet（簡稱rs）是Replication Controller的升級版，是副本集的意思，用于保證K8s集群中有指定數量的Pods副本在運行③。一般不單獨使用，而是作為Deployment理想狀態的參數使用。且擁有集合式的標簽選擇器，可以選擇多個標簽。    

Deployment被稱作是副本控制集（即rs）的控制器，通過為應用程序創建一個或多個rs以管理應用程序的多個版本。通過每個副本控制集（rs）的模板和副本保持的能力來管理無狀態應用的工作負載（應用程序集群），比如web集群。

DaemonSet

圖6 展示了DaemonSet這種類型的控制器的Pods部署

DaemonSet是特殊類型的Deployment，在集群中的全部或者部分節點上，每個節點上有且僅有一份Pod的副本資源在運行。比如系統的監控、日志的收集、分布式存儲、網絡的代理等，都需要每個成員節點上有且只有一個Pod。例如：每個Node上只需要運行一個日志采集程序Logstach，或者只運行一個性能監控程序Prometheus Node Exporter。

而且后續加入集群的新的節點也會自動創建一個相同的Pod對象。管理員也可以使用Nodeselector（節點選擇器）配合節點Label指定僅在部分具有特定特征的節點上運行指定的Pod對象。

StatefulSet

圖7 有狀態集在一個Pod故障被殺死，并重建新Pod的情況

用來管理有狀態應用的工作負載（應用程序集群），管理Pods集合的部署和伸縮，并為這些Pods提供持久存儲和持久標識符。與Depolyment類似，Statefulset管理基于相同容器模板的一組Pods。但與Depolyment不同的是，Statefulset為每個Pod維護了一個有粘性的ID。這些Pods是基于相同的模板，但是不能相互替換，即無論怎么調度，每個Pod都有一個永久不變的ID。

Job和Cronjob

圖8 Job和Cronjob在完成工作后回收算力的場景展示

Job是用來定義并啟動一個批處理任務，是單次性作業控制器。這任務通常并行或者串行啟動多個計算進程去處理一批工作項，即work item，工作項處理完成后，整個批處理任務結束。比如Hadoop的離線數據處理、視頻解碼、或者HPC業務等，都需要很多個節點提供一個集中式的大算力。與傳統算力相比，Job控制器能在保留結果的同時，快速回收算力，因為一個Job完成后，就會立即殺死使用的Pod。

 Cronjob控制器用于周期性調度Job控制器。傳統環境使用的一般用到的是7*24小時不間斷的備份服務器，現在可以使用Cronjob控制器周期性的起一個Job作業，做完后，保留結果，殺死Pod，回收算力。Cronjob基本照搬了Linux操作系統的周期性任務Crontab，用minutes、hours、dayofmonth、month、dayofweek來進行定義。

需要注意，一些控制器對Pod的重啟策略要求，G行也是按如下執行的：

Replicaset或者DaemonSet：必須設置為always，需要保證該容器持續運行。

 Job：onFailure或Never，確保容器執行完成后不再重啟。

特定場景的Pod重啟

Pod對Node有特定要求的場景：

Node節點的配置是多種類型的，比如有的安裝了SSD磁盤，有的沒有。有的是AMD64的，有的是AMD32的。如果想著把新建的Pod運行在AMD64的Node上，該怎么做呢。下面是Pod的Yaml配置：

圖片

Pod之間相互依存或者互斥的場景：

     現在想新建這么兩個Pod，有互相依存關系，需要放到同一個Region內，該如何實現呢。像這種互為親和或者互斥關系的Pod是通過在Yaml文件中增加TopologyKey屬性，來聲明目標拓撲內的Pod是否在一起的。下面是一個親和的例子，目標Pod的標簽值是APP：”Nginx”。親和Pod的標簽值也是一樣。增加的TopologyKey值為topology.kubernetes.io/region，意味著這兩個Pod給配置到了同一個Region下。

圖片

 這些相互依賴或者相互之間頻繁調用的Pod，需要盡可能的部署在同一個Zone、機房、機架、Node節點。反之，就需要讓這些Pod盡可能的互相遠離。簡而言之，就是Pod之間在同一個拓撲域中共存或互斥。拓撲域指由相同地理空間中的幾個Node節點組成。

一些常規的拓撲域有：

kubernetes.io/hostname；topology.kubernetes.io/region；topology.kubernetes.io/zone。

四、總結

在企業實際在使用容器這類資源的時候，除了技術本身，要考慮的其他問題也會很多。企業管理的容器有千千萬萬，出于效率考慮，對于有特殊需求的容器如何進行批量創建和管理呢，這就需要在統一管理平臺按照相應的模板進行創建與維護。在Pod進行重建后，如何保證客戶端應用屏蔽這些Pod IP地址的變化及數量的變化呢，這就需要通過定義Pod上層的Service進行保障。不同的應用系統有自身的架構特點，在進行控制器配置的時候如何進行考量呢，需要選擇哪種控制器呢，這就需要進行交付前的資源配置梳理。等等問題。總之，在考慮到基本的技術特性的同時，再應用系統自身特點相結合，才能夠將技術的最大價值加以發揮。

五、附錄

① 容器的狀態一共有五個：created（已創建）、running（運行中）、paused（暫停）、exited（停止）、dead（死亡）、restarted（重啟中）、removing（遷移中）。

②每種探測方式，還需要額外設置initialDelaySeconds和timeoutSeconds這兩個參數。initialDelaySeconds表示容器啟動后進行首次健康檢查的等待時間，單位是秒。timeoutSeconds表示健康檢查請求發送后等待響應的超時時間，單位是秒。如果超時，則Kubelet認為容器無法提供服務，會重啟該容器。

③例如：Pod所在節點發生宕機，K8s就會第一時間觀察到這個故障，并自動創建一個新Pod對象，將其調度到其他合適的節點上，K8s會實時監控集群中目標Pod的副本數量，并盡力與Deployment中聲明的Replicas數量保持一致。