ProHoster > Блог > Захиргаа > Helm ашиглан хэд хэдэн Kubernetes кластерт програмуудыг байрлуул

Helm ашиглан хэд хэдэн Kubernetes кластерт програмуудыг байрлуул

Dailymotion нь Kubernetes-ийг хэрхэн ашигладаг: Аппликейшн байршуулалт

Dailymotion-д бид 3 жилийн өмнөөс Kubernetes-ийг үйлдвэрлэлд ашиглаж эхэлсэн. Гэхдээ олон кластерт програмуудыг байрлуулах нь хөгжилтэй байдаг тул сүүлийн хэдэн жилийн турш бид багаж хэрэгсэл, ажлын урсгалаа сайжруулахыг хичээж байна.

Хаанаас эхэлсэн юм

Энд бид дэлхий даяарх хэд хэдэн Kubernetes кластерт өөрсдийн програмуудаа хэрхэн байршуулах талаар авч үзэх болно.

Олон Kubernetes объектыг нэгэн зэрэг байрлуулахын тулд бид ашигладаг Helm, мөн бидний бүх графикууд нэг git репозиторид хадгалагддаг. Хэд хэдэн үйлчилгээнүүдийн бүрэн програмын стекийг байрлуулахын тулд бид хураангуй диаграмыг ашигладаг. Үндсэндээ энэ нь хамаарлыг зарлаж, API болон түүний үйлчилгээг нэг тушаалаар эхлүүлэх боломжийг олгодог график юм.

Бид мөн Helm дээр жижиг Python скрипт бичсэн бөгөөд шалгах, диаграм үүсгэх, нууц нэмэх, програмуудыг байрлуулах боломжтой. Эдгээр бүх ажлыг докерын дүрс ашиглан төв CI платформ дээр гүйцэтгэдэг.

Гол зүйлдээ орцгооё.

Анхаарна уу. Үүнийг уншиж байхад Helm 3-ын анхны хувилбарын нэр дэвшигчийг аль хэдийн зарласан байна. Үндсэн хувилбар нь бидний өмнө тулгарч байсан зарим асуудлыг шийдвэрлэхэд чиглэсэн олон тооны сайжруулалтыг агуулдаг.

Диаграм боловсруулах ажлын урсгал

Бид програмын хувьд салбарлах аргыг ашигладаг бөгөөд диаграммд ч мөн адил аргыг хэрэглэхээр шийдсэн.

  • Салбар dev хөгжүүлэлтийн кластерууд дээр турших диаграммуудыг бий болгоход ашигладаг.
  • Татах хүсэлтийг илгээх үед мастер, тэдгээрийг үе шатанд шалгадаг.
  • Эцэст нь бид салбар руу өөрчлөлт оруулахын тулд татах хүсэлтийг үүсгэдэг бүтээгдэхүүн тэдгээрийг үйлдвэрлэлд ашиглах.

Хүрээлэн буй орчин бүр өөрийн гэсэн хувийн репозитортой бөгөөд бидний графикийг хадгалдаг бөгөөд бид үүнийг ашигладаг Чарт музей маш хэрэгтэй API-уудтай. Ингэснээр бид хүрээлэн буй орчныг хатуу тусгаарлаж, графикийг үйлдвэрлэлд ашиглахаасаа өмнө бодит байдалд туршиж үздэг.

Өөр өөр орчин дахь диаграмын агуулахууд

Хөгжүүлэгчид програмын салбарыг түлхэхэд тэдний диаграмын хувилбар автоматаар dev Chartmuseum руу шилждэг гэдгийг тэмдэглэх нь зүйтэй. Тиймээс бүх хөгжүүлэгчид ижил програмын агуулахыг ашигладаг бөгөөд хэн нэгний өөрчлөлтийг санамсаргүйгээр ашиглахгүйн тулд та графикийн хувилбараа сайтар зааж өгөх хэрэгтэй.

Нэмж дурдахад, бидний бяцхан Python скрипт нь Kubernetes объектуудыг Kubernetes OpenAPI-ийн техникийн үзүүлэлтүүдийн дагуу баталгаажуулдаг. Кубевал, тэдгээрийг Chartmusem дээр нийтлэхээс өмнө.

График боловсруулах ажлын явцын ерөнхий тодорхойлолт

  1. Тодорхойлолтын дагуу дамжуулах хоолойн ажлыг тохируулах gazr.io чанарын хяналтын хувьд (хөөс, нэгжийн туршилт).
  2. Манай програмуудыг байршуулдаг Python хэрэгслээр докерын дүрсийг түлхэж байна.
  3. Салбарын нэрээр орчныг тохируулах.
  4. Kubeval ашиглан Kubernetes yaml файлуудыг баталгаажуулж байна.
  5. График болон түүний эх диаграмын хувилбарыг автоматаар нэмэгдүүлэх (өөрчлөгдөж буй диаграмаас хамаарах графикууд).
  6. Chartmuseum-д хүрээлэн буй орчиндоо тохирсон диаграммыг илгээх

Кластер хоорондын ялгааг удирдах

Кластеруудын холбоо

Бид хэрэглэж байсан үе бий Кубернетес кластеруудын холбоо, энд Kubernetes объектуудыг нэг API төгсгөлийн цэгээс зарлах боломжтой. Гэвч асуудал үүссэн. Жишээ нь, зарим Kubernetes объектыг холбооны төгсгөлийн цэгт үүсгэх боломжгүй байсан нь нэгдмэл объектууд болон тусдаа кластеруудад зориулсан бусад объектуудыг хадгалахад хэцүү болгодог.

Асуудлыг шийдэхийн тулд бид кластеруудыг бие даан удирдаж эхэлсэн бөгөөд энэ нь үйл явцыг ихээхэн хялбаршуулсан (бид холбооны эхний хувилбарыг ашигласан; хоёр дахь нь ямар нэг зүйл өөрчлөгдсөн байж магадгүй).

Гео тархсан платформ

Манай платформ одоогоор 6 бүс нутагт тархсан байна - 3 орон нутагт, 3 үүлэн дээр.


Түгээмэл байршуулалт

Global Helm-ийн үнэ цэнэ

4 глобал Helm-ийн үнэ цэнэ нь кластер хоорондын ялгааг тодорхойлох боломжийг танд олгоно. Манай бүх диаграм нь анхдагч хамгийн бага утгатай байна.

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

Дэлхийн үнэт зүйлс

Эдгээр утгууд нь бидний хэрэглээний контекстийг тодорхойлоход тусалдаг бөгөөд янз бүрийн зорилгоор ашиглагддаг: хяналт тавих, мөрдөх, бүртгэх, гадаад дуудлага хийх, масштаблах гэх мэт.

  • "үүл": Бид эрлийз Kubernetes платформтой. Жишээлбэл, манай API нь GCP бүсүүд болон манай мэдээллийн төвүүдэд байрладаг.
  • "env": Үйлдвэрлэлийн бус орчинд зарим утгууд өөрчлөгдөж болно. Жишээлбэл, нөөцийн тодорхойлолт, автомат масштабын тохиргоо.
  • "бүс нутаг": Энэ мэдээлэл нь кластерын байршлыг тодорхойлоход тусалдаг бөгөөд гадны үйлчилгээний ойролцоох цэгүүдийг тодорхойлоход ашиглаж болно.
  • "clusterName": хэрэв бид тусдаа кластерын утгыг тодорхойлохыг хүсэж байгаа бол.

Энд тодорхой жишээ байна:

{{/* 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 -}}

Жолооны загварын жишээ

Kubernetes YAML-д саад учруулахгүйн тулд энэ логикийг туслах загварт тодорхойлсон болно.

Өргөдлийн зарлал

Манай байршуулах хэрэгслүүд нь олон YAML файл дээр суурилдаг. Бид үйлчилгээ болон түүний масштабын топологийг (хуулбарын тоо) кластерт хэрхэн зарлах жишээг доор харуулав.

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

Үйлчилгээний тодорхойлолт

Энэ бол бидний байршуулах ажлын урсгалыг тодорхойлсон бүх алхмуудын тойм юм. Сүүлийн алхам нь програмыг олон ажилчдын кластерт нэгэн зэрэг байрлуулна.


Женкинс байршуулах алхамууд

Нууцуудын талаар юу хэлэх вэ?

Аюулгүй байдлын тухайд бид өөр өөр газраас бүх нууцыг хянаж, өвөрмөц хайрцагт хадгалдаг Vault Парист.

Манай байршуулах хэрэгслүүд Vault-аас нууц утгыг гаргаж аваад, байршуулах цаг ирэхэд Helm-д оруулна.

Үүнийг хийхийн тулд бид Vault дахь нууцууд болон манай програмуудад шаардлагатай нууцуудын хоорондох зураглалыг тодорхойлсон.

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"

  • Бид Vault дээр нууцыг бичихдээ дагаж мөрдөх ерөнхий дүрмийг тодорхойлсон.
  • Хэрэв нууц хамааралтай бол тодорхой контекст эсвэл кластерт, та тодорхой оруулга нэмэх хэрэгтэй. (Энд контекст кластер1 нь нууц стек-апп1-нууц үгийн өөрийн гэсэн утгатай).
  • Үгүй бол утгыг ашиглана анхдагчаар.
  • Энэ жагсаалтад байгаа зүйл бүрийн хувьд Kubernetes нууц түлхүүр-утга хосыг оруулсан байна. Тиймээс манай график дахь нууц загвар нь маш энгийн.

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

Асуудал ба хязгаарлалт

Олон хадгалах газартай ажиллах

Одоо бид диаграмм болон хэрэглээний программуудыг хөгжүүлэх ажлыг салгаж байна. Энэ нь хөгжүүлэгчид хоёр git репозитор дээр ажиллах ёстой гэсэн үг юм: нэг нь програмд ​​зориулагдсан, нөгөө нь Kubernetes-д байршуулалтыг тодорхойлоход зориулагдсан. 2 git репозитор гэдэг нь 2 ажлын урсгал гэсэн үг бөгөөд шинэхэн хүн төөрөлдөхөд амархан байдаг.

Ерөнхий бүдүүвчийг удирдах нь төвөг учруулдаг

Өмнө дурьдсанчлан, ерөнхий диаграмууд нь хамаарлыг тодорхойлох, олон програмыг хурдан ашиглахад маш их хэрэгтэй байдаг. Гэхдээ бид ашигладаг --reuse-valuesЭнэхүү ерөнхий бүдүүвчийн нэг хэсэг болох програмыг ашиглах бүрт бүх утгыг дамжуулахаас зайлсхийхийн тулд.

Тасралтгүй хүргэх ажлын урсгалд бид байнга өөрчлөгддөг хоёр л утгатай байдаг: хуулбарын тоо болон зургийн шошго (хувилбар). Бусад, илүү тогтвортой утгыг гараар өөрчилдөг бөгөөд энэ нь нэлээд хэцүү байдаг. Түүнчлэн, ерөнхий бүдүүвчийг байрлуулахад нэг алдаа нь ноцтой бүтэлгүйтэлд хүргэж болзошгүйг бид өөрсдийн туршлагаас харсан.

Олон тохиргооны файлуудыг шинэчилж байна

Хөгжүүлэгч шинэ програм нэмэхдээ хэд хэдэн файлыг өөрчлөх шаардлагатай болно: програмын мэдэгдэл, нууцын жагсаалт, хэрэв ерөнхий графикт орсон бол түүнийг хамаарал болгон нэмнэ.

Vault-д Женкинсийн зөвшөөрлийг хэт сунгасан байна

Бидэнд одоо нэг байна AppRole, энэ нь Vault-аас бүх нууцыг уншдаг.

Буцах үйл явц автоматжаагүй байна

Буцааж авахын тулд та хэд хэдэн кластер дээр тушаалыг ажиллуулах хэрэгтэй бөгөөд энэ нь алдаатай байдаг. Бид зөв хувилбарын ID-г зааж өгөхийн тулд энэ үйлдлийг гараар гүйцэтгэдэг.

Бид GitOps руу явж байна

Бидний зорилго

Бид диаграмыг байршуулсан програмын репозитор руу буцаахыг хүсч байна.

Ажлын явц нь хөгжлийнхтэй адил байх болно. Жишээлбэл, салбарыг мастер руу түлхэх үед байршуулалт автоматаар өдөөгдөх болно. Энэ арга ба одоогийн ажлын урсгалын гол ялгаа нь үүнд байх болно бүх зүйлийг git дээр удирдах болно (програм нь өөрөө болон Kubernetes-д байршуулах арга зам).

Хэд хэдэн давуу талтай:

  • Маш их илүү тодорхой хөгжүүлэгчийн хувьд. Орон нутгийн диаграммд өөрчлөлтийг хэрхэн хэрэгжүүлэх талаар сурах нь илүү хялбар байдаг.
  • Үйлчилгээний байршуулалтын тодорхойлолтыг зааж өгч болно кодтой ижил газар үйлчилгээ.
  • Ерөнхий графикуудыг устгах ажлыг удирдах. Үйлчилгээ нь өөрийн Helm хувилбартай байх болно. Энэ нь бусад үйлчилгээнд нөлөөлөхгүйн тулд програмын амьдралын мөчлөгийг (буцах, шинэчлэх) хамгийн бага түвшинд удирдах боломжийг олгоно.
  • Git-ийн ашиг тус диаграмын удирдлагын хувьд: өөрчлөлтийг буцаах, аудитын бүртгэл гэх мэт. Хэрэв та диаграмын өөрчлөлтийг буцаах шаардлагатай бол git ашиглан үүнийг хийж болно. Байрлуулалт автоматаар эхэлнэ.
  • гэх мэт хэрэгслээр хөгжүүлэлтийн ажлын урсгалаа сайжруулах талаар бодож магадгүй Скаффолд, үүний тусламжтайгаар хөгжүүлэгчид үйлдвэрлэлд ойрхон нөхцөлд өөрчлөлтийг туршиж үзэх боломжтой.

Хоёр шатлалт шилжилт хөдөлгөөн

Манай хөгжүүлэгчид энэ ажлын урсгалыг 2 жилийн турш ашиглаж байгаа тул шилжилт хөдөлгөөнийг аль болох өвдөлтгүй байлгахыг хүсч байна. Тиймээс бид зорилгодоо хүрэх замд завсрын алхам нэмэхээр шийдсэн.
Эхний шат нь энгийн:

  • Бид програмын байршуулалтыг тохируулах ижил төстэй бүтцийг хадгалдаг, гэхдээ 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 хувилбар (ерөнхий графикгүйгээр).
  • Програмын git репозитор дахь графикууд.

Бид бүх хөгжүүлэгчидтэй ярилцсан тул шилжих процесс аль хэдийн эхэлсэн. Эхний үе шатыг CI платформ ашиглан удирдаж байна. Би удахгүй GitOps ажлын урсгал руу хэрхэн шилжсэн тухай хоёр дахь үе шатны талаар өөр нийтлэл бичих болно урсгал. Бид бүх зүйлийг хэрхэн тохируулж, ямар бэрхшээлтэй тулгарсан (олон хадгалах газар, нууц гэх мэт) танд хэлье. Мэдээг дагаж мөрдөөрэй.

Энд бид GitOps аргын талаар бодоход хүргэсэн сүүлийн жилүүдэд хэрэглүүр байршуулах ажлын явц дахь ахиц дэвшлийг тайлбарлахыг оролдсон. Бид зорилгодоо хараахан хүрээгүй байгаа бөгөөд үр дүнгийн талаар мэдээлэх болно, гэхдээ одоо бид бүх зүйлийг хялбаршуулж, хөгжүүлэгчдийн зуршилд ойртуулахаар шийдсэндээ зөв зүйл хийсэн гэдэгт итгэлтэй байна.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх