Zarządzanie zasobnikami w klastrach Kubernetes z wieloma pulami
Deweloperzy firmy Contoso pracują nad przekształcaniem wewnętrznie opracowanych aplikacji systemu Windows i Linux w obrazy oparte na platformie Docker, które można wdrożyć przy użyciu pakietów Helm. W ramach planowania wdrażania klastrów Kubernetes w usłudze Azure Stack HCI należy zapewnić obsługę obu platform systemu operacyjnego.
Co to są pule węzłów w klastrach Kubernetes w usłudze Azure Stack HCI
Usługa AKS w usłudze Azure Stack HCI obsługuje wiele pul węzłów w tym samym klastrze Kubernetes. Każda pula składa się z identycznych skonfigurowanych maszyn wirtualnych zgodnie z ustawieniami określonymi podczas aprowizacji tej puli.
Grupując węzły w oddzielne pule, można kierować wdrożenia zasobników do odpowiedniego zestawu maszyn wirtualnych. Na przykład mogą istnieć konteneryzowane obciążenia, które są obsługiwane tylko przez system operacyjny Windows lub wymagają wyspecjalizowanego sprzętu, takiego jak jednostki procesora graficznego.
Kontrolowanie wdrażania zasobników w pulach węzłów w klastrach Kubernetes w usłudze Azure Stack HCI
Domyślnie platforma Kubernetes planuje aprowizowanie konteneryzowanych obciążeń na wszystkich dostępnych węzłach roboczych w sposób optymalizujący wykorzystanie zasobów. Aby zmienić to zachowanie, można zastosować ograniczenia dotyczące wyboru węzłów na podstawie kryteriów niestandardowych, które określisz. Te ograniczenia obejmują selektory węzłów i defekty oraz tolerancje.
Selektory węzłów
Selektor węzłów to ustawienie w definicji opartej na języku YAML zasobnika lub wdrożenia, które identyfikuje węzły docelowe, na których można zaplanować odpowiedni zasobnik. Jeśli twoim zamiarem jest wyznaczenie węzłów docelowych na podstawie ich systemu operacyjnego, możesz opierać się na wbudowanych etykietach automatycznie przypisanych do węzłów przez platformę Kubernetes. W zależności od zamierzonego systemu operacyjnego selektor węzłów będzie miał postać kubernetes.io/os = Windows lub kubernetes.io/os = Linux. Na przykład następujący manifest zasobnika oparty na języku YAML wyznacza węzły systemu Linux jako cele wdrożenia:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
kubernetes.io/os = Linux
Taints i tolerancje
Taints i tolerancje zapewniają alternatywne podejście do kontrolowania umieszczania zasobników. W przypadku tego podejścia defekty są częścią konfiguracji węzła, a tolerancje są częścią specyfikacji zasobnika. Dzięki skażoniu węzła można skutecznie zapobiec hostowaniu dowolnego zasobnika bez odpowiedniego tolerancji specyficznego dla tego parametru.
Na przykład w usłudze AKS w usłudze Azure Stack HCI, jeśli chcesz zezwolić na zaplanowanie zasobnika w węźle systemu Windows, dodaj następującą tolerancję do jego definicji:
tolerations:
- key: node.kubernetes.io/os
operator: Equal
value: Windows
effect: NoSchedule
Ponadto należy dodać defekt node.kubernetes.io/os=Windows:NoSchedule do każdego z węzłów systemu Windows, które mają być dostępne wyłącznie na potrzeby wdrażania zasobników z odpowiednią tolerancją. W tym celu można użyć narzędzia wiersza polecenia kubectl, a następnie po nawiązaniu połączenia z klastrem docelowym uruchom następujące polecenie dla każdego węzła w zakresie (gdzie <node_name> symbol zastępczy wyznacza nazwę węzła docelowego):
kubectl taint node <node_name> node.kubernetes.io/os=Windows:NoSchedule
Uwaga
Selektory węzłów wymuszają umieszczanie zasobników w określonym zestawie węzłów. Tolerancje umożliwiają uruchamianie zasobników w wyznaczonym zestawie skażonych węzłów, ale nie zapobiega ich umieszczaniu w węzłach bez defektów.