Disciplíny CI/CD a GitOps s využitím Kubernetes s podporou Azure Arc

  • Článek

Jako konstruktor nativní pro cloud vyžaduje Kubernetes přístup nativní pro cloud pro nasazení a provoz. Pomocí GitOps deklarujete požadovaný stav nasazení založených na aplikaci v souborech uložených v úložištích Git. Aplikace mají objekty Kubernetes, které potřebují spustit, což může zahrnovat nasazení, horizontální automatické škálování podů, služby a konfiguraci Mapy. Operátoři Kubernetes běží v clusterech a průběžně odsouhlasují stav každého clusteru s požadovaným stavem deklarovaným v úložišti Git. Tito operátoři načítá soubory z vašich úložišť Git a aplikují požadovaný stav na clustery. Operátory také nepřetržitě zajišťují, že váš cluster zůstane v požadovaném stavu.

Implementace GitOps vám umožní:

  • Zlepšete celkový přehled o stavu a konfiguraci clusteru Kubernetes.
  • Projděte si jednoduchou historii auditování a verzí změn v clusteru prostřednictvím historie změn Gitu, která ukazuje, kdo provedl změny, kdy se tyto změny provedly a proč.
  • Automaticky opravovat posuny, ke kterým může dojít ve vašem clusteru.
  • Vrácení konfigurace Kubernetes do předchozí verze prostřednictvím příkazů pro vrácení zpět Gitu nebo vrácení zpět Gitu Opětovné vytvoření nasazení clusteru pro scénáře zotavení po havárii se také stává rychlým a jednoduchým procesem, protože vaše konfigurace požadovaného clusteru Kubernetes je uložená v Gitu.
  • Zvyšte zabezpečení snížením počtu účtů služeb, které jsou potřeba k tomu, aby vaše clustery měly oprávnění k nasazení.
  • Implementujte kanál CI/CD pro nasazování aplikací do clusteru.

GitOps v Kubernetes s podporou Azure Arc používá rozšíření, které implementuje flux, oblíbenou opensourcovou sadu nástrojů. Flux je operátor, který automatizuje nasazení konfigurace GitOps ve vašem clusteru. Flux poskytuje podporu pro běžné zdroje souborů (úložiště Git, úložiště Helm, kbelíky) a typy šablon (YAML, Helm a Kustomize). Flux také podporuje víceklientské prostředí a správu závislostí nasazení mimo jiné.

Architektura

Následující diagramy znázorňují koncepční referenční architekturu, která zvýrazňuje zřizování instalace rozšíření clusteru Flux v clusteru, proces konfigurace GitOps pro cluster Kubernetes s podporou Azure Arc a GitOps Flow.

Proces zřizování rozšíření clusteru Flux v2:

Diagram that shows Flux extension installation.

Proces konfigurace GitOps:

Diagram that shows how to configure GitOps.

GitOps Flow zobrazující aktualizaci aplikace:

Diagram that shows a typical GitOps workflow.

Aspekty návrhu

Při plánování implementace GitOps pro Kubernetes s podporou Azure Arc si projděte následující aspekty návrhu.

Konfigurace

Vezměte v úvahu různé vrstvy konfigurace v clusteru Kubernetes a povinnosti spojené s jejich zřizováním.

Vrstvy konfigurace

  • Konfigurace aplikace potřebná k nasazení aplikace a souvisejících objektů Kubernetes do clusteru, jako jsou prostředky Deployment, Service, HPA a ConfigMap. Konfigurace aplikací se obvykle aplikují na konfiguraci GitOps na úrovni oboru názvů, což vyžaduje, aby komponenty aplikace byly nakonfigurovány pouze v rámci jednoho oboru názvů.
  • Konfigurace na úrovni clusteru pro vytváření objektů Kubernetes, jako jsou obory názvů, účty služeb, role a vazby rolí a další zásady pro celý cluster.
  • Komponenty pro celý cluster, jako je kontroler příchozích dat, monitorování a zásobník zabezpečení a různí agenti, kteří pracují v rámci clusteru.

Odpovědnosti

  • Vývojáři aplikací zodpovídají za nasdílení zdrojového kódu, aktivaci sestavení a vytváření imagí kontejnerů.
  • Operátoři aplikací zodpovídají za údržbu úložišť aplikací, konfigurací, proměnných prostředí, grafů helmu specifických pro aplikace, kustomizace atd.
  • Za nastavení standardních hodnot vašeho clusteru zodpovídají operátoři clusteru. Obvykle se zabývají nastavením komponent a zásad pro celý cluster. Spravují adresář úložiště Git nebo adresáře, které obsahují běžné nástroje infrastruktury, jako jsou obory názvů, účty služeb, vazby rolí, CRD, zásady pro celý cluster, komponenty příchozího přenosu dat atd.

Struktura úložiště

Při výběru struktury úložiště Git zvažte kompromisy. Zvolená struktura definuje stav clusteru Kubernetes, který zahrnuje aplikace a komponenty pro celý cluster. V závislosti na tom, jaké povinnosti a osoby identifikujete, je důležité zvážit veškerou nezbytnou spolupráci nebo požadovanou nezávislost týmu, kterou vyžadují různé možnosti struktury úložiště.

Můžete použít jakoukoli strategii větvení, kterou chcete použít pro úložiště kódu, protože ji používá jenom proces kontinuální integrace (CI).

V případě úložišť konfigurace GitOps zvažte následující strategie založené na obchodních potřebách, velikosti a nástrojích vaší organizace:

  • Jedno úložiště (jedna větev v prostředí):
    • Umožňuje maximální flexibilitu pro řízení zásad a oprávnění Gitu pro každou větev, která představuje prostředí.
    • Nevýhodou je, že neexistuje sdílení společné konfigurace mezi prostředími, protože nástroje, jako je Kustomize , nefungují s větvemi Gitu.
  • Jedno úložiště (jeden adresář v prostředí):
    • Tento přístup můžete implementovat pomocí nástrojů, jako je Kustomize, což umožňuje definovat základní konfiguraci pro objekty Kubernetes a sadu artefaktů (tj. oprav) pro vaše prostředí, které přepisuje konfigurace v základu.
    • Tento přístup může snížit duplicitní soubory YAML pro každé prostředí, ale také snižuje oddělení konfigurace mezi prostředími. Provedení jediné změny v úložišti má potenciál ovlivnit všechna prostředí najednou, takže je nutné vědět, jak změny ovlivňují základní adresáře, a postupovat obezřetně.
  • Několik úložišť (každé slouží konkrétnímu účelu):
    • Můžete ho použít k oddělení úložišť konfigurace pro každou aplikaci, tým, vrstvu nebo tenanta.
    • Díky tomu můžou mít týmy více nezávislé řízení, ale přesouvají se od principu definování stavu systému v jednom úložišti, aby se zlepšila centrální konfigurace, viditelnost a kontrola nasazení do clusteru.
    • Nastavení více úložišť se doporučuje pro potřeby architektury s více tenanty. Jeho součástí je řízení přístupu na základě role (RBAC) a zabezpečení, které omezuje, jakou konfiguraci může tým nebo tenant přiřazený k určitému úložišti použít, například může povolit nasazení jenom do určitých oborů názvů.

Další způsoby strukturování úložiště najdete v průvodci technologií Flux.

Konfigurace aplikací a platforem

Operátory platformy a operátory aplikací mají několik možností pro správu konfigurace Kubernetes:

  • Nezpracované soubory YAML Kubernetes, které představují specifikace YAML pro každý objekt rozhraní API Kubernetes, který nasazujete, můžou dobře fungovat pro jednotlivá prostředí. Nevýhodou použití nezpracovaných souborů YAML je to, že přizpůsobení je obtížné, když začnete začlenit více prostředí, protože potřebujete duplikovat soubory YAML a není vhodné použít metodu opětovného použití.
  • Helm je nástroj pro správu balíčků pro objekty Kubernetes. Jedná se o platnou možnost Operátory clusteru, které můžou použít k instalaci aplikací třetích stran mimo rozsah. Ujistěte se, že jako nástroj pro správu konfigurace pro interní aplikace nepoužíváte příliš velké šablony, protože může být složité spravovat s rostoucími šablonami.
    • Pokud používáte Helm, flux obsahuje kontroler Helm, který umožňuje deklarativní správu verzí Chart Helmu pomocí manifestů Kubernetes. Můžete vytvořit objekt HelmRelease pro správu daného procesu.
  • Kustomize je nativní nástroj pro správu konfigurace Kubernetes, který představuje způsob přizpůsobení konfigurace aplikace bez šablony.
    • Pokud používáte Kustomize, flux obsahuje kontroler Kustomize, který se specializuje na spouštění kanálů průběžného doručování pro infrastrukturu a úlohy definované pomocí manifestů Kubernetes a sestavených pomocí Kustomize. Můžete vytvořit objekt Kustomization pro správu daného procesu.
  • S Kubernetes s podporou Azure Arc nemusíte spravovat životní cyklus a podporu komponent sami, můžete použít seznam dostupných rozšíření , která spravuje a podporuje Microsoft. Tato rozšíření se spravují prostřednictvím Azure Resource Manageru. Některá z těchto rozšíření, jako je poskytovatel tajných kódů služby Azure Key Vault, mají alternativy open source. Správa komponent mimo proces rozšíření poskytuje větší kontrolu nad komponentami, ale také vyžaduje větší režii pro podporu a správu životního cyklu.

Tok kontinuální integrace a průběžného doručování (CI/CD)

Následující části obsahují důležité informace o procesu aktualizace kanálů aplikací a komponent.

Kanál aplikace

  • Zvažte sestavení, testování a ověřování aplikací, které potřebujete zahrnout do procesu CI. Mezi ně patří lintování a testování související se zabezpečením, integrací a výkonem, které potřebujete k vytvoření kandidáta verze (RC) pro nasazení prostředí.
  • Pomocí tradiční metody nasazení push můžete překlenout mezeru mezi imagí kontejneru sestavení ve vašem kanálu CI a jejím nasazením v clusteru voláním rozhraní KUBERNEtes API přímo z kanálu nasazení.

Abyste se vyhnuli ručním změnám konfigurace úložiště GitOps, můžete kanál CD spustit jako účet služby, který má oprávnění k otevření žádostí o přijetí změn nebo potvrzení změny nové image kontejneru přímo do úložiště konfigurace. Tyto změny můžou také zřídit všechny objekty YAML vyžadované pro vaši aplikaci.

Následující diagram procesu znázorňuje tradiční proces CI aplikace začleněný se změnami, které podporují GitOps.

Diagram that shows the standard GitOps process.

Proces aktualizace součástí v rámci celého clusteru

  • Operátoři clusteru potřebují spravovat komponenty pro celý cluster, takže pravděpodobně nepochází z kanálu CD používaného k nasazení aplikací a služeb. Zvažte definováníprocesuho systému, který je specifický pro operátory cluster
  • Pokud potřebujete použít stejnou konfiguraci GitOps ve velkém měřítku pro clustery Kubernetes s podporou Azure Arc, zvažte použití služby Azure Policy, která může automaticky nainstalovat rozšíření Flux a použít konfiguraci GitOps na existující clustery Kubernetes s podporou Azure Arc nebo na nové clustery při jejich onboardingu do Azure Arc.

Při aktualizaci konfigurace pravděpodobně budete chtít ověřit, že se změny úspěšně použily ve vašem požadovaném prostředí. Oznámení můžete definovat v fluxu pro integraci s nástroji CI/CD, e-mailem nebo nástroji ChatOps a automaticky odesílat upozornění týkající se úspěšných změn a selhání nasazení. Informace o stavu nasazení najdete také na webu Azure Portal a prostřednictvím rozhraní příkazového řádku pro konfiguraci k8s a rozhraní API ARM.

Bezpečnostní aspekty

Při plánování implementace GitOps pro Kubernetes s podporou Azure Arc si projděte následující aspekty zabezpečení.

Ověřování úložiště

  • S GitOps můžete používat veřejné nebo privátní úložiště Git, ale vzhledem k citlivé povaze konfigurací Kubernetes doporučujeme použít privátní úložiště, které vyžaduje ověření pomocí klíče SSH nebo klíče rozhraní API. GitOps také pracuje s úložišti Git, která jsou přístupná jenom v rámci privátní sítě, pokud k němu má váš cluster Kubernetes přístup, ale toto nastavení omezuje vaši schopnost používat cloudové poskytovatele Gitu, jako jsou Azure Repos nebo GitHub.
  • Protokoly HTTPS i SSH nabízejí spolehlivé a zabezpečené připojení, které můžete použít pro připojení k nástroji pro správu zdrojového kódu. Https je ale často jednodušší nastavit a používá port, který zřídka vyžaduje otevření dalších portů v bránách firewall.

Zabezpečení úložiště a větví

  • Nastavte oprávnění a zásady větve v úložišti konfigurace. Vzhledem k tomu, že se vaše úložiště Git stane ústřední součástí nasazení Kubernetes, je důležité nastavit oprávnění k řízení, kdo může číst a aktualizovat kód ve větvi a implementovat zásady pro vynucení kvality kódu a správy změn vašeho týmu. V opačném případě může pracovní postup GitOps dodávat kód, který není v souladu se standardy vaší organizace.
  • Kanály žádostí o přijetí změn můžou pracovat se zásadami vaší větve a ověřovat konfiguraci YAML nebo nasazovat testovací prostředí podle potřeby. Brány pomáhají eliminovat chyby konfigurace a zvýšit zabezpečení a jistotu nasazení.
  • Při přiřazování přístupových oprávnění zvažte, kteří uživatelé ve vaší organizaci by měli mít přístup ke čtení úložiště, přístup k vytvoření žádosti o přijetí změn a přístup ke schválení žádosti o přijetí změn.

Správa tajných kódů

  • Vyhněte se ukládání tajných kódů zakódovaných ve formátu prostého textu nebo base64 do úložiště Git. Místo toho zvažte použití externího zprostředkovatele tajných kódů, jako je Azure Key Vault. Zprostředkovatel služby Azure Key Vault pro ovladač CSI úložiště tajných kódů umožňuje integrovat trezor klíčů Azure jako úložiště tajných kódů s clusterem Azure Kubernetes Service (AKS) pomocí svazku CSI. Tato služba je dostupná prostřednictvím rozšíření Kubernetes s podporou Azure Arc. HashiCorp Vault je alternativním poskytovatelem spravovaných tajných kódů třetí strany.
  • Dalším alternativním způsobem správy tajných kódů je použití zapečetěných tajných kódů Bitnami, které fungují z konceptu veřejných a privátních klíčů. To umožňuje operátorům ukládat jednosměrně šifrovaný tajný kód pomocí veřejného klíče v Gitu, který je možné dešifrovat pouze prostřednictvím privátního klíče, který používá kontroler SealedSecrets spuštěný ve vašem clusteru.

Doporučení k návrhu

Při plánování implementace GitOps pro Kubernetes s podporou Azure Arc si projděte následující doporučení návrhu.

Následující diagram obsahuje referenční architekturu, která znázorňuje zodpovědnosti, úložiště a kanály potřebné k implementaci procesu GitOps pomocí rozšíření Kubernetes Flux s podporou Azure Arc.

Diagram that shows a GitOps Reference flow.

Úložiště

Součástí návrhu jsou tři úložiště Git:

  • Úložiště kódu aplikace
    • Toto úložiště ukládá kód aplikace a všechny definice kanálu a konfigurační skripty.
    • Použijte strategii větvení pro vývoj, která je snadno pochopitelná a omezuje počet nežádoucích dlouhotrvajících větví.
  • Úložiště konfigurace aplikace
    • Toto úložiště ukládá konfigurace aplikací, včetně objektů Kubernetes, jako jsou Konfigurace Mapy, Nasazení, Služby a objekty HPA. Strukturujte toto úložiště s různými adresáři pro každou aplikaci. Flux synchronizuje změny z tohoto úložiště a cílové větve do clusteru.
    • Začleňte nástroje, které vývojářům aplikací a operátorům usnadňují sestavování počátečních konfigurací pro každé prostředí. Operátoři aplikací by měli definovat konfiguraci konkrétní aplikace Kubernetes, která používá správce balíčků, jako jsou Helm nebo konfigurační nástroje, jako je Kustomize, aby se zjednodušily konfigurace.
    • Vytvořte větev, která bude představovat každý typ prostředí. To umožňuje jemně odstupňovanou kontrolu nad změnami v jednotlivých konkrétních prostředích, jako jsou neprodukční a produkční prostředí.
    • Když je aplikace nasazená do konkrétního oboru názvů, použijte funkci oboru názvů v konfiguraci GitOps k vynucení konfigurace pouze pro určitý obor názvů.
  • Úložiště konfigurace na úrovni clusteru
    • Definujte komponenty pro celý cluster, jako je kontroler příchozího přenosu dat, obory názvů, RBAC, monitorování a zásobník zabezpečení pro správu operátorů clusteru. Flux synchronizuje změny z tohoto úložiště a cílové větve do clusteru.
    • Strukturujte toto úložiště s různými adresáři představujícími různé komponenty.
    • Vytvořte větev, která bude představovat každý typ prostředí. To umožňuje jemně odstupňovanou kontrolu nad změnami v jednotlivých konkrétních prostředích, jako jsou neprodukční a produkční prostředí.
    • Operátoři clusteru by měli použít správce balíčků, jako jsou nástroje Helm nebo konfigurační nástroje, jako jsou překryvné vrstvy Kustomize, aby se zjednodušily konfigurace.

Proces aktualizace CI/CD a konfigurace

Aktualizace imagí CI/CD a kontejneru

  • Kanál CI
    • Vývojové týmy by měly definovat kanál CI prostřednictvím procesu, který zahrnuje sestavování, lintování, testování a nasdílení aplikace do registru kontejneru.
  • Kanál CD
    • Vytvořte kanál CD, ve kterém se spustí skript, který cílí na změny v úložišti konfigurace vaší aplikace. Tento skript vytvoří dočasnou větev zdrojovou z cílového prostředí, provede změnu verze značky image, potvrdí změnu a otevře žádost o přijetí změn pro cílovou větev prostředí. Tento kanál CD může mít fáze prostředí s příslušnými proměnnými prostředí, které budou cílit na správné úložiště a větev konfigurace GitOps.
    • Definujte kroky ručního schvalování pro fáze prostředí, abyste omezili nežádoucí žádosti o přijetí změn na všechna prostředí.
  • Povolte zásady větve v úložišti konfigurace aplikace, abyste vynutily kontrolu partnerského vztahu nebo schválení pro prostředí. To může zahrnovat minimální počet požadovaných kontrol nebo automatické schválení pro nižší prostředí. Zvažte také integrace a schválení třetích stran podle potřeby, aby splňovaly standardy vaší organizace.

Aktualizace konfigurace pro clustery a aplikace

  • Operátory clusteru a operátory aplikací definují konfiguraci v příslušných úložištích konfigurace. Tito uživatelé nevyžadují nástroje kanálu pro nabízení konfigurací. Místo toho používají nativní procesy potvrzení Gitu a PR k definování konfigurace a nasdílení změn do větve představující prostředí.
  • U nových definic konfigurace začněte definováním konfigurace v nižších prostředích, jako je vývoj, a pak přejděte na vyšší úroveň prostředí prostřednictvím sloučení a žádostí o přijetí změn. Konfigurace výběru určitých konfigurací se podle potřeby aktualizuje specifická pro určitá prostředí.

Zpětná vazba a upozorňování

  • Nakonfigurujte oznámení flux tak, aby upozorňovala, když konfigurace GitOps nemůžou synchronizovat nebo vyvolává chyby. Operátoři aplikací by měli nakonfigurovat výstrahy, které určují, kdy nasazení aplikace proběhlo úspěšně a je v pořádku. Operátoři clusteru by měli nakonfigurovat výstrahy, které určují, kdy došlo k selhání odsouhlasení součástí v rámci celého clusteru a kdy dochází k problémům se synchronizací s vaším úložištěm Git.
  • Implementujte gitOps Připojení or pro integraci zpětné vazby z agenta Flux do nástrojů CI/CD.

Doporučení zabezpečení

  • Projděte si doporučení zásad správného řízení a zabezpečení pro clustery Kubernetes s podporou Azure Arc.
  • Vyhněte se nežádoucímu přístupu k jakékoli konfiguraci clusteru pomocí privátního úložiště Git s ověřováním a autorizací, které můžete použít k definování libovolného úložiště konfigurace.
  • Přístup k úložišti Git prostřednictvím protokolu SSH a klíče SSH, pokud ho váš poskytovatel Git podporuje. Pokud je SSH nepoužitelný z důvodu omezení odchozího připojení nebo pokud váš poskytovatel Git nepodporuje požadované knihovny SSH, použijte vyhrazený účet služby a přidružte klíč rozhraní API k tomuto účtu, aby ho mohli používat. Pokud potřebujete alternativu k SSH při použití GitHubu, můžete vytvořit osobní přístupový token pro ověřování.
  • Nakonfigurujte zásady a oprávnění větví, které odpovídají zodpovědnostem vašeho clusteru. Nastavte minimální počet revidujících ke schválení změn.
  • Nakonfigurujte kanál žádosti o přijetí změn pro ověření konfigurací a syntaxe YAML a volitelně nasaďte testovací cluster Kubernetes. Nastavte zásadu větve, která vyžaduje, aby se tento kanál úspěšně spustil, než bude možné přijmout sloučení.
  • Implementujte tajné kódy pomocí zprostředkovatele služby Azure Key Vault pro ovladač CSI úložiště tajných kódů, který umožní integraci služby Azure Key Vault jako úložiště tajných kódů s clusterem Kubernetes s podporou Azure Arc prostřednictvím svazku CSI.
  • Rozšíření Flux podporuje konfigurace s oborem názvů a clusteru. Zvolte obor názvů, pokud by vaše konfigurace neměla mít přístup nad rámec jednoho oboru názvů.

Další kroky

Další informace o vaší cestě k hybridnímu a multicloudovém cloudu najdete v následujících článcích.