Esta página se ha traducido con Cloud Translation API.

Solucionar problemas de Config Controller

En esta página se explica cómo solucionar problemas con Config Controller.

Troubleshoot installation

No hay ninguna red llamada "default"

Al crear tu instancia de Config Controller, es posible que recibas un error sobre la red predeterminada que 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 has especificado una red con la marca --network y tu red predeterminada en Google Cloudse ha eliminado o inhabilitado. 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 quieres crear la instancia en una red ya creada, añade la marca --network=NETWORK al crear la instancia de Config Controller. Sustituye NETWORK por el nombre de una red que ya tengas.

Si quieres crear la instancia de Config Controller en la red predeterminada, vuelve a crearla 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.

Una vez que hayas recreado tu red predeterminada, puedes omitir la marca --network al crear tu instancia de Config Controller.

Valor no válido para MasterIpv4CidrBlock

La creación de Config Controller usa una subred predeterminada de 172.16.0.128/28 para el CIDR IPv4 del plano de control. Si hay un conflicto en el bloque CIDR de IPv4, la creación de Config Controller falla y se muestra 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 aparece este error, selecciona otro CIDR IPv4 privado y úsalo con la marca --master-ipv4-cidr-block en el comando gcloud anthos config controller create.

Para encontrar bloques CIDR de IPv4 que ya estén en uso, sigue estos pasos:

Busca el nombre del peering:

gcloud compute networks peerings list --network=NETWORK

Sustituye NETWORK por el nombre de la red que quieras buscar.

El resultado debería ser similar al siguiente:

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.

Muestra el CIDR de IPv4 que usa el emparejamiento:
```
gcloud compute networks peerings list-routes PEERING_NAME \
    --direction=INCOMING \
    --network=NETWORK \
    --region=REGION
```
Haz los cambios siguientes:
- PEERING_NAME: el nombre del peering que quieras consultar
- NETWORK: el nombre de la red que quieres buscar
- REGION: el nombre de la región en la que se encuentra tu instancia de Config Controller

Solucionar problemas al ejecutar Config Controller

Se han agotado 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 producirse si omites la marca --cluster-ipv4-cidr-block. Si omite esta marca, Config Controller usará de forma predeterminada el intervalo de /20 CIDR de pods. Este intervalo te permite tener un máximo de 16 nodos.

Si necesitas más nodos, elimina tu instancia de Config Controller, ya que no puedes modificar el bloque CIDR después de crearla. 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 en el panel de control

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

Para conceder 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"

Haz los cambios siguientes:

PROJECT_ID: el ID del proyecto en el que has creado la instancia de Config Controller
PROJECT_NUMBER: tu Google Cloud número de proyecto

Solucionar problemas de componentes

Como tu instancia de Config Controller viene preinstalada con Policy Controller, Config Sync y Config Connector, es posible que tengas problemas con estos componentes. Para saber cómo solucionar problemas de estos componentes, consulta las siguientes páginas:

En las siguientes secciones se ofrecen consejos sobre algunos de los problemas más habituales que pueden surgir al usar Config Controller con estos componentes.

Errores de sincronización

Las configuraciones de tu fuente de información veraz (por ejemplo, un repositorio de Git o una imagen OCI) se sincronizan con tu instancia de Config Controller mediante Config Sync. Para comprobar si hay errores en este proceso de sincronización, usa el comando nomos status:

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

Solucionar problemas de recursos de Config Connector

Campos y recursos inmutables

Algunos campos de los Google Cloud recursos subyacentes son inmutables, como los IDs de proyecto o el nombre de tu red VPC. Config Connector bloquea las ediciones de estos campos y no puede activar los cambios. Si quieres editar uno de estos campos inmutables, debes eliminar el recurso original (a través de Git) antes de volver a añadirlo con los valores que prefieras.

Recursos bloqueados

A veces, es posible que los recursos no se eliminen correctamente (como se indica en nomos status). Para solucionar este problema, puedes quitar los finalizadores del recurso y, a continuación, eliminarlo manualmente.

Por ejemplo, para eliminar 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

Siguientes pasos

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.