Introducing Kubernetes

Kubernetes Analogy

• K8s greek word for helmsman or pilot
• helmsman steers the ship and captain is responsible for the ship
• A helmsman maintains the course of the ship, carries out the orders given by the captain and reports back the ship’s heading. Kubernetes steers your applications and reports on their status while you - the captain - decide where you want the system to go

Kubernetes in Nutshell

• Kubernetes is a software system for automating the deployment and management of complex, large-scale application systems composed of computer processes running in containers.
• Abstracting Infrastructure: When software developers or operators decide to deploy an application, they do this through Kubernetes instead of deploying the application to individual computers. Kubernetes provides an abstraction layer over the underlying hardware to both users and applications.
• 
• Standardizing how we deploy applications : the details of the underlying infrastructure no longer affect the deployment of applications. A single manifest that describes the application can be used for local deployment and for deploying on any cloud provider
• Deploying applications declaratively : You describe the components that make up your application and Kubernetes turns this description into a running application. It then keeps the application healthy by restarting or recreating parts of it as needed.
• 
• 
• Taking on the daily management of applications: As soon as you deploy an application to Kubernetes, it takes over the daily management of the application. If the application fails, Kubernetes will automatically restart it. If the hardware fails or the infrastructure topology changes so that the application needs to be moved to other machines, Kubernetes does this all by itself

Kubernetes as a Whole

Kubernetes was originally developed by Google and released in 2014. The predecessors of Kubernetes were Borg and Omega which were google’s internal system to manage applications.

[!Data on Google’s energy use suggests that they run around 900,000 servers.]

Every new data center is state-of-the-art. Its infrastructure differs from those built in the past. Despite the differences, the deployment of applications in one data center should not differ from deployment in another data center. This is especially important when you deploy your application across multiple zones or regions to reduce the likelihood that a regional failure will cause application downtime. To do this effectively, it’s worth having a consistent method for deploying your applications which is Kubernetes.

As soon as Google open-sourced kubernetes, RedHat as company that is in forefront of open-source software helped developed and maintain the K8s project. Several companies are now offering enterprise-quality Kubernetes products that are built from the open-source project. These include Red Hat OpenShift, Pivotal Container Service, Rancher and many others.

• Kubernetes has also spawned many other related open-source projects, most of which are now under the umbrella of the Cloud Native Computing Foundation (CNCF), which is part of the Linux Foundation.

Why tf Kubernetes is so Popular

• Automating the management of microservices :
  • In the past - most application were Monoliths services(components being tightly coupled and ran as single process) - Horizontal Scaling a bigger problem
  • Microservices paradigm - The monoliths were divided into dozens, sometimes hundreds, of separate processes. allowed organizations to divide their development departments into smaller teams where each team developed only a part of the entire system
  • MicroServices and Monolithic Services
  • Each microservice is now a separate application with its own development and release cycle. The dependencies of different microservices will inevitably diverge over time. One microservice requires one version of a library, while another microservice requires another, possibly incompatible, version of the same library. Running the two applications in the same operating system becomes difficult.
  • Fortunately, containers alone solve this problem where each microservice requires a different environment, but each microservice is now a separate application that must be managed individually.
  • Individual parts of the entire application no longer need to run on the same computer, which makes it easier to scale the entire system, but also means that the applications need to be configured to communicate with each other.
  • Kubernetes provides this automation of managing microservices
• Bridging the dev and ops divide:
  • Dev team builds the software in isolation and sends the product to operations team for deployment and management.
  • Dev-ops paradigm - the two teams now work much more closely together throughout the entire life of the software product through K8s.
• Standardizing the cloud:
  • Many organizations have moved their software from local servers to the cloud. The benefits of this seem to have outweighed the fear of being locked-in to a particular cloud provider, which is caused by relying on the provider’s proprietary APIs to deploy and manage applications.
  • The popularity of Kubernetes has forced all major cloud providers to integrate Kubernetes into their offerings. Customers can now deploy applications to any cloud provider through a standard set of APIs provided by Kubernetes.
  • 
  • If the application is built on the APIs of Kubernetes instead of directly on the proprietary APIs of a specific cloud provider, it can be transferred relatively easily to any other provider

Understanding K8s

Kubernetes is like an operating system for computer clusters

Just as an operating system supports the basic functions of a computer, such as scheduling processes onto its CPUs and acting as an interface between the application and the computer’s hardware, Kubernetes schedules the components of a distributed application onto individual computers in the underlying computer cluster and acts as an interface between the application and the cluster.

It frees application developers from the need to implement infrastructure- related mechanisms in their applications; instead, they rely on Kubernetes to provide them. This includes things like:

• service discovery - a mechanism that allows applications to find other applications and use the services they provide,
  horizontal scaling - replicating your application to adjust to fluctuations in load,

• load-balancing - distributing load across all the application replicas, self-healing - keeping the system healthy by automatically restarting failed applications and moving them to healthy nodes after their nodes fail,

• leader election - a mechanism that decides which instance of the application should be active while the others remain idle but ready to take over if the active instance fails.

Computers in a Kubernetes cluster are divided into the Control Plane and the Workload Plane

The master nodes will run the Kubernetes Control Plane, which represents the brain of your system and controls the cluster, while the rest will run your applications - your workloads - and will therefore represent the Workload Plane.

Non-production clusters can use a single master node, but highly available clusters use at least three physical master nodes to host the Control Plane. The number of worker nodes depends on the number of applications you’ll deploy.

How all cluster nodes become one large deployment area

After Kubernetes is installed on the computers, you no longer need to think about individual computers when deploying applications. Regardless of the number of worker nodes in your cluster, they all become a single space where you deploy your applications. You do this using the Kubernetes API, which is provided by the Kubernetes Control Plane.

Benefits of using K8s

• Self-service deployment of applications: Kubernetes presents all its worker nodes as a single deployment surface, it no longer matters which node you deploy your application to
• Reducing costs via better infrastructure utilization: K8s ability to move applications allows the applications to be packed tightly together so that the resources of the nodes can be utilized in the best possible way. Related: Running finite workloads with Jobs and CronJobs
• Automatically adjusting to changing load: K8s monitor the resources consumed by each application and other metrics and adjust the number of running instances of each application to cope with increased load or resource usage. When you run Kubernetes on cloud infrastructure, it can even increase the size of your cluster by provisioning additional nodes through the cloud provider’s API
• Keeping applications running smoothly: If your application crashes, Kubernetes will restart it automatically. So even if you have a broken application that runs out of memory after running for more than a few hours, Kubernetes will ensure that your application continues to provide the service to its users by automatically restarting it in this case.
  • Kubernetes is a self-healing system in that it deals with software errors like the one just described, but it also handles hardware failures
  • As clusters grow in size, the frequency of node failure also increases. For example, in a cluster with one hundred nodes and a MTBF (mean-time-between-failure) of 100 days for each node, you can expect one node to fail every day. When a node fails, Kubernetes automatically moves applications to the remaining healthy nodes
• Simplifying application development

The architecture of a Kubernetes cluster

a Kubernetes cluster consists of nodes divided into two groups:

• A set of master nodes that host the Control Plane components, which are the brains of the system, since they control the entire cluster.
• A set of worker nodes that form the Workload Plane, which is where your workloads (or applications) run.

Related Sections:

Control Plane components

The Control Plane is what controls the cluster. It consists of several components that run on a single master node or are replicated across multiple master nodes to ensure high availability.

These are the components and their functions:

• The Kubernetes API Server exposes the RESTful Kubernetes API. Engineers using the cluster and other Kubernetes components create objects via this API.
• The etcd distributed datastore persists the objects you create through the API, since the API Server itself is stateless. The Server is the only component that talks to etcd.
• The Scheduler decides on which worker node each application instance should run.
• Controllers bring to life the objects you create through the API. Most of them simply create other objects, but some also communicate with external systems (for example, the cloud provider via its API).

The components of the Control Plane hold and control the state of the cluster, but they don’t run your applications. This is done by the (worker) nodes.

Worker Nodes Components

The worker nodes are the computers on which your applications run. They form the cluster’s Workload Plane. In addition to applications, several Kubernetes components also run on these nodes. They perform the task of running, monitoring and providing connectivity between your applications.

Each node runs the following set of components:

• The Kubelet, an agent that talks to the API server and manages the applications running on its node. It reports the status of these applications and the node via the API.
• The Container Runtime, which can be Docker or any other runtime compatible with Kubernetes. It runs your applications in containers as instructed by the Kubelet.
• The Kubernetes Service Proxy (Kube Proxy) load-balances network traffic between applications. Its name suggests that traffic flows through it, but that’s no longer the case - Related CH 14 Managing Pods with deployments

Add-on components

Most Kubernetes clusters also contain several other components. This includes a DNS server, network plugins, logging agents and many others. They typically run on the worker nodes but can also be configured to run on the master.

Gain a much deeper inside on K8s architecture on Managing Pods with deployments

How Kubernetes runs an application

Defining your Application Everything in Kubernetes is represented by an object. You create and retrieve these objects via the Kubernetes API. Your application consists of several types of these objects - one type represents the application deployment as a whole, another represents a running instance of your application, another represents the service provided by a set of these instances and allows reaching them at a single IP address, and there are many others.

These objects are usually defined in one or more manifest files in either YAML or JSON format.

These actions take place when you deploy the application:

1. You submit the application manifest to the Kubernetes API.The API Server writes the objects defined in the manifest to etcd.
2. A controller notices the newly created objects and creates several new objects - one for each application instance.
3. The Scheduler assigns a node to each instance.
4. The Kubelet notices that an instance is assigned to the Kubelet’s node. It runs the application instance via the Container Runtime.
5. The KubeProxy notices that the application instances are ready to accept connections from clients and configures a load balancer for them.
6. The Kubelets and the Controllers monitor the system and keep the applications running.

More detailed procedure: Managing Pods with deployments

Submitting the application to the API

After you’ve created your YAML or JSON file(s), you submit the file to the API, usually via the Kubernetes command-line tool called kubectl.

Kubectl splits the file into individual objects and creates each of them by sending an HTTP PUT or POST request to the API, as is usually the case with RESTful APIs. The API Server validates the objects and stores them in the etcd datastore. In addition, it notifies all interested components that these objects have been created.

About the controllers Most object types have an associated controller. A controller is interested in a particular object type. It waits for the API server to notify it that a new object has been created, and then performs operations to bring that object to life. Typically, the controller just creates other objects via the same Kubernetes API. For example, the controller responsible for application deployments creates one or more objects that represent individual instances of the application. The number of objects created by the controller depends on the number of replicas specified in the application deployment object.

About the Scheduler The scheduler is a special type of controller, whose only task is to schedule application instances onto worker nodes. It selects the best worker node for each new application instance object and assigns it to the instance - by modifying the object via the API.

About the Kubelet and the Container Runtime The Kubelet that runs on each worker node is also a type of controller. Its task is to wait for application instances to be assigned to the node on which it is located and run the application. This is done by instructing the Container Runtime to start the application’s container.

About the Kube Proxy Because an application deployment can consist of multiple application instances, a load balancer is required to expose them at a single IP address. The Kube Proxy, another controller running alongside the Kubelet, is responsible for setting up the load balancer.

Keeping the applications healthy Once the application is up and running, the Kubelet keeps the application healthy by restarting it when it terminates. It also reports the status of the application by updating the object that represents the application instance. The other controllers monitor these objects and ensure that applications are moved to healthy nodes if their nodes fail.

Introducing Kubernetes into your organization

Running Kubernetes on-premises and in the cloud

If you want to run your applications on Kubernetes, you have to decide whether you want to run them locally, in your organization’s own infrastructure (on-premises) or with one of the major cloud providers, or perhaps both - in a hybrid cloud solution

Running Kubernetes on-premises Kubernetes can run directly on your bare-metal machines or in virtual machines running in your data center. In either case, you won’t be able to scale your cluster as easily as when you run it in virtual machines provided by a cloud provider.

Deploying Kubernetes in the cloud Kubernetes itself can ask the cloud provider to provision additional virtual machines when the current size of the cluster is no longer sufficient to run all the applications you want to deploy. When the number of workloads decreases and some worker nodes are left without running workloads, Kubernetes can ask the cloud provider to destroy the virtual machines of these nodes to reduce your operational costs. This elasticity of the cluster is certainly one of the main benefits of running Kubernetes in the cloud.

Using a hybrid cloud solution A more complex option is to run Kubernetes on-premises, but also allow it to spill over into the cloud. It’s possible to configure Kubernetes to provision additional nodes in the cloud if you exceed the capacity of your own data center. This way, you get the best of both worlds

To manage or not to manage Kubernetes yourself

whether you’ll manage Kubernetes yourself or use a Kubernetes-as-a-Service type offering where someone else manages it for you.

Managing Kubernetes yourself If you already run applications on-premises and have enough hardware to run a production-ready Kubernetes cluster, your first instinct is probably to deploy and manage it yourself. The management of production-ready Kubernetes clusters is a multi-billion- dollar industry. Before you decide to manage one yourself, it’s essential that you consult with engineers who have already done it to learn about the issues most teams run into.

Using a managed Kubernetes cluster in the cloud Using Kubernetes is ten times easier than managing it. Most major cloud providers now offer Kubernetes-as-a-Service. They take care of managing Kubernetes and its components while you simply use the Kubernetes API like any of the other APIs the cloud provider offers.

The top managed Kubernetes offerings include the following:

Google Kubernetes Engine (GKE)
Azure Kubernetes Service (AKS)
Amazon Elastic Kubernetes Service (EKS)
IBM Cloud Kubernetes Service
Red Hat OpenShift Online and Dedicated
VMware Cloud PKS
Alibaba Cloud Container Service for Kubernetes (ACK)

Using vanilla or extended Kubernetes

whether to use a vanilla open-source version of Kubernetes or an extended, enterprise-quality Kubernetes product.

Using a vanilla version of Kubernetes The open-source version of Kubernetes is maintained by the community and represents the cutting edge of Kubernetes development. This also means that it may not be as stable as the other options. It may also lack good security defaults. Deploying the vanilla version requires a lot of fine tuning to set everything up for production use.

Using enterprise-grade Kubernetes distributions A better option for using Kubernetes in production is to use an enterprise- quality Kubernetes distribution such as OpenShift or Rancher. In addition to the increased security and performance provided by better defaults, they offer additional object types in addition to those provided in the upstream Kubernetes API. For example, vanilla Kubernetes does not contain object types that represent cluster users, whereas commercial distributions do. They also provide additional software tools for deploying and managing well- known third-party applications on Kubernetes

Should you even use Kubernetes?

Do your workloads require automated management? If your application is a large monolith, you definitely don’t need Kubernetes. Even if you deploy microservices, using Kubernetes may not be the best option, especially if the number of your microservices is very small.

Summary

• Kubernetes is Greek for helmsman. As a ship’s captain oversees the ship while the helmsman steers it, you oversee your computer cluster, while Kubernetes performs the day-to-day management tasks.
• Kubernetes is pronounced koo-ber-netties. Kubectl, the Kubernetes command-line tool, is pronounced kube-control.
• Kubernetes is an open-source project built upon Google’s vast experience in running applications on a global scale. Thousands of individuals now contribute to it.
• Kubernetes uses a declarative model to describe application deployments. After you provide a description of your application to Kubernetes, it brings it to life.
• Kubernetes is like an operating system for the cluster. It abstracts the infrastructure and presents all computers in a data center as one large, contiguous deployment area.
• Microservice-based applications are more difficult to manage than monolithic applications. The more microservices you have, the more you need to automate their management with a system like Kubernetes. Kubernetes helps both development and operations teams to do what they do best. It frees them from mundane tasks and introduces a standard way of deploying applications both on-premises and in any cloud.
• Using Kubernetes allows developers to deploy applications without the help of system administrators. It reduces operational costs through better utilization of existing hardware, automatically adjusts your system to load fluctuations, and heals itself and the applications running on it.
• A Kubernetes cluster consists of master and worker nodes. The master nodes run the Control Plane, which controls the entire cluster, while the worker nodes run the deployed applications or workloads, and therefore represent the Workload Plane.
• Using Kubernetes is simple, but managing it is hard. An inexperienced team should use a Kubernetes-as-a-Service offering instead of deploying Kubernetes by itself.