轎車從天而降電動車主被撞身亡 超速搶道所致：現(xiàn)場視頻讓網(wǎng)友吵翻
近日，上海青浦區(qū)法院判決轎車從天而降電動車主被撞身亡案，轎車車主被判有期徒刑一年。案件顯示當時男子駕駛轎車在上海某路段行駛，前車忽然轉(zhuǎn)彎提速超車，
容器作為一種新的資源類型，已經(jīng)應用于各大公司，G行也不例外。容器的輕量化特性使得它能夠在故障發(fā)生時快速進行重建，將對業(yè)務的影響降到最低，我們通常稱它為自愈。在Kubernetes中，自動重建的邏輯是什么？為什么我們經(jīng)常說到Pod自愈而不是容器自愈？如何判定Pod狀態(tài)，Pod都有什么狀態(tài)？重啟策略都有什么，是什么推動重啟？對于不同的重啟資源需求，G行如何實現(xiàn)？下文將一一講述。
圖1 Kubernetes架構
談到容器自愈，為什么說是通過Pod自愈實現(xiàn)的呢？Pod是一組（一個或多個）容器，這些容器共享Pod的存儲、網(wǎng)絡、以及運行容器的聲明。且Pod是K8s（即Kubernetes）的最小部署管理計算單元。K8s是CNCF（Cloud Native Computing Foundation）的畢業(yè)項目之一，是目前市場使用最廣泛的自動化部署、擴展和管理成千上萬容器化應用程序的開源系統(tǒng)，也是G行采用的容器管理工具。Pod運行在被稱作是Node的節(jié)點中，節(jié)點既可以是物理機，也可以是虛擬機。當K8s判定Pod出現(xiàn)問題且需要被殺死的時候，會在運轉(zhuǎn)正常且資源充足的Node節(jié)點重建完成，從而完成自愈。
圖2 CNCF的畢業(yè)項目和孵化中的項目
應用程序可能因多種原因而變得不可靠，例如：暫時失聯(lián)、配置錯誤、應用程序錯誤、硬件故障、資源緊張等。那么如何檢測運行著應用程序的pod健康狀態(tài)是好還是壞呢，K8s是通過探針來檢查的，探針有三種：ReadinessProbe、StartupProbe及LivenessProbe。
ReadinessProbe（就緒）探針：用于判斷容器服務是否可用（即是否為ready狀態(tài)），只有Ready狀態(tài)的Pod才可以接收服務請求。
StartupProbe（啟動）探針：適用于應用程序啟動緩慢、網(wǎng)絡訪問延遲等場景，相應造成容器啟動緩慢的情況。
LivenessProbe（存活）探針：用于判斷容器是否存活①（即是否為running狀態(tài)），如果探針檢測到容器不健康，則Kubelet將殺死這個容器，并根據(jù)容器的重啟策略（重啟策略后面會說）做相應的處理。
G行通過同時使用ReadinessProbe（就緒）探針和LivenessProbe（存活）探針來判定Pod的狀態(tài)。
K8s提供了5個控制這些探針的選項：
圖片
而這三種探針均可以通過以下三種方式②實現(xiàn)：
通過容器的IP地址、端口號及路徑調(diào)用http get方法，如果相應的狀態(tài)碼大于等于200且小于400，則認定容器是健康狀態(tài)。
通過容器的IP地址和端口號執(zhí)行tcp檢查，如果能夠建立tcp連接，則表明容器健康。
在容器內(nèi)部運行一個命令，如果返回碼為0，則表示容器健康，否則表示不健康。
G行使用HTTPGetAction和TCPSocketAction兩種方式查看連接情況。
運維人員可以使用Kubectl命令行客戶端或Yaml部署模板來配置探針和IP地址、端口號、路徑連接方式。下面是以LivenessProbe探針、HTTPGetAction連接方式為例，編寫的Yaml文件：
圖片
知道如何檢查Pod的健康狀態(tài)了，如果不健康，該如何進行重啟呢？這里就需要說到Pod的重啟策略（restartPolicy）了。
重啟策略應用于Pod內(nèi)的所有容器，由Pod所處的Node上的Kubelet進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時，Kubelet會根據(jù)重啟策略的設置進行相應的操作。
Pod的重啟策略有Always、OnFailure、Never三種，Default為Always。
Always：當容器失效時，由Kubelet自動重啟該容器
OnFailure：當容器終止運行且退出碼不為0時，由Kubelet自動重啟該容器。
Never：不論容器運行狀態(tài)如何，Kubelet都不會重啟該容器。
圖3 示例Pod在G行Prometheus的可視化平臺Grafana上的重啟情況，紅線為閾值
重啟策略明確了，那么是靠誰來完成重啟的呢？是靠控制器來實現(xiàn)的。
在講述控制器之前，先考慮這樣一個場景：Pod沒有副本，如果這個Pod出現(xiàn)問題，上面跑的容器應用也就無法運轉(zhuǎn)了，服務也就中斷了。所以在K8s中，在創(chuàng)Pod之初，就是以多副本的形式創(chuàng)建的。這種負責Pod副本的創(chuàng)建、Pod重啟、調(diào)度及全生命周期自動控制的組件叫做控制器（也叫工作負載，即workload）。
控制器根據(jù)不同的功能分為Replicaset與Deployment、 DaemonSet、StatefulSet、Job和Cronjob幾種。這幾種控制器G行都有使用，并且在G行自建的容器統(tǒng)一管理平臺進行了部署。這個平臺融合管理了云上所有的應用相關容器資源，提高了運維效率。
圖4 G行容器統(tǒng)一管理平臺登錄首頁
圖片
圖5 Deployment控制器下兩種Pod滾動升級方式，分別是Recreate和Rolling update，各適用于大版本和小版本
ReplicaSet（簡稱rs）是Replication Controller的升級版，是副本集的意思，用于保證K8s集群中有指定數(shù)量的Pods副本在運行③。一般不單獨使用，而是作為Deployment理想狀態(tài)的參數(shù)使用。且擁有集合式的標簽選擇器，可以選擇多個標簽。
Deployment被稱作是副本控制集（即rs）的控制器，通過為應用程序創(chuàng)建一個或多個rs以管理應用程序的多個版本。通過每個副本控制集（rs）的模板和副本保持的能力來管理無狀態(tài)應用的工作負載（應用程序集群），比如web集群。
圖6 展示了DaemonSet這種類型的控制器的Pods部署
DaemonSet是特殊類型的Deployment，在集群中的全部或者部分節(jié)點上，每個節(jié)點上有且僅有一份Pod的副本資源在運行。比如系統(tǒng)的監(jiān)控、日志的收集、分布式存儲、網(wǎng)絡的代理等，都需要每個成員節(jié)點上有且只有一個Pod。例如：每個Node上只需要運行一個日志采集程序Logstach，或者只運行一個性能監(jiān)控程序Prometheus Node Exporter。
而且后續(xù)加入集群的新的節(jié)點也會自動創(chuàng)建一個相同的Pod對象。管理員也可以使用Nodeselector（節(jié)點選擇器）配合節(jié)點Label指定僅在部分具有特定特征的節(jié)點上運行指定的Pod對象。
圖7 有狀態(tài)集在一個Pod故障被殺死，并重建新Pod的情況
用來管理有狀態(tài)應用的工作負載（應用程序集群），管理Pods集合的部署和伸縮，并為這些Pods提供持久存儲和持久標識符。與Depolyment類似，Statefulset管理基于相同容器模板的一組Pods。但與Depolyment不同的是，Statefulset為每個Pod維護了一個有粘性的ID。這些Pods是基于相同的模板，但是不能相互替換，即無論怎么調(diào)度，每個Pod都有一個永久不變的ID。
圖8 Job和Cronjob在完成工作后回收算力的場景展示
Job是用來定義并啟動一個批處理任務，是單次性作業(yè)控制器。這任務通常并行或者串行啟動多個計算進程去處理一批工作項，即work item，工作項處理完成后，整個批處理任務結(jié)束。比如Hadoop的離線數(shù)據(jù)處理、視頻解碼、或者HPC業(yè)務等，都需要很多個節(jié)點提供一個集中式的大算力。與傳統(tǒng)算力相比，Job控制器能在保留結(jié)果的同時，快速回收算力，因為一個Job完成后，就會立即殺死使用的Pod。
Cronjob控制器用于周期性調(diào)度Job控制器。傳統(tǒng)環(huán)境使用的一般用到的是7*24小時不間斷的備份服務器，現(xiàn)在可以使用Cronjob控制器周期性的起一個Job作業(yè)，做完后，保留結(jié)果，殺死Pod，回收算力。Cronjob基本照搬了Linux操作系統(tǒng)的周期性任務Crontab，用minutes、hours、dayofmonth、month、dayofweek來進行定義。
需要注意，一些控制器對Pod的重啟策略要求，G行也是按如下執(zhí)行的：
Replicaset或者DaemonSet：必須設置為always，需要保證該容器持續(xù)運行。
Job：onFailure或Never，確保容器執(zhí)行完成后不再重啟。
Pod對Node有特定要求的場景：
Node節(jié)點的配置是多種類型的，比如有的安裝了SSD磁盤，有的沒有。有的是AMD64的，有的是AMD32的。如果想著把新建的Pod運行在AMD64的Node上，該怎么做呢。下面是Pod的Yaml配置：
圖片
Pod之間相互依存或者互斥的場景：
現(xiàn)在想新建這么兩個Pod，有互相依存關系，需要放到同一個Region內(nèi)，該如何實現(xiàn)呢。像這種互為親和或者互斥關系的Pod是通過在Yaml文件中增加TopologyKey屬性，來聲明目標拓撲內(nèi)的Pod是否在一起的。下面是一個親和的例子，目標Pod的標簽值是APP：”Nginx”。親和Pod的標簽值也是一樣。增加的TopologyKey值為topology.kubernetes.io/region，意味著這兩個Pod給配置到了同一個Region下。
圖片
這些相互依賴或者相互之間頻繁調(diào)用的Pod，需要盡可能的部署在同一個Zone、機房、機架、Node節(jié)點。反之，就需要讓這些Pod盡可能的互相遠離。簡而言之，就是Pod之間在同一個拓撲域中共存或互斥。拓撲域指由相同地理空間中的幾個Node節(jié)點組成。
一些常規(guī)的拓撲域有：
kubernetes.io/hostname；topology.kubernetes.io/region；topology.kubernetes.io/zone。
在企業(yè)實際在使用容器這類資源的時候，除了技術本身，要考慮的其他問題也會很多。企業(yè)管理的容器有千千萬萬，出于效率考慮，對于有特殊需求的容器如何進行批量創(chuàng)建和管理呢，這就需要在統(tǒng)一管理平臺按照相應的模板進行創(chuàng)建與維護。在Pod進行重建后，如何保證客戶端應用屏蔽這些Pod IP地址的變化及數(shù)量的變化呢，這就需要通過定義Pod上層的Service進行保障。不同的應用系統(tǒng)有自身的架構特點，在進行控制器配置的時候如何進行考量呢，需要選擇哪種控制器呢，這就需要進行交付前的資源配置梳理。等等問題。總之，在考慮到基本的技術特性的同時，再應用系統(tǒng)自身特點相結(jié)合，才能夠?qū)⒓夹g的最大價值加以發(fā)揮。
① 容器的狀態(tài)一共有五個：created（已創(chuàng)建）、running（運行中）、paused（暫停）、exited（停止）、dead（死亡）、restarted（重啟中）、removing（遷移中）。
②每種探測方式，還需要額外設置initialDelaySeconds和timeoutSeconds這兩個參數(shù)。initialDelaySeconds表示容器啟動后進行首次健康檢查的等待時間，單位是秒。timeoutSeconds表示健康檢查請求發(fā)送后等待響應的超時時間，單位是秒。如果超時，則Kubelet認為容器無法提供服務，會重啟該容器。
③例如：Pod所在節(jié)點發(fā)生宕機，K8s就會第一時間觀察到這個故障，并自動創(chuàng)建一個新Pod對象，將其調(diào)度到其他合適的節(jié)點上，K8s會實時監(jiān)控集群中目標Pod的副本數(shù)量，并盡力與Deployment中聲明的Replicas數(shù)量保持一致。
本文鏈接：http://www.www897cc.com/showinfo-26-70459-0.html我們一起聊聊容器資源自愈
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號