Как устроена разработка Kubernetes-платформы Deckhouse

Доклад руководителя разработки Deckhouse (https://deckhouse.ru/) Константина Аксенова на конференции HighLoad++ 2022.

Transcript

2. Обо мне Константин Аксёнов Руководитель разработки Deckhouse Kubernetes Platform konstantin.aksenov@flant.com Чем занимаюсь Больше 5 лет засыпаю и просыпаюсь с мыслями о Kubernetes. Опыт С 2011 занимаюсь разработкой. С 2017 работаю в компании «Флант». С 2020 руководитель разработки Deckhouse Kubernetes Platform. С чем работаю больше всего github.com/konstantin-axenov
3. Доклад будет интересен тем, кто Использует Kubernetes в production
4. Доклад будет интересен тем, кто Использует Kubernetes в production Только присматривается к Kubernetes
5. Доклад будет интересен тем, кто Использует Kubernetes в production Только присматривается к Kubernetes Задумывается над разработкой своего «аналога OpenShift»
6. Доклад будет интересен тем, кто Использует Kubernetes в production Только присматривается к Kubernetes Задумывается над разработкой своего «аналога OpenShift» Просто любит Open Source
7. Что вы, вообще, сделали? Взяли Kubernetes и засунули в него разные Open Source-компоненты? «Работать с Kubernetes умеет каждый»
8. Что вы, вообще, сделали? Взяли Kubernetes и засунули в него разные Open Source-компоненты? «Работать с Kubernetes умеет каждый»
9. Kubernetes — это не только YAML
10. Kubernetes — это не только YAML
11. Kubernetes — это не только YAML
12. Stateful-приложения
13. Stateful-приложения
14. Stateful-приложения Автомасштабирование и балансировка
15. Stateful-приложения Автомасштабирование и балансировка
16. Stateful-приложения Автомасштабирование и балансировка Беспростойные обновления
17. Автомасштабирование и балансировка Беспростойные обновления
18. Автомасштабирование и балансировка Беспростойные обновления Сеть и отказоустойчивость
19. Беспростойные обновления Сеть и отказоустойчивость
20. Беспростойные обновления Сеть и отказоустойчивость Безопасность
21. Сеть и отказоустойчивость Безопасность
22. Требования к Kubernetes-платформе Надежность Небольшая команда эксплуатации Идентичные Kubernetes-кластеры в любой инфраструктуре Снижение нагрузки на пользователей платформы — NoOps Безопасность
23. Поэтому мы сделали Deckhouse для себя
24. Поэтому мы сделали Deckhouse для себя
25. Управляет конфигурацией кластера и всех компонентов Устанавливает компоненты в кластер Разворачивает Kubernetes кластер Подготавливает инфраструктуру или работает поверх bare-metal
26. Управляет конфигурацией кластера и всех компонентов Устанавливает компоненты в кластер Разворачивает Kubernetes-кластер Подготавливает инфраструктуру или работает поверх bare-metal
27. Управляет конфигурацией кластера и всех компонентов Устанавливает компоненты в кластер Разворачивает Kubernetes-кластер Подготавливает инфраструктуру или работает поверх bare-metal
28. Управляет конфигурацией кластера и всех компонентов Устанавливает компоненты в кластер Разворачивает Kubernetes-кластер Подготавливает инфраструктуру или работает поверх Bare metal
29. Решает проблему айсберга
30. Решает проблему айсберга
31. Продукт с историей Первый коммит Enterprise Edition (EE) Community Edition (CE) 28 июля 2021 Июль 2020 29 сентября 2017
32. Команда Product Manager Tech Lead/Architect Engineering Manager Account Manager Release Engineer Dev Team Teamlead Developers Teamlead Developers Flant DevOps Engineers Community Dev Team Teamlead Developers Teamlead Developers
33. Жизненный цикл
34. Планирование: источники задач Product owner Сформирован roadmap до 2025 года Q4 2022 Виртуализация Q1 2023 Web UI Q3 2023 Managed Databases
35. Планирование: источники задач Product owner Команда Deckhouse Фиксы багов, работа над стабильностью CI и тесты Технический долг (переписали с Bash на Go) Обновления Kubernetes и компонентов Сформирован roadmap до 2025 года
36. Планирование: источники задач Product owner Команда Deckhouse Фиксы багов, работа над стабильностью CI и тесты Технический долг (переписали с Bash на Go) Обновления Kubernetes и компонентов Сформирован roadmap до 2025 года Пользователи Managed K8s и Enterprise-версии Баги Новая функциональность Улучшения документации DevOps Engineers
37. Планирование: источники задач Community-пользователи и большие запросы Поддержка всех возможных провайдеров Поддержка всех возможных ОС Community
38. Планирование: сортировка задач Периодичность Обработка Источник Тип Раздел Deckhouse Приоритет Один раз в неделю
39. Планирование: сортировка задач Периодичность Обработка Источник Тип Раздел Deckhouse Приоритет Один раз в неделю Планирование: релиз Минорные релизы Патч релизы По мере необходимости Один раз в две недели
40. Планирование: release flow main feature_1 feature_2 2 недели 2 недели 2 недели release-1.35 release-1.36 release-1.37
41. Планирование: release flow main feature_1 feature_2 2 недели 2 недели 2 недели release-1.36 release-1.37 release-1.35 bugfix_1
42. Планирование: release flow main feature_1 feature_2 2 недели 2 недели 2 недели bugfix_1 release-1.36 release-1.37 release-1.35
43. Разработка: GitHub Переезжали из standalone GitLab Настрадались от GitHub Actions Но GitHub по-прежнему остаётся самым популярным https://insights.stackoverflow.com/survey/2020#technology-collaboration-tools
44. Разработка: Open Source Публичные issue и changelog — доверие и уверенность Открытые исходники — прозрачность
45. Разработка: идеология Deckhouse Минимум «крутилок» Собственные интерфейсы, чтобы скрыть реализацию NoOps — безболезненные обновления платформы Cохраняем «ванильность» K8s, никаких форков
46. Разработка: идеология Deckhouse Минимум «крутилок» Собственные интерфейсы, чтобы скрыть реализацию NoOps — безболезненные обновления платформы Cохраняем «ванильность» K8s, никаких форков
47. Разработка: идеология Deckhouse Минимум «крутилок» Собственные интерфейсы, чтобы скрыть реализацию NoOps — безболезненные обновления платформы Cохраняем «ванильность» K8s, никаких форков
48. Разработка: идеология Deckhouse Минимум «крутилок» Собственные интерфейсы, чтобы скрыть реализацию NoOps — безболезненные обновления платформы Cохраняем «ванильность» K8s, никаких форков
49. Разработка: наш вклад в Kubernetes Топ-1 в России Входим в топ-150 в мире
50. Разработка: наш вклад в Open Source
51. Разработка: наш вклад в Open Source Все патчи должны быть донесены в upstream Если изменения приняли в upstream — это гарантия, что они будут работать Влияем на развитие важных для нас компонентов Дополнительная оценка наших изменений
52. Разработка: наш вклад в Open Source Все патчи должны быть донесены в upstream Если изменения приняли в upstream — это гарантия, что они будут работать Влияем на развитие важных для нас компонентов Дополнительная оценка наших изменений Наш пример с containerd
53. Тестирование Модульные тесты Helm, hook’ов, OpenAPI Модульные матричные тесты E2E-тесты для каждого провайдера и конфигурации E2E-тесты обновления минорной версии Deckhouse Линтеры кода, линтеры шаблонов, валидаторы и прочее
54. Тестирование: множество провайдеров Облачные платформы Другие варианты
55. Тестирование: разные схемы размещения Стандарт Без NAT В уже существующей сети
56. Тестирование: множество вариантов ОС и версий Kubernetes РЕД ОС Версии: 7.1 AlterOS Версии: 7 Astra Linux Special Edition Версии: 1.7 CentOS Версии: 7, 8, 9 Debian Версии: 9, 10, 11 Ubuntu Версии: 16.04, 18.04, 20.04, 22.04 Kubernetes Версии: 1.20, 1.21, 1.22, 1.23, 1.24
57. Тестирование: множество вариантов всего Поддержка 2-х CRI: Docker и сontainerd Поддержка 2-х CNI: flannel и Cilium Несколько десятков модулей
58. Тестирование: множество вариантов всего Поддержка 2-х CRI: Docker и containerd Поддержка 2-х CNI: flannel и Cilium Несколько десятков модулей
59. Разработка и тестирование: важные моменты Публичная разработка дала нам только плюсы Следует приносить изменения во все используемые Open Source-проекты У продукта должна быть идеология и правила Тесты — это хорошо, но всё протестировать невозможно
60. Разработка и тестирование: важные моменты Публичная разработка дала нам только плюсы Следует приносить изменения во все используемые Open Source-проекты У продукта должна быть идеология и правила Тесты — это хорошо, но всё протестировать невозможно И как же мы решили проблему с тестами?
61. Разработка и тестирование: важные моменты И как же мы решили проблему с тестами? Нужен правильно выстроенный релизный процесс! Публичная разработка дала нам только плюсы Следует приносить изменения во все используемые Open Source-проекты У продукта должна быть идеология и правила Тесты — это хорошо, но всё протестировать невозможно
62. Релиз: уверенность Каналы обновлений Очередность выката Окна обновлений Ручные обновления
63. Релиз: уверенность Каналы обновлений Очередность выката Окна обновлений Ручные обновления Менее стабильные Более стабильные Alpha Beta Early Access Stable Rock Solid
64. Релиз: уверенность Каналы обновлений Очередность выката Окна обновлений Ручные обновления flow.deckhouse.io
65. Релиз: уверенность Каналы обновлений Очередность выката Окна обновлений Ручные обновления flow.deckhouse.io
66. Релиз: уверенность Каналы обновлений Очередность выката Окна обновлений Ручные обновления flow.deckhouse.io
67. Релиз: уверенность Каналы обновлений Очередность выката Окна обновлений Ручные обновления
68. Релиз: уверенность Каналы обновлений Очередность выката Окна обновлений Ручные обновления Your Deckhouse is waiting for the v1.36.5 update approval $ kubectl patch deckhouserelease v1-36-5 \ --type=merge -p='{"approved": true}'
69. Релиз: люди Релиз-инженер Оповещение пользователей Отслеживание процесса релиза (телеметрия и логи) Первичная обработка входящих ошибок по проблемам во время обновления
70. Релиз: люди Релиз-инженер Оповещение пользователей Отслеживание процесса релиза (телеметрия и логи) Первичная обработка входящих ошибок по проблемам во время обновления Ответственный за релиз Своевременная «заморозка» кодовой базы Проверка changelog’а Проверка E2E по обновлению релиза Финальное согласование выката Поддержка релиз-инженера
71. Релиз: отслеживание Логи deckhouse-controller Аудит-логи с kube-apiserver Телеметрия с информацией о кластере
72. Релиз: отслеживание Логи deckhouse-controller Аудит-логи с kube-apiserver Телеметрия с информацией о кластере Всё это собирается только с кластеров под нашим управлением
73. Релиз: телеметрия
74. Релиз: телеметрия
75. Релиз: телеметрия
76. Релиз: телеметрия
77. Релиз: процесс обновления v1.36.3 v1.36.4 registry.deckhouse.io
78. Релиз: процесс обновления v1.36.3 v1.36.4 registry.deckhouse.io stable An OCI formatted image release.yml
79. Релиз: процесс обновления stable v1.36.3 v1.36.4 registry.deckhouse.io tag: v1.35.9
80. Релиз: процесс обновления stable v1.36.3 v1.36.4 registry.deckhouse.io tag: v1.35.9
81. Релиз: процесс обновления Deckhouse Release v1.36.3 stable v1.36.3 v1.36.4 registry.deckhouse.io tag: v1.35.9
82. Релиз: процесс обновления Deckhouse Release v1.36.3 stable v1.36.3 v1.36.4 registry.deckhouse.io tag: v1.35.9 Проверка требований
83. Релиз: процесс обновления Deckhouse Release v1.36.3 tag: v1.36.3 stable v1.36.3 v1.36.4 registry.deckhouse.io
84. Релиз: процесс обновления Deckhouse Release v1.36.3 tag: v1.36.3 stable v1.36.3 v1.36.4 registry.deckhouse.io
85. Релиз: процесс обновления Deckhouse Release v1.36.3 Deckhouse Release v1.36.4 tag: v1.36.3 stable v1.36.3 v1.36.4 registry.deckhouse.io
86. Релиз: процесс обновления Deckhouse Release v1.36.3 Deckhouse Release v1.36.4 tag: v1.36.4 stable v1.36.3 v1.36.4 registry.deckhouse.io
87. Релиз: процесс обновления Deckhouse Release v1.36.3 Deckhouse Release v1.36.4 tag: v1.36.4 stable v1.36.3 v1.36.4 registry.deckhouse.io
88. Релиз: интересные случаи Observed a panic Проблема: Помогли каналы обновлений и FE-редакция Сделали E2E для проверки обновлений релизов Cломался механизм обновления Deckhouse controller Решение:
89. Старый Docker Релиз: интересные случаи Проблема: Остановили канареечный релиз на Early Access Прекратили поддержку Docker 18.09 При обновлении kubelet зависали узлы с Docker 18.09 Решение:
90. Deprecated API Релиз: интересные случаи Проблема: 10 ударов плетью для тимлида команды разработки Надо обязательно ставить себя на место пользователя Пользователям пришлось дважды править устаревшие API в одном репозитории Решение:
91. Релиз: важные моменты Ретроспектива релиза Главное — делать выводы из ошибок Нельзя катать по ночам :)
92. Эксплуатация Большая сервисная история Дежурный инженер, дежурный по установке кластеров Целая команда разработчиков on-call для решения клиентских проблем А ещё есть постоянные демо, пилоты и внедрения
93. Эксплуатация: внимание к проблемам на стыке Пользователи Поддержка Приложение Платформа
94. Эксплуатация: внимание к проблемам на стыке Пользователи Поддержка Приложение Платформа
95. Эксплуатация: внимание к проблемам на стыке Пользователи Поддержка Приложение Платформа
96. Эксплуатация: внимание к проблемам на стыке Пользователи Поддержка Приложение Платформа
97. Эксплуатация: сервис Пришел инженер и в live-режиме решил проблему. Спасибо, вы нас спасли.
98. Итоги У продукта должна быть идеология и правила Протестировать всё невозможно, но правильные процессы закрывают проблему Релизы нужно обязательно катать часто, но безопасно и незаметно Клиенты ценят сервис Обязательно нужно проводить ретроспективу и анализировать ошибки
99. Что вы, вообще, сделали? Взяли Kubernetes и засунули в него разные Open Source-компоненты? «Работать с Kubernetes умеет каждый»
100. Что вы, вообще, сделали? Взяли Kubernetes и засунули в него разные Open Source-компоненты? «Работать с Kubernetes умеет каждый»
101. Флант flant.ru GitHub github.com/deckhouse Блог habr.com/company/flant Вакансии job.flant.ru deckhouse.io Константин Аксёнов konstantin.aksenov@flant.com