Ignorar campos sin especificar

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

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 los 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. Es decir, cuando utilizas kubectl get <resource kind> <resource name> -oyaml, muchos campos en la especificación de recursos no están en el YAML aplicado.

Como ejemplo, supongamos que el esquema de CRD te permite especificar dos campos llamados foo y bar en la especificación, mientras que el 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 APIs de Google Cloud, se recomienda cambiar este comportamiento predeterminado y omitir la propagación de la especificación de recursos con campos sin especificar.

Omitir la propagación de campos sin especificar en la especificación

Cuando creas tu archivo YAML, puedes especificar el valor de la anotación cnrm.cloud.google.com/state-into-spec como absent. Con esta acción, se 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

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

Si ya creaste el recurso, pero deseas cambiar el valor de esta anotación por 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, en el siguiente paso, la eliminación 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 con más detalle la diferencia que presenta 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

Supongamos también 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"

Mientras que, si 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

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

Administrar campos sin especificar en una lista de forma externa

Config Connector trata todos los campos de lista en la especificación de recursos como campos atómicos. Como resultado, de forma predeterminada, Config Connector revertirá los cambios realizados en un subcampo de la lista desde fuera de Config Connector. Sin embargo, puedes usar esta anotación para permitir que Config Connector deje de administrar los subcampos de la lista. Para obtener más información, consulta Comportamiento de los campos de lista en las especificaciones de recursos.

Resolver conflictos 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 competencia entre la herramienta de administración de configuración y Config Connector. Un ejemplo es el error de KNV2005 que se explica en la guía de solución de problemas. La causa raíz de estos tipos de problemas se debe a los siguientes motivos:

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

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

Resolver problemas de simetría GET/PUT

La simetría GET/PUT se refiere 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 que propaga Config Connector en la especificación de recursos son el resultado de una solicitud GET. Esto significa que, en futuras conciliaciones, Config Connector podría enviar una solicitud PUT/PATCH a la API de Google Cloud subyacente con estos valores de campo sin especificar aprendidos de la solicitud GET. Por lo general, esto no es un problema, pero es posible que algunas API de Google Cloud rechacen la solicitud PUT/PATCH debido a estos valores de campo no especificados. En el mismo ejemplo, el spec.barz.bz2 propagado con el valor "bz2" puede generar un error de cliente HTTP 400, o bien otras respuestas inesperadas si la implementación de la API infringe el principio de simetría GET/PUT.

Para evitar esta categoría de problemas, puedes probar la configuración de cnrm.cloud.google.com/state-into-spec: absent y verificar si los errores durante la conciliación desaparecerá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 campos no especificados. 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 tu YAML original, no debes usar esta anotación, ya que omitirá la propagación del valor de spec.address en la especificación del recurso de Kubernetes.