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

Programowanie aplikacji nadal przechodzi w kierunku podejścia opartego na kontenerach, zwiększając potrzebę organizowania zasobów i zarządzania nimi. Jako wiodąca platforma Kubernetes zapewnia niezawodne planowanie obciążeń aplikacji odpornych na uszkodzenia. Azure Kubernetes Service (AKS), zarządzana oferta Kubernetes, dodatkowo upraszcza wdrażanie i zarządzanie aplikacjami opartymi na kontenerach.

W tym artykule przedstawiono następujące elementy:

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

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 nią. Platforma Kubernetes obsługuje zarówno aplikacje bezstanowe, jak i stanowe, ponieważ zespoły przechodzą przez wdrożenie 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ą zostać zintegrowane 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łacisz tylko za węzły usługi AKS, które uruchamiają 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: uruchom 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 to sposób uwidocznienia podstawowych interfejsów API platformy Kubernetes. Ten składnik zapewnia interakcję z narzędziami do zarządzania, takimi jak kubectl lub pulpit nawigacyjny Kubernetes.
etcd Aby zachować stan klastra Kubernetes i konfiguracji, wysoka dostępność itd. 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. Określasz liczbę i rozmiar węzłów, a platforma Azure konfiguruje bezpieczną komunikację między płaszczyzną sterowania a 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 Azure Portal. Aby rozwiązać możliwe problemy, możesz przejrzeć dzienniki płaszczyzny sterowania za pośrednictwem 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ę z najlepszymi rozwiązaniami, zobacz Najlepsze rozwiązania dotyczące zabezpieczeń i uaktualnień klastra w usłudze 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 adresami IP dla usług i zasobników.
środowisko uruchomieniowe kontenera Umożliwia konteneryzowanym aplikacjom uruchamianie i interakcję z dodatkowymi zasobami, takimi jak sieć wirtualna i magazyn. Klastry usługi 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 dostępne procesory magazynu, pamięć, rozmiar i typ (na przykład 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. Skaluj w poziomie liczbę węzłów w klastrze usługi AKS, aby zaspokoić zapotrzebowanie.

W usłudze AKS obraz maszyny wirtualnej dla węzłów klastra jest oparty na systemie Ubuntu 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 wdrożonych zasobników 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. W miarę wzrostu rozmiaru węzła w zasobach rezerwacja zasobów rośnie 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 Insights (OMS), będzie zużywać dodatkowe zasoby 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 obejmuje 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 demon ma pamięć.Dostępna<reguła eksmisji 750Mi, zapewniając, kubelet że węzeł musi zawsze mieć co najmniej 750 mi allocatable przez cały czas. Gdy host znajduje się poniżej dostępnego progu pamięci, kubelet wyzwalacz spowoduje zakończenie jednego z uruchomionych zasobników i zwolnienie pamięci na maszynie hosta.

    2. Regresywna szybkość rezerwacji pamięci dla demona kubelet do prawidłowego działania (kube-reserved).

      • 25% z pierwszej 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:

  • Zachowaj kondycję węzłów agenta, w tym niektóre zasobniki systemu hostowania krytyczne dla kondycji klastra.
  • Przyczyna, że węzeł będzie zgłaszać mniej aklakatowalnej pamięci i procesora CPU, niż gdyby nie był częścią klastra Kubernetes.

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 bazowy system operacyjny węzła zastrzega sobie również ilość zasobów procesora CPU i pamięci, aby obsługiwać funkcje 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

Węzły tej samej konfiguracji są zgrupowane 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 skalować lub uaktualnić określoną pulę 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 i zarządzanie nimi.

Selektory węzłów

W klastrze usługi AKS z wieloma pulami węzłów może być konieczne powiedzenie harmonogramowi Kubernetes, który 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, gdzie ma być zaplanowany zasobnik.

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 harmonogramu zasobników, zobacz Best practices for advanced scheduler features in AKS (Najlepsze rozwiązania dotyczące zaawansowanych funkcji harmonogramu w usłudze AKS).

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 przez zaplanowanie uruchamiania zasobników w węźle z dostępnymi zasobami. Można również określić maksymalne limity zasobów, aby zapobiec używaniu 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 Cykl życia zasobników Kubernetes i zasobników Kubernetes.

Zasobnik jest zasobem logicznym, ale obciążenia aplikacji są uruchamiane w kontenerach. Zasobniki są zazwyczaj efemeryczne, jednorazowe zasoby. Indywidualnie zaplanowane zasobniki przegapią 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 na 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 z nowej definicji wdrożenia.
  • Kontynuuje proces do momentu zaktualizowania wszystkich replik we wdrożeniu.

Większość bezstanowych aplikacji 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. Po zaplanowaniu indywidualnie zasobniki nie są uruchamiane ponownie, jeśli wystąpi problem i nie zostaną 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ą liczbę replik we wdrożeniu, które 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 o wartości 4 (cztery), aby umożliwić 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 zawsze obecnych.

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 przestarzałe 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ą wdrażanie znajdowania utworzonych zasobników i zarządzania nimi.
.spec.selector.matchLabels.app Musi być zgodny z .spec.template.metadata.labelsparametrem .
.spec.template.labels Określa pary {key, value} dołączone do obiektu.
.spec.template.app Musi być zgodny z .spec.selector.matchLabelsparametrem .
.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 wymagających:

  • 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 zapewnia, ż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 ograniczyć tworzenie, wyświetlanie lub zarządzanie 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: