CODEWITHSUNDEEP
dockerkubernetesminikube
Yuval Simhon
Yuval Simhon

Reputation: 1459

Update a Deployment image in Kubernetes

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.

Upvotes: 28

Views: 38255

Answers (3)

Rotem jackoby
Rotem jackoby

Reputation: 22068

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.

Upvotes: 2

Ashfaq
Ashfaq

Reputation: 1259

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

Upvotes: 12

pagid
pagid

Reputation: 13867

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

Upvotes: 33

Related Questions