Nicht angegebene Felder ignorieren

Auf dieser Seite wird das Standardverhalten beim Ausfüllen der spec-Felder erläutert und beschrieben, wie Sie das Standardverhalten von Merge in das empfohlene Verhalten Absent ändern. Diese Seite ist möglicherweise nicht relevant, wenn Sie eine CRD verwenden, die in Version 1.114.0 und höher hinzugefügt wurde, da diese CRDs nur das Absent-Verhalten verwenden. Eine Liste der CRDs, die Merge unterstützen, finden Sie auf dieser Seite im Abschnitt CRDs mit Merge-Unterstützung.

spec Verhaltensweisen beim Ausfüllen von Feldern

Wenn Config Connector eine Ressource erstellt, können Felder, die in der Kubernetes-Ressourcenspezifikation nicht angegeben sind, zwei verschiedene Standardverhalten für das Ausfüllen haben: Absent und Merge.

Fehlt

Absent ist das empfohlene Verhalten. Config Connector füllt keine nicht angegebenen Felder in die Spezifikation ein.

Für CRDs, die in Version 1.114.0 und höher hinzugefügt wurden, ist das Standardverhalten für das Einfügen Absent. Dies ist auch das einzige Verhalten beim Füllen, das von diesen CRDs unterstützt wird. Der Wert der Annotation cnrm.cloud.google.com/state-into-spec ist in diesen benutzerdefinierten Ressourcen absent.

Zusammenführen

Merge ist ein nicht unterstütztes Verhalten in CRDs, die in Version 1.114.0 und höher hinzugefügt wurden. Die Felder spec übernehmen nach einem erfolgreichen Abgleich Werte aus der API, sofern sie lesbar sind. Weitere Informationen finden Sie unter Felder extern verwalten.

Für CRDs, die in Config Connector Version 1.113.0 und früher unterstützt werden, ist das Standardverhalten für das Einfügen Merge. Eine Liste der CRDs, die Merge unterstützen, finden Sie auf dieser Seite im Abschnitt CRDs with Merge support (CRDs mit Merge-Unterstützung). Der Standardwert der Annotation cnrm.cloud.google.com/state-into-spec ist in diesen Ressourcen-CRs merge. Sie können das Verhalten beim Einfügen auch so konfigurieren, dass es Absent ist. Folgen Sie dazu der Anleitung unter Skip populating unspecified fields into spec.

Standardmäßig werden in diesen Ressourcen-CRs Felder, die in Ihrem ursprünglichen YAML nicht angegeben wurden, immer in der CR-Spezifikation angezeigt. Wenn Sie also kubectl get <resource kind> <resource name> -oyaml ausführen, sind viele Felder in der Spezifikation nicht in Ihrem angewendeten YAML enthalten.

Angenommen, im CRD-Schema können Sie zwei Felder namens foo und bar in der Spezifikation angeben, während in der angewendeten YAML-Datei nur foo angegeben ist:

spec:
  foo: "foo"

Wenn die YAML-Datei erfolgreich angewendet wurde und die Ressource UpToDate ist, wird in der benutzerdefinierten Ressource ein weiteres Feld mit dem Namen bar angezeigt:

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

Aufgrund der Komplexität der Interaktion zwischen Config Connector undGoogle Cloud -APIs möchten Sie dieses Standardverhalten möglicherweise ändern und das Ausfüllen der Kubernetes-Ressourcenspezifikation mit nicht angegebenen Feldern überspringen.

Nicht angegebene Felder in der Spezifikation nicht ausfüllen

Sie können das Eintragen nicht angegebener Felder in die Spezifikation für CRDs, die in Config Connector Version 1.113.0 und früher unterstützt werden, auf eine der folgenden Arten überspringen:

  • Konfigurieren Sie die Überschreibung auf Cluster- oder Namespace-Ebene für stateIntoSpec auf Absent.
  • Geben Sie den Wert der Anmerkung cnrm.cloud.google.com/state-into-spec als absent für die Ressource an.

Überschreiben auf Cluster- oder Namespace-Ebene für stateIntoSpec konfigurieren

Wenn Sie Config Connector installieren oder die Config Connector-Installation aktualisieren, können Sie den stateIntoSpec-Überschreibungsbefehl auf Cluster- oder Namespace-Ebene in der ConfigConnector-CR oder ConfigConnectorContext-CR auf Absent festlegen.

spec:
  stateIntoSpec: Absent

Dadurch wird Absent zum Standardverhalten für das Einsetzen von spec-Feldern für alle neuen Ressourcen, die im Cluster oder im Namespace erstellt werden, wenn Sie die Annotation cnrm.cloud.google.com/state-into-spec in den YAML-Dateien der neuen Ressourcen nicht angeben. Das bedeutet, dass Config Connector das Ausfüllen nicht angegebener Felder in der Kubernetes-Ressourcenspezifikation für diese Ressourcen überspringt.

Das Feld stateIntoSpec hat keinen Standardwert. Config Connector bestimmt das Verhalten beim Ausfüllen der Felder spec anhand des Werts der Annotation cnrm.cloud.google.com/state-into-spec. Dabei wird die folgende Logik verwendet, um den Wert der Annotation zu ermitteln:

  1. Verwenden Sie den Wert der Annotation cnrm.cloud.google.com/state-into-spec direkt, wenn er angegeben und gültig ist.
  2. Wenn die Annotation nicht angegeben ist, verwenden Sie den entsprechenden Wert des Felds stateIntoSpec in der ConfigConnectorContext-CR.
  3. Wenn die ConfigConnectorContext-CR nicht vorhanden ist oder das Feld stateIntoSpec nicht angegeben ist, verwenden Sie den entsprechenden Wert des Felds stateIntoSpec in der ConfigConnector-CR.
  4. Wenn die ConfigConnector-CR nicht vorhanden ist oder das Feld stateIntoSpec nicht angegeben ist, verwenden Sie das Standardverhalten basierend auf der CRD, die unter Verhaltensweisen zum Ausfüllen von spec-Feldern beschrieben ist.

Beachten Sie, dass nur die CRDs für das Verhalten beim Einfügen, die in Version 1.114.0 und höher hinzugefügt wurden, Absent folgen, unabhängig von der Annotation cnrm.cloud.google.com/state-into-spec oder den Feldern stateIntoSpec in der ConfigConnector-CR oder ConfigConnectorContext-CR.

Wenn Sie die Ressource bereits erstellt haben, aber das Verhalten beim Ausfüllen der spec-Felder in Absent ändern möchten, sollten Sie Folgendes tun:

  1. Achten Sie darauf, dass die Überschreibung auf Cluster- oder Namespace-Ebene für stateIntoSpec in der ConfigConnector-CR oder ConfigConnectorContext-CR Absent ist.

  2. Ressource aufgeben und übernehmen: Achten Sie darauf, dass die für die Akquisition verwendete YAML-Konfiguration nicht die Annotation cnrm.cloud.google.com/state-into-spec enthält.

cnrm.cloud.google.com/state-into-spec-Annotation auf Ressourcenebene angeben

Wenn Sie Ihre YAML-Datei erstellen, können Sie den Wert der Annotation cnrm.cloud.google.com/state-into-spec als absent angeben. Dadurch wird das Ausfüllen nicht angegebener Felder in der Kubernetes-Ressourcenspezifikation übersprungen:

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

Wenn diese Annotation nicht angegeben ist, hat sie den Standardwert merge. Das bedeutet, dass Config Connector alle nicht angegebenen Felder in „spec“ einfügt. Diese Annotation ist unveränderlich. Sie können also den Annotationswert einer vorhandenen Config Connector-Ressource nicht aktualisieren.

Wenn Sie die Ressource bereits erstellt haben, den Wert dieser Anmerkung aber ändern möchten, um ein anderes Verhalten beim Einfügen zu erzielen, müssen Sie so vorgehen:

  1. Bearbeiten Sie die vorhandene Kubernetes-Ressource und fügen Sie die Annotation cnrm.cloud.google.com/deletion-policy: abandon hinzu, damit beim Löschen im nächsten Schritt nicht die zugrunde liegende Google Cloud Ressource gelöscht wird.

  2. Löschen Sie die Ressource aus dem Kubernetes-Cluster.

  3. Fügen Sie der YAML-Datei der Ressource die Annotation cnrm.cloud.google.com/state-into-spec: absent hinzu.

  4. Optional: Entfernen Sie cnrm.cloud.google.com/deletion-policy: abandon aus dem YAML-Code.

  5. Wenden Sie die aktualisierte YAML-Datei an.

Um den durch diese Annotation eingeführten Unterschied zu verdeutlichen, nehmen wir an, dass es eine Spezifikation mit dem folgenden Schema gibt:

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

Angenommen, Sie haben die Spezifikation in Ihrer YAML-Datei so angegeben:

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

Die ausgefüllte Spezifikation in der erstellten Kubernetes-Ressource könnte dann standardmäßig so aussehen:

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

Wenn Sie cnrm.cloud.google.com/state-into-spec: absent festlegen, sieht die endgültige Spezifikation in der erstellten Kubernetes-Ressource so aus:

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

Verwendung von cnrm.cloud.google.com/state-into-spec: absent

In den meisten Fällen sollten Sie cnrm.cloud.google.com/state-into-spec: absent festlegen, um das Verhalten zum automatischen Ausfüllen von Absent für spec-Felder zu erhalten. Hier sind die häufigsten Szenarien, in denen das Verhalten beim Ausfüllen von Absent von Vorteil ist.

Nicht angegebene Felder in einer Liste extern verwalten

Config Connector behandelt alle Listenfelder in der Spezifikation von Kubernetes-Ressourcen als atomare Felder. Daher wird Ihre Änderung an einem Unterfeld in der Liste, die außerhalb von Config Connector vorgenommen wurde, standardmäßig von Config Connector rückgängig gemacht. Sie können diese Annotation jedoch verwenden, damit Config Connector Unterfelder in der Liste nicht mehr verwaltet. Weitere Informationen finden Sie unter Verhalten für Listenfelder in der Ressourcenspezifikation.

Konflikte zwischen Konfigurationsverwaltungstools und Config Connector beheben

Wenn Sie Tools zur Konfigurationsverwaltung wie Config Sync oder Argo CD verwenden, kann es zu Konflikten zwischen dem Tool zur Konfigurationsverwaltung und Config Connector kommen. Ein Beispiel ist der Fehler KNV2005, der in der Anleitung zur Fehlerbehebung beschrieben wird. Die Ursache für diese Art von Problemen ist:

  1. Config Connector füllt nicht angegebene Werte in der Liste in der Spezifikation aus und legt Standardwerte fest. spec.bars[0].br2 ist ein Beispiel.
  2. Sowohl Konfigurationsmanagement-Tools als auch Config Connector behandeln Listenfelder als atomar. Daher wird das hinzugefügte spec.bars[0].br2 von Konfigurationsmanagement-Tools als Abweichung behandelt und entfernt, um das drift zu korrigieren.

Um diese Probleme zu beheben, können Sie cnrm.cloud.google.com/state-into-spec: absent festlegen, damit Config Connector das nicht angegebene Feld spec.bars[0].br2 nicht in die Spezifikation einfügt.

Probleme mit der GET/PUT-Symmetrie beheben

Die GET/PUT-Symmetrie bezieht sich auf ein Designprinzip in der REST API. Das bedeutet konkret, dass bei einer GET-Antwort, die als PUT-Anfrage an dieselbe URL gesendet wird, das erwartete Ergebnis eine HTTP 200-OK-Antwort ohne Änderung des Status der zugrunde liegenden REST-Ressource ist.

Die nicht angegebenen Felder, die von Config Connector in der Kubernetes-Ressourcenspezifikation ausgefüllt werden, sind das Ergebnis einer GET-Anfrage. Das bedeutet, dass Config Connector bei zukünftigen Abstimmungen möglicherweise eine PUT-/PATCH-Anfrage an die zugrunde liegendeGoogle Cloud API sendet, wobei diese nicht angegebenen Feldwerte aus der GET-Anfrage stammen. Normalerweise ist das kein Problem, aber es ist möglich, dass einigeGoogle Cloud -APIs die PUT-/PATCH-Anfrage aufgrund dieser nicht angegebenen Feldwerte ablehnen. Im selben Beispiel kann das ausgefüllte spec.barz.bz2 mit dem Wert „bz2“ zu einem HTTP-400-Clientfehler oder anderen unerwarteten Antworten führen, wenn bei der API-Implementierung gegen den Grundsatz der GET/PUT-Symmetrie verstoßen wird.

Um diese Art von Problemen zu vermeiden, können Sie cnrm.cloud.google.com/state-into-spec: absent festlegen und prüfen, ob die Fehler während des Abgleichs verschwinden.

Beobachteter Status

Wenn Sie cnrm.cloud.google.com/state-into-spec: absent festlegen müssen, Ihre Lösung jedoch von den ausgefüllten Werten aus nicht angegebenen Feldern abhängt, prüfen Sie, ob diese Felder im CRD-Schema unter status.observedState vorhanden sind. Wenn sie unter status.observedState dargestellt werden, können Sie cnrm.cloud.google.com/state-into-spec: absent festlegen und nach einem erfolgreichen Abgleich weiterhin auf die Werte der nicht angegebenen Felder zugreifen.

Das Feld status.observedState enthält den Live-Status der ausgewählten, beobachteten Felder der Ressource, die Config Connector bei der letzten erfolgreichen Abstimmung beobachtet hat. Die beobachteten Felder werden ausgewählt, wenn sie Abhängigkeiten von häufigen Anwendungsfällen sind und als spec-Felder berechnet werden. Die beobachteten Felder finden Sie in den CRD-Schemas.

Wenn Sie die gewünschten beobachteten Felder nicht finden, prüfen Sie, ob ein Problem vorhanden ist, oder eröffnen Sie ein neues Problem in der öffentlichen Problemverfolgung.

Arten mit Merge-Unterstützung

Im Folgenden finden Sie alle Config Connector-Arten, die das Verhalten zum Merge-Ausfüllen unterstützen:

  • 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
  • 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
  • DataFusionInstance
  • DataflowFlexTemplateJob
  • DataflowJob
  • DataprocAutoscalingPolicy
  • DataprocCluster
  • DataprocWorkflowTemplate
  • EdgeContainerCluster
  • EdgeContainerNodePool
  • EdgeContainerVpnConnection
  • EdgeNetworkNetwork
  • EdgeNetworkSubnet
  • EventarcTrigger
  • FilestoreBackup
  • FilestoreInstance
  • FirestoreIndex
  • Ordner
  • 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
  • Projekt
  • PubSubLiteReservation
  • PubSubSchema
  • PubSubSubscription
  • PubSubTopic
  • RecaptchaEnterpriseKey
  • RedisInstance
  • ResourceManagerLien
  • ResourceManagerPolicy
  • RunJob
  • RunService
  • SQLDatabase
  • SQLSSLCert
  • SQLUser
  • SecretManagerSecret
  • SecretManagerSecretVersion
  • Dienst
  • ServiceDirectoryEndpoint
  • ServiceDirectoryNamespace
  • ServiceDirectoryService
  • ServiceIdentity
  • ServiceNetworkingConnection
  • SourceRepoRepository
  • SpannerDatabase
  • SpannerInstance
  • StorageBucket
  • StorageBucketAccessControl
  • StorageDefaultObjectAccessControl
  • StorageNotification
  • StorageTransferJob
  • VPCAccessConnector

Die folgenden Arten unterstützen das Verhalten zum Einfügen von Merge ab der entsprechenden Version nicht:

Kind Name (Name des Kindes) Version
LoggingLogMetric 1.118.1