Is there a way to tell kubernetes to update your containers?

2.4k Views Asked by At

I have a kubernetes cluster, and I am wondering how (best practice) to update containers. I know the idea is to tear down the old containers and put up new ones, but is there a one-liner I can use, do I have to remove the replication controller or pod(s) and then spin up new ones (pods or replicaiton controllers)? With this I am using a self hosted private library that I know I have to build from the Dockerfile and the push to anyway, this I can automate with gulp (or any other build tool), can I automate kubernetes update/tear down and up?

3

There are 3 best solutions below

0
On BEST ANSWER

Found where in the Kubernetes docs they mention updates: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/replication-controller.md#rolling-updates. Wish it was more automated, but it works.

EDIT 1

For automating this, I've found https://www.npmjs.com/package/node-kubernetes-client which since I already automate the rest of my build and deployment with a node process, this will work really well.

3
On

Kubectl can automate the process of rolling updates for you. Check out the docs here: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/kubectl_rolling-update.md

A rolling update of an existing replication controller foo running Docker image bar:1.0 to image bar:2.0 can be as simple as running kubectl rolling-update foo --image=bar:2.0.

0
On

The OpenShift Origin project (https://github.com/openshift/origin) runs an embedded Kubernetes cluster, but provides automated build and deployment workflows on top of your cluster if you do not want to roll your own solution.

I recommend looking at the example here: https://github.com/openshift/origin/tree/master/examples/sample-app

It's possible some of the build and deployment hooks may move upstream into the Kubernetes project in the future, but this would serve as a good example of how deployment solutions can be built on top of Kubernetes.