Model clusteru Kubernetes s vysokou dostupností

Tento článek popisuje, jak navrhovat a provozovat vysoce dostupnou infrastrukturu založenou na Kubernetes pomocí modulu Azure Kubernetes Service (AKS) ve službě Azure Stack Hub. Tento scénář je běžný pro organizace s kritickými úlohami ve vysoce omezených a regulovaných prostředích. Organizace v oblastech, jako jsou finance, obrana a státní správa.

Kontext a problém

Mnoho organizací vyvíjí nativní cloudová řešení, která využívají nejmodernější služby a technologie, jako je Kubernetes. I když Azure poskytuje datacentra ve většině oblastí světa, někdy existují hraniční případy použití a scénáře, kdy musí důležité obchodní aplikace běžet v určitém umístění. Mezi důležité informace patří:

• Citlivost na polohu
• Latence mezi aplikací a místními systémy
• Zachování šířky pásma
• Připojení
• Zákonné nebo zákonné požadavky

Azure v kombinaci se službou Azure Stack Hub řeší většinu těchto problémů. Široká škála možností, rozhodnutí a aspektů pro úspěšnou implementaci Kubernetes spuštěného ve službě Azure Stack Hub je popsána níže.

Řešení

Tento model předpokládá, že se musíme vypořádat s striktním souborem omezení. Aplikace musí běžet místně a všechna osobní data se nesmí dostat do veřejných cloudových služeb. Data monitorování a další data, která nejsou piI, se dají odesílat do Azure a zpracovávat tam. Externí služby, jako je veřejný registr kontejneru nebo jiné, jsou přístupné, ale můžou být filtrované přes bránu firewall nebo proxy server.

Zde uvedená ukázková aplikace je navržená tak, aby používala řešení nativní pro Kubernetes, kdykoli je to možné. Tento návrh se vyhne uzamčení dodavatele místo použití služeb nativních pro platformu. Aplikace například používá back-end databáze MongoDB v místním prostředí místo služby PaaS nebo externí databázové služby. Další informace najdete ve studijním programu Úvod do Kubernetes v Azure.

Předchozí diagram znázorňuje aplikační architekturu ukázkové aplikace spuštěné v Kubernetes ve službě Azure Stack Hub. Aplikace se skládá z několika komponent, mezi které patří:

1. Cluster Kubernetes založený na modulu AKS ve službě Azure Stack Hub.
2. cert-manager, který poskytuje sadu nástrojů pro správu certifikátů v Kubernetes, které se používají k automatickému vyžádání certifikátů z Let's Encrypt.
3. Obor názvů Kubernetes, který obsahuje komponenty aplikace pro front-end (ratings-web), api (ratings-api) a databázi (ratings-mongodb).
4. Kontroler příchozího přenosu dat, který směruje provoz HTTP/HTTPS do koncových bodů v rámci clusteru Kubernetes.

Ukázková aplikace slouží ke znázornění architektury aplikace. Všechny komponenty jsou příklady. Architektura obsahuje pouze jedno nasazení aplikace. Abychom dosáhli vysoké dostupnosti, spustíme nasazení alespoň dvakrát na dvou různých instancích služby Azure Stack Hub – můžou běžet buď ve stejném umístění, nebo ve dvou (nebo více) různých lokalitách:

Služby jako Azure Container Registry, Azure Monitor a další se hostují mimo službu Azure Stack Hub v Azure nebo místně. Tento hybridní návrh chrání řešení před výpadkem jedné instance služby Azure Stack Hub.

Komponenty

Celková architektura se skládá z následujících komponent:

Azure Stack Hub je rozšíření Azure, které může spouštět úlohy v místním prostředí tím, že poskytuje služby Azure ve vašem datacentru. Další informace najdete v tématu Přehled služby Azure Stack Hub .

Azure Kubernetes Service Engine (modul AKS) je modul, který stojí za nabídkou spravované služby Kubernetes, Azure Kubernetes Service (AKS), která je dnes dostupná v Azure. Ve službě Azure Stack Hub nám modul AKS umožňuje nasazovat, škálovat a upgradovat plně funkční clustery Kubernetes s využitím funkcí IaaS služby Azure Stack Hub. Další informace najdete v tématu Přehled modulu AKS .

Další informace o rozdílech mezi modulem AKS v Azure a modulem AKS ve službě Azure Stack Hub najdete v části Známé problémy a omezení .

Azure Virtual Network (VNet) slouží k poskytování síťové infrastruktury v každé službě Azure Stack Hub pro Virtual Machines (virtuální počítače), které hostují infrastrukturu clusteru Kubernetes.

Azure Load Balancer se používá pro koncový bod rozhraní API Kubernetes a kontroler příchozího přenosu dat Nginx. Nástroj pro vyrovnávání zatížení směruje externí provoz (například internet) do uzlů a virtuálních počítačů nabízejících konkrétní službu.

Azure Container Registry (ACR) slouží k ukládání privátních imagí Dockeru a grafů Helm, které se nasazují do clusteru. Modul AKS se může ověřit ve službě Container Registry pomocí Azure AD identity. Kubernetes nevyžaduje ACR. Můžete použít jiné registry kontejnerů, například Docker Hub.

Azure Repos je sada nástrojů pro správu verzí, které můžete použít ke správě kódu. Můžete také použít GitHub nebo jiná úložiště založená na Gitu. Další informace najdete na Azure Repos Přehled.

Azure Pipelines je součástí Azure DevOps Services a spouští automatizovaná sestavení, testy a nasazení. Můžete také použít řešení CI/CD třetích stran, jako je Jenkins. Další informace najdete v tématu Přehled kanálu Azure .

Azure Monitor shromažďuje a ukládá metriky a protokoly, včetně metrik platformy pro služby Azure v řešení a telemetrii aplikací. Tato data použijte k monitorování aplikace, nastavení upozornění a řídicích panelů a provádění analýzy původních příčin selhání. Azure Monitor se integruje s Kubernetes a shromažďuje metriky z kontrolerů, uzlů a kontejnerů a také protokolů kontejnerů a protokolů hlavních uzlů. Další informace najdete v tématu Přehled služby Azure Monitor .

Azure Traffic Manager je nástroj pro vyrovnávání zatížení provozu založený na DNS, který umožňuje optimálně distribuovat provoz do služeb napříč různými oblastmi Azure nebo nasazeními služby Azure Stack Hub. Traffic Manager také poskytuje vysokou dostupnost a rychlost odezvy. Koncové body aplikace musí být přístupné z vnějšku. K dispozici jsou i další místní řešení.

Kontroler příchozího přenosu dat Kubernetes zveřejňuje trasy HTTP(S) službám v clusteru Kubernetes. K tomuto účelu je možné použít Nginx nebo jakýkoli vhodný kontroler příchozího přenosu dat.

Helm je správce balíčků pro nasazení Kubernetes, který poskytuje způsob, jak seskupit různé objekty Kubernetes, jako jsou nasazení, služby nebo tajné kódy, do jednoho "grafu". Objekt grafu můžete publikovat, nasadit, řídit správu verzí a aktualizovat ho. Azure Container Registry lze použít jako úložiště pro ukládání zabalených chartů Helm.

Na co dát pozor při navrhování

Tento model se řídí několika hlavními aspekty, které jsou podrobněji vysvětleny v dalších částech tohoto článku:

• Aplikace používá nativní řešení Kubernetes, aby se vyhnula uzamčení dodavatele.
• Aplikace používá architekturu mikroslužeb.
• Azure Stack Hub nepotřebuje příchozí připojení, ale umožňuje odchozí připojení k internetu.

Tyto doporučené postupy se budou vztahovat i na reálné úlohy a scénáře.

Aspekty zabezpečení

Škálovatelnost je důležitá k tomu, aby uživatelům poskytovala konzistentní, spolehlivý a dobře fungující přístup k aplikaci.

Ukázkový scénář se zabývá škálovatelností ve více vrstvách zásobníku aplikace. Tady je základní přehled různých vrstev:

Úroveň architektury	Ovlivňuje	Jak?
Aplikace	Aplikace	Horizontální škálování na základě počtu podů, replik nebo Container Instances*
Cluster	Cluster Kubernetes	Počet uzlů (mezi 1 a 50), virtuální počítače a velikosti skladových položek a fondy uzlů (modul AKS ve službě Azure Stack Hub v současné době podporuje pouze jeden fond uzlů); použití příkazu škálování modulu AKS (ruční)
Infrastruktura	Azure Stack Hub	Počet uzlů, kapacita a jednotky škálování v rámci nasazení služby Azure Stack Hub

* Použití horizontálního automatického škálování podů (HPA) Kubernetes; automatizované škálování na základě metrik nebo vertikální škálování podle velikosti instancí kontejneru (procesor/paměť).

Azure Stack Hub (úroveň infrastruktury)

Infrastruktura služby Azure Stack Hub je základem této implementace, protože Azure Stack Hub běží na fyzickém hardwaru v datacentru. Při výběru hardwaru centra musíte zvolit procesor, hustotu paměti, konfiguraci úložiště a počet serverů. Další informace o škálovatelnosti služby Azure Stack Hub najdete v následujících zdrojích informací:

• Přehled plánování kapacity pro Azure Stack Hub
• Přidání dalších uzlů jednotek škálování ve službě Azure Stack Hub

Cluster Kubernetes (na úrovni clusteru)

Samotný cluster Kubernetes se skládá z komponent Azure (Stack) IaaS, včetně výpočetních, úložných a síťových prostředků, a je postavený na komponentách Azure (Stack). Řešení Kubernetes zahrnují hlavní a pracovní uzly, které se nasazují jako virtuální počítače v Azure (a službě Azure Stack Hub).

• Uzly řídicí roviny (hlavní uzel) poskytují základní služby Kubernetes a orchestraci aplikačních úloh.
• Pracovní uzly (pracovní proces) spouštějí úlohy aplikací.

Při výběru velikostí virtuálních počítačů pro počáteční nasazení je potřeba vzít v úvahu několik aspektů:

• Náklady – při plánování pracovních uzlů mějte na paměti celkové náklady na virtuální počítač, které vám vzniknou. Pokud například úlohy vaší aplikace vyžadují omezené prostředky, měli byste naplánovat nasazení virtuálních počítačů s menší velikostí. Služba Azure Stack Hub se stejně jako Azure obvykle účtuje na základě spotřeby, takže vhodné nastavení velikosti virtuálních počítačů pro role Kubernetes je pro optimalizaci nákladů na spotřebu zásadní.

• Škálovatelnost – Škálovatelnost clusteru se dosahuje horizontálním navýšením a snížením kapacity počtu hlavních a pracovních uzlů nebo přidáním dalších fondů uzlů (které nejsou v současnosti k dispozici ve službě Azure Stack Hub). Škálování clusteru je možné provádět na základě dat o výkonu shromážděných pomocí služby Container Insights (Azure Monitor + Log Analytics).

  Pokud vaše aplikace potřebuje více (nebo méně) prostředků, můžete horizontálně škálovat aktuální uzly (mezi 1 a 50 uzly). Pokud potřebujete více než 50 uzlů, můžete vytvořit další cluster v samostatném předplatném. Bez opětovného nasazení clusteru nemůžete vertikálně vertikálně navýšit kapacitu skutečných virtuálních počítačů na jinou velikost virtuálního počítače.

  Škálování se provádí ručně pomocí pomocného virtuálního počítače modulu AKS, který byl původně použit k nasazení clusteru Kubernetes. Další informace najdete v tématu Škálování clusterů Kubernetes.

• Kvóty – zvažte kvóty , které jste nakonfigurovali při plánování nasazení AKS ve službě Azure Stack Hub. Ujistěte se, že každé předplatné má správné plány a nakonfigurované kvóty. Předplatné bude muset pojmout množství výpočetních, úložných a dalších služeb potřebných pro vaše clustery při horizontálním navýšení kapacity.

• Aplikační úlohy – projděte si koncepty clusterů a úloh v základních konceptech Kubernetes pro Azure Kubernetes Service dokumentu. Tento článek vám pomůže nastavit rozsah správné velikosti virtuálního počítače na základě výpočetních a paměťových potřeb vaší aplikace.

Aplikace (úroveň aplikace)

Na aplikační vrstvě používáme horizontální automatické škálování podů Kubernetes (HPA). HPA může zvýšit nebo snížit počet replik (pod/Container Instances) v našem nasazení na základě různých metrik (například využití procesoru).

Další možností je vertikální škálování instancí kontejneru. Toho lze dosáhnout změnou množství procesoru a paměti požadované a dostupné pro konkrétní nasazení. Další informace najdete v tématu Správa prostředků pro kontejnery na kubernetes.io.

Důležité informace o sítích a připojení

Sítě a možnosti připojení mají vliv také na tři vrstvy uvedené výše pro Kubernetes ve službě Azure Stack Hub. Následující tabulka ukazuje vrstvy a služby, které obsahují:

Vrstva	Ovlivňuje	Co?
Aplikace	Aplikace	Jak je aplikace přístupná? Bude vystavený na internetu?
Cluster	Cluster Kubernetes	Rozhraní KUBERNETES API, virtuální počítač modulu AKS, načítání imagí kontejnerů (výchozí přenos dat), odesílání dat a telemetrie monitorování (výchozí přenos dat)
Infrastruktura	Azure Stack Hub	Přístupnost koncových bodů správy služby Azure Stack Hub, jako jsou portál a koncové body Azure Resource Manager.

Aplikace

U aplikační vrstvy je nejdůležitějším aspektem to, jestli je aplikace vystavená a přístupná z internetu. Z pohledu Kubernetes znamená zpřístupnění internetu zveřejnění nasazení nebo podu pomocí služby Kubernetes Service nebo kontroleru příchozího přenosu dat.

Zveřejnění aplikace pomocí veřejné IP adresy prostřednictvím Load Balancer nebo kontroleru příchozího přenosu dat neznamená, že je teď aplikace přístupná přes internet. Azure Stack Hub může mít veřejnou IP adresu, která je viditelná jenom v místním intranetu – ne všechny veřejné IP adresy jsou skutečně přístupné z internetu.

Předchozí blok zohledňuje příchozí přenos dat do aplikace. Dalším tématem, které je potřeba vzít v úvahu pro úspěšné nasazení Kubernetes, je odchozí/výchozí provoz. Tady je několik případů použití, které vyžadují výchozí přenos:

• Načítání imagí kontejnerů uložených na DockerHubu nebo Azure Container Registry
• Načítání chartů Helm
• Generování dat Application Insights (nebo jiných dat monitorování)

Některá podniková prostředí můžou vyžadovat použití transparentních nebo netransparentních proxy serverů. Tyto servery vyžadují konkrétní konfiguraci v různých komponentách našeho clusteru. Dokumentace k modulu AKS obsahuje různé podrobnosti o tom, jak pojmout síťové proxy servery. Další podrobnosti najdete v tématu Modul AKS a proxy servery.

A nakonec mezi instancemi služby Azure Stack Hub musí proudit provoz mezi clustery. Ukázkové nasazení se skládá z jednotlivých clusterů Kubernetes spuštěných na jednotlivých instancích služby Azure Stack Hub. Provoz mezi nimi, například provoz replikace mezi dvěma databázemi, je "externí provoz". Aby bylo možné připojit Kubernetes ke dvěma instancím služby Azure Stack Hub, musí být externí provoz směrovaný přes síť SITE-to-Site VPN nebo veřejné IP adresy služby Azure Stack Hub:

Cluster

Cluster Kubernetes nemusí být nutně přístupný přes internet. Relevantní částí je rozhraní API Kubernetes, které se používá k provozu clusteru, například pomocí kubectl. Koncový bod rozhraní Kubernetes API musí být přístupný všem uživatelům, kteří cluster provozují nebo na něm nasazují aplikace a služby. Toto téma je podrobněji popsáno z pohledu DevOps v části Věnované nasazení (CI/CD) níže.

Na úrovni clusteru existuje také několik aspektů souvisejících s odchozím provozem:

• Aktualizace uzlů (pro Ubuntu)
• Data monitorování (odesílaná do Azure LogAnalytics)
• Další agenti, kteří vyžadují odchozí provoz (specifické pro prostředí každého nasazéru)

Než nasadíte cluster Kubernetes pomocí modulu AKS, naplánujte si konečný návrh sítě. Místo vytvoření vyhrazeného Virtual Network může být efektivnější nasadit cluster do existující sítě. Můžete například využít stávající připojení VPN typu Site-to-Site, které je už nakonfigurované ve vašem prostředí služby Azure Stack Hub.

Infrastruktura

Infrastruktura označuje přístup ke koncovým bodům správy služby Azure Stack Hub. Koncové body zahrnují portály tenanta a správce a koncové body správce a tenanta Azure Resource Manager. Tyto koncové body se vyžadují pro provoz služby Azure Stack Hub a jejích základních služeb.

Důležité informace o datech a úložišti

Ve dvou samostatných clusterech Kubernetes se nasadí dvě instance naší aplikace ve dvou instancích služby Azure Stack Hub. Tento návrh bude vyžadovat, abychom zvážili, jak mezi nimi replikovat a synchronizovat data.

S Azure máme integrovanou funkci replikace úložiště napříč několika oblastmi a zónami v cloudu. V současné době se službou Azure Stack Hub neexistují žádné nativní způsoby replikace úložiště mezi dvěma různými instancemi služby Azure Stack Hub – tvoří dva nezávislé cloudy bez zastřešujícího způsobu jejich správy jako sady. Plánování odolnosti aplikací běžících ve službě Azure Stack Hub vás nutí zvážit tuto nezávislost při návrhu a nasazení aplikací.

Ve většině případů nebude replikace úložiště nutná pro odolnou a vysoce dostupnou aplikaci nasazenou v AKS. V návrhu aplikace byste ale měli zvážit nezávislé úložiště na instanci služby Azure Stack Hub. Pokud je tento návrh problém nebo cesta k nasazení řešení ve službě Azure Stack Hub, existují možná řešení od Microsoft partnerů, kteří poskytují přílohy úložiště. Přílohy úložiště poskytují řešení replikace úložiště napříč několika službami Azure Stack Hub a Azure. Další informace najdete v tématu Partnerská řešení.

V naší architektuře byly zvažovány tyto vrstvy:

Konfigurace

Konfigurace zahrnuje konfiguraci služby Azure Stack Hub, modulu AKS a samotného clusteru Kubernetes. Konfigurace by měla být co nejvíce automatizovaná a uložená jako infrastruktura jako kód v systému správy verzí založeném na Gitu, jako je Azure DevOps nebo GitHub. Tato nastavení nelze snadno synchronizovat napříč několika nasazeními. Proto doporučujeme ukládat a používat konfiguraci z vnějšku a používat kanál DevOps.

Aplikace

Aplikace by měla být uložená v úložišti založeném na Gitu. Kdykoli dojde k novému nasazení, změnám aplikace nebo zotavení po havárii, je možné je snadno nasadit pomocí Azure Pipelines.

Data

Data jsou nejdůležitějším aspektem ve většině návrhů aplikací. Data aplikací musí zůstat synchronizovaná mezi různými instancemi aplikace. Data také potřebují strategii zálohování a zotavení po havárii, pokud dojde k výpadku.

Dosažení tohoto návrhu závisí do značné míry na volbě technologie. Tady je několik příkladů řešení pro implementaci databáze ve službě Azure Stack Hub způsobem s vysokou dostupností:

• Nasazení skupiny dostupnosti SQL Server 2016 do Azure a služby Azure Stack Hub
• Nasazení vysoce dostupného řešení MongoDB do Azure a služby Azure Stack Hub

Důležité informace o práci s daty v různých umístěních jsou ještě složitějším aspektem vysoce dostupného a odolného řešení. Rozmyslete si:

• Latence a síťové připojení mezi službou Azure Stack Hubs
• Dostupnost identit pro služby a oprávnění Každá instance služby Azure Stack Hub se integruje s externím adresářem. Během nasazování se rozhodnete použít Azure Active Directory (Azure AD) nebo Active Directory Federation Services (AD FS) (AD FS). Proto je možné použít jednu identitu, která může komunikovat s několika nezávislými instancemi služby Azure Stack Hub.

Provozní kontinuita a zotavení po havárii

Provozní kontinuita a zotavení po havárii (BCDR) je důležitým tématem ve službě Azure Stack Hub i v Azure. Hlavní rozdíl spočívá v tom, že ve službě Azure Stack Hub musí operátor spravovat celý proces BCDR. V Azure se části BCDR automaticky spravují pomocí Microsoft.

BCDR ovlivňuje stejné oblasti uvedené v předchozí části Důležité informace o datech a úložišti:

• Infrastruktura / konfigurace
• Dostupnost aplikace
• Data aplikací

A jak je uvedeno v předchozí části, za tyto oblasti zodpovídá operátor služby Azure Stack Hub a může se v jednotlivých organizacích lišit. Naplánujte BCDR podle dostupných nástrojů a procesů.

Infrastruktura a konfigurace

Tato část se zabývá fyzickou a logickou infrastrukturou a konfigurací služby Azure Stack Hub. Zabývá se akcemi v prostorech správce a tenanta.

Operátor služby Azure Stack Hub (nebo správce) zodpovídá za údržbu instancí služby Azure Stack Hub. Zahrnutí komponent, jako je síť, úložiště, identita a další témata, která jsou mimo rozsah tohoto článku. Další informace o specifikách operací služby Azure Stack Hub najdete v následujících zdrojích informací:

• Obnovení dat ve službě Azure Stack Hub pomocí služby Infrastructure Backup
• Povolení zálohování pro službu Azure Stack Hub z portálu pro správu
• Obnovení z katastrofické ztráty dat
• Osvědčené postupy pro službu Infrastructure Backup

Azure Stack Hub je platforma a prostředky infrastruktury, na které se budou nasazovat aplikace Kubernetes. Vlastníkem aplikace pro aplikaci Kubernetes bude uživatel služby Azure Stack Hub s uděleným přístupem k nasazení infrastruktury aplikace potřebné pro řešení. Infrastruktura aplikace v tomto případě znamená cluster Kubernetes nasazený pomocí modulu AKS a okolní služby. Tyto komponenty se nasadí do služby Azure Stack Hub omezené nabídkou služby Azure Stack Hub. Ujistěte se, že nabídka přijatá vlastníkem aplikace Kubernetes má dostatečnou kapacitu (vyjádřenou v kvótách služby Azure Stack Hub) pro nasazení celého řešení. Jak se doporučuje v předchozí části, nasazení aplikace by se mělo automatizovat pomocí infrastruktury jako kódu a kanálů nasazení, jako je Azure DevOps Azure Pipelines.

Další informace o nabídkách a kvótách služby Azure Stack Hub najdete v tématu Přehled služeb, plánů, nabídek a předplatných služby Azure Stack Hub.

Je důležité bezpečně uložit a uložit konfiguraci modulu AKS včetně jejích výstupů. Tyto soubory obsahují důvěrné informace používané pro přístup ke clusteru Kubernetes, takže musí být chráněný před zveřejněním pro uživatele, kteří nejsou správci.

Dostupnost aplikací

Aplikace by neměla spoléhat na zálohy nasazené instance. Standardním postupem je opětovné nasazení aplikace zcela podle vzorů infrastruktury jako kódu. Například opětovné nasazení pomocí Azure DevOps Azure Pipelines. Postup BCDR by měl zahrnovat opětovné nasazení aplikace do stejného nebo jiného clusteru Kubernetes.

Data aplikací

Data aplikací jsou důležitou součástí minimalizace ztráty dat. V předchozí části byly popsány techniky replikace a synchronizace dat mezi dvěma (nebo více) instancemi aplikace. V závislosti na infrastruktuře databáze (MySQL, MongoDB, MSSQL nebo jiné) používané k ukládání dat budou k dispozici různé techniky dostupnosti a zálohování databáze.

Doporučené způsoby, jak dosáhnout integrity, jsou následující:

• Nativní řešení zálohování pro konkrétní databázi.
• Řešení zálohování, které oficiálně podporuje zálohování a obnovení typu databáze používané vaší aplikací.

Důležité

Neukládejte zálohovaná data do stejné instance služby Azure Stack Hub, ve které se nacházejí data vaší aplikace. Úplný výpadek instance služby Azure Stack Hub by také ohrozil vaše zálohy.

Aspekty dostupnosti

Kubernetes ve službě Azure Stack Hub nasazené prostřednictvím modulu AKS není spravovaná služba. Jedná se o automatizované nasazení a konfiguraci clusteru Kubernetes s využitím infrastruktury Azure jako služby (IaaS). Proto poskytuje stejnou dostupnost jako základní infrastruktura.

Infrastruktura služby Azure Stack Hub je už odolná vůči selháním a poskytuje funkce, jako jsou skupiny dostupnosti, které umožňují distribuovat komponenty do několika domén selhání a aktualizačních domén. Základní technologie (clustering s podporou převzetí služeb při selhání) ale stále způsobuje výpadky virtuálních počítačů na ovlivněný fyzický server, pokud dojde k selhání hardwaru.

Je vhodné nasadit produkční cluster Kubernetes i úlohu do dvou (nebo více) clusterů. Tyto clustery by měly být hostované v různých umístěních nebo datových centrech a používat technologie, jako je Azure Traffic Manager, ke směrování uživatelů na základě doby odezvy clusteru nebo zeměpisné oblasti.

Zákazníci, kteří mají jeden cluster Kubernetes, se obvykle připojují k IP adrese služby nebo názvu DNS dané aplikace. V nasazení s více clustery by se zákazníci měli připojit k názvu DNS Traffic Manageru, který odkazuje na služby nebo příchozí přenos dat v každém clusteru Kubernetes.

Poznámka

Tento model je také osvědčeným postupem pro (spravované) clustery AKS v Azure.

Samotný cluster Kubernetes, nasazený prostřednictvím modulu AKS, by měl obsahovat alespoň tři hlavní a dva pracovní uzly.

Aspekty identity a zabezpečení

Identita a zabezpečení jsou důležitá témata. Zejména v případě, že řešení zahrnuje nezávislé instance služby Azure Stack Hub. Kubernetes i Azure (včetně služby Azure Stack Hub) mají odlišné mechanismy pro řízení přístupu na základě role (RBAC):

• Azure RBAC řídí přístup k prostředkům v Azure (a službě Azure Stack Hub), včetně možnosti vytvářet nové prostředky Azure. Oprávnění je možné přiřadit uživatelům, skupinám nebo instančním objektům. (Instanční objekt je identita zabezpečení používaná aplikacemi.)
• Kubernetes RBAC řídí oprávnění k rozhraní Kubernetes API. Například vytváření podů a jejich výpis jsou akce, které je možné autorizovat (nebo odepřít) uživateli prostřednictvím řízení přístupu na základě role. Pokud chcete uživatelům přiřadit oprávnění Kubernetes, vytvoříte role a vazby rolí.

Identita služby Azure Stack Hub a řízení přístupu na základě role

Azure Stack Hub nabízí dvě možnosti zprostředkovatele identity. Poskytovatel, který použijete, závisí na prostředí a na tom, jestli je spuštěný v připojeném nebo odpojeném prostředí:

• Azure AD – lze použít pouze v připojeném prostředí.
• ADFS s tradiční doménovou strukturou Active Directory – dá se použít v připojeném i odpojeném prostředí.

Zprostředkovatel identity spravuje uživatele a skupiny, včetně ověřování a autorizace pro přístup k prostředkům. Přístup je možné udělit prostředkům služby Azure Stack Hub, jako jsou předplatná, skupiny prostředků a jednotlivé prostředky, jako jsou virtuální počítače nebo nástroje pro vyrovnávání zatížení. Pokud chcete mít konzistentní model přístupu, měli byste zvážit použití stejných skupin (přímých nebo vnořených) pro všechny služby Azure Stack Hub. Tady je příklad konfigurace:

Příklad obsahuje vyhrazenou skupinu (pomocí AAD nebo ADFS) pro konkrétní účel. Chcete-li například udělit oprávnění přispěvatele pro skupinu prostředků, která obsahuje naši infrastrukturu clusteru Kubernetes v konkrétní instanci služby Azure Stack Hub (tady Je to přispěvatel clusteru Seattle K8s). Tyto skupiny se pak vnořují do celkové skupiny, která obsahuje podskupiny pro každou službu Azure Stack Hub.

Náš ukázkový uživatel teď bude mít oprávnění Přispěvatel k oběma skupinám prostředků, které obsahují celou sadu prostředků infrastruktury Kubernetes. Uživatel bude mít přístup k prostředkům v obou instancích služby Azure Stack Hub, protože instance sdílejí stejného zprostředkovatele identity.

Důležité

Tato oprávnění se týkají pouze služby Azure Stack Hub a některých prostředků nasazených nad ním. Uživatel s touto úrovní přístupu může způsobit velké škody, ale nemá přístup k virtuálním počítačům Kubernetes IaaS ani k rozhraní API Kubernetes bez dalšího přístupu k nasazení Kubernetes.

Identita Kubernetes a RBAC

Cluster Kubernetes ve výchozím nastavení nepoužívá stejného zprostředkovatele identity jako podkladový Azure Stack Hub. Virtuální počítače hostující cluster Kubernetes, hlavní a pracovní uzly používají klíč SSH zadaný během nasazování clusteru. Tento klíč SSH se vyžaduje pro připojení k těmto uzlům pomocí SSH.

Rozhraní API Kubernetes (například pomocí ) je také chráněno kubectlúčty služeb, včetně výchozího účtu služby správce clusteru. Přihlašovací údaje pro tento účet služby jsou zpočátku uložené v .kube/config souboru na hlavních uzlech Kubernetes.

Správa tajných kódů a přihlašovací údaje aplikace

Pokud chcete ukládat tajné kódy, jako jsou připojovací řetězce nebo přihlašovací údaje k databázi, máte několik možností, mezi které patří:

• Azure Key Vault
• Tajné klíče Kubernetes
• Řešení třetích stran, jako je trezor HashiCorp (spuštěný v Kubernetes)

Neuchovávejte tajné kódy ani přihlašovací údaje ve formátu prostého textu v konfiguračních souborech, kódu aplikace ani ve skriptech. A neukládejte je do systému správy verzí. Místo toho by automatizace nasazení měla podle potřeby načíst tajné kódy.

Oprava a aktualizace

Proces opravy a aktualizace (PNU) v Azure Kubernetes Service je částečně automatizovaný. Upgrady verzí Kubernetes se aktivují ručně, zatímco aktualizace zabezpečení se použijí automaticky. Tyto aktualizace můžou zahrnovat opravy zabezpečení operačního systému nebo aktualizace jádra. AKS automaticky nerestartuje tyto linuxové uzly, aby se proces aktualizace dokončil.

Proces PNU pro cluster Kubernetes nasazený pomocí modulu AKS ve službě Azure Stack Hub je nespravovaný a zodpovídá za to operátor clusteru.

Modul AKS pomáhá se dvěma nejdůležitějšími úlohami:

• Upgrade na novější verzi image Kubernetes a základního operačního systému
• Upgrade pouze základní image operačního systému

Novější základní image operačního systému obsahují nejnovější opravy zabezpečení operačního systému a aktualizace jádra.

Mechanismus bezobslužného upgradu automaticky nainstaluje aktualizace zabezpečení vydané před tím, než bude na marketplace služby Azure Stack Hub k dispozici nová základní verze image operačního systému. Bezobslužný upgrade je ve výchozím nastavení povolený a instaluje aktualizace zabezpečení automaticky, ale nerestartuje uzly clusteru Kubernetes. Restartování uzlů je možné automatizovat pomocí opensourcového KUbernetes REboot Daemon (kured)). Kured sleduje linuxové uzly, které vyžadují restartování, a pak automaticky zpracují přeplánování spuštěných podů a procesu restartování uzlu.

Důležité informace o nasazení (CI/CD)

Azure a Azure Stack Hub zpřístupňují stejná rozhraní REST API azure Resource Manager. Tato rozhraní API se řeší stejně jako jakýkoli jiný cloud Azure (Azure, Azure China 21Vianet Azure Government). Mezi cloudy můžou existovat rozdíly ve verzích rozhraní API a Služba Azure Stack Hub poskytuje pouze podmnožinu služeb. Identifikátor URI koncového bodu správy se také liší pro každý cloud a každou instanci služby Azure Stack Hub.

Kromě zmíněných drobných rozdílů poskytují rozhraní REST API Azure Resource Manager konzistentní způsob interakce s Azure i službou Azure Stack Hub. Tady je možné použít stejnou sadu nástrojů jako v jakémkoli jiném cloudu Azure. K nasazení a orchestraci služeb ve službě Azure Stack Hub můžete použít Azure DevOps, nástroje, jako je Jenkins nebo PowerShell.

Důležité informace

Jedním z hlavních rozdílů v nasazeních služby Azure Stack Hub je otázka přístupnosti internetu. Přístupnost z internetu určuje, jestli chcete pro úlohy CI/CD vybrat agenta sestavení hostovaného Microsoft nebo agenta sestavení v místním prostředí.

Agent v místním prostředí může běžet nad službou Azure Stack Hub (jako virtuální počítač IaaS) nebo v síťové podsíti, která má přístup ke službě Azure Stack Hub. Další informace o rozdílech najdete v tématu Agenti Azure Pipelines .

Následující obrázek vám pomůže rozhodnout, jestli potřebujete agenta sestavení v místním prostředí nebo Microsoft agenta sestavení hostovaného v místním prostředí:

• Jsou koncové body správy služby Azure Stack Hub přístupné přes internet?
  • Ano: Azure Pipelines můžeme použít s agenty hostovanými Microsoft pro připojení ke službě Azure Stack Hub.
  • Ne: Potřebujeme agenty v místním prostředí, kteří se můžou připojit ke koncovým bodům správy služby Azure Stack Hub.
• Je náš cluster Kubernetes přístupný přes internet?
  • Ano: Azure Pipelines s agenty hostovanými Microsoft můžeme použít k přímé interakci s koncovým bodem rozhraní API Kubernetes.
  • Ne: Potřebujeme agenty v místním prostředí, kteří se můžou připojit ke koncovému bodu rozhraní API clusteru Kubernetes.

Ve scénářích, kdy jsou koncové body správy služby Azure Stack Hub a rozhraní API Kubernetes přístupné přes internet, může nasazení používat agenta hostovaného Microsoft. Výsledkem tohoto nasazení bude architektura aplikace následujícím způsobem:

Pokud koncové body Azure Resource Manager, rozhraní Kubernetes API nebo obojí nejsou přímo přístupné přes internet, můžeme ke spuštění kroků kanálu využít agenta sestavení v místním prostředí. Tento návrh vyžaduje méně připojení a dá se nasadit pouze s místním síťovým připojením ke koncovým bodům Azure Resource Manager a rozhraním API Kubernetes:

Poznámka

A co odpojené scénáře? Ve scénářích, kdy Azure Stack Hub nebo Kubernetes nebo oba nemají internetové koncové body správy, je stále možné pro vaše nasazení použít Azure DevOps. Můžete použít buď fond agentů v místním prostředí (což je agent DevOps spuštěný místně nebo samotný Azure Stack Hub), nebo zcela místní Azure DevOps Server. Agent v místním prostředí potřebuje pouze odchozí připojení HTTPS (TCP/443) k internetu.

Model může používat cluster Kubernetes (nasazený a orchestrovaný pomocí modulu AKS) v každé instanci služby Azure Stack Hub. Zahrnuje aplikaci skládající se z front-endu, back-endových služeb střední vrstvy (například MongoDB) a kontroleru příchozího přenosu dat založeného na nginx. Místo použití databáze hostované v clusteru K8s můžete využít externí úložiště dat. Mezi možnosti databáze patří MySQL, SQL Server nebo jakýkoli druh databáze hostované mimo Azure Stack Hub nebo v IaaS. Konfigurace, jako je tato, tady nejsou v oboru.

Partnerská řešení

Existují Microsoft partnerská řešení, která mohou rozšířit možnosti služby Azure Stack Hub. Tato řešení byla shledána užitečná při nasazování aplikací spuštěných v clusterech Kubernetes.

Řešení úložiště a dat

Jak je popsáno v tématu Důležité informace o datech a úložišti, Azure Stack Hub v současné době nemá nativní řešení pro replikaci úložiště napříč několika instancemi. Na rozdíl od Azure neexistuje možnost replikace úložiště napříč několika oblastmi. Ve službě Azure Stack Hub je každá instance svým vlastním jedinečným cloudem. Od Microsoft partnerů jsou však k dispozici řešení, která umožňují replikaci úložiště napříč službami Azure Stack Hubs a Azure.

SCALITY

Scality poskytuje webové úložiště, které od roku 2009 pohánělo digitální firmy. Scality RING, naše softwarově definované úložiště, mění komoditní servery x86 na neomezený fond úložiště pro jakýkoli typ dat – soubor a objekt – v petabajtovém měřítku.

CLOUDIAN

Cloudian zjednodušuje podnikové úložiště díky neomezenému škálovatelnému úložišti, které konsoliduje velké datové sady do jediného snadno spravovaného prostředí.

Další kroky

Další informace o konceptech uvedených v tomto článku:

• Škálování napříč cloudy a vzory geograficky distribuovaných aplikací ve službě Azure Stack Hub
• Architektura mikroslužeb v Azure Kubernetes Service (AKS)

Až budete připraveni otestovat příklad řešení, pokračujte průvodcem nasazením clusteru Kubernetes s vysokou dostupností. Průvodce nasazením obsahuje podrobné pokyny pro nasazení a testování komponent.