此參考架構會顯示部署至 Azure Kubernetes Service （AKS） 的微服務應用程式。 它描述基本 AKS 組態，可以是大部分部署的起點。 本文假設 Kubernetes 的基本知識。 本文主要著重于在 AKS 上執行微服務架構的基礎結構和 DevOps 考慮。 如需如何設計微服務的指引，請參閱 在 Azure 上建置微服務。
GitHub 提供 此架構的參考實作。
架構
如果您想要查看以 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 資料庫 或 Azure Cosmos DB。
Microsoft Entra ID 。 AKS 會使用 Microsoft Entra 身分識別來建立和管理其他 Azure 資源，例如 Azure 負載平衡器。 建議在用戶端應用程式中使用 Microsoft Entra ID 進行使用者驗證。
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 終止和速率限制。 如需詳細資訊，請參閱
在 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 。
注意
針對 AKS，您也可以使用 Azure 應用程式閘道，使用 應用程式閘道 輸入控制器 （AGIC）。 Azure 應用程式閘道可以執行第 7 層路由和 SSL 終止。 它也內建支援 Web 應用程式防火牆 （WAF）。 如果您的 AKS 叢集使用 CNI 網路 功能，應用程式閘道可以部署到叢集虛擬網路的子網，也可以部署在 AKS 虛擬網路的不同虛擬網路中，不過，這兩個虛擬網路必須一起對等互連。 AGIC 也支援 Kubenet 網路外掛程式。 使用 Kubenet 模式時，輸入控制器必須管理應用程式閘道子網中的路由表，以將流量導向 Pod IP。 如需詳細資訊，請參閱 如何設定應用程式閘道與 AKS 之間的網路功能。
如需 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 許可權指派給使用者，您可以建立 角色 和 角色系 結：
角色是在命名空間內套用的一組許可權。 許可權定義為資源上的動詞命令（取得、更新、建立、刪除）（Pod、部署等）。
RoleBinding 會將使用者或群組指派給角色。
另外還有 ClusterRole 物件，就像角色一樣，但適用于所有命名空間的整個叢集。 若要將使用者或群組指派給 ClusterRole，請建立 ClusterRoleBinding。
AKS 會整合這兩個 RBAC 機制。 當您建立 AKS 叢集時，您可以將它設定為使用 Microsoft Entra ID 進行使用者驗證。 如需如何設定此設定的詳細資訊，請參閱 整合 Microsoft Entra ID 與 Azure Kubernetes Service 。
設定好之後，想要存取 Kubernetes API 的使用者（例如透過 kubectl）必須使用其 Microsoft Entra 認證登入。
根據預設，Microsoft Entra 使用者無法存取叢集。 為了授與存取權，叢集管理員會建立代表 Microsoft Entra 使用者或群組的 RoleBindings。 如果使用者沒有特定作業的許可權，它將會失敗。
如果使用者預設沒有存取權，叢集管理員如何擁有第一個位置建立角色系結的許可權？ 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 機制結合，以支援進階或更細微的存取模式。 啟用時，Azure RBAC 會以獨佔方式驗證 Microsoft Entra 主體，而 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 和容器的建議做法：
威脅監視： 使用 適用于容器 的 Microsoft Defender 監視威脅（或協力廠商功能）。 如果您要在 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 架構良好架構 中的 成本一節會說明其他考慮。
以下是此架構中所使用之一些服務的一些考慮點。
Azure Kubernetes Service (AKS)
在 Kubernetes 叢集的部署、管理和作業中，AKS 沒有任何相關成本。 您只需為 Kubernetes 叢集使用的虛擬機器執行個體、存放裝置與網路資源付費。
若要預估所需資源的費用，請參閱 Container Services 計算機。
Azure 負載平衡器
您只需支付已設定的負載平衡和輸出規則數目。 輸入 NAT 規則是免費的。 未設定任何規則時，標準 Load Balancer 不會每小時收費。
如需詳細資訊，請參閱 Azure Load Balancer 定價 。
Azure Pipelines
此參考架構只會使用 Azure Pipelines。 Azure 會以個別服務的形式提供 Azure Pipeline。 CI/CD 每月允許免費 Microsoft 裝載工作，CI/CD 為 1,800 分鐘，且每個月有一個無限制的自我裝載工作，額外的作業會收取費用。 如需詳細資訊， 請參閱 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