Ignorar campos no especificados


En esta página se explica el comportamiento predeterminado de los campos spec y cómo cambiarlo de Merge a Absent, que es el comportamiento recomendado. Es posible que esta página no sea aplicable si usas un CRD añadido en la versión 1.114.0 o posterior, ya que esos CRDs solo usan el comportamiento Absent. Para ver una lista de los CRDs que admiten Merge, consulta la sección CRDs compatibles con Merge de esta página.

spec comportamientos de relleno 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 predeterminados diferentes: Absent y Merge.

Ausente

Absent es el comportamiento recomendado. Config Connector no rellenará ningún campo sin especificar en la especificación.

En el caso de los CRDs añadidos en la versión 1.114.0 y posteriores, el comportamiento predeterminado es Absent. Este es el único comportamiento de relleno que admiten esos CRDs. El valor de la anotación cnrm.cloud.google.com/state-into-spec es absent en estos CRs de recursos.

Combinar

Merge es un comportamiento no admitido en los CRDs añadidos en la versión 1.114.0 y posteriores. Los campos spec adoptan valores de la API después de una conciliación correcta, a menos que no se puedan leer. Consulta más información en el artículo Gestionar campos externamente.

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

De forma predeterminada, en estos CRs de recursos, los campos que no se hayan especificado en el 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 archivo YAML aplicado.

Por 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 la respuesta predefinida 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 quieras cambiar este comportamiento predeterminado y omitir la población de la especificación de recursos de Kubernetes con campos no especificados.

No rellenar los campos no especificados en la especificación

Puedes omitir el paso de rellenar los campos no especificados en la especificación de los CRDs admitidos en la versión 1.113.0 de Config Connector o versiones anteriores de cualquiera de las siguientes formas:

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

Configurar la anulación a nivel de clúster o de espacio de nombresstateIntoSpec

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

spec:
  stateIntoSpec: Absent

De esta forma, Absent se convierte en 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 del nuevo recurso. Esto significa que Config Connector no rellenará los campos no especificados en la especificación de recursos de Kubernetes de estos recursos.

El campo stateIntoSpec no tiene ningún valor predeterminado. Config Connector determinará el comportamiento 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. Utilice directamente el valor de la anotación cnrm.cloud.google.com/state-into-spec si se especifica y es válido.
  2. Si no se especifica la anotación, usa el valor correspondiente del campo stateIntoSpec en el recurso personalizado ConfigConnectorContext.
  3. Si el CR ConfigConnectorContext no existe o el campo stateIntoSpec no se ha especificado, usa el valor correspondiente del campo stateIntoSpec del CR ConfigConnector.
  4. Si el CR de ConfigConnector no existe o el campo stateIntoSpec no se ha especificado, utiliza el comportamiento predeterminado basado en el CRD descrito en specComportamientos de relleno de campos.

Ten en cuenta que las únicas CRDs de comportamiento de relleno que se han añadido en la versión 1.114.0 y posteriores siguen el Absent, independientemente de la anotación cnrm.cloud.google.com/state-into-spec o de los campos stateIntoSpec de la CR de ConfigConnector o de la CR de ConfigConnectorContext.

Si ya has creado el recurso, pero quieres cambiar el comportamiento de los campos spec a Absent, debes hacer lo siguiente:

  1. Asegúrate de que la anulación stateIntoSpec a nivel de clúster o de 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 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 de recurso

Al crear el archivo YAML, puedes especificar el valor de la anotación cnrm.cloud.google.com/state-into-spec como absent. De esta forma, no se rellenan los 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 el valor predeterminado merge, lo que significa que Config Connector rellena 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 de Config Connector.

Si ya has creado el recurso, pero quieres cambiar el valor de esta anotación para que se rellene de otra forma, debes seguir estos pasos:

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

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

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

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

  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 supongamos que has especificado la especificación en tu archivo YAML de la siguiente manera:

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

De forma predeterminada, la especificación rellenada 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 defines cnrm.cloud.google.com/state-into-spec: absent, la especificación final del 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á definir cnrm.cloud.google.com/state-into-spec: absent para que los campos spec se rellenen con el comportamiento de Absent. Estos son los casos más habituales en los que se puede aprovechar el comportamiento de relleno de Absent.

Gestionar campos no especificados de una lista de forma externa

Config Connector trata todos los campos de lista de la especificación de recursos de Kubernetes como campos atómicos. Por lo tanto, de forma predeterminada, Config Connector revertirá el cambio que hayas hecho 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 gestionar los subcampos de la lista. Para obtener más información, consulta Comportamiento de los campos de lista en resource_spec.

Resolver conflictos entre herramientas de gestión de configuración y Config Connector

Si usas herramientas de gestión de configuración como Config Sync o Argo CD, puede que observes un conflicto entre la herramienta de gestión de configuración y Config Connector. Por ejemplo, el error KNV2005 se explica en la guía para solucionar problemas. La causa principal de este tipo de problemas es la siguiente:

  1. Config Connector rellenará y asignará valores predeterminados a los valores no especificados de la lista en la sección spec. spec.bars[0].br2 es un ejemplo.
  2. Tanto las herramientas de gestión de configuración como Config Connector tratan los campos de lista como atómicos, por lo que la spec.bars[0].br2 añadida se considera una desviación por las herramientas de gestión de configuración y se eliminará para corregir la drift.

Para solucionar estos problemas, puede definir cnrm.cloud.google.com/state-into-spec: absent para que Config Connector no añada el campo no especificado spec.bars[0].br2 a la especificación.

Resolver problemas de simetría GET/PUT

La simetría de GET/PUT hace referencia a un principio de diseño de la API REST. En concreto, 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 que cambie el estado del recurso REST subyacente.

Los campos no especificados que Config Connector rellena en la especificación de recursos de Kubernetes son el resultado de una solicitud GET. Esto significa que, en futuras conciliaciones, Config Connector puede enviar una solicitud PUT o PATCH a la APIGoogle Cloud subyacente con estos valores de campo no especificados obtenidos de la solicitud GET. Por lo general, esto no supone ningún 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 campo spec.barz.bz2 con el valor "bz2" puede provocar un error de cliente HTTP 400 u otras respuestas inesperadas si la implementación de la API infringe el principio de simetría GET/PUT.

Para evitar este tipo de problemas, puedes probar a definir cnrm.cloud.google.com/state-into-spec: absent y comprobar si desaparecen los errores durante la conciliación.

Estado observado

Si necesitas definir cnrm.cloud.google.com/state-into-spec: absent, pero tu solución depende de los valores rellenados de campos no especificados, comprueba si estos campos se encuentran en status.observedState en el esquema de CRD. Si se representan en status.observedState, puedes definir 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 correcta.

El campo status.observedState contiene el estado activo de los campos seleccionados y observados del recurso que Config Connector ha observado en la última conciliación correcta. Los campos observados se seleccionan si son dependencias de casos prácticos habituales y son campos spec. Puedes encontrar los campos observados en los esquemas de CRD.

Si no encuentras los campos observados que quieres, busca una incidencia o abre una nueva en las herramientas públicas de seguimiento de incidencias.

Tipos compatibles con Merge

A continuación se indican todos los tipos de Config Connector que admiten el comportamiento de relleno 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 relleno automático Merge a partir de la versión correspondiente:

Nombre de Kind Versión
LoggingLogMetric 1.118.1