Podstawowe pojęcia dotyczące rozwiązania Kubernetes Azure Kubernetes Service (AKS)

Tworzenie aplikacji w dalszym ciągu przechodzi w kierunku podejścia opartego na kontenerach, zwiększając naszą potrzebę organizowania zasobów i zarządzania nimi. Platforma Kubernetes, wiodąca platforma, zapewnia niezawodne planowanie obciążeń aplikacji, które są nieodpowiedzialnościowe. Azure Kubernetes Service (AKS), zarządzana oferta kubernetes, dodatkowo upraszcza wdrażanie aplikacji opartych na kontenerach i zarządzanie nimi.

W tym artykule oprowadzono:

  • Podstawowe składniki infrastruktury kubernetes:
    • płaszczyzna sterowania
    • Węzłów
    • pule węzłów
  • Zasoby obciążenia:
    • Strąków
    • Wdrożeń
    • Ustawia
  • Jak pogrupować 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. Kubernetes koncentruje się na obciążeniach aplikacji, a nie na podstawowych składnikach infrastruktury. Rozwiązanie Kubernetes zapewnia deklaratywne podejście do wdrożeń, oparte na niezawodnym zestawie interfejsów API do operacji zarządzania.

Korzystając z rozwiązania Kubernetes, można tworzyć i uruchamiać nowoczesne, przenośne aplikacje oparte na mikrousługach, a także zarządzać dostępnością składników aplikacji i zarządzać nimi. Usługa Kubernetes obsługuje zarówno aplikacje bez stanowe, jak i stanowe, gdy zespoły będą przechodzić przez proces wdrożenia aplikacji opartych na mikrousługach.

Jako otwarta platforma 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 usługą Kubernetes w celu planowania i wdrażania wydań.

Usługa AKS udostępnia zarządzaną usługę Kubernetes, która zmniejsza złożoność 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, w których są uruchamiane aplikacje. AKS jest zbudowany na podstawie aparatu Azure Kubernetes Service open source: aks-engine.

Architektura klastra Kubernetes

Klaster Kubernetes jest podzielony na dwa składniki:

  • Płaszczyzna sterowania: udostępnia podstawowe usługi Kubernetes i aranżację obciążeń aplikacji.
  • Węzły: uruchamianie obciążeń aplikacji.

Płaszczyzna sterowania i składniki węzła kubernetes

Płaszczyzna sterowania

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

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

Składnik Opis
kube-apiserver Serwer interfejsu API to sposób, w jaki są udostępniane podstawowe interfejsy API platformy Kubernetes. Ten składnik umożliwia interakcję z narzędziami do zarządzania, takimi jak kubectl pulpit nawigacyjny kubernetes.
etcd Aby zachować stan klastra i konfiguracji Kubernetes, wysoce dostępna usługa etcd jest magazynem wartości klucza w ramach usługi 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 kilka mniejszych kontrolerów, które wykonują akcje, takie jak replikowanie zasobników i obsługa operacji węzłów.

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 rozwiązania Kubernetes, takich jak kubectl pulpit nawigacyjny kubernetes.

Nie trzeba konfigurować składników (takich jak magazyn etcd o wysokiej jakości) przy użyciu tej zarządzanej płaszczyzny sterowania, ale nie można uzyskać bezpośredniego dostępu do płaszczyzny sterowania. Uaktualnienia płaszczyzny sterowania i węzła platformy Kubernetes są aranżowane za pomocą interfejsu wiersza polecenia platformy Azure lub Azure Portal. Aby rozwiązać możliwe problemy, możesz przejrzeć dzienniki płaszczyzny sterowania za pośrednictwem Azure Monitor inspekcji.

Aby skonfigurować płaszczyznę sterowania lub uzyskać do niego bezpośredni dostęp, wd wdrażaj własny klaster Kubernetes przy użyciu narzędzia aks-engine.

Aby uzyskać skojarzone najlepsze rozwiązania, zobacz Best practices for cluster security and upgrades in AKS(Najlepsze rozwiązania dotyczące zabezpieczeń i uaktualnień klastra w u usługi AKS).

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

Do uruchamiania aplikacji i usług obsługi potrzebny jest węzeł Kubernetes . Klaster usługi AKS ma co najmniej jeden węzeł, maszynę wirtualną platformy Azure, na których są uruchamiane składniki węzła Kubernetes i środowisko uruchomieniowe kontenera.

Składnik Opis
kubelet Agent kubernetes, który przetwarza żądania aranżacji z płaszczyzny sterowania i planowanie uruchamiania żą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 usługi Kubernetes w wersji 1.19+ dla pul węzłów systemu Linux containerd używają jako środowiska uruchomieniowego kontenera. Począwszy od platformy Kubernetes w wersji 1.20 dla pul węzłów Windows, można jej używać w wersji zapoznawczej dla środowiska uruchomieniowego kontenera, ale docker jest nadal domyślnym środowiskiem containerd uruchomieniowym kontenera. Klastry AKS używające wcześniejszych wersji platformy Kubernetes dla pul węzłów używają platformy Docker jako środowiska uruchomieniowego kontenera.

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

Rozmiar maszyny wirtualnej platformy Azure dla węzłów definiuje dostępne procesory CPU magazynu, pamięć, rozmiar i typ (na przykład dysk SSD o wysokiej wydajności lub zwykły dysk twardy). Zaplanuj rozmiar węzła wokół tego, czy aplikacje mogą wymagać dużych ilości procesora CPU i pamięci, czy magazynu o wysokiej wydajności. Skaluj w celu spełnienia wymagań liczbę węzłów w klastrze usługi AKS.

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

Wd wdrażaj własny klaster Kubernetes za pomocą narzędzia aks-engine, jeśli używasz innego systemu operacyjnego hosta, środowiska uruchomieniowego kontenera lub innych pakietów niestandardowych. Nadrzędne wersje funkcji i zapewniają opcje konfiguracji aks-engine przed obsługą w klastrach usługi AKS. Jeśli więc chcesz użyć środowiska uruchomieniowego kontenera innego niż lub docker, możesz uruchomić program , aby skonfigurować i wdrożyć klaster containerd aks-engine Kubernetes, który spełnia bieżące potrzeby.

Rezerwacje zasobów

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

Aby znaleźć przydzielone zasoby węzła, uruchom:

kubectl describe node [NODE_NAME]

Aby zachować wydajność i funkcjonalność węzłów, aks rezerwuje zasoby w każdym węźle. Wraz ze wzrostem ilości zasobów w węźle rezerwacja zasobów rośnie ze względu na większe potrzeby zarządzania zasobnikami wdrożonymi przez użytkownika.

Uwaga

Użycie dodatków usługi AKS, takich jak container Szczegółowe informacje (OMS), spowoduje zuż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 powodować mniejsze przydzielanie procesora CPU z powodu uruchamiania dodatkowych funkcji.

    Rdzenie procesora CPU na hoście 1 2 4 8 16 32 64
    Zarezerwowane kube (w milirdzeniach) 60 100 140 180 260 420 740
  • Pamięć
    Pamięć wykorzystywana przez zestaw AKS zawiera sumę dwóch wartości.

    1. kubelet Daemon
      Demon jest instalowany na wszystkich węzłach agenta kubernetes w celu zarządzania kubelet tworzeniem i zakończeniem działania kontenera.

      Domyślnie w uchwale AKS demon ma regułę eksmisji kubelet memory.available<750Mi, co gwarantuje, że węzeł zawsze musi mieć co najmniej 750 MI przydzielanych przez cały czas. Gdy host jest poniżej progu dostępnej pamięci, wyzwalacz wyzwoli zakończenie działania jednego z uruchomionych zasobników i zwalnianie pamięci kubelet na maszynie hosta.

    2. Regressive rate of memory reservations for the kubelet daemon to properly function (kube-reserved).

      • 25% pierwszych 4 GB pamięci
      • 20% z następnych 4 GB pamięci (do 8 GB)
      • 10% z następnych 8 GB pamięci (do 16 GB)
      • 6% kolejnych 112 GB pamięci (do 128 GB)
      • 2% dowolnej pamięci powyżej 128 GB

Reguły alokacji pamięci i procesora CPU:

  • Utrzymuj w dobrej kondycji węzły agenta, w tym niektóre zasobniki systemu hostingu krytyczne dla kondycji klastra.
  • Powoduje, że węzeł zgłasza mniej przydzielonej pamięci i procesora 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łasza 34% pamięci, do których nie można przydzielić, w tym próg twardego 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 kubernetes podstawowy system operacyjny węzła rezerwuje również ilość zasobów procesora CPU i pamięci do obsługi funkcji systemu operacyjnego.

Aby uzyskać skojarzone najlepsze rozwiązania, zobacz Best practices for basic scheduler features in AKS (Najlepsze rozwiązania dotyczące podstawowych funkcji harmonogramu w ucieku AKS).

Pule węzłów

Węzły tej samej konfiguracji są grupowane 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 u usługi AKS zawiera bazowe maszyny wirtualne, na których działają 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ć względem domyślnej puli węzłów. Możesz skalować lub uaktualniać określoną pulę węzłów. W przypadku operacji uaktualniania uruchamianie kontenerów jest zaplanowane w 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 u usługi AKS, zobacz Create and manage multiple node pools for a cluster in AKS (Tworzenie wielu pul węzłów dla klastra i zarządzanie nimi w u usługi AKS).

Selektory węzłów

W klastrze usługi AKS z wieloma pulami węzłów może być konieczne poinformuj harmonogram usługi Kubernetes, której puli węzłów użyć dla danego zasobu. Na przykład kontrolery ruchu przychodzących nie powinny być uruchamiane w węzłach Windows Server.

Selektory węzłów umożliwiają definiowanie różnych parametrów, takich jak system operacyjny węzła, w celu kontrolowania, gdzie powinien być zaplanowany zasobnik.

Poniższy podstawowy przykład planuje wystąpienie serwera 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 sposobu kontrolowania, gdzie zaplanowano zasobniki, zobacz Najlepsze rozwiązania dotyczące zaawansowanych funkcji harmonogramu w u użytkownikach AKS.

Strąków

W przypadku usługi Kubernetes zasobniki są używane do uruchamiania wystąpienia aplikacji. Zasobnik reprezentuje pojedyncze wystąpienie aplikacji.

Zasobniki zwykle mają mapowanie 1:1 z kontenerem. W zaawansowanych scenariuszach zasobnik może zawierać wiele kontenerów. Zasobniki z wieloma kontenerami są planowane razem w tym samym węźle i umożliwiają kontenerom współużytkują powiązane zasoby.

Podczas tworzenia zasobnika można zdefiniować żądania zasobów w celu żądania 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ędnianie limitów zasobów dla wszystkich zasobników, aby ułatwić harmonogramowi kubernetes identyfikowanie niezbędnych, dozwolonych zasobów.

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

Zasobnik jest zasobem logicznym, ale obciążenia aplikacji są uruchamiane w kontenerach. Zasobniki są zwykle efemerymi, jednorazowymi zasobami. Poszczególne zaplanowane zasobniki pomijają niektóre funkcje wysokiej dostępności i nadmiarowości usługi 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 kubernetes. Wdrożenie definiuje liczbę replik zasobników do utworzenia. Harmonogram usługi Kubernetes zapewnia zaplanowanie dodatkowych zasobników w węzłach w dobrej kondycji, jeśli zasobniki lub węzły napotkają problemy.

Wdrożenia można aktualizować w celu zmiany konfiguracji zasobników, używanego obrazu kontenera lub dołączonego magazynu. Kontroler wdrożenia:

  • Opróżnia i kończy działanie danej liczby replik.
  • Tworzy repliki z nowej definicji wdrożenia.
  • Kontynuuje proces do momentu zaktualizowania wszystkich replik we wdrożeniu.

Większość aplikacji bez stanowych w użytce AKS powinna używać modelu wdrażania, a nie planowania poszczególnych zasobników. Usługa Kubernetes może monitorować kondycję i stan wdrożenia, aby upewnić się, że wymagana liczba replik jest uruchamiana w klastrze. W przypadku indywidualnego harmonogramu zasobniki nie są ponownie uruchamiane, jeśli napotkają problem, i nie są ponownie planowane 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 przy użyciu procesu aktualizacji, jeśli aplikacja wymaga minimalnej liczby dostępnych wystąpień. Budżety przerw w działaniu zasobników definiują, ile replik we wdrożeniu można z niej zdjąć podczas aktualizacji lub uaktualniania węzła. Jeśli na przykład w swoim wdrożeniu masz pięć (5) replik, możesz zdefiniować przerwy w działaniu zasobnika na poziomie 4 (cztery), aby zezwolić na usunięcie lub ponowne wdrożenie tylko jednej repliki na raz. Podobnie jak w przypadku limitów zasobów zasobników, najlepszym rozwiązaniem jest zdefiniowanie budżetów przerw w działaniu zasobników w aplikacjach, które wymagają minimalnej liczby replik, aby zawsze były obecne.

Wdrożenia są zwykle tworzone i zarządzane za pomocą programu kubectl create 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ż zdefiniowane 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

Bardziej złożone aplikacje można tworzyć, uwzględniając usługi (takie jak usługi równoważenia obciążenia) w manifeście YAML.

Aby uzyskać więcej informacji, zobacz Wdrożenia rozwiązania Kubernetes.

Zarządzanie pakietami za pomocą helm

Program Helm jest często używany do zarządzania aplikacjami na kubernetes. Zasoby można wdrażać, budowania i używania istniejących publicznych wykresów programu Helm, które zawierają spakowana wersję kodu aplikacji i manifesty YAML rozwiązania Kubernetes. Wykresy programu Helm można przechowywać lokalnie lub w repozytorium zdalnym, takim jak Azure Container Registry repozytorium chart programu Helm.

Aby użyć programu Helm, zainstaluj klienta programu Helm na komputerze lub użyj klienta Helm w Azure Cloud Shell . Wyszukaj lub utwórz wykresy Helm, a następnie zainstaluj je w klastrze Kubernetes. Aby uzyskać więcej informacji, zobacz Install existing applications with Helm in AKS (Instalowanie istniejących aplikacji za pomocą programu Helm w UKS).

Zestawy 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 bez stanowych, 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.

Dwa zasoby kubernetes umożliwiają jednak zarządzanie tymi typami aplikacji:

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

Zestawy stanowe

Tworzenie nowoczesnych aplikacji często ma na celu zastosowanie w aplikacjach bez stanowych. W przypadku aplikacji stanowych, takich jak te, które zawierają składniki bazy danych, można użyć zestawu StatefulSets. Podobnie jak wdrożenia, zestaw StatefulSet tworzy co najmniej jeden identyczny zasobnik i zarządza nimi. Repliki w zestawie StatefulSet są zgodne z graceful, sekwencyjnym podejściem do wdrażania, skalowania, uaktualniania i zakończenia. Konwencja nazewnictwa, nazwy sieciowe i magazyn są utrwalane, gdy repliki są ponownie projektowane przy użyciu zestawu statefulSet.

Zdefiniuj aplikację w formacie YAML przy użyciu . kind: StatefulSet Z tego wystąpienia kontroler StatefulSet obsługuje wdrażanie wymaganych replik i zarządzanie nimi. Dane są zapisywane w magazynie trwałym dostarczanym przez usługę Azure Dyski zarządzane lub Azure Files. W przypadku elementów StatefulSets podstawowy magazyn trwały pozostaje, nawet po usunięciu zestawu StatefulSet.

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 działa w węźle, należy zamiast tego użyć zestawu DaemonSet.

DaemonSets

W przypadku określonej kolekcji lub monitorowania dzienników może być konieczne uruchomienie zasobnika we wszystkich węzłach lub wybranych węzłach. Możesz użyć wdrożenia daemonSet w co najmniej jednym identycznym zasobniku, ale kontroler DaemonSet zapewnia, że każdy określony węzeł uruchamia wystąpienie zasobnika.

Kontroler DaemonSet może zaplanować zasobniki na węzłach na wczesnym etapie procesu rozruchu klastra przed uruchomieniem domyślnego harmonogramu Kubernetes. Ta możliwość zapewnia, że zasobniki w daemonSet są uruchomione przed zaplanowaniem tradycyjnych zasobników w deployment lub StatefulSet.

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

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

Uwaga

W przypadku korzystania z dodatku Węzły wirtualnezestawy DaemonSets nie będą tworzyć zasobników w węźle wirtualnym.

Przestrzenie nazw

Zasoby usługi Kubernetes, takie jak zasobniki i wdrożenia, są logicznie pogrupowane w przestrzeni nazw, aby podzielić klaster usługi AKS i ograniczyć dostęp do zasobów oraz tworzyć, wyświetlać i zarządzać nimi. Można na przykład tworzyć przestrzenie nazw w celu oddzielenia grup biznesowych. Użytkownicy mogą wchodzić w interakcje tylko z zasobami w ramach przypisanych im przestrzeni nazw.

Przestrzenie nazw kubernetes do logicznego dzielenia zasobów i aplikacji

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

Przestrzeń nazw Opis
default Zasobniki i wdrożenia są tworzone domyślnie, gdy nie zostaną podane żadne. W mniejszych środowiskach można wdrażać aplikacje bezpośrednio w domyślnej przestrzeni nazw bez tworzenia dodatkowych odeparowania logicznych. Podczas interakcji z interfejsem API Kubernetes, takim jak za pomocą usługi , domyślna przestrzeń nazw jest używana, kubectl get pods gdy nie zostanie określona żadna przestrzeń nazw.
kube-system Istnieją podstawowe zasoby, takie jak funkcje sieciowe, takie jak system DNS i serwer proxy, lub pulpit nawigacyjny rozwiązania Kubernetes. Zazwyczaj nie wdraża się własnych aplikacji w tej przestrzeni nazw.
kube-public Zwykle nie jest używana, ale może służyć do wyświetlania zasobów w całym klastrze i wyświetlania ich 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 kubernetes i sposób ich stosowania w klastrach usługi AKS. Aby uzyskać więcej informacji na temat podstawowych pojęć dotyczących rozwiązania Kubernetes i AKS, zobacz następujące artykuły: