Best practices

1 - Überlegungen für große Cluster

Ein Cluster ist ein Satz von Nodes (physikalisch oder virtuell), auf denen Kubernetes-Agents laufen. Diese ermöglichen es der Kubernetes-Control Plane, die Nodes zu steuern. Kubernetes v1.35 unterstützt Cluster mit bis zu 5000 Nodes. Genauer gesagt ist Kubernetes auf folgende Konfigurationen ausgelegt:

• Nicht mehr als 110 Pods pro Node
• Nicht mehr als 5000 Nodes
• Nicht mehr als 150000 Pods insgesamt
• Nicht mehr als 300000 Container insgesamt

Ein Cluster kann skaliert werden, indem weitere Nodes hinzugefügt werden. Wie man Nodes hinzufügen kann, hängt von der Art und Weise ab, wie das Cluster initial aufgesetzt wurde.

Ressourcenlimits von Cloud-Providern

Um Probleme mit Quota von Cloud-Providern zu vermeiden, sollten Sie bei der Erstellung eines Clusters mit vielen Nodes Folgendes in Betracht ziehen:

• Beantragen Sie eine Erhöhung der Quota für Cloud-Ressourcen wie:
  • Compute-Instanzen
  • CPUs
  • Speichervolumes
  • Verwendete IP-Adressen
  • Regelwerke zur Paketfilterung
  • Anzahl der Load Balancer
  • Netzwerk-Subnetze
  • Log-Streams
• Skalierungsaktionen in Batches durchzuführen, mit einer Pause zwischen den Batches, da einige Cloud-Provider die Erstellung neuer Instanzen mit Rate Limits versehen.

Komponenten der Control Plane

Für ein großes Cluster benötigen Sie eine Control Plane mit ausreichenden Rechen- und weiteren Ressourcen.

Typischerweise betreiben Sie eine oder zwei Control-Plane-Instanzen pro Ausfallzone, wobei Sie diese Instanzen zunächst vertikal skalieren und anschließend horizontal erweitern, wenn vertikale Skalierung keine Verbesserungen mehr bringt.

Sie sollten mindestens eine Instanz pro Ausfallzone betreiben, um Fehlertoleranz zu gewährleisten. Kubernetes-Nodes leiten den Datenverkehr nicht automatisch zu Control-Plane-Endpunkten in derselben Ausfallzone um; allerdings könnte Ihr Cloud-Provider eigene Mechanismen hierfür anbieten.

Beispielsweise können Sie mit einem Managed Load Balancer den Datenverkehr, der von Kubelets und Pods in der Ausfallzone A stammt, so konfigurieren, dass er nur an die Control-Plane-Hosts in Zone A weitergeleitet wird. Fällt ein einzelner Control-Plane-Host oder ein Endpunkt in Zone A aus, bedeutet das, dass der gesamte Control-Plane-Datenverkehr der Nodes in Zone A nun zwischen den Zonen geleitet wird. Mehrere Control-Plane-Hosts in jeder Zone reduzieren die Wahrscheinlichkeit dieses Szenarios.

etcd-Speicher

Um die Leistung großer Cluster zu verbessern, können Sie Event-Objekte in einer separaten, dedizierten etcd-Instanz speichern.

Bei der Erstellung eines Clusters können Sie (mit benutzerdefinierten Tools):

• eine zusätzliche etcd-Instanz starten und konfigurieren
• den API-Server so konfigurieren, dass er diese Instanz zur Speicherung von Ereignissen nutzt

Siehe Betrieb von etcd-Clustern für Kubernetes und Einrichten eines hochverfügbaren etcd-Clusters mit kubeadm für Details zur Konfiguration und Verwaltung von etcd für große Cluster.

Addon-Ressourcen

Kubernetes-Ressourcenlimits helfen dabei, die Auswirkungen von Speicherlecks und anderer Probleme zu minimieren, bei denen Pods und Container andere Komponenten beeinträchtigen können.

Diese Ressourcenlimits gelten auch für Addons ebenso wie für Anwendungs-Workloads.

Beispielsweise können Sie CPU- und Speicherlimits für eine Logging-Komponente festlegen:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

Die Standardlimits von Addons basieren in der Regel auf Daten, die aus dem Betrieb auf kleinen oder mittleren Kubernetes-Clustern gesammelt wurden. Bei großen Clustern verbrauchen Addons oft mehr Ressourcen als ihre Standardlimits. Wenn ein großer Cluster ohne Anpassung dieser Werte bereitgestellt wird, können Addons kontinuierlich beendet werden, da sie ihr Speicherlimit überschreiten. Alternativ laufen die Addons zwar, liefern aber eine schlechte Performance aufgrund von CPU-Zeit-Slice-Beschränkungen.

Um Probleme mit Addon-Ressourcen in großen Clustern zu vermeiden, sollten Sie Folgendes beachten:

• Einige Addons skalieren vertikal – es gibt eine Replik des Addons für das Cluster oder für eine gesamte Ausfallzone. Für diese Addons sollten Sie Anfragen und Limits erhöhen, wenn Sie Ihr Cluster erweitern.
• Viele Addons skalieren horizontal – Sie erhöhen die Kapazität, indem Sie mehr Pods ausführen – aber bei einem sehr großen Cluster müssen Sie möglicherweise auch die CPU- oder Speicherlimits leicht anheben. Der Vertical Pod Autoscaler kann im Recommender-Modus ausgeführt werden, um empfohlene Werte für Anfragen und Limits bereitzustellen.
• Einige Addons laufen als eine Instanz pro Node, gesteuert durch ein DaemonSet, z. B. ein Node-level Log-Aggregator. Ähnlich wie bei horizontal skalierten Addons müssen Sie eventuell CPU- oder Speicherlimits leicht erhöhen.

Nächste Schritte

• VerticalPodAutoscaler ist eine benutzerdefinierte Ressource, die Sie in Ihr Cluster deployen können, um Ressourcenanforderungen und Limits für Pods zu verwalten. Erfahren Sie mehr über den Vertical Pod Autoscaler und wie Sie ihn nutzen können, um Cluster-Komponenten einschließlich clusterkritischer Addons zu skalieren.

• Lesen Sie mehr über Node-Autoscaling

• Addon Resizer unterstützt Sie dabei, die Addons automatisch an die Clustergröße anzupassen.

2 - PKI Zertifikate and Anforderungen

Kubernetes benötigt PKI Zertifikate für die Authentifzierung über TLS. Falls Sie Kubernetes über kubeadm installieren, wurden die benötigten Zertifikate bereits automatisch generiert. In jedem Fall können Sie diese auch selbst generieren -- beispielsweise um private Schlüssel nicht auf dem API Server zu speichern und somit deren Sicherheit zu erhöhen. Diese Seite erklärt, welche Zertifikate ein Cluster benötigt.

Wie Zertifikate in Ihrem Cluster verwendet werden

Kubernetes benötigt PKI-Zertifikate für die folgenden Vorgänge:

Server Zertifikate

• Server Zertifikate für den API Server Endpunkt
• Server Zertifikate für den etcd Server
• Server Zertifikate für jeden kubelet (every node runs a kubelet)
• Optionale Server Zertifikate für den front-proxy

Client Zertifikate

• Client-Zertifikate für jedes Kubelet zur Authentifizierung gegenüber dem API-Server als Client der Kubernetes API
• Client-Zertifikat für jeden API-Server zur Authentifizierung gegenüber etcd
• Client-Zertifikat für den Controller Manager zur sicheren Kommunikation mit dem API-Server
• Client-Zertifikat für den Scheduler zur sicheren Kommunikation mit dem API-Server
• Client-Zertifikate, eines pro Node, für kube-proxy zur Authentifizierung gegenüber dem API-Server
• Optionale Client-Zertifikate für Administratoren des Clusters zur Authentifizierung gegenüber dem API-Server
• Optionales Client-Zertifikat für den Front-Proxy

Server- und Client-Zertifikate des Kubelets

Um eine sichere Verbindung herzustellen und sich gegenüber dem Kubelet zu authentifizieren, benötigt der API-Server ein Client-Zertifikat und ein Schlüsselpaar.

In diesem Szenario gibt es zwei Ansätze für die Verwendung von Zertifikaten:

• Gemeinsame Zertifikate: Der kube-apiserver kann dasselbe Zertifikat und Schlüsselpaar verwenden, das er zur Authentifizierung seiner Clients nutzt. Das bedeutet, dass bestehende Zertifikate wie apiserver.crt und apiserver.key für die Kommunikation mit den Kubelet-Servern verwendet werden können.

• Separate Zertifikate: Alternativ kann der kube-apiserver ein neues Client-Zertifikat und Schlüsselpaar zur Authentifizierung seiner Kommunikation mit den Kubelet-Servern generieren. In diesem Fall werden ein separates Zertifikat kubelet-client.crt und der dazugehörige private Schlüssel kubelet-client.key erstellt.

Auch etcd verwendet gegenseitiges TLS zur Authentifizierung von Clients und deren Gegenstelle.

Wo Zertifikate gespeichert werden

Wenn Sie Kubernetes mit kubeadm installieren, werden die meisten Zertifikate im Verzeichnis /etc/kubernetes/pki gespeichert. Alle Pfade in dieser Dokumentation beziehen sich auf dieses Verzeichnis, mit Ausnahme der Benutzerzertifikate, die von kubeadm unter /etc/kubernetes ablegt werden.

Zertifikate manuell konfigurieren

Wenn Sie nicht möchten, dass kubeadm die benötigten Zertifikate generiert, können Sie diese entweder mithilfe einer einzelnen Root-CA selbst erstellen oder alle Zertifikate vollständig manuell bereitstellen. Details zur Erstellung einer eigenen Zertifizierungsstelle finden Sie unter Zertifikate. Weitere Informationen zur Verwaltung von Zertifikaten mit kubeadm bietet Zertifikatsverwaltung mit kubeadm.

Einzelne Root-CA

Sie können eine einzelne Root-CA erstellen, welche dann mehrere Zwischen-CAs generieren
und die Erstellung weiterer Zertifikate Kubernetes selbst überlassen kann.

Erforderliche CAs:

Zusätzlich zu den oben genannten CAs wird auch ein öffentliches/privates Schlüsselpaar für das Service-Account-Management benötigt: sa.key und sa.pub.

Das folgende Beispiel zeigt die CA-Schlüssel- und Zertifikatsdateien aus der vorherigen Tabelle:

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

Alle Zertifikate

Wenn Sie die privaten CA-Schlüssel nicht in Ihren Cluster kopieren möchten, können Sie alle Zertifikate selbst generieren.

Erforderliche Zertifikate:

Der Wert in der Spalte Typ entspricht einer oder mehreren x509-Schlüsselverwendungen, die auch in .spec.usages eines CertificateSigningRequest-Typs dokumentiert sind:

Zertifikatspfade

Zertifikate sollten in einem empfohlenen Pfad abgelegt werden (wie von kubeadm verwendet). Die Pfade sollten mit dem angegebenen Argument festgelegt werden, unabhängig vom Speicherort.

Gleiche Überlegungen gelten für das Service-Account-Schlüsselpaar:

Das folgende Beispiel zeigt die Dateipfade aus den vorherigen Tabellen, die Sie bereitstellen müssen, wenn Sie alle Schlüssel und Zertifikate selbst generieren:

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

Zertifikate für Benutzerkonten konfigurieren

Sie müssen diese Administrator- und Servicekonten manuell konfigurieren:

1. Generieren Sie für jede Konfiguration ein x509-Zertifikat/Schlüsselpaar mit dem angegebenen Common Name (CN) und der Organisation (O).

2. Führen Sie für jede Konfiguration kubectl wie folgt aus:

   KUBECONFIG=<Dateiname> kubectl config set-cluster default-cluster --server=https://<Host-IP>:6443 --certificate-authority <Pfad-zur-kubernetes-ca> --embed-certs
   KUBECONFIG=<Dateiname> kubectl config set-credentials <Anmeldeinfo-Name> --client-key <Pfad-zum-Schlüssel>.pem --client-certificate <Pfad-zum-Zertifikat>.pem --embed-certs
   KUBECONFIG=<Dateiname> kubectl config set-context default-system --cluster default-cluster --user <Anmeldeinfo-Name>
   KUBECONFIG=<Dateiname> kubectl config use-context default-system
   

Diese Dateien werden wie folgt verwendet:

Beispielhafte vollständige Pfade zu den Dateien aus der obigen Tabelle:

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf