Azure Kubernetes Service (AKS) 叢集的基準架構

此參考架構提供建議的基準基礎結構架構，以在 Azure 上部署 Azure Kubernetes Service （AKS） 叢集。 其會使用我們的設計原則，並且以 Azure 良好架構架構中的架構最佳做法為基礎，透過部署此一般用途基礎結構，引導跨領域或多個不同的小組，例如網路、安全性和身分識別。

此架構不會著重於工作負載，而是著重於 AKS 叢集本身。 以下是大部分 AKS 叢集的最低建議基準。 其與 Azure 服務整合，可提供可檢視性、支援多重區域成長的網路拓撲，以及保護叢集內流量。

目標架構會受到您的商務需求影響，因此在不同的應用程式內容之間可能會有所不同。 它應該視為生產前和生產階段的起點。

GitHub 上也提供 此架構的實作：Azure Kubernetes Service （AKS） 基準參考實作。 您可以使用它作為替代起點，並根據需求進行設定。

網路設定

網路拓撲
規劃IP位址
部署輸入資源

叢集計算

基底叢集的計算
容器映像參考
原則管理

身分識別管理

整合叢集的 Microsoft Entra 識別符
整合工作負載的 Microsoft Entra 識別碼

安全數據流

保護網路流程
新增秘密管理

業務持續性

延展性
叢集和節點可用性
可用性和多重區域支援

Operations

叢集和工作負載 CI/CD 管線
叢集健康情況和計量
成本管理和報告

網路拓撲

此架構會使用中樞輪輻網路拓撲。 中樞和輪輻會部署在透過 對等互連連線的個別虛擬網路中。 此拓撲的一些優點如下：

• 隔離的管理。 啟用套用治理並遵守最低權限準則的方法。 其也支援 Azure 登陸區域與職責區分的概念。

• 盡量不讓 Azure 資源直接公開至公用網際網路。

• 組織通常會搭配區域中樞輪輻拓撲運作。 中樞輪輻網路拓撲未來可以擴充，並提供工作負載隔離。

• 所有 Web 應用程式都應該要求 Web 應用程式防火牆 (WAF) 服務，以協助控管 HTTP 流量流程。

• 自然選擇跨多個訂用帳戶的工作負載。

• 其會使架構可進行擴充。 若要容納新功能或工作負載，可以新增輪輻，而不是重新設計網路拓撲。

• 某些資源 (例如防火牆和 DNS) 可以跨網路共用。

• 與 Azure 企業級登陸區域一致。

下載此架構的 Visio 檔案。

如需詳細資訊，請參閱 Azure 中的中樞輪輻網路拓撲。

若要檢閱 AKS 基準參考架構上 Windows 容器中包含的網路設計變更，請參閱 隨附文章。

中樞

中樞虛擬網路是連線能力和可檢視性的中心點。 中樞一律包含由中央 IT 小組定義的全域防火牆原則 Azure 防火牆，以強制執行整個組織的防火牆原則、Azure Bastion、VPN 連線的閘道子網，以及適用於網路可觀察性的 Azure 監視器。

在網路內，會部署三個子網路。

要裝載 Azure 防火牆的子網路

Azure 防火牆 是防火牆即服務。 防火牆執行個體會保護輸出網路流量。 若沒有這一層安全性，此流量可能會與惡意的第三方服務通訊，而該服務可能會將公司機密資料外洩。 Azure 防火牆 管理員可讓您集中部署及設定多個 Azure 防火牆 實例，以及管理此中樞虛擬網路架構類型的 Azure 防火牆 原則。

要裝載閘道的子網路

此子網路是 VPN 或 ExpressRoute 閘道的預留位置。 此閘道會在內部部署網路中的路由器與虛擬網路之間提供連線。

要裝載 Azure Bastion 的子網路

此子網是 Azure Bastion 的佔位符。 您可以使用 Bastion 安全地存取 Azure 資源，而不會將資源公開至網際網路。 此子網路僅用於管理和作業。

輪輻

輪輻虛擬網路包含 AKS 叢集和其他相關資源。 輪輻有四個子網路：

要裝載 Azure 應用程式閘道的子網路

Azure 應用程式閘道是在第 7 層運作的 Web 流量負載平衡器。 參考實作會使用 應用程式閘道 v2 SKU 來啟用 Web 應用程式防火牆 （WAF）。 WAF 會防範來自常見 Web 流量攻擊的傳入流量，包括 Bot。 執行個體具有公用前端 IP 設定，其會接收使用者要求。 根據設計，應用程式閘道需要專用的子網路。

要裝載輸入資源的子網路

為了路由和散發流量， Traefik 是將滿足 Kubernetes 輸入資源的輸入控制器。 Azure 內部負載平衡器存在於這個子網路中。 如需詳細資訊，請參閱搭配 Azure Kubernetes Service 使用內部負載平衡器 （AKS）。

要裝載叢集節點的子網路

AKS 會維護兩個不同的節點群組 (或節點集區)。 「系統節點集區」會裝載執行核心叢集服務的 Pod。 「使用者節點集區」會執行您的工作負載和輸入控制器，以啟用對工作負載的輸入通訊。

要裝載 Private Link 端點的子網路

Azure Private Link 連線是針對 Azure Container Registry 和 Azure 金鑰保存庫 所建立，因此可以使用輪輻虛擬網路內的私人端點來存取這些服務。 私人端點不需要專用子網路，而且也可以放在中樞虛擬網路中。 在基準實作中，其會部署到輪輻虛擬網路內的專用子網路。 此方法可減少通過對等互連網路連線的流量、將屬於叢集的資源保留在相同的虛擬網路中，並可讓您使用網路安全組在子網層級套用細微的安全性規則。

如需詳細資訊，請參閱 Private Link 部署選項。

規劃 IP 位址

下載此架構的 Visio 檔案。

虛擬網路的位址空間應該大到足以容納所有子網。 考慮將接收流量的所有實體。 這些實體的IP位址將會從子網位址空間配置。 請考慮這些點。

• 升級

  AKS 會定期更新節點，以確保基礎虛擬機器擁有最新的安全性功能和其他系統修補檔。 在升級過程中，AKS 會建立節點，暫時裝載 Pod，同時升級節點會受到封鎖並清空。 該暫存節點會從叢集子網路獲指派 IP 位址。

  針對 Pod，視您的策略而定，您可能需要額外的位址。 針對輪流更新，您需要在實際 Pod 更新時執行工作負載的暫存 Pod 位址。 如果您使用取代策略，則系統會移除 Pod 並建立新的 Pod。 因此，會重複使用與舊 Pod 相關聯的位址。

• 延展性

  將所有系統和使用者節點的節點計數及其最大可擴縮性限制納入考慮。 假設您想要擴增 400%。 所有向外延展節點的位址數目需要四倍。

  在此架構中，您可以直接聯繫每個 Pod。 因此，每個 Pod 都需要個別的位址。 Pod 延展性會影響地址計算。 該決策將取決於您選擇的Pod數目，而您想要成長。

• Azure Private Link 位址

  將透過 Private Link 與其他 Azure 服務通訊所需的位址因素考慮進去。 在此架構中，我們已針對 Azure Container Registry 和 Key Vault 的連結指派兩個位址。

• 某些位址會保留 供 Azure 使用。 無法指派它們。

上述清單並不詳盡。 如果您的設計具有會影響可用IP位址數目的其他資源，請容納這些位址。

此架構是專為單一工作負載所設計。 針對多個工作負載，您可能想要將使用者節點集區彼此隔離，以及與系統節點集區隔離。 該選擇會產生更多規模較小的子網路。 此外，輸入資源可能更複雜，因此您可能需要多個要求額外 IP 位址的輸入控制器。

如需此架構的完整考慮集，請參閱 AKS 基準網路拓撲。

如需規劃 AKS 叢集 IP 的相關信息，請參閱 規劃叢集的 IP 位址。

若要檢閱 AKS 基準參考架構上 Windows 容器中包含的 IP 位址規劃考慮，請參閱 隨附文章。

附加元件和預覽功能

Kubernetes 和 AKS 是持續演進的產品，發行週期比內部部署環境的軟體更快。 此基準架構取決於選取的 AKS 預覽功能和 AKS 附加元件。 兩者之間的差異如下：

• AKS 小組將預覽功能描述為 隨附和改善。 其背後的原因是，許多預覽功能在移至一般發行 （GA） 階段之前，只停留在該狀態幾個月。
• AKS 附加元件和延伸模組 會提供額外的支援功能。 其安裝、設定和生命週期是由 AKS 管理。

此基準架構不包含每個預覽功能或附加元件，而是只包含那些將重要價值新增至一般用途叢集的架構。 隨著這些功能的預覽，此基準架構將會據以修訂。 您可能想要在生產前叢集中評估一些額外的預覽功能或 AKS 附加元件，以增強安全性、管理性或其他需求。 使用第三方附加元件時，您必須安裝和維護它們，包括追蹤可用的版本，以及在升級叢集的 Kubernetes 版本之後安裝更新。

容器映像參考

除了工作負載之外，叢集可能包含數個其他映像，例如輸入控制器。 其中有些映像可能位於公用登錄中。 將這些點提取到您的叢集時，請考慮這些點。

• 叢集已驗證以提取映像。

• 如果您使用公用映像，請考慮將它匯入至與 SLO 一致的容器登錄中。 否則，映像可能會發生非預期的可用性問題。 當您需要映像時，這些問題可能會導致操作問題。 以下是使用容器登錄而非公用登錄的一些優點：

  • 您可以封鎖未經授權存取映像。
  • 您不會有公開的相依性。
  • 您可以存取映像提取記錄，以監視活動和分級連線問題。
  • 利用整合式容器掃描和映像合規性。

  選項為 Azure Container Registry （ACR）。

• 從授權的登錄提取映像。 您可以透過 Azure 原則 強制執行這項限制。 在此參考實作中，叢集只會從部署為架構一部分的 ACR 提取映射。

設定基底叢集的計算

在 AKS 中，每個節點集區都會對應至虛擬機器擴展集。 節點是每個節點集區中的 VM。 請考慮針對系統節點集區使用較小的 VM 大小，以將成本降到最低。 此參考實作會部署具有三個 DS2_v2 節點的系統節點集區。 該大小足以符合系統 Pod 的預期負載。 OS 磁碟為 512 GB。

針對使用者節點集區，以下是一些考量：

• 選擇較大的節點大小，以封裝節點上設定的 Pod 數目上限。 它會將所有節點上執行的服務使用量降到最低，例如監視和記錄。

• 部署至少兩個節點。 如此一來，工作負載會有具有兩個複本的高可用性模式。 使用 AKS，您可以變更節點數，而不需要重新建立叢集。

• 工作負載的實際節點大小將取決於設計小組所決定的需求。 根據商務需求，我們已針對生產工作負載選擇DS4_v2。 若要降低成本，可以將大小降到 DS3_v2，這是最低建議。

• 規劃叢集的容量時，假設您的工作負載最多可耗用每個節點的 80%; 其餘 20% 保留給 AKS 服務。

• 根據您的容量規劃，設定每個節點的 Pod 數目上限。 如果您嘗試建立容量基準，請從值 30 開始。 根據工作負載、節點大小和您的 IP 條件限制式的需求調整該值。

整合叢集的 Microsoft Entra ID

保護對叢集資源的存取以及叢集對外部資源的存取非常重要。 當您做出安全性選擇時，請從叢集的觀點思考：

• 由內而外的存取。 AKS 對 Azure 元件 (例如網路基礎結構、Azure Container Registry 與 Azure Key Vault) 的存取。 只授權叢集可以存取的資源。
• 由外而內的存取。 提供對 Kubernetes 叢集的身分識別存取。 只授權那些可以存取 Kubernetes API 伺服器與 Azure Resource Manager 的外部實體。

對 Azure 的 AKS 存取

有兩種方式可透過 Microsoft Entra ID 管理 AKS 對 Azure 的存取：服務主體或 Azure 資源受控識別。

在兩種方式中，建議使用受控識別。 使用服務主體時，您必須負責手動或以程序設計方式管理及輪替秘密。 使用受控識別，Microsoft Entra ID 會為您管理並執行驗證並及時輪替秘密。

建議 啟用 受控識別，讓叢集可以透過 Microsoft Entra ID 與外部 Azure 資源互動。 您只能在叢集建立期間啟用此設定。 即使 Microsoft Entra 識別碼未立即使用，您稍後仍可加以合併。

根據預設，叢集會使用兩個主要身分識別：叢集身分識別和 kubelet 身分識別。 AKS 控制平面元件會使用叢集身分識別來管理叢集資源，包括輸入負載平衡器、AKS 受控公用 IP 等。kubelet 身分識別是用來向 Azure Container Registry (ACR) 進行驗證。 某些附加元件也支援使用受控識別進行驗證。

作為由內而外案例的範例，讓我們研究在叢集需要從容器登錄提取映像時使用受控識別。 此動作要求叢集必須取得登錄的認證。 其中一種方式是以 Kubernetes Secrets 物件的形式儲存該資訊，並使用 imagePullSecrets 來擷取秘密。 由於安全性複雜度，建議不要使用這種方法。 您不僅需要事先知道祕密，而且會透過 DevOps 管線揭露該祕密。 另一個原因是管理祕密輪替的作業額外負荷。 相反地，將叢集的 kubelet 受控識別存取權授 acrPull 與登錄。 這種方法可消除那些疑慮。

在此架構中，叢集會存取受 Microsoft Entra ID 保護的 Azure 資源，並執行支援受控識別的作業。 根據叢集想要執行的作業，將 Azure 角色型存取控制 (Azure RBAC) 與權限指派給叢集的受控識別。 叢集會向 Microsoft Entra 識別符驗證自己，然後根據指派的角色來允許或拒絕存取。 以下是此參考實作的一些範例，其中 Azure 內建角色已指派給叢集：

• 網路參與者 (部分機器翻譯)。 叢集控制輪輻虛擬網路的能力。 此角色指派可讓 AKS 叢集系統指派的身分識別使用內部輸入控制器服務的專用子網路。
• 監視計量發行者 (部分機器翻譯)。 叢集將計量傳送至 Azure 監視器的能力。
• AcrPull (部分機器翻譯)。 叢集從指定的 Azure 容器登錄提取映像的能力。

叢集存取

Microsoft Entra 整合也可簡化由外而內存取的安全性。 假設使用者想要使用 kubectl。 在初始步驟中，他們會執行 az aks get-credentials 命令來取得叢集的認證。 Microsoft Entra ID 會根據允許取得叢集認證的 Azure 角色來驗證使用者的身分識別。 如需詳細資訊，請參閱 可用的叢集角色許可權。

AKS 允許以兩種方式使用 Microsoft Entra ID 進行 Kubernetes 存取。 第一個是使用 Microsoft Entra ID 作為與原生 Kubernetes RBAC 系統整合的識別提供者。 另一種是使用原生 Azure RBAC 來控制叢集存取。 以下詳述兩者。

將 Kubernetes RBAC 與 Microsoft Entra 標識碼產生關聯

Kubernetes 透過下列方式支援角色型存取控制 （RBAC）

• 一組許可權。 由 Role 或 ClusterRole 物件定義，以取得整個叢集的許可權。

• 指派允許執行動作之使用者和群組的系結。 由 RoleBinding 或 ClusterRoleBinding 物件定義。

Kubernetes 有一些內建角色，例如叢集管理員、編輯、檢視等等。 將這些角色系結至 Microsoft Entra 使用者和群組，以使用企業目錄來管理存取權。 如需詳細資訊，請參閱 搭配 Microsoft Entra 整合使用 Kubernetes RBAC。

請確定用於叢集和命名空間存取的 Microsoft Entra 群組包含在您的 Microsoft Entra 存取權檢閱中。

使用適用於 Kubernetes 的 Azure RBAC 授權

除了使用 Kubernetes 原生 RBAC （ClusterRoleBindings 和 RoleBindings） 進行整合式 Microsoft Entra 驗證的授權，我們建議的另一個選項是使用 Azure RBAC 和 Azure 角色指派在叢集上強制執行授權檢查。 這些角色指派甚至可以新增在訂用帳戶或資源群組範圍，讓範圍下的所有叢集都繼承一組一致的角色指派，以存取 Kubernetes 叢集上對象的許可權。

如需詳細資訊，請參閱 適用於 Kubernetes 授權的 Azure RBAC 授權。

本機帳戶

AKS 支援原生 Kubernetes 用戶驗證。 不建議使用者使用此方法存取叢集。 它是憑證型，且是在主要識別提供者外部執行;使集中式用戶訪問控制和治理變得困難。 一律使用 Microsoft Entra ID 管理叢集的存取權，並將叢集設定為明確停用本機帳戶存取。

在此參考實作中，部署叢集時，會明確停用透過本機叢集帳戶的存取。

整合工作負載的 Microsoft Entra 識別碼

類似於為整個叢集指派 Azure 系統指派的受控識別，您可以在 Pod 層級指派受控識別。 工作負載身分識別可讓裝載的工作負載透過 Microsoft Entra ID 存取資源。 例如，工作負載會將檔案儲存在 Azure 儲存體 中。 當它需要存取這些檔案時，Pod 會以 Azure 受控識別的形式向資源驗證本身。

在此參考實作中，Pod 的受控識別是透過 AKS 上的 Microsoft Entra 工作負載 ID 來提供。 這會與 Kubernetes 原生功能整合，以與外部識別提供者同盟。 如需 Microsoft Entra 工作負載 ID 同盟的詳細資訊，請參閱下列概觀。

部署輸入資源

Kubernetes 輸入資源會路由傳送並散發連入流量至叢集。 輸入資源有兩個部分：

• 內部負載平衡器。 由 AKS 管理。 此負載平衡器會透過私人靜態 IP 位址公開輸入控制器。 它可作為接收輸入流程的單一連絡點。

  在此架構中，會使用 Azure Load Balancer。 它會放在專用於輸入資源的子網中叢集外部。 它會從 Azure 應用程式閘道 接收流量，且該通訊是透過TLS。 如需輸入流量 TLS 加密的相關信息，請參閱 輸入流量流程。

• 輸入控制器。 我們選擇了特拉菲克。 它會在叢集中的用戶節點集區中執行。 它會從內部負載平衡器接收流量、終止 TLS，然後透過 HTTP 將流量轉送至工作負載 Pod。

輸入控制器是叢集的重要元件。 設定此元件時，請考慮這些點。

• 作為設計決策的一部分，請選擇允許輸入控制器運作的範圍。 例如，您可以允許控制器只與執行特定工作負載的Pod互動。

• 避免將復本放在相同的節點上，以分散負載，並確保節點關閉時保持商務持續性。 用於 podAntiAffinity 此用途。

• 使用 nodeSelectors來限制只在用戶節點集區上排程Pod。 此設定會隔離工作負載和系統 Pod。

• 開啟允許特定實體將流量傳送至輸入控制器的埠和通訊協定。 在此架構中，Traefik 只會接收來自 Azure 應用程式閘道 的流量。

• 輸入控制器應該傳送指出Pod健康情況的訊號。 設定 readinessProbe 和 livenessProbe 設定，以指定間隔監視 Pod 的健康情況。

• 請考慮限制輸入控制器對特定資源的存取，以及執行特定動作的能力。 該限制可以透過 Kubernetes RBAC 許可權來實作。 例如，在此架構中，Traefik 已獲得在 Kubernetes ClusterRole 物件中使用規則來監看、取得及列出服務和端點的許可權。

若要檢閱 AKS 基準參考架構上 Windows 容器中使用的輸入設計，請參閱 隨附文章。

路由器設定

輸入控制器會使用路由來判斷傳送流量的位置。 路由會指定接收流量的來源埠，以及目的地埠和通訊協議的相關信息。

以下是此架構的範例：

Traefik 會使用 Kubernetes 提供者來設定路由。 annotations、 tls和 entrypoints 表示路由將會透過 HTTPS 提供。 middlewares指定只允許來自 Azure 應用程式閘道 子網的流量。 如果用戶端接受，回應將會使用 gzip 編碼。 由於 Traefik 會執行 TLS 終止，因此與後端服務的通訊是透過 HTTP 進行。

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

保護網路流程

在此內容中，網路流程可以分類為：

• 輸入流量。 從用戶端到叢集中執行的工作負載。

• 輸出流量。 從叢集中的 Pod 或節點到外部服務。

• Pod 對 Pod 流量。 Pod 之間的通訊。 此流量包括輸入控制器與工作負載之間的通訊。 此外，如果您的工作負載是由多個部署至叢集的應用程式所組成，則這些應用程式之間的通訊也將屬於此類別。

• 管理流量。 用戶端與 Kubernetes API 伺服器之間的流量。

下載此架構的 Visio 檔案。

此架構有數層安全性可保護所有類型的流量。

輸入流量流程

架構只接受來自用戶端的 TLS 加密要求。 TLS v1.2 是最低允許版本，其中具有一組受限的密碼。 已啟用伺服器名稱指示 (SNI) strict。 端對端 TLS 是透過應用程式閘道設定的，方法是使用兩個不同的 TLS 憑證，如下圖所示。

下載此架構的 Visio 檔案。

1. 用戶端會將 HTTPS 要求傳送至功能變數名稱：bicycle.contoso.com。 該名稱會透過 DNS A 記錄與 Azure 應用程式閘道的公用 IP 位址相關聯。 此流量會加密，以確保客戶端瀏覽器與閘道之間的流量無法檢查或變更。

2. 應用程式閘道 具有整合式 Web 應用程式防火牆 （WAF），並交涉 tls 交握以進行 bicycle.contoso.com，只允許安全的加密。 應用程式閘道是 TLS 終止點，因為需要處理 WAF 檢查規則，並執行路由規則，將流量轉送至設定的後端。 TLS 憑證會儲存在 Azure Key Vault 中。 其存取方式是使用一個使用者指派的受控識別，其已與應用程式閘道整合。 如需該功能的相關信息，請參閱使用 金鑰保存庫 憑證終止 TLS。

3. 當流量從應用程式閘道移至後端時，系統會再次使用另一個 TLS 憑證 (萬用字元表示 *.aks-ingress.contoso.com) 將其加密，因為其會轉送至內部負載平衡器。 此重新加密可確保不安全的流量不會流入叢集子網。

4. 輸入控制器會透過負載平衡器接收加密的流量。 控制器是 *.aks-ingress.contoso.com 的另一個 TLS 終止點，並會透過 HTTP 將流量轉送至工作負載 Pod。 憑證會儲存在 Azure Key Vault 中，並使用容器儲存體介面 (CSI) 驅動程式掛接至叢集。 如需詳細資訊，請參閱 新增秘密管理。

您可以在每個躍點實作端對端 TLS 流量，以流到工作負載 Pod。 在決定保護 Pod 對 Pod 流量時，請務必測量效能、延遲和作業影響。 對於大部分的單一租使用者叢集，使用適當的控制平面 RBAC 和成熟的軟體開發生命週期做法，TLS 可以加密至輸入控制器，並使用 Web 應用程式防火牆 保護 。 這將將工作負載管理和網路效能影響的額外負荷降到最低。 您的工作負載和合規性需求會決定您執行 TLS 終止的位置。

輸出流量流程

在此架構中，我們建議透過 Azure 防火牆 或您自己的類似網路虛擬設備，透過 NAT 閘道或 HTTP Proxy 等其他選項，從叢集通訊的所有輸出流量。 對於零信任控制及檢查流量的能力，來自叢集的所有輸出流量都會經過 Azure 防火牆。 您可以使用使用者定義的路由來實作該選擇。 路由的下一個躍點是 Azure 防火牆 的私人IP位址。 在這裡，Azure 防火牆 決定是否要封鎖或允許輸出流量。 該決策是以 Azure 防火牆 或內建威脅情報規則中所定義的特定規則為基礎。

使用 Azure 防火牆 的替代方法是使用 AKS 的 HTTP Proxy 功能。 所有輸出叢集的流量都會先設定為 HTTP Proxy 的 IP 位址，以決定轉送流量或卸載流量。

使用任一方法，檢閱 AKS 所需的 輸出網路規則 。

零信任控件的例外狀況是叢集需要與其他 Azure 資源通訊時。 例如，叢集必須從容器登錄提取更新的映像，或從 Azure 金鑰保存庫 提取秘密。 建議的方法是使用 Azure Private Link。 優點是特定子網會直接連線到服務，而不是叢集與透過因特網傳輸的服務之間的流量。 缺點是 Private Link 需要額外的設定，而不是透過其公用端點使用目標服務。 此外，並非所有 Azure 服務或 SKU 都支援 Private Link。 在這些情況下，請考慮在子網上啟用 虛擬網絡 服務端點來存取服務。

如果 Private Link 或服務端點不是選項，您可以透過公用端點連線到其他服務，並透過 Azure 防火牆 規則和目標服務內建的防火牆來控制存取。 由於此流量會通過防火牆的靜態 IP 位址，因此這些位址可以新增服務的 IP 允許清單。 其中一個缺點是，Azure 防火牆 需要有額外的規則，以確保只允許來自特定子網的流量。 當您規劃多個具有 Azure 防火牆 輸出流量的IP位址時，請將這些位址納入考慮，否則您可以觸達埠耗盡。 如需多個IP位址規劃的詳細資訊，請參閱 限制和控制輸出流量。

若要檢閱 AKS 基準參考架構上 Windows 容器中使用的 Windows 特定輸出考慮，請參閱 隨附文章。

Pod 對 Pod 流量

根據預設，Pod 可以接受來自叢集中任何其他 Pod 的流量。 Kubernetes NetworkPolicy 可用來限制 Pod 之間的網路流量。 明智地套用原則，否則您可能會有重大網路流程遭到封鎖的情況。 只 允許視需要的特定通訊路徑，例如輸入控制器和工作負載之間的流量。 如需詳細資訊，請參閱 網路原則。

布建叢集時啟用網路原則，因為稍後無法新增。 實作的技術 NetworkPolicy有幾個選擇。 建議使用 Azure 網路原則，這需要 Azure 容器網路介面 （CNI），請參閱下列附注。 其他選項包括 Calico 網路原則、已知的開放原始碼選項。 如果您需要管理全叢集網路原則，請考慮 Calico。 卡利科不受標準 Azure 支援 所涵蓋。

如需詳細資訊，請參閱 Azure 網路原則和 Calico 原則之間的差異及其功能。

管理流量

在執行叢集時，Kubernetes API 伺服器會收到想要在叢集上執行管理作業的資源流量，例如建立資源或調整叢集的要求。 這些資源的範例包括 DevOps 管線中的組建代理程式集區、Bastion 子網和節點集區本身。 不要接受來自所有IP位址的這項管理流量，而是使用AKS的授權IP範圍功能，只允許來自您授權IP範圍的流量到API伺服器。

如需詳細資訊，請參閱 定義 API 伺服器授權的 IP 範圍。

如需額外的控制層，請以額外的複雜度為代價，布建私人 AKS 叢集。 藉由使用私人叢集，您可以確保 API 伺服器與節點集區之間的網路流量只會保留在專用網路上，而不會向因特網公開。 如需詳細資訊，請參閱 AKS 私人叢集。

新增秘密管理

將秘密儲存在受控密鑰存放區中，例如 Azure 金鑰保存庫。 優點是受控存放區會處理秘密輪替、提供強式加密、提供存取稽核記錄，以及將核心秘密保留在部署管線外。 在此架構中，Azure 金鑰保存庫 防火牆會啟用並設定私人連結連線，以連線到需要存取秘密和憑證的 Azure 資源。

Azure 金鑰保存庫 與其他 Azure 服務緊密整合。 使用這些服務的內建功能來存取秘密。 如需如何 Azure 應用程式閘道 存取輸入流程 TLS 憑證的範例，請參閱輸入流量一節。

金鑰保存庫 的 Azure RBAC 許可權模型可讓您將工作負載身分識別指派給 金鑰保存庫 秘密使用者或 金鑰保存庫 讀取者角色指派，以及存取秘密。 如需詳細資訊，請參閱使用 RBAC 存取 Azure 金鑰保存庫。

存取叢集秘密

您必須使用工作負載身分識別來允許 Pod 從特定存放區存取秘密。 若要加速擷取程式，請使用 秘密存放區 CSI 驅動程式。 當 Pod 需要秘密時，驅動程式會與指定的存放區連線、擷取磁碟區上的秘密，並在叢集中掛接該磁碟區。 然後，Pod 可以從磁碟區文件系統取得秘密。

CSI 驅動程式有許多提供者可支援各種受控存放區。 在此實作中，我們已選擇 Azure 金鑰保存庫 搭配秘密存放區 CSI 驅動程式使用附加元件，從 Azure 金鑰保存庫 擷取 TLS 憑證，並在執行輸入控制器的 Pod 中載入它。 在 Pod 建立期間完成，磁碟區會同時儲存公用和私鑰。

工作負載記憶體

此架構中使用的工作負載是無狀態的。 如果您需要儲存狀態，建議將其保存在叢集外部。 工作負載狀態的指引不在本文的範圍內。

若要深入瞭解記憶體選項，請參閱 Azure Kubernetes Service （AKS） 中應用程式的 儲存體 選項。

原則管理

管理 AKS 叢集的有效方式是透過原則強制執行治理。 Kubernetes 會透過 OPA Gatekeeper 實作原則。 針對 AKS，原則會透過 Azure 原則 傳遞。 每個原則都會套用至其範圍中的所有叢集。 Azure 原則 強制最終由叢集中的 OPA Gatekeeper 處理，並記錄所有原則檢查。 原則變更不會立即反映在您的叢集中，預期會看到一些延遲。

有兩種不同的案例 Azure 原則 提供來管理 AKS 叢集：

• 藉由評估您的組織標準，防止或限制在資源群組或訂用帳戶中部署 AKS 叢集。 例如，遵循命名慣例、指定標記等等。
• 透過適用於 Kubernetes 的 Azure 原則 保護您的 AKS 叢集。

設定原則時，請根據工作負載的需求加以套用。 考量下列因素：

• 您要設定原則集合（稱為計劃）或選擇個別原則嗎？ Azure 原則 提供兩個內建計劃：基本和受限。 每個方案都是適用於 AKS 叢集的內建原則集合。 建議您根據組織的需求，選取方案並挑選叢集和資源的其他原則（ACR、應用程式閘道、金鑰保存庫 和其他資源）。與叢集互動。

• 您要 稽核 或 拒絕 動作嗎？ 在 稽核 模式中，允許動作，但標示為 不符合規範。 讓程式定期檢查不符合規範的狀態，並採取必要的動作。 在 [拒絕 ] 模式中，動作會因為違反原則而遭到封鎖。 請小心選擇此模式，因為工作負載無法運作太嚴格。

• 您的工作負載中有設計不應符合規範的區域嗎？ Azure 原則 能夠指定不受原則強制執行的 Kubernetes 命名空間。 建議您仍以 稽核 模式套用原則，以便您知道這些實例。

• 您有內建原則未涵蓋的需求嗎？ 您可以建立套用自定義 OPA 閘道守衛原則的自訂 Azure 原則 定義。 請勿將自定義原則直接套用至叢集。 若要深入瞭解如何建立自定義原則，請參閱 建立和指派自定義原則定義。

• 您是否有整個組織的需求？ 如果是，請在管理群組層級新增這些原則。 即使組織有一般原則，您的叢集也應該指派自己的工作負載特定原則。

• Azure 原則會指派給特定範圍。 請確定生產原則也會針對生產前環境進行驗證。 否則，在部署到生產環境時，您可能會遇到未在生產階段前考慮的非預期額外限制。

在此參考實作中，會在建立 AKS 叢集時啟用 Azure 原則，並在稽核模式中指派限制性計劃，以取得不符合規範的可見度。

實作也會設定不屬於任何內建計劃一部分的其他原則。 這些原則會設定為 [拒絕 ] 模式。 例如，有原則可確定映像只會從已部署的 ACR 提取。 請考慮建立您自己的自訂計劃。 將適用於您工作負載的原則合併成單一指派。

若要觀察叢集中 Azure 原則 的運作方式，您可以存取命名空間中gatekeeper-system所有 Pod 的 Pod 記錄，以及命名空間中 和 azure-policy-webhook Pod 的kube-system記錄azure-policy。

若要檢閱 AKS 基準參考架構上 Windows 容器中包含的 Windows 特定 Azure 原則 考慮，請參閱隨附文章。

節點和 Pod 延展性

隨著需求增加，Kubernetes 可以透過水平 Pod 自動調整 (HPA) 將更多 Pod 新增至現有節點來擴增。 當無法再排程其他 Pod 時，必須透過 AKS 叢集自動調整來增加節點數目。 完整的縮放解決方案必須有方法可調整叢集中的 Pod 複本和節點計數。

有兩種方法: 自動調整或手動縮放。

手動或程式設計方式會要求您監視和設定 CPU 使用率或自訂計量的警示。 針對 Pod 調整，應用程式操作員可以透過 Kubernetes API 調整 ReplicaSet 來增加或減少 Pod 複本數目。 針對叢集縮放，其中一種方式是在 Kubernetes 排程器失敗時收到通知。 另一種方式是監看擱置的 Pod 一段時間。 您可以透過 Azure CLI 或入口網站調整節點計數。

自動調整是建議的方法，因為其中一些手動機制是內建在自動調整程式中。

一般方法從效能測試開始，最少的Pod和節點數目。 使用這些值來建立基準預期。 然後使用效能計量和手動調整的組合來找出瓶頸，並瞭解應用程式的調整回應。 最後，使用此數據來設定自動調整的參數。 如需使用 AKS 效能微調案例的相關信息，請參閱 效能微調案例：分散式商務交易。

水平 Pod 自動調整程式

水準 Pod 自動調整程式 （HPA） 是可調整 Pod 數目的 Kubernetes 資源。

在 HPA 資源中，建議設定最小和最大複本計數。 這些值會限制自動調整界限。

HPA 可以根據 CPU 使用率、記憶體使用量和自訂計量進行縮放。 僅提供現用的 CPU 使用率。 HorizontalPodAutoscaler 定義會指定這些計量的目標值。 例如，規格會設定目標 CPU 使用率。 當 Pod 正在執行時，HPA 控制器會使用 Kubernetes 計量 API 來檢查每個 Pod 的 CPU 使用率。 它會比較該值與目標使用率，並計算比率。 然後，它會使用比率來判斷 Pod 是否過度分派或分派不足。 它依賴 Kubernetes 排程器，將新的 Pod 指派給節點，或從節點移除 Pod。

在調整作業完成之前，可能會有競爭狀況（HPA）會檢查。 結果可能是不正確的比率計算。 如需詳細資訊，請參閱 調整事件的冷卻。

如果您的工作負載是事件驅動，熱門的開放原始碼選項是 KEDA。 如果您的工作負載是由事件來源所驅動，例如消息佇列，而不是 CPU 或記憶體系結，請考慮 KEDA。 KEDA 支援許多事件來源（或縮放程式）。 您可以在這裡找到支援的 KEDA 縮放程式清單，包括 Azure 監視器縮放器;這是根據 Azure 監視器計量調整 KEDA 工作負載的便利方式。

叢集自動調整程式

叢集自動調整程式 是 AKS 附加元件，可調整節點集區中的節點數目。 它應該會在叢集佈建期間新增。 針對每個使用者節點集區，您需要個別的叢集自動調整程式。

叢集自動調整程式是由 Kubernetes 排程器觸發。 當 Kubernetes 排程器因為資源限制而無法排程 Pod 時，自動調整程式會自動在節點集區中佈建新的節點。 相反地，叢集自動調整程式會檢查節點的未使用容量。 如果節點未以預期的容量執行，Pod 會移至另一個節點，並移除未使用的節點。

當您啟用自動調整程式時，請設定最大和最小節點計數。 建議的值取決於工作負載的效能預期、您希望叢集成長多少，以及成本影響。 最小數目是該節點集區的保留容量。 在此參考實作中，由於工作負載的簡單本質，最小值會設定為 2。

針對系統節點集區，建議的最小值為 3。

若要檢閱 AKS 基準參考架構上 Windows 容器中包含的調整考慮，請參閱 隨附文章。

商務持續性決策

若要維護商務持續性，請為基礎結構和您的應用程式定義服務等級協定。 如需每月運行時間計算的相關信息，請參閱 Azure Kubernetes Service （AKS） 的 SLA。

叢集節點

若要符合工作負載的最低可用性層級，需要節點集區中的多個節點。 如果節點關閉，相同叢集中節點集區中的另一個節點可以繼續執行應用程式。 為了可靠性，建議針對系統節點集區使用三個節點。 針對用戶節點集區，從不小於兩個節點開始。 如果您需要更高的可用性，請布建更多節點。

將應用程式放在個別的節點集區中，稱為用戶節點集區，以隔離您的應用程式與系統服務。 如此一來，Kubernetes 服務會在專用節點上執行，且不會與您的工作負載競爭。 建議使用標籤、標籤和污點來識別節點集區來排程您的工作負載，並確保系統節點集區受到 CriticalAddonsOnly [taint] （/azure/aks/use-system-pools#system-and-user-node-pools-pools） 的污染。

定期維護叢集，例如及時更新對於可靠性至關重要。 此外，建議透過探查監視Pod的健康情況。

Pod 可用性

確定 Pod 資源。 強烈建議部署指定Pod資源需求。 然後排程器可以適當地排程Pod。 如果無法排程 Pod，可靠性將會大幅淘汰。

設定 Pod 中斷預算。 此設定會決定部署中的複本在更新或升級事件期間可以關閉多少個複本。 如需詳細資訊，請參閱 Pod 中斷預算。

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

在工作負載命名空間上設定資源配額。 命名空間上的資源配額可確保Pod要求和限制在部署上正確設定。 如需詳細資訊，請參閱 強制執行資源配額。

設定 Pod 要求和限制。 設定這些限制可讓 Kubernetes 有效率地將 CPU 和 /或記憶體資源配置至 Pod，並在節點上具有較高的容器密度。 由於硬體使用率較佳，限制也可以提高可靠性，並降低成本。

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

您可以在部署指令清單中指定這些限制。 如需詳細資訊，請參閱 設定Pod要求和限制。

可用性區域和多區域支援

如果您的 SLA 需要較高的運行時間，請使用 可用性區域來防範中斷。 如果區域支援可用性區域，您可以使用它們。 然後，控制平面元件和節點集區中的節點都能夠分散到區域。 如果整個區域無法使用，該區域內另一個區域中的節點仍可供使用。 每個節點集區都會對應至個別的虛擬機擴展集，以管理節點實例和延展性。 擴展集作業和組態是由 AKS 服務所管理。 以下是啟用多重區域時的一些考慮：

• 整個基礎結構。 選擇支援可用性區域的區域。 如需詳細資訊，請參閱 限制和區域可用性。 如果您想要購買運行時間 SLA，請選擇支援該選項的區域。 使用可用性區域時，運行時間 SLA 會更大。

• 叢集。 只有在建立節點集區且稍後無法變更時，才能設定可用性區域。 所有區域都應該支持節點大小，以便可以進行預期的散發。 基礎虛擬機擴展集會跨區域提供相同的硬體組態。

  多重區域支持不僅適用於節點集區，也適用於控制平面。 AKS 控制平面將跨越所要求的區域，例如節點集區。 如果您未在叢集中使用區域支援，則不保證控制平面元件會分散到可用性區域。

• 相依資源。 如需完整的區域權益，所有服務相依性也必須支持區域。 如果相依服務不支援區域，則區域失敗可能會導致該服務失敗。

例如，受控磁碟可在布建所在的區域中使用。 如果失敗，節點可能會移至另一個區域，但受控磁碟不會隨著節點移至該區域。

為了簡單起見，此架構 AKS 會部署到跨越可用性區域 1、2 和 3 的節點集區的單一區域。 基礎結構的其他資源，例如 Azure 防火牆 和 應用程式閘道 也會部署至相同的區域，同時具有多重區域支援。 Azure Container Registry 已啟用異地複寫。

多個區域

如果整個區域關閉，啟用可用性區域就不夠。 若要具有較高的可用性，請在不同的區域中執行多個 AKS 叢集。

• 使用配對的區域。 請考慮使用設定為使用配對區域從區域失敗復原的 CI/CD 管線。 使用配對區域的優點是更新期間的可靠性。 Azure 可確保一次只更新配對中的一個區域。 某些 DevOps 工具，例如 Flux，可讓多區域部署更容易。

• 如果 Azure 資源支援異地備援，請提供備援服務將擁有其次要位置。 例如，啟用 Azure Container Registry 的異地複寫會自動將映像複寫至選取的 Azure 區域，而且即使區域發生中斷，仍會持續存取映射。

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

災害復原

如果主要區域中失敗，您應該能夠在另一個區域中快速建立新的實例。 以下是一些建議：

• 使用配對的區域。

• 非具狀態工作負載可以有效率地複寫。 如果您需要將狀態儲存在叢集中（不建議），請務必經常在配對區域中備份數據。

• 整合復原策略，例如復寫至另一個區域，作為 DevOps 管線的一部分，以符合您的服務等級目標（SLO）。

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

叢集備份

對於許多架構，布建新的叢集並將其傳回至作業狀態，可以透過以 GitOps 為基礎的 [Cluster bootstrapping}（#cluster-bootstrapping） 完成，然後接著應用程式部署。 不過，如果有重要的資源狀態，例如設定對應、作業，以及可能因為某些原因而無法擷取在啟動載入程式中的秘密，請考慮您的復原策略。 通常建議在 Kubernetes 中執行無狀態工作負載，但如果您的架構牽涉到磁碟型狀態，您也必須考慮該內容的復原策略。

當叢集備份需要成為復原策略的一部分時，您必須安裝符合叢集內業務需求的解決方案。 此代理程式將負責將叢集資源狀態推送至您選擇的目的地，以及協調以 Azure 磁碟為基礎的永續性磁碟區快照集。

VMware 的 Velero 是常見的 Kubernetes 備份解決方案範例，您可以直接安裝及管理。 或者， AKS 備份延伸模組 可用來提供受控 Velero 實作。 AKS 備份延伸模組支援備份 Kubernetes 資源和永續性磁碟區，並將排程和備份範圍外部化為 Azure 備份 中的保存庫組態。

參考實作不會實作備份，這牽涉到架構中額外的 Azure 資源來管理、監視、支付及保護;例如 Azure 儲存體 帳戶、Azure 備份 保存庫和組態，以及受信任的存取。 GitOps 與執行無狀態工作負載的意圖結合，是實作復原解決方案。

選擇並驗證符合您商務目標的解決方案，包括您定義的恢復點目標 （RPO） 和復原時間目標 （RTO）。 在小組 Runbook 中定義此復原程式，並針對所有業務關鍵性工作負載練習此復原程式。

Kubernetes API Server SLA

AKS 可作為免費服務，但該層級不提供財務支援的SLA。 若要取得該 SLA，您必須選擇 標準層。 我們建議所有生產叢集都使用標準層。 保留生產前叢集的免費層叢集。 與 Azure 可用性區域 結合時，Kubernetes API 伺服器 SLA 會增加到 99.95%。 您的節點集區和其他資源會涵蓋在自己的 SLA 之下。

權衡取捨

跨區域，特別是區域部署架構的成本對可用性取捨。 某些復寫功能，例如 Azure Container Registry 中的異地複寫，可在進階 SKU 中使用，因此成本更高。 成本也會增加，因為流量在區域和區域之間移動時所套用的頻寬費用。

此外，預期區域或區域之間的節點通訊會有額外的網路等待時間。 測量此架構決策對您的工作負載的影響。

使用模擬和強制故障轉移進行測試

透過模擬中斷，例如停止節點、在特定區域中關閉所有 AKS 資源來模擬區域性失敗，或叫用外部相依性失敗，以確保透過強制故障轉移測試的可靠性。 Azure Chaos Studio 也可以利用 來模擬 Azure 和叢集上各種類型的中斷。

如需詳細資訊，請參閱 Azure Chaos Studio。

監視和收集計量

Azure 監視器 容器深入解析 是監視容器工作負載效能的建議工具，因為您可以即時檢視事件。 它會從執行中的Pod擷取容器記錄，並匯總它們以供檢視。 它也會從計量 API 收集記憶體和 CPU 使用率的相關信息，以監視執行資源和工作負載的健康情況。 您也可以使用它來監視Pod調整的效能。 它包含遙測的收集，以監視、分析和視覺效果收集的數據，以識別趨勢，並設定警示以主動通知重大問題。

裝載在 Pod 中的大部分工作負載都會發出 Prometheus 計量。 容器深入解析能夠與 Prometheus 整合，以檢視從節點和 Kubernetes 收集的應用程式和工作負載計量。

如果您的組織已經使用這些解決方案，您可以利用與 Kubernetes 整合的一些第三方解決方案，例如 Datadog、Grafana 或 New Relic。

使用 AKS，Azure 會管理一些核心 Kubernetes 服務，以及 AKS 控制平面元件的記錄會實作為資源記錄在 Azure 中。 建議大多數叢集隨時啟用下列專案，因為它們可協助您針對叢集問題進行疑難解答，而且記錄密度相對較低：

• 登入 ClusterAutoscaler 以取得調整作業的可觀察性。 如需詳細資訊，請參閱 擷取叢集自動調整程式記錄和狀態。
• KubeControllerManager 可觀察 Kubernetes 與 Azure 控制平面之間的互動。
• KubeAudit 管理員 對修改叢集的活動具有可觀察性。 沒有理由同時啟用 KubeAudit 和 KubeAudit 管理員 兩者皆已啟用，因為 KubeAudit 是 KubeAudit 的超集 管理員 包含非修改（讀取）作業。
• Guard 會擷取 Microsoft Entra ID 和 Azure RBAC 稽核。

其他記錄類別，例如 KubeScheduler 或 KubeAudit，對於在早期叢集或工作負載生命週期開發期間啟用可能很有説明，其中新增叢集自動調整、Pod 放置和排程，以及類似的數據有助於針對叢集或工作負載作業的疑慮進行疑難解答。 一旦疑難解答需求結束，將擴充的疑難解答記錄保留為全職，可能會被視為在 Azure 監視器中內嵌和儲存不必要的成本。

雖然 Azure 監視器包含一組要開始使用的現有記錄查詢，但您也可以使用它們作為基礎來協助建置您自己的查詢。 隨著連結庫成長，您可以使用一或多個 查詢套件來儲存和重複使用記錄查詢。 您的自訂查詢連結庫可協助對 AKS 叢集的健康情況和效能啟用額外的可檢視性，並支援您的服務等級目標（SLO）。

如需 AKS 監視最佳做法的詳細資訊，請參閱 使用 Azure 監視器監視 Azure Kubernetes Service （AKS）。

若要檢閱 AKS 基準參考架構上 Windows 容器中包含的 Windows 特定監視考慮，請參閱 隨附文章。

啟用自我修復

藉由設定 Liveness 和 Readiness 探查來監視 Pod 的健康情況。 如果偵測到沒有回應的 Pod，Kubernetes 會重新啟動 Pod。 Liveness 探查會判斷 Pod 是否狀況良好。 如果它沒有回應，Kubernetes 將會重新啟動 Pod。 整備探查會判斷 Pod 是否已準備好接收要求/流量。

AKS 叢集更新

定義與商務需求一致的更新策略至關重要。 瞭解 AKS 叢集版本或其節點更新日期和時間的可預測性層級，以及所安裝特定映像或二進位檔所需的控制程度，是將描述 AKS 叢集更新藍圖的基本層面。 可預測性會系結至兩個主要 AKS 叢集更新屬性，這些屬性是更新頻率和維護時間範圍。 控制是手動或自動安裝更新。 具有非嚴格安全性法規之 AKS 叢集的組織可能會考慮每周或甚至每月更新，而其餘組織必須儘快更新安全性標籤修補程式（每日）。 將 AKS 叢集當作不可變基礎結構運作的組織不會更新它們。 這表示不會執行自動或手動更新。 相反地，當所需的更新變成可用的複本戳記時，才會部署複本戳記，而且只有在新的基礎結構實例就緒時，舊的實例才會清空，以提供最高層級的控制。

一旦判斷 AKS 叢集更新藍圖之後，即可輕鬆地對應至 AKS 節點和 AKS 叢集版本的可用更新選項：

• AKS 節點：

  1. 無/手動更新：這是針對不可變的基礎結構，或當手動更新是喜好設定時。 這可達到更高的層級可預測性，並控制 AKS 節點更新。
  2. 自動自動自動更新：AKS 執行原生 OS 更新。 這可藉由設定符合企業利益的維護時段來提供可預測性。 這可能是以尖峰時段和最佳作業為基礎。 控制層級很低，因為無法事先知道哪些項目會特別安裝在 AKS 節點內。
  3. 自動節點映像更新：建議在新的虛擬硬碟 （VHD） 可用時自動更新 AKS 節點映像。 設計盡可能符合業務需求的維護時段。 針對安全性標籤的 VHD 更新，建議設定每日維護期間，提供最低的可預測性。 一般 VHD 更新可以設定每周維護期間，每兩周甚至每月一次。 根據與排程維護期間結合的安全性標籤與一般 VHD 的需求而定，可預測性會變動提供更多或更少的彈性，以符合業務需求。 雖然離開這一點一律符合商務需求是理想的，但現實會要求組織找出臨界點。 控制層級很低，因為無法事先知道哪些特定二進位檔已包含在新的 VHD 中，而且這種自動更新仍然是建議的選項，因為映像在可供使用之前會經過審查。

  注意

  如需如何設定自動 AKS 節點更新的詳細資訊，請參閱 自動升級節點 OS 映射。

• AKS 叢集版本：

  1. 無/手動更新：這是針對不可變的基礎結構，或當手動更新是喜好設定時。 這可達到更高的層級可預測性，並控制 AKS 叢集版本更新。 建議您加入加入此選項，因為這會完全控制，讓您有機會在較低的環境中測試新的 AKS 叢集版本（即 1.14.x 到 1.15.x），再達到生產環境。
  2. 自動更新：不建議以任何方式自動修補或更新生產叢集（例如 1.16.x 到 1.16.y）到新的 AKS 叢集版本，而不需在較低環境中正確測試。 雖然 Kubernetes 上游版本和 AKS 叢集版本更新會協調提供一般頻率，但建議仍要防禦生產環境中的 AKS 叢集，以增加更新程式的可預測性和控制權。 針對較低環境的此設定視為卓越營運的一部分，讓主動式例行測試執行能夠儘早偵測潛在問題。

使用支援的 N-2 版本，讓 Kubernetes 版本保持最新 狀態。 升級至最新版本的 Kubernetes 非常重要，因為新版本經常發行。

如需詳細資訊，請參閱 定期更新至最新版的 Kubernetes 和 升級 Azure Kubernetes Service （AKS） 叢集。

叢集引發的事件通知，例如叢集的新 AKS 版本可用性，可透過適用於 Azure 事件方格 的 AKS 系統主題來達成。 參考實作會部署此事件方格系統主題，讓您可以從事件串流通知解決方案訂閱 Microsoft.ContainerService.NewKubernetesVersionAvailable 事件。

每周更新

AKS 提供具有最新 OS 和運行時間更新的新節點映像。 這些新映像不會自動套用。 您必須負責決定影像應該更新的頻率。 建議您每周升級節點集區基底映像的程式。 如需詳細資訊，請參閱 Azure Kubernetes Service （AKS） 節點映射升級AKS 版本資訊。

每日更新

在映射升級之間，AKS 節點會個別下載並安裝 OS 和運行時間修補程式。 安裝可能需要重新啟動節點 VM。 AKS 不會因為擱置的更新而重新啟動節點。 讓行程監視所套用更新的節點，這些更新需要重新啟動，並以受控制的方式執行這些節點的重新啟動。 開放原始碼選項為 Kured （Kubernetes 重新啟動精靈）。

讓節點映像與最新的每周版本保持同步，將這些偶爾重新啟動要求降到最低，同時維持增強的安全性狀態。 只依賴節點映像升級可確保 AKS 相容性和每周安全性修補。 雖然套用每日更新會更快速地修正安全性問題，但它們不一定已在 AKS 中進行測試。 可能的話，請使用節點映射升級作為主要每周安全性修補策略。

安全性監視

監視您的容器基礎結構，以取得作用中威脅和潛在的安全性風險：

• 啟用適用於容器的 Microsoft Defender，以識別並補救容器映像 適用於雲端的 Defender 建議。
• 適用於容器的 Microsoft Defender 會定期 掃描您的容器映射是否有弱點。
• 適用於容器的 Microsoft Defender 也會針對可疑活動產生即時安全性警示。
• 如需套用至 AKS 虛擬機主機的安全性強化相關信息，請參閱 主機 OS 中的安全性強化。

叢集和工作負載作業 （DevOps）

以下是一些考慮。 如需詳細資訊，請參閱 卓越營運 支柱。

叢集啟動載入

布建完成之後，您有一個工作叢集，但部署工作負載之前可能仍有需要步驟。 準備叢集的程式稱為啟動載入，而且可以包含動作，例如將必要條件映射部署到叢集節點、建立命名空間，以及滿足使用案例或組織需求的任何其他專案。

若要減少布建叢集與已正確設定的叢集之間的差距，叢集操作員應該考慮其獨特的啟動載入程序外觀，並事先準備相關資產。 例如，如果在部署應用程式工作負載之前在每個節點上執行 Kured 很重要，叢集操作員會想要在布建叢集之前，先確定包含目標 Kured 映像的 ACR 存在。

您可以使用下列其中一種方法來設定啟動載入程式：

• 使用 Flux 或 Argo CD 之類的自我設定
• 管線
• GitOps Flux v2 叢集擴充功能

針對 AKS 使用 GitOps Flux v2 叢集擴充功能的主要優點之一，在於布建的叢集與開機叢集之間實際上沒有差距。 其會將環境設定為未來穩固的管理基礎，也支援將啟動載入納入為資源範本，以符合您的 IaC 策略。

最後，使用擴充功能時， kubectl 啟動載入程式的任何部分都不需要，而且 kubectl使用型存取權可以保留給緊急中斷修復情況。 在 Azure 資源定義的範本和透過 GitOps 擴充功能啟動指令清單之間，可以執行所有一般設定活動，而不需要使用 kubectl。

隔離工作負載責任

將工作負載除以小組和資源類型，以個別管理每個部分。

從包含基本元件的基本工作負載開始，並加以建置。 初始工作是設定網路功能。 為這些網路內的中樞和輪輻和子網布建虛擬網路。 例如，輪輻有系統與用戶節點集區的個別子網，以及輸入資源。 中樞中 Azure 防火牆 的子網。

另一個部分是整合基本工作負載與 Microsoft Entra ID。

使用基礎結構即程式代碼 （IaC）

盡可能選擇命令式方法的等冪宣告式方法。 不使用撰寫指定組態選項的命令序列，而是使用描述資源及其屬性的宣告式語法。 其中一個選項是 Azure Resource Manager （ARM） 範本。 另一個是 Terraform。

請確定您根據控管原則布建資源。 例如，選取正確的 VM 大小時，請保留在成本限制、可用性區域選項內，以符合應用程式的需求。

如果您需要撰寫一連串的命令，請使用 Azure CLI。 這些命令涵蓋一系列 Azure 服務，並可透過腳本自動化。 Windows 和 Linux 上支援 Azure CLI。 另一個跨平台選項是 Azure PowerShell。 您的選擇將取決於慣用的技能集。

在您的原始檔控制系統中儲存和版本腳本和範本檔案。

工作負載 CI/CD

工作流程和部署的管線必須能夠持續建置和部署應用程式。 更新 必須安全地且快速地部署，並在發生問題時回復。

您的部署策略必須包含可靠且自動化的持續傳遞 （CD） 管線。 工作負載容器映像的變更應該會自動部署到叢集。

在此架構中，我們選擇了 GitHub Actions 來管理工作流程和部署。 其他熱門選項包括 Azure DevOps Services 和 Jenkins。

叢集 CI/CD

下載此架構的 Visio 檔案。

不使用 kubectl 之類的命令式方法，而是使用可自動同步處理叢集和存放庫變更的工具。 若要管理工作流程，例如新版本的發行，以及在部署到生產環境之前驗證該版本，請考慮 GitOps 流程。

CI/CD 流程的基本部分是新布建叢集的啟動載入。 GitOps 方法在此端很有用，可讓操作員以宣告方式定義啟動載入程式作為 IaC 策略的一部分，並自動查看叢集中反映的設定。

使用 GitOps 時，代理程式會部署在叢集中，以確保叢集的狀態會與儲存在私人 Git 存放庫中的組態協調。 其中一個這類代理程式是 flux，它會使用叢集中的一或多個運算符來觸發 Kubernetes 內的部署。 Flux 會執行下列工作：

• 監視所有已設定的存放庫。
• 偵測新的組態變更。
• 觸發部署。
• 更新 根據這些變更所需的執行組態。

您也可以設定原則，以控管這些變更的部署方式。

以下範例示範如何使用 GitOps 和 flux 將叢集設定自動化：

下載此架構的 Visio 檔案。

1. 開發人員會認可原始碼的變更，例如儲存在 Git 存放庫中的組態 YAML 檔案。 變更接著會推送至 Git 伺服器。

2. Flux 會與工作負載一起在 Pod 中執行。 Flux 具有 Git 存放庫的唯讀存取權，以確保 Flux 只會依照開發人員的要求套用變更。

3. Flux 會辨識組態中的變更，並使用 kubectl 命令套用這些變更。

4. 開發人員無法透過 kubectl 直接存取 Kubernetes API。

5. 在您的 Git 伺服器上擁有分支原則。 如此一來，多個開發人員就可以先透過提取要求核准變更，再套用至生產環境。

雖然可以手動設定 GitOps 和 Flux， 但 AKS 建議使用 Flux v2 叢集延伸模組 的 GitOps。

工作負載和叢集部署策略

將任何變更（架構元件、工作負載、叢集組態）部署到至少一個生產階段前 AKS 叢集。 這樣做會模擬變更可能會在部署至生產環境之前解開問題。

在每個階段執行測試/驗證，再繼續進行下一個階段，以確保您可以以高度控制的方式將更新推送至生產環境，並將非預期部署問題的中斷降到最低。 此部署應遵循與生產環境類似的模式，使用相同的 GitHub Actions 管線或 Flux 運算符。

進階部署技術，例如 藍綠部署、A/B 測試和 Canary 版本，將需要額外的程式及潛在的工具。 Flagger 是熱門的開放原始碼解決方案，可協助您解決進階部署案例。

成本管理

首先，請檢閱成本優化設計檢查清單，以及AKS架構架構中所述的建議清單。 使用 Azure 定價計算機來估計架構中使用的服務成本。 Microsoft Azure 架構良好架構中的成本優化一節會說明其他最佳做法。

請考慮針對 Kubernetes 特定建構的細微叢集基礎結構成本配置啟用 AKS 成本分析 。

若要檢閱 AKS 基準參考架構上 Windows 容器中包含的 Windows 工作負載專屬成本管理考慮，請參閱 隨附文章。

佈建

• Kubernetes 叢集的部署、管理和作業中沒有任何與 AKS 相關聯的成本。 影響成本的是叢集所耗用的虛擬機實例、記憶體、記錄數據和網路資源。 請考慮為系統節點集區選擇更便宜的 VM。 DS2_v2 SKU 是系統節點集區的典型 VM 類型。

• 針對開發/測試和生產環境，沒有相同的設定。 生產工作負載具有高可用性的額外需求，而且通常成本更高。 開發/測試環境中不需要此設定。

• 針對生產工作負載，新增運行時間 SLA。 不過，針對開發/測試或實驗性工作負載所設計的叢集會節省成本，而不需要保證可用性。 例如，SLO 就已足夠。 此外，如果您的工作負載支援它，請考慮使用執行 現成 VM 的專用現成節點集區。

  針對包含 Azure SQL 資料庫 或 Azure App 服務 的非生產工作負載，評估您是否有資格使用 Azure 開發/測試訂用帳戶來接收服務折扣。

• 與其從超大叢集開始以符合調整需求，而是布建節點數目下限的叢集，並讓叢集自動調整程式能夠監視和做出重設大小決策。

• 設定 Pod 要求和限制，以允許 Kubernetes 配置密度較高的節點資源，讓硬體能夠用於容量。

• 在叢集上啟用診斷可能會增加成本。

• 如果您的工作負載預期存在很長一段時間，您可以認可一年或三年的保留虛擬機實例，以降低節點成本。 如需詳細資訊，請參閱 保留的 VM。

• 當您建立節點集區時，請使用標籤。 標記有助於建立自定義報表來追蹤產生的成本。 標記可讓您追蹤總費用，並將任何成本對應至特定資源或小組。 此外，如果叢集在小組之間共用，請針對每位取用者建置退款報告，以識別共用雲端服務的計量付費成本。 如需詳細資訊，請參閱 指定節點集區的污點、標籤或標籤。

• 區域可用性區域之間的數據傳輸並非免費。 如果您的工作負載是多個區域，或可用性區域之間有傳輸，則預期需要額外的頻寬成本。 如需詳細資訊，請參閱 跨計費區域和區域的流量。

• 建立預算，以保留在組織所識別的成本限制內。 其中一種方式是透過 Azure 成本管理建立預算。 您也可以建立警示，以在超過特定閾值時取得通知。 如需詳細資訊，請參閱 使用範本建立預算。

監視器

為了監視整個叢集的成本，以及計算成本，也會收集記憶體、頻寬、防火牆和記錄的成本資訊。 Azure 提供各種儀錶板來監視和分析成本：

• Azure Advisor

• Azure 成本管理

在理想情況下，在計算成本之前，實時監視成本，或至少要定期採取動作。 同時監視一段時間的每月趨勢，以留在預算中。

若要做出數據驅動決策，請找出哪些資源（細微層級）會產生大部分成本。 此外，也對用來計算每個資源使用量的計量有很好的瞭解。 藉由分析計量，您可以判斷平臺是否因實例大小過大。 您可以在 Azure 監視器計量中看到使用量計量。

最佳化

根據 Azure Advisor 所提供的建議採取行動。 還有其他方式可以優化：

• 啟用叢集自動調整程式，以偵測和移除節點集區中使用量過低的節點。

• 如果您的工作負載支援節點集區，請選擇較低的SKU。

• 如果應用程式不需要高載調整，請考慮藉由分析一段時間的效能計量，將叢集大小調整為正確的大小。

• 如果您的工作負載支援， 請在沒有預期用戶節點集區執行時，將用戶節點集區調整為0個節點 。 此外，如果叢集中沒有排程要執行的工作負載，請考慮使用 AKS 啟動/停止功能 來關閉所有計算，其中包括您的系統節點集區和 AKS 控制平面。

如需其他成本相關信息，請參閱 AKS 定價。

下一步

繼續瞭解 AKS 基準架構：

• 若要瞭解如何在 AKS 基準上裝載微服務，請參閱 進階 Azure Kubernetes Service （AKS） 微服務架構。
• 如需跨多個區域部署 AKS 基準，請參閱 多區域叢集的 AKS 基準。
• 如需將 AKS 基準部署到 PCI-DSS 3.2.1 環境，請參閱 PCI-DSS 3.2.1 的 AKS 管制叢集。
• 若要瞭解將 Windows 容器新增至參考架構的考慮，請參閱隨附文章： AKS 基準參考架構上的 Windows 容器

深入了解 AKS

• 檢閱 AKS 產品藍圖，請參閱 GitHub 上的 Azure Kubernetes Service 藍圖。
• 如果您需要 Kubernetes 上的重新整理程式，請完成 Kubernetes 的簡介，並在 Kubernetes 學習路徑上開發及部署應用程式。

相關資源

請參閱下列相關指南：

• 適用於 Azure Kubernetes Service 的 Azure 架構架構檢閱 （AKS）
• AKS 登陸區域加速器，這是以這個架構為基礎的企業級實作。 此加速器可協助您使用 Azure Kubernetes Service （AKS） 部署的基礎結構即程式代碼 （IaC） 以一致且重複的方式設定 Azure 環境。
• Azure Kubernetes Services （AKS） 第 2 天作業指南

請參閱下列相關架構：

• Azure Kubernetes Service 上的微服務架構
• 使用 Azure 防火牆 來協助保護 Azure Kubernetes Service （AKS） 叢集
• 適用於 Azure Kubernetes Service 的 GitOps
• 使用 AKS 進行數據流處理