Helm 3 bilan tanishtirish

Helm 3 bilan tanishtirish

Eslatma. tarjima.: Joriy yilning 16-may kuni Kubernetes - Helm uchun paketlar menejerini ishlab chiqishda muhim bosqich bo'ldi. Shu kuni loyihaning kelajakdagi asosiy versiyasining birinchi alfa-relizi - 3.0 taqdim etildi. Uning chiqarilishi Helm-ga sezilarli va uzoq kutilgan o'zgarishlarni olib keladi, bunga Kubernetes hamjamiyatidagi ko'pchilik katta umid bog'laydi. Biz o'zimiz ham ulardan birimiz, chunki biz Helm-dan ilovalarni joylashtirish uchun faol foydalanamiz: biz uni CI/CD-ni amalga oshirish uchun vositamizga birlashtirdik. werf va vaqti-vaqti bilan biz yuqori oqimni rivojlantirishga o'z hissamizni qo'shamiz. Ushbu tarjima Helm 7 ning birinchi alfa versiyasiga bag'ishlangan va loyiha tarixi va Helm 3 ning asosiy xususiyatlari haqida gapiradigan rasmiy Helm blogidagi 3 ta eslatmani birlashtiradi. Ularning muallifi Matt "bacongobbler" Fisher, Microsoft xodimi. va Helmning asosiy saqlovchilaridan biri.

15-yil 2015-oktabrda hozirda Helm nomi bilan tanilgan loyiha tug‘ildi. Tashkil etilganidan bir yil o'tgach, Helm hamjamiyati Helm 2 ustida faol ishlayotgan vaqtda Kubernetesga qo'shildi. 2018 yil iyun oyida Helm CNCFga qo'shildi rivojlanayotgan (inkubatsiya qiluvchi) loyiha sifatida. Hozircha oldinga siljiting va yangi Helm 3 ning birinchi alfa-versiyasi yo'lda. (ushbu nashr allaqachon sodir bo'lgan may oyining o'rtalarida - taxminan. tarjima.).

Ushbu maqolada men hammasi qaerdan boshlangani, bugungi kunga qanday etib kelganimiz haqida gapirib beraman, Helm 3 ning birinchi alfa versiyasida mavjud bo'lgan ba'zi noyob xususiyatlar bilan tanishtiraman va bundan keyin qanday rivojlanishni rejalashtirganimizni tushuntiraman.

Xulosa:

  • Helmning yaratilish tarixi;
  • Tiller bilan xayrlashish;
  • diagramma omborlari;
  • chiqarishni boshqarish;
  • diagrammaga bog'liqliklarning o'zgarishi;
  • kutubxona jadvallari;
  • keyin nima?

Helm tarixi

Tug'ilgan

Helm 1 Deis tomonidan yaratilgan Open Source loyihasi sifatida boshlangan. Biz kichik startap edik so'riladi Microsoft 2017 yil bahorida. Bizning boshqa ochiq manba loyihamiz, shuningdek, Deis deb nomlangan vositamiz bor edi deisctl, (boshqa narsalar qatorida) Deis platformasini o'rnatish va ishlatish uchun ishlatilgan Filo klasteri. O'sha paytda Fleet birinchi konteyner orkestr platformalaridan biri edi.

2015 yil o'rtalarida biz yo'nalishni o'zgartirishga qaror qildik va Deisni (o'sha paytda Deis Workflow deb o'zgartirildi) Fleetdan Kubernetesga ko'chirdik. Qayta ishlab chiqilgan birinchilardan biri o'rnatish vositasi edi. deisctl. Biz undan Fleet klasterida Deis Workflow-ni o'rnatish va boshqarish uchun foydalandik.

Helm 1 Homebrew, apt va yum kabi mashhur paket menejerlari qiyofasida yaratilgan. Uning asosiy maqsadi Kubernetes-da ilovalarni qadoqlash va o'rnatish kabi vazifalarni soddalashtirish edi. Helm rasman 2015 yilda San-Frantsiskodagi KubeCon konferensiyasida taqdim etilgan.

Helm bilan birinchi urinishimiz natija berdi, ammo bu jiddiy cheklovlardan xoli emas edi. U boshlang'ich YAML bloklari sifatida generatorlar bilan ta'minlangan Kubernetes manifestlari to'plamini oldi. (oldingi masala)* va natijalarni Kubernetesga yukladi.

* Eslatma. tarjima.: Helmning birinchi versiyasidan Kubernetes resurslarini tavsiflash uchun YAML sintaksisi tanlangan va konfiguratsiyalarni yozishda Jinja shablonlari va Python skriptlari qo‘llab-quvvatlangan. Biz bu haqda va umuman Helmning birinchi versiyasining tuzilishi haqida "Helmning qisqacha tarixi" bobida ko'proq yozganmiz. bu material.

Masalan, YAML faylidagi maydonni almashtirish uchun siz manifestga quyidagi konstruktsiyani qo'shishingiz kerak edi:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Bugungi kunda shablonli dvigatellar mavjudligi ajoyib, shunday emasmi?

Ko'pgina sabablarga ko'ra, Kubernetesning ushbu dastlabki o'rnatuvchisi manifest fayllarning qattiq kodlangan ro'yxatini talab qildi va faqat kichik, qat'iy hodisalar ketma-ketligini bajardi. Foydalanish shunchalik qiyin ediki, Deis Workflow R&D jamoasi o‘z mahsulotlarini ushbu platformaga o‘tkazishga urinib ko‘rishganda qiynaldilar – ammo bu g‘oya urug‘lari allaqachon ekilgan edi. Bizning birinchi urinishimiz ajoyib o'rganish imkoniyati edi: biz foydalanuvchilarimiz uchun kundalik muammolarni hal qiladigan pragmatik vositalarni yaratishga chinakam ishtiyoqli ekanligimizni angladik.

O'tgan xatolar tajribasiga asoslanib, biz Helm 2 ni ishlab chiqishni boshladik.

Rulni yasash 2

2015 yil oxirida Google jamoasi biz bilan bog'landi. Ular Kubernetes uchun xuddi shunday vosita ustida ishlayotgan edi. Kubernetes uchun joylashtirish menejeri Google Cloud Platform uchun ishlatiladigan mavjud vosita porti edi. "Biz bir necha kun o'xshashlik va farqlarni muhokama qilishni xohlaymizmi?"

2016-yil yanvar oyida “Helm” va “Deployment Manager” guruhlari Sietl shahrida fikr almashish uchun uchrashishdi. Muzokaralar ambitsiyali reja bilan yakunlandi: Helm 2 yaratish uchun ikkala loyihani birlashtirish. Deis va Google bilan birga SkippBox (hozir Bitnami qismi - taxminan. tarjima), va biz Helm 2 ustida ishlay boshladik.

Biz Helm-dan foydalanish qulayligini saqlamoqchi edik, lekin quyidagilarni qo'shing:

  • moslashtirish uchun diagramma shablonlari;
  • jamoalar uchun klaster ichidagi boshqaruv;
  • jahon darajasidagi grafiklar ombori;
  • imzo opsiyasi bilan barqaror paket formati;
  • semantik versiyalashtirish va versiyalar o'rtasida orqaga qarab muvofiqlikni saqlashga qat'iy sodiqlik.

Ushbu maqsadlarga erishish uchun Helm ekotizimiga ikkinchi element qo'shildi. Ushbu klaster ichidagi komponent Tiller deb nomlangan va Helm diagrammalarini o'rnatish va ularni boshqarish uchun javobgar edi.

2-yilda Helm 2016 chiqqandan beri Kubernetes bir nechta asosiy yangiliklarni qo'shdi. Rolga asoslangan kirish boshqaruvi qo'shildi (RBAC), bu oxir-oqibat Atributga asoslangan kirishni boshqarish (ABAC) o'rnini egalladi. Yangi resurs turlari joriy etildi (O'rnatishlar hali beta-versiyada edi). Maxsus resurs ta'riflari (dastlab uchinchi tomon resurslari yoki TPR deb ataladi) ixtiro qilingan. Va eng muhimi, eng yaxshi tajribalar to'plami paydo bo'ldi.

Ushbu o'zgarishlarning barchasida Helm Kubernetes foydalanuvchilariga sodiqlik bilan xizmat qilishda davom etdi. Uch yil va ko'plab yangi qo'shimchalardan so'ng, Helm rivojlanayotgan ekotizimning o'sib borayotgan ehtiyojlarini qondirishda davom etishini ta'minlash uchun kodlar bazasiga jiddiy o'zgartirishlar kiritish vaqti kelganligi aniq bo'ldi.

Tiller bilan xayrlashish

Helm 2 ni ishlab chiqish jarayonida biz Google Deployment Manager bilan integratsiyalashuvimizning bir qismi sifatida Tillerni taqdim etdik. Tiller umumiy klasterda ishlaydigan jamoalar uchun muhim rol o'ynadi: u infratuzilmani boshqaradigan turli mutaxassislarga bir xil relizlar to'plami bilan o'zaro aloqada bo'lish imkonini berdi.

Kubernetes 1.6 da rolga asoslangan kirishni boshqarish (RBAC) sukut bo'yicha yoqilganligi sababli, ishlab chiqarishda Tiller bilan ishlash qiyinlashdi. Mumkin bo'lgan xavfsizlik siyosatlarining ko'pligi tufayli bizning pozitsiyamiz sukut bo'yicha ruxsat beruvchi konfiguratsiyani taklif qilish edi. Bu yangi boshlanuvchilarga birinchi navbatda xavfsizlik sozlamalariga sho'ng'imasdan Helm va Kubernetes bilan tajriba o'tkazish imkonini berdi. Afsuski, ushbu ruxsat konfiguratsiyasi foydalanuvchiga kerak bo'lmagan juda keng doiradagi ruxsatlarni berishi mumkin. DevOps va SRE muhandislari Tillerni ko'p ijarachilarli klasterga o'rnatishda qo'shimcha operatsion bosqichlarni o'rganishlari kerak edi.

Hamjamiyat Helm-dan muayyan vaziyatlarda qanday foydalanilganini bilib olgach, biz Tillerning relizlarni boshqarish tizimi holatni saqlab qolish yoki relizlar ma'lumotlari uchun markaziy markaz sifatida ishlash uchun klaster ichidagi komponentga tayanishi shart emasligini tushundik. Buning o'rniga biz shunchaki Kubernetes API serveridan ma'lumot olishimiz, mijoz tomonida diagramma yaratishimiz va Kubernetes-da o'rnatish yozuvini saqlashimiz mumkin edi.

Tillerning asosiy maqsadiga Tillersiz erishish mumkin edi, shuning uchun Helm 3 bilan bog'liq birinchi qarorlarimizdan biri Tillerdan butunlay voz kechish edi.

Tiller ketishi bilan Helmning xavfsizlik modeli tubdan soddalashtirildi. Helm 3 hozirda joriy Kubernetesning barcha zamonaviy xavfsizlik, identifikatsiya va avtorizatsiya usullarini qo‘llab-quvvatlaydi. Helm ruxsatlari yordamida aniqlanadi kubeconfig fayli. Klaster ma'murlari foydalanuvchi huquqlarini har qanday darajali darajada cheklashlari mumkin. Relizlar hali ham klaster ichida saqlanadi va Helmning qolgan funksiyalari o'zgarmasligicha qoladi.

Diagramma omborlari

Yuqori darajada, diagramma ombori - bu grafiklarni saqlash va almashish mumkin bo'lgan joy. Helm mijozi jadvallarni paketlaydi va omborga yuboradi. Oddiy qilib aytganda, diagrammalar ombori index.yaml fayli va ba'zi paketli diagrammalarga ega bo'lgan ibtidoiy HTTP serveridir.

Eng asosiy saqlash talablariga javob beradigan Charts Repository API-ning ba'zi afzalliklari mavjud bo'lsa-da, bir qator kamchiliklar ham mavjud:

  • Grafik omborlari ishlab chiqarish muhitida talab qilinadigan ko'pgina xavfsizlik dasturlariga mos kelmaydi. Ishlab chiqarish stsenariylarida autentifikatsiya va avtorizatsiya uchun standart APIga ega bo'lish juda muhimdir.
  • Grafikni imzolash, yaxlitligi va kelib chiqishini tekshirish uchun ishlatiladigan Helmning diagrammaning kelib chiqishi asboblari Chartni nashr qilish jarayonining ixtiyoriy qismidir.
  • Ko'p foydalanuvchili stsenariylarda bir xil jadval boshqa foydalanuvchi tomonidan yuklanishi mumkin, bu bir xil tarkibni saqlash uchun zarur bo'lgan joy miqdorini ikki baravar oshiradi. Ushbu muammoni hal qilish uchun aqlli omborlar ishlab chiqilgan, ammo ular rasmiy spetsifikatsiyaning bir qismi emas.
  • Metadatani qidirish, saqlash va diagrammalarni olish uchun bitta indeks faylidan foydalanish xavfsiz ko'p foydalanuvchi dasturlarini ishlab chiqishni qiyinlashtirdi.

Loyiha Docker tarqatish (Shuningdek, Docker Registry v2 nomi bilan ham tanilgan) Docker Registry vorisi bo'lib, asosan Docker tasvirlarini qadoqlash, jo'natish, saqlash va yetkazib berish uchun vositalar to'plami sifatida ishlaydi. Ko'pgina yirik bulut xizmatlari Distributionga asoslangan mahsulotlarni taklif qiladi. Ushbu ortib borayotgan e'tibor tufayli Distribution loyihasi ko'p yillik yaxshilanishlar, xavfsizlik bo'yicha ilg'or tajribalar va maydon sinovlaridan foyda ko'rdi, bu esa uni Ochiq manbalar dunyosining eng muvaffaqiyatli qahramonlaridan biriga aylantirdi.

Taqsimlash loyihasi faqat konteyner tasvirlarini emas, balki har qanday shakldagi kontentni tarqatish uchun mo'ljallanganligini bilasizmi?

Sa'y-harakatlarga rahmat Ochiq konteyner tashabbusi (yoki OCI), Helm diagrammalari har qanday Distribution misolida joylashtirilishi mumkin. Hozircha bu jarayon eksperimental hisoblanadi. To‘liq Helm 3 uchun zarur bo‘lgan tizimga kirishni qo‘llab-quvvatlash va boshqa funktsiyalar davom etmoqda, ammo biz OCI va Distribution jamoalarining yillar davomida qilgan kashfiyotlaridan o‘rganishdan xursandmiz. Va ularning murabbiyligi va yo'l-yo'riqlari orqali biz keng miqyosda yuqori darajada mavjud bo'lgan xizmatni ishlatish nimani anglatishini bilib olamiz.

Helm diagrammasi omborlarida bo'ladigan ba'zi o'zgarishlarning batafsil tavsifi mavjud aloqa.

Chiqarish boshqaruvi

Helm 3 da dastur holati klaster ichida bir juft ob'ekt tomonidan kuzatiladi:

  • chiqarish ob'ekti - dastur namunasini ifodalaydi;
  • chiqarish versiyasi siri - ma'lum bir vaqtning o'zida dasturning istalgan holatini ifodalaydi (masalan, yangi versiyani chiqarish).

Qiyinchilik helm install reliz ob'ekti va reliz versiyasi sirini yaratadi. Qo'ng'iroq qiling helm upgrade chiqarish ob'ektini talab qiladi (uni o'zgartirishi mumkin) va yangi qiymatlar va tayyorlangan manifestni o'z ichiga olgan yangi nashr versiyasi sirini yaratadi.

Release ob'ekti reliz haqida ma'lumotni o'z ichiga oladi, bu erda reliz nomli diagramma va qiymatlarning o'ziga xos o'rnatilishi. Ushbu ob'ekt nashr haqidagi yuqori darajadagi metama'lumotlarni tavsiflaydi. Chiqarish ob'ekti ilovaning butun hayoti davomida saqlanib qoladi va barcha versiyalar sirlari, shuningdek Helm diagrammasi tomonidan bevosita yaratilgan barcha ob'ektlarning egasidir.

Reliz versiyasi siri relizni bir qator tahrirlar (o'rnatish, yangilash, orqaga qaytarish, o'chirish) bilan bog'laydi.

Helm 2 da tahrirlar juda izchil edi. Qo'ng'iroq qiling helm install yaratilgan v1, keyingi yangilash (yangilash) - v2 va boshqalar. Chiqarish va chiqarish versiyasi sirlari qayta ko'rib chiqish deb nomlanuvchi yagona ob'ektga yig'ildi. Tahrirlar Tiller bilan bir xil nomlar maydonida saqlangan, bu esa har bir nashr nomlar maydoni jihatidan "global" ekanligini anglatadi; natijada ismning faqat bitta nusxasidan foydalanish mumkin edi.

Helm 3 da har bir reliz bir yoki bir nechta reliz versiyasi sirlari bilan bog'langan. Chiqarish obyekti har doim Kubernetes-ga joylashtirilgan joriy nashrni tavsiflaydi. Har bir reliz versiyasi siri ushbu nashrning faqat bitta versiyasini tavsiflaydi. Yangilanish, masalan, yangi versiya versiyasi sirini yaratadi va keyin chiqarish ob'ektini yangi versiyaga ishora qilish uchun o'zgartiradi. Orqaga qaytarilgan taqdirda, relizni oldingi holatga qaytarish uchun oldingi versiya versiyasi sirlaridan foydalanishingiz mumkin.

Tiller tark etilgandan so'ng, Helm 3 reliz ma'lumotlarini reliz bilan bir xil nomlar maydonida saqlaydi. Ushbu o'zgarish sizga bir xil reliz nomiga ega diagrammani boshqa nomlar maydoniga o'rnatish imkonini beradi va ma'lumotlar va hokazolarda klaster yangilanishlari/qayta yuklashlar orasida saqlanadi. Masalan, siz WordPress-ni "foo" nom maydoniga, keyin esa "bar" nom maydoniga o'rnatishingiz mumkin va ikkala nashr ham "wordpress" deb nomlanishi mumkin.

Diagrammaga bog'liqlikdagi o'zgarishlar

Diagrammalar to'plangan (foydalangan helm package) Helm 2 bilan foydalanish uchun Helm 3 bilan oʻrnatilishi mumkin, ammo diagrammani ishlab chiqish jarayoni toʻliq qayta koʻrib chiqilgan, shuning uchun Helm 3 bilan diagramma ishlab chiqishni davom ettirish uchun baʼzi oʻzgarishlar kiritilishi kerak. Xususan, diagrammaga bogʻliqlikni boshqarish tizimi oʻzgardi.

Diagrammaning qaramlikni boshqarish tizimi o'zgartirildi requirements.yaml и requirements.lock haqida Chart.yaml и Chart.lock. Bu buyruqni ishlatgan diagrammalar degan ma'noni anglatadi helm dependency, Helm 3 da ishlash uchun ba'zi sozlashlarni talab qiladi.

Keling, bir misolni ko'rib chiqaylik. Keling, Helm 2 da diagrammaga qaramlikni qo'shamiz va Helm 3 ga o'tishda nima o'zgarishini ko'rib chiqamiz.

Rulda 2 requirements.yaml shunday ko'rinardi:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Helm 3 da xuddi shu bog'liqlik sizda aks etadi Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Grafiklar hali ham yuklab olinadi va katalogga joylashtiriladi charts/, shuning uchun pastki diagrammalar (quyi diagrammalar), katalogda yotadi charts/, o'zgarishsiz ishlashda davom etadi.

Kutubxona jadvallari bilan tanishtirish

Helm 3 kutubxona diagrammalari deb nomlangan diagrammalar sinfini qo‘llab-quvvatlaydi (kutubxona jadvali). Ushbu diagramma boshqa diagrammalar tomonidan qo'llaniladi, lekin o'z-o'zidan hech qanday reliz artefaktlarini yaratmaydi. Kutubxona diagrammasi shablonlari faqat elementlarni e'lon qilishi mumkin define. Boshqa kontent shunchaki e'tiborga olinmaydi. Bu foydalanuvchilarga bir nechta diagrammalarda ishlatilishi mumkin bo'lgan kod parchalarini qayta ishlatish va almashish imkonini beradi, shu bilan takrorlanishning oldini oladi va printsipga rioya qiladi. QURUQ.

Kutubxona jadvallari bo'limda e'lon qilingan dependencies faylda Chart.yaml. Ularni o'rnatish va boshqarish boshqa jadvallardan farq qilmaydi.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Ushbu komponent diagramma ishlab chiquvchilar uchun ochiladigan foydalanish holatlari, shuningdek, kutubxona diagrammalarida paydo bo'ladigan eng yaxshi amaliyotlar bizni xursand qiladi.

Keyin nima?

Helm 3.0.0-alpha.1 biz Helmning yangi versiyasini yaratishni boshlayotgan poydevordir. Maqolada men Helm 3 ning ba'zi qiziqarli xususiyatlarini tasvirlab berdim. Ularning ko'pchiligi hali rivojlanishning dastlabki bosqichida va bu normaldir; Alfa versiyasining maqsadi g'oyani sinab ko'rish, dastlabki foydalanuvchilarning fikr-mulohazalarini to'plash va bizning taxminlarimizni tasdiqlashdir.

Alfa versiyasi chiqishi bilanoq (esda tutingki, bu allaqachon sodir bo'lgan - taxminan. tarjima.), biz jamoadan Helm 3 uchun yamoqlarni qabul qilishni boshlaymiz. Siz yangi funksiyalarni ishlab chiqish va qabul qilish imkonini beruvchi, shuningdek, foydalanuvchilar chiptalarni ochish va tuzatishlar kiritish orqali jarayonda ishtirok etishlarini his qilishlari uchun kuchli poydevor yaratishingiz kerak.

Men Helm 3-ga keladigan ba'zi muhim yaxshilanishlarni ta'kidlashga harakat qildim, ammo bu ro'yxat to'liq emas. Helm 3 uchun to'liq yo'l xaritasi takomillashtirilgan yangilash strategiyalari, OCI registrlari bilan chuqurroq integratsiya va diagramma qiymatlarini tekshirish uchun JSON sxemalaridan foydalanish kabi xususiyatlarni o'z ichiga oladi. Shuningdek, biz kodlar bazasini tozalashni va uning so'nggi uch yil davomida e'tibordan chetda qolgan qismlarini yangilashni rejalashtirmoqdamiz.

Agar biror narsani o'tkazib yuborgandek bo'lsangiz, fikringizni eshitishdan xursand bo'lamiz!

Bizning munozaraga qo'shiling Bo'shashgan kanallar:

  • #helm-users savollar va jamiyat bilan oddiy muloqot uchun;
  • #helm-dev tortish so'rovlari, kod va xatolarni muhokama qilish.

Shuningdek, payshanba kunlari soat 19:30 MSK da bizning haftalik Public Developer qo'ng'iroqlari orqali suhbatlashishingiz mumkin. Uchrashuvlar asosiy ishlab chiquvchilar va hamjamiyat ustida ishlayotgan masalalarni, shuningdek, haftalik muhokama qilinadigan mavzularni muhokama qilishga bag'ishlangan. Yig'ilishda har kim ishtirok etishi va ishtirok etishi mumkin. Havola Slack kanalida mavjud #helm-dev.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

a Izoh qo'shish