Soluciona problemas del Sincronizador de configuración

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

Si bien nos esforzamos por que la experiencia del Sincronizador de configuración para que funcione siempre, hay situaciones en las que te podrías encontrar que requieren que soluciones los problemas de configuración. En esta guía, se explican algunos mecanismos comunes que pueden ayudarte a resolver problemas que encuentres.

Prácticas recomendadas generales

Consulta el estado del Sincronizador de configuración

El comando nomos status te proporciona datos y errores agregados para ayudarte a comprender lo que sucede en la instalación del Sincronizador de configuración. La siguiente información está disponible con nomos status:

• Estado de la instalación por clúster
• Errores de sincronización (lectura de Git y conciliación de los cambios)

Para usar nomos status, instala el comando nomos.

También puedes usar el comando gcloud alpha anthos config sync repo o el panel del Sincronizador de configuración para ver el estado del Sincronizador de configuración por repositorio.

Usa indicadores de nivel de servicio (SLI)

Para recibir notificaciones cuando el Sincronizador de configuración no funciona según lo previsto, configura reglas de alerta de Prometheus basadas en los SLI del Sincronizador de configuración. Para obtener más información, consulta Usa los SLI del Sincronizador de configuración.

Utilice kubectl para examinar los recursos

El Sincronizador de configuración se compone de varios recursos personalizados que puedes consultar mediante los comandos kubectl. Estos comandos te ayudan a comprender el estado de cada uno de los objetos del Sincronizador de configuración.

Debes conocer la siguiente información sobre los recursos de Kubernetes que administra el Sincronizador de configuración:

• config-management-system es el espacio de nombres que usamos para ejecutar todos los componentes principales del sistema del Sincronizador de configuración.
• configmanagement.gke.io/v1 y configsync.gke.io son los prefijos de versión que usamos para todos los recursos personalizados.

Puedes obtener una lista completa de los recursos personalizados si ejecutas el siguiente comando:

kubectl api-resources | grep -E "configmanagement.gke.io|configsync.gke.io"

Puedes consumir recursos personalizados individuales si ejecutas el siguiente comando: kubectl get RESOURCE -o yaml.

Por ejemplo, el resultado del siguiente comando te permite verificar el estado de un objeto RootSync:

kubectl get rootsync -n config-management-system -o yaml

También puedes usar el comando gcloud alpha anthos config sync resources o el panel del Sincronizador de configuración para ver los recursos que administra el Sincronizador de configuración.

Explora tus objetos RootSync y RepoSync

Cuando instalas el Sincronizador de configuración con kubectl, creas un objeto RootSync que contiene detalles sobre la configuración de tu repositorio raíz. Cuando instalas el Sincronizador de configuración con la consola de Google Cloud o Google Cloud CLI, el Sincronizador de configuración crea de forma automática un objeto RootSync por ti. Cuando configuras la sincronización desde varios repositorios, debes crear objetos RepoSync que contienen información de configuración sobre tus repositorios de espacios de nombres.

La exploración de estos objetos puede revelar información valiosa sobre el estado del Sincronizador de configuración. Para obtener más información, consulta Supervisa los objetos RepoSync y RootSync.

Usa registros de auditoría

Los registros de auditoría pueden ser una herramienta de depuración útil.

Si instalaste el Sincronizador de configuración con la consola de Google Cloud o Google Cloud CLI, completa los siguientes pasos para usar los registros de auditoría a fin de investigar el Sincronizador de configuración.

Consola

1. Habilita los registros de auditoría de las API de GKE Connect/Hub.

   1. En la consola de Google Cloud, ve a la página de Registros de auditoría de IAM.

      Ir a la página Registros de auditoría

   2. En la tabla, selecciona la casilla de verificación API de GKE Connect/Hub.

   3. Selecciona las siguientes casillas de verificación:

      • Lectura de administración
      • Lectura de datos
      • Escritura de datos

   4. Haz clic en Guardar.

2. Ir a la página Explorador de registros.

   Ir a la página Explorador de registros

3. En el cuadro de texto Compilador de consultas, agrega los siguientes filtros:

   resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
   

4. Haz clic en Run Query.

5. En la sección Resultados de consultas, selecciona entradas para obtener más información sobre los eventos.

Configura el nivel de registro de Conciler

A veces, los registros del contenedor (por ejemplo, registros del conciliador o de git-sync) en un conciliador de RootSync o RepoSync pueden contener información útil para depurar el Sincronizador de configuración. Para incluir más información en los registros, puedes configurar la verbosidad del registro mediante la configuración de .spec.override.logLevels, como en el siguiente ejemplo:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  override:
    logLevels:
    - containerName: "reconciler"
      logLevel: 8
    - containerName: "git-sync"
      logLevel: 10

El nombre del contenedor debe ser uno de los siguientes: reconciler, git-sync, hydration-controller, oci-sync o helm-sync.

Para confirmar que se configuró la verbosidad del registro, ejecuta el siguiente comando:

kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml

La verbosidad del registro se puede encontrar como una de las args dentro de spec.template.spec.containers[] y se parece a -v=0, en la que 0 es la verbosidad del registro actual.

Crea un informe de errores

Si tienes un problema con el Sincronizador de configuración que requiera la ayuda del equipo de asistencia de Google Cloud, puedes proporcionarles información de depuración valiosa mediante el comando nomos bugreport. Puedes usar este comando para un solo repositorio y varios repositorios.

nomos bugreport

Este comando genera un archivo ZIP con marca de tiempo que contiene información sobre el conjunto de clústeres de Kubernetes en tu contexto kubectl. El archivo contiene registros de los pods del Sincronizador de configuración. No contiene información sobre los recursos sincronizados con el Sincronizador de configuración. Para obtener más información sobre el contenido del archivo ZIP, consulta la referencia de nomos bugreport.

Comprende la arquitectura del Sincronizador de configuración

Cuando solucionas problemas del Sincronizador de configuración, es útil comprender los objetos y recursos que crea el Sincronizador de configuración en un clúster y cómo se relacionan entre sí. La mayoría de estos objetos y recursos se crean automáticamente cuando instalas el Sincronizador de configuración y no necesitas modificarlos. En el siguiente diagrama, se muestra la arquitectura del Sincronizador de configuración en un clúster y sus recursos relacionados:

Cuando se instala el Sincronizador de configuración en un clúster, agrega el operador de Config Management al clúster. El operador crea o administra los otros componentes necesarios para que funcione el Sincronizador de configuración. El operador consta de una definición de recurso personalizado ConfigManagement y el recurso personalizado. Para ver un ejemplo de cómo se ve este recurso, consulta Ejemplo de objeto ConfigManagement. El operador crea y administra los siguientes recursos:

• Administrador de conciliación: Crea y administra los conciliadores raíz o de espacios de nombres. También se crea un conciliador creado para cada objeto RootSync y RepoSync que se crea. El conciliador de RootSync o RepoSync extrae los archivos de configuración almacenados en la fuente de información, lo que crea o actualiza los recursos y objetos que administra el Sincronizador de configuración en el clúster.
• Recurso personalizado y definición de recursos personalizados de RootSync o RepoSync: Configura el Sincronizador de configuración a fin de que vigile tu fuente de información y aplique objetos de esa fuente a un clúster para objetos RootSync o a un espacio de nombres en un clúster para objetos RepoSync. Cuando instalas el Sincronizador de configuración, el operador de Config Management crea automáticamente un RootSync, pero puedes modificarlo o crear objetos RootSync o RepoSync adicionales. Para obtener más información sobre estos recursos, consulta Campos RootSync y RepoSync.
• Control de ResourceGroup y definición de recurso personalizado: El Sincronizador de configuración lo usa para conservar el inventario de objetos que aplicó y administra anteriormente. El Sincronizador de configuración crea un objeto ResourceGroup para cada RootSync o RepoSync del clúster.

Cuando agregas o modificas la fuente de información, el Sincronizador de configuración concilia continuamente los clústeres según esas opciones de configuración.

Soluciona problemas generales

Evento con FailedScheduling

La salida de kubectl get events podría incluir un evento con el tipo FailedScheduling. Este evento es similar al siguiente ejemplo:

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

Este evento puede suceder porque los Pods no se pueden programar en tus nodos, lo que significa que no hay suficiente CPU o memoria en tus nodos. Para corregir este error, elige una de las siguientes opciones:

• agregar un nodo a un grupo de nodos de GKE existente, o
• crear un grupo de nodos con nodos más grandes

Objeto ConfigManagement válido pero incorrecto

Nota: Esta sección solo se aplica si creaste un objeto ConfigManagement. Si creas un archivo apply-spec.yaml incorrecto y tratas de aplicarlo, el comando falla al instante y muestra un mensaje de error en el que se explica qué campos del archivo apply-spec.yaml son incorrectos. Debido a que los campos spec.git del objeto ConfigManagement están obsoletos, debes migrar tu objeto ConfigManagement.

Si instalas el Sincronizador de configuración con comandos kubectl y la instalación falla debido a un problema con el objeto ConfigManagement que no se debe a un error de sintaxis de YAML o JSON, es posible que se cree una instancia del objeto en el clúster, pero es posible que no funcione correctamente. En este caso, puedes usar el comando nomos status para verificar si hay errores en el objeto.

Una instalación válida sin problemas tiene el estado PENDING o SYNCED.

Una instalación no válida tiene un estado de NOT CONFIGURED y enumera uno de los siguientes errores:

• missing git-creds Secret
• missing required syncRepo field
• git-creds Secret is missing the key specified by secretType

Para solucionar el problema, corrige el error de configuración. Según el tipo de error, es posible que debas volver a aplicar el manifiesto de ConfigManagement al clúster.

Si el problema es que te olvidaste de crear el Secret git-creds, el Sincronizador de configuración detecta el Secret en cuanto lo creas y no es necesario que vuelvas a aplicar la configuración.

Los campos ResourceGroup cambian constantemente

Para cada repositorio de Git sincronizado con el clúster, el estado de conciliación de todos los recursos se agrega en un recurso llamado ResourceGroup. Para cada objeto RootSync o RepoSync, se genera un ResourceGroup a fin de capturar el conjunto de recursos aplicados al clúster y los estados agregados.

En ocasiones, ResourceGroup puede ingresar un bucle que continúa con la actualización del spec de ResourceGroup. Si esto sucede, es posible que observes los siguientes problemas:

• El metadata.generation de un ResourceGroup sigue aumentando en un período breve.
• El ResourceGroup spec cambia constantemente.
• El ResourceGroup spec no incluye el status.resourceStatuses de los recursos que se están sincronizando con el clúster.

Si observas estos problemas, significa que algunos de los recursos de tus repositorios de Git no se aplicaron al clúster. La causa de estos problemas es que no tienes los permisos necesarios para aplicar esos recursos.

Para verificar que faltan los permisos, obtén el estado de los recursos de RepoSync:

kubectl get reposync repo-sync -n NAMESPACE -o yaml

Reemplaza NAMESPACE por el espacio de nombres en el que creaste el repositorio de espacio de nombres.

También puedes usar nomos status.

Si ves los siguientes mensajes en el estado, significa que el conciliador en NAMESPACE carece del permiso necesario para aplicar el recurso:

errors:
  - code: "2009"
    errorMessage: |-
      KNV2009: deployments.apps "nginx-deployment" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-     default" cannot get resource "deployments" in API group "apps" in the namespace "default"

      For more information, see https://g.co/cloud/acm-errors#knv2009

Para solucionar este problema, debes declarar una configuración de RoleBinding que otorgue a la cuenta de servicio ns-reconciler-NAMESPACE permiso para administrar el recurso con errores en ese espacio de nombres. Los detalles sobre cómo agregar una RoleBinding se incluyen en Configura la sincronización desde varios repositorios.

Gran cantidad de recursos en el repositorio de Git

Cuando el repositorio de Git que se sincroniza con un clúster mediante un objeto RootSync o RepoSync contiene una configuración de más de unos pocos miles de recursos, puede hacer que ResourceGroup exceda el límite de tamaño del objeto etcd. Cuando esto sucede, no puedes ver el estado agregado para los recursos del repositorio de Git. Si bien no podrás ver el estado agregado, es posible que el repositorio aún esté sincronizado.

Si ves el siguiente error de los registros de RootSync, del objeto RepoSync o del conciliador, significa que el recurso ResourceGroup excede el límite de tamaño de objeto etcd.

KNV2009: etcdserver: request is too large

Para resolver este problema, te recomendamos que dividas tu repositorio de Git en varios repositorios. Para obtener más información, consulta Cómo dividir un repositorio en varios repositorios.

Si no puedes dividir el repositorio de Git, en la versión 1.11.0 y posteriores del Sincronizador de configuración, puedes mitigar el problema si inhabilitas la aparición de datos de estado. Para ello, configura el campo .spec.override.statusMode del objeto RootSync o RepoSync en disabled. Cuando lo haces, el Sincronizador de configuración deja de actualizar el estado de los recursos administrados en el objeto ResourceGroup. Reduce el tamaño del objeto ResourceGroup. Sin embargo, ya no puedes ver el estado de los recursos administrados desde nomos status o gcloud alpha anthos config sync.

Si instalaste el Sincronizador de configuración con la consola de Google Cloud o Google Cloud CLI, crea un objeto RootSync editable para poder configurar spec.override.statusMode. Para obtener más información, consulta Configura el Sincronizador de configuración con los comandos de kubectl.

Si no ves ningún error del objeto RootSync o RepoSync, significa que tu repositorio de Git está sincronizado con el clúster. Para verificar si el recurso ResourceGroup supera el límite de tamaño del objeto etcd, verifica el estado y el registro del controlador ResourceGroup:

1. Verifica el estado de ResourceGroup:

   • Para verificar el objeto RootSync, ejecuta el siguiente comando:

    kubectl get resourcegroup.kpt.dev root-sync -n config-management-system
   

   • Para verificar el objeto RepoSync, ejecuta el siguiente comando:

   kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE
   

   El resultado es similar al siguiente ejemplo.

   NAME        RECONCILING   STALLED   AGE
   root-sync   True          False     35m
   

   Si el valor en la columna RECONCILING es True, significa que el recurso de ResourceGroup todavía se encuentra en conciliación.

2. Revisa los registros para el controlador ResourceGroup:

   kubectl logs deployment/resource-group-controller-manager -c manager -n resource-group-system
   

   Si ves el siguiente error en el resultado, el recurso de ResourceGroup es demasiado grande y supera el límite de tamaño de los objetos etcd:

   "error":"etcdserver: request is too large"
   

Para evitar que ResourceGroup se vuelva demasiado grande, reduce la cantidad de recursos en el repositorio de Git. Puedes seguir las instrucciones para dividir un repositorio raíz en varios repositorios raíz.

Sin sincronizar con el repositorio de Git

Si se envían confirmaciones nuevas al repositorio de Git, pero el estado del Sincronizador de configuración de tu clúster sigue siendo Synced para una confirmación anterior y durante mucho tiempo (más de spec.git.period), debes verificar los registros del contenedor git-sync:

# check git-sync logs for a root reconciler
kubectl logs -n config-management-system deployment/root-reconciler -c git-sync

# check git-sync logs for a namespace reconciler
kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE -c git-sync

Es probable que git-sync no se sincronice desde el repositorio de Git, pero el conciliador continúe con la sincronización desde la confirmación sincronizada con anterioridad. El siguiente resultado de ejemplo indica que tienes un problema git-sync:

"msg"="unexpected error syncing repo, will retry" "error"="Run(git fetch -f
--tags --depth 1 origin develop): exit status 128: { stdout: "", stderr: "fatal:
couldn't find remote ref develop\n" }"

Webhook rechaza la solicitud de actualizar o borrar un recurso que era administrado por un objeto RootSync/RepoSync borrado

Borrar un objeto RootSync o RepoSync no borra las anotaciones y etiquetas del Sincronizador de configuración, y el webhook de admisión del Sincronizador de configuración rechazaría las solicitudes de modificación o eliminación de estos recursos si el Sincronizador de configuración aún está habilitado en el clúster.

Si el intent es mantener estos recursos administrados, primero puedes dejar de administrar estos recursos si configuras la anotación configmanagement.gke.io/managed en disabled en cada Recurso administrado declarado en el repositorio de Git. Esto quitaría las anotaciones y etiquetas de Sincronizador de configuración de los recursos administrados, pero no los borraría. Una vez que se complete la sincronización, puedes quitar el objeto RootSync o RepoSync.

Si la intención es borrar estos recursos administrados, primero puedes borrar los recursos administrados mediante la modificación del objeto RootSync o RepoSync para sincronizar desde un directorio de Git vacío. Una vez que se complete la sincronización, puedes quitar el objeto RootSync o RepoSync.

Si se borró el objeto RootSync o RepoSync antes de dejar de administrar o borrar recursos administrados, puedes volver a agregar el objeto RootSync o RepoSync, dejar de administrar o borrar los recursos administrados y, luego, borrar el objeto RootSync o RepoSync de nuevo.

El ajuste de escala automático horizontal de pods no funciona

El Sincronizador de configuración administra todos los campos que especificas en los manifiestos en tu repositorio de Git. Puede haber competencias de recursos cuando dos controladores intentan controlar el mismo campo y estas competencias de recursos ocurren cuando intentas usar el ajuste de escala automático horizontal de Pods con el Sincronizador de configuración.

Si deseas usar el Ajuste de escala automático horizontal de Pods, debes permitir que el escalador automático horizontal de Pods administre el campo spec.replicas mediante la eliminación de ese campo de todos los manifiestos en el repositorio de Git. De lo contrario, el Sincronizador de configuración intenta revertir los cambios a lo que se especifica en el repositorio.

PersistentVolumeClaim se encuentra en estado de pérdida

Cuando se actualiza un clúster de Kubernetes a la versión 1.22 y posteriores, existe la posibilidad de que las PersistentVolumeClaims administradas puedan dar como resultado un estado Lost. Esto ocurre cuando la vinculación de PersistentVolumes y PersistentVolumeClaims se definen con el campo claimRef dentro de un recurso PersistentVolume. Los cambios ascendentes de Kubernetes hicieron que el campo claimRef fuera atómico, lo que genera este error, ya que impide que los diferentes propietarios de campos para los distintos subcampos claimRef se apliquen del servidor.

Hasta que este problema se resuelva en Kubernetes ascendente (herramienta de seguimiento de errores de GitHub, error de corrección de PR), recomendamos que actualices tus recursos PersistentVolume y PersistentVolumeClaim. para usar un método de vinculación alternativo. En su lugar, la vinculación se puede configurar dentro del spec.volumeName del recurso de PersistentVolumeClaim. Esto se puede hacer en las versiones 1.21 de Kubernetes o en versiones anteriores para evitar interrupciones cuando actualizas a la versión 1.22.

El siguiente es un ejemplo mínimo de vinculación de staging-pvc a staging-pv:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: staging-pvc
  namespace: staging
spec:
  volumeName: staging-pv
  ...

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: staging-pv
spec:
  ...

El uso de volumeName en lugar de claimRef para la vinculación no garantiza ningún privilegio de vinculación al PersistentVolume.

Solucionar problemas de mensajes de error

KNV1045: No se permiten las configuraciones con estado especificado

Si especificas cualquier campo status en el repositorio de origen, verás KNV1045: las configuraciones con el “estado” especificado no están permitidas. No se permite usar el Sincronizador de configuración para sincronizar el campo status. Otro controlador debe administrar y actualizar el campo status en el clúster de forma dinámica. Si el Sincronizador de configuración intenta controlar el estado deseado del campo status, compite con el controlador responsable de administrar el campo status.

Para corregir este error, quita el campo status del repositorio de código fuente. En la configuración de terceros que no te pertenece, usa parches kustomize para quitar los campos status especificados en tus manifiestos de forma masiva.

KNV2004: No se puede sincronizar el repositorio en el contenedor de git-sync.

El Sincronizador de configuración crea una clonación superficial de tu repositorio de Git. En casos excepcionales, es posible que el Sincronizador de configuración no pueda encontrar la confirmación desde la clonación superficial. Cuando esto sucede, el Sincronizador de configuración aumenta la cantidad de confirmaciones de Git que se recuperarán.

Para establecer la cantidad de confirmaciones de Git que se recuperarán, configura el campo spec.override.gitSyncDepth en un objeto RootSync o RepoSync:

• Si no se proporciona este campo, el Sincronizador de configuración lo configura de forma automática.
• El Sincronizador de configuración realiza una clonación completa si este campo es 0 y una clonación superficial si este campo es mayor que 0.

• No se puede establecer este campo en un valor negativo.

  Si instalaste el Sincronizador de configuración con la consola de Google Cloud o Google Cloud CLI, crea un objeto RootSync editable para poder configurar spec.override.gitSyncDepth. Para obtener más información, consulta Configura el Sincronizador de configuración con los comandos de kubectl.

A continuación, se muestra un ejemplo de la configuración de la cantidad de confirmaciones de Git para recuperar en 88:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  override:
    gitSyncDepth: 88
  git:
    ...

Ejecuta el siguiente comando para verificar que el cambio surta efecto (GIT_SYNC_DEPTH debe establecerse como 88 en el campo data del ConfigMap root-reconciler-git-sync):

kubectl get cm root-reconciler-git-sync -n config-management-system -o yaml

Puedes anular la cantidad de confirmaciones de Git para recuperar en un conciliador de espacios de nombres de manera similar.

Error: Permiso denegado.

Si recibes un error similar al siguiente ejemplo cuando intentas configurar el Sincronizador de configuración, es posible que no tengas la función de administrador de GKE Hub:

Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

Para asegurarte de tener los permisos necesarios, asegúrate de haber otorgado los roles de IAM necesarios.

Error: el webhook de admisión rechazó una solicitud

Si recibes el siguiente error cuando intentas aplicar un cambio en un campo que administra el Sincronizador de configuración, es posible que hayas realizado un cambio conflictivo:

error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified

Cuando declaras un campo en una configuración y el repositorio se sincroniza con un clúster, el Sincronizador de configuración administra ese campo. Cualquier cambio que intentes hacer en ese campo es un cambio conflictivo.

Por ejemplo, si tienes una configuración de implementación en el repositorio con una etiqueta environment:prod y tratas de cambiar esa etiqueta a environment:dev en el clúster, habrá un cambio conflictivo y recibirás el mensaje de error anterior. Sin embargo, si agregas una etiqueta nueva (por ejemplo, tier:frontend) a la implementación, no habrá un conflicto.

Si quieres que el Sincronizador de configuración ignore los cambios en un objeto, puedes agregar la anotación que se describe en Ignora las mutaciones de objetos.

Error: se agotó el tiempo de espera de E/S de la solicitud de webhook

Si recibes el siguiente error cuando el conciliador intenta aplicar una configuración al clúster, el puerto de webhook de admisión 8676 podría ser bloqueado por el firewall a la red del plano de control:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout

Para resolver este problema, agrega una regla de firewall a fin de admitir el puerto 8676, que el webhook de admisión del Sincronizador de configuración usa para la prevención de desvíos.

Error: se rechazó la conexión de webhook de admisión

Si recibes el siguiente error cuando el conciliador intenta aplicar una configuración al clúster, el webhook de admisión aún no está listo:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused

Es un error transitorio que puedes ver cuando se inicializa el Sincronizador de configuración. Si el problema persiste, consulta la implementación del webhook de admisión para ver si sus pods se pueden programar y están en buen estado.

kubectl describe deploy admission-webhook -n config-management-system

kubectl get pods -n config-management-system -l app=admission-webhook

Error: No se puede activar el Secret de Git

Si recibes el siguiente error cuando el contenedor git-sync intenta sincronizar un repositorio con un Secret, entonces el Secret de Git no se activó correctamente en el contenedor git-sync:

KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory

Esto puede deberse a que cambiaste el tipo de autenticación del repositorio de Git de none, gcenode o gcpserviceaccount a otros tipos que necesiten un Secret.

Para resolver este problema, ejecuta los siguientes comandos a fin de reiniciar Reconciler Manager y los conciliadores:

# Stop the reconciler-manager Pod. The reconciler-manager Deployment will spin
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system

# Delete the reconciler Deployments. The reconciler-manager will recreate the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system

Error: No se pueden extraer bases remotas de repositorios públicos.

Si recibes el siguiente error durante el proceso de renderizado, cuando intentas extraer bases remotas de repositorios públicos, el proceso de renderización no se completa de forma correcta:

KNV1068: failed to run kustomize build in /repo/source/0a7fd88d6c66362584131f9dfd024024352916af/remote-base, stdout:...
no 'git' program on path: exec: "git": executable file not found in $PATH

For more information, see https://g.co/cloud/acm-errors#knv1068

Para resolver este problema, establece spec.override.enableShellInRendering como true.

Los contenedores del Pod del conciliador están OOMKilled

Puedes anular las solicitudes y los límites de CPU o memoria de un repositorio raíz o de espacio de nombres. Para anular estos valores, usa el campo spec.override.resources de un objeto RootSync o RepoSync. Si instalaste el Sincronizador de configuración con la consola de Google Cloud o Google Cloud CLI, crea un objeto RootSync editable para poder configurar spec.override.resources. Para obtener más información, consulta Configura el Sincronizador de configuración con los comandos de kubectl.

En el siguiente ejemplo, se muestra cómo anular los límites de CPU y memoria del contenedor reconciler, y la solicitud de CPU y el límite de memoria del contenedor git-sync de un conciliador raíz. Puede anular los contenedores git-sync, oci-sync, helm-sync, hydration-controller y reconciler. Se permite la anulación parcial: cuando no se proporciona un valor de anulación para una solicitud o un límite de recursos, se usa el valor de recurso predeterminado de la solicitud o el límite.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: "unstructured"
  override:
    resources:
    - containerName: "reconciler"
      cpuLimit: "800m"
      memoryLimit: "500Mi"
    - containerName: "git-sync"
      cpuRequest: "100m"
      memoryLimit: "400Mi"
  git:
     ...

Ejecute el siguiente comando para verificar que se apliquen los límites de recursos nuevos:

kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml

Puedes anular los límites de recursos de un conciliador de espacio de nombres de manera similar.

Error: Un espacio de nombres se atasca en la fase de Terminating

Un espacio de nombres atascado en la fase de Terminating debe tener la siguiente condición:

    message: 'Failed to delete all resource types, 1 remaining: admission webhook
      "v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
      is not authorized to delete managed resource "_configmap_bookstore_cm1"'
    reason: ContentDeletionFailed
    status: "True"
    type: NamespaceDeletionContentFailure

Esto sucede cuando intentas borrar un espacio de nombres de un repositorio raíz, pero algunos objetos bajo el espacio de nombres todavía están administrados de manera activa por un conciliador de espacio de nombres. Cuando se borra un espacio de nombres, el controlador de espacio de nombres, cuya cuenta de servicio es system:serviceaccount:kube-system:namespace-controller, intenta borrar todos los objetos que se encuentran en ese espacio de nombres. Sin embargo, el webhook de admisión del Sincronizador de configuración solo permite que el conciliador raíz o de espacio de nombres borre estos objetos y no permite que el controlador de espacio de nombres los pueda borrar.

La solución alternativa es borrar el webhook de admisión del Sincronizador de configuración:

kubectl delete deployment.apps/admission-webhook -n config-management-system

El operador de Config Management recrea el webhook de admisión del Sincronizador de configuración.

Si esta solución alternativa no funciona, es posible que debas reinstalar el Sincronizador de configuración.

Para que el error vuelva a ocurrir, quita el repositorio del espacio de nombres antes de quitar el espacio de nombres.

Error: No se encontró el campo webhooks en ValidtingWebhookConfiguration

Si encuentras los siguientes errores en los registros de webhook de admisión del Sincronizador de configuración cuando ejecutas kubectl logs -n config-management-system -l app=admission-webhook, haz lo siguiente:

cert-rotation "msg"="Unable to inject cert to webhook." "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "gvk"={"Group":"admissionregistration.k8s.io","Version":"v1","Kind":"ValidatingWebhookConfiguration"} "name"="admission-webhook.configsync.gke.io"
controller-runtime/manager/controller/cert-rotator "msg"="Reconciler error" "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "name"="admission-webhook-cert" "namespace"="config-management-system"

Esto significa que root-reconciler no sincronizó ningún recurso con el clúster. Esto podría deberse a que root-reconciler aún no está listo o no hay nada que sincronizar desde el repositorio de Git (por ejemplo, el directorio de sincronización está vacío). Si el problema persiste, verifica el estado de root-reconciler:

kubectl get pods -n config-management-system -l configsync.gke.io/reconciler=root-reconciler

Si root-reconciler está en un bucle de fallas u OOMKilled, aumenta sus límites de recursos.

Error: No se pudo crear el exportador de Stackdriver/Google Cloud

Cuando un componente de Open Telemetry Collector no puede acceder a la cuenta de servicio predeterminada en el mismo espacio de nombres, es posible que notes que el Pod otel-collector en config-management-monitoring se encuentra en el estado CrashLoopBackoff o que veas un mensaje de error similar al siguiente:

Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Error: Permission monitoring.timeSeries.create denied (or the resource may not exist).

Este problema suele ocurrir cuando Workload Identity está habilitado en un clúster.

A fin de resolver este problema, sigue las instrucciones en Supervisa el Sincronizador de configuración para otorgar permiso de escritura de métricas a la cuenta de servicio predeterminada.

Si el error persiste después de configurar IAM, reinicia el Pod otel-collector para que se apliquen los cambios.

Si usas una solución de supervisión personalizada, pero bifurcaste el ConfigMap predeterminado de otel-collector-googlecloud, verifica y reubica cualquier diferencia.

Error: Falló la verificación del certificado del servidor

Si el contenedor git-sync no puede clonar el repositorio de Git y muestra el siguiente mensaje de error server certificate verification failed. CAfile: /etc/ca-cert/cert CRLfile: none, significa que el servidor Git está configurado con certificados de una autoridad certificadora (CA) personalizada. Sin embargo, la CA personalizada no está configurada de forma correcta, lo que provoca que el contenedor git-sync no clonar el repositorio de Git.

Primero, puedes verificar si se especificó el campo spec.git.caCertSecretRef.name en tu objeto RootSync o RepoSync y, también, si el objeto secreto existe.

Si el campo se configuró y el objeto secreto existe, asegúrate de que este contenga los certificados completos.

Según cómo se aprovisione la AC personalizada, los enfoques para verificar los certificados completos pueden variar.

A continuación, puedes ver un ejemplo de cómo enumerar los certificados de servidor:

echo -n | openssl s_client -showcerts -connect HOST:PORT -servername SERVER_NAME 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Puedes solicitar a tu equipo de administración de red que obtenga los certificados de CA por ti.