排解 Config Controller 問題

本頁說明如何解決 Config Controller 的問題。

排解安裝問題

沒有名為「default」的網路

建立 Config Controller 執行個體時，您可能會收到預設網路無法使用的錯誤訊息：

Error 400: Project \"PROJECT_ID\" has no network named \"default\"., badRequest\n\n  on main.tf line 35, in resource \"google_container_cluster\" \"acp_cluster\"

如果您未使用 --network 旗標指定現有網路，且 Google Cloud中的預設網路已遭刪除或停用，就會發生這項錯誤。根據預設，Config Controller 會在預設網路中，建立支援 Config Controller 執行個體的 Google Kubernetes Engine 叢集。

如要在現有網路中建立執行個體，請在建立 Config Controller 執行個體時新增 --network=NETWORK 標記。將 NETWORK 替換為現有網路的名稱。

如要在預設網路中建立 Config Controller 執行個體，請使用下列指令重新建立預設網路：

gcloud compute networks create default --subnet-mode=auto

如要使用這項指令，必須使用 --subnet-mode=auto 標記啟用自動子網路。

重新建立預設網路後，建立 Config Controller 執行個體時，可以省略 --network 旗標。

MasterIpv4CidrBlock 的值無效

建立 Config Controller 時，系統會使用 172.16.0.128/28 做為控制層 IPv4 CIDR 的預設子網路。如果 IPv4 CIDR 區塊發生衝突，Config Controller 建立作業就會失敗，並顯示下列錯誤訊息：

Cloud SSA\n\nError: Error waiting for creating GKE cluster: Invalid value for field PrivateClusterConfig.MasterIpv4CidrBlock: 172.16.0.128/28 conflicts with an existing subnet in one of the peered VPCs.

如果看到這則錯誤訊息，請選取其他私人 IPv4 CIDR，並在 gcloud anthos config controller create 指令中使用 --master-ipv4-cidr-block 旗標。

如要找出已使用的 IPv4 CIDR 區塊，請完成下列步驟：

  1. 找出對等互連的名稱：

    gcloud compute networks peerings list --network=NETWORK

    將 NETWORK 替換為要查詢的網路名稱。

    輸出結果會與下列內容相似：

    NAME                                    NETWORK   PEER_PROJECT               PEER_NETWORK                            PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
gke-n210ce17a4dd120e16b6-7ebf-959a-peer  default  gke-prod-us-central1-59d2  gke-n210ce17a4dd120e16b6-7ebf-0c27-net            False                 False                 ACTIVE  [2021-06-08T13:22:07.596-07:00]: Connected.

  2. 顯示對等互連使用的 IPv4 CIDR：

    gcloud compute networks peerings list-routes PEERING_NAME \
    --direction=INCOMING \
    --network=NETWORK \
    --region=REGION

    更改下列內容：

    • PEERING_NAME：要查詢的對等互連名稱
    • NETWORK：要查詢的網路名稱
    • REGION：Config Controller 執行個體所在的區域名稱

排解執行 Config Controller 時的問題

節點集區 IP 不足

如果看到下列錯誤訊息，表示節點集區可能沒有足夠的 IP 位址：

Can't scale up because instances in managed instance groups hosting node pools ran out of IPs

如果省略 --cluster-ipv4-cidr-block 旗標，就可能發生這個問題。如果省略這個旗標，Config Controller 預設會使用 /20 Pod CIDR 範圍。這個範圍最多可提供 16 個節點。

如果需要更多節點，請刪除 Config Controller 執行個體，因為建立後就無法修改 CIDR 區塊。重新建立 Config Controller 執行個體時，請使用選用參數 --cluster-ipv4-cidr-block 並指定 CIDR range or netmask size。

Config Sync 資訊主頁未列出 Config Controller 管理的叢集

如果點選 Config Sync 資訊主頁後沒有看到任何執行個體，請建立空白機群，然後將 Config Controller 叢集指派給該機群。

缺少資訊主頁資訊

如果 Google Cloud 控制台資訊主頁中未顯示 Config Controller 的任何詳細資料，則 Config Controller 使用的預設服務帳戶可能沒有所需的 Google Cloud Observability 權限。

如要授予這些權限，請使用下列指令：

# Cloud Monitoring metrics permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/monitoring.metricWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/stackdriver.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/opsconfigmonitoring.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Logging permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/logging.logWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Trace permissions\
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/cloudtrace.agent \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

更改下列內容：

  • PROJECT_ID：您在其中建立 Config Controller 執行個體的專案 ID
  • PROJECT_NUMBER：您的 Google Cloud 專案編號

排解元件問題

由於 Config Controller 執行個體已預先安裝 Policy Controller、Config Sync 和 Config Connector，您可能會遇到這些元件的問題。如要瞭解如何排解這些元件的問題，請參閱下列網頁：

以下各節提供建議，說明使用這些元件時，可能會遇到哪些常見的 Config Controller 問題。

同步處理錯誤

可靠資料來源 (例如 Git 存放區或 OCI 映像檔) 中的設定會透過 Config Sync 同步至 Config Controller 執行個體。使用 nomos status 指令檢查這個同步程序是否有錯誤：

nomos status  --contexts $(kubectl config current-context)

排解 Config Connector 資源問題

無法變更的欄位和資源

基礎 Google Cloud 資源的某些欄位無法變更，例如專案 ID 或虛擬私有雲網路名稱。Config Connector 會禁止編輯這類欄位，且無法啟動變更。如要編輯其中一個不可變更的欄位，請先刪除原始資源 (透過 Git)，然後使用偏好的值重新新增。

無法存取的資源

有時資源可能無法正確刪除 (如 nomos status 所回報)。您可以移除資源上的終結器，然後手動刪除資源，即可修正這個問題。

舉例來說，如要刪除卡住的 IAMPolicyMember，請執行下列指令：

kubectl patch IAMPolicyMember logging-sa-iam-permissions \
    -p '{"metadata":{"finalizers":[]}}' --type=merge -n config-control
kubectl delete IAMPolicyMember logging-sa-iam-permissions -n config-control

後續步驟