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

  • Článek
  • 14 min ke čtení

Vývoj aplikací se i nadále přesouvá směrem k přístupu založenému na kontejnerech, což zvyšuje naši potřebu orchestrace a správy prostředků. Kubernetes jako přední platforma poskytuje spolehlivé plánování aplikačních úloh odolných proti chybám. Azure Kubernetes Service (AKS), což je 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í komponenty infrastruktury Kubernetes:
    • řídicí rovina
    • Uzly
    • fondy uzlů
  • Zdroje informací o úlohách:
    • pody
    • Nasazení
    • Nastaví
  • Jak seskupit prostředky do oborů názvů.

Co je Kubernetes?

Kubernetes je rychle se rozvíjející platforma, která spravuje kontejnerové aplikace a jejich přidružené síťové komponenty a komponenty úložiště. Kubernetes se zaměřuje na úlohy aplikací, nikoli na základní komponenty infrastruktury. Kubernetes poskytuje deklarativní přístup k nasazením, který je podporovaný 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 aplikací. Kubernetes podporuje bezstavové i stavové aplikace s tím, jak týmy postupují přechodem na aplikace založené 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 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ích úloh správy, jako je koordinace upgradu. Platforma Azure spravuje řídicí rovinu AKS a vy platíte pouze za uzly AKS, na kterých běží vaše aplikace.

Architektura clusteru Kubernetes

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

  • Řídicí rovina: Poskytuje základní služby Kubernetes a orchestraci úloh aplikací.
  • Uzly: Spouští úlohy aplikací.

Řídicí rovina a komponenty uzlů Kubernetes

Ří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 se zveřejňují základní rozhraní API Kubernetes. Tato komponenta poskytuje interakci s nástroji pro správu, jako kubectl je nebo řídicí panel Kubernetes.
etcd Kvůli zachování stavu clusteru a konfigurace Kubernetes je vysoce dostupný etcd úložištěm klíčových hodnot v rámci Kubernetes.
kube-scheduler Když vytváříte nebo škálujete aplikace, plánovač určí, na kterých uzlech může být úloha spuštěná, a spustí 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. K interakci s řídicí rovinou dochází prostřednictvím rozhraní API Kubernetes, jako kubectl je nebo řídicí panel Kubernetes.

I když nemusíte konfigurovat komponenty (jako je vysoce dostupné úložiště etcd ) s touto spravovanou řídicí rovinou, nemůžete k řídicí rovině přistupovat přímo. Upgrady řídicí roviny a uzlů Kubernetes se orchestrují prostřednictvím Azure CLI nebo Azure Portal. Při řešení možných problémů můžete zkontrolovat protokoly řídicí roviny prostřednictvím protokolů služby Azure Monitor.

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

Související osvědčené postupy najdete v tématu Osvědčené postupy pro zabezpečení clusterů a upgrady v 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 uzlů 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ě v každém uzlu. Proxy server 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 je virtuální síť a úložiště. Clustery AKS používající Kubernetes verze 1.19 nebo novější pro fondy uzlů s Linuxem se používají containerd jako modul runtime kontejneru. Počínaje platformou Kubernetes verze 1.20 pro fondy containerd uzlů s Windows se dá použít ve verzi Preview pro modul runtime kontejneru, ale výchozím modulem runtime kontejneru je stále Docker. Clustery AKS, které používají předchozí verze Kubernetes pro fondy uzlů, používají jako modul runtime kontejneru Docker.

Virtuální počítač Azure a podpůrné prostředky pro uzel Kubernetes

Velikost virtuálního počítače Azure pro vaše uzly definuje procesory úložiště, paměť, velikost a dostupný typ (například vysoce výkonný disk SSD nebo běžný disk HDD). Naplánujte velikost uzlu podle toho, jestli vaše aplikace můžou vyžadovat velké množství procesoru a paměti nebo vysoce výkonné úložiště. Vertikálně navyšte kapacitu počtu uzlů v clusteru AKS, abyste vyhověli poptávce.

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

U spravovaných disků se výchozí velikost disku a výkon přiřadí podle vybrané skladové položky virtuálního počítače a počtu virtuálních procesorů. Další informace najdete 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 a operačním systémem uzlu Kubernetes, můžete nasadit samoobslužně spravovaný cluster pomocí poskytovatele rozhraní Api clusteru Azure.

Rezervace prostředků

AKS využívá prostředky uzlu k tomu, aby uzel fungoval jako součást clusteru. Toto použití může vytvořit nesrovnalost mezi celkovými prostředky vašeho uzlu a prostředky, které lze v AKS přidělovat. Tyto informace si zapamatujte při nastavování požadavků a omezení pro uživatelem nasazené pody.

Pokud chcete najít přidělené prostředky uzlu, spusťte:

kubectl describe node [NODE_NAME]

Za účelem zachování výkonu a funkčnosti uzlu si AKS vyhrazuje prostředky na každém uzlu. S tím, jak se uzel zvětšuje v prostředcích, roste rezervace prostředků kvůli vyšší potřebě správy uživatelem nasazených podů.

Poznámka

Použití doplňků AKS, jako je Container Insights (OMS), spotřebuje další prostředky uzlů.

Vyhrazeny 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ého procesoru 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.

    1. kubelet Daemon
      Proces kubelet démon se nainstaluje na všechny uzly agenta Kubernetes, aby bylo možné spravovat vytváření a ukončování kontejneru.

      Ve výchozím nastavení v AKS kubelet má démon pravidlo vyřazení memory.available<750Mi , což zajišťuje, že uzel musí mít vždy alokovatelné alespoň 750 Mi. Pokud je hostitel nižší než tato prahová hodnota dostupné paměti, kubelet aktivuje se aktivace, která ukončí jeden ze spuštěných podů a uvolní paměť na hostitelském počítači.

    2. Regresivní rychlost rezervací paměti , aby správně fungoval proces démon kubelet (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 vyhrazuje další 2 GB pro systémový proces v uzlech Windows, které nejsou součástí počítané paměti.

Pravidla přidělování paměti a procesoru:

  • Udržujte uzly agenta v dobrém stavu, včetně některých podů hostitelského systému, které jsou pro stav clusteru kritické.
  • Způsobí, že uzel bude hlásit méně využitelné paměti a procesoru, než kdyby nebyl součástí clusteru Kubernetes.

Výše uvedené rezervace prostředků nelze 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 pro pevné 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 zachování funkcí operačního systému.

Související 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ů. Cluster Kubernetes obsahuje alespoň jeden fond uzlů. Počáteční počet uzlů a velikost se definují při vytvoř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 spolehlivý provoz clusteru, měli byste ve výchozím fondu uzlů spustit alespoň dva (2) uzly.

Škálujete nebo upgradujete cluster AKS s výchozím fondem uzlů. Můžete se rozhodnout škálovat nebo upgradovat konkrétní fond uzlů. Pro operace upgradu se spouštění kontejnerů plánuje na jiných uzlech ve fondu uzlů, dokud se úspěšně neupgradují všechny uzly.

Další informace o použití více fondů uzlů v AKS najdete v tématu Vytvoření a správa více fondů uzlů pro cluster v AKS.

Selektory uzlů

V clusteru AKS s více fondy uzlů možná budete muset plánovači Kubernetes říct, který fond uzlů se má pro daný prostředek použít. Například kontrolery příchozího přenosu dat by 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 tak, kde se má pod naplánovat.

Následující základní příklad naplánuje instanci NGINX na uzlu s Linuxem pomocí selektoru uzlů "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.

Lusky

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 , které budou vyžadovat určité množství prostředků procesoru nebo paměti. Plánovač Kubernetes se snaží vyhovět požadavku 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ů z podkladového uzlu. Osvědčeným postupem je zahrnout limity prostředků pro všechny pody, které plánovači Kubernetes pomůžou identifikovat potřebné a povolené prostředky.

Další informace najdete v tématu Životní cyklus podů Kubernetes a Kubernetes.

Pod je logický prostředek, ale úlohy aplikací se spouští v kontejnerech. Pody jsou obvykle dočasné, jednorázové prostředky. U individuálně plánovaných podů chybí některé funkce Kubernetes s vysokou dostupností a redundancí. Místo toho se pody nasazují a spravují pomocí kontrolerů Kubernetes, jako je například řadič 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, aby byly na uzlech, které jsou v pořádku, naplánovány další pody, pokud dojde k problémům.

Můžete aktualizovat nasazení a změnit konfiguraci podů, použité image kontejneru nebo připojeného úložiště. Řadič nasazení:

  • Vyprázdní a ukončí daný počet replik.
  • Vytvoří repliky z nové definice nasazení.
  • Pokračuje v procesu, dokud se neaktualizují 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 zajistit tak, aby se v clusteru spustil požadovaný počet replik. Při individuálním naplánování se pody nerestartují, pokud narazí na problém, a pokud u aktuálního uzlu narazí na problém, nebudou přeplánované na uzlech, které jsou v pořádku.

Pokud vaše aplikace vyžaduje minimální počet dostupných instancí, nechcete narušovat rozhodování o správě procesem aktualizace. Rozpočty přerušení podů definují, kolik replik v nasazení může být během aktualizace nebo upgradu uzlu odebráno. Pokud máte například v nasazení pět (5) replik, můžete definovat přerušení podu na 4 (čtyři), aby bylo možné odstranit nebo přeplánovat jenom jednu repliku najednou. Stejně jako u omezení prostředků podů je osvědčeným postupem definovat rozpočty přerušení podů u aplikací, které vyžadují minimální počet replik, aby byly vždy přítomné.

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, aby byl v kontejneru otevřený port 80 . 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 Description
.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 Hub.
.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 dvojic {key, value} , která umožňuje nasazení najít a spravovat vytvořené pody.
.spec.selector.matchLabels.app Musí odpovídat .spec.template.metadata.labels.
.spec.template.labels Určuje dvojice {key, value} připojené k objektu.
.spec.template.app Musí odpovídat .spec.selector.matchLabels.
.spec.spec.containers Určuje seznam kontejnerů, které patří do podu.
.spec.spec.containers.name Určuje název kontejneru zadané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ý objem procesoru.
.spec.spec.resources.requests.memory Určuje minimální požadovanou velikost paměti.
.spec.spec.resources.limits Určuje maximální povolený počet výpočetních prostředků. Toto omezení vynucuje kubelet.
.spec.spec.resources.limits.cpu Určuje maximální povolenou velikost procesoru. Toto omezení vynucuje kubelet.
.spec.spec.resources.limits.memory Určuje maximální povolenou velikost paměti. Toto omezení 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í) do manifestu YAML.

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

Správa balíčků pomocí Helmu

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 chartů Helm, které obsahují zabalenou verzi kódu aplikace a manifesty YaML Kubernetes. Grafy Helmu můžete ukládat místně nebo ve vzdáleném úložišti, jako je Azure Container Registry úložiště chartů Helm.

Pokud chcete používat Helm, nainstalujte do počítače klienta Helm nebo použijte klienta Helm v azure Cloud Shell. 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í Helmu v AKS.

StatefulSets a DaemonSets

Pomocí plánovače Kubernetes spouští řadič nasazení 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í:

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

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

  • StatefulSets udržují stav aplikací nad rámec životního cyklu jednotlivých podů, jako je úložiště.
  • DaemonSets zajišťují spuštěnou instanci na každém uzlu v rané fázi procesu spouštění Kubernetes.

Stavové sady

Vývoj moderních aplikací často cílí na bezstavové aplikace. Pro stavové aplikace, jako jsou ty, které zahrnují databázové komponenty, můžete použít StatefulSets. Podobně jako u nasazení i StatefulSet vytvoří a spravuje aspoň jeden identický pod. Repliky ve StatefulSet používají elegantní a sekvenční přístup k nasazení, škálování, upgradu a ukončení. Zásady vytváření názvů, názvy sítí a úložiště se zachovají, 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ě StatefulSets zůstane základní trvalé úložiště, i když se StatefulSet odstraní.

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

Repliky ve StatefulSet jsou naplánované a běží na libovolném dostupném uzlu v clusteru AKS. Pokud chcete zajistit, aby alespoň jeden pod v 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 nebo vybraných uzlech. Nasazení daemonSet můžete použít na jednom nebo více identických podech, ale kontroler DaemonSet zajišťuje, že každý zadaný uzel spustí instanci podu.

DaemonSet Controller může plánovat pody na uzlech na začátku procesu spouštění clusteru, ještě než se spustí výchozí plánovač Kubernetes. Tato schopnost zajišťuje, že se pody v daemonSet spustí před naplánování tradičních podů v nasazení nebo statefulSet.

Podobně jako StatefulSets se daemonSet definuje 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 nevytvoří pody na virtuálním uzlu.

Obory názvů

Prostředky Kubernetes, jako jsou pody a nasazení, jsou logicky seskupené do oboru názvů , aby se cluster AKS rozdělil a omezil se vytváření, zobrazení nebo správa přístupu 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ů.

Obory názvů Kubernetes pro logické rozdělení prostředků a aplikací

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

Obor názvů Description
default Kde se pody a nasazení vytvářejí ve výchozím nastavení, když není k dispozici žádný. V menších prostředích můžete nasazovat aplikace přímo do výchozího oboru názvů bez vytváření dalších logických 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 jsou 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 byly prostředky viditelné v celém clusteru, a může je zobrazit libovolný uživatel.

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í na clustery AKS. Další informace o základních konceptech Kubernetes a AKS najdete v následujících článcích: