Поставите апликације у више Кубернетес кластера помоћу Хелм-а

Како Даилимотион користи Кубернетес: Примена апликације

Ми у Даилимотион-у смо почели да користимо Кубернетес у производњи пре 3 године. Али постављање апликација у више кластера је забавно, тако да смо у последњих неколико година покушавали да побољшамо наше алате и токове посла.

Где је почело

Овде ћемо покрити како примењујемо наше апликације у више Кубернетес кластера широм света.

Да бисмо применили више Кубернетес објеката одједном, користимо кормило, а сви наши графикони се чувају у једном гит спремишту. Да бисмо применили комплетан стек апликација из неколико сервиса, користимо такозвани сажетак графикона. У суштини, ово је графикон који декларише зависности и омогућава вам да иницијализујете АПИ и његове услуге једном командом.

Написали смо и малу Питхон скрипту на врху Хелм-а за проверу, креирање графикона, додавање тајни и постављање апликација. Сви ови задаци се изводе на централној ЦИ платформи помоћу доцкер слике.

Пређимо на ствар.

Белешка. Док читате ово, први кандидат за издање за Хелм 3 је већ најављен. Главна верзија садржи читав низ побољшања за решавање неких проблема са којима смо се сусрели у прошлости.

Радни ток развоја графикона

Користимо гранање за апликације и одлучили смо да применимо исти приступ на графиконе.

• Филијала дев користи се за креирање графикона који ће бити тестирани на развојним кластерима.
• Када се поднесе захтев за повлачење мајстор, проверавају се у инсценацији.
• Коначно, креирамо захтев за повлачење за урезивање промена у грану прод и примењују их у производњи.

Свако окружење има своје приватно спремиште које чува наше графиконе и које ми користимо Цхартмусеум са веома корисним АПИ-јима. На овај начин обезбеђујемо строгу изолацију између окружења и тестирање графикона у стварном свету пре него што их употребимо у производњи.

Складишта графикона у различитим окружењима

Вреди напоменути да када програмери гурну грану за програмере, верзија њиховог графикона се аутоматски гура у дев Цхартмусеум. Дакле, сви програмери користе исто дев спремиште, а ви морате пажљиво да наведете своју верзију графикона како не бисте случајно користили туђе промене.

Штавише, наша мала Питхон скрипта потврђује Кубернетес објекте у односу на Кубернетес ОпенАПИ спецификације користећи Кубевал, пре него што их објави на Цхартмусем-у.

Општи опис тока рада развоја графикона

1. Постављање задатака цевовода према спецификацији газр.ио за контролу квалитета (линт, унит-тест).
2. Гурање доцкер слике помоћу Питхон алата који примењују наше апликације.
3. Подешавање окружења по имену гране.
4. Провера Кубернетес иамл датотека помоћу Кубевал-а.
5. Аутоматски повећајте верзију графикона и његових надређених графикона (графикони који зависе од графикона који се мења).
6. Слање графикона у Цхартмусеум који одговара његовом окружењу

Управљање разликама у кластерима

Федерација кластера

Било је времена када смо користили федерација Кубернетес кластера, где Кубернетес објекти могу бити декларисани са једне крајње тачке АПИ-ја. Али су се појавили проблеми. На пример, неки Кубернетес објекти нису могли да се креирају у крајњој тачки федерације, што отежава одржавање федералних објеката и других објеката за појединачне кластере.

Да бисмо решили проблем, почели смо да управљамо кластерима независно, што је умногоме поједноставило процес (користили смо прву верзију федерације; можда се нешто променило у другој).

Гео-дистрибуирана платформа

Наша платформа је тренутно дистрибуирана у 6 региона - 3 локално и 3 у облаку.

Дистрибутед Деплоимент

Глобал Хелм вредности

4 глобалне вредности Хелм-а вам омогућавају да идентификујете разлике између кластера. Сви наши графикони имају подразумеване минималне вредности.

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

Глобалне вредности

Ове вредности помажу у дефинисању контекста за наше апликације и користе се у различите сврхе: праћење, праћење, евидентирање, упућивање екстерних позива, скалирање итд.

• „облак“: Имамо хибридну Кубернетес платформу. На пример, наш АПИ је распоређен у ГЦП зонама и у нашим центрима података.
• „енв“: Неке вредности могу да се промене за непроизводна окружења. На пример, дефиниције ресурса и конфигурације аутоматског скалирања.
• „регион“: Ове информације помажу у одређивању локације кластера и могу се користити за одређивање оближњих крајњих тачака за спољне услуге.
• "цлустерНаме": ако и када желимо да дефинишемо вредност за појединачни кластер.

Ево конкретног примера:

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

Пример шаблона за кормило

Ова логика је дефинисана у помоћном шаблону да би се избегло затрпавање Кубернетес ИАМЛ-а.

Најава пријаве

Наши алати за примену су засновани на више ИАМЛ датотека. Испод је пример како декларишемо услугу и њену топологију скалирања (број реплика) у кластеру.

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

Дефиниција услуге

Ово је преглед свих корака који дефинишу наш ток рада за имплементацију. Последњи корак примењује апликацију на више кластера радника истовремено.

Кораци постављања Џенкинса

Шта је са тајнама?

Што се тиче безбедности, пратимо све тајне са различитих места и чувамо их у јединственом трезору Свод у Паризу.

Наши алати за примену извлаче тајне вредности из Ваулт-а и, када дође време примене, убацују их у Хелм.

Да бисмо то урадили, дефинисали смо мапирање између тајни у трезору и тајни које су потребне нашим апликацијама:

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"

• Дефинисали смо општа правила која треба поштовати када снимате тајне у трезору.
• Ако се тајна односи одређеном контексту или кластеру, потребно је да додате одређени унос. (Овде контекст цлустер1 има сопствену вредност за тајну лозинку за стецк-апп1).
• У супротном се користи вредност подразумевано.
• За сваку ставку на овој листи у Кубернетес тајна уметнут је пар кључ-вредност. Стога је тајни шаблон у нашим графиконима врло једноставан.

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

Проблеми и ограничења

Рад са више спремишта

Сада раздвајамо развој графикона и апликација. То значи да програмери морају да раде у два гит спремишта: једно за апликацију и једно за дефинисање њене примене у Кубернетес. 2 гит спремишта значе 2 тока посла, а почетницима је лако да се збуне.

Управљање генерализованим графиконима је гњаважа

Као што смо већ рекли, генерички графикони су веома корисни за идентификацију зависности и брзо постављање више апликација. Али ми користимо --reuse-valuesда бисмо избегли прослеђивање свих вредности сваки пут када применимо апликацију која је део овог генерализованог графикона.

У континуираном току рада испоруке, имамо само две вредности које се редовно мењају: број реплика и ознаку слике (верзија). Друге, стабилније вредности се мењају ручно, а то је прилично тешко. Штавише, једна грешка у примени генерализованог графикона може довести до озбиљних неуспеха, као што смо видели из сопственог искуства.

Ажурирање више конфигурационих датотека

Када програмер додаје нову апликацију, мора да промени неколико фајлова: декларацију апликације, листу тајни, додајући апликацију као зависност ако је укључена у генерализовани графикон.

Џенкинсове дозволе су превише проширене у трезору

Сада имамо једну АппРоле, који чита све тајне из Трезора.

Процес враћања није аутоматизован

Да бисте се вратили, потребно је да покренете команду на неколико кластера, а то је препуно грешака. Ову операцију изводимо ручно како бисмо осигурали да је наведен тачан ИД верзије.

Идемо ка ГитОпс-у

Наш циљ

Желимо да вратимо графикон у спремиште апликације коју примењује.

Ток посла ће бити исти као и за развој. На пример, када је грана гурнута на мастер, имплементација ће се аутоматски покренути. Главна разлика између овог приступа и тренутног тока посла би била у томе све ће се управљати у гит-у (сама апликација и начин на који је распоређена у Кубернетес).

Постоји неколико предности:

• Много јасније за програмера. Лакше је научити како да примените промене на локалном графикону.
• Дефиниција постављања услуге може бити специфицирана исто место као код usluga.
• Управљање уклањањем генерализованих графикона. Услуга ће имати сопствено издање Хелм-а. Ово ће вам омогућити да управљате животним циклусом апликације (повратак, надоградња) на најмањем нивоу, како не бисте утицали на друге услуге.
• Предности гит-а за управљање графиконом: опозовите промене, евиденцију ревизије, итд. Ако треба да поништите промену графикона, то можете учинити помоћу гит-а. Примена почиње аутоматски.
• Можда бисте размислили о побољшању тока развоја помоћу алата као што су Скаффолд, са којим програмери могу тестирати промене у контексту блиском продукцијском.

Миграција у два корака

Наши програмери користе овај ток рада већ 2 године, тако да желимо да миграција буде што безболнија. Стога смо одлучили да додамо међукорак на путу до циља.
Прва фаза је једноставна:

• Задржавамо сличну структуру за подешавање примене апликације, али у једном објекту који се зове ДаилимотионРелеасе.

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 издање по апликацији (без генерализованих графикона).
• Графикони у гит спремишту апликације.

Разговарали смо са свим програмерима, тако да је процес миграције већ почео. Прва фаза се још увек контролише помоћу ЦИ платформе. Ускоро ћу написати још један пост о другој фази: како смо прешли на ГитОпс радни ток Флукс. Рећи ћу вам како смо све поставили и на какве смо тешкоће наишли (више репозиторија, тајни итд.). Пратите вести.

Овде смо покушали да опишемо наш напредак у току рада примене апликација током протеклих година, што је довело до размишљања о ГитОпс приступу. Још нисмо достигли циљ и извештаваћемо о резултатима, али сада смо уверени да смо урадили праву ствар када смо одлучили да све поједноставимо и приближимо навикама програмера.

Извор: ввв.хабр.цом