CC Us

Presentation
 Presented To:
Mam Tayyaba
 Presented By:
Shooaib (18251598-005)
Luqman (18251598-012)
Ashar (18251598-045)
 Topic Name:
Kubernetes
Kubernetes
 Introduction:
 Minikube is a “all in one” Kubernetes “cluster”. It

runs all the components of Kubernetes in a single
node, usually a virtual machine, for development
purposes.
 Kubectl is the command line tool to control
Kubernetes clusters, from a control host or your
workstation.
 Kubelet is the agent running on each Kubernetes
node to manage the containers locally based on the
information provided by the control plane.
Service
 Service resource is the one which is used to create a single,

constant point of entry to a group of pods
 Each service resource has an IP address and port that never
changes while the service resource exists
 By using that IP and Port provided by service resource, we can
access our application
Types of Service Resource
 Service resource has many types, few of them are
Cluster IP
Node Port
Load Balancer
External Name
Types of Service
 ClusterIP (default)
 Exposes the Service on an internal IP in the cluster
 This type makes the Service only reachable from within the
cluster
 We can check it by minikube ssh and than clusterIP:port
 NodePort
 Exposes the Service on the same port of each selected Node in the
cluster
 Port range is 30000 to 32767
 Makes a Service accessible from outside the cluster using
<NodeIP>:<NodePort>
Types of Service
 LoadBalancer
 Creates an external load balancer for traffic
 Assigns a fixed, external IP to the Service
 ExternalName
 To create a service that serves as an alias for an external service
 Let’s say your database is on AWS and it has the following URL
test.database.aws.com
 By create externalName you can have let’s say my-db diverted to
test.database.aws.com
Service commands
 my-svc.yaml
 apiVersion: v1
 kind: Service
 metadata:
 name: my-service
 spec:
 ports:
 - port: 8080
 targetPort: 80
 selector:
 app: myapp
 type: LoadBalancer
HEALTH CHECK
 Kubernetes provide use way to check health of you

application.
 One of the main benefits of using Kubernetes it keep our
containers running somewhere in the cluster
 If app container crashes because of bug in your app,
Kubernetes will restart your app container automatically
LIVENESS PROBES
 You can specify a liveness probe for each container in the

pod’s specification
 There are three types of probes
 HTTP GET
 TCP SOCKET
 EXEC Probe
HTTP GET
 HTTP GET
 This type of probe send request on the container’s IP address, a
port and path you specify
 Probe is considered a failure and Container will be automatically
restarted if
 Probe receives error response code
 Container app doesn’t respond at all
TCP SOCKET
 TCP SOCKET
 TCP Socket probe tries to open a TCP connection to the
specified port of the container
 If the connection is established successfully, the probe is
successful
 Otherwise, the container is restarted.
EXEC Probe
 EXEC Probe
 An Exec probe executes some commands you provide inside the
container and checks the command’s exit status code
 If the status code is 0, the probe is successful
 All other codes are considered failures
READINESS PROBES
 Similar to liveness probes, Kubernetes allows you to also

define a readiness probe for your pod
 The readiness probe is invoked periodically and determines
whether the specific pod should receive client requests or not
 When a container’s readiness probe returns success, it’s
signaling that the container is ready to accept requests
Types of readiness probes
 There are three types of readiness probes:

 HTTP GET
 This type of probe send request on the container’s IP address, a
port and path you specify
 Probe is considered a failure and Container will be treated as not
ready and no traffic will get diverted to it
TCP SOCKET
 TCP SOCKET
 TCP Socket probe tries to open a TCP connection to the specified
port of the container
 If the connection is established successfully, container will
marked as ready and it will receive traffic
 Otherwise, Kubernetes will wait and rerun the probe to check the
status again
EXEC Probe
 EXEC Probe
 An Exec probe executes some commands you provide inside the
container and checks the command’s exit status code
 If the status code is 0, the probe is successful
 All other codes are considered failures
VOLUMES
 Volumes in kubernetes can be thought of shared directory for

the containers in a Pod at a Pod level
 Pod level mean the life of that volume is dependent on Pod’s
life, If Pod restarts all the files will be lost
 Volumes aren’t a standalone Kubernetes object and cannot be
created or deleted on their own
Types Of Volumes
 There are many types of volumes

 emptyDir
 configMap , secret , downwardAPI
 persistentVolumeClaim
 gitRepo
 gcePersistentDisk
 awsElasticBlockStore
 azureDisk
Volumes
 To access the container:
 kubectl exec my-pod-with-vol -it -c container-one -- sh
 kubectl exec my-pod-with-vol -it -c container-two -- sh

PERSISTENT VOLUMES
 To solve this issue Kubernetes provides us option of Persistent

Volume
 Persistent Volume add a volume at a cluster level instead pod
level
 Kubernetes Persistent Volumes remains available outside of the
pod lifecycle
Persistent Volume Access
Modes
 Type of accessModes
 ReadWriteOnce
 Only a single node can mount the volume for reading and writing
 ReadOnlyMany
 Multiple nodes can mount the volume for reading
 ReadWriteMany
 Multiple nodes can mount the volume for both reading and writing
 RWO , ROX , and RWX pertain to the number of worker
nodes that can use the volume at the same time, not to the
number of pods!
Persistent Volume Reclaim
Policy
 The lifetime of a Persistent Volume is determined by its
reclaim policy
 Reclaim Policy controls the action the cluster will take when a
pod releases its ownership of the storage
 persistentVolumeReclaimPolicy tag can be used in YAML
configuration file at the time of creating PV
ConfigMap
 ConfigMaps allow you to separate your application

configurations from your application code, which helps keep
your containerized applications portable
 ConfigMaps are useful for storing and sharing non-sensitive,
unencrypted configuration information which you can change
at runtime
SECRETS
 Secrets are also used to pass key/value data to application

dynamically like configMaps
 Secrets are secure objects which stores sensitive data, such as
passwords, OAuth tokens, and SSH keys, in your clusters
 The Secret values are Base64 encoded in Kubernetes
Environmental Variable
 Uptil now we have seen how we can pass environmental

variables to containers using envFrom Tag using configMap
and Secrets
 We also can pass environmental variables hardcoded in pod
specification
DEPLOYMENT
 We have two ways of updating all those pods

 Delete all existing pods first and then start the new ones
 Start new ones and, once they’re up, delete the old ones
 This could be done either by adding all the new pods and then
deleting all the old pods at once
 Sequentially, by adding new pods and removing old ones gradually
KUBERNETES BEST PRACTICES
 Using multi-dimensional instead of single-dimensional labels

 Labels may include things like
-The name of the application
-Version
 Making manageable container images
 Describing each resource through annotations
 Handling application logs

CC Us

Uploaded by

Copyright:

Available Formats

CC Us

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CC Us

Uploaded by

Copyright:

Available Formats

Presentation

 Minikube is a “all in one” Kubernetes “cluster”. It

 Service resource is the one which is used to create a single,

 Service resource has many types, few of them are

 Kubernetes provide use way to check health of you

 You can specify a liveness probe for each container in the

 Similar to liveness probes, Kubernetes allows you to also

 There are three types of readiness probes:

 Volumes in kubernetes can be thought of shared directory for

 There are many types of volumes

 To access the container:

 kubectl exec my-pod-with-vol -it -c container-one -- sh

 kubectl exec my-pod-with-vol -it -c container-two -- sh

 To solve this issue Kubernetes provides us option of Persistent

 ConfigMaps allow you to separate your application

 Secrets are also used to pass key/value data to application

 Uptil now we have seen how we can pass environmental

 We have two ways of updating all those pods

 Using multi-dimensional instead of single-dimensional labels

You might also like