Kubernetes: Implementar actualización continua para conjuntos de demonios

Creado en 4 mar. 2016 · 3Comentarios · Fuente: kubernetes/kubernetes

Hola,

Perdón por hacerlo en el orden incorrecto como se menciona aquí: https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md#contributing -a-patch

Hice # 22439 para abordar este problema (en el lado de kubectl)

La necesidad es poder actualizar un conjunto de demonios en una sola línea de comando.
Básicamente es equivalente a hacer:

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

EDITAR: @ bgrant0607 sugirió actualizar el ds en lugar de delte / recreate

areapp-lifecycle areworkload-apdaemonset prioritbacklog siapps

Fuente

Seb-Solon

👍13

Comentario más útil

1.6 incluye actualizaciones continuas para DaemonSets.

kargakis en 20 mar. 2017

🎉9 ❤6

Todos 3 comentarios

15310 cubre los requisitos para que DaemonSet pase de beta a GA, incluida la orquestación de actualizaciones del lado del servidor. Prefiero esforzarme en eso, pero es complicado y no planeamos trabajar en eso en 1.3.

Si desea contribuir con una solución del lado del cliente, aunque esa no es la dirección a largo plazo que tenemos en mente (# 12143), no debería introducir un nuevo comando. En su lugar, deberíamos hacer que kubectl rolling-update funcione para DaemonSet (y ReplicaSet, también, si así lo desea).

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

Debido a que rolling-update no especifica el tipo de recurso ( replicationcontroller ), debemos asumir rc por defecto. Aparte de eso, creo que la sintaxis es naturalmente extensible a otros tipos de controladores, usando la sintaxis de tipo / nombre.

Por ejemplo:

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

Sin embargo, aparte del comando en sí, no esperaría que el procedimiento de actualización compartiera código.

El comando actual rolling-update crea un nuevo ReplicationController y lo escala gradualmente mientras reduce la escala anterior. En el caso de --image , hace un "baile de eliminación" al final para cambiar el nombre al RC original: elimina el original, crea otro RC con el mismo nombre y luego elimina el RC temporal utilizado para desplegar la nueva imagen.

En el caso de DaemonSet, kubectl haría lo contrario: actualizaría el DaemonSet original y eliminaría los pods uno por uno para que fueran reemplazados. Si se especificaran --image , se haría al final. Si se especificara un nuevo nombre de DaemonSet (por ejemplo, kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml ), el nuevo DaemonSet se crearía al final del proceso de actualización y el original se eliminaría. Tendríamos que asegurarnos de que DaemonSet manejara eso con elegancia, o tendríamos que eliminar el DaemonSet original antes de crear el nuevo (similar a mi propuesta en # 7402).

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