使用 GitOps 探索多叢集環境中的工作負載管理

開發雲端原生應用程式的企業組織，會面臨部署、設定和升階多種大規模 Kubernetes 叢集機群的各種應用程式和服務的挑戰。 此環境可能包括 Azure Kubernetes Service (AKS) 叢集、在其他公用雲端提供者上執行的叢集，或透過 Azure Arc 連線至 Azure 的內部部署資料中心中的叢集。請參閱探索商務程序、挑戰和解決方案架構的概念性文章。

本文會逐步引導您完成多叢集 Kubernetes 環境中的工作負載部署和設定的範例案例。 首先，您會使用一些 GitHub 存放庫和 AKS 叢集來部署範例基礎結構。 接下來，您會使用一組使用案例，其中您會以不同的角色在相同環境中工作：平台小組和應用程式小組。

必要條件

若要成功部署範例，您需要：

• Azure 訂用帳戶。 如果您沒有 Azure 訂用帳戶，請在開始前建立免費帳戶。
• Azure CLI
• GitHub CLI
• Helm
• kubectl
• jq
• 具有下列範圍的 GitHub 權杖：repo、workflow、write:packages、delete:packages、read:org、delete_repo。

1 - 部署範例

若要部署範例，請執行下列指令碼：

mkdir kalypso && cd kalypso
curl -fsSL -o deploy.sh https://raw.githubusercontent.com/microsoft/kalypso/main/deploy/deploy.sh
chmod 700 deploy.sh
./deploy.sh -c -p <prefix. e.g. kalypso> -o <GitHub org. e.g. eedorenko> -t <GitHub token> -l <azure-location. e.g. westus2> 

此指令碼可能需要 10-15 分鐘才能完成。 完成後，它會報告輸出中的執行結果，如下所示：

Deployment is complete!
---------------------------------
Created repositories:
  - https://github.com/eedorenko/kalypso-control-plane
  - https://github.com/eedorenko/kalypso-gitops
  - https://github.com/eedorenko/kalypso-app-src
  - https://github.com/eedorenko/kalypso-app-gitops
---------------------------------
Created AKS clusters in kalypso-rg resource group:
  - control-plane
  - drone (Flux based workload cluster)
  - large (Flux based workload cluster)
---------------------------------  

注意

如果部署發生問題，您可以使用下列命令來刪除已建立的資源：

./deploy.sh -d -p <preix. e.g. kalypso> -o <GitHub org. e.g. eedorenko> -t <GitHub token> -l <azure-location. e.g. westus2> 

範例概觀

此部署指令碼已建立基礎結構，如下圖所示：

有幾個平台小組存放庫：

• 控制平面：包含以高階抽象概念定義的平台模型，例如環境、叢集類型、應用程式和服務、對應規則和設定，以及升階工作流程。
• 平台 GitOps：包含代表多叢集環境拓撲的最終資訊清單，例如每個環境中可用的叢集類型、排程的工作負載，以及設定哪些平台設定值。
• 服務來源：包含範例撥號音平台服務的高階資訊清單範本。
• 服務 GitOps：包含要跨叢集部署的範例撥號音平台服務的最終資訊清單。

基礎結構也包含幾個應用程式小組存放庫：

• 應用程式來源：包含範例應用程式原始程式碼，包括 Docker 檔案、資訊清單範本和 CI/CD 工作流程。
• 應用程式 GitOps：包含要部署到部署目標的最終範例應用程式資訊清單。

指令碼已建立下列 Azure Kubernetes Service (AKS) 叢集：

• control-plane - 此叢集是不會執行任何工作負載的管理叢集。 control-plane 叢集會裝載 Kalypso 排程器操作員，其會將高階抽象概念從控制平面存放庫轉換成平台 GitOps 存放庫中的原始 Kubernetes 資訊清單。
• drone - 範例工作負載叢集。 此叢集已安裝 GitOps 延伸模組，並使用 Flux 來協調來自平台 GitOps 存放庫的資訊清單。 針對此範例，drone 叢集可以代表已啟用 Azure Arc 的叢集或具有 Flux/GitOps 延伸模組的 AKS 叢集。
• large - 範例工作負載叢集。 此叢集已安裝 GitOps 延伸模組，並使用 Flux 來協調來自平台 GitOps 存放庫的資訊清單。

探索控制平面

control plane 存放庫包含三個分支：main、dev 和 stage。 dev 和 stage 分支包含 Dev 和 Stage 環境特有的設定。 另一方面，main 分支並不代表任何特定環境。 main 分支的內容是通用的，而且供所有環境使用。 對 main 分支的任何變更都是要跨環境升階的主體。 例如，只有在 Dev 環境上成功測試之後，才能將新的應用程式或新的範本升階至 Stage 環境。

main 分支：

資料夾	描述
.github/workflows	包含實作升階流程的 GitHub 工作流程。
功能。	包含具有環境設定的分支指標的環境清單。
templates	包含各種協調器的資訊清單範本，以及工作負載命名空間的範本。
工作負載	包含已上線的應用程式和服務的清單，其中包含對應 GitOps 存放庫的指標。

dev 和 stage 分支：

項目	說明
cluster-types	包含環境中可用叢集類型的清單。 叢集類型會群組在自訂子資料夾中。 每個叢集類型都會以一組標籤標示。 它會指定用來從 GitOps 存放庫擷取資訊清單的協調器類型。 子資料夾也包含一些設定對應，以及可在叢集類型上使用的平台設定值。
configs/dev-config.yaml	包含設定對應，以及適用環境中所有叢集類型的平台設定值。
scheduling	包含將工作負載部署目標與環境中叢集類型對應的排程原則。
base-repo.yaml	排程器應從中取得範本和工作負載註冊位置的 Control Plane 存放庫 (main) 中的位置指標。
gitops-repo.yaml	Platform GitOps 存放庫中的位置指標，排程器應該在其中提取要求產生資訊清單。

提示

Control Plane 存放庫中的資料夾結構並不重要。 此範例提供一種組織存放庫中檔案的方式，但您可以自由以自己偏好的方式執行。 排程器對檔案的內容感興趣，而不是檔案所在的位置。

2 - 平台小組：將新的應用程式上線

應用程式小組會執行其軟體開發生命週期。 他們會建置其應用程式，並跨環境升階應用程式。 他們不知道有哪些叢集類型可供使用，以及其應用程式部署位置。 但他們確實知道，他們想要在 Dev 環境中部署其應用程式，以進行功能與效能測試，並在 Stage 環境中部署，以進行 UAT 測試。

應用程式小組在 Application Source 存放庫中的 workload 檔案中描述此意圖 ：

apiVersion: scheduler.kalypso.io/v1alpha1
kind: Workload
metadata:
  name: hello-world-app
  labels:
    type: application
    family: force
spec:
  deploymentTargets:
    - name: functional-test
      labels:
        purpose: functional-test
        edge: "true"
      environment: dev
      manifests:
        repo: https://github.com/microsoft/kalypso-app-gitops
        branch: dev
        path: ./functional-test
    - name: performance-test
      labels:
        purpose: performance-test
        edge: "false"
      environment: dev
      manifests:
        repo: https://github.com/microsoft/kalypso-app-gitops
        branch: dev
        path: ./performance-test   
    - name: uat-test
      labels:
        purpose: uat-test
      environment: stage
      manifests:
        repo: https://github.com/microsoft/kalypso-app-gitops
        branch: stage
        path: ./uat-test   

此檔案包含三個部署目標的清單。 這些目標會標示為自訂標籤，並指向應用程式 GitOps 存放庫中的資料夾，其中應用程式小組會為每個部署目標產生應用程式資訊清單。

使用此檔案，應用程式小組會向平台小組要求 Kubernetes 計算資源。 作為回應，平台小組必須在控制平面存放庫中註冊應用程式。

若要註冊應用程式，請開啟終端機，並使用下列指令碼：

export org=<GitHub org>
export prefix=<prefix>

# clone the control-plane repo
git clone https://github.com/$org/$prefix-control-plane control-plane
cd control-plane

# create workload registration file

cat <<EOF >workloads/hello-world-app.yaml
apiVersion: scheduler.kalypso.io/v1alpha1
kind: WorkloadRegistration
metadata:
  name: hello-world-app
  labels:
    type: application
spec:
  workload:
    repo: https://github.com/$org/$prefix-app-src
    branch: main
    path: workload/
  workspace: kaizen-app-team
EOF

git add .
git commit -m 'workload registration'
git push

注意

為了簡單起見，本範例會將變更直接推送至 main。 實際上，您會建立提取要求以提交變更。

備妥之後，應用程式會在控制平面中上線。 但是控制平面仍然不知道如何將應用程式部署目標對應到所有叢集類型。

定義開發上的應用程式排程原則

平台小組必須定義如何在 Dev 環境中的叢集類型上排程應用程式部署目標。 若要這樣做，請使用下列指令碼提交 functional-test 和 performance-test 部署目標的排程原則：

# Switch to dev branch (representing Dev environemnt) in the control-plane folder
git checkout dev
mkdir -p scheduling/kaizen

# Create a scheduling policy for the functional-test deployment target
cat <<EOF >scheduling/kaizen/functional-test-policy.yaml
apiVersion: scheduler.kalypso.io/v1alpha1
kind: SchedulingPolicy
metadata:
  name: functional-test-policy
spec:
  deploymentTargetSelector:
    workspace: kaizen-app-team
    labelSelector:
      matchLabels:
        purpose: functional-test
        edge: "true"
  clusterTypeSelector:
    labelSelector:
      matchLabels:
        restricted: "true"
        edge: "true"
EOF

# Create a scheduling policy for the performance-test deployment target
cat <<EOF >scheduling/kaizen/performance-test-policy.yaml
apiVersion: scheduler.kalypso.io/v1alpha1
kind: SchedulingPolicy
metadata:
  name: performance-test-policy
spec:
  deploymentTargetSelector:
    workspace: kaizen-app-team
    labelSelector:
      matchLabels:
        purpose: performance-test
        edge: "false"
  clusterTypeSelector:
    labelSelector:
      matchLabels:
        size: large
EOF

git add .
git commit -m 'application scheduling policies'
git config pull.rebase false
git pull --no-edit
git push

第一個原則指出，來自 kaizen-app-team 工作區且標示為標籤 purpose: functional-test 和 edge: "true" 的所有部署目標，應該在標示為標籤 restricted: "true" 的所有環境叢集類型上排程。 您可以將工作區視為應用程式小組所產生的應用程式群組。

第二個原則指出，來自 kaizen-app-team 工作區且標示為標籤 purpose: performance-test 和 edge: "false" 的所有部署目標，應該在標示為標籤 size: "large" 的所有環境叢集類型上排程。

此推送至 dev 分支會觸發排程程序，並對 Platform GitOps 存放庫中的 dev 分支建立提取要求：

除了 Promoted_Commit_id，其為升階 CD 流程的追蹤資訊，提取要求還包含指派資訊清單。 functional-test 部署目標會指派給 drone 叢集類型，並將 performance-test 部署目標指派給 large 叢集類型。 這些資訊清單會放置在 drone 和 large 資料夾中，其中包含 Dev 環境中對這些叢集類型的所有指派。

Dev 環境也包含 command-center 和 small 叢集類型：

不過，您定義的排程原則只會選取 drone 和 large 叢集類型。

了解部署目標指派資訊清單

繼續之前，請仔細查看針對 functional-test 部署目標產生的指派資訊清單。 有 namespace.yaml、platform-config.yaml 和 reconciler.yaml 資訊清單檔案。

namespace.yaml 會定義將在 hello-world 應用程式執行所在的任何 drone 叢集上建立的命名空間。

apiVersion: v1
kind: Namespace
metadata:
  name: "dev-drone-hello-world-app-functional-test" 
  labels:
    environment: "dev"
    workspace: "kaizen-app-team"
    workload: "hello-world-app"
    deploymentTarget: "hello-world-app-functional-test"
    someLabel: some-value

platform-config.yaml 包含應用程式可在 Dev 環境中使用的任何 drone 叢集上使用的所有平台設定值。

apiVersion: v1
kind: ConfigMap
metadata:
  name: platform-config
  namespace: dev-drone-hello-world-app-functional-test
data:
  CLUSTER_NAME: Drone
  DATABASE_URL: mysql://restricted-host:3306/mysqlrty123
  ENVIRONMENT: Dev
  REGION: East US
  SOME_COMMON_ENVIRONMENT_VARIABLE: "false"

reconciler.yaml 包含 drone 叢集用來擷取應用程式資訊清單的 Flux 資源，由應用程式小組針對 functional-test 部署目標準備。

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: "hello-world-app-functional-test"
  namespace: flux-system
spec:
  interval: 15s
  url: "https://github.com/eedorenko/kalypso-tut-test-app-gitops"
  ref:
    branch: "dev"
  secretRef:
      name: repo-secret    
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: "hello-world-app-functional-test"
  namespace: flux-system
spec:
  interval: 30s
  targetNamespace: "dev-drone-hello-world-app-functional-test"
  sourceRef:
    kind: GitRepository
    name: "hello-world-app-functional-test"
  path: "./functional-test" 
  prune: true

注意

control plane 會定義 drone 叢集類型使用 Flux 來協調來自應用程式 GitOps 存放庫的資訊清單。 因此 reconciler.yaml 檔案包含 GitRepository 和 Kustomization 資源。

將應用程式升階至暫存

核准並合併提取要求至 Platform GitOps 存放庫之後，代表對應叢集類型的 drone 和 large AKS 叢集會開始擷取指派資訊清單。 drone 叢集已安裝 GitOps 延伸模組，指向 Platform GitOps 存放庫。 它會將其 compliance 狀態回報給 Azure Resource Graph：

提取要求合併事件會在 control plane 存放庫中啟動 GitHub 工作流程 checkpromote。 此工作流程會等到查看 Platform GitOps 存放庫中 dev 分支的已安裝 GitOps 延伸模組的所有叢集都與提取要求認可相容為止。 在本範例中，唯一的這類叢集是 drone。

checkpromote 成功之後，它會啟動將變更 (應用程式註冊) 升階至 Stage 環境的 cd 工作流程。 為了獲得更好的可見度，它也會更新 control plane 存放庫中的 git 認可狀態：

注意

如果 drone 叢集因故無法協調指派資訊清單，升階流程將會失敗。 認可狀態會標示為失敗，且應用程式註冊將不會升階至 Stage 環境。

接下來，在暫存環境中設定 uat-test 部署目標的排程原則：

# Switch to stage branch (representing Stage environemnt) in the control-plane folder
git checkout stage
mkdir -p scheduling/kaizen

# Create a scheduling policy for the uat-test deployment target
cat <<EOF >scheduling/kaizen/uat-test-policy.yaml
apiVersion: scheduler.kalypso.io/v1alpha1
kind: SchedulingPolicy
metadata:
  name: uat-test-policy
spec:
  deploymentTargetSelector:
    workspace: kaizen-app-team
    labelSelector:
      matchLabels:
        purpose: uat-test
  clusterTypeSelector:
    labelSelector: {}
EOF

git add .
git commit -m 'application scheduling policies'
git config pull.rebase false
git pull --no-edit
git push

原則指出，來自 kaizen-app-team 工作區且標示為標籤 purpose: uat-test 的所有部署目標，應該在環境中定義的所有叢集類型上排程。

將此原則推送至 stage 分支會觸發排程程序，其會建立具有對 Platform GitOps 存放庫指派資訊清單的提取要求，類似用於 Dev 環境的提取要求。

如同 Dev 環境的情況，在檢閱並合併提取要求至 Platform GitOps 存放庫之後，control plane 存放庫中的 checkpromote 工作流程會等到叢集與 GitOps 延伸模組 (drone) 協調指派資訊清單為止。

成功執行時，認可狀態會更新。

3 - 應用程式開發小組：建置和部署應用程式

應用程式小組會定期將提取要求提交至 Application Source 存放庫中的 main 分支。 一旦提取要求合併至 main，就會啟動 CI/CD 工作流程。 在這裡，工作流程將手動啟動。

移至 GitHub 中的 Application Source 存放庫。 在 Actions 索引標籤上，選取 Run workflow。

該工作流程會執行下列動作：

• 建置應用程式 Docker 映像，並將其推送至 GitHub 存放庫套件。
• 產生 functional-test 和 performance-test 部署目標的資訊清單。 它會使用來自 dev-configs 分支的設定值。 產生的資訊清單會新增至提取要求，並在 dev 分支中自動合併。
• 產生 uat-test 部署目標的資訊清單。 它會使用來自 stage-configs 分支的設定值。

產生的資訊清單會新增至等候核准的 stage 分支的提取要求：

若要在 Dev 環境上先手動測試應用程式，再核准 Stage 環境的提取要求，請先驗證 functional-test 應用程式執行個體在 drone 叢集上的運作方式：

kubectl port-forward svc/hello-world-service -n dev-drone-hello-world-app-functional-test 9090:9090 --context=drone

# output:
# Forwarding from 127.0.0.1:9090 -> 9090
# Forwarding from [::1]:9090 -> 9090

當此命令執行時，請在瀏覽器中開啟 localhost:9090。 您會看到下列問候語頁面：

下一個步驟是檢查 performance-test 執行個體在 large 叢集上的運作方式：

kubectl port-forward svc/hello-world-service -n dev-large-hello-world-app-performance-test 8080:8080 --context=large

# output:
# Forwarding from 127.0.0.1:8080 -> 8080
# Forwarding from [::1]:8080 -> 8080

這次，在瀏覽器中使用 8080 連接埠並開啟 localhost:8080。

一旦您滿意 Dev 環境，請核准並將提取要求合併至 Stage 環境。 之後，請在這兩個叢集上的 uat-test 環境中測試 Stage 應用程式執行個體。

針對 drone 叢集執行下列命令，並在瀏覽器中開啟 localhost:8001：

kubectl port-forward svc/hello-world-service -n stage-drone-hello-world-app-uat-test 8001:8000 --context=drone

針對 large 叢集執行下列命令，並在瀏覽器中開啟 localhost:8002：

kubectl port-forward svc/hello-world-service -n stage-large-hello-world-app-uat-test 8002:8000 --context=large

large 叢集上的應用程式執行個體會顯示下列問候語頁面：

4 - 平台小組：提供平台設定

叢集中的應用程式會從 Dev 和 Stage 環境中的相同資料庫擷取資料。 讓我們變更它，並設定 west-us 叢集，為 Stage 環境中運作的應用程式提供不同的資料庫 URL：

# Switch to stage branch (representing Stage environemnt) in the control-plane folder
git checkout stage

# Update a config map with the configurations for west-us clusters
cat <<EOF >cluster-types/west-us/west-us-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: west-us-config
  labels:
     platform-config: "true"
     region: west-us
data:
  REGION: West US
  DATABASE_URL: mysql://west-stage:8806/mysql2
EOF

git add .
git commit -m 'database url configuration'
git config pull.rebase false
git pull --no-edit
git push

排程器會掃描環境中的所有設定對應，並根據標籤對應收集每個叢集類型的值。 然後，它會將 platform-config 設定對應放在 Platform GitOps 存放庫的每個部署目標資料夾中。 platform-config 設定對應包含工作負載可以在此環境中的此叢集類型上使用的所有平台設定值。

幾秒鐘後，Platform GitOps 存放庫中 stage 分支的新提取要求隨即出現：

核准提取要求並合併。

新設定到達 large 叢集之後，請在執行下列命令之後，於 localhost:8002 檢查 uat-test 應用程式執行個體：

kubectl rollout restart deployment hello-world-deployment -n stage-large-hello-world-app-uat-test --context=large
kubectl port-forward svc/hello-world-service -n stage-large-hello-world-app-uat-test 8002:8000 --context=large

您會看到更新的資料庫 URL：

5 - 平台小組：將叢集類型新增至環境

目前，只有 drone 和 large 叢集類型會包含在 Stage 環境中。 讓我們也將 small 叢集類型包含在 Stage。 雖然沒有代表此叢集類型的實體叢集，但您可以看到排程器對此變更的反應。

# Switch to stage branch (representing Stage environemnt) in the control-plane folder
git checkout stage

# Add "small" cluster type in west-us region
mkdir -p cluster-types/west-us/small
cat <<EOF >cluster-types/west-us/small/small-cluster-type.yaml
apiVersion: scheduler.kalypso.io/v1alpha1
kind: ClusterType
metadata:
  name: small
  labels: 
    region: west-us
    size: small
spec:
  reconciler: arc-flux
  namespaceService: default
  configType: configmap
EOF

git add .
git commit -m 'add new cluster type'
git config pull.rebase false
git pull --no-edit
git push

在幾秒鐘內，排程器會將提取要求提交至 Platform GitOps 存放庫。 根據您建立的 uat-test-policy，它會將 uat-test 部署目標指派給新的叢集類型，因為它應該可在環境中所有可用的叢集類型上運作。

清除資源

不再需要時，請刪除您所建立的資源。 若要這樣做，請執行下列命令：

# In kalypso folder
./deploy.sh -d -p <preix. e.g. kalypso> -o <GitHub org. e.g. eedorenko> -t <GitHub token> -l <azure-location. e.g. westus2> 

下一步

您已針對多叢集 Kubernetes 環境中一些常見的工作負載管理案例執行工作。 您可能想要探索許多其他案例。 繼續使用範例，並了解如何在日常活動中實作最常見的使用案例。

若要深入了解基礎概念和機制，請參閱下列資源：

• 概念：使用 GitOps 的多叢集環境中的工作負載管理
• 範例實作：使用 GitOps 的多叢集環境中的工作負載管理
• 概念：使用 GitOps 進行 CD 流程 (英文)
• 範例實作：使用 GitOps 探索 CI/CD 流程 (英文)