У любого инфраструктурщика и backend-разработчика рано или поздно наступает тот самый момент. Ты сидишь ночью перед очередным сервисом, смотришь на очередной requirements.txt, на старом Flask-проекте, на монолитный Django, на десяток костылей вокруг асинхронности, и начинаешь задаваться вопросом:

"А почему вообще всё это настолько сложно? Может плюнуть и переписать?!"

И вот примерно в этот момент многие приходят к FastAPI.

Есть в жизни инфраструктурщика несколько стадий взросления.

1. Сначала ты создаешь пользователей руками на каждом сервере.
2. Потом понимаешь, что количество серверов растет и начинаешь писать скрипты на bash
3. Позже растешь и начинаешь писать роли на Ansible и Terraform.
4. Бам и у тебя 400 серверов, 120 разработчиков, 20 “временных подрядчиков”, которые работают уже третий год, и один одинаковый ssh ключ на всех стендах (бывает и хуже - одинаковый пароль вида qwe123).

Еще в 2022 году стало понятно, что эпоха “вечного VMware” подходит к концу, но тогда многие компании решили, что время еще есть. Сегодня уже очевидно: инфраструктурная зависимость от VMware превращается в серьезный бизнес-риск, потому что большие VMware-инфраструктуры стали слишком дорогими, слишком сложными и слишком привязанными к экосистеме, правила которой компании больше не контролируют. Проблема в том, что сотни production VM, legacy Windows, SAN, ERP и HA-кластеры невозможно перевезти “за выходные”, особенно если инфраструктура последние десять лет росла по принципу “работает - не трогай”, а значит готовиться к миграции нужно было еще несколько лет назад. Именно поэтому Proxmox VE сегодня перестает быть “решением для лабораторий” и становится реальным способом вернуть контроль над виртуализацией, снизить зависимость от поставщика и успеть переехать раньше, чем миграция превратится в аварийный проект с горящими дедлайнами, ночными rollback и очень нервными разговорами с бизнесом.

Когда компания маленькая, архитекторов обычно нет. Есть разработчик Алеша, системный администратор Димон и руководитель Саша, который говорит сакральную фразу:

"Да что там делать, поднимите сервер, выкатите приложение. Делов-то!".

Потом компания растет. Появляются Kubernetes, микросервисы, Clickhouse, десять команд разработки, пять облаков, семь подрядчиков, бюджеты на миллионы рублей и внезапное осознание:

"Кажется, нам нужен человек, который понимает, как это вообще должно работать вместе".

Так в компании появляются архитекторы.

И именно в этот момент ИТ перестает быть набором случайных серверов и превращается в инженерную систему.

Когда-то давно разработчик открывал IDE, пил кофе, писал код, ругался на NullPointerException, снова пил кофе и шел фиксить прод.

Сейчас разработчик открывает IDE, а рядом уже сидит цифровой коллега, который:

• предлагает архитектуру,
• пишет код,
• сам делает рефакторинг,
• запускает тесты,
• чинит линтер,
• иногда даже объясняет почему оно не работает лучше, чем тот человек, который это писал.

И вот тут начинается самое интересное.

Есть два типа Kubernetes-кластеров.

В первом люди хранят секреты в values.yaml, коммитят .env в Git и называют это “временным решением”.

Во втором - поднимают HashiCorp Vault, настраивают auto unseal, раздают доступ через Kubernetes Auth, а потом спокойно пьют кофе, пока остальные экстренно ротируют токены после очередного “ой”.

Сегодня - как раз про второй вариант.

Еще пару лет назад рынок ИТ напоминал черную пятницу в торговом центре.

Люди после курсов “DevOps за 3 месяца” массово шли менять профессию. HR писали всем подряд. Зарплаты росли быстрее курса доллара. А слово Kubernetes произносили так, будто это заклинание на +300к к зарплате.

Потом случилась суровая встреча с реальностью.

Вот какой вопрос я задаю очень часто на собеседовании:

- Если вы подняли на дефолтных настройках, по мануалам из интернета, кластер с помощью kubespray, что будет, если выключить первый мастер?

- Все будет хорошо! Ведь это Kubernetes!

- Кластер превратится в тыкву. Давайте попробую объяснить...

И, после этого, я пробую объяснить. Но, лучше, опишу это в статье.