隨著DevOps開(kāi)發(fā)模式的盛行，Kubernetes正在迅速占領(lǐng)著技術(shù)界。作為一個(gè)開(kāi)源的容器編排系統(tǒng)，它可以自動(dòng)化容器應(yīng)用的部署、擴(kuò)展和管理。由于Kubernetes是一種經(jīng)濟(jì)、強(qiáng)大、可靠的分布式容器集群的管理工具，因此它本身具有一定的復(fù)雜性。一旦開(kāi)發(fā)者未加注意、或配置不當(dāng)，就可能導(dǎo)致生產(chǎn)環(huán)境出現(xiàn)各種故障。

為了避免潛在陷阱與錯(cuò)誤，本文將和您探討在Kubernetes部署中的一些常見(jiàn)錯(cuò)誤，它們的基本原理，以及如何修復(fù)的簡(jiǎn)單技巧。

Kubernetes的基礎(chǔ)知識(shí)

圖片來(lái)源： ??Kubernetes.io??

Kubernetes使用一組API和命令行工具，來(lái)管理集群中的容器。其架構(gòu)由一個(gè)主節(jié)點(diǎn)和多個(gè)分節(jié)點(diǎn)、或工作節(jié)點(diǎn)所組成。其中，主節(jié)點(diǎn)既負(fù)責(zé)集群的狀態(tài)和分節(jié)點(diǎn)的活動(dòng)，又管理分節(jié)點(diǎn)上的工作負(fù)載，調(diào)度容器，并為容器分配適當(dāng)?shù)馁Y源。分節(jié)點(diǎn)雖然不限于是物理機(jī)還是虛擬機(jī)，但是它們都需要通過(guò)訪問(wèn)Docker引擎和kubelet服務(wù)，才能與Kubernetes集群協(xié)同工作。此外，一個(gè)節(jié)點(diǎn)需要通過(guò)與其他節(jié)點(diǎn)連接，才能實(shí)現(xiàn)彼此間的數(shù)據(jù)傳輸。

Kubernetes使用一種聲明性配置模式，來(lái)便捷地設(shè)計(jì)可擴(kuò)展性系統(tǒng)，以應(yīng)對(duì)那些可預(yù)期和無(wú)法預(yù)期的變化。這種聲明式配置方便了Kubernetes去處理各種容器和集群操作的底層復(fù)雜性，進(jìn)而能夠輕松地構(gòu)建出具有高可用性、可擴(kuò)展性和安全性的集群。

當(dāng)然，由于其固有的部署復(fù)雜性，您的Kubernetes應(yīng)用可能會(huì)經(jīng)常存在如下錯(cuò)誤：

1.忽略健康檢查

圖片來(lái)源：?? Kaizenberglabs??

如上圖所示，在將服務(wù)部署到Kubernetes時(shí)，了解pod的狀態(tài)和Kubernetes集群的整體健康狀況，對(duì)于保障服務(wù)能夠按照預(yù)期運(yùn)行是非常重要的。為此，我們可以用到啟動(dòng)探針、活躍度探針、以及就緒度探針。其中，啟動(dòng)探針可以確保Pod的成功啟動(dòng)和創(chuàng)建;活躍度探針?lè)奖懔宋覀內(nèi)y(cè)試應(yīng)用程序是否處于活躍狀態(tài);而就緒度探針則被用于確定應(yīng)用程序是否已為接收流量準(zhǔn)備就緒。

2. 在容器中掛載主機(jī)文件系統(tǒng)

在容器中掛載主機(jī)文件系統(tǒng)是一種常見(jiàn)的反模式，時(shí)常被用于持久化數(shù)據(jù)的場(chǎng)景中。其中，最簡(jiǎn)單的方法是將主機(jī)的本地目錄，掛載成為容器文件系統(tǒng)中的一個(gè)目錄。據(jù)此，寫入該目錄的任何內(nèi)容都會(huì)被保留在主機(jī)上。不過(guò)，此舉可能會(huì)導(dǎo)致如下潛在的后果：

• 無(wú)法在多個(gè)容器之間共享狀態(tài)(即，無(wú)法將兩個(gè)不同的目錄掛載到兩個(gè)不同的主機(jī)上)。
• 在主機(jī)文件系統(tǒng)上的任何更改，對(duì)于其他容器都是不可見(jiàn)的。
• 無(wú)法在不更改所有權(quán)的情況下，管理任何已掛載目錄上的文件。

因此，為避免出現(xiàn)上述問(wèn)題，請(qǐng)勿將主機(jī)的任何文件系統(tǒng)掛載到容器中，除非是出于數(shù)據(jù)持久性目的。

3. 使用“Latest(最新)”標(biāo)簽

如果在生產(chǎn)環(huán)境中使用Latest標(biāo)簽，那么一旦針對(duì)版本的描述不夠清楚的話，就可能會(huì)引起混亂，因此我們不建議在生產(chǎn)環(huán)境中使用此類標(biāo)簽。例如，當(dāng)服務(wù)出現(xiàn)中斷需要盡快恢復(fù)時(shí)，您卻發(fā)現(xiàn)“Latest”標(biāo)簽并非指向新推送的鏡像版本，那么就會(huì)導(dǎo)致您無(wú)法知曉剛才在運(yùn)行的應(yīng)用的具體版本。因此，您應(yīng)該持續(xù)使用那些有意義的Docker標(biāo)簽。

4. 將服務(wù)部署到錯(cuò)誤的Kubernetes節(jié)點(diǎn)

根據(jù)前面的介紹，工作節(jié)點(diǎn)僅能運(yùn)行由其主節(jié)點(diǎn)分配的任務(wù)。那么，一旦您將服務(wù)部署到錯(cuò)誤的節(jié)點(diǎn)上，就可能導(dǎo)致其無(wú)法正常工作。此外，新的容器在啟動(dòng)時(shí)，需要等待一個(gè)可用的調(diào)度程序來(lái)分配任務(wù)，這往往需要占用比預(yù)期更長(zhǎng)的時(shí)間。

為避免這種情況，您需要在部署服務(wù)之前，知曉自己的服務(wù)需要在主節(jié)點(diǎn)、還是工作節(jié)點(diǎn)上運(yùn)行。而在啟動(dòng)任何容器之前，您還應(yīng)該檢查pod是否可以訪問(wèn)集群中需要與之通信的其他pod。

5. 未能使用現(xiàn)成的部署模式

Kubernetes憑借其眾多的部署技術(shù)，讓開(kāi)發(fā)人員可以輕松地部署自己的應(yīng)用程序。如下圖所示，Kubernetes建議您使用：??藍(lán)綠??(Blue-Green)、金絲雀(Canary)和滾動(dòng)(Rolling)等部署策略，來(lái)保證用戶不會(huì)因?yàn)樾碌能浖渴穑龅饺魏瓮C(jī)或服務(wù)中斷。

• 滾動(dòng)部署策略是Kubernetes的默認(rèn)策略，它會(huì)用新版本的pod，去慢慢替換之前舊的pod版本。
• 在藍(lán)綠模式中，藍(lán)色和綠色版本會(huì)被同時(shí)部署，但是在單位時(shí)間內(nèi)，只有一個(gè)版本處于活動(dòng)狀態(tài)。如果我們將藍(lán)色視為舊版本、將綠色視為新版本的話，那么可以首先將默認(rèn)所有流量都發(fā)送到藍(lán)色版本上。一旦最新的綠色版本滿足了所有要求，我們則可以將舊版本上的流量轉(zhuǎn)移到新版本上(即：從藍(lán)到綠)。
• 金絲雀部署策略可被用于進(jìn)行A/B測(cè)試和“暗”啟動(dòng)。它與藍(lán)綠方法非常類似，唯一不同的是，A、B兩個(gè)版本是同時(shí)提供服務(wù)并受理請(qǐng)求的。我們可以在后臺(tái)通過(guò)管控，讓用戶流量緩慢地從版本A轉(zhuǎn)移至版本B。

6. 重復(fù)部署

當(dāng)我們創(chuàng)建多個(gè)相同狀態(tài)的副本，并行地部署到不同的集群上時(shí)，可能會(huì)發(fā)生重復(fù)部署的情況。例如：當(dāng)某個(gè)集群出現(xiàn)故障時(shí)，另一個(gè)集群會(huì)繼續(xù)處理部署的請(qǐng)求。但是，當(dāng)它恢復(fù)、或有新的集群加入時(shí)，兩個(gè)正在運(yùn)行的副本會(huì)加倍處理請(qǐng)求，進(jìn)而超額占用底層主機(jī)上的CPU和內(nèi)存資源。對(duì)此，我建議您使用Headless Service或Daemon Set等服務(wù)類型，以便在任何給定時(shí)間，限制只有一個(gè)部署版本在運(yùn)行。

7. 在生產(chǎn)環(huán)境中只使用一種容器(即無(wú)狀態(tài))

許多人會(huì)錯(cuò)誤地認(rèn)為所有的容器都是相同的。其實(shí)，它們之間存在顯著的差異。其中，有狀態(tài)的容器會(huì)允許您，將數(shù)據(jù)存儲(chǔ)在磁盤等持久性存儲(chǔ)介質(zhì)上，以避免數(shù)據(jù)的丟失。而無(wú)狀態(tài)容器則只在運(yùn)行期間保留其數(shù)據(jù)，而在完成后丟棄數(shù)據(jù)(除非額外予以備份)。因此，您應(yīng)該同時(shí)使用有狀態(tài)和無(wú)狀態(tài)兩種容器。

8. 在不考慮監(jiān)控和日志記錄要求的情況下部署應(yīng)用

不考慮監(jiān)控和記錄的需要，往往會(huì)導(dǎo)致開(kāi)發(fā)人員疏忽他們的代碼或應(yīng)用在生產(chǎn)環(huán)境中運(yùn)行的情況。為了避免此類缺陷，我們應(yīng)當(dāng)在應(yīng)用部署之前，建立一個(gè)監(jiān)控系統(tǒng)和日志聚合服務(wù)器，以獲悉應(yīng)用的性能，并發(fā)現(xiàn)需要更改和優(yōu)化的地方。

不過(guò)，當(dāng)您僅使用由Kubernetes自身提供的服務(wù)和工具、而非第三方解決方案時(shí)，可能會(huì)碰到廠商鎖定的問(wèn)題。例如，您在使用CRI容器的運(yùn)行時(shí)接口，來(lái)部署容器時(shí)，就不能使用Docker或RKT容器。此外，許多開(kāi)發(fā)人員也會(huì)碰到由于集群容量不足、或在錯(cuò)誤的時(shí)間部署應(yīng)用，而產(chǎn)生的低效與混亂。

9. 在沒(méi)有任何安全配置的情況下部署應(yīng)用

開(kāi)發(fā)人員在使用集群外部可訪問(wèn)的端點(diǎn)時(shí)，往往會(huì)忽略諸如：密鑰保護(hù)、以及如何安全地運(yùn)行特權(quán)容器等問(wèn)題。因此，我們應(yīng)當(dāng)對(duì)Kubernetes的如下安全性引起重視：

• 授權(quán)——身份驗(yàn)證和授權(quán)對(duì)于控制訪問(wèn)Kubernetes集群中資源是至關(guān)重要的。
• 網(wǎng)絡(luò)——Kubernetes網(wǎng)絡(luò)會(huì)涉及到管理覆蓋網(wǎng)絡(luò)(overlay networks)和服務(wù)端點(diǎn)，以確保容器之間的流量在集群內(nèi)被安全地路由。
• 存儲(chǔ)——由于Kubernetes API服務(wù)器上有個(gè)REST接口，可以訪問(wèn)所有存儲(chǔ)的信息，因此用戶只需向API發(fā)送HTTP請(qǐng)求，即可訪問(wèn)到存儲(chǔ)在API中的任何信息。為了避免未經(jīng)授權(quán)的用戶或進(jìn)程訪問(wèn)到敏感數(shù)據(jù)，我們可以為API服務(wù)器配置支持用戶名/密碼、或基于令牌的身份驗(yàn)證的方法(請(qǐng)參考下圖)。

此外，您還可以通過(guò)配置基于角色的??訪問(wèn)控制??(RBAC)策略，來(lái)保護(hù)Kubernetes集群。即，通過(guò)給用戶分配諸如：“管理員”或“操作員”角色，并限制角色去訪問(wèn)資源，來(lái)保護(hù)Kubernetes集群。其中，管理員角色具有完全的訪問(wèn)權(quán)限，而操作員角色僅有對(duì)集群內(nèi)有限資源的訪問(wèn)權(quán)限。

10.未設(shè)置資源的使用限制

如果您發(fā)現(xiàn)自己的資源利用率和賬單雙雙猛增的話，那么就該重新檢查服務(wù)的資源使用情況了。我們可以通過(guò)對(duì)應(yīng)用程序執(zhí)行壓力測(cè)試，來(lái)設(shè)置容器的CPU和內(nèi)存的限制。對(duì)此，Kubernetes在其資源利用的類別中定義了“請(qǐng)求”和“限制”。其中，“請(qǐng)求”代表應(yīng)用需要運(yùn)行的最小資源，而“限制”則定義了最大的資源。我們可以在部署YAML中指定資源的限制。

由上圖可見(jiàn)，Harness Cloud Cost Management(CCM)通過(guò)計(jì)算和分析不同的工作流負(fù)載，對(duì)CPU和內(nèi)存的占用率，以直方圖的形式顯示了各種資源地優(yōu)化可能性，為您的Kubernetes集群提供各項(xiàng)建議，進(jìn)而減少您的每月支出。

小結(jié)

在上文中，我向您介紹了在Kubernetes部署過(guò)程中十種常見(jiàn)的錯(cuò)誤、以及對(duì)應(yīng)的解決方法。希望它們能夠協(xié)助您有效地交付出更加完善的應(yīng)用與服務(wù)。

譯者介紹

陳峻 (Julian Chen)，51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn);持續(xù)以博文、專題和譯文等形式，分享前沿技術(shù)與新知;經(jīng)常以線上、線下等方式，開(kāi)展信息安全類培訓(xùn)與授課。

原文標(biāo)題：Don't Make These 10 Kubernetes Mistakes，作者：Pavan Belagatti