解決 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 會在預設網路中建立 Google Kubernetes Engine (GKE) Enterprise 版叢集,做為 Config Controller 執行個體的備份。

如要在現有網路中建立執行個體,請在建立 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

缺少資訊主頁資訊

如果 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

後續步驟