Автор: Дмитрий Самохвалов · HighLoad++ Channel

Доклад с HighLoad++ 2024, 49 минут. Kubernetes великолепно работает внутри себя. Проблемы начинаются на границе: когда поды должны обращаться к legacy-сервисам вне кластера, а legacy-системы — к подам. Эта граница существует у большинства компаний, которые переходят на Kubernetes постепенно, а не заново строят всё с нуля.

Самохвалов разбирает конкретные конфигурации и паттерны: как работает сетевая модель Kubernetes (flat network, каждый под получает IP) и почему она не совпадает с тем, чего ждёт legacy-окружение; как CNI-плагины (Calico, Cilium, Flannel) по-разному решают задачу связности; как настроить BGP-пиринг между кластером и существующей сетевой инфраструктурой; почему NodePort и LoadBalancer — это не решение, а костыль, который работает до определённого масштаба. Это доклад не про «установите Kubernetes», а про то, что происходит когда старая и новая инфраструктура должны сосуществовать в одной сети.

Кому смотреть: DevOps- и SRE-инженерам, занимающимся миграцией на Kubernetes в организациях с существующей инфраструктурой — особенно там, где legacy не уйдёт в ближайшие годы.

Из этого можно взять в работу: если у вас поды Kubernetes обращаются к legacy-сервисам через ExternalName Service или захардкоженные IP — это временное решение, которое не масштабируется и не обеспечивает failover. Доклад показывает, как это сделать правильно.

Автор: Дмитрий Евдокимов · VK Cloud

Дмитрий Евдокимов — CTO Luntry, платформы безопасности для Kubernetes. Luntry строится поверх Kubernetes API, поэтому понимание KRM у него не теоретическое — это основа продукта. Доклад с VK Kubernetes Conference.

Kubernetes Resource Model — это абстракция, которую легко пропустить за привычными деплойментами и сервисами. Суть в том, что Kubernetes — это не оркестратор контейнеров, а universal control plane для управления любыми ресурсами. Всё, что можно описать как «желаемое состояние + текущее состояние + reconciler», может стать Kubernetes-ресурсом. Это означает, что KRM применима не только к подам, но и к облачным ресурсам, сетевым политикам, конфигурациям безопасности и вообще к любому объекту с жизненным циклом. Everything-as-Code здесь не лозунг, а архитектурное следствие: если ресурс существует в Kubernetes API, он автоматически версионируем, аудируем, управляем через GitOps.

Евдокимов объясняет, как устроены CRD (Custom Resource Definitions), как писать операторы, и почему правильно понятый KRM убирает необходимость в отдельных инструментах управления конфигурацией для многих сценариев.

Кому смотреть: platform engineering командам и SRE, которые уже используют Kubernetes и думают о расширении его за пределы стандартных ресурсов — управление инфраструктурой, политиками, секретами через единый API.

Из этого можно взять в работу: посмотри, какие операции ты делаешь через скрипты или сторонние инструменты, которые по сути управляют состоянием системы. Можно ли выразить это как Kubernetes-ресурс с оператором? Если да — ты получаешь GitOps, аудит и версионирование бесплатно.