🥇3 жақты werf біріктіру: Helm көмегімен Кубернетеске «стероидтарда» орналастыру

Біз (тек біз ғана емес) көптен күткен нәрсе болды: верф, қолданбаларды құруға және оларды Kubernetes-ке жеткізуге арналған ашық бастапқы қызметтік бағдарламамыз енді 3 жақты біріктіру патчтары арқылы өзгертулерді қолдануды қолдайды! Бұған қоса, бұл ресурстарды қайта құрмай-ақ, бар K8s ресурстарын Helm шығарылымдарына қабылдауға болады.

Егер ол өте қысқа болса, біз қоямыз WERF_THREE_WAY_MERGE=enabled — біздегідей орналастыруды аламыз kubectl apply", бұрыннан бар Helm 2 қондырғыларымен үйлесімді және одан да көп.

Бірақ теориядан бастайық: 3 жақты біріктіру патчтары дегеніміз не, адамдар оларды құру тәсілін қалай ойлап тапты және олар Кубернетес негізіндегі инфрақұрылымы бар CI/CD процестерінде неге маңызды? Осыдан кейін werf-те үш жақты біріктірудің не екенін, әдепкі бойынша қандай режимдер пайдаланылатынын және оны қалай басқаруға болатынын көрейік.

3 жақты біріктіру патч дегеніміз не?

Сонымен, YAML манифестінде сипатталған ресурстарды Кубернетеске шығару тапсырмасынан бастайық.

Ресурстармен жұмыс істеу үшін 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 kube 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-те сақталады, біз нысанды жасау немесе оны жаңарту қажет екенін алдын ала біле алмаймыз - бұл пайдаланушы бағдарламалық жасақтамасы арқылы орындалуы керек.

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

Негізінде біз... Бұл үшін біріктіру операциясын орындау қажет болады манифесттер және қандай да бір байланыстыру:

кластердегі нысанның болуын тексереді,
бастапқы ресурстарды құруды жүзеге асырады,
оны жаңартады немесе жояды.

Жаңарту кезінде мынаны ескеріңіз ресурс өзгерген болуы мүмкін соңғы уақыттан бері get және оптимистік құлыптау жағдайын автоматты түрде өңдеңіз - қайталап жаңарту әрекеттерін жасаңыз.

Дегенмен, kube-apiserver ресурстарды жаңартудың басқа әдісін ұсынса, неге дөңгелекті қайта ойлап табу керек: операция patch, бұл пайдаланушыны сипатталған мәселелердің кейбірінен босатады?

жамау

Енді патчтарға келеміз.

Патчтар Kubernetes ішіндегі бар нысандарға өзгертулерді қолданудың негізгі жолы болып табылады. Операция patch ол келесідей жұмыс істейді:

kube-apiserver пайдаланушысы JSON пішінінде патч жіберуі және нысанды көрсетуі керек,
және аписервердің өзі объектінің ағымдағы күйімен айналысады және оны қажетті пішінге келтіреді.

Бұл жағдайда оптимистік құлыптау қажет емес. Бұл операция ауыстырудан гөрі декларативті болып табылады, бірақ бастапқыда ол басқаша көрінуі мүмкін.

Осылайша:

операцияны қолдану create біз Git-тен манифестке сәйкес нысан жасаймыз,
көмегімен delete — объект қажет болмаса, жою;
көмегімен patch — объектіні Git-те сипатталған пішінге келтіре отырып, өзгертеміз.

Дегенмен, мұны істеу үшін сіз жасауыңыз керек дұрыс патч!

2 Helm жүйесінде патчтар қалай жұмыс істейді: 2 жақты біріктіру

Шығарылымды бірінші рет орнатқан кезде Helm операцияны орындайды create диаграмма ресурстары үшін.

Әрбір ресурс үшін Helm шығарылымын жаңарту кезінде:

алдыңғы диаграммадағы ресурс нұсқасы мен ағымдағы диаграмма нұсқасы арасындағы патчты қарастырады,
осы патчты қолданады.

Біз бұл патч деп атаймыз 2 жақты біріктіру патч, өйткені оны жасауға 2 манифест қатысады:

алдыңғы шығарылымдағы ресурс манифесті,
ағымдағы ресурстағы ресурс манифесті.

Операцияны жою кезінде delete kube аписервері алдыңғы шығарылымда жарияланған, бірақ ағымдағы нұсқада жарияланбаған ресурстарға шақырылады.

Екі жолды біріктіру патч тәсілінің проблемасы бар: ол әкеледі кластердегі ресурстың нақты күйімен және Git ішіндегі манифестпен синхрондалмаған.

Мәселені мысалмен көрсету

Git-те диаграмма өріс орналасқан манифестті сақтайды image Орналастыру маңызды ubuntu:18.04.
Пайдаланушы арқылы kubectl edit осы өрістің мәнін өзгертті ubuntu:19.04.
Helm диаграммасын қайта орналастыру кезінде патч жасамайды, өйткені өріс image шығарылымның алдыңғы нұсқасында және ағымдағы диаграммада бірдей.
Қайта орналастырудан кейін image суйек ubuntu:19.04, дегенмен диаграммада айтылған ubuntu:18.04.

Біз десинхронизацияға ие болдық және декларативтілікті жоғалттық.

Синхрондалған ресурс дегеніміз не?

Жалпы айтқанда, аяқталды Іске қосылған кластердегі ресурс манифесті мен Git манифесті арасындағы сәйкестікті алу мүмкін емес. Өйткені нақты манифестте кейбір контроллерлер динамикалық түрде ресурсқа қосылатын және жойылатын сервистік аннотациялар/белгілер, қосымша контейнерлер және басқа деректер болуы мүмкін. Біз бұл деректерді Git-те сақтай алмаймыз және қаламаймыз. Дегенмен, біз Git-те нақты көрсеткен өрістер шығарылған кезде сәйкес мәндерді алуын қалаймыз.

Бұл өте жалпы болып шығады синхрондалған ресурс ережесі: ресурсты шығару кезінде Git-тен манифестте нақты көрсетілген (немесе алдыңғы нұсқада көрсетілген және қазір жойылған) өрістерді ғана өзгертуге немесе жоюға болады.

3 жақты біріктіру патч

Негізгі идея 3 жақты біріктіру патч: біз Git-тен манифесттің соңғы қолданылған нұсқасы мен Git-тен манифесттің мақсатты нұсқасы арасында іске қосылған кластерден манифесттің ағымдағы нұсқасын ескере отырып, патч жасаймыз. Алынған патч синхрондалған ресурс ережесіне сәйкес болуы керек:

мақсатты нұсқаға қосылған жаңа өрістер патч арқылы қосылады;
соңғы қолданылған нұсқада бұрын бар және мақсатты нұсқада жоқ өрістер патч арқылы қалпына келтіріледі;
манифесттің мақсатты нұсқасынан ерекшеленетін нысанның ағымдағы нұсқасындағы өрістер патч арқылы жаңартылады.

Дәл осы принцип бойынша ол патчтарды жасайды kubectl apply:

манифесттің соңғы қолданылған нұсқасы нысанның аннотациясында сақталады,
мақсат - көрсетілген YAML файлынан алынған,
ағымдағы кластерден алынған.

Енді біз теорияны сұрыптағаннан кейін, сізге Верфте не істегенімізді айтатын уақыт келді.

werf жүйесіне өзгертулер қолдану

Бұрын werf, Helm 2 сияқты, екі жақты біріктіру патчтарын пайдаланды.

Жөндеу патч

Патчтардың жаңа түріне - 3 жақты біріктіруге көшу үшін біз бірінші қадам деп аталатындарды енгіздік. жөндеу патчтары.

Орналастыру кезінде стандартты екі жақты біріктіру патч пайдаланылады, бірақ werf қосымша ресурстың нақты күйін Git-те жазылғанмен синхрондайтын патчты жасайды (мұндай патч жоғарыда сипатталған бірдей синхрондалған ресурс ережесі арқылы жасалады) .

Синхрондау орын алса, қолданудың соңында пайдаланушы тиісті хабарламасы бар ЕСКЕРТУ және ресурсты синхрондалған пішінге келтіру үшін қолданылуы керек патч алады. Бұл патч арнайы аннотацияда да жазылған werf.io/repair-patch. Пайдаланушының қолдары деп болжанады сам бұл патчты қолданады: werf оны мүлде қолданбайды.

Жөндеу патчтарын жасау - 3 жақты біріктіру принципіне негізделген патчтарды жасауды нақты тексеруге мүмкіндік беретін уақытша шара, бірақ бұл патчтарды автоматты түрде қолданбайды. Қазіргі уақытта бұл жұмыс режимі әдепкі бойынша қосылған.

3 жақты біріктіру патч тек жаңа шығарылымдарға арналған

1 жылдың 2019 желтоқсанынан бастап werf-тің бета және альфа нұсқалары басталады әдепкі бойынша өзгертулерді тек werf арқылы шығарылған жаңа Helm шығарылымдарына қолдану үшін толыққанды 3 жақты біріктіру патчтарын пайдаланыңыз. Қолданыстағы шығарылымдар 2 жақты біріктіру + жөндеу патчтары әдісін пайдалануды жалғастырады.

Бұл жұмыс режимін орнату арқылы анық қосуға болады WERF_THREE_WAY_MERGE_MODE=onlyNewReleases қазір.

ескерту: мүмкіндік werf-те бірнеше шығарылымдарда пайда болды: альфа арнасында ол нұсқамен дайын болды v1.0.5-alpha.19, ал бета арнасында - бірге v1.0.4-бета.20.

Барлық шығарылымдар үшін 3 жақты біріктіру патч

15 жылдың 2019 желтоқсанынан бастап werf бағдарламасының бета және альфа нұсқалары барлық шығарылымдарға өзгертулерді қолдану үшін әдепкі бойынша толық 3 жақты біріктіру патчтарын пайдалана бастайды.

Бұл жұмыс режимін орнату арқылы анық қосуға болады WERF_THREE_WAY_MERGE_MODE=enabled қазір.

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

Kubernetes-те автоматты масштабтаудың 2 түрі бар: HPA (көлденең) және VPA (тік).

Көлденең көшірмелердің санын, тік - ресурстардың санын автоматты түрде таңдайды. Көшірмелердің саны да, ресурс талаптары да ресурс манифестінде көрсетілген (Ресурс манифестін қараңыз). 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 әрбір орналастырудағы сәйкес мәндерді қалпына келтірмейді, бірақ оларды ресурс бастапқыда жасалған кезде ғана орнатады.

Қосымша мәліметтер алу үшін жобалық құжаттаманы қараңыз HPA и VPA.

3 жақты біріктіру патчын пайдалануға тыйым салыңыз

Пайдаланушы қазіргі уақытта орта айнымалы мәнін пайдаланып werf жүйесінде жаңа патчтарды пайдалануға тыйым сала алады WERF_THREE_WAY_MERGE_MODE=disabled. Дегенмен, бастау 1 жылдың 2020 наурызынан бастап бұл тыйым енді қолданылмайды. және тек 3 жақты біріктіру патчтарын пайдалану мүмкін болады.

werf-тегі ресурстарды қабылдау

3 жақты біріктіру патчтары бар өзгертулерді қолдану әдісін меңгеру бізге кластерде бар ресурстарды 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 жақты біріктіру патч әрқашан қолданылады.

Толық мәліметтер - в құжаттама.

Қорытынды және алдағы жоспарлар

Осы мақаладан кейін 3 жақты біріктіру патчтары деген не және олар неге келгені түсінікті болды деп үміттенемін. Верф жобасын әзірлеудің практикалық тұрғысынан оларды іске асыру Helm тәрізді орналастыруды жақсарту жолындағы тағы бір қадам болды. Енді Helm 2-ні пайдалану кезінде жиі туындайтын конфигурацияны синхрондау мәселелерін ұмытуға болады. Сонымен бірге Helm шығарылымына жүктеп алынған Kubernetes ресурстарын қабылдаудың жаңа пайдалы мүмкіндігі қосылды.

Go үлгілерін пайдалану сияқты Helm тәрізді орналастыруларда әлі де кейбір мәселелер мен қиындықтар бар, біз оларды шешуді жалғастырамыз.

Ресурстарды жаңарту әдістері және қабылдау туралы ақпаратты мына жерден табуға болады бұл құжаттама беті.

Руль 3

Ерекше атап өтуге тұрарлық босатылған жақында ғана Helm жаңа негізгі нұсқасы - v3 - ол сонымен қатар 3 жақты біріктіру патчтарын пайдаланады және Tiller-тен құтылады. Helm жаңа нұсқасы қажет көші-қон бар орнатуларды жаңа шығарылым сақтау пішіміне түрлендіру үшін.

Werf, өз кезегінде, қазіргі уақытта Tiller пайдаланудан құтылды, 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 тұрақтануға уақыт алады.

PS

Біздің блогта да оқыңыз:

werf-тегі инновациялар туралы ескертулер сериясы:
«werf - біздің Kubernetes-тегі CI/CD құралы (шолу және бейне есеп)«;
«werf және GitLab CI көмегімен бір типті микросервистерді құрастырыңыз және орналастырыңыз«;
«Рульмен таныстыру 3«.

Ақпарат көзі: www.habr.com

werf-ке 3 жақты біріктіру: Helm көмегімен Кубернетеске «стероидтарда» орналастыру