In this last article of my Kubernetes-101 article I will briefly look at three interesting pieces of the Cloud-Native landscape. The common thread in these technologies is the use of custom resources in Kubernetes.

Security is in general a large and complex topic, and security in Kubernetes is no different. In this article I will go through three important security concepts in Kubernetes: NetworkPolicies, ServiceAccounts (along with Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings), and security contexts.

The times has come to look at the Ingress resource in Kubernetes. The Ingress is used to expose a Service on HTTP or HTTPS outside of your Kubernetes cluster. You can set up advanced routing rules for multiple hosts and paths to allow for complex traffic routing.

In this article I will create a Helm chart for an application consisting of a Service and a Deployment. Helm is a package manager for Kubernetes application and it is a ubiquitous tool in the Kubernetes world and well worth to be familiar with.

In this article we return to the concept of pure Pods. We’ll start by looking at how we can read the logs from our Pods. Next we look at how we can configure different kinds of probes (readiness, liveness, startup) to control when traffic is sent to our Pods. Finally we look at a few sections of the Pod manifest that we have not encountered before.

The time has come to look at workload resources known as Jobs and CronJobs. A Job creates a Pod that performs a given task and then shuts itself down. A CronJob creates Jobs according to a schedule, e.g. once per day at 11:30. Examples of Jobs are taking backups of a database or generating daily or monthly reports.

In the final part of the mini-series on Kubernetes Volumes we will look at Container Storage Interface (CSI) drivers.

We continue our journey into the world of Volumes in Kubernetes by learning about PersistentVolumes and PersistentVolumeClaims. These two resources are used to separate the lifecycle of Volumes from our Pod resources.

Now it is time to provide storage possibilities for our Pods. We do this through the use of Volumes. Volumes are directories with a backing storage media, they allow us to persist data between Pod restarts and they also allow us to share data between containers in our Pod. This is the first of three articles about Volumes.

In this article we will look at how we can provide our Pods with configuration values and secrets using two new Kubernetes primitives: ConfigMaps and Secrets.