Обновление версий Kubernetes и время простоя
Я только что протестировал Ranche RKE, обновляя kubernetes 13.xx до 14.xx, во время обновления уже работающий nginx Pod был перезапущен во время обновления. Это ожидаемое поведение?
Можно ли обновить кластер Kubernetes без перезагрузки пользовательских модулей?
Какой инструмент поддерживает непрерывные обновления?
Каковы простои, которые мы никогда не можем избежать? (кроме плоскости управления)
1 ответ
Стандартным способом обновления Kubernetes является последовательное обновление узлов, по одному за раз.
Это работает путем опустошения и оцепления (пометки узла как недоступного для новых развертываний) каждого обновляемого узла, чтобы на этом узле не работали модули.
Он делает это, создавая новую ревизию существующих модулей на другом узле (если она доступна), и когда новый модуль начинает работать (и отвечает на проверки готовности / работоспособности), он останавливается и удаляет старый модуль (отправляя SIGTERM на каждый контейнер pod) на обновляемом узле.
Количество времени, в течение которого Kubernetes ожидает постепенного выключения стручка, контролируется terminationGracePeriodSeconds по спецификации стручка, если стручок занимает больше времени, его убивают SIGKILL,
Суть в том, что для изящного обновления Kubernetes вам нужно иметь достаточно доступных узлов, и ваши модули должны иметь правильные пробники жизнеспособности и готовности ( https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
Некоторые интересные материалы, которые стоит прочитать:
https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-upgrading-your-clusters-with-zero-downtime (специфично для GKE, но имеет некоторые сведения)
https://blog.gruntwork.io/zero-downtime-server-updates-for-your-kubernetes-cluster-902009df5b33
Решено. Настроив среду выполнения контейнера на хостах, чтобы не перезапускать контейнеры при перезапуске докера.