Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei der Bereitstellung privilegierter Autopilot-Arbeitslasten

Autopilot

Privilegierte Arbeitslasten in Google Kubernetes Engine (GKE) Autopilot-Clustern müssen richtig konfiguriert werden, um Probleme zu vermeiden. Fehlkonfigurationen können zu Synchronisierungsfehlern bei Zulassungslisten führen oder dazu, dass die Arbeitslast abgelehnt wird. Diese Probleme können verhindern, dass wichtige Agents oder Dienste mit den erforderlichen Berechtigungen ausgeführt werden.

In diesem Dokument erfahren Sie, wie Sie Probleme bei der Bereitstellung privilegierter Arbeitslasten in Autopilot beheben können. Hier finden Sie Informationen zum Beheben von Fehlern bei der Synchronisierung der Zulassungsliste und zur Diagnose, warum eine privilegierte Arbeitslast möglicherweise abgelehnt wird.

Diese Informationen sind wichtig für Plattformadministratoren und ‑operatoren sowie Sicherheitsteams, die Arbeitslasten mit erhöhten Berechtigungen in Autopilot-Clustern bereitstellen. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Probleme bei der Synchronisierung der Zulassungsliste

Wenn Sie ein AllowlistSynchronizer bereitstellen, versucht GKE, die von Ihnen angegebenen Zulassungslistendateien zu installieren und zu synchronisieren. Wenn diese Synchronisierung fehlschlägt, wird der Fehler im Feld status der AllowlistSynchronizer gemeldet.

Rufen Sie den Status des AllowlistSynchronizer-Objekts ab:

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

Die Ausgabe sieht etwa so aus:

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/allowlist1.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/allowlist2.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

Die Felder conditions.message und managedAllowlistStatus.lastError enthalten detaillierte Informationen zum Fehler. Anhand dieser Informationen können Sie das Problem beheben.

Mehrere AllowlistSynchronizer

In GKE-Clustern mit Versionen vor 1.33.4-gke.1035000 kann die Installation von WorkloadAllowlists fehlschlagen, wenn mehr als ein AllowlistSynchronizer vorhanden ist.

Verwenden Sie nur einen einzelnen AllowlistSynchronizer, der mehrere allowlistPaths enthält, um das Problem zu beheben.

Alternativ können Sie ein Upgrade Ihres Clusters auf eine neuere Version durchführen.

Sortierung von Arbeitslastcontainern

In GKE-Clustern mit Versionen vor 1.34.0-gke.0000000 werden Arbeitslastcontainer möglicherweise erstellt und in umgekehrter alphabetischer Reihenfolge sortiert, wenn ein oder mehrere Arbeitslastcontainer-Images mit einem Container-Image übereinstimmen, das in einer WorkloadAllowlist im Cluster angegeben ist.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

Aktualisieren Sie Ihren Cluster auf Version 1.34.0-gke.0000000 oder höher.
Benennen Sie die Container Ihrer Arbeitslast um, damit sie in der richtigen Reihenfolge sortiert werden.

Probleme bei der Bereitstellung privilegierter Arbeitslasten

Nachdem Sie eine Zulassungsliste erfolgreich installiert haben, stellen Sie die entsprechende privilegierte Arbeitslast in Ihrem Cluster bereit. In einigen Fällen lehnt GKE die Arbeitslast möglicherweise ab.

Versuchen Sie Folgendes:

Achten Sie darauf, dass die GKE-Version Ihres Clusters die Versionsanforderung der Arbeitslast erfüllt.
Prüfen Sie, ob die Arbeitslast, die Sie bereitstellen, die Arbeitslast ist, für die die Zulassungslistendatei gilt.

Wenn Sie wissen möchten, warum eine privilegierte Arbeitslast abgelehnt wurde, fordern Sie detaillierte Informationen zu Verstößen gegen die Zulassungsliste von GKE an:

Rufen Sie eine Liste der installierten Zulassungslisten im Cluster ab:
```
kubectl get workloadallowlist
```
Suchen Sie den Namen der Zulassungsliste, die für die privilegierte Arbeitslast gelten soll.
Öffnen Sie das YAML-Manifest der privilegierten Arbeitslast in einem Texteditor. Wenn Sie nicht auf die YAML-Manifeste zugreifen können, z. B. wenn beim Bereitstellungsprozess der Arbeitslast andere Tools verwendet werden, wenden Sie sich an den Arbeitslastanbieter, um ein Problem zu melden. Überspringen Sie die restlichen Schritte.
Fügen Sie der Pod-Spezifikation der privilegierten Arbeitslast im Abschnitt spec.metadata.labels das folgende Label hinzu:
```
labels:
  cloud.google.com/matching-allowlist: ALLOWLIST_NAME
```
Ersetzen Sie ALLOWLIST_NAME durch den Namen der Zulassungsliste, die Sie im vorherigen Schritt erhalten haben. Verwenden Sie den Namen aus der Ausgabe des Befehls kubectl get workloadallowlist, nicht den Pfad zur Zulassungslistendatei.

Speichern Sie das Manifest und wenden Sie die Arbeitslast auf den Cluster an:

kubectl apply -f WORKLOAD_MANIFEST_FILE

Ersetzen Sie WORKLOAD_MANIFEST_FILE durch den Pfad zur Manifestdatei.

Die Ausgabe enthält detaillierte Informationen dazu, welche Felder in der Arbeitslast nicht mit der angegebenen Zulassungsliste übereinstimmen, wie im folgenden Beispiel:

Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:

===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
         - data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
        - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
        - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
        - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
        - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.

In diesem Beispiel treten die folgenden Verstöße auf:

In der Arbeitslast wird hostNetwork: true angegeben, in der Zulassungsliste jedoch nicht.hostNetwork: true
In der Arbeitslast wird hostPID: true angegeben, in der Zulassungsliste jedoch nicht.hostPID: true
In der Arbeitslast wird ein Volume mit dem Namen data angegeben, in der Zulassungsliste jedoch nicht.data
Im Container werden Umgebungsvariablen mit den Namen ENV_VAR1 und ENV_VAR2 angegeben, in der Zulassungsliste jedoch nicht.
Der Container gibt das Image k8s.gcr.io/diff/image an, die Zulassungsliste jedoch k8s.gcr.io/pause2.
Der Container fügt die Funktionen SYS_ADMIN und SYS_PTRACE hinzu, aber die Zulassungsliste erlaubt das Hinzufügen dieser Funktionen nicht.
Der Container gibt eine Volume-Bereitstellung mit dem Namen data an, aber die Zulassungsliste gibt keine Volume-Bereitstellung mit dem Namen data an.

Wenn Sie eine Arbeitslast bereitstellen, die von einem Drittanbieter bereitgestellt wird, wenden Sie sich an diesen Anbieter, um die Verstöße zu beheben. Geben Sie die Ausgabe aus dem vorherigen Schritt im Problem an.

Webhook-Beeinträchtigung von Arbeitslasten auf einer Zulassungsliste

In einigen Fällen kann eine Arbeitslast von GKE abgelehnt werden, auch wenn sie korrekt konfiguriert ist, um einer Zulassungsliste zu entsprechen. Dies kann passieren, wenn ein anderer Zugangs-Controller (Webhook) in Ihrem Cluster die von dem Workload-Controller erstellten Pods ändert, nachdem sie von der Zulassungsliste zugelassen wurden. Diese Änderungen können dazu führen, dass die Pod-Spezifikation nicht mehr mit der Zulassungsliste übereinstimmt, was zur Ablehnung durch den GKE Warden-Zugangs-Webhook führt.

Dieses Problem tritt häufig bei Überwachungs- und Sicherheits-Agents von Drittanbietern auf, die Sidecar-Container oder Umgebungsvariablen in Pods einfügen.

Symptom

Das häufigste Symptom ist, dass der Controller für die Arbeitslast (z. B. ein DaemonSet oder Deployment) erfolgreich erstellt wird, aber keine Pods erstellt werden können. Wenn Sie die Ereignisse des Controllers untersuchen, sehen Sie Meldungen, die darauf hinweisen, dass die Pods vom Admission-Webhook abgelehnt wurden.

Diagnose

Folgen Sie der Anleitung im Abschnitt Probleme bei der Bereitstellung privilegierter Arbeitslasten, um Ihrer Arbeitslast das Label cloud.google.com/matching-allowlist hinzuzufügen.
Kopieren Sie die spec.template aus dem YAML-Manifest Ihrer Arbeitslast.
Erstellen Sie ein neues Pod-Manifest und fügen Sie die kopierte Spezifikation in das Feld spec ein.

Legen Sie die Felder apiVersion, kind und metadata.name im Pod-Manifest fest:

apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
  labels:
    cloud.google.com/matching-allowlist: ALLOWLIST_NAME
spec:
  # Paste the content of spec.template here

Ersetzen Sie Folgendes:

POD_NAME: Der Name für Ihren Test-Pod.
ALLOWLIST_NAME: Der Name der Zulassungsliste.

Wenden Sie das Pod-Manifest an:
```
kubectl apply -f YOUR_POD_MANIFEST_FILE
```
Ersetzen Sie YOUR_POD_MANIFEST_FILE durch den Pfad zu Ihrer Pod-Manifestdatei.
Prüfen Sie die Ausgabe des vorherigen Schritts. Wenn Sie im Bereich „Workload Mismatches“ (Arbeitslast-Abweichungen) unerwartete Felder sehen, z. B. zusätzliche Umgebungsvariablen (z. B. DD_AGENT_HOST), Container oder Volumes, ist das ein starkes Indiz dafür, dass ein anderer Webhook Ihre Pods ändert.

Lösung

Um dieses Problem zu beheben, müssen Sie den in Konflikt stehenden Webhook so konfigurieren, dass er die Pods Ihrer zugelassenen Arbeitslast nicht ändert. Dies geschieht in der Regel, indem der Arbeitslast oder ihrem Namespace ein Label oder eine Annotation hinzugefügt wird, um dem Webhook zu signalisieren, dass sie von der Mutation ausgeschlossen werden soll. Wenn Sie beispielsweise Datadog verwenden, fügen Sie dem Namespace Ihrer Arbeitslast das Label admission.datadoghq.com/enabled: "false" hinzu.

In der Dokumentation der jeweiligen Drittanbietersoftware erfahren Sie, wie Sie Arbeitslasten aus dem Admission Controller ausschließen.

Wenn Sie verhindern, dass der andere Webhook die Pods ändert, können Sie dafür sorgen, dass sie weiterhin der Zulassungsliste entsprechen und erfolgreich in Ihrem Autopilot-Cluster bereitgestellt werden.

Programmfehler und Funktionsanfragen für privilegierte Arbeitslasten und Zulassungslisten

Partner sind für die Erstellung, Entwicklung und Wartung ihrer privilegierten Arbeitslasten und Zulassungslisten verantwortlich. Wenn Sie einen Fehler finden oder einen Funktionswunsch für eine privilegierte Arbeitslast oder Zulassungsliste haben, wenden Sie sich an den entsprechenden Partner.

Nächste Schritte

Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen:
- Sie können eine Supportanfrage erstellen, indem Sie sich an den Cloud Customer Care wenden.
- Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem Tag google-kubernetes-engine nach ähnlichen Problemen suchen. Sie können auch dem #kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten.
- Sie können Fehler melden oder Funktionsanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.

Fehlerbehebung bei der Bereitstellung privilegierter Autopilot-Arbeitslasten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.