Contents

1 Kubernetes Components 2
1.1 API Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Controller Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 ETCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Worker Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Kubelet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2 Container runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.3 Kube-Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 kubernetes building blocks 6

2.1 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Label Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Persistent Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 ConfigMap and Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Services and Networking 9

3.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 ClusterIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 NodePort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3 LoadBalanacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

i
3.2 Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

ii
Introduction

Kubernetes is an open-source platform for automating deployment, scaling, and management of

containerized applications. It was originally developed by Google and is now maintained by the
Cloud Native Computing Foundation (CNCF).
Since its release in 2014, Kubernetes has become one of the most popular solutions for container
orchestration and has been adopted by many organizations for their production workloads. Ku-
bernetes provides features such as self-healing, auto-scaling, and rolling updates, which make it
a powerful platform for managing large and complex applications.
One of the key advantages of Kubernetes is its extensibility. The platform is designed to be
modular and can be extended with custom resources, controllers, and APIs. This has led to a
large ecosystem of extensions and tools that integrate with Kubernetes, including monitoring and
logging solutions, network plugins, and storage solutions.
Despite its popularity and widespread adoption, Kubernetes can be complex to set up and man-
age, especially for organizations that are new to container orchestration. There have also been
concerns about the security of Kubernetes clusters, as well as the scalability of some of its com-
ponents.
Overall, Kubernetes continues to evolve and mature, and it remains a critical component of many
organizations’ cloud-native strategies. With its strong community, vast ecosystem, and pow-
erful features, Kubernetes is well-positioned to continue to be a leading solution for container
orchestration for years to come.

1
Chapter 1
Kubernetes Components

1.1 API Server

All the administrative tasks are coordinated by the kube-apiserver, a central control plane com-
ponent running on the control plane node. The API Server intercepts RESTful calls from users,
administrators, developers, operators and external agents, then validates and processes them.
During processing the API Server reads the Kubernetes cluster’s current state from the key-value
store, and after a call’s execution, the resulting state of the Kubernetes cluster is saved in the
key-value store for persistence. The API Server is the only control plane component to talk to
the key-value store, both to read from and to save Kubernetes cluster state information - acting
as a middle interface for any other control plane agent inquiring about the cluster’s state.

1.2 Scheduler
The role of the kube-scheduler is to assign new workload objects, such as pods encapsulating
containers, to nodes - typically worker nodes. During the scheduling process, decisions are made
based on current Kubernetes cluster state and new workload object’s requirements. The sched-
uler obtains from the key-value store, via the API Server, resource usage data for each worker
node in the cluster. The scheduler also receives from the API Server the new workload object’s
requirements which are part of its configuration data. Requirements may include constraints that
users and operators set, such as scheduling work on a node labeled with disk==ssd key-value

2
pair. The scheduler also takes into account Quality of Service (QoS) requirements, data locality,
affinity, anti-affinity, taints, toleration, cluster topology.

1.3 Controller Manager

The controller managers are components of the control plane node running controllers or operator
processes to regulate the state of the Kubernetes cluster. Controllers are watch-loop processes
continuously running and comparing the cluster’s desired state (provided by objects’ configuration
data) with its current state (obtained from the key-value store via the API Server). In case of
a mismatch, corrective action is taken in the cluster until its current state matches the desired
state.
The kube-controller-manager runs controllers or operators responsible to act when nodes
become unavailable, to ensure container pod counts are as expected, to create endpoints, service
accounts, and API access tokens.

1.4 ETCD
etcd is an open source project under the Cloud Native Computing Foundation (CNCF). etcd is a
strongly consistent, distributed key-value data store used to persist a Kubernetes cluster’s state.
New data is written to the data store only by appending to it, data is never replaced in the data
store. Obsolete data is compacted (or shredded) periodically to minimize the size of the data
store. Out of all the control plane components, only the API Server is able to communicate with
the etcd data store.

3
Figure 1.1: Stacked etcd topolgy

Figure 1.2: External etcd topolgy

4
1.5 Worker Node

1.5.1 Kubelet

The kubelet is an agent running on each node, control plane and workers, and communicates with
the control plane. It receives Pod definitions, primarily from the API Server, and interacts with
the container runtime on the node to run containers associated with the Pod. It also monitors
the health and resources of Pods running containers.

1.5.2 Container runtime

Although Kubernetes is described as a "container orchestration engine", it lacks the capability to

directly handle and run containers. In order to manage a container’s lifecycle, Kubernetes requires
a container runtime on the node where a Pod and its containers are to be scheduled. Runtimes
are required on all nodes of a Kubernetes cluster, both control plane and worker. Kubernetes
supports several container runtimes.

1.5.3 Kube-Proxy

The kube-proxy is the network agent which runs on each node, control plane and workers, are
responsible for dynamic updates and maintenance of all networking rules on the node. It abstracts
the details of Pods networking and forwards connection requests to the containers in the Pods.

5
Chapter 2
kubernetes building blocks

2.1 Namespaces
If multiple users and teams use the same Kubernetes cluster we can partition the cluster into
virtual sub-clusters using Namespaces. The names of the resources/objects created inside a
Namespace are unique, but not across Namespaces in the cluster.

2.2 Label Selector

Controllers, or operators, and Services, use label selectors to select a subset of objects. Kubernetes
supports two types of Selectors:
• Equality-Based Selectors Equality-Based Selectors allow filtering of objects based on Label keys
and values.
• Set-Based Selectors Set-Based Selectors allow filtering of objects based on a set of values. We
can use in, notin operators for Label values, and exist/does not exist operators for Label keys.

2.3 Deployment
Deployment objects provide declarative updates to Pods and ReplicaSets. The DeploymentCon-
troller is part of the control plane node’s controller manager, and as a controller it also ensures
that the current state always matches the desired state of our running containerized application.
It allows for seamless application updates and rollbacks, known as the default RollingUpdate

6
strategy, through rollouts and rollbacks, and it directly manages its ReplicaSets for application
scaling. It also supports a disruptive, less popular update strategy, known as Recreate.

Figure 2.1: Deploymeny.yml

2.4 Persistent Volumes

In a typical IT environment, storage is managed by the storage/system administrators. The
end user will just receive instructions to use the storage but is not involved with the underlying
storage management. In the containerized world, we would like to follow similar rules, but it
becomes challenging, given the many Volume Types we have seen earlier. Kubernetes resolves
this problem with the PersistentVolume (PV) subsystem, which provides APIs for users and
administrators to manage and consume persistent storage. To manage the Volume, it uses the
PersistentVolume API resource type, and to consume it, it uses the PersistentVolumeClaim API
resource type. A Persistent Volume is a storage abstraction backed by several storage technologies,
which could be local to the host where the Pod is deployed with its application container(s),

7
network attached storage, cloud storage, or a distributed storage solution. A Persistent Volume
is statically provisioned by the cluster administrator.

2.5 ConfigMap and Secrets

While deploying an application, we may need to pass such runtime parameters like configuration
details, permissions, passwords, keys, certificates, or tokens. Let’s assume we need to deploy ten
different applications for our customers, and for each customer, we need to display the name of
the company in the UI. Then, instead of creating ten different Docker images for each customer,
we may just use the same template image and pass customers’ names as runtime parameters. In
such cases, we can use the ConfigMap API resource. Similarly, when we want to pass sensitive
information, we can use the Secret API resource.
Secret Let’s assume that we have a Wordpress blog application, in which our wordpress frontend
connects to the MySQL database backend using a password. While creating the Deployment
for wordpress, we can include the MySQL password in the Deployment’s YAML file, but the
password would not be protected. The password would be available to anyone who has access
to the configuration file. In this scenario, the Secret object can help by allowing us to encode
the sensitive information before sharing it. With Secrets, we can share sensitive information like
passwords, tokens, or keys in the form of key-value pairs, similar to ConfigMaps; thus, we can
control how the information in a Secret is used, reducing the risk for accidental exposures. In
Deployments or other resources, the Secret object is referenced, without exposing its content. It
is important to keep in mind that by default, the Secret data is stored as plain text inside etcd,
therefore administrators must limit access to the API server and etcd.

8
Chapter 3
Services and Networking

3.1 Services

3.1.1 ClusterIP

The ClusterIP service is the default service for Kubernetes. It provides a service within the
cluster. Pods within the same cluster can use this service to access them. The ClusterIP service
does not provide external access.

3.1.2 NodePort

A NodePort service is the easiest way to route external traffic directly to a Pod. NodePort, as
its name suggests, opens a specific port on all nodes (VMs), and any traffic sent to that port is
forwarded to the service.

3.1.3 LoadBalanacer

A LoadBalancer service is the standard way to expose a service via a load balancer. This type of
service is particularly suitable for Kubernetes clusters managed by a cloud provider. For example
on Google’s cloud infrastructure, in a GKE cluster, this will run a loadbalancer that will give a
single IP address that will forward all traffic to your service.

9
3.2 Ingress
With Services, routing rules are associated with a given Service. They exist for as long as the
Service exists, and there are many rules because there are many Services in the cluster. If we can
somehow decouple the routing rules from the application and centralize the rules management,
we can then update our application without worrying about its external access. This can be done
using the Ingress resource.
To allow the inbound connection to reach the cluster Services, Ingress configures a Layer 7
HTTP/HTTPS load balancer for Services and provides the following:
• TLS (Transport Layer Security)
• Name-based virtual hosting
• Fanout routing • Loadbalancing
With Ingress, users do not connect directly to a Service. Users reach the Ingress endpoint, and,
from there, the request is forwarded to the desired Service.

3.3 Networking
Kubernetes networking refers to the way that network traffic is managed within a Kubernetes
cluster. The goal of Kubernetes networking is to provide a network that is simple to use and
manage, while also providing the features that are required for running cloud-native applications,
such as load balancing, service discovery, and network segmentation.
Kubernetes networking is implemented using the Container Network Interface (CNI), which is a
plugin-based architecture for connecting containers to networks. The CNI provides a standard
interface for networking plugins to communicate with the Kubernetes API server. There are many
CNI plugins available, including Calico, Cilium, and Flannel, each of which implements its own
network policy, network segmentation, and network topology.
In addition to the CNI, Kubernetes networking also includes other components, such as Services
and NetworkPolicies, which are used to manage network traffic between pods and external end-
points. Services are used to expose pods to external network traffic, while NetworkPolicies are
used to restrict network access between pods. There are several plugins available for implement-
ing the networking model in Kubernetes. Some of the most commonly used plugins are:

10
Calico: Calico is a pure-play networking solution that provides network security, network seg-
mentation, and network policy enforcement. It uses the Border Gateway Protocol (BGP) to route
traffic between pods, and is known for its performance and scalability.
Cilium: Cilium is a network security solution that uses eBPF (extended Berkeley Packet Filter)
to provide network security and visibility. It provides a simple and efficient way to enforce net-
work policies and to monitor network traffic.
Flannel: Flannel is a simple, easy-to-use overlay network that provides network communication
between pods. It uses the Virtual Ethernet Bridge (VEB) to route traffic between pods, and is
designed to be easy to deploy and manage.
Weave Net: Weave Net is a flexible and scalable overlay network that provides network com-
munication between pods. It uses a distributed virtual switch to route traffic between pods, and
is known for its simplicity and performance.
Kube-router: Kube-router is a network routing solution that provides network communication
between pods. It uses the BGP routing protocol to route traffic between pods, and is known for
its simplicity and performance.
Each plugin has its own set of advantages and disadvantages, and the choice of plugin depends
on the specific requirements of your deployment. Additionally, some plugins are more suited to
specific use cases, such as network security or performance, while others are more general-purpose.

11
Statefulset

A StatefulSet is a type of resource in Kubernetes that manages stateful applications. Stateful ap-
plications are applications that require stable network identities, persistent storage, and ordered,
graceful deployment and scaling.
A StatefulSet is similar to a Deployment in that it manages the deployment and scaling of pods,
but with some important differences. First, each pod in a StatefulSet has a unique, persistent
network identity that is maintained across restarts and rescheduling. This is important for state-
ful applications that need to maintain a stable network identity for their data and configuration.
Second, a StatefulSet provides a stable, ordered deployment and scaling process. When a State-
fulSet is created or updated, pods are deployed one at a time in a predictable order, and when a
StatefulSet is deleted, pods are deleted in the reverse order. This allows stateful applications to
maintain the correct order of operations during deployment and scaling.
Finally, a StatefulSet can be used to manage persistent storage for stateful applications. Each
pod in a StatefulSet can be associated with a PersistentVolumeClaim, which allows it to access
persistent storage that is maintained across restarts and rescheduling.
In summary, a StatefulSet is useful for managing stateful applications that require stable network
identities, persistent storage, and ordered graceful deployment and scaling. Some examples of
stateful applications that can be run using a StatefulSet include databases, message brokers, and
distributed file systems.

12