Кілька середовищ (постановка, якість, виробництво тощо) з Kubernetes

Що вважається хорошою практикою роботи K8S для керування кількома середовищами (QA, Staging, Production, Dev тощо)?

Як приклад, скажіть, що команда працює над продуктом, який потребує розгортання декількох API, а також додатка на передній панелі. Зазвичай для цього знадобиться щонайменше 2 середовища:

• Постановка: для ітерацій / тестування та перевірки перед випуском клієнта
• Виробництво: Це середовище, до якого має доступ клієнт. Повинен містити стабільні та добре перевірені функції.

Отже, якщо припустити, що команда використовує Kubernetes, що було б хорошою практикою розміщення цих середовищ? На сьогодні ми розглянули два варіанти:

1. Використовуйте кластер K8s для кожного середовища
2. Використовуйте лише один кластер K8s і зберігайте їх у різних просторах імен.

(1) Здається найбезпечнішим варіантом, оскільки це мінімізує ризики можливих помилок людини та збоїв на машині, що можуть поставити під загрозу виробниче середовище. Однак це пов'язано з витратами на більшу кількість головних машин, а також з витратами на більше управління інфраструктурою.

(2) Схоже, це спрощує управління інфраструктурою та розгортанням, оскільки є один єдиний кластер, але він викликає кілька питань, таких як:

• Як можна переконатися, що помилка людини може вплинути на виробниче середовище?
• Як можна переконатися, що високе навантаження в умовах постановки не призведе до втрати продуктивності у виробничих умовах?

Можуть бути і інші проблеми, тому я звертаюся до спільноти К8 на StackOverflow, щоб краще зрозуміти, як люди мають справу з подібними проблемами.

Кілька міркувань кластерів

Подивіться цю публікацію в блозі від Вадима Айзенберга ( IBM / Istio ): Контрольний список: плюси і мінуси використання декількох кластерів Kubernetes та як розподілити навантаження між ними .

Я хотів би виділити деякі плюси / мінуси:

Причини виникнення кількох кластерів

• Розділення виробництва / розробки / тестування: особливо для тестування нової версії Kubernetes, сервісної сітки іншого кластерного програмного забезпечення
• Відповідність: згідно з деякими правилами деякі програми повинні працювати в окремих кластерах / окремих VPN
• Краща ізоляція для безпеки
• Cloud / on-prem: розподілити навантаження між локальними послугами

Причини мати єдиний кластер

• Скорочення витрат на налаштування, обслуговування та адміністрування
• Поліпшити використання
• Зниження витрат

Беручи до уваги не надто дороге середовище із середнім обслуговуванням та все-таки забезпеченням ізоляції безпеки для виробничих додатків, я рекомендую:

• 1 кластер для DEV і STAGING (розділений просторами імен, можливо навіть ізольованим, використовуючи мережеві політики, як у Calico )
• 1 кластер для PROD

Паритет навколишнього середовища

Це корисна підтримка розвитку, постановки та виробництва максимально схожим:

Відмінності між резервними службами означають, що крихітні несумісності з'являються, що призводить до того, що код, який працював і пройшов тести на розробці чи стадії, не вийшов із виробництва. Ці типи помилок створюють тертя, що зневажає постійне розгортання.

Поєднайте потужний інструмент CI / CD з кермом . Можна використовувати гнучкість значень керма для встановлення конфігурацій за замовчуванням, просто переосмислюючи конфігурації, які відрізняються від середовища до іншого.

GitLab CI / CD з AutoDevops має потужну інтеграцію з Kubernetes, що дозволяє керувати кількома кластерами Kubernetes вже за підтримки керма.

Керування декількома кластерами ( kubectlвзаємодіями)

Коли ви працюєте з декількома кластерами Kubernetes, легко зіпсувати контексти і бігти kubectlв неправильний кластер. Крім того, у Kubernetes є обмеження щодо невідповідності версій між клієнтом ( kubectl) та сервером (kubernetes master), тому виконання команд у правильному контексті не означає виконання потрібної версії клієнта.

Щоб подолати це:

• Використовуйте asdfдля керування кількома kubectlверсіями
• ВстановітьKUBECONFIG env var для зміни між декількома kubeconfigфайлами
• Використовуйте kube-ps1для відстеження поточного контексту / простору імен
• Використовуйте kubectxтаkubens швидко змінюйте кластери / простори імен
• Використовуйте псевдоніми, щоб об’єднати їх усі разом

У мене є стаття, яка пояснює, як це досягти: Використання різних версій kubectl з кількома кластерами Kubernetes

Я також рекомендую такі прочитання:

• Оволодіння файлом KUBECONFIG Ahmet Alp Balkan ( Google Engineer )
• Як Zalando управляє 140 кластерами кубернетів від Henning Jacobs ( Zalando Tech )

Однозначно використовуйте окремий кластер для розробки та створення зображень докерів, щоб ваші кластери постановки / виготовлення могли бути заблоковані безпекою. Незалежно від того, чи будете ви використовувати окремі кластери, staging + productionвирішувати, виходячи з ризику / вартості, - безумовно, утримання їх окремо допоможе уникнути stagingвпливу production.

Я також настійно рекомендую використовувати GitOps для просування версій ваших додатків між вашими середовищами.

Щоб мінімізувати людські помилки, я також рекомендую розібратися в автоматизації якнайбільше для ваших CI / CD та просування.

Ось демонстрація того, як автоматизувати CI / CD з декількома середовищами на Kubernetes, використовуючи GitOps для просування між середовищами та попереднього перегляду середовищ на Pull Requests, що було зроблено в прямому ефірі на GKE, хоча Jenkins X підтримує більшість кластерів кубернетів

Це залежить від того, що ви хочете протестувати у кожному зі сценаріїв. Взагалі я б намагався уникати запуску тестових сценаріїв на виробничому кластері, щоб уникнути зайвих побічних ефектів (вплив продуктивності тощо).

Якщо ваш намір тестується за допомогою системи постановки, яка точно імітує виробничу систему, я рекомендую випустити точну репліку цілого кластера та закрити його після завершення тестування та перенести розгортання на виробництво.

Якщо ваша мета - тестування системи постановки, яка дозволяє тестувати програму для розгортання, я б постійно запускав менший кластерний етап та оновлював розгортання (з також зменшеною версією розгортань), як це потрібно для постійного тестування.

Для управління різними кластерами я вважаю за краще мати окрему машину ci / cd, яка не є частиною кластера, але використовується для запуску та вимкнення кластерів, а також для виконання робіт з розгортання, ініціювання тестів тощо. Це дозволяє налаштувати і вимкнути кластери як частина автоматизованих сценаріїв тестування.

Зрозуміло, що завдяки збереженню виробничого кластера від поетапного зменшується ризик можливих помилок, що впливають на виробничі послуги. Однак це коштує більше управління інфраструктурою / конфігурацією, оскільки для цього потрібно щонайменше:

• щонайменше 3 майстри виробничого кластера і хоча б один майстер для постановочного
• 2 конфігураційні файли Kubectl, які потрібно додати до системи CI / CD

Не забуваймо також, що середовищ може бути більше, ніж одне. Наприклад, я працював у компаніях, де є щонайменше 3 середовища:

• QA: Це місце, де ми робимо щоденні розгортання і де робимо внутрішню QA, перш ніж випускати клієнта)
• Клієнт QA: це місце, де ми розгорнулися перед розгортанням у виробництво, щоб клієнт міг перевірити середовище перед тим, як перейти до виробництва)
• Виробництво: це місце, де розміщуються виробничі послуги.

Я думаю, що ефемерні кластери / на вимогу мають сенс, але лише для певних випадків використання (тестування навантаження / працездатності або дуже «велика» інтеграція / тестування в кінці), але для більш стійких / клейких середовищ я бачу накладні витрати, які можуть бути зменшені запускаючи їх у межах одного кластера.

Напевно, я хотів звернутися до спільноти k8s, щоб побачити, які зразки використовуються для таких сценаріїв, як описаний нами.

Якщо відповідність чи інші вимоги не диктують інше, я віддаю перевагу одному кластеру для всіх середовищ. При такому підході точки уваги:

• Переконайтесь, що ви також групуєте вузли в середовищі за допомогою міток. Потім можна використовувати nodeSelectorресурси on, щоб переконатися, що вони працюють на певних вузлах. Це знизить шанси на (перевищення) споживання ресурсів між середовищами.

• Ставтесь до своїх просторів імен як до підмереж і забороняйте весь вихідний / вхідний трафік за замовчуванням. Дивіться https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

• Створити стратегію управління обліковими записами послуг. ClusterRoleBindingsмається на увазі щось інше, якщо кластери розміщують більше одного середовища.

• Використовуйте ретельний аналіз при використанні таких інструментів, як Helm. Деякі діаграми нахабно встановлюють облікові записи сервісів із дозволами для всіх кластерів, але дозволи для облікових записів послуг повинні бути обмежені середовищем, в якому вони перебувають.

Використання декількох кластерів є нормою, за самим списком, щоб забезпечити сильний розрив між виробництвом та "невиробничим".

У цьому дусі зауважте, що GitLab 13.2 (липень 2020 року) тепер включає:

Кілька розгортань кластерів Kubernetes в Core

Використовуючи GitLab для розгортання декількох кластерів Kubernetes з GitLab, раніше потрібна ліцензія Premium.
Наша спільнота говорила, і ми слухали: розгортання в декілька кластерів корисно навіть для окремих учасників.
На основі ваших відгуків, починаючи з GitLab 13.2, ви можете розгорнути до декількох кластерних груп та проектів у Core.

Дивіться документацію та випуск /

Я думаю, що працювати з одним кластером має сенс, оскільки це зменшує накладні витрати, моніторинг. Але, ви повинні переконатися, що розмістити мережеву політику та контроль доступу.

Мережева політика - забороняти робочому навантаженню середовища dev / qa взаємодіяти з магазинами prod / staging.

Контроль доступу - які мають доступ до різних ресурсів середовища за допомогою ClusterRoles, Roles тощо.