Nasazení aplikací s Využitím GitOps (Flux v2) pro AKS a Kubernetes s podporou Azure Arc
Azure poskytuje funkci automatizovaného nasazení aplikací pomocí GitOps, která funguje se službou Azure Kubernetes Service (AKS) a clustery Kubernetes s podporou Azure Arc. Mezi klíčové výhody, které poskytuje přijetí GitOps pro nasazování aplikací do clusterů Kubernetes, patří:
- Nepřetržitý přehled o stavu aplikací spuštěných v clusterech.
- Oddělení obav mezi týmy pro vývoj aplikací a týmy infrastruktury Aplikační týmy nemusí mít zkušenosti s nasazeními Kubernetes. Technické týmy platformy obvykle vytvářejí samoobslužný model pro aplikační týmy a umožňují jim spouštět nasazení s větší jistotou.
- Schopnost znovu vytvořit clustery se stejným požadovaným stavem v případě chybového ukončení nebo horizontálního navýšení kapacity
V případě GitOps deklarujete požadovaný stav vašich clusterů Kubernetes v souborech v úložištích Git. Úložiště Git můžou obsahovat následující soubory:
- Manifesty ve formátu YAML, které popisují prostředky Kubernetes (jako jsou obory názvů, tajné kódy, nasazení a další)
- Charty Helm pro nasazování aplikací
- Soubory Kustomize k popisu změn specifických pro prostředí
Vzhledem k tomu, že tyto soubory jsou uložené v úložišti Git, jsou jejich verze a změny mezi verzemi se snadno sledují. Kontrolery Kubernetes běží v clusterech a průběžně sladit stav clusteru s požadovaným stavem deklarovaným v úložišti Git. Tito operátoři přetahují soubory z úložišť Git a aplikují na clustery požadovaný stav. Operátory také nepřetržitě zajišťují, že cluster zůstává v požadovaném stavu.
GitOps v Kubernetes s podporou Azure Arc nebo Azure Kubernetes Service používá flux, oblíbenou opensourcovou sadu nástrojů. Flux poskytuje podporu běžných zdrojů souborů (úložiště Git a Helm, Buckets, Azure Blob Storage) a typů šablon (YAML, Helm a Kustomize). Flux také podporuje správu závislostí pro více tenantů a nasazení mimo jiné.
Flux se nasazuje přímo do clusteru a řídicí rovina každého clusteru je logicky oddělená. Díky tomu se škáluje dobře na stovky a tisíce clusterů. Flux umožňuje čistě nasazení aplikací GitOps založených na vyžádání. Zdrojové úložiště ani žádný jiný cluster nepotřebuje přístup ke clusterům.
Rozšíření clusteru Flux
GitOps je povolený v clusteru Kubernetes nebo AKS s podporou Azure Arc jako Microsoft.KubernetesConfiguration/extensions/microsoft.flux
prostředek rozšíření clusteru. Rozšíření microsoft.flux
musí být nainstalováno v clusteru, než bude možné vytvořit jeden nebo více fluxConfigurations
. Rozšíření se nainstaluje automaticky při vytváření prvního Microsoft.KubernetesConfiguration/fluxConfigurations
v clusteru nebo ho můžete nainstalovat ručně pomocí portálu, Azure CLI (az k8s-extension create --extensionType=microsoft.flux
), šablony ARM nebo rozhraní REST API.
Kontrolery
Ve výchozím nastavení microsoft.flux
rozšíření nainstaluje kontrolery Flux (Source, Kustomize, Helm, Notification) a FluxConfig Custom Resource Definition (CRD) fluxconfig-agent
a fluxconfig-controller
. Volitelně můžete nainstalovat také flux image-automation
a image-reflector
kontrolery, které poskytují funkce pro aktualizaci a načítání imagí Dockeru.
Kontroler zdroje flux: Sleduje
source.toolkit.fluxcd.io
vlastní prostředky. Zpracovává synchronizaci mezi úložišti Git, úložišti Helm, kbelíky a úložištěm objektů blob Azure. Zpracovává autorizaci se zdrojem pro privátní úložiště Git, úložiště Helm a účty úložiště objektů blob v Azure. Zobrazí nejnovější změny zdroje prostřednictvím souboru archivu tar.Kontroler Flux Kustomize: Sleduje
kustomization.toolkit.fluxcd.io
vlastní prostředky. Použije kustomizaci nebo nezpracované soubory YAML ze zdroje do clusteru.Kontroler Flux Helm: Sleduje
helm.toolkit.fluxcd.io
vlastní prostředky. Načte přidružený graf ze zdroje úložiště Helm, který je na povrchu kontroleru zdroje.HelmChart
Vytvoří vlastní prostředek a použije proHelmRelease
cluster hodnoty definované zákazníkem s danou verzí, názvem a zákazníkem.Kontroler oznámení flux: Sleduje
notification.toolkit.fluxcd.io
vlastní prostředky. Přijímá oznámení ze všech kontrolerů Flux. Odesílá oznámení do uživatelem definovaných koncových bodů webhooku.Definice vlastních prostředků flux:
kustomizations.kustomize.toolkit.fluxcd.io
imagepolicies.image.toolkit.fluxcd.io
imagerepositories.image.toolkit.fluxcd.io
imageupdateautomations.image.toolkit.fluxcd.io
alerts.notification.toolkit.fluxcd.io
providers.notification.toolkit.fluxcd.io
receivers.notification.toolkit.fluxcd.io
buckets.source.toolkit.fluxcd.io
gitrepositories.source.toolkit.fluxcd.io
helmcharts.source.toolkit.fluxcd.io
helmrepositories.source.toolkit.fluxcd.io
helmreleases.helm.toolkit.fluxcd.io
fluxconfigs.clusterconfig.azure.com
FluxConfig CRD: Vlastní definice prostředků pro
fluxconfigs.clusterconfig.azure.com
vlastní prostředky, které definujíFluxConfig
objekty Kubernetes.fluxconfig-agent
: Zodpovídá za sledování nových nebo aktualizovanýchfluxConfigurations
prostředků Azure a za spuštění přidružené konfigurace Flux v clusteru. Také zodpovídá za nabízení změn stavu Flux v clusteru zpět do Azure pro každýfluxConfigurations
prostředek.fluxconfig-controller
: Sledujefluxconfigs.clusterconfig.azure.com
vlastní prostředky a reaguje na změny pomocí nové nebo aktualizované konfigurace strojů GitOps v clusteru.
Poznámka:
Rozšíření microsoft.flux
je nainstalované v flux-system
oboru názvů a má obor clusteru. Toto rozšíření nemůžete nainstalovat v oboru názvů.
Konfigurace fluxu
Vytvoříte prostředky konfigurace fluxu (Microsoft.KubernetesConfiguration/fluxConfigurations
), které umožní správu clusteru GitOps z úložišť Git, zdrojů bucketů nebo úložiště objektů blob v Azure. Při vytváření fluxConfigurations
prostředku se hodnoty, které zadáte pro parametry, jako je cílové úložiště Git, používají k vytvoření a konfiguraci objektů Kubernetes, které umožňují proces GitOps v tomto clusteru. Aby se zajistilo zabezpečení dat, fluxConfigurations
ukládají se neaktivní uložená data prostředků v databázi Azure Cosmos DB službou Konfigurace clusteru zašifrovaná.
fluxconfig-controller
Agenti fluxconfig-agent
a agenti nainstalovaní s rozšířením microsoft.flux
spravují proces konfigurace GitOps.
fluxconfig-agent
zodpovídá za následující úkoly:
- Dotazuje službu roviny dat konfigurace Kubernetes na nové nebo aktualizované
fluxConfigurations
prostředky. - Vytvoří nebo aktualizuje
FluxConfig
vlastní prostředky v clusteru s informacemi o konfiguraci. - Sleduje
FluxConfig
vlastní prostředky a nasdílí změny stavu zpět přidruženým prostředkům Azure fluxConfiguration.
fluxconfig-controller
zodpovídá za následující úkoly:
- Sleduje aktualizace stavu vlastních prostředků Flux vytvořených spravovaným
fluxConfigurations
nástrojem . - Vytvoří pár privátního nebo veřejného klíče, který existuje po celou dobu životnosti objektu
fluxConfigurations
. Tento klíč se používá k ověřování, pokud je adresa URL založená na protokolu SSH a pokud uživatel během vytváření konfigurace neposkytuje vlastní privátní klíč. - Vytvoří vlastní tajný klíč ověřování na základě uživatelem poskytnutého privátního klíče/http basic-auth/known-hosts/no-auth data.
- Nastaví řízení přístupu na základě role (zřízený účet služby, vytvoření vazby role, přiřazení, vytvoření nebo přiřazení role).
- Vytvoří
GitRepository
neboBucket
vlastní prostředek aKustomization
vlastní prostředky z informací veFluxConfig
vlastním prostředku.
Každý fluxConfigurations
prostředek v Azure je přidružený k jednomu prostředku Flux GitRepository
nebo Bucket
vlastnímu prostředku a k jednomu nebo více Kustomization
vlastním prostředkům v clusteru Kubernetes. Při vytváření fluxConfigurations
prostředku zadáte adresu URL zdroje (úložiště Git, Bucket nebo Azure Blob Storage) a cíl synchronizace ve zdroji pro každý z nich Kustomization
. Můžete nakonfigurovat závislosti mezi Kustomization
vlastními prostředky a řídit sekvencování nasazení. Na stejném clusteru můžete také vytvořit více prostředků vymezených fluxConfigurations
oborem názvů pro různé aplikace a aplikační týmy.
Poznámka:
Monitorování fluxconfig-agent
nových nebo aktualizovaných fluxConfiguration
prostředků v Azure Agent vyžaduje připojení k Azure, aby se na cluster použil požadovaný stav fluxConfiguration
. Pokud se agent nemůže připojit k Azure, změny v clusteru počkejte, dokud se agent nemůže připojit. Pokud je cluster odpojený od Azure déle než 48 hodin, vyprší časový limit požadavku na cluster a změny bude potřeba v Azure znovu použít.
Citlivé vstupy zákazníků, jako je privátní klíč a token nebo heslo, se ve službě Konfigurace Kubernetes ukládají méně než 48 hodin. Pokud aktualizujete některou z těchto hodnot v Azure, ujistěte se, že se vaše clustery připojují k Azure do 48 hodin.
Stav konfigurace fluxu a dodržování předpisů můžete monitorovat na webu Azure Portal nebo pomocí řídicích panelů monitorovat stav, dodržování předpisů, spotřebu prostředků a aktivitu odsouhlasení. Další informace najdete v tématu Monitorování stavu a aktivity GitOps (Flux v2).
Podpora verzí
Podporují se nejnovější verze rozšíření Flux v2 (microsoft.flux
) a dvě předchozí verze (N-2). Obecně doporučujeme použít nejnovější verzi rozšíření. microsoft.flux
Od verze 1.7.0 se podporují clustery založené na ARM64.
Poznámka:
Pokud jste používali flux v1, doporučujeme co nejdříve migrovat na Flux v2 .
Podpora prostředků konfigurace clusteru založených na flux v1 vytvořených před 1. lednem 2024 skončí 24. května 2025. Od 1. ledna 2024 nebudete moct vytvářet nové prostředky konfigurace clusteru založené na fluxu v1.
GitOps s privátním propojením
Pokud jste přidali podporu privátního propojení ke clusteru Kubernetes s podporou Služby Azure Arc, microsoft.flux
rozšíření funguje s komunikací zpět do Azure. Pro připojení k úložišti Git, úložišti Helm nebo jakýmkoli jiným koncovým bodům potřebným k nasazení manifestů Kubernetes musíte tyto koncové body zřídit za bránou firewall nebo je uvést do brány firewall, aby se k nim řadič zdroje Flux úspěšně dostal.
Umístění dat
Služba Azure GitOps (Správa konfigurace Azure Kubernetes) ukládá a zpracovává zákaznická data. Ve výchozím nastavení se zákaznická data replikují do spárované oblasti. V oblastech Singapur, Východní Asie a Brazílie – jih se všechna zákaznická data ukládají a zpracovávají v dané oblasti.
Použití konfigurací flux ve velkém měřítku
Vzhledem k tomu, že Azure Resource Manager spravuje vaše konfigurace, můžete automatizovat vytváření stejné konfigurace ve všech prostředcích Kubernetes Service a Kubernetes s podporou Azure Arc pomocí služby Azure Policy v rámci předplatného nebo skupiny prostředků. Toto vynucování ve velkém měřítku zajišťuje, aby se konkrétní konfigurace používaly konzistentně napříč všemi skupinami clusterů.
Další informace najdete v tématu Nasazení aplikací konzistentně ve velkém měřítku pomocí konfigurací Flux v2 a Azure Policy.
Parametry
Pokud chcete zobrazit všechny parametry podporované fluxem v2 v Azure, prohlédni si az k8s-configuration
dokumentace. Implementace Azure v současné době nepodporuje všechny parametry, které Flux podporuje.
Informace o dostupných parametrech a jejich použití najdete v tématu Podporované parametry GitOps (Flux v2).
Architektura s více tenanty
Flux v2 podporuje víceklientské architektury od verze 0.26. Tato funkce je integrovaná do fluxu v2 v Azure.
Poznámka:
U funkce s více tenanty musíte vědět, jestli manifesty obsahují jakýkoli zdroj mezi obory názvů Pro HelmRelease, Kustomization, ImagePolicy nebo jiné objekty nebo pokud používáte verzi Kubernetes menší než 1.20.6. Příprava:
- Upgradujte na Kubernetes verze 1.20.6 nebo vyšší.
- V manifestech Kubernetes zajistěte, aby všechny
sourceRef
objekty byly ve stejném oboru názvů jako konfigurace GitOps.- Pokud potřebujete čas aktualizovat manifesty, můžete se odhlásit z víceklientské architektury. Stále ale potřebujete upgradovat verzi Kubernetes.
Aktualizace manifestů pro víceklientské architektury
Řekněme, že nasadíte fluxConfiguration
jeden z našich clusterů Kubernetes v cluster-config
oboru názvů s oborem clusteru. Zdroj nakonfigurujete tak, aby synchronizoval https://github.com/fluxcd/flux2-kustomize-helm-example
úložiště. Jedná se o stejné ukázkové úložiště Git, které se používá v nasazení aplikací pomocí GitOps s kurzem Flux v2.
Jakmile Flux synchronizuje úložiště, nasadí prostředky popsané v manifestech (soubory YAML). Dva manifesty popisují HelmRelease
a HelmRepository
objekty.
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: nginx
namespace: nginx
spec:
releaseName: nginx-ingress-controller
chart:
spec:
chart: nginx-ingress-controller
sourceRef:
kind: HelmRepository
name: bitnami
namespace: flux-system
version: "5.6.14"
interval: 1h0m0s
install:
remediation:
retries: 3
# Default values
# https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
values:
service:
type: NodePort
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
name: bitnami
namespace: flux-system
spec:
interval: 30m
url: https://charts.bitnami.com/bitnami
Ve výchozím nastavení nasadí fluxConfigurations
rozšíření Flux zosobněním flux-applier
účtu služby nasazeného pouze v cluster-config
oboru názvů. Použití výše uvedených manifestů, pokud je povolena víceklientská architektura, HelmRelease
bude blokovaná. Důvodem je to, že HelmRelease
je v nginx
oboru názvů, ale odkazuje na HelmRepository v flux-system
oboru názvů. Flux helm-controller
také nemůže použít HelmRelease
, protože v nginx
oboru názvů neexistuje žádný flux-applier
účet služby.
Pro práci s více tenanty je správným přístupem nasadit všechny objekty Flux do stejného oboru názvů jako objekty fluxConfigurations
. Tento přístup zabraňuje problému s odkazem na křížový obor názvů a umožňuje kontrolery Flux získat oprávnění k použití objektů. Pro konfiguraci GitOps vytvořenou cluster-config
v oboru názvů by se tedy tyto ukázkové manifesty změnily takto:
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: nginx
namespace: cluster-config
spec:
releaseName: nginx-ingress-controller
targetNamespace: nginx
chart:
spec:
chart: nginx-ingress-controller
sourceRef:
kind: HelmRepository
name: bitnami
namespace: cluster-config
version: "5.6.14"
interval: 1h0m0s
install:
remediation:
retries: 3
# Default values
# https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
values:
service:
type: NodePort
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
name: bitnami
namespace: cluster-config
spec:
interval: 30m
url: https://charts.bitnami.com/bitnami
Odhlášení z víceklientské architektury
microsoft.flux
Po instalaci rozšíření je ve výchozím nastavení povolená víceklientská architektura. Pokud potřebujete zakázat víceklientské architektury, můžete se odhlásit vytvořením nebo aktualizací microsoft.flux
rozšíření ve vašich clusterech, --configuration-settings multiTenancy.enforce=false
jak je znázorněno v těchto ukázkových příkazech:
az k8s-extension create --extension-type microsoft.flux --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>
az k8s-extension update --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>
Migrace z flux v1
Pokud stále používáte Flux v1, doporučujeme co nejdříve migrovat na Flux v2.
Pokud chcete migrovat na používání fluxu v2 ve stejných clusterech, ve kterých jste používali Flux v1, musíte nejprve odstranit všechny flux verze 1 sourceControlConfigurations
z clusterů. Protože flux v2 má zásadně odlišnou architekturu, rozšíření clusteru se nenainstaluje, microsoft.flux
pokud v clusteru existují prostředky Flux v1 sourceControlConfigurations
. Proces odebrání konfigurací Flux v1 a nasazení konfigurací Flux v2 by neměl trvat déle než 30 minut.
Odebrání fluxu v1 sourceControlConfigurations
nezastaví žádné aplikace spuštěné v clusterech. Během období, kdy se odebere konfigurace Flux v1 a rozšíření Flux v2 ještě není plně nasazené:
- Pokud jsou v manifestech aplikace uložené v úložišti Git nové změny, tyto změny se během migrace nepřetáhnou a verze aplikace nasazená v clusteru bude zastaralá.
- Pokud dojde k nezamýšleným změnám ve stavu clusteru a liší se od požadovaného stavu zadaného ve zdrojovém úložišti Git, cluster se nebude moct sami léčit.
Před migrací produkčního prostředí doporučujeme otestovat váš scénář migrace ve vývojovém prostředí.
Zobrazení a odstranění konfigurací Flux v1
Pomocí těchto příkazů Azure CLI vyhledejte a pak odstraňte existující sourceControlConfigurations
v clusteru:
az k8s-configuration flux list --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
az k8s-configuration flux delete --name <configuration name> --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
Existující konfigurace GitOps pro cluster můžete také najít a odstranit na webu Azure Portal. Uděláte to tak, že přejdete do clusteru, ve kterém se konfigurace vytvořila, a v levém podokně vyberete GitOps . Vyberte konfiguraci a pak vyberte Odstranit.
Nasazení konfigurací Flux v2
Pomocí webu Azure Portal nebo Azure CLI použijte pro clustery konfigurace Flux v2.
Informace o vyřazení fluxu v1
Opensourcový projekt Flux v1 byl archivován a vývoj funkcí se zastavil na neomezenou dobu.
Flux v2 byl spuštěn jako upgradovaný opensourcový projekt Flux. Má novou architekturu a podporuje více případů použití GitOps. Microsoft spustil verzi rozšíření pomocí flux v2 v květnu 2022. Od té doby se zákazníkům doporučuje přejít na flux v2 do tří let, protože podpora používání flux v1 je naplánovaná na ukončení v květnu 2025.
Klíčové nové funkce představené v rozšíření GitOps pro Flux v2:
- Flux v1 je monolitický operátor do-it-all. Flux v2 odděluje funkce na specializované kontrolery (zdrojový kontroler, kontroler Kustomize, kontroler Helm a kontroler oznámení).
- Podporuje synchronizaci s více zdrojovými úložišti.
- Podporuje víceklientské prostředí, jako je použití jednotlivých zdrojových úložišť s vlastní sadou oprávnění.
- Poskytuje provozní přehledy prostřednictvím kontrol stavu, událostí a upozornění.
- Podporuje větve Gitu, připnutí potvrzení a značek a následující rozsahy značek SemVer.
- Konfigurace přihlašovacích údajů na prostředek GitRepository: privátní klíč SSH, uživatelské jméno HTTP/S uživatelské jméno/ heslo/token a veřejné klíče OpenPGP.
Další kroky
- V našem kurzu se dozvíte, jak povolit GitOps v clusterech Kubernetes s podporou AKS nebo Azure Arc.
- Seznamte se s pracovním postupem CI/CD pomocí GitOps.