Иван Круглов, Booking.com
1500 человек, 30 000 серверов.
Состав:
- ServerDB
- Puppet
- Perl & Java
- MySQL
- storage
- service discovery (Zookeeper)
- data streaming (Kafka + in-house)
- data aggregation
- graphite, переписанный на Go
- alerts/predictions (in-house)
Бизнес хочет ускорить time to market.
Есть роли серверов — server role. Новый продукт — новая роль. Надо писать puppet, открывать доступы и порты, конфигурировать-конфигурировать-конфигурироовать. ВРУЧНУЮ.
Это умеет горстка людей — это узкое звено. Они делают это дни или недели, это тоже.
Хотим: доступно всем, работает за минуты. Для решения стали строить PaaS.
Пробовали:
- marathon
- openshift
- k8s
Первые две платформы профакапили, последнюю наполовину. О том и речь в докладе.
Начался как хакатон, но так и не закончился. Не хватило фич.
Мысль 1: не стоит недооценивать способность кода выживать.
Случилась эйфория:
- Там же k8s, а его разработал Google
- Там же есть Ansible, а это круто.
- И ещё Open vSwitch, который должен был порешать все проблемы.
Раз фичи есть, хотелось их использовать, просто потому что они клёвые. А потом эйфория закончилась. Началось непонятное поведение системы.
А ещё не было нормального мониторинга, алертов и лимитов. Разработчик опечатался и заиспользовал 100500 ресурсов платформы.
Мысль 2: Cool vs. boring. Три крупных сложных системы вместе — круто, но нереально. Лучше скучно, но работает, чем интересно, но не работает.
От платформы хотели простой и удобный интерфейс. Как Heroku.
В результате: пользователей научили нажимать кнопку, а внутренности скрыли. При проблемах нужно идти и дебажить людям их приложения. Нет времени на развитие платформы.
Мысль 3: стоит сформулировать ожидание пользователей от системы и системы от пользователей.
Пользователям нужны хотя бы базовые знания о том, как платформа устроена внутри.
Новые приложения должны работать со старой системой.
Точки интеграции:
- DLB (distributed load balancing)
- service discovery
- events
- storage
- DB: MySQL, Cassandra, Redis, Kafka
- SSL certivicates, identity key management
- Secrets
Секреты в k8s:
- Не шифруются в etcd (появилось в 1.7 alpha)
- Есть Vault, который пришлось форкнуть и дописывать. Сложный, но безопасный workflow.
Мысль 4: k8s — клёво, но его интеграция в существующую экосистему компании важнее.
- Устали
- Задолбались
- Потеряли доверие пользователей
- Но был план!
-
Минимум клёвых штук. Отказ от Ansible и Open vSwitch.
-
Мониторинг инфраструктуры. Сами сообщаем, что у нас проблемы.
-
Выстроили чёткие ожидания внутри команды, между командой и пользователями:
Если вы хотите использовать платформу, вы должны 1) иметь базовые знания о k8s, 2) обеспечить свой сервис поддержкой.
и ещё ожидания с провайдерами интеграций.
-
Инвестиции в знания.
- тренинги
- онлайн-курсы
- книги
- документация
С этими идеями пришли к третьему шагу: внедрять чистый k8s.
(Пока что) не профакапленная платформа.
Сделали несколько кластеров — застраховались сами от себя. Если положат один, то только один, а не всю систему.
Архитектура:
Цель — плоская и простая сеть. Каждой ноде назначен /27, маленькая подсеть. Каждый под получает адрес, как любой физический сервер — 10.*. Между подами и другими хостами во внутренней сети — прямой доступ. Поэтому не нужен ingress.
Поощряем использование Pod IP-адреса. Экспортируем в Service Discovery и почти в DLB.
service.namespace.svc.cluster.local
service.namespace.svc.eu-nl-prod-a.booking.com
kube-probe — функциональное тестирование для k8s. Проверяет способность кластера выполнять:
- базовые функции
- сетевое соединение
- интеграции
- Есть стабильная система
- ~200 уникальных сервисов, количество растёт
- Понимаем происходящее
- Отладили взаимодействие
- Вся система самообслуживается
- Выстроили отлаженную систему обучения
- Управление ожиданиями — ключ к успеху.
- k8s хорош, но интеграция важнее.
- k8s — это экосистема, он требует понимания даже со стороны пользователей.
- важно вкладываться в обучение.