Najlepsze rozwiązania dotyczące wdrażania i niezawodności klastra dla usługi Azure Kubernetes Service (AKS)

Ten artykuł zawiera najlepsze rozwiązania dotyczące niezawodności klastra zaimplementowane zarówno na poziomie wdrożenia, jak i klastra dla obciążeń usługi Azure Kubernetes Service (AKS). Ten artykuł jest przeznaczony dla operatorów klastrów i deweloperów, którzy są odpowiedzialni za wdrażanie aplikacji i zarządzanie nimi w usłudze AKS.

Najlepsze rozwiązania opisane w tym artykule są zorganizowane w następujące kategorie:

Najlepsze rozwiązania dotyczące poziomu wdrożenia

Poniższe najlepsze rozwiązania dotyczące poziomu wdrożenia pomagają zapewnić wysoką dostępność i niezawodność obciążeń usługi AKS. Najlepsze praktyki to konfiguracje lokalne, które można zaimplementować w plikach YAML dla zasobników (pods) i wdrożeń.

Limity procesora i pamięci podu

Wskazówki dotyczące najlepszych rozwiązań

Ustaw limity procesora i pamięci dla wszystkich podów, aby upewnić się, że nie zużywają one wszystkich zasobów na węźle i chronić podczas zagrożeń, takich jak ataki DDoS.

Limity CPU i pamięci definiują maksymalną ilość CPU i pamięci, z których może korzystać pod. Gdy zasobnik przekroczy zdefiniowane limity, zostanie oznaczony do usunięcia. Aby uzyskać więcej informacji, zobacz jednostki zasobów procesora CPU w Kubernetes i jednostki zasobów pamięci w Kubernetes.

Ustawienie limitów procesora i pamięci pomaga zachować zdrowie węzła i zminimalizować wpływ na inne pody. Unikaj ustawiania limitu dla podów wyższego niż mogą obsłużyć węzły. Każdy węzeł usługi AKS rezerwuje pewną ilość procesora CPU i pamięci dla podstawowych składników Kubernetes. Jeśli ustawisz limit zasobnika wyższy niż węzeł może obsługiwać, aplikacja może próbować zużywać zbyt wiele zasobów i negatywnie wpływać na inne zasobniki w węźle. Administratorzy klastra muszą ustawić limity przydziału zasobów w przestrzeni nazw, która wymaga ustawienia żądań zasobów i limitów. Aby uzyskać więcej informacji, zobacz Wymuszanie przydziałów zasobów w usłudze AKS.

W poniższym przykładowym pliku definicji zkładki sekcja resources ustawia limity CPU i pamięci dla zakładki.

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

Aby uzyskać więcej informacji, zobacz Przypisywanie zasobów procesora CPU do kontenerów i zasobników oraz Przypisywanie zasobów pamięci do kontenerów i zasobników.

Autoskalator pionowych zasobników (VPA)

Wskazówki dotyczące najlepszych rozwiązań

Użyj narzędzia Vertical Pod Autoscaler (VPA), aby automatycznie dostosować żądania CPU i pamięci dla podów na podstawie ich rzeczywistego użycia.

Chociaż nie zaimplementowano bezpośrednio za pomocą pliku YAML zasobnika, narzędzie Vertical Pod Autoscaler (VPA) pomaga zoptymalizować alokację zasobów przez automatyczne dostosowanie żądań procesora CPU i pamięci dla zasobników. Dzięki temu aplikacje mają zasoby potrzebne do wydajnego działania bez nadmiernego lub niedostatecznego przydzielania zasobów.

VpA działa w trzech trybach:

• Wyłączone: udostępnia tylko zalecenia bez stosowania zmian.
• Auto: Automatycznie aktualizuje żądania zasobów dla podu podczas jego ponownego uruchamiania.
• Początkowe: ustawia żądania zasobów tylko podczas tworzenia podu.

W poniższym przykładzie pokazano, jak skonfigurować zasób VPA na platformie Kubernetes:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-deployment
  updatePolicy:
    updateMode: "Auto" # Options: Off, Auto, Initial

Aby uzyskać więcej informacji, zobacz dokumentację narzędzia Vertical Pod Autoscaler.

Budżety zakłóceń zasobników (PDB)

Wskazówki dotyczące najlepszych rozwiązań

Użyj budżetów zakłóceń zasobników (PDB), aby upewnić się, że minimalna liczba zasobników pozostaje dostępna podczas dobrowolnych zakłóceń, takich jak operacje uaktualniania lub przypadkowe usunięcie zasobników.

Budżety zakłóceń zasobników (PDB) umożliwiają zdefiniowanie sposobu reagowania wdrożeń lub zestawów replik podczas dobrowolnych zakłóceń, takich jak operacje uaktualniania lub przypadkowe usunięcie zasobników. Za pomocą plików PDB można zdefiniować minimalną lub maksymalną liczbę niedostępnych zasobów. Pliki PDB wpływają tylko na interfejs API eksmisji w przypadku dobrowolnych zakłóceń.

Załóżmy na przykład, że musisz przeprowadzić uaktualnienie klastra i mieć już zdefiniowany plik PDB. Przed przeprowadzeniem uaktualnienia klastra harmonogram Kubernetes gwarantuje, że minimalna liczba zasobników zdefiniowanych w pliku PDB jest dostępna. Jeśli uaktualnienie spowoduje, że liczba dostępnych zasobników spadnie poniżej minimum zdefiniowanego w plikach PDB, harmonogram harmonogramuje dodatkowe zasobniki na innych węzłach przed zezwoleniem na kontynuowanie uaktualniania. Jeśli nie ustawisz pliku PDB, harmonogram nie ma żadnych ograniczeń dotyczących liczby zasobników, które mogą być niedostępne podczas uaktualniania, co może prowadzić do braku zasobów i potencjalnych awarii klastra.

W poniższym przykładowym pliku definicji PDB pole minAvailable określa minimalną liczbę zasobników, które muszą pozostać dostępne w trakcie dobrowolnych zakłóceń. Wartość może być liczbą bezwzględną (na przykład 3) lub procentem żądanej liczby zasobników (na przykład 10%).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

Aby uzyskać więcej informacji, zobacz Planowanie dostępności przy użyciu plików PDB i Określanie budżetu zakłóceń dla aplikacji.

Łagodne zakończenie dla zasobników

Wskazówki dotyczące najlepszych rozwiązań

Skorzystaj z haczyków PreStop i skonfiguruj odpowiednią wartość terminationGracePeriodSeconds, aby upewnić się, że pody są łagodnie zakończone.

Łagodne zakończenie gwarantuje, że pody mają wystarczająco dużo czasu na oczyszczenie zasobów, ukończenie bieżących zadań lub powiadomienie usług zależnych przed zakończeniem działania. Jest to szczególnie ważne w przypadku stanowych aplikacji lub usług, które wymagają odpowiednich procedur zamykania.

Korzystanie z PreStop hooków

Hook PreStop jest wywoływany bezpośrednio przed zakończeniem kontenera z powodu żądania API lub zdarzenia zarządzania, takiego jak wywłaszczanie, rywalizacja o zasoby, lub niepowodzenie sondy liveness/startup. Hook PreStop pozwala na zdefiniowanie niestandardowych poleceń lub skryptów do wykonania przed zatrzymaniem kontenera. Można na przykład użyć go do opróżniania dzienników, zamykania połączeń z bazą danych lub powiadamiania innych usług o zamknięciu.

Poniższy przykładowy plik definicji zasobnika pokazuje, jak używać haka PreStop w celu zapewnienia bezproblemowego zakończenia kontenera.

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

Konfigurowanie terminationGracePeriodSeconds

Pole terminationGracePeriodSeconds określa czas oczekiwania platformy Kubernetes przed wymuszonym kończeniem zasobnika. Ten okres obejmuje czas potrzebny na wykonanie haka PreStop . PreStop Jeśli hak nie zostanie ukończony w okresie prolongaty, zasobnik zostanie wymuszono zakończony.

Na przykład poniższa definicja zasobnika ustawia okres prolongaty zakończenia na 30 sekund:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: example-container
    image: nginx

Aby uzyskać więcej informacji, zobacz Hooki cyklu życia kontenera i Zakończenie działania zasobników.

Wysoka dostępność podczas uaktualniania

Używanie maxSurge dla szybszych aktualizacji

Wskazówki dotyczące najlepszych rozwiązań

Skonfiguruj pole maxSurge aby umożliwić tworzenie dodatkowych zasobników podczas aktualizacji rolowych, co pozwoli na szybsze aktualizacje z minimalnymi przestojami.

Pole maxSurge określa maksymalną liczbę dodatkowych zasobników, które można utworzyć poza żądaną liczbą zasobników podczas aktualizacji stopniowej. Dzięki temu nowe zasobniki mogą być tworzone i gotowe przed zakończeniem działania starych zasobników, zapewniając szybsze aktualizacje i zmniejszając ryzyko przestoju.

W poniższym przykładowym manifeście wdrożenia pokazano, jak skonfigurować program maxSurge:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 33% # Maximum number of additional pods created during the update

Po ustawieniu maxSurge wartości 3 ta konfiguracja gwarantuje, że podczas aktualizacji stopniowej można utworzyć maksymalnie trzy dodatkowe zasobniki, przyspieszając proces wdrażania przy zachowaniu dostępności aplikacji. Aby uzyskać więcej informacji, zobacz Rolling Updates in Kubernetes (Aktualizacje stopniowe na platformie Kubernetes).

Używanie maxUnavailable do kontrolowanych aktualizacji

Wskazówki dotyczące najlepszych rozwiązań

Skonfiguruj pole maxUnavailable, aby ograniczyć liczbę zasobników, które mogą być niedostępne podczas aktualizacji przeprowadzanych stopniowo, zapewniając, że aplikacja pozostaje operacyjna z minimalnymi zakłóceniami.

Pole maxUnavailable jest szczególnie przydatne w przypadku aplikacji wymagających intensywnych obliczeń lub potrzeb związanych z konkretną infrastrukturą. Określa maksymalną liczbę zasobników, które mogą być niedostępne w danym momencie podczas aktualizacji stopniowej. Gwarantuje to, że część aplikacji pozostanie funkcjonalna podczas wdrażania nowych podów, a stare zostaną usunięte.

Można ustawić maxUnavailable jako liczbę bezwzględną (np 1. ) lub wartość procentową żądanej liczby zasobników (np. 25%). Jeśli na przykład aplikacja ma cztery repliki i wartości maxUnavailable ustawione są na 1, platforma Kubernetes gwarantuje, że co najmniej trzy pody pozostaną dostępne podczas procesu aktualizacji.

W poniższym przykładowym manifeście wdrożenia pokazano, jak skonfigurować program maxUnavailable:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Maximum number of pods that can be unavailable during the update

W tym przykładzie ustawienie maxUnavailable na 1 zapewnia, że podczas aktualizacji stopniowej w jednym momencie niedostępny będzie nie więcej niż jeden pod. Ta konfiguracja jest idealna w przypadku aplikacji wymagających wyspecjalizowanych zasobów obliczeniowych, w przypadku których utrzymanie minimalnego poziomu dostępności usług ma kluczowe znaczenie.

Aby uzyskać więcej informacji, zobacz Rolling Updates in Kubernetes (Aktualizacje stopniowe na platformie Kubernetes).

Ograniczenia rozmieszczenia topologii podów

Wskazówki dotyczące najlepszych rozwiązań

Użyj ograniczeń rozprzestrzeniania się topologii zasobników, aby upewnić się, że zasobniki są rozmieszczone w różnych węzłach lub strefach w celu zwiększenia dostępności i niezawodności.

Za pomocą ograniczeń rozprzestrzeniania topologii zasobników można kontrolować rozmieszczenie zasobników w klastrze w oparciu o topologię węzłów i rozmieszczać zasobniki w różnych węzłach lub strefach w celu zwiększenia dostępności i niezawodności.

Poniższy przykładowy plik definicji zasobnika pokazuje, jak używać topologySpreadConstraints pola do rozmieszczania zasobników w różnych węzłach:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

Aby uzyskać więcej informacji, zobacz Ograniczenia rozprzestrzeniania topologii podów.

Gotowość, żywość i sondy uruchamiania

Wskazówki dotyczące najlepszych rozwiązań

Skonfiguruj sondy gotowości, żywotności i uruchamiania, jeśli ma to zastosowanie, aby zwiększyć odporność na duże obciążenia i zmniejszyć liczbę ponownych uruchomień kontenerów.

Sondy gotowości

Na platformie Kubernetes narzędzie kubelet używa sond gotowości, aby wiedzieć, kiedy kontener jest gotowy do rozpoczęcia akceptowania ruchu. Pod jest uważany za gotowy, gdy wszystkie jego kontenery są gotowe. Gdy zasobnik nie jest gotowy, zostanie usunięty z modułów równoważenia obciążenia usługi. Aby uzyskać więcej informacji, zobacz Readiness Probes in Kubernetes (Sondy gotowości na platformie Kubernetes).

Poniższy przykładowy plik definicji podu przedstawia konfigurację sondy gotowości.

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Aby uzyskać więcej informacji, zobacz Konfiguracja sond gotowości.

Sondy sprawdzania dostępności

Na platformie Kubernetes narzędzie kubelet używa sond liveness, aby wiedzieć, kiedy ponownie uruchomić kontener. Jeśli kontener nie przejdzie sondy żywotności, zostanie uruchomiony ponownie. Aby uzyskać więcej informacji, zobacz Liveness Probes in Kubernetes (Sondy na żywo na platformie Kubernetes).

Poniższy plik definicji przykładowego podu przedstawia konfigurację sondy *liveness*:

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

Inny rodzaj sondy sprawdzania żywotności używa żądania HTTP GET. Poniższy przykładowy plik definicji zasobnika przedstawia konfigurację sondy dostępności dla żądania HTTP GET:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Aby uzyskać więcej informacji, zobacz Konfigurowanie sond aktywności i Definiowanie żądania HTTP dotyczącego aktywności.

Testy/początkowe sondy uruchamiania

Na platformie Kubernetes narzędzie kubelet używa sond startowych, aby wiedzieć, kiedy aplikacja kontenera została uruchomiona. Podczas konfigurowania sondy uruchomieniowej, sondy gotowości i żywotności nie są uruchamiane, dopóki sonda uruchomieniowa nie zakończy się pomyślnie, co zapewnia, że sondy gotowości i żywotności nie zakłócają uruchamiania aplikacji. Aby uzyskać więcej informacji, zobacz Sondy uruchamiania na platformie Kubernetes.

Poniższy przykładowy plik definicji poda przedstawia konfigurację sondy uruchamiania.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Aplikacje z wieloma replikami

Wskazówki dotyczące najlepszych rozwiązań

Wdróż co najmniej dwie repliki aplikacji, aby zapewnić wysoką dostępność i odporność w przypadku awarii węzłów.

Na platformie Kubernetes możesz użyć pola we wdrożeniu replicas , aby określić liczbę zasobników, które chcesz uruchomić. Instalowanie wielu instancji aplikacji zapewnia wysoką dostępność i odporność w przypadkach awarii węzła. Jeśli masz strefy dostępności włączone, możesz użyć replicas pola, aby określić liczbę podów, które mają być uruchamiane w wielu strefach dostępności.

Poniższy przykładowy plik definicji zasobnika pokazuje, jak za pomocą replicas pola określić liczbę zasobników, które chcesz uruchomić:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Aby uzyskać więcej informacji, zobacz Zalecane rozwiązanie o wysokiej dostępności aktywne-aktywne — omówienie usługi AKS i Repliki w specyfikacjach wdrożenia.

Najlepsze praktyki na poziomie klastrów i pul węzłów

Poniższe najlepsze rozwiązania dotyczące poziomu klastra i puli węzłów pomagają zapewnić wysoką dostępność i niezawodność klastrów usługi AKS. Te najlepsze rozwiązania można zaimplementować podczas tworzenia lub aktualizowania klastrów usługi AKS.

Strefy dostępności

Wskazówki dotyczące najlepszych rozwiązań

Użyj wielu stref dostępności podczas tworzenia klastra AKS, aby zapewnić wysoką dostępność w przypadku awarii strefy. Pamiętaj, że nie można zmienić konfiguracji strefy dostępności po utworzeniu klastra.

Strefy dostępności są oddzielnymi grupami centrów danych w obrębie regionu. Te strefy są wystarczająco blisko, aby mieć ze sobą połączenia o małych opóźnieniach, ale wystarczająco daleko od siebie, aby zmniejszyć prawdopodobieństwo, że więcej niż jedna strefa ma wpływ na lokalne awarie lub pogodę. Korzystanie ze stref dostępności pomaga utrzymać dane zsynchronizowane i dostępne w przypadku awarii strefy. Aby uzyskać więcej informacji, zobacz Uruchamianie w wielu strefach.

Skalowanie automatyczne klastra

Wskazówki dotyczące najlepszych rozwiązań

Użyj skalowania automatycznego klastra, aby upewnić się, że klaster może obsłużyć zwiększone obciążenie i zmniejszyć koszty podczas niskiego obciążenia.

Aby nadążyć za wymaganiami aplikacji w usłudze AKS, może być konieczne dostosowanie liczby węzłów, które uruchamiają twoje obciążenia. Składnik automatycznego skalowania klastra obserwuje zasobniki w klastrze, których nie można zaplanować z powodu ograniczeń zasobów. Gdy narzędzie do automatycznego skalowania klastra wykryje problemy, skaluje w górę liczbę węzłów w puli węzłów, aby zaspokoić zapotrzebowanie aplikacji. Regularnie sprawdza również węzły pod kątem braku uruchomionych zasobników i skaluje w dół liczbę węzłów zgodnie z potrzebami. Aby uzyskać więcej informacji, zobacz Skalowanie automatyczne klastra w usłudze AKS.

Parametru --enable-cluster-autoscaler można użyć podczas tworzenia klastra usługi AKS w celu włączenia narzędzia do automatycznego skalowania klastra, jak pokazano w poniższym przykładzie:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

Możesz również włączyć narzędzie do automatycznego skalowania klastra w istniejącej puli węzłów i skonfigurować bardziej szczegółowe szczegóły autoskalatora klastra, zmieniając wartości domyślne w profilu automatycznego skalowania w całym klastrze.

Aby uzyskać więcej informacji, zobacz Używanie narzędzia do automatycznego skalowania klastra w usłudze AKS.

Standardowy Load Balancer

Wskazówki dotyczące najlepszych rozwiązań

Użyj usługi Load Balancer warstwy Standardowej, aby zapewnić większą niezawodność i zasoby, obsługę wielu stref dostępności, sondy HTTP i funkcjonalność w wielu centrach danych.

Na platformie Azure SKU Standardowy Load Balancer została zaprojektowana do równoważenia obciążenia w warstwie sieciowej, gdy wymagana jest wysoka wydajność i niskie opóźnienie. Standardowa usługa Load Balancer kieruje ruch wewnątrz i pomiędzy regionami oraz do stref dostępności w celu zwiększenia odporności. Jednostka SKU Standard to zalecana i domyślna opcja podczas tworzenia klastra AKS.

W poniższym przykładzie pokazano LoadBalancer manifest usługi, który używa Standardowego Load Balancer:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

Aby uzyskać więcej informacji, zobacz Używanie standardowego modułu równoważenia obciążenia w usłudze AKS.

Pule węzłów systemu

Korzystanie z dedykowanych pul węzłów systemowych

Wskazówki dotyczące najlepszych rozwiązań

Użyj pul węzłów systemowych, aby upewnić się, że żadne inne aplikacje użytkownika nie działają w tych samych węzłach, co może powodować niedobór zasobów i wpływać na zasobniki systemowe.

Użyj dedykowanych pul węzłów systemowych, aby upewnić się, że żadna inna aplikacja użytkownika nie działa w tych samych węzłach, co może powodować niedobór zasobów i potencjalne awarie klastra z powodu warunków wyścigu. Aby użyć dedykowanej puli węzłów systemowych, można użyć defektu CriticalAddonsOnly w puli węzłów systemowych. Aby uzyskać więcej informacji, zobacz Używanie pul węzłów systemowych w usłudze AKS.

Skalowanie automatyczne dla pul węzłów systemowych

Wskazówki dotyczące najlepszych rozwiązań

Skonfiguruj narzędzie do automatycznego skalowania dla pul węzłów systemowych, aby ustawić minimalne i maksymalne limity skalowania dla puli węzłów.

Użyj narzędzia do automatycznego skalowania w pulach węzłów, aby skonfigurować minimalne i maksymalne limity skalowania dla puli węzłów. Pula węzłów systemowych powinna zawsze mieć możliwość skalowania w celu spełnienia wymagań zasobników systemowych. Jeśli pula węzłów systemowych nie może się skalować, klaster traci zasoby potrzebne do zarządzania planowaniem, skalowaniem i równoważeniem obciążenia, co może skutkować brakiem reakcji klastra.

Aby uzyskać więcej informacji, zobacz Używanie narzędzia do automatycznego skalowania klastra w pulach węzłów.

Co najmniej dwa węzły na pulę węzłów systemowych

Wskazówki dotyczące najlepszych rozwiązań

Upewnij się, że pule węzłów systemowych mają co najmniej dwa węzły, aby zapewnić odporność na scenariusze zamrażania/aktualizacji, co może prowadzić do ponownego uruchomienia lub zamknięcia węzłów.

Pule węzłów systemowych służą do uruchamiania zasobników systemowych, takich jak kube-proxy, coredns i wtyczka azure CNI. Zalecamy upewnienie się, że pule węzłów systemowych mają co najmniej dwa węzły , aby zapewnić odporność na scenariusze blokowania/uaktualniania, co może prowadzić do ponownego uruchomienia lub zamknięcia węzłów. Aby uzyskać więcej informacji, zobacz Zarządzanie pulami węzłów systemowych w usłudze AKS.

Aktualizacja konfiguracji pól węzłów

Używanie maxSurge do aktualizacji puli węzłów

Wskazówki dotyczące najlepszych rozwiązań

maxSurge Skonfiguruj ustawienie uaktualnień puli węzłów, aby zwiększyć niezawodność i zminimalizować przestoje podczas operacji uaktualniania.

Ustawienie maxSurge określa maksymalną liczbę dodatkowych węzłów, które można utworzyć podczas uaktualniania. Dzięki temu nowe węzły są aprowidowane i gotowe, zanim stare węzły zostaną opróżnione i usunięte, co zmniejsza ryzyko przestoju aplikacji.

Na przykład następujące polecenie interfejsu wiersza polecenia platformy Azure ustawia wartość maxSurge 1 dla puli węzłów:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-surge 1

Konfigurując maxSurge, można zapewnić szybsze wykonywanie aktualizacji, utrzymując dostępność aplikacji.

Aby uzyskać więcej informacji, odwiedź Uaktualnianie pul węzłów w AKS.

Używanie maxUnavailable do aktualizacji puli węzłów

Wskazówki dotyczące najlepszych rozwiązań

maxUnavailable Skonfiguruj ustawienie uaktualnień puli węzłów, aby zapewnić dostępność aplikacji podczas operacji uaktualniania.

Ustawienie maxUnavailable określa maksymalną liczbę węzłów, które mogą być niedostępne podczas uaktualniania. Gwarantuje to, że część puli węzłów pozostaje operacyjna podczas uaktualniania węzłów.

Na przykład następujące polecenie interfejsu wiersza polecenia platformy Azure ustawia wartość maxUnavailable 1 dla puli węzłów:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-unavailable 1

Konfigurując maxUnavailable, można kontrolować wpływ aktualizacji na pracę, zapewniając, że wystarczające zasoby pozostaną dostępne podczas procesu.

Aby uzyskać więcej informacji, zapoznaj się z Uaktualnianie pul węzłów w usłudze AKS.

Wskazówki dotyczące najlepszych rozwiązań

Użyj przyspieszonej sieci, aby zapewnić mniejsze opóźnienia, mniejsze zakłócenia i mniejsze wykorzystanie procesora CPU na maszynach wirtualnych.

Przyspieszone sieciowanie umożliwia wirtualizację we/wy single root (SR-IOV) na obsługiwanych typach maszyn wirtualnych, znacznie poprawiając wydajność sieci.

Na poniższym diagramie pokazano, jak dwie maszyny wirtualne komunikują się z przyspieszoną siecią i bez:

Aby uzyskać więcej informacji, zobacz Omówienie przyspieszonej sieci.

Wersje obrazów

Wskazówki dotyczące najlepszych rozwiązań

Obrazy nie powinny używać tagu latest .

Tagi obrazu kontenera

Użycie tagu latest dla obrazów kontenerowych może prowadzić do nieprzewidywalnego zachowania i utrudnia to śledzenie wersji obrazu uruchomionej w klastrze. Te zagrożenia można zminimalizować, integrując i uruchamiając narzędzia do skanowania i korygowania w kontenerach w środowisku kompilacji i środowiska uruchomieniowego. Aby uzyskać więcej informacji, zobacz Najlepsze praktyki zarządzania obrazami kontenerów w AKS.

Aktualizacje obrazu węzła

Usługa AKS udostępnia wiele kanałów automatycznej aktualizacji obrazów systemu operacyjnego węzłów. Możesz użyć tych kanałów do kontrolowania harmonogramu uaktualnień. Zalecamy dołączenie tych kanałów automatycznego uaktualniania, aby upewnić się, że węzły korzystają z najnowszych poprawek zabezpieczeń i aktualizacji. Aby uzyskać więcej informacji, zobacz Automatyczne uaktualnianie obrazów systemu operacyjnego węzła w usłudze AKS.

poziom standardowy dla obciążeń produkcyjnych

Wskazówki dotyczące najlepszych rozwiązań

Użyj warstwy standardowej dla obciążeń produktu, aby uzyskać większą niezawodność i zasoby klastra, obsługując maksymalnie 5000 węzłów w klastrze, a umowa SLA zapewniająca czas działania jest włączona domyślnie. Jeśli potrzebujesz LTS, rozważ użycie poziomu Premium.

Warstwa Standardowa dla usługi Azure Kubernetes Service (AKS) gwarantuje 99,9% czasu pracy z finansowym wsparciem w ramach umowy o poziomie usług (SLA) dla obciążeń produkcyjnych. Warstwa standardowa zapewnia również większą niezawodność i zasoby klastra, obsługę maksymalnie 5000 węzłów w klastrze, a także domyślnie włączoną umowę SLA czasu dostępności. Aby uzyskać więcej informacji, zobacz Warstwy cenowe zarządzania klastrem AKS.

Azure CNI na potrzeby dynamicznej alokacji adresów IP

Wskazówki dotyczące najlepszych rozwiązań

Konfigurowanie sieci CNI platformy Azure na potrzeby dynamicznej alokacji adresów IP w celu lepszego wykorzystania adresów IP i zapobiegania wyczerpaniu adresów IP dla klastrów usługi AKS.

Funkcja dynamicznej alokacji adresów IP w usłudze Azure CNI przydziela adresy IP zasobników z podsieci niezależnie od podsieci hostowania klastra usługi AKS i oferuje następujące korzyści:

• Lepsze wykorzystanie adresów IP: adresy IP są dynamicznie przydzielane do Podów klastra z podsieci Podów. Prowadzi to do lepszego wykorzystania adresów IP w klastrze w porównaniu z tradycyjnym rozwiązaniem CNI, które wykonuje statyczną alokację adresów IP dla każdego węzła.
• Skalowalne i elastyczne: podsieci węzłów i podów mogą być skalowane niezależnie. Pojedyncza podsieć podów może być współdzielona w wielu pulach węzłów klastra lub w wielu klastrach AKS wdrożonych w tej samej sieci wirtualnej. Można również skonfigurować oddzielną podsieć podów dla puli węzłów.
• Wysoka wydajność: ponieważ pody mają przypisane adresy IP sieci wirtualnej, mają bezpośrednią łączność z innymi podami klastra i zasobami w VNet. Rozwiązanie obsługuje bardzo duże klastry bez spadku wydajności.
• Oddzielne zasady sieci wirtualnej dla zasobników: ponieważ zasobniki mają oddzielną podsieć, można skonfigurować oddzielne zasady sieci wirtualnej dla nich, które różnią się od zasad węzłów. Umożliwia to wiele przydatnych scenariuszy, takich jak zezwolenie na łączność z Internetem tylko dla podów, a nie dla węzłów, przypisanie źródłowego adresu IP dla poda w puli węzłów przy użyciu Azure NAT Gateway oraz filtrowanie ruchu między pulami węzłów za pomocą grup zabezpieczeń sieci.
• Zasady sieciowe platformy Kubernetes: zarówno zasady sieci platformy Azure, jak i Calico współpracują z tym rozwiązaniem.

Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci CNI platformy Azure na potrzeby dynamicznej alokacji adresów IP i rozszerzonej obsługi podsieci.

Maszyny wirtualne SKU v5

Wskazówki dotyczące najlepszych rozwiązań

Użyj jednostek SKU maszyn wirtualnych w wersji 5 w celu zwiększenia wydajności podczas aktualizacji i po nich, mniejszego ogólnego wpływu i bardziej niezawodnego połączenia dla aplikacji.

W przypadku pul węzłów w usłudze AKS użyj maszyn wirtualnych SKU v5 z efemerycznymi dyskami systemu operacyjnego, aby zapewnić wystarczające zasoby obliczeniowe dla zasobników kube-system. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące wydajności i skalowania dużych obciążeń w usłudze AKS.

Nie używaj maszyn wirtualnych serii B

Wskazówki dotyczące najlepszych rozwiązań

Nie używaj maszyn wirtualnych serii B dla klastrów AKS, ponieważ mają niską wydajność i nie działają dobrze z AKS.

Maszyny wirtualne serii B mają niską wydajność i nie działają dobrze z usługą AKS. Zamiast tego zalecamy używanie v5 SKU VMs.

Dyski w wersji Premium

Wskazówki dotyczące najlepszych rozwiązań

Użyj dysków w warstwie Premium, aby uzyskać dostępność na 99,9% na jednej maszynie wirtualnej.

Azure Premium Disks oferują spójne opóźnienie dysku poniżej jednej milisekundy oraz wysoką liczbę operacji we/wy na sekundę i przepustowość. Dyski w warstwie Premium zostały zaprojektowane w celu zapewnienia małych opóźnień, wysokiej wydajności i spójnej wydajności dysków dla maszyn wirtualnych.

Poniższy przykładowy manifest YAML przedstawia definicję klasy magazynu dla dysku premium.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Aby uzyskać więcej informacji, zobacz Używanie dysków SSD Premium v2 platformy Azure w usłudze AKS.

Szczegółowe informacje o kontenerze

Wskazówki dotyczące najlepszych rozwiązań

Włącz usługę Container Insights, aby monitorować i diagnozować wydajność aplikacji konteneryzowanych.

Container Insights to funkcja usługi Azure Monitor, która zbiera i analizuje dzienniki kontenerów z usługi AKS. Zebrane dane można analizować przy użyciu kolekcji widoków i wstępnie utworzonych skoroszytów.

Monitorowanie usługi Container Insights w klastrze usługi AKS można włączyć przy użyciu różnych metod. W poniższym przykładzie pokazano, jak włączyć monitorowanie usługi Container Insights w istniejącym klastrze przy użyciu interfejsu wiersza polecenia platformy Azure:

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

Aby uzyskać więcej informacji, zobacz Włączanie monitorowania dla klastrów Kubernetes.

Azure Policy

Wskazówki dotyczące najlepszych rozwiązań

Stosowanie i wymuszanie wymagań dotyczących zabezpieczeń i zgodności dla klastrów usługi AKS przy użyciu usługi Azure Policy.

Za pomocą usługi Azure Policy można zastosować i wymusić wbudowane zasady zabezpieczeń w klastrach usługi AKS. Usługa Azure Policy pomaga wymuszać standardy organizacyjne i oceniać zgodność na dużą skalę. Po zainstalowaniu dodatku usługi Azure Policy dla usługi AKS można zastosować poszczególne definicje zasad lub grupy definicji zasad nazywanych inicjatywami do klastrów.

Aby uzyskać więcej informacji, zobacz Zabezpieczanie klastrów usługi AKS za pomocą usługi Azure Policy.

Następne kroki

Ten artykuł koncentruje się na najlepszych rozwiązaniach dotyczących wdrażania i niezawodności klastra dla klastrów usługi Azure Kubernetes Service (AKS). Aby uzyskać więcej najlepszych rozwiązań, zobacz następujące artykuły:

• Omówienie wysokiej dostępności i odzyskiwania po awarii dla usługi AKS
• Uruchamianie klastrów usługi AKS na dużą skalę
• Architektura linii bazowej dla klastra usługi AKS