使用 kubectl 手動安裝 Config Sync (不建議)

1.20.0 以上版本

1. 使用下列指令下載最新版本的 Config Sync 資訊清單。如要下載特定版本，請參閱「下載」一文。

   gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz
   

2. 解壓縮封存檔：

   tar -xzvf config-sync.tar.gz

3. 在先前步驟中解壓縮的封存檔中，按照提供的 README 中的操作說明編輯自訂項目。

4. 如要更新 Config Sync 安裝作業，請套用按照 README 指示建構的已算繪資訊清單：

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   將 CONFIG_SYNC_MANIFEST 替換為已算繪資訊清單的名稱。

5. 將所有用戶端的 nomos 指令替換為新版本。這項變更可確保 nomos 指令一律能取得所有已註冊叢集的狀態，並驗證這些叢集的設定。

1.19.2 以下版本

1. 下載新版本的 Config Sync 資訊清單和 nomos 指令。

2. 套用 Config Sync 資訊清單：

   kubectl apply -f config-management-operator.yaml
   

3. 建立名為 config-management.yaml 的檔案，然後將下列 YAML 檔案複製到該檔案中：

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
     enableMultiRepo: true
     preventDrift: PREVENT_DRIFT
   

   更改下列內容：

   • PREVENT_DRIFT：如果設為 true，系統會啟用 Config Sync 許可控制 Webhook，防止發生差異，方法是拒絕將衝突變更推送至實際叢集。預設為 false。無論這個欄位的值為何，Config Sync 一律會修正差異。

4. 套用變更：

   kubectl apply -f config-management.yaml
   

5. 將所有用戶端的 nomos 指令替換為新版本。這項變更可確保 nomos 指令一律能取得所有已註冊叢集的狀態，並驗證這些叢集的設定。

安全殼層金鑰組

SSH 金鑰組包含兩個檔案：一個公開金鑰和一個私密金鑰。公開金鑰的副檔名通常是 .pub。

如要使用安全殼層金鑰組，請完成下列步驟：

1. 建立 SSH 金鑰組，允許 Config Sync 對您的 Git 存放區進行驗證。如果您必須對存放區進行驗證才能複製或讀取存放區，此為必要步驟。如果安全性管理員會提供金鑰組給您，請略過這個步驟。您可以將單一金鑰組用於所有叢集，或是針對每個叢集使用專屬的金鑰組，全視您的安全性與法規遵循要求而定。

   以下指令會建立 4096 位元的 RSA 金鑰。我們建議您不要使用低於 4096 位元的值：

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   更改下列內容：

   • GIT_REPOSITORY_USERNAME：您希望 Config Sync 用來向存放區驗證身分的使用者名稱
   • /path/to/KEYPAIR_FILENAME：金鑰組的路徑

   如果您使用第三方 Git 存放區主機 (例如 GitHub)，或是想搭配 Cloud Source Repositories 使用服務帳戶，建議您使用不同的帳戶。

2. 設定存放區來辨識您剛才建立的「公開金鑰」。請參閱您 Git 主機供應商的說明文件。為方便起見，以下提供幾個熱門 Git 主機供應商的操作說明：

   • Cloud Source Repositories
   • Bitbucket
   • GitHub 建議您建立個別的部署金鑰， 提供單一 GitHub 存放區的唯讀存取權。
   • GitLab

3. 將「私密金鑰」新增到叢集的新 Secret 中：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   將 /path/to/KEYPAIR_PRIVATE_KEY_FILENAME 替換為私密金鑰的名稱 (沒有 .pub 後置字串者)。

4. (建議) 如要使用 SSH 驗證設定已知主機檢查，請將已知主機金鑰新增至 git_creds 密鑰的 data.known_hosts 欄位。如要停用 known_hosts 檢查，可以從密鑰中移除 known_hosts 欄位。如要新增已知主機金鑰，請執行下列指令：

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   然後在 data 下方新增已知主機項目：

   known_hosts: KNOWN_HOSTS_KEY
   

5. 將私密金鑰從本機磁碟中刪除，或是保護該金鑰。

6. 設定 Config Sync 並新增 Git 存放區的網址時，請使用 SSH 通訊協定。如果您使用 Cloud Source Repositories 中的存放區，輸入網址時必須採用下列格式：

   ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
   

   更改下列內容：

   • EMAIL：你的 Google Cloud 使用者名稱
   • PROJECT_ID：存放區所在專案的 ID Google Cloud
   • REPO_NAME：存放區名稱

Cookiefile

取得 cookiefile 的程序取決於您存放區的設定。如需範例，請參閱 Cloud Source Repositories 說明文件中的「產生靜態憑證」。憑證通常儲存在主目錄的 .gitcookies 檔案中，或是由安全性管理員提供給您。

如要使用 cookiefile，請完成下列步驟：

1. 建立並取得 cookiefile 後，請將其新增至叢集中的新 Secret。

   如果您未使用 HTTPS Proxy，請使用下列指令建立 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   如需使用 HTTPS Proxy，請執行下列指令，將 Proxy 新增至 Secret，並一併新增 cookiefile：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   更改下列內容：

   • /path/to/COOKIEFILE：適當的路徑和檔案名稱
   • HTTPS_PROXY_URL：與 Git 存放區通訊時使用的 HTTPS Proxy 網址

2. 如果本機仍須使用 cookiefile，請妥善保管，否則請將其刪除。

權杖

如果貴機構不允許使用安全殼層金鑰，可以選擇使用權杖。有了 Config Sync，您就能使用 GitHub 的個人存取權杖 (PAT)、GitLab 的 PAT 或部署金鑰，或是 Bitbucket 的應用程式密碼做為權杖。

如要使用權杖建立 Secret，請完成下列步驟：

1. 使用 GitHub、GitLab 或 Bitbucket 建立權杖：

   • GitHub： 建立 PAT。將 repo 範圍授予權杖，以便讀取私人存放區。由於您將 PAT 繫結至 GitHub 帳戶，我們也建議您建立電腦使用者，並將 PAT 繫結至該使用者。
   • GitLab：建立 PAT 或建立部署權杖
   • Bitbucket： 建立應用程式密碼。

2. 建立並取得權杖後，請將權杖新增至叢集中的新 Secret。

   如果您未使用 HTTPS Proxy，請使用下列指令建立 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   更改下列內容：

   • USERNAME：您要使用的使用者名稱。
   • TOKEN：您在上一個步驟中建立的權杖。

   如需使用 HTTPS Proxy，請執行下列指令，將 Proxy 連同 username 和 token 一併新增至 Secret：

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   更改下列內容：

   • USERNAME：您要使用的使用者名稱。
   • TOKEN：您在上一個步驟中建立的權杖。
   • HTTPS_PROXY_URL：與 Git 存放區通訊時使用的 HTTPS 代理伺服器網址。

3. 如果本機仍須使用權杖，請妥善保管，否則請刪除。

Google 服務帳戶

如果存放區位於 Cloud Source Repositories，且叢集使用 GKE 適用的工作負載身分聯盟或車隊適用的工作負載身分聯盟，您可以使用 Google 服務帳戶，授予 Config Sync 權限，允許存取代管叢集所在專案中的存放區。

1. 如果您還沒有服務帳戶，請建立服務帳戶。

2. 將 Cloud Source Repositories 讀者 (roles/source.reader) IAM 角色授予 Google 服務帳戶。如要進一步瞭解 Cloud Source Repositories 角色和權限，請參閱授予檢視存放區的權限。

   • 如果專案中的所有存放區都適用相同權限，請授予專案層級權限。

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • 如要讓服務帳戶在專案中對每個存放區擁有不同層級的存取權，請授予存放區專屬權限。

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

3. 如果您使用 Google Cloud 主控台設定 Config Sync，請選取「Workload Identity Federation for GKE」做為「Authentication Type」，然後新增服務帳戶電子郵件地址。

   如果您使用 Google Cloud CLI 設定 Config Sync，請將 gcpserviceaccount 新增為 secretType，然後將服務帳戶電子郵件地址新增至 gcpServiceAccountEmail。

4. 設定 Config Sync 後，請在 Kubernetes 服務帳戶與 Google 服務帳戶之間建立 IAM 政策繫結。系統會等到您完成 Config Sync 初次設定之後，再建立 Kubernetes 服務帳戶。

   如果您使用已註冊至機群的叢集，每個機群只需建立一次政策繫結。註冊至機群的所有叢集都會共用相同的 Workload Identity Federation for GKE 集區。根據機群的相同性概念，如果您在某個叢集中將 IAM 政策新增至 Kubernetes 服務帳戶，則同一個機群中其他叢集上相同命名空間的 Kubernetes 服務帳戶也會取得相同的 IAM 政策。

   有了這個繫結，Config Sync Kubernetes 服務帳戶即可做為 Google 服務帳戶：

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

更改下列內容：

• PROJECT_ID：機構的專案 ID。
• FLEET_HOST_PROJECT_ID：如果您使用 GKE Workload Identity Federation for GKE，這與 PROJECT_ID 相同。如果您使用 GKE 適用的 Fleet 工作負載身分聯盟，這個 ID 是叢集註冊的 Fleet 專案 ID。
• GSA_NAME：您要用來連線至 Artifact Registry 的自訂 Google 服務帳戶。服務帳戶必須具備 Artifact Registry 讀者 (roles/artifactregistry.reader) IAM 角色。
• KSA_NAME：調解器的 Kubernetes 服務帳戶。
  • 如果是根存放區，如果 RootSync 名稱是 root-sync，請使用 root-reconciler。否則，請使用 root-reconciler-ROOT_SYNC_NAME。如果您使用 Google Cloud 控制台或 Google Cloud CLI 安裝 Config Sync，Config Sync 會自動建立名為 root-sync 的 RootSync 物件。
• REPOSITORY：存放區的名稱。
• POLICY_FILE：具備 Identity and Access Management 政策的 JSON 或 YAML 檔案。

Compute Engine 預設服務帳戶

如果存放區位於 Cloud Source Repositories，且叢集是 GKE，並停用了 GKE 適用的工作負載身分聯盟，則可以使用 gcenode 做為驗證類型。

如果您使用 Google Cloud 控制台設定 Config Sync，請選取「Google Cloud Repository」做為「Authentication Type」。

如果您使用 Google Cloud CLI 設定 Config Sync，請將 gcenode 新增為 secretType。

選取「Google Cloud Repository」或 gcenode，即可使用 Compute Engine 預設服務帳戶。您必須將 Cloud Source Repositories Reader (roles/source.reader) IAM 角色授予 Compute Engine 預設服務帳戶。如要進一步瞭解 Cloud Source Repositories 角色和權限，請參閱授予檢視存放區的權限。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

將 PROJECT_ID 替換為貴機構的專案 ID，並將 PROJECT_NUMBER 替換為貴機構的專案編號。

GitHub 應用程式

如果存放區位於 GitHub，您可以將 githubapp 設為驗證類型。

如要使用 GitHub 應用程式，請完成下列步驟：

1. 按照 GitHub 上的操作說明，佈建 GitHub 應用程式並授予從存放區讀取資料的權限。

2. 將 GitHub 應用程式設定新增至叢集內的新 Secret：

   使用用戶端 ID

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • 將 CLIENT_ID 替換為 GitHub 應用程式的用戶端 ID。
   • 將 INSTALLATION_ID 替換為 GitHub 應用程式的安裝 ID。
   • 將 /path/to/GITHUB_PRIVATE_KEY 替換為包含私密金鑰的檔案名稱。
   • 將 BASE_URL 替換成 GitHub API 端點的基本網址。只有在存放區並非託管於 www.github.com 時才需要。否則可以省略這個引數，並預設為 https://api.github.com/。

   使用應用程式 ID

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • 將 APPLICATION_ID 替換為 GitHub 應用程式的應用程式 ID。
   • 將 INSTALLATION_ID 替換為 GitHub 應用程式的安裝 ID。
   • 將 /path/to/GITHUB_PRIVATE_KEY 替換為包含私密金鑰的檔案名稱。
   • 將 BASE_URL 替換成 GitHub API 端點的基本網址。只有在存放區並非託管於 www.github.com 時才需要。否則可以省略這個引數，並預設為 https://api.github.com/。

3. 將私密金鑰從本機磁碟中刪除，或是保護該金鑰。

4. 設定 Config Sync 並新增 Git 存放區的網址時，請使用 githubapp 驗證類型。

Kubernetes 服務帳戶

如果將 OCI 映像檔儲存在 Artifact Registry，且叢集使用 GKE 適用的 Workload Identity Federation 或 Fleet 適用的 Workload Identity Federation，則可使用 Kubernetes 服務帳戶做為驗證類型。

1. 將 Artifact Registry Reader (roles/artifactregistry.reader) 身分與存取權管理角色授予 Kubernetes 服務帳戶，並搭配使用 GKE 集區的 Workload Identity Federation。如要進一步瞭解 Artifact Registry 角色和權限，請參閱設定 Artifact Registry 的角色和權限。

   • 如果專案中的所有存放區都適用相同權限，請授予專案層級權限。

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • 如要讓服務帳戶在專案中對每個存放區擁有不同層級的存取權，請授予存放區專屬權限。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   更改下列內容：

   • PROJECT_ID：機構的專案 ID。
   • FLEET_HOST_PROJECT_ID：如果您使用 GKE Workload Identity Federation for GKE，這與 PROJECT_ID 相同。如果您使用 GKE 適用的 Fleet 工作負載身分聯盟，這個 ID 是叢集註冊的 Fleet 專案 ID。
   • KSA_NAME：調解器的 Kubernetes 服務帳戶。
     • 如果是根存放區，如果 RootSync 名稱是 root-sync，請使用 root-reconciler。否則，請使用 root-reconciler-ROOT_SYNC_NAME。如果您使用 Google Cloud 控制台或 Google Cloud CLI 安裝 Config Sync，Config Sync 會自動建立名為 root-sync 的 RootSync 物件。
   • REPOSITORY：存放區的 ID。
   • LOCATION：存放區的區域或多區域位置。

Compute Engine 預設服務帳戶

如果 Helm 資訊圖表儲存在 Artifact Registry 中，且叢集是 GKE，並停用了 GKE 適用的工作負載身分聯盟，則可以使用 gcenode 做為驗證類型。Config Sync 會使用 Compute Engine 預設服務帳戶。 您必須授予 Compute Engine 預設服務帳戶 Artifact Registry 的讀取權。

1. 執行下列指令，授予 Compute Engine 服務帳戶 Artifact Registry 的讀取權限：

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/artifactregistry.reader
   

   將 PROJECT_ID 替換為貴機構的專案 ID，並將 PROJECT_NUMBER 替換為貴機構的專案編號。

RootSync

1. 擷取用於核發 Git 伺服器憑證的 CA 憑證，並儲存到檔案中。

2. 如果是 RootSync 物件，則必須在 config-management-system 命名空間中建立 Secret。例如：

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. 設定 Config Sync 時，請將 RootSync 物件中 caCertSecretRef.name 欄位的值設為 ROOT_CA_CERT_SECRET_NAME。

RepoSync

1. 擷取用於核發 Git 伺服器憑證的 CA 憑證，並儲存到檔案中。

2. 如果是 RepoSync 物件，Secret 必須與 RepoSync 建立在相同的命名空間。例如：

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. 設定 RepoSync 時，請將 RepoSync 物件中的 caCertSecretRef.name 欄位值設為 NAMESPACE_CA_CERT_SECRET_NAME。

權杖

使用 Helm 存放區使用者名稱和密碼建立密鑰：

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

更改下列內容：

• SECRET_NAME：您要授予 Secret 的名稱。
• USERNAME：Helm 存放區使用者名稱。
• PASSWORD：Helm 存放區密碼。

設定 Config Sync 時，您會使用為 spec.helm.secretRef.name 選擇的 Secret 名稱。

Kubernetes 服務帳戶

如果 Helm 資訊圖表儲存在 Artifact Registry，且叢集使用 GKE 適用的 Workload Identity Federation for GKE 或 Fleet 適用的 Workload Identity Federation for GKE，則可使用 Kubernetes 服務帳戶做為驗證類型。

1. 將 Artifact Registry Reader (roles/artifactregistry.reader) 身分與存取權管理角色授予 Kubernetes 服務帳戶，並搭配使用 GKE 集區的 Workload Identity Federation。如要進一步瞭解 Artifact Registry 角色和權限，請參閱設定 Artifact Registry 的角色和權限。

   • 如果專案中的所有存放區都適用相同權限，請授予專案層級權限。

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • 如要讓服務帳戶在專案中對每個存放區擁有不同層級的存取權，請授予存放區專屬權限。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   更改下列內容：

   • PROJECT_ID：機構的專案 ID。
   • FLEET_HOST_PROJECT_ID：如果您使用 GKE Workload Identity Federation for GKE，這與 PROJECT_ID 相同。如果您使用 GKE 適用的 Fleet 工作負載身分聯盟，這個 ID 是叢集註冊的 Fleet 專案 ID。
   • KSA_NAME：調解器的 Kubernetes 服務帳戶。
     • 如果是根存放區，如果 RootSync 名稱是 root-sync，請使用 root-reconciler。否則，請使用 root-reconciler-ROOT_SYNC_NAME。
   • REPOSITORY：存放區的 ID。
   • LOCATION：存放區的區域或多區域位置。

Compute Engine 預設服務帳戶

如果 Helm 資訊圖表儲存在 Artifact Registry 中，且叢集是 GKE，並停用了 GKE 適用的工作負載身分聯盟，則可以使用 gcenode 做為驗證類型。Config Sync 會使用 Compute Engine 預設服務帳戶。 您必須授予 Compute Engine 預設服務帳戶 Artifact Registry 的讀取權。您可能需要授予 storage-ro 存取權範圍，才能授予唯讀權限來提取圖片。

1. 授予 Compute Engine 服務帳戶 Artifact Registry 的讀取權限：

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
       --role=roles/artifactregistry.reader
   

   將 PROJECT_ID 替換為貴機構的專案 ID，並將 PROJECT_NUMBER 替換為貴機構的專案編號。

nomos (建議)

1. 確認 nomos CLI 為最新版本。

2. 執行下列指令，更新目前 kubectl 環境中的叢集：

   nomos migrate --remove-configmanagement
   

殼層指令碼

將下列殼層指令碼複製到檔案中，然後執行該檔案，更新目前 kubectl 環境中的叢集。

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

1.20.0 以上版本

1. 下載新版本的 Config Sync 資訊清單和 nomos 指令。

2. 解壓縮封存檔：

   tar -xzvf config-sync.tar.gz

3. 在先前步驟中解壓縮的封存檔中，按照提供的 README 中的操作說明編輯自訂項目。

4. 如要更新 Config Sync 安裝作業，請套用按照 README 指示建構的已算繪資訊清單：

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   將 CONFIG_SYNC_MANIFEST 替換為已算繪資訊清單的名稱。

5. 將所有用戶端的 nomos 指令替換為新版本。這項變更可確保 nomos 指令一律能取得所有已註冊叢集的狀態，並驗證這些叢集的設定。

1.19.2 以下版本

1. 下載新版本的 Config Sync 資訊清單和 nomos 指令。

2. 套用 Config Sync 資訊清單：

   kubectl apply -f config-management-operator.yaml
   

   這項指令會更新 ConfigManagement Operator 映像檔。Kubernetes 會擷取新版本，並使用新版本重新啟動 Config Sync Pod。Config Sync 啟動時，會執行協調迴圈，套用新映像檔中綁定的資訊清單集。這會更新並重新啟動每個元件 Pod。

3. 建立名為 config-management.yaml 的檔案，然後將下列 YAML 檔案複製到該檔案中：

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
     enableMultiRepo: true
     preventDrift: PREVENT_DRIFT
   

   更改下列內容：

   • PREVENT_DRIFT：如果設為 true，系統會啟用 Config Sync 許可控制 Webhook，防止發生差異，方法是拒絕將衝突變更推送至實際叢集。預設為 false。無論這個欄位的值為何，Config Sync 一律會修正差異。

4. 套用變更：

   kubectl apply -f config-management.yaml
   

5. 將所有用戶端的 nomos 指令替換為新版本。這項變更可確保 nomos 指令一律能取得所有已註冊叢集的狀態，並驗證這些叢集的設定。