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

Dotyczy: ✔️ AKS Automatic AKS Standard ✔️

Niezawodność klastra usługi AKS odnosi się do możliwości klastra Azure Kubernetes Service do utrzymania dostępności, odzyskiwania po awariach i obsługi zakłóceń przy minimalnym przestoju. Ten artykuł zawiera najlepsze rozwiązania dotyczące niezawodności klastra zaimplementowane zarówno na poziomie wdrożenia, jak i klastra dla obciążeń 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.

Kluczowe wnioski

• Ustaw limity procesora CPU i pamięci dla wszystkich zasobników, aby zapobiec wyczerpaniu zasobów i chronić przed zagrożeniami usługi, takimi jak ataki DDoS.
• Użyj budżetów zakłóceń podów (PDB), aby zapewnić minimalną dostępność podów podczas dobrowolnych zakłóceń, takich jak aktualizacje lub przypadkowe usunięcia.
• Włącz strefy dostępności podczas tworzenia klastra, aby zapewnić wysoką dostępność w scenariuszach w dół strefy (nie można jej zmienić po utworzeniu).
• Wdróż co najmniej dwie repliki aplikacji, aby zapewnić wysoką dostępność i odporność na awarie w przypadku awarii węzła.
• Skonfiguruj sondy gotowości, aktywności i uruchamiania, aby zwiększyć odporność aplikacji i ograniczyć niepotrzebne ponowne uruchamianie kontenera.
• Użyj usługa Load Balancer w warstwie Standardowa w przypadku obciążeń produkcyjnych, ponieważ obsługuje wiele stref dostępności i wysoką odporność na awarie.
• Włącz usługę Container Insights , aby monitorować i diagnozować wydajność aplikacji konteneryzowanych.

Ten artykuł zawiera najlepsze rozwiązania dotyczące niezawodności klastra zaimplementowane zarówno na poziomie wdrożenia, jak i klastra dla obciążeń 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:

Tryby klastra AKS i niezawodność

Usługa AKS obsługuje dwa tryby klastra: AKS Automatic i AKS Standard. Wiele rozwiązań dotyczących niezawodności na poziomie obciążenia stosuje się równie do obu trybów, takich jak ustawianie żądań zasobów, definiowanie budżetów zakłóceń zasobników (PDB), konfigurowanie sond i uruchamianie wielu replik. Jednak obowiązki na poziomie klastra różnią się w zależności od trybu:

• AKS Automatic zapewnia więcej wstępnie skonfigurowanych ustawień domyślnych dotyczących niezawodności, w tym zarządzane pule węzłów systemowych, automatyczne aprowizowanie węzłów (NAP), automatyczne aktualizacje klastra, automatyczne aktualizacje obrazu systemu operacyjnego węzłów, warstwę Standard i LocalDNS.
• Usługa AKS Standard zapewnia szerszą bezpośrednią kontrolę konfiguracji i wymaga od operatorów jawnego włączania funkcji niezawodności na poziomie klastra i zarządzania nimi.

Aby uzyskać więcej informacji, zobacz Co to jest usługa AKS Automatic?

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

Lista kontrolna szybkich odwołań:

• Konfigurowanie plików PDB dla wszystkich obciążeń produkcyjnych
• Ustaw limity procesora i pamięci dla wszystkich podów
• Wdrażanie co najmniej 2 replik dla obciążeń odpornych na strefy
• Skonfiguruj sondy gotowości, żywotności i uruchamiania dla wszystkich kontenerów
• Używanie ograniczeń rozprzestrzeniania się topologii zasobników dla aplikacji krytycznych

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.

Administratorzy klastrów mogą również wzmocnić te ustawienia przy użyciu limitów przydziałów na poziomie przestrzeni nazw i mechanizmów kontroli zasad. W usłudze AKS Automatic zabezpieczenia wdrożenia mogą pomóc w wymuszaniu najlepszych rozwiązań związanych z zasobami, ale operatorzy nadal powinni jawnie definiować odpowiednie dla obciążenia żądania i limity. 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.

W usłudze AKS Automatic vpA jest domyślnie włączona w klastrze. W usłudze AKS Standard operatorzy wybierają, czy ją włączyć.

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.

Automatyzacja uaktualnień na poziomie klastra w usłudze AKS Automatic zmniejsza część obciążenia operacyjnego, ale dostępność obciążeń roboczych podczas zakłóceń nadal zależy od mechanizmów kontroli na poziomie aplikacji, takich jak mechanizmy PDB.

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.

Aby zautomatyzować tworzenie pliku PDB dla niechronionych wdrożeń i zapobiec awariom opróżniania związanych z plikiem PDB podczas uaktualniania, zobacz Automatyczne zarządzanie plikiem PDB dla usługi AKS (wersja zapoznawcza).

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

W usłudze AKS Automatic zabezpieczenia wdrożenia mogą pomóc w zastosowaniu niektórych najlepszych rozwiązań dotyczących dystrybucji obciążeń, ale wymagania topologii specyficzne dla aplikacji powinny być nadal definiowane jawnie w manifestach obciążeń.

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.

Nawet jeśli usługa AKS Automatic zapewnia podstawowe zabezpieczenia, konfiguracja sond nadal zależy od konkretnego obciążenia i powinna być definiowana w manifestach aplikacji.

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. Usługa AKS Automatic poprawia gotowość operacyjną i sposób skalowania, ale dostępność nadal zależy od uruchomienia wystarczającej liczby replik oraz zastosowania odpowiednich mechanizmów kontroli rozmieszczania. 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. W porównaniu z ustawieniami na poziomie wdrożenia odpowiedzialność różni się znacznie bardziej między AKS Automatic a AKS Standard.

Lista kontrolna szybkich odwołań:

• Włączanie stref dostępności podczas tworzenia klastra (zalecane jest 3 strefy dostępności)
• Używaj usługa Load Balancer w warstwie Standardowa we wszystkich obciążeniach produkcyjnych
• Skonfiguruj co najmniej 2 węzły w każdej puli węzłów systemowych
• Włączanie usługi Container Insights na potrzeby monitorowania
• Użyj warstwy cenowej Standard lub Premium dla środowiska produkcyjnego

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.

Usługa AKS Automatic upraszcza operacje typu dzień 2, ale nie eliminuje potrzeby planowania topologii podczas tworzenia klastra, w którym wdrożenie strefowe jest częścią projektu.

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.

Zachowanie skalowania różni się w zależności od trybu klastra:

• AKS Automatic: automatyczne aprowizowanie węzłów jest skonfigurowane fabrycznie, a funkcje skalowania obciążeń, takie jak HPA, KEDA i VPA, są domyślnie włączone.
• AKS Standard: operatorzy jawnie włączają i dostrajają autoskalowanie klastra, automatyczne aprowizowanie węzłów oraz funkcje automatycznego skalowania obciążeń.

W przypadku usługi AKS Standard można użyć parametru --enable-cluster-autoscaler podczas tworzenia klastra:

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.

Niezawodność ruchu wejściowego i wyjściowego

Wskazówki dotyczące najlepszych rozwiązań

Użyj modelu sieci klastra zgodnego z wymaganiami dotyczącymi trybu klastra i niezawodności usługi AKS.

W przypadku usługi AKS Standard usługa Load Balancer w warstwie Standardowa pozostaje typowym i zalecanym wyborem niezawodności dla scenariuszy ruchu przychodzącego i wychodzącego.

W przypadku usługi AKS Automatic wartości domyślne ruchu przychodzącego i wychodzącego są bardziej zarządzane:

• Zarządzana sieć wirtualna jest domyślnie wstępnie skonfigurowana.
• Zarządzana brama NAT jest wstępnie skonfigurowana na potrzeby obsługiwanych scenariuszy zarządzanej sieci wirtualnej.
• Zarządzany ruch przychodzący za pośrednictwem routingu aplikacji jest wstępnie skonfigurowany dla obsługiwanych wersji klastra.

Jeśli używasz usługi AKS w warstwie Standardowa, nadal obowiązują następujące wskazówki usługa Load Balancer w warstwie Standardowa:

usługa Load Balancer w warstwie Standardowa

Wskazówki dotyczące najlepszych rozwiązań

Użyj usługa Load Balancer w warstwie Standardowa, aby zapewnić większą niezawodność i zasoby, obsługę wielu stref dostępności, sond HTTP i funkcji w wielu centrach danych.

W Azure jednostka SKU usługa Load Balancer w warstwie Standardowa0 została zaprojektowana tak, aby była wyposażona w równoważenie obciążenia ruchu w warstwie sieciowej, gdy jest wymagana wysoka wydajność i małe opóźnienia. Standardowy Load Balancer przekierowuje ruch wewnątrz i pomiędzy regionami oraz do stref dostępności w celu zapewnienia wysokiej niezawodności. Jednostka SKU Standard to zalecana i domyślna opcja podczas tworzenia klastra AKS.

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

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

Usługa AKS Automatic używa zarządzanych pul węzłów systemu, które są tworzone, skalowane, uaktualnione i obsługiwane przez usługę AKS. Punkt ciężkości pracy operatora przenosi się z ręcznego tworzenia topologii puli systemowej na weryfikację rozmieszczenia obciążeń, zachowania pojemności oraz mechanizmów kontroli na poziomie przestrzeni nazw.

W przypadku usługi AKS Standard nadal obowiązują następujące wskazówki:

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.

W usłudze AKS Automatic pojemność puli węzłów systemowych jest zarządzana przez usługę AKS. W usłudze AKS Standard użyj konfiguracji narzędzia autoskalowania, aby pula węzłów systemowych zawsze mogła być skalowana zgodnie z potrzebami zasobników systemowych.

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.

W usłudze AKS Standard systemowe pule węzłów powinny mieć co najmniej dwa węzły, aby zwiększyć odporność podczas ponownego uruchamiania lub operacji uaktualniania. W usłudze AKS Automatic odporność puli węzłów systemowych jest zarządzana przez usługę, ale przy projektowaniu obciążeń nadal należy zakładać, że składniki systemowe mogą być aktualizowane lub przenoszone w ramach operacji platformy.

Pule węzłów systemowych służą do uruchamiania zasobników systemowych, takich jak kube-proxy, coredns i wtyczka Azure CNI. Zalecamy, aby pule węzłów systemowych miały co najmniej dwa węzły, co zapewni odporność na scenariusze zawieszenia/uaktualniania, które mogą prowadzić do ponownego uruchamiania lub wyłączania 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

Odpowiedzialność za aktualizację różni się w zależności od trybu klastra:

• AKS Automatic: aktualizacje klastra domyślnie używają kanału Stable, a aktualizacje obrazu systemu operacyjnego węzłów domyślnie używają kanału NodeImage. Operator koncentruje się na gotowości obciążeń, kontroli zakłóceń, harmonogramach konserwacji i bezpiecznej weryfikacji wdrożenia.
• AKS Standard: Operatorzy jawnie konfigurują kanały uaktualniania i ustawienia puli węzłów, takie jak maxSurge i maxUnavailable.

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 Azure CLI ustawia maxSurge na 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 Azure CLI ustawia maxUnavailable na 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, odwiedź Uaktualnianie pul węzłów w AKS.

Przyspieszone Sieciowanie

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

Zachowanie uaktualniania obrazu węzła różni się w zależności od trybu klastra:

• AKS Automatic: uaktualnienia obrazu systemu operacyjnego węzła są wstępnie skonfigurowane za pośrednictwem kanału NodeImage.
• AKS Standard: operatorzy wybierają ręczne zarządzanie lub kanał automatycznego uaktualniania.

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.

Standardowa warstwa cenowa dla obciążeń produkcyjnych

Wskazówki dotyczące najlepszych rozwiązań

Użyj warstwy cenowej Standard dla obciążeń produkcyjnych, aby uzyskać większą niezawodność klastra i więcej zasobów, obsługę do 5 000 węzłów w klastrze oraz domyślnie włączoną umowę SLA dostępności. Jeśli potrzebujesz LTS, rozważ użycie poziomu Premium.

Warstwa Standardowa dla Azure Kubernetes Service (AKS) zapewnia gwarantowany finansowo 99,9% poziom dostępności umowy dotyczącej poziomu 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.

Uwaga dotycząca trybu klastra:

• Usługa AKS Automatic ma wstępnie skonfigurowane: warstwę Standard, umowę SLA czasu pracy oraz umowę SLA gotowości podów.
• Usługa AKS Standard domyślnie używa warstwy Free, chyba że wyraźnie wybierzesz warstwę Standard lub Premium.

Usługa LocalDNS na potrzeby niezawodności usługi DNS

Wskazówki dotyczące najlepszych rozwiązań

Włącz localDNS w pulach węzłów, aby zwiększyć niezawodność rozpoznawania nazw DNS i zachować łączność z usługą podczas przejściowych awarii DNS.

Usługa LocalDNS wdraża serwer proxy DNS w każdym węźle usługi AKS, zapewniając rozpoznawanie nazw DNS o niskich opóźnieniach i odporne na awarie. Dzięki lokalnemu rozpoznawaniu zapytań usługa LocalDNS zmniejsza zależność od scentralizowanych zasobników CoreDNS i unika conntrack wyczerpania tabel, co jest częstą przyczyną porzuconych zapytań DNS w środowiskach o wysokiej przepływności. Usługa LocalDNS obsługuje również serwowanie nieaktualnych odpowiedzi z pamięci podręcznej przez konfigurowalny czas, gdy serwer DNS nadrzędny jest niedostępny, co pomaga zachować łączność podów podczas zakłóceń. Aby uzyskać instrukcje dotyczące konfiguracji i najlepsze rozwiązania, zobacz Konfigurowanie lokalnych sieciDNS w usłudze AKS.

Uwaga dotycząca trybu klastra:

• Automatyczna usługa AKS: wstępnie skonfigurowana jest usługa LocalDNS.
• AKS Standard: LocalDNS jest opcjonalna i musi być włączona jawnie.

Azure CNI na potrzeby dynamicznej alokacji adresów IP

Wskazówki dotyczące najlepszych rozwiązań

Skonfiguruj CNI Azure do dynamicznej alokacji adresów IP, aby lepiej wykorzystać adresy IP i zapobiec ich wyczerpaniu w klastrach AKS.

W przypadku usługi AKS Standard Azure alokacja dynamicznych adresów IP CNI pomaga zwiększyć wykorzystanie adresów IP i zapobiec wyczerpaniu adresów IP. W przypadku usługi AKS Automatic domyślną opcją sieciową jest zarządzana sieć wirtualna z użyciem Azure CNI Overlay obsługiwanej przez Cilium, z opcjonalnymi niestandardowymi konfiguracjami sieci wirtualnej w obsługiwanych scenariuszach.

Funkcja dynamicznej alokacji adresów IP w Azure CNI przydziela adresy IP zasobników z podsieci innej niż podsieć hostująca klaster AKS i zapewnia 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ż zasobniki mają przypisane adresy IP sieci wirtualnej, mają bezpośrednią łączność z innymi zasobnikami i zasobami klastra w sieci wirtualnej. 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 korzystanie z wielu przydatnych scenariuszy, takich jak zezwolenie na łączność z Internetem wyłącznie dla podów, a nie dla węzłów; przypisywanie stałego źródłowego adresu IP podom w puli węzłów za pomocą bramy Azure NAT Gateway; oraz filtrowanie ruchu między pulami węzłów przy użyciu sieciowych grup zabezpieczeń.
• Zasady sieci Kubernetes: Zarówno zasady sieci Azure, jak i Calico współpracują z tym rozwiązaniem.

Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci CNI 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.

Azure SSD w warstwie Premium

Wskazówki dotyczące najlepszych rozwiązań

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

Dyski zarządzane Azure Premium SSD oferują niezmiennie opóźnienie dysku poniżej jednej milisekundy oraz wysokie wartości IOPS i przepustowość. Dyski SSD w warstwie Premium zaprojektowano 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 Azure Premium SSD w wersji 2 na 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 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.

Uwaga dotycząca trybu klastra:

• Automatyczny AKS: funkcja Container Insights jest domyślnie włączona w obsługiwanych procesach tworzenia w interfejsie wiersza polecenia platformy Azure i w portalu Azure.
• AKS Standard: usługa Container Insights jest opcjonalna i włączona jawnie.

Monitorowanie usługi Container Insights w klastrze usługi AKS można włączyć przy użyciu różnych metod. Poniższy przykład pokazuje, jak włączyć monitorowanie usługi Container Insights w istniejącym klastrze AKS w warstwie Standard za pomocą narzędzia Azure CLI:

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 Azure Policy.

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

Uwaga dotycząca trybu klastra:

• AKS Automatic: zabezpieczenia wdrożeń i bazowe standardy zabezpieczeń zasobników są wstępnie skonfigurowane w trybie wymuszania.
• AKS Standard: zabezpieczenia Azure Policy i wdrożenia są opcjonalne i wymagają jawnej konfiguracji.

Aby uzyskać więcej informacji, zobacz Secure your AKS clusters with Azure Policy (Zabezpieczanie klastrów usługi AKS za pomocą Azure Policy

Treści powiązane

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

• Co to jest usługa AKS Automatic?
• 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