共用方式為

Azure Kubernetes Service 的作業管理考慮

  • 發行項

Kubernetes 是一項相對較新的技術，其發展速度很快，生態系統令人印象深刻。 因此，管理和保護它可能很困難。

AKS 的作業基準

您可以適當地設計 Azure Kubernetes Service （AKS） 解決方案，並考慮管理和監視，以取得卓越營運和客戶的成功。

設計考量

請考慮下列因素：

  • 請注意 AKS 限制。 使用多個 AKS 實例來調整超過這些限制。
  • 請注意在叢集內以邏輯方式隔離工作負載，以及在個別叢集中實際隔離工作負載的方法。
  • 請注意控制工作負載資源耗用量的方法。
  • 請注意可協助 Kubernetes 瞭解工作負載健康情況的方法。
  • 請注意各種虛擬機大小，以及使用一個或另一個虛擬機的影響。 較大的 VM 可以處理更多負載。 當計劃性和非計劃性維護無法使用時，其他 VM 可以更容易取代。 此外，請注意擴展集中的節點集區和 VM，允許相同叢集中不同大小的虛擬機。 較大的 VM 比較理想，因為 AKS 會保留較小的資源百分比，讓更多資源可供您的工作負載使用。
  • 請注意監視和記錄 AKS 的方法。 Kubernetes 是由各種元件所組成，監視和記錄應該提供其健康情況、趨勢和潛在問題的深入解析。
  • 建置在監視和記錄的基礎上，Kubernetes 或應用程式可能會產生許多事件。 警示有助於區分記錄專案，以用於歷程記錄目的，以及需要立即採取動作的記錄專案。
  • 請注意您應該執行的更新和升級。 在 Kubernetes 層級，有主要、次要和修補程式版本。 客戶應根據上游 Kubernetes 中的原則套用這些更新，以維持支援。 在背景工作主機層級，OS 核心修補程式可能需要重新啟動，客戶應該重新啟動，並升級至新的 OS 版本。 除了手動升級叢集之外，您還可以在叢集上設定 自動升級通道 。
  • 請注意叢集的資源限制和個別工作負載。
  • 請注意水準 Pod 自動調整程式與叢集自動調整程式之間的差異
  • 請考慮使用 網路原則和 Azure 原則外掛程式來保護 Pod 之間的流量
  • 若要協助針對在 AKS 上執行的應用程式和服務進行疑難解答，您可能需要檢視控制平面元件所產生的記錄。 您可能想要 啟用 AKS 的資源記錄，因為預設不會啟用記錄。

建議

  • 瞭解 AKS 限制：

  • 在命名空間層級使用邏輯隔離來分隔應用程式、小組、環境和業務單位。 多租使用者和叢集隔離。 此外，節點集區可協助具有不同節點規格的節點，以及 Kubernetes 升級 多個節點集區的維護

  • 在命名空間層級規劃及套用資源配額。 如果 Pod 未定義資源要求和限制，請使用原則拒絕部署等等。 這不適用於 kube 系統 Pod，因為並非所有 kube 系統 Pod 都有要求和限制。 監視資源使用量，並視需要調整配額。 基本排程器功能

  • 將健康情況探查新增至您的 Pod。 請確定 Pod 包含 livenessProbe、 readinessProbe和 startupProbe AKS 健康情況探查。

  • 使用夠大的 VM 大小來包含多個容器實例，因此您會獲得密度增加的優點，但無法讓叢集處理失敗節點的工作負載。

  • 使用監視解決方案。 根據預設，Azure 監視器容器深入解析 已設定，並可讓您輕鬆存取許多深入解析。 如果您想要更深入鑽研或使用 Prometheus 的經驗，可以使用 Prometheus 整合 。 如果您也想要在 AKS 上執行監視應用程式，則也應該使用 Azure 監視器來監視該應用程式。

  • 使用 Azure 監視器容器深入解析 計量警示 ，在需要直接動作時提供通知。

  • 使用 自動節點集區調整 功能與 水準 Pod 自動調整程式 ，以符合應用程式需求，並降低尖峰時間負載。

  • 使用 Azure Advisor 來取得成本、安全性、可靠性、卓越營運和效能的最佳做法建議。 此外，使用 適用於雲端的 Microsoft Defender 來防止和偵測映像弱點等威脅。

  • 使用已啟用 Azure Arc 的 Kubernetes，使用 Azure 原則、適用於雲端的 Defender、GitOps 等，在 Azure 中管理非 AKS Kubernetes 叢集。

  • 使用 Pod 要求和限制 來管理 AKS 叢集中的計算資源。 Pod 要求和限制會通知 Kubernetes 排程器要指派給 Pod 的計算資源。

商務持續性/災害復原，以保護和復原 AKS

您的組織需要設計適當的 Azure Kubernetes Service （AKS） 平台層級功能，以符合其特定需求。 這些應用程式服務具有與復原時間目標 （RTO） 和恢復點目標 （RPO） 相關的需求。 AKS災害復原有多個考慮。 您的第一個步驟是為您的基礎結構和應用程式定義服務等級協定（SLA）。 瞭解 Azure Kubernetes Service （AKS） 的 SLA。 如需每月運行時間計算的相關信息，請參閱 SLA 詳細數據一節。

設計考量

請考慮下列因素：

  • AKS 叢集應該使用節點集區中的多個節點，為您的應用程式提供最低層級的可用性。

  • 設定 Pod 要求和限制。 設定這些限制可讓 Kubernetes：

    • 有效率地為 Pod 提供 CPU 和記憶體資源。
    • 節點上的容器密度較高。

    由於硬體的使用方式較佳，限制也可以提高可靠性，並降低成本。

  • 適用於 可用性區域 或可用性設定組的 AKS 適用性。

    • 選擇支援 可用性區域的區域。
    • 可用性區域 只能在建立節點集區且稍後無法變更時設定。 多重區域支援僅適用於節點集區。
    • 如需完整的區域權益，所有服務相依性也必須支持區域。 如果相依服務不支援區域，區域失敗可能會導致該服務失敗。
    • 在不同的配對區域中執行多個 AKS 叢集，以獲得超越 可用性區域 所能達到的更高可用性。 如果 Azure 資源支援異地備援，請提供備援服務具有其次要區域的位置。

  • 您應該知道 AKS 中災害復原 的指導方針。 然後，請考慮它們是否適用於您用於 Azure Dev Spaces 的 AKS 叢集。

  • 持續建立應用程式和數據的備份。

    • 非具狀態服務可以有效率地複寫。
    • 如果您需要將狀態儲存在叢集中，請經常在配對區域中備份數據。 其中一個考慮是適當地將狀態儲存在叢集中可能會很複雜。

  • 叢集更新和維護。

    • 一律讓您的叢集保持最新狀態。
    • 請注意發行和淘汰程式。
    • 規劃您的更新和維護。

  • 如果發生故障轉移，則網路連線能力。

    • 根據您的需求，選擇可跨區域或區域分散流量的流量路由器。 此架構會 部署 Azure Load Balancer ，因為它可以將非 Web 流量分散到區域。
    • 如果您需要將流量分散到區域，請考慮使用 Azure Front Door。

  • 計劃性和非計劃性故障轉移。

    • 設定每個 Azure 服務時，請選擇支援災害復原的功能。 例如，此架構會啟用 Azure Container Registry 進行異地複寫。 如果區域關閉，您仍然可以從複寫區域提取映像。

  • 維護工程DevOps功能以達到服務等級目標。

  • 判斷您是否需要 Kubernetes API 伺服器端點的財務支援 SLA 。

設計建議

以下是您設計的最佳做法：

  • 針對系統節點集區使用三個節點。 針對用戶節點集區，從不小於兩個節點開始。 如果您需要更高的可用性，請設定更多節點。

  • 將應用程式放在不同的節點集區中，以隔離您的應用程式與系統服務。 如此一來，Kubernetes 服務會在專用節點上執行，且不會與其他服務競爭。 使用 標籤、標籤和污點 來識別節點集區來排程您的工作負載。

  • 例如，定期維護叢集，進行及時更新，對於可靠性至關重要。 請留意 AKS 上 Kubernetes 版本的支援視窗，並規劃您的更新。 此外，建議透過探查監視Pod的健康情況。

  • 盡可能 從容器內移除服務狀態。 請改用支援多重區域複寫的 Azure 平臺即服務 （PaaS）。

  • 確定 Pod 資源。 強烈建議部署指定Pod資源需求。 然後排程器可以適當地排程Pod。 未排程Pod時的可靠性會過時。

  • 在部署中設定多個複本，以處理硬體故障等中斷。 對於更新和升級等計劃性事件，中斷預算可確保所需的Pod複本數目存在，以處理預期的應用程式負載。

  • 您的應用程式可能會針對其數據使用 Azure 儲存體。 由於您的應用程式分散於不同區域中的多個 AKS 叢集，因此您必須保持記憶體同步。 下列為兩個常見的複寫儲存體方式：

    • 以基礎結構為基礎的非同步複寫
    • 以應用程式為基礎的非同步複寫

  • 估計 Pod 限制。 測試並建立基準。 從要求和限制的相等值開始。 然後，逐漸調整這些值，直到您已建立可能導致叢集中不穩定的臨界值為止。 您可以在部署指令清單中指定 Pod 限制。

    內建功能可為處理服務架構中失敗和中斷的複雜工作提供解決方案。 這些設定有助於簡化設計和部署自動化。 當組織為 SLA、RTO 和 RPO 定義標準時，可以使用內建服務將 Kubernetes 和 Azure 達成其商務目標。

  • 設定 Pod 中斷預算。 此設定會檢查您可以在更新或升級事件期間關閉的部署中有多少個複本。

  • 在服務命名空間上強制執行資源配額 。 命名空間上的資源配額可確保Pod要求和限制在部署上正確設定。

    • 在叢集層級設定資源配額可能會導致部署沒有適當要求和限制的合作夥伴服務時發生問題。

  • 將您的容器映像儲存在 Azure Container Registry 中，並將登錄異地複寫至每個 AKS 區域。

  • 針對裝載生產工作負載的所有叢集，使用運行時間 SLA 來啟用財務支援的更高 SLA。 針對使用可用性區域的叢集，執行時間 SLA 可保證 Kubernetes API 伺服器端點 99.95% 的可用性；針對未使用可用性區域的叢集，則可保證 99.9% 的可用性。 您的節點、節點集區和其他資源會涵蓋在其 SLA 之下。 AKS 為其控制平面元件提供服務等級目標 （SLO） 為 99.5% 的免費層。 未啟用運行時間 SLA 的叢集不應該用於生產工作負載。

  • 針對 Azure ExpressRoute 連線使用多個區域和對等互連位置。

    如果發生影響 Azure 區域或對等互連提供者位置的中斷，備援混合式網路架構可協助確保跨單位連線中斷。

  • 將區域與 全域虛擬網路對等互連互連。 如果叢集需要彼此交談，可以透過虛擬網路對等互連來將兩個虛擬網路連線到彼此。 這項技術會將虛擬網路彼此互連，在Microsoft的骨幹網路之間提供高頻寬，甚至是跨不同地理區域。

  • Azure Front Door 使用 分割 TCP 型的任何廣播通訊協定，可確保您的終端使用者會立即連線到最接近的 Front Door 存在點。 Azure Front Door 的其他功能包括：

    • TLS 終止
    • 自訂網域
    • Web 應用程式防火牆
    • URL 重寫
    • 工作階段親和性

    檢閱應用程式流量的需求，以瞭解哪一個解決方案最適合。