Kubernetes Overview, Part Two
In my previous post we looked at kubectl, clusters, the control plane, namespaces, pods, services, replication controllers, and labels.
In this post we take a look at at volumes, secrets, rolling updates, and Helm.
A volume is a directory, possibly with some data in it, accessible to a container as part of its filesystem. Volumes are used used, for example, to store stateful app data.
Kubernetes supports several types of volumes:
See the documentation for more on each of those.
For the purposes of this post, let's look at one of volumes types: hostPath.
A hostPath volume mounts a file or directory from the host node's filesystem into your pod. It can be used, for example, to provide HTML files for the
my-nginx replication controller we made in the previous post.
nginxrc.yaml with the volume config:
With the replication controller configured like this, the
nginx container will serve HTML files from the host mounted volume.
This might work if you change the number of configured replicas, because
/somepath/shared/html might not exist on other nodes. If you want to scale, you need to replicate files between Kubernetes nodes so they're always available. Or you use the NFS or GlusterFS volume types.
A secret is any piece of sensitive data, such as authentication tokens, encryption keys, SSL certificates, SSH keys, and so on. Secrets can then be made available to containers on request. Putting information in a secret is safer and more flexible than putting it in a pod definition or in a Docker image.
To use a secret, a pod or replication controller needs to reference the secret.
An example of secret manifest file:
Create this by running:
We can then mount this as a volume in our container:
Our app can now consume passwords from the
/etc/my-passwords-volume where two files now exist:
password. If you read those files, you'll get the value you specified in your secret manifest. Simple.
If your app requires environment variables, one approach is to read in the content of these files and then set them as environment variables before starting your app.
For more information about secrets, see the documentation.
In the previous post, we looked at how to deploy pods via replication controllers. For this post, we're going to look at how to do a rolling update, which can, for example, upgrade a Docker image to a newer version.
Here's how you'd do that:
We just updated the pods controlled by our
my-nginx replication controller by upgrading the Docker image. In other words, this deleted the old container and created a new one from a more recent image.
This can only be done when a replication controller is only responsible for one type of Docker image. If your replication controller is managing multiple different docker images, a new replication controller must be created.
For example, you could run:
What this does is update the pods of
my-nginx by using the new replication controller as specified in the
nginxrc-v2.yaml manifest file. When the new replication controller is in place, the old one gets deleted.
Helm is the Kubernetes package manager.
We have learned how to install replication controllers and services on a Kubernetes cluster. You can write your these controllers yourself, or you can use controllers that have been pre-written and tested for you. This is where Helm comes in.
Helm lets you install charts. A chart is a unit of Kubernetes manifests. These charts, then, can be shared by the Helm community.
Let’s install Helm:
You can check available commands:
To start using Helm, first get the latest charts from Github:
Let’s search for a chart:
Weave Scope provides a visual map of your Docker containers. Read more on the official product page.
We can get more information about this chart:
And we can fetch the chart to our workspace:
Helm always saves a copy of the chart to the
So let's install the fetched Weave Scope chart:
Let's check the replication controller is working:
Cool. Now we can check the daemon sets are working:
Weave Scope works on port 4040, but that port is not exposed to us. So let's forward the local port to remote port so we can access it from our laptop remotely.
Get the pods list:
We're interested in the
We can add a port forward like so:
And now you can open
http://127.0.0.1:4040 your browser.
You should see WeaveScope UI:
Great. Everything is working!
If you later want to uninstall Weave Scope, you can do so like this:
In part two of this Kubernetes miniseries we looked at volumes, secrets, rolling updates, and Helm. Helm is the package manager for Kubernetes, and makes it much easier to install and manage Kubernetes manifest files.