Kann ich meine eigenen Zugangscontroller erstellen?

Ja, weitere Informationen finden Sie in der Dokumentation zu Kubernetes und Red Hat OpenShift.

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 Ressourcenbesitzer 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. Für OpenShift-Cluster haben Steuerebenenkomponenten häufig ein eigenes Zeitlimit von 13 Sekunden.

  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 bearbeiten.

• 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 Taints oder erzwungene Affinitäten, die die Möglichkeiten zur Einplanung der Webhook-Pods einschränken könnten.

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

• Definieren Sie Ihren Webhook für das entsprechende Projekt. Vermeiden Sie Webhooks, die Ressourcen verarbeiten, die in systemkritischen Projekten ausgeführt werden, die standardmäßig in Ihrem Cluster eingerichtet sind, wie beispielsweise die Projekte 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 Worker-Knoten 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

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.