Kas yra FluxCD ir kodėl jis keičia žaidimo taisykles
Jei dirbate su Kubernetes, tikriausiai jau girdėjote apie GitOps principus. Bet jei dar nesusipažinote su FluxCD, tai laikas tai padaryti. FluxCD yra vienas iš populiariausių GitOps operatorių, leidžiantis automatizuoti Kubernetes klasterių valdymą naudojant Git kaip vienintelį tiesos šaltinį. Skamba sudėtingai? Iš tikrųjų viskas gana paprasta – jūsų infrastruktūros būsena saugoma Git repozitorijoje, o FluxCD užtikrina, kad jūsų klasteris visada atitiktų tą būseną.
Tradicinis Kubernetes valdymo būdas dažnai atrodo taip: kažkas paleidžia kubectl apply komandą savo kompiuteryje, kažkas kitas daro tai per CI/CD pipeline, o dar kažkas tiesiog rankiniu būdu keičia konfigūracijas tiesiogiai klasteryje. Rezultatas? Chaosas, nesuderinamumas ir nuolatinė baimė, kad niekas tiksliai nežino, kas iš tikrųjų veikia produkcijoje.
FluxCD išsprendžia šią problemą elegantiškai. Vietoj to, kad stumtumėte pakeitimus į klasterį, FluxCD nuolat stebi jūsų Git repozitoriją ir automatiškai sinchronizuoja bet kokius pasikeitimus. Tai reiškia, kad jūsų Git repozitorija tampa vienintele tiesos vieta – jei ko nėra Git’e, to neturėtų būti ir klasteryje.
Kaip FluxCD veikia po gaubtu
FluxCD architektūra yra gana elegantiška ir modulinė. Vietoj vieno monolitinio komponento, Flux v2 (dabartinė versija) susideda iš kelių specializuotų kontrolerių, kiekvienas atsakingas už specifinę funkciją.
Pirmiausia yra Source Controller – jis atsakingas už šaltinių stebėjimą. Tai gali būti Git repozitorijos, Helm repozitorijos ar net S3 bucket’ai. Šis kontroleris reguliariai tikrina, ar nėra naujų commit’ų ar pakeitimų, ir praneša kitiems komponentams, kai kažkas pasikeičia.
Toliau eina Kustomize Controller ir Helm Controller. Šie vyrukai atsakingi už tai, kad jūsų Kubernetes manifestai ar Helm chart’ai būtų teisingai pritaikyti klasteryje. Jie paima tai, ką Source Controller jiems pateikia, ir užtikrina, kad klasteris atitiktų norimą būseną.
Notification Controller rūpinasi pranešimais – jis gali siųsti įspėjimus į Slack, Microsoft Teams ar bet kurią kitą sistemą, kai įvyksta svarbūs įvykiai. Tai neįtikėtinai naudinga, kai norite žinoti, kada naujas deployment’as buvo pritaikytas arba kai kažkas nepavyko.
Galiausiai yra Image Automation Controllers – jie gali automatiškai atnaujinti jūsų Git repozitoriją, kai pasirodys naujos konteinerių versijos. Tai ypač patogu, kai norite automatizuoti visą procesą nuo kodo commit’o iki deployment’o produkcijoje.
Pradedame dirbti su FluxCD praktiškai
Gerai, užteks teorijos – pažiūrėkime, kaip iš tikrųjų pradėti naudoti FluxCD. Pirmas žingsnis yra įdiegti Flux CLI įrankį savo kompiuteryje. Tai paprasta:
curl -s https://fluxcd.io/install.sh | sudo bash
Arba jei naudojate macOS su Homebrew:
brew install fluxcd/tap/flux
Kai turite CLI, galite patikrinti, ar jūsų Kubernetes klasteris yra pasiruošęs Flux:
flux check --pre
Ši komanda patikrins, ar jūsų klasteris atitinka minimalius reikalavimus. Jei viskas gerai, galite bootstrap’inti Flux į savo klasterį. Čia prasideda tikroji magija:
flux bootstrap github \
--owner=jusu-github-vartotojas \
--repository=jusu-repo \
--branch=main \
--path=./clusters/production \
--personal
Ši komanda padarys kelis dalykus vienu metu: sukurs GitHub repozitoriją (jei jos dar nėra), įdiegs Flux komponentus į jūsų klasterį, sukonfigūruos Flux, kad stebėtų tą repozitoriją, ir commit’ins pradinę konfigūraciją atgal į Git. Tai puikus GitOps principo pavyzdys – net pats Flux yra valdomas per Git!
Struktūrizuojame repozitoriją protingai
Vienas iš dažniausių klausimų, su kuriais susiduriu padedant komandoms pradėti naudoti FluxCD, yra: kaip organizuoti Git repozitoriją? Nėra vieno teisingo atsakymo, bet yra keletas patikrintų praktikų.
Populiarus būdas yra organizuoti repozitoriją pagal aplinkos ir komandas. Pavyzdžiui:
├── clusters/
│ ├── production/
│ │ └── flux-system/
│ └── staging/
│ └── flux-system/
├── infrastructure/
│ ├── base/
│ └── overlays/
├── apps/
│ ├── base/
│ └── overlays/
└── tenants/
├── team-a/
└── team-b/
Tokia struktūra leidžia aiškiai atskirti skirtingus klasterius, infrastruktūros komponentus (kaip ingress kontrolerius, monitoring’as) ir pačias aplikacijas. base direktorijos paprastai turi bendrus manifest’us, o overlays – specifines konfigūracijas skirtingoms aplinkoms.
Svarbu suprasti, kad FluxCD naudoja Kustomization objektus (ne painioti su Kustomize įrankiu, nors jie ir susiję). Šie objektai nurodo Flux, ką ir kaip taikyti. Pavyzdys:
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: apps
namespace: flux-system
spec:
interval: 10m
sourceRef:
kind: GitRepository
name: flux-system
path: ./apps/production
prune: true
wait: true
Darbas su Helm chart’ais per FluxCD
Daugelis aplikacijų Kubernetes ekosistemoje platinamos kaip Helm chart’ai, ir FluxCD puikiai su jais dirba. Iš tikrųjų, Flux dažnai yra patogesnė alternatyva tradiciniam Helm naudojimui.
Norėdami naudoti Helm chart’ą su Flux, pirmiausia turite apibrėžti HelmRepository šaltinį:
apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: bitnami namespace: flux-system spec: interval: 1h url: https://charts.bitnami.com/bitnami
Tada galite sukurti HelmRelease objektą, kuris nurodo, kaip tą chart’ą įdiegti:
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: postgresql
namespace: database
spec:
interval: 10m
chart:
spec:
chart: postgresql
version: "12.x.x"
sourceRef:
kind: HelmRepository
name: bitnami
namespace: flux-system
values:
auth:
username: myuser
database: mydb
Kas čia įdomu? Viskas yra deklaratyvus manifest’as, saugomas Git’e. Jei norite pakeisti PostgreSQL konfigūraciją, tiesiog keičiate values sekciją, commit’inate, ir Flux automatiškai pritaiko pakeitimus. Jokių rankinių helm upgrade komandų!
Dar vienas privalumas – galite naudoti Flux funkcijas kaip dependsOn, kad užtikrintumėte teisingą deployment’ų seką. Pavyzdžiui, jūsų aplikacija gali priklausyti nuo duomenų bazės, ir Flux užtikrins, kad duomenų bazė būtų įdiegta pirmiau.
Automatinis konteinerių atnaujinimas
Viena iš galingiausių FluxCD funkcijų yra automatinis konteinerių image’ų atnaujinimas. Tai leidžia sukurti visiškai automatizuotą pipeline’ą nuo kodo commit’o iki deployment’o produkcijoje, be jokio rankinio įsikišimo.
Kaip tai veikia? Pirmiausia, turite sukonfigūruoti ImageRepository, kad Flux stebėtų jūsų konteinerių registry:
apiVersion: image.toolkit.fluxcd.io/v1beta2 kind: ImageRepository metadata: name: myapp namespace: flux-system spec: image: ghcr.io/myorg/myapp interval: 1m
Tada apibrėžiate ImagePolicy, kuri nurodo, kokias versijas laikyti „geriausiomis”:
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
name: myapp
namespace: flux-system
spec:
imageRepositoryRef:
name: myapp
policy:
semver:
range: 1.x.x
Galiausiai, jūsų deployment manifest’e naudojate specialų marker’į:
spec:
containers:
- name: myapp
image: ghcr.io/myorg/myapp:1.0.0 # {"$imagepolicy": "flux-system:myapp"}
Kai Flux aptinka naują image’ą, atitinkantį jūsų policy, jis automatiškai atnaujins šią eilutę Git repozitorijoje ir sukurs commit’ą. Tada Source Controller pamatys pakeitimą ir pritaikys jį klasteryje. Viskas automatiškai!
Žinoma, reikia būti atsargiam su tokia automatizacija. Rekomenduoju naudoti ją staging aplinkoje be apribojimų, bet production’e galbūt norėsite turėti papildomų apsaugų, kaip manual approval ar progresyvius rollout’us.
Troubleshooting ir dažniausios problemos
Kaip ir su bet kuria technologija, su FluxCD kartais susiduriate su problemomis. Gera žinia – Flux turi puikius debugging įrankius.
Pirmasis jūsų draugas yra flux get komandos. Jos leidžia greitai pamatyti visų Flux objektų būseną:
flux get all
Jei kažkas negerai, paprastai pamatysite klaidos pranešimą čia. Norėdami gauti daugiau detalių, galite naudoti:
flux logs --all-namespaces --follow
Dažna problema, su kuria susiduriu, yra neteisingi Git credentials. Jei Flux negali pasiekti jūsų repozitorijos, jis negalės nieko sinchronizuoti. Patikrinkite, ar jūsų deploy key ar personal access token turi teisingas teises.
Kita dažna problema – Kustomization objektai, kurie nurodo į neegzistuojančius path’us. Flux bus laimingas pranešti, kad negali rasti ./apps/production, jei tokio kelio nėra jūsų repozitorijoje. Atrodo akivaizdu, bet pasitiki manimi, tai nutinka dažniau nei norėtumėte.
Jei deployment’as nepavyksta dėl Kubernetes klaidų (pavyzdžiui, nepakanka resursų ar yra validation klaidos), Flux tai parodys Kustomization ar HelmRelease objekto status’e. Galite tai pamatyti su:
kubectl describe kustomization apps -n flux-system
Saugumas ir best practices su FluxCD
GitOps yra puikus būdas valdyti infrastruktūrą, bet tai nereiškia, kad galite ignoruoti saugumą. Priešingai – kadangi visa jūsų infrastruktūra yra aprašyta kode, saugumas tampa dar svarbesnis.
Pirmiausia, niekada nesaugokite slaptažodžių ar API raktų tiesiogiai Git repozitorijoje. Net jei repozitorija yra private, tai vis tiek bloga praktika. Vietoj to, naudokite sprendimus kaip Sealed Secrets ar SOPS (Mozilla’s Secrets OPerationS).
Sealed Secrets veikia taip: jūs užšifruojate savo secret’us public key, kurį generuoja kontroleris jūsų klasteryje. Užšifruotus secret’us galite saugiai commit’inti į Git. Kai Flux juos pritaiko klasteryje, Sealed Secrets kontroleris juos iššifruoja naudodamas private key, kurį tik jis žino.
SOPS yra kitas populiarus pasirinkimas, ypač jei jau naudojate AWS KMS, Google Cloud KMS ar Azure Key Vault. Flux turi native SOPS palaikymą:
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: apps
namespace: flux-system
spec:
decryption:
provider: sops
secretRef:
name: sops-gpg
Kitas svarbus saugumo aspektas – RBAC (Role-Based Access Control). Flux komponentai veikia su tam tikromis teisėmis jūsų klasteryje. Pagal nutylėjimą, jie turi gana plačias teises, bet galite jas apriboti priklausomai nuo jūsų poreikių.
Taip pat rekomenduoju naudoti Git branch protection rules. Kadangi jūsų Git repozitorija yra tiesos šaltinis, norite užtikrinti, kad pakeitimai būtų peržiūrėti prieš patenkant į main branch. Pull request’ai su code review yra puikus būdas tai padaryti.
Multi-tenancy ir komandų izoliacija
Jei dirbate didelėje organizacijoje su keliomis komandomis, tikriausiai norite tam tikro lygio izoliacijos. FluxCD palaiko multi-tenancy scenarijus, nors tai reikalauja šiek tiek daugiau planavimo.
Pagrindinis principas – kiekviena komanda turi savo namespace’us ir savo Flux Kustomization objektus, kurie turi teises tik į tuos namespace’us. Galite tai pasiekti naudodami Flux serviceAccountName funkciją:
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: team-a-apps
namespace: flux-system
spec:
serviceAccountName: team-a-reconciler
path: ./tenants/team-a
sourceRef:
kind: GitRepository
name: flux-system
Tada sukuriate ServiceAccount su RBAC teisėmis, apribotomis tik team-a namespace’ams. Taip komanda A negali atsitiktinai (ar tyčia) pakeisti komandos B resursų.
Dar vienas įdomus pattern’as – leisti kiekvienai komandai turėti savo Git repozitoriją. Flux gali stebėti kelias repozitorijas vienu metu, todėl galite turėti centrinę infrastruktūros repozitoriją ir atskiras repozitorijas kiekvienai komandai. Tai suteikia komandomis daugiau autonomijos ir sumažina konfliktų tikimybę.
Monitoringas, alertai ir kas toliau
Įdiegę FluxCD, norite žinoti, kas vyksta. Flux exportuoja Prometheus metricas, kurias galite naudoti monitoring’ui ir alertams. Pagrindinės metrikos, į kurias verta atkreipti dėmesį:
– gotk_reconcile_condition – rodo, ar reconciliation pavyko ar ne
– gotk_reconcile_duration_seconds – kiek laiko užtruko reconciliation
– gotk_suspend_status – ar objektas yra suspended
Galite sukurti Prometheus alert rules, kurie praneš jums, jei reconciliation pradeda failinti arba užtrunka neįprastai ilgai. Pavyzdžiui:
- alert: FluxReconciliationFailure
expr: gotk_reconcile_condition{type="Ready",status="False"} == 1
for: 10m
annotations:
summary: "Flux reconciliation failing for {{ $labels.name }}"
Be Prometheus, Flux gali siųsti pranešimus tiesiogiai į įvairias sistemas per Notification Controller. Galite konfigūruoti alert’us į Slack, Microsoft Teams, Discord ar bet kurią kitą sistemą, palaikančią webhooks.
Kas toliau su FluxCD? Projektas aktyviai vystomas, ir roadmap’e yra įdomių dalykų. Viena iš sričių, kuri sparčiai tobulėja, yra OCI (Open Container Initiative) palaikymas. Tai leis saugoti Kubernetes manifest’us ir Helm chart’us tiesiogiai container registry kaip OCI artifacts, o ne tik Git repozitorijose.
Taip pat matau vis daugiau integracijų su kitais CNCF projektais. Pavyzdžiui, Flux puikiai veikia su Flagger progresyviems deployment’ams, Kyverno ar OPA policy enforcement’ui, ir Crossplane infrastruktūros valdymui.
GitOps su FluxCD nėra tik dar viena technologija – tai būdas mąstyti apie infrastruktūros valdymą. Kai viską aprašote kodu ir saugote Git’e, gaunate version control, audit trail, ir galimybę lengvai grįžti atgal, jei kažkas nepavyksta. Flux automatizuoja nuobodžią sinchronizacijos dalį, leisdamas jums sutelkti dėmesį į tai, kas iš tikrųjų svarbu – kurti ir pristatyti vertę jūsų vartotojams.
Pradėti gali atrodyti bauginančiai, ypač jei esate įpratę prie tradicinių deployment metodų. Bet patikėkite manimi – kai pereisite prie GitOps su FluxCD, grįžti atgal nenorėsite. Jūsų deployment’ai taps patikimesni, jūsų komanda turės geresnį matomumą, ir jūs galėsite miegoti ramiau, žinodami, kad jūsų infrastruktūra yra valdoma kontroliuotai ir pakartotinai.
