If you’re a Back-End Developer or Full-Stack Developer, you may already be familiar with containerized applications. For those who aren’t: Containerized apps come with all the code, files, and packages they need to run properly on any device, and they’re especially popular with Agile and DevOps teams.
But how can an application run on hundreds or thousands of containers without causing problems? And when one container fails, why doesn’t the whole program crash?
The answer is Kubernetes. If you haven’t heard of it before, no problem. Ahead, we’ll walk you through the basics of what Kubernetes is and how it helps developers seamlessly manage huge containerized applications.
What is Kubernetes?
Kubernetes (pronounced koo-ber-NEH-tees) is an open-source container orchestration platform that helps Software Developers deploy, manage, and scale containers. It was developed by Google in 2014, but now it’s managed by the Cloud Native Computing Foundation (CNCF) — an organization whose founding members include Google, Docker, Twitter, Red Hat, Huawei, Intel, and IBM.
Kubernetes is often written as K8s (a ‘K,’ followed by eight letters, followed by an ‘s’), and it comes from the Greek word that means “helmsman,” “pilot,” or “governor” — an appropriate name for a platform that directs how software containers run together.
What’s a software container?
A software container contains all the source code, libraries, plug-ins, and other dependencies needed to run an application. This makes it easy to move the software from one computer to another along with everything the software needs to run.
In an Agile or DevOps environment, developers often divide a larger application into smaller, independently run software units called microservices. When each development team is finished with their microservice, they package it into a container to be run and managed separately from the other microservice containers.
Containerized applications have become extremely popular over the last few years, and it’s common to see software running on multiple containers or even containers packaged within containers.
What does Kubernetes do?
If you only need to run a few containers on your computer or a local machine, then there’s nothing to worry about. They probably don’t require a lot of system resources, and you can easily troubleshoot issues like a container shutting down unexpectedly.
But what if your software relies on 50 containers spread out over different computers and servers? Or 500? Or two billion? (That’s the number of containers Google runs each week.)
Kubernetes was created to manage many containers hosted across different servers. If you want to deploy containerized software at a massive scale, then Kubernetes is one of several CAAS (containers as a service) tools that can be leveraged to manage these resources.
Kubernetes is a container orchestration system — it helps automate managing large groups of containers that work together to run a single process or application. That includes:
- Managing resources for specific containers or container groups
- Deploying replicas of containers to improve efficiency
- Restarting containers that unexpectedly shut down
- Scheduling requests and container deployment to specific servers
Kubernetes functions almost like the conductor of an orchestra. Each container is a musician — they come with their own instrument, talent, sheet music, and everything else they need to make great music on their own. But it’s Kubernetes that decides how many flutes are needed, who gets to play the big solo, how loudly the violins should play, and when to start and stop the music. When it’s time for a quartet to perform, Kubernetes dismisses the other musicians that aren’t needed. And when there’s a need for a big symphony, Kubernetes calls in extra instruments to help out.
Kubernetes architecture and terms to know
If you want to understand the Kubernetes architecture, you’ll need to learn some new words and some new definitions for words you already know.
Pods are the smallest and simplest units of the Kubernetes architecture. Kubernetes technically doesn’t manage containers directly. Instead, it manages pods.
A pod is a group of containers that shares resources such as IP address, memory, CPU, and storage. Containers within a pod are treated as a single application, similar to running a small group of containers on your computer.
A pod can also consist of a single container, which is quite common. The advantage of grouping several containers into a pod is that it allows the containers to easily share the same data. Without Kubernetes, you would need to manually set up shared resources between containers on your own.
A Kubernetes deployment helps define the scale at which you run your application by managing pod replicas. The larger the scale, the more pod replicas you’ll need, so your application can run smoothly by distributing requests among multiple pods that perform the same functions.
Kubernetes also tracks pod health and can automatically add or remove pods as needed to help your application run at scale without wasting resources.
Kubernetes pods aren’t always reliable. Pods and containers run into issues, change IP addresses, and shut down all the time. When that happens, Kubernetes can quickly detect the problem and replace the pod so that the application can keep running.
When Kubernetes sets up new pods, the new pod names and IP addresses might be different from the old ones. The Kubernetes services act as an abstraction, or mask, for the application — automatically mapping a single name and IP address to each pod. That way, the application only needs to work with one set of information.
In other words, the Kubernetes services provide a consistent interface to the outside network, even as pods are continually restarted, renamed, and reassigned IP addresses.
A Kubernetes node is the physical or virtual machine that runs the pods. Nodes come with all the computer resources needed to run the pod.
Kubernetes nodes have limited resources. The control plane helps manage node resources by automating pod scheduling and deployment.
When all of the components above are set up together as a unit, they create a Kubernetes cluster. A cluster typically contains several nodes to run a containerized application.
While Kubernetes is designed to manage multiple nodes spread across different services, sometimes it’s helpful to use a scaled-down version of Kubernetes. That’s where minikube (pronounced mini-koob), a tool that lets developers run Kubernetes locally, comes in. A minikube sets up a single-node Kubernetes cluster that you can run on a personal computer for daily development work.
When developers want to directly interact with Kubernetes, they use kubectl (pronounced koob control), a command-line Kubernetes tool. Developers use kubectl to monitor cluster resources, view logs, and manually deploy applications.
Most applications rely on sensitive data such as passwords and keys to run properly. If this type of data were directly included in a pod specification or container, then anyone who can view or edit the pod would have access to the sensitive data.
A Kubernetes Secret is an object that’s created independently of the pods that use them. That way, there’s no need to include sensitive data in the application source code. Since Secrets are separate objects, Kubernetes and cluster applications can also set special rules for them — for example, ensuring that the data contained in a Secret isn’t permanently recorded.
Operators help extend Kubernetes’ functionality by linking it with the additional tools and resources needed to run a specific application. For example, a database operator allows developers to use Kubernetes to manage and deploy databases without having to come up with a custom workaround or extension.
Kubernetes node components
Kubernetes nodes are made up of three main components: a Kubelet, a container runtime, and a Kube proxy.
A Kubernetes Kubelet (pronounced KOOB-let) constantly tracks the health of a pod and makes sure that all the containers within the pod are running properly. Every few seconds, the Kubelet sends an update to the control plane. If it stops sending messages, then the control plane considers the node to be unhealthy and will attempt to restart or replace the pod.
Kubelets work from a set of instructions, or PodSpecs, that indicate which containers should be running within a Pod at any given time.
Kubernetes doesn’t directly run containers. Instead, it relies on a container runtime, which is the software that runs the containers. Popular container runtimes supported by Kubernetes include:
- Windows Containers
Kubernetes tells the container runtime which containers to run as well as when to run them.
A Kube (pronounced koob) proxy is an example of a network proxy. It manages communications to and from a node. When a node receives a work request from another node, it sends the request to the appropriate containers. Kube proxies also manage network rules for communication between pods, such as requests for resources.
Kubernetes and containerized applications are the future
Containerized applications and microservice architecture aren’t going away. So, if you’re interested in becoming a Back-End Developer or Full-Stack Developer, you’ll want to learn everything you can about Kubernetes and other important containerization tools like Docker. That way, you’ll be prepared if you face any interview questions about Kubernetes.