Cette page a été traduite par l'API Cloud Translation.

Ignorer les champs non spécifiés

Cette page explique le comportement de remplissage par défaut des champs spec et comment modifier le comportement par défaut de Merge pour adopter le comportement recommandé Absent. Cette page ne s'applique peut-être pas si vous utilisez un CRD ajouté dans la version 1.114.0 ou ultérieure, car ces CRD n'utilisent que le comportement Absent. Pour obtenir la liste des CRD compatibles avec Merge, consultez la section CRD compatibles avec Merge sur cette page.

Comportements de remplissage des champs `spec`

Lorsque Config Connector crée une ressource, les champs laissés vides dans la spécification de la ressource Kubernetes peuvent avoir deux comportements de remplissage par défaut différents : Absent et Merge.

Manquante

Absent est le comportement recommandé. Config Connector ne renseignera aucun champ non spécifié dans la spécification.

Pour les CRD ajoutées dans la version 1.114.0 et ultérieures, le comportement de remplissage par défaut est Absent. Il s'agit également du seul comportement de remplissage pris en charge par ces CRD. La valeur de l'annotation cnrm.cloud.google.com/state-into-spec est absent dans ces CR de ressources.

Fusionner

Merge n'est pas un comportement compatible dans les CRD ajoutées dans la version 1.114.0 et ultérieures. Les champs spec prennent des valeurs de l'API après une réconciliation réussie, sauf s'ils ne sont pas lisibles. Pour en savoir plus, consultez Gérer les champs en externe.

Pour les CRD compatibles avec Config Connector version 1.113.0 et les versions antérieures, le comportement de remplissage par défaut est Merge. Pour obtenir la liste des CRD compatibles avec Merge, consultez la section CRD compatibles avec Merge sur cette page. La valeur par défaut de l'annotation cnrm.cloud.google.com/state-into-spec est merge dans ces CR de ressources. Vous pouvez également configurer le comportement de remplissage sur Absent en suivant les instructions de la section Ignorer le remplissage des champs non spécifiés dans la spécification.

Par défaut, dans ces CR de ressources, les champs qui n'ont pas été spécifiés dans votre fichier YAML d'origine apparaissent toujours dans la spécification du CR. Cela signifie que lorsque vous exécutez kubectl get <resource kind> <resource name> -oyaml, de nombreux champs de la spécification ne figurent pas dans votre fichier YAML appliqué.

Par exemple, supposons que le schéma CRD vous permette de spécifier deux champs nommés foo et bar dans la spécification, tandis que votre fichier YAML appliqué ne comporte que foo :

spec:
  foo: "foo"

Si le fichier YAML est appliqué correctement et que la ressource est UpToDate, un autre champ nommé bar s'affiche dans la CR :

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

En raison de la complexité de l'interaction entre Config Connector et les APIGoogle Cloud , vous pouvez modifier ce comportement par défaut et ignorer le remplissage de la spécification de ressource Kubernetes avec des champs non spécifiés.

Ignorer le remplissage des champs non spécifiés dans la spécification

Vous pouvez ignorer le remplissage des champs non spécifiés dans la spécification des CRD compatibles avec Config Connector version 1.113.0 et versions antérieures de l'une des manières suivantes :

Configurez le remplacement stateIntoSpec au niveau du cluster ou de l'espace de noms sur Absent.
Spécifiez la valeur de l'annotation cnrm.cloud.google.com/state-into-spec comme absent pour la ressource.

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

Lorsque vous installez Config Connector ou que vous mettez à jour son installation, vous pouvez configurer le remplacement stateIntoSpec au niveau du cluster ou de l'espace de noms sur Absent dans le CR ConfigConnector ou le CR ConfigConnectorContext.

spec:
  stateIntoSpec: Absent

Cela fait de Absent le comportement par défaut de remplissage des champs spec pour toutes les nouvelles ressources créées dans le cluster ou dans l'espace de noms lorsque vous ne spécifiez pas l'annotation cnrm.cloud.google.com/state-into-spec dans les nouveaux fichiers YAML de ressources. Cela signifie que Config Connector ne renseignera pas les champs non spécifiés dans la spécification de la ressource Kubernetes pour ces ressources.

Le champ stateIntoSpec n'a pas de valeur par défaut. Config Connector déterminera le comportement de remplissage des champs spec en fonction de la valeur de l'annotation cnrm.cloud.google.com/state-into-spec. Il suivra la logique ci-dessous pour déterminer la valeur de l'annotation :

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 le CR ConfigConnectorContext.
Si le CR ConfigConnectorContext n'existe pas ou si le champ stateIntoSpec n'est pas spécifié, utilisez la valeur correspondante du champ stateIntoSpec dans le CR ConfigConnector.
Si le CR ConfigConnector n'existe pas ou si le champ stateIntoSpec n'est pas spécifié, utilisez le comportement par défaut basé sur le CRD décrit dans Comportements de remplissage des champs spec.

Notez que les CRD de comportement de remplissage ajoutés dans la version 1.114.0 et ultérieures suivent Absent, quels que soient l'annotation cnrm.cloud.google.com/state-into-spec ou les champs stateIntoSpec dans le CR ConfigConnector ou le CR ConfigConnectorContext.

Si vous avez déjà créé la ressource, mais que vous souhaitez modifier le comportement de remplissage des champs spec sur Absent, vous devez :

Assurez-vous que le remplacement stateIntoSpec au niveau du cluster ou de l'espace de noms est défini sur Absent dans le CR ConfigConnector ou le CR ConfigConnectorContext.
Abandonnez la ressource et acquérez-la. Assurez-vous que la configuration YAML utilisée pour l'acquisition ne comporte pas l'annotation cnrm.cloud.google.com/state-into-spec.

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

Lorsque vous créez votre fichier YAML, vous pouvez spécifier la valeur de l'annotation cnrm.cloud.google.com/state-into-spec comme absent. Cela permet d'éviter de remplir les champs non spécifiés dans la spécification de ressource Kubernetes :

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

Si elle n'est pas spécifiée, cette annotation a une valeur par défaut de merge, ce qui signifie que Config Connector renseigne tous les champs non spécifiés dans la spécification. Cette annotation est immuable, ce qui signifie que vous ne pouvez pas mettre à jour la valeur d'annotation d'une ressource Config Connector existante.

Si vous avez déjà créé la ressource, mais que vous souhaitez modifier la valeur de cette annotation pour un comportement de remplissage différent, vous devez suivre ces étapes :

Modifiez et ajoutez l'annotation cnrm.cloud.google.com/deletion-policy: abandon à la ressource Kubernetes existante pour vous assurer que la suppression à l'étape suivante ne supprimera pas la ressource Google Cloud sous-jacente.
Supprimez la ressource du cluster Kubernetes.
Ajoutez l'annotation cnrm.cloud.google.com/state-into-spec: absent au fichier YAML de la ressource.
(Facultatif) Supprimez cnrm.cloud.google.com/deletion-policy: abandon du fichier YAML.
Appliquez le fichier YAML mis à jour.

Pour mieux comprendre la différence introduite par cette annotation, supposons qu'il existe une spécification avec le schéma suivant :

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

Supposons également que vous avez spécifié la spécification dans votre fichier YAML comme suit :

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

Par défaut, la spécification renseignée dans la ressource Kubernetes créée peut être la suivante :

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

Si vous définissez cnrm.cloud.google.com/state-into-spec: absent, la spécification finale de la ressource Kubernetes créée sera la suivante :

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

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

Dans la plupart des cas, vous devez définir cnrm.cloud.google.com/state-into-spec: absent pour obtenir le comportement de remplissage Absent pour les champs spec. Voici les scénarios les plus courants qui bénéficieront du comportement de remplissage de Absent.

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

Config Connector traite tous les champs de liste de la spécification de ressource Kubernetes comme des champs atomiques. Par conséquent, par défaut, toute modification apportée à un sous-champ de la liste en dehors de Config Connector sera annulée par Config Connector. Toutefois, vous pouvez utiliser cette annotation pour permettre à Config Connector de ne plus gérer les sous-champs dans la liste. 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 la configuration et Config Connector

Si vous utilisez des outils de gestion de la configuration tels que Config Sync ou Argo CD, vous remarquerez peut-être un conflit entre l'outil de gestion de la configuration et Config Connector. Par exemple, l'erreur KNV2005 est expliquée dans le guide de dépannage. Les causes de ces types de problèmes sont les suivantes :

Config Connector remplira et définira par défaut les valeurs non spécifiées dans la liste de la spécification. spec.bars[0].br2 en est un exemple.
Les outils de gestion de la configuration et Config Connector traitent les champs de liste comme des éléments atomiques. Par conséquent, l'élément spec.bars[0].br2 ajouté est traité comme une dérive par les outils de gestion de la configuration et sera supprimé pour corriger drift.

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

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

La symétrie GET/PUT fait référence à un principe de conception dans l'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 une réponse HTTP 200 OK sans modification de l'état de la ressource REST sous-jacente.

Les champs non spécifiés renseignés par Config Connector dans la spécification de la ressource Kubernetes résultent d'une requête GET. Cela signifie que lors des prochaines réconciliations, Config Connector pourra envoyer une requête PUT/PATCH à l'APIGoogle Cloud sous-jacente, avec ces valeurs de champ non spécifiées apprises à partir de la requête GET. Cela ne pose généralement pas de problème, mais il est possible que certaines APIGoogle Cloud rejettent la requête PUT/PATCH en raison de ces valeurs de champ non spécifiées. Dans le même exemple, le champ spec.barz.bz2 rempli avec la valeur "bz2" 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 essayer de définir cnrm.cloud.google.com/state-into-spec: absent et vérifier si les erreurs lors de la réconciliation disparaissent.

État observé

Si vous devez définir cnrm.cloud.google.com/state-into-spec: absent, mais que votre solution dépend des valeurs renseignées dans les champs non spécifiés, vérifiez si ces champs existent sous status.observedState dans le schéma CRD. S'ils sont représentés sous status.observedState, vous pouvez définir cnrm.cloud.google.com/state-into-spec: absent et accéder aux valeurs des champs non spécifiés après une réconciliation réussie.

Le champ status.observedState contient l'état actuel des champs observés sélectionnés de la ressource que Config Connector a observée lors de la dernière réconciliation réussie. Les champs observés sont sélectionnés s'ils sont des dépendances de cas d'utilisation courants et s'ils sont des champs spec. Vous trouverez les champs observés dans les schémas CRD.

Si vous ne trouvez pas les champs observés souhaités, recherchez un problème existant ou signalez-en un nouveau dans les outils publics de suivi des problèmes.

Types de comptes compatibles avec `Merge`

Voici tous les types Config Connector qui acceptent le comportement de remplissage Merge :

AccessContextManagerAccessLevel
AccessContextManagerAccessPolicy
AccessContextManagerServicePerimeter
AlloyDBBackup
AlloyDBCluster
AlloyDBUser
ApigeeEnvironment
ApigeeOrganization
ArtifactRegistryRepository
BigQueryDataset
BigQueryJob
BigQueryTable
BigtableAppProfile
BigtableGCPolicy
BigtableInstance
BigtableTable
BillingBudgetsBudget
BinaryAuthorizationAttestor
BinaryAuthorizationPolicy
CertificateManagerCertificate
CertificateManagerCertificateMap
CertificateManagerCertificateMapEntry
CloudBuildTrigger
CloudFunctionsFunction
CloudIdentityGroup
CloudIdentityMembership
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
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
VPCAccessConnector

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

Nom du type	Version
LoggingLogMetric	1.118.1