Kubernetes POD Failover

Question

Я играю с Kubernetes и мне удалось развернуть приложение statefull (экземпляр jenkins) на одном узле.Он использует PVC, чтобы убедиться, что я могу сохранить свои данные jenkins (задания, плагины и т. Д.).

Теперь я хотел бы поэкспериментировать с аварийным переключением.

В моем кластере есть 2 цифровых океанских капли.

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

Сейчас я смотрю, как выполнить аварийное переключение в том смысле, что, когда модуль jenkins выходит из строя на моем узле, он будет раскручиваться на другом узле.(так короткое время простоя во время этого процесса в порядке).

Конечно, он должен использовать тот же PVC, чтобы мои данные оставались нетронутыми.

Я считаю, что при чтении StatefulSet kanбыть использованы для этого?

Любые указатели очень ценятся!

С уважением

Answer 1

Служба Digital Ocean Kubernetes поддерживает только ReadWriteOnce режимы доступа для PVC (см. здесь ).Это означает, что том может быть подключен только к одному узлу за раз.

Я встречал этот пост , который, хотя и сфокусирован на Jenkins на Azure, имеет ту же ситуацию, что и поддержка ReadWriteOnce.Автор заявляет:

недостаток для меня заключается в том, что режим доступа к постоянным томам Azure Disk - ReadWriteOnce.Это означает, что диск Azure может быть одновременно подключен только к одному узлу кластера.В случае сбоя или обновления узла может потребоваться от 1 до 5 минут, чтобы диск Azure был отсоединен и подключен к следующему доступному узлу.

Примечание, сбой Pod иотказы узлов - это разные вещи.Поскольку DO поддерживает только ReadWriteOnce, нет смысла пробовать что-то более сложное, чем то, что у вас есть сейчас, с точки зрения терпимости к отказу узла .Так как это ReadWriteOnce, том должен быть размонтирован с отказавшего узла и повторно подключен к новому узлу, а затем новый Pod будет запланирован на новом узле.Kubernetes сделает это за вас, и вы ничего не сможете сделать, чтобы оптимизировать его.

Для сбоя Pod вы можете использовать Deployment, так как вы хотите читать и записывать одни и те же данные, вы нене хочу, чтобы разные копии были прикреплены к разным репликам.Это может быть очень ограниченным преимуществом: у вас будет несколько реплик Pod, работающих на одном и том же узле, поэтому это зависит от того, как масштабируется процесс Jenkins и может ли он поддерживать модель такого типа с горизонтальным масштабированием при выполнении всей записи.на тот же объем (в отличие от простого вертикального масштабирования памяти или запросов ЦП).

Если вы действительно хотите добиться более высокой доступности в условиях сбоев узлов и / или Pod и рабочей нагрузки Jenkins, которую вы ''Для повторного развертывания требуется жесткое требование к локальным томам для постоянного состояния, вам нужно будет рассмотреть плагин альтернативного тома, такой как NFS, или перейти к другому облачному провайдеру, например, GKE.

Answer 2

Хорошо, позвольте мне ответить на свой вопрос здесь.Я думаю, что Amit Kumar Gupta подошел ближе всего к тому, что, по моему мнению, здесь происходит.

Поскольку я использую Deployment и мой PVC в ReadWriteOnce, я в основном застрял с одним модулем, на котором запущен jenkins, на одномузел.

weibelds ответ заставил меня понять, что я задавал вопросы о концепции, которую Kubernetes использует по умолчанию.Если мой модуль выходит из строя (в моем случае я специально отключаю узел, выполняя принудительное отключение питания для имитации сбоя), кластер (контроллер?) Обнаружит это и создаст новый модуль на другом узле.

Пока все в порядке, но потом я заметил, что мой новый модуль застрял в состоянии ContainerCreating.

Запуск describe на моем новом модуле (тот, что в состоянии ContainerCreating) показалthis

Warning  FailedAttachVolume  16m                attachdetach-controller  Multi-Attach error for volume "pvc-cb772fdb-492b-4ef5-a63e-4e483b8798fd" Volume is already used by pod(s) jenkins-deployment-6ddd796846-dgpnm
Warning  FailedMount         70s (x7 over 14m)  kubelet, cc-pool-bg6u    Unable to mount volumes for pod "jenkins-deployment-6ddd796846-wjbkl_default(93747d74-b208-421c-afa4-8d467e717649)": timeout expired waiting for volumes to attach or mount for pod "default"/"jenkins-deployment-6ddd796846-wjbkl". list of unmounted volumes=[jenkins-home]. list of unattached volumes=[jenkins-home default-token-wd6p7]

Тогда это начало поражать меня, это имеет смысл.Это жалко, но в этом есть смысл.

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

Когда я читаю больше об этом, я читал, что только DigitalOceanподдерживает ReadWriteOnce, что теперь заставляет меня задуматься, как, черт возьми, я могу добиться простого перехода на другой ресурс для приложения с сохранением состояния на кластере Kubernetes в Digital Ocean, который состоит всего из пары простых капель?

Answer 3

То, что вы описываете, - это поведение по умолчанию Kubernetes для модулей, управляемых контроллером, например, Deployment.

Вы должны развертывать любое приложение как Deployment (или другой контроллер), даже если оно состоиттолько одного стручка.Вы никогда не применяете стручки непосредственно в Kubernetes.Так что в этом случае вам ничего не нужно делать, чтобы получить такое поведение.

Когда один из ваших узлов умирает, Pod тоже умирает.Это обнаруживается контроллером развертывания, который создает новый Pod.Это в свою очередь обнаруживается планировщиком, который назначает новый Pod узлу.Поскольку один из узлов не работает, он назначит Pod другому узлу, который все еще работает.Как только Pod будет назначен этому узлу, kubelet этого узла будет запускать контейнер (ы) этого Pod на этом узле.

Answer 4

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