ProHoster > Blog > Administrimi > Shpërndarja e aplikacioneve në disa klasterë Kubernetes me Helm

Shpërndarja e aplikacioneve në disa klasterë Kubernetes me Helm

Si si Dailymotion përdor Kubernetes: implementimi i aplikacioneve

Ne në Dailymotion filluam të përdorim Kubernetes në prodhim 3 vjet më parë. Por të implementosh aplikacione në disa klasterë është një kënaqësi e veçantë, prandaj gjatë këtyre viteve kemi shkuar për të përmirësuar mjetet dhe proceset tona të punës.

Si filloi gjithçka

Këtu do të tregojmë se si e implementojmë aplikacionet tona në disa klasterë Kubernetes në të gjithë botën.

Për të implementuar disa objekte Kubernetes njëherësh, ne përdorim Helm, dhe të gjithë kartat tona ruhen në një depo git. Për të implementuar një stack të plotë të aplikacionit nga disa shërbime, ne përdorim atë që quhet kartë e përmbledhur. Në thelb, kjo është një kartë që shpall varësitë dhe lejon inicializimin e API-së dhe shërbimeve të saj me një komandë.

Gjithashtu, kemi shkruar një skenar të vogël në Python mbi Helm, për të bërë verifikime, krijuar karta, shtuar sekrete dhe implementuar aplikacione. Të gjitha këto detyra kryhen në një platformë CI qendrore duke përdorur një imazh docker.

Të kalojmë në thelb.

Shënim. Kur po e lexoni këtë, kandidati i parë për lëshim i Helm 3 është shpallur tashmë. Versioni kryesor përmban një grup të tërë përmirësimesh, të destinuara për të zgjidhur disa probleme me të cilat u përballëm në të kaluarën.

Procesi i punës për zhvillimin e kartave

Për aplikacionet, ne përdorim degëzim, dhe ky qasje e kemi aplikuar edhe te kartat.

  • Dega dev pĂ«rdoret pĂ«r krijimin e kartave qĂ« do tĂ« testohet nĂ« klasterĂ«t e zhvillimit.
  • Kur kĂ«rkesa e palĂ«s sĂ« tretĂ« dĂ«rgohet nĂ« master, ato kontrollohen nĂ« skenĂ«.
  • MĂ« nĂ« fund, ne krijojmĂ« njĂ« kĂ«rkesĂ« tĂ« palĂ«s sĂ« tretĂ« pĂ«r tĂ« transferuar ndryshimet nĂ« degĂ« prod dhe pĂ«r t'i aplikuar ato nĂ« prodhim.

Çdo mjedis ka depo private qĂ« ruan kartat tona dhe ne pĂ«rdorim Chartmuseum me API shumĂ« tĂ« dobishme. KĂ«shtu, ne kemi garantuar izolim tĂ« fortĂ« midis ambienteve dhe verifikim tĂ« kartave nĂ« kushte reale para se t'i pĂ«rdorim nĂ« prodhim.

Depo kartash në ambiente të ndryshme

Vlen të theksohet se kur zhvilluesit dërgojnë degën dev, versioni i kartës së tyre dërgohet automatikisht në Chartmuseum dev. Kështu, të gjithë zhvilluesit përdorin një depo dev, dhe është e nevojshme të specifikohet me kujdes versioni i kartës për të mos përdorur rastësisht ndryshimet e dikujt tjetër.

Për më tepër, skenari ynë i vogël Python kontrollon objektet Kubernetes sipas specifikimeve të Kubernetes OpenAPI duke përdorur Kubeval, para se t'i publikojë në Chartmuseum.

Përmbledhje e procesit të punës për zhvillimin e kartave

  1. Konfigurimi i detyrave të pipeline sipas specifikimit gazr.io për kontrollin e cilësisë (lint, test të njësi).
  2. Dërgimi i imazhit docker me mjetet Python, të cilat implementojnë aplikacionet tona.
  3. Konfigurimi i mjedisit sipas emrit të degës.
  4. Kontrolli i skedarëve yaml Kubernetes duke përdorur Kubeval.
  5. Rritja automatike e versionit të kartës dhe kartave të saj prind (kartat që varen nga karta e ndryshuar).
  6. Dërgimi i kartës në Chartmuseum, i cili është në përputhje me ambientin e saj.

Menaxhimi i diferencave në klasterë

Federata e klasterëve

Ishte një herë një kohë kur ne përdornim federatën e klasterëve Kubernetes, ku mund të shpallnim objekte Kubernetes nga një pikë fundore API. Por patëm probleme. Për shembull, disa objekte Kubernetes nuk mund të krijoheshin në pikën fundore të federatës, prandaj ishte e vështirë të menaxhoheshin objektet e bashkuara dhe objekte të tjera për klasterë të veçantë.

Për të zgjidhur problemin, filluam të menaxhonim klasterët në mënyrë të pavarur, gjë që e thjeshtoi shumë procesin (përdorëm versionin e parë të federatës; në të dytin diçka mund të ketë ndryshuar).

Platforma gjeo-distribuar

Tani platforma jonĂ« Ă«shtĂ« e shpĂ«rndarĂ« nĂ« 6 regione — 3 lokalisht dhe 3 nĂ« cloud.


Implementimi i shpërndarë

Vlerat globale të Helm

4 vlera globale të Helm lejojnë përcaktimin e diferencave midis klasterëve. Për të gjitha kartat tona, ka vlera minimale sipas parazgjedhjes.

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

Vlerat globale

Këto vlera ndihmojnë në përcaktimin e kontekstit për aplikacionet tona dhe përdoren për detyra të ndryshme: monitorimi, ndjekja, regjistrimi, kryerja e thirrjeve të jashtme, shkallëzimi, etj.

  • «cloud»: ne kemi njĂ« platformĂ« hibrid Kubernetes. PĂ«r shembull, API-ja jonĂ« implementohet nĂ« zonat GCP dhe nĂ« qendrat tona tĂ« tĂ« dhĂ«nave.
  • «env»: disa vlera mund tĂ« ndryshojnĂ« pĂ«r ambientet joaktive. PĂ«r shembull, pĂ«rcaktimet e burimeve dhe konfigurimi i automatikĂ« shkallĂ«zimin.
  • «region»: kjo informacion ndihmon nĂ« pĂ«rcaktimin e vendndodhjes sĂ« klasterit dhe mund tĂ« pĂ«rdoret pĂ«r tĂ« pĂ«rcaktuar pikĂ« fundore mĂ« tĂ« afĂ«rt pĂ«r shĂ«rbime tĂ« jashtme.
  • «clusterName»: nĂ«se dhe kur duam tĂ« pĂ«rcaktojmĂ« njĂ« vlerĂ« pĂ«r njĂ« klaster tĂ« veçantĂ«.

Ja një shembull konkret:

{{/* Kthe numrin e replikave të Horizontal Pod Autoscaler për 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 -}}

Shembulli i shabllonit Helm

Kjo logjikë është përcaktuar në një shabllon ndihmës, për të mos ngarkuar YAML-në e Kubernetes.

Deklarata e aplikacionit

Veglat tona të vendosjes bazohen në disa skedarë YAML. Më poshtë është një shembull se si ne deklarojmë shërbimin dhe topologjinë e tij të shkallëzimit (numri i replikave) në klaster.

releases:
  - foo.world

foo.world:                # Emri i lëshimit
  services:               # Lista e aplikacioneve/projekteve të dailymotion
    foobar:
      chart_name: foo-foobar
      repo: git@github.com:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

Përcaktimi i shërbimit

Kjo është skema e të gjithë hapave që përcaktojnë procesin tonë të vendosjes. Hapi i fundit vendos aplikacionin në mënyrë të njëkohshme në disa klasterë të punës.


Hapat e vendosjes në Jenkins

Dhe sekretet?

Sa i përket sigurisë, ne ndjekim të gjithë sekretet nga vende të ndryshme dhe i ruajmë ato në një depo unike Vault në Paris.

Veglat tona të vendosjes nxjerrin vlerat e sekretëve nga Vault dhe, kur vjen koha e vendosjes, i inkuadrojnë ato në Helm.

Për këtë, ne kemi përcaktuar një lidhje mes sekretëve në Vault dhe sekretëve që i nevojiten aplikacioneve tona:

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"

  • Ne kemi pĂ«rcaktuar rregulla tĂ« pĂ«rgjithshme qĂ« duhet tĂ« ndiqen kur shkruhen sekretet nĂ« Vault.
  • NĂ«se njĂ« sekret i pĂ«rket njĂ« konteksti ose klasteri tĂ« caktuar, duhet tĂ« shtohet njĂ« regjistĂ«r specifik. (KĂ«tu konteksti cluster1 ka njĂ« vlerĂ« tĂ« vetme pĂ«r sekretin stack-app1-password).
  • NĂ« tĂ« kundĂ«rt, pĂ«rdoret vlera nĂ« mĂ«nyrĂ« default.
  • PĂ«r çdo pikĂ« nĂ« kĂ«tĂ« listĂ« nĂ« sekretin e Kubernetes shtohet njĂ« çift çelĂ«s-vlerĂ«. Prandaj, shablloni i sekretit nĂ« chart-Ă«t tanĂ« Ă«shtĂ« shumĂ« i thjeshtĂ«.

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

Problemet dhe kufizimet

Puna me depo të shumta

Aktualisht ne ndajmë zhvillimin e chart-eve dhe aplikacioneve. Kjo do të thotë që zhvilluesit duhet të punojnë në dy depo git: një për aplikacionin dhe tjetra për përcaktimin e vendosjes së tij në Kubernetes. 2 depo git janë 2 procese punë, dhe një fillestar lehtë mund të ngatërrohet.

Të menaxhosh chart-et e përgjithshëm është e lodhshme

Siç e thashë, chart-et e përgjithshëm janë shumë të dobishme për përcaktimin e varësive dhe për vendosjen e shpejtë të disa aplikacioneve. Por ne përdorim --reuse-values, për të shmangur transferimin e të gjitha vlerave çdo herë kur vendosim një aplikacion që bën pjesë në këtë chart të përgjithshëm.

Në procesin e vazhdueshëm të furnizimit kemi vetëm dy vlera që ndryshojnë rregullisht: numri i replikave dhe etiketa e imazhit (versioni). Vlera të tjera, më të qëndrueshme, ndryshojnë manualisht, dhe kjo është mjaft e vështirë. Për më tepër, një gabim në vendosjen e chart-it të përgjithshëm mund të çojë në dështime të rënda, siç e kemi përjetuar në përvojën tonë.

Përditësimi i disa skedarëve të konfigurimit

Kur një zhvillues shton një aplikacion të ri, duhet të ndryshojë disa skedarë: deklarata e aplikacionit, lista e sekretëve, shtimi i aplikacionit në varësi, nëse bën pjesë në chart-in e përgjithshëm.

Lejet e Jenkins janë shumë të gjera në Vault

Aktualisht kemi një AppRole, që lexon të gjitha sekretet nga Vault.

Procesi i rikthimit nuk është automatizuar

Për rikthim ne duhet të ekzekutojmë një komandë në disa klasterë, që sjell mundësi për gabime. Ne e kryejmë këtë operacion manualisht, për të siguruar që të tregojmë identifikuesin e duhur të versionit.

Ne jemi në drejtim të GitOps

Qëllimi ynë

Duam ta kthejmë chart-in në depozitën e aplikacionit që po e shpërndajmë.

Procesi do të jetë i njëjtë si për zhvillimin. Për shembull, kur dega dërgohet në master, shpërndarja do të nisë automatikisht. Diferenca kryesore midis këtij qasjeje dhe procesit aktual do të jetë që gjithçka do të menaxhohet në git (si aplikacioni ashtu edhe mënyra e shpërndarjes së tij në Kubernetes).

Ka disa përfitime:

  • ShumĂ« mĂ« e qartĂ« pĂ«r zhvilluesin. MĂ« e lehtĂ« pĂ«r t'u mĂ«suar tĂ« aplikosh ndryshime nĂ« chart-in lokal.
  • Definimi i shpĂ«rndarjes sĂ« shĂ«rbimeve mund tĂ« pĂ«rcaktohet aty ku Ă«shtĂ« kodi i shĂ«rbimit.
  • Menaxhimi i heqjes sĂ« chart-Ă«ve tĂ« pĂ«rgjithshme. ShĂ«rbimi do tĂ« ketĂ« lĂ«shimin e tij Helm. Kjo do tĂ« lejojĂ« menaxhimin e ciklit tĂ« jetĂ«s sĂ« aplikacionit (rikthim, pĂ«rmirĂ«sim) nĂ« njĂ« nivel tĂ« imĂ«t, pĂ«r tĂ« mos prekur shĂ«rbimet e tjera.
  • PĂ«rfitimet e git pĂ«r menaxhimin e chart-eve: anulimi i ndryshimeve, regjistri i auditimeve dhe tĂ« tjera. NĂ«se Ă«shtĂ« e nevojshme tĂ« anullohet njĂ« ndryshim nĂ« chart, kjo mund tĂ« bĂ«het pĂ«rmes git. ShpĂ«rndarja nis automatikisht.
  • Mund tĂ« mendohet pĂ«r pĂ«rmirĂ«simin e procesit tĂ« zhvillimit me ndihmĂ«n e mjeteve tĂ« tilla si Skaffold, me tĂ« cilat zhvilluesit mund tĂ« testojnĂ« ndryshimet nĂ« njĂ« kontekst tĂ« ngjashĂ«m me prodhimin.

Migrimi në dy etapa

Zhvilluesit tanë e përdorin këtë proces prej 2 vitesh, kështu që na nevojitet një migrim sa më pa dhimbje. Prandaj, ne vendosëm të shtojmë një fazë ndërmjetëse në rrugën drejt qëllimit.
Faza e parë është e thjeshtë:

  • Ne ruajmĂ« njĂ« strukturĂ« tĂ« ngjashme pĂ«r konfigurimin e shpĂ«rndarjes sĂ« aplikacioneve, por nĂ« njĂ« objekt me emrin 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 lĂ«shim pĂ«r aplikacion (pa chart-e tĂ« pĂ«rgjithshme).
  • Chart-e nĂ« depozitĂ«n git tĂ« aplikacionit.

Kemi biseduar me të gjithë zhvilluesit, kështu që procesi i migrimit ka filluar tashmë. Faza e parë ende kontrollohet duke përdorur platformën CI. Shpejt do të shkruaj një postim tjetër për fazën e dytë: si kaluam në procesin GitOps me Flux. Do të tregoj se si e kemi konceptuar gjithçka dhe me çfarë vështirësish jemi përballur (disa depozita, sekrete, etj.). Qëndroni të informuar.

Këtu përpiqemi të përshkruajmë progresin tonë në procesin e shpërndarjes së aplikacioneve gjatë viteve të fundit, që na ka çuar në mendimin për qasjen GitOps. Endae nuk e kemi arritur qëllimin dhe do të raportojmë rezultatet, por tani jemi të bindur se vepruam si duhet kur vendosëm të thjeshtojmë gjithçka dhe ta afrojmë me zakonet e zhvilluesve.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster