🥇Programų diegimas keliose Kubernetes klasteriuose su Helm

Kaip „Dailymotion“ naudoja „Kubernetes“: programų diegimas

Mes, Dailymotion, pradėjome naudoti Kubernetes gamyboje prieš 3 metus. Tačiau diegti programas keliose grupėse yra smagu, todėl per pastaruosius kelerius metus stengėmės tobulinti savo įrankius ir darbo eigą.

Kur tai prasidėjo

Čia apžvelgsime, kaip diegiame savo programas keliose Kubernetes grupėse visame pasaulyje.

Norėdami vienu metu įdiegti kelis „Kubernetes“ objektus, naudojame Šalmas, ir visos mūsų diagramos saugomos vienoje git saugykloje. Norėdami įdiegti visą programų paketą iš kelių paslaugų, naudojame vadinamąją suvestinę diagramą. Iš esmės tai yra diagrama, kuri deklaruoja priklausomybes ir leidžia inicijuoti API ir jos paslaugas viena komanda.

Taip pat ant Helm parašėme nedidelį Python scenarijų, kad galėtume atlikti patikrinimus, kurti diagramas, pridėti paslapčių ir diegti programas. Visos šios užduotys atliekamos centrinėje CI platformoje naudojant docker vaizdą.

Eikime prie esmės.

Pastaba. Kai skaitote tai, pirmasis kandidatas į Helm 3 jau buvo paskelbtas. Pagrindinėje versijoje yra daugybė patobulinimų, skirtų išspręsti kai kurias problemas, su kuriomis susidūrėme praeityje.

Diagramos kūrimo darbo eiga

Programoms naudojame šakojimą ir nusprendėme tą patį metodą taikyti diagramoms.

Filialas dev naudojamas kuriant diagramas, kurios bus išbandytos kūrimo grupėse.
Kai ištraukimo prašymas pateikiamas meistras, jie tikrinami inscenizacijoje.
Galiausiai sukuriame ištraukimo užklausą, kad atliktume filialo pakeitimus prod ir pritaikyti juos gamyboje.

Kiekviena aplinka turi savo privačią saugyklą, kurioje saugomos mūsų diagramos, o mes naudojame Chartmuseum su labai naudingomis API. Taip užtikriname griežtą aplinkų izoliaciją ir diagramų testavimą realiame pasaulyje prieš naudojant jas gamyboje.

Diagramų saugyklos įvairiose aplinkose

Verta paminėti, kad kai kūrėjai stumia kūrėjo šaką, jų diagramos versija automatiškai nusiunčiama į dev Chartmuseum. Taigi visi kūrėjai naudoja tą pačią kūrėjų saugyklą, todėl turite atidžiai nurodyti savo diagramos versiją, kad netyčia nepasinaudotumėte kažkieno atliktais pakeitimais.

Be to, mūsų mažasis Python scenarijus patvirtina Kubernetes objektus pagal Kubernetes OpenAPI specifikacijas naudodamas Kubeval, prieš paskelbdami juos Chartmusem.

Bendras diagramos kūrimo darbo eigos aprašymas

Dujotiekio užduočių nustatymas pagal specifikaciją gazr.io kokybės kontrolei (pūkų, vieneto bandymas).
„Docker“ vaizdo perkėlimas naudojant „Python“ įrankius, kurie diegia mūsų programas.
Aplinkos nustatymas pagal filialo pavadinimą.
Kubernetes yaml failų patvirtinimas naudojant Kubeval.
Automatiškai padidinkite diagramos ir jos pirminių diagramų (diagramų, kurios priklauso nuo keičiamos diagramos) versiją.
Diagramos pateikimas Chartmuseum, atitinkančiam jo aplinką

Skirtumų tarp grupių valdymas

Klasterių federacija

Buvo laikas, kai naudojome Kubernetes klasterių federacija, kur Kubernetes objektus galima deklaruoti iš vieno API galutinio taško. Tačiau iškilo problemų. Pavyzdžiui, kai kurių „Kubernetes“ objektų nepavyko sukurti susiejimo galutiniame taške, todėl sunku prižiūrėti susietus objektus ir kitus atskirų grupių objektus.

Norėdami išspręsti problemą, pradėjome savarankiškai valdyti grupes, o tai labai supaprastino procesą (naudojome pirmąją federacijos versiją; antroje galbūt kažkas pasikeitė).

Geografiškai paskirstyta platforma

Šiuo metu mūsų platforma yra paskirstyta 6 regionuose – 3 vietoje ir 3 debesyje.

Paskirstytas diegimas

Global Helm vertybės

4 pasaulinės Helm reikšmės leidžia nustatyti klasterių skirtumus. Visos mūsų diagramos turi numatytąsias minimalias reikšmes.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

Pasaulinės vertybės

Šios reikšmės padeda apibrėžti mūsų programų kontekstą ir yra naudojamos įvairiems tikslams: stebėjimui, sekimui, registravimui, išoriniams skambučiams, mastelio keitimui ir kt.

„debesis“: turime hibridinę Kubernetes platformą. Pavyzdžiui, mūsų API yra įdiegta GCP zonose ir duomenų centruose.
„env“: kai kurios reikšmės gali keistis negamybinėje aplinkoje. Pavyzdžiui, išteklių apibrėžimai ir automatinio mastelio keitimo konfigūracijos.
„regionas“: ši informacija padeda nustatyti klasterio vietą ir gali būti naudojama norint nustatyti netoliese esančius išorinių paslaugų galinius taškus.
"clusterName": jei ir kada norime apibrėžti atskiro klasterio reikšmę.

Štai konkretus pavyzdys:

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

Vairo šablono pavyzdys

Ši logika apibrėžta pagalbiniame šablone, kad būtų išvengta Kubernetes YAML netvarkos.

Paraiškos skelbimas

Mūsų diegimo įrankiai yra pagrįsti keliais YAML failais. Toliau pateikiamas pavyzdys, kaip mes deklaruojame paslaugą ir jos mastelio keitimo topologiją (kopijų skaičių) klasteryje.

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

Paslaugos apibrėžimas

Tai yra visų veiksmų, apibrėžiančių mūsų diegimo darbo eigą, apžvalga. Paskutinis veiksmas diegia programą keliose darbuotojų grupėse vienu metu.

Jenkins diegimo žingsniai

O paslaptys?

Kalbant apie saugumą, mes sekame visas paslaptis iš skirtingų vietų ir saugome jas unikaliame saugykloje Vault Paryžiuje.

Mūsų diegimo įrankiai ištraukia slaptas vertes iš Vault ir, kai ateina diegimo laikas, įterpia jas į Helm.

Norėdami tai padaryti, apibrėžėme Vault paslapčių ir paslapčių, kurių reikia mūsų programoms, susiejimą:

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

Apibrėžėme bendrąsias taisykles, kurių reikia laikytis įrašydami paslaptis „Vault“.
Jei paslaptis galioja į konkretų kontekstą ar grupę, turite pridėti konkretų įrašą. (Čia konteksto klasteris1 turi savo slaptojo kamino-app1 slaptažodžio reikšmę).
Kitu atveju naudojama vertė pagal nutylėjimą.
Kiekvienam šio sąrašo elementui Kubernetes paslaptis įterpiama rakto-reikšmių pora. Todėl slaptas šablonas mūsų diagramose yra labai paprastas.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

Problemos ir apribojimai

Darbas su keliomis saugyklomis

Dabar atskiriame diagramų ir programų kūrimą. Tai reiškia, kad kūrėjai turi dirbti dviejose „git“ saugyklose: viena skirta programai, o kita – apibrėžti jos diegimą „Kubernetes“. 2 git saugyklos reiškia 2 darbo eigas, o naujokas gali lengvai susipainioti.

Apibendrintų diagramų tvarkymas yra vargo

Kaip jau minėjome, bendrosios diagramos yra labai naudingos nustatant priklausomybes ir greitai diegiant kelias programas. Bet mes naudojame --reuse-valueskad nebūtų perduodamos visos reikšmės kiekvieną kartą, kai diegiame programą, kuri yra šios apibendrintos diagramos dalis.

Nepertraukiamo pristatymo darbo eigoje turime tik dvi vertes, kurios reguliariai keičiasi: kopijų skaičius ir vaizdo žyma (versija). Kitos, stabilesnės vertės keičiamos rankiniu būdu, ir tai yra gana sunku. Be to, viena klaida diegiant apibendrintą diagramą gali sukelti rimtų nesėkmių, kaip matėme iš savo patirties.

Kelių konfigūracijos failų atnaujinimas

Kai kūrėjas prideda naują programą, jis turi pakeisti kelis failus: programos deklaraciją, paslapčių sąrašą, įtraukti programą kaip priklausomybę, jei ji įtraukta į apibendrintą diagramą.

„Jenkins“ leidimai „Vault“ per daug išplėsti

Dabar turime vieną „AppRole“., kuris nuskaito visas paslaptis iš saugyklos.

Atkūrimo procesas nėra automatizuotas

Norėdami atšaukti, turite paleisti komandą keliose grupėse, ir tai yra pilna klaidų. Šią operaciją atliekame rankiniu būdu, kad įsitikintume, jog nurodytas teisingas versijos ID.

Judame link GitOps

Mūsų tikslas

Norime grąžinti diagramą į jos įdiegtos programos saugyklą.

Darbo eiga bus tokia pati kaip ir plėtrai. Pvz., kai atšaka perkeliama į pagrindinį valdymą, diegimas bus paleistas automatiškai. Pagrindinis skirtumas tarp šio požiūrio ir dabartinės darbo eigos būtų tas viskas bus tvarkoma git (pati programa ir jos diegimo būdas Kubernetes).

Yra keletas privalumų:

Daug aiškiau kūrėjui. Lengviau išmokti taikyti pakeitimus vietinėje diagramoje.
Galima nurodyti paslaugos diegimo apibrėžimą toje pačioje vietoje kaip kodas paslauga.
Apibendrintų diagramų pašalinimo valdymas. Paslauga turės savo „Helm“ leidimą. Tai leis jums valdyti programos gyvavimo ciklą (atšaukti, atnaujinti) mažiausiu lygiu, kad nebūtų paveiktos kitos paslaugos.
Git privalumai diagramos valdymui: anuliuoti pakeitimus, audito žurnalą ir kt. Jei reikia anuliuoti diagramos pakeitimą, tai galite padaryti naudodami git. Diegimas prasideda automatiškai.
Galite patobulinti savo kūrimo darbo eigą naudodami tokius įrankius kaip Skarfas, su kuria kūrėjai gali išbandyti pakeitimus kontekste, artimame gamybai.

Dviejų etapų migracija

Mūsų kūrėjai šią darbo eigą naudoja jau 2 metus, todėl norime, kad perkėlimas būtų kuo neskausmingesnis. Todėl nusprendėme pridėti tarpinį žingsnį kelyje į tikslą.
Pirmasis etapas yra paprastas:

Mes laikome panašią programos diegimo nustatymo struktūrą, bet viename objekte, vadinamame DailymotionRelease.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

1 leidimas vienai programai (be apibendrintų diagramų).
Diagramos programos git saugykloje.

Kalbėjomės su visais kūrėjais, todėl migracijos procesas jau prasidėjo. Pirmasis etapas vis dar valdomas naudojant CI platformą. Netrukus parašysiu kitą įrašą apie antrąjį etapą: kaip perėjome prie „GitOps“ darbo eigos Fliusas. Aš jums pasakysiu, kaip mes viską nustatėme ir su kokiais sunkumais susidūrėme (kelios saugyklos, paslaptys ir pan.). Sekite naujienas.

Čia mes bandėme apibūdinti savo pažangą diegiant programų diegimą per pastaruosius metus, todėl kilo minčių apie GitOps metodą. Tikslo dar nepasiekėme ir pranešime apie rezultatus, tačiau dabar įsitikinome, kad pasielgėme teisingai, kai nusprendėme viską supaprastinti ir priartinti prie kūrėjų įpročių.

Šaltinis: www.habr.com

Įdiekite programas keliuose „Kubernetes“ klasteriuose naudodami „Helm“.