🥇3-жолдуу werf менен биригүү: Helm менен Кубернетеске “стероиддерде” жайгаштыруу

Биз (жана биз гана эмес) көптөн бери күткөн нерсе болду: werf, тиркемелерди түзүү жана аларды Kubernetesке жеткирүү үчүн биздин Ачык булак утилитабыз, эми 3 тараптуу бириктирүү патчтарын колдонуу менен өзгөртүүлөрдү киргизүүнү колдойт! Мындан тышкары, бул ресурстарды калыбына келтирбестен, учурдагы K8s ресурстарын Helm релизине кабыл алууга болот.

Эгерде ал абдан кыска болсо, анда биз койдук WERF_THREE_WAY_MERGE=enabled — биз жайгаштырууну алабыз «болжол менен kubectl apply", учурдагы Helm 2 орнотуулары менен шайкеш жана бир аз көбүрөөк.

Бирок, келгиле, теориядан баштайлы: так үч тараптуу бириктирүү патчтары деген эмне, адамдар аларды генерациялоо ыкмасын кантип ойлоп табышты жана алар эмне үчүн Kubernetes негизиндеги инфраструктурасы бар CI/CD процесстеринде маанилүү? Андан кийин, келгиле, werfте үч тараптуу бириктирүү деген эмне экенин, демейки боюнча кандай режимдер колдонуларын жана аны кантип башкарууну карап көрөлү.

3-жолдуу бириктирүү патч деген эмне?

Ошентип, келгиле, YAML манифесттеринде сүрөттөлгөн ресурстарды Kubernetesке жайылтуу тапшырмасынан баштайлы.

Ресурстар менен иштөө үчүн Kubernetes API төмөнкү негизги операцияларды сунуштайт: түзүү, оңдоо, алмаштыруу жана жок кылуу. Алардын жардамы менен ресурстардын кластерге ыңгайлуу үзгүлтүксүз жайылышын куруу зарыл деп болжолдонууда. Кантип?

kubectl императивдик буйруктар

Kubernetesтеги объекттерди башкаруунун биринчи ыкмасы бул объекттерди түзүү, өзгөртүү жана жок кылуу үчүн kubectl императивдик буйруктарын колдонуу. Жөнөкөй сөз менен айтканда:

команда kubectl run Жайгаштыруу же Жумушту иштете аласыз:
```
kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
```
команда kubectl scale — репликалардын санын өзгөртүү:
```
kubectl scale --replicas=3 deployment/mysql
```
жана башкалар.

Бул ыкма биринчи караганда ыңгайлуу көрүнүшү мүмкүн. Бирок көйгөйлөр бар:

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

Бул ыкма тиркемени жана инфраструктураны код катары сактоого туура келбей турганы түшүнүктүү (IaC же ал тургай GitOps заманбап вариант катары, Kubernetes экосистемасында популярдуулукка ээ болуу). Ошондуктан, бул буйруктар kubectl андан ары өнүктүрүүнү алган жок.

Операцияларды түзүү, алуу, алмаштыруу жана жок кылуу

Баштапкы менен түзүү бул жөнөкөй: манифестти операцияга жөнөтүү create кубе api жана ресурс тузулду. Манифесттин YAML өкүлчүлүгү Gitте сакталып, буйруктун жардамы менен түзүлүшү мүмкүн kubectl create -f manifest.yaml.

С жок кылуу ошондой эле жөнөкөй: ошол эле алмаштыруу manifest.yaml Гиттен командага kubectl delete -f manifest.yaml.

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

Конфигурацияны Gitте сактоо жана алмаштырууну колдонуу менен жаңыртуу үчүн операцияны аткарышыңыз керек get, Gitтен конфигурацияны биз алган нерсе менен бириктирип, аткарыңыз replace. Демейки боюнча, kubectl сизге буйрукту колдонууга гана мүмкүнчүлүк берет kubectl replace -f manifest.yamlкайда manifest.yaml — толук даярдалган (биздин учурда бириктирилген) манифест, аны орнотуу керек. Көрсө, колдонуучу бириктирүү манифесттерин ишке ашырышы керек экен, бул майда-чүйдө маселе эмес...

Ошондой болсо да белгилей кетуу керек manifest.yaml жана Gitде сакталгандыктан, объектти түзүү же аны жаңыртуу керекпи же жокпу, биз алдын ала биле албайбыз - бул колдонуучунун программалык камсыздоосу тарабынан жасалышы керек.

Бардыгы: үзгүлтүксүз жайылтуу кура алабыз түзүү, алмаштыруу жана жок кылууну колдонуу менен инфраструктуранын конфигурациясынын Gitте код жана ыңгайлуу CI/CD менен бирге сакталышын камсыз кылуу керекпи?

Принцибинде биз... Бул учун бириктирүү операциясын ишке ашыруу керек болот манифесттер жана кандайдыр бир милдеттүү түрдө:

кластердеги объекттин болушун текшерет,
баштапкы ресурстарды түзүүнү жүзөгө ашырат,
жаңыртат же жок кылат.

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

Бирок, kube-apiserver ресурстарды жаңыртуунун башка жолун сунуш кылганда, эмне үчүн дөңгөлөктү кайра ойлоп табуу керек: операция patch, бул колдонуучуну сүрөттөлгөн көйгөйлөрдүн айрымдарынан бошотот?

жамаачы

Эми биз тактарга барабыз.

Патчтар Kubernetes'теги учурдагы объекттерге өзгөртүүлөрдү киргизүүнүн негизги жолу. Операция patch ал мындай иштейт:

kube-apiserver колдонуучусу JSON формасында патч жөнөтүп, объектти көрсөтүшү керек,
жана apiserver өзү объекттин учурдагы абалы менен алектенет жана аны керектүү формага келтирет.

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

Ошентип:

операцияны колдонуу create биз Гиттен манифестке ылайык объект түзөбүз,
жардамы менен delete — объекттин кереги жок болсо, жок кылуу;
жардамы менен patch — биз объектти Гитте сүрөттөлгөн формага келтирип өзгөртөбүз.

Бирок, бул үчүн, сиз түзүү керек туура патч!

Helm 2де патчтар кантип иштейт: 2-жолдуу бириктирүү

Чыгарууну биринчи жолу орнотконуңузда, Helm операцияны аткарат create диаграмма ресурстар үчүн.

Ар бир ресурс үчүн Helm чыгарууну жаңыртууда:

мурунку диаграммадагы ресурстук версия менен учурдагы диаграмма версиясынын ортосундагы патчты карайт,
бул патчты колдонот.

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

мурунку релиздеги ресурс манифести,
учурдагы ресурстун манифести.

Операцияны алып салганда delete kube apiserver мурунку релизде жарыяланган, бирок азыркы версияда жарыяланбаган ресурстар үчүн чакырылат.

2 жолду бириктирүү патч ыкмасы көйгөй бар: ал алып келет кластердеги ресурстун чыныгы абалына жана Гиттеги манифестке шайкеш келбейт.

Мисал менен маселенин иллюстрациясы

Гитте диаграмма талаа жайгашкан манифестти сактайт image Жайгаштыруу маанилүү ubuntu:18.04.
Колдонуучу аркылуу kubectl edit бул талаанын маанисин өзгөрттү ubuntu:19.04.
Helm диаграммасын кайра жайылтууда патч жаратпайт, анткени талаа image релиздин мурунку версиясында жана учурдагы диаграммада бирдей.
кайра жайгаштыруу кийин image калдыктар ubuntu:19.04, бирок диаграммада айтылган ubuntu:18.04.

Бизде синхронизация болуп, декларативдик жоголду.

Шайкештештирилген ресурс деген эмне?

Жалпылап айтканда, толук Иштеп жаткан кластердеги ресурс манифести менен Гиттен манифесттин ортосунда дал келүү мүмкүн эмес. Анткени реалдуу манифестте сервистик аннотациялар/белгилер, кошумча контейнерлер жана башка маалыматтар болушу мүмкүн, алар кээ бир контроллерлор тарабынан динамикалык түрдө ресурска кошулуп, алынып салынат. Биз бул маалыматтарды Гитте сактай албайбыз жана каалабайбыз. Бирок, биз Gitте ачык көрсөткөн талаалар жайылгандан кийин тиешелүү маанилерди алышын каалайбыз.

Бул ушунчалык жалпы болуп чыгат синхрондуу ресурс эрежеси: ресурсту чыгарууда, сиз Gitтен манифестте ачык көрсөтүлгөн талааларды гана өзгөртө аласыз же жок кыла аласыз (же мурунку версияда көрсөтүлгөн жана азыр жок кылынган).

3 тараптуу бириктирүү патч

борбордук идея 3 тараптуу бириктирүү патч: иштеп жаткан кластерден манифесттин учурдагы версиясын эске алуу менен Git'тен манифесттин акыркы колдонулган версиясы менен Git'тен манифесттин максаттуу версиясынын ортосунда патч түзүңүз. Натыйжадагы патч шайкештештирилген ресурс эрежесине ылайык келиши керек:

максаттуу версияга кошулган жаңы талаалар патч аркылуу кошулат;
акыркы колдонулган версияда мурда болгон жана максаттуу версияда жок талаалар патч аркылуу баштапкы абалга келтирилет;
манифесттин максаттуу версиясынан айырмаланган объекттин учурдагы версиясындагы талаалар патчтын жардамы менен жаңыланат.

Дал ушул принцип боюнча ал тактарды жаратат kubectl apply:

манифесттин акыркы колдонулган версиясы объекттин аннотациясында сакталат,
максаттуу - көрсөтүлгөн YAML файлынан алынган,
учурдагысы иштеп жаткан кластерден.

Эми биз теорияны иргеп алгандан кийин, биз werfте эмне кылганыбызды айтып берүүгө убакыт келди.

werfке өзгөртүүлөр колдонулууда

Мурда Helm 2 сыяктуу werf эки тараптуу бириктирүү патчтарын колдонгон.

Оңдоо патч

Жаңы типтеги патчтарга өтүү үчүн - 3-жолдуу бириктирүү - биз биринчи кадам деп аталган нерсени киргиздик. оңдоо тактар.

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

Эгерде десинхронизация болуп кетсе, жайылтуунун аягында колдонуучу тиешелүү билдирүү менен ЭСКЕРТҮҮнү алат жана бул ресурсту синхрондоштурулган формага алып келүү үчүн колдонулушу керек. Бул жама атайын аннотацияда да жазылган werf.io/repair-patch. Колдонуучунун колу деп болжолдонууда сам бул патчты колдонот: werf аны такыр колдонбойт.

Оңдоо патчтарын түзүү - бул 3 жолду бириктирүү принцибинин негизинде тактарды түзүүнү чындыгында сынап көрүүгө мүмкүндүк берген убактылуу чара, бирок бул тактарды автоматтык түрдө колдонбойт. Учурда бул иштөө режими демейки боюнча иштетилген.

Жаңы чыгарылыштар үчүн гана 3-жолдуу бириктирүү патч

1-жылдын 2019-декабрынан баштап werfтин бета жана альфа версиялары башталат демейки боюнча Өзгөртүүлөрдү werf аркылуу чыгарылган жаңы Helm релиздерине гана колдонуу үчүн толук кандуу 3 тараптуу бириктирүү патчтарын колдонуңуз. Учурдагы релиздер эки тараптуу бириктирүү + оңдоо тактары ыкмасын колдоно беришет.

Бул иштөө режимин орнотуу менен ачык иштетсе болот WERF_THREE_WAY_MERGE_MODE=onlyNewReleases азыр.

пикир: өзгөчөлүк werfте бир нече чыгарылыштарда пайда болгон: альфа каналында ал версияга даяр болуп калды v1.0.5-alpha.19, жана бета каналында - менен v1.0.4-beta.20.

Бардык чыгарылыштар үчүн 3 жолду бириктирүү патч

15-жылдын 2019-декабрынан баштап werfтин бета жана альфа версиялары бардык релиздерге өзгөртүүлөрдү киргизүү үчүн демейки боюнча толук үч тараптуу бириктирүү патчтарын колдоно баштайт.

Бул иштөө режимин орнотуу менен ачык иштетсе болот WERF_THREE_WAY_MERGE_MODE=enabled азыр.

Ресурстарды автоматтык масштабдоо менен эмне кылуу керек?

Kubernetesте автоскалдаштыруунун 2 түрү бар: HPA (горизонталдуу) жана VPA (вертикалдуу).

Horizontal автоматтык түрдө репликалардын санын, вертикалдуу - ресурстардын санын тандайт. Репликалардын саны да, ресурстарга болгон талаптар да ресурс манифестинде көрсөтүлгөн (Ресурс Манифестин караңыз). spec.replicas же spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

Көйгөй: эгерде колдонуучу диаграммадагы ресурсту ресурстар үчүн белгилүү бир маанилерди көрсөткөндөй кылып конфигурацияласа же бул ресурс үчүн репликалар жана автошкалагычтар иштетилген болсо, анда ар бир жайгаштыруу менен werf бул маанилерди диаграмма манифестинде жазылганга кайтарат. .

Маселени чечүүнүн эки жолу бар. Баштоо үчүн, диаграмма манифестинде автоматтык масштабдуу маанилерди ачык көрсөтүүдөн качканыңыз жакшы. Эгерде бул параметр кандайдыр бир себептерден улам ылайыктуу болбосо (мисалы, ресурстун баштапкы чектерин жана диаграммадагы репликалардын санын коюу ыңгайлуу болгондуктан), анда werf төмөнкү аннотацияларды сунуштайт:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

Эгерде мындай аннотация бар болсо, werf ар бир жайгаштыруу боюнча тиешелүү маанилерди баштапкы абалга келтирбейт, бирок аларды ресурс алгач түзүлгөндө гана орнотот.

Көбүрөөк маалымат алуу үчүн долбоордун документтерин караңыз мбар и VPA.

3-жолдуу бириктирүү жамаачы колдонууга тыюу салуу

Колдонуучу учурда айлана-чөйрө өзгөрмөсүн колдонуу менен werfте жаңы тактарды колдонууга тыюу сала алат WERF_THREE_WAY_MERGE_MODE=disabled. Бирок, баштап 1-жылдын 2020-мартынан баштап бул тыюу мындан ары колдонулбайт. жана 3-жолдуу бириктирүү патчтарын колдонуу гана мүмкүн болот.

werf ресурстарын кабыл алуу

Үч тараптуу бириктирүү патчтары менен өзгөртүүлөрдү колдонуу ыкмасын өздөштүрүү бизге кластерде бар ресурстарды Helm релизине кабыл алуу сыяктуу функцияны дароо ишке ашырууга мүмкүндүк берди.

Helm 2де көйгөй бар: бул ресурсту нөлдөн баштап кайра жаратпай туруп, кластерде бар манифесттердин диаграммасына ресурс кошо албайсыз (караңыз. #6031, #3275). Биз werfке учурдагы ресурстарды чыгаруу үчүн кабыл алууну үйрөттүк. Бул үчүн, иштеп жаткан кластерден ресурстун учурдагы версиясына аннотацияны орнотуу керек (мисалы, kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

Эми бул ресурс диаграммада сүрөттөлүшү керек жана кийинки жолу werf ылайыктуу аталыштагы релизди жайгаштырганда, учурдагы ресурс бул релизге кабыл алынып, анын көзөмөлүндө калат. Мындан тышкары, чыгаруу үчүн ресурсту кабыл алуу процессинде, werf иштеп жаткан кластерден ресурстун учурдагы абалын диаграммада сүрөттөлгөн абалга алып келет, ошол эле 3 жолду бириктирүү патчтарын жана синхрондогон ресурс эрежесин колдонуу менен.

пикир: жөндөө WERF_THREE_WAY_MERGE_MODE ресурстардын кабыл алынышына таасир этпейт - кабыл алууда ар дайым 3-жолдуу бириктирүү патч колдонулат.

Толук маалымат - in документтер.

Жыйынтыктар жана келечектеги пландар

Бул макаладан кийин 3-жолдуу бириктирүү патчтары эмне экени жана аларга эмне үчүн келгендиги түшүнүктүү болду деп үмүттөнөм. Werf долбоорун иштеп чыгуунун практикалык көз карашынан алганда, аларды ишке ашыруу Helm сыяктуу жайгаштырууну жакшыртууга карай дагы бир кадам болду. Эми сиз Helm 2ди колдонууда көп пайда болгон конфигурацияны синхрондоштуруу көйгөйлөрүн унута аласыз. Ошол эле учурда Helm релизине жүктөлүп алынган Kubernetes ресурстарын кабыл алуунун жаңы пайдалуу функциясы кошулду.

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

Ресурстарды жаңыртуу ыкмалары жана кабыл алуу жөнүндө маалыматты да табууга болот бул документ баракчасы.

Руль 3

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

Werf, өз кезегинде, учурда Tilleri колдонуудан арылып, 3-жолдуу бириктирүүгө которулду жана кошту дагы көп, учурдагы Helm 2 орнотуулары менен шайкеш бойдон калуу менен (миграция скрипттерин аткаруунун кереги жок). Ошондуктан, werf Helm 3ке которулмайынча, werf колдонуучулары Helm 3тин Helm 2ге караганда негизги артыкчылыктарын жоготпойт (werf да аларга ээ).

Бирок, werfти Helm 3 код базасына которуу сөзсүз болот жана жакынкы келечекте болот. Кыязы, бул werf 1.1 же werf 1.2 болот (учурда werfтин негизги версиясы 1.0; werf версиялоочу түзүлүш жөнүндө көбүрөөк маалымат алуу үчүн, караңыз бул жерде). Бул убакыттын ичинде, Helm 3 турукташтыруу үчүн убакыт болот.