Kubernetes: Implementar atualização contínua para conjuntos de daemons

Criado em 4 mar. 2016 · 3Comentários · Fonte: kubernetes/kubernetes

Oi,

Desculpe por fazer isso na ordem errada, conforme mencionado aqui: https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md#contributing -a-patch

Eu fiz # 22439 para resolver este problema (no lado do kubectl)

A necessidade é ser capaz de atualizar um daemon definido em uma única linha de comando.
Basicamente, é equivalente a fazer:

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

EDITAR: @ bgrant0607 sugeriu atualizar o ds em vez de delte / recriar

areapp-lifecycle areworkload-apdaemonset prioritbacklog siapps

Fonte

Seb-Solon

👍13

Comentários muito úteis

1.6 inclui atualizações contínuas para DaemonSets.

kargakis em 20 mar. 2017

🎉9 ❤6

Todos 3 comentários

15310 cobre os requisitos para o DaemonSet passar de beta para GA, incluindo orquestração de atualização do lado do servidor. Eu prefiro me esforçar nisso, mas é complicado, e não planejamos trabalhar nisso no 1.3.

Se você gostaria de contribuir com uma solução do lado do cliente, embora essa não seja a direção de longo prazo que temos em mente (# 12143), não deve introduzir um novo comando. Em vez disso, devemos fazer kubectl rolling-update trabalhar para DaemonSet (e ReplicaSet, também, se você quiser).

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

Como rolling-update não especifica o tipo de recurso ( replicationcontroller ), devemos assumir rc por padrão. Fora isso, acho que a sintaxe é naturalmente extensível a outros tipos de controlador, usando a sintaxe de tipo / nome.

Por exemplo:

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

Além do comando em si, eu não esperaria que o procedimento de atualização compartilhasse código.

O comando rolling-update atual cria um novo ReplicationController e aumenta gradualmente enquanto reduz o antigo. No caso de --image , ele faz uma "dança de exclusão" no final para mudar o nome de volta para o RC original - ele exclui o original, cria outro RC com o mesmo nome e, em seguida, exclui o RC temporário usado para lançar a nova imagem.

No caso do DaemonSet, o kubectl faria o oposto: atualizaria o DaemonSet original e excluiria os pods um por um para fazer com que fossem substituídos. Se --image fosse especificado, isso seria feito apenas no final. Se um novo nome DaemonSet for especificado (por exemplo, kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml ), o novo DaemonSet será criado no final do processo de atualização e o original será excluído. Precisamos garantir que o DaemonSet lide com isso normalmente ou precisamos excluir o DaemonSet original antes de criar o novo (semelhante à minha proposta em # 7402).

cc @mikedanese @davidopp @madhusudancs @janetkuo @kargakis @pwittrock @gmarek