Ignorar campos sin especificar

En este documento, se explica cómo cambiar los campos de especificaciones predeterminados que propagan el comportamiento mediante la anotación cnrm.cloud.google.com/state-into-spec y cuándo debes cambiarlo.

Como se explica en Administra campos de forma externa, cuando Config Connector crea un recurso en Google Cloud, los campos que no se especifican en la especificación toman valores de la API, a menos que no sean legibles (por ejemplo, no están disponibles mediante una solicitud HTTP GET).

Esto significa que, de forma predeterminada, los campos que no se especificaron en el YAML original siempre aparecen en la especificación del recurso de Kubernetes. Esto significa que, cuando haces kubectl get <resource kind> <resource name> -oyaml, muchos campos de la especificación del recurso no están en el YAML que aplicaste.

Como ejemplo, supongamos que el esquema de CRD te permite especificar dos campos llamados foo y bar en la especificación, mientras que tu archivo YAML aplicado solo tiene especificado foo:

spec:
  foo: "foo"

Notarás que aparece otro campo llamado bar en el recurso de Kubernetes si el YAML se aplica correctamente y el recurso es UpToDate:

spec:
  foo: "foo"
  bar: "bar"

Debido a la complejidad de la interacción entre Config Connector y las API de Google Cloud, es posible que desees cambiar este comportamiento predeterminado y omitir la propagación de la especificación de recursos con campos sin especificar.

Omite los campos no especificados en la especificación

Cuando creas el archivo YAML, puedes especificar el valor de la anotación cnrm.cloud.google.com/state-into-spec como absent. Esto omite la propagación de campos sin especificar en la especificación de recursos de Kubernetes:

metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent

Si no se especifica, esta anotación tiene un valor predeterminado de merge, lo que significa que Config Connector propaga todos los campos sin especificar en la especificación. Esta anotación es inmutable, lo que significa que no puedes actualizar el valor de la anotación de un recurso de Config Connector existente.

Si ya creaste el recurso, pero deseas cambiar el valor de esta anotación para un comportamiento de propagación diferente, debes seguir estos pasos:

  1. Edita y agrega la anotación cnrm.cloud.google.com/deletion-policy: abandon al recurso de Kubernetes existente para asegurarte de que la eliminación en el siguiente paso no borre el recurso subyacente de Google Cloud.

  2. Borra el recurso del clúster de Kubernetes.

  3. Agrega la anotación cnrm.cloud.google.com/state-into-spec: absent al YAML del recurso.

  4. (Opcional) quita cnrm.cloud.google.com/deletion-policy: abandon del YAML.

  5. Aplica el YAML actualizado.

Para explicar mejor la diferencia que introdujo esta anotación, supongamos que hay una especificación con el siguiente esquema:

foo1: string
foo2: string
bars:
- bar:
    br1: string
    br2: string
barz:
  bz1: string
  bz2: string

También supongamos que especificaste la especificación en tu YAML de la siguiente manera:

spec:
  foo1: "foo1"
  bars:
  - br1: "1_br1"
  - br1: "2_br1"
  barz:
    bz1: "bz1"

De forma predeterminada, la especificación propagada en el recurso de Kubernetes creado podría ser la siguiente:

spec:
  foo1: "foo1"
  foo2: "foo2"
  bars:
  - br1: "1_br1"
    br2: "1_br2"
  - br1: "2_br1"
    br2: "2_br2"
  barz:
    bz1: "bz1"
    bz2: "bz2"

Si bien configuras cnrm.cloud.google.com/state-into-spec: absent, la especificación final en el recurso de Kubernetes creado será la siguiente:

spec:
  foo1: "foo1"
  bars:
  - br1: "1_br1"
  - br1: "2_br1"
  barz:
    bz1: "bz1"

Cuándo usar cnrm.cloud.google.com/state-into-spec: absent

Existen algunas situaciones comunes en las que puedes establecer cnrm.cloud.google.com/state-into-spec: absent.

Administrar los campos sin especificar en una lista externamente

Config Connector trata todos los campos de lista de las especificaciones de recursos como campos atómicos. Como resultado, de manera predeterminada, Config Connector revertirá el cambio realizado en un subcampo de la lista desde fuera del Config Connector. Sin embargo, puedes usar esta anotación para permitir que Config Connector administre los subcampos de la lista. Si deseas obtener más información, consulta Comportamiento para enumerar campos en las especificaciones de los recursos.

Resolver la pelea entre las herramientas de administración de configuración y Config Connector

Si usas herramientas de administración de configuración, como el Sincronizador de configuración o el CD de Argo, es posible que notes una pelea entre la herramienta de administración de configuración y Config Connector. Un ejemplo es el error KNV2005 que se explica en la guía de solución de problemas. Las causas principales de estos tipos de problemas son las siguientes:

  1. Config Connector propagará y configurará de forma predeterminada los valores no especificados en la lista; la spec.bars[0].br2 es un ejemplo.
  2. Las herramientas de administración de configuración y Config Connector tratan los campos de lista como atómicos, por lo que el spec.bars[0].br2 agregado se trata como un desvío por herramientas de administración de configuración y se quitará para corregir el drift.

Para resolver estos problemas, puedes configurar cnrm.cloud.google.com/state-into-spec: absent de modo que Config Connector no agregue el campo spec.bars[0].br2 no especificado a la especificación.

Resolver problemas de simetrías GET y PUT

La simetría GET/PUT hace referencia a un principio de diseño en la API de REST. Específicamente, significa que, cuando se envía una respuesta GET como una solicitud PUT a la misma URL, el resultado esperado es una respuesta HTTP 200 OK sin cambios en el estado del recurso REST subyacente.

Los campos sin especificar propagados por Config Connector en la especificación de recursos son el resultado de una solicitud GET. Esto significa que, en futuras conciliaciones, Config Connector puede enviar una solicitud PUT/PATCH a la API de Google Cloud subyacente, con estos valores de campo sin especificar aprendidos a partir de la solicitud GET. Por lo general, esto no es un problema, pero es posible que algunas APIs de Google Cloud rechacen la solicitud PUT/PATCH debido a estos valores de campo sin especificar. En el mismo ejemplo, el spec.barz.bz2 propagado con el valor “bz2” puede generar un error de cliente HTTP 400 u otras respuestas inesperadas si la implementación de la API incumple el principio de simetría GET/PUT.

Para evitar esta categoría de problemas, puedes experimentar con la configuración de cnrm.cloud.google.com/state-into-spec: absent y verificar si desaparecerán los errores durante la conciliación.

Cuándo evitar cnrm.cloud.google.com/state-into-spec: absent

Debes evitar configurar cnrm.cloud.google.com/state-into-spec: absent si tu solución depende de los valores propagados de los campos sin especificar. Por ejemplo, si usas un recurso ComputeAddress y necesitas el valor spec.address generado por el servidor, que podría ser un campo no especificado en el YAML original, no debes usar esta anotación, ya que omitirá la propagación del valor de spec.address en la especificación de recursos de Kubernetes.