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

Vývoj aplikací pokračuje směrem k přístupu založenému na kontejnerech a zvyšuje naši potřebu orchestrace a správy prostředků. Kubernetes jako špičková platforma poskytuje spolehlivé plánování úloh aplikací odolnosti 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í komponenty infrastruktury Kubernetes:
  • řídicí rovina
  • Uzly
  • fondy uzlů
• Prostředky úloh:
  • Lusky
  • Nasazení
  • Nastaví
• Jak seskupit prostředky do oborů názvů.

Co je Kubernetes?

Kubernetes je rychle se vyvíjející platforma, která spravuje kontejnerové aplikace a související síťové a úložné komponenty. Kubernetes se zaměřuje na úlohy aplikací, nikoli na komponenty základní infrastruktury. Kubernetes nabízí deklarativní přístup k nasazením, který je založený na robustní sadě 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 bez stavové i stavové aplikace, protože týmy postupují přechodem na aplikace založené na mikroslužbách.

Kubernetes jako otevřená platforma umožňuje vytvářet aplikace s vaším preferovaným programovacím jazykem, operačním systémem, knihovnami nebo sběrnici zasílání zpráv. Stávající nástroje kontinuální integrace a průběžného doručování (CI/CD) je možné integrovat s Kubernetes a plánovat a nasazovat 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 vy platíte jenom za uzly AKS, na které běží vaše aplikace. AKS je postavená na open source modulu Azure Kubernetes Service: aks-engine.

Architektura clusteru Kubernetes

Cluster Kubernetes je rozdělený do dvou komponent:

• Řídicí rovina: Poskytuje základní služby Kubernetes a orchestraci aplikačních úloh.
• Uzly: Spouštění úloh aplikace.

Řídicí rovina

Při vytváření clusteru AKS se automaticky vytvoří a konfiguruje řídicí rovina. Tato řídicí rovina je poskytována bez nákladů jako spravovaný prostředek Azure abstrahovaný od uživatele. Platíte jenom 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:

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 je kubectl nebo řídicí panel Kubernetes.

I když s touto spravovanou řídicí rovinou nemusíte konfigurovat komponenty (například vysoce dostupné úložiště etcd), 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. Pokud chcete řešit možné problémy, můžete si projít protokoly řídicí roviny prostřednictvím Azure Monitor protokolů.

Pokud chcete konfigurovat řídicí rovinu nebo k řídicí rovině přistupovat přímo, nasaďte vlastní cluster Kubernetes pomocí aks-engine.

Související osvědčené postupy najdete v tématu Osvědčené postupy pro zabezpečení clusteru 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ý běží komponenty uzlu Kubernetes a modul runtime kontejneru.

Velikost virtuálního počítače Azure pro vaše uzly definuje dostupné procesory, paměť, velikost a typ úložiště (například vysoce výkonný disk SSD nebo běžný pevný disk HDD). Naplánujte velikost uzlu podle toho, jestli vaše aplikace vyžadovat velké objemy procesoru a paměti nebo vysoce výkonné úložiště. Škálování počtu uzlů v clusteru AKS podle poptávky

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

Pokud používáte jiný hostitelský operační systém, modul runtime kontejneru nebo jiné vlastní balíčky, nasaďte vlastní cluster Kubernetes s aks-engine. Upstream vydává aks-engine funkce a nabízí možnosti konfigurace před podporou v clusterech AKS. Pokud tedy chcete použít jiný modul runtime kontejneru než nebo Docker, můžete spustit příkaz ke konfiguraci a nasazení containerd aks-engine clusteru Kubernetes, který splňuje vaše aktuální potřeby.

Rezervace prostředků

AKS používá prostředky uzlu k pomoc funkci uzlu jako součást clusteru. Toto využití může vytvořit nesrovnalosti mezi celkovými prostředky vašeho uzlu a přidělitelnými prostředky v AKS. Tyto informace si zapamatujete při nastavování požadavků a omezení pro pody nasazené uživatelem.

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

kubectl describe node [NODE_NAME]

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

Rezervované jsou dva typy prostředků:

• Procesor
  Rezervované procesory závisí na typu uzlu a konfiguraci clusteru, což může způsobit méně alokovatelný procesor kvůli spouštění dalších funkcí.

  Jádra procesoru na hostiteli	1	2	4	8	16	32	64
  Vyhrazený kube (milimetry)	60	100	140	180	260	420	740

• Memory (Paměť)
  Paměť využíovaná AKS zahrnuje součet dvou hodnot.

  1. kubelet Daemon
     Proces kubelet démon je nainstalovaný na všech uzlech agenta Kubernetes, aby bylo možné spravovat vytváření a ukončování kontejnerů.

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

  2. Regresní míra rezervací paměti pro proces démon Kubelet pro správné fungování (kube-reserved).

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

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

• Udržujte uzly agentů v dobrém stavu, včetně některých hostujících systémových podů, které jsou důležité pro stav clusteru.
• Způsobit, že uzel bude hlásit méně alokovatelné 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é není možné přidělit, včetně prahové hodnoty pevného vy vyřazování 750Mi.

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 operační systém základního uzlu také vyhrazuje množství prostředků procesoru a paměti pro údržbu 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 definuje 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 nichž běží uzly agentů.

Cluster AKS můžete škálovat nebo upgradovat na výchozí fond uzlů. Můžete zvolit škálování nebo upgrade konkrétního fondu uzlů. Pro operace upgradu jsou spuštěné kontejnery naplánovány na jiných uzlech ve fondu uzlů, dokud nebudou úspěšně upgradovány 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. Kontrolery příchozích 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 tak, kde se má pod naplánovat.

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ánovány, 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 se plánují 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é si vyžádají určitý objem prostředků procesoru nebo paměti. Plánovač Kubernetes se pokusí splnit požadavek naplánováním spuštění podů na uzlu s dostupnými prostředky. Můžete také zadat maximální limity prostředků, aby pod spotřebovává 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, aby plánovač Kubernetes mohl identifikovat potřebné povolené prostředky.

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

Pod je logický prostředek, ale úlohy aplikací běží na kontejnerech. Pody jsou obvykle dočasné a jednorázové prostředky. U jednotlivých plánovaných podů chybí některé funkce Kubernetes s vysokou dostupností a redundancí. Místo toho se pody nasadí a spravují pomocí kontrolerů Kubernetes, jako je kontroler nasazení.

Nasazení a manifesty YAML

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

Nasazení můžete aktualizovat a změnit tak konfiguraci podů, použité image 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 bez stavový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, že v clusteru běží požadovaný počet replik. Při plánování zvlášť se pody nerestartují, pokud narazíte na problém, a neplánují se na uzly, které jsou v pořádku, pokud jejich aktuální uzel narazí na problém.

Rozhodnutí o správě nechcete narušovat procesem aktualizace, pokud vaše aplikace vyžaduje minimální počet dostupných instancí. Rozpočty přerušení podů definují, kolik replik v nasazení je možné během aktualizace nebo upgradu uzlu vypnout. Pokud máte například v nasazení pět (5) replik, můžete definovat přerušení podu o 4 (čtyři) a povolit odstranění nebo naplánování pouze jedné repliky 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í, aby vždy byl 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 vytvoří, a vyžaduje otevření portu 80 v kontejneru. Požadavky na prostředky a omezení se také definují 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

Složitější aplikace je možné vytvářet zahrnutím služeb (jako jsou nástroje pro vyrovnávání zatížení) do manifestu YAML.

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

Správa balíčků s helmem

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 manifesty YAML Kubernetes. Charty Helm můžete ukládat buď místně, nebo ve vzdáleném úložišti, například ve Azure Container Registry chartu Helm.

Pokud chcete použít Helm, nainstalujte do počítače klienta Helm nebo použijte klienta Helm v Azure Cloud Shell. Vyhledejte nebo vytvořte grafy 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 dostačující pro bezvýcové aplikace, kontroler nasazení není ideální pro aplikace, které vyžadují:

• Trvalou konvenci 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 vám ale umožňují spravovat tyto typy aplikací:

• Stavové sady udržují stav aplikací po dobu životního cyklu jednotlivých podů, jako je například úložiště.
• DaemonSets zajišťují spuštění instance na každém uzlu v rané fázi procesu spuštění Kubernetes.

Stavové sady

Moderní vývoj aplikací je často zaměřen na bezvýcové aplikace. Pro stavové aplikace, jako jsou ty, které obsahují databázové komponenty, můžete použít StatefulSets. Podobně jako nasazení i StatefulSet vytvoří a spravuje alespoň jeden identický pod. Repliky ve stavové sadě dodržují elegantní a sekvenční přístup k nasazení, škálování, upgradu a ukončení. Zásady vytváření názvů, síťové názvy a úložiště se zachytává jako repliky a přeloží se na 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 zapisuje do trvalého úložiště poskytovaného službou Azure Spravované disky nebo Azure Files. U statefulSets zůstává základní trvalé úložiště i po odstranění statefulSet.

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

Repliky ve stavové sadě jsou naplánované a spouštěné napříč všemi dostupnými uzly v clusteru AKS. Pokud chcete zajistit, aby alespoň jeden pod v sadě běží na uzlu, použijte místo toho DaemonSet.

DaemonSets

Pro konkrétní shromažďování nebo monitorování protokolů může být nutné spustit pod na všech (nebo vybraných) uzlech. DaemonSet můžete nasadit na jeden nebo více identických podů, ale kontroler DaemonSet zajistí, že každý zadaný uzel spustí instanci podu.

Kontroler DaemonSet může naplánovat pody na uzlech v rané fázi procesu spouštění clusteru před zahájením výchozího plánovače Kubernetes. Tato schopnost zajišťuje, že se pody v DaemonSet s zahájily před naplánování tradičních podů v Nasazení nebo Stavová sada.

Podobně jako StatefulSets se DaemonSet definuje jako součást definice YAML pomocí kind: DaemonSet .

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

Obory názvů

Prostředky Kubernetes, jako jsou pody a nasazení, jsou logicky seskupené do oboru názvů a rozdělují cluster AKS a omezují vytváření, zobrazení nebo správu přístupu k prostředkům. Můžete například vytvořit obory názvů pro oddělení obchodních skupin. Uživatelé mohou s prostředky pracovat jenom v rámci svých přiřazených oborů názvů.

Při vytváření clusteru AKS jsou k dispozici následující obory názvů:

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

Další kroky

Tento článek se zabývá některými základními komponentami Kubernetes a jejich použití v clusterech AKS. Další informace o základních konceptech Kubernetes a AKS najdete v následujících článcích:

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