Upravit

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 nativní rozšíření clusteru pro AKS. Rozšíření clusteru poskytují 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 Nasazení aplikací konzistentně 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 konfigurace Mapy, a potvrdit změny přímo do úložiště GitHub.

Tok dat pro tento scénář je následující:

  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. Dva příklady jsou Minio a Alibaba Cloud OSS, ale existují i jiné.
  • 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.

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

Diagram implementace 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. Data procházejí tímto scénářem:

  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ě Azure 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

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

Tok dat pro tento scénář je následující:

  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 sestavy a vizualizuje rozdíly a současně poskytuje zařízení 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 akcím můžete použít také 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: Použití GitOps s Argo CD, GitHub Actions a AKS k implementaci CI/CD

Diagram implementace 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. Data procházejí tímto scénářem:

  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ě Azure 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 nebo 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í. Tento článek popisuje některé běžné možnosti použití GitOps společně s clusterem AKS.

Podle principů GitOps musí být požadovaný stav systému spravovaného GitOps následující:

  1. 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.
  2. Správa verzí a neměnnost: Požadovaný stav je uložený způsobem, který vynucuje neměnnost a správu verzí a zachovává úplnou historii verzí.
  3. Načítané automaticky: Agenti softwaru automaticky vyžádali deklarace požadovaného stavu ze zdroje.
  4. Nepřetržitě odsouhlasené: Agenti softwaru nepřetržitě sledují skutečný stav systému a pokoušejí se použít požadovaný stav.

V GitOps infrastruktura jako kód (IaC) používá 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ím způsobem 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í.

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 různé týmy, aby jim poskytly aktuální stav 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, aby stav clusteru mohl změnit jenom GitOps, můžete omezit přímý přístup ke clusteru. Existují různé způsoby, jak to udělat, včetně řízení přístupu na základě role v Azure (RBAC), kontrolerů přístupu a dalších nástrojů.

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

V rámci základní konfigurace je možné nasadit clustery AKS. Příkladem je, že před nasazením úloh musíte nasadit sadu sdílených služeb nebo konfiguraci. Tyto sdílené služby můžou konfigurovat doplňky AKS, například:

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. Architektura standardních hodnot pro cluster AKS navrhuje použití GitOps pro spouštění. Pokud používáte rozšíření Flux, můžete clustery spustit velmi 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í je přínosné pro všechny organizace, které chtějí využívat výhody nasazování aplikací a infrastruktury jako kódu s protokolem auditu každé změny.

GitOps chrání vývojáře před složitostmi správy prostředí kontejneru. 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í. GitOps tímto způsobem zvyšuje produktivitu vývojářů.

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 naleznete v tématu Microsoft Azure Well-Architected Framework.

Spolehlivost

Spolehlivost zajišťuje, aby vaše aplikace splňovala závazky, které jste udělali pro své zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.

Jedním z klíčových pilířů spolehlivosti je odolnost. Cílem odolnosti proti chybám je obnovení plně funkčního stavu aplikace co nejdříve po selhání. Pokud cluster přestane být dostupný, GitOps může rychle vytvořit nový. 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 tématu Přehled pilíře 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átor GitOps (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ě úlohy nastavení 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í žádostí o přijetí změn můžete provádět změny a mít aspoň jednu další osobu, která kontroluje každou žádost o přijetí změn. K automatické kontrole použijte také žádosti o přijetí změn.
  • Kontrola žádosti o přijetí změn: Vyžaduje, 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í. Také povolte pouze potvrzení, která jsou podepsána, aby se zabránilo změnám.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

  • Na úrovni Free nabízí AKS 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ů.
  • GitHub nabízí bezplatnou službu, ale pokud chcete používat pokročilé funkce související 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 na stránce s cenami GitHubu.
  • Azure DevOps nabízí úroveň Free, kterou můžete použít v některých scénářích.
  • K odhadu nákladů použijte cenovou kalkulačku Azure.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v tématu Přehled pilíře efektivity 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ě, pouze provedením operací Gitu. Graf potvrzení stále obsahuje všechna potvrzení, takže může pomoct s analýzou po mortemu.

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

Následující seznam obsahuje odkazy na informace o nasazení pěti scénářů:

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

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

Další kroky