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
stateIntoSpec
Absent
. - Especifica el valor de la anotación
cnrm.cloud.google.com/state-into-spec
comoabsent
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:
- Utilice directamente el valor de la anotación
cnrm.cloud.google.com/state-into-spec
si se especifica y es válido. - Si no se especifica la anotación, usa el valor correspondiente del campo
stateIntoSpec
en el recurso personalizado ConfigConnectorContext. - Si el CR ConfigConnectorContext no existe o el campo
stateIntoSpec
no se ha especificado, usa el valor correspondiente del campostateIntoSpec
del CR ConfigConnector. - Si el CR de ConfigConnector no existe o el campo
stateIntoSpec
no se ha especificado, utiliza el comportamiento predeterminado basado en el CRD descrito enspec
Comportamientos 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:
Asegúrate de que la anulación
stateIntoSpec
a nivel de clúster o de espacio de nombres seaAbsent
en el CR de ConfigConnector o en el CR de ConfigConnectorContext.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:
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.Elimina el recurso del clúster de Kubernetes.
Añade la anotación
cnrm.cloud.google.com/state-into-spec: absent
al archivo YAML del recurso.(Opcional) Quita
cnrm.cloud.google.com/deletion-policy: abandon
del archivo YAML.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:
- 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. - 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 ladrift
.
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 |