HasnainWaris

Continuing my Kubernetes series, this post covers storage – one of the trickier concepts to grasp when starting with Kubernetes. Understanding how containers handle data, the difference between ephemeral and persistent storage, and how Kubernetes manages volumes is crucial for running stateful applications.

Before diving into Kubernetes storage, let’s look at how Docker handles storage – it makes understanding Kubernetes much easier.

Docker Storage

Docker stores data on the local filesystem at /var/lib/docker, organizing it into directories for containers, images, volumes, and other data.

When you build a container from a Dockerfile, each line creates a layer. The first time you build, all layers are created fresh. On subsequent builds, Docker uses cached layers for unchanged instructions, making builds much faster.

By default, container storage is ephemeral – when the container is deleted, its data disappears. For persistent data, you need volumes.

Docker Volumes:

Create a volume with docker volume create volume-name. You can then mount this volume to your container, and the data persists even after the container is removed.

Volumes are stored at /var/lib/docker/volumes.

Two mounting methods:

• Volume mount – Mounts a volume from the Docker volumes directory
• Bind mount – Mounts any directory from the Docker host into the container

Storage Drivers vs Volume Drivers:

Storage drivers manage storage for images and containers – handling the layered filesystem.

Volume drivers handle volumes through plugins. These plugins can integrate with third-party storage platforms like NFS, cloud storage, or specialized storage solutions.

Container Storage Interface (CSI)

CSI is a standard that allows Kubernetes to work with various storage providers. It makes it possible to incorporate third-party storage platforms without modifying Kubernetes core code. Storage vendors implement CSI drivers, and Kubernetes uses those drivers to provision and manage storage.

Volumes in Kubernetes

Just like Docker, containers in Kubernetes have ephemeral storage by default. To make data persistent, you attach volumes.

Volumes persist even when containers are deleted. However, basic volumes are local to the node they’re on. If your pod moves to a different node, it won’t have access to that data. For sharing volumes across nodes, you need network storage like NFS or cloud solutions like AWS EBS or Azure Disks.

Example: Mounting a directory from node to container

spec:
  containers:
  - name: myapp-container
    image: nginx
    volumeMounts:
    - name: app-storage
      mountPath: /data/app
  volumes:
  - name: app-storage
    hostPath:
      path: /data/foo
      type: Directory

This mounts the /data/foo directory from the node into /data/app inside the container.

Persistent Volumes (PVs)

Configuring storage at the pod level for every application gets cumbersome. Persistent Volumes let you manage storage centrally.

A PersistentVolume (PV) is a cluster resource created via YAML, just like other Kubernetes resources. It defines a block of storage with specific characteristics:

• Storage capacity (e.g., 10Gi)
• Access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany)
• Volume type (hostPath, NFS, AWS EBS, etc.)
• Reclaim policy (what happens when it’s no longer needed)

Example PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-1
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

This defines a 10GB volume using local storage at /mnt/data.

Persistent Volume Claims (PVCs)

A PersistentVolumeClaim is how pods request storage. It’s also a Kubernetes object created via YAML.

Here’s the key concept: PVs are created on the cluster by admins. PVCs are created by users requesting storage. Kubernetes then matches claims to suitable PVs – it’s not a direct one-to-one relationship you configure manually.

Example PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mealie-data
  namespace: mealie
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

This requests 500Mi of storage with ReadWriteOnce access.

How Matching Works:

The Kubernetes control plane looks for a PV that matches the PVC based on:

• Storage capacity – PV must have >= requested storage
• Access modes – must match (ReadWriteOnce, ReadOnlyMany, ReadWriteMany)
• Storage class – must match if specified
• Selectors/Labels – if specified in the PVC

The first suitable match wins – not necessarily the “best” match. Once bound, it’s a one-to-one exclusive relationship. The PV status changes from Available to Bound, and the PVC status changes from Pending to Bound.

Using the PVC in a Pod:

Once your PVC is created and bound, you attach it to your container:

spec:
  containers:
  - image: ghcr.io/mealie-recipes/mealie:v1.2.0
    name: mealie
    ports:
    - containerPort: 9000
    volumeMounts:
    - mountPath: /app/data
      name: mealie-data
  volumes:
  - name: mealie-data
    persistentVolumeClaim:
      claimName: mealie-data

Even if the pod is deleted, the claim remains. PVCs are independent of pods – that’s the whole point. Your data persists beyond the lifecycle of individual pods.

Reclaim Policies

What happens to a PV when its PVC is deleted? That’s determined by the reclaim policy.

Retain (default for manually created PVs):

• PV remains after PVC deletion
• Data is preserved
• PV status becomes Released (not Available)
• An admin must manually clean up the data and make it available again

Delete:

• PV and underlying storage are deleted when PVC is deleted
• Common with dynamic provisioning
• Be careful with this – deleting a PVC deletes your data

Storage Classes

So far, we’ve been manually creating PVs. This means someone has to provision the underlying storage (create the disk, set up NFS shares, etc.) before creating the PV resource in Kubernetes.

Storage Classes automate this process – they enable dynamic provisioning.

The workflow with Storage Classes:

1. Create a StorageClass that defines how storage should be provisioned (which provisioner to use, parameters like disk type, replication settings, etc.)
2. Reference that StorageClass in your PVC
3. Mount the PVC in your pod

When the PVC is created, Kubernetes automatically provisions the underlying storage and creates the PV. No manual disk creation needed.

This is especially useful in cloud environments where you can dynamically provision EBS volumes, Azure Disks, or Google Persistent Disks on demand.

Wrapping Up

Storage in Kubernetes starts with understanding Docker’s layered filesystem and volume concepts. In Kubernetes, we build on this with Persistent Volumes for centralized storage management and Persistent Volume Claims for requesting storage.

The key takeaways:

• Basic volumes are ephemeral and node-local
• PVs provide persistent, centrally-managed storage
• PVCs are how pods request storage from available PVs
• Kubernetes automatically matches PVCs to suitable PVs
• Reclaim policies determine what happens when PVCs are deleted
• Storage Classes enable dynamic provisioning, removing the need for manual storage setup

Understanding these concepts is essential for running databases, file storage, and any stateful application in Kubernetes.

This wraps up storage, I’ll see you in the next post when we’ll cover the last topic, Networking in Kubernetes.

Continuing my Kubernetes series, this post dives into security – one of the most critical aspects of running a production cluster. From authentication and authorization to network policies and securing containers, understanding these concepts is essential for protecting your cluster and workloads.

Security in Kubernetes starts at two levels:

Secure the hosts – Basic security practices like disabling root login, using SSH keys, keeping systems patched. If your underlying nodes are compromised, nothing else matters.

Secure the Kubernetes cluster – Control access to the kube-apiserver. Since the API server is the gateway to everything in the cluster, securing it is critical. This involves determining who can access it (authentication) and what they can do (authorization).

We also use network policies to control pod-to-pod communication at a granular level.

Authentication: Who Can Access the Cluster

Different users and services need to access your cluster – admins, developers, CI/CD systems, monitoring tools. Each needs proper authentication.

User access is managed by the kube-apiserver. When a request comes in, the API server verifies the identity before processing it.

Authentication Mechanisms:

• Static token files – Authentication based on a file containing tokens. Not recommended for production due to security concerns.

• Certificates – Using TLS certificates for authentication. This is the most common and secure method.

• Identity services – Integration with external providers like LDAP, Active Directory, or cloud IAM services.

TLS Certificates in Kubernetes

Communication between master and worker nodes needs to be encrypted and authenticated. Kubernetes uses TLS certificates extensively – server certificates for servers and client certificates for clients.

Server Certificates:

• kube-apiserver has apiserver.crt and apiserver.key
• etcd has its own certificate and key
• kubelet on each node has its certificate and key

Client Certificates:

• Admin users accessing the API server have their own certificates
• Components like kube-scheduler, controller-manager, and kube-proxy also have client certificates
• The kube-apiserver acts as both server and client – it’s a client when accessing etcd

Checking Certificate Health

To verify certificate details, check the YAML files in /etc/kubernetes/manifests for each service. Each file references the certificates being used. You can inspect those certificates to check expiration dates, subject names, and other details.

Understanding certificate locations and validity is crucial for troubleshooting authentication issues.

Certificate API

When a new user needs access, the manual process is cumbersome. Kubernetes has a Certificate API to automate this.

The workflow:

1. User creates their private key
2. User creates a CSR and sends it to an admin
3. Admin creates a CertificateSigningRequest resource in Kubernetes
4. Admin approves the CSR using kubectl certificate approve
5. User can retrieve the signed certificate

Check pending CSRs with kubectl get csr.

KubeConfig: Managing Access

The kubeconfig file (stored at ~/.kube/config) holds details about clusters, contexts, and users. This is how kubectl knows which cluster to talk to and with what credentials.

The three main sections:

• Clusters – Different Kubernetes clusters you might access (production, development, staging)

• Users – Credentials for different users or service accounts, including certificate information

• Contexts – Bridge users to clusters. A context combines a specific user with a specific cluster, optionally specifying a default namespace.

For example, you might have contexts like “admin@production” or “developer@staging”.

Working with contexts:

View all contexts:

kubectl config get-contexts

Check current context:

kubectl config current-context

Switch contexts:

kubectl config use-context production

Use a specific kubeconfig file:

kubectl config --kubeconfig=/path/to/config use-context research

Contexts vs Namespaces

Let’s understand these 2 concepts, this can be confusing at first, so let me clarify:

Namespaces are logical partitions within a single cluster. They organize resources, provide scope for names (you can have a pod named “nginx” in multiple namespaces), and allow you to apply resource quotas and policies.

Common uses: separating environments (dev, staging, prod), multi-tenancy (team-a, team-b), or isolating applications (frontend, backend).

Default namespaces in Kubernetes:

• default – where resources go if you don’t specify a namespace
• kube-system – Kubernetes system components
• kube-public – publicly accessible data
• kube-node-lease – node heartbeat data

Contexts are combinations of cluster + user + namespace saved in your kubeconfig file. They help you quickly switch between different clusters, users, or default namespaces.

Common uses: managing multiple clusters (prod-cluster, dev-cluster), different cloud providers (aws-cluster, gcp-cluster), or different roles (admin-context, developer-context).

The key difference: namespaces exist within the cluster itself, while contexts exist in your local kubeconfig file to help you manage access to multiple clusters.

Authorization: What Can Users Do

Authentication gets you in the door – authorization determines what you can do once inside.

You don’t want all users to have equal access. Admins need full control, developers might only need access to specific namespaces, and monitoring tools need read-only access.

Authorization Mechanisms:

• Node Authorization – For kubelet on nodes to communicate with the API server

• ABAC (Attribute-Based Access Control) – Policies defined per user. Difficult to manage at scale.

• RBAC (Role-Based Access Control) – Create roles defining permissions, then bind users to those roles. This is the most common approach.

• Webhook – Outsource authorization decisions to an external service

You can configure which mechanisms to use and in what order via the authorization-mode flag.

RBAC in Practice

RBAC involves two resources: Roles and RoleBindings.

• Role – Defines permissions: which API resources (pods, services, deployments), and which verbs (get, list, create, delete) are allowed.

• RoleBinding – Associates a role with users or service accounts.

Roles are namespaced – they apply within a specific namespace.

Check role bindings:

kubectl describe rolebinding kube-proxy -n kube-system

This shows which users or service accounts are bound to the kube-proxy role.

Cluster Roles

ClusterRoles work like RBAC roles but at the cluster level, not namespace level. Use these for cluster-wide resources like nodes, persistent volumes, or for granting permissions across all namespaces.

Service Accounts

Accounts in Kubernetes come in two forms: users and service accounts.

Service accounts are for applications that need to interact with the Kubernetes API – things like Prometheus for monitoring, Jenkins for CI/CD, or custom controllers.

When you create a service account, Kubernetes generates a token for authentication.

For external applications: Provide the application with the service account token so it can authenticate to the API server.

For applications running inside the cluster: Every namespace has a default service account that’s automatically attached to pods. To use a specific service account, reference it in your pod spec.

When a service account is attached to a pod, Kubernetes automatically:

• Creates a token
• Mounts it as a projected volume
• Rotates the token periodically
• Expires the token when the pod is deleted

Pod level Security

Image Security

When you specify an image in your pod spec, the full path is registry/user-or-account/image-name.

By default, this pulls from public registries like Docker Hub. For production workloads, you’ll likely use private registries for better security and control.

To pull from a private registry, create a Secret containing the registry credentials, then reference it in your deployment’s imagePullSecrets field. Kubernetes uses this secret to authenticate when pulling the image.

Pod and Container Security

You can define security settings at both the pod and container level – things like which user the container runs as, Linux capabilities, whether it can run as root, and filesystem permissions.

This is done by adding a securityContext section in your pod spec. Container-level settings override pod-level settings.

Example use cases:

• Run containers as non-root users
• Drop unnecessary Linux capabilities
• Make the root filesystem read-only
• Prevent privilege escalation

Network Policies

By default, all pods in a Kubernetes cluster can communicate with each other. Network policies let you restrict this traffic.

A NetworkPolicy is a resource that defines rules for pods – which traffic is allowed in (ingress) and out (egress).

You specify:

• Which pods the policy applies to (using labels and selectors)
• The type of policy (ingress, egress, or both)
• Which ports are affected
• Which sources/destinations are allowed

A single network policy can define multiple rules, handling both ingress and egress in one resource.

Useful Command-Line Tools

kubectx – Quickly switch between contexts. Much faster than typing out the full kubectl config use-context command.

kubens – Switch between namespaces. Saves you from adding –namespace to every command.

These aren’t built into kubectl but are incredibly useful utilities to install.

Custom Resources

Kubernetes lets you extend the API by creating custom resources. You define a CustomResourceDefinition (CRD) that acts as a template for creating resources of your custom kind.

This is how operators and custom controllers work – they define new resource types specific to their needs, then watch and manage those resources.

Wrapping Up

Security in Kubernetes is layered – from securing the underlying nodes, to authentication and authorization, to network policies and container security contexts. Understanding these concepts and implementing them properly is critical for production workloads.

Authentication gets users and services into the cluster, authorization determines what they can do, and network policies control how pods communicate. Add in proper image security and container hardening, and you’ve got a solid security foundation.

In the next post, I’ll cover storage – persistent volumes, volume claims, and stateful applications. See you then!

Continuing my Kubernetes series, this post covers how to manage applications throughout their lifecycle – from deployments and updates to configuration and scaling. I’ll also dive into cluster maintenance tasks like upgrades and backups as well as other topics such as Scaling These are critical topics for keeping your applications running smoothly and your cluster healthy.

Application Lifecycle Management

Rolling Updates and Rollbacks

One of Kubernetes’ strengths is how it handles application updates without downtime. When you create a deployment, it triggers rollout version 1. Update the image and apply the changes, and you get rollout version 2.

Kubernetes tracks these rollout versions, making it easy to roll back if something goes wrong.

Check rollout status and history with kubectl rollout status and kubectl rollout history.

Deployment Strategies:

Recreate – Destroy the existing deployment completely, then create the new one. This causes downtime but is simpler.

Rolling Update (default) – This method brings down one pod at a time and brings up a new one. No downtime, but the update takes longer. This is the default method.

To trigger a rolling update, just apply your updated deployment with kubectl apply and Kubernetes handles the rest – gradually replacing old pods with new ones. Feel free to try this out in your test environment, have 2 windows open. Create a deployment on 1, edit and apply changes to the deployment and from the second window you can see the rolling update take place.

If an update causes issues, roll back with kubectl rollout undo deployment deployment-name.

Configuring Applications

Applications need configuration – commands to run, environment variables to call, and sensitive data like passwords to manage. Kubernetes gives you several ways to handle this.

Commands and Arguments

Remember that containers aren’t meant to be standalone operating systems. They’re stateless applications that exit when their task is done.

When running containers, whether with docker run or in a Dockerfile, you specify what the container should do using CMD, ENTRYPOINT, and ARG.

In Kubernetes, you define these in your pod spec under the container section using the command and args fields.

Environment Variables

You can pass environment variables directly to your containers in the pod spec:

env:
  - name: DATABASE_URL
    value: "mysql://db:3306"

This is the direct approach – you’re hardcoding values in your YAML. It works but isn’t ideal for values you use across multiple pods or sensitive data.

ConfigMaps: Centralized Configuration

ConfigMaps provide a more centralized solution. Instead of repeating the same environment variables across multiple pod definitions, you create a ConfigMap once and reference it from your pods.

Two steps: create the ConfigMap, then inject it into your pods.

You can inject a single environment variable from a ConfigMap:

env:
  - name: PLAYER_INITIAL_LIVES
    valueFrom:
      configMapKeyRef:
        name: game-demo
        key: player_initial_lives

Or use all variables from a ConfigMap at once:

envFrom:
  - configMapRef:
      name: myconfigmap

This second approach is cleaner when you have many related configuration values.

Secrets: Handling Sensitive Data

Secrets work similarly to ConfigMaps but are meant for sensitive information like passwords, API keys, and tokens. The values are encoded (base64) before storing.

Create and reference Secrets the same way as ConfigMaps, just using Secret resources instead. Kubernetes also supports encrypting data at rest using encryption configuration for added security.

Multi-Container Pods

Sometimes you need two services working together closely. Instead of configuring the relationship between two separate pods, you can run multiple containers in a single pod.

This way they scale together, share volume mounts, and share resources. There are different design patterns for this – sidecars, ambassadors, and adapters.

Init Containers

In multi-container pods, you usually expect all containers to run continuously. But sometimes you want a container to run a task and stop before the main application starts – that’s where init containers come in.

Init containers run to completion before the main containers start. Common use cases include setting up configuration files, waiting for dependencies to be ready, or performing database migrations.

Self-Healing Applications

Kubernetes supports self-healing through ReplicaSets and Replication Controllers. If a pod crashes, the controller automatically recreates it. If you’ve specified 3 replicas and one goes down, Kubernetes spins up a replacement to maintain your desired state.

This happens automatically – no manual intervention needed. It’s one of the core features that makes Kubernetes reliable for production workloads.

Autoscaling

Scaling comes in two flavors: horizontal and vertical.

Horizontal scaling – Increases the number of pods or nodes

Vertical scaling – Increase the size (CPU/memory) of existing pods or nodes

Scaling can be done manually or automatically.

Scaling Cluster Infrastructure (Nodes)

To scale the number of nodes in your cluster, you can use the Cluster Autoscaler (Cloud platforms have their own). It watches for pods that can’t be scheduled due to insufficient resources and automatically adds nodes. It also scales down when nodes are underutilized.

Scaling Workloads (Pods)

For pods, you have Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA).

Horizontal Pod Autoscaler (HPA):

You can manually scale with kubectl scale, but that’s not efficient. HPA automates this by observing metrics and adding pods when needed.

Create an HPA with kubectl autoscale deployment myapp –cpu-percent=50 –min=2 –max=10.

This tells Kubernetes to maintain CPU usage around 50%, scaling between 2 and 10 replicas as needed. You can also define these parameters in the HPA spec for more control.

Vertical Pod Autoscaler (VPA):

Manually scaling pod resources is done with kubectl edit, but VPA automates it by observing metrics and adjusting CPU/memory requests and limits.

VPA doesn’t come by default – you need to deploy it separately. It’s useful for workloads with variable resource needs.

In-Place Pod Resizing:

Traditionally, changing a pod’s resources means deleting and redeploying it. There’s a feature for in-place vertical scaling that adjusts resources without recreating the pod, helping avoid downtime. This needs to be enabled as it’s still evolving.

Cluster Maintenance

Now let’s talk about keeping your cluster healthy through upgrades and proper maintenance procedures.

OS Upgrades

When you need to upgrade the OS on a node, that node goes down and its pods become inaccessible.

If the node is down for less than 5 minutes, the controller waits and brings pods back online when the node returns. If it’s down longer, Kubernetes considers the pods dead and the node comes back clean.

The safe way to handle this is to drain the node first with kubectl drain node-name. This gracefully moves the pods to other nodes. Once the upgrade is complete, uncordon the node with kubectl uncordon node-name to allow scheduling again.

You can also cordon a node with kubectl cordon node-name, which just prevents new pods from being scheduled there without moving existing pods.

Kubernetes Version Upgrades

Kubernetes releases follow semantic versioning: 1.xx.xx (Major.Minor.Patch).

When upgrading, there shouldn’t be a big version gap between cluster components, but nothing should run a higher version than kube-apiserver – it’s the central component everything else talks to.

Upgrade Process:

Upgrade master nodes first, then worker nodes. While masters are upgrading, the cluster still runs, but you can’t make changes or deploy new workloads.

For worker nodes, you have different strategies:

• All at once (causes downtime for all workloads)
• One at a time (safer, rolling approach)
• Add new nodes with the new version, drain old nodes, then remove them

With kubeadm:

First upgrade kubeadm itself, then use it to upgrade the cluster.

Steps:

1. Upgrade kubeadm package on the master node
2. Run kubeadm upgrade apply v1.xx.xx on master
3. If kubelet runs on the master, upgrade it too
4. For worker nodes: drain the node, upgrade kubeadm and kubelet packages, run kubeadm upgrade node, restart the kubelet service, then uncordon the node

Repeat for each worker node.

Different Kubernetes distributions (k3s, Rancher, manual kubeadm installations) have their own upgrade procedures, so always check the specific documentation.

Backup and Restore

Backups are critical – you need a recovery plan if something goes wrong.

What to backup:

Resource configuration files – Your YAML manifests. Store these in version control (Git) so you can recreate resources if needed.

etcd – This is where all cluster state is stored – information about nodes, pods, configs, secrets, everything. Backing up etcd means you can restore your entire cluster state.

You can backup the etcd data directory directly, or create a snapshot using etcdctl snapshot save. To restore, use etcdctl snapshot restore.

etcdctl is the command-line client for etcd and your main tool for backup and restore operations.

Certification Exam Tip

In the CKA exam, you won’t get immediate feedback like in practice tests. You must verify your work yourself. If asked to create a pod with a specific image, run kubectl describe pod to confirm it was created with the correct name and image. Get in the habit of verifying everything you do.

Wrapping Up

Managing application lifecycles in Kubernetes involves understanding deployments and updates, properly configuring applications with environment variables and secrets, and implementing autoscaling for reliability and efficiency. Cluster maintenance – from OS upgrades to Kubernetes version updates and backups – keeps your infrastructure healthy and recoverable.

These concepts build on the scheduling and monitoring topics from the previous post. Together, they give you the foundation to run production Kubernetes workloads confidently.

Next in the series, I’ll cover what steps we take to secure our Kubernetes Cluster. See you soon!

My Takeaways from Kubernetes Fundamentals

I recently just wrapped up a Kubernetes fundamentals course and wanted to share some of the key concepts that stuck with me. If you’re just getting started with Kubernetes like I am, hopefully this helps clarify some things.

The biggest thing I learned early on: everything in Kubernetes is defined through YAML files. Once that clicked, things started making a lot more sense.

The course mainly focused on three core components: Deployments, Services, and Storage.

Deployments are where you define your pods. This includes details like what container image you’re using, how many replicas you want running, selectors and labels for organizing things, which namespace you’re working in, and any volumes you want to attach. Think of deployments as the blueprint for what you want running.

Services are what actually give you an IP address to access your pods. Each pod comes with it’s own IP address, but services allow us to group our Pods under a single IP. There are a few types but the main ones are ClusterIP, LoadBalancer, and NodePort. Each one serving its own purpose.

ClusterIP is the default and gives you an internal IP that your pods can use to talk to each other. You can quickly create one using the expose command on an existing deployment. If you need temporary external access, port forwarding does the job.

LoadBalancer is what you use when you need something more permanent and externally accessible. Say you have a group of pods you want exposed to the outside world. You create one LoadBalancer service for them and boom, you’ve got a persistent external IP. No need for port forwarding here.

Storage was probably the trickiest part for me to grasp at first. By default pods are ephemeral and so is the default storage. You can say goodbye to any data on a pod you just deleted. For more persistent storage you can create either Persistent Volumes or Persistent Volume Claims. They work a bit differently but accomplish similar goals. The key benefit is that once you attach these volumes to your deployment, your data sticks around even if the pods get deleted or recreated.

These fundamentals have given me a solid foundation to start working with Kubernetes in real environments. There’s obviously a lot more to learn, but understanding deployments, services, and storage gets you pretty far. Looking forward to diving deeper and sharing more as I continue this journey into container orchestration.