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

  • Artykuł

Opracowywanie aplikacji nadal przechodzi w kierunku podejścia opartego na kontenerach, co zwiększa potrzebę organizowania zasobów i zarządzania nimi. Jako wiodąca platforma Kubernetes zapewnia niezawodne planowanie obciążeń aplikacji odpornych na błędy. Usługa Azure Kubernetes Service (AKS), zarządzana oferta kubernetes, dodatkowo upraszcza wdrażanie aplikacji opartych na kontenerach i zarządzanie nimi.

W tym artykule przedstawiono podstawowe pojęcia:

  • Składniki infrastruktury kubernetes:

    • płaszczyzna sterowania
    • Węzłów
    • pule węzłów

  • Zasoby obciążenia:

    • Strąków
    • Wdrożeń
    • Ustawia

  • Grupuj zasoby przy użyciu przestrzeni nazw.

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.

Nowoczesne, przenośne, oparte na mikrousługach aplikacje można tworzyć i uruchamiać przy użyciu platformy Kubernetes do organizowania składników aplikacji i zarządzania nimi. Platforma Kubernetes obsługuje zarówno aplikacje bezstanowe, jak i stanowe, ponieważ zespoły przechodzą przez wdrażanie aplikacji opartych na mikrousługach.

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, takich jak koordynacja uaktualniania. 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: zapewnia podstawowe usługi Kubernetes i aranżację obciążeń aplikacji.
  • Węzły: uruchamianie obciążeń aplikacji.

Kubernetes control plane and node components

Płaszczyzna sterowania

Podczas tworzenia klastra usługi AKS płaszczyzna sterowania jest automatycznie tworzona i konfigurowana. Ta płaszczyzna sterowania jest dostarczana bezpłatnie jako zarządzany zasób platformy Azure odrębny od użytkownika. Płacisz tylko za węzły dołączone do klastra usługi AKS. Płaszczyzna sterowania i jej zasoby znajdują się tylko w regionie, w którym został utworzony klaster.

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

Składnik opis
kube-apiserver Serwer interfejsu API jest sposobem uwidocznienia bazowych interfejsów API platformy Kubernetes. Ten składnik zapewnia interakcję z narzędziami do zarządzania, takimi jak kubectl lub pulpit nawigacyjny platformy Kubernetes.
etcd Aby zachować stan klastra Kubernetes i konfiguracji, funkcja wysokiej dostępności jest magazynem wartości klucza w ramach platformy Kubernetes.
kube-scheduler Podczas tworzenia lub skalowania aplikacji harmonogram określa, które węzły mogą uruchamiać obciążenie i uruchamiać je.
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.

Usługa AKS udostępnia płaszczyznę sterowania z jedną dzierżawą z dedykowanym serwerem interfejsu API, harmonogramem itp. Definiujesz liczbę i rozmiar węzłów, a platforma Azure konfiguruje bezpieczną komunikację między płaszczyzną sterowania i węzłami. Interakcja z płaszczyzną sterowania odbywa się za pośrednictwem interfejsów API platformy Kubernetes, takich jak kubectl lub pulpit nawigacyjny platformy Kubernetes.

Chociaż nie trzeba konfigurować składników (takich jak magazyn o wysokiej dostępności itp. ) za pomocą tej zarządzanej płaszczyzny sterowania, nie można bezpośrednio uzyskać 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 za pomocą dzienników usługi Azure Monitor.

Aby skonfigurować lub bezpośrednio uzyskać dostęp do płaszczyzny sterowania, wdróż własny klaster Kubernetes przy użyciu dostawcy interfejsu API klastra platformy Azure.

Aby uzyskać informacje o skojarzonych najlepszych rozwiązaniach, zobacz Najlepsze rozwiązania dotyczące zabezpieczeń i uaktualnień klastra w usłudze AKS.

Aby uzyskać informacje dotyczące zarządzania kosztami w usłudze AKS, zobacz AKS cost basics (Podstawy kosztów usługi AKS) i Pricing for AKS (Cennik usługi AKS).

Węzły i pule węzłów

Do uruchamiania aplikacji i usług pomocniczych potrzebny jest węzeł Kubernetes. 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.

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 Obsługuje sieć wirtualną w każdym węźle. Serwer proxy kieruje ruch sieciowy i zarządza adresowania IP dla usług i zasobników.
środowisko uruchomieniowe kontenera Umożliwia uruchamianie konteneryzowanych aplikacji i interakcję z dodatkowymi zasobami, takimi jak sieć wirtualna lub magazyn. Klastry AKS korzystające z platformy Kubernetes w wersji 1.19 lub nowszej dla pul węzłów systemu Linux używają containerd jako środowiska uruchomieniowego kontenera. Począwszy od platformy Kubernetes w wersji 1.20 dla pul węzłów systemu Windows, containerd można jej używać w wersji zapoznawczej dla środowiska uruchomieniowego kontenera, ale platforma Docker jest nadal domyślnym środowiskiem uruchomieniowym kontenera. Klastry AKS korzystające z wcześniejszych wersji platformy Kubernetes dla pul węzłów używają platformy Docker jako środowiska uruchomieniowego kontenera.

Azure virtual machine and supporting resources for a Kubernetes node

Rozmiar maszyny wirtualnej platformy Azure dla węzłów definiuje procesory CPU, pamięć, rozmiar i dostępny typ magazynu (na przykład 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 systemach Ubuntu Linux, Azure Linux lub Windows Server 2019. 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 maszyny wirtualnej (w tym rezerwacje platformy Azure) są automatycznie stosowane.

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

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.

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źć zasoby allocatable węzła, uruchom polecenie:

kubectl describe node [NODE_NAME]

Aby zachować wydajność i funkcjonalność węzła, usługa AKS rezerwuje zasoby 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.

Uwaga

Korzystanie z dodatków usługi AKS, takich jak Container Szczegółowe informacje (OMS), spowoduje wykorzystanie dodatkowych zasobów węzłów.

Zarezerwowane są dwa typy zasobó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.

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ęć używana przez usługę 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. Gwarantuje to, że węzeł zawsze 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 jest instalowany na wszystkich węzłach agenta Kubernetes w celu zarządzania tworzeniem i kończeniem działania kontenera. Domyślnie w usłudze AKS kubelet demon ma pamięć.Dostępna<reguła eksmisji 750Mi , zapewniając, że węzeł musi zawsze mieć co najmniej 750Mi allocatable przez cały czas. Gdy host znajduje się poniżej tego progu dostępnej pamięci, kubelet wyzwalacz spowoduje przerwanie jednego z uruchomionych zasobników i zwolnienie pamięci 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% dowolnej pamięci powyżej 128 GB

Uwaga

Usługa AKS rezerwuje dodatkowe 2 GB dla procesu systemowego 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 wykonywania następujących czynności:

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

Nie można zmienić powyższych rezerwacji zasobów.

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. Klaster Kubernetes zawiera co najmniej jedną pulę węzłów. Początkowa liczba węzłów i rozmiar są definiowane 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 (2) 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 na temat używania wielu pul węzłów w usłudze AKS, zobacz Tworzenie wielu pul węzłów dla klastra w usłudze AKS.

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 umożliwiają definiowanie różnych parametrów, takich jak system operacyjny węzła, w celu 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 na temat kontrolowania miejsca zaplanowanych zasobników, 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, w której ma zostać utworzony zasób klastra. Oprócz tej grupy zasobów dostawca zasobów usługi AKS tworzy również 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 przypisaną nazwę, taką jak MC_myResourceGroup_myAKSCluster_eastus. Podczas tworzenia klastra można również określić nazwę przypisaną do grupy zasobów węzła. 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.

Jeśli zmodyfikujesz lub usuniesz tagi utworzone przez platformę Azure i 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. Ponieważ usługa AKS zarządza cyklem życia infrastruktury w grupie zasobów węzła, wszelkie zmiany spowodują przeniesienie klastra do stanu nieobsługiwanego.

Typowym scenariuszem, w którym klienci chcą modyfikować zasoby, są tagi. Usługa AKS umożliwia tworzenie i modyfikowanie tagów propagowanych 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żna to również osiągnąć, tworząc zasady platformy Azure z zakresem w zarządzanej grupie zasobów.

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). Aby uzyskać więcej informacji, zobacz Czy usługa AKS oferuje umowę dotyczącą poziomu usług?

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. Więcej informacji można znaleźć w temacie Konfiguracja klastra w usłudze AKS.

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ąpienia aplikacji. 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, aby zażądać określonej ilości zasobów 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. 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 zasobniki są wdrażane i zarządzane przez kontrolery kubernetes, takie jak kontroler wdrażania.

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, używanego obrazu kontenera lub dołączonego magazynu. Kontroler wdrażania:

  • 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 zostaną ponownie zaplanowane na 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ęć (5) replik we wdrożeniu, możesz zdefiniować zakłócenia zasobnika 4 (cztery), aby zezwolić tylko na usunięcie lub ponowne zaplanowanie jednej repliki naraz. Podobnie jak w przypadku limitów zasobów zasobników, 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. Utwórz wdrożenie, definiując plik manifestu w formacie YAML.

Poniższy przykład tworzy podstawowe wdrożenie serwera internetowego NGINX. Wdrożenie określa trzy (3) repliki do utworzenia i wymaga otwarcia portu 80 w kontenerze. Żądania zasobów i limity są również definiowane dla procesora CPU i pamięci.

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 plik uruchomi obraz nginx z usługi Docker Hub.
.spec.replicas Określa liczbę zasobników do utworzenia. Ten plik utworzy 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. Ten limit jest wymuszany przez narzędzie kubelet.
.spec.spec.resources.limits.cpu Określa maksymalną dozwoloną ilość procesora CPU. Ten limit jest wymuszany przez narzędzie kubelet.
.spec.spec.resources.limits.memory Określa maksymalną dozwoloną ilość pamięci. Ten limit jest wymuszany przez narzędzie kubelet.

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

Za pomocą harmonogramu Kubernetes kontroler wdrażania 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:

  • 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 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 wdrażania, skalowania, uaktualniania i kończenia. Konwencja nazewnictwa, nazwy sieci i magazyn są utrwalane podczas ponownego instalowania replik z zestawem StatefulSet.

Zdefiniuj aplikację w formacie YAML przy użyciu polecenia kind: StatefulSet. Z tego miejsca kontroler StatefulSet obsługuje wdrażanie wymaganych replik i zarządzanie nimi. Dane są zapisywane w magazynie trwałym udostępnianym 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.

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 wczesnym etapie procesu rozruchu klastra, zanim domyślny harmonogram Kubernetes został uruchomiony. Dzięki temu zasobniki w zestawie DaemonSet są uruchamiane przed zaplanowaniem tradycyjnych zasobników we wdrożeniu lub zestawie stanowym.

Podobnie jak StatefulSets, element DaemonSet jest definiowany jako część definicji YAML przy użyciu metody kind: DaemonSet.

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

Uwaga

Jeśli używasz dodatku Węzły wirtualne, zestawy DaemonSets nie będą tworzyć zasobników w węźle wirtualnym.

Przestrzenie nazw

Zasoby platformy Kubernetes, takie jak zasobniki i wdrożenia, są logicznie grupowane w przestrzeń 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.

Kubernetes namespaces to logically divide resources and applications

Podczas tworzenia klastra usługi AKS dostępne są 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, ale może służyć do wyświetlania zasobów w całym klastrze i może być wyświetlany przez dowolnego użytkownika.

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

Następne kroki

W tym artykule opisano niektóre podstawowe składniki platformy Kubernetes i sposób ich stosowania do klastrów usługi AKS. Aby uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz następujące artykuły: