Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Ignora i campi non specificati

Questa pagina spiega il comportamento di compilazione predefinito dei campi spec nelle risorse Config Connector e come eseguire la migrazione delle risorse esistenti dal comportamento Merge precedente al comportamento Absent consigliato. Questa pagina potrebbe non essere applicabile se utilizzi una CustomResourceDefinition (CRD) aggiunta nella versione 1.114.0 e successive perché queste CRD supportano solo il comportamento Absent. Per un elenco dei CRD che supportano il comportamento Merge, consulta la sezione Tipi con supporto Merge di questa pagina.

`spec` comportamenti di compilazione dei campi

Quando Config Connector crea una risorsa, i campi non specificati nel campo spec della risorsa Kubernetes possono avere due diversi comportamenti di compilazione: Absent e Merge.

Assente

Il comportamento Absent è quello consigliato. Quando una risorsa utilizza il comportamento Absent, Config Connector non compila i campi non specificati nel campo spec della risorsa Kubernetes.

A partire dalla versione 1.123.1 di Config Connector, il comportamento Absent è il comportamento di compilazione predefinito per tutte le risorse appena create, a meno che non imposti il valore del campo spec.stateIntoSpec su Merge nella risorsa personalizzata ConfigConnector o ConfigConnectorContext. Per le risorse che utilizzano l'annotazione cnrm.cloud.google.com/state-into-spec, Config Connector imposta il valore dell'annotazione su absent in minuscolo per impostazione predefinita (il campo spec.stateIntoSpec utilizza Absent o Merge in maiuscolo). Le risorse riconciliate dai controller diretti utilizzano il comportamento Absent senza aggiungere l'annotazione.

Per le CRD aggiunte nella versione 1.114.0 e successive, il comportamento Absent è l'unico supportato per il popolamento.

Unisci

Il comportamento Merge non è supportato nei CRD aggiunti nella versione 1.114.0 e successive. Quando una risorsa utilizza il comportamento Merge, i campi spec assumono i valori dell'API Google Cloud dopo una riconciliazione riuscita, a meno che i campi non siano leggibili. Per maggiori dettagli, consulta Gestisci i campi esternamente.

Per le CRD aggiunte nella versione 1.113.0 e precedenti, Config Connector supporta i comportamenti Absent e Merge. Per l'elenco completo delle risorse supportate, consulta Tipi con supporto di Merge. Nelle versioni di Config Connector precedenti alla 1.123.1, il comportamento di compilazione predefinito per questi CRD era Merge e Config Connector impostava il valore dell'annotazione cnrm.cloud.google.com/state-into-spec su merge per impostazione predefinita.

Poiché l'annotazione cnrm.cloud.google.com/state-into-spec è immutabile dopo la creazione di una risorsa, le risorse create prima della versione 1.123.1 conservano l'annotazione cnrm.cloud.google.com/state-into-spec: merge anche dopo l'upgrade di Config Connector alla versione 1.123.1 o successive. Per configurare nuove risorse in modo che utilizzino il comportamento Absent, consulta Salta la compilazione dei campi non specificati nella specifica. Per eseguire la migrazione delle risorse esistenti, consulta Esegui la migrazione delle risorse da Merge a Absent.

Quando una risorsa utilizza il comportamento Merge, i campi non specificati nel manifest YAML originale vengono inseriti nel campo spec della risorsa personalizzata nel server API Kubernetes. Questo comportamento significa che quando esegui il comando kubectl get RESOURCE_KIND RESOURCE_NAME -o yaml, il campo spec nell'output può includere campi secondari che non sono presenti nel file YAML applicato.

Ad esempio, supponiamo che lo schema CRD ti consenta di specificare due campi denominati foo e bar nel campo spec, ma il file YAML applicato specifica solo il campo foo:

spec:
  foo: "foo"

Se il manifest YAML viene applicato correttamente e la risorsa è UpToDate, il campo bar viene visualizzato nella risorsa personalizzata:

spec:
  foo: "foo"
  bar: "bar"

Config Connector non compila i campi di riferimento delle risorse non specificati, ad esempio projectRef, folderRef, organizationRef o billingAccountRef, da Google Cloud in spec. Ad esempio, anche se il tipo Project supporta Merge, tutti i suoi campi facoltativi spec (billingAccountRef, folderRef e organizationRef) sono campi di riferimento alle risorse. Di conseguenza, Merge non compila i campi non specificati di una risorsa Project.

A causa della complessità delle interazioni tra Config Connector e le APIGoogle Cloud , utilizza il comportamento Absent in modo che Config Connector salti la compilazione del campo spec della risorsa Kubernetes con campi non specificati.

Salta la compilazione dei campi non specificati nella specifica

Puoi configurare Config Connector in modo che non compili i campi non specificati nel campo spec per i CRD aggiunti in Config Connector versione 1.113.0 e precedenti in uno dei seguenti modi:

Imposta il valore del campo stateIntoSpec a livello di cluster o di spazio dei nomi su Absent.
Nella risorsa, imposta il valore dell'annotazione cnrm.cloud.google.com/state-into-spec su absent.

Configura l'override di `stateIntoSpec` a livello di cluster o di spazio dei nomi

Quando installi Config Connector o aggiorni l'installazione di Config Connector, puoi impostare il valore del campo stateIntoSpec a livello di cluster o di spazio dei nomi su Absent nella risorsa personalizzata ConfigConnector o ConfigConnectorContext:

spec:
  stateIntoSpec: Absent

Questa impostazione rende il comportamento Absent il comportamento predefinito per la compilazione dei campi spec per tutte le nuove risorse create nel cluster o nello spazio dei nomi quando non specifichi l'annotazione cnrm.cloud.google.com/state-into-spec nei manifest YAML delle risorse. Config Connector non compila i campi non specificati nel campo spec della risorsa Kubernetes per queste risorse.

Il campo stateIntoSpec nelle risorse personalizzate ConfigConnector e ConfigConnectorContext non ha un valore predefinito. Config Connector determina il comportamento di compilazione dei campi spec in base al valore dell'annotazione cnrm.cloud.google.com/state-into-spec e segue questo ordine di precedenza per determinare il valore dell'annotazione quando viene creata una risorsa:

Utilizza direttamente il valore dell'annotazione cnrm.cloud.google.com/state-into-spec se è specificato e valido.
Se l'annotazione non è specificata, utilizza il valore corrispondente del campo stateIntoSpec nella risorsa personalizzata ConfigConnectorContext.
Se la risorsa personalizzata ConfigConnectorContext non esiste o il campo stateIntoSpec non è specificato, utilizza il valore corrispondente del campo stateIntoSpec nella risorsa personalizzata ConfigConnector.
Se la risorsa personalizzata ConfigConnector non esiste o il campo stateIntoSpec non è specificato, Config Connector versione 1.123.1 e successive utilizza per impostazione predefinita il valore absent. Le versioni precedenti alla 1.123.1 utilizzano il comportamento predefinito per il CRD, come descritto in Comportamenti di compilazione dei campi spec.

Le CRD aggiunte nella versione 1.114.0 e successive supportano solo il comportamento di compilazione Absent, indipendentemente dal campo stateIntoSpec nella risorsa personalizzata ConfigConnector o ConfigConnectorContext.

Se hai già creato una risorsa con il comportamento Merge, l'aggiornamento del valore del campo stateIntoSpec a Absent nella risorsa personalizzata ConfigConnector o ConfigConnectorContext non modifica l'annotazione della risorsa esistente. Per eseguire la migrazione delle risorse esistenti, vedi Eseguire la migrazione delle risorse da Merge a Absent.

Imposta l'annotazione `cnrm.cloud.google.com/state-into-spec` a livello di risorsa

Quando crei il file YAML, puoi impostare il valore dell'annotazione cnrm.cloud.google.com/state-into-spec su absent. Questa annotazione salta la compilazione dei campi non specificati nel campo spec della risorsa Kubernetes:

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

In Config Connector versione 1.123.1 e successive, questa annotazione viene impostata per impostazione predefinita sul valore absent se non è specificata (a meno che non venga eseguito l'override impostando il valore del campo spec.stateIntoSpec su Merge nella risorsa personalizzata ConfigConnector o ConfigConnectorContext). Nelle versioni precedenti alla 1.123.1, questa annotazione utilizzava per impostazione predefinita il valore merge per le CRD aggiunte nella versione 1.113.0 e precedenti, il che significa che Config Connector inseriva tutti i campi non specificati nel campo spec.

Questa annotazione è immutabile, il che significa che non puoi aggiornare il valore dell'annotazione direttamente su una risorsa Config Connector esistente. Se hai già creato una risorsa con il valore merge e vuoi modificare il suo comportamento in modo che corrisponda al valore absent, consulta Migrazione delle risorse da Merge a Absent.

Per spiegare ulteriormente la differenza introdotta da questa annotazione, supponiamo che una risorsa abbia un campo spec con il seguente schema:

foo1: string
foo2: string
bars:
- br1: string
  br2: string
barz:
  bz1: string
  bz2: string

Supponiamo inoltre che tu abbia specificato il campo spec nel manifest YAML come:

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

Quando il valore dell'annotazione cnrm.cloud.google.com/state-into-spec è impostato su merge, il campo spec compilato nella risorsa Kubernetes creata è simile al seguente:

spec:
  foo1: "foo1"
  foo2: "foo2"
  bars:
  - br1: "1_br1"
    br2: "1_br2"
  - br1: "2_br1"
    br2: "2_br2"
  barz:
    bz1: "bz1"
    bz2: "bz2"

Quando imposti l'annotazione cnrm.cloud.google.com/state-into-spec: absent, il campo spec finale nella risorsa Kubernetes creata rimane:

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

Esegui la migrazione delle risorse da `Merge` a `Absent`

Poiché l'annotazione cnrm.cloud.google.com/state-into-spec è immutabile su una risorsa Kubernetes esistente, l'upgrade di Config Connector alla versione 1.123.1 o successive non modifica automaticamente le risorse esistenti dal valore merge al valore absent.

La migrazione delle risorse e degli spazi dei nomi esistenti dal comportamento Merge al comportamento Absent aiuta a prevenire i seguenti problemi:

Errori di riconciliazione nei campi aggiornati automaticamente: Google Cloud aggiorna automaticamente determinati campi delle risorse sottostanti, ad esempio le versioni di manutenzione o le impostazioni di scalabilità automatica. Le risorse con l'annotazione state-into-spec: merge potrebbero non riuscire a eseguire la riconciliazione o entrare in un loop di aggiornamento infinito nel tentativo di ripristinare il campo al valore spec precedente.
Conflitti con GitOps e strumenti di gestione della configurazione: strumenti come Config Sync e Argo CD possono entrare in conflitto con Config Connector quando il comportamento di Merge compila i campi secondari non specificati negli elenchi.
Errori di convalida su tipi di risorse più recenti: se il valore del campo spec.stateIntoSpec è impostato su Merge in una risorsa personalizzata ConfigConnector o ConfigConnectorContext, la gestione delle risorse che non supportano il comportamento Merge può causare errori di convalida (invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation).

Identifica gli spazi dei nomi e le risorse interessati

Prima di eseguire la migrazione, controlla le impostazioni a livello di cluster, spazio dei nomi e risorsa per identificare dove viene ancora utilizzato il comportamento Merge:

Controlla la risorsa personalizzata ConfigConnector a livello di cluster per un override del campo stateIntoSpec:

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

Controlla tutte le risorse personalizzate ConfigConnectorContext a livello di spazio dei nomi per verificare la presenza di override del campo stateIntoSpec:
```
kubectl get configconnectorcontext -A \
    -o custom-columns=NAMESPACE:.metadata.namespace,STATE_INTO_SPEC:.spec.stateIntoSpec
```
Controlla il valore dell'annotazione cnrm.cloud.google.com/state-into-spec su una risorsa Config Connector esistente:
```
kubectl get RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/state-into-spec}{"\n"}'
```
Sostituisci quanto segue:
- RESOURCE_KIND: il tipo di risorsa Config Connector, ad esempio SQLInstance.
- RESOURCE_NAME: il nome della risorsa.
- NAMESPACE: lo spazio dei nomi della risorsa.

Eseguire la migrazione di una risorsa a `Absent`

Per modificare il comportamento di compilazione di una risorsa esistente da Merge a Absent, devi abbandonare la risorsa Kubernetes e acquisire nuovamente la risorsa Google Cloud sottostante con l'annotazione cnrm.cloud.google.com/state-into-spec: absent. Per abbandonare e acquisire nuovamente la risorsa, completa i seguenti passaggi:

Se il valore del campo spec.stateIntoSpec è impostato su Merge nella risorsa personalizzata ConfigConnector o ConfigConnectorContext, aggiorna il valore del campo a Absent:
```
spec:
  stateIntoSpec: Absent
```
Aggiungi l'annotazione cnrm.cloud.google.com/deletion-policy: abandon alla risorsa Config Connector esistente nel cluster. Questa annotazione consente di assicurarsi che l'eliminazione della risorsa Kubernetes nel passaggio successivo non elimini la risorsa Google Cloud sottostante:
```
kubectl annotate RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    cnrm.cloud.google.com/deletion-policy=abandon --overwrite
```

Elimina la risorsa dal cluster Kubernetes:

kubectl delete RESOURCE_KIND RESOURCE_NAME -n NAMESPACE

Nel manifest YAML della risorsa, imposta il valore dell'annotazione cnrm.cloud.google.com/state-into-spec su absent:
```
metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent
```
Esamina il campo spec nel manifest YAML per verificare che includa tutti i campi che vuoi che Config Connector gestisca. Ometti i campi che vuoi che Google Cloud o i sistemi esterni gestiscano automaticamente, ad esempio il campo spec.maintenanceVersion in una risorsa SQLInstance.
(Facoltativo) Se il file manifest YAML locale include anche l'annotazione cnrm.cloud.google.com/deletion-policy: abandon e non vuoi più la politica di cancellazione abandon, rimuovi l'annotazione dal file manifest YAML.
Applica il manifest YAML aggiornato per riacquisire la risorsa:
```
kubectl apply -f MANIFEST_FILE
```
Sostituisci MANIFEST_FILE con il percorso del file YAML della risorsa.

Quando utilizzare l'attributo `cnrm.cloud.google.com/state-into-spec: absent`

Nella maggior parte dei casi, utilizza l'annotazione cnrm.cloud.google.com/state-into-spec: absent per ottenere il comportamento di compilazione di Absent per i campi spec. Le sezioni seguenti descrivono gli scenari comuni che traggono vantaggio dal comportamento di compilazione di Absent.

Evita conflitti con i campi aggiornati automaticamente da Google Cloud

Quando una risorsa utilizza l'annotazione cnrm.cloud.google.com/state-into-spec: merge, Config Connector legge i valori dall'API Google Cloud durante la riconciliazione iniziale e li scrive nel campo spec della risorsa Kubernetes. Se un servizio Google Cloud aggiorna in un secondo momento uno di questi campi automaticamente, Config Connector considera il valore precedente archiviato nel campo spec come stato di destinazione e tenta di ripristinare la modifica nella risorsaGoogle Cloud sottostante.

Ad esempio, se crei una risorsa SQLInstance con l'annotazione cnrm.cloud.google.com/state-into-spec: merge senza specificare il campo spec.maintenanceVersion, Config Connector inserisce la versione di manutenzione iniziale nel campo spec.maintenanceVersion. Quando Cloud SQL esegue in un secondo momento un aggiornamento di manutenzione automatico sull'istanza, la versione di manutenzione live in Cloud SQL viene aggiornata. Durante la riconciliazione successiva, Config Connector tenta di applicare una patch all'istanza per ripristinare il valore spec.maintenanceVersion precedente. Poiché Cloud SQL rifiuta i downgrade della versione di manutenzione, la riconciliazione non va a buon fine ripetutamente con un errore UpdateFailed (The requested maintenance version is not an available maintenance version to upgrade).

Quando imposti l'annotazione cnrm.cloud.google.com/state-into-spec: absent, ometti i campi aggiornati automaticamente, ad esempio spec.maintenanceVersion, dal manifest YAML. Config Connector non registra questi campi nel campo spec, che consente Google Cloud di aggiornarli senza causare conflitti di riconciliazione.

Gestisci i campi non specificati in un elenco esternamente

Config Connector considera tutti i campi elenco nel campo spec della risorsa Kubernetes come campi atomici. Di conseguenza, quando il valore dell'annotazione state-into-spec è impostato su merge, Config Connector annulla qualsiasi modifica apportata a un campo secondario in un elenco dall'esterno di Config Connector. Tuttavia, puoi utilizzare l'annotazione cnrm.cloud.google.com/state-into-spec: absent per consentire a Config Connector di lasciare i campi secondari non specificati in un elenco non gestito. Per saperne di più, consulta Comportamento per i campi elenco nella specifica della risorsa.

Risolvi i conflitti tra gli strumenti di gestione della configurazione e Config Connector

Se utilizzi strumenti di gestione della configurazione come Config Sync o Argo CD, potresti notare conflitti tra lo strumento di gestione della configurazione e Config Connector. Un esempio è l'errore KNV2005 spiegato nella guida alla risoluzione dei problemi. Questi problemi si verificano per i seguenti motivi:

Quando il valore dell'annotazione state-into-spec è impostato su merge, Config Connector compila e imposta come predefiniti i valori non specificati negli elenchi del campo spec, ad esempio il campo spec.bars[0].br2.
Gli strumenti di gestione della configurazione e Config Connector trattano i campi elenco come atomici, quindi gli strumenti di gestione della configurazione trattano il campo spec.bars[0].br2 aggiunto come deriva e lo rimuovono.

Per risolvere questi problemi, puoi impostare l'annotazione cnrm.cloud.google.com/state-into-spec: absent in modo che Config Connector non aggiunga il campo spec.bars[0].br2 non specificato al campo spec.

Risolvi i problemi di simmetria GET/PUT

La simmetria GET/PUT si riferisce a un principio di progettazione delle API REST. Nello specifico, significa che quando una risposta GET viene inviata come richiesta PUT allo stesso URL, il risultato previsto è un codice di stato HTTP 200 OK senza alcuna modifica dello stato della risorsa REST sottostante.

Quando il valore dell'annotazione state-into-spec è impostato su merge, i campi non specificati compilati da Config Connector nel campo spec della risorsa Kubernetes sono il risultato di una richiesta GET. Questo comportamento significa che nelle future riconciliazioni, Config Connector potrebbe inviare una richiesta PUT o PATCH all'API Google Cloud sottostante con questi valori di campo non specificati appresi dalla richiesta GET. Questo comportamento di solito non è un problema, ma alcune API Google Cloud potrebbero rifiutare la richiesta PUT o PATCH a causa di questi valori di campo non specificati. Nello stesso esempio, il campo spec.barz.bz2 compilato con il valore "bz2" potrebbe generare un errore client HTTP 400 o altre risposte impreviste se l'implementazione dell'API viola il principio di simmetria GET/PUT.

Per evitare questo tipo di problemi, puoi impostare l'annotazione cnrm.cloud.google.com/state-into-spec: absent e verificare se gli errori durante la riconciliazione scompaiono.

Stato osservato

Se devi impostare l'annotazione cnrm.cloud.google.com/state-into-spec: absent, ma la tua soluzione dipende dai valori compilati da campi non specificati, controlla se questi campi esistono nel campo status.observedState nello schema CRD. Se sono rappresentati nel campo status.observedState, puoi impostare l'annotazione cnrm.cloud.google.com/state-into-spec: absent e accedere comunque ai valori dei campi non specificati dopo una riconciliazione riuscita.

Il campo status.observedState contiene lo stato in tempo reale dei campi selezionati e osservati della risorsa osservata da Config Connector nell'ultima riconciliazione riuscita. Config Connector seleziona i campi osservati che sono campi spec calcolati e dipendenze per i casi d'uso comuni. Puoi trovare i campi osservati negli schemi CRD.

Se non riesci a trovare i campi osservati che ti interessano, controlla se esiste un problema o aprine uno nuovo nell'Issue Tracker pubblico.

Tipi con supporto `Merge`

Di seguito sono riportati tutti i tipi di Config Connector che supportano il comportamento di compilazione di 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
Cartella
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
Progetto
PubSubLiteReservation
PubSubSchema
PubSubSubscription
PubSubTopic
RecaptchaEnterpriseKey
RedisInstance
ResourceManagerLien
ResourceManagerPolicy
RunJob
RunService
SQLDatabase
SQLSSLCert
SQLUser
SecretManagerSecret
SecretManagerSecretVersion
Servizio
ServiceDirectoryEndpoint
ServiceDirectoryNamespace
ServiceDirectoryService
ServiceIdentity
ServiceNetworkingConnection
SourceRepoRepository
SpannerDatabase
SpannerInstance
StorageBucket
StorageBucketAccessControl
StorageDefaultObjectAccessControl
StorageNotification
StorageTransferJob
TagsTagBinding
TagsTagKey
TagsTagValue
VPCAccessConnector

I seguenti tipi non supportano il comportamento di compilazione di Merge a partire dalla versione corrispondente:

Nome del tipo	Versione
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