ProHoster > Blog > Ma'muriyat > Helm yordamida bir nechta Kubernetes klasterlarida ilovalarni joylashtiring

Helm yordamida bir nechta Kubernetes klasterlarida ilovalarni joylashtiring

Dailymotion Kubernetesdan qanday foydalanadi: Ilovalarni joylashtirish

Biz Dailymotion-da 3 yil oldin ishlab chiqarishda Kubernetes-dan foydalanishni boshladik. Ammo ilovalarni bir nechta klasterlarda joylashtirish qiziqarli, shuning uchun so'nggi bir necha yil ichida biz asboblarimiz va ish jarayonlarimizni yaxshilashga harakat qilmoqdamiz.

Qayerdan boshlandi

Bu yerda biz ilovalarimizni dunyo boΚ»ylab bir nechta Kubernetes klasterlarida qanday joylashtirishimizni koΚ»rib chiqamiz.

Bir vaqtning o'zida bir nechta Kubernetes ob'ektlarini joylashtirish uchun biz foydalanamiz dubulg'a, va bizning barcha jadvallarimiz bitta git omborida saqlanadi. Bir nechta xizmatlardan to'liq ilovalar to'plamini o'rnatish uchun biz umumiy diagrammadan foydalanamiz. Aslida, bu bog'liqliklarni e'lon qiladigan va API va uning xizmatlarini bitta buyruq bilan ishga tushirishga imkon beruvchi diagramma.

Shuningdek, biz Helm tepasida tekshirishlar, diagrammalar yaratish, sirlarni qo'shish va ilovalarni joylashtirish uchun kichik Python skriptini yozdik. Bu vazifalarning barchasi docker tasviridan foydalangan holda markaziy CI platformasida amalga oshiriladi.

Keling, mavzuga o'taylik.

Eslatma. Siz buni o'qiyotganingizda, Helm 3 uchun birinchi reliz nomzodi allaqachon e'lon qilingan. Asosiy versiyada biz o'tmishda duch kelgan ba'zi muammolarni hal qilish uchun ko'plab yaxshilanishlar mavjud.

Diagrammani ishlab chiqish jarayoni

Ilovalar uchun biz filiallardan foydalanamiz va biz diagrammalarda ham xuddi shunday yondashuvni qo'llashga qaror qildik.

  • Filial ulkan rivojlanish klasterlarida sinovdan o'tkaziladigan diagrammalarni yaratish uchun foydalaniladi.
  • Pull so'rovi yuborilganda usta, ular sahnalashtirishda tekshiriladi.
  • Nihoyat, biz filialga o'zgartirish kiritish uchun tortish so'rovini yaratamiz prod va ularni ishlab chiqarishda qo'llash.

Har bir muhitda bizning jadvallarimizni saqlaydigan o'zining shaxsiy ombori mavjud va biz foydalanamiz Chartmuzeyi juda foydali API bilan. Shunday qilib, biz muhitlar o'rtasida qat'iy izolyatsiyani va ularni ishlab chiqarishda ishlatishdan oldin diagrammalarni haqiqiy sinovdan o'tkazamiz.

Turli muhitdagi diagramma omborlari

Shuni ta'kidlash kerakki, ishlab chiquvchilar dev bo'limini bosganda, ularning diagrammasining versiyasi avtomatik ravishda Dev Chartmuseumga yuboriladi. Shunday qilib, barcha ishlab chiquvchilar bir xil ishlab chiquvchilar omboridan foydalanadilar va boshqalarning o'zgarishlarini tasodifan ishlatmaslik uchun siz diagramma versiyasini diqqat bilan ko'rsatishingiz kerak.

Bundan tashqari, bizning kichik Python skriptimiz Kubernetes ob'ektlarini Kubernetes OpenAPI spetsifikatsiyalaridan foydalangan holda tasdiqlaydi. Kubeval, ularni Chartmusem-da nashr etishdan oldin.

Diagrammani ishlab chiqish ish jarayonining umumiy tavsifi

  1. Spetsifikatsiyaga muvofiq quvur liniyasi vazifalarini o'rnatish gazr.io sifat nazorati uchun (lint, birlik-test).
  2. Ilovalarimizni joylashtiradigan Python vositalari yordamida docker tasvirini surish.
  3. Filial nomi bo'yicha muhitni o'rnatish.
  4. Kubeval yordamida Kubernetes yaml fayllarini tekshirish.
  5. Grafik versiyasini va uning asosiy diagrammalarini avtomatik ravishda oshirish (o'zgartirilayotgan diagrammaga bog'liq diagrammalar).
  6. Chartmuseumga uning muhitiga mos keladigan diagramma yuborish

Klasterlar orasidagi farqlarni boshqarish

Klasterlar federatsiyasi

Biz foydalangan vaqtlar ham bor edi Kubernetes klasterlari federatsiyasi, bu erda Kubernetes ob'ektlari bitta API so'nggi nuqtasidan e'lon qilinishi mumkin. Ammo muammolar paydo bo'ldi. Misol uchun, ba'zi Kubernetes obyektlarini federatsiya so'nggi nuqtasida yaratib bo'lmadi, bu alohida klasterlar uchun federatsiyalangan ob'ektlar va boshqa ob'ektlarni saqlashni qiyinlashtirdi.

Muammoni hal qilish uchun biz klasterlarni mustaqil ravishda boshqarishni boshladik, bu jarayonni sezilarli darajada soddalashtirdi (biz federatsiyaning birinchi versiyasidan foydalandik; ikkinchisida nimadir o'zgargan bo'lishi mumkin).

Geo-tarqatilgan platforma

Bizning platformamiz hozirda 6 ta mintaqada tarqatilgan - 3 ta mahalliy va 3 ta bulutda.


Taqsimlangan joylashtirish

Global Helm qiymatlari

4 global Helm qiymatlari sizga klasterlar orasidagi farqlarni aniqlash imkonini beradi. Bizning barcha jadvallarimiz standart minimal qiymatlarga ega.

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

Global qadriyatlar

Ushbu qiymatlar bizning ilovalarimiz uchun kontekstni aniqlashga yordam beradi va turli maqsadlarda qo'llaniladi: monitoring, kuzatish, jurnalga yozish, tashqi qo'ng'iroqlarni amalga oshirish, masshtablash va boshqalar.

  • "bulut": Bizda gibrid Kubernetes platformasi mavjud. Masalan, bizning API GCP zonalarida va maΚΌlumotlar markazlarimizda joylashtirilgan.
  • "env": Ba'zi qiymatlar ishlab chiqarishdan tashqari muhitlar uchun o'zgarishi mumkin. Masalan, resurs ta'riflari va avtomatik o'lchov konfiguratsiyasi.
  • "mintaqa": Bu ma'lumot klaster joylashuvini aniqlashga yordam beradi va tashqi xizmatlar uchun yaqin atrofdagi so'nggi nuqtalarni aniqlash uchun ishlatilishi mumkin.
  • "clusterName": agar va qachon individual klaster uchun qiymat aniqlamoqchi bo'lsak.

Mana aniq bir misol:

{{/* 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 shabloniga misol

Bu mantiq Kubernetes YAML-ni chalkashtirib yubormaslik uchun yordamchi shablonda belgilangan.

Arizani e'lon qilish

Bizning tarqatish vositalarimiz bir nechta YAML fayllariga asoslangan. Quyida biz klasterda xizmat va uning masshtablash topologiyasini (replikalar soni) qanday e'lon qilishimiz misoli keltirilgan.

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

Xizmat ta'rifi

Bu bizning joylashtirish ish jarayonini belgilaydigan barcha bosqichlarning qisqacha tavsifi. Oxirgi qadam dasturni bir vaqtning o'zida bir nechta ishchi klasterlariga joylashtiradi.


Jenkinsni joylashtirish bosqichlari

Sirlar haqida nima deyish mumkin?

Xavfsizlikka kelsak, biz barcha sirlarni turli joylardan kuzatib boramiz va ularni noyob omborda saqlaymiz bank seyfi Parijda.

Bizning tarqatish vositalarimiz Vault'dan maxfiy qiymatlarni chiqaradi va o'rnatish vaqti kelganda ularni Helm-ga joylashtiring.

Buning uchun biz Vault sirlari va ilovalarimizga kerak bo'lgan sirlar o'rtasidagi xaritani aniqladik:

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-da sirlarni yozib olishda amal qilish kerak bo'lgan umumiy qoidalarni belgilab oldik.
  • Agar sir amal qilsa muayyan kontekstga yoki klasterga, ma'lum bir yozuvni qo'shishingiz kerak. (Bu erda kontekstli klaster1 maxfiy stack-app1-parol uchun o'z qiymatiga ega).
  • Aks holda, qiymat ishlatiladi sukut bo'yicha.
  • Ushbu ro'yxatdagi har bir element uchun Kubernetes siri kalit-qiymat juftligi kiritiladi. Shuning uchun, bizning jadvallarimizdagi maxfiy shablon juda oddiy.

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

Muammolar va cheklovlar

Bir nechta omborlar bilan ishlash

Endi biz diagrammalar va ilovalarni ishlab chiqishni ajratamiz. Bu shuni anglatadiki, ishlab chiquvchilar ikkita git omborida ishlashlari kerak: biri dastur uchun, ikkinchisi uning Kubernetes-ga joylashtirilishini aniqlash uchun. 2 git ombori 2 ish jarayonini bildiradi va yangi boshlanuvchilar chalkashib ketishi oson.

Umumlashtirilgan jadvallarni boshqarish juda qiyin

Yuqorida aytib o'tganimizdek, umumiy diagrammalar bog'liqliklarni aniqlash va bir nechta ilovalarni tezda joylashtirish uchun juda foydali. Lekin biz foydalanamiz --reuse-valuesUshbu umumlashtirilgan diagrammaning bir qismi bo'lgan ilovani har safar joylashtirganda barcha qiymatlarni o'tkazib yubormaslik uchun.

Uzluksiz etkazib berish ish jarayonida bizda muntazam ravishda o'zgarib turadigan faqat ikkita qiymat mavjud: replikalar soni va rasm yorlig'i (versiya). Boshqa barqaror qiymatlar qo'lda o'zgartiriladi va bu juda qiyin. Bundan tashqari, umumlashtirilgan diagrammani joylashtirishdagi bitta xato, biz o'z tajribamizdan ko'rganimizdek, jiddiy muvaffaqiyatsizlikka olib kelishi mumkin.

Bir nechta konfiguratsiya fayllarini yangilash

Ishlab chiquvchi yangi ilovani qo'shganda, u bir nechta fayllarni o'zgartirishi kerak: dastur deklaratsiyasi, sirlar ro'yxati, agar ilova umumlashtirilgan jadvalga kiritilgan bo'lsa, unga bog'liqlik sifatida qo'shiladi.

Jenkins ruxsatlari Vault'da juda kengaytirilgan

Endi bizda bitta AppRole, Vaultdan barcha sirlarni o'qiydi.

Orqaga qaytarish jarayoni avtomatlashtirilmagan

Orqaga qaytarish uchun siz buyruqni bir nechta klasterlarda bajarishingiz kerak va bu xatolar bilan to'la. To'g'ri versiya identifikatori ko'rsatilganligiga ishonch hosil qilish uchun biz ushbu operatsiyani qo'lda bajaramiz.

Biz GitOps tomon harakatlanmoqdamiz

Bizning maqsadimiz

Biz diagrammani u joylashtirgan ilovaning omboriga qaytarmoqchimiz.

Ish jarayoni rivojlanish bilan bir xil bo'ladi. Masalan, filial masterga surilganda, joylashtirish avtomatik ravishda ishga tushadi. Ushbu yondashuv va hozirgi ish jarayoni o'rtasidagi asosiy farq shundaki hamma narsa gitda boshqariladi (ilovaning o'zi va uni Kubernetesda joylashtirish usuli).

Bir nechta afzalliklarga ega:

  • Ko'p aniqroq ishlab chiquvchi uchun. Mahalliy diagrammadagi o'zgarishlarni qanday qo'llashni o'rganish osonroq.
  • Xizmatni joylashtirish ta'rifi belgilanishi mumkin kod bilan bir xil joy xizmat ko'rsatish.
  • Umumlashtirilgan diagrammalarni olib tashlashni boshqarish. Xizmat o'zining Helm versiyasiga ega bo'ladi. Bu boshqa xizmatlarga ta'sir qilmaslik uchun ilovaning hayot aylanishini (orqaga qaytarish, yangilash) eng kichik darajada boshqarish imkonini beradi.
  • Gitning afzalliklari diagramma boshqaruvi uchun: o'zgarishlarni bekor qilish, audit jurnali va boshqalar. Agar siz diagrammadagi o'zgarishlarni bekor qilishingiz kerak bo'lsa, buni git yordamida amalga oshirishingiz mumkin. O'rnatish avtomatik ravishda boshlanadi.
  • kabi vositalar yordamida ishlab chiqish ish jarayonini yaxshilash haqida o'ylashingiz mumkin Skaffold, uning yordamida ishlab chiquvchilar ishlab chiqarishga yaqin kontekstdagi o'zgarishlarni sinab ko'rishlari mumkin.

Ikki bosqichli migratsiya

Ishlab chiquvchilarimiz ushbu ish oqimidan 2 yildan beri foydalanishmoqda, shuning uchun biz migratsiya imkon qadar og'riqsiz bo'lishini xohlaymiz. Shuning uchun biz maqsadga erishish yo'lida oraliq bosqichni qo'shishga qaror qildik.
Birinchi bosqich oddiy:

  • Biz ilovalarni joylashtirishni o'rnatish uchun shunga o'xshash tuzilmani saqlaymiz, ammo DailymotionRelease deb nomlangan bitta ob'ektda.

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"

  • Har bir dastur uchun 1 ta nashr (umumiy jadvallarsiz).
  • Ilovaning git omboridagi diagrammalar.

Biz barcha ishlab chiquvchilar bilan gaplashdik, shuning uchun migratsiya jarayoni allaqachon boshlangan. Birinchi bosqich hali ham CI platformasi yordamida boshqariladi. Tez orada ikkinchi bosqich haqida yana bir post yozaman: GitOps ish jarayoniga qanday o'tganimiz oqib. Men sizga hamma narsani qanday o'rnatganimizni va qanday qiyinchiliklarga duch kelganimizni (bir nechta omborlar, sirlar va boshqalar) aytib beraman. Yangiliklarni kuzatib boring.

Bu erda biz so'nggi yillardagi ilovalarni joylashtirish bo'yicha ish jarayonidagi yutuqlarimizni tasvirlashga harakat qildik, bu GitOps yondashuvi haqida fikrlarni keltirib chiqardi. Biz hali maqsadga erishmadik va natijalar haqida hisobot beramiz, ammo endi biz hamma narsani soddalashtirishga va uni ishlab chiquvchilarning odatlariga yaqinlashtirishga qaror qilganimizda, biz to'g'ri ish qilganimizga amin bo'ldik.

Manba: www.habr.com

a Izoh qo'shish