Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Ignora los campos sin especificar

En esta página, se explica el comportamiento predeterminado de propagación de los campos spec en los recursos de Config Connector y cómo migrar los recursos existentes del comportamiento heredado Merge al comportamiento recomendado Absent. Es posible que esta página no sea aplicable si usas una CustomResourceDefinition (CRD) agregada en la versión 1.114.0 y posteriores, ya que esas CRD solo admiten el comportamiento de Absent. Para obtener una lista de CRD que admiten el comportamiento Merge, consulta la sección Tipos con compatibilidad con Merge de esta página.

`spec` campos que propagan comportamientos

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

Ausente

El comportamiento Absent es el recomendado. Cuando un recurso usa el comportamiento Absent, Config Connector no propaga los campos no especificados en el campo spec del recurso de Kubernetes.

A partir de la versión 1.123.1 de Config Connector, el comportamiento de Absent es el comportamiento de propagación predeterminado para todos los recursos recién creados, a menos que establezcas el valor del campo spec.stateIntoSpec en Merge en tu recurso personalizado ConfigConnector o ConfigConnectorContext. Para los recursos que usan la anotación cnrm.cloud.google.com/state-into-spec, Config Connector establece el valor de la anotación en minúsculas absent de forma predeterminada (el campo spec.stateIntoSpec usa Absent o Merge en mayúsculas). Los recursos conciliados por controladores directos usan el comportamiento Absent sin agregar la anotación.

Para los CRD agregados en la versión 1.114.0 y posteriores, el comportamiento de Absent es el único comportamiento de propagación compatible.

Combinar

El comportamiento de Merge no se admite en los CRD agregados en la versión 1.114.0 y posteriores. Cuando un recurso usa el comportamiento Merge, los campos spec adoptan valores de la API de Google Cloud después de una reconciliación exitosa, a menos que esos campos no sean legibles. Para obtener más detalles, consulta Administra campos de forma externa.

Para los CRD agregados en la versión 1.113.0 y anteriores, Config Connector admite los comportamientos Absent y Merge. Para obtener la lista completa de los recursos compatibles, consulta Tipos con compatibilidad con Merge. En las versiones de Config Connector anteriores a la 1.123.1, el comportamiento de propagación predeterminado para estos CRD era Merge, y Config Connector establecía el valor de la anotación cnrm.cloud.google.com/state-into-spec en merge de forma predeterminada.

Debido a que la anotación cnrm.cloud.google.com/state-into-spec es inmutable después de que se crea un recurso, los recursos creados antes de la versión 1.123.1 conservan la anotación cnrm.cloud.google.com/state-into-spec: merge incluso después de actualizar Config Connector a la versión 1.123.1 o posterior. Para configurar recursos nuevos para que usen el comportamiento de Absent, consulta Cómo omitir el completado de campos no especificados en la especificación. Para migrar recursos existentes, consulta Cómo migrar recursos de Merge a Absent.

Cuando un recurso usa el comportamiento Merge, los campos que no se especifican en tu manifiesto YAML original se propagan en el campo spec del recurso personalizado en el servidor de la API de Kubernetes. Este comportamiento significa que, cuando ejecutas el comando kubectl get RESOURCE_KIND RESOURCE_NAME -o yaml, el campo spec en el resultado puede incluir campos secundarios que no están en el archivo YAML aplicado.

Por ejemplo, supongamos que el esquema de CRD te permite especificar dos campos llamados field1 y field2 en el campo spec, pero el archivo YAML aplicado solo especifica el campo field1:

spec:
  field1: "value-1"

Si el manifiesto YAML se aplica correctamente y el recurso está UpToDate, el campo field2 aparecerá en el recurso personalizado:

spec:
  field1: "value-1"
  field2: "value-2"

Config Connector no propaga los campos de referencia de recursos no especificados, como projectRef, folderRef, organizationRef o billingAccountRef, deGoogle Cloud a spec. Por ejemplo, aunque el tipo Project admite Merge, todos sus campos spec opcionales (billingAccountRef, folderRef y organizationRef) son campos de referencia de recursos. Como resultado, Merge no propaga ningún campo sin especificar en un recurso Project.

Debido a la complejidad de las interacciones entre Config Connector y las APIs deGoogle Cloud , usa el comportamiento Absent para que Config Connector omita propagar el campo spec del recurso de Kubernetes con campos no especificados.

Omitir el llenado de campos no especificados en la especificación

Puedes configurar Config Connector para que omita propagar campos no especificados en el campo spec de las CRD agregadas en la versión 1.113.0 y anteriores de Config Connector de cualquiera de las siguientes maneras:

Establece el valor del campo stateIntoSpec a nivel del clúster o del espacio de nombres en Absent.
En el recurso, establece el valor de la anotación cnrm.cloud.google.com/state-into-spec en absent.

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

Cuando instales Config Connector o actualices tu instalación de Config Connector, puedes establecer el valor del campo stateIntoSpec a nivel de clúster o de espacio de nombres en Absent en el recurso personalizado ConfigConnector o ConfigConnectorContext:

spec:
  stateIntoSpec: Absent

Este parámetro de configuración hace que el comportamiento de Absent sea el comportamiento predeterminado de propagación de campos de spec para cualquier recurso nuevo creado en el clúster o espacio de nombres cuando no especificas la anotación cnrm.cloud.google.com/state-into-spec en los manifiestos YAML del recurso. Config Connector omite propagar los campos no especificados en el campo spec del recurso de Kubernetes para estos recursos.

El campo stateIntoSpec en los recursos personalizados ConfigConnector y ConfigConnectorContext no tiene un valor predeterminado. Config Connector determina 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 sigue este orden de prioridad para determinar el valor de la anotación cuando se crea un recurso:

Usa el valor de la anotación cnrm.cloud.google.com/state-into-spec directamente 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 recurso personalizado ConfigConnectorContext no existe o el campo stateIntoSpec no está especificado, usa el valor correspondiente del campo stateIntoSpec en el recurso personalizado ConfigConnector.
Si el recurso personalizado de ConfigConnector no existe o el campo stateIntoSpec no se especifica, Config Connector versión 1.123.1 y posteriores se establecen de forma predeterminada en el valor absent. Las versiones anteriores a la 1.123.1 usan el comportamiento predeterminado para la CRD, como se describe en Comportamientos de propagación de campos de spec.

Las CRD agregadas en la versión 1.114.0 y versiones posteriores solo admiten el comportamiento de propagación de Absent, independientemente del campo stateIntoSpec en el recurso personalizado ConfigConnector o ConfigConnectorContext.

Si ya creaste un recurso con el comportamiento Merge, actualizar el valor del campo stateIntoSpec a Absent en el recurso personalizado ConfigConnector o ConfigConnectorContext no cambia la anotación del recurso existente. Para migrar recursos existentes, consulta Migra recursos de Merge a Absent.

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

Cuando crees tu archivo YAML, puedes establecer el valor de la anotación cnrm.cloud.google.com/state-into-spec en absent. Esta anotación omite la propagación de campos no especificados en el campo spec del recurso de Kubernetes:

metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent

En la versión 1.123.1 y posteriores de Config Connector, esta anotación se establece de forma predeterminada en el valor absent si no se especifica (a menos que lo anules configurando el valor del campo spec.stateIntoSpec en Merge en tu recurso personalizado ConfigConnector o ConfigConnectorContext). En versiones anteriores a la 1.123.1, esta anotación se establecía de forma predeterminada en el valor merge para los CRD agregados en la versión 1.113.0 y anteriores, lo que significa que Config Connector completaba todos los campos no especificados en el campo spec.

Esta anotación es inmutable, lo que significa que no puedes actualizar el valor de la anotación directamente en un recurso de Config Connector existente. Si ya creaste un recurso con el valor merge y quieres cambiar su comportamiento al valor absent, consulta Migra recursos de Merge a Absent.

Para explicar mejor la diferencia que introduce esta anotación, supongamos que un recurso tiene un campo spec con el siguiente esquema:

field1: string
field2: string
listField:
- itemField1: string
  itemField2: string
objectField:
  subField1: string
  subField2: string

También supón que especificaste el campo spec en tu manifiesto YAML de la siguiente manera:

spec:
  field1: "value-1"
  listField:
  - itemField1: "1_value1"
  - itemField1: "2_value1"
  objectField:
    subField1: "sub-value-1"

Cuando el valor de la anotación cnrm.cloud.google.com/state-into-spec se establece en merge, el campo spec propagado en el recurso de Kubernetes creado se ve de la siguiente manera:

spec:
  field1: "value-1"
  field2: "value-2"
  listField:
  - itemField1: "1_value1"
    itemField2: "1_value2"
  - itemField1: "2_value1"
    itemField2: "2_value2"
  objectField:
    subField1: "sub-value-1"
    subField2: "sub-value-2"

Cuando configuras la anotación cnrm.cloud.google.com/state-into-spec: absent, el campo spec final en el recurso de Kubernetes creado permanece de la siguiente manera:

spec:
  field1: "value-1"
  listField:
  - itemField1: "1_value1"
  - itemField1: "2_value1"
  objectField:
    subField1: "sub-value-1"

Migra recursos de `Merge` a `Absent`

Debido a que la anotación cnrm.cloud.google.com/state-into-spec es inmutable en un recurso de Kubernetes existente, actualizar el Config Connector a la versión 1.123.1 o posterior no cambia automáticamente los recursos existentes del valor merge al valor absent.

Migrar tus recursos y espacios de nombres existentes del comportamiento de Merge al comportamiento de Absent ayuda a evitar los siguientes problemas:

Errores de conciliación en campos actualizados automáticamente: Google Cloud actualiza automáticamente ciertos campos en los recursos subyacentes, como las versiones de mantenimiento o la configuración de ajuste de escala automático. Es posible que los recursos con la anotación state-into-spec: merge no se reconcilien o entren en un bucle de actualización interminable en el que se intente revertir el campo al valor spec anterior.
Conflictos con herramientas de GitOps y de administración de configuración: Herramientas como el Sincronizador de configuración y Argo CD pueden entrar en conflicto con Config Connector cuando el comportamiento de Merge propaga subcampos no especificados en listas.
Errores de validación en tipos de recursos más nuevos: Si el valor del campo spec.stateIntoSpec se establece en Merge en un recurso personalizado ConfigConnector o ConfigConnectorContext, la administración de recursos que no admiten el comportamiento Merge puede causar errores de validación (invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation).

Identifica los espacios de nombres y los recursos afectados

Antes de migrar, verifica la configuración a nivel de clúster, de espacio de nombres y de recursos para identificar dónde se sigue usando el comportamiento de Merge:

Verifica el recurso personalizado ConfigConnector a nivel del clúster para ver si hay una anulación del campo stateIntoSpec:

kubectl get configconnector configconnector.core.cnrm.cloud.google.com \
    -o jsonpath='{.spec.stateIntoSpec}{"\n"}'

Verifica todos los recursos personalizados ConfigConnectorContext a nivel del espacio de nombres para ver si hay anulaciones de campos stateIntoSpec:
```
kubectl get configconnectorcontext -A \
    -o custom-columns=NAMESPACE:.metadata.namespace,STATE_INTO_SPEC:.spec.stateIntoSpec
```
Verifica el valor de la anotación cnrm.cloud.google.com/state-into-spec en un recurso de Config Connector existente:
```
kubectl get RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/state-into-spec}{"\n"}'
```
Reemplaza lo siguiente:
- RESOURCE_KIND: Es el tipo de recurso de Config Connector, como SQLInstance.
- RESOURCE_NAME: el nombre del recurso.
- NAMESPACE: Es el espacio de nombres del recurso.

Migra un recurso a `Absent`

Para cambiar el comportamiento de propagación de un recurso existente de Merge a Absent, debes abandonar el recurso de Kubernetes y volver a adquirir el recurso Google Cloud subyacente con la anotacióncnrm.cloud.google.com/state-into-spec: absent. Para abandonar y volver a adquirir el recurso, completa los siguientes pasos:

Si el valor del campo spec.stateIntoSpec se establece en Merge en tu recurso personalizado ConfigConnector o ConfigConnectorContext, actualiza el valor del campo a Absent:
```
spec:
  stateIntoSpec: Absent
```
Agrega la anotación cnrm.cloud.google.com/deletion-policy: abandon al recurso de Config Connector existente en tu clúster. Esta anotación ayuda a garantizar que, cuando borres el recurso de Kubernetes en el siguiente paso, no se borre el recurso de Google Cloud subyacente:
```
kubectl annotate RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    cnrm.cloud.google.com/deletion-policy=abandon --overwrite
```

Borra el recurso de tu clúster de Kubernetes:

kubectl delete RESOURCE_KIND RESOURCE_NAME -n NAMESPACE

En el manifiesto YAML de tu recurso, establece el valor de la anotación cnrm.cloud.google.com/state-into-spec en absent:
```
metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent
```
Revisa el campo spec en tu manifiesto de YAML para verificar que incluya todos los campos que quieres que administre Config Connector. Omite los campos que deseas que Google Cloud o los sistemas externos administren automáticamente, como el campo spec.maintenanceVersion en un recurso SQLInstance.
Opcional: Si tu manifiesto YAML local también incluye la anotación cnrm.cloud.google.com/deletion-policy: abandon y ya no deseas la política de eliminación de abandon, quita esa anotación del manifiesto YAML.
Aplica el manifiesto YAML actualizado para volver a adquirir el recurso:
```
kubectl apply -f MANIFEST_FILE
```
Reemplaza MANIFEST_FILE por la ruta de acceso al archivo YAML del recurso.

Cuándo usar `cnrm.cloud.google.com/state-into-spec: absent`

En la mayoría de los casos, usa la anotación cnrm.cloud.google.com/state-into-spec: absent para obtener el comportamiento de propagación de Absent para los campos spec. En las siguientes secciones, se describen situaciones comunes en las que el comportamiento de propagación de Absent resulta beneficioso.

Evita conflictos con los campos que actualiza automáticamente Google Cloud

Cuando un recurso usa la anotación cnrm.cloud.google.com/state-into-spec: merge, Config Connector lee los valores de la API de Google Cloud durante la conciliación inicial y los escribe en el campo spec del recurso de Kubernetes. Si un servicio de Google Cloud actualiza más adelante uno de esos campos automáticamente, el Config Connector trata el valor anterior almacenado en el campo spec como el estado objetivo y trata de revertir el cambio en el recurso Google Cloud subyacente.

Por ejemplo, si creas un recurso SQLInstance con la anotación cnrm.cloud.google.com/state-into-spec: merge sin especificar el campo spec.maintenanceVersion, Config Connector propaga la versión de mantenimiento inicial en el campo spec.maintenanceVersion. Cuando Cloud SQL realiza una actualización de mantenimiento automática en la instancia, la versión de mantenimiento activa en Cloud SQL avanza. Durante la siguiente conciliación, Config Connector intenta aplicar un parche a la instancia para que vuelva al valor anterior de spec.maintenanceVersion. Debido a que Cloud SQL rechaza las versiones anteriores de mantenimiento, la conciliación falla de forma reiterada con un error UpdateFailed (The requested maintenance version is not an available maintenance version to upgrade).

Cuando configures la anotación cnrm.cloud.google.com/state-into-spec: absent, omite los campos que se actualizan automáticamente, como spec.maintenanceVersion, de tu manifiesto de YAML. Config Connector no registra esos campos en el campo spec, lo que permite que Google Cloud los actualice sin causar conflictos de conciliación.

Administra campos sin especificar en una lista de forma externa

Config Connector trata todos los campos de lista del campo spec del recurso de Kubernetes como campos atómicos. Como resultado, cuando el valor de la anotación state-into-spec se establece en merge, Config Connector revierte cualquier cambio realizado en un subcampo de una lista desde fuera de Config Connector. Sin embargo, puedes usar la anotación cnrm.cloud.google.com/state-into-spec: absent para permitir que Config Connector deje sin administrar los subcampos no especificados de una lista. Para obtener más información, consulta Comportamiento de los campos de lista en la especificación de recursos.

Resuelve conflictos entre las herramientas de administración de configuración y Config Connector

Si usas herramientas de administración de configuraciones, como Sincronizador de configuración o Argo CD, es posible que observes conflictos 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. Estos problemas se producen por los siguientes motivos:

Cuando el valor de la anotación state-into-spec se establece en merge, Config Connector propaga y establece valores predeterminados no especificados en las listas del campo spec, como el campo spec.listField[0].itemField2.
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 tratan el campo spec.listField[0].itemField2 agregado como una desviación y lo quitan.

Para resolver estos problemas, puedes configurar la anotación cnrm.cloud.google.com/state-into-spec: absent de modo que Config Connector no agregue el campo spec.listField[0].itemField2 no especificado en el campo spec.

Cómo resolver problemas de simetría de GET/PUT

La simetría GET/PUT se refiere a un principio de diseño en las APIs de REST. En particular, significa que, cuando se envía una respuesta GET como una solicitud PUT a la misma URL, el resultado esperado es un código de estado HTTP 200 OK sin cambios en el estado del recurso de REST subyacente.

Cuando el valor de la anotación state-into-spec se establece en merge, los campos no especificados que propaga Config Connector en el campo spec del recurso de Kubernetes son el resultado de una solicitud GET. Este comportamiento significa que, en futuras conciliaciones, Config Connector podría enviar una solicitud PUT o PATCH a la API de Google Cloud subyacente con estos valores de campo no especificados que se aprendieron de la solicitud GET. Por lo general, este comportamiento no es un problema, pero algunas Google Cloud APIs podrían rechazar la solicitud PUT o PATCH debido a estos valores de campo no especificados. En el mismo ejemplo, el campo spec.objectField.subField2 completado con el valor "sub-value-2" podría 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 establecer la anotación cnrm.cloud.google.com/state-into-spec: absent y verificar si desaparecen los errores durante la conciliación.

Estado observado

Si necesitas establecer la anotación 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 el campo status.observedState del esquema de CRD. Si se representan en el campo status.observedState, puedes establecer la anotación 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 observados y seleccionados del recurso que Config Connector observó en la última conciliación exitosa. Config Connector selecciona los campos observados que son campos spec calculados y dependencias para casos de uso comunes. 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 con `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
BigQueryRoutine
BigQueryTable
BigtableAppProfile
BigtableGCPolicy
BigtableInstance
BigtableTable
BillingBudgetsBudget
BinaryAuthorizationAttestor
BinaryAuthorizationPolicy
CertificateManagerCertificate
CertificateManagerCertificateMap
CertificateManagerCertificateMapEntry
CloudBuildTrigger
CloudFunctionsFunction
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
DataCatalogPolicyTag
DataCatalogTaxonomy
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
TagsTagBinding
TagsTagKey
TagsTagValue
VPCAccessConnector

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

Nombre del tipo	Versión
AlloyDBInstance	1.129.2
CertificateManagerDNSAuthorization	1.124.0
CloudIdentityGroup	1.134.0
CloudIdentityMembership	1.134.0
ComputeFirewallPolicyRule	1.125.0
GKEHubFeatureMembership	1.128.0
LoggingLogMetric	1.118.1
MonitoringDashboard	1.119.0
SQLInstance	1.129.2