At the highest level, Kubernetes is two things:

• A cluster for running applications.
• An orchestrator of cloud-native microservices apps.

Kubernetes as a cluster

Kubernetes is like any other cluster – a bunch of nodes and a control plane. The control plane exposes an API and records the state in a persistent store; it also has a scheduler for assigning work to nodes. Nodes are where application services run.

It can be useful to think of the control plane as the brains of the cluster and the nodes as the muscle. In this analogy, the control plane is the brain because it implements all of the important features, such as auto-scaling and zero-downtime rolling updates. The nodes are the muscle because they do the every-day hard work of executing application code.

Kubernetes as an orchestrator

Orchestrator is just a fancy word for a system that takes care of deploying and managing applications.

Let’s look at a quick analogy.

In the real world, a football (soccer) team is made of individuals. No two individuals are the same, and each has a different role to play in the team – some defend, some attack, some are great at passing, some tackle, and some shoot. Along comes the coach, and he or she gives everyone a position and organizes them into a team with a purpose.

The coach also makes sure the team maintains its formation, sticks to the game plan, and deals with any injuries and other changes in circumstance.

Well, guess what? Microservices apps on Kubernetes are the same. Stick with me on this.

We start out with lots of individually specialized services – some serve web pages, some perform authentication, some perform searches, others persist data. Kubernetes comes along – a bit like the coach in the football analogy – and organizes everything into a useful app and keeps things running smoothly. It even responds to events and other changes.

In the sports world, we call this coaching. In the application world, we call it orchestration. Kubernetes orchestrates cloud-native microservices applications.

How it works

To make this happen, you start out with an app; you package it up and give it to the cluster (Kubernetes). The cluster is made up of one or more masters and a bunch of nodes.

The masters, sometimes called heads or head nodes, are in charge of the cluster. This means they make scheduling decisions, perform monitoring, implement changes, respond to events, and more. For these reasons, we often refer to the masters as the control plane.

The nodes are where application services run, and we sometimes call them the data plane. Each node has a reporting line back to the masters and constantly watches for new work assignments.

To run applications on a Kubernetes cluster, we follow this simple pattern:

1. Write the application as small independent microservices in our favorite languages.
2. Package each microservice in its own container.
3. Wrap each container in its own Pod.
4. Deploy Pods to the cluster via higher-level controllers, such as, Deployments, DaemonSets, StatefulSets, CronJobs etc.

We’re still near the beginning of the course, and you’re not expected to know what all of this means yet. However, at a high level, Deployments offer scalability and rolling updates; DaemonSets run one instance of a service on every node in the cluster; StatefulSets are for stateful application components, and CronJobs are for short-lived tasks that need to run at set times. There are more than these, but these will do for now.

Kubernetes likes to manage applications declaratively. This is a pattern where you describe how you want your application to look and feel in a set of YAML files. You POST these files to Kubernetes, then sit back while Kubernetes makes it all happen.

But it doesn’t stop there. Because the declarative pattern tells Kubernetes how an application should look, Kubernetes can watch it and make sure things don’t stray from what you asked for. If something isn’t as it should be, Kubernetes tries to fix it.