Тернии контейнеризированных приложений и микросервисов

Проблема

Бизнес хочет ускорить time to market.

Есть роли серверов — server role. Новый продукт — новая роль. Надо писать puppet, открывать доступы и порты, конфигурировать-конфигурировать-конфигурироовать. ВРУЧНУЮ.

Это умеет горстка людей — это узкое звено. Они делают это дни или недели, это тоже.

Хотим: доступно всем, работает за минуты. Для решения стали строить PaaS.

Первые попытки решения

Пробовали:

Первые две платформы профакапили, последнюю наполовину. О том и речь в докладе.

Marathon

Начался как хакатон, но так и не закончился. Не хватило фич.

Мысль 1: не стоит недооценивать способность кода выживать.

Openshift

Случилась эйфория:

Раз фичи есть, хотелось их использовать, просто потому что они клёвые. А потом эйфория закончилась. Началось непонятное поведение системы.

А ещё не было нормального мониторинга, алертов и лимитов. Разработчик опечатался и заиспользовал 100500 ресурсов платформы.

Мысль 2: Cool vs. boring. Три крупных сложных системы вместе — круто, но нереально. Лучше скучно, но работает, чем интересно, но не работает.

Проблема с деплоем

От платформы хотели простой и удобный интерфейс. Как Heroku.

В результате: пользователей научили нажимать кнопку, а внутренности скрыли. При проблемах нужно идти и дебажить людям их приложения. Нет времени на развитие платформы.

Мысль 3: стоит сформулировать ожидание пользователей от системы и системы от пользователей.

Пользователям нужны хотя бы базовые знания о том, как платформа устроена внутри.

Проблема с интеграциями

Новые приложения должны работать со старой системой.

Точки интеграции:

Секреты в k8s:

Мысль 4: k8s — клёво, но его интеграция в существующую экосистему компании важнее.

Результат двух первых попыток внедрения

План!

Если вы хотите использовать платформу, вы должны 1) иметь базовые знания о k8s, 2) обеспечить свой сервис поддержкой.

и ещё ожидания с провайдерами интеграций. * Инвестиции в знания.

* тренинги
* онлайн-курсы
* книги
* документация

С этими идеями пришли к третьему шагу: внедрять чистый k8s.

kubernetes

(Пока что) не профакапленная платформа.

Сделали несколько кластеров — застраховались сами от себя. Если положат один, то только один, а не всю систему.

Архитектура:

booking-k8s-arch

Directly Routable Pods

Цель — плоская и простая сеть. Каждой ноде назначен /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. Проверяет способность кластера выполнять:

Результаты и достижения

Заключение: