Разполагане на приложения в множество Kubernetes клъстери с Helm

Как Dailymotion използва Kubernetes: Разполагане на приложения

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

Откъде започна

Тук ще разгледаме как внедряваме нашите приложения в множество Kubernetes клъстери по света.

За да разположим няколко Kubernetes обекта наведнъж, използваме Шлеми всички наши диаграми се съхраняват в едно git хранилище. За да внедрим пълен стек от приложения от няколко услуги, ние използваме така наречената обобщена диаграма. По същество това е диаграма, която декларира зависимости и ви позволява да инициализирате API и неговите услуги с една команда.

Написахме и малък Python скрипт върху Helm, за да правим проверки, да създаваме диаграми, да добавяме тайни и да внедряваме приложения. Всички тези задачи се изпълняват на централна CI платформа с помощта на докер изображение.

Да минем по същество.

Забележка. Докато четете това, първият кандидат за освобождаване на Helm 3 вече е обявен. Основната версия съдържа цял набор от подобрения за справяне с някои от проблемите, които сме срещали в миналото.

Работен процес за разработване на диаграма

Използваме разклоняване за приложения и решихме да приложим същия подход към диаграмите.

• Клон Дев използвани за създаване на диаграми, които ще бъдат тествани на клъстери за разработка.
• Когато се изпрати заявка за изтегляне на майстор, те се проверяват поетапно.
• Накрая създаваме заявка за изтегляне, за да ангажираме промените в клона ръгане и ги прилагат в производството.

Всяка среда има собствено частно хранилище, което съхранява нашите диаграми и ние използваме Chartmuseum с много полезни API. По този начин гарантираме стриктна изолация между средите и тестване в реалния свят на диаграми, преди да ги използваме в производството.

Хранилища на диаграми в различни среди

Струва си да се отбележи, че когато разработчиците натискат клон за разработчици, версия на тяхната диаграма автоматично се изпраща в dev Chartmuseum. По този начин всички разработчици използват едно и също хранилище за разработчици и трябва внимателно да посочите вашата версия на диаграмата, за да не използвате случайно промените на някой друг.

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

Общо описание на работния процес за разработване на диаграма

1. Настройване на конвейерни задачи според спецификацията gazr.io за контрол на качеството (мъх, тест на единица).
2. Избутване на докер изображение с инструменти на Python, които внедряват нашите приложения.
3. Настройка на средата по име на клон.
4. Валидиране на Kubernetes yaml файлове с помощта на Kubeval.
5. Автоматично увеличаване на версията на диаграма и нейните родителски диаграми (диаграми, които зависят от променената диаграма).
6. Изпращане на диаграма в Chartmuseum, която съответства на неговата среда

Управление на различията между клъстерите

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

Имаше време, когато използвахме федерация на Kubernetes клъстери, където обектите на 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

Дефиниция на услугата

Това е схема на всички стъпки, които определят нашия работен процес за внедряване. Последната стъпка разгръща приложението в множество работни клъстери едновременно.

Стъпки за разполагане на Jenkins

Ами тайните?

По отношение на сигурността, ние проследяваме всички тайни от различни места и ги съхраняваме в уникален трезор свод в Париж.

Нашите инструменти за внедряване извличат тайни стойности от 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.
• Ако тайната е приложима към конкретен контекст или клъстер, трябва да добавите конкретен запис. (Тук контекстът cluster1 има своя собствена стойност за тайната парола на stack-app1).
• В противен случай се използва стойността по подразбиране.
• За всеки елемент от този списък в Тайната на 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за да избегнем предаването на всички стойности всеки път, когато разположим приложение, което е част от тази обобщена диаграма.

В непрекъснат работен процес на доставка имаме само две стойности, които се променят редовно: броя на репликите и етикета на изображението (версия). Други, по-стабилни стойности се променят ръчно и това е доста трудно. Освен това една грешка при разгръщането на обобщена диаграма може да доведе до сериозни неуспехи, както видяхме от собствения си опит.

Актуализиране на множество конфигурационни файлове

Когато разработчикът добави ново приложение, той трябва да промени няколко файла: декларацията на приложението, списъка с тайни, добавяне на приложението като зависимост, ако е включено в обобщената диаграма.

Разрешенията на Jenkins са твърде разширени в Vault

Сега имаме един AppRole, който чете всички тайни от Трезора.

Процесът на връщане не е автоматизиран

За да се върнете назад, трябва да изпълните командата на няколко клъстера и това е изпълнено с грешки. Извършваме тази операция ръчно, за да гарантираме, че е посочен правилният идентификатор на версията.

Придвижваме се към 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 Flux. Ще ви кажа как настроихме всичко и какви трудности срещнахме (множество хранилища, тайни и т.н.). Следете новините.

Тук се опитахме да опишем нашия напредък в работния процес за внедряване на приложения през последните години, което доведе до мисли относно подхода GitOps. Все още не сме постигнали целта и ще докладваме за резултатите, но сега сме убедени, че постъпихме правилно, когато решихме да опростим всичко и да го доближим до навиците на разработчиците.

Източник: www.habr.com