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

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

Kubernetes的基礎知識

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

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

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

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

1.忽略健康檢查

圖片來源：?? Kaizenberglabs??

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 重復部署

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

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

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

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

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

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

9. 在沒有任何安全配置的情況下部署應用

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

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

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

10.未設置資源的使用限制

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

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

小結

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

譯者介紹

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

原文標題：Don't Make These 10 Kubernetes Mistakes，作者：Pavan Belagatti