管理新式應用程式平台叢集

  • 發行項

雲端採用架構提供的核心方法，可讓您以中立的方式定義雲端的作業管理流程。 其指導可協助您建立作業管理基準和其他特定層級的作業。 對於混合使用基礎結構即服務 (IaaS)、平台即服務 (PaaS) 和容器化工作負載的組織而言，本指導可能仍適用。 本文概述您需要整合到現有作業以準備進行容器管理的事項。 它也強調將 Azure Kubernetes Service (AKS) 整合至您的容器管理策略中的好處。

針對作業管理需求的商務調整

容器會移除多層基礎結構的相依性，進而改善作業管理的能力。 若要實現這些作業上的改進，您可能必須從商務調整開始，修改整體雲端管理策略。

若要建立適當的作業管理實務，您必須了解如何在雲端採用計劃中使用容器，以及您想從這項轉移到容器化工作負載得到的好處。

  • 您是否會在雲端平台中管理多個技術解決方案，例如容器、IaaS 和 PaaS？
  • 集中式小組是否支援容器或 AKS 平台的作業和管理？ 此責任是否轉移給個別的工作小組？
  • 針對在每個容器或 Pod 中執行的工作負載，集中式小組是否會支援其作業和管理？ 此責任是否轉移給個別的工作小組？
  • 您使用的是任務關鍵性工作負載的容器嗎？
  • 您是否僅針對較不重要或公用工作負載使用容器來降低成本？
  • 個別工作負載的效能和可靠性有多重要？
  • 您容器中的應用程式是否處於無狀態？ 您是否需要保持狀態以保護和復原容器中的工作負載？

這些基本問題將決定如何以最佳方式將容器和 AKS 整合到您的作業管理策略中。

作業基準

實作作業基準可讓您集中存取在雲端環境中操作及管理所有資產所需的工具。 如果您的非容器化資產沒有作業基準，您可以實作管理方法中定義的作業基準。

您的作業基準應該包含工具和設定，以提供可見度、監視、作業合規性、最佳化和保護/復原。

作業管理基準

上述文章中所述的作業基準不會為您的容器或 AKS 平台提供支援。 不過，它會提供可延伸的工具基礎以支援容器，例如 Azure 監視器、Azure 備份和其他工具。

如果您在雲端中的大部分組合都裝載在容器中，請考慮將下一節中的特殊平台作業納入您的作業基準中。

平台作業

除非此實作是您組織的第一個或唯一的雲端部署，否則您應該已有了作業基準。 本節指出您可能想要包含的一些工具，以協助管理容器或 AKS 部署。

清查和可見性

監視容器和 AKS 叢集會使用您作業基準中包含的工具、儀表板和警示。 不過，您可能需要進行更多設定，以將容器中的資料放入作業監視工具，例如容器的 Azure 監視器。 請參閱容器的 Azure 監視器概觀，以收集將容器和 AKS 平台作業新增至作業基準所需的資料。

當您設定 Azure 監視器以收集容器上的資料之後，便可以在集中式管理程序中監視下列區域：

  • 識別在各個區域中執行的叢集，最好是繫結至服務樹狀結構項目，並識別這些叢集上的關鍵事實
    • 識別叢集節點集區、網路和這些叢集的儲存體拓撲
    • 識別 AKS 版本和節點映像版本分層。
  • 識別叢集節點資源使用率 (程序、記憶體和儲存體)
  • 識別節點上執行中的容器，及其對節點使用率的貢獻
  • 了解叢集在平均負載和最高負載之下的行為。 此知識可協助您識別所需的容量，並判斷叢集可承受的負載上限。
  • 設定警示，當節點或容器上的 CPU 和記憶體使用率超過閾值，或在叢集在基礎結構或節點健康情況彙總時發生健康情況狀態變化時，主動通知您或加以記錄。
  • 使用查詢來建立一組通用的警示、儀表板，以及詳細的效能分析

這項資料也能提供在容器化平台上執行的工作負載詳細資訊，以支援工作負載作業小組：

  • 檢閱在和支援 Pod 的標準程序無關之主機上執行的工作負載的資源使用率。
  • 與 Prometheus 整合，以檢視應用程式計量。
  • 監視部署至 Azure Stack 上的 AKS 引擎內部部署和 AKS 引擎的容器工作負載。
  • 監視部署至 Azure Red Hat OpenShift 的容器工作負載。
  • 監視部署至已啟用 Azure Arc 的 Kubernetes (預覽版) 的容器工作負載。

作業合規性

在容器化環境中，修補、微調和調整大小會發生在幾個不同的層級中。 根據您所需的作業方法，操作員可能會位於一些不同的小組。 為了維持作業合規性，操作員將會監視使用量、調整資產大小以平衡效能和成本，以及修補基礎系統以將風險和設定漂移降至最低。 中央 IT 組織傾向於以 IaaS 和 PaaS 解決方案為作業基準來交付這些工作。

在 Azure 的叢集環境中，這些工作會在多個層級上執行：AKS 叢集、節點映像和節點作業系統。 所有這些作業工作都會變得更依賴於對叢集或個別節點集區上執行之工作負載的理解和工作關聯性。 下列陳述將有助於評估您要做什麼，以及您是否要操作容器環境。

  • 如果 AKS 叢集、節點映像或節點作業系統的調整大小和修補是以應用程式部署管線的一部分來提供，或是相依於應用程式架構或設定，最好將作業合規性轉移給工作負載小組，以進行細微控制。 因為工作負載通常會相依於協調流程功能，所以這是最常見的模式，因為未預期的 AKS 版本變更或節點映像變更可能會對工作負載或其執行階段工具造成災難性的變化。
  • 針對較不常見的集中式叢集，支援工作負載的組合和各種應用程式，集中式作業小組可能仍會負責作業合規性工作，下列指南將有助於在您的叢集中交付這些工作。 定期執行這些工作，逐漸將特定作業加入平台。 中央操作方法有明顯的風險，因此包括在預先生產環境中仔細測試升級、對排程維護需明確並加以遵守，以及為不符合規範之工作負載做好應變計劃，這一切都必須準備就緒。 一個不良升級可能是單一失敗點，同樣地，一個無法升級的工作負載可能會導致叢集失去支援。 盡責地規劃和管理多租用戶叢集。

對於這兩種叢集類型，請遵循升級、節點映像和節點作業系統更新的指導，如下所示：

保護和復原

AKS 節點本質上是暫時性的，因此不會以可個別還原的方式進行備份。 從事件中復原可能涉及到將工作負載重新部署到新的節點集區或整個新叢集，取決於事件範圍而定。

  • 選擇是否將執行時間服務等級協定新增至您的叢集。
  • 對於較高的服務等級協定，建議考慮多區域 BCDR 最佳做法，以提供額外的保護。
  • 因為叢集不應該包含狀態，所以會使用現有的作業基準指導來處理外部狀態還原。 如果將狀態帶入您的叢集，請確保遵循儲存體上的運算子最佳做法，並制定可針對指定的工作負載備份和還原此資料的策略。 使用 Velero 之類的工具就是平台特定作業的一個範例，這種工具可擴充作業基準。
    • 如果您的應用程式組合不一致地套用狀態，則中央作業小組不應該嘗試同時維護這兩種解決方案。 相反地，請將所有容器的所需狀態工具鏈標準化，但是將替代復原解決方案的責任轉移給工作負載作業小組。 此方法可讓開發人員自由設計，保持較低的中心成本，並為工作負載小組提供成本降低的動機，以符合標準。

工作負載作業

上述平台作業一節說明管理 AKS 叢集時的通用對話。 Kubernetes 叢集是需要受到集中管理的技術平台嗎？ 或者它們是工作負載工具，應該由擁有每個工作負載的團隊進行管理？ 此問題視不同組織而有不同的答案。 在大部分組織中觀察到的情況是，容器和 AKS 的設計目的是為了讓工作負載小組能更靈活地操作每個工作負載，並為這些工作負載提供特定功能，以便在其架構中使用，讓應用程式的擁有者和客戶受益。

工作負載作業可以根據您現有的作業基準和平台特定作業來建立。 您也可以使用完全非集中式的工作負載作業，安全地操作 AKS 叢集。 無論是哪一種情況，當您需要提升作業以著重於特定工作負載的特定結果時，您可以使用 Azure Well-Architected Framework 和 Microsoft Azure Well-Architected Review，以取得工作負載所使用作業流程和工具類型的特定資訊。

下一步：您的下一個移轉反覆項目

完成新式應用程式平台移轉之後，雲端採用小組就可以開始下一個特定案例的移轉。 或者，如果有其他要移轉的平台，可以再次使用此文章系列來引導您下一個新式應用程式平台的移轉或部署。