Verwalten von Pods in Kubernetes-Clustern mit mehreren Pools
Contoso-Entwickler arbeiten daran, intern entwickelte Windows- und Linux-Anwendungen in Docker-basierte Images zu transformieren, die mit Helm-Charts bereitgestellt werden können. Bei der Planung der Implementierung von Kubernetes-Clustern in Azure Stack HCI müssen Sie die Unterstützung beider Betriebssystemplattformen sicherstellen.
Was sind Knotenpools in Kubernetes-Clustern in Azure Stack HCI?
AKS in Azure Stack HCI unterstützt mehrere Knotenpools im selben Kubernetes-Cluster. Jeder Pool besteht aus identisch konfigurierten VMs gemäß den Einstellungen, die Sie bei der Bereitstellung dieses Pools angeben.
Indem Sie Knoten in separaten Pools gruppieren, können Sie Podbereitstellungen auf die geeignete Gruppe von VMs ausrichten. Angenommen, Sie verfügen über Containerworkloads, die nur vom Windows-Betriebssystem unterstützt werden oder spezielle Hardware erfordern, z. B. Grafikprozessoreinheiten.
Steuern der Bereitstellung von Pods in Knotenpools in Kubernetes-Clustern in Azure Stack HCI
Standardmäßig plant Kubernetes, Containerworkloads auf allen verfügbaren Workerknoten so bereitzustellen, dass die Ressourcennutzung optimiert wird. Um dieses Verhalten zu ändern, können Sie Einschränkungen auf die Auswahl von Knoten auf Basis von benutzerdefinierten Kriterien anwenden, die Sie angeben. Zu diesen Einschränkungen gehören Knotenauswahlen sowie Taints und Toleranzen.
Knotenselektoren
Die Knotenauswahl ist eine Einstellung innerhalb der YAML-basierten Definition eines Pods oder einer Bereitstellung, die die Zielknoten identifiziert, auf denen der entsprechende Pod geplant werden kann. Wenn Sie Zielknoten auf ihrem Betriebssystem basierend festlegen möchten, können Sie sich auf die integrierten Bezeichnungen verlassen, die Knoten automatisch von Kubernetes zugewiesen werden. Abhängig vom vorgesehenen Betriebssystem hat die Knotenauswahl die Form kubernetes.io/os = Windows
oder kubernetes.io/os = Linux
. Im folgenden YAML-basierten Podmanifest werden beispielsweise Linux-Knoten als Bereitstellungsziele festgelegt:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
kubernetes.io/os = Linux
Taints und Toleranzen
Taints und Toleranzen stellen einen alternativen Ansatz zum Steuern der Podplatzierung dar. Bei diesem Ansatz sind Taints Teil der Knotenkonfiguration und Toleranzen Teil der Podspezifikationen. Durch das Tainting eines Knotens hindern Sie ihn effektiv daran, Pods ohne die entsprechende taint-spezifische Toleranz zu hosten.
Wenn Sie beispielsweise in AKS in Azure Stack HCI zulassen möchten, dass ein Pod in einem Windows-Knoten geplant wird, sollten Sie seiner Definition folgende Toleranz hinzufügen:
tolerations:
- key: node.kubernetes.io/os
operator: Equal
value: Windows
effect: NoSchedule
Darüber hinaus müssten Sie den Taint node.kubernetes.io/os=Windows:NoSchedule
jedem der Windows-Knoten hinzufügen, die Sie ausschließlich für die Bereitstellung von Pods mit der entsprechenden Toleranz verfügbar machen möchten. Hierzu können Sie das Befehlszeilen-Hilfsprogramm kubectl verwenden und dann nach dem Herstellen einer Verbindung mit dem Zielcluster den folgenden Befehl für jeden Knoten im Bereich ausführen (wobei der <node_name>
-Platzhalter den Namen des Zielknotens bestimmt):
kubectl taint node <node_name> node.kubernetes.io/os=Windows:NoSchedule
Hinweis
Knotenauswahlen erzwingen die Platzierung von Pods in einem bestimmten Satz von Knoten. Mit Toleranzen können Pods auf einem festgelegten Satz von Tainted-Knoten ausgeführt werden, jedoch wird ihre Platzierung auf Knoten ohne Taints nicht verhindert.