Soy muy nuevo en Kubernetes y uso k8s v1.4, Minikube v0.15.0 y el complemento Spotify maven Docker.
El proceso de compilación de mi proyecto crea una imagen Docker y la inserta directamente en el motor Docker de Minikube.
Los pods son creados por la implementación que he creado (usando un conjunto de réplicas) y la estrategia se configuró para type: RollingUpdate .
Vi esto en la documentación:
Nota : el lanzamiento de una implementación se activa solo si se cambia la plantilla del pod de la implementación (es decir, .spec.template).
Estoy buscando una manera fácil/solución alternativa para automatizar el flujo: compilación activada> se inserta una nueva imagen de Docker (sin cambiar la versión)> La implementación actualizará el pod> el servicio expondrá el nuevo pod.
cuando no cambie el nombre o la etiqueta de la imagen del contenedor, simplemente escalaría su aplicación a 0 y volvería al tamaño original con algo como:
kubectl scale --replicas=0 deployment application kubectl scale --replicas=1 deployment application Como ya se mencionó en los comentarios, ImagePullPolicy: Always se requiere en su configuración.
Al cambiar la imagen, descubrí que esta es la forma más sencilla de actualizar el
kubectl set image deployment/application app-container=$IMAGENo cambiar la imagen tiene la desventaja de que no tendrá nada a lo que recurrir en caso de problemas. Por lo tanto, no sugeriría usar esto fuera de un entorno de desarrollo.
Editar: pequeña bonificación: mantener la escala sincronizada antes y después podría parecer algo. me gusta:
replica_spec=$(kubectl get deployment/applicatiom -o jsonpath='{.spec.replicas}') kubectl scale --replicas=0 deployment application kubectl scale --replicas=$replica_spec deployment applicationSalud
Tengo curiosidad por qué no estás cambiando la versión de la imagen (:
Otra opción (además kubectl rollout restart ) es usar el parche de kubectl :
kubectl patch deployment name -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"version\":\"$BUILD_SHA_OR_DATE\"}}}}}}"Con este comando, tiene la flexibilidad de cambiar campos específicos en la especificación de implementación, como el selector de etiquetas, la etiqueta del pod, las variables de entorno, etc.
(*) Otra opción que es más adecuada para la depuración pero que vale la pena mencionar es verificar el historial de revisión de su implementación:
$ kubectl rollout history deployment my-dep deployment.apps/my-dep REVISION CHANGE-CAUSE 2 <none> 4 <none> 5 <none> 6 <none> 11 <none> 12 <none>Y luego volviendo a la revisión anterior ejecutando:
$kubectl rollout undo deployment my-dep --to-revision=11Y luego volver a la nueva.
(**) La CAUSA DEL CAMBIO es <none> porque debe ejecutar las actualizaciones con el indicador --record , como se menciona aquí :
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record(***) Hay una discusión sobre la desaprobación de esta bandera.