叢集設計和作業
本文涵蓋叢集設定與網路設計。 了解如何透過自動化基礎結構佈建，證明未來的可擴縮性。 佈建是設定所需 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 中斷預算規劃可用性。
在命名空間上實施資源配額。 在命名空間層級規劃及套用資源配額。 您可以設定計算資源、儲存體資源，以及物件計數的配額。 如需詳細資訊，請參閱實施資源配額。
最佳化和調整規模
應用程式進入生產環境中後，要如何最佳化工作流程，並準備應用程式和小組進行調整？ 使用最佳化和縮放檢查清單進行準備。 在完成本節後，您將能回答以下問題：
- 您是否已有商務持續性和災害復原的方案？
- 您的叢集是否可調整以因應應用程式需求？
- 您是否能監視叢集和應用程式的健康狀態及接收警示？
檢查清單：
自動調整叢集以符合應用程式需求。 為了滿足應用程式的需求，您可能會需要使用叢集自動調整程式來調整自動執行工作負載的節點數目。 如需詳細資訊，請參閱設定 Kubernetes 叢集自動調整程式。
商務持續性和災害復原方案。 規劃多區域部署、建立儲存體移轉計畫，並啟用容器映像的異地複寫功能。 如需深入了解，請參閱區域部署的最佳做法 - Azure Container Registry 異地複寫。
大規模設定監視與疑難排解。 在 Kubernetes 中設定應用程式的警示及監視。 了解預設設定、如何整合較先進的計量，以及如何新增自訂的監視及警示功能以操作應用程式。