DevOps Certification Training

Continuous Orchestration Using

Kubernetes
 Learning Objectives

By the end of this lesson, you will be able to:

Describe container orchestration

Explain the Kubernetes components and its features

Demonstrate the creation of a Kubernetes cluster

Deploy an application to the Kubernetes cluster

Container Orchestration
 Container Orchestration

Container orchestration is the automation and management of lifecycle of containers and services.

Purpose

• A container orchestrator automatically deploys and manages containerized apps.

• It responds dynamically to changes in the environment to increase or decrease the
deployed instances of the managed app.
• It ensures all deployed container instances get updated if a new version of a service is
released.
 Why Do We Need Container Orchestration?

Container orchestration is essential to automate and manage tasks such as:

Provisioning and deployment Configuration and scheduling

Resource allocation Container availability

Scaling or removing containers Load balancing and traffic

routing

Monitoring container health Secure container interactions

How Does Container Orchestration Work?

● Container orchestration tools use configuration files (YAML

or JSON) that specify where to find the container images,
how to establish a network, and where to store the logs.

● While deploying a new container, the orchestration tool

automatically schedules the deployment to a cluster and
finds the right host, taking into account any defined
requirements or restrictions.

● It then manages the container’s lifecycle based on the

specifications in the config files.

● These tools can be used in any environment that runs

containers.
 Container Orchestration Tools

Docker Swarm
Introduction to Kubernetes
 Introduction to Kubernetes

Open-source orchestration tool used to manage containerized applications

Originally developed by Google and acquired by Cloud Native Computing

Foundation

Automates deployment and scales containers across multiple nodes in

Kubernetes clusters

Designed in GO language

Acts as a cloud service in major cloud providers such as EKS in AWS and Kubernetes Engine in
GCP
 Features of Kubernetes

Automatic rollouts and Service discovery and load

rollbacks balancing

Horizontal scaling Self-healing

Kubernetes
Automatic bin packing Batch execution
Features

Storage orchestration IPv4/IPv6 dual-stack

Secret and configuration

Service Topology
management
 Docker Swarm Vs. Kubernetes

Docker Swarm Kubernetes

Installation and cluster Easy and fast to install and Takes some work to get up and
setup configure running
Autoscaling Cannot do autoscaling Can do autoscaling

GUI There is no GUI GUI is the Kubernetes dashboard

Highly scalable, scales five times Highly scalable, but scaling and
Scalability
faster than Kubernetes deployment are slow
Manual intervention needed for
Load balancing Automatic load balancing of traffic
load balancing
Can overcome Docker API
Container setup Limited to Docker API capabilities
constraints
Need third party tools for logging Built-in tools for logging and
Logging and monitoring
and monitoring monitoring
 Benefits of Kubernetes

Open source and Portability and flexibility

modular

Multi-cloud capability Huge community support

Easy service organization

with pods Increased developer
productivity
 Case Study: Spotify

Spotify is an audio-streaming platform launched in 2008 and has grown to over 200 million
monthly active users across the world.

With a goal to enable an immersive listening experience for all of its consumers,
Spotify became an early adopter of microservices and Docker.
 Case Study: Spotify

Challenge

Spotify had containerized microservices running across its fleet of virtual machines with a
homegrown container orchestration system called Helios. By late 2017, it was clear that having a
small team working on the features was just not as efficient as adopting something that was
supported by a much bigger community.
Case Study: Spotify

Solution

Adopting Kubernetes was the solution!

It was more feature-rich than Helios. The company could
benefit from added velocity and reduced cost and also align
with the rest of the industry on best practices and tools.
The migration would be smooth and in parallel with Helios
running, as Kubernetes fits very nicely as a complement and
would be a great replacement to Helios.
 Case Study: Spotify

The impacts of adopting Kubernetes by Spotify are given below:

● Less need to concentrate on manual capacity provisioning and

more time to focus on delivering features for Spotify.

● The largest service currently running on Kubernetes takes

around 10 million requests each second and benefits
significantly from autoscaling.

● Teams that previously had to wait for an hour to create a new

service and get an operational host to run it in production, can
do it in the order of seconds and minutes with Kubernetes.

● With it’s bin-packing and multi-tenancy capacities, CPU usage

has enhanced on average two- to threefold.
Kubernetes Architecture
 Kubernetes Components

A working Kubernetes deployment is called a cluster. It has the following components:

Control Plane Nodes

kube-apiserver
kubelet

kube-proxy
kube scheduler
Container runtime
kube-controller-
manager Pod

etcd Containers

Kubernetes cluster
 Kubernetes Components

• Nodes: Sets of worker machines on the Kubernetes cluster that run containerized applications

• Pods: Components of the application workload that run on the worker nodes

• Control Plane: Manages the worker nodes and the pods in the cluster

In production environments, the control plane runs across multiple computers and a cluster runs
multiple nodes, providing fault tolerance and high availability.
 Kubernetes Architecture

Control Plane

• The Kubernetes cluster contains at least kube-controller-

manager

one control plane and one or more kube-apiserver

worker nodes. Developer

kube-scheduler
Users
/Operator

etcd
• Control plane contains the following
components:
o etcd
o kube-apiserver Kubelet Kube-Proxy Kubelet Kube-Proxy

o kube-scheduler
o kube-controller-manager Pod Pod … Pod … Pod Pod … Pod

Plugin Network (eg Flannel, Weavnet, etc)

Kubernetes Node Kubernetes Node

 Kubernetes Architecture

Control Plane

kube-controller-
manager

kube-apiserver

kube-scheduler
Developer
Users
• Kubernetes node contains the following /Operator

etcd
architecture components:
o kubelet
o kube-proxy
o Pod Kubelet Kube-Proxy Kubelet Kube-Proxy

o Container runtime
Pod Pod … Pod … Pod Pod … Pod

Plugin Network (eg Flannel, Weavnet, etc)

Kubernetes Node Kubernetes Node

 Kubernetes Control Plane Components

Control Plane

kube-apiserver
kube-apiserver
● kube-apiserver supports Kubernetes API and processes all the
kube scheduler requests from various components.

● It handles the REST requests and JSON requests and updates the
kube-controller-manager
state of each object in etcd.

etcd
 Kubernetes Control Plane Components

Control Plane
kube-scheduler
kube-apiserver
● kube-scheduler is the component of Kubernetes responsible for
managing workloads in a cluster.
kube scheduler
● It identifies the unutilized node and the process to schedule pods
kube-controller-manager on unutilized nodes based on the requirements.

● It helps to manage all Kubernetes resources effectively.

etcd
 Kubernetes Control Plane Components

Control Plane

kube-controller-manager
kube-apiserver
● kube-controller-manager manages all controllers in Kubernetes
kube scheduler such as DaemonSet and ReplicationController.

● It interacts with the API server to create, edit, and delete any
kube-controller-manager
resources being managed.

etcd
 Kubernetes Control Plane Components

Control Plane
etcd

kube-apiserver ● etcd is a persistent, lightweight, and key-value data store.

● It stores the complete configuration data of a Kubernetes cluster.

kube scheduler
● You can check the state of a cluster with the available data

kube-controller-manager anytime.

● This data store can be shared with other components.

etcd
● It provides a data layer in Kubernetes clusters.
 Kubernetes Control Plane Components

cloud-controller-manager

● It occurs as a part of the control plane components only if you run

kubernetes with a specific cloud provider.

● It incorporates cloud-specific control logic and helps to link your kubernetes

cluster with the cloud provider’s API.

● It only runs the controllers that are specific to your cloud provider.
 Kubernetes Node Components

Kubernetes Node

kubelet kubelet

kube-proxy ● Kubelet is responsible for the working of each node and ensuring
the container’s health.
Container runtime
● It monitors how the pods start, stop, and are maintained.

Pod
● It does not manage containers that are not created by kubernetes.

Containers
 Kubernetes Node Components

Kubernetes Node

kubelet kube-proxy

kube-proxy ● kube-proxy implements network proxy and acts as a load balancer

in Kubernetes cluster.
Container runtime
● It helps to redirect traffic to a specific container in a pod based on
Pod the incoming port and IP details.

Containers
 Kubernetes Node Components

Kubernetes Node
Container runtime

kubelet ● The container runtime is the underlying software that runs

containers on a Kubernetes cluster.
kube-proxy

● It is responsible for fetching, starting, and stopping container

Container runtime
images.

Pod ● Kubernetes supports several container runtimes, including but

not limited to Docker, rkt, CRI-O, and any implementation of the
Containers Kubernetes CRI (Container Runtime Interface).
Interacting with a Kubernetes Cluster
 Overview of kubectl

Kubernetes provides a command-line tool called kubectl to manage your cluster.

kubectl Kubernetes

Kubernetes API
You use kubectl to send commands to the cluster's control plane, or fetch
information about all Kubernetes objects via the API server.
 Overview of kubectl

● kubectl uses a configuration file to find the information it

needs to choose a cluster and communicate with the API server
of a cluster.

● The config files store information about clusters, users,

namespaces, and authentication mechanisms.

kubeconfig file ● You can configure kubectl to connect to multiple clusters by

providing the correct context as part of the command-line
syntax.
 Overview of kubectl

Use the following syntax to run kubectl commands from your terminal window:

kubectl [command] [TYPE] [NAME] [flags]

Where the arguments are as follows:

• command: Refers to the operation you want to perform on one or more resources, for
example create, get, describe, delete

• TYPE: Refers to the resource type, for example pod.

• NAME: Refers to the name of the resource

• flags: Refers to optional flags

Kubernetes Installation and Cluster Setup

Duration: 25 Min.

Problem Statement:

You are given a project to install Kubernetes and set up a Kubernetes cluster.
 Assisted Practice: Guidelines

Steps to install and setup Kubernetes on Linux:

1. Install Kubernetes.

2. Set up a Kubernetes cluster using the kubeadm command.

Kubernetes Basics
 Pods

Pod is a collection of one or more containers with shared storage and network resources and a specification
to run its containers. It is the smallest unit of a Kubernetes application.

Kubernetes Node
• Each pod comprises one or more
containers that can be initialized on any kubelet
host.
kube-proxy
• Each pod is assigned a unique IP using
which we can redirect traffic from outside Pod
to the pod.
Containers
• Pods are managed using the kubelet
command line in a Kubernetes cluster.
 Pods

apiVersion: batch/v1
kind: Job
• Containers in a pod can consist of multiple metadata:
name: hello
applications. spec:
template:
# This is the pod template
spec:
• Pod templates are used to define how pods will containers:
- name: hello
be created and deployed. image: busybox
command: ['sh', '-c', 'echo
"Hello, Kubernetes!" && sleep 3600']
restartPolicy: OnFailure
• Pods share physical resources from host # The pod template ends here

machines in forms of CPU, RAM, and storage.

Pod Template
 Pods

Pods in a Kubernetes cluster are used in two main ways.

Single Container Pods Multi Container Pods

• Common use case • Advanced use case

• Act as a wrapper • Can encapsulate an

around a single application composed of
container multiple co-located,
tightly coupled
containers
Pod Creation in Kubernetes

Duration: 20 Min.

Problem Statement:

You are given a project to create a Kubernetes pod using a yaml file.
 Assisted Practice: Guidelines

Steps to create a Kubernetes cluster on Linux:

1. Create multi-container pods.

2. Create a single container pod.

 Labels and Selectors

Label
s
• Kubernetes attaches key-value pairs called labels for various objects such as services,
pods, and nodes.
• They are intended for easy identification by users and do not have any semantic
implication on the core system.
• They can be used to organize and to select subsets of objects.
 Labels

"metadata": {
• Labels can be attached to objects at creation time and can
"labels": {
"key1" : "value1", be added or modified at any time.
"key2" : "value2"
} • Each object can have a set of key/value labels defined.
}
• Each Key must be unique for a given object.
 Labels

Some examples of labels are as shown below:

"release" : "stable" "environment" : "dev" "tier" : "frontend"

"track" : "daily" "partition" : "customerA"

 Labels and Selectors

Selectors

• Labels do not provide uniqueness, many objects can have a similar label.
• In Kubernetes, the label selector is the core grouping primitive.
• They are used by the users to select a group of objects.
• The Kubernetes API currently supports two kinds of selectors: equality based and set based.
 Selectors

Equality-based selectors allow filtering by using label keys and values.

• Matching objects must satisfy all the specified

environment = production
tier != frontend label constraints.
• Three types of operators are permitted namely
Example: Equality-based selector
=, ==, !=.
 Selectors

Set-based selectors allow filtering keys according to a set of values.

environment in (production, qa) • Three types of operators are permitted namely

tier notin (frontend, backend)
partition in, notin, and exists.
!partition • Set-based requirements can be mixed with
equality-based requirements.
Example: Set-based selector
 Controllers

Controllers are control loops that monitor the state of your Kubernetes cluster, and make or request
changes wherever needed.

Responsible for bringing

Track at least one
the current state closer
Kubernetes resource
to that desired state
type

Kubernetes
Controllers

Ensure availability of
Manage pods using
pods by creating
labels and selectors to
replacements
identify resources
automatically
 Controllers

The controller can directly carry out the action on its own or can control via the API server in
order to bring the desired state.

Direct control Control via API server

• Controllers interact with • Inbuilt controllers

the external state, find manage the current
the desired state from state by interacting with
the API server, then the cluster API server.
communicate directly
with an external system • Example: Autoscaler
to bring the current state controller.
closer in line.

• Example: Job controller.

 Controllers

Types

• ReplicationController replicates and scales pods across Kubernetes clusters.

• Controllers take care of availability of pods, and if it fails, a replacement pod gets created
automatically.
• DaemonSet controller ensures only one pod runs on each node.
• Job controller manages all the batch jobs of pods which are executed in a Kubernetes
cluster.
 Controllers

• Kubernetes has a set of built-in controllers which provide important core behaviors.

• They run inside the kube-controller-manager.

• Some examples of such controllers are deployment controller and job controller.

• There are a few controllers that run outside the control plane.

• You can also write your own controllers to extend the functionalities to suit your needs.
 ReplicaSet

A ReplicaSet is used to ensure that a set of replica pods is running at any given time. It is commonly used to
guarantee the availability of a specified number of identical pods.

● The ReplicaSet uses the selector to identify the pods running and based on the result,
it creates or deletes the pods.

● It is similar to a ReplicationController, the main difference being, ReplicaSet uses set-

based selectors, unlike the replication controller that uses the equality-based
selectors.

● It acquires the pod if the pod does not have an OwnerReference and matches the
selector of ReplicaSet.
 ReplicaSet

When you require custom When you do not

update orchestration require updates at all
When to use a
ReplicaSet
 ReplicaSet

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3

Example of a ReplicaSet
 Deployments

A Deployment is used to provide updates for pods and ReplicaSets. It is a controller that changes the actual
state to the desired state as specified.

To clean up older 7 1 To roll out a ReplicaSet

ReplicaSets

To indicate that a 2 To declare the new

6
rollout is stuck state of pods
Uses

To apply multiple fixes to 5 3 To rollback to an earlier

pods Deployment version

To facilitate more
load
 Deployments

Creating a Deployment
1
Scaling a Deployment
2

Cleaning up a Deployment 6 Operations

policy on
Deployments Updating a Deployment
3

Pausing and resuming a

5
Deployment Rolling back a Deployment
4
 Services

Service is an abstraction which defines a logical set of pods and a policy which can be used to access them.

• The set of pods targeted by a service is commonly determined by a selector.

• Kubernetes allocates a unique port and DNS to each service. The port and DNS details are
changed only if the service object is recreated.

• There can be multiple replicated pods in a service.

• In case of multiple pods, an in-built load balancer is used to share the load between pods
running on different nodes.
 Services

Services are defined in YAML, similar to all other Kubernetes objects.

• Kubernetes assigns a service an IP address on

creation, just like a node or pod.
apiVersion: v1
kind: Service
metadata: • The example specification creates a new service
name: my-service
spec: object named my-service, which targets TCP port
selector:
app: TestApp
ports: 9377 on any Pod with the app=TestApp label.
- protocol: TCP
port: 80
targetPort: 9377 • The controller for the service selector continuously
scans for pods that match its selector, then POSTs
Example: Defining a Service
any updates to an endpoint object also named my-
service.
 Services

When you define a service without a pod selector, the corresponding endpoints object is not
created automatically.

apiVersion: v1 apiVersion: v1
kind: Service kind: Endpoints
metadata: metadata:
name: my-service name: my-service
spec: subsets:
ports: - addresses:
- protocol: TCP - ip: 192.0.2.42
port: 80 ports:
targetPort: 9377 - port: 9377

Service without a Selector Endpoints object

You can manually map the service to the network address and port where it's running, by adding an
endpoints object manually.
 How Do Kubernetes Services Work?

A Kubernetes service enables communication between nodes, pods, and users of your app, both
internal and external, to the cluster.

• Services point to pods via labels.

• They are not node specific and can point to a pod irrespective of where the pod runs in the
cluster at any given point in time.

• By exposing a service IP address along with the DNS service name, the application can be
accessed by either method as long as the service exists.
 Accessing a Kubernetes Service

The primary ways of accessing Kubernetes service

DNS Environment Variables

● The DNS server monitors the Kubernetes API for new services and creates a set of DNS records for each.

● The kubelet adds a set of environment variables for each active service for every node a pod is running on.
 Types of Kubernetes Services

Kubernetes provides four types of services in order to expose a service onto an external IP address
that's outside the cluster.

ClusterIP NodePort

LoadBalancer ExternalName
 Types of Kubernetes Services

• ClusterIP: Exposes the service within the Kubernetes cluster, default ServiceType

• NodePort: Exposes the service via a static port on each node’s IP. The NodePort
service routes to a ClusterIP service that is automatically created. To access the
service from outside the cluster use NodeIP:nodePort.

• LoadBalancer: Exposes the service externally via a cloud provider’s load balancer.
The external load balancer routes to NodePort and ClusterIP Services that are
automatically created.

• ExternalName: Maps a service to a predefined externalName field by returning a

CNAME record with its value.

• Ingress can also be used to expose the service although it’s not a service type.
 Kubernetes Networking

Kubernetes networking allows Kubernetes components to communicate with each other and
with other applications.

It is primarily concerned with:

● Containers within a pod using networking to communicate via loopback

● Communication between different pods provided by cluster networking

● The service resource that enables you to expose an application running in pods to make it
reachable from outside your cluster

● Services used to publish services only for consumption inside your cluster
 Kubernetes Storage

Kubernetes storage architecture relies on volumes as a central abstraction.

● Kubernetes uses the same storage volume concept that you find when using Docker.

● The Kubernetes volume's lifetime is an explicit lifetime that matches the pod's lifetime. This
means a volume outlives the containers that run in the pod. However, if the pod is removed,
so is the volume.

● Volumes may be persistent or non-persistent, and Kubernetes allows containers to request

storage resources dynamically, using a mechanism called volume claims.
 Kubernetes Configuration

Kubernetes has two types of objects that are used to inject configuration data into a
container when it starts up: Secrets and ConfigMaps.

Secrets ConfigMaps

Used to store and Used to store non-

manage sensitive confidential configuration
information, such as data in key-value pairs
passwords, OAuth
tokens, and ssh keys
 Key Takeaways

Container orchestration is the automation and management

of lifecycle of containers and services.

Kubernetes is an open-source orchestration tool used to

manage containerized applications.

A working Kubernetes deployment is called a cluster and it

contains at least one control plane and one or more worker
nodes.

kubectl is a command-line tool provided by Kubernetes to

manage your cluster.

Kubernetes automates deployment and scales containers

across multiple nodes in Kubernetes clusters.
Lesson-End Project Deploy an App to the Kubernetes Cluster

Project Agenda: To deploy a Node.js application to the Kubernetes cluster.

Description: You have created an application and want to containerize it. For
efficient load balancing and auto-scaling of the containers depending on the
requirement, you decide to deploy your app on a Kubernetes cluster.

Perform the following:

• Create a Node.js application
• Create a Docker image for the application
• Create a Kubernetes deployment using a Yaml file
• Verify the deployment of the app on the Kubernetes cluster