What is Kubernetes?

Kubernetes is a platform that encompasses a huge number of services and capabilities that keeps growing. The core functionality is scheduling workloads in containers across your infrastructure, but it doesn't stop there. Here are some of the other capabilities Kubernetes brings to the table:

• Mounting storage systems
• Distributing secrets
• Checking application health and readiness
• Replicating application instances
• Using the Horizontal Pod Autoscaler
• Using Cluster Autoscaling
• Naming and service discovery
• Balancing loads
• Rolling updates
• Monitoring resources
• Accessing and ingesting logs
• Debugging applications
• Providing authentication and authorization

We will cover all these capabilities in great detail throughout the book. At this point, just absorb and appreciate how much value Kubernetes can add to your system.

Kubernetes has impressive scope, but it is also important to understand what Kubernetes explicitly doesn't provide.

What Kubernetes is not

Kubernetes is not a Platform as a Service (PaaS). It doesn't dictate many important aspects that are left to you or to other systems built on top of Kubernetes, such as Deis, OpenShift, and Eldarion; for example:

• Kubernetes doesn't require a specific application type or framework
• Kubernetes doesn't require a specific programming language
• Kubernetes doesn't provide databases or message queues
• Kubernetes doesn't distinguish apps from services
• Kubernetes doesn't have a click-to-deploy service marketplace
• Kubernetes doesn't provide a built-in function as a service solution
• Kubernetes doesn't mandate a logging, monitoring, and alerting system

Now that we have a clear idea about the boundaries of Kubernetes, let's pe into its primary responsibility – container orchestration.

Understanding container orchestration

The primary responsibility of Kubernetes is container orchestration. That means making sure that all the containers that execute various workloads are scheduled to run on physical or virtual machines. The containers must be packed efficiently following the constraints of the deployment environment and the cluster configuration. In addition, Kubernetes must keep an eye on all running containers and replace dead, unresponsive, or otherwise unhealthy containers. Kubernetes provides many more capabilities, which you will learn about in the following chapters. In this section, the focus is on containers and their orchestration.

Physical machines, virtual machines, and containers

It all starts and ends with hardware. In order to run your workloads, you need some real hardware provisioned. That includes actual physical machines with certain compute capabilities (CPUs or cores), memory, and some local persistent storage (spinning disks or SSDs). In addition, you will need some shared persistent storage and to hook up all these machines using networking, so they can find and talk to each other. At this point, you run multiple virtual machines on the physical machines or stay at the bare-metal level (real hardware only – no virtual machines). Kubernetes can be deployed on a bare-metal cluster or on a cluster of virtual machines. Kubernetes, in turn, can orchestrate the containers it manages directly on bare metal or on virtual machines. In theory, a Kubernetes cluster can be composed of a mix of bare-metal and virtual machines, but this is not very common.

The benefits of containers

Containers represent a true paradigm shift in the development and operation of large, complicated software systems. Here are some of the benefits compared to more traditional models:

• Agile application creation and deployment
• Continuous development, integration, and deployment
• Dev and Ops separation of concerns
• Environmental consistency across development, testing, staging, and production
• Cloud and OS distribution portability
• Application-centric management (dependencies are packaged with the application)
• Resource isolation (container CPU and memory can be limited)
• Resource utilization (multiple containers can be deployed on the same node)

The benefits of container-based development and deployment are significant in many contexts, but are particularly significant if you deploy your system to the cloud.

Containers in the cloud

Containers are ideal to package microservices because while providing isolation to the microservice, they are very lightweight and you don't incur a lot of overhead when deploying many microservices as you do with virtual machines. That makes containers ideal for cloud deployment, where allocating a whole virtual machine for each microservice would be cost-prohibitive.

All major cloud providers, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft's Azure, provide container hosting services these days. Many other companies have jumped on the Kubernetes wagon and offer managed Kubernetes services, including:

• IBM IKS
• Alibaba Cloud
• DigitalOcean DKS
• Oracle OKS
• OVH Managed Kubernetes
• Rackspace KaaS

The Google Kubernetes Engine (GKE) was always based on Kubernetes. Amazon's Elastic Kubernetes Service (EKS) was added in addition to the proprietary AWS ECS orchestration solution. Microsoft Azure's container service used to be based on Apache Mesos but later switched to Kubernetes with Azure Kubernetes Service (AKS). You could always deploy Kubernetes on all the cloud platforms, but it wasn't deeply integrated with other services. However, at the end of 2017, all cloud providers announced direct support for Kubernetes. Microsoft's launched AKS, AWS released EKS, and Alibaba Cloud started working on a Kubernetes controller manager to integrate Kubernetes seamlessly.

Cattle versus pets

In the olden days, when systems were small, each server had a name. Developers and users knew exactly what software was running on each machine. I remember that, in many of the companies I worked for, we had multi-day discussions to decide on a naming theme for our servers. For example, composers and Greek mythology characters were popular choices. Everything was very cozy. You treated your servers like beloved pets. When a server died it was a major crisis. Everybody scrambled to try to figure out where to get another server, what was even running on the dead server, and how to get it working on the new server. If the server stored some important data, then hopefully you had an up-to-date backup and maybe you'd even be able to recover it.

Obviously, that approach doesn't scale. When you have tens or hundreds of servers, you must start treating them like cattle. You think about the collective and not inpiduals. You may still have some pets like your CI/CD machines (although managed CI/CD solutions are becoming more common), but your web servers and backend services are just cattle.

Kubernetes takes the cattle approach to the extreme and takes full responsibility for allocating containers to specific machines. You don't need to interact with inpidual machines (nodes) most of the time. This works best for stateless workloads. For stateful applications, the situation is a little different, but Kubernetes provides a solution called StatefulSet, which we'll discuss soon.

In this section, we covered the idea of container orchestration and discussed the relationships between hosts (physical or virtual) and containers, as well as the benefits of running containers in the cloud, and finished with a discussion about cattle versus pets. In the following section, we will get to know the world of Kubernetes and learn its concepts and terminology.