搭配 Active Assist 使用 GKE Enterprise 工具鍊


本文是系列文章之一,探討企業可使用的架構模式,以便透過 Active Assist 大規模最佳化雲端足跡。本教學課程說明如何為 Active Assist 建議建立自動化管道,以便搭配 GKE Enterprise 工具鍊使用。這項功能適用於使用 Config Sync 管理 GKE Enterprise 環境,以及使用 Config Connector 管理 Google Cloud 資源的使用者。本系列的其他部分如下:

在本教學課程中建構的自動化管道可協助您達成下列目標:

  • 在貴機構中擴大使用 Active Assist 系列產品。
  • 將 Active Assist 納入持續整合和持續推送軟體更新 (CI/CD) 管道。
  • 使用 GitHub 問題和提取要求等建構項目,控管 Active Assist 建議的審查和啟動程序。

本教學課程也會使用 kpt,這是 Google 開發的開放原始碼工具包,可協助您管理、操控、自訂及套用 Kubernetes 資源設定資料檔案。

架構

下方架構圖顯示您將在本教學課程使用的元件:

架構中使用的元件。

這些元件的用途如下:

  • GitHub don't repeat yourself (DRY) 存放區,用於您在 Google Cloud 機構的專案中部署的 Config Connector 範本。
  • 一或多個專案或環境專用的 GitHub 存放區,內含已補水的設定檔。這些已補水的存放區適用於 Config Sync 管理的環境。他們使用 Config Connector 啟動及管理 Google Cloud 資源,這些資源位於 Google Cloud 機構中。
  • 使用 Config Sync 進行版本控管和漂移偵測的 GKE 叢集。這個叢集也已安裝 Config Connector。Config Connector 可讓叢集管理 Google CloudGoogle Cloud 整個機構的資源。
  • Cloud Build 觸發條件,可在範本推送至 GitHub DRY 存放區時觸發建構作業。
  • 排定的 Cloud Build 觸發條件,會定期觸發建構作業。建構作業會使用 kpt 函式。函式會叫用 Active Assist Recommender API,擷取有效建議。這項服務會檢查並剖析建議,判斷 Config Connector 管理的Google Cloud 資源是否需要調整大小或進行最佳化。如果 Config Connector 管理的 Google Cloud 資源需要調整大小或最佳化,kpt 函式會在 DRY 存放區中建立 GitHub 問題,並附上建議變更的詳細資料。

這個架構的工作流程如下:

  1. 有權存取 DRY 存放區的授權團隊,可在存放區中建立及管理 Config Connector 範本。
  2. 建立或修改範本並簽入 main 分支時,系統會觸發 Cloud Build 工作。
  3. Cloud Build 工作會叫用 kpt 設定器,為範本補水。這項工作會將已補水的設定檔推送至已補水的 GitHub 存放區。Secret Manager 用於儲存私人存放區的 GitHub 部署金鑰。
  4. Config Sync 會監控已補水的存放區是否有變更,並將存放區中的更新套用至受管理叢集。
  5. Config Connector 會監控變更,並在因 Config Sync 套用 Kubernetes 資源模型 (KRM) 變更而需要建立或更新資源時,啟動 Google Cloud資源。
  6. 排定的 Cloud Build 觸發程序會定期執行,叫用 Recommender API,擷取 Config Connector 管理的專案適用的建議。
  7. 排定的 Cloud Build 工作會執行自訂 kpt 函式,叫用 Recommender API,並擷取及剖析有效建議。
  8. kpt 函式會建立 GitHub 問題,顯示目前資源設定與建議資源設定的比較結果。採用這種做法時,GitHub 問題會在 DRY 存放區中建立,方便追蹤存放區變更。

目標

  • 建立下列範例 GitHub 存放區:
    • Config Connector KRM 的 DRY 存放區。
    • 存放區,用於保存使用 kpt setter 產生的已補水設定檔。
  • 使用 Config Sync 和 Config Connector 建立 GKE 叢集。
  • 建立範例 kpt 函式,以擷取 Config Connector 管理的專案適用的 Active Assist 建議。
  • 建立 Cloud Build 觸發條件,在範本推送到 DRY 存放區的 main 分支版本時觸發。
  • 建立排定的 Cloud Build 工作,定期執行以擷取 Config Connector 管理資源的可用 Active Assist 建議。
  • 使用本教學課程 GitHub 存放區提供的虛設常式建議,測試端對端管道。

費用

在本文件中,您會使用 Google Cloud的下列計費元件:

如要根據預測用量估算費用,請使用 Pricing Calculator

初次使用 Google Cloud 的使用者可能符合免費試用資格。

完成本文所述工作後,您可以刪除已建立的資源,避免繼續計費。詳情請參閱清除所用資源一節。

事前準備

  1. In the Google Cloud console, go to the project selector page.

    Go to project selector

  2. Select or create a Google Cloud project.

  3. 記下 Google Cloud 專案 ID,您會在下一節設定環境時使用這個 ID。在本教學課程中,這個專案稱為 build 專案。
  4. Enable the Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Scheduler, and Cloud Source Repositories APIs.

    Enable the APIs

    在本教學課程中,您會使用預設應用程式憑證。如果系統在「將憑證新增至專案」頁面中提示您建立憑證,請按一下「取消」
  5. Verify that billing is enabled for your Google Cloud project.

正在設定環境

在本教學課程中,您將使用 Cloud Shell 執行所有指令。

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  2. 為目前 build 專案的專案 ID 和專案編號設定變數:Google Cloud

    export RECO_MGR_PROJECT=PROJECT_ID
    gcloud config set project $RECO_MGR_PROJECT
    export RECO_MGR_PROJECT_NUMBER=$(gcloud projects describe $RECO_MGR_PROJECT --format='value(projectNumber)')
    

    PROJECT_ID 換成您在上一個章節中記下的專案 ID。

  3. 設定部署地區的變數:

    export REGION=us-central1
    export ZONE=us-central1-a
    
  4. 複製內有本教學課程所用範例應用程式程式碼的存放區:

    git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
    
  5. 前往專案目錄:

    cd activeassist-anthos-toolchain
    
  6. 建立管道

    在本節中,您將建立用於建構管道的元件。Active Assist 建議是根據使用模式和系統指標產生。每個建議類別可使用不同的預設時間範圍,根據產生的建議分析使用資料和指標。如要測試端對端管道,您在稍早步驟中複製的存放區會提供範例建議 (存根),您可以使用這些建議執行端對端管道。

    或者,如果您在有現有資源和建議的範例專案中執行管道,可以對範例程式碼進行適當變更,然後執行管道。

    設定範例私人的 GitHub 存放區

    在下列各節中,您將為本教學課程設定範例 GitHub 存放區。

    設定私人的 DRY GitHub 存放區

    1. 為 DRY 存放區建立私人的 GitHub 存放區。請記下您為存放區指定的名稱。

    2. 在 Cloud Shell 中,為 GitHub 使用者名稱和 DRY 存放區名稱建立環境變數:

      export REPO_OWNER=YOUR_GITHUB_USERNAME
      export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
      

      更改下列內容:

      • YOUR_GITHUB_USERNAME: 您的 GitHub 使用者名稱。
      • YOUR_PRIVATE_DRY_REPO: DRY 存放區的名稱。
    3. 建立個人存取權杖 (PAT),以便在這個存放區中建立問題。如果需要審查 Active Assist 建議,管道會建立 GitHub 問題。如要進一步瞭解如何在 GitHub 中建立 PAT,請參閱 GitHub 說明文件

      為這個權杖設定範圍時,請選取「完全控管私人存放區」

    4. 在 Cloud Shell 中,為您產生的 PAT 建立環境變數:

      export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
      

      YOUR_PERSONAL_ACCESS_TOKEN 替換成您自己的權杖。

    設定私人的已補水 GitHub 存放區

    1. 為已補水的存放區建立私人的 GitHub 存放區。 請記下您為存放區指定的名稱。

    2. 在 Cloud Shell 中,為已補水的存放區設定環境變數:

      export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
      export HYDRATED_REPO='git@github.com:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
      

      YOUR_PRIVATE_HYDRATED_REPO 替換為已補水的存放區名稱。

    3. 建立部署金鑰組:

      ssh-keygen -t rsa -b 4096 \
      -C 'active-assist-robot' \
      -N '' \
      -f $(pwd)/active-assist-robot
      

      執行 Cloud Build 工作來補充設定檔時,您可以使用部署金鑰部署至私人 GitHub 存放區。

    4. 列印產生的金鑰:

      cat $(pwd)/active-assist-robot.pub
      
    5. 將部署金鑰新增至私人的 GitHub 存放區。新增部署金鑰時,請務必選取「Allow write access」。如要瞭解如何將部署金鑰新增至 GitHub 存放區,請參閱 GitHub 說明文件中的管理部署金鑰

    將 GitHub 金鑰上傳至 Secret Manager

    1. 在 Cloud Shell 中,建立密鑰來儲存部署金鑰組中的私密金鑰:

      gcloud secrets create github-ssh-key \
        --data-file=$(pwd)/active-assist-robot
      
    2. 建立密鑰來儲存 PAT:

      echo $GITHUB_TOKEN | gcloud secrets create github-pat --data-file=-
      

    建立 GKE 叢集

    在本節中,您將使用 Config Connector 外掛程式建立 GKE 叢集、建立身分,並設定 Config Connector。您也可以設定 Config Sync。您可以使用 Config Sync,為所有基礎架構建立通用設定 (包括自訂政策),並將設定套用至內部部署系統和雲端環境。Config Sync 會評估變更,然後推送至所有 Kubernetes 叢集,確保叢集隨時反映所需狀態。

    1. 在 Cloud Shell 中,建立已啟用Config Connector 外掛程式的新 GKE 叢集:

      gcloud container clusters create sample-ops \
        --machine-type n1-standard-4 \
        --zone $ZONE \
        --release-channel regular \
        --addons ConfigConnector \
        --workload-pool=$RECO_MGR_PROJECT.svc.id.goog \
        --enable-stackdriver-kubernetes \
        --enable-ip-alias
      
    2. 請完成「使用 GKE 外掛程式安裝」指南中的下列章節,建立身分並設定 Config Connector。

      1. 建立身分
      2. 設定 Config Connector
    3. 在您建立的 GKE 叢集中安裝 Config Sync。設定 Config Sync 時,您必須執行下列操作:

      1. 使用權杖授予 Config Sync 的 Git 唯讀存取權。使用設定私人 DRY GitHub 存放區時建立的 GitHub 權杖。這個權杖可透過 $GITHUB_TOKEN 環境變數取得。
      2. 使用 gcloud 設定 Config Sync。 進行下列設定:
        1. sourceFormathierarchy
        2. syncRepohttps://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
        3. 「syncBranch」syncBranchmain
        4. secretTypetoken
        5. policyDir:請勿填寫這個選項

    建立 Cloud Build 觸發條件,將內容推送至已補水的存放區

    在接下來的章節中,您將建立 Cloud Build 觸發條件,在範本推送到 YOUR_PRIVATE_DRY_REPO 存放區的主要分支版本時觸發。這個觸發程序會執行相關步驟,在 YOUR_PRIVATE_DRY_REPO 存放區中補水 config-as-data KRM 範本,並將補水後的設定檔推送至 YOUR_PRIVATE_HYDRATED_REPO 存放區。

    將 Cloud Build 連線至 GitHub 存放區

    在本節中,您會連結 YOUR_PRIVATE_DRY_REPOYOUR_PRIVATE_HYDRATED_REPO GitHub 存放區至 Cloud Build。

    1. 前往 Cloud Build 應用程式的 GitHub 市集頁面。

      前往 Cloud Build 應用程式頁面

    2. 按一下 [Setup with Google Cloud Build] (以 Google Cloud Build 設定)

    3. 如果系統提示,請登入 GitHub。

    4. 選取「Only select repositories」

      使用「選取存放區」下拉式選單,透過 Cloud Build 應用程式啟用對 YOUR_PRIVATE_DRY_REPOYOUR_PRIVATE_HYDRATED_REPO 存放區的存取權。

    5. 按一下 [安裝]

    6. 登入 Google Cloud。系統隨即會顯示「Authorization」(授權) 頁面,並提示您授權 Google Cloud Build 應用程式連線至 Google Cloud。

    7. 按一下「Authorize Google Cloud Build by GoogleCloudBuild」(透過 GoogleCloudBuild 授權 Google Cloud Build)。 系統會將您重新導向至 Google Cloud 控制台。

    8. 選取 Google Cloud 專案。

    9. 勾選「同意」核取方塊,然後按一下「下一步」

    10. 按一下 [安裝]

    11. 登入 Google Cloud。系統隨即會顯示「Authorization」(授權) 頁面,並提示您授權 Google Cloud Build 應用程式連線至 Google Cloud。

    12. 按一下「Authorize Google Cloud Build by GoogleCloudBuild」(透過 GoogleCloudBuild 授權 Google Cloud Build)。 系統會將您重新導向至 Google Cloud 控制台。

    13. 選取 Google Cloud 專案。

    14. 勾選「同意」核取方塊,然後按一下「下一步」

    15. 在隨即顯示的「Select repository」(選取存放區) 頁面中,選取下列 GitHub 存放區:

      • YOUR_PRIVATE_DRY_REPO
      • YOUR_PRIVATE_HYDRATED_REPO
    16. 依序按一下「連結」和「完成」

    為 DRY 存放區建立 Cloud Build 觸發條件

    1. 在 Cloud Shell 中執行下列指令:

      envsubst < cloudbuild.template.yaml > cloudbuild.yaml
      

      這個指令會產生 cloudbuild.yaml 檔案。

    2. 建立觸發條件:

      gcloud beta builds triggers create github \
        --name ActiveAssistDemo \
        --repo-name=$DRY_REPO_NAME \
        --repo-owner=$REPO_OWNER \
        --branch-pattern="main" \
        --build-config=cloudbuild.yaml
      
    3. 授予 Cloud Build 服務帳戶存取 Secret Manager 的權限:

      gcloud secrets add-iam-policy-binding github-ssh-key  \
        --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/secretmanager.secretAccessor"
      
      gcloud secrets add-iam-policy-binding github-pat  \
        --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/secretmanager.secretAccessor"
      

    為 Active Assist 建議建立排定的 Cloud Build 觸發條件

    在接下來的幾節中,您將建立定期執行的排程 Cloud Build 觸發條件。這個觸發程序會使用 kpt 函式擷取 Active Assist 建議,並判斷 YOUR_PRIVATE_HYDRATED_REPO 存放區中的資源是否有任何有效建議。如果資源設定有需要審查及執行的有效建議,kpt 函式也會在存放區中建立 GitHub 問題。YOUR_PRIVATE_HYDRATED_REPO

    產生 Cloud Build 映像檔

    在本節中,您將產生包含 kpt、gh 和 Node 元件的 Cloud Build 映像檔。

    1. 在 Cloud Shell 中,建構 Docker 映像檔並推送至 Container Registry

      gcloud auth configure-docker
      
      docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
      
      docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
      

    為已補水的存放區建立 Cloud Build 觸發條件

    1. 在 Cloud Shell 中,建立設定排定時間的 Cloud Build 觸發程序所需的設定檔:

       envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
      
    2. 建立 Cloud Build 觸發條件:

      gcloud beta builds triggers create github \
        --name ActiveAssistScheduledRecommendations \
        --repo-name=YOUR_PRIVATE_HYDRATED_REPO \
        --repo-owner=$REPO_OWNER \
        --branch-pattern="main" \
        --build-config=cloudbuild-scheduled-recommendations.yaml
      
    3. 取得這項觸發條件的 ID:

      export TRIGGER_ID=`gcloud beta builds triggers describe \
        ActiveAssistScheduledRecommendations \
        --format="value(id)"`
      

    建立 Cloud Scheduler 工作來叫用觸發條件

    1. 在 Cloud Shell 中建立服務帳戶:

      gcloud iam service-accounts create build-invoker \
         --description "Service Account used by Cloud Scheduler to invoke the sample scheduled Cloud Build job" \
         --display-name "recommender-scheduler-sa" \
         --project $RECO_MGR_PROJECT
      

      Cloud Scheduler 工作會使用這個服務帳戶執行 recommender-parser 服務。

    2. 授予服務帳戶叫用 Cloud Build 作業的權限:

      gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
        --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
        --role roles/cloudbuild.builds.editor \
        --project $RECO_MGR_PROJECT
      
       gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
         --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
         --role roles/serviceusage.serviceUsageConsumer \
         --project $RECO_MGR_PROJECT
      
    3. 建立 Cloud Scheduler 工作,叫用您在上一個步驟中建立的觸發程序:

      gcloud scheduler jobs create http scheduled-build \
         --project $RECO_MGR_PROJECT \
         --time-zone "America/Los_Angeles" \
         --schedule="0 */3 * * *" \
         --uri="https://cloudbuild.googleapis.com/v1/projects/${RECO_MGR_PROJECT}/triggers/${TRIGGER_ID}:run" \
         --description="Scheduler job to invoke Cloud Build" \
         --oauth-service-account-email="build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com" \
         --headers="Content-Type=application/json" \
         --http-method="POST" \
      

      如果看到以下訊息,請選取 Y

      There is no App Engine app in the project.

      如果系統提示您選擇 App Engine 應用程式所在的地區,請選取 us-central 地區。

    將 Cloud Build 設定檔修訂後推送到 GitHub

    將您建立的兩個 Cloud Build 設定檔推送至 YOUR_PRIVATE_DRY_REPO 存放區:

    git remote add dry https://github.com/$REPO_OWNER/$DRY_REPO_NAME.git
    
    git add cloudbuild.yaml
    git add cloudbuild-scheduled-recommendations.yaml
    git commit -m "Added cloudbuild configuration YAMLs"
    git push dry main
    

    將程式碼推送至私人存放區時,系統可能會提示您輸入 GitHub 憑證。

    查看 Cloud Build 工作的結果

    當您將變更提交並推送至 YOUR_PRIVATE_DRY_REPO 存放區時,系統會觸發 Cloud Build 工作。如果 Cloud Build 工作順利執行,系統會建立多項資源。在本節中,您將驗證 Cloud Build 工作完成後是否已建立資源。

    1. 在 Cloud Shell 中,於 sample-ops 叢集內驗證您是否有名為 activeassist-kcc 的命名空間:

      kubectl get ns | grep activeassist-kcc
      
    2. Config Connector 會將執行中的 Compute Engine 執行個體範例部署到您的PROJECT_ID專案。

      確認 Compute Engine 執行個體位於專案中:

       gcloud compute instances list | grep \
       computeinstance-sample-cloudmachine
      

      這部機器的 MACHINE_TYPE 類型為 n1-standard-1

    執行端對端測試

    為了方便您測試端對端管道,您為本教學課程複製的存放區提供範例建議 (存根)。您可以使用這些存根執行端對端管道。這個存根會模擬 Active Assist 建議酬載,並建議將從 n1-standard-1 執行個體類型部署的 Compute Engine 執行個體,變更為 g1-small 執行個體類型。

    在本節中,您會手動叫用排定的 Cloud Build 觸發條件,執行使用 kpt 函式擷取 Active Assist 建議的工作。您也會確認 YOUR_PRIVATE_DRY_REPO 存放區中是否已建立 GitHub 問題。

    1. 在 Google Cloud 控制台中開啟「建構觸發條件」頁面

      開啟「建構觸發條件」頁面

    2. 選取 ActiveAssistScheduledRecommendations 觸發條件。

    3. 如要手動測試觸發條件,請在觸發條件清單中,點按觸發條件項目上的「執行」

      觸發條件會在存放區中建立 GitHub 問題。YOUR_PRIVATE_DRY_REPO問題類似於下列情況:

      gcloud auth configure-docker
      
      docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
      
      docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
      

      在範例問題中,kpt 函式輸出內容顯示 Compute Engine 執行個體的目前 MACHINE_TYPE 類型為 n1-standard-1 類型。Active Assist 建議將其變更為 g1-small 型別。

      企業中的版本控管審查人員可以審查自動產生的 GitHub 問題,並視企業需求採取適當行動。

清除所用資源

如要避免系統向您的 Google Cloud 帳戶收取本教學課程中所用資源的相關費用,請刪除含有該項資源的專案,或者保留專案但刪除個別資源。

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

後續步驟