Вы находитесь на странице: 1из 31

10 причин [не]

использовать k8s
Евгений Афанасьев
DevOps Engineer TeamLead, Viseven
e.afanasyev@viseven.com
Почему это вообще важно
▪ Почему X лучше чем Y ?
▪ Puppet/Chef/Ansible/Bash+SSH - уже достаточно хороши
▪ Критерии:
▪ Время от коммита до релиза
▪ Автоматизация сборки, тестов, релиза
▪ CI/CD
▪ Количество прилагаемых усилий
Очень быстрое
погружение в k8s
• Masters - Workers (Nodes)
• API, CLI
• Namespaces
• Pod, Labels, Selectors
• ReplicaSet, Services, Deployments
Важность для разработчиков
▪ Повторяемость
▪ Стандартизированное окружение
▪ Упрощенная процедура тестирования
▪ CI
Важность для релиз-инженеров
▪ Иммутабельная инфраструктура
▪ Инфраструктура как код
▪ Идемпотентность
▪ Релиз одной кнопкой (почти)
▪ Простота и скорость отката релиза
▪ Интроспекция и анализ проблем
▪ CD
Заблуждения
▪ Контейнеры - это облегченные виртуальные машины
▪ k8s делает ваше приложение более защищенным
▪ k8s автоматически делает ваше приложение скалируемым
▪ k8s работает с любой ОС без проблем
Опыт внедрения
▪ Нужен большой дополнительных стек вокруг k8s
▪ Требуется изучение большого стека технологий
▪ Нужно беспокоиться об отказоустойчивости многих сервисов этого стека
Helm
▪ Это пакетный менеджер для Kubernetes
▪ Client (helm) + Server (Tiller: etcd)
▪ Chart (yaml) + templates (yaml) + values (yaml)
▪ Позволяет скачивать (из репы), устанавливать,
откатывать пакеты
▪ Работает с плагинами
Внутренний репозиторий образов
▪ Внутренний репозиторий (Docker Distribution)
▪ Высокая цена поддержки:
▪ Требуется отказоустойчивость (поломки ssd, сети, самой машины)
▪ GC (масса устаревших и/или больших образов)
▪ Высокая нагрузка
Внешний репозиторий образов
▪ DockerHub как внешний репозиторий образов
▪ Чаще всего непубличные образы: Secrets -> imagePullSecrets
Опыт: Kubespray
▪ HA мастер-ноды, идемпотентность (state-sync модель), addons, …
▪ Ansible playbook
▪ Тонкая настройка, большое количество параметров
▪ Проблемы при обновлении/добавлении нод (multimaster)
▪ Использование динамических inventory
Опыт: Pharos Cluster
▪ HA мастер-ноды, идемпотентность (state-sync модель), addons, …
▪ Ruby + terraform
▪ Простота + надёжность
▪ Нулевое время простоя во время rolling upgrades (multimaster)
CRI (container runtime interface)
▪ Много вариантов
▪ Docker <=17.03
▪ CRI-O
▪ containerd
CRI (container runtime interface)
Сети
▪ Много вариантов
▪ Pharos поддерживает только часть из них (Calico, Weave, …)
▪ Можно использовать другие CNI провайдеры
▪ Лучше использовать самые популярные: лучше протестированы
Опыт: Weave
▪ L2
▪ Хорошо работает с минимальным количеством проблем
▪ Не использует внешнее хранилище
▪ Достаточно TCP/UDP по 6783 и 6784 порту
Опыт: HA
▪ 5 Master-нод, синхронизация по etcd. Можно 7/9.
▪ Keepalived/VIP/Route53 healthcheck
▪ Cordon/evict
▪ Pod antiaffinity
Квоты и доступ
▪ RBAC (Role-Based Access Control) намного лучше чем ABAC
▪ RBAC, ограничение доступа - по namespace
▪ LDAP и ключи для авторизации
Телеметрия
Опыт: Prometheus
▪ Хороший язык запросов, алерты
▪ K8s уже экспортирует совместимые метрики
▪ Prometheus operator
▪ Агрегация с нескольких кластеров с помощью federation
▪ Приложение имеет endpoint для метрик
▪ Grafana для визуализации
Опыт: Логирование
▪ Требование: отсутствие дополнительных действий от пользователя, печать в
stdout/stderr
▪ Fluentd -> Graylog
▪ Зависит от CRI/OS
▪ Stern, kubectl
▪ Фильтры и трансформация в graylog
Разработка в k8s
Ад разработчика
▪ “Docker-way”
▪ Компромиссы:
▪ Создавать образ в CI Pipeline <-> Обновлять образ FS на лету
▪ Запускать тесты локально <-> Делать коммит, чтобы CI проверил
▪ Запускать окружение <-> Эмулировать (mock) окружение
Инструменты разработчика
▪ Helm Charts: простой, понятный. Нужны дополнительные инструменты
поверх (ksonnet?)
▪ Нужна хорошая документация + организованная структура процесса (HowTo-
s, FAQ-s, “быстрое введение”, etc)
▪ CLI инструменты: kubectl / helm / drone / docker / stern / minikube
Итого: Минусы, часть 1
▪ Очень большой объем информации на изучение (не только новые
технологии, но и новые концепции и привычки)
▪ Kubernetes будет лишь [маленькой] частью вашей инфраструктуры
▪ Некоторые приложения в принципе сложно запускать на k8s, чем в
“классическом” варианте
▪ Очень многословные конфигурационные файлы (k8s/helm)
▪ Все текущие решения на рынке - сырые
Итого: Минусы, часть 2
▪ Все “менеджеры пакетов” далеки от совершенства
▪ K8s + Docker-way полностью поменяет ваши привычки разработки
▪ Очень много компромиссов, делать выбор сложно, это создает негатив и
отторжение
▪ Чтобы отладить работу на k8s локально придется хорошо постараться
Итого: Плюсы 1
▪ С течением времени все меньше придется учить новичков k8s
▪ Короткий цикл релиза. Commit -> CI -> Image -> Нажал кнопку для релиза
▪ Разделение инфраструктурного и бизнес кода
▪ Большое и очень активное сообщество, много изменений (kops, helm, stern,
geodesic, rbac, autoscaler, … - за 2 последних года)
▪ Логи приложения и k8s событий в одном месте (Kibana)
▪ Нет прямого доступа на ноды
Итого: Минусы, часть 2
▪ Не требуется поддержка или помощь ops команды для релизов или решения
проблем в продакшене
▪ Ops команда перестает быть узким местом
▪ Ops команда перестает быть “Полицией Нравов”, у всех общая цель
▪ Сильно уменьшает напряженность отношений в компании
Вопросы?
Евгений Афанасьев
e.afanasyev@viseven.com
facebook.com/evgenyjafanasyev

Оценить