Далеко не всички сървърни платформи, дори и най-мощните и мащабируеми, отговарят на всички нужди. Въпреки че Kubernetes работи отлично сам по себе си, може да му липсват необходимите части за завършеност. Винаги ще намерите специфичен случай, който игнорира вашата нужда или където Kubernetes няма да работи при инсталация по подразбиране — например, поддръжка на бази данни или работа с CD.
Тук и възникват добавки, разширения и други полезни неща за този оркестратор на контейнери, поддържани от широка общност. В тази статия ще представим 11 от най-добрите неща, които намерихме. Ние самите в те са много интересни и планираме да се запознаем с тях практически — да ги разглобим на винтчета и гайки и да видим какво има вътре. Част от тях прекрасно ще допълнят всеки кластер на Kubernetes, а други ще помогнат за решаване на специфични задачи, които не са реализирани в стандартната доставка на Kubernetes.
Gatekeeper: управление на политиките
Проект (OPA) предоставя възможността за създаване на политики над облачните стекове на приложения в Kubernetes, започвайки от ingress и завършвайки с service mesh. дава нативна на Kubernetes възможност за автоматично прилагане на политики в кластера, както и проверка на всякакви събития или ресурси, нарушаващи политиката. Всичко това се обработва чрез сравнително нов механизъм на Kubernetes, диспетчера на достъпа Webhooks, който работи при промяна на ресурсите. С помощта на Gatekeeper политиките OPA стават част от състоянието на вашия кластер Kubernetes, без да е необходима постоянна намеса.
Gravity: Преносими клъстери на Kubernetes
Ако желаете да внедрите приложение в Kubernetes, много приложения имат Helm chart, който насочва и автоматизира този процес. Но какво, ако искате да вземете вашия кластер Kubernetes „както е“ и да го внедрите някъде другаде?
прави снимки на състоянието на клъстерите на Kubernetes, техния регистър за изображения на контейнери, а също така и стартирани приложения, наречени „пакети от приложения“. Такъв пакет, представляващ се от обикновен файл .tar, може да репликира клъстер навсякъде, където Kubernetes може да работи.
Gravity също проверява дали целевата инфраструктура се държи по същия начин както оригиналната, а също така, дали Kubernetes средата на целевата инсталация е достъпна. Платената версия на Gravity добавя функции за сигурност, включително RBAC и възможността за синхронизиране на настройки за сигурност между различни разгръщания на клъстери.
Последната основна версия, Gravity 7, може да разгръща образа на Gravity в съществуващ клъстер Kubernetes, вместо да разгръща изцяло нов клъстер от образа. Gravity 7 също може да работи с клъстери, инсталирани без използване на образа Gravity. Освен това, Gravity поддържа SELinux и работи нативно с Teleport SSH шлюза.
Kaniko: Сборка на контейнери в клъстера Kubernetes
Повечето образи на контейнери се изграждат на системи извън контейнерния стек. Въпреки това, понякога е необходимо да се построи образ вътре в контейнерния стек, например, някъде в работещ контейнер или в клъстера Kubernetes.
извършва изграждане на контейнери в контейнерна среда, но без зависимости от контейнеризационен сервис, например Docker. Вместо това, Kaniko извлича файловата система от базовия образ, изпълнява всички команди за изграждане в потребителското пространство върху извлечената файлова система и прави снимка на файловата система след всяка команда.
Забележка: Kaniko в момента (май 2020 г., прим. преводача) не може да изгражда Windows контейнери.
Kubecost: Опции за разходите при стартиране на Kubernetes
Повечето инструменти за администриране на Kubernetes са насочени към лесна употреба, мониторинг, разбиране на поведението в подовете и т.н. Но какво да кажем за наблюдението на разходите — в лева и стотинки — свързани със стартирането на Kubernetes?
обработва параметрите на Kubernetes в реално време, което води до получаване на информация за актуалната цена от стартираните клъстери при основните облачни доставчици, показвани на таблото с месечната цена на всеки клъстер. Цените за оперативна памет, процесорно време, GPU и дисковите подсистеми са разбити по компоненти на Kubernetes (контейнер, под, услуга и т.н.)
Kubecost също така следи разходите за извънклъстерни ресурси, например Amazon S3 кофи, въпреки че е ограничена до AWS. Данните за разходите могат да бъдат изпратени в Prometheus, така че можете да ги използвате за програмирано изменение на поведението на клъстера.
Kubecost е безплатен за използване, ако ви е достатъчно данните в логовете за 15 дни. За допълнителни функции цените започват от 199$ на месец за мониторинг на 50 възела.
KubeDB: Стартиране на производствени бази данни в Kubernetes
Базите данни са достатъчно сложни за ефикасно стартиране в Kubernetes. Можете да намерите Kubernetes оператори за MySQL, PostgreSQL, MongoDB и Redis, но всички те имат недостатъци. Освен това стандартният набор от функции на Kubernetes не може директно да реши повечето специфични проблеми с базите данни.
помага ви да създадете свои Kubernetes оператори за управление на бази данни. Стартиране на резервни копия, клониране, мониторинг, създаване на снимки и декларативно създаване на бази — това са неговите съставни части. Обърнете внимание, че поддръжката на функции зависи от базата данни. Например, създаването на клъстери работи за PostgreSQL, но не и за MySQL ( има, както правилно отбеляза , прим. преводача).
Kube-monkey: Chaos Monkey за Kubernetes
Най-сигурният начин за стрес-тестиране са случайните повреди. Тази теория е в основата на Chaos Monkey от Netflix, хаотичен инженерни инструмент, който случайно изключва виртуални машини и контейнери в производствена среда, за да "стимулира" разработчиците да създават по-устойчиви системи. — реализация на същата основна теория за стрес-тестиране за Kubernetes клъстери. Той работи, като случайно убива модули в клъстера, определяни от вас, и може да бъде настроен да работи в определен времеви интервал.
Kubernetes Ingress Controller за AWS
Kubernetes предоставя външен балансировач на натоварването и мрежови услуги на клъстера чрез услуга, наречена AWS предоставя функции за балансировка на натоварването, но не ги свързва автоматично с това, което предлага Kubernetes. поправя този пропуск.
Той автоматично управлява ресурсите на AWS за всеки ingress обект в клъстера, създавайки балансировачи на натоварването за нови ingress ресурси и премахвайки балансировачите при изтриване на ресурси. Използва CloudFormation, за да гарантира, че състоянието на клъстера остава непокътнато. Той също така поддържа настройки на CloudWatch Alarm и автоматично управлява други елементи, използвани в клъстера, като например SSL сертификати и EC2 Auto Scaling Groups.
Kubespray: Автоматична инсталация на Kubernetes
автоматизира инсталацията на готов клъстер Kubernetes, започвайки от инсталация на 'железни' сървъри и завършвайки с основните публични облаци. Той използва Ansible (Vagrant - допълнително) за стартиране на разгръщане и създаване на високо достъпен клъстер от нулата с избраното от вас мрежово добавление (например Flannel, Calico и др.) на избрания от вас популярен дистрибутив на Linux при инсталация на 'железни' сървъри.
Skaffold: Итеративна разработка за Kubernetes
— един от инструментите на Google, използвани за организиране на CD приложения в Kubernetes. Веднага щом направите промени в изходния код— Skaffold автоматично ги определя, стартира изграждане и разгръщане, предупреждава ви, ако има някакви грешки. Skaffold работи напълно на клиентска страна, така че могат да се появят малки нюанси с инсталацията или обновленията. Той може да се използва с вече съществуващи CICD конвейери и също така взаимодейства с някои външни инструменти за изграждане, основно с Bazel от Google.
Teresa: Най-простият PaaS на Kubernetes
е система за разгръщане на приложения, която стартира най-простия PaaS над Kubernetes. Потребителите, разделени по отбори, могат да разгръщат и управляват приложенията си. Това малко улеснява работата на хората, които се доверяват на това приложение и не искат да се занимават с Kubernetes и всичките му сложности.
Tilt: Потоково разпространение на актуализации на контейнери в клъстера Kubernetes
, разработен от Windmill Engineering, наблюдава промените в различни файлове Dockerfile и след това постепенно разгръща съответните контейнери в клъстера Kubernetes. По същество, той позволява актуализацията на производствения клъстер в реално време просто чрез обновяване на файловете Dockerfile. Tilt извършва изграждане вътре в клъстера, изходният код — всичко, което трябва да се променя. Можете също да направите стик на състоянието на клъстера и да фиксирате условията за задействане на грешки директно от Tilt, за да ги споделите с членовете на екипа за отстраняване на проблеми.
P.S. Всички тези инструменти сме проучвали многократно с нашите любопитни ръце. За да представим реални практики вече (надявам се!) на офлайн-интензиви през февруари. 8–10 февруари 2021. И 8–10 февруари 2021. И 12–14 февруари. Честно казано, и ние също се поразхождахме по топлата и енергийно заредена атмосфера на офлайн обучението. Каквито и напредничави технологии да съществуват, те не могат да заместят живото човешко общуване и специалната атмосфера, когато се събират хора с общи интереси.
Източник: habr.com
