Fehlerbehebung bei Policy Controller

Auf dieser Seite erfahren Sie, wie Sie Probleme mit Policy Controller beheben.

Allgemeine Tipps

Der folgende Abschnitt enthält allgemeine Hinweise zur Behebung von Problemen mit Policy Controller.

Policy Controller stoppen

Wenn Policy Controller Probleme in Ihrem Cluster verursacht, können Sie Policy Controller anhalten, während Sie das Problem untersuchen.

Messwerte untersuchen

Wenn Sie die Messwerte des Policy Controllers untersuchen, können Sie Probleme mit Policy Controller diagnostizieren.

Installation prüfen

Sie können prüfen, ob Policy Controller und die Einschränkungsvorlagenbibliothek erfolgreich installiert wurden.

Policy Controller trennen

In seltenen Fällen kann es erforderlich sein, Policy Controller von Ihren Clustern zu trennen. Dadurch wird die Verwaltung von Policy Controller vollständig deaktiviert. Versuchen Sie, Policy Controller vorübergehend zu beenden, um zu sehen, ob Probleme behoben werden können, bevor Sie den Befehl detach verwenden.

Warnung: Dieser Befehl sollte nur in Notfällen verwendet werden. Lassen Sie Ihre Cluster nicht für längere Zeit getrennt. Wenn Sie ein schwerwiegendes Problem mit Ihren Clustern haben, wenden Sie sich an Google Cloud-Support, um das Problem mit der verwalteten Steuerungsebene zu melden und zu beheben, sodass Sie den Cluster wieder verbinden können.

1. Trennen Sie den Policy Controller von Ihrer gesamten Flotte:

   gcloud container fleet policycontroller detach
   

2. Hängen Sie Policy Controller wieder an:

   gcloud container fleet policycontroller enable
   

Fehler beim Erstellen einer Einschränkungsvorlage

Wenn bei einem Fehler disallowed ref erwähnt wird, prüfen Sie, dass Sie referenzielle Einschränkungen aktiviert haben. Wenn Sie beispielsweise data.inventory in einer Einschränkungsvorlage verwenden, ohne zuerst referenzielle Einschränkungen zu aktivieren, sieht der Fehler etwa so aus:

admission webhook "validation.gatekeeper.sh" denied the request: check refs failed on module {templates["admission.k8s.gatekeeper.sh"]["MyTemplate"]}: disallowed ref data.inventory...

Einschränkung nicht erzwungen

Der folgende Abschnitt enthält Hinweise zur Fehlerbehebung, wenn Sie vermuten oder wissen, dass Ihre Einschränkungen nicht erzwungen werden.

Prüfen, ob die Einschränkung erzwungen wird

Wenn Sie befürchten, dass Ihre Einschränkung nicht erzwungen wird, können Sie den spec.status Ihrer Einschränkung und die Einschränkungsvorlage prüfen. Führen Sie zum Prüfen des Status den folgenden Befehl aus:

kubectl describe CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

Dabei gilt:

• CONSTRAINT_TEMPLATE_NAME: der Name der Einschränkungsvorlage, die Sie prüfen möchten. Beispiel: K8sNoExternalServices.

• CONSTRAINT_NAME: der Name der Einschränkung, die Sie prüfen möchten.

  Führen Sie bei Bedarf kubectl get constraint aus, um zu sehen, welche Einschränkungsvorlagen und Einschränkungen auf Ihrem System installiert sind.

Notieren Sie in der Ausgabe des Befehls kubectl describe die Werte in den Feldern metadata.generation und status.byPod.observedGeneration. Im folgenden Beispiel sind diese Werte fett formatiert:

Name:         no-internet-services
Namespace:
API Version:  constraints.gatekeeper.sh/v1beta1
Kind:         K8sNoExternalServices
Metadata:
  Creation Timestamp:  2021-12-03T19:00:06Z
  Generation:          1
  Managed Fields:
    API Version:  constraints.gatekeeper.sh/v1beta1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          f:config.k8s.io/owning-inventory:
          f:configmanagement.gke.io/cluster-name:
          f:configmanagement.gke.io/managed:
          f:configmanagement.gke.io/source-path:
          f:configmanagement.gke.io/token:
          f:configsync.gke.io/declared-fields:
          f:configsync.gke.io/git-context:
          f:configsync.gke.io/manager:
          f:configsync.gke.io/resource-id:
        f:labels:
          f:app.kubernetes.io/managed-by:
          f:configsync.gke.io/declared-version:
      f:spec:
        f:parameters:
          f:internalCIDRs:
    Manager:      configsync.gke.io
    Operation:    Apply
    Time:         2022-02-15T17:13:20Z
    API Version:  constraints.gatekeeper.sh/v1beta1
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
    Manager:         gatekeeper
    Operation:       Update
    Time:            2021-12-03T19:00:08Z
  Resource Version:  41460953
  UID:               ac80849d-a644-4c5c-8787-f73e90b2c988
Spec:
  Parameters:
    Internal CID Rs:
Status:
  Audit Timestamp:  2022-02-15T17:21:51Z
  By Pod:
    Constraint UID:       ac80849d-a644-4c5c-8787-f73e90b2c988
    Enforced:             true
    Id:                   gatekeeper-audit-5d4d474f95-746x4
    Observed Generation:  1
    Operations:
      audit
      status
    Constraint UID:       ac80849d-a644-4c5c-8787-f73e90b2c988
    Enforced:             true
    Id:                   gatekeeper-controller-manager-76d777ddb8-g24dh
    Observed Generation:  1
    Operations:
      webhook
  Total Violations:  0
Events:              <none>

Wenn Sie jeden Policy Controller-Pod mit einem observedGeneration-Wert sehen, der dem Wert metadata.generation entspricht (im vorherigen Beispiel der Fall), wird Ihre Einschränkung wahrscheinlich erzwungen. Wenn diese Werte jedoch übereinstimmen, aber Probleme mit der Erzwingung Ihrer Einschränkung auftreten, finden Sie im folgenden Abschnitt Tipps. Wenn Sie feststellen, dass nur bestimmte Werte übereinstimmen oder einige Pods nicht aufgeführt sind, ist der Status Ihrer Einschränkung unbekannt. Die Einschränkung wird möglicherweise über die Pods von Policy Controller inkonsistent oder überhaupt nicht erzwungen. Wenn es keine übereinstimmenden Werte gibt, wird Ihre Einschränkung nicht erzwungen.

Einschränkung nicht erzwungen, aber Audit-Ergebnisse werden gemeldet

Wenn die im vorherigen Abschnitt beschriebene Prüfung observedGeneration übereinstimmende Werte hatte und zur Einschränkung, die die erwarteten Verstöße zeigt (für bereits vorhandene Objekte, nicht für eingehende Anfragen), Audit-Ergebnisse angezeigt werden, aber die Einschränkung immer noch nicht erzwungen wird, dann liegt das Problem wahrscheinlich am Webhook. Beim Webhook kann eines der folgenden Probleme auftreten:

• Der Policy Controller-Webhook-Pod ist möglicherweise nicht betriebsbereit. Kubernetes-Debugging-Methoden können Ihnen dabei helfen, Probleme mit dem Webhook-Pod zu beheben.
• Es kann eine Firewall zwischen dem API-Server und dem Webhook-Dienst vorhanden sein. Weitere Informationen zum Beheben der Firewall finden Sie in der Dokumentation Ihres Firewallanbieters.

Referenzielle Einschränkung nicht erzwungen

Wenn Ihre Einschränkung eine referenzielle Einschränkung ist, achten Sie darauf, dass die erforderlichen Ressourcen im Cache gespeichert werden. Weitere Informationen zum Caching von Ressourcen finden Sie unter Policy Controller für referenzielle Einschränkungen konfigurieren.

Syntax der Einschränkungsvorlage prüfen

Wenn Sie Ihre eigene Einschränkungsvorlage geschrieben haben und es nicht erzwungen wird, liegt möglicherweise ein Fehler in der Syntax der Einschränkungsvorlage vor.

Sie können die Vorlage mit dem folgenden Befehl prüfen:

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

Ersetzen Sie CONSTRAINT_TEMPLATE_NAME durch den Namen der Vorlage, die Sie untersuchen möchten. Fehler sollten im Feld status gemeldet werden.

Nächste Schritte

• Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Google Cloud-Support.