There are many ways of managing secrets in Kubernetes, some ways are simpler than others but when researching this topic for my project at work I found that there are drawbacks to many of these approaches. When managing your secrets in any modern software system, one needs to think of a number of important aspects. For my project, these were the most important:

The internet is a dangerous place, or so we are always told. VPN providers sponsor every second YouTube video, antivirus software is bundled with consumer hardware and many online services are touting internet security-related features as their differentiators. I consider myself an informed internet user — you know, the type of person that won’t open random email attachments or visit dodgy internet sites — but all this advertising got me thinking about my own approach to home internet security and privacy.

Millions of people have been down the same road as I have, the one that leads to you want…

If you’ve read any of my previous articles, you’ll know that I am a big fan of Helm. The “package manager” for Kubernetes as it’s often called is a powerful tool that can be adapted to do far more than merely churning out Kubernetes metadata. Because Helm is the engine that delivers your workloads in a neat little bundle to Kubernetes, why not hook other operational processes into it as part of the Helm upgrade?

Thinking about a CI/CD process from a GitOps perspective, there are a number of stages that are typically employed. …

For the most part, when mapping a file into a container using Helm, the standard approach is to use a ConfigMap, Volume, and VolumeMount. For a single file, this approach works perfectly fine, but what if the requirement is to map a directory of files into a container? What if those filenames do not conform to the YAML key naming standards?

Probably the main reason to use Helm is to dynamically build Kubernetes objects based on an ever-changing set of variables. The ability to dynamically generate a ConfigMap every time you run a Helm upgrade is powerful, but when combined…

Helm umbrella charts, for those who aren’t familiar, describe and encapsulate a deployable collection of loosely couple Kubernetes components as a higher-order Helm chart. In other words, a collection of software elements that each have their own individual charts but, for whatever reason (e.g. design choices, ease of deployability, versioning complexities), must be installed or upgraded as a since atomic unit.

A simple use case for an Umbrella chart could be that of a web application with a separate web-scraper component that populates a database. In this trivial example, the web application and scraper would each be described in their…

In the Kubernetes world, Helm umbrella charts allow the provisioning of sub-charts through the parent-child mechanism. A child chart placed in the the charts folder in Helm can be deployed by declaring the sub-chart in the parent’s Charts.yaml file. One neat feature of Helm is the ability to push values from parent (umbrella) charts down to sub-charts by making use of global variables as shown below.

foo: bar

By specifying the global variable, sub-charts can now reference the global value in the parent’s values.yaml file as follows.

{{- if }}
key1: {{ }}
{{- else }}…

Christopher Parker, MSc

Solutions & Infrastructure Architect working as a consultant. I write about real-world problems in the hope of helping others find solutions to theirs.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store