Introduction Kubernetes

INTRODUCTION TO DOCKER SWARM KUBERNETES

01 KUBERNETES 02 VS KUBERNETES 03 ARCHITECTURE

KUBERNETES WORKING OF DEPLOYMENTS IN

04 05 KUBERNETES 06 KUBERNETES
INSTALLATION

SERVICES IN INGRESS IN KUBERNETES

07 08 KUBERNETES
09
KUBERNETES DASHBOARD
Introduction to Kubernetes
Introduction to Kubernetes

Kubernetes is an open-source container orchestration software

It was originally developed by Google

It was first released on July 21st 2015

It is the ninth most active repository on GitHub in terms of

number of commits
Features of Kubernetes

Pods Service Discovery

Replication Controller Networking

Storage Management Secret Management

Resource Monitoring Rolling Updates

Health Checks
Docker Swarm vs
Kubernetes
Docker Swarm vs Kubernetes
Docker Swarm vs Kubernetes

Docker Swarm Kubernetes

Easy to Install and Initialize Complex Procedure to install Kubernetes

Faster when compared to Kubernetes Slower when compared with Docker Swarm

Not Reliable and has less features More Reliable and comparatively has more
features
Kubernetes Architecture
Kubernetes Architecture

Master Node

Slave Node Slave Node Slave Node

Kubernetes Architecture

Master Node Docker

etcd API Server Scheduler

Controller Manager

Slave Node Slave Node Slave Node

Docker Docker Docker

Kubelet Kube-proxy Kubelet Kube-proxy Kubelet Kube-proxy

Kubernetes Architecture –
Master Components
Kubernetes Architecture – Master Components

It is a highly available distributed key value store, which is used to store

cluster wide secrets. It is only accessible by Kubernetes API server, as it has
etcd
sensitive information.

API Server

Scheduler
Master Node Docker

etcd API Server Scheduler

Controller Manager
Controller Manager
Kubernetes Architecture – Master Components

It exposes the Kubernetes API. The Kubernetes API is the front-end for
Kubernetes Control Plane, and is used to deploy and execute all
etcd
operations in Kubernetes

API Server

Scheduler
Master Node Docker

etcd API Server Scheduler

Controller Manager
Controller Manager
Kubernetes Architecture – Master Components

The scheduler takes care of scheduling of all the processes, Dynamic Resource
Management and manages present and future events on the cluster
etcd

API Server

Scheduler
Master Node Docker

etcd API Server Scheduler

Controller Manager
Controller Manager
Kubernetes Architecture – Master Components

The controller manager, runs all the controllers on the Kubernetes Cluster.
Although each controller, is a separate process, but to reduce complexity,
all the controllers are compiled into a single process. They are as follows:
etcd Node Controller, Replication Controller, Endpoints Controller, Service
Accounts and Token Controllers

API Server

Scheduler
Master Node Docker

etcd API Server Scheduler

Controller Manager
Controller Manager
Kubernetes Architecture –
Slave Components
Kubernetes Architecture – Master Components

Kubelet takes the specification from the API server, and ensures the
application is running according to the specifications which were mentioned.
Each node has it’s kubelet service

Kubelet

Kube-Proxy Slave Node

Docker

Kubelet Kube-proxy
Kubernetes Architecture – Master Components

This proxy service runs on each node and helps in making services available
to the external host. It helps in connection forwarding to the correct
resources, it is also capable of doing primitive load balancing

Kubelet

Kube-Proxy Slave Node

Docker

Kubelet Kube-proxy
Kubernetes Installation
Kubernetes Installation
There are numerous ways to install Kubernetes, following are some of the popular ways:

▪ Kubeadm – Bare Metal Installation

▪ Minikube – Virtualized Environment for Kubernetes

▪ Kops – Kubernetes on AWS

▪ Kubernetes on GCP – Kubernetes running on Google Cloud Platform

Hands-on: Installing
Kubernetes using kubeadm
Working of Kubernetes
Working of Kubernetes

Pod – Replica 1

Pod – Replica 2

Pods can have one or more containers coupled

together. They are the basic unit of Kubernetes.
To increase High Availability, we always prefer
pods to be in replicas Pod – Replica 3
Working of Kubernetes

Services are used to load balance the traffic

among the pods. It follows round robin
distribution among the healthy pods

Pod – Replica 1

Service

Pod – Replica 2

Pod – Replica 3
Working of Kubernetes

Pod – Replica 1
Image Processing

Service
Pod – Replica 2

Intellipaat.com/image

Pod – Replica 3
Ingress

Intellipaat.com/video
Pod – Replica 1
An Ingress is an object that allows access to
your Kubernetes services from outside the Service
Kubernetes cluster. You configure access by creating a Video Processing Pod – Replica 2
collection of rules that define which inbound
connections reach which services.
Pod – Replica 3
Deployments in Kubernetes
Deployments in Kubernetes

Deployment in Kubernetes is a controller which helps your applications reach the

desired state, the desired state is defined inside the deployment file

Deployment

Pods
YAML Syntax for Deployments
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
This YAML file will deploy 3 pods for nginx, and matchLabels:
maintain the desired state which is 3 pods, until app: nginx
template:
this deployment is deleted
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Creating a Deployment
Once the file is created, to deploy this deployment use the following syntax:

Syntax
kubectl create –f nginx.yaml
List the Pods
To view the pods, type the following command:

Syntax
kubectl get po

As you can see, the number of pods are matching with the number of replicas specified in the deployment file
Creating a Service
Creating a Service

A Service is basically a round-robin load balancer for all the pods, which match with it’s name or selector. It
constantly monitors the pods, in case a pod gets unhealthy, the service will start deploying the traffic to the
other healthy pods.

Pod – Replica 1

Service
Pod – Replica 2

Pod – Replica 3
Service Types

ClusterIP: Exposes the service on cluster-internal IP

NodePort: Exposes the service on each Node’s IP at a static port

LoadBalancer: Exposes the service externally using a cloud provider’s load balancer.

ExternalName: Maps the service to the contents of the ExternalName

Pod – Replica 1

Service
Pod – Replica 2

Pod – Replica 3
Creating a NodePort Service
We can create a NodePort service using the following syntax:

Syntax
kubectl create service nodeport <name-of-service> --tcp=<port-of-service>:<port-of-container>
Creating a NodePort Service
To know the port, on which the service is being exposed type the following command:

Syntax
kubectl get svc nginx
Creating a NodePort Service
To know the port, on which the service is being exposed type the following command:

Syntax
kubectl get svc nginx
Creating an Ingress
What is an Ingress?

Kubernetes ingress is a collection of routing rules that govern how external users
access services running in a Kubernetes cluster.

Service
Intellipaat.com/image

Ingress

Intellipaat.com/video
Service
What is an Ingress?
Ingress Rules
Pod – Replica 1

Service
Pod – Replica 2
ClusterIP
Intellipaat.com/video

Pod – Replica 3

Ingress Ingress
Service Controller
Intellipaat.com/image
Pod – Replica 1

NodePort
Service
Pod – Replica 2
ClusterIP

Pod – Replica 3
Installing Ingress Controller
We will be using the nginx ingress controller, for our demo. We can download it from the following link:

Link
https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md
Define Ingress Rules

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: simple-fanout-example
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
The following rule, will redirect traffic which asks for spec:
/foo to nginx service. All the other requests, will be rules:
redirected to ingress controller’s default page - http:
paths:
- path: /foo
backend:
serviceName: nginx
servicePort: 80
Deploying Ingress Rules
To deploy the ingress rules, we use the following syntax:

Syntax
kubectl create –f ingress.yaml
Viewing Ingress Rules
To deploy the ingress rules, we use the following syntax:

Syntax
kubectl get ing
Kubernetes Dashboard
Kubernetes Dashboard

Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy
containerized applications to a Kubernetes cluster, troubleshoot your containerized
application, and manage the cluster resources.
Installing Kubernetes Dashboard
To install Kubernetes Dashboard, execute the following command:

Syntax
kubectl create -f
https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-
dashboard.yaml
Accessing Kubernetes Dashboard
Change the service type for Kubernetes-Dashboard to Nodeport

Syntax
kubectl -n kube-system edit service kubernetes-dashboard
Logging into Kubernetes Dashboard
1. Check the NodePort from the kubernetes-dashboard service
2. Browse to your cluster on the internet browser, and enter the IP address
3. Click on Token, it will ask you for the token entry
4. Generate a token using the following command

$ kubectl create serviceaccount cluster-admin-dashboard-sa

$ kubectl create clusterrolebinding cluster-admin-dashboard-sa \
--clusterrole=cluster-admin \
--serviceaccount=default:cluster-admin-dashboard-sa

$ TOKEN=$(kubectl describe secret $(kubectl -n kube-system get secret | awk '/^cluster-admin-dashboard-sa-

token-/{print $1}') | awk '$1=="token:"{print $2}')

$ echo $TOKEN

5. Finally, enter the token and login to your dashboard