Ignorar campos sin especificar

En esta página, se explica el comportamiento predeterminado de los campos spec y cómo cambiarlo 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 de Absent. Para obtener una lista de los CRD que admiten Merge, consulta la sección CRD con compatibilidad con Merge de esta página.

spec comportamientos de propagación de campos

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 completará ningún campo no especificado en la especificación.

Para las CRD agregadas en la versión 1.114.0 y posteriores, el comportamiento de propagación predeterminado es Absent. Este es también el único comportamiento de propagación que admiten esos 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 la versión 1.114.0 y posteriores. Los campos spec toman valores de la API después de una conciliación exitosa, 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 que admiten 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 como Absent siguiendo las instrucciones en Cómo 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 tu archivo YAML aplicado.

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

spec:
  foo: "foo"

Verás otro campo llamado bar en el CR si el archivo YAML se aplica 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 , es posible que desees cambiar este comportamiento predeterminado y omitir la propagación de la especificación del recurso de Kubernetes con campos no especificados.

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

Puedes omitir el proceso de completar los campos no especificados en la especificación de los CRD compatibles con la versión 1.113.0 y versiones anteriores de Config Connector de cualquiera 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 como Absent en el CR de ConfigConnector o en el CR de ConfigConnectorContext.

spec:
  stateIntoSpec: Absent

Esto hace que Absent sea el comportamiento predeterminado de los campos spec para cualquier recurso nuevo que se cree en el clúster o en el espacio de nombres cuando no especifiques la anotación cnrm.cloud.google.com/state-into-spec en los archivos YAML de los recursos nuevos. Esto significa que Config Connector omitirá la propagación de 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 en función del 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 se especifica y es válido.
  2. Si no se especifica la anotación, usa el valor correspondiente del campo stateIntoSpec en el CR de ConfigConnectorContext.
  3. Si el CR de ConfigConnectorContext no existe o no se especifica el campo stateIntoSpec, usa el valor correspondiente del campo stateIntoSpec en el CR de ConfigConnector.
  4. Si el CR de ConfigConnector no existe o el campo stateIntoSpec no está especificado, usa el comportamiento predeterminado según el CRD que se describe en Comportamientos de propagación de campos de spec.

Ten en cuenta que las únicas CRD de comportamiento de propagación agregadas en la versión 1.114.0 y versiones posteriores que se siguen son las de 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 stateIntoSpec a nivel del clúster o del espacio de nombres sea Absent en el CR de ConfigConnector o en el CR de ConfigConnectorContext.

  2. Abandona y adquiere el recurso. Asegúrate de que la configuración de YAML utilizada 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

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

Si ya creaste el recurso, pero quieres 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 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 YAML del recurso.

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

  5. Aplica el archivo YAML actualizado.

Para explicar mejor 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

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

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

Entonces, 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"

En cambio, 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 establecer 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 en los que se beneficiará del comportamiento de completado de Absent.

Administra campos sin especificar 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 de 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 configuración y Config Connector

Si usas herramientas de administración de configuración como Config Sync o Argo CD, es posible que observes una lucha 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. 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 configuración como Config Connector tratan los campos de lista como atómicos, por lo que las herramientas de administración de configuración tratan el spec.bars[0].br2 agregado como una desviación y se quitará para corregir el drift.

Para resolver estos problemas, puedes establecer 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 de GET/PUT

La simetría de 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 Config Connector completa en la especificación del recurso de Kubernetes son el resultado de una solicitud GET. Esto significa que, en futuras reconciliaciones, Config Connector puede enviar una solicitud PUT o PATCH a la API deGoogle Cloud subyacente, con estos valores de campo no especificados que se obtuvieron de la solicitud GET. Por lo general, esto no es un problema, pero es posible que algunas APIs rechacen la solicitud PUT o PATCH debido a estos valores de campo no especificados.Google Cloud En el mismo ejemplo, el spec.barz.bz2 completado con el valor "bz2" puede generar un error del cliente HTTP 400 o cualquier otra respuesta inesperada si la implementación de la API incumple el principio de simetría GET/PUT.

Para evitar este tipo de problemas, puedes experimentar con el parámetro de configuración cnrm.cloud.google.com/state-into-spec: absent y verificar si desaparecen los errores durante la reconciliación.

Estado observado

Si necesitas establecer cnrm.cloud.google.com/state-into-spec: absent, pero tu solución depende de los valores propagados de los campos no especificados, verifica si estos campos existen en status.observedState en el esquema del CRD. Si se representan en status.observedState, puedes establecer cnrm.cloud.google.com/state-into-spec: absent y seguir accediendo a los valores de los campos no especificados después de una conciliación exitosa.

El campo status.observedState contiene el estado activo de los campos observados y seleccionados del recurso que Config Connector observó en la última reconciliación exitosa. Los campos observados se seleccionan si son dependencias de casos de uso comunes y son campos calculados 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 la herramienta pública de seguimiento de errores.

Tipos con compatibilidad de Merge

A continuación, se indican 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