This is the second article in a series I plan to write about my experience learning and using Kubernetes. In the previous post I talked about why I wanted to use Kubernetes. In this post I will go over the main concepts of Kubernetes.
Summary
If you don't have time to read the entire article, here are the most important things to know.
Key Components of Kubernetes:
- Node: A machine (or VPS) in your cluster
- Pod: One or more containers that run together
- ReplicaSet: Manages multiple pods and controls concurrency/redundancy
- Deployment: Manages deploying new versions of pod by spinning ReplicaSets up and down
- Service: Routes communication between pods
- Ingress: Routes requests from the outside world into your cluster
- Secret: Manages secrets that are deployed to pods
Important concepts:
- Use Deployments and avoid creating Pods and ReplicaSets yourself
- Deploy secrets and configs to your pod instead of including them in the containers
Main Components
The following sections describe the most important components that you need to understand in order to get started with Kubernetes. I intentionally avoided some parts of Kubernetes to keep this article relatively short. You should definitely eventually understand all the components of Kubernetes, but the following list should be sufficient to get started.
Nodes
A Node is a machine that is controlled by your Kubernetes cluster. It could be a bare-metal machine or a VPS. Kubernetes aims to manage the Nodes so that you don't have to think about them too much. For this reason I don't think it's necessary to go into more detail about them.
Pods
Pods are the main building blocks in Kubernetes. A Pod consists of one or more containers that run together along with all the resources allocated to them such as volumes. Pods are how you deploy and run your code. When a Pod has multiple containers, they are run together on the same Node.
It's important to note that containers in a Pod share a network space.
This is particularly different if you're used to running things in docker and docker-compose.
It means that containers in the same pod can communicate with each other through localhost
and it also means that two containers in a pod can't listen on the same port at the same time.
Besids that, pods can be configured in much the same way you would do in docker and docker-compose.
You can pass secrets, configuration files, environment variables, and mount storage volumes to the local filesystem.
IMPORTANT: Keep in mind that although you can, you most likely do not want to be directly creating Pods yourself. In the next sections we'll be talking about ReplicaSets and Deployments, which are what you should be using to manage Pod lifecycles.
ReplicaSets
A ReplicaSet is a controller used to run multiple pods. A ReplicaSet works to keep a number of healthy Pods running. For example, if you specify that you want three instances of your Pod running, the ReplicaSet will do things like:
- Find the right machines to deploy the Pods to
- Restart a Pod if it crashes
- Redeploy Pods to new Nodes if a Node goes down
Using ReplicaSets instead of creating Pods directly is a great idea. However, similar to what I previously said about Pods, you probably don't want to be creating your own ReplicaSets directly either. Instead, you should be using a Deployment to manage them, which brings us to the next section...
Deployments
Deployments are used to manage updates to Pods and ReplicaSets. Deployments allow you to do things like:
- Roll out a ReplicaSet
- Roll out a new ReplicaSet when you update your pods
- Spin down old ReplicaSets
- Fall back to previous ReplicaSet when an update fails
In most scenarios, Deployments are what you want to be creating and pushing to Kubernetes. I will talk in more detail about this in future posts.
Services
The important thing to know about Services
is that they allow you to communicate with Pods.
A Service allows you to assign a DNS name to a group of pods.
For example, you could assign a service named my-service to a group of pods
and then access them at http://myservice from other pods.
Ingresses
Ingresses allow you to route external traffic into your cluster. With Ingresses you can map request to different services in your cluster based on the host name and/or path of the request.
Secrets
Secrets allow you to store keys and certificates that your pods need to run. It's not good practice to include passwords and secrets in your code. With Secrets, you have Kubernetes inject this sensitive data into your application at runtime instead.
Conclusion
And there you have it, the basics of Kubernetes. This is by no means enough information to spin up your own cluster. However, my hope is that this post provides you with enough information to visit the Kubernetes documentation and understand what's going on there.
In upcoming posts I will get more practical, with a step-by-step tutorial on how to set up and deploy a simple service with Kubernetes.