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

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

Kubernetes的基礎(chǔ)知識

圖片來源： ??Kubernetes.io??

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

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

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

1.忽略健康檢查

圖片來源：?? Kaizenberglabs??

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

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

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

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

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

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

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

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

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

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

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

Kubernetes憑借其眾多的部署技術(shù)，讓開發(fā)人員可以輕松地部署自己的應(yīng)用程序。如下圖所示，Kubernetes建議您使用：??藍(lán)綠??(Blue-Green)、金絲雀(Canary)和滾動(Rolling)等部署策略，來保證用戶不會因為新的軟件部署，而碰到任何停機(jī)或服務(wù)中斷。

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

6. 重復(fù)部署

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

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

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

譯者介紹

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

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