Was sind die Standardzugangscontroller in meinem Cluster?

In den Referenzinformationen zur Komponente kube-apiserver können Sie die Reihenfolge der standardmäßigen Zugangscontroller nach Cluster-Version überprüfen.

Kann ich meine eigenen Zugangscontroller erstellen?

Ja, siehe die Kubernetes dokumentation für weitere Informationen.

Wie in der Kubernetes-Dokumentation vermerkt, können Sie für Operationen, die ansonsten von der Steuerebene abgewickelt werden, Zugangscontroller verwenden. Lassen Sie beim Konfigurieren eines angepassten Zugangscontrollers äußerste Vorsicht walten. Sie sind für alle Änderungen verantwortlich, die in Ihrem Cluster aufgrund eines angepassten Zugangscontrollers auftreten.

Was sind die Best Practices für die Verwendung von Webhooks?

Vermeiden Sie nach Möglichkeit die Verwendung von Webhooks. Verwenden Sie stattdessen die Optionen ValidatingAdmissionPolicy und MutatingAdmissionPolicy (sofern standardmäßig aktiviert).

Wenn Sie Webhooks verwenden müssen, beachten Sie bei der Konfiguration eines Webhooks die folgenden bewährten Verfahren und Überlegungen.

• Verwenden Sie keine mutierenden Webhooks, um Ressourcen zu mutieren, die einem anderen Controller oder Operator gehören. Andernfalls kann es zu einer unendlichen Abstimmungsschleife zwischen dem Eigentümer der Ressource und dem Webhook kommen. Webhooks können den Besitz einer Ressource bestimmen, indem sie prüfen, ob metadata.ownerReferences in den Ressourcendaten gesetzt ist. Zum Beispiel gehört eine Kubernetes Replicaset-Ressource zu einer Kubernetes Deployment-Ressource und darf niemals durch einen Webhook verändert werden.

• Erstellen Sie Replikatpods für den Webhook, sodass der Webhook im Falle der Inaktivität eines Pods weiter Anforderungen von Ihren Ressourcen verarbeiten kann. Streuen Sie die Replikatpods nach Möglichkeit über mehrere Zonen.

• Legen Sie eine entsprechende failurePolicy-Option fest, z. B. ob Ihr Webhook fehlschlägt oder Verbindungsfehler oder Zeitlimitüberschreitungen ignoriert. Sie können failurePolicy auf Ignore setzen, wenn Ihr Webhook Verbindungsfehler und Zeitlimitüberschreitungen ignorieren soll. Beachten Sie, dass dies das Verhalten von apiserver nicht ändert, wenn der Webhook eine Anforderung zurückweist.

• Überprüfen Sie das Intervall timeoutSeconds. Ältere Webhooks, die die v1beta1.admissionregistration.k8s.io API verwenden, haben ein Standardzeitlimit von 30 Sekunden. Die v1-API verwendet einen Standardwert von 10 Sekunden. Wenn die Webhook-Fehlerrichtlinie "Ignorieren" lautet und der aktuelle Wert für timeoutSeconds 30 ist, sollten Sie das Zeitlimit auf 10 Sekunden reduzieren.

  Vermeiden Sie es, mehrere mutierende Webhooks auf denselben Ressourcen ausführen zu lassen. Mutierende Webhooks werden sequenziell ausgeführt. Ein einzelner mutierender Webhook funktioniert möglicherweise aus Sicht der Zeitüberschreitungs- und Fehlerrichtlinien wie erwartet, aber in Kombination mit zusätzlichen mutierenden Webhooks, die auf derselben Ressource ausgeführt werden, können die mutierenden Webhooks die Gesamtkontextzeitüberschreitung überschreiten, die für die Ausführung aller Webhooks vorgesehen ist.

• Legen Sie für Ihren entsprechende Ressourcenanforderungen und -grenzwerte für CPU und Speicher fest.

• Fügen Sie Liveness- und Readiness-Probes hinzu, um sicherzustellen, dass Ihr Webhook-Container läuft und bereit ist, Anfragen zu bedienen.

• Legen Sie Zeitplanregeln mit Anti-Affinität fest, damit Ihre Webhook-Pods nach Möglichkeit auf unterschiedlichen Workerknoten und in unterschiedlichen Zeitzonen ausgeführt werden. Sie können stattdessen die Pod-Topologie verwenden. Vermeiden Sie jedoch Färbungen oder eine erzwungene Affinität, die den Ort, an dem die Webhook-Pods geplant werden können, einschränken könnte.

• Podpriorität festlegen auf system-cluster-critical für die Webhookpods, sodass andere Pods keine Ressourcen aus Ihren Webhookpods nehmen können.

• Legen Sie den Geltungsbereich für Ihren Webhook durch Angabe des geeigneten Namensbereichs fest. Vermeiden Sie Webhooks, die Ressourcen verarbeiten, die in systemkritischen Namespaces laufen, die in Ihrem Cluster standardmäßig eingerichtet sind, wie die Namespaces kube-system, ibm-system, ibm-operators, calico-apiserver, calico-system, tigera-operator und openshift-*.

• Überprüfen Sie die Option namespaceSelector. Sie können Bezeichnungen zu bestimmten kritischen Namensbereichen wie kube-system hinzufügen, sodass der Webhook für diese Fälle nicht aufgerufen wird. Diese Konfiguration wird als "Opt-out"-Konfiguration bezeichnet. Sie können auch die Option namespaceSelector so konfigurieren, dass der Webhook nur für Namensbereiche mit einer bestimmten Bezeichnung aufgerufen wird. Diese Konfiguration wird als "Opt-in"-Konfiguration bezeichnet. Je nach Zweck des Webhooks kann es wichtig sein, dass der Webhook für alle Namensbereiche aufgerufen wird. Sehen Sie sich die namespaceSelector-Konfigurationsoptionen in der Kubernetes-Dokumentation an und passen Sie Ihre Webhook-Konfiguration an.

• Stellen Sie sicher, dass die Arbeitsknoten in Ihrem Cluster die richtige Größe für die Ausführung Ihrer Webhook-Anwendungen haben. Wenn Ihre Pods beispielsweise mehr CPU oder Speicher anfordern, als der Workerknoten bereitstellen kann, die Pods nicht in die Planung einbezogen.

Welche anderen Arten von Apps verwenden Zugangscontroller?

Viele Cluster-Add-Ons, Plug-Ins und andere Erweiterungen von Drittanbietern verwenden Zugangscontroller. Einige gängige Beispiele sind:

• Portieris
• Istio

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

Ich brauche Hilfe bei einem defekten Webhook. Was kann ich tun?

Informationen zur Fehlerbehebung für Webhooks finden Sie unter Debugging für Webhooks oder Cluster kann wegen defekter Webhooks nicht aktualisiert werden.