Is an open-source provides a powerful and flexible framework

container orchestration for automating the deployment, scaling,

platform and management of containerized
applications

Originally developed by Google and is now

Initial release in 2014 maintained by the Cloud Native Computing
Foundation (CNCF)
Why ?
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 (Self-healing) Kubernetes offers other benefits and
features:
● Secret and configuration management
● Designed for extensibility: you can add feature to k8s, it is not
monolithic, and these default solutions are optional and pluggable.
● Service discovery and load balancing
● Automated rollouts and rollbacks
What is not
● Does not deploy source code and does not build your application
● Does not provide application-level services, such as middleware (for
example, message buses), data-processing frameworks (for example,
Spark), databases (for example, MySQL), caches, nor cluster storage
systems (for example, Ceph) as built-in services.
● Does not dictate logging, monitoring, or alerting solutions. It provides
some integrations as proof of concept, and mechanisms to collect and
export metrics.
Architecture
 2 types of nodes

Kube-apiserver

the master nodes are responsible for the

the worker nodes main task is to run
tracking of the other nodes, the scheduling
of the containers and other task
the applications containers

ETCD Kubelet

Kube-scheduler Kube-proxy

Controller-manager Container runtime engine

Master node Worker node

Kube-apiserver
Is the entry-point to k8s, it’s the components that manages all other components
and based on the requests that it receives can invoke the write components.

When we run a command using kubectl, it interacts with the kube-apiserver:

● First the kube-apiserver authenticates the request

● Then it interacts with the etcd to get the data and send the response
● The kubectl isn’t required because we can directly send a post request to the
API
Kube-apiserver
Example of a typical workflow: Pod creation
1. Kube-apiserver authenticates the request
2. Kube-apiserver interacts with the etcd to save the Pod details
3. Kube-scheduler that constantly checks the kube-apiserver finds that a new
Pod was added but it’s not yet associated to any node, it identifies the right
node to put the Pod on it and communicate this information to the
Kube-apiserver
4. The kube-apiserver interacts with the Kubelet to inform it
5. The Kubelet instracts the container runtime to start the Pod
6. Once done the Kublet reports back to the Kube-apiserver
7. The Kube-apiserver interacts with the etcd to update the Pod information
ETCD
● A key-value data store, It stores informations about nodes, Pods, configs,
Secrets, Accounts, Roles, Bindings, and other components.
● Every change to components is stored in the etcd
● For high-availability we may have multiple master nodes in the cluster and
thus multiple etcd instances, for this we must make sure that all instances are
able to communicate with each other
Kube-Scheduler
It decides which pod goes to which node but it does not deploy it, this is the job of
the kubelet.

In the process of finding the best node for a pod the kube-scheduler goes through
2 phases:

1. Filter-out unsuitable nodes

2. It ranks the node to find the best fit
Controller-Manager
By definition a controller is a process that continuously monitors the state of various
components within the system and works toward bringing the system to the desired
state.

this component itself is made of different sub-components each responsible for the
control and management of a specific part of k8s, example:
● Node-controller:
○ responsible for onboarding new nodes to the cluster
○ Handling situations where nodes became unavailable
● Replication-controller:
○ Makes sure that the desired number of replication is available
Container runtime engine
It’s what containers use to run. This component can also be installed on the
master in case we want to run some of the master node controlleplane
components as containers. K8s can use Docker container but also other
containers:
● At first k8s was built to manage docker containers
● k8s introduced CRI (Container Runtime Interface) a layer of abstraction that
allowed any container vendor to use k8s as long a it respects the OCI(Open
Container Initiative)
● docker is made of a set of tools one of them is ContainerD which is a
container runtime developed by docker following the OCI standard.
Kubelet
this component is installed on each worker node and it’s responsibilities include:

● Interacting with the master node first to join the cluster

● Receiving information about the containers that needs to be loaded on the
node
● Reporting back to the master about the status of the node and the containers
Kube-proxy
is the component that insures communication between the different Pods on
different nodes within a cluster:
● In a k8s cluster every Pod can reach every other pod and this is made
possible by deploying a Pod networking solution to the cluster. This network
expands through all networks in the cluster
● Kube-proxy is a process that runs on each node in the cluster
● Its role is to look for new services and each time a new service is created it
creates the appropriate roles to forward traffic from those services to the
back-end pods
Different objects management techniques
1. Imperative Commands: the most basic way, managing objects directly using
commands, example of creating a Pod: kubectl run nginx --image=nginx
2. Imperative Object Configuration: this technique uses a config file for the
object but it’s considered imperative because the action to be performed is
specific, example:
kubectl create -f nginx.yaml
kubectl delete -f nginx.yaml
kubectl replace -f nginx.yaml
1. Declarative Object Configuration: similar to imperative Object Configuration
it uses a file but instead of a specific action it leaves this step to kubectl to
compare the changes in the file and decide on what are the best action to
take. Example:
kubectl apply -f nginx.yaml
Objects
Pod
Pods are the smallest deployable unit in kubernetes, it’s also considered the
smallest building block of K8S:
● A Pod contains 1 or many containers
● All containers within a pod share the same IP@, shared disk space ,and they
run on the same node where the Pod is deployed
● Containers within the same pod can refer to each other as localhost since
they share the same ressources
● Pods are often not managed directly. Instead, you typically create higher-level
abstractions like Deployments or StatefulSets, which manage the lifecycle of
the Pods and ensure that a desired number of replicas are running at all
times.
Kubectl get pods
Kubectl get pod
Kubectl get po
Kubectl get pods -o wide //to display additional data including the nodes on which the pods are deployed
Kubectl get pods --show-labels//to display the labels
Kubectl get pods -l [key]=[value] //to filter by label example of multiple labels env=dev,test

Kubectl run [POD_NAME] --image [IMAGE_NAME] --dry-run=client -o yaml > [FILE].yaml

● --dry-run: doesn’t create a pod it just simulates the command
● -o yaml: formats the output to yaml
● > [FILE].yaml: stores the generated pod config in a file
● You can use this command to generate a pod config file that can later be used to create a pod

Kubectl -n [NAMESPACE] run [POD_NAME] --image [IMAGE_NAME] //-n to specify the namespace
Kubectl run [POD_NAME] --image [IMAGE_NAME] -l [KEY]=[VALUE] //-l specify labels
Kubectl run [POD_NAME] --image [IMAGE_NAME] --port=[PORT] //--port to expose the container
Kubectl run [POD_NAME] --image [IMAGE_NAME] --expose//--expose to create pod and service from the
same command
//edit a pod config
Kubectl edit pod [POD_NAME]
● This command changes the config file directly connected to the pod(under /etcd) and changes are live
while kubectl apply changes to the file from which we created the pod

//delete pod
Kubectl delete pod [POD_NAME]
Kubectl delete pod --all
Kubectl delete pod [POD_NAME] --grace-period=0 --force //delete the pod immediately
Replication controller & ReplicatSet
Replication controller is the older technology that was replaced by ReplicaSet
which is the new recommended way to setup replications.
The yaml definition files of both object are similar, however the ReplicaSet require
one additional field which is selector the reason we need a selector is that Replicat
set can handle Pods that were created before it and the way to identify them is
using the selector, example:
● If we have a running Pod with label env=dev
● We can create a ReplicaSet with selector: env=dev and replicas: 3
● This ResplicaSet will start 2 new Pod and include the old pod that we have as
one of the pod that it’s managing
//list all
Kubectl get rs

//show replicaset description

kubectl describe replicasets.apps [RS_NAME]
kubectl describe replicasets.apps [RS_NAME] | grep -i image ://you can use this option to filter for specific attributes
within the description, here we took the case of the image

//delete rs
Kubectl delete rs [RS_NAME]
Kubectl delete rs --all

//scale rs
kubectl scale rs new-replica-set --replicas=N
Deployment
Deployment is similar to replicaSet in the way that it provide multiple replication of the pod and
manages them to insure that the desired state is always kept. In fact the Deployment itself
creates a replicaSet to manage the Pods, so why do we have it ?
Deployment provide a higher abstraction level and more features to manage the replications,
some of the features include:
● Rolling Updates and Rollbacks: While you can declare the desired state in both
Deployments and ReplicaSets, Deployments are explicitly designed to handle rolling
updates and rollbacks in a more automated and controlled manner. When you update a
Deployment's image or configuration, it ensures a smooth transition from the old version to
the new version with no downtime and the ability to roll back if necessary.
● Revision History: Deployments maintain a revision history of all changes, making it easier to
track and manage different versions of your application. ReplicaSets don't provide this
built-in revision history.
Daemonset
Daemonset is similar to ReplicaSet, However it ensures that only one Pod is
deployed on each node.
Use-case for Daemonsets include:
● Monitoring
● Networking
Static Pods
Since the Kubelet has all it needs to run Pods on its own. K8s introduced the
concept of Static-Pods.
● The creation of these Pods is not order by the API-server however it has a
local directory where any Pod definition file in it gets created directly as a Pod:
The Kubelet periodically checks this directory to know if there are new Pods
to create/Update or Pods to delete
● These pods start when the node starts
Static Pods
● The Kubelet informs the master node about the Static Pods this is why when
we list pods we find Static Pods too. However even though the master node
knows about it all actions on the pod through the management Commands
will not work. Only changes the the pod definition file work
● Main use cas for Static Pod are K8s components themselves
● How to know if a pod is a static pod: [POD_NAME]-[NODE_NAME]
● Path to these file on the controlplane is generally: /etc/kubernetes/manifests
Services
Thanks to the kube-proxy network, every pod can reach each other pod in the cluster however
there are some limitation to this solution mainly that whenever a pod is re-scheduled its IP@
changes more benefits of using services include:
● Scalability & load balancing: As your application grows and you need to scale your pods
horizontally (add more instances), Kubernetes Services make it easier to manage the
communication and load balancing for the increasing number of pods.
● Service Discovery: Services simplify service discovery for your applications. They allow
you to find and communicate with other components of your application without needing to
know specific pod IP addresses or hostnames.
● Abstraction: Services provide a level of abstraction between the pods that implement the
service and the consumers of the service. This abstraction allows you to change the
underlying pods without affecting the consumers.
● Network Policies: Kubernetes Network Policies can be applied to Services to control the
network traffic and access between different parts of your application.
Services
K8s service can be grouped into 3 categories:
● ClusterIP (Cluster-Internal IP):
○ This is the default type of service.
○ It exposes the service on an internal IP address within the cluster.
○ It makes the service reachable only from within the cluster.
○ This is often used for communication between services within the cluster.
Services
● NodePort:
○ This type of service exposes the service on a static port on each node's IP address.
○ It allows external traffic to reach the service by targeting any node's IP address on the
specified port.
○ NodePort services are commonly used for exposing applications externally, but they may
require additional load balancing for high availability.
Services
● NodePort:
Services
● LoadBalancer:
○ This type of service is used in cloud environments with load balancer support (e.g., AWS,
GCP, Azure).
○ It provisions an external load balancer to distribute incoming traffic across the pods in the
service.
○ It's a good choice when you need to expose a service to the internet and require automatic
load balancing.
○ If this option is used on a non-supported cloud environment the service created will be of type
nodePort
//list services
Kubectl get svc

//create a service
kubectl expose deployment [NAME] --type=NodePort --name=[NAME] --port=[PORT] --dry-run=client -o yaml >
[FILE].yaml
● --type=NodePort: by default it’s ClusterIP
Namespaces
● In k8s, namespaces provides a mechanism for isolating groups of resources
within a single cluster.
● Names of resources need to be unique within a namespace, but not across
namespaces.
● Namespace-based scoping is applicable only for namespaced objects (e.g.
Deployments, Services, etc) and not for cluster-wide objects (e.g.
StorageClass, Nodes, PersistentVolumes, etc).
● Namespaces are a way to divide cluster resources (via resource quota).
○ Exemple : Error from server (Forbidden): ResourceQuota memory-quota exceeded: requested: limits.memory=2Gi, used:
limits.memory=3.5Gi, limited: limits.memory=4Gi
Namespaces
Scheduling
Manual scheduling
By setting the attribute ‘nodeName’ at creation-time, once a pod is created we
can’t change this value.
Node selector
By labeling the nodes and adding the attribute node selector to the object
definition file we can specify where the pod should get deployed.
A limitation of this technique is that we can only add 1 nodeSelector
Taints and tolerations
● They are not related to security.
● They are used to decide which pods can be scheduled on which node
● If a pod has Toleration to a Taint that doesn’t meant it should be deployed on
that node, it just has the permission.
● Taint effects : are the way we should deal with pod that do not tolerate the
taint. There are 3 types:
○ NoSchedule: the scheduler will not place pods on the node
○ PreferedNoSchedule: the scheduler will try not place those pods on the node, but this is not
guaranteed
○ NoExecute: the scheduler will not place those pods on the node and existing pods that do not
tolerate the taint will be evicted The master node in k8s has a default taint that prevents pod
from being deployed on it.
Example :
● Taints :
○ kubectl taint nodes node1 priority=high:NoSchedule

● Tolerations :
○ tolerations:
○ - key: "priority"
○ operator: "Equal"
○ value: "high"
○ effect: "NoSchedule"
Node Affinity
● Node Affinity: the main aim of this feature is to ensure that the pods are
deployed on a particular set of nodes(resolving the limitations of Node
Selector)
● Types:
○ requiredduringschedulingignoredduringexecution
○ preferredduringschedulingignoredduringexecution
○ requiredduringschedulingrequiredduringexecution(Planned)
● Node affinity weight:
○ You can specify a weight between 1 and 100 for each instance of the
preferredDuringSchedulingIgnoredDuringExecution affinity type. The node with the highest
sum win.