Read on Twitter
A gentle introduction to Kubernetes (short: K8s)
You might have heard the name Kubernetes already and can't really imagine what it is, or you've already heard about it but still need a little more info.
No matter what your background is, this thread is for you!
You might have heard the name Kubernetes already and can't really imagine what it is, or you've already heard about it but still need a little more info.
No matter what your background is, this thread is for you!
What is Kubernetes?Kubernetes is an open source container orchestration platform. It basically handles everything related to deploying, managing and scaling containerized applications.
Its name originates from Greek, meaning something like pilot.
You might have already worked with Docker and created a few containers, started them, and then used it to deploy a database to test your app locally.
And now imagine that you want to take your app, containerize it, and deploy it to a server.
And now imagine that you want to take your app, containerize it, and deploy it to a server.
But instead of only one instance, you want to deploy three instances on three different machines. This seems a little more difficult, doesn't it?
And how should other applications reach your app? Should they really know about all three containers with different IP addresses?
And how should other applications reach your app? Should they really know about all three containers with different IP addresses?
Well, most certainly not, so you need a load balancer or reverse proxy that takes incoming traffic and distributes it across your three instances. This leads to another problem. Every time you add a new instance, you need to add it to your proxy's configuration!
Okay, that's only one app you need to do all the work for. Multiply that by 10, 20, or 35 and you have a small system running at scale.
That would be a lot of manual work, scaling services, configuring proxies, and somehow documenting what runs where and how.
That would be a lot of manual work, scaling services, configuring proxies, and somehow documenting what runs where and how.
Kubernetes was designed and developed at Google to tackle exactly those problems.
To be more precise, Google first developed Borg to tackle those problems, which ultimately lead to the development of Kubernetes as a successor to Borg.
To be more precise, Google first developed Borg to tackle those problems, which ultimately lead to the development of Kubernetes as a successor to Borg.
Google later open-sourced Kubernetes and finally gave it over to the Cloud Native Computing Foundation ( https://www.cncf.io/ ) as a seed technology which now manages it further development.
How does Kubernetes work?Kubernetes is a cluster application that runs distributed on many machines.
While Docker is there to handle containers, Kubernetes is the orchestrator, that uses a container runtime like containerd to manage containers running on multiple servers.
By the way:
containerd is the container runtime also used by Docker under the hood.
Kubernetes recently deprecated Docker as a runtime in favor of OCI-compliant runtimes like containerd.
containerd is the container runtime also used by Docker under the hood.
Kubernetes recently deprecated Docker as a runtime in favor of OCI-compliant runtimes like containerd.
But now take a look at the image below to get an idea of the general architecture of Kubernetes.
The Control Plane components can run on one or on multiple machines. They are the cockpit and make all decisions regarding the whole cluster (like scheduling).
The nodes contain the components necessary to handle user containers.
The nodes contain the components necessary to handle user containers.
A kube-proxy is a component that handles everything related to the network. It basically builds the cluster network and makes that containers and Pods can talk to each other on different machines.
A kubelet is a container and Pod management component. It handles the complete lifecycle of containers and uses the underlying container runtime for that task. It's like a robot copy of you using the Docker API to start and stop containers.
Every time you tell Kubernetes to deploy some containers, the control plane components schedule those containers and then tell the appropriate kubelets to do their work.
The kubelets then call the underlying container runtime and sends the commands you would usually send...
The kubelets then call the underlying container runtime and sends the commands you would usually send...
... by using the Docker CLI, for example.
The kubelets don't use a CLI for that, of course, but connect to the remote APIs (REST e.g.) the container runtimes offer.
They also check if the container is still running and restart it if it becomes necessary.
The kubelets don't use a CLI for that, of course, but connect to the remote APIs (REST e.g.) the container runtimes offer.
They also check if the container is still running and restart it if it becomes necessary.
Controlling KubernetesIf you still remember the image showing Kubernetes' architecture, you might remember that there is an API component located within the control plane components.
Like Docker offering a REST API, Kubernetes does so, as well.
If you want to communicate with the cluster, the API is the way to do so. You could use curl to send requests to the cluster, and use this documentation: https://kubernetes.io/docs/concepts/overview/kubernetes-api/ to find out about all endpoints offered.
Another (and most probably better way as a user) is to use kubectl, which is a CLI tool that sends requests to the Kubernetes API under the hood.
You can read more about it here: https://kubernetes.io/docs/reference/kubectl/
You can read more about it here: https://kubernetes.io/docs/reference/kubectl/
No matter which way you use to communicate with and control the cluster, you'll work a lot with YAML files.
Because how you work with Kubernetes is pretty special. Instead of you telling it what to do, you define a desired state and let Kubernetes decide how to get there.
Because how you work with Kubernetes is pretty special. Instead of you telling it what to do, you define a desired state and let Kubernetes decide how to get there.
Take a look at the following Deployment spec. It tells Kubernetes that you want three instances of an nginx container, reachable on port 80.
If you hand over this spec to Kubernetes, its components will decide how to best reach that goal.
If you hand over this spec to Kubernetes, its components will decide how to best reach that goal.
Oh and did you notice this field 'kind' within the yaml spec?
That's another awesome thing that Kubernetes offers. It is extendable!
Many of Kubernetes' core components are actually implement using custom resource definitions, which define their own version and kind.
That's another awesome thing that Kubernetes offers. It is extendable!
Many of Kubernetes' core components are actually implement using custom resource definitions, which define their own version and kind.
Components within the cluster can react when a yaml spec with a kind, associated with a custom resource definition, is sent and do work based on what is written within this spec.
What's next?Well, there is a lot to learn, and so much to discover. But this thread is over now!
It is the first one of many more to come to tell you more about Kubernetes.
Some will cover more basics. Others will go more in-depth.
But this one remains as it is...
...a gentle introduction on a higher level, trying to give you a basic overview about this container orchestrator that took even the enterprise world as one of the fastest technologies ever adopted.
Hope you enjoyed the read!
Hope you enjoyed the read!
