Оттенки сложности k8s

k8s как айсберг. На поверхности — деплойменты и сервисы. А в глубине такие бездны, что Ктулху и не снилось. Фхтагн!

🔷 Affinity & Anti-Affinity: Вы думаете, что раскидали свои поды по разным нодам? Если этого не описать явно, таких гарантий нет.

🔷 PodDisruptionBudget: Защищает сервисы от «внезапных» отключений при обновлениях нод. Звучит классно, пока PDB не начнет конфликтовать с HPA.

🔷 Resource Quotas & Limit Ranges: Защищают кластер от жадных разработчиков. Но! Если вы не продумали дефолтные значения, готовьтесь к жалобам «у меня ничего не работает!». А еще квоты могут конфликтовать с HPA, создавая проблемные ситуации.

🔷 ImagePullBackOff: kubelet просит container runtime скачать image, но по какой-то причине это не работает. Причин вагон: неправильный тег, приватный репозиторий, а секрет забыли добавить, лимиты на Docker Hub.

🔷 Отсутствие алертинга: мое любимое. Узнать, что поды попали в CrashLoopBackoff, можно только посмотрев в дашборд (если он есть), а алерты отсутствуют или сыпятся на email, который никто не смотрит 🙂 

Но это ладно, пользователи придут и сообщат, что что-то не работает, а вот узнать спустя месяц, что пара нод кластера not ready, но электричество успешно потребляют, не очень интересно. Не делайте так, вкладывайтесь в конфигурацию алертинга и в целом в мониторинг.

k8s — система сложная, но многие типовые ошибки уже давно решены и важно уметь их применить в своей инфраструктуре.

А с какими из перечисленных проблем вы сталкивались?

Неочевидные проблемы Kubernetes, которые вы могли пропустить

➡️ обсудим послезавтра на бесплатном вебинаре.

Специальный гость: Руслан Гайнанов, главный инженер DevOps, T1 Иннотех

Вместе с Русланом мы поговорим про типовые ошибки, которые можно допустить при деплое сервисов в кластер, от некорректной настройки лимитов ресурсов, до более сложных кейсов с admission webhooks.

🐈 В конце вебинара — рекомендации по настройке вашего кластера и приложений для безотказной работы.

Когда: 16 июля в 19:00 мск

➡️ Занять место на вебинаре — через бота.

Liveness probe of death

У вас есть приложение, которое активно использует БД. Liveness probe проверяет коннект к БД каждую секунду.

Уже поняли, что не так?

Кажется логичным: если приложение не может подключиться к БД, значит, оно не работает. Разберемся, почему это плохая идея.

Что произойдет, если БД отвалится на 3+ секунд, а ваша liveness probe говорит, что после 3-х проверок нужно под рестартовать?

🟠Получаем рестарты подов. Приложение могло бы пережить недоступность БД, но вместо этого начало рестартовать, усугубляя и без того проблемную ситуацию.
🟠 Увеличение нагрузки на БД. После рестарта подов они начинают ломиться в БД, создавая новые коннекты.

Особо внимательные читатели скажут, что и без рестарта подов можно получить такую ситуацию, и в каких-то ситуациях это может быть так. Но если у нас используется промежуточный прокси (например, pgbouncer стоит перед PostgreSQL), эти коннекты могут и не разорваться, если под не рестартовал. Тут все зависит от настроек connection pooling как в приложении, так и в pgbouncer.

🟠 Часть приложения может работать без БД, потому что могут использоваться кеши. Можно отдавать fallback данные, можно имплементировать gracefull degradatation и прочие умные слова.

➡️ Summary

Проверять доступность любой зависимости вашего сервиса в корне неправильный подход, потому что сервис за доступность зависимости не отвечает. Но, как всегда, it depends. «Неправильный» liveness probe может «чинить» ошибки в плохо написанных приложениях путем их рестарта. Классический пример — меряем потребление памяти своего процесса и отвечаем в liveness, что мы недоступны и пора бы рестартануть, потому что не можем найти утечку памяти.

Более детально можно прочитать в статье. А кто отвечает за запуск probes? Конечно же kubelet. Разбираться можно начать отсюда, если хочется увидеть работу изнутри. За что еще отвечает kubelet можно посмотреть в недавнем посте.

А завтра на вебинаре мы разберем еще более коварные ошибки и неочевидные проблемы k8s, которые вы могли пропустить.

Ну и напоследок предлагаю посмотреть, как реплики сервиса Маркус обслуживают ваши потребности в котиках ⬇️

Привет! Это Маркус.

Сурово смотрю на тех, кто еще не зарегистрировался на вебинар по неочевидным проблемам k8s. Он, кстати, уже через час.

➡️ Специальный гость: Руслан Гайнанов, главный инженер DevOps, T1 Иннотех
Ну и я, возможно, тоже приду.

Поговорим про типовые ошибки, которые можно допустить при деплое сервисов в кластер, от некорректной настройки лимитов ресурсов, до более сложных кейсов с admission webhooks.

Ссылки, как всегда, придут в бота. Подключайтесь! 🐈

Гранты Слёрма добрались и до нас с вами 🔥

Объявляю конкурс грантов на летний поток курса «Kubernetes Мега», который стартует 28 июля.

🐈 1 место — скидка 100%
🐈 2 места — скидка 70%
🐈 3 места — скидка 50%

Условия участия:
➡️ Быть подписанным на мой канал
➡️ Заполнить анкету участника и пройти тестирование до 21 июля — по ссылке

Итоги мы с Маркусом подведем 23 июля. Удачи!

GitOps: не все так просто

Вы наверняка слышали что-то вроде «просто поставь argocd». И все, кажется, что все проблемы раскатки изменений в кластер решены, у вас есть больше времени пить кофе, смотря на автоматическую синхронизацию изменений.

Но все не так однозначно :)

➡️ Начнем с плюсов:

🟠 Единая точка правды: все изменения можно ревьювить и откатывать при необходимости.

🟠 Иммутабельность и воспроизводимость: в идеально выстроенной системе накатить все приложения в кластер с нуля не составит больших проблем. Подняли кластер, накатили argocd, применили базовые настройки для связки с git → argocd сделает все остальное.

🟠 Избегаем configuration drift: любые ручные изменения в кластере автоматически откатываются. Если у вас разработчики могут править задеплоенное в кластере в обход репозиториев, у меня для вас не очень хорошие новости.

➡️ Минусы:

🟣 Управление секретами: секреты не защищены — хранение в git строгое no-no (про то, как хранить секреты безопасно, подробно говорим на «Kubernetes Мега» — уделили этому целый модуль).

🟣 Сложная организация репозиториев: с ростом числа сервисов и окружений резко увеличивается сложность структуры репозиториев. Монорепа или множество инфра-репозиториев — каждая компания решает по-своему.

🟣 Конфликты: при частых выкатках нередки конфликты pull request-ов при одновременном обновлении конфигураций нескольких сервисов. Сломать при неправильном разрешении конфликтов инфраструктуру становится так же просто, как сделать git commit.

🟣 Ограниченная валидация: без дополнительных инструментов легко получить конфигурации с ошибками, начиная от неправильных отступов в yaml, заканчивая неприменяемыми манифестами, потому что ваш kyverno запретил запрашивать 100 cpu (упс, хотели же 10 написать).

🟣 Вопросы масштабирования: при больших масштабах (десятки–сотни кластеров, разные среды) нагрузка на devops/sre/infra/k8s инженеров (или как у вас называются люди, отвечающие за инфру) резко увеличивается из-за необходимости поддерживать множество раздельных конфигураций, не обязательно совместимых друг с другом.

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

➡️ Cложные кейсы использования GitOps

🟠 Мультикластерное управление и гибридные инфраструктуры: управление множеством кластеров в разных облаках требует сложных решений по структурированию репозиториев, разграничения доступа и автоматизации disaster recovery.

🟠 Разграничение прав и политики безопасности: при большом количестве команд и сервисов приходится тщательно разделять доступы к файлам конфигураций, а для policy-as-code внедрять дополнительные инструменты валидации.

🟠 Промежуточные среды (stage, production): применение изменений между окружениями может стать нетривиальным из-за различий в настройках и необходимости поддерживать множество веток с разными настройками.
Применили изменения в stage, а в production применили немного отличающиеся? Привет, различие окружений.

🟠 Масштабируемость CI/CD в монорепозиториях: при большом количестве сервисов и команд нужно детально проработать логику автоматических запусков пайплайнов и раздельного деплоя, чтобы не было конфликтов и чрезмерной загрузки на раннеры, создающей очередь деплоя на часы вперед.

➡️ Важные нюансы

🟣 Требуется дисциплина команд: для успешной работы GitOps критичны стандарты именования, ревью изменений и контроль.

🟣 Дополнительные инструменты: необходима интеграция secret провайдеров (vault, но не обязательно, но это и без gitops нужно делать), внешних валидаторов (например, OPA или kyverno), управление множеством pipeline-ов (например, через merge train)

GitOps отлично подходит для k8s как инструмент стандартизации, аудита и автоматизации изменений, но требует грамотной архитектуры pipeline-ов, дисциплины разработки и интеграции дополнительных средств безопасности, мониторинга и валидации.

k8s обучение

Привет руководителям, менеджерам всех уровней и им сочувствующим! Сегодня хочу обсудить с вами, как понять, что команде пора на обучение.

➡️ Симптомы проблем при работе с k8s:

- Инженеры часто копаются в StackOverflow/ChatGPT/Google, чтобы понять, как работает или как настроить какую-то абстракцию в k8s
- Фиксят проблемы методом научного тыка, опираясь на рандомные статьи
- Не уверены, как проверить корректность применяемых изменений в инфраструктуре

Если хотя бы один из этих симптомов вам знаком, значит, самое время систематизировать знания, пройти практику в безопасной среде, где нет риска сломать прод, и получить ответы на свои вопросы от практикующих инженеров.

➡️ Почему это важно?

- Вместо чтения блогов и общения с ChatGPT, ваш инженер получает структурированные знания по Kubernetes от практиков
- Вместо страха сломать прод — уверенность во внесении изменений в инфраструктуру
- Вместо вопросов, ответы на которые не может проверить, опыт инженеров, внедряющих k8s много лет

➡️ Важно!

1. Обучение должно быть целевым.

Учеба ради учебы — путь в никуда. Учеба ради снижения выгорания инженеров в силу постоянных запросов от бизнеса, которые сложно реализовывать, не имея багажа знаний по k8s — наш путь.

2. Время на обучение желательно выделять из рабочих часов.

Мало кто захочет учиться вечером или в выходные, так что вопрос об эффективности остается открытым.

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

В итоге, обученные инженеры — это не просто знающие инженеры. Это люди, которые меньше косячат, быстрее внедряют, и, главное, горят желанием делать крутые вещи.

А как вы оцениваете потребность в обучении у ваших сотрудников?

Сегодня хочу познакомить вас с одним из наших студентов

🐈 Павел Елецков, руководитель направления Kubernetes компании «СБЕР Спасибо», проходил обучение на курсе «Kubernetes Мега» и поделился с нами подробным видеоотзывом. В нем он рассказывает, кому подойдет курс, как организован процесс обучения, плюсы, минусы и чего ему не хватило внутри в программы.

Где посмотреть:

➡️ YouTube
➡️ VK Видео

Старт следующего потока уже 28 июля. Узнать подробности и занять место — по ссылке.

Итоги конкурса грантов 💥

В тестировании приняли участие 108 человек. Выбрать было сложно — мы с командой ориентировались на мотивацию каждого из вас и правильность ответов в техническом скрининге.

Список победителей:

🐈 Скидка 100%
@Alex_Gureev

🐈 Скидка 70%
@qwaldo
@glycosupport

🐈 Скидка 50%
@Ms1blast
@justaleksy
@samkilanoff

Поздравляю! 🥳

В ближайшее время с вами свяжутся организаторы конкурса и расскажут, что делать дальше.  Стартуем уже в следующий понедельник!

Как перестать бояться оркестрации и полюбить k8s

Задумываетесь о нырянии с головой в бездны k8s? 28 июля стартует новый поток курса «Kubernetes Мега», где мы с коллегами разбираем k8s по полочкам и учим не просто деплоить ямлы, а рассказываем, как оно работает внутри.

➡️ «Kubernetes Мега» может быть вашим выбором, если:

🔷 Вы устали изучать тонны yaml. Курс погружает в архитектуру k8s, раскрывая внутренние механизмы работы Control Plane, kubelet и других компонентов.

🔷 Вам нужно глубокое понимание для поддержки сложных инсталляций. Качественный курс часто является отличным способом систематизировать знания и подготовиться к более сложным и интересным задачам.

🔷 В вашей команде не хватает экспертов по Kubernetes, и вы хотите поднять общий уровень. Коллективное обучение может быть отличным способом выровнять знания в команде ваших k8s инженеров.

➡️ «Kubernetes Мега» не подойдет вам, если:

🔷 Вы ожидаете, что можно просто пройти теорию и получить сертификат. Теория без практики не позволит закрепить знания. На курсе делаем много практических занятий, где можно руками пощупать разные механизмы k8s.

🔷 Вы ищете готовые рецепты и «серебряные пули». k8s — сложная платформа, и универсальных решений не существует. Курс научит вас самостоятельно выбирать подходящие решения в зависимости от контекста, а не просто копировать готовые конфиги.

🔷 У вас нет базовых знаний о контейнеризации и DevOps-практиках. k8s — это не для новичков. Перед курсом стоит изучить основы Docker, Linux и попрактиковаться с базовыми инсталляциями k8s. Для этого можно пройти k8s база.

На днях делился с вами подробным отзывом от выпускника курса Павла Елецкова, руководителя направления Kubernetes компании «СБЕР Спасибо». Дублирую ссылки для тех, кто пропустил, чтобы вы могли получить представление о курсе не только со стороны спикера, но и со стороны студента:

➡️ YouTube
➡️ VK Видео

Обучение на курсе может стать полезным вложением, если вы готовы активно учиться и применять полученные знания на практике. Старт потока уже в понедельник. Занимайте места по ссылке!

Kubernetes Мега: 3 дня до старта

Новый поток продвинутого курса по k8s стартует уже в понедельник. Осталось 3 дня, чтобы запрыгнуть в последний вагон и уже осенью добавить в резюме новые компетенции.

После курса вы сможете:

🔷 Привести «зоопарк» инструментов к управляемой экосистеме, повысить отказоустойчивость продукта и автоматизировать развёртывания

🔷 Использовать все возможности k8s при проектировании платформенных решений и уверенно переводить продукты компании на k8s

🔷 Сдать сертификацию и получить свидетельство установленного образца, которое можно прикрепить к резюме

Первым трем, кто пройдет курс на 80% и сдаст сертификацию, дарим эксклюзивную сессию 1-1 с Павлом Елецковым, Teamlead k8s в СберСпасибо и ментором курса.

На ней вы сможете:
➡️ Разобрать свой рабочий кейс и получить прикладные советы
➡️ Прокачать резюме для топовых вакансий
➡️ Пройти mock-интервью, чтобы быть готовым к реальным вызовам

Дополнительные модули для всех, кто прйдет курс на 80% и сдаст сертификацию к последней встрече:

🐈 Мониторинг и трассировка сервисов с Istio
🐈 Безопасность в Kubernetes с Istio
🐈 Canary and A/B Deployments

Узнать подробности и занять место на потоке — по ссылке. Подключайтесь, прокачать свои навыки и вырасти в должности и зарплате!

База или мега? Всё сразу, и побольше!

Замахнулись на k8s? Отлично, их есть у нас! Но не спешите, тут нужен систематический подход.

Есть два стула пути:

🔷 Для тех, кто в теме

Если вы на k8s уже собаку съели, то вам прямая дорога на «Kubernetes Мега». Поток стартует уже сегодня, и присоединиться к нему можно до конца недели. Там такое покажут, что ваши кластера сами себя настраивать будут! Разберете внутренности scheduler, научитесь строить операторы одной левой и многое другое. Готовьтесь, будет хардкор, но оно того стоит. А детальнее про то, для кого мега, я уже рассказывал в этом посте.

🔷 Для тех, кто начинает свой путь в мир k8s

Если k8s для вас — это что-то страшное и непонятное, не паникуйте. Есть «Kubernetes База». Поток стартует 4 августа. Там вас за ручку проведут по основам: какие абстракции есть, как все это применяется, как деплоится и раскатывается в кластер, как мониторится, и, конечно же, как начать — раскатать ваш первый кластер и заботиться о нем, как я о Маркусе, чтобы не нашкодил.

🐈 На самом деле, есть еще третий путь — для тех, кто хочет сразу на двух стульях усидеть. Это комплект из потока «Kubernetes База» и видеокурса «Kubernetes Мега». С ним вы сможете прокачать свои навыки с нуля до уровня «Бог k8s» — со скидкой 20%.

Подробности — по ссылке.

И совет напоследок: k8s — это не rocket science, но и не игра. Не бойтесь копаться в YAML, экспериментировать, ломать и чинить (только не в проде, пожалуйста). Только так можно по-настоящему понять, как все работает.

k8s база: рассказываем то, что нельзя нагуглить

«Kubernetes База» — это не просто k8s для начинающих инженеров, которые решили связать свой профессиональный путь с эксплуатацией k8s.

Это путь от базовых понятий до работающего приложения, развернутого с учетом best practices. Мы не просто крутим kubectl apply, а выстраиваем понимание концепций, а не конкретных решений, чтобы применять на своих проектах с учётом особенностей проектов.

С ней вы сможете самостоятельно выбирать более подходящие инструменты экосистемы k8s под ваши проекты и не переусложнять там, где нет на то реальной необходимости.

➡️ Вместо перечисления компонентов — погружение в то, как они взаимодействуют. Не «Node состоит из kubelet, kube-proxy, etc.», а «Почему kubelet нужен, чтобы Pod вообще запустился, и как kube-proxy разруливает трафик до этих Pod'ов, даже если их IP меняются».

➡️ Не просто «Deployment управляет Pod'ами», а «Как Deployment использует ReplicaSet для rolling updates?». Понимание StatefulSet'ов и DaemonSet'ов для специфических workload'ов.

Также обязательно рассмотрим, как раскатывать свой кластер на bare metal, и что нам это будет стоить с точки зрения дальнейшей поддержки.

Само собой, ни один production кластер не обойдется без выстроенных процессов доставки приложений и надежного мониторинга. Под эти темы выделены отдельные модули про CI/CD и про, что бы вы думали? Конечно, мониторинг.

А еще на курсе есть 5 Q&A сессий со спикерами, где вы сможете разобраться ваши кейсы от экспертов, которые крутят k8s уже много лет, и повидали всякого, о чем в приличном обществе не принято рассказывать, потому что темы строго 18+, и иногда такое увидишь, что волосы дыбом встают, как это вообще еще не сломалось. А всего лишь надо было следовать лучшим практикам и соблюдать требования, указанные в документации.

🐈 И самое вкусное: сертификация, которая позволит вам закрепить полученные знания на кейсах, приближенных к реальным, и получить уверенность в задачах, которые у вас появятся в дальнейшем. Сломать тестовый кластер не страшно. Страшно, когда не знаешь как чинить прод, потому что не прошел сертификацию)

Поток стартует 4 августа. Занять место можно по ссылке. Присоединяйтесь, если хотите разобраться в работе k8s и получить востребованные скиллы.

Сколько зарабатывает SRE в Нидерландах?

Рассказал на интервью для пилотного выпуска спецпроекта «DevOps про деньги».

Ведущий: Всеволод Севостьянов, Staff engineer в Lokalise.

Что обсуждали:
➡️ Какие навыки нужны SRE в бигтехе?
➡️ Требования в вакансии vs реальные рабочие задачи: есть ли разница?
➡️ Главный вопрос: сколько получает SRE в Амстердаме, и за что столько платят?

Посмотреть можно тут:
🟠YouTube
🟠Rutube
🟠VK Видео

А всех, кто после просмотра захочет двигаться в направлении подобных задач (и подобных зарплат, конечно же) — приглашаю на «Kubernetes База». Старт 4 августа!

Отзывы студентов

Принес вам отзыв на курс «Kubernetes База» от сотрудника Т-Банка:

От pod'а до prod'a за 1.5 месяца

Только что закончил обучение на курсе от Slurm. Полтора месяца и я освоил навыки работы в Kubernetes и даже прошёл сертификацию. Экзамен для которой длился аж 6 часов.

Зачем мне к8s?

Моей главной целью на курсе было научиться деплоить приложение в кластер, чтобы затем настроить СІ/СD pipeline, который бы сам поднимал стенд с новой версией приложения, запускал имеющиеся автотесты и принимал решение о деплойменте приложения.

Стоит ли тебе его проходить?

В курсе разобрано множество тем k8s, начиная с основных компонентов и устройства кластера, заканчивая непрерывным деплойментом приложения с помощью Gitlab-Cl и helm- чартов.

Для каждой темы курса предлагается выполнить практическое задание на реальном к8ѕ кластере (battery included), с автоматической проверкой решения, что в свою очередь помогает быстрее закрепить знания на практике. (Отмечу, что опыт решения этих задач уже пригодился мне в реальных задачах).

На курсе есть возможность обратиться в тех-поддержку slurm, если возникают сложности с решением заданий. (Мне отвечали в течение 5 минут.) Дополнительно, для потока был создан tg-канал, где куратор и ведущие курса, а иногда студенты потока помогают с решением возникших вопросов.

В конце курса предусмотрена сертификация полученных знаний в виде экзамена с практическими заданиями. Экзамен это набор таких же практических заданий, которые попадались на курсе, но с небольшими изменениями. При этом во время экзамена разрешается пользоваться любыми источниками, главное это представить решение.

Если хочешь овладеть навыками работы в k8s для решения рабочих задач, то рекомендую смело рассмотреть этот курс. Как мне показалось, все моменты для качественного обучения в нём предусмотрены.

➡️ Если вы не знаете, как подступиться к k8s, с чего начать и как перейти на него в своих проектах — начните со структурированных знаний, которые мы даем на курсах. Так вы сможете разложить все по полочкам и начать работать с k8s с минимальным количеством трудностей.

🔷 Старт ближайшего потока «Kubernetes База» уже в понедельник. Подробности — на сайте.

*Орфография и пунктуация автора отзыва сохранены.

Kubernetes База: старт уже в понедельник!

Осталось три дня, чтобы вкатиться в новый поток стартового курса по k8s и получить востребованный скилл уже через полтора месяца.

Что внутри:

🟣 6 недель обучения, 63 часа практики и 23 часа теории
🟣 73% программы — работа со стендами для отработки практических навыков
🟣 5 Q&A-встреч со спикерами курса
🟣 Сертификация по итогу обучения, закрепляющая весь пройденный материал

Присоединяйтесь к потоку, чтобы уже в сентябре уметь работать k8s, кластерами и CI/CD.

➡️ Подробности — на странице курса.

Kubernetes База: поток стартовал!

Пристегните ремни, потому что сегодня — первый день путешествия в мир k8s. Слишком просто не будет, но и архисложного ничего не предвидится (хотя кто знает, конечно).

Ближайшие 6 недель будем разбираться с основами работы с k8s, базовыми абстракциями кластера, запуском приложений в кластере и принципами их работы.

➡️ Сегодня еще можно присоединиться к потоку. Ссылка для опоздавших: https://to.slurm.io/4EbSIQ

А для тех, кто хочет сразу прокачать свои навыки до продвинутого уровня и получить полный контроль над своей контейнерной инфраструктурой, мы с командой подготовили комплект:

Kubernetes База (поток) + Kubernetes Мега (видеокурс) со скидкой 20%.

Подробности — на сайте.

Что будет, если k8s исчезнет?

Представьте мир без k8s, без контейнеров. Мир, где окружения уникальны. Где зависимости от пакетов, установленных в ОС, максимально жесткие.

Мне лично и представлять не надо, я там был. И ничего хорошего в общем случае в этом нет. Два приложения с разными версиями системных библиотек → доигрались, сломали одно из них. Обновили ОС → положили все проекты на этом сервере.

➡️ Усаживайтесь поудобнее, дед побухтит, почему виртуализация и контейнеризация в современном мире это просто must have, и почему раньше было тоже неплохо.

Раньше как было? Берёшь каталог с PHP файлами, заливаешь по FTP на сервер, и вроде работает. Но времена изменились. Бизнес требует скорости, надежности, и масштабирования. 20 лет назад почти не было IT компаний с сотнями миллионов пользователей.

Почти не было. Были google, yahoo и другие гиганты, но большинство компаний так или иначе не требовали того масштаба. Да и сейчас некоторым это не нужно. Например, представьте небольшую сеть пиццерий с доставкой с приложением на php монолите. И это будет неплохо работать, особенно если поднять пару реплик приложения и добавить auto failover для БД.

➡️ В современном мире, если продукт упал, это уже не просто «ой, извините», это вполне ощутимые финансовые потери.

Без k8s вся эта история превращается в адский ручной труд.

🔷 Развёртывание

Забудьте про GitOps и пайпланы выкатки. Придётся писать скрипты, плейбуки, или вообще руками всё настраивать на каждой виртуалке или bare metal.

🔷 Масштабирование

Нужно больше мощности? Опять ручками поднимать новые серверы, настраивать балансировку. Никакой тебе горизонтальной автомасштабируемости по CPU или памяти.

🔷 Отказоустойчивость

Сервер упал? Сидишь и молишься, чтобы бэкап сработал и чтобы всё поднялось как можно быстрее.

🔷 Управление конфигурацией

Хранить конфиги, секреты, переменные окружения в разных местах, помнить, что где лежит, и постоянно синхронизировать? k8s централизованно управляет конфигурацией, упрощая жизнь и уменьшая риск ошибок.

🔷 Мониторинг и логирование

Собирать метрики и логи с кучи серверов вручную — то ещё удовольствие. В k8s можно выстроить нормальный процесс доставки логов.

А как вы делали деплои до k8s?