Ignorar campos não especificados

Nesta página, explicamos o comportamento de preenchimento padrão dos campos spec nos recursos do Config Connector e como migrar recursos do comportamento legado Merge para o comportamento recomendado Absent. Esta página pode não ser aplicável se você estiver usando uma CustomResourceDefinition (CRD) adicionada na versão 1.114.0 e mais recentes, porque essas CRDs são compatíveis apenas com o comportamento Absent. Para uma lista de CRDs que oferecem suporte ao comportamento Merge, consulte a seção Tipos com suporte para Merge desta página.

spec campos que preenchem comportamentos

Quando o Config Connector cria um recurso, os campos não especificados no campo spec do recurso do Kubernetes podem ter dois comportamentos de preenchimento diferentes: Absent e Merge.

Ausente

O comportamento Absent é o recomendado. Quando um recurso usa o comportamento Absent, o Config Connector não preenche campos não especificados no campo spec do recurso do Kubernetes.

A partir da versão 1.123.1 do Config Connector, o comportamento Absent é o padrão para todos os recursos recém-criados, a menos que você defina o valor do campo spec.stateIntoSpec como Merge no recurso personalizado ConfigConnector ou ConfigConnectorContext. Para recursos que usam a anotação cnrm.cloud.google.com/state-into-spec, o Config Connector define o valor da anotação como minúsculo absent por padrão (o campo spec.stateIntoSpec usa Absent ou Merge em maiúsculas). Os recursos reconciliados por controladores diretos usam o comportamento Absent sem adicionar a anotação.

Para CRDs adicionados na versão 1.114.0 e mais recentes, o comportamento Absent é o único comportamento de preenchimento compatível.

Mesclar

O comportamento Merge não é compatível com CRDs adicionados na versão 1.114.0 e mais recentes. Quando um recurso usa o comportamento Merge, os campos spec assumem valores da API Google Cloud após uma reconciliação bem-sucedida, a menos que esses campos não sejam legíveis. Para mais detalhes, consulte Gerenciar campos externamente.

Para CRDs adicionados na versão 1.113.0 e anteriores, o Config Connector é compatível com os comportamentos Absent e Merge. Para ver a lista completa de recursos compatíveis, consulte Tipos com suporte para Merge. Nas versões do Config Connector anteriores à 1.123.1, o comportamento de preenchimento padrão para essas CRDs era Merge, e o Config Connector definia o valor da anotação cnrm.cloud.google.com/state-into-spec como merge por padrão.

Como a anotação cnrm.cloud.google.com/state-into-spec é imutável após a criação de um recurso, os recursos criados antes da versão 1.123.1 mantêm a anotação cnrm.cloud.google.com/state-into-spec: merge mesmo depois de fazer upgrade do Config Connector para a versão 1.123.1 ou posterior. Para configurar novos recursos para usar o comportamento Absent, consulte Ignorar o preenchimento de campos não especificados na especificação. Para migrar recursos atuais, consulte Migrar recursos de Merge para Absent.

Quando um recurso usa o comportamento Merge, os campos que não são especificados no manifesto YAML original são preenchidos no campo spec do recurso personalizado no servidor da API Kubernetes. Esse comportamento significa que, ao executar o comando kubectl get RESOURCE_KIND RESOURCE_NAME -o yaml, o campo spec na saída pode incluir subcampos que não estão no arquivo YAML aplicado.

Por exemplo, suponha que o esquema de CRD permita especificar dois campos chamados field1 e field2 no campo spec, mas o arquivo YAML aplicado especifique apenas o campo field1:

spec:
  field1: "value-1"

Se o manifesto YAML for aplicado com sucesso e o recurso estiver UpToDate, o campo field2 vai aparecer no recurso personalizado:

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

O Config Connector não preenche campos de referência de recursos não especificados, como projectRef, folderRef, organizationRef ou billingAccountRef, de Google Cloud em spec. Por exemplo, embora o tipo Project seja compatível com Merge, todos os campos spec opcionais (billingAccountRef, folderRef e organizationRef) são campos de referência de recursos. Como resultado, Merge não preenche campos não especificados em um recurso Project.

Observação: definir explicitamente cnrm.cloud.google.com/state-into-spec: merge em um manifesto retorna um aviso de webhook de admissão em todos os recursos, mesmo em CRDs que oferecem suporte a Merge.

Devido à complexidade das interações entre o Config Connector e as APIsGoogle Cloud , use o comportamento Absent para que o Config Connector pule o preenchimento do campo spec do recurso do Kubernetes com campos não especificados.

Pular o preenchimento de campos não especificados na especificação

É possível configurar o Config Connector para pular o preenchimento de campos não especificados no campo spec para CRDs adicionados no Config Connector versão 1.113.0 e anteriores de uma das seguintes maneiras:

• Defina o valor do campo stateIntoSpec no nível do cluster ou do namespace como Absent.
• No recurso, defina o valor da anotação cnrm.cloud.google.com/state-into-spec como absent.

Configurar a substituição de stateIntoSpec no nível do cluster ou do namespace

Ao instalar ou atualizar o Config Connector, é possível definir o valor do campo stateIntoSpec no nível do cluster ou do namespace como Absent no recurso personalizado ConfigConnector ou ConfigConnectorContext:

spec:
  stateIntoSpec: Absent

Essa configuração faz com que o comportamento Absent seja o padrão para o preenchimento dos campos spec de qualquer novo recurso criado no cluster ou namespace quando você não especifica a anotação cnrm.cloud.google.com/state-into-spec nos manifestos YAML de recursos. O Config Connector ignora o preenchimento de campos não especificados no campo spec do recurso do Kubernetes para esses recursos.

O campo stateIntoSpec nos recursos personalizados ConfigConnector e ConfigConnectorContext não tem um valor padrão. O Config Connector determina o comportamento de preenchimento dos campos spec com base no valor da anotação cnrm.cloud.google.com/state-into-spec e segue esta ordem de precedência para determinar o valor da anotação quando um recurso é criado:

1. Use o valor da anotação cnrm.cloud.google.com/state-into-spec diretamente se ela for especificada e válida.
2. Se a anotação não for especificada, use o valor correspondente do campo stateIntoSpec no recurso personalizado ConfigConnectorContext.
3. Se o recurso personalizado ConfigConnectorContext não existir ou o campo stateIntoSpec não for especificado, use o valor correspondente do campo stateIntoSpec no recurso personalizado ConfigConnector.
4. Se o recurso personalizado do ConfigConnector não existir ou o campo stateIntoSpec não estiver especificado, o Config Connector versão 1.123.1 e mais recente vai usar o valor absent por padrão. As versões anteriores à 1.123.1 usam o comportamento padrão do CRD, conforme descrito em Comportamentos de preenchimento de campos spec.

Os CRDs adicionados na versão 1.114.0 e posteriores são compatíveis apenas com o comportamento de preenchimento Absent, independentemente do campo stateIntoSpec no recurso personalizado ConfigConnector ou ConfigConnectorContext.

Se você já tiver criado um recurso com o comportamento Merge, atualizar o valor do campo stateIntoSpec para Absent no recurso personalizado ConfigConnector ou ConfigConnectorContext não mudará a anotação do recurso atual. Para migrar recursos, consulte Migrar recursos de Merge para Absent.

Definir a anotação cnrm.cloud.google.com/state-into-spec no nível do recurso

Ao criar o arquivo YAML, defina o valor da anotação cnrm.cloud.google.com/state-into-spec como absent. Essa anotação ignora o preenchimento de campos não especificados no campo spec do recurso do Kubernetes:

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

No Config Connector versão 1.123.1 e posterior, essa anotação assume como padrão o valor absent se não for especificada, a menos que você a substitua definindo o valor do campo spec.stateIntoSpec como Merge no recurso personalizado ConfigConnector ou ConfigConnectorContext. Em versões anteriores à 1.123.1, essa anotação usava por padrão o valor merge para CRDs adicionados na versão 1.113.0 e anteriores. Isso significa que o Config Connector preencheu todos os campos não especificados no campo spec.

Essa anotação é imutável, o que significa que não é possível atualizar o valor dela diretamente em um recurso do Config Connector. Se você já criou um recurso com o valor merge e quer mudar o comportamento dele para o valor absent, consulte Migrar recursos de Merge para Absent.

Para explicar melhor a diferença introduzida por essa anotação, suponha que um recurso tenha um campo spec com o seguinte esquema:

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

Suponha também que você especificou o campo spec no manifesto YAML como:

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

Quando o valor da anotação cnrm.cloud.google.com/state-into-spec é definido como merge, o campo spec preenchido no recurso do Kubernetes criado fica assim:

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"

Quando você define a anotação cnrm.cloud.google.com/state-into-spec: absent, o campo spec final no recurso do Kubernetes criado permanece:

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

Migrar recursos de Merge para Absent

Como a anotação cnrm.cloud.google.com/state-into-spec é imutável em um recurso do Kubernetes, a atualização do Config Connector para a versão 1.123.1 ou mais recente não muda automaticamente os recursos atuais do valor merge para o valor absent.

Migrar os recursos e namespaces atuais do comportamento Merge para o comportamento Absent ajuda a evitar os seguintes problemas:

• Erros de reconciliação em campos atualizados automaticamente: Google Cloud atualiza automaticamente determinados campos em recursos subjacentes, como versões de manutenção ou configurações de escalonamento automático. Os recursos com a anotação state-into-spec: merge podem falhar na reconciliação ou entrar em um loop de atualização infinito ao tentar reverter o campo para o valor spec mais antigo.
• Conflitos com o GitOps e as ferramentas de gerenciamento de configuração: ferramentas como o Config Sync e o Argo CD podem entrar em conflito com o Config Connector quando o comportamento de Merge preenche subcampos não especificados em listas.
• Erros de validação em tipos de recursos mais recentes: se o valor do campo spec.stateIntoSpec for definido como Merge em um recurso personalizado do ConfigConnector ou do ConfigConnectorContext, o gerenciamento de recursos que não oferecem suporte ao comportamento Merge poderá causar erros de validação (invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation).

Identificar namespaces e recursos afetados

Antes de migrar, verifique as configurações no nível do cluster, do namespace e do recurso para identificar onde o comportamento de Merge ainda é usado:

• Verifique o recurso personalizado ConfigConnector no nível do cluster para uma substituição de campo stateIntoSpec:

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

• Verifique todos os recursos personalizados ConfigConnectorContext no nível do namespace para substituições de campo stateIntoSpec:

  kubectl get configconnectorcontext -A \
      -o custom-columns=NAMESPACE:.metadata.namespace,STATE_INTO_SPEC:.spec.stateIntoSpec
  

• Verifique o valor da anotação cnrm.cloud.google.com/state-into-spec em um recurso do Config Connector:

  kubectl get RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
      -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/state-into-spec}{"\n"}'
  

  Substitua:

  • RESOURCE_KIND: o tipo do recurso do Config Connector, como SQLInstance.
  • RESOURCE_NAME: o nome do recurso.
  • NAMESPACE: o namespace do recurso.

Migrar um recurso para Absent

Para mudar o comportamento de preenchimento de um recurso de Merge para Absent, é necessário abandonar o recurso do Kubernetes e adquirir novamente o recurso Google Cloud subjacente com a anotação cnrm.cloud.google.com/state-into-spec: absent. Para abandonar e adquirir novamente o recurso, siga estas etapas:

1. Se o valor do campo spec.stateIntoSpec estiver definido como Merge no recurso personalizado ConfigConnector ou ConfigConnectorContext, atualize o valor do campo para Absent:

   spec:
     stateIntoSpec: Absent
   

2. Adicione a anotação cnrm.cloud.google.com/deletion-policy: abandon ao recurso do Config Connector no cluster. Essa anotação ajuda a garantir que a exclusão do recurso do Kubernetes na próxima etapa não exclua o recurso Google Cloud subjacente:

   kubectl annotate RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
       cnrm.cloud.google.com/deletion-policy=abandon --overwrite
   

3. Exclua o recurso do cluster do Kubernetes:

   kubectl delete RESOURCE_KIND RESOURCE_NAME -n NAMESPACE
   

4. No manifesto YAML do recurso, defina o valor da anotação cnrm.cloud.google.com/state-into-spec como absent:

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

   Revise o campo spec no manifesto YAML para verificar se ele inclui todos os campos que você quer que o Config Connector gerencie. Omita os campos que você quer que o Google Cloud ou sistemas externos gerenciem automaticamente, como o campo spec.maintenanceVersion em um recurso SQLInstance.

5. Opcional: se o manifesto YAML local também incluir a anotação cnrm.cloud.google.com/deletion-policy: abandon e você não quiser mais a política de exclusão abandon, remova essa anotação do manifesto YAML.

6. Aplique o manifesto YAML atualizado para readquirir o recurso:

   kubectl apply -f MANIFEST_FILE
   

   Substitua MANIFEST_FILE pelo caminho para o arquivo YAML do recurso.

Quando usar cnrm.cloud.google.com/state-into-spec: absent

Na maioria dos casos, use a anotação cnrm.cloud.google.com/state-into-spec: absent para receber o comportamento de preenchimento Absent para campos spec. As seções a seguir descrevem cenários comuns que se beneficiam do comportamento de preenchimento do Absent.

Evitar conflitos com campos atualizados automaticamente pelo Google Cloud

Quando um recurso usa a anotação cnrm.cloud.google.com/state-into-spec: merge, o Config Connector lê valores da API Google Cloud durante o reconciliação inicial e os grava no campo spec do recurso do Kubernetes. Se um serviço do Google Cloud atualizar automaticamente um desses campos, o Config Connector vai tratar o valor mais antigo armazenado no campo spec como o estado de destino e tentar reverter a alteração no recursoGoogle Cloud .

Por exemplo, se você criar um recurso SQLInstance com a anotação cnrm.cloud.google.com/state-into-spec: merge sem especificar o campo spec.maintenanceVersion, o Config Connector vai preencher a versão de manutenção inicial no campo spec.maintenanceVersion. Quando o Cloud SQL realiza uma atualização de manutenção automática na instância, a versão de manutenção ativa no Cloud SQL é atualizada. Durante a próxima reconciliação, o Config Connector tenta corrigir a instância de volta para o valor spec.maintenanceVersion mais antigo. Como o Cloud SQL rejeita downgrades de versão de manutenção, a reconciliação falha repetidamente com um erro UpdateFailed (The requested maintenance version is not an available maintenance version to upgrade).

Ao definir a anotação cnrm.cloud.google.com/state-into-spec: absent, omita campos atualizados automaticamente, como spec.maintenanceVersion, do manifesto YAML. O Config Connector não registra esses campos no campo spec, o que permite que o Google Cloud os atualize sem causar conflitos de reconciliação.

Gerenciar campos não especificados em uma lista externamente

O Config Connector trata todos os campos de lista no campo spec do recurso do Kubernetes como campos atômicos. Como resultado, quando o valor da anotação state-into-spec é definido como merge, o Config Connector reverte qualquer alteração feita em um subcampo em uma lista de fora do Config Connector. No entanto, é possível usar a anotação cnrm.cloud.google.com/state-into-spec: absent para permitir que o Config Connector deixe subcampos não especificados em uma lista não gerenciada. Para mais informações, consulte Comportamento para campos de lista na especificação de recurso.

Resolver conflitos entre ferramentas de gerenciamento de configuração e o Config Connector

Se você estiver usando ferramentas de gerenciamento de configuração, como o Config Sync ou o Argo CD, talvez perceba conflitos entre a ferramenta de gerenciamento de configuração e o Config Connector. Um exemplo é o erro KNV2005, explicado no guia de solução de problemas. Esses problemas ocorrem pelos seguintes motivos:

• Quando o valor da anotação state-into-spec é definido como merge, o Config Connector preenche e define como padrão os valores não especificados em listas no campo spec, como o campo spec.listField[0].itemField2.
• As ferramentas de gerenciamento de configuração e o Config Connector tratam os campos de lista como atômicos. Portanto, as ferramentas de gerenciamento de configuração tratam o campo spec.listField[0].itemField2 adicionado como desvio e o removem.

Para resolver esses problemas, defina a anotação cnrm.cloud.google.com/state-into-spec: absent para que o Config Connector não adicione o campo spec.listField[0].itemField2 não especificado ao campo spec.

Resolver problemas de simetria GET/PUT

A simetria GET/PUT se refere a um princípio de design em APIs REST. Especificamente, isso significa que, quando uma resposta GET é enviada como uma solicitação PUT para o mesmo URL, o resultado esperado é um código de status HTTP 200 OK sem alteração no estado do recurso REST subjacente.

Quando o valor da anotação state-into-spec é definido como merge, os campos não especificados preenchidos pelo Config Connector no campo spec do recurso do Kubernetes são o resultado de uma solicitação GET. Esse comportamento significa que, em futuras reconciliações, o Config Connector pode enviar uma solicitação PUT ou PATCH para a API Google Cloud subjacente com esses valores de campo não especificados aprendidos com a solicitação GET. Normalmente, esse comportamento não é um problema, mas algumas APIs Google Cloud podem rejeitar a solicitação PUT ou PATCH devido a esses valores de campo não especificados. No mesmo exemplo, o campo spec.objectField.subField2 preenchido com o valor "sub-value-2" pode resultar em um erro de cliente HTTP 400 ou outras respostas inesperadas se a implementação da API violar o princípio de simetria GET/PUT.

Para evitar esse tipo de problema, defina a anotação cnrm.cloud.google.com/state-into-spec: absent e verifique se os erros durante o ajuste desaparecem.

Estado observado

Se você precisar definir a anotação cnrm.cloud.google.com/state-into-spec: absent, mas sua solução depender dos valores preenchidos de campos não especificados, verifique se esses campos existem no campo status.observedState no esquema de CRD. Se eles estiverem representados no campo status.observedState, você poderá definir a anotação cnrm.cloud.google.com/state-into-spec: absent e ainda acessar os valores dos campos não especificados após uma reconciliação bem-sucedida.

O campo status.observedState contém o estado ativo dos campos selecionados e observados do recurso que o Config Connector observou na última reconciliação bem-sucedida. O Config Connector seleciona campos observados que são campos spec computados e dependências para casos de uso comuns. Encontre os campos observados nos esquemas de CRD.

Se você não encontrar os campos observados que quer, verifique se há um problema ou abra um novo no Issue Tracker público.

Tipos com suporte para Merge

Veja a seguir todos os tipos de Config Connector que oferecem suporte ao comportamento de preenchimento 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
• Pasta
• 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
• Projeto
• PubSubLiteReservation
• PubSubSchema
• PubSubSubscription
• PubSubTopic
• RecaptchaEnterpriseKey
• RedisInstance
• ResourceManagerLien
• ResourceManagerPolicy
• RunJob
• RunService
• SQLDatabase
• SQLSSLCert
• SQLUser
• SecretManagerSecret
• SecretManagerSecretVersion
• Serviço
• ServiceDirectoryEndpoint
• ServiceDirectoryNamespace
• ServiceDirectoryService
• ServiceIdentity
• ServiceNetworkingConnection
• SourceRepoRepository
• SpannerDatabase
• SpannerInstance
• StorageBucket
• StorageBucketAccessControl
• StorageDefaultObjectAccessControl
• StorageNotification
• StorageTransferJob
• TagsTagBinding
• TagsTagKey
• TagsTagValue
• VPCAccessConnector

Os tipos a seguir não são compatíveis com o comportamento de preenchimento Merge a partir da versão correspondente:

Nome do tipo	Versão
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