Name : Manish Sonawane

Roll No. : 321071

PRN No. : 22210982

ASSIGNMENT 8

AIM: Deploy Web app using Kubernetes

THEORY:

 What is Kubernetes?
Kubernetes is a portable, extensible, open-source platform for
managing containerized workloads and services, that facilitates
both declarative configuration and automation. It has a large,
rapidly growing ecosystem. Kubernetes services, support, and tools
are widely available.
The name Kubernetes originates from Greek, meaning helmsman or
pilot. Google open-sourced the Kubernetes project in 2014.
Kubernetes combines over 15 years of Google's experience running
production workloads at scale with best-of-breed ideas and
practices from the community

 Why you need Kubernetes and what it can do

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. For
example, if a container goes down, another container needs to
start. Wouldn't it be easier if this behavior was handled by a
system?
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.
Kubernetes provides you with:
 Service discovery and load balancing
 Storage orchestration
 Automated rollouts and rollbacks
  Automatic bin packing
 Self-healing
 Secret and configuration management
 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 workload. 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.
This document outlines the various components you need to have a
complete and working Kubernetes cluster.
Here's the diagram of a Kubernetes cluster with all the components
tied together.

 Kubernetes Architecture
Kubernetes Architecture on AWS:

 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.
1. 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.
2. 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 back up plan for those data.
You can find in-depth information about etcd in the official
documentation.
3. 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.
4. 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.
5. cloud-controller-manager
A Kubernetes control plane component that embeds cloud-specific
control logic. The cloud controller manager lets you link your cluster
into your cloud provider's API, and separates out the components
that interact with that cloud platform from components that just
interact with your cluster.
The cloud-controller-manager only runs controllers that are specific
to your cloud provider. If you are running Kubernetes on your own
premises, or in a learning environment inside your own PC, the
cluster does not have a cloud controller manager.
As with the kube-controller-manager, the cloud-controller-manager
combines several logically independent control loops into a single
binary that you run as a single process. You can scale horizontally
(run more than one copy) to improve performance or to help
tolerate failures.
The following controllers can 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
 Node Components
Node components run on every node, maintaining running pods and
providing the Kubernetes runtime environment.
1. 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.
2. 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.
3. 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).
 Pods
Pods are the smallest deployable units of computing that you can
create and manage in Kubernetes.
A Pod (as in a pod of whales or pea pod) is a group of one or more
containers, with shared storage/network resources, and a
specification for how to run the containers. A Pod's contents are
always co-located and co-scheduled, and run in a shared context. A
Pod models an application-specific "logical host": it contains one or
more application containers which are relatively tightly coupled. In
non-cloud contexts, applications executed on the same physical or
virtual machine are analogous to cloud applications executed on
the same logical host.
 Using Pods
Usually you don't need to create Pods directly, even singleton Pods.
Instead, create them using workload resources such as Deployment
or Job. If your Pods need to track state, consider the StatefulSet
resource.
Pods in a Kubernetes cluster are used in two main ways:
 Pods that run a single container. The "one-container-per-
Pod" model is the most common Kubernetes use case; in this
case, you can think of a Pod as a wrapper around a single
container; Kubernetes manages Pods rather than managing
the containers directly.
 Pods that run multiple containers that need to work
together. A Pod can encapsulate an application composed of
multiple co-located containers that are tightly coupled and
need to share resources. These co-located containers form a
single cohesive unit of service—for example, one container
serving data stored in a shared volume to the public, while a
separate sidecar container refreshes or updates those files.
The Pod wraps these containers, storage resources, and an
ephemeral network identity together as a single unit.
  Service
An abstract way to expose an application running on a set of Pods
as a network service.
With Kubernetes you don't need to modify your application to use
an unfamiliar service discovery mechanism. Kubernetes gives Pods
their own IP addresses and a single DNS name for a set of Pods, and
can load-balance across them.

 Ingress
FEATURE STATE: Kubernetes v1.19 [stable]
An API object that manages external access to the services in a
cluster, typically HTTP.
Ingress may provide load balancing, SSL termination and name-
based virtual hosting.
 Terminology
For clarity, this guide defines the following terms:
 Node: A worker machine in Kubernetes, part of a cluster.
 Cluster: A set of Nodes that run containerized applications
managed by Kubernetes. For this example, and in most
common Kubernetes deployments, nodes in the cluster are not
part of the public internet.
 Edge router: A router that enforces the firewall policy for your
cluster. This could be a gateway managed by a cloud provider
or a physical piece of hardware.
 Cluster network: A set of links, logical or physical, that
facilitate communication within a cluster according to the
Kubernetes networking model.
 Service: A Kubernetes Service that identifies a set of Pods
using label selectors. Unless mentioned otherwise, Services
are assumed to have virtual IPs only routable within the
cluster network.
 What is Ingress?
Ingress exposes HTTP and HTTPS routes from outside the cluster to
services within the cluster. Traffic routing is controlled by rules
defined on the Ingress resource.
Here is a simple example where an Ingress sends all its traffic to
one Service:
An Ingress may be configured to give Services externally-reachable
URLs, load balance traffic, terminate SSL / TLS, and offer name-
based virtual hosting. An Ingress controller is responsible for
fulfilling the Ingress, usually with a load balancer, though it may
also configure your edge router or additional frontends to help
handle the traffic.
An Ingress does not expose arbitrary ports or protocols. Exposing
services other than HTTP and HTTPS to the internet typically uses a
service of type Service.Type=NodePort or
Service.Type=LoadBalancer.

Try Kubernetes:

There are many ways to install Kubernetes.

1) Manual means that you manually set up everything from the

networking bits over downloading, configuring and launching
components such as etcd or kube-apiserver. You've got full control
over what goes where, but it might take you some time and it's
error-prone. The ultimate reference in this area is Kelsey
Hightower's Kubernetes The Hard Way (KTHW).

2) Installer are CLI tools that leverage templates and/or

automation tools such as Terraform and Ansible. You typically have
a lot control over what is going on, but less than in the manual
approach. Examples include:
 OpenCredo's Kubernetes from scratch to AWS with Terraform
and Ansible
 kubeadm (bare metal installation, a building block for other
installers)
 kops, mainly AWS (AWS also provide service for kubernetes:
 EKS – Elastic Kubernets Service)
 kubicorn
 kubespray (Ansible-based, both bare-metal and cloud)
 OpenShift advanced install based on Ansible
3) Hosted effectively means little to no installation effort on your
end. For example:
 Azure Container Service (ACS) with Kubernetes
 Google Container Engine (GKE)
 IBM Bluemix Container Service
 OpenShift Online (OSO)
4) Minikube or Minishift – Virtualized Environemnt for Kubernetes

 Setup Single Node Kubernetes Cluster with Minikube

1. Installing Minikube ->

https://kubernetes.io/docs/tasks/tools/install-minikube/
Install Virtualbox latest edition.

2. Setting up Minikube on virtualbox ->

https://kubernetes.io/docs/tasks/tools/install-minikube/
You will need to keep the minikube in the PATH both on
Windows/Linux

Use the following instruction to setup single node Kubernetes

cluster
minikube start --driver=virtualbox
You can also set custom configuration like
minikube start --driver=virtualbox --cpus=2 --memory=4096m

3. Open the minikube dashboard with following command. It will

take 2-10 mins depending on your bandwidth.
minikube dashboard

4. The dashboard will open in your default browser

 5. On the right side corner you will see a symbol for , click on
it, and go to -> Create from form

6. Enter the details as below

App Name: nginx
Container image: nginx
Number of pods: 1
Service: External
Port: 80
Target Port: 80
Protocol: TCP
Click Deploy

7. Now you will see something like this,

Wait for it to turn green.

You will see the details for deployment below.

8. Access the nginx application in your browser with following

command.

minikube service nginx

The nginx default page will open in browser and you will see the
service details as well.

CONCLUSION:

Thus we have successfully Deployed Web app using Kubernetes.