Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Результати опитування CatOps щодо Kubernetes Operations 2023

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Вже вдруге я проводжу це опитування. Тогорічні результати можна переглянути тут. Сирі дані можна переглянути в Google таблиці. Англомовна версія статті досутпна у моєму блозі або ж на Substack.

Вступ

Цього року опитування тривало два місяці: від 14-го березня по 18-е травня і зібрало 122 відповіді. Хоча маю зазначити, що я активно просував це опитування лише у перший місяць. Цього року я поширював його через трохи інакші канали, ніж торік. Проте ці відмінності не мають відобразитись на результатах.

Багато питань не змінились з минулого року, але все ж таки мені довелось змінити деякі запитання через формулювання. Та все одно можна проводити паралелі з минулорічним опитуванням.

Для кожної із відповідей я буду наводити абсолютні величини та долю у відсотках. Відсотки взяти у (круглі дужки).

Типи та Кількість Кластерів

48 (39.3%) респондентів використовують декілька статичних кластерів для різних команд і департаментів. Це число зросло у порівнянні із минулим роком, тоді ця кількість складала 29 (28%). Кількість людей, що використовують по одному статичному кластеру на оточення теж зросла з 35 (34%) у 2022 до 44 (36.1%) у 2023.

18 (14.8%) респондентів мають динамічні кластери, які можуть бути підняті по запиту.

У цьому питанні не було достатньо влучної відповіді для мультирегіональних сетапів. Тож деякі люди скористались графою «Інше». Попри те, що таких відповідей було всього декілька, можливо, інші просто вибирали найбільш схожу відповідь.

Якими Дистрибутивами Користуються


Більшість респондентів використовує хмарні дистрибутиви Kubernetes — 99 (81.1%). Можна заперечити, що хмарні сервіси не є окремими дистрибутивами самі по собі, але минулорічне опитування явно бракувало подібної відповіді.

На другому місці за популярністю «ванільний» Kubernetes із 30 (24.6%) користувачів.

Rancher займає третє й четверте місця із RKE — 14 (11.5%) — і k3s — 12 (9.8%) — відповідно.

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

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

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

І моє улюблене:

Company is stupid

Хмарні Рішення

96 (78.7%) респондентів використовують managed-Kubernetes. 51 (41.8%) опікуються кластерами власноруч і 3 (2.5%) мають для цього стороннього вендора.


Це питання дає змогу опосередковано зрозуміти, якими клаудами користуються люди.

Досить передбачувано, найпопулярнішим є AWS: 68 (68%). GCP GKE на другому місці — 37 (37%). На третьому — Azure AKS — (28%).

Ці результати дещо суперечать статистиці використання хмарних вендорів — Cloud infrastructure services vendor market share statistics. Згідно із яким Azure посідає друге місце за популярністю, тоді як GCP — третє. Такі результати можуть бути спричинені тим, що серед тих, хто брав участь в опитуванні, було більше користувачів GCP або тим, що користувачі Azure рідше використовують managed-Kubernetes. Для того, щоби дати більш точну відповідь, потрібно буде додати окреме питання щодо хмарних вендорів. З іншого боку, цьогорічні результати узгоджуються із минулорічними.

Версії Kuberentes


32 (26.2%) людини використовують останню доступну версію Kubernetes Оскільки хмарні провайдери можуть відставати від апстріма, я надав саме такий варіант відповіді.

27 (22.1%) використовують декілька різних версій одночасно.

26 (21.3%) користуються старшою версією, що все ще підтримується.

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

13 (10.7%) людей відповіли, що досі використовують версію, що вже не підтримується. Це число зросло у порівнянні із попереднім роком — 6 (5.9%). Така розбіжність може бути спричинена тим, що в опитуванні брали учать різні люди або ж тим, що більше людей не встигають за оновленнями Kubernetes.

Тільки 10 (8.2%) людей використовують останню патч-версію. Ця цифра також трохи зросла у порівнянні із попереднім роком — 6 (5.9%).

Оновлення Kubernetes


Біль як половина респондентів оновлюють версію Kubernetes, коли на то є потреба — 68 (55.7%). Дехто відповів, що оновлюють версію коли поточна добігає кінця циклу підтримки або ж коли мають достатньо часу та бюджет на оновлення.

27 (22.1%) респондентів оновлюють свої кластери зі сталою регулярністю і 26 (21.3%) із виходом нової версії.

1 (0.8%) людина відповіла, що вони не оновлюють версію Kubernetes через «дивні вимоги» зі сторони розробників.


Щодо частоти оновлення: 38 (31.7%) респондентів оновлюють кластери як мінімум раз у пів року. 36 (30%) роблять це хоча б раз у квартал.

19 (15.8%) респондентів оновлюють версію Kubernetes раз на місяць або частіше і 20 (16.7%) роблять це хоча б раз на рік.

7 (5.8%) людей відповіли, що оновлюють версію Kubernetes рідше ніж раз на рік.

Як люди оновлюють Kubernetes


Переважна більшість оновлює версію Kubernetes у поточному кластері — 103 (84.4%). Тільки 16 (13.1%) респондентів створюють новий кластер і мігрують застосунки туди.

Дехто використовує змішаний підхід в залежності від критичності застосунків у кластері — 3 (2.5%).

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

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


Більшість тих, хто оновлює Kubernetes шляхом міграції у новий кластер, робить це за допомогою GitOps інструментів — 45 (68.2%).

29 (43.9%) респондентів використовують власну автоматизацію.

Проте дехто мігрує застосунки вручну — 13 (19.7%) — або звертається за цим до відповідних команд — 5 (7.6%). Ці цифри є меншими у порівнянні із попереднім роком.

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


Майже половина респондентів — 58 (47.5%) — мають напівавтоматизовані оновлення Kubernetes. Це означає, що сама по собі автоматизація існує, але все ще залишаються деякі мануальні кроки.

28 (23%) відповіли, що у них оновлення Kubernetes повністю автоматизоване і для 36 (29.5%) це все ще повністю ручна процедура.

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


Очевидно багато людей використовують інструменти хмарного провайдера для оновлення Kubernetes — 82 (54.7%).

24 (16%) людей використовують сторонні інструменти, як open source, так і ні.

Cluster API досі не є дуже поширеною технологією. Нею користується лише 10 (6.7%) респондентів.

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

Плагіни

В англомовній версії статті я використовую термін «core components». Я не знаю влучного перекладу на українську мову, тому буду просто використовувати слово «плагіни». Під цим терміном я розумію всі компоненти, що становлять функціональний кластер, такі як Ingress Controllers, інструменти Observability, GitOps оператори тощо.


71 (58.2%) респондент не звʼязує життєвий цикл плагінів із життєвим циклом кластерів.

Хоча 32 (26.2%) привʼязують життєвий цикл деяких плагінів до життєвого циклу кластера.

16 (13.1%) респондентів створюють новий кластер кожного разу, коли мають необхідність оновити один із плагінів.

Декілька людей не змогли відповісти на це запитання.

Періодичність оновлень виглядає наступним чином:


  • 65 (53.3%) не мають специфічної політики щодо оновлень плагінів.
  • 22 (18%) оновлюють плагіни, якщо знайшли багу чи вразливість.
  • 21 (17.2%) оновлюють плагіни за графіком.
  • 13 (10.7%) оновлюються, коли доступна нова версія плагіну.

Інструменти, які використовуються для менеджменту плагінів:

  • Helm посідає перше місце за популярністю із 89 (73%) користувачами.
  • Terraform займає друге місце із 82 (67.2%).
  • ArgoCD — третє із 47 (38.5%).
  • FluxCD вдвічі менш популярний за ArgoCD із 21 (17.2%) користувачем.
  • Не є несподіванкою, що це питання має довгий «хвіст» з інструментів, що люди використовують для менеджменту плагінів.

Маю зауважити, що це питання мало можливість мультивибору, а отже загальна сума перевищує 100%.

Гомогенність оточень


Цей параграф присвячений гомогенності оточень (dev, staging, production тощо). Більшість респондентів — 97 (79.5%) — мають однакову версію як Kubernetes, так і його плагінів для різних оточень. Ця цифра включає людей, що використовують один кластер для всіх оточень (1 людина) і тих, хто підіймає кластери по запиту. Це є хорошим знаком, оскільки дає надію, що Kubernetes трошки наближує нас до стандартизації між продакшн і не продакшн оточеннями.

11 (9%) респондентів мають однакову версію Kubernetes, але різні версії плагінів і 5 (4.1%) мають різні плагіни у різних оточеннях.

8 (6.6%) відповіли, що мають різну версію Kubernetes у різних оточеннях і ще одна людина не змогла дати відповідь на це питання.

Disaster Recovery


Тільки 18 (14.8%) респондентів відповіли, що мають вибудований disaster recovery план і регулярно його тестують. 29 (23.8%) сказали, що мають план і тестували його хоча б один раз і 41 (33.6%) відповіли, мають план, але ніколи його не тестували. 34 (27.9%) респонденти відповіли, що не мають disaster recovery плану взагалі.


Проте 47 (38.5%) респондентів заявили, що можуть відновити кластер за допомогою GitOps підходу. Отже, вони не роблять бекапи своїх кластерів.

24 (19.7%) респонденти використовують інструменти для бекапу як, наприклад, Velero і 15 (12.3%) роблять снепшоти ETCD. 36 (29.5%) людей сказали, що не мають бекапів своїх кластерів.

The Fun Part

Як і минулого року, я ставив питання: «Яким був ваш найболючіший досвід роботи із Kuberentes?».

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

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

Всі відповіді доступні у Гугл таблицях.

Що далі?

Додатково мені дали фідбек, що не вистачало питань стосовно Observabiliy. Це слушне зауваження, тож я обовʼязково додам ці питання наступного року.

Дякую за увагу! Якщо вам було цікаво — підпишіться на CatOps в Telegram.

Слава Україні!

#kubernetes #devops #sre

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі