Ignora los campos sin especificar

En esta página, se explica el comportamiento de propagación predeterminado de los campos spec y cómo cambiar el comportamiento predeterminado de Merge al comportamiento recomendado Absent. Es posible que esta página no se aplique si usas un CRD agregado en la versión 1.114.0 y versiones posteriores, ya que esos CRD solo usan el comportamiento Absent. Para obtener una lista de las CRD que admiten Merge, consulta la sección CRD con compatibilidad con Merge de esta página.

Comportamientos de propagación de campos spec

Cuando Config Connector crea un recurso, los campos que no se especifican en la especificación del recurso de Kubernetes pueden tener dos comportamientos de propagación predeterminados diferentes: Absent y Merge.

Ausente

Absent es el comportamiento recomendado. Config Connector no propagará ningún campo no especificado en la especificación.

Para las CRD que se agregaron en la versión 1.114.0 y posteriores, el comportamiento de propagación predeterminado es Absent. Este también es el único comportamiento de propagación que admiten esas CRD. El valor de la anotación cnrm.cloud.google.com/state-into-spec es absent en estos CR de recursos.

Combinar

Merge es un comportamiento no admitido en los CRD agregados en 1.114.0 y versiones posteriores. Los campos spec toman valores de la API después de una conciliación correcta, a menos que no sean legibles. Puedes encontrar más detalles en Administra campos de forma externa.

Para los CRD compatibles con la versión 1.113.0 y versiones anteriores de Config Connector, el comportamiento de propagación predeterminado es Merge. Para obtener una lista de las CRD que admiten Merge, consulta la sección CRD con compatibilidad con Merge de esta página. El valor predeterminado de la anotación cnrm.cloud.google.com/state-into-spec es merge en estos CR de recursos. También puedes configurar el comportamiento de propagación para que sea Absent siguiendo las instrucciones en Omitir la propagación de campos no especificados en la especificación.

De forma predeterminada, en estos CR de recursos, los campos que no se especificaron en tu archivo YAML original siempre aparecen en la especificación del CR. Esto significa que, cuando ejecutas kubectl get <resource kind> <resource name> -oyaml, muchos campos de la especificación no están en el YAML aplicado.

A modo de 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 CR si se aplica el archivo YAML correctamente y el recurso está UpToDate:

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

Debido a la complejidad de la interacción entre Config Connector y las APIs deGoogle Cloud , te recomendamos que cambies este comportamiento predeterminado y omitas propagar la especificación de recursos de Kubernetes con campos no especificados.

Omitir la propagación de campos no especificados en la especificación

Puedes omitir la propagación de campos no especificados en la especificación para las CRD compatibles con la versión 1.113.0 y versiones anteriores de Config Connector de una de las siguientes maneras:

  • Configura la anulación de stateIntoSpec a nivel del clúster o del espacio de nombres como Absent.
  • Especifica el valor de la anotación cnrm.cloud.google.com/state-into-spec como absent para el recurso.

Configura la anulación de stateIntoSpec a nivel del clúster o del espacio de nombres

Cuando instales Config Connector o actualices la instalación de Config Connector, puedes configurar la anulación de stateIntoSpec a nivel del clúster o del espacio de nombres para que sea Absent en la CR de ConfigConnector o ConfigConnectorContext.

spec:
  stateIntoSpec: Absent

Esto hace que Absent sea el comportamiento predeterminado de los campos spec que propagan los recursos nuevos que se crean en el clúster o en el espacio de nombres cuando no especificas la anotación cnrm.cloud.google.com/state-into-spec en los archivos YAML del recurso nuevo. Esto significa que Config Connector omitirá propagar campos no especificados en la especificación de recursos de Kubernetes para estos recursos.

El campo stateIntoSpec no tiene un valor predeterminado. Config Connector determinará el comportamiento de propagación de los campos spec según el valor de la anotación cnrm.cloud.google.com/state-into-spec y seguirá la lógica que se indica a continuación para determinar el valor de la anotación:

  1. Usa el valor de la anotación cnrm.cloud.google.com/state-into-spec directamente si está especificado y es válido.
  2. Si no se especifica la anotación, usa el valor correspondiente del campo stateIntoSpec en la CR de ConfigConnectorContext.
  3. Si no existe la CR de ConfigConnectorContext o si no se especifica el campo stateIntoSpec, usa el valor correspondiente del campo stateIntoSpec en la CR de ConfigConnector.
  4. Si no existe la CR de ConfigConnector o no se especifica el campo stateIntoSpec, usa el comportamiento predeterminado basado en la CRD que se describe en Comportamientos de propagación de campos spec.

Ten en cuenta que las únicas CRDs de comportamiento de propagación que se agregaron en la versión 1.114.0 y versiones posteriores son Absent, independientemente de la anotación cnrm.cloud.google.com/state-into-spec o los campos stateIntoSpec en la CR de ConfigConnector o la CR de ConfigConnectorContext.

Si ya creaste el recurso, pero quieres cambiar el comportamiento de propagación de los campos spec a Absent, debes hacer lo siguiente:

  1. Asegúrate de que la anulación de stateIntoSpec a nivel del clúster o del espacio de nombres sea Absent en la CR de ConfigConnector o ConfigConnectorContext.

  2. Abandonar y adquirir el recurso Asegúrate de que la configuración de YAML que se usa para la adquisición no tenga la anotación cnrm.cloud.google.com/state-into-spec.

Especifica la anotación cnrm.cloud.google.com/state-into-spec a nivel del recurso

Cuando crees tu 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

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 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 obtener 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 Google Cloud subyacente.

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

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

  4. Quita cnrm.cloud.google.com/deletion-policy: abandon del archivo YAML (opcional).

  5. Aplica el archivo YAML actualizado.

Para explicar con más detalle la diferencia que introduce 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"

Luego, 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

En la mayoría de los casos, querrás configurar cnrm.cloud.google.com/state-into-spec: absent para obtener el comportamiento de propagación de Absent para los campos spec. Estos son los casos más comunes que se beneficiarán del comportamiento de propagación de Absent.

Administra campos no especificados en una lista de forma externa

Config Connector trata todos los campos de lista en la especificación de recursos de Kubernetes como campos atómicos. Como resultado, de forma predeterminada, Config Connector revertirá el cambio que realices 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 en la lista. Para obtener más información, consulta Comportamiento de los campos de lista en la especificación de recursos.

Cómo resolver conflictos entre las herramientas de administración de configuraciones y Config Connector

Si usas herramientas de administración de configuraciones, como Config Sync o Argo CD, es posible que notes una disputa entre la herramienta de administración de configuraciones y Config Connector. Un ejemplo es el error KNV2005 que se explica en la guía de solución de problemas. La causa raíz de este tipo de problemas es la siguiente:

  1. Config Connector propagará y establecerá de forma predeterminada los valores no especificados en la lista de la especificación. spec.bars[0].br2 es un ejemplo.
  2. Tanto las herramientas de administración de configuraciones como Config Connector tratan los campos de lista como atómicos, por lo que las herramientas de administración de configuraciones consideran que el spec.bars[0].br2 agregado es un desvío 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.

Cómo resolver problemas de simetría GET/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 no especificados que propaga Config Connector en la especificación de recursos de Kubernetes son el resultado de una solicitud GET. Esto significa que, en futuras reconciliaciones, Config Connector puede enviar una solicitud PUT/PATCH a la API subyacente deGoogle 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 APIs deGoogle 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 alguna otra respuesta inesperada 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 los errores durante la conciliación desaparecen.

Estado observado

Si necesitas configurar cnrm.cloud.google.com/state-into-spec: absent, pero tu solución depende de los valores propagados de campos no especificados, verifica si estos campos existen en status.observedState en el esquema de CRD. Si están representados en status.observedState, puedes configurar cnrm.cloud.google.com/state-into-spec: absent y, aun así, acceder a los valores de los campos no especificados después de una conciliación exitosa.

El campo status.observedState contiene el estado en vivo de los campos seleccionados y observados del recurso que Config Connector observó en la última conciliación correcta. Los campos observados se seleccionan si son dependencias de casos de uso comunes y se calculan como campos spec. Puedes encontrar los campos observados en los esquemas de CRD.

Si no encuentras los campos observados que deseas, verifica si hay un problema existente o abre uno nuevo en las herramientas públicas de seguimiento de errores.

Tipos compatibles con Merge

Los siguientes son todos los tipos de Config Connector que admiten el comportamiento de propagación de Merge:

  • AccessContextManagerAccessLevel
  • AccessContextManagerAccessPolicy
  • AccessContextManagerServicePerimeter
  • AlloyDBBackup
  • AlloyDBCluster
  • AlloyDBUser
  • ApigeeEnvironment
  • ApigeeOrganization
  • ArtifactRegistryRepository
  • BigQueryDataset
  • BigQueryJob
  • BigQueryTable
  • BigtableAppProfile
  • BigtableGCPolicy
  • BigtableInstance
  • BigtableTable
  • BillingBudgetsBudget
  • BinaryAuthorizationAttestor
  • BinaryAuthorizationPolicy
  • CertificateManagerCertificate
  • CertificateManagerCertificateMap
  • CertificateManagerCertificateMapEntry
  • CloudBuildTrigger
  • CloudFunctionsFunction
  • CloudIdentityGroup
  • CloudIdentityMembership
  • CloudSchedulerJob
  • ComputeAddress
  • ComputeBackendBucket
  • ComputeBackendService
  • ComputeDisk
  • ComputeExternalVPNGateway
  • ComputeFirewall
  • ComputeFirewallPolicy
  • ComputeFirewallPolicyAssociation
  • ComputeForwardingRule
  • ComputeHTTPHealthCheck
  • ComputeHTTPSHealthCheck
  • ComputeHealthCheck
  • ComputeImage
  • ComputeInstance
  • ComputeInstanceGroup
  • ComputeInstanceGroupManager
  • ComputeInstanceTemplate
  • ComputeInterconnectAttachment
  • ComputeNetwork
  • ComputeNetworkEndpointGroup
  • ComputeNetworkFirewallPolicy
  • ComputeNetworkPeering
  • ComputeNodeGroup
  • ComputeNodeTemplate
  • ComputePacketMirroring
  • ComputeProjectMetadata
  • ComputeRegionNetworkEndpointGroup
  • ComputeReservation
  • ComputeResourcePolicy
  • ComputeRoute
  • ComputeRouter
  • ComputeRouterInterface
  • ComputeRouterNAT
  • ComputeRouterPeer
  • ComputeSSLCertificate
  • ComputeSSLPolicy
  • ComputeSecurityPolicy
  • ComputeServiceAttachment
  • ComputeSharedVPCHostProject
  • ComputeSharedVPCServiceProject
  • ComputeSnapshot
  • ComputeSubnetwork
  • ComputeTargetGRPCProxy
  • ComputeTargetHTTPProxy
  • ComputeTargetHTTPSProxy
  • ComputeTargetInstance
  • ComputeTargetPool
  • ComputeTargetSSLProxy
  • ComputeTargetTCPProxy
  • ComputeTargetVPNGateway
  • ComputeURLMap
  • ComputeVPNGateway
  • ComputeVPNTunnel
  • ConfigControllerInstance
  • ContainerAnalysisNote
  • ContainerAttachedCluster
  • ContainerCluster
  • ContainerNodePool
  • DLPDeidentifyTemplate
  • DLPInspectTemplate
  • DLPJobTrigger
  • DLPStoredInfoType
  • DNSManagedZone
  • DNSPolicy
  • DNSRecordSet
  • DataFusionInstance
  • DataflowFlexTemplateJob
  • DataflowJob
  • DataprocAutoscalingPolicy
  • DataprocCluster
  • DataprocWorkflowTemplate
  • EdgeContainerCluster
  • EdgeContainerNodePool
  • EdgeContainerVpnConnection
  • EdgeNetworkNetwork
  • EdgeNetworkSubnet
  • EventarcTrigger
  • FilestoreBackup
  • FilestoreInstance
  • FirestoreIndex
  • Carpeta
  • GKEHubFeature
  • GKEHubMembership
  • IAMAccessBoundaryPolicy
  • IAMAuditConfig
  • IAMCustomRole
  • IAMPartialPolicy
  • IAMPolicy
  • IAMPolicyMember
  • IAMServiceAccount
  • IAMServiceAccountKey
  • IAMWorkforcePool
  • IAMWorkforcePoolProvider
  • IAMWorkloadIdentityPool
  • IAMWorkloadIdentityPoolProvider
  • IAPBrand
  • IAPIdentityAwareProxyClient
  • IdentityPlatformConfig
  • IdentityPlatformOAuthIDPConfig
  • IdentityPlatformTenant
  • IdentityPlatformTenantOAuthIDPConfig
  • KMSCryptoKey
  • KMSKeyRing
  • LoggingLogBucket
  • LoggingLogExclusion
  • LoggingLogSink
  • LoggingLogView
  • MemcacheInstance
  • MonitoringAlertPolicy
  • MonitoringGroup
  • MonitoringMetricDescriptor
  • MonitoringMonitoredProject
  • MonitoringNotificationChannel
  • MonitoringService
  • MonitoringServiceLevelObjective
  • MonitoringUptimeCheckConfig
  • NetworkConnectivityHub
  • NetworkConnectivitySpoke
  • NetworkSecurityAuthorizationPolicy
  • NetworkSecurityClientTLSPolicy
  • NetworkSecurityServerTLSPolicy
  • NetworkServicesEndpointPolicy
  • NetworkServicesGRPCRoute
  • NetworkServicesGateway
  • NetworkServicesHTTPRoute
  • NetworkServicesMesh
  • NetworkServicesTCPRoute
  • NetworkServicesTLSRoute
  • OSConfigGuestPolicy
  • OSConfigOSPolicyAssignment
  • PrivateCACAPool
  • PrivateCACertificate
  • PrivateCACertificateAuthority
  • PrivateCACertificateTemplate
  • Proyecto
  • PubSubLiteReservation
  • PubSubSchema
  • PubSubSubscription
  • PubSubTopic
  • RecaptchaEnterpriseKey
  • RedisInstance
  • ResourceManagerLien
  • ResourceManagerPolicy
  • RunJob
  • RunService
  • SQLDatabase
  • SQLSSLCert
  • SQLUser
  • SecretManagerSecret
  • SecretManagerSecretVersion
  • Servicio
  • ServiceDirectoryEndpoint
  • ServiceDirectoryNamespace
  • ServiceDirectoryService
  • ServiceIdentity
  • ServiceNetworkingConnection
  • SourceRepoRepository
  • SpannerDatabase
  • SpannerInstance
  • StorageBucket
  • StorageBucketAccessControl
  • StorageDefaultObjectAccessControl
  • StorageNotification
  • StorageTransferJob
  • VPCAccessConnector

Los siguientes tipos no admiten el comportamiento de propagación de Merge a partir de la versión correspondiente:

Nombre del tipo Versión
LoggingLogMetric 1.118.1