Have you ever wanted to move a Kubernetes volume (Persistent Volume Claim) to another storage class or back it up? We do it now and again so we created a generally useful container image that can be attached to a pair of volumes to then automatically copy (using rsync) from one to the other.

Have a look at our docker-volume-replicator repository and accompanying public Docker image.

We recently encountered a Kubernetes cluster that had experienced catastrophic etcd failure. We had 3 nodes running etcd that had suddenly been reduced to one without quorum. Repairing the situation required action on a number of fronts.

We had no viable backups, and had to rely on the db file that was left on the remaining etcd node.

Try using popeye, a Kubernetes Cluster Sanitizer, to help lint objects deployed to Kubernetes to detect misconfigurations, and give you some feedback on compliance with community best practices.

Here we’re going to explore repetitive project content and one method you can employ to automate its generation.

After creating a few Ansible-based Kubernetes projects the boilerplate begins to emerge on two fronts - a number of mandatory Ansible files and the Kubernetes object definitions. What’s most frustrating is that, for the most part, Kubernetes objects are often detailed (verbose) yet irritatingly repetitive and predictable.

In this article we’ll see how to deploy container images from a [GitLab] private registry into Kubernetes.

Public container images, in registries like [Docker Hub], can be deployed easily without needing to provide any credentials. Kubernetes Deployments (and other objects like StatefulSets) simply need the image, i.e. informaticsmatters/neo4j:3.5.20. However, images resident on a private registry will require you to deploy an ImagePullSecret that Kubernetes uses to pull the image.

[Kubernetes documentation] describes such secrets with a section explaining how they can be created from the command-line.

Here we provide a brief cheat-sheet that explains how to create a pull-secret using [GitLab] and then use that in a Deployment.

In this brief article we’ll see how to setup a Kubernetes nginx ingress to redirect HTTP traffic from example.com to www.example.com.

Prerequisites here are a cluster with an nginx ingress controller and a route to the cluster. This relies on your domain routing example.com and www.example.com to your cluster, usually through some form of load-balancer. We’re not going to cover these aspect of the solution, just the ingress definition you need.

In this article we’ll see how simple it is to install Kubernetes onto some Ubuntu hosts using [Pharos].

Pharos is a Certified Kubernetes with all batteries included. It is powered by the latest upstream version of Kubernetes kernel and include tools for cluster lifecycle management.