Распоредување на апликации на повеќе кластери на Kubernetes со Helm

Како Dailymotion го користи Kubernetes: распоредување на апликации

Ние во Dailymotion почнавме да го користиме Kubernetes во производството пред 3 години. Но, распоредувањето апликации низ повеќе кластери е забавно, така што во последните неколку години се обидуваме да ги подобриме нашите алатки и работни текови.

Каде почна

Овде ќе покриеме како ги распоредуваме нашите апликации низ повеќе кластери на Kubernetes ширум светот.

За да распоредиме повеќе Кубернетес објекти одеднаш, користиме кормилото, и сите наши графикони се зачувани во едно git складиште. За да распоредиме целосен куп апликации од неколку услуги, ја користиме таканаречената сумарна табела. Во суштина, ова е графикон кој декларира зависности и ви овозможува да го иницијализирате API и неговите услуги со една команда.

Напишавме и мала Python скрипта на врвот на Helm за да правиме проверки, да создаваме графикони, да додаваме тајни и да распоредуваме апликации. Сите овие задачи се изведуваат на централна CI платформа со помош на докер слика.

Ајде да дојдеме до поентата.

Забелешка. Додека го читате ова, веќе е објавен првиот кандидат за издавање на Helm 3. Главната верзија содржи цела низа подобрувања за решавање на некои од проблемите со кои се сретнавме во минатото.

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

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

• Филијала dev се користи за креирање графикони кои ќе се тестираат на развојни кластери.
• Кога се поднесува барање за повлекување до господар, се проверуваат во етапно.
• Конечно, креираме барање за повлекување за да ги извршиме промените во гранката prod и да ги применуваат во производството.

Секоја околина има свое приватно складиште кое ги чува нашите графикони, а ние ги користиме Шартмузеј со многу корисни API. На овој начин обезбедуваме строга изолација помеѓу околините и тестирање на графиконите во реалниот свет пред да ги користите во производството.

Складишта на графикони во различни средини

Вреди да се напомене дека кога програмерите туркаат гранка на dev, верзијата на нивната табела автоматски се турка во Музејот на dev Chartmuseum. Така, сите програмери го користат истото складиште на dev, и треба внимателно да ја наведете вашата верзија на графиконот за да не случајно да користите туѓи промени.

Покрај тоа, нашата мала Python скрипта ги потврдува објектите на Kubernetes наспроти спецификациите Kubernetes OpenAPI користејќи Кубевал, пред да ги објави на Chartmusem.

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

1. Поставување задачи на гасоводот според спецификацијата gazr.io за контрола на квалитетот (влакнест, единица-тест).
2. Притискање на докер-слика со Python алатки кои ги распоредуваат нашите апликации.
3. Поставување на околината по име на гранка.
4. Валидација на Kubernetes yaml датотеки со користење на Kubeval.
5. Автоматски зголемете ја верзијата на графиконот и неговите матични графикони (табели што зависат од менувањето на графиконот).
6. Поднесување графикон до Музејот на графикони што одговара на неговата околина

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

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

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

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

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

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

Дистрибуирано распоредување

Вредностите на глобалната кормила

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 и, кога ќе дојде време за распоредување, ги вметнуваат во 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 има своја вредност за тајниот stack-app1-password).
• Во спротивно, вредноста се користи стандардно.
• За секоја ставка во оваа листа во Тајната на Кубернет се вметнува пар клуч-вредност. Затоа, тајниот шаблон во нашите графикони е многу едноставен.

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, кој ги чита сите тајни од Трезорот.

Процесот на враќање не е автоматизиран

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

Се движиме кон GitOps

Нашата цел

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

Работниот тек ќе биде ист како и за развој. На пример, кога една гранка ќе се притисне да се совлада, распоредувањето ќе се активира автоматски. Главната разлика помеѓу овој пристап и тековниот работен тек би била тоа сè ќе се управува во git (самата апликација и начинот на кој е распоредена во Kubernetes).

Има неколку предности:

• Многу појасно за инвеститорот. Полесно е да научите како да ги примените промените во локалниот графикон.
• Може да се наведе дефиницијата за распоредување на услугата истото место како кодот Сервис.
• Управување со отстранување на генерализирани графикони. Услугата ќе има сопствено ослободување на Helm. Ова ќе ви овозможи да управувате со животниот циклус на апликацијата (враќање, надградба) на најмало ниво, за да не влијаете на другите услуги.
• Придобивки од 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