Результати Опитування щодо Використання Kubernetes

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Нещодавно, від імені Телеграм каналу CatOps, я проводив опитування про те, як люди пораються із Kubernetes кластерами у своїх компаніях . Мені вдалось зібрати більш ніж сто відгуків із Telegram, Reddit, Twitter та DOU. 102, якщо бути точним. І сьогодні я хочу поділитися з вами результатами цього опитування!

Сирі дані ви можете знайти за цим посиланням.

Матеріал також доступний англійською.

Передмова (можна пропустити)

Після написання статті «Why backup Kubernetes?», я отримав кілька питань щодо концепції «clusters as cattle», та технічних складнощів, які ця концепція тягне за собою. Я вже був почав писати нову статтю, щоби відповісти на ці запитання, та зрозумів: мій досвід обмежений лише теперішньою та минулою компаніями. Тому, я вирішив запитати спільноту, що вона використовує для менеджменту своїх кластерів.

Я все ще планую написати статтю про «clusters as cattle», але спочатку я хочу поділитись результатами мого опитування.

Як і Скільки?

Більшість респондентів (~80%) використовують статичні кластери. 35 з опитаних (34.3%) мають один статичний кластер на кожне оточення, 29 (28.4%) використовують різні статичні кластери для різних цілей або команд.

17 респондентів (16.7%) використовують динамічні кластери, які вони можуть розгорнути по запиту. Також кілька людей відзначило, що вони є наразі у процесі міграції до «кластерів по запиту».

Максимальне число кластерів серед опитаних — 200.

Дистрибутиви

• Переважна більшість (>70%) використовує стандартний дистрибутив Kubernetes, якщо враховувати також Kubernetes as a service від хмарних провайдерів
• 18% використовують дистрибутиви Rancher, включаючи k3s
• Дехто має комбінацію різних дистрибутивів, наприклад, хмарні кластери в одних економічних зонах та власні RKE кластери в інших
• OpenShift посідає 3-є місце із 8% користувачів

Чесно кажучи, я передбачав більше користувачів OpenShift. Проте є важливе питання: що саме можна вважати дистрибутивом? З одного боку GKE та EKS мають власні фічі на додачу до стандартної версії, але чи можна їх вважати повністю окремим продуктом? Також варто зазначити, що Rancher пропонує декілька рішень, тому групування їх усіх в одному пункті вплинуло на це питання.

Хто Завідує Кластером?

• 71 респондент (69.6%) використовує хмарні рішення для своїх кластерів
• 54 (52.9%) керують своїми кластерами самотужки
• 5 людей (близько 5%) відповіли, що аутсорсять свої кластери третім особам
• Загальне відсоткове співвідношення є понад 100% тому що деякі люди використовують як власні, так і менеджд-кластери
• Популярна причина використовувати такий мікс полягає у мультиклауді або гібридній інфраструктурі
• Інша популярна причина — міграція на хмарне рішення
• Дехто із респондентів зазначив, що вони мають мікс із власних та хмарних кластерів, тому що мають тестувати різні сценарії інтеграції для різних замовників

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

Я припускаю, що кількість користувачів хмарних кластерів зросте у найближчі роки. Однак селф-хостед кластери, звісно, нікуди не зникнуть. Існує досить багато компаній, що мають власні дата-центри, або ж мають специфічні вимоги щодо доступу до контрольної панелі.

Кілька інших спостережень:

• AWS залишається найпопулярнішою публічною хмарою. Як мінімум серед опитаних
• 25 людей (33.3%) використовують GKE
• AKS (Azure) посідає третє місце із 17 (22.7%) користувачами

Версії Kubernetes та Динаміка Оновлень

Беручи до уваги загальний тренд щодо використання хмарних кластерів, буде слушно припустити, що багато людей використовують ту версію Kubnernetes, що доступна у їхній хмарі. 34 респонденти (34.3%) відповіли саме це.

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

Щодо інших чисел:

• 26 респондентів (25.5%) використовують декілька різних версій Kubernetes одночасно
• 14 (13.7%) використовують старшу версію із тих, що досі підтримуються
• Стратегією «Остання версія мінус один» керуються 10 зі 102 респондентів (9.8%)
• 6 респондентів (5.9%) ідуть у ногу із часом і використовують останню patch-версію
• Інші 6 (5.9%) — старші версії Kubernetes, що вже не підтримуються (<1.20 на момент виходу опитування)

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

Майже 3/4 опитаних не дотримуються чіткої періодичності в оновленні своїх кластерів. Лише 26 респондентів (25.5%) мають чіткий цикл оновлень.

Серед причин апґрейду є:

• Нагальна потреба: кінець підтримки версії, критичні вразливості тощо — 42 (41.2%)
• Вихід нової версії — 28 (27.5%)
• Дехто зазначив, що оновлюють кластери, коли є час та натхнення
• Одна людина написала, що у них є план оновлюватись за чітким графіком, але це не завжди є можливим
• Ще одна людина зазначила, що оновлення кластерів мають бути узгоджені із замовником

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

Це питання містить очевидну помилку. В ідеалі воно мало б називатись щось на кшталт «How often do you upgrade your clusters?»

Як ви бачите, тут немає чітко вираженої загальної практики.

• 36 опитаних (35.6%) оновлюють свої кластери хоча б раз на пів року
• 32 респонденти (31.7%) роблять це хоча б раз на квартал
• 23 (22.8%) — хоча б раз на рік
• Тільки 3 людини оновлюють свої кластери рідше аніж раз на рік
• 7 людей (6.9%) роблять апґрейд хоча б раз на місяць

Буде цікаво поспостерігати за цією метрикою в динаміці. З одного боку, перехід до хмарних кластерів мав би збільшити частоту оновлень. З іншого боку, ця частота може навпаки зменшитись через зміни резілного циклу Kubernetes.

Автоматизація Оновлень

Переважна більшість опитаних (83 / 81.4%) оновлюють свої кластери «по живому», в сенсі, що вони застосовують оновлення на кластери, що вже запущені.

Інші (19 / 18.6%) — створюють новий кластер і мігрують свої застосунки туди.

Щодо автоматизації, більшість (90 / 88%) має бодай якусь автоматизацію оновлень. 42 респонденти (42.2%) відповіли, що мають повну автоматизацію всього процесу. Тобто людина може виконати команду або запустити пайплайн, щоб оновити кластер. Лише 12% опитаних зазначили, що оновлення кластерів для них все ще є ручною задачею.

Це ще одна метрика, яку буде вкрай цікаво поспостерігати у динаміці. Я припускаю, що кількість людей із мануальним підходом знизиться із часом. Проте я не думаю, що 100% досягнуть повної автоматизації своїх процесів. Іноді «good enough is enough».

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

І знову я натупив із постановкою запитання. Мені дуже шкода.

• 59 (57.8%) респондентів використовують API своїх хмарних провайдерів для керування кластерами. Це прекрасно корелює із загальною тенденцією щодо використання менеджд-кластерів
• Несподівано великий відсоток опитаних (25 / 24.5%) використовують написану власноруч автоматизацію для роботи із кластерами
• Open-source залишається популярним вибором. Відкритими рішеннями користуються 28 (27.5%) респондентів
• Із цікавого, 15 людей (14.7%) використовують Kubernetes Cluster API, що ставить цей спосіб на 4-те місце за популярністю

Базові Компоненти

Я вже не раз казав, що «голий» Kubernetes нікому не потрібен. Саме екосистема робить його унікальною і широковживаною технологією. Ця екосистема налічує десятки плагінів, що допомагають операторам запускати застосунки у Kubernetes. В цій статті я буду називати такі плагіни «базовими компонентами». До них, наприклад, відносяться: CNI, Ingress controllers, Log scrappers, і т.д.

• Більша частина опитаних (59 / 57.8%) не узгоджують оновлення кластерів з оновленням базових компонентів. Це означає, що компоненти живуть власним життям і не залежать від циклу оновлень кластерів
• 31 респондент (30.4%) узгоджують лише оновлення критичних компонентів. Тобто, наприклад, оновлюють CNI разом із кластером, а менш критичні речі — окремо
• 11 людей (10.8%) створюють нові кластери для оновлення базових компонентів

Також одна людина зазначила, що GKE вимагає створення нового кластера для оновлення деяких плагінів. Для мене це був досить цікавий інсайт, оскільки я не маю досвіду із GCP.

• Більшість респондентів (60 / 58.8%) не мають чіткої періодичності оновлень базових компонентів і роблять це за необхідності
• 16 опитаних (15.7%) оновлюються в разі викритого критичного багу чи вразливлсті
• 9 людей (8.8%) — коли доступні нові версії плагінів
• Одна людина зазначила, що процес оновлення базових компонентів у їхній компанії є частково автоматизованим за GitOps підходом

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

Із інструментарію

• Helm залишається найпопулярнішим вибором для менеджменту базових компонентів для 67 опитаних (65.7%)
• Terraform посідає друге місце із 40 відповідями (39.9%)
• ArgoCD і Kustomise мають третє і четверте місця відповідно. Argo є трохи популярнішим: 30 (29.4%) проти 21 (20.6%)

Досить очікувано, що це питання має «довгий хвіст» в пункті «Інше». Серед технологій для керування базовими компонентами люди також зазначили: Flux, Ansible, чистий YAML, власні оператори, і т.д.

Blue/Green Апґрейди

• Близько половини (44 / 56.4%) тих, що створюють новий кластер при апґрейді, використовують для цього GitOps
• Інші 25 опитаних (32.1%) мають власну автоматизацію
• 21 респондент (26.9%) перевстановлює застосунки у новий кластер вручну
• 14 опитаних (17.9%) відповіли, що мають просити відповідальні команди перевстановити свої застосунки
• Також одна людина зазначила, що редеплой потрібен не завжди. Будь-ласка, якщо це були ви — звʼяжіться зі мною. Мені дуже цікаві такі кейси

Резервне Копіювання та План щодо Дій у Надзвичайних Ситуаціях

Оскільки моя серія статей розпочалась із посту про резервне копіювання Kubernetes, мені був дуже цікавий цей блок питань.

• Отже, тільки 39 респондентів (38.2%) мають план щодо дії у надзвичайній ситуації, що є протестованим. На жаль, я не запитав, чи був цей план протестований як частина повсякденної перевірки, чи під час реального інциденту
• 22 людини (21.6%) мають екстрений план, але ніколи його не перевіряли
• 41 респондент (40.2%) відповіли, що взагалі не мають екстреного плану

Проте не все так погано.

• 42 респонденти (41.2%) зазначили, що можуть відновити кластер без допомоги резервного копіювання. Наприклад, з використанням GitOps
• 21 респондент (20.6%) використовують спеціальні інструменти для бекапів, наприклад, Velero
• 14 (13.7%) — створюють снепшоти ETCD
• Однак 14 респондентів (13.7%) відповіли, що взагалі не мають резервного копіювання для своїх кластерів

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

Лише 15 користувачів (14.7%) відповіли, що вони не мають ні резервних копій, ні плану дії у надзвичайних ситуаціях. Чесно кажучи, це трохи бентежні цифри, адже лихо може статись навіть у хмарному середовищі. План Б ніколи не буде зайвим.

Висновки та Тизер Частини II

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

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

І ось що ще. В цьому опитуванні я також ставив питання «Яким був ваш найбільш болючий досвід із Kubernetes?». І Я отримав досить багато цікавих історій! Однак я хочу, щоби перша частина була про цифри. Тому я зберу ваші історії до купи й опублікую їх у другій частині. Stay tuned!