If you are interested in Kubernetes you should also be interested in (distributed) systems architecture. Because it is “just” another tool to operate nuts and bolts in your software landscape, if I may be so crude. I say this because out of the box it offers very little. Yes, it alleviates you from loadbalancing your software containers and gives you a cli to build automation with. But it is up to you to design, build and implement everything else on top of it. But don’t worry, there are many solutions and building blocks to help you with this.  The aim of this series is to lay out focus points needed to tick all the boxes that make you say “We have utilized the capabilities in k8s to cover all important aspects of (containerized) software delivery, security and lifecycle management”.

The complexity of containerized software

Before I go into the k8s part, I want to acknowledge the fact that just before it was introduced, we were forced to deal with one of the biggest paradigm shifts: containerization and the segmentation it brought with it. “Thou shalt split up software into cooperating standalone parts.” Micro services should not be the end game for all, but the vision of software as a network of parts should be on the horizon for all serious software companies. And the promise of software becoming “highly scalable and always up” suddenly made monoliths running on a single computer seen as a serious liability.

And so began a new era in software design. While we just got used to Cloud Computing, and thus Software Defined Networking in the form of deploy-once static cloud infra, we suddenly had to figure out how to deal with dynamic networks for ephemeral containers needing to talk to each other on a need to know basis.

On top of that we were forced to rethink how to monitor application metrics and logs, which were now collected and stored in disparate locations. The introduction of ephemeral IPs for VMs and containers brought new “service discovery” paradigms. So many changes in this new era of “workload orchestration”!

Kubernetes to the rescue

New imperatives were needed to support these new fields of operation. Kubernetes was designed from the ground up with these requirements in mind. But before you can use them, you have to understand the problems they are designed to solve. We will zoom into the most important areas of concern that Kubernetes forces us to deal with:

1. Security by design: every “actor” in your networked application landscape should be operating on a need-to-know basis, and given least necessary permissions only temporarily to do their work.
2. Workloads: artifact attestation, deployment, autoscaling, resource allocation
3. Networking: services, ingress/egress control, network policies, encryption
4. Policies: operator (deploy time) and workload (runtime) permissions regulation
5. Observability: the ability to make sense from (aggregated) metrics and logs from all the distributed parts
6. State: persistent volumes, encryption at rest, backup strategies
7. Extensibility: A solid framework that allows for the modeling and execution of custom automation.

The more experienced reader may observe that the topics in this list were part of software design for a long time already, and that is true. However, the area of operation has now shifted towards kubernetes, which offers us the controls to automate them with a uniform approach. Amazing!

You might also have noted that “security” does not “fit” in that list as a separate thing as it is a crosscutting concern that should be anticipated and incorporated in every step/area of design and development. But because it is so pervasive and important we want to start the series with it, hoping to establish a pragmatic approach and vision that serves you in every step of your journey. Maybe even long after Kubernetes has been forgotten.

Before we continue we ask one thing from the reader: familiarity with containerization. Are you ready? 

‍