How Kubernetes Works

Containers are useful for many use cases, from tests, developmnent, and production apps.

The arrival of containers the software development completely. They enabled a way to create repeatable, consistent environments to run code.

Never again could someone say "Well, it worked on my machine." Instead of managing your own OS files, updates, and hardware, the container system allows us to focus instead on our code itself. It takes the security and resource features of VMs without the costs of maintaining your own OS or hardware.

And thus a new era on how teams build and ship software was born.

With developers seeing the benefits of containers in the development and production lifecycle, the need for a contianer orchestration became apparent.

Enter Kubernetes (or k8s as it is abbreviated), which is currently the most popular and in-demand container orchestration tool.

In this post we'll go over Kubernetes and its concepts, how it works and it is structured.

Background

Starting only in 2014, Kubernetes has risen to the #1 container orchestration platform, over Docker Swarm and Apache Mesos. It enjoys high demand due to its quick release cycle most popular tool to manage container infrastructure — with enterprise customers especially.

Kubernetes takes this evolution of container orchestration a step further. It gives a consistent, (relatively) cloud neutral way of deploying and orchestrating your container environments in an Infrastructure as Code (IAC) style.

With it one can define an entire application's structure using YAML. This includes everything from Load Balancers, autoscaling, TLS, networking rules, and more.

Combining it with a CI/CD workflow and you have a powerful method of defining, deploying and updating your architecture with speed and high availability. This ability has enabled the fast adoption of Kubernetes worldwide, with countless organizations adopting it.

It's complex however, and it's important to understand how it works.

Kubernetes Fundamental Concepts

The goal of Kubernetes is to coordinate your containers to be highly available and to act as a single unit. All applications need to be containerized for it to work.

Tip: If you don't know containers well I highly recommend Brian Holt's Complete Intro to Containers.

The Basic Architecture

Kubernetes has a "hub and spoke" pattern, where control of a cluster of containers is orchestrated from an API server that fans out to nodes who then talk to pods

Diagram of a node and its pods

The master (or control plane)

The master, or control plane, acts as the "brain" of kubernetes. Monitors the entire cluster, and manages its operation using the Kubernetes API.

The master handles the High Availability aspects of Kubernetes, from self healing of nodes and pods to replacement if a node goes down.

The node

Nodes are individual worker servers (computers or VMs) that host groups of containers, depending on your design. They are responsible for checking the health of each container on the node, and restarting or repairing containers that have problems.

The pod

The smallest unit item in Kubernetes is the Pod. Usually a single container run from an image (the kind you build with a Dockerfile) pulled from some container registry.

A Pod can run multiple containers, but that's an advanced use case like sidecars.

Services and Deployments

But how do we manage application lifecyle, and scaling, or networking? Kubernetes separates them into services and deployments.

Deployments

A deployment definition handles your full applicaton lifecycle, like rollouts of new pods, to auto healing and auto scaling.

A deployment spec will take in your desired Pod state (such as images) along with information about a desired number of containers, and how a rollout of updates should work.

Deployment controllers monitor your images for changes, and will use the ReplicaSet specified within your deployment yaml specification to deploy changes, handle failures and rollbacks, all automatically for you.

They are a high level Controller that combine other services like ReplicaSets and others to manage your app's lifecycle.

Networking with Services

Kubernetes doesn't automatically setup any networking for us. It expects us to define them in our .yaml files. To do this, we use services

A Kubernetes service is a policy definition for handling networking of pods in your cluster, for inside and outside communication.

Since pods can be created or destroyed at any time, it's important to define how pods should be able to contact one another regardless of Pod lifecycle. A Service definition defines your networking topology within your cluster.

Example: A frontend pod (serving a static web page for example) needs to communicate with a backend pod (maybe a DB or redis cache). If you deploy a new update to the backend pod, how does the frontend pod know the new IP of the backend pod?

These are the most common types of Services:

• ClusterIP: The default service. It exposes a service IP available for the cluster only.
• NodePort: Exposes a port on the external cluster IP (called NodePort), and creates a port for the node itself (called port)s , that allows you to connect to other ports or externally
• LoadBalancer: For using external cloud load balancers for cloud deployments, such as the ALB from AWS or Cloud Load Balancer from GCP.
• Ingress: A method for using a third party load balancer (such as nginx, HAProxy, or Envoy) within your cluster. Currently becoming the defacto method for implementing load balancers in clusters.

Controllers

Controllers track a resource(s) and makes sure they are in the desired state. This could be something like auto scaling on high loads, keeping a minimum number of pods running, to even running like cron jobs.

The most important ones for beginners are:

StatefulSets

StatefulSets match containers to storage volumes, providing persistence to your workloads (like running PostgreSQL, for example).

ReplicaSets

ReplicaSets ensure that you have a minimum number of pods you specify be deployed at all times.

You would typically want to use Deployments instead of replicasets, as they manage ReplicaSets and have other useful features.

Conclusion

And that's pretty much it! This overview gives you a good understanding of how kubernetes works conceptually, and will allow you to understand what is going on in the background and how it connects everything together.

Need help with kubernetes? You can contact me stephen@lizcano.dev