Sdílet prostřednictvím

GitOps pro Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHubu

GitOps je sada principů pro provoz a správu softwarového systému. Tento článek popisuje techniky použití principů GitOps k provozování a správě clusteru Azure Kubernetes Services (AKS).

Loga Flux, Argo CD, OPA Gatekeeper, Kubernetes a Git jsou ochranné známky příslušných společností. Použití těchto značek nevyžaduje žádné doporučení.

Architektura

Dva operátory GitOps, které můžete použít s AKS, jsou Flux a Argo CD. Oba jsou odstupňované projekty CNCF (Cloud Native Computing Foundation) a široce se používají. Následující scénáře ukazují způsoby jejich použití.

Scénář 1: GitOps s fluxem a AKS

Diagram GitOps s Flux v2, GitHubem a AKS.

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat pro scénář 1

Flux je rozšíření clusteru , které se nativně integruje s AKS. Rozšíření clusteru poskytuje platformu pro instalaci a správu řešení v clusteru AKS. K povolení fluxu jako rozšíření AKS můžete použít skripty webu Azure Portal, Azure CLI nebo infrastruktury jako kódu (IaC), například Terraform nebo Bicep. Azure Policy můžete použít také k použití konfigurací Flux v2 ve velkém měřítku v clusterech AKS. Další informace najdete v tématu Konzistentní nasazování aplikací ve velkém měřítku pomocí konfigurací Flux v2 a Azure Policy.

Flux může nasazovat manifesty Kubernetes, charty Helm a soubory Kustomization do AKS. Flux je proces založený na dotazování, takže dokáže detekovat, vyžádat a odsouhlasit změny konfigurace bez vystavení koncových bodů clusteru agentům sestavení.

V tomto scénáři můžou správci Kubernetes měnit objekty konfigurace Kubernetes, jako jsou tajné kódy a objekty ConfigMap, a potvrdit změny přímo do úložiště GitHub.

Následující tok dat odpovídá předchozímu diagramu:

  1. Vývojář potvrdí změny konfigurace v úložišti GitHub.

  2. Flux detekuje posun konfigurace v úložišti Git a načítá změny konfigurace.

  3. Flux odsouhlasí stav v clusteru Kubernetes.

Alternativy pro scénář 1

  • Flux můžete použít s jinými úložišti Git, jako jsou Azure DevOps, GitLab a Bitbucket.

  • Místo úložišť Git definuje rozhraní Flux Bucket API zdroj pro vytváření artefaktů pro objekty z řešení úložiště, jako jsou Amazon S3 a Kontejnery Google Cloud Storage. Můžete také použít řešení, které má rozhraní API kompatibilní s S3. Dvěma příklady jsou MinIO a Alibaba Cloud Object Storage Service (OSS), ale existují i jiná řešení.

  • Flux můžete také nakonfigurovat pro kontejner Azure Blob Storage jako zdroj pro vytváření artefaktů. Další informace najdete v tématu Konfigurace GitOps Flux v2 s využitím AKS a Kubernetes s podporou Azure Arc.

  • Flux v2 podporuje víceklientské prostředí tím, že umožňuje samostatným týmům nasazovat úlohy do jednoho sdíleného clusteru Kubernetes. Do clusteru je možné synchronizovat několik úložišť Git, která představují jiného tenanta. Aby se zajistila izolace úloh mezi týmy, může mít každý tým vlastní obor názvů nebo obory názvů v rámci clusteru AKS, ke kterému je přístup omezený prostřednictvím zásad řízení přístupu na základě role (RBAC) Kubernetes.

  • Flux může používat jeden cluster ke správě aplikací ve stejném clusteru nebo v jiných clusterech. Ústřední cluster AKS s operátorem Flux spravuje GitOps nepřetržité doručování aplikací a úloh infrastruktury do několika vedlejších clusterů AKS.

Scénář 2: Použití GitOps s Fluxem, GitHubem a AKS k implementaci CI/CD

Diagram znázorňující, jak implementovat CI/CD pomocí GitOps s Fluxem, GitHubem a AKS

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat pro scénář 2

Tento scénář je kanál DevOps založený na vyžádání obsahu pro typickou webovou aplikaci. Kanál používá k sestavení GitHub Actions. Pro nasazení používá flux jako operátor GitOps k vyžádání a synchronizaci aplikace.

Následující tok dat odpovídá předchozímu diagramu:

  1. Kód aplikace se vyvíjí pomocí integrovaného vývojového prostředí (IDE), jako je Visual Studio Code.

  2. Kód aplikace se potvrdí do úložiště GitHub.

  3. GitHub Actions sestaví image kontejneru z kódu aplikace a nasdílí image kontejneru do služby Azure Container Registry.

  4. GitHub Actions aktualizuje soubor nasazení manifestu Kubernetes s aktuální verzí image, která je založená na počtu verzí image kontejneru ve službě Container Registry.

  5. Operátor Flux detekuje posun konfigurace v úložišti Git a načítá změny konfigurace.

  6. Flux používá soubory manifestu k nasazení aplikace do clusteru AKS.

Scénář 3: GitOps s argo CD, úložištěm GitHubu a AKS

Diagram GitOps s Argo CD, GitHubem a AKS.

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat pro scénář 3

Argo CD můžete povolit jako rozšíření clusteru v AKS. V tomto scénáři může správce Kubernetes změnit objekty konfigurace Kubernetes, jako jsou tajné kódy a objekty ConfigMap, a potvrdit změny přímo do úložiště GitHub.

Následující tok dat odpovídá předchozímu diagramu:

  1. Správce Kubernetes provede změny konfigurace v souborech YAML a potvrdí změny do úložiště GitHub.

  2. Argo CD načítá změny z úložiště Git.

  3. Argo CD odsouhlasí změny konfigurace v clusteru AKS.

Argo CD nemusí automaticky synchronizovat požadovaný cílový stav do clusteru AKS. Implementuje se jako kontroler Kubernetes, který nepřetržitě monitoruje spuštěné aplikace. Porovná aktuální živý stav clusteru AKS s požadovaným cílovým stavem zadaným v úložišti Git. Argo CD hlásí a vizualizuje rozdíly, a poskytuje nástroje pro automatickou nebo ruční synchronizaci živého stavu zpět do požadovaného cílového stavu.

Argo CD poskytuje uživatelské rozhraní založené na prohlížeči. Můžete ho použít k přidání konfigurací aplikací, sledování stavu synchronizace s ohledem na cluster a zahájení synchronizace s clusterem. K těmto úlohám můžete také použít příkazový řádek Argo CD. Uživatelské rozhraní i rozhraní příkazového řádku poskytují funkce pro zobrazení historie změn konfigurace a vrácení zpět na předchozí verzi.

Ve výchozím nastavení se uživatelské rozhraní Argo CD a server rozhraní API nezobrazují. Pro přístup k nim doporučujeme vytvořit kontroler příchozího přenosu dat, který má interní IP adresu. Nebo můžete k jejich zveřejnění použít interní nástroj pro vyrovnávání zatížení .

Alternativy pro scénář 3

Jakékoli úložiště, které je kompatibilní s Gitem, včetně Azure DevOps, může sloužit jako zdrojové úložiště konfigurace.

Scénář 4: Implementace CI/CD s využitím GitOps s Argo CD, GitHub Actions a AKS

Diagram znázorňující, jak implementovat CI/CD pomocí GitOps s Argo CD, GitHubem a AKS

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat pro scénář 4

Tento scénář je kanál DevOps založený na vyžádání obsahu pro typickou webovou aplikaci. Kanál používá k sestavení GitHub Actions. Pro nasazení používá jako operátor GitOps cd Argo k načtení a synchronizaci aplikace.

Následující tok dat odpovídá předchozímu diagramu:

  1. Kód aplikace se vyvíjí pomocí integrovaného vývojového prostředí (IDE), jako je Visual Studio Code.

  2. Kód aplikace se potvrdí do úložiště GitHub.

  3. GitHub Actions sestaví image kontejneru z kódu aplikace a nasdílí image kontejneru do Container Registry.

  4. GitHub Actions aktualizuje soubor nasazení manifestu Kubernetes s aktuální verzí image, která je založená na počtu verzí image kontejneru ve službě Container Registry.

  5. Argo CD načítá z úložiště Git.

  6. Argo CD nasadí aplikaci do clusteru AKS.

Alternativy pro scénář 4

Jakékoli úložiště, které je kompatibilní s Gitem, včetně Azure DevOps, může sloužit jako zdrojové úložiště konfigurace.

Podrobnosti scénáře

GitOps je sada principů pro provoz a správu softwarového systému.

  • Používá správu zdrojového kódu jako jediný zdroj pravdy pro systém.

  • Používá vývojové postupy, jako je správa verzí, spolupráce, dodržování předpisů a kontinuální integrace a průběžné nasazování (CI/CD) pro automatizaci infrastruktury.

  • Můžete ho použít na jakýkoli softwarový systém.

GitOps se často používá ke správě clusteru Kubernetes a doručování aplikací.

Podle principů GitOps musí požadovaný stav systému spravovaného GitOps splňovat následující kritéria:

  • Deklarativní: Systém, který GitOps spravuje, musí mít svůj požadovaný stav vyjádřený deklarativním způsobem. Deklarace je obvykle uložená v úložišti Git.

  • Verzováno a neměnné: Požadovaný stav se ukládá způsobem, který vynucuje neměnnost a verzování a zachovává úplnou historii verzí.

  • Automaticky získáno: Softwaroví agenti automaticky získávají deklarace požadovaného stavu ze zdroje.

  • Nepřetržitě synchronizované: Softwaroví agenti nepřetržitě sledují aktuální stav systému a snaží se aplikovat požadovaný stav.

V GitOps používá IaC kód k deklaraci požadovaného stavu komponent infrastruktury, jako jsou virtuální počítače, sítě a brány firewall. Tento kód je řízen a auditovatelný.

Kubernetes popisuje vše od stavu clusteru až po nasazení aplikací deklarativně pomocí manifestů. GitOps pro Kubernetes umístí požadovanou infrastrukturu clusteru do správy verzí. Komponenta v clusteru, obvykle označovaná jako operátor, nepřetržitě synchronizuje deklarativní stav. Tento přístup umožňuje kontrolovat a auditovat změny kódu, které ovlivňují cluster. Zvyšuje zabezpečení tím, že podporuje princip nejnižších oprávnění (PoLP).

Agenti GitOps nepřetržitě odsouhlasí stav systému s požadovaným stavem uloženým v úložišti kódu. Někteří agenti GitOps můžou vrátit operace prováděné mimo cluster, například ruční vytváření objektů Kubernetes. Kontrolery přístupu například vynucují zásady pro objekty během operací vytváření, aktualizace a odstraňování. Pomocí nich můžete zajistit, aby se nasazení měnila pouze v případě, že se změní kód nasazení ve zdrojovém úložišti.

Pomocí GitOps můžete kombinovat nástroje pro správu a vynucování zásad a vynucovat zásady a poskytovat zpětnou vazbu k navrhovaným změnám zásad. Můžete nakonfigurovat oznámení pro jednotlivé týmy, abyste je mohli informovat o aktuálním stavu GitOps. Můžete například odesílat oznámení o úspěšných nasazeních a selháních odsouhlasení.

GitOps jako jediný zdroj pravdy

GitOps poskytuje konzistenci a standardizaci stavu clusteru a může pomoct zvýšit zabezpečení. GitOps můžete použít také k zajištění konzistentního stavu napříč několika clustery. GitOps může například použít stejnou konfiguraci napříč primárními clustery a clustery zotavení po havárii nebo ve farmě clusterů.

Pokud chcete vynutit GitOps jako jedinou metodu pro změnu stavu clusteru, omezte přímý přístup ke clusteru. K nastavení této konfigurace použijte řízení přístupu na základě role v Azure (Azure RBAC), kontrolery přístupu nebo jiné nástroje.

Použití GitOps ke spuštění počáteční konfigurace

V některých případech se nasazení clusteru AKS vyžaduje jako součást základní konfigurace. Před nasazením aplikačních úloh můžete například potřebovat nasadit sdílené služby nebo konfigurace na úrovni systému. Tyto sdílené služby můžou nakonfigurovat následující doplňky a nástroje:

Flux můžete povolit jako rozšíření, které se použije při vytváření clusteru AKS. Flux pak může spustit základní konfiguraci clusteru. Základní architektura clusteru AKS doporučuje ke spuštění GitOps. Pokud používáte rozšíření Flux, můžete clustery spustit brzy po nasazení.

Další nástroje a doplňky GitOps

Popsané scénáře můžete rozšířit na další nástroje GitOps. Jenkins X je další nástroj GitOps, který poskytuje pokyny pro integraci do Azure. Pomocí progresivních nástrojů pro doručování, jako je Flagger , můžete postupně přesouvat produkční úlohy nasazené prostřednictvím GitOps.

Potenciální případy použití

Toto řešení přináší výhody organizacím, které chtějí nasazovat aplikace a IaC a udržovat záznam auditu každé změny.

GitOps zjednodušuje správu kontejnerů pro vývojáře, což zvyšuje produktivitu. Vývojáři můžou dál pracovat se známými nástroji, jako je Git, ke správě aktualizací a nových funkcí.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace najdete v tématu Well-Architected Framework.

Spolehlivost

Spolehlivost pomáhá zajistit, aby vaše aplikace splňovala závazky, které jste pro své zákazníky udělali. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost.

Pokud cluster přestane být dostupný, gitOps by se měl použít jako součást vytváření nového clusteru. Používá úložiště Git jako jediný zdroj pravdy pro konfiguraci Kubernetes a logiku aplikace. Může vytvořit a použít konfiguraci clusteru a nasazení aplikace jako jednotku škálování a může vytvořit vzor razítka nasazení .

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu zabezpečení.

S přístupem GitOps nemají jednotliví vývojáři nebo správci přímý přístup ke clusterům Kubernetes, aby mohli použít změny nebo aktualizace. Místo toho uživatelé nasdílí změny do úložiště Git a operátora GitOps, jako je Flux nebo Argo CD, změny přečte a použije je v clusteru. Tento přístup se řídí osvědčeným postupem zabezpečení nejnižších oprávnění tím, že týmům DevOps neuděluje oprávnění k zápisu do rozhraní Kubernetes API. Ve scénářích diagnostiky nebo řešení potíží můžete udělit oprávnění clusteru po omezenou dobu pro případ.

Kromě konfigurace oprávnění úložiště zvažte implementaci následujících bezpečnostních opatření v úložištích Git, která se synchronizují s clustery AKS:

  • Ochrana větví: Chraňte větve, které představují stav clusterů Kubernetes, před tím, aby se do nich změny nasdílely přímo. Pomocí pull requestů (PR) provádějte změny, a minimálně jeden další člověk by měl zkontrolovat každý PR. K automatickým kontrolám používejte také PRs.

  • Kontrola žádosti o přijetí změn: Vyžadovat, aby žádosti o přijetí změn měly alespoň jeden kontrolor, aby vynutil zásadu čtyř očí. Pomocí funkce vlastníci kódu GitHubu můžete také definovat jednotlivce nebo týmy zodpovědné za kontrolu konkrétních souborů v úložišti.

  • Neměnná historie: Umožňuje pouze nová potvrzení nad existujícími změnami. Neměnná historie je zvláště důležitá pro účely auditování.

  • Další bezpečnostní opatření: Vyžadovat, aby uživatelé GitHubu aktivovali dvojúrovňové ověřování. Povolte pouze podepsané commity, aby se předešlo neoprávněným změnám.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů.

  • Úroveň Free AKS poskytuje bezplatnou správu clusteru. Náklady jsou omezené na výpočetní prostředky, úložiště a síťové prostředky, které AKS používá k hostování uzlů. Úroveň Free AKS nezahrnuje smlouvu o úrovni služeb (SLA) a nedoporučuje se pro produkční úlohy.

  • GitHub poskytuje bezplatnou službu, ale k používání pokročilých funkcí souvisejících se zabezpečením, jako jsou vlastníci kódu nebo požadované revidujícím, potřebujete týmový plán. Další informace najdete v tématu o cenách GitHubu.

  • Azure DevOps poskytuje úroveň Free, kterou můžete použít v některých scénářích.

  • K odhadu nákladů použijte cenovou kalkulačku Azure.

Efektivita provozu

Efektivita provozu se zabývá provozními procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu.

GitOps může zvýšit produktivitu DevOps. Jednou z nejužitečnějších funkcí je schopnost rychle vrátit zpět změny, které se chovají neočekávaně provedením operací Gitu. Graf potvrzení stále obsahuje všechna potvrzení, takže může pomoct s retrospektivní analýzou.

Týmy GitOps často spravují více prostředí pro stejnou aplikaci. Je typické mít několik fází aplikace, které se nasazují do různých clusterů nebo oborů názvů Kubernetes. Úložiště Git, což je jediný zdroj pravdy, ukazuje, které verze aplikací jsou aktuálně nasazené do clusteru.

Nasazení scénáře

Další informace o nasazení pěti scénářů najdete v následujících zdrojích informací:

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autor:

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se na LinkedIn.

Další kroky