此參考架構會顯示部署至 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。
Azure Active Directory。 AKS 會使用 Azure Active Directory (Azure AD) 身分識別來建立及管理其他 Azure 資源，例如 Azure 負載平衡器。 也建議您將 Azure AD 用於用戶端應用程式中的使用者驗證。
Azure Container Registry。 您可以使用 Container Registry 來儲存部署到叢集的私人 Docker 映像。 AKS 可以使用其 Azure AD 身分識別向 Container Registry 進行驗證。 AKS 不需要Azure Container Registry。 您可以使用其他容器登錄，例如 Docker Hub。 請確定您的容器登錄符合或超過工作負載的服務等級協定 (SLA) 。
Azure Pipelines。 Azure Pipelines 是Azure DevOps Services和執行自動化組建、測試和部署的一部分。 您也可以使用 Jenkins 等第三方 CI/CD 解決方案。
Helm。 Helm 是 Kubernetes 的套件管理員，可將 Kubernetes 物件組合並一般化成單一單位，可發佈、部署、版本設定和更新。
Azure 監視器。 Azure 監視器會收集及儲存 Azure 服務的計量和記錄、應用程式遙測和平臺計量。 您可以使用此資料來監視應用程式、設定警示和儀表板，以及對失敗執行根本原因分析。 Azure 監視器會與 AKS 整合，以從控制器、節點和容器收集計量。
考量
設計
此參考架構著重于微服務架構，雖然許多建議的做法適用于 AKS 上執行的其他工作負載。
微服務
微服務是鬆散耦合且可獨立部署的程式碼單元。 微服務通常會透過定義完善的 API 進行通訊，並可透過某種形式的服務探索來探索。 即使 Pod 四處移動，服務也應該一律可連線。 Kubernetes Service 物件是在 Kubernetes 中建立微服務模型的自然方式。
API 閘道
API 閘道是一般的微服務設計模式。 API 閘道位於外部用戶端與微服務之間。 它會作為反向 Proxy，將要求從用戶端路由傳送到微服務。 它也可以執行各種跨領域工作，例如驗證、SSL 終止和速率限制。 如需詳細資訊，請參閱
在 Kubernetes 中，API 閘道的功能主要是由 輸入控制器處理。 輸入 一節會 說明這些考慮。
資料儲存體
在微服務架構中，服務不應該共用資料儲存體解決方案。 每個服務都應該管理自己的資料集，以避免服務之間的隱藏相依性。 資料分隔有助於避免服務之間不小心結合，當服務共用相同的基礎資料架構時，可能會發生這種情況。 此外，若服務能管理自己的資料存放區，即可針對服務的特定需求來使用正確的資料存放區。
如需詳細資訊，請參閱 設計微服務：資料考慮。
避免將持續性資料儲存在本機叢集儲存體中，因為這會將資料系結至節點。 請改用外部服務，例如 Azure SQL Database 或 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 位址和連接埠的實際對應會由 kube-proxy (Kubernetes 網路 Proxy) 來完成。
輸入
在 Kubernetes 中， 輸入控制器 可能會實作 API 閘道模式。 在此情況下， 輸入 和 輸入控制器 會搭配運作以提供這些功能：
將用戶端要求路由傳送至正確的後端服務。 此路由會為用戶端提供單一端點，並協助將用戶端與服務分離。
將多個要求匯總成單一要求，以減少用戶端與後端之間的交談。
從後端服務卸載功能，例如 SSL 終止、驗證、IP 限制或用戶端速率限制 (節流) 。
輸入會擷取 Proxy 伺服器的組態設定。 您也需要輸入控制器，以提供輸入的基礎實作。 Nginx、HAProxy、Traefik 和 Azure 應用程式閘道 還有輸入控制器。
輸入資源可以透過不同的技術來完成。 若要共同作業，必須將它們部署為叢集內的輸入控制器。 它會以邊緣路由器或反向 Proxy 的形式運作。 反向 Proxy 伺服器是潛在瓶頸或單一失敗點，因此請一律部署至少兩個複本以獲得高可用性。
通常，設定 Proxy 伺服器需要複雜的檔案，如果您不是專家，可能難以調整。 因此，輸入控制器提供良好的抽象概念。 輸入控制器也可以存取 Kubernetes API，因此它可以做出關於路由和負載平衡的智慧決策。 例如，Nginx 輸入控制器會略過 kube-proxy 網路 Proxy。
相反地，如果您需要完全掌控設定，您可以略過此抽象功能，然後手動設定 Proxy 伺服器。 如需詳細資訊，請參閱 將 Nginx 或 HAProxy 部署至 Kubernetes。
注意
針對 AKS，您也可以使用 Azure 應用程式閘道，使用應用程式閘道 輸入控制器 (AGIC) 。 Azure 應用程式閘道可以執行第 7 層路由和 SSL 終止。 它也有 Web 應用程式防火牆的內建支援， (WAF) 。 如果您的 AKS 叢集使用CNI 網路，應用程式閘道可以部署到叢集虛擬網路的子網，也可以從 AKS 虛擬網路部署在不同的虛擬網路中，不過，這兩個虛擬網路必須對等互連。 AGIC 也支援 Kubenet 網路外掛程式。 使用 Kubenet 模式時，輸入控制器必須管理應用程式閘道子網中的路由表，以將流量導向 Pod IP。 如需詳細資訊，請參閱如何設定 應用程式閘道 與 AKS 之間的網路功能。
如需 Azure 中負載平衡服務的相關資訊，請參閱 Azure 中的負載平衡選項概觀。
TLS/SSL 加密
在常見的實作中，輸入控制器會用於 SSL 終止。 因此，在部署輸入控制器時，您需要建立 TLS 憑證。 僅針對開發/測試用途使用自我簽署憑證。 如需詳細資訊，請參閱建立 HTTPS 輸入控制器，並在 AKS) Azure Kubernetes Service (上使用您自己的 TLS 憑證。
針對生產工作負載，請從受信任的憑證授權單位單位取得已簽署的憑證， (CA) 。 如需產生和設定Let's Encrypt憑證的相關資訊，請參閱Azure Kubernetes Service (在 AKS) 中建立具有靜態公用 IP 位址的輸入控制器。
您可能也需要根據組織的原則輪替您的憑證。 如需詳細資訊，請參閱在AKS Azure Kubernetes Service () 輪替憑證。
命名空間
您可以使用命名空間來組織叢集內的服務。 Kubernetes 叢集中的每個物件都會屬於一個命名空間。 根據預設，當您建立新的物件時，此物件會進入 default 命名空間。 但是較好的做法是建立更具描述性的命名空間，以協助組織叢集中的資源。
首先，命名空間有助於防止命名衝突。 當多個小組都將微服務部署到相同的叢集中時，就可能有數百個微服務，如果這些微服務都進入相同命名空間，就會變得難以管理。 此外，命名空間可讓您：
將資源限制套用至命名空間，如此一來，指派到該命名空間的 Pod 集合總數就不會超過命名空間的資源配額。
在命名空間層級上套用原則，包括 RBAC 和安全性原則。
針對微服務架構，請考慮將微服務組織到限界內容中，並為每個限界內容建立命名空間。 例如，與「訂單履行」限界內容相關的所有微服務可進入相同的命名空間。 或者，為每個開發小組建立命名空間。
將公用程式服務放入他們自己的個別命名空間中。 例如，您可能會部署 Elasticsearch 或 Prometheus 來監視叢集，或部署適用於 Helm 的 Tiller。
健康情況探查
Kubernetes 會定義兩種可由 Pod 公開的健康情況探查類型：
整備探查：告訴 Kubernetes Pod 是否已準備好接受要求。
活躍度探查：告知 Kubernetes 是否應該移除 Pod，以及啟動新的實例。
考慮使用哪個探查時，回想服務在 Kubernetes 中的運作方式可協助您做決定。 服務會有符合一組 (零或多個) Pod 的標籤選取器。 Kubernetes 會將流量負載平衡至符合選取器的 Pod。 只有成功啟動且狀況良好的 Pod 會接收流量。 如果容器損毀，Kubernetes 會終止 Pod，並安排取代事宜。
有時候，即使已成功啟動 Pod，Pod 仍可能尚未準備好接收流量。 例如，可能有初始設定工作，像是在容器中執行的應用程式要將項目載入記憶體或讀取設定資料。 若要指出 Pod 健康情況良好但未準備好接收流量，可定義整備度探查。
活躍度探查所處理的狀況是，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 許可權指派給使用者，您可以建立 角色 和 角色系結：
角色是可在命名空間內套用的一組權限。 權限會定義為資源 (Pod 和部署等) 上的動詞命令 (取得、更新、建立、刪除)。
RoleBinding 會將使用者或群組指派給角色 (Role)。
另外還有 ClusterRole 物件，就像 Role 一樣，但適用于所有命名空間的整個叢集。 若要將使用者或群組指派給 ClusterRole，請建立 ClusterRoleBinding。
AKS 會整合這兩種 RBAC 機制。 建立 AKS 叢集時，您可以將其設定為使用 Azure AD 進行使用者驗證。 如需如何設定此動作的詳細資料，請參閱整合 Azure Active Directory 與 Azure Kubernetes Service。
完成此設定之後，想要存取 Kubernetes API (例如，透過 kubectl) 的使用者必須先使用其 Azure AD 認證登入。
根據預設，Azure AD 使用者沒有叢集的存取權。 若要授與存取權，叢集管理員會建立參照 Azure AD 使用者或群組的 RoleBindings。 如果使用者沒有執行特定作業的權限，則此動作會失敗。
如果使用者預設為沒有存取權，那麼叢集管理員怎麼有權限先建立角色繫結？ AKS 叢集實際上有兩種類型的認證，可呼叫 Kubernetes API 伺服器：叢集使用者和叢集管理員。叢集管理員認證會授與叢集的完整存取權。 Azure CLI 命令 az aks get-credentials --admin 會下載叢集管理員認證，並將其儲存到您的 kubeconfig 檔案。 叢集管理員可以使用此 kubeconfig 來建立角色和角色繫結。
建議使用 Azure RBAC 進行 Kubernetes 授權，而不是在 Kubernetes 中原生管理 Kubernetes 叢集 Role 和 RoleBinding 物件。 這允許跨 Azure 資源、AKS 和 Kubernetes 資源進行統一管理和存取控制。 這些 Azure RBAC 角色指派可以鎖定叢集內的叢集或命名空間，以取得更精細的存取控制。 Azure RBAC 支援一組有限的預設許可權，您可以將其與管理 Role 和 RoleBindings 的原生 Kubernetes 機制結合，以支援進階或更細微的存取模式。 啟用時，Azure AD 主體將會由 Azure RBAC 單獨驗證，而一般 Kubernetes 使用者和服務帳戶則由 Kubernetes RBAC 單獨驗證。
由於叢集管理員認證的功能強大，因此使用 Azure RBAC 來限制其存取權：
「Azure Kubernetes Service 叢集管理員角色」有權下載叢集管理員認證。 您應只將叢集管理員指派給此角色。
「Azure Kubernetes Service 叢集使用者角色」有權下載叢集使用者認證。 您可以將非管理員的使用者指派給這個角色。 此角色不會在叢集內的 Kubernetes 資源上授與任何特定許可權，它只是允許使用者連線到 API 伺服器。
定義您的 RBAC 原則 (Kubernetes 和 Azure) 時，請考量您組織中的角色：
- 誰可以建立或刪除 AKS 叢集和下載管理員認證？
- 誰可以管理叢集？
- 誰可以建立或更新命名空間內的資源？
以命名空間來界定 Kubernetes RBAC 權限的範圍是個好方法，請使用 Roles 和 RoleBindings，而不是 ClusterRoles 和 ClusterRoleBindings。
最後，有一個問題是 AKS 叢集必須建立和管理 Azure 資源的許可權，例如負載平衡器、網路或儲存體。 若要使用 Azure API 驗證叢集本身，叢集會使用 Azure AD 服務主體。 如果您未在建立叢集時指定服務主體，系統會自動建立一個。 不過，先建立服務主體，再將最低的 RBAC 權限指派給該服務主體是很好的安全性做法。 如需詳細資訊，請參閱服務主體與 Azure Kubernetes Service。
祕密管理和應用程式認證
應用程式和服務通常需要認證，才能連線到 Azure 儲存體或 SQL Database 等外部服務。 而所面臨的挑戰是保護這些認證的安全，以免遭到洩漏。
針對Azure 資源，其中一個選項是使用受控識別。 受控識別的概念是應用程式或服務具有儲存在 Azure AD 中的身分識別，並會使用此身分識別向 Azure 服務進行驗證。 應用程式或服務會在 Azure AD 中建立其服務主體，並使用 OAuth 2.0 權杖進行驗證。 執行中的進程程式碼可以透明地取得要使用的權杖。 如此一來，您就不需要儲存任何密碼或連接字串。 您可以在 AKS 中使用受控識別，方法是使用 Azure AD 工作負載 身分識別將 Azure AD 身分識別指派給個別 Pod， (預覽) 。
目前，並非所有 Azure 服務都支援使用受控識別進行驗證。 如需支援清單，請參閱支援 Azure AD 驗證的 Azure 服務。
即使有受控識別，您仍可能需要儲存某些認證或其他應用程式祕密，以取得不支援受控識別的 Azure 服務、第三方服務和 API 金鑰等等。 以下是可安全儲存祕密的一些選項：
Azure Key Vault。 在 AKS 中，您可以將 Key Vault 中的一個或多個祕密掛接為磁碟區。 磁碟區會從 Key Vault 讀取祕密。 然後 Pod 就可以讀取祕密，就像是一般的磁碟區。 如需詳細資訊，請參閱在 AKS 叢集中使用 Azure 金鑰保存庫 Provider for Secrets Store CSI 驅動程式。
Pod 會使用工作負載身分識別或使用使用者或系統指派的受控識別來驗證本身。 如需詳細資訊，請參閱提供身分識別來存取 Azure 金鑰保存庫 Provider for Secrets Store CSI 驅動程式。
HashiCorp Vault。 Kubernetes 應用程式可使用 Azure AD 受控識別向 HashiCorp Vault 進行驗證。 請參閱 HashiCorp Vault 可使用 Azure Active Directory。 您可以將保存庫本身部署至 Kubernetes，請考慮在與應用程式叢集不同的專用叢集中執行。
Kubernetes 祕密。 另一個選項是直接使用 Kubernetes 祕密。 此選項最容易設定，但仍有一些挑戰。 祕密會儲存在 etcd，這是分散式的索引鍵-值存放區。 AKS 會對 etcd 進行待用加密。 Microsoft 負責管理加密金鑰。
使用 HashiCorp Vault 或 Azure Key Vault 等系統有幾項優點，例如：
- 集中控制祕密。
- 確保所有祕密都會進行待用加密。
- 集中管理金鑰。
- 對祕密進行存取控制。
- 稽核
容器和 Orchestrator 安全性
以下是保護 Pod 和容器的建議做法：
威脅監視：使用容器 (或協力廠商功能Microsoft Defender監視威脅) 。 如果您要在 VM 上裝載容器，請使用Microsoft Defender 作為伺服器或協力廠商功能。 此外，您可以將 記錄從 Azure 監視器中的容器監視解決方案 整合至 Microsoft Sentinel 或現有的 SIEM 解決方案。
弱點監視：使用雲端Microsoft Defender或透過Azure Marketplace提供的協力廠商解決方案，持續監視映射和執行容器中的已知弱點。
使用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 templates][arm-template] 時，您可以使用Azure DevOps Services在幾分鐘內布建不同的環境，例如複寫生產案例。 這可讓您只在需要時節省成本和布建負載測試環境。
請考慮遵循工作負載隔離準則來建構 ARM 範本，工作負載通常會定義為任意功能單位;例如，您可以為叢集建立個別的範本，然後針對相依服務使用其他範本。 工作負載隔離可讓 DevOps 執行持續整合和持續傳遞 (CI/CD) ，因為每個工作負載都會與其對應的 DevOps 小組相關聯和管理。
部署 (CI/CD) 考量︰
針對微服務架構，以下是強固 CI/CD 程序的一些目標：
- 每個小組都可建置並部署獨立擁有的服務，而不會影響或干擾其他小組。
- 將新版服務部署到生產環境之前，可先部署到開發/測試/QA 環境來進行驗證。 在每個階段上強制執行品質閘門 (Quality Gate)。
- 新版本的服務可以與舊版並存部署。
- 有足夠的存取控制原則。
- 針對容器化工作負載，您可以信任部署至生產環境的容器映射。
若要深入瞭解挑戰，請參閱 微服務架構的 CI/CD。
如需特定建議和最佳做法，請參閱 Kubernetes 上的微服務 CI/CD。
成本最佳化
使用 Azure 定價計算機來估計成本。 Microsoft Azure Well-Architected Framework中的成本一節會說明其他考慮。
以下是在此架構中使用的部分服務所要考慮的一些重點。
Azure Kubernetes Service (AKS)
在 Kubernetes 叢集的部署、管理和作業中，AKS 沒有任何相關成本。 您只需為 Kubernetes 叢集使用的虛擬機器執行個體、存放裝置與網路資源付費。
若要估計所需資源的成本，請參閱 容器服務計算機。
Azure Load Balancer
您只需支付已設定的負載平衡和輸出規則數目的費用。 輸入 NAT 規則是免費的。 未設定任何規則時，Standard Load Balancer不會收取每小時費用。
如需詳細資訊，請參閱Azure Load Balancer定價。
Azure Pipelines
此參考架構只會使用 Azure Pipelines。 Azure 提供 Azure Pipeline 作為個別服務。 針對 CI/CD，每個月允許有 1，800 分鐘的免費 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