What is Kubernetes?

Kubernetes (or K8s) is an open source platform for the deployment and management of containerized applications at scale. It is designed to automate many processes and tasks such as deployment, scaling, update, scheduling, and communication of containerized applications. With Kubernetes, it is simple to group multiple hosts running Linux containers and turn them into a working computer cluster controlled and managed by the intelligent control plane maintaining the desired state of your deployments.

Kubernetes was originally designed and developed by Google for the management of its huge computer clusters and application deployments. Google generated more than 2 billion container deployments per week in 2014, meaning that every second Google was launching an average of 3,300 containers. All these containers were managed by their internal orchestration platform named Borg that became a predecessor of Kubernetes. Google open-sourced Kubernetes in 2014. This move continued Google’s track record of successful contributions to container ecosystem and cloud-native movement including the development of cGroups that ultimately made Docker possible and BorgMon, which became the inspiration for Prometheus.

To make a long story short, since 2014 a number of companies and developers have contributed to the Kubernetes project, building dozens of integrations with popular cloud providers, storage systems, and networking infrastructures etc. Kubernetes is supported by the growing ecosystem and community and is currently the most popular container orchestration tool around.

Why Do Companies Need Kubernetes?

Container runtimes were designed as an alternative to running immutable virtual machine (VM) images. VM images are much heavier (require more resources) than containers and, thus, need more servers to be deployed. In contrast, modern container technologies simplify running thousands of lightweight containers on a single host, which leads to the radical saving of computing resources. Also, containers allow you to disentangle applications from the underlying infrastructure and isolate them from the host environment using an autonomous filesystem, virtual networks, and dependencies. This isolation makes containers much more portable and easier to deploy than VMs.

In itself, however, container technologies like Docker do not fully address the challenge of running containerized applications in production. Docker did offer Swarm (and still does) for orchestration, but Swarm, ultimately, didn’t offer as much as K8s. Think about this for a moment: real production applications include multiple containers deployed across many server hosts. When you manage hundreds or thousands of containers across multiple nodes in production, you’ll need to have an ability to scale them depending on the application’s load, enable communication and external access (e.g., via microservices), storage, running regular health checks, managing updates, and many other tasks. These are all orchestration tasks that do not come out of the box in container runtimes. Developing your own orchestration framework to perform these tasks would be an unnecessary overhead for your business.

Fortunately, though, Google open-sourced Kubernetes, so you can get all these handy features and tools without writing a single line of code! With Kubernetes, you get such features as manual and automatic scaling, multi-level networking and service discovery, native support for co-located and tightly coupled applications, and many more. Let’s discuss some of these features.

Scalability Is Not a Problem

Scalability is among the major concerns of modern production-grade applications exposed to millions of potential users. When it comes to running applications in clusters of hundreds or even thousands of servers, scaling becomes a complex administration task that involves many prerequisites and caveats. Here are some of the questions that might arise along the way:

  • Is the desired number of application instances running?
  • How many of those instances are healthy and ready to serve the traffic?
  • What is the current application load? How many replicas are needed to service that load?
  • How many nodes are currently available for scheduling? How many resources are available in the cluster?

These are just a few questions which could make a cluster administrator without appropriate tools go crazy. The obvious solution is automation, and this is where Kubernetes truly shines.

For example, the platform’s controllers like deployments can monitor how many applications are running in your cluster, and if, for some reason, this number is different from the desired state, Kubernetes will scale the deployment up or down to reach it. Under the hood, Kubernetes will also keep a record of available nodes and resources to intelligently schedule your applications during the scaling process. At the same time, you can always do a manual scaling using Kubernetes command line tools (kubectl).

How about auto-scaling? This feature is critical for managing the ever-changing application load. It’s also important because it comes down to managing your infrastructure costs: normally, you don’t need more applications instances running than the current demand for your services. Kubernetes ships with a Horizontal Pod Autoscaler that scales the number of pods in a replication controller, deployment, or replica set based on observed CPU utilization.

Our new Supergiant Kubernetes-as-a-Service platform extends this auto-scaling feature even further. Its efficient cost-reduction algorithm based on machine learning and real-time analysis of traffic and resources ensures that you utilize precisely the storage and memory that are needed for your applications to work properly. In this way, Supergiant adds the horizontal auto-scaling feature to Kubernetes’ native vertical scaling functionality while introducing immense cost savings.

Efficient Multi-Layer Networking and Service Discovery

The purpose of Kubernetes networking is to turn containers into bona fide “virtual hosts” that can communicate with each other across nodes, thereby combining the benefits of VMs, containers, and microservices. Kubernetes networking is based on several layers, all serving this final goal:

  • Container-to-container communication on localhost and using a pod’s network namespace. This networking layer enables the container network interfaces for tightly coupled containers that can communicate with each other on specified ports much like the conventional applications.
  • Pod-to-pod communication that enables communication of pods across nodes. Kubernetes can turn the cluster into a virtual network where all pods can communicate with each other no matter what nodes they land on.
  • Services. A Service abstraction defines a policy (microservice) for accessing pods by other applications. Services act as load-balancers that distribute requests across backend pods managed by the service.

Kubernetes is very flexible about networking solutions that you can use. However, the platform imposes the following principles for the cluster-level network interfaces:

  • All containers can communicate with each other without NAT.
  • All nodes can communicate with all containers (and vice versa) without NAT.
  • The IP seen by one container is the same IP seen by other containers.

There are a number of powerful networking implementations of this model including Cilium, Contriv, Flannel, and others.

Enabling Co-Located and Tightly Coupled Applications

Kubernetes packages containers in abstractions called pods that provide Kubernetes infrastructure resources and services to containers. Pods work as wrappers for the containers that provide interfaces for sharing resources and communication between them.

In particular, containers can communicate via localhost on the pod network and share resources via volumes assigned to pods. This allows implementing various tightly coupled application designs where one container serves as the main application and another container (sidecar) helps it process data or consume logs. Containers in a pod also can have shared fate and behavior, which dramatically simplifies the deployment of co-located applications.

Fast, Zero Downtime Updates

Users expect your applications to be up all the time. However, if your app runs thousands of containers in production, doing manual updates can introduce a lot of risks and cause downtimes. The last thing you want is to make your application unavailable when it’s being updated.

Fortunately, Kubernetes ships with a native support for rolling updates which allow updates to pass with zero downtime. Kubernetes controllers will incrementally update running pods according to parameters you specified, ensuring that the old versions of your application are running before the new replicas are launched. Also, with Kubernetes API, you can have fine-grained control over the maximum number of pods unavailable and the maximum surge of new pods above the desired number specified in your deployment. As an added benefit, Kubernetes will store all updates you make in the revision history, so you can always roll back the deployment to any point in time if your update went wrong for some reason (e.g., image pull error).

Efficient Management of Hardware Resources in your Cluster

When you run thousands of applications in production and have multiple teams working on dozens of projects at the same time, cluster resource management becomes essential for the efficient distribution of your limited cloud budget.

Kubernetes was built with this practical concern in mind. It is based on the efficient resource management model implemented from the lowest level of containers and pods to the highest level of your cluster.

At the container level, Kubernetes allows assigning resource requests and limits that control how many resources are requested by the containers and set the upper boundary of resource usage. By setting different request/limit ratios, you can create diverse classes of pods.– best-effort, guaranteed, and burstable –depending on your application’s needs.

Also, Kubernetes allows efficiently managing resources at the namespace level. For example, you can define default resource requests and limits automatically applied to containers, resource constraints (minimum and maximum resource requests and limits), and resource quota for all containers running in a given namespace. These features enable efficient resource utilization by applications in your cluster, and they help divide resources productively between different teams. For example, with the namespace resource constraints you can control the share of cluster resources assigned to production and development workloads, ensuring efficient distribution of budget across different workload types. With all these features, you can ensure that your cluster always has available resources for running your applications and dramatically decrease cloud infrastructure costs.

Native Support for Stateful Applications

Kubernetes comes with a native support for stateful applications like databases and key-value stores. In particular, its persistent volumes subsystem provides an API that abstracts details of the underlying storage infrastructure (e.g., AWS EBS, Azure Disk, etc.), allowing users and administrators to focus on storage capacity and storage types that their applications will consume, rather than the subtle details of each storage provider’s API.

Persistent volumes allow reserving the needed amount of resources using persistent volume claims. The claim is automatically bound to volumes that match storage type, capacity, and other requirements specified in the claim. Claims are automatically unbound, too, if a matching volume does not exist. This feature allows efficiently reserving storage by applications running in your Kubernetes cluster.

Another great feature for stateful applications is dynamic storage provisioning. In Kubernetes, administrators can describe various storage types available in the cluster and their specific reclaim, mounting, and backup policies. After such storage classes are defined, Kubernetes can automatically provision the requested amount of resources from the underlying storage provider like AWS EBS or Azure disk.

Also, one of the best statefulness features in Kubernetes is stateful sets, which are relevant for applications that require stable and unique network identifiers, stable and persistent storage, ordered deployment and scaling, and ordered and automated rolling updates. Using described APIs you can deploy production-grade stateful apps of any complexity in Kubernetes.

Seamless Integration with Cloud and Container Ecosystem

Kubernetes works well with all major container runtimes, cloud environments, and cloud native applications. In particular, Kubernetes has:

  • Support for popular container runtimes. Kubernetes 1.5 release came out with the Container Runtime Interface (CRI), a plugin interface that allows using a wide variety of container runtimes without the need to recompile. Since that release, Kubernetes has simplified the usage of various container runtimes compatible with the CRI.
  • Support for multiple volume types. Kubernetes allows creating custom volume plugins that help abstract any external volume infrastructure and use it inside the Kubernetes cluster. Kubernetes currently supports over 25 volume plugins, which include volumes of cloud service providers (AWS EBS, GCE Persistent Disk), object storage systems (CephFS), network filesystems (NFS, Gluster), data center filesystems (Quobyte), and more.
  • Easy integration with cloud providers and use of their native services. Kubernetes makes it easy to deploy clusters on popular cloud platforms and to use their native infrastructure and networking tools. For example, Kubernetes supports external load balancers provided by major cloud providers. They give externally-accessible IP addresses that send traffic to the specified ports on your cluster nodes.

Extensibility and Pluggability

Kubernetes emphasizes the philosophy of extensibility and pluggability, which means that the platform preserves user choice and flexibility where those matter. Kubernetes aims to support the widest variety of workloads and application types possible and to be easy to integrate with any environment and tool.

Some pluggin framework supported by Kubernetes include:

  • Container Network Interface (CNI() plugins: these implement the CNI networking model and are designed for interoperability.
  • The out-of-tree volume plugins such as the Container Storage Interface (CSI) and FlexVolume. They enable storage vendors to create custom storage plugins without adding them to the Kubernetes repository.

How Does Supergiant Add to Kubernetes?

Supergiant simplifies deployment and management of applications in Kubernetes for developers and administrators. In addition to easing the configuration and deployment of Helm charts, Supergiant facilitates clusters on multiple cloud providers, striving for truly agnostic infrastructure. It achieves this with an autoscaling system designed to increase efficiency and reduce costs. Autoscaling ensures that non-utilized infrastructure is not paid for by downscaling unused nodes and resource packing. In addition to that, Supergiant implements various abstract layers for load balancing, application deployment, basic monitoring, node deployment, and destruction on a highly usable UI.

What’s Next?

Read some articles that introduce to key concepts of Kubernetes :

Find more about Supergiant:

Subscribe to our newsletter