分享方式：

叢集設計和作業

  • 文章

本文涵蓋叢集設定與網路設計。 了解如何透過自動化基礎結構佈建，證明未來的可擴縮性。 佈建是設定所需 IT 基礎結構的一個程序。 自動化的基礎結構佈建可支援遠端安裝及設定虛擬環境。 它還可以透過規劃商務持續性和災害復原來維持高可用性。

規劃、訓練和證明

開始使用時，以下的檢查清單與 Kubernetes 資源將有助於您規劃叢集設計。 在完成本節後，您將能回答以下問題：

  • 您是否已識別出叢集所需的網路設計需求？
  • 您是否擁有具備不同需求的服務？ 您所要使用的節點集區數量為何？

檢查清單：

  • 識別網路設計的考量。 了解叢集網路設計的考量項目、比較網路模型，並選擇符合您需求的 Kubernetes 網路外掛程式。 針對 Azure 容器網路介面 (CNI) 網路，將所需的 IP 位址數量視為單位節點上 Pod 數目上限 (預設值為 30) 和節點數目的倍數。 在升級期間新增所需的一個節點。 在選擇負載平衡器服務時，可考量在服務數量太多時使用輸入控制器，以減少公開端點的數目。 針對 Azure CNI，在整個虛擬網路以及所有連線的虛擬網路中只能有一個 CIDR 服務，以確保適當的路由。

    若要深入了解，請參閱：

  • 建立多個節點集區。 若要支援具有不同計算或儲存體需求的應用程式，您可以選擇性地設定叢集搭配多個節點集區。 例如，使用較多的節點集區提供密集計算應用程式，或存取高效能 SSD 儲存體所需的 GPU。 如需詳細資訊，請參閱在 Azure Kubernetes Service 中建立和管理叢集的多個節點集區。

  • 決定可用性的需求。 Azure Kubernetes Service 至少要有兩個 Pod 才能確保當 Pod 失敗或重新開機時，應用程式的高可用性。 使用三個 (含) 以上的 Pod 來處理 Pod 失敗或重新啟動期間的負載。 針對叢集設定，在可用性設定組或虛擬機器擴展集中至少需要兩個節點，才會符合服務等級協定所要求的 99.95%。 使用至少三個 Pod 以確保在節點失敗和重新開機期間可進行 Pod 排程。

    若要為應用程式提供較高等級的可用性，可將叢集分散於整個可用性區域中。 這些可用性區域會實際分散於特定區域的不同資料中心內。 當叢集元件分散至多個區域時，叢集就可容忍其中一個區域出現失敗的情況。 即使整個資料中心都發生故障，您的應用程式和管理作業依舊可供使用。 如需詳細資訊，請參閱建立使用可用性區域的 Azure Kubernetes Service (AKS) 叢集。

移至生產環境並套用基礎結構最佳做法

在準備生產環境所需的應用程式時，請實作一組最小的最佳做法。 在這個階段，請使用此檢查清單。 在完成本節後，您將能回答以下問題：

  • 您是否能有信心地重新部署叢集基礎結構？
  • 您是否已套用了資源配額？

檢查清單：

  • 自動佈建叢集。 您可以使用基礎結構即程式碼來自動化基礎結構的佈建，以便能在災害期間提供更多的復原能力，並視需要以靈活快速的方式重新部署基礎結構。 如需詳細資訊，請參閱使用 Terraform 建立含有 Azure Kubernetes Service 的 Kubernetes 叢集。

  • 使用 Pod 中斷預算規劃可用性。 若要維護應用程式的可用性，請定義 Pod 中斷預算 (PDB) 以確定在硬體失敗或叢集升級期間，可以確保叢集中可用 Pod 數目的下限。 如需深入了解，請參閱使用 Pod 中斷預算規劃可用性。

  • 在命名空間上實施資源配額。 在命名空間層級規劃及套用資源配額。 您可以設定計算資源、儲存體資源，以及物件計數的配額。 如需詳細資訊，請參閱實施資源配額。

最佳化和調整規模

應用程式進入生產環境中後，要如何最佳化工作流程，並準備應用程式和小組進行調整？ 使用最佳化和縮放檢查清單進行準備。 在完成本節後，您將能回答以下問題：

  • 您是否已有商務持續性和災害復原的方案？
  • 您的叢集是否可調整以因應應用程式需求？
  • 您是否能監視叢集和應用程式的健康狀態及接收警示？

檢查清單：