Из песочницы Compose в боевой Kubernetes: как я построил отказоустойчивую архитектуру за 5 месяцев, изучая все с нуля

[pustoskinkiri]

автор немного смешивает учебный стенд и реальный production. Single-node K3s с одной ВМ — это скорее хороший лабораторный полигон, чем отказоустойчивая инфраструктура. При падении самой ноды весь этот «zero downtime» заканчивается.

[Ru_dockerr]

да, вы правы, полноценной отказоустойчивостью это назвать нельзя. В статье я больше фокусировался на механизмах Kubernetes после перехода с Compose (ReplicaSet, перераспределение нагрузки, поведение приложения при падении подов и ZDD). Кластер получился однонодовым из-за ограничений тестового окружения, поэтому отказоустойчивость на уровне самих нод и не рассматривалась. Я уже подумываю развернуть полноценный кластер и уже проверить сценарии с отказом узлов, балансировкой и восстановлением сервисов.

[Ru_dockerr]

Спасибо за замечание! Согласен, конечно за 5 месяцев невозможно охватить весь Kubernetes и всю инфраструктуру в целом — поэтому статья скорее про мой путь и конкретные механизмы, с которыми я успел поработать. Возможно, слово “боевой” в названии получилось немного громким). Идея была показать именно переход от Compose к Kubernetes и то, какие проблемы он решает на уровне приложения.

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

[Granulex]

Отказоустойчивость stateless-сервисов в K3s даётся почти бесплатно. Настоящая проверка начинается на данных: по умолчанию тома раздаются через local-path и намертво привязаны к ноде – упадёт нода, и под с базой поднимется в другом месте уже без своего PVC. Ещё момент про Zero-Downtime: бесшовный деплой обеспечивает rolling update, а выживание при сбое ноды – PodDisruptionBudget, без которого drain снесёт все реплики разом.

[Ru_dockerr]

Спасибо за такой глубокий комментарий! В рамках текущего стенда с одной виртуалкой использование local-path было скорее вынужденным компромиссом, но для полноценной production-ready среды жесткая привязка данных к ноде, конечно, недопустима.

И отдельное спасибо за наводку на PodDisruptionBudget — обязательно детально разберу этот механизм и добавлю PDB-манифесты при переходе к тестам кластера с несколькими нодами

[Artzver]

Судя по вашему расскажу "от первых команд в Linux..." до проекта. Каким роадмапом вы придерживались? Собрать все цело в голове и двигатьcя к этому. То есть изучить нужное и применить тут же на проекте.

[Ru_dockerr]

Точного родмапа с самого начала у меня не было (был, конечно, уж совсем базовый с yt «девопсим потихоньку», но это чтоб не уйти вообще не туда). Я шел от задач самого проекта и того, на что обращали внимание другие авторы.

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

[apachp]

Присмотритесь еще к hpa и vpa для обеспечения отказоустойсивости ваших же приложений и про гитлаб раннер внутри кубернетиса,ему в таком случае никакой смш не надо ,все происходит сквозь апи кубернетиса