Прим. прев.: В общността на Kubernetes става все по-популярен тренд, наречен GitOps, в което ние лично се убедихме, KubeCon Europe 2019. Този термин беше сравнително наскоро от ръководителя на компанията Weaveworks — Алексис Ричардсън — и означава прилагането на познати на разработчиците инструменти (първоначално — Git, откъдето и името) за решаване на оперативни задачи. По-конкретно, става дума за експлоатацията на Kubernetes чрез съхраняване на неговите конфигурации в Git и автоматично разразходване на промените в кластера. За двата подхода към това разразходване разказва Матийас Йг в тази статия.
Миналата година (наистина, формално това стана през август 2017 г. — бел. прев.) появи се нов подход за разполагане на приложения в Kubernetes. Той се нарича GitOps, а в основата му стои основното разбиране, че проследяването на версиите на разполаганията се извършва в безопасна среда на Git-репозитория.
Основните предимства на този подход са следните:
- Версиониране на разполаганията и история на промените. Състоянието на целия кластер се съхранява в Git-репозитория, а разполаганията се обновяват само чрез комити. Освен това всички промени могат да бъдат проследявани чрез историята на комитите.
- Връщания с помощта на познатите команди Git. Прост
git resetпозволява да се нулират промените в разполаганията; винаги са достъпни предишни състояния. - Готов контрол на достъпа. Обикновено системата Git съдържа множество конфиденциални данни, затова повечето компании обръщат особено внимание на нейното защитаване. Съответно, тази защита се разширява и върху операциите с разполаганията.
- Политики за разполагания. Повечето Git системи с времето подкрепят политики за различни клонове — например, само pull request-и могат да обновяват master, а промените трябва да бъдат проверени и приети от друг член на екипа. Както при контрола на достъпа, същите политики се прилагат и към обновленията на разполаганията.
Както виждате, методът GitOps има множество предимства. През последната година особена популярност придобиха два подхода. Единият е основан на push, а другият — на pull. Преди да ги разгледаме, нека първо видим как изглеждат типичните разполагания на Kubernetes.
Методи за разполагане
През последните години в Kubernetes се наложиха различни методи и инструменти за разполагания:
- На базата на оригинални шаблони Kubernetes/Kustomize. Това е най-простият начин за разгръщане на приложения в Kubernetes. Разработчикът създава основни YAML файлове и ги прилага. За да се избегне постоянното презаписване на едни и същи шаблони, е разработен Kustomize (който преобразува шаблони на Kubernetes в модули). Прим. прев.: Kustomize беше интегриран в kubectl с .
- Helm Charts. Helm Charts позволяват създаването на комплекти от шаблони, init контейнери, sidecar-и и др., които се прилагат за разгръщане на приложения с по-гъвкави възможности за конфигурация, отколкото при шаблонния подход. В основата на този метод са шаблонизирани YAML файлове. Helm ги запълва с различни параметри и след това ги изпраща до Tiller – компонент на клъстера, който ги разгръща в клъстера и позволява извършване на актуализации и откат. Важно е, че по същество Helm просто вмъква необходимите стойности в шаблоните и след това ги прилага по същия начин, както се прави в традиционния подход. (повече информация за това как всичко това работи и как можете да го използвате, прочетете в нашата — забележка на преводача). Съществува голямо разнообразие от готови Helm графици, обхващащи широк спектър от задачи.
- Алтернативни инструменти. Има много алтернативни инструменти. Всички те имат обща черта – превръщат определени шаблонни файлове в разбираеми Kubernetes YAML файлове и след това ги прилагат.
В нашата работа постоянно използваме Helm графици за важни инструменти (тъй като много от тях вече са готови, което значително улеснява живота) и „чисти“ YAML файлове на Kubernetes за разгръщане на собствени приложения.
Pull & Push
В едно от своите последни публикации в блога представих инструмента , позволяващ да се комитират шаблони в Git хранилище и да се актуализира разгръщането след всяко комитиране или push на контейнер. Моят опит показва, че този инструмент е един от основните в насърчаването на pull подхода, затова ще се позовавам на него често. Ако искате да научите повече за това как да го използвате, ето .
NB! Всички предимства от използването на GitOps се запазват за двата подхода.
Подход на базата на Pull
Основата на подхода pull е фактът, че всички промени се прилагат от вътре на кластера. Вътре в кластера има оператор, който редовно проверява свързаните Git хранилища и Docker Registry. Ако в тях настъпят промени, състоянието на кластера се обновява отвътре. Обикновено се счита, че такъв процес е доста безопасен, тъй като нито един външен клиент няма достъп до администраторски права на кластера.
Плюсове:
- Нито един външен клиент няма права да прави промени в кластера, всички актуализации се прилагат отвътре.
- Някои инструменти също така позволяват синхронизиране на актуализации на Helm-чартове и свързването им с клъстера.
- Docker Registry може да се сканира за нови версии. Ако се появи нов образ, Git хранилището и разгръщането се актуализират до новата версия.
- Инструментите pull могат да бъдат разпределени в различни пространства от имена с различни Git хранилища и права за достъп. Благодарение на това може да се приложи мултиарендната (multitenant) модел. Например, екип А може да използва пространство от имена А, екип В — пространство от имена В, а екипът, занимаващ се с инфраструктурата, може да използва глобално пространство.
- Като правило, инструментите са много леки.
- В комбинация с инструменти като оператор , тайните могат да се съхраняват в криптиран вид в Git хранището и да се извлекат в кластера.
- Липсва връзка с CD пайплайни, тъй като разгръщанията се случват в кластера.
Недостатъци:
- Управлението на тайните на разгръщанията от Helm-чартове е по-сложно от обикновените, тъй като първо трябва да бъдат генерирани под формата, да речем, на sealed secrets, след което да бъдат декриптирани от вътрешния оператор и само след това те стават достъпни за pull инструмента. След това може да бъде задействано освобождаване в Helm с параметрите в вече разгръщаните тайни. Най-лесният начин е да се създаде тайна с всички стойности на Helm, използвани за разгръщането, да се декриптира и да се добави в Git.
- Когато прилагате подхода pull, вие се свързвате с инструменти, които работят с pull. Това ограничава възможността за настройка на процеса на разгръщане на deployment в клъстера. Например, работата с Kustomize е усложнена, тъй като той трябва да бъде изпълнен преди окончателните шаблони да достигнат до Git. Не казвам, че не можете да използвате отделни инструменти, но тяхната интеграция в процеса на разгръщане е по-трудна.
Подход на базата на Push
В push-подхода външната система (предимно CD пайплайни) стартира разгръщания в клъстера след комит в Git репозиторий или в случай на успешното завършване на предишен CI пайплайн. В този подход системата има достъп до клъстера.
Плюсове:
- Сигурността се определя от Git репозитория и пайплайна за изграждане.
- Разгръщането на Helm чарта е по-лесно, има поддръжка за Helm плъгини.
- Управлението на секрети е по-лесно, тъй като секретите могат да се прилагат в пайплайни и да се съхраняват в Git в криптиран вид (в зависимост от предпочитанията на потребителя).
- Липсата на зависимост от конкретен инструмент, тъй като можете да използвате всякакви видове.
- Актуализациите на версиите на контейнерите могат да бъдат инициирани от пайплайна за изграждане.
Недостатъци:
- Данните за достъп до клъстера се намират в системата за изграждане.
- Актуализацията на контейнерите в deployment все пак е по-лесно да се извърши с pull процеса.
- Силна зависимост от CD системата, тъй като необходимите ни пайплайни може първоначално да са написани за Gitlab Runners, а след това екипът решава да премине на Azure DevOps или Jenkins… и ще се наложи миграция на голямо количество пайплайни за изграждане.
Резюме: Push или Pull?
Както обикновено, всеки подход има своите предимства и недостатъци. Някои задачи е по-лесно да се изпълнят с един метод, а по-трудно с друг. Поначало правех внедрения ръчно, но след като се сблъсках с няколко статии за Weave Flux, реших да внедря GitOps процеси за всички проекти. За основните шаблони това се оказа лесно, но по-късно започнах да срещам трудности с Helm чартовете. По това време Weave Flux предлагаше само начален вариант на Helm Chart Operator, но дори и сега някои задачи са по-трудни заради необходимостта от ръчно създаване на тайни и прилагането им. Можете да кажете, че pull подходът е много по-защитен, тъй като данните за кластера не са достъпни извън него, което толкова увеличава сигурността, че си струва допълнителните усилия.
След като се замислих, стигнах до неочакваното заключение, че не е така. Ако говорим за компоненти, които изискват максимална защита, в такъв списък ще влязат хранилища за тайни и CI/CD системи, Git репозитории. Информацията вътре в тях е доста уязвима и нуждае се от максимална защита. Освен това, ако някой проникне в вашия Git репозиторий и успее да push-не код, той ще може да внедри всичко, което пожелае (независимо от избрания подход, дали е pull или push), и да навлезе в системите на кластера. Така че най-важните компоненти, които изискват защита, са Git репозитория и CI/CD системите, а не данните за кластера. Ако имате добре настроени политики и мерки за сигурност за такива системи, а данните за кластера се извличат в пайплайни само под формата на тайни, допълнителната сигурност на pull подхода може да се окаже не толкова ценна, колкото първоначално се предполагаше.
И така, ако pull подходът е по-трудоемък и не предоставя предимство в сигурността, нали е нелогично да използваме само push подхода? Но пък някой може да заяви, че в push подхода сте прекалено зависими от CI/CD системата и, възможно, е по-добре да не правите така, за да бъде по-лесно в бъдеще да извършвате миграции.
Според мен (както винаги) е необходимо да се използва подхода, който е най-подходящ за конкретния случай или да се комбинират подходите. Лично аз използвам и двата подхода: Weave Flux за разгръщания, основани на pull, които основно включват собствените ни услуги, и push-подход с Helm и плъгини, което опростява прилагането на Helm-чартове към клъстера и позволява безпроблемно създаване на секрети. Мисля, че никога няма да има единно решение, подходящо за всички случаи, защото нюансите винаги са много и зависят от конкретния вариант на приложение. Въпреки това, настоятелно препоръчвам GitOps — той значително улеснява живота и повишава сигурността.
Надявам се моят опит по темата да помогне да определите кой метод е по-подходящ за вашия тип разгръщания, а аз ще бъда радостен да чуя вашето мнение.
P.S. Забележка от преводача
В недостатъците на pull-модела пише, че е трудно да се поставят в Git отрендерените манифести, но не беше споменато, че CD пайплайнът в pull-модела живее отделно от разгръщането и по същество става пайплайн от категорията Continuous Apply. Следователно ще са необходими още повече усилия, за да се събира състоянието на всички разгръщания и да се осигури достъп до логовете/състоянието, като за предпочитане е да е свързано с CD системата.
В това отношение push-моделът позволява да се предоставят поне някакви гаранции за разгръщането, тъй като жизненият цикъл на пайплайна може да бъде равен на жизнения цикъл на разгръщането.
Изпробвахме и двата модела и стигнахме до същите заключения, като автора на статията:
- Pull-моделът е подходящ за организиране на актуализациите на системните компоненти на голям брой клъстери (вижте ).
- Push-моделът на базата на GitLab CI е добре подходящ за разгръщане на приложения чрез Helm-чартове. В същото време разгръщането на deployment’ите в рамките на пайплайните се проследява с помощта на инструмента . Между другото, в контекста на този наш проект често чувахме „GitOps“, когато обсъждахме належащите проблеми на DevOps-инженерите на нашия щанд на KubeCon Europe’19.
P.P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Само регистрирани потребители могат да участват в анкетата. , моля.
Използвате ли GitOps?
Да, подход pull
Да, push
Да, pull + push
Да, нещо друго
Не
30 потребители проведоха гласуване. 10 потребители се въздържаха.
Източник: habr.com
