ProHoster > Blog > башкаруу > Helm менен бир нече Kubernetes кластерлерине тиркемелерди жайгаштырыңыз

Helm менен бир нече Kubernetes кластерлерине тиркемелерди жайгаштырыңыз

Dailymotion кантип Kubernetes колдонот: Колдонмолорду жайылтуу

Биз Dailymotion компаниясында 3 жыл мурун өндүрүштө Kubernetes колдоно баштаганбыз. Бирок колдонмолорду бир нече кластерлерде жайылтуу кызыктуу, ошондуктан акыркы бир нече жылда биз куралдарыбызды жана иш процесстерибизди жакшыртууга аракет кылып жатабыз.

Кайдан башталды

Бул жерде биз дүйнө жүзү боюнча бир нече Kubernetes кластерлеринде тиркемелерибизди кантип жайгаштыраарыбызды карап чыгабыз.

Бир эле учурда бир нече Kubernetes объектилерин жайгаштыруу үчүн биз колдонобуз башкаруу рулю, жана биздин бардык диаграммаларыбыз бир гит репозиторийинде сакталат. Бир нече кызматтардан толук тиркеме стегин жайылтуу үчүн биз жыйынды диаграмма деп аталганды колдонобуз. Негизинен, бул көз карандылыкты жарыялаган диаграмма жана API жана анын кызматтарын бир буйрук менен инициализациялоого мүмкүндүк берет.

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

Келгиле, кепке келели.

Эскертүү. Сиз муну окуп жатканда, Helm 3 үчүн биринчи релиз талапкери буга чейин жарыяланган. Негизги версияда биз мурда кездешкен айрым маселелерди чечүү үчүн көптөгөн жакшыртуулар камтылган.

Диаграмманы иштеп чыгуу процесси

Биз тиркемелер үчүн бутактандырууну колдонобуз жана диаграммаларга да ушундай ыкманы колдонууну чечтик.

  • Филиалы ишт.ч. өнүктүрүү кластерлеринде сынала турган диаграммаларды түзүү үчүн колдонулат.
  • Тартуу өтүнүчү берилгенде кожоюн, алар коюуда текшерилет.
  • Акыры, биз филиалга өзгөртүүлөрдү киргизүү үчүн тартуу өтүнүчүн түзөбүз продукт жана аларды ендуруште колдонуу.

Ар бир чөйрөдө биздин диаграммаларды сактаган өзүнүн жеке репозиторийлери бар жана биз колдонобуз Chartmuseum абдан пайдалуу API менен. Ушундай жол менен биз чөйрөнүн ортосунда катуу изоляцияны жана диаграммаларды өндүрүштө колдонуудан мурун реалдуу дүйнөдөгү сыноону камсыз кылабыз.

Ар кандай чөйрөлөрдөгү диаграмма репозиторийлери

Белгилей кетчү нерсе, иштеп чыгуучулар иштеп чыгуучу бутагын түрткөндө, алардын диаграммасынын версиясы автоматтык түрдө dev Chartmuseumга түртүлөт. Ошентип, бардык иштеп чыгуучулар бир эле иштеп чыгуучу репозиторийди колдонушат жана башка бирөөнүн өзгөртүүлөрүн кокустан колдонбоо үчүн диаграмманын версиясын кылдат тактооңуз керек.

Мындан тышкары, биздин кичинекей Python скриптибиз Kubernetes объекттерин Kubernetes OpenAPI спецификацияларына каршы текшерет. Кубевал, аларды Chartmusemде жарыялоодон мурун.

Диаграмманы иштеп чыгуунун жалпы сүрөттөлүшү

  1. спецификацияга ылайык түтүк милдеттерин орнотуу gazr.io сапатын контролдоо үчүн (линт, бирдик-сыноо).
  2. Биздин тиркемелерди жайгаштырган Python куралдары менен докердин сүрөтүн түртүү.
  3. Тармактын аталышы боюнча чөйрөнү орнотуу.
  4. Kubeval аркылуу Kubernetes yaml файлдарын текшерүү.
  5. Диаграмманын версиясын жана анын негизги диаграммаларын автоматтык түрдө көбөйтүү (өзгөрүлүп жаткан диаграммага жараша диаграммалар).
  6. Чартмузейге анын чөйрөсүнө дал келген диаграмма тапшыруу

Кластерлердин ортосундагы айырмачылыктарды башкаруу

Кластерлердин федерациясы

Биз колдонгон учур болгон Кубернетес кластерлеринин федерациясы, бул жерде 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 -}}

Helm үлгүсү

Бул логика 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'дан жашыруун баалуулуктарды алып чыгып, жайгаштыруу убактысы келгенде, аларды 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

Проблемалар жана чектөөлөр

Бир нече репозиторийлер менен иштөө

Эми биз диаграммаларды жана тиркемелерди иштеп чыгууну бөлөбүз. Бул иштеп чыгуучулар эки гит репозиторийинде иштеши керек дегенди билдирет: бири тиркеме үчүн, экинчиси анын Kubernetesке жайгаштырылышын аныктоо үчүн. 2 гит репозиторийлери 2 иш процессин билдирет жана жаңыдан башаламан болуп калышы оңой.

Жалпыланган диаграммаларды башкаруу түйшүк

Жогоруда айтылгандай, жалпы диаграммалар көз карандылыкты аныктоо жана бир нече тиркемелерди тез жайылтуу үчүн абдан пайдалуу. Бирок биз колдонобуз --reuse-valuesБул жалпыланган диаграмманын бир бөлүгү болгон тиркемени жайылткан сайын бардык баалуулуктарды өткөрүп жибербөө үчүн.

Үзгүлтүксүз жеткирүү иш процессинде бизде дайыма өзгөрүп турган эки гана маани бар: репликалардын саны жана сүрөт теги (версиясы). Башка туруктуу баалуулуктар кол менен өзгөртүлөт жана бул абдан кыйын. Андан тышкары, жалпыланган диаграмманы жайгаштыруудагы бир ката олуттуу кемчиликтерге алып келиши мүмкүн, муну биз өз тажрыйбабыздан көрдүк.

Бир нече конфигурация файлдарын жаңыртуу

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

Jenkins уруксаттары Vault'та өтө кеңейтилген

Азыр бизде бирөө бар AppRole, ал Vault бардык сырларын окуйт.

Артка кайтаруу процесси автоматташтырылган эмес

Артка кайтаруу үчүн, сиз буйрукту бир нече кластерлерде иштетишиңиз керек жана бул каталар менен коштолот. Туура версия ID көрсөтүлгөнүн текшерүү үчүн биз бул операцияны кол менен аткарабыз.

Биз GitOps көздөй жылып жатабыз

Биздин максат

Биз диаграмманы ал жайгаштырган колдонмонун репозиторийине кайтаргыбыз келет.

Иш процесси иштеп чыгуудагыдай болот. Мисалы, бутак кожоюнга түртүлгөндө, жайылтуу автоматтык түрдө ишке киргизилет. Бул ыкма менен учурдагы иш процессинин негизги айырмасы мына ушунда болот баары gitте башкарылат (колдонмонун өзү жана аны Kubernetesте жайгаштыруу жолу).

бир нече артыкчылыктары бар:

  • көп айкыныраак иштеп чыгуучу үчүн. Жергиликтүү диаграммада өзгөртүүлөрдү кантип колдонууну үйрөнүү оңой.
  • Кызматты жайылтуу аныктамасы көрсөтүлүшү мүмкүн код менен бирдей жер кызматы.
  • Жалпыланган диаграммаларды алып салууну башкаруу. Кызматтын өзүнүн Helm релизине ээ болот. Бул башка кызматтарга таасирин тийгизбеши үчүн колдонмонун жашоо циклин (кайра, жаңыртуу) эң кичине деңгээлде башкарууга мүмкүндүк берет.
  • Gitтин пайдасы диаграммаларды башкаруу үчүн: өзгөртүүлөрдү жокко чыгаруу, аудит журналы ж.б.. Эгер диаграммадагы өзгөртүүнү жокко чыгаруу керек болсо, муну git аркылуу кылсаңыз болот. Жайгаштыруу автоматтык түрдө башталат.
  • Сиз сыяктуу куралдар менен иштеп чыгуу процессиңизди жакшыртууну ойлонушуңуз мүмкүн Skaffold, анын жардамы менен иштеп чыгуучулар өндүрүшкө жакын контекстте өзгөрүүлөрдү сынай алышат.

Эки кадамдуу миграция

Биздин иштеп чыгуучулар бул иш процессин 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 мамилеси жөнүндө ойлорго алып келген акыркы жылдардагы тиркемени жайылтуу иш процессиндеги прогрессибизди сүрөттөөгө аракет кылдык. Биз максатка жете элекпиз жана анын натыйжалары жөнүндө кабарлайбыз, бирок азыр биз бардыгын жөнөкөйлөштүрүп, аны иштеп чыгуучулардын адаттарына жакындатууну чечкенде туура иш кылганыбызга ынандык.

Source: www.habr.com

Комментарий кошуу