Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Ignorer les champs non spécifiés

Cette page explique le comportement de remplissage par défaut des champs spec dans les ressources Config Connector, et comment migrer les ressources existantes de l'ancien comportement Merge vers le comportement recommandé Absent. Il est possible que cette page ne s'applique pas si vous utilisez une CustomResourceDefinition (CRD) ajoutée dans la version 1.114.0 ou ultérieure, car ces CRD ne sont compatibles qu'avec le comportement Absent. Pour obtenir la liste des CRD compatibles avec le comportement Merge, consultez la section Types compatibles avec Merge de cette page.

Comportements de remplissage des champs `spec`

Lorsque Config Connector crée une ressource, les champs non spécifiés dans le champ spec de la ressource Kubernetes peuvent avoir deux comportements de remplissage différents : Absent et Merge.

Manquante

Le comportement Absent est le comportement recommandé. Lorsqu'une ressource utilise le comportement Absent, Config Connector ne renseigne pas les champs non spécifiés dans le champ spec de la ressource Kubernetes.

À partir de la version 1.123.1 de Config Connector, le comportement Absent est le comportement de remplissage par défaut pour toutes les ressources nouvellement créées, sauf si vous définissez la valeur du champ spec.stateIntoSpec sur Merge dans votre ressource personnalisée ConfigConnector ou ConfigConnectorContext. Pour les ressources qui utilisent l'annotation cnrm.cloud.google.com/state-into-spec, Config Connector définit par défaut la valeur de l'annotation sur absent en minuscules (le champ spec.stateIntoSpec utilise Absent ou Merge en majuscules). Les ressources rapprochées par des contrôleurs directs utilisent le comportement Absent sans ajouter l'annotation.

Pour les CRD ajoutés dans la version 1.114.0 et les versions ultérieures, le comportement Absent est le seul comportement de remplissage accepté.

Fusionner

Le comportement Merge n'est pas compatible avec les CRD ajoutées dans la version 1.114.0 et ultérieures. Lorsqu'une ressource utilise le comportement Merge, les champs spec prennent les valeurs de l'API Google Cloud après un rapprochement réussi, sauf si ces champs ne sont pas lisibles. Pour en savoir plus, consultez Gérer les champs en externe.

Pour les CRD ajoutées dans la version 1.113.0 et les versions antérieures, Config Connector est compatible avec les comportements Absent et Merge. Pour obtenir la liste complète des ressources compatibles, consultez Genres compatibles avec Merge. Dans les versions de Config Connector antérieures à 1.123.1, le comportement de remplissage par défaut de ces CRD était Merge, et Config Connector définissait la valeur de l'annotation cnrm.cloud.google.com/state-into-spec sur merge par défaut.

Étant donné que l'annotation cnrm.cloud.google.com/state-into-spec est immuable une fois la ressource créée, les ressources créées avant la version 1.123.1 conservent l'annotation cnrm.cloud.google.com/state-into-spec: merge même après la mise à niveau de Config Connector vers la version 1.123.1 ou ultérieure. Pour configurer de nouvelles ressources afin qu'elles utilisent le comportement Absent, consultez Ignorer le renseignement des champs non spécifiés dans la spécification. Pour migrer des ressources existantes, consultez Migrer des ressources de Merge vers Absent.

Lorsqu'une ressource utilise le comportement Merge, les champs qui ne sont pas spécifiés dans votre fichier manifeste YAML d'origine sont renseignés dans le champ spec de la ressource personnalisée sur le serveur d'API Kubernetes. Cela signifie que lorsque vous exécutez la commande kubectl get RESOURCE_KIND RESOURCE_NAME -o yaml, le champ spec dans la sortie peut inclure des sous-champs qui ne figurent pas dans le fichier YAML appliqué.

Par exemple, supposons que le schéma CRD vous permette de spécifier deux champs nommés field1 et field2 dans le champ spec, mais que votre fichier YAML appliqué ne spécifie que le champ field1 :

spec:
  field1: "value-1"

Si le fichier manifeste YAML est appliqué correctement et que la ressource est UpToDate, le champ field2 apparaît dans la ressource personnalisée :

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

Config Connector ne remplit pas les champs de référence de ressources non spécifiés, tels que projectRef, folderRef, organizationRef ou billingAccountRef, deGoogle Cloud dans spec. Par exemple, même si le genre Project est compatible avec Merge, tous ses champs spec facultatifs (billingAccountRef, folderRef et organizationRef) sont des champs de référence de ressource. Par conséquent, Merge ne renseigne aucun champ non spécifié sur une ressource Project.

En raison de la complexité des interactions entre Config Connector et les APIGoogle Cloud , utilisez le comportement Absent afin que Config Connector n'ajoute pas de champs non spécifiés au champ spec de la ressource Kubernetes.

Ignorer l'ajout des champs non spécifiés dans la spécification

Vous pouvez configurer Config Connector pour qu'il ignore le remplissage des champs non spécifiés dans le champ spec pour les CRD ajoutés dans Config Connector version 1.113.0 et versions antérieures de l'une des manières suivantes :

Définissez la valeur du champ stateIntoSpec au niveau du cluster ou de l'espace de noms sur Absent.
Sur la ressource, définissez la valeur de l'annotation cnrm.cloud.google.com/state-into-spec sur absent.

Configurer le remplacement de `stateIntoSpec` au niveau du cluster ou de l'espace de noms

Lorsque vous installez Config Connector ou que vous mettez à jour votre installation Config Connector, vous pouvez définir la valeur du champ stateIntoSpec au niveau du cluster ou de l'espace de noms sur Absent dans la ressource personnalisée ConfigConnector ou ConfigConnectorContext :

spec:
  stateIntoSpec: Absent

Ce paramètre fait du comportement Absent le comportement par défaut de remplissage des champs spec pour toutes les nouvelles ressources créées dans le cluster ou l'espace de noms lorsque vous ne spécifiez pas l'annotation cnrm.cloud.google.com/state-into-spec dans les fichiers manifestes YAML des ressources. Config Connector ne renseigne pas les champs non spécifiés dans le champ spec de la ressource Kubernetes pour ces ressources.

Le champ stateIntoSpec des ressources personnalisées ConfigConnector et ConfigConnectorContext n'a pas de valeur par défaut. Config Connector détermine le comportement de remplissage des champs spec en fonction de la valeur de l'annotation cnrm.cloud.google.com/state-into-spec. Il suit cet ordre de priorité pour déterminer la valeur de l'annotation lorsqu'une ressource est créée :

Utilisez directement la valeur de l'annotation cnrm.cloud.google.com/state-into-spec si elle est spécifiée et valide.
Si l'annotation n'est pas spécifiée, utilisez la valeur correspondante du champ stateIntoSpec dans la ressource personnalisée ConfigConnectorContext.
Si la ressource personnalisée ConfigConnectorContext n'existe pas ou si le champ stateIntoSpec n'est pas spécifié, utilisez la valeur correspondante du champ stateIntoSpec dans la ressource personnalisée ConfigConnector.
Si la ressource personnalisée ConfigConnector n'existe pas ou si le champ stateIntoSpec n'est pas spécifié, Config Connector version 1.123.1 et ultérieures utilise par défaut la valeur absent. Les versions antérieures à la version 1.123.1 utilisent le comportement par défaut du CRD, comme décrit dans Comportements de remplissage des champs spec.

Les CRD ajoutées dans la version 1.114.0 et les versions ultérieures ne sont compatibles qu'avec le comportement de remplissage Absent, quel que soit le champ stateIntoSpec de la ressource personnalisée ConfigConnector ou ConfigConnectorContext.

Si vous avez déjà créé une ressource avec le comportement Merge, la mise à jour de la valeur du champ stateIntoSpec sur Absent dans la ressource personnalisée ConfigConnector ou ConfigConnectorContext ne modifie pas l'annotation de la ressource existante. Pour migrer des ressources existantes, consultez Migrer des ressources de Merge vers Absent.

Définir l'annotation `cnrm.cloud.google.com/state-into-spec` au niveau de la ressource

Lorsque vous créez votre fichier YAML, vous pouvez définir la valeur de l'annotation cnrm.cloud.google.com/state-into-spec sur absent. Cette annotation ignore le renseignement des champs non spécifiés dans le champ spec de la ressource Kubernetes :

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

Dans Config Connector 1.123.1 et versions ultérieures, cette annotation est définie par défaut sur la valeur absent si elle n'est pas spécifiée (sauf si vous la remplacez en définissant la valeur du champ spec.stateIntoSpec sur Merge dans votre ressource personnalisée ConfigConnector ou ConfigConnectorContext). Dans les versions antérieures à la version 1.123.1, cette annotation était définie par défaut sur la valeur merge pour les CRD ajoutés dans la version 1.113.0 et les versions antérieures, ce qui signifie que Config Connector renseignait tous les champs non spécifiés dans le champ spec.

Cette annotation est immuable, ce qui signifie que vous ne pouvez pas modifier sa valeur directement sur une ressource Config Connector existante. Si vous avez déjà créé une ressource avec la valeur merge et que vous souhaitez modifier son comportement pour la valeur absent, consultez Migrer des ressources de Merge vers Absent.

Pour mieux expliquer la différence introduite par cette annotation, supposons qu'une ressource comporte un champ spec avec le schéma suivant :

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

Supposons également que vous avez spécifié le champ spec dans votre fichier manifeste YAML comme suit :

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

Lorsque la valeur de l'annotation cnrm.cloud.google.com/state-into-spec est définie sur merge, le champ spec renseigné dans la ressource Kubernetes créée ressemble à ce qui suit :

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"

Lorsque vous définissez l'annotation cnrm.cloud.google.com/state-into-spec: absent, le champ spec final de la ressource Kubernetes créée reste :

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

Migrer des ressources de `Merge` vers `Absent`

Étant donné que l'annotation cnrm.cloud.google.com/state-into-spec est immuable sur une ressource Kubernetes existante, la mise à niveau de Config Connector vers la version 1.123.1 ou ultérieure ne modifie pas automatiquement les ressources existantes en remplaçant la valeur merge par la valeur absent.

La migration de vos ressources et espaces de noms existants du comportement Merge vers le comportement Absent permet d'éviter les problèmes suivants :

Erreurs de rapprochement sur les champs mis à jour automatiquement : Google Cloudmet à jour automatiquement certains champs sur les ressources sous-jacentes, tels que les versions de maintenance ou les paramètres d'autoscaling. La rapprochement des ressources avec l'annotation state-into-spec: merge peut échouer ou entrer dans une boucle de mise à jour sans fin pour tenter de rétablir l'ancienne valeur spec du champ.
Conflits avec les outils GitOps et de gestion de la configuration : des outils tels que Config Sync et Argo CD peuvent entrer en conflit avec Config Connector lorsque le comportement Merge remplit les sous-champs non spécifiés dans les listes.
Erreurs de validation sur les types de ressources plus récents : si la valeur du champ spec.stateIntoSpec est définie sur Merge sur une ressource personnalisée ConfigConnector ou ConfigConnectorContext, la gestion des ressources qui ne sont pas compatibles avec le comportement Merge peut entraîner des erreurs de validation (invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation).

Identifier les espaces de noms et les ressources concernés

Avant la migration, vérifiez vos paramètres au niveau du cluster, de l'espace de noms et des ressources pour identifier où le comportement Merge est encore utilisé :

Vérifiez la ressource personnalisée ConfigConnector au niveau du cluster pour un remplacement du champ stateIntoSpec :

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

Vérifiez toutes les ressources personnalisées ConfigConnectorContext au niveau de l'espace de noms pour les remplacements de champs stateIntoSpec :
```
kubectl get configconnectorcontext -A \
    -o custom-columns=NAMESPACE:.metadata.namespace,STATE_INTO_SPEC:.spec.stateIntoSpec
```
Vérifiez la valeur de l'annotation cnrm.cloud.google.com/state-into-spec sur une ressource Config Connector existante :
```
kubectl get RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/state-into-spec}{"\n"}'
```
Remplacez les éléments suivants :
- RESOURCE_KIND : type de ressource Config Connector, par exemple SQLInstance.
- RESOURCE_NAME : nom de la ressource.
- NAMESPACE : espace de noms de la ressource.

Migrer une ressource vers `Absent`

Pour modifier le comportement de remplissage d'une ressource existante de Merge à Absent, vous devez abandonner la ressource Kubernetes et récupérer la ressource Google Cloud sous-jacente avec l'annotation cnrm.cloud.google.com/state-into-spec: absent. Pour abandonner et réacquérir la ressource, procédez comme suit :

Si la valeur du champ spec.stateIntoSpec est définie sur Merge dans votre ressource personnalisée ConfigConnector ou ConfigConnectorContext, remplacez-la par Absent :
```
spec:
  stateIntoSpec: Absent
```
Ajoutez l'annotation cnrm.cloud.google.com/deletion-policy: abandon à la ressource Config Connector existante dans votre cluster. Cette annotation permet de s'assurer que la suppression de la ressource Kubernetes à l'étape suivante n'entraîne pas la suppression de la ressource Google Cloud sous-jacente :
```
kubectl annotate RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    cnrm.cloud.google.com/deletion-policy=abandon --overwrite
```

Supprimez la ressource de votre cluster Kubernetes :

kubectl delete RESOURCE_KIND RESOURCE_NAME -n NAMESPACE

Dans le fichier manifeste YAML de votre ressource, définissez la valeur de l'annotation cnrm.cloud.google.com/state-into-spec sur absent :
```
metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent
```
Examinez le champ spec de votre fichier manifeste YAML pour vérifier qu'il inclut tous les champs que vous souhaitez que Config Connector gère. Omettez les champs que vous souhaitez que Google Cloud ou les systèmes externes gèrent automatiquement, comme le champ spec.maintenanceVersion sur une ressource SQLInstance.
Facultatif : Si votre fichier manifeste YAML local inclut également l'annotation cnrm.cloud.google.com/deletion-policy: abandon et que vous ne souhaitez plus appliquer le règlement relatif à la suppression abandon, supprimez cette annotation du fichier manifeste YAML.
Appliquez le fichier manifeste YAML mis à jour pour réacquérir la ressource :
```
kubectl apply -f MANIFEST_FILE
```
Remplacez MANIFEST_FILE par le chemin d'accès au fichier YAML de votre ressource.

Dans quel contexte utiliser `cnrm.cloud.google.com/state-into-spec: absent` ?

Dans la plupart des cas, utilisez l'annotation cnrm.cloud.google.com/state-into-spec: absent pour obtenir le comportement de remplissage Absent pour les champs spec. Les sections suivantes décrivent les scénarios courants qui bénéficient du comportement de remplissage Absent.

Éviter les conflits avec les champs mis à jour automatiquement par Google Cloud

Lorsqu'une ressource utilise l'annotation cnrm.cloud.google.com/state-into-spec: merge, Config Connector lit les valeurs de l'API Google Cloud lors de la réconciliation initiale et les écrit dans le champ spec de la ressource Kubernetes. Si un service Google Cloud met à jour automatiquement l'un de ces champs ultérieurement, Config Connector considère l'ancienne valeur stockée dans le champspeccomme l'état cible et tente d'annuler la modification apportée à la ressourceGoogle Cloud sous-jacente.

Par exemple, si vous créez une ressource SQLInstance avec l'annotation cnrm.cloud.google.com/state-into-spec: merge sans spécifier le champ spec.maintenanceVersion, Config Connector renseigne la version de maintenance initiale dans le champ spec.maintenanceVersion. Lorsque Cloud SQL effectue ultérieurement une mise à jour de maintenance automatique sur l'instance, la version de maintenance en direct dans Cloud SQL est mise à jour. Lors du rapprochement suivant, Config Connector tente de corriger l'instance pour rétablir l'ancienne valeur spec.maintenanceVersion. Étant donné que Cloud SQL refuse les rétrogradations de version de maintenance, la réconciliation échoue à plusieurs reprises avec une erreur UpdateFailed (The requested maintenance version is not an available maintenance version to upgrade).

Lorsque vous définissez l'annotation cnrm.cloud.google.com/state-into-spec: absent, omettez les champs mis à jour automatiquement, tels que spec.maintenanceVersion, de votre fichier manifeste YAML. Config Connector n'enregistre pas ces champs dans le champ spec, ce qui permet à Google Cloud de les mettre à jour sans provoquer de conflits de rapprochement.

Gérer les champs non spécifiés dans une liste externe

Config Connector traite tous les champs de liste du champ spec de la ressource Kubernetes comme des champs atomiques. Par conséquent, lorsque la valeur de l'annotation state-into-spec est définie sur merge, Config Connector annule toute modification apportée à un sous-champ d'une liste en dehors de Config Connector. Toutefois, vous pouvez utiliser l'annotation cnrm.cloud.google.com/state-into-spec: absent pour que Config Connector laisse les sous-champs non spécifiés d'une liste non gérés. Pour en savoir plus, consultez Comportement des champs de liste dans la spécification de ressource.

Résoudre les conflits entre les outils de gestion de configuration et Config Connector

Si vous utilisez des outils de gestion de configuration tels que Config Sync ou Argo CD, vous pouvez rencontrer des conflits entre l'outil de gestion de configuration et Config Connector. L'erreur KNV2005 expliquée dans le guide de dépannage en est un exemple. Ces problèmes surviennent pour les raisons suivantes :

Lorsque la valeur de l'annotation state-into-spec est définie sur merge, Config Connector renseigne et définit par défaut les valeurs non spécifiées dans les listes du champ spec, telles que le champ spec.listField[0].itemField2.
Les outils de gestion de la configuration et Config Connector traitent les champs de liste comme des éléments atomiques. Par conséquent, les outils de gestion de la configuration traitent le champ spec.listField[0].itemField2 ajouté comme une dérive et le suppriment.

Pour résoudre ces problèmes, vous pouvez définir l'annotation cnrm.cloud.google.com/state-into-spec: absent afin que Config Connector n'ajoute pas le champ spec.listField[0].itemField2 non spécifié dans le champ spec.

Résoudre les problèmes de symétrie GET/PUT

La symétrie GET/PUT fait référence à un principe de conception des API REST. Plus précisément, cela signifie que lorsqu'une réponse GET est envoyée en tant que requête PUT à la même URL, le résultat attendu est un code d'état HTTP 200 OK sans modification de l'état de la ressource REST sous-jacente.

Lorsque la valeur de l'annotation state-into-spec est définie sur merge, les champs non spécifiés renseignés par Config Connector dans le champ spec de la ressource Kubernetes sont le résultat d'une requête GET. Ce comportement signifie que lors des futures réconciliations, Config Connector peut envoyer une requête PUT ou PATCH à l'APIGoogle Cloud sous-jacente avec ces valeurs de champ non spécifiées apprises à partir de la requête GET. Ce comportement ne pose généralement pas de problème, mais certaines API Google Cloud peuvent rejeter la requête PUT ou PATCH en raison de ces valeurs de champ non spécifiées. Dans le même exemple, le champ spec.objectField.subField2 renseigné avec la valeur "sub-value-2" peut entraîner une erreur client HTTP 400 ou d'autres réponses inattendues si l'implémentation de l'API ne respecte pas le principe de symétrie GET/PUT.

Pour éviter ce type de problème, vous pouvez définir l'annotation cnrm.cloud.google.com/state-into-spec: absent et vérifier si les erreurs disparaissent lors du rapprochement.

État observé

Si vous devez définir l'annotation cnrm.cloud.google.com/state-into-spec: absent, mais que votre solution dépend des valeurs renseignées à partir de champs non spécifiés, vérifiez si ces champs existent dans le champ status.observedState du schéma CRD. S'ils sont représentés dans le champ status.observedState, vous pouvez définir l'annotation cnrm.cloud.google.com/state-into-spec: absent et accéder aux valeurs des champs non spécifiés après un rapprochement réussi.

Le champ status.observedState contient l'état en direct des champs sélectionnés et observés de la ressource que Config Connector a observée lors du dernier rapprochement réussi. Config Connector sélectionne les champs observés qui sont des champs spec calculés et des dépendances pour les cas d'utilisation courants. Vous trouverez les champs observés dans les schémas CRD.

Si vous ne trouvez pas les champs observés que vous souhaitez, recherchez un problème existant ou signalez un nouveau problème dans l'Issue Tracker public.

Genres compatibles avec `Merge`

Voici tous les types de Config Connector compatibles avec le comportement de renseignement 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
Tâche Cloud Scheduler
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
Dossier
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
Projet
PubSubLiteReservation
PubSubSchema
PubSubSubscription
PubSubTopic
RecaptchaEnterpriseKey
RedisInstance
ResourceManagerLien
ResourceManagerPolicy
RunJob
RunService
SQLDatabase
SQLSSLCert
SQLUser
SecretManagerSecret
SecretManagerSecretVersion
Service
ServiceDirectoryEndpoint
ServiceDirectoryNamespace
ServiceDirectoryService
ServiceIdentity
ServiceNetworkingConnection
SourceRepoRepository
SpannerDatabase
SpannerInstance
StorageBucket
StorageBucketAccessControl
StorageDefaultObjectAccessControl
StorageNotification
StorageTransferJob
TagsTagBinding
TagsTagKey
TagsTagValue
VPCAccessConnector

Les types suivants ne sont pas compatibles avec le comportement de remplissage Merge à partir de la version correspondante :

Nom du genre	Version
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