Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Diese Seite wurde von der Cloud Translation API übersetzt.

Konfigurationsabweichungen verhindern

Config Sync reduziert das Risiko von „Shadow Ops“ durch automatische Selbstreparatur, regelmäßige Neusynchronisierung und optionale Drift-Prävention. Wenn Config Sync eine Abweichung zwischen dem Cluster und der Source of Truth erkennt, kann diese entweder zugelassen und schnell rückgängig gemacht oder vollständig abgelehnt werden.

Die Selbstreparatur überwacht verwaltete Ressourcen, erkennt eine Abweichung von der "Source of Truth" und macht diese Abweichung rückgängig. Die Selbstheilung ist immer aktiviert.

Die regelmäßige Neusynchronisierung erfolgt automatisch eine Stunde nach der letzten erfolgreichen Synchronisierung, auch wenn keine Änderungen an der „Source of Truth“ vorgenommen wurden. Die regelmäßige Synchronisierung ist immer aktiviert.

Während Selbstreparatur und regelmäßige Neusynchronisierungen dazu beitragen, Abweichungen zu beheben, fängt die Drift-Prävention Anfragen zum Ändern verwalteter Objekte ab und prüft, ob die Änderung zugelassen werden sollte. Wenn die Änderung nicht mit der Source of Truth übereinstimmt, wird sie abgelehnt. Die Drift-Prävention ist standardmäßig deaktiviert. Wenn diese Option aktiviert ist, schützt die Drift-Prävention standardmäßig RootSync-Objekte und kann auch zum Schutz von RepoSync-Objekten konfiguriert werden.

Wenn Sie die Drift-Prävention verwenden möchten, müssen Sie die RootSync und RepoSync APIs aktivieren.

Hinweise

Wenn Sie die Google Cloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab.

Drift-Prävention aktivieren

Sie können die Drift-Prävention mit der gcloud CLI aktivieren. Sie können die Drift-Prävention nicht in der Cloud de Confiance Console aktivieren.

Führen Sie die folgenden Schritte aus, um die Drift-Prävention zu aktivieren:

Aktualisieren Sie Ihr applySpec-Manifest, um das Feld spec.configSync.preventDrift auf true festzulegen:

applySpecVersion: 1
spec:
  configSync:
    enabled: true
    ... existing content ...
    preventDrift: true

Wenden Sie das aktualisierte Manifest an:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Ersetzen Sie Folgendes:
- MEMBERSHIP_NAME: Name der Flottenmitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben. Rufen Sie den Namen mit dem Befehl gcloud container fleet memberships list ab.
- MANIFEST_NAME: der Name des Manifests für die Apply-Spezifikation, in der Regel apply-spec.yaml.
- PROJECT_ID: Ihre Projekt-ID.

Warten Sie, bis das Config Sync-ValidateWebhookConfiguration-Objekt vom Config Management Operator erstellt wurde:

kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

NAME                                  WEBHOOKS   AGE
admission-webhook.configsync.gke.io   0          2m15s

Führen Sie ein Commit einer neuen Änderung an der zu synchronisierenden „Source of Truth“ durch, damit das root-reconciler-Deployment Webhooks zum Config Sync-ValidatingWebhookConfiguration-Objekt hinzufügen kann. Alternativ können Sie das root-reconcilier-Deployment löschen, um einen Abgleich auszulösen. Das neue root-reconciler-Deployment würde das Config Sync-ValidatingWebhookConfiguration-Objekt aktualisieren.

Warten Sie, bis der Webhook-Server bereit ist. Das Deployment-Log für den Config Sync-Zulassungs-Webhook sollte serving webhook server enthalten. Dieser Vorgang kann einige Minuten dauern.

kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250

Drift-Prävention deaktivieren

Wenn Sie die Drift-Prävention deaktivieren, löscht Config Sync alle Config Sync-Zulassungs-Webhook-Ressourcen. Da das Config Sync-ValidatingWebhookConfiguration-Objekt nicht mehr vorhanden ist, generieren die Config Sync-Reconciler keine Webhook-Konfigurationen für verwaltete Ressourcen mehr.

Führen Sie die folgenden Schritte aus, um die Drift-Prävention zu deaktivieren:

Aktualisieren Sie Ihr applySpec-Manifest, um das Feld spec.configSync.preventDrift auf false festzulegen:

applySpecVersion: 1
spec:
  configSync:
    enabled: false
    ... existing content ...
    preventDrift: false

Wenden Sie das aktualisierte Manifest an:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Ersetzen Sie Folgendes:
- MEMBERSHIP_NAME: Name der Flottenmitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben. Rufen Sie den Namen mit dem Befehl gcloud container fleet memberships list ab.
- MANIFEST_NAME: der Name des Manifests für die Apply-Spezifikation, in der Regel apply-spec.yaml.
- PROJECT_ID: Ihre Projekt-ID.

Zulassungs-Webhook in Namespace-bezogenen Quellen aktivieren

Namespace-bezogene "Sources of Truth" sind nicht vollständig durch den Webhook geschützt. Der Config Sync-Reconciler für jede Namespace-Quelle hat nicht die Berechtigung, die ValidatingWebhookConfiguration-Objekte auf Clusterebene zu lesen oder zu aktualisieren.

Diese fehlende Berechtigung führt zu einem Fehler für die Namespace-Abgleicher-logs, ähnlich dem folgenden Beispiel:

Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope

Sie können diesen Fehler ignorieren, wenn Sie den Webhook-Schutz für Ihre Namespace-bezogene „Source of Truth“ nicht verwenden möchten. Wenn Sie jedoch den Webhook verwenden möchten, erteilen Sie dem Abgleicher für jede Namespace-bezogene "Source of Truth" die Berechtigung, nachdem Sie die Synchronisierung aus mehreren Sources of Truth konfiguriert haben. Möglicherweise müssen Sie diese Schritte nicht ausführen, wenn bereits ein RoleBinding für ns-reconciler-NAMESPACE mit Berechtigungen für die ClusterRole cluster-admin vorhanden ist.

Deklarieren Sie in der Root-Source of Truth eine neue ClusterRole-Konfiguration, die dem Config Sync-Zulassungs-Webhook Berechtigungen gewährt. Diese ClusterRole muss nur einmal pro Cluster definiert werden:

# ROOT_SOURCE/cluster-roles/webhook-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admission-webhook-role
rules:
- apiGroups: ["admissionregistration.k8s.io"]
  resources: ["validatingwebhookconfigurations"]
  resourceNames: ["admission-webhook.configsync.gke.io"]
  verbs: ["get", "update"]

Deklarieren Sie für jede Namespace-Quelle, für die die Zulassungs-Webhook-Berechtigung gewährt werden muss, eine ClusterRoleBinding-Konfiguration, um Zugriff auf den Zulassungs-Webhook zu gewähren:

# ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-webhook
subjects:
- kind: ServiceAccount
  name: ns-reconciler-NAMESPACE
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: admission-webhook-role
  apiGroup: rbac.authorization.k8s.io

Ersetzen Sie NAMESPACE durch den Namespace, in dem Sie Ihre quellbezogene Quelle erstellt haben.

Übernehmen Sie die Änderungen an der Root-Source of Truth, z. B. bei der Synchronisierung aus einem Git-Repository:

git add .
git commit -m 'Providing namespace repository the permission to update the admission webhook.'
git push

Prüfen Sie zur Bestätigung mit kubectl get, ob ClusterRole und ClusterRoleBinding erstellt wurden:

kubectl get clusterrole admission-webhook-role
kubectl get clusterrolebindings syncs-webhook

Drift-Prävention für verworfene Ressourcen deaktivieren

Wenn Sie ein RootSync- oder RepoSync-Objekt löschen, ändert Config Sync standardmäßig nicht die Ressourcen, die zuvor von diesem RootSync- oder RepoSync-Objekt verwaltet wurden. Dadurch können mehrere Labels und Annotationen zurückbleiben, die Config Sync zum Nachverfolgen dieser Ressourcenobjekte verwendet. Wenn der Drift-Schutz aktiviert ist, können Änderungen an den zuvor verwalteten Ressourcen abgelehnt werden.

Wenn Sie die Löschweitergabe nicht verwendet haben, behalten die verbleibenden Ressourcenobjekte möglicherweise weiterhin Labels und Annotationen bei, die von Config Sync hinzugefügt wurden.

Wenn Sie diese verwalteten Ressourcen behalten möchten, heben Sie die Verwaltung dieser Ressourcen auf, bevor Sie die RootSync- oder RepoSync-Objekte löschen, indem Sie die configmanagement.gke.io/managed-Annotation bei jeder verwalteten Ressource, die in der „Source of Truth“ deklariert ist, auf disabled setzen. Dadurch wird Config Sync angewiesen, die Labels und Annotationen aus den verwalteten Ressourcen zu entfernen, ohne diese Ressourcen zu löschen. Nach Abschluss der Synchronisierung können Sie das RootSync- oder RepoSync-Objekt entfernen.

Wenn Sie diese verwalteten Ressourcen löschen möchten, haben Sie zwei Möglichkeiten:

Löschen Sie die verwalteten Ressourcen aus der Source of Truth. Anschließend löscht Config Sync die verwalteten Objekte aus dem Cluster. Nach Abschluss der Synchronisierung können Sie das RootSync- oder RepoSync-Objekt entfernen.
Aktivieren Sie die Löschweitergabe für das RootSync- oder RepoSync-Objekt, bevor Sie es löschen. Anschließend löscht Config Sync die verwalteten Objekte aus dem Cluster.

Wenn das RootSync- oder RepoSync-Objekt gelöscht wird, bevor seine verwalteten Ressourcen nicht mehr verwaltet oder gelöscht werden, können Sie das RootSync- oder RepoSync-Objekt neu erstellen, und es übernimmt die Ressourcen auf dem Cluster, die der Source of Truth entsprechen. Anschließend können Sie die Verwaltung der Ressourcen aufheben oder sie löschen, und warten, bis die Änderungen synchronisiert wurden, und das RootSync- oder RepoSync-Objekt noch einmal löschen.

Nächste Schritte

Weitere Informationen zur Fehlerbehebung für Webhook.