Kubernetes-client: Rolling update image for multi container pod

Created on 12 Jan 2016 · 10Comments · Source: fabric8io/kubernetes-client

Is there any way to do a rolling update on the Docker image for a multi-container pod?

I was looking at FullExample.java in the tests where it does a rolling update at https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-examples/src/main/java/io/fabric8/kubernetes/examples/FullExample.java#L146-L153.

However, there is no way shown to do an update for a multi container pod. From my understanding, the way to do this would be to:

Read the entire pod spec first (store it in an object)
Update the spec with the new image (find container by name)
Do a rolling update withNewSpec

PodSpec podSpec = client.replicationControllers().inNamespace("thisisatest").withName("nginx-controller").get().getSpec().getTemplate().getSpec();

List<Container> containers = podSpec.getContainers();
/* Logic to iterate, find container by name and update the image comes here.. */

client.replicationControllers().inNamespace("thisisatest").withName("nginx-controller")
.rolling()
.edit().
editSpec().
editTemplate().
withNewSpecLike(podSpec)
.endSpec()
.endTemplate()
.endSpec()
.done();

Is there a better way to do this?
For example,

client.replicationControllers().inNamespace("thisisatest").withName("nginx-controller")
.rolling()
.updateImageForContainerName("nginx", "container-name");

Source

parikhyash

Most helpful comment

@parikhyash: a slightly more elegant yet powerful approach would be to use something like:

client.replicationControllers().withName("name").rolling().edit().accept(new Visitor<ContainerBuilder>() {
  @Override
  public void visit(ContainerBuilder o) {
    o.withImage("myImage");
  }
});

This is a pure visitor pattern implementation. The visit method will be called for every single nested visitor in the structure. In the example above we are explicit that we are interested in container builders, so it will be called just for the nested container builder.

If you have multiple containers in the structure, it will visit all of them, so you may want to wrap the statement in an if clause.

The benefit if not obvious, is that it allows you to write code that is decoupled from the internal structure and is also boilerplate free.

iocanel on 20 Jan 2016

👍2 🎉1

All 10 comments

@jimmidyson @iocanel Any update on this?

parikhyash on 13 Jan 2016

This isn't something we support with this client at the moment. We'd accept a PR for it though if you're willing?

jimmidyson on 14 Jan 2016

@parikhyash: a slightly more elegant yet powerful approach would be to use something like:

client.replicationControllers().withName("name").rolling().edit().accept(new Visitor<ContainerBuilder>() {
  @Override
  public void visit(ContainerBuilder o) {
    o.withImage("myImage");
  }
});

If you have multiple containers in the structure, it will visit all of them, so you may want to wrap the statement in an if clause.

The benefit if not obvious, is that it allows you to write code that is decoupled from the internal structure and is also boilerplate free.

iocanel on 20 Jan 2016

👍2 🎉1

@iocanel That is very, very nice!

jimmidyson on 20 Jan 2016

@parikhyash @jimmidyson: and btw this is something that should work already.

iocanel on 20 Jan 2016

Thanks @iocanel for the really clean and elegant solution!

parikhyash on 21 Jan 2016

Just as an update on this, I've easily been able to implement a customized rolling update logic for multi-container pods based on Docker images and/or container resource changes using the visitor pattern and they work really well.

parikhyash on 28 Jan 2016

@parikhyash That's brilliant - do I hear a blog post coming soon? ;)

jimmidyson on 28 Jan 2016

@jimmidyson Sure once my APIs are ready :)

parikhyash on 29 Jan 2016

@parikhyash, may i please know , any blog posted on this issue?
@iocanel,is the same can be done using client.extensions().replicaset()?