Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Nicht angegebene Felder ignorieren

Auf dieser Seite wird das Standardverhalten beim Ausfüllen von spec-Feldern in Config Connector-Ressourcen erläutert. Außerdem wird beschrieben, wie Sie vorhandene Ressourcen vom alten Merge-Verhalten zum empfohlenen Absent-Verhalten migrieren. Diese Seite ist möglicherweise nicht relevant, wenn Sie eine CustomResourceDefinition (CRD) verwenden, die in Version 1.114.0 oder höher hinzugefügt wurde, da diese CRDs nur das Verhalten Absent unterstützen. Eine Liste der CRDs, die das Merge-Verhalten unterstützen, finden Sie auf dieser Seite im Abschnitt Arten mit Merge-Unterstützung.

`spec` Verhaltensweisen zum Ausfüllen von Feldern

Wenn Config Connector eine Ressource erstellt, können Felder, die im Feld spec der Kubernetes-Ressource nicht angegeben sind, zwei verschiedene Verhaltensweisen beim Ausfüllen haben: Absent und Merge.

Fehlt

Das Absent-Verhalten ist das empfohlene Verhalten. Wenn eine Ressource das Verhalten Absent verwendet, füllt Config Connector nicht angegebene Felder nicht in das Feld spec der Kubernetes-Ressource ein.

Ab Config Connector-Version 1.123.1 ist das Verhalten von Absent das Standardverhalten für alle neu erstellten Ressourcen, sofern Sie den Wert des Felds spec.stateIntoSpec in Ihrer benutzerdefinierten Ressource „ConfigConnector“ oder „ConfigConnectorContext“ nicht auf Merge festlegen. Bei Ressourcen, für die die Annotation cnrm.cloud.google.com/state-into-spec verwendet wird, legt Config Connector den Wert der Annotation standardmäßig auf Kleinbuchstaben absent fest. Das Feld spec.stateIntoSpec verwendet die Großbuchstaben Absent oder Merge. Bei Ressourcen, die von direkten Controllern abgeglichen werden, wird das Verhalten von Absent verwendet, ohne dass die Annotation hinzugefügt wird.

Für CRDs, die in Version 1.114.0 und höher hinzugefügt wurden, ist das Verhalten Absent das einzige unterstützte Verhalten für das Ausfüllen.

Zusammenführen

Das Verhalten Merge wird in CRDs, die in Version 1.114.0 und höher hinzugefügt wurden, nicht unterstützt. Wenn eine Ressource das Merge-Verhalten verwendet, übernehmen spec-Felder nach einem erfolgreichen Abgleich Werte aus der Google Cloud API, sofern diese Felder lesbar sind. Weitere Informationen finden Sie unter Felder extern verwalten.

Für CRDs, die in Version 1.113.0 und früher hinzugefügt wurden, unterstützt Config Connector sowohl das Verhalten Absent als auch Merge. Eine vollständige Liste der unterstützten Ressourcen finden Sie unter Arten mit Merge-Unterstützung. In Config Connector-Versionen vor 1.123.1 war das Standardverhalten für das Einsetzen von Werten für diese CRDs Merge und Config Connector hat den Wert der Annotation cnrm.cloud.google.com/state-into-spec standardmäßig auf merge gesetzt.

Da die Annotation cnrm.cloud.google.com/state-into-spec nach dem Erstellen einer Ressource unveränderlich ist, behalten Ressourcen, die vor Version 1.123.1 erstellt wurden, die Annotation cnrm.cloud.google.com/state-into-spec: merge auch nach dem Upgrade von Config Connector auf Version 1.123.1 oder höher. Informationen zum Konfigurieren neuer Ressourcen für die Verwendung des Absent-Verhaltens finden Sie unter Nicht angegebene Felder in der Spezifikation überspringen. Informationen zum Migrieren vorhandener Ressourcen finden Sie unter Ressourcen von Merge zu Absent migrieren.

Wenn eine Ressource das Verhalten Merge verwendet, werden Felder, die nicht in Ihrem ursprünglichen YAML-Manifest angegeben sind, im Feld spec der benutzerdefinierten Ressource auf dem Kubernetes API-Server ausgefüllt. Das bedeutet, dass das Feld spec in der Ausgabe des Befehls kubectl get RESOURCE_KIND RESOURCE_NAME -o yaml Unterfelder enthalten kann, die nicht in der angewendeten YAML-Datei enthalten sind.

Angenommen, Sie können im CRD-Schema zwei Felder mit den Namen field1 und field2 im Feld spec angeben, aber in Ihrer angewendeten YAML-Datei ist nur das Feld field1 angegeben:

spec:
  field1: "value-1"

Wenn das YAML-Manifest erfolgreich angewendet wurde und die Ressource UpToDate ist, wird das Feld field2 in der benutzerdefinierten Ressource angezeigt:

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

Config Connector füllt nicht angegebene Ressourcenreferenzfelder wie projectRef, folderRef, organizationRef oder billingAccountRef nicht vonGoogle Cloud in spec aus. Obwohl die Art Project beispielsweise Merge unterstützt, sind alle optionalen spec-Felder (billingAccountRef, folderRef und organizationRef) Ressourcenreferenzfelder. Daher werden von Merge keine nicht angegebenen Felder in einer Project-Ressource ausgefüllt.

Aufgrund der Komplexität der Interaktionen zwischen Config Connector undGoogle Cloud -APIs sollten Sie das Verhalten Absent verwenden, damit Config Connector das Feld spec der Kubernetes-Ressource nicht mit nicht angegebenen Feldern füllt.

Nicht angegebene Felder nicht in die Spezifikation einfügen

Sie können Config Connector so konfigurieren, dass nicht angegebene Felder nicht in das Feld spec für CRDs eingefügt werden, die in Config Connector-Version 1.113.0 und früher hinzugefügt wurden. Dazu haben Sie folgende Möglichkeiten:

Legen Sie den Wert des Felds stateIntoSpec auf Cluster- oder Namespace-Ebene auf Absent fest.
Legen Sie für die Ressource den Wert der Annotation cnrm.cloud.google.com/state-into-spec auf absent fest.

`stateIntoSpec`-Überschreibung auf Cluster- oder Namespace-Ebene konfigurieren

Wenn Sie Config Connector installieren oder Ihre Config Connector-Installation aktualisieren, können Sie den Wert des Felds stateIntoSpec auf Cluster- oder Namespace-Ebene in der benutzerdefinierten Ressource ConfigConnector oder ConfigConnectorContext auf Absent setzen:

spec:
  stateIntoSpec: Absent

Mit dieser Einstellung wird das Verhalten von Absent zum Standardverhalten für das Einsetzen von spec-Feldern für alle neuen Ressourcen, die im Cluster oder Namespace erstellt werden, wenn Sie die Annotation cnrm.cloud.google.com/state-into-spec in den YAML-Manifesten der Ressourcen nicht angeben. Config Connector überspringt das Eintragen nicht angegebener Felder in das Feld spec der Kubernetes-Ressource für diese Ressourcen.

Das Feld stateIntoSpec in den benutzerdefinierten Ressourcen ConfigConnector und ConfigConnectorContext hat keinen Standardwert. Config Connector bestimmt das Verhalten beim Ausfüllen der spec-Felder anhand des Werts der Annotation cnrm.cloud.google.com/state-into-spec. Dabei wird die folgende Rangfolge verwendet, um den Wert der Annotation beim Erstellen einer Ressource zu bestimmen:

Verwenden Sie den Wert der Annotation cnrm.cloud.google.com/state-into-spec direkt, wenn er angegeben und gültig ist.
Wenn die Annotation nicht angegeben ist, verwenden Sie den entsprechenden Wert des Felds stateIntoSpec in der benutzerdefinierten Ressource ConfigConnectorContext.
Wenn die benutzerdefinierte Ressource „ConfigConnectorContext“ nicht vorhanden ist oder das Feld stateIntoSpec nicht angegeben ist, verwenden Sie den entsprechenden Wert des Felds stateIntoSpec in der benutzerdefinierten Ressource „ConfigConnector“.
Wenn die benutzerdefinierte ConfigConnector-Ressource nicht vorhanden ist oder das Feld stateIntoSpec nicht angegeben ist, wird in Config Connector-Version 1.123.1 und höher standardmäßig der Wert absent verwendet. In Versionen vor 1.123.1 wird das Standardverhalten für die CRD verwendet, wie unter Verhalten beim Ausfüllen von spec-Feldern beschrieben.

CRDs, die in Version 1.114.0 und höher hinzugefügt wurden, unterstützen nur das Verhalten zum Einfügen von Absent, unabhängig vom Feld stateIntoSpec in der benutzerdefinierten Ressource „ConfigConnector“ oder „ConfigConnectorContext“.

Wenn Sie bereits eine Ressource mit dem Verhalten Merge erstellt haben, wird die Annotation der vorhandenen Ressource nicht geändert, wenn Sie den Wert des Felds stateIntoSpec in der benutzerdefinierten Ressource ConfigConnector oder ConfigConnectorContext auf Absent aktualisieren. Informationen zum Migrieren vorhandener Ressourcen finden Sie unter Ressourcen von Merge zu Absent migrieren.

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

Beim Erstellen der YAML-Datei können Sie den Wert der Annotation cnrm.cloud.google.com/state-into-spec auf absent festlegen. Mit dieser Annotation wird das Einfügen nicht angegebener Felder in das Feld spec der Kubernetes-Ressource übersprungen:

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

In Config Connector-Version 1.123.1 und höher wird diese Annotation standardmäßig auf den Wert absent gesetzt, wenn sie nicht angegeben ist (es sei denn, Sie überschreiben sie, indem Sie den Wert des Felds spec.stateIntoSpec in Ihrer benutzerdefinierten ConfigConnector- oder ConfigConnectorContext-Ressource auf Merge setzen). In Versionen vor 1.123.1 wurde für CRDs, die in Version 1.113.0 und früher hinzugefügt wurden, standardmäßig der Wert merge für diese Annotation verwendet. Das bedeutet, dass Config Connector alle nicht angegebenen Felder in das Feld spec eingefügt hat.

Diese Annotation ist unveränderlich. Das bedeutet, dass Sie den Annotationswert nicht direkt für eine vorhandene Config Connector-Ressource aktualisieren können. Wenn Sie bereits eine Ressource mit dem Wert merge erstellt haben und ihr Verhalten in den Wert absent ändern möchten, lesen Sie den Abschnitt Ressourcen von Merge zu Absent migrieren.

Um den durch diese Annotation eingeführten Unterschied weiter zu erläutern, nehmen wir an, dass eine Ressource ein spec-Feld mit dem folgenden Schema hat:

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

Angenommen, Sie haben das Feld spec in Ihrem YAML-Manifest so angegeben:

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

Wenn der Wert der Annotation cnrm.cloud.google.com/state-into-spec auf merge festgelegt ist, sieht das ausgefüllte Feld spec in der erstellten Kubernetes-Ressource so aus:

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"

Wenn Sie die Annotation cnrm.cloud.google.com/state-into-spec: absent festlegen, bleibt das endgültige Feld spec in der erstellten Kubernetes-Ressource erhalten:

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

Ressourcen von `Merge` zu `Absent` migrieren

Da die Annotation cnrm.cloud.google.com/state-into-spec für eine vorhandene Kubernetes-Ressource unveränderlich ist, werden vorhandene Ressourcen beim Upgrade von Config Connector auf Version 1.123.1 oder höher nicht automatisch vom Wert merge in den Wert absent geändert.

Wenn Sie Ihre vorhandenen Ressourcen und Namespaces vom Verhalten Merge zum Verhalten Absent migrieren, können Sie die folgenden Probleme vermeiden:

Abgleichfehler bei automatisch aktualisierten Feldern: Google Cloudaktualisiert automatisch bestimmte Felder in zugrunde liegenden Ressourcen, z. B. Wartungsversionen oder Autoscaling-Einstellungen. Bei Ressourcen mit der Annotation state-into-spec: merge kann der Abgleich fehlschlagen oder es kann zu einer endlosen Aktualisierungsschleife kommen, wenn versucht wird, das Feld auf den älteren spec-Wert zurückzusetzen.
Konflikte mit GitOps- und Konfigurationsverwaltungstools: Tools wie Config Sync und Argo CD können mit Config Connector in Konflikt geraten, wenn das Verhalten von Merge nicht angegebene Unterfelder in Listen füllt.
Validierungsfehler bei neueren Ressourcenarten: Wenn der Wert des Felds spec.stateIntoSpec in einer benutzerdefinierten ConfigConnector- oder ConfigConnectorContext-Ressource auf Merge festgelegt ist, kann die Verwaltung von Ressourcen, die das Verhalten Merge nicht unterstützen, zu Validierungsfehlern (invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation) führen.

Betroffene Namespaces und Ressourcen identifizieren

Prüfen Sie vor der Migration Ihre Einstellungen auf Cluster-, Namespace- und Ressourcenebene, um herauszufinden, wo das Merge-Verhalten noch verwendet wird:

Prüfen Sie die ConfigConnector-Ressource auf Clusterebene auf eine stateIntoSpec-Feldüberschreibung:

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

Prüfen Sie alle benutzerdefinierten ConfigConnectorContext-Ressourcen auf Namespace-Ebene auf stateIntoSpec-Feldüberschreibungen:

kubectl get configconnectorcontext -A \
    -o custom-columns=NAMESPACE:.metadata.namespace,STATE_INTO_SPEC:.spec.stateIntoSpec

Prüfen Sie den Wert der Annotation cnrm.cloud.google.com/state-into-spec für eine vorhandene Config Connector-Ressource:
```
kubectl get RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/state-into-spec}{"\n"}'
```
Ersetzen Sie Folgendes:
- RESOURCE_KIND: Die Art der Config Connector-Ressource, z. B. SQLInstance.
- RESOURCE_NAME ist der Name der -Ressource.
- NAMESPACE: der Namespace der Ressource.

Ressource zu `Absent` migrieren

Wenn Sie das Verhalten einer vorhandenen Ressource von Merge zu Absent ändern möchten, müssen Sie die Kubernetes-Ressource aufgeben und die zugrunde liegende Google Cloud -Ressource mit der Annotation cnrm.cloud.google.com/state-into-spec: absent neu abrufen. Führen Sie die folgenden Schritte aus, um die Ressource zu verwerfen und neu zu erfassen:

Wenn der Wert des Felds spec.stateIntoSpec in Ihrer benutzerdefinierten ConfigConnector- oder ConfigConnectorContext-Ressource auf Merge festgelegt ist, aktualisieren Sie den Wert des Felds auf Absent:
```
spec:
  stateIntoSpec: Absent
```
Fügen Sie die Annotation cnrm.cloud.google.com/deletion-policy: abandon der vorhandenen Config Connector-Ressource in Ihrem Cluster hinzu. Diese Annotation sorgt dafür, dass beim Löschen der Kubernetes-Ressource im nächsten Schritt die zugrunde liegende Google Cloud -Ressource nicht gelöscht wird:
```
kubectl annotate RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    cnrm.cloud.google.com/deletion-policy=abandon --overwrite
```

Löschen Sie die Ressource aus Ihrem Kubernetes-Cluster:

kubectl delete RESOURCE_KIND RESOURCE_NAME -n NAMESPACE

Legen Sie im YAML-Manifest der Ressource den Wert der Annotation cnrm.cloud.google.com/state-into-spec auf absent fest:
```
metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent
```
Prüfen Sie das Feld spec in Ihrem YAML-Manifest, um sicherzustellen, dass es alle Felder enthält, die von Config Connector verwaltet werden sollen. Lassen Sie Felder weg, die von Google Cloud oder externen Systemen automatisch verwaltet werden sollen, z. B. das Feld spec.maintenanceVersion in einer SQLInstance-Ressource.
Optional: Wenn Ihr lokales YAML-Manifest auch die Annotation cnrm.cloud.google.com/deletion-policy: abandon enthält und Sie die Richtlinie zur Datenlöschung abandon nicht mehr verwenden möchten, entfernen Sie diese Annotation aus dem YAML-Manifest.
Wenden Sie das aktualisierte YAML-Manifest an, um die Ressource neu abzurufen:
```
kubectl apply -f MANIFEST_FILE
```
Ersetzen Sie MANIFEST_FILE durch den Pfad zu Ihrer YAML-Datei für Ressourcen.

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

In den meisten Fällen sollten Sie die cnrm.cloud.google.com/state-into-spec: absent-Annotation verwenden, um das Verhalten beim Ausfüllen von Absent für spec-Felder zu erhalten. In den folgenden Abschnitten werden gängige Szenarien beschrieben, die vom Verhalten beim Ausfüllen von Absent profitieren.

Konflikte mit Feldern vermeiden, die automatisch von Google Cloudaktualisiert werden

Wenn für eine Ressource die Annotation cnrm.cloud.google.com/state-into-spec: merge verwendet wird, liest Config Connector Werte aus der Google Cloud API während der ersten Abstimmung und schreibt sie in das Kubernetes-Ressourcenfeld spec. Wenn ein Google Cloud -Dienst später eines dieser Felder automatisch aktualisiert, behandelt Config Connector den älteren Wert, der im Feld spec gespeichert ist, als Zielstatus und versucht, die Änderung an der zugrunde liegendenGoogle Cloud -Ressource rückgängig zu machen.

Wenn Sie beispielsweise eine SQLInstance-Ressource mit der Annotation cnrm.cloud.google.com/state-into-spec: merge erstellen, ohne das Feld spec.maintenanceVersion anzugeben, füllt Config Connector das Feld spec.maintenanceVersion mit der ursprünglichen Wartungsversion. Wenn Cloud SQL später ein automatisches Wartungsupdate für die Instanz ausführt, wird die Live-Wartungsversion in Cloud SQL aktualisiert. Beim nächsten Abgleich versucht Config Connector, die Instanz wieder auf den älteren spec.maintenanceVersion-Wert zu patchen. Da Cloud SQL Downgrades von Wartungsversionen ablehnt, schlägt die Abstimmung wiederholt mit einem UpdateFailed-Fehler (The requested maintenance version is not an available maintenance version to upgrade) fehl.

Wenn Sie die Annotation cnrm.cloud.google.com/state-into-spec: absent festlegen, lassen Sie automatisch aktualisierte Felder wie spec.maintenanceVersion in Ihrem YAML-Manifest weg. Config Connector zeichnet diese Felder nicht im Feld spec auf, sodass Google Cloud sie ohne Abgleichskonflikte aktualisieren kann.

Nicht angegebene Felder in einer Liste extern verwalten

Config Connector behandelt alle Listenfelder im Feld spec der Kubernetes-Ressource als atomare Felder. Wenn der Wert der Annotation state-into-spec auf merge gesetzt ist, macht Config Connector alle Änderungen rückgängig, die außerhalb von Config Connector an einem Unterfeld in einer Liste vorgenommen wurden. Sie können jedoch die Annotation cnrm.cloud.google.com/state-into-spec: absent verwenden, damit Config Connector nicht angegebene Unterfelder in einer Liste nicht verwaltet. Weitere Informationen finden Sie unter Verhalten für Listenfelder in der Ressourcenspezifikation.

Konflikte zwischen Tools zur Konfigurationsverwaltung und Config Connector beheben

Wenn Sie Konfigurationsverwaltungstools wie Config Sync oder Argo CD verwenden, können Konflikte zwischen dem Konfigurationsverwaltungstool und Config Connector auftreten. Ein Beispiel ist der Fehler KNV2005, der in der Anleitung zur Fehlerbehebung erläutert wird. Diese Probleme treten aus folgenden Gründen auf:

Wenn der Wert der Annotation state-into-spec auf merge gesetzt ist, füllt Config Connector nicht angegebene Werte in Listen im Feld spec, z. B. im Feld spec.listField[0].itemField2, mit Standardwerten auf.
Sowohl Konfigurationsverwaltungstools als auch Config Connector behandeln Listenfelder als atomar. Daher betrachten Konfigurationsverwaltungstools das hinzugefügte Feld spec.listField[0].itemField2 als Abweichung und entfernen es.

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

GET/PUT-Symmetrieprobleme beheben

GET/PUT-Symmetrie bezieht sich auf ein Designprinzip in REST APIs. Das bedeutet, dass bei einer GET-Antwort, die als PUT-Anfrage an dieselbe URL gesendet wird, ein HTTP-Statuscode 200 OK erwartet wird, ohne dass sich der Status der zugrunde liegenden REST-Ressource ändert.

Wenn der Wert der Annotation state-into-spec auf merge festgelegt ist, sind die nicht angegebenen Felder, die von Config Connector im Feld spec der Kubernetes-Ressource eingefügt werden, das Ergebnis einer GET-Anfrage. Das bedeutet, dass Config Connector bei zukünftigen Abstimmungen möglicherweise eine PUT- oder PATCH-Anfrage mit diesen nicht angegebenen Feldwerten, die aus der GET-Anfrage stammen, an die zugrunde liegendeGoogle Cloud API sendet. Dieses Verhalten ist in der Regel kein Problem, aber einige Google Cloud APIs lehnen die PUT- oder PATCH-Anfrage möglicherweise aufgrund dieser nicht angegebenen Feldwerte ab. Im selben Beispiel kann das ausgefüllte Feld spec.objectField.subField2 mit dem Wert "sub-value-2" zu einem HTTP-400-Clientfehler oder anderen unerwarteten Antworten führen, wenn die API-Implementierung gegen das GET/PUT-Symmetrieprinzip verstößt.

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

Beobachteter Status

Wenn Sie die Annotation 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 Feld status.observedState im CRD-Schema vorhanden sind. Wenn sie im Feld status.observedState dargestellt werden, können Sie die Anmerkung 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 Livestatus der ausgewählten, beobachteten Felder der Ressource, die Config Connector bei der letzten erfolgreichen Abstimmung beobachtet hat. Config Connector wählt beobachtete Felder aus, die berechnete spec-Felder und Abhängigkeiten für gängige Anwendungsfälle sind. Die beobachteten Felder finden Sie in den CRD-Schemas.

Wenn Sie die gewünschten beobachteten Felder nicht finden, suchen Sie in der öffentlichen Problemverfolgung nach einem vorhandenen Problem oder eröffnen Sie ein neues Problem.

Arten mit `Merge`-Unterstützung

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

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
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
TagsTagBinding
TagsTagKey
TagsTagValue
VPCAccessConnector

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

Artname	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