OpenTofu в 2026 году: почему именно этот инструмент становится фундаментом современной инфраструктуры

Есть один очень характерный этап взросления инфраструктуры.

Сначала все выглядит прекрасно:

• один backend,
• один nginx,
• один PostgreSQL,
• один frontend,
• и один человек, который “примерно помнит где лежат конфиги”.

Все просто. Все понятно. Все работает.

Знаете эту боль? Сначала вы ставите Keycloak «на пробу» на пару месяцев. Всё летает. Вы даёте ссылку на auth.myapp.ru разрабам. А потом бац - прод, 10 тысяч пользователей, и Keycloak внезапно говорит: «Я устал, я ухожу, и все сессии с собой забираю». Мммм. Классика!

И тут из-за угла, на белом коне (слегка прихрамывающем, потому что JVM жрёт память) приезжает кластерный Keycloak.

Есть два типа инфраструктурных инженеров:

- те, у кого сертификаты лежат в

/root/certs-final-final-REAL/

- и те, кто уже поставил себе нормальный PKI на HashiCorp Vault.

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

“А может хватит руками генерировать сертификаты в три часа ночи через openssl?”

И тут появляется Vault PKI.

Интернет задумывался как глобальная сеть, в которой любой компьютер может связаться с любым другим компьютером. На практике всё давно работает немного иначе. Где-то провайдер режет определённые сервисы, где-то появляются ограничения на отдельные протоколы, где-то плохо работает международная маршрутизация, а иногда нужный ресурс оказывается недоступен просто потому, что находится за пределами привычного маршрута вашего трафика. В результате даже опытный инженер периодически сталкивается с ситуацией, когда нужная документация не открывается, очередной релиз на GitHub скачивается со скоростью почтового голубя, пакеты PyPi становятся недоступными, Telemost начинает заикаться в голосовых каналах, а какой-нибудь зарубежный сервис внезапно оказывается недоступен из-за особенностей маршрутизации или региональной политики доступа.

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

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

Например:

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

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

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