Не всі серверні платформи, навіть найпотужніші і масштабовані, задовольняють всі потреби, як є. Хоча 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, їхньої registry для образів контейнерів, а також запущених додатків, званих «пакетами додатків». Такий пакет, що є звичайним файлом .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 націлені на простоту використання, моніторинг, розуміння поведінки всередині pod, тощо. Але що щодо спостереження за вартістю — у рублях та копійках — пов'язаною із запуском Kubernetes?
обробляє параметри Kubernetes у режимі реального часу, що призводить до надходження інформації про актуальну вартість від запущених кластерів у основних постачальників хмарних послуг, що відображаються на панелі зі щомісячною вартістю кожного кластера. Ціни за оперативну пам'ять, процесорний час, GPU та дискову підсистему розбиті за компонентами Kubernetes (контейнер, pod, сервіс тощо)
Kubecost також відстежує вартість позакластерних ресурсів, наприклад, Amazon S3 buckets, хоча вона обмежена 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, щоб поділитися ними з членами команди для налагодження.
PS Всі ці інструменти ми неодноразово в промацали нашими цікавими ручками. Щоб уявити реальні практики вже (сподіваюся!) на офлайн-інтенсивах у лютому. 8–10 лютого 2021 року. 12-14 лютого. Чесно, ми теж скучили за теплою та енергетично зарядженою атмосферою офлайн-навчання. Хоч би які просунуті технології були, вони не замінять живого людського спілкування та особливої атмосфери, коли збираються однодумці.
Джерело: habr.com