Podstawowe pojęcia dotyczące platformy Kubernetes dla usługi Azure Kubernetes Service (AKS)

W tym artykule opisano podstawowe pojęcia związane z usługą Azure Kubernetes Service (AKS), zarządzaną usługą Kubernetes, której można użyć do wdrażania i obsługi konteneryzowanych aplikacji na dużą skalę na platformie Azure. Ułatwia to poznanie składników infrastruktury platformy Kubernetes i uzyskanie dokładniejszego zrozumienia sposobu działania platformy Kubernetes w usłudze AKS.

Co to jest platforma Kubernetes?

Platforma Kubernetes to szybko rozwijająca się platforma, która zarządza aplikacjami opartymi na kontenerach i skojarzonymi z nimi składnikami sieci i magazynu. Platforma Kubernetes koncentruje się na obciążeniach aplikacji, a nie na podstawowych składnikach infrastruktury. Platforma Kubernetes zapewnia deklaratywne podejście do wdrożeń, wspierane przez niezawodny zestaw interfejsów API na potrzeby operacji zarządzania.

Możesz tworzyć i uruchamiać nowoczesne, przenośne, oparte na mikrousługach aplikacje korzystające z platformy Kubernetes w celu organizowania dostępności składników aplikacji i zarządzania nimi. Platforma Kubernetes obsługuje zarówno aplikacje bezstanowe, jak i stanowe.

Jako otwarta platforma Kubernetes umożliwia tworzenie aplikacji przy użyciu preferowanego języka programowania, systemu operacyjnego, bibliotek lub magistrali komunikatów. Istniejące narzędzia ciągłej integracji i ciągłego dostarczania (CI/CD) mogą integrować się z platformą Kubernetes w celu planowania i wdrażania wydań.

Usługa AKS udostępnia zarządzaną usługę Kubernetes, która zmniejsza złożoność zadań wdrażania i zarządzania podstawowego. Platforma Azure zarządza płaszczyzną sterowania usługi AKS i płaci tylko za węzły usługi AKS, na których są uruchamiane aplikacje.

Architektura klastra Kubernetes

Klaster Kubernetes jest podzielony na dwa składniki:

• Płaszczyzna sterowania, która zapewnia podstawowe usługi Kubernetes i orkiestrację obciążeń aplikacji oraz
• Węzły, które uruchamiają obciążenia aplikacji.

Płaszczyzna sterowania

Podczas tworzenia klastra usługi AKS platforma Azure automatycznie tworzy i konfiguruje skojarzona z nią płaszczyzna sterowania. Ta płaszczyzna sterowania z jedną dzierżawą jest zapewniana bez kosztów, ponieważ zarządzany zasób platformy Azure jest abstrahowany od użytkownika. Płacisz tylko za węzły dołączone do klastra usługi AKS. Płaszczyzna sterowania i jego zasoby znajdują się tylko w regionie, w którym utworzono klaster.

Płaszczyzna sterowania zawiera następujące podstawowe składniki platformy Kubernetes:

Składnik	opis
kube-apiserver	Serwer interfejsu API uwidacznia podstawowe interfejsy API platformy Kubernetes i zapewnia interakcję z narzędziami do zarządzania, takimi jak kubectl lub pulpit nawigacyjny platformy Kubernetes.
etcd	Etcd to magazyn o wysokiej dostępności klucz-wartość w usłudze Kubernetes, który pomaga zachować stan klastra Kubernetes i konfiguracji.
kube-scheduler	Podczas tworzenia lub skalowania aplikacji harmonogram określa, które węzły mogą uruchamiać obciążenie i uruchamia zidentyfikowane węzły.
kube-controller-manager	Menedżer kontrolera nadzoruje wiele mniejszych kontrolerów, które wykonują akcje, takie jak replikowanie zasobników i obsługa operacji węzła.

Należy pamiętać, że nie można uzyskać bezpośredniego dostępu do płaszczyzny sterowania. Uaktualnienia płaszczyzny sterowania i węzła platformy Kubernetes są orkiestrowane za pośrednictwem interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal. Aby rozwiązać możliwe problemy, możesz przejrzeć dzienniki płaszczyzny sterowania przy użyciu usługi Azure Monitor.

Uwaga

Jeśli chcesz skonfigurować lub bezpośrednio uzyskać dostęp do płaszczyzny sterowania, możesz wdrożyć własny klaster Kubernetes przy użyciu dostawcy interfejsu API klastra platformy Azure.

Węzły

Do uruchamiania aplikacji i usług pomocniczych potrzebny jest węzeł Kubernetes. Każdy klaster usługi AKS ma co najmniej jeden węzeł, maszynę wirtualną platformy Azure, która uruchamia składniki węzła Kubernetes i środowisko uruchomieniowe kontenera.

Węzły obejmują następujące podstawowe składniki platformy Kubernetes:

Składnik	opis
kubelet	Agent Kubernetes, który przetwarza żądania orkiestracji z płaszczyzny sterowania wraz z planowaniem i uruchamianiem żądanych kontenerów.
kube-proxy	Serwer proxy obsługuje sieć wirtualną w każdym węźle, routing ruchu sieciowego i zarządzanie adresami IP dla usług i zasobników.
środowisko uruchomieniowe kontenera	Środowisko uruchomieniowe kontenera umożliwia uruchamianie konteneryzowanych aplikacji i interakcję z innymi zasobami, takimi jak sieć wirtualna lub magazyn. Aby uzyskać więcej informacji, zobacz Konfiguracja środowiska uruchomieniowego kontenera.

Rozmiar maszyny wirtualnej platformy Azure dla węzłów definiuje procesory CPU, pamięć, rozmiar i dostępny typ magazynu, taki jak dyski SSD o wysokiej wydajności lub zwykły dysk TWARDY. Zaplanuj rozmiar węzła w zależności od tego, czy aplikacje mogą wymagać dużej ilości procesora CPU i pamięci, czy magazynu o wysokiej wydajności. Skalowanie w poziomie liczby węzłów w klastrze usługi AKS w celu spełnienia wymagań. Aby uzyskać więcej informacji na temat skalowania, zobacz Opcje skalowania aplikacji w usłudze AKS.

W usłudze AKS obraz maszyny wirtualnej dla węzłów klastra jest oparty na systemie Ubuntu Linux, Azure Linux lub Windows Server 2022. Podczas tworzenia klastra usługi AKS lub skalowania w poziomie liczby węzłów platforma Azure automatycznie tworzy i konfiguruje żądaną liczbę maszyn wirtualnych. Węzły agenta są rozliczane jako standardowe maszyny wirtualne, więc wszelkie rabaty na rozmiar maszyn wirtualnych, w tym rezerwacje platformy Azure, są automatycznie stosowane.

W przypadku dysków zarządzanych domyślny rozmiar dysku i wydajność są przypisywane zgodnie z wybraną jednostki SKU maszyny wirtualnej i liczbą procesorów wirtualnych. Aby uzyskać więcej informacji, zobacz Domyślny rozmiar dysku systemu operacyjnego.

Uwaga

Jeśli potrzebujesz zaawansowanej konfiguracji i kontroli w środowisku uruchomieniowym kontenera węzła Kubernetes i systemie operacyjnym, możesz wdrożyć klaster zarządzany samodzielnie przy użyciu dostawcy interfejsu API klastra platformy Azure.

Konfiguracja systemu operacyjnego

Usługa AKS obsługuje systemy operacyjne Ubuntu 22.04 i Azure Linux 2.0 jako system operacyjny węzła dla klastrów z rozwiązaniem Kubernetes 1.25 i nowszym. System Ubuntu 18.04 można również określić podczas tworzenia puli węzłów dla platformy Kubernetes w wersji 1.24 lub nowszej.

Usługa AKS obsługuje system Operacyjny Windows Server 2022 jako domyślny system operacyjny dla pul węzłów systemu Windows w klastrach z platformą Kubernetes w wersji 1.25 lub nowszej. System Windows Server 2019 można również określić podczas tworzenia puli węzłów dla platformy Kubernetes w wersji 1.32 lub nowszej. System Windows Server 2019 jest wycofywany po zakończeniu działania platformy Kubernetes w wersji 1.32 i nie jest obsługiwany w przyszłych wersjach. Aby uzyskać więcej informacji na temat tego wycofania, zobacz informacje o wersji usługi AKS.

Konfiguracja środowiska uruchomieniowego kontenera

Środowisko uruchomieniowe kontenera to oprogramowanie, które wykonuje kontenery i zarządza obrazami kontenerów w węźle. Środowisko uruchomieniowe ułatwia abstrakcję wywołań sys-calls lub funkcji specyficznych dla systemu operacyjnego w celu uruchamiania kontenerów w systemie Linux lub Windows. W przypadku pul węzłów containerd systemu Linux jest używany na platformie Kubernetes w wersji 1.19 lub nowszej. W przypadku pul węzłów containerd systemu Windows Server 2019 i 2022 jest ogólnie dostępna i jest jedyną opcją środowiska uruchomieniowego na platformie Kubernetes w wersji 1.23 lub nowszej. Od maja 2023 r. platforma Docker jest wycofana i nie jest już obsługiwana. Aby uzyskać więcej informacji na temat tego wycofania, zobacz informacje o wersji usługi AKS.

Containerd to środowisko uruchomieniowe kontenera zgodnego ze standardem OCI (Open Container Initiative), które zapewnia minimalny zestaw wymaganych funkcji do wykonywania kontenerów i zarządzania obrazami w węźle. W przypadkucontainerd węzłów opartych na węzłach i pulach węzłów narzędzie kubelet komunikuje się bezpośrednio z containerd użyciem wtyczki CRI (interfejsu środowiska uruchomieniowego kontenera), usuwając dodatkowe przeskoki w przepływie danych w porównaniu z implementacją cri platformy Docker. W związku z tym widać lepsze opóźnienie uruchamiania zasobnika i mniejsze użycie zasobów (procesora CPU i pamięci).

Containerd działa na każdej ogólnie dostępnej wersji platformy Kubernetes w usłudze AKS, w każdej wersji kubernetes począwszy od wersji 1.19 i obsługuje wszystkie funkcje platformy Kubernetes i AKS.

Ważne

Klastry z pulami węzłów systemu Linux utworzonymi na platformie Kubernetes w wersji 1.19 lub nowszej są domyślne dla środowiska uruchomieniowego kontenera containerd . Klastry z pulami węzłów we wcześniejszych obsługiwanych wersjach platformy Kubernetes otrzymują platformę Docker dla środowiska uruchomieniowego kontenera. Pule węzłów systemu Linux zostaną zaktualizowane do containerd wersji kubernetes puli węzłów do wersji obsługującej program containerd.

containerd jest ogólnie dostępny dla klastrów z pulami węzłów systemu Windows Server 2019 i 2022 i jest jedyną opcją środowiska uruchomieniowego kontenera dla platformy Kubernetes w wersji 1.23 lub nowszej. Możesz nadal korzystać z pul węzłów i klastrów platformy Docker w wersjach starszych niż 1.23, ale platforma Docker nie jest już obsługiwana od maja 2023 r. Aby uzyskać więcej informacji, zobacz Dodawanie puli węzłów systemu Windows Server za pomocą containerdpolecenia .

Zdecydowanie zalecamy przetestowanie obciążeń w pulach containerd węzłów usługi AKS z użyciem klastrów z wersją platformy Kubernetes obsługiwaną containerd dla pul węzłów.

containerd ograniczenia/różnice

• W przypadku containerdprogramu zalecamy użycie crictl jako zamiennika interfejsu wiersza polecenia platformy Docker w celu rozwiązywania problemów z zasobnikami, kontenerami i obrazami kontenerów w węzłach platformy Kubernetes. Aby uzyskać więcej informacji na crictltemat programu , zobacz ogólne opcje użycia i konfiguracji klienta.

  • Containerd Nie zapewnia pełnej funkcjonalności interfejsu wiersza polecenia platformy Docker. Jest ona dostępna tylko do rozwiązywania problemów.
  • crictl oferuje bardziej przyjazny dla platformy Kubernetes widok kontenerów, z pojęciami takimi jak zasobniki itp.

• Containerd Konfiguruje rejestrowanie przy użyciu standardowego cri formatu rejestrowania. Rozwiązanie do rejestrowania musi obsługiwać cri format rejestrowania, taki jak usługa Azure Monitor for Containers.

• Nie można już uzyskać dostępu do aparatu platformy Docker lub /var/run/docker.sockużyć platformy Docker-in-Docker (DinD).

  • Jeśli obecnie wyodrębnisz dzienniki aplikacji lub dane monitorowania z aparatu platformy Docker, zamiast tego użyj Szczegółowe informacje kontenera. Usługa AKS nie obsługuje uruchamiania żadnych poleceń poza pasmem w węzłach agenta, które mogą powodować niestabilność.
  • Nie zalecamy kompilowania obrazów ani bezpośredniego używania aparatu platformy Docker. Platforma Kubernetes nie jest w pełni świadoma tych wykorzystanych zasobów, a te metody przedstawiają wiele problemów, jak opisano tutaj i tutaj.

• Podczas kompilowania obrazów możesz nadal używać bieżącego przepływu pracy kompilacji platformy Docker w zwykły sposób, chyba że tworzysz obrazy wewnątrz klastra usługi AKS. W takim przypadku rozważ przełączenie na zalecane podejście do tworzenia obrazów przy użyciu usługi ACR Tasks lub bezpieczniejszą opcję w klastrze, taką jak Docker Buildx.

Rezerwacje zasobów

Usługa AKS używa zasobów węzłów, aby ułatwić działanie węzła w ramach klastra. To użycie może spowodować rozbieżność między całkowitymi zasobami węzła a zasobami allocatable w usłudze AKS. Zapamiętaj te informacje podczas ustawiania żądań i limitów dla zasobników wdrożonych przez użytkownika.

Aby znaleźć zasób allocatable węzła, możesz użyć kubectl describe node polecenia :

kubectl describe node [NODE_NAME]

Aby zachować wydajność i funkcjonalność węzła, usługa AKS rezerwuje dwa typy zasobów, procesor CPU i pamięć w każdym węźle. Wraz z rozwojem węzła w zasobach rezerwacja zasobów zwiększa się z powodu większego zapotrzebowania na zarządzanie zasobnikami wdrożonym przez użytkownika. Należy pamiętać, że nie można zmienić rezerwacji zasobów.

Uwaga

Korzystanie z dodatków usługi AKS, takich jak container Szczegółowe informacje (OMS), zużywa dodatkowe zasoby węzłów.

Procesor CPU

Zarezerwowany procesor CPU jest zależny od typu węzła i konfiguracji klastra, co może spowodować mniejsze przydzielanie procesora CPU z powodu uruchamiania dodatkowych funkcji. W poniższej tabeli przedstawiono rezerwację procesora CPU w milisekundach:

Rdzenie procesora CPU na hoście	1	2	4	8	16	32	64
Kube-reserved (millicores)	60	100	140	180	260	420	740

Pamięć

Pamięć zarezerwowana w usłudze AKS zawiera sumę dwóch wartości:

Ważne

Wersja zapoznawcza usługi AKS 1.29 w styczniu 2024 r. obejmuje pewne zmiany w rezerwacjach pamięci. Te zmiany zostały szczegółowo opisane w poniższej sekcji.

Usługa AKS 1.29 lub nowsza

1. kubelet Demon ma domyślnie regułę eksmisji memory.available<100Mi eviction. Ta reguła gwarantuje, że węzeł ma co najmniej 100Mi allocatable przez cały czas. Gdy host znajduje się poniżej tego progu dostępnej pamięci, kubelet wyzwala zakończenie jednego z uruchomionych zasobników i zwalnia pamięć na maszynie hosta.

2. Szybkość rezerwacji pamięci ustawiona zgodnie z mniejszą wartością: 20 MB * Maksymalna liczba zasobników obsługiwanych w węźle + 50 MB lub 25% całkowitej ilości zasobów pamięci systemowej.

   Przykłady:

   • Jeśli maszyna wirtualna zapewnia 8 GB pamięci, a węzeł obsługuje maksymalnie 30 zasobników, usługa AKS zastrzega sobie 20 MB * 30 maksymalnych zasobników + 50 MB = 650 MB dla zarezerwowanego rozwiązania kube-reserved. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Jeśli maszyna wirtualna zapewnia 4 GB pamięci, a węzeł obsługuje maksymalnie 70 zasobników, usługa AKS rezerwuje 25% * 4 GB = 1000 MB dla usługi kube-reserved, ponieważ jest to mniej niż 20 MB * 70 Maksymalna liczba zasobników + 50 MB = 1450 MB.

   Aby uzyskać więcej informacji, zobacz Konfigurowanie maksymalnych zasobników na węzeł w klastrze usługi AKS.

Wersje usługi AKS wcześniejsze niż 1.29

1. kubelet Demon ma domyślnie regułę eksmisji memory.available<750Mi. Ta reguła gwarantuje, że węzeł ma co najmniej 750Mi allocatable przez cały czas. Gdy host znajduje się poniżej tego progu dostępnej pamięci, kubelet wyzwala zakończenie jednego z uruchomionych zasobników i zwalnia pamięć na maszynie hosta.
2. Regresja liczby rezerwacji pamięci dla demona kubelet do prawidłowego działania (kube-reserved).
   • 25% z pierwszych 4 GB pamięci
   • 20% następnej 4 GB pamięci (do 8 GB)
   • 10% następnej 8 GB pamięci (do 16 GB)
   • 6% następnej 112 GB pamięci (do 128 GB)
   • 2% pamięci więcej niż 128 GB

Uwaga

Usługa AKS rezerwuje dodatkowe 2 GB dla procesów systemowych w węzłach systemu Windows, które nie są częścią pamięci obliczeniowej.

Reguły alokacji pamięci i procesora CPU są przeznaczone do:

• Zachowaj kondycję węzłów agenta, w tym niektóre zasobniki systemu hostowania krytyczne dla kondycji klastra.
• Jeśli węzeł nie był częścią klastra Kubernetes, węzeł zgłasza mniej pamięci i procesor CPU, niż raportowałby.

Jeśli na przykład węzeł oferuje 7 GB, zgłosi 34% pamięci, w tym próg eksmisji 750Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Oprócz rezerwacji dla samej platformy Kubernetes podstawowy system operacyjny węzła zastrzega sobie również ilość zasobów procesora CPU i pamięci w celu obsługi funkcji systemu operacyjnego.

Aby uzyskać informacje o skojarzonych najlepszych rozwiązaniach, zobacz Najlepsze rozwiązania dotyczące podstawowych funkcji harmonogramu w usłudze AKS.

Pule węzłów

Uwaga

Pula węzłów systemu Linux platformy Azure jest teraz ogólnie dostępna . Aby dowiedzieć się więcej o korzyściach i krokach wdrażania, zobacz Wprowadzenie do hosta kontenera systemu Linux platformy Azure dla usługi AKS.

Węzły tej samej konfiguracji są grupowane razem w pule węzłów. Każdy klaster Kubernetes zawiera co najmniej jedną pulę węzłów. Początkowa liczba węzłów i rozmiarów jest definiowana podczas tworzenia klastra usługi AKS, który tworzy domyślną pulę węzłów. Ta domyślna pula węzłów w usłudze AKS zawiera bazowe maszyny wirtualne, które uruchamiają węzły agenta.

Uwaga

Aby zapewnić niezawodne działanie klastra, należy uruchomić co najmniej dwa węzły w domyślnej puli węzłów.

Klaster usługi AKS można skalować lub uaktualniać do domyślnej puli węzłów. Możesz wybrać skalowanie lub uaktualnienie określonej puli węzłów. W przypadku operacji uaktualniania uruchomione kontenery są zaplanowane na innych węzłach w puli węzłów do momentu pomyślnego uaktualnienia wszystkich węzłów.

Aby uzyskać więcej informacji, zobacz Tworzenie pul węzłów i Zarządzanie pulami węzłów.

Domyślny rozmiar dysku systemu operacyjnego

Podczas tworzenia nowego klastra lub dodawania nowej puli węzłów do istniejącego klastra liczba procesorów wirtualnych domyślnie określa rozmiar dysku systemu operacyjnego. Liczba procesorów wirtualnych jest oparta na jednostce SKU maszyny wirtualnej. W poniższej tabeli wymieniono domyślny rozmiar dysku systemu operacyjnego dla każdej jednostki SKU maszyny wirtualnej:

Rdzenie jednostek SKU maszyny wirtualnej (procesory wirtualne)	Domyślna warstwa dysku systemu operacyjnego	Aprowizowane operacje wy/wy na sekundę	Aprowizowana przepływność (Mb/s)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

Ważne

Domyślne ustalanie rozmiaru dysku systemu operacyjnego jest używane tylko w nowych klastrach lub pulach węzłów, gdy efemeryczne dyski systemu operacyjnego nie są obsługiwane i nie określono domyślnego rozmiaru dysku systemu operacyjnego. Domyślny rozmiar dysku systemu operacyjnego może mieć wpływ na wydajność lub koszt klastra. Nie można zmienić rozmiaru dysku systemu operacyjnego po utworzeniu klastra lub puli węzłów. Ten domyślny rozmiar dysku ma wpływ na klastry lub pule węzłów utworzone w lipcu 2022 r. lub nowszym.

Selektory węzłów

W klastrze usługi AKS z wieloma pulami węzłów może być konieczne określenie harmonogramu Kubernetes, która pula węzłów ma być używana dla danego zasobu. Na przykład kontrolery ruchu przychodzącego nie powinny działać w węzłach systemu Windows Server. Selektory węzłów służą do definiowania różnych parametrów, takich jak system operacyjny węzła, do kontrolowania miejsca, w którym zasobnik powinien być zaplanowany.

Poniższy podstawowy przykład planuje wystąpienie NGINX w węźle systemu Linux przy użyciu selektora węzłów "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące zaawansowanych funkcji harmonogramu w usłudze AKS.

Grupa zasobów węzła

Podczas tworzenia klastra usługi AKS należy określić grupę zasobów platformy Azure, w której będą tworzone zasoby klastra. Oprócz tej grupy zasobów dostawca zasobów usługi AKS tworzy oddzielną grupę zasobów o nazwie node i zarządza nią. Grupa zasobów węzła zawiera następujące zasoby infrastruktury:

• Zestawy skalowania maszyn wirtualnych i maszyny wirtualne dla każdego węzła w pulach węzłów
• Sieć wirtualna klastra
• Magazyn dla klastra

Domyślnie grupa zasobów węzła ma następujący format: MC_resourceGroupName_clusterName_location. Podczas tworzenia klastra można określić nazwę przypisaną do grupy zasobów węzła. W przypadku korzystania z szablonu usługi Azure Resource Manager można zdefiniować nazwę przy użyciu nodeResourceGroup właściwości . W przypadku korzystania z interfejsu --node-resource-group wiersza polecenia platformy Azure należy użyć parametru z poleceniem az aks create , jak pokazano w poniższym przykładzie:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

Po usunięciu klastra usługi AKS dostawca zasobów usługi AKS automatycznie usunie grupę zasobów węzła.

Grupa zasobów węzła ma następujące ograniczenia:

• Nie można określić istniejącej grupy zasobów dla grupy zasobów węzła.
• Nie można określić innej subskrypcji dla grupy zasobów węzła.
• Nie można zmienić nazwy grupy zasobów węzła po utworzeniu klastra.
• Nie można określić nazw zarządzanych zasobów w grupie zasobów węzła.
• Nie można modyfikować ani usuwać utworzonych przez platformę Azure tagów zasobów zarządzanych w grupie zasobów węzła.

Modyfikowanie dowolnych tagów utworzonych przez platformę Azure w zasobach w grupie zasobów węzła w klastrze usługi AKS jest nieobsługiwaną akcją, która przerywa cel poziomu usług (SLO). Jeśli zmodyfikujesz lub usuniesz tagi utworzone przez platformę Azure lub inne właściwości zasobów w grupie zasobów węzła, możesz uzyskać nieoczekiwane wyniki, takie jak skalowanie i uaktualnianie błędów. Usługa AKS zarządza cyklem życia infrastruktury w grupie zasobów węzła, dlatego wprowadzanie wszelkich zmian powoduje przeniesienie klastra do stanu nieobsługiwanego. Aby uzyskać więcej informacji, zobacz Czy usługa AKS oferuje umowę dotyczącą poziomu usług?

Usługa AKS umożliwia tworzenie i modyfikowanie tagów, które są propagowane do zasobów w grupie zasobów węzła, oraz dodawanie tych tagów podczas tworzenia lub aktualizowania klastra. Możesz na przykład utworzyć lub zmodyfikować tagi niestandardowe, aby przypisać jednostkę biznesową lub centrum kosztów. Możesz również utworzyć zasady platformy Azure z zakresem w zarządzanej grupie zasobów.

Aby zmniejszyć prawdopodobieństwo zmian w grupie zasobów węzła wpływających na klastry, możesz włączyć blokadę grupy zasobów węzła, aby zastosować przypisanie odmowy do zasobów usługi AKS. Aby uzyskać więcej informacji, zobacz W pełni zarządzana grupa zasobów (wersja zapoznawcza).

Ostrzeżenie

Jeśli nie masz włączonej blokady grupy zasobów węzła, możesz bezpośrednio zmodyfikować dowolny zasób w grupie zasobów węzła. Bezpośrednie modyfikowanie zasobów w grupie zasobów węzła może spowodować, że klaster stanie się niestabilny lub nie odpowiada.

Zasobniki

Platforma Kubernetes używa zasobników do uruchamiania wystąpień aplikacji. Pojedynczy zasobnik reprezentuje pojedyncze wystąpienie aplikacji.

Zasobniki zazwyczaj mają mapowanie 1:1 z kontenerem. W zaawansowanych scenariuszach zasobnik może zawierać wiele kontenerów. Zasobniki z wieloma kontenerami są zaplanowane razem w tym samym węźle i umożliwiają kontenerom udostępnianie powiązanych zasobów.

Podczas tworzenia zasobnika można zdefiniować żądania zasobów dla określonej ilości procesora CPU lub pamięci. Harmonogram kubernetes próbuje spełnić żądanie, planując zasobniki do uruchomienia w węźle z dostępnymi zasobami. Można również określić maksymalne limity zasobów, aby uniemożliwić zasobnikowi korzystanie ze zbyt dużej ilości zasobów obliczeniowych z węzła bazowego. Naszym zalecanym najlepszym rozwiązaniem jest uwzględnienie limitów zasobów dla wszystkich zasobników, aby ułatwić usłudze Kubernetes Scheduler zidentyfikowanie niezbędnych, dozwolonych zasobów.

Aby uzyskać więcej informacji, zobacz Kubernetes pods and Kubernetes pod lifecycle (Cykl życia zasobników Kubernetes).

Zasobnik jest zasobem logicznym, ale obciążenia aplikacji są uruchamiane w kontenerach. Zasobniki są zwykle efemeryczne, jednorazowe zasoby. Pojedynczo zaplanowane zasobniki przegapią niektóre funkcje wysokiej dostępności i nadmiarowości platformy Kubernetes. Zamiast tego kontrolery Kubernetes, takie jak kontroler wdrożenia, wdraża zasobniki i zarządzają nimi.

Wdrożenia i manifesty YAML

Wdrożenie reprezentuje identyczne zasobniki zarządzane przez kontroler wdrażania platformy Kubernetes. Wdrożenie definiuje liczbę replik zasobników do utworzenia. Harmonogram Kubernetes gwarantuje, że dodatkowe zasobniki są zaplanowane w węzłach w dobrej kondycji, jeśli zasobniki lub węzły napotykają problemy. Wdrożenia można aktualizować w celu zmiany konfiguracji zasobników, obrazu kontenera lub dołączonego magazynu.

Kontroler wdrażania zarządza cyklem życia wdrożenia i wykonuje następujące czynności:

• Opróżnia i kończy daną liczbę replik.
• Tworzy repliki z nowej definicji wdrożenia.
• Kontynuuje proces do momentu zaktualizowania wszystkich replik we wdrożeniu.

Większość aplikacji bezstanowych w usłudze AKS powinna używać modelu wdrażania, a nie planowania poszczególnych zasobników. Platforma Kubernetes może monitorować kondycję i stan wdrożenia, aby upewnić się, że wymagana liczba replik jest uruchamiana w klastrze. Gdy zasobniki są zaplanowane indywidualnie, nie są uruchamiane ponownie, jeśli napotkają problem, i nie są zaplanowane ponownie w węzłach w dobrej kondycji, jeśli ich bieżący węzeł napotka problem.

Nie chcesz zakłócać podejmowania decyzji dotyczących zarządzania procesem aktualizacji, jeśli aplikacja wymaga minimalnej liczby dostępnych wystąpień. Budżety zakłóceń zasobników określają, ile replik we wdrożeniu można zdjąć podczas uaktualniania aktualizacji lub węzła. Jeśli na przykład masz pięć replik we wdrożeniu, możesz zdefiniować zakłócenia zasobnika o wartości czterech , aby zezwolić tylko na usunięcie lub zaplanowanie jednej repliki naraz. Podobnie jak w przypadku limitów zasobów zasobników, naszym zalecanym najlepszym rozwiązaniem jest zdefiniowanie budżetów zakłóceń zasobników w aplikacjach, które wymagają minimalnej liczby replik, aby zawsze istnieć.

Wdrożenia są zwykle tworzone i zarządzane za pomocą kubectl create polecenia lub kubectl apply. Wdrożenie można utworzyć, definiując plik manifestu w formacie YAML. W poniższym przykładzie przedstawiono podstawowy plik manifestu wdrożenia dla serwera internetowego NGINX:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Podział specyfikacji wdrożenia w pliku manifestu YAML jest następujący:

Specyfikacja	opis
.apiVersion	Określa grupę interfejsów API i zasób interfejsu API, którego chcesz użyć podczas tworzenia zasobu.
.kind	Określa typ zasobu, który chcesz utworzyć.
.metadata.name	Określa nazwę wdrożenia. Ten przykładowy plik YAML uruchamia obraz nginx z usługi Docker Hub.
.spec.replicas	Określa liczbę zasobników do utworzenia. W tym przykładzie plik YAML tworzy trzy zduplikowane zasobniki.
.spec.selector	Określa, które zasobniki będą miały wpływ na to wdrożenie.
.spec.selector.matchLabels	Zawiera mapę par {key, value} , które umożliwiają wdrożeniu znajdowanie utworzonych zasobników i zarządzanie nimi.
.spec.selector.matchLabels.app	Musi być zgodna .spec.template.metadata.labelsz parametrem .
.spec.template.labels	Określa pary {key, value} dołączone do obiektu.
.spec.template.app	Musi być zgodna .spec.selector.matchLabelsz parametrem .
.spec.spec.containers	Określa listę kontenerów należących do zasobnika.
.spec.spec.containers.name	Określa nazwę kontenera określonego jako etykietę DNS.
.spec.spec.containers.image	Określa nazwę obrazu kontenera.
.spec.spec.containers.ports	Określa listę portów do uwidocznienia z kontenera.
.spec.spec.containers.ports.containerPort	Określa liczbę portów do uwidocznienia na adresIE IP zasobnika.
.spec.spec.resources	Określa zasoby obliczeniowe wymagane przez kontener.
.spec.spec.resources.requests	Określa minimalną wymaganą ilość zasobów obliczeniowych.
.spec.spec.resources.requests.cpu	Określa minimalną wymaganą ilość procesora CPU.
.spec.spec.resources.requests.memory	Określa minimalną wymaganą ilość pamięci.
.spec.spec.resources.limits	Określa dozwoloną maksymalną ilość zasobów obliczeniowych. Polecenie kubelet wymusza ten limit.
.spec.spec.resources.limits.cpu	Określa maksymalną dozwoloną ilość procesora CPU. Polecenie kubelet wymusza ten limit.
.spec.spec.resources.limits.memory	Określa maksymalną dozwoloną ilość pamięci. Polecenie kubelet wymusza ten limit.

Bardziej złożone aplikacje można tworzyć, włączając usługi, takie jak moduły równoważenia obciążenia, w manifeście YAML.

Aby uzyskać więcej informacji, zobacz Wdrożenia platformy Kubernetes.

Zarządzanie pakietami za pomocą programu Helm

Program Helm jest często używany do zarządzania aplikacjami na platformie Kubernetes. Zasoby można wdrażać, kompilując i używając istniejących publicznych wykresów helm zawierających spakowana wersja kodu aplikacji i manifesty YAML platformy Kubernetes. Wykresy programu Helm można przechowywać lokalnie lub w repozytorium zdalnym, takim jak repozytorium programu Helm usługi Azure Container Registry.

Aby użyć programu Helm, zainstaluj klienta helm na komputerze lub użyj klienta Helm w usłudze Azure Cloud Shell. Wyszukaj lub utwórz wykresy helm, a następnie zainstaluj je w klastrze Kubernetes. Aby uzyskać więcej informacji, zobacz Instalowanie istniejących aplikacji za pomocą programu Helm w usłudze AKS.

StatefulSets i DaemonSets

Kontroler wdrażania używa harmonogramu Kubernetes i uruchamia repliki w dowolnym dostępnym węźle z dostępnymi zasobami. Chociaż takie podejście może być wystarczające w przypadku aplikacji bezstanowych, kontroler wdrażania nie jest idealny dla aplikacji wymagających następujących specyfikacji:

• Trwała konwencja nazewnictwa lub magazyn.
• Replika, która ma istnieć w każdym węźle wyboru w klastrze.

Jednak dwa zasoby kubernetes umożliwiają zarządzanie tymi typami aplikacji: StatefulSets i DaemonSets.

StatefulSets utrzymuje stan aplikacji poza cyklem życia poszczególnych zasobników. Zestawy DaemonSet zapewniają uruchomione wystąpienie na każdym węźle na wczesnym etapie procesu uruchamiania platformy Kubernetes.

Stanowe zestawy

Nowoczesne programowanie aplikacji często ma na celu zastosowanie aplikacji bezstanowych. W przypadku aplikacji stanowych, takich jak te, które zawierają składniki bazy danych, można użyć elementów StatefulSets. Podobnie jak wdrożenia, zestaw StatefulSet tworzy co najmniej jeden identyczny zasobnik i zarządza nim. Repliki w elemencie StatefulSet są zgodne z bezproblemowym, sekwencyjnym podejściem do operacji wdrażania, skalowania, uaktualniania i kończenia. Konwencja nazewnictwa, nazwy sieci i magazyn są utrwalane podczas ponownego instalowania replik z zestawem StatefulSet.

Aplikację można zdefiniować w formacie YAML przy użyciu polecenia kind: StatefulSet. Z tego miejsca kontroler StatefulSet obsługuje wdrażanie wymaganych replik i zarządzanie nimi. Zapisy danych w magazynie trwałym udostępniane przez usługę Azure Dyski zarządzane lub Azure Files. W przypadku zestawów StatefulSet podstawowy magazyn trwały pozostaje nawet wtedy, gdy element StatefulSet zostanie usunięty.

Aby uzyskać więcej informacji, zobacz Kubernetes StatefulSets.

Ważne

Repliki w zestawie statefulSet są zaplanowane i uruchamiane we wszystkich dostępnych węzłach w klastrze usługi AKS. Aby upewnić się, że co najmniej jeden zasobnik w zestawie jest uruchamiany w węźle, należy zamiast tego użyć elementu DaemonSet.

Zestawy demonów

W przypadku określonej kolekcji dzienników lub monitorowania może być konieczne uruchomienie zasobnika na wszystkich węzłach lub w wybranym zestawie węzłów. Zestawy DaemonSet można użyć do wdrożenia w co najmniej jednym identycznym zasobniku. Kontroler DaemonSet gwarantuje, że każdy określony węzeł uruchamia wystąpienie zasobnika.

Kontroler daemonSet może planować zasobniki na węzłach na początku procesu rozruchu klastra przed uruchomieniem domyślnego harmonogramu Kubernetes. Ta możliwość gwarantuje, że zasobniki w stanie DaemonSet przed zaplanowaniem tradycyjnych zasobników we wdrożeniu lub zestawie stanowym.

Podobnie jak StatefulSets, można zdefiniować element DaemonSet jako część definicji YAML przy użyciu polecenia kind: DaemonSet.

Aby uzyskać więcej informacji, zobacz Kubernetes DaemonSets.

Uwaga

Jeśli używasz dodatku Węzły wirtualne, zestawy DaemonSet nie tworzą zasobników w węźle wirtualnym.

Przestrzenie nazw

Zasoby platformy Kubernetes, takie jak zasobniki i wdrożenia, są logicznie grupowane w przestrzenie nazw, aby podzielić klaster usługi AKS i utworzyć, wyświetlić lub zarządzać dostępem do zasobów. Można na przykład utworzyć przestrzenie nazw, aby oddzielić grupy biznesowe. Użytkownicy mogą korzystać tylko z zasobów znajdujących się w przypisanych przestrzeniach nazw.

Podczas tworzenia klastra usługi AKS są dostępne następujące przestrzenie nazw:

Przestrzeń nazw	opis
default	Miejsce, w którym zasobniki i wdrożenia są tworzone domyślnie, gdy nie są udostępniane żadne. W mniejszych środowiskach można wdrażać aplikacje bezpośrednio w domyślnej przestrzeni nazw bez tworzenia dodatkowych separacji logicznych. W przypadku interakcji z interfejsem API Kubernetes, takim jak z kubectl get pods, domyślna przestrzeń nazw jest używana, gdy nie zostanie określona żadna.
kube-system	Gdzie istnieją podstawowe zasoby, takie jak funkcje sieciowe, takie jak DNS i proxy, lub pulpit nawigacyjny platformy Kubernetes. W tej przestrzeni nazw zazwyczaj nie wdraża się własnych aplikacji.
kube-public	Zazwyczaj nie jest używany, można go używać, aby zasoby były widoczne w całym klastrze i mogą być wyświetlane przez dowolnego użytkownika.

Aby uzyskać więcej informacji, zobacz Kubernetes namespaces (Przestrzenie nazw kubernetes).

Następne kroki

Aby uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz następujące artykuły:

• Dostęp i tożsamość usługi AKS
• Zabezpieczenia usługi AKS
• Sieci wirtualne usługi AKS
• Magazyn usługi AKS
• Skala usługi AKS