Kubernetes

Seminar report for the evaluation and partial fulfilment of the

requirement for the end semester.
B. TECH (ECE)

Submitted By –

Arpit Singh (20/BEC/063)

UNDER THE SUPERVISION OF

Dr Vimlesh Kumar Ray & Ms Shruti Awasthi

University School Of Information & Communication Technology

Gautam Buddha University
Greater Noida-201312, Gautam Buddha Nagar
Uttar Pradesh India
Session 2023-2024

Gautam Buddha University

 University School Of Information & Communication Technology
Gautam Buddha University
Greater Noida-201312, Gautam Buddha Nagar

Candidate’s Declaration
I, hereby, certify that the work embodied in this Seminar report entitled " Kubernetes" is in
partial fulfilment of the requirements for the award of the Degree of B. Tech (ECE) submitted
to the School of Information and Communication Technology, Gautam Buddha University,
Greater Noida is an authentic record of our own work carried out under the supervision of Dr.
Vimlesh Kumar Ray and Ms. Shruti Awasthi, School of ICT. The matter presented in this report
has not been submitted to any other University Institute for the award of any other degree or
diploma. Responsibility for plagiarism-related issue stands solely with us.

Arpit Singh 20/BEC/063

This is to certify that the above statement made by the candidates is correct to the best of my
knowledge and belief. However, responsibility for any plagiarism-related issue solely stands
with the students.

Signature of the Supervisor:

Name with Designation:

Gautam Buddha University

 ACKNOWLEDGEMENT

I wish to take this opportunity to express my sincere and deep sense of respect to Prof. Sanjay
Kumar Sharma (Dean, SoICT), Dr. Vimlesh Ray, Ms. Shruti Awasthi , Supervisors &
Faculties of SoICT of Gautam Buddha University for giving me this opportunity and
allowing me to work on this topic.

I would also like to extent my deep appreciation to my family without their support and
constant encouragement I would not have been able to complete this topic.

Arpit Singh
20/BEC/063
B.Tech (Electronics and Communication) 8th Semester
Gautam Buddha University, Greater Noida

Gautam Buddha University

 ABSTRACT

Kubernetes is a Container Orchestration Platform incubated under the Cloud Native Computing
Foundation, which allows users to run applications at scale. It Consists a set of Master and Worker
nodes. The master node is where the user interacts with the Cluster. The Master Nodes consists of
components like API-Server, Scheduler, etc. which form the brain of the cluster. Kubernetes also
depends on ETCD, as the Meta store where the cluster’s state is stored. ETCD uses Raft protocol for the
underlying replicated state machine. Users apply a declarative config to the Cluster, and the Kubernetes
Master components make sure that the desired state meets the current state. Applications are bundled as
Container Images, and are pushed to an Image Registry. The worker nodes pull those images and run the
application. By Pushing the storage problems out of the cluster, Kubernetes makes it very easy to
manage the state of the cluster, and also perform upgrades. It also nails the developer experience in
maintaining the cluster. One of the other benefits of Kubernetes is flexibility. Rather than using concrete
implementations, Kubernetes chooses Interfaces thus making every component pluggable. Based on
their applications and priorities, users can use component of their use-case without having to choose
trade-offs. This also fuelled the growth of an awesome open source ecosystem around Kubernetes
components, thus making Kubernetes very flexible and allowing users to change it based on their use-
case.

Gautam Buddha University

Contents
1. INTRODUCTON ........................................................................................................................................ 1
1.1 INTRODUCTION TO KUBERNETES............................................................................................... 1
1.2 INTRODUCTION TO CONTAINERS ............................................................................................... 3
2. KUBERNETES COMPONENTS ................................................................................................................ 4
2.1 CONTROL PLANE COMPONENTS ................................................................................................. 4
kube-apiserver ............................................................................................................................................. 4
etcd.............................................................................................................................................................. 4
2.2 NODE COMPONENTS...................................................................................................................... 6
kubelet ......................................................................................................................................................... 6
kube-proxy .................................................................................................................................................. 6
Container Runtime ....................................................................................................................................... 6
2.3 ADDONS ........................................................................................................................................... 7
DNS ............................................................................................................................................................ 7
Web UI (Dashboard) .................................................................................................................................... 7
Container Resource Monitoring.................................................................................................................... 7
Cluster-level Logging................................................................................................................................... 7
3. HISTORY OF DISTRIBUTED SYSTEMS.................................................................................................. 8
4. ARCHITECTURE ....................................................................................................................................... 9
4.1 ARCHITECTURE OF KUBERNETES............................................................................................... 9
4.2 NETWORKING ............................................................................................................................... 10
5. MICRO SERVICES .................................................................................................................................. 11
5.1 INTRODUCTION ............................................................................................................................ 11
5.2 SERVICE DISCOVERY .................................................................................................................. 12
6. KUBERNETS AND CONTAINERS ......................................................................................................... 13
6.1 ADVANTAGES ............................................................................................................................... 13
6.2 DISADVANTAGES ......................................................................................................................... 13
7. CONCLUSION ......................................................................................................................................... 14

Gautam Buddha University

 KUBERNETES

1. INTRODUCTON

1.1 INTRODUCTION TO KUBERNETES

Early on, organizations ran applications on physical servers. There was no way to define resource
boundaries for applications in a physical server, and this caused resource allocation issues. For example,
if multiple applications run on a physical server, there can be instances where one application would take
up most of the resources, and as a result, the other applications would underperform. A solution for this
would be to run each application on a different physical server. But this did not scale as resources were
underutilized, and it was expensive for organizations to maintain many physical servers. As a solution,
virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical
server’s CPU. Virtualization allows applications to be isolated between VMs and provides a level of
security as the information of one application cannot be freely accessed by another application.

Virtualization allows better utilization of resources in a physical server and allows better scalability
because an application can be added or updated easily, reduces hardware costs, and much more. With
virtualization you can present a set of physical resources as a cluster of disposable virtual machines.
Each VM is a full machine running all the components, including its own operating system, on top of the
virtualized hardware. Containers are similar to VMs, but they have relaxed isolation properties to share
the Operating System (OS) among the applications. Therefore, containers are considered lightweight.
Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are
decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.

Containers are a good way to bundle and run your applications. In a production environment, you need to
manage the containers that run the applications and ensure that there is no downtime. That’s how
Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems
resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and
more. For example, Kubernetes can easily manage a canary deployment for your system.

Gautam Buddha University 1 20/BEC/063

 KUBERNETES

Kubernetes was originally developed and designed by engineers at Google. It was based on their
Internal Platform called Borg. Borg was the predecessor to Kubernetes and the lessons learned from
developing Borg over the years became the primary influence behind much of Kubernetes technology.

The Declarative Configuration is provided to the API-Server in the form of YAML or JSON. Based on
the configuration, API-Server then schedules relevant applications on the worker nodes, based on the
current state of the cluster.

Fig 1: Master Slave

Gautam Buddha University 2 20/BEC/063

 KUBERNETES

1.2 INTRODUCTION TO CONTAINERS

A Container can be considered as an Isolated Process. There is no concrete primitive as a Container in

Linux, but Containers can be considered as a group of isolated configurations applied to a Linux
process. Docker is one of the popular tools, that makes it very easy for users to run Containers. Users
use docker and build an image of their application. The image will usually consist of all the application
dependencies, thus allowing users to directly run the image without installing any application
dependencies including a base operating system. Docker or any other Container Runtime just takes those
images, and runs them as Containers with relevant configuration. Unlike Virtual Machines, All
Containers on the same host share the same Kernel, thus not having the overhead of start-up times, and
performance which are common with Virtual Machines. As there is no base overhead, a greater number
of Containers can be run on the same host, unlike Virtual Machines.

Docker is a tool designed to make it easier to create, deploy, and run applications by using containers.
Containers allow a developer to package up an application with all of the parts it needs, such as libraries
and other dependencies, and deploy it as one package.

Fig 2: Containerization

Gautam Buddha University 3 20/BEC/063

 KUBERNETES

2. KUBERNETES COMPONENTS
When you deploy Kubernetes, you get a cluster. A Kubernetes cluster consists of a set of worker
machines, called nodes, that run containerized applications. Every cluster has at least one worker
node. The worker node(s) host the pods that are the components of the application. The Control
Plane manages the worker nodes and the pods in the cluster. In production environments, the
Control Plane usually runs across multiple computers and a cluster usually runs multiple nodes,
providing fault-tolerance and high availability.

 Control plane Components

 Node Components
 Addons

2.1 CONTROL PLANE COMPONENTS

The Control Plane’s components make global decisions about the cluster (for example, scheduling), as
well as detecting and responding to cluster events (for example, starting up a new pod when a
deployment’s replicas field is unsatisfied).Control Plane components can be run on any machine in the
cluster. However, for simplicity, set up scripts typically start all Control Plane components on the same
machine, and do not run user containers on this machine. See Building High-Availability Clusters for an
example multi-master- VM setup.

kube-apiserver

The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The
API server is the front end for the Kubernetes control plane. The main implementation of a Kubernetes
API server is kube-apiserver. kube-apiserver is designed to scale horizontally—that is, it scales by
deploying more instances. You can run several instances of kube-apiserver and balance traffic between
those instances.

etcd

Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data. If
your Kubernetes cluster uses etcd as its backing store, make sure you have a backup plan for those data.

Gautam Buddha University 4 20/BEC/063

 KUBERNETES

kube-scheduler

Control Plane component that watches for newly created pods with no assigned node, and selects a node
for them to run on. Factors taken into account for scheduling decisions include individual and collective
resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications,
data locality, inter-workload interference and deadlines.

kube-controller-manager

Control Plane component that runs controller processes. Logically, each controller is a separate process,
but to reduce complexity, they are all compiled into a single binary and run in a single process.

These controllers include:

Node Controller: Responsible for noticing and responding when nodes go down.
Replication Controller: Responsible for maintaining the correct number of pods for every replication
controller object in the system.
Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
Service Account & Token Controllers: Create default accounts and API access tokens for new
namespaces.

cloud-controller-manager

It runs controllers that interact with the underlying cloud providers. The cloud-controller-manager
binary is an alpha feature introduced in Kubernetes release 1.6. cloud-controller-manager runs cloud-
provider- specific controller loops only. You must disable these controller loops in the kube-controller-
manager. You can disable the controller loops by setting the --cloud-provider flag to external when
starting the kube- controller-manager. cloud-controller-manager allows the cloud vendor’s code and the
Kubernetes code to evolve independently of each other. In prior releases, the core Kubernetes code was
dependent upon cloud- provider-specific code for functionality. In future releases, code specific to cloud
vendors should be maintained by the cloud vendor themselves, and linked to cloud-controller-manager
while running Kubernetes.

Gautam Buddha University 5 20/BEC/063

 KUBERNETES

The following controllers have cloud provider dependencies:

Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud
after it stops responding
Route Controller: For setting up routes in the underlying cloud infrastructure
Service Controller: For creating, updating and deleting cloud provider load balancers
Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud
provider to orchestrate volumes

2.2 NODE COMPONENTS

Node components run on every node, maintaining running pods and providing the Kubernetes
runtime environment.

kubelet

An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.

The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures
that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t
manage containers which were not created by Kubernetes.

kube-proxy

kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the
Kubernetes Service concept. kube-proxy maintains network rules on nodes. These network rules
allow network communication to your Pods from network sessions inside or outside of your
cluster. kube-proxy uses the operating system packet filtering layer if there is one and it’s
available. Otherwise, kube-proxy forwards the traffic itself.

Container Runtime

The container runtime is the software that is responsible for running containers. Kubernetes
supports several container runtimes: Docker , containerd , CRI-O , and any implementation of the
Kubernetes CRI (Container Runtime Interface).

Gautam Buddha University 6 20/BEC/063

 KUBERNETES

2.3 ADDONS

Addons use Kubernetes resources (Daemon Set, Deployment , etc.) to implement cluster features.
Because these are providing cluster-level features, namespaced resources for addons belong
within the kube-systemnamespace.

DNS

While the other addons are not strictly required, all Kubernetes clusters should have cluster DNS,
as many examples rely on it. Cluster DNS is a DNS server, in addition to the other DNS server(s)
in your environment, which serves DNS records for Kubernetes services. Containers started by
Kubernetes automatically include this DNS server in their DNS searches.

Web UI (Dashboard)

Dashboard is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage
and troubleshoot applications running in the cluster, as well as the cluster itself.

Container Resource Monitoring

Container Resource Monitoring records generic time-series metrics about containers in a central
database, and provides a UI for browsing that data.

Cluster-level Logging

A cluster-level logging mechanism is responsible for saving container logs to a central log store
with search/browsing interface.

Gautam Buddha University 7 20/BEC/063

 KUBERNETES

3. HISTORY OF DISTRIBUTED SYSTEMS

Distributed Systems allow tasks to be performed at scale, by using a lot of machines together
and distributing the load across the systems. This was especially needed for Internet scale
systems, as there would be a lot of traffic. Previously, Systems like Azure Service Fabric,
Apache Mesos, etc were developed at companies like Microsoft, etc to run their massive scale
systems. These are pretty complicated systems as they use complex state machine algorithms
like Paxos, Raft, etc to replicate data across machines for high availability, and scalability.
This also meant that the mentioned systems were really hard to maintain and upgrade, and
had a lot of constraints around it. Service Fabric was developed at Microsoft, and is currently
used to run Azure, Xbox Services, etc. Google internally uses Borg for running services like
Gmail, YouTube, etc which are internet scale.

Kubernetes takes a drastically different approach by taking the storage problem and moving
it to Etcd, so that it can focus on the developer experience and running containers only. Thus,
Reducing operational and maintenance tasks on the cluster. As Kubernetes is also OSS, Cloud
providers now run a managed offering of it and allow users to easily provision clusters
without having to take up the hard task of provision and maintenance.

Gautam Buddha University 8 20/BEC/063

 KUBERNETES

4. ARCHITECTURE

4.1 ARCHITECTURE OF KUBERNETES

A working Kubernetes deployment is called a cluster. You can visualize a Kubernetes cluster
as two parts: the control plane, which consists of the master node or nodes, and the compute
machines, or worker nodes. Worker nodes run pods, which are made up of containers. Each
node is its own Linux environment, and could be either a physical or virtual machine.

The worker nodes will need the capability to create and run containers. It’s also important to
note that there is an expectation that all the nodes are able to talk to each other.

Fig 4.1: Architecture

Gautam Buddha University 9 20/BEC/063

 KUBERNETES

4.2 NETWORKING

Kubernetes imposes the following fundamental requirements on any networking implementation:

 Pods on a node can communicate with all pods on all nodes without NAT

 All Nodes can communicate with all Pods without NAT.

 The IP that a Pod sees itself as is the same IP that others see it as.

Because each pod has a unique IP in a flat address space inside the Kubernetes cluster, direct
pod-to-pod communication is possible without requiring any kind of proxy or address
translation. This also allows using standard ports for most applications as there is no need to
route traffic from a host port to a container port, as in Docker. Kubernetes services allow
grouping pods under a common access policy. The service gets assigned a virtual IP which
pods outside the service can communicate with. Those requests are then transparently proxied
(via the kube-proxy component that runs on each node) to the pods inside the service. For
Services, there is no central Load Balancer but the proxy on each node updates the IP Tables
rules to perform the routing to the respective Pod on the node.

Kubernetes also allows users to build their own networking plugins which perform this
functionality. This allowed cloud providers like AWS, etc create their own plugins so that
the pods are allocated a IP address from the Virtual Network from the cloud provider, Thus
allowing interoperability with other services from the cloud provider without having to
create bridges.

For traffic coming inside from outside, Kubernetes provides a Ingress resource through
which traffic can be allowed at the Layer 7, and also allows users to perform some routing
there.

Gautam Buddha University 10 20/BEC/063

 KUBERNETES

5. MICRO SERVICES

5.1 INTRODUCTION

Microservices, aka Microservice Architecture, is an architectural style that structures an

application as a collection of small autonomous services, modelled around a business domain.
In microservice architecture, each service is self-contained and implements a single business
capability. A service typically implements a set of distinct features or functionality, such as
order management, customer management, etc. Each microservice is a mini‑application that
has its own hexagonal architecture consisting of business logic along with various adapters.
Some microservices would expose an API that’s consumed by other microservices or by the
application’s clients. Other microservices might implement a web UI. At runtime, each
instance is often a cloud VM or a Docker container.

It allows users to build Highly maintainable, and testable applications and enables rapid and
frequent development and deployment. As these services are loosely coupled with others,
each team can work independently without having to rely on changes in other services and
deploy their work independently. As these applications are also small, Teams can also be
built in a smaller way thus enabling higher productivity by avoiding the high communication
overhead of large teams.

A lot of applications are now being moved from a monolith architecture to Microservices
for the above stated benefits but it has become harder and harder for applications to find
other services that they depend on, as in a dynamic environment IP addresses keep changing
there by needing a way for services to discover other services.

Gautam Buddha University 11 20/BEC/063

 KUBERNETES

5.2 SERVICE DISCOVERY

Kubernetes provides a very easy of way of allowing services to discover other services without having to
hard code their IP Addresses. Kubernetes allows this by using DNS. Services can just call other services
using their name (which is given when the service object is created.) Kubernetes automatically resolves the
Name to the relevant IP address of the pods corresponding to that service, and the service can then directly
send requests to that IP. This makes it very easy for application developers to depend on other services
without having to fall into the configuration hell.

<service_name>. <namespace> => Corresponding IP addresses.

Example:

The DNS query for a service name backend in team-2 namespace.

Backend.team-2 => {192.168.1.1, 192.18.1.2, etc}

Applications can then send requests directly to those IP addresses. These IP addresses are the endpoints of
the relevant pods of the service and would directly respond back to the user application. Kubernetes
performs this DNS resolution by using CoreDNS as the component. The CoreDNS talks to the API Server,
and maintains the list of services in the cluster, and updates the list based on the changes.

Gautam Buddha University 12 20/BEC/063

 KUBERNETES

6. KUBERNETS AND CONTAINERS

6.1 ADVANTAGES
 Open Source, backed by a very active Foundation called Cloud Native Computing Foundation with
a very active contributor base.
 A very flexible architecture, allowing users to plug and play components as they are needed without
having to opt-in for the full package.
 Users can also write their own variants of the components based on their infrastructure, as most
components are just interfaces.
 Cloud Providers offer their own Managed Kubernetes Services, allowing users to directly take
advantage of this technology without having to provision and maintain underlying machines.
 There is no vendor lock-in as the same Kubernetes cluster experience is present across various
Cloud providers, on- premise and even on edge now.
 Allows applications to be deployed as containers, thus notonly being light weight but also making
the builds reproducible.
 An awesome OSS ecosystem of projects that add features to Kubernetes like GitOps, Service
Meshes, etc. Thus, there are multiple solution available for most problems

6.2 DISADVANTAGES
 It can be overkill for simple applications, as its relatively complex to manage and maintain.
 If not used correctly and with standards, it can even decrease developer productivity as maintaining
the cluster could behard.
 As it’s a fast-moving project, Things keep changing every release and it’s important to keep up
with the changes and this requires additional developers to take this work.
 The transition to Kubernetes can be really hard, based on your existing infrastructure, as existing
applications have to be first converted to microservices, and then containerized and then deployed
into the cluster.
 Running Stateful Applications is comparatively harder and its definitely not easy right now.

Gautam Buddha University 13 20/BEC/063

 KUBERNETES

7. CONCLUSION

Kubernetes has definitely re defined how Micro-services are built now. Most applications that we use daily
like Spotify, twitter, etc. moved to Kubernetes as the underlying infrastructure platform and these
applications are internet scale. So, Kubernetes can mostly support all types of use-cases. Though there is a
debate on supporting stateful applications on Kubernetes, it’s not easy and requires professional disks and
underlying hardware to be highly available which is not the case in most on-premises Infrastructure. But
there is a lot of work being added, to support stateful applications on Kubernetes. Kubernetes even after
being late to the Distributed Systems ecosystem i.e 2014 but already is considered a winner as it’s the most
widely used orchestration platform.
Even cloud providers like Microsoft, Google, etc are also not only offering Kubernetes as a service but also
are using it as a platform to run services like Xbox, Gmail, etc. Massive Scale applications are being
deployed on Kubernetes and are ran successfully, which is a huge testament to the project and its
architecture.

Gautam Buddha University 14 20/BEC/063

 KUBERNETES

REFERENCES

 https://kubernetes.io/docs/concepts/architecture/
 https://www.nginx.com/blog/introduction-to-microservices/
 https://www.docker.com/resources/what-container
 https://kubernetes.io/docs/concepts/cluster- administration/networking/
 https://kubernetes.io/docs/concepts/services- networking/ingress/
 https://kubernetes.io/docs/concepts/services- networking/service/
 https://kubernetes.io/case-studies/

Gautam Buddha University 15 20/BEC/063