Ultimate Kubernetes Security Guide — Part 2 — Kubernetes Architecture — Contd

4 min readMay 12, 2021

Part 1 was explaining the need for Kubernetes. In Part 2 we are talking about the technical reasons for why we need Kubernets and we dive into components in a Kubernetes Architecture.

If you prefer listening to the audio, Click on the image below to hear the audio version of this post:

Ultimate Guide to Kubernetes Security — Part 2 — Kubernetes Components and Architecture

Why Kubernetes (Technical Reason)

A lot of organisations have been adopting Containers as the default standard for deploying application in their infrastructure on Cloud or on-premise.

This was great when there was only 1 Application to deploy. This tends to get really complicated if you start deploying multiple application possibly written in different languages and need to be deployed on different platforms. :)

Container Orchestration Choices:

Docker Swarm is a solution that was initially released to solve the challenge of orchestrating containers at scale but was disappointing when it came to complex architecture which require dynamic scaling with zero down times.

MESOS is (or was rather since Kubernetes has taken over this space) is another solution which has the capability to handle complex architecture but it itself has a complex architecture to get your head around.

Kubernetes for the moment seems to be leading the Container Orchestration space by a landslide compared to the above options especially if you look at their Github downloads. This does solve the complex architecture and dynamic scaling problem with Docker Swarm but similar to MESOS has a complex implementation challenges.

Kubernetes Add-Ons

As mentioned in Part-1 there are a lot of things that Kubernetes is not out of the box. However, to build a complex architecture in Kubernetes requires Add-Ons to fill these gaps.

Let’s talk about the core Kubernetes Components and the cover some of the popular Add-Ons.

Kuberentes Components

Kubernetes has a Server/Client model that it follows to maintain the state.

Server (Master)maintains a record for what state should a Kubernetes Cluster contain and run as application(s).
Client (Worker) on-goingly interacts with the Server to know what state it needs to maintain.

Server/Client model would normally start with Operating System to run the Client but let’s park that for now as we are cover it next week.

Kubernetes Architecture

Kubernetes Services that run in Master and container Control Plane components

Server/ Master Node — Control Plane Components or Mothership

API Server (Cluster gateway) — Interaction point for Kubernetes, which is THE WAY to interact with any Kubernetes Cluster(s). If you are using AWS EKS (eksctl), UnManaged Kubernetes (kubectl)
etcd — Cluster brain with a key value store to store the state of cluster (source of truth for cluster), what resources are available, did the cluster state change?, is the cluster healthy? Did the scheduler start a new pod?
Scheduler — decider where to which Node to put a Pod on? looks for unscheduled nodes? Tells the Kubelet in the worker node to start <insert-app> pod.
Controller Manager — monitors cluster for any pods that have died. This component works with Scheduler to start another Node with the pod.
Container Runtime — Helps execute container orchestration since Kubernetes is running containers after all. 😎
kubectl — Command line interface for Kubernetes Cluster is used by Users to interacts with the API server.

Client/ Worker Node

Kubelet — internal process running as an agent which is part of each node, which talks to the API Server and receives what state to maintain
Deployment — Blueprint/template for what and how many replicas of an application should be deployed
Pods ( Container(s)) — run the application and is also the smallest element in a Node

Storage

Storage in Kubernetes built Containers are ephermal so no local long term storage.
PVC Objects and Storage Classes are used instead of pointing straight to remote storage

NameSpace

Logical Separation of a Kubernetes Cluster ( 4 defaults that come with deployment) — kube-system, kube-public, kube-node-lease (health check), default(used for cluster)
Custom NameSpace can be also created to logically separate resources e.g database, monitoring, etc

Kubernetes Extensions/ Add Ons

Kubernetes does not have all the components you would need to run a production ready large scale complex application architecture. This means the open architecture requires other components to compliment the amazing distribution capability that Kubernetes provides.

Some of the common examples of Kubernetes extension can be:

Istio — Enables a Mesh network between clusters
Envoy proxy- Reverse proxy, load balancer and ingress controller for Kubernetes Cluster

If you are a RISK Analyst who wants to understand how to start doing a RISK Analyst and what a good Kubernetes Architecture looks like, you may want to hear the Cloud Security Podcast episode with Mark Manning who runs Kubernetes Risk Analysis in his day job.

If you found the information valuable, consider following the Cloud Security Podcast on your favourite podcast and video platform to be notified when we create more content like this.

In the Next Part — Kubernetes Security Architecture components.