Soluciona problemas del controlador de configuración

En esta página, se muestra cómo resolver problemas con el controlador de configuración.

Soluciona problemas de instalación

No hay ninguna red llamada predeterminada

Cuando creas la instancia de Config Controller, es posible que recibas un error que indica que la red predeterminada no está disponible:

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\"

Este error se produce si no especificaste una red existente con la --network marca y tu red predeterminada en Google Cloud se borra o se inhabilita. De forma predeterminada, Config Controller crea el clúster de Google Kubernetes Engine que respalda tu instancia de Config Controller en la red predeterminada.

Si deseas crear la instancia en una red existente, agrega la --network=NETWORK marca cuando crees tu instancia de Config Controller. Reemplaza NETWORK por el nombre de una red existente.

Si deseas crear la instancia de Config Controller en la red predeterminada, vuelve a crear tu red predeterminada con el siguiente comando:

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

Para que este comando funcione, es necesario habilitar las subredes automáticas con la marca --subnet-mode=auto.

Después de volver a crear tu red predeterminada, puedes omitir la marca --network cuando crees tu instancia de Config Controller.

Valor no válido para MasterIpv4CidrBlock

La creación del controlador de configuración usa una subred predeterminada de 172.16.0.128/28 para el CIDR de IPv4 del plano de control. Si hay un conflicto en el bloque de CIDR de IPv4, la creación de Config Controller fallará con el siguiente error:

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.

Si ves este error, selecciona un CIDR de IPv4 privado diferente y úsalo con la marca --master-ipv4-cidr-block en el comando gcloud anthos config controller create.

Para encontrar los bloques de CIDR IPv4 que ya están en uso, completa los siguientes pasos:

  1. Busca el nombre del intercambio de tráfico:

    gcloud compute networks peerings list --network=NETWORK

    Reemplaza NETWORK por el nombre de la red que deseas buscar.

    El resultado es similar a este:

    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. Muestra el CIDR IPv4 que usa el intercambio de tráfico:

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

    Reemplaza lo siguiente:

    • PEERING_NAME: El nombre del intercambio de tráfico que deseas buscar
    • NETWORK: el nombre de la red que deseas buscar
    • REGION: El nombre de la región en la que se encuentra tu instancia de Config Controller

Soluciona problemas mientras se ejecuta Config Controller

Se agotaron las IPs del grupo de nodos

Si ves el siguiente mensaje de error, es posible que tus grupos de nodos no tengan suficientes direcciones IP:

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

Este problema puede ocurrir si omites la marca --cluster-ipv4-cidr-block. Cuando omites esta marca, Config Controller usa de forma predeterminada el rango de CIDR de Pod /20. Este rango te brinda un máximo de 16 nodos.

Si necesitas más nodos, borra tu instancia de Config Controller, ya que no puedes modificar el bloque de CIDR después de la creación. Cuando vuelvas a crear la instancia de Config Controller, usa el parámetro opcional --cluster-ipv4-cidr-block y especifica el CIDR range or netmask size.

Falta información del panel

Si no ves ningún detalle de Config Controller en el Google Cloud panel de la consola, es posible que la cuenta de servicio predeterminada que usa Config Controller no tenga los permisos de Google Cloud Observability que necesita.

Para otorgar estos permisos, usa los siguientes comandos:

# 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"

Reemplaza lo siguiente:

  • PROJECT_ID: El ID del proyecto en el que creaste tu instancia de Config Controller
  • PROJECT_NUMBER: tu Google Cloud número de proyecto

Soluciona problemas de componentes

Debido a que tu instancia de Config Controller viene preinstalada con Policy Controller, el Sincronizador de configuración y Config Connector, es posible que tengas problemas con estos componentes. Para obtener información sobre cómo solucionar problemas de estos componentes, consulta las siguientes páginas:

En las siguientes secciones, se proporcionan sugerencias sobre algunos de los problemas más comunes que puedes encontrar cuando usas Config Controller con estos componentes.

Errores de sincronización

Los parámetros de configuración de tu fuente de información (por ejemplo, un repositorio de Git o una imagen de OCI) se sincronizan con tu instancia de Config Controller con el Sincronizador de configuración. Para verificar si hay errores en este proceso de sincronización, usa el nomos status comando:

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

Soluciona problemas de recursos de Config Connector

Campos inmutables y recursos

Algunos campos de los recursos subyacentes son inmutables, como los de ID del proyecto o el nombre de tu red de VPC. Google Cloud Config Connector bloquea las ediciones en esos campos y no puede activar los cambios. Si deseas editar uno de estos campos inmutables, debes borrar el recurso original (mediante Git) antes de volver a agregarlo con tus valores preferidos.

Recursos bloqueados

En algunos casos, es posible que los recursos no se borren correctamente (como informa nomos status). Puedes solucionar este problema si quitas los finalizadores del recurso y, luego, lo borras de forma manual.

Por ejemplo, para borrar un IAMPolicyMember que está bloqueado, ejecuta el siguiente comando:

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

¿Qué sigue?