P5-05_多種發(fā)布模式實(shí)現(xiàn)容器化交付

交付的邊界

應(yīng)用=網(wǎng)絡(luò)（Services）+服務(wù)載體（Pods）+存儲(chǔ)（Volumes）

大部分的發(fā)布策略都是網(wǎng)絡(luò)層的變更。

容器的網(wǎng)絡(luò)分為2大部分：?jiǎn)螜C(jī)網(wǎng)絡(luò)模型（host、bridge、共享所有命名空間）、跨主機(jī)的網(wǎng)絡(luò)模型（L2 Flat、L3 Flat、Overlay）

host網(wǎng)絡(luò)一般是利用宿主機(jī)的host網(wǎng)卡，相當(dāng)于容器會(huì)綁定宿主機(jī)的網(wǎng)卡，通過(guò)這種方式實(shí)現(xiàn)高性能的網(wǎng)絡(luò)轉(zhuǎn)發(fā)。IP地址、mac地址都是復(fù)用宿主機(jī)的網(wǎng)絡(luò)。

這種方式的缺點(diǎn)是沒有隔離性。

bridge，通過(guò)橋接的方式實(shí)現(xiàn)。

容器里最主要的模型，就是L3 Flat和Overlay

在阿里云的環(huán)境里，如果是VPC的網(wǎng)絡(luò)，通常就是L3 Flat模型，而經(jīng)典網(wǎng)絡(luò)使用的就是Overlay的網(wǎng)絡(luò)模型。

比較來(lái)說(shuō)，L3 Flat要比Overlay有更好的性能，因?yàn)樗鼈兊膶ぶ凡恍枰ㄟ^(guò)ARP廣播實(shí)現(xiàn)，而且網(wǎng)絡(luò)通信可以直接通過(guò)路由，而不需要封解包。

kubernetes：Service（LoadBalancer、NodePort、ClusterIP）

常見的發(fā)布策略：藍(lán)綠發(fā)布、金絲雀發(fā)布（灰度發(fā)布）、ABTest

藍(lán)綠發(fā)布通常被稱為熱部署

藍(lán)綠發(fā)布：在發(fā)布過(guò)程中用戶無(wú)感知服務(wù)的重啟，通常情況下是通過(guò)新舊版本并存的方式實(shí)現(xiàn)，也就是在發(fā)布的流程中，新的版本和舊的版本是相互熱備的，通過(guò)切換路由權(quán)重的方式（非0即100，要么全部訪問(wèn)A，要么全部訪問(wèn)B）實(shí)現(xiàn)不同的應(yīng)用的上線或者下線。

藍(lán)綠發(fā)布適合絕大多數(shù)的應(yīng)用場(chǎng)景的發(fā)布，能夠零宕機(jī)更新。缺點(diǎn)是發(fā)布時(shí)，資源消耗大。

金絲雀發(fā)布：

通過(guò)在線上運(yùn)行的服務(wù)中，新加入少量的新版本的服務(wù)，然后從這少量的新版本中快速獲得反饋，根據(jù)反饋決定最后的交付形態(tài)。金絲雀發(fā)布主要面向的場(chǎng)景是功能兼容的新版本驗(yàn)證，可以用最小的代價(jià)實(shí)現(xiàn)功能驗(yàn)證，且保證主體流量不受影響。缺點(diǎn)是面向場(chǎng)景比較單一，對(duì)于開發(fā)者要求較高。

如果對(duì)接入層的流量沒有區(qū)分，發(fā)布的金絲雀版本沒有在接入層對(duì)流量進(jìn)行切分，就屬于金絲雀發(fā)布。

如果對(duì)流量有明確的切分，比如A必須只能訪問(wèn)新的實(shí)例，B必須不能訪問(wèn)這個(gè)新實(shí)例，就是灰度發(fā)布。

如果對(duì)流量沒有指向性，就是金絲雀發(fā)布；如果有指向性，就是灰度發(fā)布。

灰度發(fā)布：

灰度發(fā)布是通過(guò)切換線上并存版本之間的路由權(quán)重，逐步從一個(gè)版本切換為另一個(gè)版本的過(guò)程。

金絲雀發(fā)布更傾向于獲取快速的反饋，而灰度發(fā)布更傾向于從一個(gè)版本到另一個(gè)版本長(zhǎng)時(shí)間平穩(wěn)的切換。

灰度發(fā)布是期望在一個(gè)非常大的版本之間，有指向性的導(dǎo)流。然后通過(guò)這種導(dǎo)流的策略，逐漸把新版本迭代上線。

A/BTest

A/BTest和灰度發(fā)布非常像，但是從發(fā)布的目的上，可以簡(jiǎn)單的區(qū)分灰度發(fā)布與A/BTest，A/BTest側(cè)重的是從A版本或者B版本之間的差異，并根據(jù)這個(gè)結(jié)果進(jìn)行決策，最終選擇一個(gè)版本進(jìn)行部署。因此和灰度發(fā)布相比，A/BTest更傾向于去決策，和金絲雀發(fā)布相比，A/BTest在權(quán)重和流量的切換上更靈活。

A/BTest和灰度發(fā)布從原理上講，沒有區(qū)別，都能夠準(zhǔn)確切分流量，有快速驗(yàn)證，可以實(shí)現(xiàn)版本并存和發(fā)布。

分批發(fā)布

分批發(fā)布是對(duì)發(fā)布流程的細(xì)粒度控制，并不是一種標(biāo)準(zhǔn)的發(fā)布策略。

分批發(fā)布和藍(lán)綠發(fā)布比較像，也希望通過(guò)一種0宕機(jī)的發(fā)布方式，解決版本更新的問(wèn)題。但是，藍(lán)綠發(fā)布會(huì)有大量的資源消耗，分批發(fā)布就是要解決資源消耗的問(wèn)題，它會(huì)將應(yīng)用的副本切分成不同的批次，每次發(fā)布會(huì)發(fā)布其中一個(gè)批次，并將新流量直接打入到新的批次上進(jìn)行快速驗(yàn)證。當(dāng)驗(yàn)證沒有問(wèn)題會(huì)再發(fā)布第二個(gè)批次、第三個(gè)批次……直到所有批次發(fā)布完成。

對(duì)于分批發(fā)布這種流程，如果完全基于k8s來(lái)實(shí)現(xiàn)，會(huì)很復(fù)雜。因?yàn)檫@里面不只是有自動(dòng)的過(guò)程，還有手動(dòng)的過(guò)程。因?yàn)樵隍?yàn)證這個(gè)版本是正確，還是錯(cuò)誤，實(shí)際是需要手動(dòng)來(lái)判斷是繼續(xù)，還是要回滾。這種場(chǎng)景對(duì)于k8s來(lái)講，是很難做的。因?yàn)閗8s里的抽象，大部分都是原子的，比如deployment的抽象、Service的抽象……它們之間是沒有辦法很好的有機(jī)結(jié)合在一起，實(shí)現(xiàn)一個(gè)過(guò)程的。

在k8s里面，通過(guò)yaml的方式，只能定義單一一種的抽象。為了解決這個(gè)問(wèn)題，k8s社區(qū)推出一種工具——helm。

helm是k8s下的一個(gè)包管理工具，它將應(yīng)用部署包含的多種k8s資源對(duì)象整合成單一的對(duì)象，這個(gè)對(duì)象叫做chart，模板提供默認(rèn)的部署配置，部署時(shí)可以進(jìn)行環(huán)境變量的替換修改，具有生命周期的管理能力，可以升級(jí)、回滾和版本追蹤。

helm聽起來(lái)很完美，但是也有自己的問(wèn)題。helm雖然可以很好的定義資源的拓?fù)洹?yīng)用的始態(tài)和終態(tài)，但是對(duì)于中間的流程控制是缺乏的。也就是說(shuō)，helm雖然把拓?fù)潢P(guān)系都管理起來(lái)了，但是沒有辦法做發(fā)布方式。

特別是常用的藍(lán)綠發(fā)布、分批發(fā)布、灰度發(fā)布等場(chǎng)景難以很好的支持。

有沒有什么辦法來(lái)解決這個(gè)問(wèn)題呢？

k8s目前有1個(gè)新的概念：CRD來(lái)解決這個(gè)問(wèn)題。

CRD（CustomResourceDefinition）是一種擴(kuò)展定義kubernetes抽象對(duì)象的方式，阿里云定義了分批發(fā)布的CRD，幫助開發(fā)者實(shí)現(xiàn)分批次的發(fā)布流程控制。

1個(gè)分批發(fā)布的CRD，包含1個(gè)service和1個(gè)statefulset

P6-06_開源框架與阿里云容器服務(wù)集成

Derrick：構(gòu)建Dockerfile的自動(dòng)化工具

這是阿里巴巴開源的工具，中文意思：起重機(jī)

Kompose

Kompose=Kubernetes+Compose

把Dockercompose的yaml文件轉(zhuǎn)換成kubernetes需要的yaml格式

helm

中文意思：舵

kubernetes的包管理器

在CentOS安裝軟件時(shí)，都會(huì)用到包管理器，比如yum，進(jìn)行安裝軟件的過(guò)程。

helm可以在kubernetes上，把打包好的資源文件部署到kubernetes集群上并進(jìn)行管理。

SpringCloud

微服務(wù)不限定語(yǔ)言。

https://developer.aliyun.com/article/596889——阿里云Kubernetes SpringCloud 實(shí)踐進(jìn)行時(shí)(1): 分布式服務(wù)注冊(cè)與發(fā)現(xiàn)

Istio

Service Mesh中有1個(gè)很重要的概念：Sidecar

Sidecar就是把應(yīng)用本身，在部署起來(lái)的pod里面注入1個(gè)新容器，作為sidecar。

Service Mesh的意思，服務(wù)網(wǎng)格

https://developer.aliyun.com/article/599874——阿里云Kubernetes Service Mesh實(shí)踐進(jìn)行時(shí)(1): Istio初體驗(yàn)

P7-07_容器化應(yīng)用性能測(cè)試與調(diào)優(yōu)

C10K

C10M

性能調(diào)優(yōu)：首先要找到現(xiàn)象，然后把現(xiàn)象轉(zhuǎn)換成癥狀，最后再通過(guò)癥狀找到問(wèn)題的本質(zhì)，然后再去解決它。

性能調(diào)優(yōu)有以下幾種常見方法：

負(fù)載測(cè)試：負(fù)載測(cè)試是用戶觀點(diǎn)的測(cè)試行為。簡(jiǎn)單說(shuō)來(lái)就是負(fù)載測(cè)試就是讓系統(tǒng)在一定得負(fù)載壓力下進(jìn)行正常的工作，觀察系統(tǒng)的表現(xiàn)能否滿足用戶的需求。

a.系統(tǒng)要在穩(wěn)定的狀態(tài)運(yùn)行

b.在滿足穩(wěn)定狀態(tài)前提的最高壓力

壓力測(cè)試：壓力測(cè)試的關(guān)鍵字就是“極端”。通過(guò)對(duì)系統(tǒng)的極端加壓，從而觀察系統(tǒng)所表現(xiàn)出來(lái)的性能問(wèn)題。再對(duì)此性能問(wèn)題進(jìn)行分析，從而達(dá)到系統(tǒng)優(yōu)化的目的。所以，壓力測(cè)試就是一定要讓系統(tǒng)出問(wèn)題，如果系統(tǒng)沒有出問(wèn)題，那么壓力測(cè)試的手段和方法就肯定存在問(wèn)題。

壓力測(cè)試和負(fù)載測(cè)試之間，它們最大的區(qū)別，就是要不要把系統(tǒng)壓出問(wèn)題。

負(fù)載測(cè)試，是在系統(tǒng)不出問(wèn)題的情況下測(cè)試；壓力測(cè)試是一定要讓系統(tǒng)出問(wèn)題，再找出問(wèn)題的原因。

并發(fā)測(cè)試：驗(yàn)證系統(tǒng)的并發(fā)能力。通過(guò)一定的并發(fā)量觀察系統(tǒng)在該并發(fā)量的情況下所表現(xiàn)出來(lái)的行為特征，確定系統(tǒng)是否滿足設(shè)計(jì)的并發(fā)需要。并發(fā)測(cè)試是系統(tǒng)觀點(diǎn)的測(cè)試行為。

負(fù)載測(cè)試和并發(fā)測(cè)試的區(qū)別：

并發(fā)測(cè)試驗(yàn)證的并發(fā)能力和我們所理解的系統(tǒng)對(duì)外的承載能力是不同的。比如說(shuō)，系統(tǒng)的并發(fā)能力可能只有300，但是，每天卻可以承載幾百萬(wàn)人的訪問(wèn)量。這其實(shí)是2種不同的維度。

qbs300是系統(tǒng)觀點(diǎn)的測(cè)試，每天對(duì)外服務(wù)幾百萬(wàn)，是用戶觀點(diǎn)的測(cè)試行為。

大部分的負(fù)載測(cè)試或壓力測(cè)試，更多是為了滿足用戶觀點(diǎn)的測(cè)試行為。

基準(zhǔn)測(cè)試：基準(zhǔn)測(cè)試要有1個(gè)基準(zhǔn)點(diǎn)，也就是說(shuō)供比較基點(diǎn)。當(dāng)軟件系統(tǒng)中增加1個(gè)新的模塊的時(shí)候，需要做基準(zhǔn)測(cè)試，以判斷新模塊對(duì)整個(gè)軟件系統(tǒng)的性能影響。按照基準(zhǔn)測(cè)試的方法，需要打開/關(guān)閉新模塊至少各做一次測(cè)試。關(guān)閉模塊之前的系統(tǒng)各個(gè)性能指標(biāo)記下來(lái)作為基準(zhǔn)，然后與打開模塊狀態(tài)下的系統(tǒng)性能指標(biāo)作比較，以判斷模塊對(duì)系統(tǒng)性能的影響。

一些大型軟件在上線新功能模塊的時(shí)候，會(huì)做這種測(cè)試。這種測(cè)試目前不是很多。

一些傳統(tǒng)項(xiàng)目做的相對(duì)多一點(diǎn)，在互聯(lián)網(wǎng)的產(chǎn)品里，基準(zhǔn)測(cè)試相對(duì)做的比較少。

穩(wěn)定性測(cè)試：長(zhǎng)時(shí)間的負(fù)載測(cè)試，確定系統(tǒng)的穩(wěn)定性。

穩(wěn)定性測(cè)試和負(fù)載測(cè)試基本是一樣的東西，只是穩(wěn)定性測(cè)試需要比較長(zhǎng)時(shí)間的保留。因此，穩(wěn)定性測(cè)試的閾值會(huì)比負(fù)載測(cè)試低一些。

可恢復(fù)性測(cè)試：測(cè)試系統(tǒng)能否快速地從錯(cuò)誤狀態(tài)中恢復(fù)到正常狀態(tài)。比如，在1個(gè)配有負(fù)載均衡的系統(tǒng)中，主機(jī)承受了壓力無(wú)法正常工作后，備份機(jī)是否能夠快速地接管負(fù)載?？苫謴?fù)測(cè)試通常結(jié)合壓力測(cè)試一起來(lái)做。

全鏈路測(cè)試：在大型互聯(lián)網(wǎng)公司中提出的包含系統(tǒng)上下游的全鏈路壓力測(cè)試與穩(wěn)定性測(cè)試方式，通過(guò)模擬近似真實(shí)的用戶流量和用戶行為來(lái)仿真線上流量，是目前大型活動(dòng)前或者大版本演進(jìn)上線前的一種非常有效的保障措施。

容器性能分析——Linux命名空間

容器性能分析——Cgroup

容器性能分析——網(wǎng)絡(luò)損耗

容器性能分析——文件IO損耗

容器性能分析——框架語(yǔ)言性能降低

容器性能分析——不同鏡像的性能差異

容器性能分析——內(nèi)核參數(shù)差異

docker對(duì)于/proc是只讀掛載，因此對(duì)于內(nèi)核參數(shù)的修改會(huì)在主機(jī)級(jí)別共享，這可能會(huì)造成同一臺(tái)主機(jī)不同的容器之間存在對(duì)內(nèi)核參數(shù)的相互影響，從而造成性能差異。例如：1個(gè)長(zhǎng)連接的應(yīng)用和1個(gè)短連接的應(yīng)用在同1個(gè)節(jié)點(diǎn)運(yùn)行，他們對(duì)于內(nèi)核的參數(shù)會(huì)有所不同的要求，從而造成性能差異。對(duì)這樣的節(jié)點(diǎn)進(jìn)行參數(shù)調(diào)優(yōu)時(shí)，就需要兼顧長(zhǎng)連接場(chǎng)景和短連接場(chǎng)景的差異，這種差異很多時(shí)候都是不可調(diào)節(jié)的。必須通過(guò)調(diào)度，或者其他方式去解決。

常用容器性能調(diào)優(yōu)工具與使用：10個(gè)常用的主機(jī)調(diào)試工具

uptime?-->?load averages（負(fù)載）

dmesg | tail?-->?kernel errors

vmstat 1?-->?overall stats by time

mpstat -P ALL 1?-->?CPU balance

pidstat 1?-->?process usage

iostat -xz 1?-->?disk I/O

free -m?-->?memory usage

sar -n DEV 1?-->?network I/O

sar -n TCP,ETCP 1?-->?TCP stats

top?-->?check overview

容器壓測(cè)工具

WRK：適合常規(guī)的壓力測(cè)試和穩(wěn)定性測(cè)試的場(chǎng)景，支持連接數(shù)、線程、時(shí)間等基礎(chǔ)參數(shù)，支持腳本、header頭（短連接）等場(chǎng)景。但是，壓測(cè)工具的壓測(cè)指標(biāo)一定要選擇1個(gè)適當(dāng)?shù)膲簻y(cè)時(shí)間長(zhǎng)度，最好在5分鐘以上，因?yàn)閷?duì)于壓測(cè)量級(jí)比較大的場(chǎng)景（上千、上萬(wàn)的并發(fā)），WRK存在預(yù)熱的問(wèn)題（壓測(cè)第1分鐘的流量可能非常少，因?yàn)樵诮onnect的時(shí)候，需要比較長(zhǎng)的時(shí)間），過(guò)短的壓測(cè)時(shí)間，可能會(huì)造成壓測(cè)結(jié)果不準(zhǔn)確的問(wèn)題。

PTS：全鏈路壓測(cè)工具，通過(guò)腳本編寫可以模擬真實(shí)的流量、參數(shù)以及用戶行為。目前服務(wù)于邏輯思維、懂球帝等多家客戶。

資源概覽工具

對(duì)于容器調(diào)優(yōu)的場(chǎng)景，第1件事要看有沒有內(nèi)存泄露、文件連接數(shù)泄露的問(wèn)題。以上場(chǎng)景，比較常用的是資源概覽工具

ctop：它是專門為容器開發(fā)的，可用于容器層級(jí)間監(jiān)控進(jìn)程。底層的實(shí)現(xiàn)，是通過(guò)讀取cgroup的信息實(shí)現(xiàn)top的能力。

htop：ctop能夠幫助查看容器的實(shí)時(shí)監(jiān)控指標(biāo)，但是，主機(jī)上的一些性能爭(zhēng)搶的場(chǎng)景，并不一定就是容器之間的互相爭(zhēng)搶，可能是主機(jī)上的進(jìn)程和容器進(jìn)行爭(zhēng)搶。這時(shí)候，htop就非常重要了，它可以在主機(jī)上幫助我們查看進(jìn)程級(jí)的搶占情況。

CPU Memory性能工具

perf

strace

磁盤性能

大部分的IO問(wèn)題，都是因?yàn)槭褂锰囟ǖ姆植际酱鎯?chǔ)（比如，對(duì)象存儲(chǔ)OSS、文件存儲(chǔ)NAS）。這2種存儲(chǔ)可以通過(guò)阿里云上的云監(jiān)控查看監(jiān)控指標(biāo)即可。

常規(guī)的磁盤監(jiān)控，推薦的工具是iotop和iosnoop

iotop可以找到IO比較高的進(jìn)程，然后再根據(jù)這個(gè)進(jìn)程進(jìn)行分析。在分析的時(shí)候，就需要用到iosnoop。

iosnoop可以進(jìn)行進(jìn)程跟蹤，找到對(duì)應(yīng)寫入磁盤的事件。從而查找是不是代碼里有寫入瓶頸的癥狀。

網(wǎng)絡(luò)性能

sar：其他大部分性能調(diào)試工具是在使用的時(shí)候采集（實(shí)時(shí)采集或者單次采集）。而sar工具在linux可以記錄和分析歷史數(shù)據(jù)。

性能調(diào)優(yōu)時(shí)，最擔(dān)心沒有辦法復(fù)現(xiàn)問(wèn)題，或者不確定這個(gè)問(wèn)題是在這臺(tái)機(jī)器上出現(xiàn)過(guò)，以及什么時(shí)候會(huì)再次復(fù)現(xiàn)。而sar工具可以定位這些問(wèn)題：比如可以定位tcp的重傳。

netstat：實(shí)時(shí)網(wǎng)絡(luò)診斷工具，通常會(huì)用這個(gè)命令檢查tcp協(xié)議棧的網(wǎng)絡(luò)狀態(tài)。

通常情況下，在容器的場(chǎng)景里，網(wǎng)絡(luò)性能的調(diào)優(yōu)很多時(shí)候會(huì)變成內(nèi)核參數(shù)的調(diào)優(yōu)。但是，并不建議在沒有性能瓶頸的情況下，還做內(nèi)核調(diào)優(yōu)。因?yàn)閮?nèi)核目前還沒有辦法進(jìn)行抽象和可編程，這會(huì)造成系統(tǒng)配置很難管理。

網(wǎng)絡(luò)診斷

結(jié)合tcpdump和wireshark，可以對(duì)數(shù)據(jù)包進(jìn)行分析。

因?yàn)閠cpdump很難看到上下游的跟蹤狀態(tài)，數(shù)據(jù)的輸出太快。但是，在wireshark可以通過(guò)可視化的方式，定位問(wèn)題。

大殺器

sysdig是sysdig cloud出品的基于lua語(yǔ)言開發(fā)的超強(qiáng)工具，它相當(dāng)于strace+tcpdump+lsof+htop+iftop，還有其他工具的合集。除此之外，它還支持對(duì)容器，如docker、CoreOS、LXC進(jìn)行監(jiān)控。sysdig的優(yōu)勢(shì)在于融合多款工具，在1個(gè)軟件中完成所有的調(diào)優(yōu)工作。

相對(duì)而言，sysdig的使用方式比較復(fù)雜，安裝方法也不是太友好。對(duì)開發(fā)者而言，需要掌握更多的知識(shí)。

如果希望專門做容器的調(diào)優(yōu)或者系統(tǒng)調(diào)優(yōu)方向，建議能夠了解、掌握這個(gè)工具。

以上的調(diào)優(yōu)工具都是被動(dòng)調(diào)優(yōu)工具，這里的“被動(dòng)”，是要求使用者要有一些基礎(chǔ)條件，比如要知道排查的問(wèn)題是網(wǎng)絡(luò)方向的，還要清楚使用的strace工具，輸出的信息都是什么意思。

但是，更多情況是，開發(fā)者并不知道在排查問(wèn)題時(shí)，要尋找那個(gè)方向，要使用那個(gè)工具（什么時(shí)候應(yīng)該使用iotop？什么時(shí)候應(yīng)該使用sysdig？什么時(shí)候應(yīng)該使用free……）我們就需要一款主動(dòng)性能調(diào)優(yōu)和診斷機(jī)制。

snout就是一款主動(dòng)性能調(diào)優(yōu)工具，只需要把它拷貝到宿主機(jī)上，直接執(zhí)行snout命令即可。它會(huì)探測(cè)系統(tǒng)里可能隱藏的問(wèn)題，比如會(huì)檢查網(wǎng)絡(luò)協(xié)議棧、磁盤利用率……定位可能存在的某些問(wèn)題。

發(fā)現(xiàn)這些問(wèn)題后，會(huì)給我們一些建議并輸出。

P8-08_容器化應(yīng)用問(wèn)題診斷、監(jiān)控與運(yùn)維

kubernetes常見問(wèn)題——etcd穩(wěn)定性問(wèn)題

kubernetes常見問(wèn)題——網(wǎng)絡(luò)鏈路

kubernetes常見問(wèn)題——核心組件

99%的情況下，核心組件都是異常穩(wěn)定的，而且基于k8s內(nèi)部的實(shí)現(xiàn)機(jī)制，刪除重新部署是恢復(fù)的最佳方式。

對(duì)于k8s核心組件的故障排查和恢復(fù)，是即簡(jiǎn)單又復(fù)雜。

因?yàn)槿绻胪暾挪槌鍪鞘裁磫?wèn)題，對(duì)于大部分開發(fā)者是有難度的。因?yàn)檫@要對(duì)k8s的核心組件非常了解，要知道日志每行信息代表的內(nèi)容是什么，產(chǎn)生的原因可能要到代碼里查找。但是，對(duì)于大部分開發(fā)者來(lái)說(shuō)，只需要知道，當(dāng)發(fā)現(xiàn)問(wèn)題時(shí)，如何恢復(fù)它即可。對(duì)于這種場(chǎng)景，k8s對(duì)開發(fā)者是非常友好的。因?yàn)樗膶?shí)現(xiàn)是基于狀態(tài)機(jī)。那么，對(duì)于狀態(tài)機(jī)這種機(jī)制來(lái)講，只需要能夠全量同步一次基本就能解決問(wèn)題。所以，對(duì)于核心組件的問(wèn)題，殺掉相應(yīng)的pod，由上層的Deployment直接拉起，并進(jìn)行全量的基于狀態(tài)級(jí)別的恢復(fù)。

kubernetes常見問(wèn)題——pod異常

kubernetes診斷問(wèn)題流程——判斷故障的等級(jí)

1.kubectl get componentstatus（核心組件的健康狀態(tài)）

2.kubectl get nodes

kubectl describe node [node_name]

kubectl top node [node_name]（節(jié)點(diǎn)的健康狀態(tài)）

kubernetes診斷問(wèn)題流程——縮小故障排查范圍

核心管控故障：

排查順序：資源是否足夠-->etcd-->apiserver-->dns-->其他核心組件

負(fù)載節(jié)點(diǎn)故障：

排查順序：資源-->系統(tǒng)日志（dmsg）-->kubelet日志-->網(wǎng)絡(luò)通暢是否有問(wèn)題

負(fù)載故障：

排查順序：負(fù)載本身狀態(tài)標(biāo)志-->負(fù)載事件信息-->負(fù)載自身日志-->負(fù)載相關(guān)資源權(quán)限與狀態(tài)

kubernetes診斷問(wèn)題流程——獲取信息轉(zhuǎn)換“現(xiàn)象”為“癥狀”

kubernetes診斷問(wèn)題流程——處理問(wèn)題驗(yàn)證結(jié)果

kubernetes監(jiān)控方案