Azure Kubernetes Service 上的微服務架構

此參考架構會顯示部署至 Azure Kubernetes Service （AKS） 的微服務應用程式。 它描述基本 AKS 組態，可以是大部分部署的起點。 本文假設 Kubernetes 的基本知識。 本文主要著重於在 AKS 上執行微服務架構的基礎結構和 DevOps 考慮。 如需如何設計微服務的指引，請參閱 在 Azure 上建置微服務。

GitHub 提供此架構的參考實作。

架構

下載此架構的 Visio 檔案。

如果您想要查看以 AKS 基準架構為基礎的更進階微服務範例，請參閱進階 Azure Kubernetes Service （AKS） 微服務架構

工作流程

此結構由下列元件組成。

Azure Kubernetes Service (AKS)。 AKS 是 Azure 雲端中裝載的受控 Kubernetes 叢集。 Azure 會管理 Kubernetes API 服務，而您只需要管理代理程式節點。

虛擬網路。 根據預設，AKS 會建立用來連線代理程式節點的虛擬網路。 您可以先為更進階的案例建立虛擬網路，以控制子網路設定、內部部署連線和 IP 位址等內容。 如需詳細資訊，請參閱在 Azure Kubernetes Service 中設定進階網路功能（AKS）。

輸入。 輸入ㄏ會將 HTTP(S) 路由公開至叢集內的服務。 如需詳細資訊，請參閱下面的 API 閘道一節。

Azure Load Balancer。 建立 AKS 叢集之後，叢集即可使用負載平衡器。 然後，部署 NGINX 服務之後，負載平衡器將會使用新的公用 IP 來設定，以前端輸入控制器。 如此一來，負載平衡器會將網際網路流量路由傳送至輸入伺服器。

外部資料存放區。 微服務通常是無狀態，且會將狀態寫入外部資料存放區，例如 Azure SQL Database 或 Azure Cosmos DB。

Microsoft Entra ID。 AKS 會使用 Microsoft Entra 身分識別來建立和管理其他 Azure 資源，例如 Azure 負載平衡器。 Microsoft用戶端應用程式中也建議使用 Entra 識別碼進行用戶驗證。

Azure Container Registry。 使用 Container Registry 來儲存部署至叢集的私人 Docker 映射。 AKS 可以使用其Microsoft Entra 身分識別向 Container Registry 進行驗證。 AKS 不需要 Azure Container Registry。 您可以使用其他容器登錄，例如 Docker Hub。 請確定您的容器登錄符合或超過工作負載的服務等級協定 （SLA）。

Azure Pipelines。 Azure Pipelines 是 Azure DevOps Services 的一部分，並執行自動化組建、測試和部署。 您也可以使用第三方 CI/CD 解決方案，例如 Jenkins。

赫爾姆 Helm 是 Kubernetes 的套件管理員，可將 Kubernetes 對象組合並一般化成單一單位，可發佈、部署、版本設定和更新。

Azure 監視器。 Azure 監視器會收集並儲存 Azure 服務的計量和記錄、應用程式遙測資料和平台計量。 使用此資料來監視應用程式、設定警示、儀表板，以及執行失敗的根本原因分析。 Azure 監視器會與 AKS 整合，以從控制器、節點和容器收集計量。

考量

設計

此參考架構著重於微服務架構，雖然許多建議的做法適用於AKS上執行的其他工作負載。

微服務

微服務是鬆散結合、獨立部署的程式代碼單位。 微服務通常會透過定義完善的 API 進行通訊，而且可透過某種形式的服務探索來探索。 即使 Pod 四處移動，服務也應該一律可連線。 Kubernetes Service 物件是在 Kubernetes 中建立微服務模型的自然方式。

API 閘道

API 閘道是一般 微服務設計模式。 API 閘道位於外部用戶端與微服務之間。 其可作為反向 Proxy，將要求從用戶端路由傳送至微服務。 它也可以執行各種跨領域工作，例如驗證、SSL 終止和速率限制。 如需詳細資訊，請參閱

• 在微服務中使用 API 閘道
• 選擇閘道技術

在 Kubernetes 中，API 閘道的功能主要是由 輸入控制器處理。 輸入一節會說明考慮事項。

資料存放區

在微服務架構中，服務不應該共用數據儲存解決方案。 每個服務都應該管理自己的數據集，以避免服務之間的隱藏相依性。 數據區隔有助於避免服務之間的非預期結合，當服務共用相同的基礎數據架構時，可能會發生這種情況。 此外，當服務管理自己的數據存放區時，他們可以使用正確的數據存放區來符合其特定需求。

如需詳細資訊，請參閱 設計微服務：數據考慮。

避免將持續性數據儲存在本機叢集記憶體中，因為這會將數據系結至節點。 請改用外部服務，例如 Azure SQL 資料庫 或 Azure Cosmos DB。 另一個選項是使用 Azure 磁碟或 Azure 檔案儲存體，將永續性數據磁碟區掛接至解決方案。

如需詳細資訊，請參閱 Azure Kubernetes Service 中應用程式的記憶體選項。

服務物件

Kubernetes Service 物件提供一組功能，符合服務可探索性的微服務需求：

• IP 位址。 Service 物件會為一組 Pod （ReplicaSet） 提供靜態的內部 IP 位址。 建立或移動Pod時，服務一律可在此內部IP位址連線。

• 負載平衡。 傳送至服務IP位址的流量會負載平衡至Pod。

• 服務探索。 服務會由 Kubernetes DNS 服務指派內部 DNS 專案。 這表示 API 閘道可以使用 DNS 名稱呼叫後端服務。 相同的機制可用於服務對服務通訊。 DNS 專案會依命名空間組織，因此如果您的命名空間對應至限定內容，則服務的 DNS 名稱自然會對應至應用程式域。

下圖顯示服務與 Pod 之間的概念關聯性。 與端點 IP 位址和埠的實際對應是由 Kubernetes 網路 Proxy kube-proxy 所完成。

輸入

在 Kubernetes 中 ，輸入控制器 可能會實作 API 閘道模式。 在此情況下，輸入和輸入控制器會搭配使用以提供這些功能：

• 將用戶端要求路由傳送至正確的後端服務。 此路由會為用戶端提供單一端點，並協助將客戶端與服務分離。

• 將多個要求匯總成單一要求，以減少用戶端與後端之間的聊天。

• 從後端服務卸除功能，例如 SSL 終止、驗證、IP 限制或用戶端速率限制（節流）。

輸入會抽象化 Proxy 伺服器的組態設定。 您也需要輸入控制器，其提供輸入的基礎實作。 Nginx、HAProxy、Traefik 和 Azure 應用程式閘道 等都有輸入控制器。

輸入資源可以透過不同的技術來完成。 若要一起運作，必須將它們部署為叢集內的輸入控制器。 它會以邊緣路由器或反向 Proxy 的形式運作。 反向 Proxy 伺服器是潛在的瓶頸或單一失敗點，因此請一律部署至少兩個複本以提供高可用性。

通常，設定 Proxy 伺服器需要複雜的檔案，如果您不是專家，可能很難微調。 因此，輸入控制器提供了很好的抽象概念。 輸入控制器也可以存取 Kubernetes API，因此它可以針對路由和負載平衡做出智慧型手機決策。 例如，Nginx 輸入控制器會略過 kube-proxy 網路 Proxy。

另一方面，如果您需要完全控制設定，您可能想要略過此抽象概念，並手動設定 Proxy 伺服器。 如需詳細資訊，請參閱 將 Nginx 或 HAProxy 部署至 Kubernetes。

如需 Azure 中負載平衡服務的相關信息，請參閱 Azure 中的負載平衡選項概觀。

TLS/SSL 加密

在常見的實作中，輸入控制器會用於 SSL 終止。 因此，在部署輸入控制器時，您必須建立 TLS 憑證。 僅針對開發/測試目的使用自我簽署憑證。 如需詳細資訊，請參閱 在 Azure Kubernetes Service （AKS） 上建立 HTTPS 輸入控制器並使用您自己的 TLS 憑證。

針對生產工作負載，請從受信任的證書頒發機構單位取得已簽署的憑證（CA）。 如需產生和設定 Let's Encrypt 憑證的相關信息，請參閱 在 Azure Kubernetes Service （AKS） 中使用靜態公用 IP 位址建立輸入控制器。

您可能也需要根據組織的原則輪替憑證。 如需詳細資訊，請參閱在 Azure Kubernetes Service 中輪替憑證（AKS）。

命名空間

使用命名空間來組織叢集中的服務。 Kubernetes 叢集中的每個物件都屬於命名空間。 根據預設，當您建立新的物件時，它會進入 default 命名空間。 但最好建立更具描述性的命名空間，以協助組織叢集中的資源。

首先，命名空間有助於防止命名衝突。 當多個小組將微服務部署到相同的叢集中時，如果微服務全都進入相同的命名空間，則很難管理微服務。 此外，命名空間可讓您：

• 將資源條件約束套用至命名空間，讓指派給該命名空間的 Pod 總數不能超過命名空間的資源配額。

• 在命名空間層級套用原則，包括 RBAC 和安全策略。

針對微服務架構，請考慮將微服務組織成限定內容，以及為每個限定內容建立命名空間。 例如，與「訂單履行」限定內容相關的所有微服務都可以進入相同的命名空間。 或者，為每個開發小組建立命名空間。

將公用程式服務放入自己的個別命名空間。 例如，您可以部署 Elasticsearch 或 Prometheus 以進行叢集監視，或 Helm 的 Tiller。

健康情況探查

Kubernetes 會定義 Pod 可以公開的兩種健康情況探查類型：

• 整備探查：告知 Kubernetes Pod 是否準備好接受要求。

• Liveness 探查：告知 Kubernetes 是否應該移除 Pod 並啟動新的實例。

在考慮探查時，重新叫用 Kubernetes 中的服務運作方式會很有用。 服務具有符合一組 （零或多個） Pod 的標籤選取器。 Kubernetes 會將流量平衡到符合選取器之 Pod 的流量。 只有成功啟動且狀況良好的 Pod 才會接收流量。 如果容器當機，Kubernetes 會終止 Pod 並排程取代。

有時候，即使 Pod 已順利啟動，Pod 可能尚未準備好接收流量。 例如，可能有初始化工作，其中在容器中執行的應用程式會將專案載入記憶體或讀取組態數據。 若要指出Pod狀況良好，但尚未準備好接收流量，請定義整備探查。

Liveness 探查會處理 Pod 仍在執行，但狀況不良且應該回收的情況。 例如，假設容器正在提供 HTTP 要求，但因為某些原因而停止回應。 容器不會當機，但已停止處理任何要求。 如果您定義 HTTP 活躍度探查，探查將會停止回應，並通知 Kubernetes 重新啟動 Pod。

以下是設計探查時的一些考慮：

• 如果您的程式代碼有很長的啟動時間，則啟動完成之前，活躍度探查會報告失敗的危險。 若要防止此探查失敗，請使用 initialDelaySeconds 設定，這會延遲探查啟動。

• 除非重新啟動Pod，否則活躍度探查無法協助將它還原為狀況良好的狀態。 您可以使用即時性探查來減輕記憶體流失或非預期的死結，但重新啟動 Pod 時沒有意義，而該 Pod 會立即再次失敗。

• 有時候會使用整備探查來檢查相依服務。 例如，如果 Pod 相依於資料庫，探查可能會檢查資料庫連線。 不過，此方法可能會造成非預期的問題。 基於某些原因，外部服務可能會暫時無法使用。 這會導致服務中所有 Pod 的整備探查失敗，導致所有 Pod 從負載平衡中移除，進而在上游建立串聯失敗。 更好的方法是在服務內實作重試處理，讓您的服務能夠從暫時性失敗中正確復原。

資源限制

資源爭用可能會影響服務的可用性。 定義容器的資源條件約束，讓單一容器無法壓倒叢集資源（記憶體和 CPU）。 針對非容器資源，例如線程或網路連線，請考慮使用 大量模式 來隔離資源。

使用資源配額來限制命名空間所允許的資源總數。 如此一來，前端就無法耗盡資源的後端服務，反之亦然。

安全性

角色型存取控制 (RBAC)

Kubernetes 和 Azure 都有角色型存取控制的機制（RBAC）：

• Azure RBAC 可控制對 Azure 中資源的存取，包括建立新 Azure 資源的能力。 許可權可以指派給使用者、群組或服務主體。 （服務主體是應用程式所使用的安全性身分識別。

• Kubernetes RBAC 控制 Kubernetes API 的許可權。 例如，建立 Pod 和列出 Pod 是可透過 Kubernetes RBAC 授權或拒絕用戶的動作。 若要將 Kubernetes 許可權指派給使用者，您可以建立 角色 和 角色系結：

  • 角色是在命名空間內套用的一組許可權。 許可權定義為資源上的動詞命令（get、update、create、delete）（Pod、部署等等）。

  • RoleBinding 會將使用者或群組指派給角色。

  • 另外還有 ClusterRole 物件，就像角色一樣，但適用於所有命名空間的整個叢集。 若要將使用者或群組指派給 ClusterRole，請建立 ClusterRoleBinding。

AKS 會整合這兩個 RBAC 機制。 當您建立 AKS 叢集時，您可以將它設定為使用 Microsoft Entra ID 進行使用者驗證。 如需如何設定此設定的詳細資訊，請參閱 整合 Microsoft Entra ID 與 Azure Kubernetes Service。

設定之後，想要存取 Kubernetes API 的使用者（例如透過 kubectl）必須使用其Microsoft Entra 認證登入。

根據預設，Microsoft Entra 用戶無法存取叢集。 為了授與存取權，叢集管理員會建立 RoleBindings，以參考Microsoft Entra 使用者或群組。 如果用戶沒有特定作業的許可權，它將會失敗。

如果使用者預設沒有存取權，叢集管理員如何擁有第一個位置建立角色系結的許可權？ AKS 叢集實際上有兩種類型的認證，可呼叫 Kubernetes API 伺服器：叢集使用者和叢集管理員。叢集管理員認證會授與叢集的完整存取權。 Azure CLI 命令 az aks get-credentials --admin 會下載叢集管理員認證，並將其儲存到 kubeconfig 檔案中。 叢集管理員可以使用此 kubeconfig 來建立角色和角色系結。

與其在 Kubernetes 中原生管理 Kubernetes 叢集角色和 RoleBinding 物件，而是偏好使用 適用於 Kubernetes 授權的 Azure RBAC。 這可讓您跨 Azure 資源、AKS 和 Kubernetes 資源進行統一管理和訪問控制。 這些 Azure RBAC 角色指派可以鎖定叢集中的叢集或命名空間，以取得更精細的訪問控制。 Azure RBAC 支援一組有限的默認許可權，而且您可以將它與管理 Role 和 RoleBindings 的原生 Kubernetes 機制結合，以支援進階或更細微的存取模式。 啟用時，Microsoft Entra 主體將由 Azure RBAC 獨佔驗證，而 Kubernetes RBAC 會以獨佔方式驗證一般 Kubernetes 使用者和服務帳戶。

因為叢集管理員認證非常強大，所以請使用 Azure RBAC 來限制其存取：

• 「Azure Kubernetes Service 叢集管理員角色」具有下載叢集管理員認證的許可權。 只有叢集管理員應指派給此角色。

• 「Azure Kubernetes Service 叢集使用者角色」有權下載叢集用戶認證。 非系統管理員使用者可以指派給此角色。 此角色不會授與叢集內 Kubernetes 資源的任何特定許可權， 它只允許使用者連線到 API 伺服器。

當您定義 RBAC 原則 （Kubernetes 和 Azure）時，請考慮您組織中的角色：

• 誰可以建立或刪除 AKS 叢集並下載管理員認證？
• 誰可以管理叢集？
• 誰可以在命名空間內建立或更新資源？

最好是使用 Roles 和 RoleBindings，而不是 ClusterRoles 和 ClusterRoleBindings 依命名空間來設定 Kubernetes RBAC 許可權的範圍。

最後，有一個問題是 AKS 叢集必須建立和管理 Azure 資源的許可權，例如負載平衡器、網路或記憶體。 若要使用 Azure API 自行驗證，叢集會使用 Microsoft Entra 服務主體。 如果您在建立叢集時未指定服務主體，則會自動建立一個服務主體。 不過，先建立服務主體併為其指派最小 RBAC 許可權是很好的安全性做法。 如需詳細資訊，請參閱 使用 Azure Kubernetes Service 的服務主體。

秘密管理和應用程式認證

應用程式和服務通常需要認證，讓它們能夠連線到外部服務，例如 Azure 儲存體 或 SQL 資料庫。 挑戰在於確保這些認證安全，而不會洩漏認證。

針對 Azure 資源，其中一個選項是使用受控識別。 受控識別的概念是應用程式或服務具有儲存在 Microsoft Entra ID 中的身分識別，並使用此身分識別向 Azure 服務進行驗證。 應用程式或服務在 Microsoft Entra 識別符中建立服務主體，並使用 OAuth 2.0 令牌進行驗證。 執行中的進程程式代碼可以透明地取得要使用的令牌。 如此一來，您就不需要儲存任何密碼或 連接字串。 您可以使用 Microsoft Entra 工作負載 ID （預覽） 將Microsoft Entra 身分識別指派給個別 Pod，以在 AKS 中使用受控識別。

目前，並非所有 Azure 服務都支援使用受控識別進行驗證。 如需清單，請參閱 支援 Microsoft Entra 驗證的 Azure 服務。

即使使用受控識別，您可能也需要儲存某些認證或其他應用程式秘密，無論是針對不支援受控識別的 Azure 服務、第三方服務、API 密鑰等等。 以下是一些安全地儲存秘密的選項：

• Azure Key Vault。 在 AKS 中，您可以將一或多個秘密從 金鑰保存庫 掛接為磁碟區。 磁碟區會從 金鑰保存庫 讀取秘密。 然後Pod可以像一般磁碟區一樣讀取秘密。 如需詳細資訊，請參閱在 AKS 叢集中使用 Azure 金鑰保存庫 Provider for Secrets Store CSI Driver。

  Pod 會使用工作負載身分識別或使用使用者或系統指派的受控識別來驗證自己。 如需詳細資訊，請參閱提供身分識別以存取 Azure 金鑰保存庫 Provider for Secrets Store CSI Driver。

• HashiCorp Vault。 Kubernetes 應用程式可以使用 Microsoft Entra 受控識別向 HashiCorp Vault 進行驗證。 請參閱 HashiCorp Vault Microsoft Entra ID。 您可以將保存庫本身部署到 Kubernetes，請考慮在與應用程式叢集不同的專用叢集中執行。

• Kubernetes 秘密。 另一個選項只是使用 Kubernetes 秘密。 此選項是最簡單的設定選項，但有一些挑戰。 秘密會儲存在etcd中，這是分散式索引鍵/值存放區。 AKS 會在待用時加密 etcd。 Microsoft管理加密金鑰。

使用 HashiCorp Vault 或 Azure 金鑰保存庫 等系統可提供數個優點，例如：

• 集中控制秘密。
• 確保所有秘密都會在待用時加密。
• 集中式金鑰管理。
• 秘密的訪問控制。
• 稽核

容器和 Orchestrator 安全性

以下是保護 Pod 和容器的建議做法：

• 威脅監視： 使用 適用於容器 的Defender Microsoft監視威脅（或第三方功能）。 如果您要在 VM 上裝載容器，請使用 適用於伺服器的 Microsoft Defender 或第三方功能。 此外，您可以從 Azure 監視器中的容器監視解決方案將記錄整合至 Microsoft Sentinel 或現有的 SIEM 解決方案。

• 弱點監視：使用 Azure Marketplace 提供的 適用於雲端的 Microsoft Defender 或第三方解決方案，持續監視映射和執行容器的已知弱點。

• 使用 ACR 工作將映像修補自動化，這是 Azure Container Registry 的功能。 容器映像是從圖層建置而來。 基底層包括 OS 映像和應用程式架構映像，例如 ASP.NET Core 或 Node.js。 基底映像通常是從應用程式開發人員上游建立，並由其他專案維護者維護。 當這些映像在上游修補時，請務必更新、測試及重新部署您自己的映像，讓您不會留下任何已知的安全性弱點。 ACR 工作可協助將此程式自動化。

• 將映像儲存在受信任的私人登錄 中，例如 Azure Container Registry 或 Docker Trusted Registry。 使用 Kubernetes 中的驗證許可 Webhook，以確保 Pod 只能從信任的登錄提取映像。

• 套用最低許可權 原則

  • 請勿以特殊許可權模式執行容器。 特殊許可權模式可讓容器存取主機上的所有裝置。
  • 可能的話，請避免在容器內以根目錄的形式執行進程。 容器不會從安全性觀點提供完全隔離，因此最好以非特殊許可權使用者身分執行容器進程。

DevOps

此參考架構提供 Azure Resource Manager 範本 來布建雲端資源及其相依性。 使用 [Azure Resource Manager 範本][arm-template] 時，您可以使用 Azure DevOps Services 在幾分鐘內布建不同的環境，例如復寫生產案例。 這可讓您只在需要時節省成本並布建負載測試環境。

請考慮遵循工作負載隔離準則來建構 ARM 範本，工作負載通常會定義為任意功能單位;例如，您可以針對叢集有個別的範本，然後針對相依服務使用其他範本。 工作負載隔離可讓 DevOps 執行持續整合和持續傳遞 （CI/CD），因為每個工作負載都會由其對應的 DevOps 小組相關聯及管理。

部署 （CI/CD） 考慮

以下是微服務架構強固 CI/CD 程式的一些目標：

• 每個小組都可以獨立建置及部署其擁有的服務，而不會影響或中斷其他小組。
• 將新版本的服務部署到生產環境之前，它會部署到開發/測試/QA 環境以進行驗證。 每個階段都會強制執行質量大門。
• 新版本的服務可以與舊版並存部署。
• 已備妥足夠的訪問控制原則。
• 針對容器化工作負載，您可以信任部署到生產環境的容器映像。

若要深入了解挑戰，請參閱 微服務架構的 CI/CD。

如需特定建議和最佳做法，請參閱 Kubernetes 上微服務的 CI/CD。

成本最佳化

使用 Azure 定價計算機來預估成本。 Microsoft Azure Well-Architected Framework 中的「成本」一節會說明其他考量。

以下是此架構中所使用之一些服務的一些考慮點。

Azure Kubernetes Service (AKS)

在 Kubernetes 叢集的部署、管理和作業中，AKS 沒有任何相關成本。 您只需為 Kubernetes 叢集使用的虛擬機器執行個體、存放裝置與網路資源付費。

若要預估所需資源的費用，請參閱 Container Services 計算機。

Azure 負載平衡器

您只需支付已設定的負載平衡和輸出規則數目。 輸入 NAT 規則是免費的。 未設定任何規則時，標準 Load Balancer 不會每小時收費。

如需詳細資訊，請參閱 Azure Load Balancer 定價。

Azure Pipelines

此參考架構只會使用 Azure Pipelines。 Azure 會以個別服務的形式提供 Azure Pipeline。 您每月可以有 1,800 分鐘的 CI/CD 免費Microsoft裝載工作，以及一個每月無限制的自我裝載工作，額外的作業會收取費用。 如需詳細資訊， 請參閱 Azure DevOps Services 定價。

Azure 監視器

針對 Azure 監視器 Log Analytics，您需支付數據擷取和保留費用。 如需詳細資訊，請參閱 Azure 監視器定價。

部署此案例

若要部署此架構的 參考實作，請遵循 GitHub 存放庫中的步驟。

下一步

• 使用 Azure Kubernetes Service 的服務主體
• 適用於容器的 Microsoft Defender (部分機器翻譯)
• 適用於伺服器的 Microsoft Defender
• Azure 監視器中的容器監視解決方案
• Microsoft Sentinel 或現有的 SIEM 解決方案。
• 適用於雲端的 Microsoft Defender 或第三方解決方案可透過 Azure Marketplace 取得。
• ACR 工作

相關資源

• 若要完成更進階的微服務範例，請參閱 進階 Azure Kubernetes Service （AKS） 微服務架構
• 若要瞭解如何監視此架構，請參閱在 Azure Kubernetes Service 中監視微服務架構（AKS）。
• 若要瞭解如何測量此應用程式的效能，請參閱 效能微調案例：分散式商務交易。
• 微服務架構的 CI/CD
• Kubernetes 上微服務的 CI/CD