Comments 8
автор немного смешивает учебный стенд и реальный production. Single-node K3s с одной ВМ — это скорее хороший лабораторный полигон, чем отказоустойчивая инфраструктура. При падении самой ноды весь этот «zero downtime» заканчивается.
да, вы правы, полноценной отказоустойчивостью это назвать нельзя. В статье я больше фокусировался на механизмах Kubernetes после перехода с Compose (ReplicaSet, перераспределение нагрузки, поведение приложения при падении подов и ZDD). Кластер получился однонодовым из-за ограничений тестового окружения, поэтому отказоустойчивость на уровне самих нод и не рассматривалась. Я уже подумываю развернуть полноценный кластер и уже проверить сценарии с отказом узлов, балансировкой и восстановлением сервисов.
Хорошее название, сразу вызывает желание усмехнуться (:
Ну серьезно, какая может быть отказоустойчивая инфраструктура за 5 месяцев с нуля? Там тонкостей столько, что даже работая с этим 5 лет, а не пять месяцев, можно с уверенностью сказать, что ты ничего не знаешь.
Но автору всё равно поставлю плюсик — не бросил через неделю, довёл до какого-то логического конца и даже написал подробную статью, которая точно кому-то может быть полезна, даже в плане обучения.
Спасибо за замечание! Согласен, конечно за 5 месяцев невозможно охватить весь Kubernetes и всю инфраструктуру в целом — поэтому статья скорее про мой путь и конкретные механизмы, с которыми я успел поработать. Возможно, слово “боевой” в названии получилось немного громким). Идея была показать именно переход от Compose к Kubernetes и то, какие проблемы он решает на уровне приложения.
Дальше как раз планирую строить многонодовый кластер и проверить отказы уже на уровне инфраструктуры. Буду рад, если потом заглянете в продолжение
Отказоустойчивость stateless-сервисов в K3s даётся почти бесплатно. Настоящая проверка начинается на данных: по умолчанию тома раздаются через local-path и намертво привязаны к ноде – упадёт нода, и под с базой поднимется в другом месте уже без своего PVC. Ещё момент про Zero-Downtime: бесшовный деплой обеспечивает rolling update, а выживание при сбое ноды – PodDisruptionBudget, без которого drain снесёт все реплики разом.
Спасибо за такой глубокий комментарий! В рамках текущего стенда с одной виртуалкой использование local-path было скорее вынужденным компромиссом, но для полноценной production-ready среды жесткая привязка данных к ноде, конечно, недопустима.
И отдельное спасибо за наводку на PodDisruptionBudget — обязательно детально разберу этот механизм и добавлю PDB-манифесты при переходе к тестам кластера с несколькими нодами
Судя по вашему расскажу "от первых команд в Linux..." до проекта. Каким роадмапом вы придерживались? Собрать все цело в голове и двигатьcя к этому. То есть изучить нужное и применить тут же на проекте.
Точного родмапа с самого начала у меня не было (был, конечно, уж совсем базовый с yt «девопсим потихоньку», но это чтоб не уйти вообще не туда). Я шел от задач самого проекта и того, на что обращали внимание другие авторы.
Лучший родмап — это архитектура твоего приложения: появляется узкое место — идешь изучать конкретный инструмент для его решения, применяешь его, двигаешься дальше.
Из песочницы Compose в боевой Kubernetes: как я построил отказоустойчивую архитектуру за 5 месяцев, изучая все с нуля