Kubernetes — podstawowe pojęcia dotyczące usługi Azure Kubernetes Service (AKS)

  • Artykuł

Tworzenie aplikacji w dalszym ciągu 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. Azure Kubernetes Service (AKS), zarządzana oferta Kubernetes, dodatkowo upraszcza wdrażanie aplikacji opartych na kontenerach i zarządzanie nimi.

W tym artykule przedstawiono następujące informacje:

  • Podstawowe składniki infrastruktury Kubernetes:
    • płaszczyzna sterowania
    • Węzłów
    • pule węzłów
  • Zasoby obciążenia:
    • zasobniki
    • Wdrożeń
    • Ustawia
  • Jak grupować zasoby w przestrzenie nazw.

Co to jest platforma Kubernetes?

Kubernetes to szybko rozwijająca się platforma, która zarządza aplikacjami opartymi na kontenerach oraz 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.

Za pomocą platformy Kubernetes można tworzyć i uruchamiać nowoczesne, przenośne, oparte na mikrousługach aplikacje i zarządzać dostępnością składników aplikacji. Platforma Kubernetes obsługuje aplikacje bezstanowe i stanowe, ponieważ zespoły przechodzą przez proces wdrażania aplikacji opartych na mikrousługach.

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) można zintegrować 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 podstawowych zadań zarządzania, takich jak koordynacja uaktualniania. Platforma Azure zarządza płaszczyzną sterowania usługi AKS i płacisz 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 orkiestrację obciążeń aplikacji.
  • Węzły: uruchamiaj obciążenia aplikacji.

Składniki płaszczyzny sterowania i węzła platformy Kubernetes

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 pulpit nawigacyjny platformy Kubernetes lub pulpit nawigacyjny platformy Kubernetes.
etcd Aby zachować stan klastra Kubernetes i konfiguracji, funkcja wysokiej dostępności itp. jest magazynem wartości klucza w usłudze 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 kontrolerów 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 kubernetes.

Nie musisz konfigurować składników (takich jak magazyn o wysokiej dostępności itp. ) przy użyciu tej zarządzanej płaszczyzny sterowania, ale nie możesz 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 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 zapoznać się ze skojarzonymi najlepszymi rozwiązaniami, 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 sieci wirtualne w każdym węźle. Serwer proxy kieruje ruchem sieciowym i zarządza adresami IP dla usług i zasobników.
środowisko uruchomieniowe kontenera Umożliwia uruchamianie konteneryzowanych aplikacji i interakcję z dodatkowymi zasobami, takimi jak sieć wirtualna i 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 usługi AKS korzystające z wcześniejszych wersji platformy Kubernetes dla pul węzłów używają platformy Docker jako środowiska uruchomieniowego kontenera.

Maszyna wirtualna platformy Azure i zasoby pomocnicze dla węzła Kubernetes

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żych 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 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. Pamiętaj te informacje podczas ustawiania żądań i limitów dla zasobników wdrożonych przez użytkownika.

Aby znaleźć zasoby z możliwością allocatable węzła, uruchom następujące polecenie:

kubectl describe node [NODE_NAME]

Aby zachować wydajność i funkcjonalność węzła, usługa AKS rezerwuje zasoby w każdym węźle. W miarę rozwoju węzła w zasobach rezerwacja zasobów rośnie ze względu na większe zapotrzebowanie na zarządzanie zasobnikami wdrożonym przez użytkownika.

Uwaga

Korzystanie z dodatków usługi AKS, takich jak Container Insights (OMS), spowoduje użycie dodatkowych zasobów węzła.

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ć zmniejszenie możliwości użycia 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.

    1. kubelet Daemon
      Demon kubelet 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 zostanie wyzwolony, aby zakończyć jeden z uruchomionych zasobników i zwolnić pamięć na maszynie hosta.

    2. Regresywna szybkość 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 dobrą kondycję węzłów agenta, w tym niektóre zasobniki systemu hostowania krytyczne dla kondycji klastra.
  • Jeśli węzeł nie będzie częścią klastra Kubernetes, węzeł będzie zgłaszał mniej dostępnej ilości pamięci i procesora CPU niż raport.

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 rezerwuje również ilość zasobów procesora CPU i pamięci w celu obsługi funkcji systemu operacyjnego.

Aby zapoznać się ze skojarzonymi najlepszymi rozwiązaniami, zobacz Najlepsze rozwiązania dotyczące podstawowych funkcji harmonogramu w usłudze AKS.

Pule węzłów

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 podstawowe maszyny wirtualne, na których są uruchamiane 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ła "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, gdzie zasobniki są zaplanowane, 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 grupa zasobów węzła 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 do grupy zasobów węzła jest przypisywana nazwa, taka 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 usuwa 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 zasobów zarządzanych 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 błędy skalowania i uaktualniania. 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.

Typowy scenariusz, w którym klienci chcą modyfikować zasoby, to 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 w celu zastosowania przypisania 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.

Strąków

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 zużywanie 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 podss and Kubernetes pod lifecycle (Cykl życia zasobników kubernetes).

Zasobnik jest zasobem logicznym, ale obciążenia aplikacji są uruchamiane w kontenerach. Zasobniki są zazwyczaj efemeryczne, jednorazowe zasoby. Pojedynczo zaplanowane zasobniki pomijają niektóre funkcje platformy Kubernetes o wysokiej dostępności i nadmiarowości. 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 zapewnia, ż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 zaktualizować 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 na podstawie 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 działa w klastrze. Gdy zasobniki są zaplanowane indywidualnie, nie są uruchamiane ponownie, jeśli napotkają problem i nie są ponownie zaplanowane 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 we wdrożeniu masz pięć (5) replik, możesz zdefiniować zakłócenie zasobnika 4 (cztery), aby zezwolić tylko na usunięcie lub ponowne zaplanowanie jednej repliki naraz. Podobnie jak w przypadku limitów zasobów zasobnika, najlepszym rozwiązaniem jest zdefiniowanie budżetów zakłóceń zasobników w aplikacjach, które wymagają minimalnej liczby replik do zawsze obecnej.

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 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 odpowiadać .spec.template.metadata.labels.
.spec.template.labels Określa pary {key, value} dołączone do obiektu.
.spec.template.app Musi odpowiadać .spec.selector.matchLabels.
.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 adres 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 maksymalną dozwoloną ilość zasobów obliczeniowych. Ten limit jest wymuszany przez polecenie kubelet.
.spec.spec.resources.limits.cpu Określa maksymalną dozwoloną ilość procesora CPU. Ten limit jest wymuszany przez polecenie kubelet.
.spec.spec.resources.limits.memory Określa maksymalną dozwoloną ilość pamięci. Ten limit jest wymuszany przez polecenie 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 pakietów Helm zawierających spakowana wersja kodu aplikacji i manifesty YAML platformy Kubernetes. Pakiety helm można przechowywać lokalnie lub w repozytorium zdalnym, takim jak repozytorium programu Helm Azure Container Registry.

Aby użyć programu Helm, zainstaluj klienta programu 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

Korzystając z 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 idealnym rozwiązaniem w przypadku aplikacji, które wymagają:

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

Jednak dwa zasoby platformy Kubernetes umożliwiają zarządzanie tymi typami aplikacji:

  • StatefulSets utrzymują stan aplikacji poza cykl życia poszczególnych zasobników, takich jak magazyn.
  • Zestawy DaemonSet zapewniają uruchomione wystąpienie na każdym węźle na wczesnym etapie procesu uruchamiania platformy Kubernetes.

Zestawy stanowe

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 przy użyciu elementu 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 stanowym są zaplanowane i uruchamiane w dowolnym dostępnym węźle 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 lub wybranych węzłach. Można użyć narzędzia DaemonSet wdrożyć na co najmniej jednym identycznym zasobniku, ale 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 przed uruchomieniem domyślnego harmonogramu Kubernetes. Dzięki temu zasobniki w zestawie DaemonSet są uruchamiane przed zaplanowaniem tradycyjnych zasobników w elemocie Deployment lub StatefulSet.

Podobnie jak statefulSets, element DaemonSet jest definiowany 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 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.

Przestrzenie nazw kubernetes do logicznego dzielenia zasobów i aplikacji

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

Przestrzeń nazw Opis
default Gdzie zasobniki i wdrożenia są tworzone domyślnie, gdy nie jest podany żaden. 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 usługą kubectl get pods, domyślna przestrzeń nazw jest używana, gdy nie zostanie określona żadna.
kube-system Tam, 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: