En este documento, se explica cómo cambiar los campos de especificación 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 se puedan leer (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 las especificaciones 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 aplicado.
Como ejemplo, supongamos que el esquema de CRD te permite especificar dos campos llamados foo y bar en las especificaciones, mientras que tu archivo YAML aplicado solo tiene foo especificado:
spec:
foo: "foo"
Notará 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 no especificados.
Omitir completar campos sin especificar 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 no especificados 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. 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:
Edita y agrega la anotación
cnrm.cloud.google.com/deletion-policy: abandonal recurso de Kubernetes existente para asegurarte de que la eliminación en el siguiente paso no borre el recurso subyacente de Google Cloud.Borra el recurso del clúster de Kubernetes.
Agrega la anotación
cnrm.cloud.google.com/state-into-spec: absental YAML del recurso.(Opcional) quita
cnrm.cloud.google.com/deletion-policy: abandondel YAML.Aplica el YAML actualizado.
Para explicar mejor 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
Además, 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 estableces 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 podrías establecer cnrm.cloud.google.com/state-into-spec: absent.
Administrar los campos sin especificar en una lista de forma externa
Config Connector trata todos los campos de lista de las especificaciones de recursos como campos atómicos. Como resultado, Config Connector revertirá el cambio que realizaste de forma predeterminada 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 en la lista. Si deseas obtener más información, consulta Comportamiento para enumerar campos en las especificaciones de recursos.
Resolver combate 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:
- Config Connector propagará y establecerá los valores sin especificar predeterminados en la lista en la especificación.
spec.bars[0].br2es un ejemplo. - Las herramientas de administración de configuración y Config Connector tratan los campos de lista como atómicos, por lo que las
spec.bars[0].br2agregadas se tratan como un desvío por herramientas de administración de configuración y se quitarán para corregirdrift.
Para resolver estos problemas, puedes configurar cnrm.cloud.google.com/state-into-spec: absent a fin de que Config Connector no agregue el campo spec.bars[0].br2 no especificado a la especificación.
Resolver problemas de simetría 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 que propaga Config Connector en la especificación del recurso son el resultado de una solicitud GET. Esto significa que, en futuras conciliaciones, Config Connector puede enviar una solicitud PUT/PATCH a la API subyacente de Google Cloud con estos valores de campo no especificados 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 sin especificar. En el mismo ejemplo, la spec.barz.bz2 propagada 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 configurar cnrm.cloud.google.com/state-into-spec: absent y verificar si desaparecen 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 puede 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 de recursos de Kubernetes.