Так же, как и многие другие компании, мы долго и счастливо использовали целый стек популярных облачных сервисов (Github, Slack, Jira, Confluence и т.д.) и связывал это все Google Workspace, который выступал в том числе и как SSO для всех используемых сервисов.

В связи с последними событиями нам пришлось достаточно быстро искать и реализовывать альтернативу из отечественных сервисов и open source продуктов. При этом одним из требований стало использование общей с «офисными»
и почтовыми сервисами точки аутентификации.

В этой статье я расскажу о том, как мы решали задачу создания SSO поверх выбранного поставщика почтового и «офисных» сервисов для используемых нами приложений с помощью Keycloak и с какими проблемами мы при этом столкнулись.

Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

Это обновление моего предыдущего бенчмарка, который теперь работает на Kubernetes 1.14 с актуальной версией CNI на апрель 2019 года.

Во-первых, хочу поблагодарить команду Cilium: ребята помогли мне проверить и исправить скрипты мониторинга метрик.

Что изменилось с ноября 2018

Вот что изменилось с тех пор (если интересно):

Flannel остается самым быстрым и простым интерфейсом CNI, но все еще не поддерживает сетевые политики и шифрование.

Romana больше не поддерживается, так что мы удалили ее из бенчмарка.

WeaveNet теперь поддерживает сетевые политики для Ingress и Egress! Но производительность снизилась.

В Calico все еще нужно вручную настраивать максимальный размер пакета (MTU) для лучшей производительности. Calico предлагает два варианта установки CNI, так что можно обойтись без отдельного хранилища ETCD:

CD признано в качестве практики разработки корпоративного программного обеспечения, это — результат естественной эволюции устоявшихся принципов CI. Однако CD по-прежнему довольно редкое явление, возможно, из-за сложности управления и страха перед неудачными деплоями, влияющими на доступность системы.

Flagger — это оператор Kubernetes с открытым исходным кодом, цель которого — исключить запутанные взаимосвязи. Он автоматизирует продвижение canary деплоев, используя смещение трафика Istio и метрик Prometheus, чтобы анализировать поведение приложения во время управляемого роллаута.

Ниже приведено пошаговое руководство по настройке и использованию Flagger в Google Kubernetes Engine (GKE).

Итак, у вас есть кластер Kubernetes, а для проброса внешнего трафика сервисам внутри кластера вы уже настроили Ingress-контроллер NGINX, ну, или пока только собираетесь это сделать. Класс!

Я тоже через это прошел, и поначалу все выглядело очень просто: установленный NGINX Ingress-контроллер был на расстоянии одного helm install. А затем оставалось лишь подвязать DNS к балансировщику нагрузки и создать необходимые Ingress-ресурсы.

Спустя несколько месяцев весь внешний трафик для всех окружений (dev, staging, production) направлялся через Ingress-серверы. И все было хорошо. А потом стало плохо.

Все мы отлично знаем, как это бывает: сначала вы заинтересовываетесь этой новой замечательной штукой, начинаете ей пользоваться, а затем начинаются неприятности.