Ignorer les champs non spécifiés

Cette page décrit le comportement de remplissage par défaut des champs spec et la manière dont pour remplacer le comportement par défaut Merge par le comportement recommandé Absent Cette page peut ne pas s'appliquer si vous utilisez un CRD ajouté à partir de la version 1.114.0, car ces CRD n'utilisent que le comportement Absent. Pour Consultez les CRD avec Merge pour connaître la liste des objets CRD compatibles avec Merge. l'assistance technique de cette page.

Comportements de remplissage des champs spec

Lorsque Config Connector crée une ressource, les champs ne sont pas spécifiés dans le La spécification des ressources Kubernetes peut présenter 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és dans la version 1.114.0 et ultérieures, le comportement de remplissage par défaut est Absent. C'est aussi le seul afflux de compatible avec les 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 pris en charge dans les objets CRD ajoutés à partir de la version 1.114.0. Les champs spec prennent les valeurs de l'API après une mise en correspondance réussie, sauf s'ils ne sont pas lisibles. Pour en savoir plus, consultez Gérer des champs en externe.

Pour les objets CRD compatibles avec la version de Config Connector 1.113.0 et les versions antérieures, le comportement de remplissage par défaut est Merge. Pour obtenir la liste des objets CRD Compatibilité avec Merge, consultez les CRD compatibles avec Merge de cette page. La valeur par défaut du paramètre L'annotation cnrm.cloud.google.com/state-into-spec est merge dans cette ressource RS. 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 RP de ressources, les champs qui n'ont pas été spécifiés dans votre fichier YAML d'origine apparaissent toujours dans la spécification de la RP. 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 les spécifications, alors que votre fichier YAML appliqué ne spécifie que foo :

spec:
  foo: "foo"

Vous remarquerez qu'un autre champ nommé bar apparaît dans la RS si le code YAML est appliqué. avec succès et que la ressource est UpToDate:

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

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

Ignorer le remplissage des champs non spécifiés dans les spécifications

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

  • Configurez le forçage stateIntoSpec au niveau du cluster ou de l'espace de noms pour qu'il soit Absent
  • Spécifiez la valeur de l'annotation cnrm.cloud.google.com/state-into-spec comme absent pour la ressource.

Configurer le forçage stateIntoSpec au niveau du cluster ou de l'espace de noms

Lors de l'installation ou de la mise à jour de Config Connector, vous pouvez configurer le remplacement stateIntoSpec au niveau du cluster ou de l'espace de noms sur Absent dans la RS ConfigConnector ou ConfigConnectorContext.

spec:
  stateIntoSpec: Absent

Absent devient ainsi le comportement de remplissage des champs spec par défaut 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 fichiers YAML de la nouvelle ressource. Cela signifie que Config Connector ne remplira pas les champs non spécifiés les spécifications Kubernetes correspondantes.

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

  1. Utilisez directement la valeur de l'annotation cnrm.cloud.google.com/state-into-spec si elle est spécifiée et valide.
  2. Si l'annotation n'est pas spécifiée, utilisez la valeur correspondante de l'attribut Champ stateIntoSpec dans la RS pour ConfigConnectorContext.
  3. Si la requête de changement ConfigConnectorContext n'existe pas ou si le champ stateIntoSpec n'est pas spécifié, utilisez la valeur correspondante du champ stateIntoSpec dans la requête de changement ConfigConnector.
  4. Si la 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 la section Comportements de remplissage des champs spec.

Notez que les seuls CRD de comportement de remplissage ajoutés dans la version 1.114.0 et ultérieure sont Absent, quelle que soit 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 les champs spec de remplissage à Absent, vous devez:

  1. Assurez-vous que le forçage stateIntoSpec au niveau du cluster ou de l'espace de noms doit être Absent dans la RS ConfigConnector ou dans la RS ConfigConnectorContext.

  2. Abandonnez et acquérez la ressource. Assurez-vous que la configuration YAML utilisée pour l'acquisition ne dispose pas du rôle Annotation cnrm.cloud.google.com/state-into-spec.

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

Lors de la création de votre fichier YAML, vous pouvez spécifier la valeur du paramètre Annotation cnrm.cloud.google.com/state-into-spec en tant que absent. Cela évite de renseigner les champs non spécifiés dans la spécification de la ressource Kubernetes :

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

Si elle n'est pas spécifiée, cette annotation a pour valeur par défaut 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 de l'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, procédez comme suit :

  1. Modifier et ajouter une annotation cnrm.cloud.google.com/deletion-policy: abandon à la ressource Kubernetes existante pour vous assurer que la suppression à l'étape suivante supprimer la ressource Google Cloud sous-jacente.

  2. Supprimez la ressource du cluster Kubernetes.

  3. Ajouter l'annotation cnrm.cloud.google.com/state-into-spec: absent au fichier YAML de la ressource.

  4. (Facultatif) Supprimez cnrm.cloud.google.com/deletion-policy: abandon du YAML.

  5. Appliquez le fichier YAML mis à jour.

Pour mieux expliquer 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"

La spécification indiquée par défaut 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 dans 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 peuvent vous être utiles. du comportement de remplissage Absent.

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

Config Connector traite tous les champs de liste dans la spécification de ressources Kubernetes comme atomiques . Par défaut, Config Connector annule les modifications apportées à un sous-champ de la liste en dehors de Config Connector. Toutefois, vous pouvez utiliser cette annotation pour autoriser Config Connector à ne plus gérer les sous-champs dans la liste. Pour Pour en savoir plus, consultez la section Comportement des champs de liste dans les ressources caractéristiques.

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

Si vous utilisez des outils de gestion de configuration tels que Config Sync ou Argo CD, vous remarquerez peut-être une incohérence entre la configuration et Config Connector. Par exemple, l'erreur KNV2005 expliquée dans le guide de dépannage. La cause de ces types de problèmes est la suivante :

  1. Config Connector insère et définit par défaut les valeurs non spécifiées dans la liste de la spécification. spec.bars[0].br2 en est un exemple.
  2. Les outils de gestion de la configuration et Config Connector traitent les champs de liste comme atomiques. Par conséquent, l'spec.bars[0].br2 ajouté est traité comme une dérive par les outils de gestion de la configuration et sera supprimé pour corriger le 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 aucun champ non spécifié spec.bars[0].br2 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 les API REST. Plus précisément, il signifie qu'une réponse GET envoyée à la même URL sous la forme d'une requête PUT, est une réponse HTTP 200 OK sans modification de l'état ressource REST.

Les champs non spécifiés renseignés par Config Connector dans la spécification de la ressource Kubernetes sont le résultat d'une requête GET. Cela signifie que lors de futures réconciliations, Config Connector peut envoyer une requête PUT/PATCH à l'API Google 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 API Google Cloud rejettent la requête PUT/PATCH en raison de ces valeurs de champ non spécifiées. Dans le même exemple, la valeur "bz2" renseignée dans spec.barz.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 tester cnrm.cloud.google.com/state-into-spec: absent et vérifiez si les erreurs se produisent le rapprochement disparaît.

É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 à partir de 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 continuer à accéder aux valeurs des champs non spécifiés après une mise en correspondance réussie.

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és lors de la dernière mise en correspondance réussie. Les champs observés sont sélectionnés s'ils sont des dépendances de cas d'utilisation courants et sont des champs spec calculés. 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 dans les outils publics de suivi des problèmes.

Types compatibles avec Merge

Vous trouverez ci-dessous tous les types de Config Connector compatibles avec le comportement de remplissage Merge :

  • AccessContextManagerAccessLevel
  • AccessContextManagerAccessPolicy
  • AccessContextManagerServicePerimeter
  • AlloyDBBackup
  • AlloyDBCluster
  • AlloyDBInstance
  • AlloyDBUser
  • ApigeeEnvironment
  • ApigeeOrganization
  • ArtifactRegistryRepository
  • BigQueryDataset
  • BigQueryJob
  • BigQueryTable
  • BigtableAppProfile
  • BigtableGCPolicy
  • BigtableInstance
  • BigtableTable
  • BillingBudgetsBudget
  • BinaryAuthorizationAttestor
  • BinaryAuthorizationPolicy
  • CertificateManagerCertificate
  • CertificateManagerCertificateMap
  • CertificateManagerCertificateMapEntry
  • CertificateManagerDNSAuthorization
  • CloudBuildTrigger
  • CloudFunctionsFunction
  • CloudIdentityGroup
  • CloudIdentityMembership
  • Tâche Cloud Scheduler
  • ComputeAddress
  • ComputeBackendBucket
  • ComputeBackendService
  • ComputeDisk
  • ComputeExternalVPNGateway
  • ComputeFirewall
  • ComputeFirewallPolicy
  • ComputeFirewallPolicyAssociation
  • ComputeFirewallPolicyRule
  • 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
  • GKEHubFeatureMembership
  • 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
  • MonitoringDashboard
  • 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
  • SQLInstance
  • SQLSSLCert
  • SQLUser
  • SecretManagerSecret
  • SecretManagerSecretVersion
  • Service
  • ServiceDirectoryEndpoint
  • ServiceDirectoryNamespace
  • ServiceDirectoryService
  • ServiceIdentity
  • ServiceNetworkingConnection
  • SourceRepoRepository
  • SpannerDatabase
  • SpannerInstance
  • StorageBucket
  • StorageBucketAccessControl
  • StorageDefaultObjectAccessControl
  • StorageNotification
  • StorageTransferJob
  • VPCAccessConnector

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

Kind Name (Nom du genre) Version
LoggingLogMetric 1.118.1