Cloud computing, containerization, and container orchestration are the most important trends in DevOps. Whether you’re a data scientist, software developer, or product manager, it’s good to know Docker and Kubernetes basics. Both technologies help you collaborate with others, deploy your projects, and increase your value to employers.

There are a lot of Kubernetes terms, which can make it intimidating. I’ll help you make a mental model to speed your understanding of the technology. Kubernetes online training for more techniques.

Kubernetes is an open-source platform for managing containerized apps in production. Kubernetes is referred to as K8s for short. I’ll mostly use the term K8s going forward, because who doesn’t love efficiency?

Why is K8s so in demand? Kubernetes makes it easier for you to automatically scale your app, reduce downtime, and increase security. No more writing scripts to check, restart, and change the number of Docker containers. Instead, you tell K8s your desired number of containers and it does the work for you. K8s can even automatically scale your containers based on resources used.

Kubernetes is all about abstracting away complexity. It provides clear points to interface with your app’s development environment.

K8s doesn’t make a lot of sense for a basic static website that gets a handful of visitors per day. Its use case is for larger apps that might have to scale up and down quickly.

For large apps, you can use K8s to get the most out of your compute and storage resources. When paired with cloud providers, K8s can save you money. No matter where you run K8s, it should help you save time and reduce DevOps headaches.

Docker has a competing product named Docker swarm that orchestrates containers. However, it doesn’t have the features and market share that K8s does. While you might think that Docker wouldn’t play nicely with K8s when it has its own offering, the two play extremely well together. I strongly suggest you use K8s to orchestrate your containers.

Keeping the many K8s abstractions straight can be tricky. I’ll explain how the key parts fit together so you can wrap your head around this powerful platform. Let’s explore key K8s concepts and how they relate to each other.

First we’ll look at six layers of abstraction and the parts that make them up. Then we’ll look at seven other key K8s API objects.

The Six Layers of K8s

Let’s assume you have an app that is running continuously and doesn’t need to store state.

Here are the six layers of K8s concepts, starting with the highest-level abstraction.

1. Deployment
2. ReplicaSet
3. Pod
4. Node Cluster
5. Node Processes
6. Docker Container

Deployment, ReplicaSet, Pod levels are higher-level K8s abstractions. The Node Cluster, Node Processes, Docker Container levels represent Nodes and Node subprocess that you should be aware of, but may not touch.

Note that your K8s instances will often have multiple Pods that can run on a single Node.

Deployment

If you want to make a stateless app that will run continuously, such as an HTTP server, you want a Deployment. Deployments allow you to update a running app without downtime. Deployments also specify a strategy to restart Pods when they die. You can create a Deployment from the command line or a configuration file. Kubernetes online course helps you to learn more effectively.

ReplicaSet

The Deployment creates a ReplicaSet that will ensure your app has the desired number of Pods. ReplicaSets will create and scale Pods based on the triggers you specify in your Deployment.

Replication Controllers perform the same function as ReplicaSets, but Replication Controllers are old school. ReplicaSets are the smart way to manage replicated Pods in 2019.

Pod

A Pod contains a group of one or more containers. Generally, each Pod has one container.

Pods handle Volumes, Secrets, and configuration for containers.

Pods are ephemeral. They are intended to be restarted automatically when they die.

Pods are replicated when the app is scaled horizontally by the ReplicationSet. Each Pod will run the same container code.

Pods live on Worker Nodes.

Docker Container Level

Your app needs to be in a container of some sort if you want to run it with K8s. Docker is by far the most common container platform. We’ll assume you’re using it.

You’ll specify which Docker image your Pods should use when you create your Deployment. The Container Runtime will download the image and create the containers.

K8s doesn’t create containers directly. It creates Pods that hold containers inside them. The containers in a Pod share any configured resources, such as Volume storage.

There are five high-level K8s API resources that manage and run Pods: Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs. These objects are responsible for managing and running the Pods that create and run your containers. Let’s look at these controllers that create and manage continuous processes.

ReplicaSets, StatefulSets, and DaemonSets

As you’ve seen, a ReplicaSet creates and manages Pods. If a Pod shuts down because a Node fails, a ReplicaSet can automatically replace the Pod on another Node. You should generally create a ReplicaSet through a Deployment rather than creating it directly, because it’s easier to update your app with a Deployment.

Service

A K8s Service creates a single access point for a group of Pods. A Service provides a consistent IP address and port to access underlying Pods. Both external users and internal Pods use Services to communicate with other Pods.

Services come in a variety of flavors. Networking with K8s a topic worthy of its own guide.

Volumes, PersistentVolumes, and PersistentVolume Claims

Volumes

A Volume is a directory that can hold data. A Volume is a component of a Pod, and is not independent of it. A Volume is created in the Pod specification. A Volume cannot be deleted on its own.

A Volume is made accessible to all the containers in a Pod. Each container that you want to access the Volume must mount it individually.

A K8s Volume outlives any individual containers, but when the enclosing Pod dies, the Volume dies, too. However, the files of some Volu

Wrap

I hope you found this introduction to K8s concepts helpful. If you did, please share it on your favorite social media so others can find it, too.

Let’s recap the K8s concepts we’ve seen. Here are the six levels of abstraction for a Deployment:

• Deployment: manages ReplicaSets. Use for persistent, stateless apps (e.g. HTTP servers).
• ReplicaSet: creates and manages Pods.
• Pod: basic unit of K8s.
• Node Cluster: Worker Nodes + Cluster Master.
  - Worker Nodes: machines for Pods.
  - Cluster Master: directs worker nodes.
• Node Processes
  Master subcomponents:
  - API server: hub.
  - etcd: cluster info.
  - scheduler: matcher.
  - kube-controller-manager: cluster controller.
  - cloud-controller-manager: cloud interface.
  Worker Node subcomponents:
  - kubelet: Worker Node brain.
  - kube-proxy: traffic cop.
  - container-runtime: Docker.
• Docker Container: where the app code lives.

Here are the 7 additional high-level K8s API objects to know:

• StatefulSet: Like a ReplicaSet for stateful processes. Think state.
• DaemonSet: One automatic Pod per Node. Think monitor.
• Job: Run a container to completion. Think batch.
• CronJob: Repeated Job. Think time.
• Service: Access point for Pods. Think access point.
• Volume: Holds data. Think disk.
• PersistentVolume, PersistentVolumeClaim: System for allocating storage. Think storage claim. Docker and kubernetes training for more skills.

Wrapping your head around K8s requires understanding many abstract concepts. Don’t expect that you’ll remember them all the first time. Check out some of the resources below to build your mental model.