Kubernetes: Реализовать скользящее обновление для наборов демонов

Созданный на 4 мар. 2016 · 3Комментарии · Источник: kubernetes/kubernetes

Привет,

Извините за то, что сделал это в неправильном порядке, как указано здесь: https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md#contributing -a-patch

Я сделал # 22439 для решения этой проблемы (на стороне kubectl)

Необходимо иметь возможность обновлять набор демонов в одной командной строке.
В основном это эквивалентно:

kubectl delete  -f dsfile  --cascade=false
kubectl create   -f dsfile
for pod in pods
kubectl  delete pod
wait for delete

РЕДАКТИРОВАТЬ: @ bgrant0607 предложил обновить ds вместо delte / воссоздать

areapp-lifecycle areworkload-apdaemonset prioritbacklog siapps

Источник

Seb-Solon

👍13

Самый полезный комментарий

1.6 включает последовательные обновления для DaemonSets.

kargakis 20 мар. 2017

🎉9 ❤6

Все 3 Комментарий

15310 охватывает требования к DaemonSet для перехода от бета-версии к GA, включая оркестровку обновлений на стороне сервера. Я бы предпочел приложить к этому усилия, но это сложно, и мы не планируем работать над этим в версии 1.3.

Если вы хотите предложить решение на стороне клиента, хотя это не является долгосрочным направлением, которое мы имеем в виду (# 12143), не следует вводить новую команду. Вместо этого мы должны заставить kubectl rolling-update работать для DaemonSet (и ReplicaSet, если вы так склонны).

https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/rollingupdate.go

Поскольку rolling-update не указывает тип ресурса ( replicationcontroller ), мы должны принять rc по умолчанию. Помимо этого, я думаю, что синтаксис естественно расширяется для других типов контроллеров, используя синтаксис типа / имени.

Например:

kubectl rolling-update daemonset/mydaemon --image=image:v2

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

Текущая команда скользящего обновления создает новый ReplicationController и постепенно масштабирует его, уменьшая при этом старый. В случае --image в конце он выполняет "танец удаления", чтобы вернуть имя к исходному RC - он удаляет оригинал, создает другой RC с тем же именем, а затем удаляет временный RC, используемый для развертывания нового образа.

В случае DaemonSet kubectl будет делать противоположное: он обновит исходный DaemonSet и удалит поды один за другим, чтобы вызвать их замену. Если указать --image , это будет сделано в конце. Если было указано новое имя DaemonSet (например, kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml ), новый DaemonSet будет создан в конце процесса обновления, а исходный будет удален. Нам нужно либо убедиться, что DaemonSet обработал это изящно, либо нам нужно будет удалить исходный DaemonSet перед созданием нового (аналогично моему предложению в # 7402).

копи @mikedanese @davidopp @madhusudancs @janetkuo @kargakis @pwittrock @gmarek