Трансляция 👀
https://www.youtube.com/watch?v=bRv-_ePBmL8
12:00 — Открытие митапа
12:10 — Java и Kotlin в Яндекс Финтехе
12:40 — Как строить надежные цепочки интеграций в облаке, чтобы пользователь мог изменить заказ на лету
13:10 — Взболтать, но не смешивать - пробуем *Gpt в быту разработчика
13:40 — Перерыв
14:10 — Разработка на Scala - проще, чем кажется
14:40 — Отказоустойчивая архитектура Java сервисов для отправки пуш нотификаций в мобильные приложения Яндекса
15:10 — Закрытие митапа
https://www.youtube.com/watch?v=bRv-_ePBmL8
12:00 — Открытие митапа
12:10 — Java и Kotlin в Яндекс Финтехе
12:40 — Как строить надежные цепочки интеграций в облаке, чтобы пользователь мог изменить заказ на лету
13:10 — Взболтать, но не смешивать - пробуем *Gpt в быту разработчика
13:40 — Перерыв
14:10 — Разработка на Scala - проще, чем кажется
14:40 — Отказоустойчивая архитектура Java сервисов для отправки пуш нотификаций в мобильные приложения Яндекса
15:10 — Закрытие митапа
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5⚡2👍2
Так, ну что, митап закончился, напишу свои впечатления ✨
Доклады не такие, к которым мы привыкли на больших конференциях, это факт)
Более короткие (по полчасика), более прикладные (показывали много кода на scala и java), менее структурированные))
Парочка инсайтов:
• я ещё раз подтвердила для себя мысль о том, что язык это просто инструмент и что когда умеешь программировать, неважно на чём
• мне уже интереснее размышлять о системах и подходах в целом, на более высоких уровнях абстракции, код смотреть неинтересно :)
• в яндексе люди решают такие же задачи, как и в других компаниях, хотя лично у меня всегда было впечатление, что они уже всё решили))))
Доклады не такие, к которым мы привыкли на больших конференциях, это факт)
Более короткие (по полчасика), более прикладные (показывали много кода на scala и java), менее структурированные))
Парочка инсайтов:
• я ещё раз подтвердила для себя мысль о том, что язык это просто инструмент и что когда умеешь программировать, неважно на чём
• мне уже интереснее размышлять о системах и подходах в целом, на более высоких уровнях абстракции, код смотреть неинтересно :)
• в яндексе люди решают такие же задачи, как и в других компаниях, хотя лично у меня всегда было впечатление, что они уже всё решили))))
👍16❤7🔥6🌭2
Всё, ребята, привела в порядок свои цифровые каракули, теперь рассказываю!
Мне понравился первый доклад из 4х, поэтому расскажу про него.
Называется Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке. Максим Чудновский. Сбертех.
Максим рассказал, с какими проблемами сталкиваются владельцы большого кластера, в котором живёт множество команд и как их нивелировать.
В любом кластере k8s важно следить, чтобы приложениям давались минимальные полномочия, образы были доверенные, была реализована правильная работа с секретами, было некое единообразие и соответствие стандартам организации.
Когда команд много, Helm чарты и Kustomize не спасают, т.к. у каждой команды свои настройки, свой релизный цикл и повторное применение какого-нибудь helm чарта с сайдкаром на весь кластер может стать проблемой.
K8s предоставляет автоматизацию применения политик с помощью Admission Controller’ов.
1. Validation Admission
Валидирует сущности кубера при создании. Если сущность не удовлетворяет политикам и стандартам - возвращает ошибку.
2. Mutation Admission
Исправляет ошибки пользователя за него.
3. Operators
Это управление функциональным доменом в рамках кластера. Если у приложения сложное развертывание, можно инкапсулировать эту сложность в оператор.
———
У нас кластер маленький, команд мало, автоматизации сейчас нет, поэтому я теперь во всех чатах умничаю, что нам нужны адмишен контроллеры 🤣 Хочу чтобы всё красиво, автоматизированно
Мне понравился первый доклад из 4х, поэтому расскажу про него.
Называется Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке. Максим Чудновский. Сбертех.
Максим рассказал, с какими проблемами сталкиваются владельцы большого кластера, в котором живёт множество команд и как их нивелировать.
В любом кластере k8s важно следить, чтобы приложениям давались минимальные полномочия, образы были доверенные, была реализована правильная работа с секретами, было некое единообразие и соответствие стандартам организации.
Когда команд много, Helm чарты и Kustomize не спасают, т.к. у каждой команды свои настройки, свой релизный цикл и повторное применение какого-нибудь helm чарта с сайдкаром на весь кластер может стать проблемой.
K8s предоставляет автоматизацию применения политик с помощью Admission Controller’ов.
1. Validation Admission
Валидирует сущности кубера при создании. Если сущность не удовлетворяет политикам и стандартам - возвращает ошибку.
2. Mutation Admission
Исправляет ошибки пользователя за него.
3. Operators
Это управление функциональным доменом в рамках кластера. Если у приложения сложное развертывание, можно инкапсулировать эту сложность в оператор.
———
У нас кластер маленький, команд мало, автоматизации сейчас нет, поэтому я теперь во всех чатах умничаю, что нам нужны адмишен контроллеры 🤣 Хочу чтобы всё красиво, автоматизированно
👍11🔥5👏3🌭1
Для больших кластеров в которых живёт множество команд, такой автоматизации может быть недостаточно. Разным командам требуется разный профиль использования кубера, сервис меша. Появляется огромное количество веб хуков, которые применяются к большому числу объектов в кластере и начинают конфликтовать.
Тем более оказывается что в 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
Тем более оказывается что в 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
👍7🔥4👏3🌭1