Точного родмапа с самого начала у меня не было (был, конечно, уж совсем базовый с yt «девопсим потихоньку», но это чтоб не уйти вообще не туда). Я шел от задач самого проекта и того, начтообращаливниманиедругиеавторы.
Лучший родмап — это архитектура твоего приложения: появляется узкое место — идешь изучать конкретный инструмент для его решения, применяешь его, двигаешься дальше.
Спасибо за такой глубокий комментарий! В рамках текущего стенда с одной виртуалкой использование local-path было скорее вынужденным компромиссом, но для полноценной production-ready среды жесткая привязка данных к ноде, конечно, недопустима.
И отдельное спасибо за наводку на PodDisruptionBudget — обязательно детально разберу этот механизм и добавлю PDB-манифесты при переходе к тестам кластера с несколькими нодами
Спасибо за замечание! Согласен, конечно за 5 месяцев невозможно охватить весь Kubernetes и всю инфраструктуру в целом — поэтому статья скорее про мой путь и конкретные механизмы, с которыми я успел поработать. Возможно, слово “боевой” в названии получилось немного громким). Идея была показать именно переход от Compose к Kubernetes и то, какие проблемы он решает на уровне приложения.
Дальше как раз планирую строить многонодовый кластер и проверить отказы уже на уровне инфраструктуры. Буду рад, если потом заглянете в продолжение
да, вы правы, полноценной отказоустойчивостью это назвать нельзя. В статье я больше фокусировался на механизмах Kubernetes после перехода с Compose (ReplicaSet, перераспределение нагрузки, поведение приложения при падении подов и ZDD). Кластер получился однонодовым из-за ограничений тестового окружения, поэтому отказоустойчивость на уровне самих нод и не рассматривалась. Я уже подумываю развернуть полноценный кластер и уже проверить сценарии с отказом узлов, балансировкой и восстановлением сервисов.
Точного родмапа с самого начала у меня не было (был, конечно, уж совсем базовый с yt «девопсим потихоньку», но это чтоб не уйти вообще не туда). Я шел от задач самого проекта и того, на что обращали внимание другие авторы.
Лучший родмап — это архитектура твоего приложения: появляется узкое место — идешь изучать конкретный инструмент для его решения, применяешь его, двигаешься дальше.
Спасибо за такой глубокий комментарий! В рамках текущего стенда с одной виртуалкой использование local-path было скорее вынужденным компромиссом, но для полноценной production-ready среды жесткая привязка данных к ноде, конечно, недопустима.
И отдельное спасибо за наводку на PodDisruptionBudget — обязательно детально разберу этот механизм и добавлю PDB-манифесты при переходе к тестам кластера с несколькими нодами
Спасибо за замечание! Согласен, конечно за 5 месяцев невозможно охватить весь Kubernetes и всю инфраструктуру в целом — поэтому статья скорее про мой путь и конкретные механизмы, с которыми я успел поработать. Возможно, слово “боевой” в названии получилось немного громким). Идея была показать именно переход от Compose к Kubernetes и то, какие проблемы он решает на уровне приложения.
Дальше как раз планирую строить многонодовый кластер и проверить отказы уже на уровне инфраструктуры. Буду рад, если потом заглянете в продолжение
да, вы правы, полноценной отказоустойчивостью это назвать нельзя. В статье я больше фокусировался на механизмах Kubernetes после перехода с Compose (ReplicaSet, перераспределение нагрузки, поведение приложения при падении подов и ZDD). Кластер получился однонодовым из-за ограничений тестового окружения, поэтому отказоустойчивость на уровне самих нод и не рассматривалась. Я уже подумываю развернуть полноценный кластер и уже проверить сценарии с отказом узлов, балансировкой и восстановлением сервисов.