Helm 3 менен тааныштыруу

Эскертүү. котормо.: Үстүбүздөгү жылдын 16-майы Kubernetes - Helm үчүн пакет менеджерин өнүктүрүүдө маанилүү этап болуп саналат. Бул күнү долбоордун келечектеги негизги версиясынын биринчи альфа-релизинин бет ачары болду - 3.0. Анын чыгышы Helmге олуттуу жана көптөн күткөн өзгөрүүлөрдү алып келет, буга Kubernetes коомчулугунда көптөр үмүт артып жатышат. Биз өзүбүз булардын бирибиз, анткени биз Helmди тиркемени жайылтуу үчүн жигердүү колдонобуз: биз аны CI/CDди ишке ашыруу үчүн куралыбызга бириктирдик. werf жана мезгил-мезгили менен биз жогорку агымдын өнүгүшүнө өз салымыбызды кошобуз. Бул котормо Helm 7-тун биринчи альфа-релизине арналган жана долбоордун тарыхы жана Helm 3тин негизги өзгөчөлүктөрү жөнүндө сөз болгон расмий Helm блогунун 3 эскертүүсүн бириктирет. Алардын автору Мэтт “баконгоблер” Фишер, Microsoft кызматкери. жана Helm негизги колдоочулардын бири.

15-жылдын 2015-октябрында азыр Хельм деп аталган долбоор пайда болгон. Түзүлгөндөн бир жыл өткөндөн кийин, Helm коомчулугу Helm 2де жигердүү иштеп жатып, Kubernetesке кошулду. 2018-жылдын июнь айында Helm CNCF кошулду иштеп чыгуучу (инкубациялоочу) долбоор катары. Учурдагы тез алдыга умтулуңуз жана жаңы Helm 3тин биринчи альфа-релизи келе жатат. (бул чыгарылыш буга чейин орун алган май айынын ортосунда - болжол менен. котормо.).

Бул макалада мен мунун баары кайдан башталган, кандайча бүгүнкү абалга жеткенибиз жөнүндө сүйлөшөм, Helm 3тун биринчи альфа-релизинде бар болгон уникалдуу функциялардын айрымдары менен тааныштырам жана кантип алдыга жылууну пландап жатканыбызды түшүндүрөм.

Кыскача мазмууну:

• Хелмдин жаралуу тарыхы;
• Тиллер менен коштошуу;
• диаграмма репозиторийлери;
• бошотуу башкаруу;
• диаграммада көз карандылыктын өзгөрүшү;
• китепкана диаграммалары;
• кийинкиси эмне?

Helm тарыхы

туулган

Helm 1 Deis тарабынан түзүлгөн Open Source долбоору катары башталган. Биз кичинекей стартап болчубуз сиңирилген Microsoft 2017-жылдын жазында. Биздин башка Open Source долбоорубуз, ошондой эле Деис деп аталган, куралы бар болчу deisctl, ал Deis платформасын орнотуу жана иштетүү үчүн (башка нерселер менен бирге) колдонулган Флот кластери. Ошол учурда, Fleet биринчи контейнер оркестрдик аянтчалардын бири болгон.

2015-жылдын орто ченинде биз багытты өзгөртүүнү чечтик жана Дейсти (ошол кезде Deis Workflow деп өзгөртүлгөн) Флоттон Кубернетеске көчүрдүк. Биринчилерден болуп кайра конструкцияланган орнотуу куралы болгон. deisctl. Биз аны Fleet кластеринде Deis Workflow орнотуу жана башкаруу үчүн колдондук.

Helm 1 Homebrew, apt жана yum сыяктуу атактуу пакет менеджерлеринин образында түзүлгөн. Анын негизги максаты Кубернетеске тиркемелерди таңгактоо жана орнотуу сыяктуу милдеттерди жөнөкөйлөтүү болгон. Helm расмий түрдө 2015-жылы Сан-Францискодогу KubeCon конференциясында киргизилген.

Helm менен болгон биринчи аракетибиз ийгиликтүү болду, бирок бул олуттуу чектөөлөрсүз болгон жок. Ал киришүү YAML блоктору катары генераторлор менен даамдалган Кубернетес манифесттеринин топтомун алды. (алдынкы маселе)*, жана натыйжаларды Kubernetesке жүктөдү.

* Эскертүү. котормо.: Helmдин биринчи версиясынан Kubernetes ресурстарын сүрөттөө үчүн YAML синтаксиси тандалган жана конфигурацияларды жазууда Jinja шаблондору жана Python скрипттери колдоого алынган. Бул тууралуу жана жалпысынан Helmдин биринчи версиясынын түзүлүшү жөнүндө «Хелмдин кыскача тарыхы» бөлүмүндө кененирээк жазганбыз. бул материал.

Мисалы, YAML файлындагы талааны алмаштыруу үчүн, манифестке төмөнкү конструкцияны кошушуңуз керек болчу:

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

Шаблон кыймылдаткычтары бүгүн бар экени абдан жакшы, туурабы?

Көптөгөн себептерден улам, бул алгачкы Kubernetes орнотуучусу манифест файлдарынын катуу коддолгон тизмесин талап кылды жана окуялардын кичинекей, белгиленген ырааттуулугун гана аткарды. Колдонуу ушунчалык кыйын болгондуктан, Deis Workflow R&D командасы өз продукциясын бул платформага өткөрүүгө аракет кылганда кыйынга турду - бирок идеянын үрөнү эбак эле себилген болчу. Биздин биринчи аракетибиз сонун үйрөнүү мүмкүнчүлүгү болду: биз колдонуучуларыбыз үчүн күнүмдүк көйгөйлөрдү чечкен прагматикалык куралдарды түзүүгө чындап дилгир экенибизди түшүндүк.

Өткөн каталардын тажрыйбасына таянып, биз Helm 2ди иштеп чыга баштадык.

Руль жасоо 2

2015-жылдын аягында Google командасы биз менен байланышты. Алар Kubernetes үчүн ушундай куралдын үстүндө иштеп жатышкан. Kubernetes үчүн Deployment Manager Google Cloud Platform үчүн колдонулган учурдагы куралдын порту болгон. "Биз, - деп сурашты алар, - окшоштуктарды жана айырмачылыктарды талкуулоо үчүн бир нече күн өткөрүүнү каалайбызбы?"

2016-жылдын январь айында Руль жана Жайгаштыруу Менеджеринин командалары Сиэтл шаарында пикир алмашуу үчүн жолугушкан. Сүйлөшүүлөр амбициялуу план менен аяктады: эки долбоорду тең бириктирип Helm 2. Дейс жана Google менен бирге, SkippBox (азыр Bitnami бөлүгү - болжол менен котормо.), жана биз Helm 2де иштей баштадык.

Биз Helm колдонуунун ыңгайлуулугун сактап калгыбыз келди, бирок төмөнкүлөрдү кошуңуз:

• ыңгайлаштыруу үчүн диаграмма шаблондору;
• командалар үчүн кластердик башкаруу;
• дүйнөлүк класстагы диаграмма репозиторий;
• кол опциясы менен туруктуу пакет форматы;
• семантикалык версиялоо жана версиялар ортосундагы артка шайкештикти сактоо боюнча күчтүү милдеттенме.

Бул максаттарга жетүү үчүн Helm экосистемасына экинчи элемент кошулду. Бул кластер ичиндеги компонент Tiller деп аталып, Helm диаграммаларын орнотуу жана аларды башкаруу үчүн жооптуу болгон.

2-жылы Helm 2016 чыккандан бери, Kubernetes бир нече негизги инновацияларды кошту. Ролдун негизинде кирүү башкаруусу кошулду (RBAC), ал акырында Атрибутка негизделген мүмкүндүктү башкарууну (ABAC) алмаштырды. Ресурстун жаңы түрлөрү киргизилген (Орнотуулар ал кезде дагы бета версиясында болчу). Ыңгайлаштырылган ресурстардын аныктамалары (башында Үчүнчү Тарап Ресурстары же TPR деп аталат) ойлоп табылган. Эң негизгиси, алдыңкы тажрыйбанын комплекси пайда болду.

Бардык ушул өзгөрүүлөрдүн арасында, Helm Kubernetes колдонуучуларына ишенимдүү кызмат кылууну улантты. Үч жылдан жана көптөгөн жаңы толуктоолордон кийин, Helm өнүгүп жаткан экосистеманын өсүп жаткан муктаждыктарын канааттандырууну камсыз кылуу үчүн код базасына олуттуу өзгөртүүлөрдү киргизүүгө убакыт келгени анык болду.

Тиллер менен коштошуу

Helm 2ди иштеп чыгуу учурунда биз Google'дун Deployment Manager менен интеграциясынын бир бөлүгү катары Tilleri киргиздик. Tiller жалпы кластердин ичинде иштеген командалар үчүн маанилүү ролду ойногон: ал инфраструктураны башкарган ар кандай адистерге бир эле чыгарылыш топтому менен иштешүүгө мүмкүндүк берди.

Ролдун негизинде кирүү башкаруусу (RBAC) Kubernetes 1.6 демейки боюнча иштетилгендиктен, өндүрүштө Tiller менен иштөө кыйындады. Мүмкүн болгон коопсуздук саясаттарынын көптүгүнө байланыштуу, биздин позициябыз демейки боюнча уруксат берүүчү конфигурацияны сунуштоо болду. Бул жаңы келгендерге коопсуздук жөндөөлөрүнө кирбестен Helm жана Kubernetes менен эксперимент жүргүзүүгө мүмкүндүк берди. Тилекке каршы, бул уруксат конфигурациясы колдонуучуга алар кереги жок уруксаттардын өтө кеңири спектрин бериши мүмкүн. DevOps жана SRE инженерлери көп ижарачылардын кластеринде Tilleri орнотууда кошумча операциялык кадамдарды үйрөнүшү керек болчу.

Коомчулуктун Helmди конкреттүү кырдаалдарда кантип колдонгонун билгенден кийин, биз Тиллердин релизди башкаруу тутуму абалды сактоо үчүн же релиз маалыматы үчүн борбордук борбор катары иштеши үчүн кластер ичиндеги компонентке таянуунун кереги жок экенин түшүндүк. Анын ордуна, биз жөн гана Kubernetes API серверинен маалымат алып, кардар тарабында диаграмма түзө алабыз жана Kubernetes'те орнотуунун жазуусун сактай алабыз.

Тиллердин негизги максатына Тиллерсиз жетсе болмок, ошондуктан Helm 3 боюнча биздин биринчи чечимдерибиздин бири Тиллерден толугу менен баш тартуу болду.

Тиллер кеткенден кийин, Helm коопсуздук модели түп-тамырынан бери жөнөкөйлөтүлгөн. Helm 3 азыр учурдагы Kubernetesтин бардык заманбап коопсуздук, идентификация жана авторизация ыкмаларын колдойт. Helm уруксаттар аркылуу аныкталат kubeconfig файлы. Кластердин администраторлору колдонуучунун укуктарын каалаган деңгээлге чейин чектей алышат. Релиздер дагы эле кластердин ичинде сакталат, ал эми Helm функцияларынын калган бөлүгү бузулбай калат.

Диаграмма репозиторийлери

Жогорку деңгээлде, диаграмма репозиторий - бул диаграммаларды сактоого жана бөлүшүүгө болот. Helm кардары диаграммаларды топтойт жана репозиторийге жөнөтөт. Жөнөкөй сөз менен айтканда, диаграммалар репозиторий index.yaml файлы жана кээ бир пакеттелген диаграммалары бар примитивдүү HTTP сервери.

Эң негизги сактоо талаптарына жооп берген Charts Repository API'нин кээ бир артыкчылыктары бар, бирок бир нече кемчиликтери бар:

• Диаграмма репозиторийлери өндүрүш чөйрөсүндө талап кылынган көпчүлүк коопсуздукту ишке ашыруу менен шайкеш келбейт. Аутентификация жана авторизация үчүн стандарттуу API'ге ээ болуу өндүрүш сценарийлеринде өтө маанилүү.
• Диаграммага кол коюу, бүтүндүгүн жана келип чыгышын текшерүү үчүн колдонулган Helm's диаграмма инструменттери Диаграмманы жарыялоо процессинин кошумча бөлүгү болуп саналат.
• Көп колдонуучу сценарийинде бир эле диаграмманы башка колдонуучу жүктөй алат, бул бир эле мазмунду сактоо үчүн талап кылынган мейкиндиктин көлөмүн эки эсеге көбөйтөт. Бул көйгөйдү чечүү үчүн акылдуу репозиторийлер иштелип чыккан, бирок алар расмий спецификациянын бир бөлүгү эмес.
• Издөө, метаберилиштерди сактоо жана диаграммаларды алуу үчүн бир индекс файлын колдонуу коопсуз көп колдонуучу ишке ашырууларды иштеп чыгууну кыйындаткан.

долбоору Docker Distribution (Ошондой эле Docker Registry v2 катары белгилүү) Docker Реестринин мураскери болуп саналат жана негизинен Docker сүрөттөрүн таңгактоо, жеткирүү, сактоо жана жеткирүү үчүн куралдардын жыйындысы катары иштейт. Көптөгөн чоң булут кызматтары бөлүштүрүүгө негизделген өнүмдөрдү сунуштайт. Бул көбөйгөн көңүлдүн аркасында Бөлүштүрүү долбоору көп жылдык өркүндөтүүлөрдөн, коопсуздуктун мыкты тажрыйбаларынан жана талаа сыноолорунан пайда алып, аны Ачык Булак дүйнөсүнүн эң ийгиликтүү көрүнбөгөн каармандарынын бирине айлантты.

Бирок сиз бөлүштүрүү долбоору жөн гана контейнер сүрөттөрүн эмес, ар кандай формадагы мазмунду жайылтуу үчүн иштелип чыкканын билесизби?

Аракеттерге рахмат Ачык контейнер демилгеси (же OCI), Helm диаграммалары каалаган Distribution инстанциясында жайгаштырылышы мүмкүн. Азырынча бул процесс эксперименталдык. Толук Helm 3 үчүн зарыл болгон кирүү колдоо жана башка функциялар аткарылып жаткан иш, бирок биз OCI жана Distribution топторунун жылдар бою жасаган ачылыштарынан үйрөнүүгө кубанычтабыз. Жана алардын насаатчылыгы жана жетекчилиги аркылуу биз жогорку деңгээлдеги жеткиликтүү кызматты иштетүү кандай экенин билебиз.

Helm диаграмма репозиторийлерине боло турган кээ бир өзгөрүүлөрдүн кеңири сүрөттөлүшү жеткиликтүү байланыш.

Чыгарууну башкаруу

Helm 3-де, колдонмонун абалы кластердин ичинде бир жуп объект аркылуу көзөмөлдөнөт:

• чыгаруу объекти - колдонмонун инстанциясын билдирет;
• релиз версиясынын сыры - белгилүү бир убакытта колдонмонун каалаган абалын көрсөтөт (мисалы, жаңы версиянын чыгышы).

чакыруу helm install чыгаруу объектисин жана релиз версиясынын сырын түзөт. Чалуу helm upgrade чыгаруу объектисин талап кылат (ал өзгөртө алат) жана жаңы баалуулуктарды жана даярдалган манифестти камтыган жаңы чыгаруу версиясынын сырын түзөт.

Чыгаруу объектиси релиз жөнүндө маалыматты камтыйт, мында релиз аталган диаграмманын жана баалуулуктардын белгилүү бир орнотуусу. Бул объект релиз жөнүндө жогорку деңгээлдеги метадайындарды сүрөттөйт. Чыгаруу объекти колдонмонун бүткүл өмүр циклинде сакталат жана релиз версиясынын бардык сырларынын, ошондой эле Helm диаграммасы тарабынан түз түзүлгөн бардык объекттердин ээси болуп саналат.

Релиз версиясынын сыры релизди бир катар оңдоолор менен байланыштырат (орнотуу, жаңыртуулар, артка кайтаруу, жок кылуу).

Helm 2де оңдоолор абдан ырааттуу болгон. Чалуу helm install түзүлгөн v1, кийинки жаңыртуу (жаңыртуу) - v2 ж.б.у.с. Чыгаруу жана чыгаруу версиясынын сыры кайра кароо деп аталган бир объектке жыйылган. Ревизиялар Tiller менен бирдей аталыш мейкиндигинде сакталган, бул ар бир релиз аттар мейкиндиги жагынан "глобалдык" экенин билдирген; Натыйжада, ысымдын бир гана нускасы колдонулушу мүмкүн.

Helm 3-те ар бир релиз бир же бир нече релиз версиясынын сырлары менен байланышкан. Чыгаруу объекти дайыма Kubernetesке жайгаштырылган учурдагы релизди сүрөттөйт. Ар бир релиз версиясынын сыры ошол релиздин бир гана версиясын сүрөттөйт. Жаңыртуу, мисалы, жаңы релиз версиясынын сырын түзүп, анан ошол жаңы версияга көрсөтүү үчүн чыгаруу объектисин өзгөртөт. Артка кайтарылган учурда, релизди мурунку абалга кайтаруу үчүн мурунку версия версиясынын сырларын колдонсоңуз болот.

Tiller таштап кеткенден кийин, Helm 3 релиз маалыматтарын релиз сыяктуу эле мейкиндикте сактайт. Бул өзгөртүү башка аттар мейкиндигинде бир эле релиз аталышы бар диаграмманы орнотууга мүмкүндүк берет жана маалымат ж.б. кластердик жаңыртуулар/кайра жүктөөлөр арасында сакталат. Мисалы, сиз WordPressти "foo" аттар мейкиндигине, анан "бар" аттар мейкиндигине орното аласыз жана эки релизди тең "wordpress" деп атоого болот.

Диаграмманын көз карандылыктарына өзгөртүүлөр

Диаграммалар топтолгон (колдонуу менен helm package) Helm 2 менен колдонуу үчүн Helm 3 менен орнотсо болот, бирок диаграмманы иштеп чыгуу процесси толугу менен оңдолду, андыктан Helm 3 менен диаграмманы иштеп чыгууну улантуу үчүн кээ бир өзгөртүүлөрдү киргизүү керек. Атап айтканда, диаграмманын көз карандылыгын башкаруу системасы өзгөрдү.

Диаграмманын көз карандылыкты башкаруу системасы андан жылды requirements.yaml и requirements.lock боюнча Chart.yaml и Chart.lock. Бул буйрукту колдонгон диаграммалар дегенди билдирет helm dependency, Helm 3те иштөө үчүн кээ бир орнотууларды талап кылат.

Келгиле, бир мисал карап көрөлү. Келгиле, Helm 2деги диаграммага көз карандылыкты кошолу жана Helm 3кө өткөндө эмне өзгөрөрүн көрөлү.

Рульде 2 requirements.yaml мындай көрүндү:

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

Helm 3, ошол эле көз карандылык сиздин чагылдырылат Chart.yaml:

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

Диаграммалар дагы эле жүктөлүп алынып, каталогго жайгаштырылат charts/, ошондуктан субдиаграммалар (кошумча диаграммалар), каталогдо жатат charts/, өзгөрүүсүз иштей берет.

Китепкана диаграммалары менен тааныштыруу

Helm 3 китепкана диаграммалары деп аталган диаграммалар классын колдойт (китепкананын диаграммасы). Бул диаграмма башка диаграммалар тарабынан колдонулат, бирок өз алдынча эч кандай чыгаруу артефакттарын түзбөйт. Китепкана диаграммасынын калыптары элементтерди гана жарыялай алат define. Башка мазмун жөн гана этибарга алынбайт. Бул колдонуучуларга бир нече диаграммаларда колдонула турган код үзүндүлөрүн кайра колдонууга жана бөлүшүүгө мүмкүндүк берет, ошону менен кайталанууга жол бербейт жана принципти карманышат. КУРГАН.

Китепкананын схемалары бөлүмдө жарыяланды dependencies файлда Chart.yaml. Аларды орнотуу жана башкаруу башка диаграммалардан эч айырмаланбайт.

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

Бул компонент диаграмманы иштеп чыгуучулар үчүн ачыла турган колдонуу учурлары, ошондой эле китепкана диаграммаларынан пайда боло турган мыкты тажрыйбалар бизди кубандырат.

Кийинкиси эмне?

Helm 3.0.0-alpha.1 биз Helm жаңы версиясын кура баштаган негиз болуп саналат. Макалада мен Helm 3 кээ бир кызыктуу өзгөчөлүктөрүн сүрөттөлгөн. Алардын көбү дагы эле өнүгүүнүн алгачкы баскычында жана бул нормалдуу көрүнүш; Альфа-релиздин максаты идеяны сынап көрүү, алгачкы колдонуучулардын пикирлерин чогултуу жана биздин божомолдорду ырастоо.

Альфа версиясы чыгаары менен (бул экенин унутпа мурунтан эле болгон — болжол менен. котормо.), биз коомчулуктан Helm 3 үчүн патчтарды кабыл ала баштайбыз. Сиз жаңы функцияларды иштеп чыгууга жана кабыл алууга, ошондой эле колдонуучулар билеттерди ачуу жана оңдоолорду киргизүү аркылуу процесске катышууга мүмкүнчүлүк берген күчтүү негиз түзүшүңүз керек.

Мен Helm 3ке келген негизги жакшыртуулардын айрымдарын баса белгилегенге аракет кылдым, бирок бул тизме толук эмес. Helm 3 үчүн толук жол картасы жакшыртылган жаңыртуу стратегиялары, OCI реестрлери менен тереңирээк интеграция жана диаграмма маанилерин текшерүү үчүн JSON схемаларын колдонуу сыяктуу функцияларды камтыйт. Ошондой эле код базасын тазалап, анын акыркы үч жылдан бери каралбай калган бөлүктөрүн жаңыртууну пландап жатабыз.

Эгер биз бир нерсени өткөрүп жибердик деп ойлосоңуз, биз сиздин оюңузду уккубуз келет!

Биздин талкууга кошулуңуз Бош каналдар:

• #helm-users суроолор жана коомчулук менен жөнөкөй байланыш үчүн;
• #helm-dev тартуу сурамдарын, кодду жана мүчүлүштүктөрдү талкуулоо.

Ошондой эле бейшемби күндөрү саат 19:30 MSKда жума сайын Коомдук Иштеп чыгуучу чалууларыбызда баарлаша аласыз. Жолугушуулар негизги иштеп чыгуучулар жана коомчулуктун үстүндө иштеп жаткан маселелерди, ошондой эле жумалык талкуулоо темаларын талкуулоого арналган. Каалоочулар чогулушка кошулуп, катыша алышат. Шилтеме Slack каналында бар #helm-dev.

Котормочудан PS

Биздин блогдон дагы окуңуз:

• «Kubernetes үчүн пакет менеджери - Helm: өткөн, азыркы, келечек";
• «Helm 2ге сергек карап: "Бул эмне..."";
• «Kubernetes үчүн пакет менеджерине практикалык киришүү - Helm";
• «Kubernetes кеңештери жана амалдары: кластерде иштеген ресурстарды Helm 2 башкаруусуна өткөрүп берүү";
• «Дапп менен машыгыңыз. 2-бөлүк. Helm жардамы менен Docker сүрөттөрүн Kubernetesке жайылтуу«.

Source: www.habr.com