Základní koncepty Kubernetes pro Azure Kubernetes Service

Vývoj aplikací se stále přesouvá k přístupu založenému na kontejnerech a zvyšuje potřebu orchestrace a správy prostředků. Jako přední platforma poskytuje Kubernetes spolehlivé plánování úloh aplikací odolných proti chybám. Azure Kubernetes Service (AKS), spravovaná nabídka Kubernetes, dále zjednodušuje nasazování a správu aplikací založených na kontejnerech.

Tento článek představuje základní koncepty:

• Komponenty infrastruktury Kubernetes:

  • řídicí rovina
  • Uzly
  • Fondy uzlů

• Prostředky úloh:

  • Lusky
  • Nasazení
  • Nastaví

• Seskupte prostředky pomocí oborů názvů.

Co je Kubernetes?

Kubernetes je rychle se vyvíjející platforma, která spravuje aplikace založené na kontejnerech a související síťové a úložné komponenty. Kubernetes se zaměřuje na úlohy aplikací, ne na základní komponenty infrastruktury. Kubernetes poskytuje deklarativní přístup k nasazením, který je zajištěn robustní sadou rozhraní API pro operace správy.

Pomocí Kubernetes můžete vytvářet a spouštět moderní, přenosné aplikace založené na mikroslužbách a orchestrovat a spravovat dostupnost komponent aplikace. Kubernetes podporuje bezstavové i stavové aplikace, protože týmy procházejí přijetím aplikací založených na mikroslužbách.

Kubernetes jako otevřená platforma umožňuje vytvářet aplikace pomocí preferovaného programovacího jazyka, operačního systému, knihoven nebo sběrnice pro zasílání zpráv. Stávající nástroje pro kontinuální integraci a průběžné doručování (CI/CD) se můžou integrovat s Kubernetes a plánovat a nasazovat vydané verze.

AKS poskytuje spravovanou službu Kubernetes, která snižuje složitost úloh nasazení a základní správy, jako je koordinace upgradu. Platforma Azure spravuje řídicí rovinu AKS a platíte jenom za uzly AKS, které spouští vaše aplikace.

Architektura clusteru Kubernetes

Cluster Kubernetes je rozdělený na dvě komponenty:

• Řídicí rovina: poskytuje základní služby Kubernetes a orchestraci aplikačních úloh.
• Uzly: Spusťte úlohy aplikace.

Řídicí rovina

Při vytváření clusteru AKS se automaticky vytvoří a nakonfiguruje řídicí rovina. Tato řídicí rovina se dodává zdarma jako spravovaný prostředek Azure abstrahovaný od uživatele. Platíte jen za uzly připojené ke clusteru AKS. Řídicí rovina a její prostředky se nacházejí jen v oblasti, ve které jste cluster vytvořili.

Řídicí rovina zahrnuje následující základní komponenty Kubernetes:

Komponenta	Popis
kube-apiserver	Server rozhraní API je způsob, jakým jsou podkladová rozhraní API Kubernetes vystavená. Tato komponenta poskytuje interakci s nástroji pro správu, jako kubectl je řídicí panel Kubernetes.
atd.	Pokud chcete zachovat stav clusteru a konfigurace Kubernetes, vysoce dostupný atd. je úložiště klíčových hodnot v rámci Kubernetes.
kube-scheduler	Při vytváření nebo škálování aplikací plánovač určuje, které uzly můžou spouštět úlohy a spouštět je.
kube-controller-manager	Správce kontroleru dohlíží na řadu menších kontrolerů, které provádějí akce, jako je replikace podů a zpracování operací uzlů.

AKS poskytuje řídicí rovinu s jedním tenantem s vyhrazeným serverem rozhraní API, plánovačem atd. Definujete počet a velikost uzlů a platforma Azure nakonfiguruje zabezpečenou komunikaci mezi řídicí rovinou a uzly. Interakce s řídicí rovinou probíhá prostřednictvím rozhraní API Kubernetes, jako kubectl je řídicí panel Kubernetes.

I když s touto spravovanou řídicí rovinou nemusíte konfigurovat komponenty (jako je úložiště s vysokou dostupností atd. ), nemůžete k řídicí rovině přistupovat přímo. Řídicí rovina Kubernetes a upgrady uzlů se orchestrují prostřednictvím Azure CLI nebo webu Azure Portal. Pokud chcete vyřešit možné problémy, můžete si projít protokoly řídicí roviny prostřednictvím protokolů služby Azure Monitor.

Pokud chcete nakonfigurovat řídicí rovinu nebo získat přímý přístup k řídicí rovině, nasaďte cluster Kubernetes s využitím poskytovatele rozhraní API clusteru Azure.

Přidružené osvědčené postupy najdete v tématu Osvědčené postupy pro zabezpečení a upgrady clusteru v AKS.

Informace o správě nákladů AKS najdete v tématu Základy nákladů AKS a Ceny pro AKS.

Uzly a fondy uzlů

Ke spouštění aplikací a podpůrných služeb potřebujete uzel Kubernetes. Cluster AKS má alespoň jeden uzel, virtuální počítač Azure, na kterém běží komponenty uzlu Kubernetes a modul runtime kontejneru.

Komponenta	Popis
kubelet	Agent Kubernetes, který zpracovává požadavky orchestrace z řídicí roviny spolu s plánováním a spouštěním požadovaných kontejnerů.
kube-proxy	Zpracovává virtuální sítě na každém uzlu. Proxy směruje síťový provoz a spravuje přidělování IP adres pro služby a pody.
modul runtime kontejneru	Umožňuje kontejnerizovaným aplikacím spouštět a pracovat s dalšími prostředky, jako jsou virtuální síť nebo úložiště. Clustery AKS využívající Kubernetes verze 1.19 nebo novější pro fondy uzlů Linuxu se používají containerd jako modul runtime kontejneru. Počínaje kubernetes verze 1.20 pro fondy containerd uzlů Windows se dá použít ve verzi Preview pro modul runtime kontejneru, ale Docker je stále výchozím modulem runtime kontejneru. Clustery AKS využívající předchozí verze Kubernetes pro fondy uzlů používají Jako modul runtime kontejneru Docker.

Velikost virtuálního počítače Azure pro vaše uzly definuje procesory, paměť, velikost a dostupný typ úložiště (například vysoce výkonný disk SSD nebo běžný pevný disk). Naplánujte velikost uzlu tak, aby vaše aplikace mohly vyžadovat velké množství procesoru a paměti nebo vysoce výkonného úložiště. Vertikálně navyšte kapacitu počtu uzlů v clusteru AKS, aby se splnila poptávka. Další informace o škálování najdete v tématu Možnosti škálování pro aplikace v AKS.

V AKS je image virtuálního počítače pro uzly vašeho clusteru založená na Ubuntu Linuxu, Azure Linuxu nebo Windows Serveru 2019. Když vytvoříte cluster AKS nebo škálujete počet uzlů, platforma Azure automaticky vytvoří a nakonfiguruje požadovaný počet virtuálních počítačů. Uzly agentů se účtují jako standardní virtuální počítače, takže se automaticky použijí slevy na velikost virtuálních počítačů (včetně rezervací Azure).

U spravovaných disků se výchozí velikost a výkon disku přiřadí podle vybrané skladové položky virtuálního počítače a počtu vCPU. Další informace naleznete v tématu Výchozí nastavení velikosti disku s operačním systémem.

Pokud potřebujete pokročilou konfiguraci a kontrolu nad modulem runtime kontejneru uzlů Kubernetes a operačním systémem, můžete nasadit cluster s využitím poskytovatele rozhraní API clusteru Azure.

Rezervace prostředků

AKS používá prostředky uzlů, které pomáhají funkci uzlu v rámci clusteru. Toto využití může způsobit nesrovnalosti mezi celkovými prostředky vašeho uzlu a přidělováním prostředků v AKS. Při nastavování požadavků a omezení pro pody nasazené uživatelem si tyto informace zapamatujte.

Pokud chcete najít akopatelné prostředky uzlu, spusťte:

kubectl describe node [NODE_NAME]

Aby se zachoval výkon a funkčnost uzlů, AKS si na každém uzlu vyhrazuje prostředky. Vzhledem k tomu, že uzel roste ve větších prostředcích, rezervace prostředků roste kvůli vyšší potřebě správy podů nasazených uživatelem.

Poznámka:

Použití doplňků AKS, jako je kontejnerová Přehledy (OMS), bude využívat další prostředky uzlů.

Rezervované jsou dva typy prostředků:

Procesor

Vyhrazený procesor závisí na typu uzlu a konfiguraci clusteru, což může způsobit méně přidělené procesory kvůli spouštění dalších funkcí.

Jádra procesoru na hostiteli	1	2	4	8	16	32	64
Kube-reserved (millicores)	60	100	140	180	260	420	740

Memory (Paměť)

Paměť využívaná službou AKS zahrnuje součet dvou hodnot.

Důležité

Verze Preview AKS 1.29 v lednu 2024 a zahrnují určité změny rezervací paměti. Tyto změny jsou podrobně popsané v následující části.

AKS 1.29 a novější

1. kubelet Démon má ve výchozím nastavení pravidlo vyřazení paměti.available<100Mi. Tím se zajistí, že uzel bude mít vždy aspoň 100Mi alokovatelný. Pokud je hostitel nižší než prahová hodnota dostupné paměti, kubelet aktivuje ukončení jednoho ze spuštěných podů a uvolní paměť na hostitelském počítači.

2. Frekvence rezervací paměti nastavená na nižší hodnotu: 20 MB * Maximální počet podů podporovaných na uzlu + 50 MB nebo 25 % celkových systémových paměťových prostředků.

   Příklady:

   • Pokud virtuální počítač poskytuje 8 GB paměti a uzel podporuje až 30 podů, AKS si rezervuje 20 MB × 30 maximálních podů + 50 MB = 650 MB pro kube-reserved. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Pokud virtuální počítač poskytuje 4 GB paměti a uzel podporuje až 70 podů, AKS si rezervuje 25 % × 4 GB = 1000 MB pro kube-reserved, protože je menší než 20 MB × 70 Maximální počet podů + 50 MB = 1450 MB.

   Další informace najdete v tématu Konfigurace maximálního počtu podů na uzel v clusteru AKS.

Verze AKS starší než 1.29

1. kubelet Proces démon je nainstalovaný na všech uzlech agenta Kubernetes pro správu vytváření a ukončení kontejneru. Ve výchozím nastavení má proces démon v AKS pravidlo vyřazení paměti.available<750Mi, které zajišťuje, kubelet že uzel musí mít vždy aspoň 750Mi alokovatelné. Pokud je hostitel nižší než prahová hodnota dostupné paměti, kubelet aktivuje se ukončení jednoho ze spuštěných podů a uvolnění paměti na hostitelském počítači.

2. Regresní rychlost rezervací paměti pro démon kubelet správně fungovat (kube-reserved).

   • 25 % z prvních 4 GB paměti
   • 20 % z dalších 4 GB paměti (až 8 GB)
   • 10 % z dalších 8 GB paměti (až 16 GB)
   • 6 % z dalších 112 GB paměti (až 128 GB)
   • 2 % jakékoli paměti nad 128 GB

Poznámka:

AKS si v uzlech Windows rezervuje další 2 GB pro systémový proces, který není součástí počítané paměti.

Pravidla přidělování paměti a procesoru jsou navržená tak, aby postupovat takto:

• Udržujte uzly agentů v pořádku, včetně některých podů hostitelského systému, které jsou důležité pro stav clusteru.
• Způsobit, že uzel hlásí méně paměti a procesoru, než kdyby nebyl součástí clusteru Kubernetes.

Výše uvedené rezervace prostředků není možné změnit.

Pokud například uzel nabízí 7 GB, bude hlásit 34 % paměti, které nelze přidělovat, včetně prahové hodnoty 750Mi pevného vyřazení.

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

Kromě rezervací pro samotný Kubernetes si základní operační systém uzlu také vyhrazuje množství prostředků procesoru a paměti pro údržbu funkcí operačního systému.

Přidružené osvědčené postupy najdete v tématu Osvědčené postupy pro základní funkce plánovače v AKS.

Fondy uzlů

Poznámka:

Fond uzlů Azure s Linuxem je teď obecně dostupný (GA). Další informace o výhodách a postupu nasazení najdete v tématu Úvod do služby Azure Linux Container Host for AKS.

Uzly stejné konfigurace jsou seskupené do fondů uzlů. Cluster Kubernetes obsahuje alespoň jeden fond uzlů. Počáteční počet uzlů a velikost jsou definovány při vytváření clusteru AKS, který vytvoří výchozí fond uzlů. Tento výchozí fond uzlů v AKS obsahuje základní virtuální počítače, na kterých běží uzly agenta.

Poznámka:

Pokud chcete zajistit, aby cluster fungoval spolehlivě, měli byste ve výchozím fondu uzlů spustit alespoň dva (2) uzly.

Cluster AKS škálujete nebo upgradujete na výchozí fond uzlů. Můžete se rozhodnout škálovat nebo upgradovat konkrétní fond uzlů. V případě operací upgradu jsou spuštěné kontejnery naplánované na jiných uzlech ve fondu uzlů, dokud se všechny uzly úspěšně neupgradují.

Další informace o použití více fondů uzlů v AKS naleznete v tématu Vytvoření více fondů uzlů pro cluster v AKS.

Selektory uzlů

V clusteru AKS s více fondy uzlů možná budete muset sdělit plánovači Kubernetes, který fond uzlů se má pro daný prostředek použít. Kontrolery příchozího přenosu dat by například neměly běžet na uzlech Windows Serveru.

Selektory uzlů umožňují definovat různé parametry, jako je operační systém uzlu, a řídit, kde má být pod naplánován.

Následující základní příklad naplánuje instanci NGINX na linuxovém uzlu pomocí selektoru uzlu "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

Další informace o tom, jak řídit, kde jsou pody naplánované, najdete v tématu Osvědčené postupy pro pokročilé funkce plánovače v AKS.

Skupina prostředků uzlu

Při vytváření clusteru AKS je potřeba zadat skupinu prostředků, ve které se má prostředek clusteru vytvořit. Kromě této skupiny prostředků poskytovatel prostředků AKS také vytvoří a spravuje samostatnou skupinu prostředků označovanou jako skupina prostředků uzlu. Skupina prostředků uzlu obsahuje následující prostředky infrastruktury:

• Škálovací sady virtuálních počítačů a virtuální počítače pro každý uzel ve fondech uzlů
• Virtuální síť pro cluster
• Úložiště pro cluster

Skupina prostředků uzlu má ve výchozím nastavení přiřazený název, například MC_myResourceGroup_myAKSCluster_eastus. Během vytváření clusteru máte také možnost zadat název přiřazený skupině prostředků uzlu. Když odstraníte cluster AKS, poskytovatel prostředků AKS automaticky odstraní skupinu prostředků uzlu.

Skupina prostředků uzlu má následující omezení:

• Pro skupinu prostředků uzlu nemůžete zadat existující skupinu prostředků.
• Pro skupinu prostředků uzlu nemůžete zadat jiné předplatné.
• Po vytvoření clusteru nemůžete změnit název skupiny prostředků uzlu.
• Nemůžete zadat názvy spravovaných prostředků ve skupině prostředků uzlu.
• Ve skupině prostředků uzlu nemůžete upravovat ani odstraňovat značky spravovaných prostředků vytvořených v Azure.

Pokud upravíte nebo odstraníte značky vytvořené v Azure a další vlastnosti prostředku ve skupině prostředků uzlu, můžou se zobrazit neočekávané výsledky, například chyby škálování a upgradu. Vzhledem k tomu, že AKS spravuje životní cyklus infrastruktury ve skupině prostředků uzlu, všechny změny přesunou cluster do nepodporovaného stavu.

Běžným scénářem, ve kterém zákazníci chtějí upravovat prostředky, jsou prostřednictvím značek. AKS umožňuje vytvářet a upravovat značky, které se šíří do prostředků ve skupině prostředků uzlu, a tyto značky můžete přidat při vytváření nebo aktualizaci clusteru. Můžete chtít vytvořit nebo upravit vlastní značky, například přiřadit obchodní jednotku nebo nákladové středisko. Toho lze dosáhnout také vytvořením zásad Azure s oborem ve spravované skupině prostředků.

Úprava všech značek vytvořených v Azure u prostředků ve skupině prostředků uzlu v clusteru AKS je nepodporovaná akce, která přeruší cíl na úrovni služby (SLO). Další informace najdete v tématu Nabízí AKS smlouvu o úrovni služeb?

Pokud chcete snížit pravděpodobnost změn ve skupině prostředků uzlu, které ovlivňují vaše clustery, můžete povolit uzamčení skupiny prostředků uzlu, aby u prostředků AKS použilo přiřazení zamítnutí. Další informace najdete v konfiguraci clusteru v AKS.

Upozorňující

Pokud nemáte povolený uzamčení skupiny prostředků uzlu, můžete přímo upravit libovolný prostředek ve skupině prostředků uzlu. Přímé úpravy prostředků ve skupině prostředků uzlu můžou způsobit nestabilitu clusteru nebo nereagování.

Pody

Kubernetes používá pody ke spuštění instance vaší aplikace. Pod představuje jednu instanci vaší aplikace.

Pody mají obvykle mapování 1:1 s kontejnerem. V pokročilých scénářích může pod obsahovat více kontejnerů. Pody s více kontejnery jsou naplánované společně na stejném uzlu a umožňují kontejnerům sdílet související prostředky.

Při vytváření podu můžete definovat požadavky na prostředky pro vyžádání určitého množství prostředků procesoru nebo paměti. Plánovač Kubernetes se pokusí splnit požadavek tím, že naplánuje spuštění podů na uzlu s dostupnými prostředky. Můžete také zadat maximální limity prostředků, abyste zabránili tomu, aby pod spotřeboval příliš mnoho výpočetních prostředků ze základního uzlu. Osvědčeným postupem je zahrnout omezení prostředků pro všechny pody, které plánovači Kubernetes pomůžou identifikovat nezbytné a povolené prostředky.

Další informace najdete v tématu o životním cyklu podů Kubernetes a Kubernetes.

Pod je logický prostředek, ale úlohy aplikací běží na kontejnerech. Pody jsou obvykle dočasné a uvolnitelné prostředky. Jednotlivé naplánované pody chybí některé z funkcí Kubernetes s vysokou dostupností a redundancí. Místo toho se pody nasazují a spravují kontrolery Kubernetes, například kontrolerem nasazení.

Nasazení a manifesty YAML

Nasazení představuje identické pody spravované kontrolerem nasazení Kubernetes. Nasazení definuje počet replik podů, které se mají vytvořit. Plánovač Kubernetes zajišťuje, že jsou na uzlech v pořádku naplánované další pody, pokud dojde k problémům s pody nebo uzly.

Nasazení můžete aktualizovat a změnit konfiguraci podů, použitých imagí kontejneru nebo připojeného úložiště. Kontroler nasazení:

• Vyprázdní a ukončí daný počet replik.
• Vytvoří repliky z nové definice nasazení.
• Pokračuje v procesu, dokud nebudou aktualizovány všechny repliky v nasazení.

Většina bezstavových aplikací v AKS by měla místo plánování jednotlivých podů používat model nasazení. Kubernetes může monitorovat stav nasazení a stav, aby se zajistilo, že se v clusteru spustí požadovaný počet replik. Při individuálním naplánování se pody nerestartují, pokud narazí na problém, a pokud jejich aktuální uzel narazí na problém, nepřeplánují se na uzlech, které jsou v pořádku.

Pokud vaše aplikace vyžaduje minimální počet dostupných instancí, nechcete rušit rozhodování o správě procesem aktualizace. Rozpočty přerušení podů definují, kolik replik v nasazení je možné během aktualizace nebo upgradu uzlu snížit. Pokud máte například v nasazení pět (5) replik, můžete definovat přerušení podu 4 (čtyři), které umožní odstranění nebo přeplánování jedné repliky najednou. Stejně jako u limitů prostředků podů je osvědčeným postupem definovat rozpočty přerušení podů u aplikací, které vyžadují, aby byl vždy k dispozici minimální počet replik.

Nasazení se obvykle vytvářejí a spravují pomocí kubectl create nebo kubectl apply. Vytvořte nasazení definováním souboru manifestu ve formátu YAML.

Následující příklad vytvoří základní nasazení webového serveru NGINX. Nasazení určuje tři (3) repliky, které se mají vytvořit, a vyžaduje otevření portu 80 v kontejneru. Požadavky na prostředky a omezení jsou také definovány pro procesor a paměť.

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

Rozpis specifikací nasazení v souboru manifestu YAML je následující:

Specifikace	Popis
.apiVersion	Určuje skupinu rozhraní API a prostředek rozhraní API, které chcete použít při vytváření prostředku.
.kind	Určuje typ prostředku, který chcete vytvořit.
.metadata.name	Určuje název nasazení. Tento soubor spustí image nginx z Docker Hubu.
.spec.replicas	Určuje, kolik podů se má vytvořit. Tento soubor vytvoří tři duplicitní pody.
.spec.selector	Určuje, které pody budou tímto nasazením ovlivněny.
.spec.selector.matchLabels	Obsahuje mapu párů {klíč, hodnota} , které umožňují nasazení najít a spravovat vytvořené pody.
.spec.selector.matchLabels.app	Musí se shodovat .spec.template.metadata.labels.
.spec.template.labels	Určuje páry {key, value} připojené k objektu.
.spec.template.app	Musí se shodovat .spec.selector.matchLabels.
.spec.spec.containers	Určuje seznam kontejnerů patřících podu.
.spec.spec.containers.name	Určuje název kontejneru určeného jako popisek DNS.
.spec.spec.containers.image	Určuje název image kontejneru.
.spec.spec.containers.ports	Určuje seznam portů, které se mají zveřejnit z kontejneru.
.spec.spec.containers.ports.containerPort	Určuje počet portů, které se mají zveřejnit na IP adrese podu.
.spec.spec.resources	Určuje výpočetní prostředky vyžadované kontejnerem.
.spec.spec.resources.requests	Určuje minimální požadovaný počet výpočetních prostředků.
.spec.spec.resources.requests.cpu	Určuje minimální požadovaný počet procesoru.
.spec.spec.resources.requests.memory	Určuje minimální požadovaný počet paměti.
.spec.spec.resources.limits	Určuje maximální povolený počet výpočetních prostředků. Tento limit vynucuje kubelet.
.spec.spec.resources.limits.cpu	Určuje maximální povolenou velikost procesoru. Tento limit vynucuje kubelet.
.spec.spec.resources.limits.memory	Určuje maximální povolenou velikost paměti. Tento limit vynucuje kubelet.

Složitější aplikace je možné vytvořit zahrnutím služeb (například nástrojů pro vyrovnávání zatížení) v manifestu YAML.

Další informace najdete v tématu Nasazení Kubernetes.

Správa balíčků pomocí Nástroje Helm

Helm se běžně používá ke správě aplikací v Kubernetes. Prostředky můžete nasadit sestavením a použitím existujících veřejných grafů Helm, které obsahují zabalenou verzi kódu aplikace a manifestů YAML Kubernetes. Grafy Helm můžete ukládat místně nebo ve vzdáleném úložišti, jako je úložiště chartů Helm služby Azure Container Registry.

Pokud chcete použít Helm, nainstalujte klienta Helm do počítače nebo použijte klienta Helm v Azure Cloud Shellu. Vyhledejte nebo vytvořte charty Helm a pak je nainstalujte do clusteru Kubernetes. Další informace najdete v tématu Instalace existujících aplikací pomocí nástroje Helm v AKS.

StatefulSets a DaemonSets

Pomocí plánovače Kubernetes spouští kontroler nasazení repliky na libovolném dostupném uzlu s dostupnými prostředky. I když tento přístup může být dostatečný pro bezstavové aplikace, řadič nasazení není ideální pro aplikace, které vyžadují:

• Trvalé zásady vytváření názvů nebo úložiště.
• Replika, která existuje na každém vybraném uzlu v clusteru.

Dva prostředky Kubernetes ale umožňují spravovat tyto typy aplikací:

• Stavové sady udržují stav aplikací nad rámec životního cyklu jednotlivých podů .
• DaemonSets zajišťují spuštěnou instanci na každém uzlu v rané fázi procesu bootstrap Kubernetes.

Stavové sady

Moderní vývoj aplikací se často zaměřuje na bezstavové aplikace. Pro stavové aplikace, jako jsou ty, které zahrnují databázové komponenty, můžete použít StatefulSets. Podobně jako nasazení vytvoří a spravuje StatefulSet alespoň jeden identický pod. Repliky ve stavové sadě se řídí elegantním, sekvenčním přístupem k nasazení, škálování, upgradu a ukončení. Zásady vytváření názvů, názvy sítí a úložiště se uchovávají, protože repliky se přeplánují pomocí StatefulSet.

Definujte aplikaci ve formátu YAML pomocí kind: StatefulSet. Odtud kontroler StatefulSet zpracovává nasazení a správu požadovaných replik. Data se zapisují do trvalého úložiště, které poskytuje Azure Spravované disky nebo Azure Files. V případě StatefulSet zůstává základní trvalé úložiště, i když je statefulSet odstraněno.

Další informace najdete v tématu Kubernetes StatefulSets.

Repliky ve stavové sadě jsou naplánované a spuštěné v libovolném dostupném uzlu v clusteru AKS. Pokud chcete zajistit, aby alespoň jeden pod ve vaší sadě běžel na uzlu, použijte místo toho daemonSet.

DaemonSets

Pro konkrétní shromažďování nebo monitorování protokolů možná budete muset spustit pod na všech uzlech nebo ve vybrané sadě uzlů. DaemonSets můžete použít k nasazení na jeden nebo více identických podů. Kontroler DaemonSet zajišťuje, že každý zadaný uzel spustí instanci podu.

Kontroler DaemonSet může plánovat pody na uzlech v rané fázi procesu spouštění clusteru před spuštěním výchozího plánovače Kubernetes. Tato schopnost zajistí, že se pody v daemonSet spustí dříve, než se naplánují tradiční pody v nasazení nebo stavové sadě.

Podobně jako StatefulSets je daemonSet definován jako součást definice YAML pomocí kind: DaemonSet.

Další informace najdete v tématu DaemonSets Kubernetes.

Poznámka:

Pokud používáte doplněk Virtuální uzly, daemonSets na virtuálním uzlu nevytvoří pody.

Obory názvů

Prostředky Kubernetes, jako jsou pody a nasazení, se logicky seskupují do oboru názvů , který rozdělí cluster AKS a vytvoří, zobrazí nebo spravuje přístup k prostředkům. Můžete například vytvořit obory názvů pro oddělení obchodních skupin. Uživatelé můžou pracovat pouze s prostředky v jim přiřazených oborech názvů.

Po vytvoření clusteru AKS jsou k dispozici následující obory názvů:

Obor názvů	Popis
default	Pokud nejsou k dispozici žádné pody a nasazení, vytvoří se ve výchozím nastavení. V menších prostředích můžete aplikace nasadit přímo do výchozího oboru názvů, aniž byste museli vytvářet další logické oddělení. Při interakci s rozhraním API Kubernetes, například s kubectl get pods, se použije výchozí obor názvů, pokud není zadán žádný.
kube-system	Kde existují základní prostředky, jako jsou síťové funkce, jako je DNS a proxy server, nebo řídicí panel Kubernetes. V tomto oboru názvů se obvykle nenasazují vlastní aplikace.
kube-public	Obvykle se nepoužívá, ale dá se použít k tomu, aby prostředky byly viditelné v celém clusteru a dají se zobrazit libovolným uživatelem.

Další informace najdete v tématu Obory názvů Kubernetes.

Další kroky

Tento článek popisuje některé základní komponenty Kubernetes a jejich použití u clusterů AKS. Další informace o základních konceptech Kubernetes a AKS najdete v následujících článcích:

• Přístup a identita AKS
• Zabezpečení AKS
• Virtuální sítě AKS
• Úložiště AKS
• Škálování AKS