排查 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 标志来使用该 CIDR。

如需查找已在使用的 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 或 VPC 网络的名称。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

后续步骤