Так, ну что, митап закончился, напишу свои впечатления ✨

Доклады не такие, к которым мы привыкли на больших конференциях, это факт)
Более короткие (по полчасика), более прикладные (показывали много кода на scala и java), менее структурированные))

Парочка инсайтов:
• я ещё раз подтвердила для себя мысль о том, что язык это просто инструмент и что когда умеешь программировать, неважно на чём
• мне уже интереснее размышлять о системах и подходах в целом, на более высоких уровнях абстракции, код смотреть неинтересно :)
• в яндексе люди решают такие же задачи, как и в других компаниях, хотя лично у меня всегда было впечатление, что они уже всё решили))))

Всё, ребята, привела в порядок свои цифровые каракули, теперь рассказываю!

Мне понравился первый доклад из 4х, поэтому расскажу про него.
Называется Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке. Максим Чудновский. Сбертех.

Максим рассказал, с какими проблемами сталкиваются владельцы большого кластера, в котором живёт множество команд и как их нивелировать.

В любом кластере k8s важно следить, чтобы приложениям давались минимальные полномочия, образы были доверенные, была реализована правильная работа с секретами, было некое единообразие и соответствие стандартам организации.

Когда команд много, Helm чарты и Kustomize не спасают, т.к. у каждой команды свои настройки, свой релизный цикл и повторное применение какого-нибудь helm чарта с сайдкаром на весь кластер может стать проблемой.

K8s предоставляет автоматизацию применения политик с помощью Admission Controller’ов.

1. Validation Admission
Валидирует сущности кубера при создании. Если сущность не удовлетворяет политикам и стандартам - возвращает ошибку.

2. Mutation Admission
Исправляет ошибки пользователя за него.

3. Operators
Это управление функциональным доменом в рамках кластера. Если у приложения сложное развертывание, можно инкапсулировать эту сложность в оператор.

———
У нас кластер маленький, команд мало, автоматизации сейчас нет, поэтому я теперь во всех чатах умничаю, что нам нужны адмишен контроллеры 🤣 Хочу чтобы всё красиво, автоматизированно

Для больших кластеров в которых живёт множество команд, такой автоматизации может быть недостаточно. Разным командам требуется разный профиль использования кубера, сервис меша. Появляется огромное количество веб хуков, которые применяются к большому числу объектов в кластере и начинают конфликтовать.
Тем более оказывается что в k8s веб хуки исполняются по алфавиту)))

Один из подходов, который предлагается для решения этой проблемы - генерализация создания вебхуков.

Например, реализуется один Mutation Webhook Server, который обрабатывает все мутации. В него встраивается оператор, который принимает шаблон-описание политики и триггер (признак, по которому определяется, к каким объектам применить политику). Триггером может быть лейбл, анноташка и т.д.
Таким образом всё что идёт в кластер приводится в целевое состояние, соответствующее требованиям, которые на кластер возлагаются.

Сбертех сделал свою реализацию этого подхода — инструмент Kubelatte, про который можно почитать туть.

Коротко скажу, что они реализовали сущности:

1. Generic Sidecar Injector - тут всё понятно

2. Generic Mutation Manager - мутирует все сущности по заданному шаблону с заданным тригером

3. Generic Validation Manager - содержит два типа валидаций - внутренние и внешние. Внутренние валидируют yaml’ы, сгенерированные Kubelatte, чтобы не было yaml-инъекций. Внешние проверяют то, что пользователь загружает в Kubelatte

4. Generic Creation Manager - генерирует группу ресурсов по запросу клиента. Например, когда множество команд ходит на какой-то внешний ресурс и каждой команде приходится настраивать gateway и открывать трафик на этот ресурс через Service Mesh

Что ещё было на конфе:

• Доклад Единое рабочее пространство администратора, или Когда закончилось место на панели вкладок - ребята из Сбера рассказали каким инструментом пользуются администраторы для контроля АС, работы с инцидентами и так далее. Для меня эта тема пока-что мимо.

• Разделение на dev/master-ветки при деплое на стенды: паттерн или антипаттерн? - Семён Киреков из МТС рассказал про ситуации, которые могут возникнуть если использовать dev/master ветки. Вместо них он предлагает использовать trunk-based development с feature flags. Доклад получился холиварный, имхо примеры были надуманные, как-будто разработчик с закрытыми глазами пользуется гитом))

• Как мы в Сбере предоставляем техническую поддержку сотрудникам. Дмитрий из Сбера рассказал, как построили сервис, оказывающий тех. поддержку для 250к сотрудников. Тема тоже мимо меня)