While the Docker Workflow Plugin is really great, it still doesn't cover some special needs that a Kubernetes user might have, such as secrets. A typical workflow its more than likely to need to access remote repositories, either to checkout code, push artifacts etc and using secrets in Kubernetes is the cleanest and more secure way to share credentials for those resources.

Not being able to use secrets was pretty much a blocker for us and we desperately needed it for Fabric8 DevOps. So, we though that we should migrate the concept of running builds inside containers, to running builds inside pods, which lead to implementation of the Kubernetes Workflow Plugin.

The Kubernetes workflow plugin

Here is small snippet that demonstrates how you can use Kubernetes Workflow Plugin in order to create a pod in order to perform a maven build:

The beauty of it is that you can just use the standard maven image and run your build inside it (as one would do with the Docker Workflow Plugin). On top of that it allows you to mount your gpg keys using a secretsvolume.

A detailed list of the plugins features:

Running Builds inside Pods

Environment variables

Privileged containers

Volumes

Secrets

Host Path Mounts

Empty Dir Mounts

Manipulating Docker Images

Building

Tagging

Pushing

Building, tagging and pushing docker images

The plugin also allows you to build, tag and push images to a docker registry. Here's a snippet that demonstrates how to do it:
The example is cloning a NodeJS project, creating a simple Dockerfile for it and then triggering a build. Finally, it tags the built image and pushes it to a Docker Registry. In this example "default" is the project name and "172.30.101.121:5000" is the address of the registry. The example was written against Openshift and the plugin is smart enough to handle authenticating to the Openshift. Of course, it also supports reading auth configuration from "${user.home}/.docker/config.json" and also specifying it as part of the DSL.

Note: The building and pushing of docker images could be handled by the Docker Workflow Plugin too, if the docker binaries were available on the node. Why? Because the plugin actually calls the golang docker client via shell. If the step is run on master, the master needs the binaries, if the step is executed on the slave the slave need the binaries, if the step is executed inside the pod, then the pod needs the binaries (which is not ideal). To gain in flexibility the Kubernetes Workflow Plugin uses java to talk to Docker instead.