如何為Kubernetes建構合适的平台

Kubernetes是一個編排器。這是你部署、網絡、負載均衡、擴充和維護容器化應用程式的方式。這些工作負載中的每一個都有自己的架構，無論是有狀态的還是無狀态的，都是容器化的單體，或者是與服務網格、批處理作業或無伺服器功能一起使用的微服務。

但你還需要考慮Kubernetes基礎設施本身的架構：如何建構Kubernete運作的平台。

Kubernetes足夠靈活，可以在幾乎任何類型的硬體上部署任何類型的應用程式，無論是在雲中還是其他地方：為了既通用又強大，它具有極高的可配置性和可擴充性。這提供了許多架構選擇。

這些選擇包括你是否自己做出所有單獨的配置選擇，是否遵循VMware Tanzu或Azure Arc等工具中的預設選項（這些工具提供了更內建的部署和管理基礎設施的方法），或者使用托管雲Kubernetes服務（該服務提供有關部署資源的選擇，為常見應用程式工作負載設計的參考架構和藍圖）。

規劃Kubernetes資源

Kubernetes基礎設施是Kubernete用于運作容器化應用程式（及其自己的服務）的一組實體或虛拟資源，以及在指定和配置它們時所做的選擇。

需要根據pod和服務的工作負載和資源需求，決定控制平面伺服器、叢集服務、附加元件、叢集、資料存儲和網絡元件所需的虛拟機（或裸金屬硬體），叢集上需要多少節點，以及它們應該具有哪些記憶體和vCPU。

自動縮放允許動态地向上或向下調整容量，但需要有可用的基礎容量。需要考慮托管Kubernetes叢集的最佳平台：在自己的資料中心、邊緣、托管提供商或公共、私有或混合雲中的基礎設施。

其中一些将取決于工作負載的需求：如果它們主要是無狀态的（或者如果很容易将狀态存儲在外部），可以通過使用部署打折扣但也可能突然中斷的現貨執行個體來降低雲成本。需要了解計劃運作的應用程式的大小、複雜性和可擴充性，以及所需的控制和定制量，并考慮将使用的資源的性能、可用性和成本。

最初，Kubernetes的建構是基于這樣的假設，即它運作的所有硬體基本上都是相似的，并且可以有效地互換，因為它是為了利用雲基礎設施即服務（IaaS）中常見的商品伺服器而開發的。

但即使在雲環境中，不同的工作負載仍然需要非常不同的資源，Kubernetes已經進化為支援更多的異構基礎設施：不僅是Windows節點和Linux節點，還有GPU、CPU、Arm處理器和x86。甚至可以選擇使用某些類别的Linux裝置作為節點。

如果正在為Kubernetes虛拟機使用雲IaaS，或者使用托管雲Kubernete服務（如AKS或EKS），可以為VM選擇合适的執行個體。如果正在邊緣建構自己的Kubernetes基礎設施，可能會選擇Arm硬體或消費級Intel NUC來運作要求較低的Kubernet分發，例如在餐廳或零售店中的k3s，在那裡沒有資料中心級硬體的設施。

根據選擇的Kubernetes發行版，可能還需要考慮所需的主機作業系統以及要使用的容器運作時。運作自己的容器系統資料庫還是隻從公共系統資料庫中提取鏡像？在哪裡儲存秘密？使用HashiCorp Vault或來自雲提供商的托管密鑰存儲意味着部署管道中不會有可能洩漏的憑據。

多叢集K8s基礎架構

還需要考慮可能的故障：是否需要運作關鍵控制平面元件的多個副本的高可用性叢集，或者運作多叢集架構？

對于較小的Kubernetes基礎設施，可以使用命名空間分隔不同的工作負載：邏輯分區，允許在一個叢集上隔離和管理不同的應用程式、環境和項目。但也可以使用單個Kubernetes控制平面來管理多個節點叢集，将工作負載放在不同的叢集上，以獲得更好的安全性和性能。

如果對延遲有監管要求或嚴格限制，需要強制執行不同的政策和權限，或者希望避免需要零停機的應用程式出現單點故障，這可以在不同的位置（包括不同的雲提供商）編排應用程式，但仍有一個地方可以通路該基礎設施。這簡化了從叢集到叢集的應用程式遷移，無論是用于擴充還是災難恢複，盡管這也帶來了很大的複雜性。

Kubernetes基礎設施聯網

還需要規劃服務發現選項和網絡拓撲，包括防火牆和VPN連接配接，以及網絡插件、DNS設定、負載均衡器和叢集的入口控制器。

考慮通路管理：需要部署基于角色的通路控制（RBAC）來為使用者和資源實施細粒度的權限和政策，并確定確定管理者通路的安全。還需要為需要通路現有資料存儲的工作負載管理機器辨別。

原生Kubernetes使用者身份驗證使用證書：如果需要對使用者通路進行集中控制和管理，你可能希望使用現有的身份提供程式進行身份驗證。

Kubernetes管理架構

由于Kubernetes的建構使其易于擴充應用程式，而你可以手動更改單個設定，如活躍度和就緒性探測，是以它确實是為聲明性配置管理而設計的。可以在YAML中編寫配置檔案（或使用一個發出配置檔案的工具），告訴Kubernetes應用程式應該如何運作，而Kubernete負責實作這一點。

與其調整設定，不如将重點放在使用“基礎設施即代碼”實作可重複性的自動化上：将配置設定為版本控制、可稽核的代碼，并根據需要經常應用它（如果出現問題，則重新啟動它），每次都得到相同的系統。

可重複、不可變的基礎設施，将叢集視為牛（而不是單獨命名、擁抱和關心的寵物），這就是Kubernetes的設計宗旨。為此做好準備是關于如何減少持續管理和實際運維生産中容器的工作量。

可以使用具有Flux或Argo CD的GitOps工作流将其擴充到政策管理和治理以及應用程式傳遞，該工作流部署應用程式更新，并從引導到配置更新，始終保持叢集處于所需狀态。需要收集名額并跟蹤性能：大多數工作負載都會發出Prometheus名額，但還需要考慮監控儀表闆以及希望啟用的日志記錄。

需要監控容器基礎設施的威脅和安全風險，并確定VM主機得到了适當的加強。同樣，在規劃Kubernetes基礎設施時，考慮将使用的工具和流程，可以更容易地確定不會遺漏任何内容。

了解Kubernetes架構

将所有這些放在一起并不簡單，你可以從其他Kubernetes使用者如何建構其基礎設施中學到很多東西。

前Kubernetes釋出負責人兼指導委員會成員Lachlan Evenson說：“需要數年Kubernete開發經驗才能取得成效。你需要一本幫助導航和避開冰山的書。”Evenson與Kubernetes聯合創始人Brendan Burns合著了《Kubernetes Best Practices》，試圖提供一個配套指南來提供一些幫助。

但你仍然應該花時間弄清楚什麼樣的基礎設施最适合你的特定工作負載，并獲得運作它的專業知識。