Тимлид в инфраструктуре: человек, которого подозревают в безделье, пока не падает прод

Когда человек впервые слышит аббревиатуру IDM, обычно происходит одна из двух вещей.

Разработчик делает умное лицо и произносит: "А, Identity Management...". Инфраструктурщик же тяжело вздыхает, потому что мгновенно вспоминает очередной ночной инцидент, в ходе которого выяснилось, что бывший сотрудник, уволившийся ещё несколько месяцев назад, по-прежнему может подключиться к production через старый VPN. А если повезёт особенно сильно, то у него ещё обнаружится действующий Jenkins token, забытый kubeconfig и сервисный аккаунт, который когда-то создавался "буквально на пару дней".

И именно в этот момент становится понятно, что IDM - это не про логин и пароль.

Еще несколько лет назад разговоры о замене VMware воспринимались как попытка сэкономить ради самой экономии. Практически в любой крупной компании можно было услышать один и тот же аргумент: "VMware дорогой, зато надежный". Инфраструктурные команды привыкли к знакомым инструментам, процедуры эксплуатации были отлажены годами, а сам гипервизор казался чем-то настолько фундаментальным, что его замена выглядела почти невозможной. Однако изменения на рынке заставили многие организации пересмотреть эти убеждения. Рост стоимости лицензий, ужесточение условий использования и усиливающаяся зависимость от одного поставщика сделали вопрос миграции не теоретическим, а вполне практическим.

Сразу хочется сделать одно важное уточнение. Всё, что будет написано ниже, не является рекламой и не претендует на абсолютную объективность. Это взгляд инженера, который успел поработать с разными вариантами эксплуатации Kubernetes - от полностью самособранных кластеров на базе kubeadm до платформенных решений, внедрённых в крупных корпоративных инфраструктурах. Это опыт человека, который обновлял кластеры в рабочее время и восстанавливал их ночью, спорил с отделами информационной безопасности, искал причины деградации сети между площадками и объяснял бизнесу, почему фраза "просто обновите Kubernetes" на практике редко оказывается простой задачей. Среди этих решений был и Deckhouse, поэтому дальнейший рассказ основан не на презентациях и маркетинговых материалах, а на наблюдениях, сделанных во время реальной эксплуатации.

Есть в мире Kubernetes вещи вечные.

Например:

• разработчик, который «ничего не менял»;
• DevOps-инженер, который в 02:47 смотрит tcpdump с глазами человека, увидевшего бездну;
• и выбор CNI-плагина, который превращается в религиозный спор похлеще Vim против Nano.

Каждый Kubernetes-кластер рано или поздно приходит к вопросу:

А что вообще ставить для сети?

Есть два типа компаний:

1. Те, кто уже внедрил Kubernetes и теперь ходят с глазами человека, пережившего три переезда дата-центра и миграцию из Oracle в Postgres.
2. Те, кто только собирается его внедрять, потому что «у конкурентов уже есть».

K3S Ansible Stack

Полный Kubernetes стек на базе K3S с HA (High Availability), управляемый через Ansible внутри Docker-контейнера. Ansible, Helm и kubectl устанавливать не нужно — всё работает через make.