I'm very new to Kubernetes and using k8s v1.4, Minikube v0.15.0 and Spotify maven Docker plugin.
The build process of my project creates a Docker image and push it directly into the Docker engine of Minikube.
The pods are created by the Deployment I've created (using replica set), and the strategy was set to type: RollingUpdate.
I saw this in the documentation:
Note: a Deployment’s rollout is triggered if and only if the Deployment’s pod template (i.e. .spec.template) is changed.
I'm searching for an easy way/workaround to automate the flow:
Build triggered > a new Docker image is pushed (withoud version changing) > Deployment will update the pod > service will expose the new pod.
when not changing the container image name or tag you would just scale your application to 0 and back to the original size with sth like:
kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application
As mentioned in the comments already ImagePullPolicy: Always is then required in your configuration.
When changing the image I found this to be the most straight forward way to update the
kubectl set image deployment/application app-container=$IMAGE
Not changing the image has the downsite that you'll have nothing to fall back to in case of problems. Therefore I'd not suggest to use this outside of a development environment.
Edit: small bonus - keeping the scale in sync before and after could look sth. like:
replica_spec=$(kubectl get deployment/applicatiom -o jsonpath='{.spec.replicas}')
kubectl scale --replicas=0 deployment application
kubectl scale --replicas=$replica_spec deployment application
Cheers
Use the following functionality if you have atleast a 1.15 version
kubectl rollout restart deployment/deployment-name
Read more about it here kubectl rollout restart
I'm curious why you're not changing the image version (:
Another option (beside kubectl rollout restart) is to use kubectl patch:
kubectl patch deployment name -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"version\":\"$BUILD_SHA_OR_DATE\"}}}}}}"
With this command you have the flexibility to change specific fields in the deployment spec like the label selector, pod label, environment variables etc'
(*) Another option that is more suitable for debugging but worth mentioning is to check in revision history of your rollout:
$ 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>
And then returning to the previous revision by running:
$kubectl rollout undo deployment my-dep --to-revision=11
And then returning back to the new one.
(**) The CHANGE-CAUSE is <none> because you should run the updates with the --record flag - like mentioned here:
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
(***) There is a discussion regarding deprecating this flag.