What Is Kubernetes? Kubernetes Architecture Overview

Kubernetes: How Does It Work?

Kubernetes relies on its cluster as its central component. In a cluster, many virtual or physical machines work as either masters or nodes, each with a specific role.

Containers (containing your applications) are housed in each node, and the master communicates with nodes regarding when containers must be created and destroyed. Additionally, it instructs nodes how to re-adjust traffic routing based on new Kubernetes container alignments.

Kubernetes architecture diagram is showing a general view of the cluster:

The Kubernetes master

As the cluster’s touchpoint (and control plane), the Kubernetes master manages scheduling and deployment of containers for administrators and other users and their interaction with the cluster. There will always be one master in a cluster, but there may be others depending on the replication patterns of the cluster.

In etcd, a persistent and distributed key-value data store, the master stores all cluster-wide state and configuration information. ECTD is accessible to each node and, through it, nodes can discover how to understand the configurations of the containers running on their instance. It is possible to run etcd on the Kubernetes master or in a standalone configuration.

For masters to communicate with the cluster at large, kube-apiserver is their main point of access to the control plane. Using kube-apiserver, for example, the cluster’s configurations in etcd are matched to the settings of containers deployed.

Kube-controller-manager is responsible for controlling the cluster’s state via the API server of Kubernetes. This service manages deployments, replicas, and nodes. The node controller, for example, handles node registration, as well as monitoring a node’s health during its lifetime.

Kube-scheduler tracks and manages the workloads on nodes in the cluster. Based on the nodes’ availability and capacity, this service assigns work to nodes accordingly.

The cloud-controller-manager belongs to the Kubernetes platform and helps keep it cloud-agnostic. As an abstraction layer, the cloud-controller-manager provides a path between the cloud provider’s APIs and tools (for example, storage volumes and load balancers) and Kubernetes’ representation of those tools.

Nodes

Container runtimes must be configured on every node of the Kubernetes cluster, which is usually Docker. The container runtime starts and manages the containers as Kubernetes deploys them to nodes in the cluster. Your applications (web servers, databases, API servers, etc.) run inside the containers.

A kubelet, an agent process on each Kubernetes node, manages the node’s state by starting, stopping, and maintaining application containers as determined by the control plane. A kubelet collects information about the health and performance of the nodes, pods, and containers it runs. This information is shared with the control plane in order to help its schedule.

On the nodes of the cluster, kube proxy acts as a network proxy. In addition, it is a load balancer for the services running on the nodes.

Pods are the basic scheduling unit, each of which consists of one or more containers that can share resources and are guaranteed to be co-located on the host machine. Within the cluster, each pod is assigned a unique IP address, so that ports can be used freely.

The desired state of each container in a pod is described in a YAML or JSON object called a Pod Spec. The API server passes these objects to the kubelet.

Volumes, such as disks or network drives, can be defined and exposed by a pod to the containers inside, allowing different containers to share storage space. As an example, volumes may be used when one container downloads something and another container uploads it to a different location. In light of the fact that containers in pods can be ephemeral, Kubernetes provides a type of load balancer, called a service, that helps send requests to groups of pods. Service targets logical groups of pods generated by labels (explained below). You can enable public access to services if you wish them to be accessed outside of the cluster. By default, services can only be accessed within the cluster.

Deployments and replicas

This is a collection of YAML objects defining the pods and the number of containers, known as replicas, included in each pod. A ReplicaSet in the deployment object defines how many replicas should run in the cluster. The replica set, for example, ensures that another pod is scheduled on another available node if a node running a pod dies.

A DaemonSet runs a specific daemon (in a pod) across the specified nodes. The most common use of DaemonSets is to provide pods with services or maintenance. In IT Outposts Infrastructure, a DaemonSet is used to deploy the Infrastructure agent across all cluster nodes.

Namespaces

On top of a physical cluster, namespaces allow you to create virtual clusters. In environments that have many users distributed across multiple projects or teams, namespaces are intended for use. Resource quotas are assigned and cluster resources are logically isolated.

Labels

A Label is a key/value pair assigned to a Kubernetes object or pod. Objects can be organized and selected using labels in Kubernetes. You can quickly find the information you are interested in by drilling down with labels when monitoring Kubernetes objects.

Stateful sets and persistent storage volumes

When using StatefulSets, you are able to assign unique IDs to pods so that they can be moved to another node, networked, or data can persist between them. In the same way, persistent storage volumes provide a cluster with storage resources to which pods can request access as they deploy.

Other Useful Components

Kubernetes components listed below provide useful functionality but aren’t required to run Kubernetes.

Kubernetes DNS

This is a method for locating services between pods in Kubernetes using DNS. Your infrastructure may include other DNS servers in addition to this one.

Cluster-level logs

It is possible to integrate Kubernetes with a logging tool in order to use it to gather and store logs from applications and systems within a cluster, using standard output and standard error.

Cluster logs can be stored on your own log storage solution if you choose to use Kubernetes. Kubernetes does not feature native log storing.

Helm: managing Kubernetes applications

Helm is a registry for application packages for Kubernetes, maintained by the CNCF. You can download and deploy Helm charts in your Kubernetes environment as pre-configured software resources. A CNCF survey conducted in 2020 found that 63% of respondents preferred Helm for managing Kubernetes packages. DevOps teams can focus on managing Kubernetes applications more efficiently when using Helm charts. Charts can be shared, versioned, and deployed in their development and production environments using it.

Kubernetes and Istio: a popular pairing

When you have a microservice architecture, like those in Kubernetes, your service instances communicate with each other via a service mesh, which is an infrastructure layer. The service mesh also provides the ability to configure critical actions such as service discovery, load balancing, data encryption, and authentication and authorization among service instances. It is predicted that service meshes like Istio will become increasingly inseparable in the near future, given that tech giants like IBM and Google have already delivered on that promise.

With Istio, the IBM Cloud team can control, monitor, and secure its Kubernetes deployment over a massive scale. Istio helps IBM in the following ways:

• The flow of traffic can be controlled by connecting services
• Flexible authorization and authentication policies for secure microservice interactions
• The control point for managing production services for IBM
• By connecting Istio data to IT Outposts via an adapter, users can observe their services, both microservices from Kubernetes and application data from the company’s existing collection.