Kubernetes Deep Dive and Use Cases

When containers were first introduced in 2008, Virtual Machines, or VMs, were the state-of-the-art option to optimize a data center’s physical resources. This arrangement worked well enough, but had some flaws: Virtual machines utilized too many resources because they required both a complete operating system, and emulated instructions to reach the physical CPU. Even with some technologies like Intel VT-x and AMD-V that attempted to solve the emulation problem, virtual machines were behind bare metal.

The goal of containers is to maximize resource utilization to reach a similar bare-metal performance with the advantages of VMs. To do this, a common kernel is shared to all applications that can choose any operational resources as necessary. All containers have exclusive access to resources (like CPU, memory, disk, and network) and each container can be prioritized by a manager. In other words, containers can run on bare metal while sharing resources, but without being able to access other containers’ resources.

How do containers ensure high availability, disaster recovery, or scalability? Container orchestration systems such as Kubernetes (nicknamed K8S) offer a solution. The systems are responsible for handling one or multiple clusters of machines and detect the availability of each image running on it. The size of the clusters can range from three machines to more than thousands of machines and containers, distributed among different cloud providers if needed. If a machine breaks down, the tool should be able to shift its containers to another node while keeping the entire cluster operational.

Orchestrators as a Multicloud Operating System

Container orchestrators handle several machines that can be in the same data center or in different physical locations from different providers. In fact, when using an orchestrator tool such as Kubernetes, it creates an abstraction that an organization won’t need to know where or how its computing resources are distributed. An orchestrator tool transforms the capacity of cloud providers into a commodity that can easily be substituted, or, better yet, organizations can distribute workloads among different providers.

Companies that have an on-premise data center can benefit from container orchestrators as well. If the orchestrator is deployed within a local infrastructure, the unlimited computing resources on the cloud won’t be available. However, companies can manage resources in the same way, which allows for an easy migration if necessary.

Another use case occurs when an operator wants to use unlimited computing capacity of the cloud in addition to internal resources. A hybrid cloud is designed to utilize a company’s existing hardware resources while increasing computing capacity without buying new hardware.

Container orchestration tools like Kubernetes have the capacity to function as a multicloud operating system. Companies do not need to know what they are handling, where the operating system is or who is providing it—they just need to designate what resources need to be running.

The Rise of Kubernetes

First released in 2014, Kubernetes is an open-source container orchestration tool that can automatically scale, distribute and manage fault tolerance on containers. Originally created by Google and then donated to Cloud Native Computing Foundation, Kubernetes is widely used in production environments to handle Docker containers and other container tools in a fault-tolerant manner. As an open-source product, it is available on various platforms and systems. Google Cloud, Microsoft Azure, and Amazon AWS offer official support for Kubernetes, so configuration changes to the cluster itself are not necessary.

The popularity of Kubernetes has steadily increased, with more than four major releases in 2017. K8s also was the most discussed project in GitHub during 2017, and was the project with the second most reviews.

Deploying Kubernetes

Kubernetes offers a new way to deploy applications using containers. It creates an abstraction layer which can be manipulated with declarative rather than imperative programming. This way, it is much simpler to deploy and upgrade services over time. The screenshot below shows the deployment of a replication controller which controls the creation of pods—the smaller K8S unit available. The file is almost self-explanatory: the definition gcr.io/google_containers/elasticsearch:v5.5.1- 1 indicates that a Docker Elasticsearch will be deployed. This image will have two replicas and uses persistent storage for persistent data.

Deploying ElasticSearch through Kubernetes

There are many ways to deploy a tool. A Deployment, for example, is an upgrade from a replication controller that has mechanisms to perform rolling updates — updating a tool while keeping it available. Moreover, it is possible to configure Load Balancers, subnet, and even secrets through declarations.

Computing resources can occasionally remain idle; the main goal is to avoid excess, such as containing cloud environment costs. A good way to reduce idle time is to use namespaces as a form of virtual cluster inside your cluster. Each namespace is a completely isolated space inside Kubernetes, which means several environments can be created as necessary, such as production environments or staging environments. Services within a namespace will receive a DNS name such as <service-name>.<namespace-name>.svc.cluster.local. This means that services within the same namespace just need to make a request to another service using a service name.

K8s can be deployed in very different scenarios depending on the size of the company and its objectives:

• In-house: Organizations can transform their own data center into a K8s cluster. In this case, companies can take full advantage of their own resources.
• Cloud: The setup process is similar to an in-house deployment, but includes virtual machines on the cloud. This allows for the creation of a virtually infinite number of machines, depending on demand.
• Hybrid: An organization’s data center might perform well for most of the day, but sometimes a peak occurs that local computing resources cannot handle. In this case, a hybrid solution works well. When necessary, K8s will create virtual machines on the cloud to better distribute computing resources when on-premise servers are full.
• On-premise: Some cloud providers have their own K8s implementation embedded. In this case, there is no need to deploy and configure Kubernetes itself; an organization just needs to manage the service. Since deploying Kubernetes can be tricky, this is a good solution for companies that do not have a big IT team capable of handling cluster configuration and maintenance.
• Multicloud: This is the next level of a hybrid cloud solution. Computing resources are deployed among two or more cloud vendors. In this case, companies need to avoid vendor lock-in and minimize risk if something goes wrong.

Kubernetes is not the only container orchestrator available. Other popular tools on the market include Docker Swarm and Apache Mesos. Swarm is an open-source container orchestrator intended to be the “big brother” of Docker and Docker Compose. Swarm uses the same command line from Docker and is not very opinionated: organizations must decide which tools to use for nearly every feature needed on their cluster. Apache Mesos is another open-source orchestrator that manages other technologies in addition to managing containers. Apache Mesos calls itself a “data center operating system.” This is also the name of its commercial product, Mesosphere‘s Data Center Operating System (DC/OS). Apache Mesos is much less opinionated than K8s, allowing for the deployment of various types of applications besides containerized applications.

Use Cases

We have selected some common use cases to demonstrate Kubernetes’ capabilities. The use cases can be utilized together for different setups.

Self-Healing and Scaling Services

For simplicity, K8s process units can be detailed as pods and services. A pod is the smaller deployment unit available on Kubernetes. A pod can contain several containers that will have some related communication—such as network and storage. Services are the interface that provides accessibility to a set of containers. These services can be for internal or public access and can load balance several container instances.

Pods are mortal: once finished, they vanish from the cluster. Pod termination can be natural or through an error. A deployment is the most modern Kubernetes module to create and maintain pods. Using a single description file, a developer can specify everything necessary to deploy, keep running, scale, and upgrade the pod.

The figure below shows a simple deployment. This creates a pod of Nginx (version 1.7.9) with three replicas. In other words, Kubernetes will manage three Nginx instances; when an instance stops working, Kubernetes will create a new one.

A Kubernetes Deployment of Nginx

This Deployment can be configured to be auto-scalable with the following command line:

One of the advantages of K8s is that it’s easy to understand what the platform is doing. In this case, the cluster will have 10 Nginx instances, and as many as 15 instances if the CPU utilization exceeds 80 percent of capacity.

Serverless, with Server

Serverless architecture has taken the world by a storm since AWS launched Lambda. The principle is simple: just develop the code, and don’t worry about anything else. Server and scalability are handled by the cloud provider and code just has to be developed as functions that handle specific events: from HTTP requests to queue messages.

Vendor lock-in is the major disadvantage of this solution. It almost impossible to change cloud providers without refactoring most of the code. There are some solutions like Serverless that seek to standardize function code across clouds. Another solution is to use a Kubernetes cluster to create a vendor-free serverless platform. As mentioned above, K8S abstracts away the difference between cloud servers. Currently, two popular frameworks virtualize the cluster as a serverless platform: Kubeless and Fission.

Optimized Resource Usage with Namespaces

A K8s namespace is also known as a virtual cluster. Namespaces create a virtually separated cluster inside the real cluster. Clusters without namespaces probably have test, staging and production clusters. Virtual clusters usually waste some resources because they do not undergo continuous testing, and because staging is used from time to time to validate the work of a new feature. By using a virtual cluster, or a namespace, an operations team can use the same set of physical machines for different sets depending on a given workload.

Namespaces are closely related to DNS because services located within the same namespace are accessible through their names. Namespaces offer a good solution for creating similar environments that locate services through network names: instances from different namespaces will find their dependencies without having to take into account which namespace they are located in.

In addition, namespaces can have resource quotas: each virtual cluster can receive a defined allocation in order to avoid a resource competition between namespaces. This is particularly useful to avoid a production environment sharing computing resources with just a few priority environments. Finally, different permissions can be created with roles for each namespace in order to limit the number of individuals with access to production environments.

Hybrid and Multiclouds

A hybrid cloud utilizes computing resources from a local, conventional data center, and from a cloud provider. A hybrid cloud is normally used when a company has some servers in an on-premise data center and wants to use the cloud’s unlimited computing resources to expand or substitute company resources. A multicloud, on the other hand, refers to a cloud that uses multiple cloud providers to handle computing resources. Multiclouds are generally used to avoid vendor lock-in, and to reduce the risk from a cloud provider going down while performing mission-critical operations.

Both solutions are addressed by Kubernetes Federation. Multiple clusters — one for each cloud or on-premise data center — are created that are managed by the Federation. The Federation synchronizes computing resources, and even allows cross-cluster discovery: virtually any pod can communicate with a pod in another cluster without knowing the infrastructure.

The Federation setup is not simple, and there is a caveat: for obvious reasons, the solution doesn’t work on managed services like Google Kubernetes Engine, Azure Container Service or AWS EKS.