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

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

Kubernetes的基礎知識

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

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

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

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

1.忽略健康檢查

圖片來源：?? Kaizenberglabs??

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

2. 在容器中掛載主機文件系統

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

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

因此，為避免出現上述問題，請勿將主機的任何文件系統掛載到容器中，除非是出于數據持久性目的。

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

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

4. 將服務部署到錯誤的Kubernetes節點

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

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

5. 未能使用現成的部署模式

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

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

6. 重復部署

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

7. 在生產環境中只使用一種容器(即無狀態)

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

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

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

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

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

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

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

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

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

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

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

小結

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

譯者介紹

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

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