Základní koncepty Kubernetes pro Azure Kubernetes Service (AKS)

Tento článek popisuje základní koncepty služby Azure Kubernetes Service (AKS), spravované služby Kubernetes, kterou můžete použít k nasazení a provozu kontejnerizovaných aplikací ve velkém měřítku v Azure. Pomůže vám získat informace o komponentách infrastruktury Kubernetes a získat hlubší přehled o tom, jak Kubernetes funguje v AKS.

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í, nikoli 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.

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. 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, která poskytuje základní služby Kubernetes a orchestraci aplikačních úloh a
• Uzly, které spouští úlohy vaší aplikace.

Řídicí rovina

Když vytvoříte cluster AKS, platforma Azure automaticky vytvoří a nakonfiguruje přidruženou řídicí rovinu. Tato řídicí rovina s jedním tenantem je poskytována bez poplatků 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í pouze 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 zveřejňuje základní rozhraní API Kubernetes a poskytuje interakci s nástroji pro správu, jako kubectl je řídicí panel Kubernetes.
atd.	Etcd je vysoce dostupné úložiště klíč-hodnota v Rámci Kubernetes, které pomáhá udržovat stav clusteru a konfigurace 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 spustí identifikované uzly.
kube-controller-manager	Správce kontroleru dohlíží na řadu menších kontrolerů, které provádějí akce, jako jsou replikace podů a zpracování operací uzlů.

Mějte na paměti, že nemáte přímý přístup k řídicí rovině. Ří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 pomocí služby Azure Monitor.

Uzly

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

Uzly zahrnují následující základní komponenty Kubernetes:

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	Proxy zpracovává virtuální sítě na každém uzlu, směruje síťový provoz a spravuje přidělování IP adres pro služby a pody.
modul runtime kontejneru	Modul runtime kontejneru umožňuje kontejnerizovaným aplikacím spouštět a pracovat s dalšími prostředky, jako je virtuální síť nebo úložiště. Další informace najdete v tématu Konfigurace modulu runtime kontejneru.

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ý 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 2022. 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í všechny slevy na velikost virtuálních počítačů, včetně rezervací Azure.

U spravovaných disků se výchozí velikost disku a výkon přiřazují 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.

Konfigurace operačního systému

AKS podporuje Ubuntu 22.04 a Azure Linux 2.0 jako operační systém uzlu (OS) pro clustery s Kubernetes 1.25 a vyšší. Ubuntu 18.04 lze také zadat při vytváření fondu uzlů pro Kubernetes verze 1.24 a novější.

AKS podporuje Windows Server 2022 jako výchozí operační systém pro fondy uzlů Windows v clusterech s Kubernetes 1.25 a vyšší. Windows Server 2019 je také možné zadat při vytváření fondu uzlů pro Kubernetes verze 1.32 a novější. Windows Server 2019 se vyřadí, jakmile Kubernetes verze 1.32 dosáhne konce životnosti a v budoucích verzích se nepodporuje. Další informace o tomto vyřazení najdete v poznámkách k verzi AKS.

Konfigurace modulu runtime kontejneru

Modul runtime kontejneru je software, který spouští kontejnery a spravuje image kontejnerů na uzlu. Modul runtime pomáhá abstraktovat volání sys nebo funkce specifické pro operační systém pro spouštění kontejnerů v Linuxu nebo Windows. Pro fondy containerd uzlů Linuxu se používá v Kubernetes verze 1.19 a vyšší. Pro fondy containerd uzlů s Windows Serverem 2019 a 2022 je obecně dostupná a je jedinou možností modulu runtime v Kubernetes verze 1.23 a vyšší. Od května 2023 se Docker vyřadí z důchodu a už se nepodporuje. Další informace o tomto vyřazení najdete v poznámkách k verzi AKS.

Containerd je modul runtime základního kontejneru kompatibilní s architekturou OCI (Open Container Initiative), který poskytuje minimální sadu požadovaných funkcí pro spouštění kontejnerů a správu imagí na uzlu. Díkycontainerd uzlům a fondům uzlů kubelet komunikuje přímo s containerd použitím modulu plug-in CRI (rozhraní modulu runtime kontejneru) a v porovnání s implementací Docker CRI odebírá další segmenty směrování v toku dat. V takovém případě vidíte lepší latenci spouštění podů a nižší využití prostředků (procesoru a paměti).

Containerd funguje na všech verzích GA Kubernetes v AKS, ve všech verzích Kubernetes počínaje verzí 1.19 a podporuje všechny funkce Kubernetes a AKS.

containerd omezení/rozdíly

• Pro containerdúčely řešení potíží s pody, kontejnery a image kontejnerů na uzlech Kubernetes doporučujeme použít crictl jako náhradu za rozhraní příkazového řádku Dockeru. Další informace o crictlobecném použití a možnostech konfigurace klienta.

  • Containerd neposkytuje kompletní funkce rozhraní příkazového řádku Dockeru. Je k dispozici pouze pro řešení potíží.
  • crictl nabízí přehlednější zobrazení kontejnerů Kubernetes s koncepty, jako jsou pody atd.

• Containerd nastaví protokolování pomocí standardizovaného cri formátu protokolování. Vaše řešení protokolování musí podporovat cri formát protokolování, jako je Azure Monitor pro kontejnery.

• K modulu /var/run/docker.sockDocker už nemáte přístup ani nemůžete používat Docker-in-Docker (DinD).

  • Pokud aktuálně extrahujete protokoly aplikací nebo data monitorování z modulu Dockeru, použijte místo toho kontejner Přehledy. AKS nepodporuje spouštění žádných příkazů mimo pásmo na agentových uzlech, které by mohly způsobit nestabilitu.
  • Nedoporučujeme vytvářet image ani přímo používat modul Docker. Kubernetes tyto spotřebované prostředky plně nezná a tyto metody představují řadu problémů, jak je popsáno tady a tady.

• Při vytváření imagí můžete pokračovat v používání aktuálního pracovního postupu sestavení Dockeru jako obvykle, pokud nevytvořujete image v clusteru AKS. V takovém případě zvažte přechod na doporučený přístup pro vytváření imagí pomocí ACR Tasks nebo bezpečnější možnost v clusteru, jako je Docker Buildx.

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 akocatable prostředek uzlu, můžete použít kubectl describe node tento příkaz:

kubectl describe node [NODE_NAME]

Kvůli zachování výkonu a funkčnosti uzlů si AKS na každém uzlu vyhrazuje dva typy prostředků, procesoru a paměti. 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. Mějte na paměti, že rezervace prostředků se nedají změnit.

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í. Následující tabulka ukazuje rezervaci procesoru v milicores:

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

Memory (Paměť)

Rezervovaná paměť v AKS zahrnuje součet dvou hodnot:

AKS 1.29 a novější

1. kubelet Démon má ve výchozím nastavení pravidlo vyřazení paměti.available<100Mi. Toto pravidlo zajistí, že uzel bude mít aspoň 100Mi alokatelné ve všech časech. 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 Démon má ve výchozím nastavení pravidlo vyřazení paměti.available<750Mi. Toto pravidlo zajistí, že uzel bude mít aspoň 750Mi alokovatelné za všech okolností. 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. 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 větší než 128 GB

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

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

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ů

Uzly stejné konfigurace jsou seskupené do fondů uzlů. Každý cluster Kubernetes obsahuje alespoň jeden fond uzlů. Počáteční počet uzlů a velikostí definujete 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.

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 naleznete v tématu Vytvoření fondů uzlů a Správa fondů uzlů.

Výchozí velikost disku s operačním systémem

Při vytváření nového clusteru nebo přidání nového fondu uzlů do existujícího clusteru určuje číslo virtuálních procesorů ve výchozím nastavení velikost disku s operačním systémem. Počet virtuálních procesorů vychází ze skladové položky virtuálního počítače. Následující tabulka uvádí výchozí velikost disku s operačním systémem pro každou skladovou položku virtuálního počítače:

Jádra skladových položek virtuálních počítačů (vCPU)	Výchozí úroveň disku s operačním systémem	Zřízené IOPS	Zřízená propustnost (Mb/s)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

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ů slouží k definování různých parametrů, jako je operační systém uzlu, k řízení, 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 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 zadáte skupinu prostředků Azure, ve které se vytvoří prostředky clusteru. Kromě této skupiny prostředků vytvoří a spravuje poskytovatel prostředků AKS 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 s následujícím formátem: MC_resourceGroupName_clusterName_location. Během vytváření clusteru můžete zadat název přiřazený ke skupině prostředků uzlu. Při použití šablony Azure Resource Manageru můžete definovat název pomocí nodeResourceGroup vlastnosti. Při použití Azure CLI použijete --node-resource-group parametr s příkazem az aks create , jak je znázorněno v následujícím příkladu:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

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.

Ú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). Pokud upravíte nebo odstraníte značky vytvořené v Azure nebo jiné vlastnosti prostředku ve skupině prostředků uzlu, může dojít k neočekávaným výsledkům, například k chybám škálování a upgradu. AKS spravuje životní cyklus infrastruktury ve skupině prostředků uzlu, takže veškeré změny přesunou cluster do nepodporovaného stavu. Další informace najdete v tématu Nabízí AKS smlouvu o úrovni služeb?

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 například chtít vytvořit nebo upravit vlastní značky tak, aby přiřadily obchodní jednotku nebo nákladové středisko. Můžete také vytvořit zásady Azure s oborem pro spravovanou skupinu prostředků.

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 tématu Plně spravovaná skupina prostředků (Preview).

Pody

Kubernetes používá pody ke spouštění instancí vaší aplikace. Jeden 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 určité množství 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. Doporuč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 nasadí a spravuje pody kontrolery Kubernetes, jako je kontroler 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 na pody nebo uzly narazí na problémy. Nasazení můžete aktualizovat tak, aby se změnila konfigurace podů, image kontejneru nebo připojené úložiště.

Kontroler nasazení spravuje životní cyklus nasazení a provádí následující akce:

• 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, nenaplá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 replik, můžete definovat přerušení podu se čtyřmi , abyste umožnili odstranění nebo přeplánování jedné repliky najednou. Stejně jako u limitů prostředků podů doporučujeme 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. Nasazení můžete vytvořit definováním souboru manifestu ve formátu YAML. Následující příklad ukazuje základní soubor manifestu nasazení pro webový server NGINX:

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 příklad souboru YAML spustí image nginx z Docker Hubu.
.spec.replicas	Určuje, kolik podů se má vytvořit. Tento příklad souboru YAML 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ů. Kubelet vynucuje tento limit.
.spec.spec.resources.limits.cpu	Určuje maximální povolenou velikost procesoru. Kubelet vynucuje tento limit.
.spec.spec.resources.limits.memory	Určuje maximální povolenou velikost paměti. Kubelet vynucuje tento limit.

Složitější aplikace je možné vytvářet včetně služeb, jako jsou nástroje 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

Kontroler nasazení používá plánovač Kubernetes a spouští repliky na libovolném dostupném uzlu s dostupnými prostředky. I když tento přístup může stačit pro bezstavové aplikace, řadič nasazení není ideální pro aplikace, které vyžadují následující specifikace:

• 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í: StatefulSets a DaemonSets.

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í operací. 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.

Aplikaci můžete definovat ve formátu YAML pomocí kind: StatefulSet. Odtud kontroler StatefulSet zpracovává nasazení a správu požadovaných replik. Zápisy dat do trvalého úložiště poskytované službou Azure Spravované disky nebo Soubory Azure 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.

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 zajišťuje, že se pody ve stavu daemonSet před plánováním tradičních podů v nasazení nebo stavové sadě.

Podobně jako StatefulSets můžete daemonSet definovat jako součást definice YAML pomocí kind: DaemonSet.

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

Obory názvů

Prostředky Kubernetes, jako jsou pody a nasazení, se logicky seskupují do oborů názvů , aby se cluster AKS rozdělil a vytvořil, zobrazil nebo spravoval 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ů.

Při vytvář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á, můžete ho 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

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