10 Basic Facts About Kubernetes That You Didn’t Know

Kubernetes is a growing trend. In recent years, K8s technology has experienced a rapid rise from a small open source Google project to the main project of the Cloud Native Computing Foundation (CNCF).

Nowadays, many organizations and companies are using it to automate the management of containerized applications. But there are a lot of questions around Kubernetes, and in this article, I will try to answer the most popular ones.

What Is Kubernetes?

Kubernetes is a cluster orchestration system. It was designed from the ground up to be an environment for building distributed applications from containers.

The main Kubernetes task is to build and manage distributed systems. Kubernetes's goal is to simplify the organization and scheduling of your application through the fleet. At a high level, this is the operating system for your cluster.

Basically, it allows you to not worry about which specific machines in the data center run components of your application.

In addition, it provides common primitives for testing and replicating your application on these machines. As well as services for connecting your application to microservices so that each layer in your application is separated from other layers so that you can scale/update/maintain them independently from each other.

Although you can perform many of these functions at the application level, such solutions are usually one-time and unreliable; it’s much better to have a separation of issues when the orchestration system is responsible for running the application, and you only think about your application code.

Why Is Kubernetes Abbreviated K8s?

Have you ever wondered why Kubernetes called the K8s?

So-called numeronyms appeared in the late ’80s. There are a lot of different stories about how people actually started to use them.

But all of the stories share the same idea that to simplify communication, people in IT companies started to use numeronym forms to shorten the words: taking the first and the last letter and between them putting a number of the rest letters.

For instance, the term “i18n,” is derived from the spelling of "internationalization," as the letter “i” plus 18 letters plus the letter “n.” And similar for Kubernetes, “k” plus 8 letters plus the letter “s.”

How Is Kubernetes Different From Docker Swarm?

Docker Swarm was created by Docker Inc. and grew up as an orchestrator for Docker. Kubernetes was originally made by Google for internal use (the Borg project), and now the whole Open Source world is working on it. Docker Swarm is a closed system.

Both are trying to solve the same problem – container orchestration on a large number of hosts. These are two fundamentally similar systems, there are still differences.

• Kubernetes is developing much faster and occupies most of the market (Kubernetes 51% and Docker Swarm 11%).
• Docker Swarm is less scalable and there is no built-in support for load balancing, which K8s has. In fact, Docker Swarm offers only one method of load balancing, which is based on opening a fixed port for each service on each server included in the cluster.
• Unlike Docker Swarm, K8s offers a built-in implementation for both internal (East-West) and external load balancing (North-South). Internal balancing is provided by the Service object and allows you to reach from one application in a cluster to all the living instances of another application by referring to the Service object. The Service is an internal load balancer, that knows at each moment of time which of the backend of the application is alive and which does not work and sends requests only to live replicas.
• External load balancing in Kubernetes is provided by the NodePort concept (opening a fixed port on the load balancer), as well as through the built-in LoadBalancer primitive, which can automatically create a load balancer in the cloud if Kubernetes works in a cloud environment, for example, AWS, Google Cloud, MS Azure, OpenStack, Hidora, etc.
• Docker Swarm does not support Auto-Scaling, neither auto-scaling containers nor auto-scaling nodes.
• Kubernetes supports all possible auto-scalers: vertical scaling due to Vertical Pod Autoscaler, horizontal auto-scaling applications (Horizontal Pod Autoscaler), as well as auto-scaling of the cluster itself (the number of nodes) based on the Cluster AutoScaler. Cluster Autoscaler only works if you run Kubernetes in the cloud.
• Docker Swarm has difficulties with monitoring. You can monitor containers mostly only with the help of proprietary tools.
• Persistent storage for stateful applications is not natively supported in Docker Swarm. You need to work with network attached storage, which is not good for all types of workloads.
• Docker Swarm only works with Docker containers, whereas K8s can work with many container runtime options, such as Docker, Rocket, ContainerD, and others. This is very important because There is no dependency on specific docker features (some of them are available only in Docker EE).

Why Do You Need Container Orchestration?

• Deploy applications to servers without worrying about specific servers.

You need container orchestrators when you have a microservice application consisting of several services, which consist of containers. And there is another part – the servers on which this application can run.

The container orchestrator performs many tasks. The first task is to initially place the containers of your application on the required number of servers, taking into account the load of the servers, in order to prevent the container from reaching the overloaded server, and also considering the memory and processor requirements for a particular container.

• Scale the application horizontally up and down.

There is another scenario, when an application needs to be scaled horizontally, adding more containers of the same type.

The container orchestrator performs the task of scaling up or down the applications taking into account the resources consumed on each target server, as well as the resource requirements of each application.

In this case, the orchestrator can support the so-called affinity and anti-affinity principles. The last one allows us to guarantee that, for example, all containers of the same type will be launched on different physical servers.

• Restore the application if the server on which it worked fails.

This is called container auto-healing or rescheduling.

If the server fails, you need to properly restore the application. K8s can monitor every container/pod of application to see if this container/pod is alive or not. And if not, Kubernetes will restart it.

In fact, in K8s, this function is called “maintaining the right number of replicas.”

In the case of Kubernetes, you can say, "I want to have 5 containers of my WordPress," and K8s will ensure that you always have 5 containers.

If suddenly there are less than 5 containers, Kubernetes will launch a new container to maintain the quantity. This is important for processing the application and predicting the load.

K8s also monitors the state of the servers on which the application is running, and if the server is dead, it will reschedule all its containers on other servers.

How Does K8s Compare to OpenStack?

Kubernetes is designed to manage container orchestration, and OpenStack is initially designed to manage virtual machines. In other words, OpenStack is used to manage traditional virtual infrastructure, and Kubernetes for containerized.

These are two different systems, both of which are open source systems, developed by the community. The difference is that Kubernetes was originally developed by Google for a long time under the name Borg, and during this time it became a stable service; even the first version was rich in functionality and fairly stable.

OpenStack was developed almost from scratch by the community and OpenStack is very much fragmented.

Both the community and about 30 different companies make their own versions. K8s is more like Apple, and OpenStack is more like Android. Overhead costs and time-to-market for running Kubernetes in production is much lower than with OpenStack.

At the same time, OpenStack manages virtual machines, for example, KVM. Kubernetes can run on top of OpenStack and this is a typical scenario for cloud providers.

Is Kubernetes Only for Stateless Applications?

Kubernetes is not only suitable for stateless applications. An example of a stateless application is usually web applications that perform some function, give HTTP pages, and do not store their states themselves.

It was originally made for stateless apps and support for stateful applications was very limited and unreliable.

Kubernetes supports the concept of persistent volume and persistent volume claims. It also supports various types of volumes, like block storages that can be mounted to pods in exclusive mode, as well as file storages that can be mounted to several pods simultaneously using the NFS protocol, for instance.

Therefore, you can safely place databases or persistent message queues in Kubernetes.

Can I Use it for Hybrid Cloud Deployment? Multi-Cloud?

Initially, K8s supported only deployed in one datacenter and work in a hybrid mode was not available.

After that, the Kubernetes Federation was developed, which allowed organizing a hybrid scenario when there are several Kubernetes clusters in different datacenters that are controlled from one control panel.

In fact, one of the clusters becomes the main federated cluster and the hybrid cloud control panel is installed on it. With it, you can manage deployments in several clusters that are far from each other.

But it is also possible in the multi-cloud scenario. If you have one on-premise cluster, one cluster on Amazon, another on Google Cloud, this will all be supported.

In the case of several cloud providers, you do not have to adapt the application to work at once with several remote clusters that work in Google, Amazon, because the Kubernetes will correctly interpret annotations in their resources for each cloud.

The Kubernetes federation v1 project has been developing for a long time and it has reached an impasse, Kubernetes federation v2 is currently developing, which fundamentally works in a different way with a hybrid cloud.

Do I Need to Manage an External Load Balancer to Run My Applications in Kubernetes?

In the case of Docker Swarm, it was necessary to manage an external load balancer in order to balance the load.

K8s contains automatic load balancing based on the concept of services and, in addition, an ingress controller that supports load balancing by DNS name and path.

Many options are supported. There is also integration with the cloud load balancer: if you work somewhere in Amazon, Google Cloud, or OpenStack, there is integration out of the box with those load balancers.

What Is the Difference Between a Pod and a Container?

The problem is that people who come from the Docker world only work with containers.

They are trying to transfer the knowledge they gained when using Docker Swarm and containers to work with Kubernetes. But it doesn’t work this way. In Kubernetes, the control unit is the pod, not the container.

A pod is a group of one or more containers that perform the same function. This is a component of a single application. Kubernetes manages pods, scales and monitors their condition. The application in Kubernetes is scaled by the number of pods, but not containers.

In one pod most often there is a single container, but there may be several of them and this set of containers is rigidly fixed. Inside pod containers do not scale in any way and this should be considered when designing applications.

How Does Kubernetes Simplify Containerized Deployment?

Several advantages that Kubernetes gives out of the box:

• In Kubernetes, there is built-in service discovery. In other words, when a new service appears, it is assigned a unique domain name and other services can get information about this service in etcd.
• The second point is that Kubernetes offers flexible manifests for the deployment of applications that support different deployment strategies of container applications. Kubernetes has canary deployment support for A/B tests. There are also built-in health checks and Prometheus-based monitoring.
• Kubernetes uses a rolling update strategy to roll-out pod version updates. Rolling update strategy helps to save the app from downtime by maintaining some instances up-and-running at any moment while performing the updates. When the new pods of the new deployment version are ready to handle the traffic the system first activate them and only after that shut down the old ones.