Kubernetes Architecture :

Kubernetes architecture can be understood as a series of steps, from the initial client request
to the final treatment of that request. Here's a simplified version of that process:

1. Client Request: A client, such as a user or another system, makes a request to the
Kubernetes API server.
2. API Server: The API server receives the request and acts as the frontend for the
cluster. It validates and persists the request in the etcd database.
3. etcd: etcd is a distributed key-value store that holds the cluster's configuration data. It
ensures data consistency and reliability by replicating data across multiple nodes.
4. Controller Manager: The controller manager watches the state of the cluster and
makes changes to ensure the desired state is maintained. For example, if a Pod crashes,
the Replication Controller component of the Controller Manager creates a new Pod to
replace it.
5. Scheduler: The scheduler assigns Pods to Nodes, taking into account the available
resources and constraints.
6. Kubelet: The kubelet is a component running on each Node that communicates with
the API server to ensure the containers are running as desired.
7. Container Engine: The container engine, such as Docker, runs containers on the Node
and communicates with the kubelet to ensure the desired state is maintained.
8. Final Treatment: Finally, the request is treated as desired, with the necessary resources
and configurations being provided by the Kubernetes cluster.
Authorization, authentication, and admission control are important concepts in Kubernetes
that ensure the security and reliability of the cluster.

1. Authorization: The process of granting or denying access to specific resources based

on the identity of a user or system. In Kubernetes, authorization can be based on the
user's role and permissions within the cluster.
2. Authentication: The process of verifying the identity of a user or system. In
Kubernetes, authentication is typically achieved through the use of a token or
certificate.
3. Mutating Admission Controller: A mutating admission controller is a component in
Kubernetes that can modify incoming API requests before they are processed. This
can be used to enforce specific policies, such as automatically adding labels to
resources.
4. Schema Validation: The process of validating the structure and content of an API
request to ensure it meets certain standards. In Kubernetes, schema validation helps
ensure that incoming requests conform to the API's expected format and can be
processed correctly.
5. Validation Admission Controller: A validation admission controller is a component in
Kubernetes that checks incoming API requests to ensure they meet specific
requirements. This can be used to validate the format of requests or enforce specific
policies, such as ensuring that a resource has a certain label.

Admission control is a critical part of the Kubernetes architecture, as it helps ensure the
security and reliability of the cluster by enforcing specific policies and standards on incoming
API requests.

An example of a Mutating Admission Controller in Kubernetes is the pod-preset admission

controller. This admission controller can be used to automatically add environment variables,
volumes, or other settings to Pods as they are created.

For example, consider a scenario where all Pods in a cluster need to have access to a specific
secret. A pod-preset admission controller can be used to automatically add a volume that
references the secret to every Pod as it is created, ensuring that the secret is available to all
Pods without the need for manual intervention.

Here's an example of how a pod-preset could be created to add an environment variable to all
Pods:

yaml
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: add-env-var
spec:
selector:
matchLabels:
app: myapp
env:
- name: MY_ENV_VAR
value: "example value"
In this example, the selector field is used to specify which Pods the pod-preset should apply
to. In this case, it applies to all Pods with the label app: myapp. The env field is used to
specify the environment variables that should be added to the Pods.

Once this pod-preset is created, it will automatically add the environment variable
MY_ENV_VAR to all Pods with the label app: myapp as they are created, without the need for
manual intervention.

Network Add-ons
In Kubernetes, network add-ons refer to additional components that can be added to a cluster
to enhance its networking capabilities. Some common examples of network add-ons include:

1. Service meshes: These are popular add-ons that provide features such as service
discovery, load balancing, traffic management, and security.
2. Ingress controllers: An ingress controller is a component that manages incoming
traffic to a Kubernetes cluster.
3. Network policies: Network policies allow administrators to define rules that govern
network traffic within a cluster.
4. Load balancers: Load balancers distribute traffic across multiple replicas of a service
to improve performance and reliability.

These network add-ons work together to provide a robust, secure, and highly available
network infrastructure for running applications in a Kubernetes cluster. The choice of network
add-ons will depend on the specific needs of the cluster and the applications running on it.

Common network add-ons

In Kubernetes, network add-ons refer to additional components that can be added to a cluster
to enhance its networking capabilities. Some common network add-ons include:

1. Calico: Calico is a popular open-source networking and network security solution for
containers, virtual machines, and bare metal workloads.
2. Flannel: Flannel is a simple, easy-to-use network fabric that provides network
connectivity for containers.
3. Weave Net: Weave Net is a Docker-compatible network that provides secure and
scalable networking for containers.
4. Cilium: Cilium is an open-source network security solution for containers and
microservices that provides network security, load balancing, and service discovery.
5. Canal: Canal is a networking solution that combines the simplicity of Flannel with the
security of Calico.
6. Istio: Istio is an open-source service mesh that provides features such as traffic
management, service discovery, and security for microservices.
7. Kubernetes Network Policy: Kubernetes Network Policy is a built-in network policy
solution for Kubernetes that provides network segmentation and network access
control.
These network add-ons can be used to provide a robust, secure, and highly available network
infrastructure for running applications in a Kubernetes cluster. The choice of network add-ons
will depend on the specific needs of the cluster and the applications running on it.

Calico
Yes, Calico is an open-source networking and network security solution for containers, virtual
machines, and bare metal workloads. Some of the key features of Calico include:

1. Scalable Networking: Calico allows administrators to easily scale their network as

their cluster grows, with no limit on the number of nodes or pods.
2. Network security: Calico provides a rich set of network security policies, including
network segmentation, network access control, and network traffic management.
3. High Availability: Calico provides high availability for network connectivity, ensuring
that applications remain accessible even if a node fails.
4. Performance: Calico has been optimized for high performance, making it well-suited
for large-scale production deployments.
5. Flexibility: Calico supports a variety of platforms and deployment models, including
on-premises, public cloud, and hybrid cloud environments.
6. Integration with Kubernetes: Calico integrates seamlessly with Kubernetes, providing
a networking solution that is easy to deploy and manage.
7. Easy Management: Calico provides a simple, declarative syntax for defining network
policies, making it easy for administrators to manage their network.

Overall, Calico provides a robust, scalable, and secure networking solution for containers,
virtual machines, and bare metal workloads, making it an attractive option for many
organizations.

Understanding cluster Initialization

When you run the kubeadm init command, several phases are executed to initialize a
Kubernetes control plane. Here is a general outline of these phases:

1. Preflight Checks: In this phase, kubeadm performs various checks to ensure that the
environment is suitable for initializing a cluster. These checks include verifying that
required software is installed, that the required ports are open, and that there
are no conflicting resources in the cluster.
2. Certificate Generation: In this phase, kubeadm generates the necessary certificates
and keys to secure communication between the control plane components and between
the control plane and worker nodes.
3. Configuration Generation: In this phase, kubeadm generates a configuration file that
contains the settings needed to initialize the control plane components. This
configuration file can be customized to meet specific needs, such as specifying the
network plugin to use.
 4. Control Plane Component Startup: In this phase, kubeadm starts the control plane
components, including the API server, etcd, controller manager, and scheduler. These
components communicate with each other to manage the state of the cluster.
5. Token Generation: In this phase, kubeadm generates a join token that can be used by
worker nodes to join the cluster.
6. Completion: In this phase, kubeadm displays the join command that can be used by
worker nodes to join the cluster. This command includes the join token generated in
the previous phase.

This is a high-level overview of the phases executed when you run the kubeadm init
command. The exact details of each phase can vary depending on the specific needs of the
cluster and the environment it is running in.

Client group context

En Kubernetes, un contexte de groupe client (en anglais "client group context") fait référence
à un ensemble de configurations client qui permettent à un utilisateur de se connecter à
différents clusters Kubernetes et de basculer entre eux.

Un contexte de groupe client dans Kubernetes est utilisé pour définir un ensemble de clusters
et leurs configurations associées, telles que l'adresse du serveur API, les informations
d'authentification, etc. Les contextes de groupe client sont généralement utilisés pour gérer
plusieurs environnements de Kubernetes, tels que les environnements de développement, de
test et de production, chacun ayant ses propres clusters et configurations.

Pour basculer entre différents contextes de groupe client, les utilisateurs peuvent utiliser l'outil
en ligne de commande "kubectl" avec la commande "kubectl config use-context". Cela permet
à un utilisateur de sélectionner un contexte de groupe client spécifique pour l'interaction avec
le cluster Kubernetes correspondant.

Arguments of kubeadm init

Kubeadm is a command-line tool that is used to set up a Kubernetes cluster. The kubeadm
init command is used to initialize a new Kubernetes control plane, and it has several
arguments that can be used to customize the installation. Some of the most common
arguments of the kubeadm init command include:

1. --pod-network-cidr: Specifies the CIDR block for the pod network. This is the
network that the pods will use to communicate with each other. The default value is
"10.244.0.0/16", but this can be changed to match the network of your choice.
2. --service-cidr: Specifies the CIDR block for the Kubernetes service network. This
is the network that the Kubernetes control plane uses to communicate with the pods.
The default value is "10.96.0.0/12", but this can be changed to match the network of
your choice.
 3. --apiserver-advertise-address: Specifies the IP address or DNS name that the
Kubernetes API server will advertise to the other nodes in the cluster. If this option is
not specified, Kubeadm will attempt to auto-detect the IP address.
4. --control-plane-endpoint: Specifies the endpoint for the Kubernetes control
plane. This is used to create a load balancer or a DNS entry that points to the
Kubernetes control plane. If this option is not specified, Kubeadm will use the IP
address of the current node as the endpoint.
5. --upload-certs: Specifies whether to upload the control plane certificates to a
Kubernetes secret. This is required if you want to join additional control plane nodes
to the cluster.
6. --ignore-preflight-errors: Specifies a list of pre-flight checks that can be
ignored. This can be useful if you are setting up a cluster in an environment with non-
standard configurations.
7. --experimental-upload-certs: This is an experimental option that can be used to
upload control plane certificates to an external location instead of to a Kubernetes
secret.

These are just a few examples of the arguments that can be used with the kubeadm init
command. For a complete list of options and their descriptions, you can run the command
kubeadm init --help.

Adding Nodes to the cluster

To add worker nodes to a Kubernetes cluster created with kubeadm, you need to perform the
following steps:

1. Install Docker and Kubernetes on the new worker node(s) as per the instructions for
your operating system and version.
2. On the master node, run the command kubeadm token create --print-join-
command to generate a command that will allow the new node to join the cluster. This
command includes a unique token that is used for authentication.
3. Copy the output of the kubeadm token create command from the master node to the
new worker node(s).
4. On each worker node, run the command that was copied from the master node to join
the cluster. For example:

ruby
4. sudo kubeadm join <master-node-ip>:<master-node-port> --token <token>
--discovery-token-ca-cert-hash <hash>
5. Replace <master-node-ip> and <master-node-port> with the IP address and port
of the master node, <token> with the token generated by kubeadm token create,
and <hash> with the hash of the CA certificate. The hash can be obtained from the --
discovery-token-ca-cert-hash option of the kubeadm init command on the
master node.
6. Once the join command has been executed on the new worker node, return to the
master node and run the command kubectl get nodes to confirm that the new node
has joined the cluster.
7. Repeat steps 2 to 5 for each new worker node that needs to be added to the cluster.
Note that the kubeadm token command generates a token that is valid for a limited time. If
the token expires before you have added all the nodes to the cluster, you can generate a new
token with the same command on the master node. Additionally, you can use the kubeadm
reset command to remove a node from the cluster if necessary.

Kubernetes Client
In Kubernetes, the client is a command-line tool that provides a way to interact with a
Kubernetes cluster from the command line. The Kubernetes client, commonly known as
kubectl, is a powerful tool that can be used to deploy applications, manage clusters, and
troubleshoot issues.

The Kubernetes client communicates with the Kubernetes API server to perform operations
on the cluster. The client sends HTTP requests to the API server, which then performs the
requested action and returns the result. The Kubernetes API server is the primary way to
interact with the Kubernetes control plane, which manages the state of the cluster.

kubectl has many commands that can be used to manage different aspects of a Kubernetes
cluster. Here are some of the most commonly used commands:

• kubectl create: Creates a new object in the cluster, such as a deployment or a

service.
• kubectl get: Retrieves information about one or more objects in the cluster, such as
pods or nodes.
• kubectl describe: Provides detailed information about an object, such as the logs
for a pod or the configuration for a service.
• kubectl delete: Deletes one or more objects from the cluster.
• kubectl apply: Applies changes to an object in the cluster, such as updating the
configuration of a deployment.
• kubectl logs: Displays the logs for a specific pod.
• kubectl exec: Runs a command inside a running container in a pod.
• kubectl port-forward: Forwards a port from a local machine to a specific pod in
the cluster.
• kubectl scale: Increases or decreases the number of replicas in a deployment.

In addition to these basic commands, kubectl also provides many options and flags that can
be used to further customize the behavior of the client.

The Kubernetes client is an essential tool for anyone working with Kubernetes, whether you
are a developer deploying applications or an administrator managing a cluster. Understanding
the kubectl command-line tool is an important part of working with Kubernetes effectively.
 Deployment in Kubernetes
Deployment manage the life cycle of an application:

1. Declarative configuration: Deployments in Kubernetes allow you to define the

desired state of your application in a declarative way. You can specify the number of
replicas you want, the container image to use, the resources to allocate, and other
configuration options. Kubernetes will ensure that the desired state is always met, and
will automatically adjust the number of replicas based on demand.
2. Rolling updates: Deployments in Kubernetes support rolling updates, which allows
you to update your application with zero downtime. When you update the
deployment, Kubernetes will create new replicas with the updated version, gradually
replace the old replicas with the new ones, and ensure that a minimum number of
replicas are always available during the update.
3. Rollbacks: In case of issues or failures during an update, you can easily roll back to
the previous version of your application. Kubernetes will automatically roll back the
deployment to the previous version, and ensure that the application is running
correctly.
4. Scaling: Deployments in Kubernetes make it easy to scale your application up or
down based on demand. You can increase or decrease the number of replicas, and
Kubernetes will automatically adjust the deployment to meet the new desired state.
5. Self-healing: Kubernetes provides built-in self-healing capabilities that ensure your
application is always available. If a pod fails or becomes unresponsive, Kubernetes
will automatically restart it or create a new replica to replace it.
6. Resource optimization: Deployments in Kubernetes allow you to specify resource
requirements and limits for your application, which helps optimize resource usage and
prevent resource contention. Kubernetes will ensure that the application is only
scheduled on nodes that have the required resources available.

In Kubernetes, a deployment is an object that provides declarative updates for Pods and
ReplicaSets. It is used to manage the deployment of a specific application version in a
cluster.

A deployment defines the desired state for the application that it manages, including the
number of replicas to be created, the container image to be used, and other configuration
options. When a deployment is created or updated, Kubernetes uses the desired state specified
in the deployment to create or update the corresponding ReplicaSet and Pods.

The deployment object supports rolling updates and rollbacks, which allows for safe and
controlled updates to the application without downtime or service disruption. Rolling updates
replace the old replicas with new ones gradually, ensuring that a minimum number of replicas
are available during the process. Rollbacks allow for quick and easy reversion to a previous
application version in case of issues or failures.

In summary, a Kubernetes deployment provides a simple and scalable way to manage the
deployment and update of containerized applications in a cluster, while ensuring high
availability and reliability.
Example of a deployment in Kubernetes:

Suppose we have a simple web application that runs in a container and exposes a service on
port 8080. We want to deploy this application in our Kubernetes cluster, and ensure that three
replicas are always running.

We can create a deployment using a YAML file, like the following:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: myregistry/webapp:1.0
ports:
- containerPort: 8080

This YAML file creates a new deployment with the name webapp-deployment. The spec
section of the deployment specifies that we want three replicas of our web application
running, and the selector section defines a label selector that will be used to identify the
pods managed by this deployment. The template section specifies the pod template that will
be used to create the replicas.

The template section contains a metadata section with labels that match the selector
section. The spec section contains a container definition for our web application, specifying
the container image to use and the port that it exposes.

We can create this deployment in our Kubernetes cluster by running the following command:

kubectl apply -f webapp-deployment.yaml

Once the deployment is created, Kubernetes will automatically create three replicas of our
web application, and ensure that they are running and available. If we need to update the
application, we can simply edit the deployment YAML file to specify a new container image
or other configuration changes, and re-apply the changes using the kubectl apply command.
Kubernetes will automatically roll out the changes to the running replicas, ensuring that there
is no downtime or service disruption.
 Replicas
Yes, in a Kubernetes deployment, the replicas field specifies the desired number of replicas
(or copies) of the pod template that should be created and managed by the deployment. Each
replica is a separate and independent pod with the same configuration.

When you create a deployment, Kubernetes creates a ReplicaSet, which is responsible for
ensuring that the desired number of replicas are always running. If a replica fails or becomes
unavailable, the ReplicaSet will automatically create a new replica to replace it.

The replicas field in the deployment YAML file determines the number of replicas to
create, and you can adjust this number at any time by editing the YAML file and running
kubectl apply. For example, if you want to scale up the number of replicas to 5, you can
change the value of replicas to 5 in the YAML file, save the file, and then run kubectl
apply to update the deployment.

In summary, the replicas field in a Kubernetes deployment specifies the desired number of
pods (replicas) that should be created and managed by the deployment.

Replicas And ReplicaSets

Yes, there is a difference between replicas and ReplicaSets in Kubernetes:

• Purpose: The primary purpose of replicas is to define the desired number of

identical copies of a pod that should be running in the cluster. The replicas field is
typically used in higher-level abstractions like Deployments or StatefulSets to specify
the desired number of replicas.
• Object type: replicas is a field in a Kubernetes object (e.g. Deployment), whereas
ReplicaSet is a Kubernetes resource that manages a set of identical replicas of a
pod.
• Pod management: ReplicaSets manage the lifecycle of pods and ensure that the
specified number of replicas are running at all times. If a pod fails, the ReplicaSet will
automatically create a new pod to replace it, ensuring that the desired number of
replicas is maintained.
• Selector: ReplicaSets use a selector field to identify the pods that they manage. The
selector is used to match the labels in the pod template with the labels of running
pods. If the labels match, the ReplicaSet assumes that the pod is part of its set and
manages it accordingly.

In summary, the replicas field is used to define the desired number of identical replicas
of a pod, while ReplicaSets are Kubernetes resources that manage a set of identical replicas
of a pod and ensure that the specified number of replicas are always running.
ReplicaSets use a selector field to match pods with the set of replicas that they manage.
 Declarative and Imperative Method Deployment
Declarative management is a way of defining the desired state of a resource and letting
Kubernetes handle the details of how to achieve that state, while imperative management
involves directly modifying resources by issuing commands to the Kubernetes API server.

Imperative method:

To create a deployment imperatively, you can use the kubectl create command as follows:

kubectl create deployment nginx --image=nginx:latest --replicas=3

This command creates a new deployment named nginx with the nginx:latest container
image and 3 replicas. This is an example of an imperative command because we are directly
instructing Kubernetes to create the deployment with specific parameters.

Declarative method:

To create a deployment declaratively, you can create a YAML file that describes the desired
state of the deployment and use the kubectl apply command to apply the changes to the
cluster.

Here is an example YAML file for a deployment that uses the nginx:latest image and has 3
replicas:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest

To create this deployment declaratively, save the YAML file as nginx-deployment.yaml,

and run the following command:

kubectl apply -f nginx-deployment.yaml

This command creates or updates the deployment to match the desired state described in the
YAML file. This is an example of a declarative approach because we are describing the
desired state of the deployment rather than directly instructing Kubernetes to create it.

Deployment object And Deployment controller

In Kubernetes, there are two similar-sounding concepts: Deployment object and Deployment
controller. Here are the differences between the two:

Deployment object: A Deployment object is a high-level Kubernetes resource that provides

declarative updates for Pods and ReplicaSets. A Deployment object defines a desired state for
a set of replicas of a specific application. When a deployment is created, Kubernetes creates a
ReplicaSet and manages the creation, scaling, and deletion of Pods based on the specified
configuration. Deployment objects are useful for managing application upgrades, rollbacks,
and scaling.

In other words, a Deployment object is a Kubernetes resource that provides a declarative way
to manage a set of replicas of a specific application.

Deployment controller: A Deployment controller is a part of the Kubernetes control plane

responsible for managing the Deployment object. It watches the desired state of the
Deployment object and takes actions to ensure that the actual state of the system
matches the desired state. The Deployment controller manages the ReplicaSets and Pods
that are created as part of the deployment, and ensures that the deployment strategy
(e.g., rolling updates or blue-green deployments) is followed correctly.

In other words, a Deployment controller is a component of the Kubernetes control plane that
is responsible for managing the lifecycle of a Deployment object.

In summary, a Deployment object is a Kubernetes resource that provides a declarative way to

manage a set of replicas of a specific application, while a Deployment controller is a
component of the Kubernetes control plane that manages the lifecycle of the Deployment
object.

Create Deployment
example with an explanation of the kubectl create deployment command:

kubectl create deployment myfirstapp --image=nginx --replicas=3

This command creates a deployment named myfirstapp with the nginx image and 3
replicas.

• kubectl is the command-line tool used to interact with a Kubernetes cluster.

• create is the command to create a new resource.
• deployment is the type of resource to create. A deployment manages a set of replicas
of a pod template.
 • myfirstapp is the name of the deployment you're creating. You can choose any name
you want.
• --image=nginx specifies the container image to use for the pod template. In this case,
we're using the official nginx image from Docker Hub.
• --replicas=3 specifies the desired number of replicas for the deployment. In this
case, we're creating 3 replicas.

This command will create a deployment named myfirstapp and start 3 replicas of the nginx
container image. The replicas will be managed by the deployment and if any of the replicas
fail or become unavailable, the deployment will automatically create new replicas to maintain
the desired number of replicas.

DaemonSet
Note: DaemonSet don’t use ReplicaSet because he runs one
pod instance in every node in the cluster
A DaemonSet is a Kubernetes object that ensures that a specific pod is running on all
nodes in a cluster. DaemonSets are often used for system-level daemons or services that
need to run on every node in the cluster, such as log collectors, monitoring agents, or
network proxies.

A DaemonSet in Kubernetes is a resource that ensures a single pod of a specified

configuration is running on each node in a cluster. Here's an example of how you can create a
DaemonSet in Kubernetes:

Let's say you want to run a logging agent on each node in your cluster. You can create a
DaemonSet with a YAML configuration file that looks like this:

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: logging-agent
spec:
selector:
matchLabels:
app: logging-agent
template:
metadata:
labels:
app: logging-agent
spec:
containers:
- name: logging-agent
image: my-logging-agent-image:latest

In this example, the YAML configuration file defines a DaemonSet named "logging-agent".
The selector field specifies that the DaemonSet should manage pods with the label app:
logging-agent. The template field defines the pod template for the DaemonSet, which
includes a single container with the name logging-agent and the image my-logging-
agent-image:latest.
When you apply this configuration to your Kubernetes cluster, the DaemonSet controller will
ensure that a single pod of the specified configuration is running on each node in the cluster.
If a new node is added to the cluster, the controller will automatically create a new pod on that
node. Similarly, if a node is removed from the cluster, the controller will automatically
terminate the corresponding pod.

In this way, DaemonSets can be used to ensure that a specific task or service is running on
each node in a cluster, even as the cluster scales up or down.

DaemonSet : ds command
The kubectl get ds command is used to list all the DaemonSets running in the current
Kubernetes context. When you run this command, Kubernetes will return a list of all the
DaemonSets, along with some basic information about each one, such as their name,
namespace, number of desired and current instances, and selectors.

Here's an example of how to use the kubectl get ds command:

$ kubectl get ds

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE

logging-agent 3 3 3 3 3 <none> 1d

In this example, we can see that there is one DaemonSet running named logging-agent. The
DESIRED, CURRENT, and READY columns show that there are currently 3 instances of this
DaemonSet running, and all of them are ready. The UP-TO-DATE and AVAILABLE columns
indicate that all the pods are up-to-date and available.

The NODE SELECTOR column shows that no specific node selector was used when creating this
DaemonSet, and the AGE column shows how long the DaemonSet has been running.

This command can be very useful for getting a quick overview of all the DaemonSets running
in your cluster, and for checking the status of individual DaemonSets.

The kubectl get ds -A command is used to list all the DaemonSets running in all
namespaces in the current Kubernetes context. When you run this command with the -A
option, Kubernetes will return a list of all the DaemonSets running in all namespaces, along
with some basic information about each one, such as their name, namespace, number of
desired and current instances, and selectors.
 Create DaemonSets:
• student@control:~$ kubectl create deploy mydaemon --image=nginx --dry-run=client -o
yaml > mydaemon.yaml

• student@control:~$ vim mydaemon.yaml

• student@control:~$ kubectl apply -f mydaemon.yaml

kubectl create deploy mydaemon --image=nginx --dry-run=client -o yaml > mydaemon.yaml

The command you provided will create a Kubernetes deployment object named "mydaemon"
using the "nginx" Docker image, but instead of actually creating the deployment, it will
output the YAML definition of the deployment to the file "mydaemon.yaml" in the current
directory. The "--dry-run=client" option specifies that the command should not actually create
the deployment, but instead simulate the creation and output the result. The "-o yaml" option
specifies that the output format should be YAML.

Here's a breakdown of the command:

• "kubectl" is the command-line interface for managing Kubernetes clusters.

• "create deploy" specifies that a new deployment object should be created.
• "mydaemon" is the name you have chosen for the deployment.
• "--image=nginx" specifies that the deployment should use the "nginx" Docker image.
• "--dry-run=client" specifies that the deployment should not actually be created, but the
result should be simulated.
• "-o yaml" specifies that the output format should be YAML.
• ">" redirects the output of the command to a file named "mydaemon.yaml" in the
current directory.
 StatefulSets
Sure! A StatefulSet is a Kubernetes object that is used to manage the deployment and
scaling of stateful applications. A stateful application is one that has a persistent identity
or state, such as a database or a message queue.

Unlike a Deployment, which is designed to manage stateless applications, a StatefulSet

provides guarantees about the identity and ordering of its pods, and ensures that each pod
has a stable, unique network identity.

Here are some key features of StatefulSets:

1. Stable, unique network identities: Each pod in a StatefulSet is assigned a unique

hostname and network identity that is stable across rescheduling and scaling
operations. This makes it easier for applications to reference specific pods by their
unique hostname, rather than relying on dynamic IP addresses.
2. Ordered, graceful deployment and scaling: StatefulSets provide guarantees about the
ordering of pod deployment and scaling, ensuring that pods are started and stopped in
a predictable order. This can be important for stateful applications, which may have
dependencies or require initialization or shutdown procedures.
3. Automatic rolling updates: StatefulSets support automatic rolling updates, which can
be used to update the version of a stateful application without disrupting the
availability or consistency of its data.
4. Persistence: StatefulSets can be used to manage stateful applications that require
persistent storage, such as databases. Each pod in a StatefulSet can be configured with
a persistent volume claim, which ensures that the data stored in the pod's file system is
preserved across rescheduling and scaling operations.
5. Headless service: A StatefulSet also automatically creates a headless service that
exposes the pod names and IP addresses, and is used to enable discovery and
communication between the pods in the StatefulSet.

Overall, StatefulSets provide a powerful way to manage stateful applications in Kubernetes,

by ensuring that each pod has a unique identity and persistence, and by providing predictable
deployment and scaling behavior.

StatefulSets is a Kubernetes resource that is used to manage stateful applications. In

Kubernetes, most applications are stateless, which means that they do not store data and
do not rely on specific resources. However, some applications are stateful, which means
that they have specific requirements for resources and depend on specific storage.
 kubectl config use-context
The kubectl config use-context k8s command is used to set the current context of your
kubectl configuration to a context with the name "k8s". A context in kubectl is a group of
access parameters for a Kubernetes cluster, such as the cluster's server URL, authentication
credentials, and default namespace.

The use-context command tells kubectl to use the context specified by the context name
after the command. In this case, the context name is "k8s". This means that any kubectl
commands you run after setting the context will be executed against the Kubernetes cluster
defined by the "k8s" context.

Here's an example of how you might use the kubectl config use-context command to
switch between contexts:

1. List the available contexts in your kubectl configuration:

sql
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* k8s my-cluster my-user my-namespace
local local <none> <none>

2. Use the use-context command to set the current context to "local":

lua
$ kubectl config use-context local
Switched to context "local".

3. Confirm that the current context has been changed:

lua
$ kubectl config current-context
local

4. Use the use-context command again to switch back to the "k8s" context:

lua
$ kubectl config use-context k8s
Switched to context "k8s".

By using the kubectl config use-context command, you can easily switch between
different Kubernetes clusters or contexts without having to modify your kubectl
configuration directly.
 When to use StatefulSet ?
StatefulSets are used in Kubernetes to manage stateful applications. They provide guarantees
around the ordering and uniqueness of deployment and scaling of pods, making them ideal for
managing stateful applications like databases or other applications that rely on persistent
storage. Here are some scenarios where you might use StatefulSets:

1. Stable persistent storage.

2. Stable and unique network identifiers.
3. Running stateful applications: As mentioned, StatefulSets are ideal for running stateful
applications like databases. Since these applications require persistent storage,
StatefulSets ensure that each pod has a unique hostname and stable network identity,
which makes it easier to manage stateful applications in a cluster.
4. Scaling stateful applications: Scaling stateful applications can be a complex process,
as you need to ensure that each replica is created and scaled in the correct order to
maintain the integrity of the data. StatefulSets simplify this process by providing
guarantees around the ordering and uniqueness of pod deployment and scaling.
5. Managing stateful applications with affinity or anti-affinity requirements: StatefulSets
can be used to manage applications that have affinity or anti-affinity requirements.
You can use StatefulSets to ensure that pods are scheduled on specific nodes or with
specific pods to meet the affinity requirements.
6. Performing rolling updates: When performing rolling updates of stateful applications,
you need to ensure that each replica is updated in the correct order to maintain the
integrity of the data. StatefulSets simplify this process by providing guarantees around
the ordering and uniqueness of pod deployment and scaling.

In summary, StatefulSets are ideal for managing stateful applications that require persistent
storage and have complex deployment, scaling, and management requirements.
 StatefulSet Considerations
• Storage must be automatically provisioned by a persistent volume provisioner. Pre-
provisioning is challenging, as volumes need to be dynamically added when new Pods
are scheduled.
• When a StatefulSet is deleted, associated volumes will not be deleted.
• A headless (ClusterIP = None) Service resource must be created in order to manage
the network identity of Pods.
• Pods are not guaranteed to be stopped while deleting a StatefulSet, and it is
recommended to scale down to zero Pods before deleting the StatefulSet

How to run StatefulSets

apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
 image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteMany" ]
resources:
requests:
storage: 1Gi

Running Individual Pods

Running individual Pods has disadvantages:
• No workload protection
• No load balancing
• No zero-downtime application update
Use individual Pods only for testing, troubleshooting, and analyzing
In all other cases, use Deployment, DaemonSet, or StatefulSet

Run individual Pods:

Command: kubectl run sleepy –image=busybox – sleep 3600

volumeClaimTemplates
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteMany" ]
resources:
requests:
storage: 1Gi

volumeClaimTemplates is a field in the Kubernetes StatefulSet object that specifies the

template for the persistent volume claims (PVCs) that are created by the StatefulSet. The
purpose of PVCs is to provide persistent storage to the StatefulSet pods.
In this configuration, the volumeClaimTemplates field defines a single volume claim
template named www. The metadata field specifies the name of the template. The spec field
contains the specifications for the template, which include:

• The accessModes field specifies the access modes for the volume, which determines
how many pods can access the volume simultaneously. In this case, it is set to
ReadWriteMany, which allows multiple pods to read and write to the volume
concurrently.
• The resources field specifies the resource requirements for the volume claim. In this
case, it requests 1Gi of storage.

When the StatefulSet is created, three PVCs are created based on this template, one for each
pod. The PVCs are dynamically provisioned by Kubernetes, and each PVC is mounted as a
volume in the corresponding pod. Any data written to the volume by a pod is preserved even
if the pod is terminated or rescheduled to a different node.

ContainerInit
"ContainerInit" (short for "Container Initialization") typically refers to the first process that
runs inside a container when it is started. This process is responsible for setting up the
container environment and performing any necessary initialization tasks, such as
starting background processes, configuring networking, and mounting volumes.

In Kubernetes, ContainerInit refers specifically to an optional property that can be set in a Pod
specification. If specified, Kubernetes ensures that the ContainerInit process is started before
any other containers in the Pod. This is useful when a container relies on some shared
resources, such as a configuration file, that need to be set up before any other containers can
use them.

The ContainerInit process is specified as a separate container within the Pod, with its own
image, command, and arguments. Once the ContainerInit process has completed its
initialization tasks, it exits, and the other containers in the Pod can start up and run normally.

Overall, ContainerInit is a way to ensure that the necessary setup and initialization tasks are
performed before the main containers in the Pod start running.

Scaling Applications
kubectl scale is used to manually scale Deployment, ReplicaSet, or StatefulSet

• kubectl scale deployment myapp--replicas=3

Alternatively, HorizontalPodAutoscaler can be used

 Using Sidecar Containers for Application Logging
Un sidecar container est un conteneur qui est associé à un conteneur principal dans un pod
Kubernetes. Le but du sidecar container est d'étendre les fonctionnalités du conteneur
principal, en ajoutant des fonctionnalités qui ne sont pas directement liées à l'application elle-
même.

Le sidecar container peut effectuer une variété de tâches, telles que la collecte de
données de performance, la journalisation, la surveillance, la gestion des connexions
réseau, la gestion des certificats et des clés, la configuration du système, la distribution
de trafic, etc. Le sidecar container fonctionne de manière étroitement couplée avec le
conteneur principal, partageant le même espace de réseau et de stockage.

Le modèle de sidecar container est très flexible et peut être utilisé pour étendre les
fonctionnalités d'un conteneur principal sans affecter son code ou sa configuration. Par
exemple, un sidecar container peut être utilisé pour ajouter une fonction de
journalisation à un conteneur principal sans modifier son code, ou pour ajouter une
fonction de distribution de trafic pour un conteneur principal sans modifier sa
configuration.

Le modèle de sidecar container est souvent utilisé en conjonction avec d'autres modèles de
conteneurs, tels que le modèle d'injection de dépendances et le modèle d'observabilité, pour
créer des applications cloud-native hautement évolutives et résilientes.
 Managing Storage
$ Kubectl explain pod.spec.volumes

Relation entre PV et PVC: Les PVCs et les PVs sont liés l'un à l'autre dans
Kubernetes. Les PVCs sont des demandes de stockage persistant, et les PVs sont
des ressources de stockage persistant. Les PVCs utilisent les spécifications de
stockage pour rechercher un PV disponible et se lient à lui. Une fois que le PVC est
lié au PV, le Pod peut utiliser le stockage persistant associé au PV.

Je vais expliquer chaque terme et comment ils sont liés au concept de dé-couplage pour la
flexibilité du stockage dans Kubernetes.

• Pod: Un Pod est la plus petite unité de déploiement dans Kubernetes. C'est un
environnement d'exécution pour un ou plusieurs conteneurs. Les Pods sont utilisés
pour exécuter des applications dans le cluster.
• Conteneur : Un conteneur est un environnement isolé pour exécuter des applications.
Les conteneurs sont une unité d'exécution légère et portable qui peut être déployée
dans n'importe quel environnement. Dans Kubernetes, les applications sont exécutées
dans des conteneurs qui sont regroupés dans des Pods.
• Volume : Un Volume est un espace de stockage qui peut être utilisé par un ou
plusieurs conteneurs dans un Pod. Les Volumes peuvent être utilisés pour stocker des
 données de manière persistante. Les données stockées dans un Volume ne sont pas
perdues lorsque le Pod est supprimé ou redéployé.
• Stockage local: Le stockage local est un type de stockage dans lequel les données sont
stockées sur le disque dur du nœud sur lequel le Pod est exécuté. Le stockage local est
rapide et offre des performances élevées, mais il est limité par la capacité de stockage
du nœud.
• PVC : PVC signifie Persistent Volume Claim. Un PVC est une demande de stockage
persistant qui peut être utilisée par un Pod. Un PVC est lié à un Volume, qui peut être
un stockage local ou distant.
• PV : PV signifie Persistent Volume. Un PV est un espace de stockage persistant dans
le cluster qui est utilisé par un PVC. Les PV peuvent être provisionnés de manière
statique ou dynamique.
• StorageClass: Une StorageClass est un moyen de définir différents types de stockage
avec différentes propriétés telles que les performances, la disponibilité et le coût. Les
StorageClasses sont utilisées pour provisionner des PVs.
• Provisioner: Un Provisioner est un outil qui crée et gère les ressources de stockage
sous-jacentes pour les PVs. Les provisioners peuvent être intégrés ou tiers, et ils
interagissent généralement avec les services de stockage du fournisseur de cloud ou un
NAS/SAN.

Maintenant, parlons du concept de dé-couplage pour la flexibilité du stockage dans

Kubernetes. Dans Kubernetes, les applications sont conçues pour être dé-couplées de leur
environnement d'exécution. Cela signifie que les applications ne doivent pas dépendre d'un
environnement spécifique pour fonctionner correctement. Le stockage est une partie
importante de l'environnement d'exécution, et il est important que le stockage soit également
dé-couplé pour garantir la flexibilité et la portabilité des applications.

Kubernetes permet de dé-coupler le stockage des applications en utilisant des PV, des
PVC, des StorageClasses et des provisioners. Les applications peuvent demander des
ressources de stockage à l'aide de PVCs qui spécifient les exigences de stockage, telles que la
taille et les performances requises. Les PVCs peuvent être liés à des PVs, qui représentent
l'espace de stockage réel. Les PVs peuvent être provisionnés de manière statique ou
dynamique en utilisant des provisioners qui créent et gèrent les ressources de
Kubernetes propose plusieurs options pour stocker des données persistantes pour les
applications s'exécutant sur le cluster. Voici un aperçu des principales options de stockage de
Kubernetes :

1. Volumes vides : Kubernetes prend en charge les volumes vides qui peuvent être
utilisés pour stocker des données persistantes. Les volumes vides sont des volumes
temporaires qui sont créés lorsque les pods sont créés et qui sont supprimés lorsque les
pods sont supprimés. Les volumes vides sont utiles pour les scénarios où les données
n'ont pas besoin d'être stockées de manière permanente, ou lorsqu'un stockage externe
n'est pas disponible.

2. Persistent Volumes (PV) : Les Persistent Volumes sont des volumes de stockage qui
sont séparés du cycle de vie des pods et qui peuvent être utilisés pour stocker des
données persistantes. Les PV sont créés indépendamment des pods et sont attachés aux
pods lorsqu'ils sont créés. Les PV sont utiles pour les scénarios où les données doivent
être stockées de manière permanente, ou lorsqu'un stockage externe est disponible.
3. Persistent Volume Claims (PVC) : Les Persistent Volume Claims sont utilisés pour
demander des ressources de stockage à partir d'un PV. Les PVC sont créés par les
utilisateurs ou par les systèmes Kubernetes pour allouer une partie du stockage
disponible dans un PV à un pod. Les PVC sont utiles pour les scénarios où les
applications ont besoin d'une quantité spécifique d'espace de stockage.
4. Stockage en nuage : Kubernetes prend en charge le stockage en nuage, qui permet aux
utilisateurs de créer des volumes de stockage dans les services de stockage en nuage
tels que Amazon Web Services (AWS), Google Cloud Platform (GCP) ou Microsoft
Azure. Les volumes de stockage en nuage peuvent être utilisés pour stocker des
données persistantes pour les applications s'exécutant sur le cluster.
5. Stockage de données de l'hôte : Les pods peuvent également utiliser le stockage local
de l'hôte pour stocker des données persistantes. Cette option de stockage est utile pour
les scénarios où les applications ont besoin d'un accès rapide aux données.
En utilisant l'une de ces options de stockage, les utilisateurs de Kubernetes peuvent configurer
des environnements de stockage flexibles et hautement évolutifs pour les applications
s'exécutant sur le cluster.

PV est une ressource de stockage qui peut être utilisée pour stocker des données
persistantes, tandis que le PVC est une demande de stockage pour une application
spécifique. Les PV sont créés en dehors des pods, tandis que les PVC sont créés par les
utilisateurs ou les applications. Les PVC utilisent les PV pour réserver de l'espace de
stockage pour une application spécifique. Les PVC permettent aux utilisateurs de
demander des ressources de stockage en fonction de leurs besoins, ce qui facilite la gestion
du stockage persistant dans Kubernetes.

Accessing Storage Through Pod Volumes

As we can see we are creating a file in container centos1 a file with name:
centosfile and in the second container we find the same file because it was a
shared storage that we are configuring the the file.yaml

In Kubernetes, pod volumes are used to store and access data from persistent storage. Pod
volumes are similar to traditional file systems, where data is stored in files and directories.
However, pod volumes have some unique properties that make them suitable for use in a
distributed environment like Kubernetes.

To access storage through pod volumes, follow these steps:

1. Create a Persistent Volume (PV) or choose an existing one. A PV represents a piece of

storage in the cluster and can be provisioned by a storage provider or an administrator.
 2. Create a Persistent Volume Claim (PVC) or choose an existing one. A PVC is a
request for storage that is bound to a PV. It specifies the storage capacity and access
mode required by the application.
3. Create a Pod and attach the PVC to it. A Pod is the smallest deployable unit in
Kubernetes that contains one or more containers. In the Pod specification, you can
define the volume to be used by the container and mount it at a specific path.

Here is an example Pod specification that mounts a PVC to a container:

yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mycontainer
image: myimage
volumeMounts:
- name: mypvc
mountPath: /data
volumes:
- name: mypvc
persistentVolumeClaim:
claimName: myclaim

In this example, the Pod has one container named mycontainer and one volume named
mypvc. The PVC used by the volume is named myclaim. The volumeMounts field in the
container specification defines the volume to be mounted and the mount path in the container.
In this case, the volume is mounted at /data in the container.

By mounting a volume to a container in a Pod, the application running in the container can
read and write data to the persistent storage. This allows the data to be preserved even if the
Pod or the node it's running on is deleted or recreated.

Summary Kubernetes Storage with Example

PV and PVC in Kubernetes architecture, the relationship between them, and with
StorageClass and Provisioner, along with examples.

• Persistent Volume (PV): A PV is a persistent storage space in Kubernetes. It's a

storage resource that exists independently of the Pod and can be used by multiple
Pods. PVs are provisioned by cluster administrators or authorized users, either
statically by creating PVs in advance or dynamically on demand. PVs are bound to
storage specifications such as storage type, capacity, storage class, access mode, and
availability level.
• Persistent Volume Claim (PVC): A PVC is a persistent storage request in Kubernetes.
It's a demand resource that is created by a user or application to obtain access to
storage. PVCs specify the same storage attributes as PVs, such as storage type,
capacity, storage class, access mode, and availability level. When a PVC is created,
 Kubernetes searches for a PV that matches the PVC specifications, and binds it to the
PVC if an available one is found.
• Relationship between PV and PVC: PVCs and PVs are linked to each other in
Kubernetes. PVCs are persistent storage requests, and PVs are persistent storage
resources. PVCs use the storage specifications to search for an available PV and bind
to it. Once the PVC is bound to the PV, the Pod can use the persistent storage
associated with the PV.
• StorageClass: A StorageClass is a Kubernetes resource that defines a set of properties
for PVs. StorageClasses define storage attributes such as storage type, capacity,
storage class, access mode, and availability level. StorageClasses can be used to
dynamically provision PVs. PVCs can be created without specifying a PV and can be
dynamically bound to a PV that matches the properties defined in the StorageClass.
• Provisioner: A provisioner is a process that creates and manages PVs. Provisioners can
be built-in or third-party, and are responsible for creating the storage space and
configuring the access to the storage. Provisioners can be bound to StorageClasses to
dynamically provision PVs.

Here's an example to illustrate how these resources are used together in Kubernetes:

Suppose you have a Kubernetes cluster, and you want to create a deployment that uses
persistent storage to store application data. You would follow these steps:

1. Create a PV: You can create a PV statically by defining the storage specifications,
such as storage type, capacity, storage class, access mode, and availability level. For
example, you can create a PV to store data on a NAS with 10 GB capacity and read-
write access.
2. Create a StorageClass: You can create a StorageClass that defines the storage
attributes, such as storage type, capacity, storage class, access mode, and availability
level. For example, you can create a StorageClass for the NAS storage type with a
capacity of 10 GB, read-write access, and a storage class of standard.
3. Create a Provisioner: You can create a provisioner to manage the PV and
StorageClass. The provisioner can be a built-in provisioner or a third-party
provisioner.
4. Create a PVC: You can create a PVC that specifies the storage attributes, such as
storage type, capacity, storage class, access mode, and availability level. For example,
you can create a PVC with the same attributes as the StorageClass for the NAS storage
type with a capacity of 10 GB, read-write access, and a storage class of standard.
5. Bind PVC to PV: Kubernetes will automatically find an available PV that matches the
PVC specifications and bind it to the PVC.
6. Mount the PVC to the Pod: You can mount the PVC to the Pod as a volume, which
allows the application to read and write data to the persistent storage
 Creating PV

Creating PVC

Configuring Pod Storage with PV and PVC

 StorageClass
StorageClass est un objet de l'API Kubernetes qui permet la provision automatique de
stockage dans un cluster Kubernetes. Il s'agit d'une manière pour les administrateurs de
cluster de définir des exigences et des capacités de stockage qui sont disponibles dans
leur cluster, puis de permettre aux utilisateurs et aux applications de demander du
stockage qui répond à ces exigences.

Lorsqu'un utilisateur ou une application demande un volume persistant en utilisant une

revendication de volume persistant (PVC) qui référence une StorageClass, Kubernetes
provisionne automatiquement un nouveau volume persistant (PV) qui répond aux exigences
définies dans la StorageClass. Cela permet aux utilisateurs et aux applications de demander
facilement et dynamiquement du stockage selon leurs besoins, sans avoir à se soucier de
l'infrastructure sous-jacente ou du système de stockage.

StorageClass est particulièrement utile dans les environnements de cloud où les ressources de
stockage sont souvent provisionnées dynamiquement, mais il peut également être utilisé avec
des systèmes de stockage sur site qui prennent en charge la provision dynamique. En utilisant
StorageClass, les administrateurs de cluster peuvent simplifier la gestion du stockage dans
leur cluster et fournir un ensemble cohérent de capacités de stockage pour leurs utilisateurs et
leurs applications.

• StorageClass is an API resource that allows storage to be automatically

provisioned
• StorageClass can also be used as a property that connects PVC and PV without using
an actual StorageClass resource
• Multiple StorageClass resources can co-exist in the same cluster to provide access to
different types of storage
• For automatic working, one StorageClass must be set as default:

kubectl patch storageclass mysc -p '{"metadata":{"annotations":

{"storageclass.kubernetes.io/is-default-class": "true"}}}'

• To enable automatic provisioning, StorageClass needs a backing storage provisioner

• In the PV and PVC definition, a storageClass property can be set to connect to a
specific StorageClass which is useful if multiple StorageClass resources are available
• If the storageClass property is not set, the PVC will get storage from the default
StorageClass
• If also no default StorageClass is set, the PVC will get stuck in a status of Pending
 Understanding Storage Provisioners
Using an NFS Storage Provisioner
• The Storage Provisioner works with a StorageClass to automatically provide storage
• It runs as a Pod in the Kubernetes cluster, provided with access control configured
through Roles, RoleBindings, and ServiceAccounts
• Once operational, you don't have to manually create PersistentVolumes anymore

Understanding Requirements
• To create a storage provisioner, access permissions to the API are required
• Roles and RoleBindings are created to provide these permissions
• A ServiceAccount is created to connect the Pod to the appropriate RoleBinding
• More information about Role Based Access Control (RBAC) is in Lesson 10.3

Demo: Configuring a Storage Provisioner

• On control: sudo apt install nfs-server-y
• On other nodes: sudo apt install nfs-client
• On control:
o sudo mkdir /nfsexport
o sudo sh -c 'echo "/nfsexport *(rw,no_root_squash)" > /etc/exports'
o sudo systemctl restart nfs-server
• On other nodes: showmount -e control-machine-name-or-@-ip

Demo: Configuring a Storage Provisioner

• Fetch the helm binary from github.com/helm/helm/releases and install it
to/usr/local/bin
• Add the helm repo using helm repo add nfs-subdir-external-provisioner
https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
• Install the package using helm install nfs-subdir-external-provisioner nfs-subdir-
external-provisioner/nfs-subdir-external-provisioner --set nfs.server=xx.xx.xx.yy
–set nfs.path=/nfsexport
• Use kubectl get pods to verify that the nfs-subdir-provisioner Pod is running
 La commande "helm install nfs-subdir-external-provisioner" permet d'installer un
provisionneur externe pour les volumes persistants dans Kubernetes qui utilise le protocole
NFS pour stocker les données.

Plus spécifiquement, cette commande installe un chart Helm nommé "nfs-subdir-

external-provisioner" provenant du référentiel "nfs-subdir-external-provisioner/nfs-subdir-
external-provisioner". Ce chart contient des instructions pour déployer un provisionneur
externe pour les volumes persistants dans Kubernetes qui utilise le protocole NFS pour
stocker les données.

Le paramètre "--set nfs.server=192.168.232.13" permet de spécifier l'adresse IP du

serveur NFS qui sera utilisé pour stocker les données persistantes dans Kubernetes. Cela
permet au provisionneur externe d'accéder au stockage NFS et de créer des volumes
persistants pour les applications qui en ont besoin.

Kubernetes est un système open source de déploiement, de mise à l'échelle et de

gestion d'applications en conteneurs. Il permet de déployer des applications de manière
déclarative et de les exécuter dans un environnement de production.

Helm est un outil open source de gestion de paquets pour Kubernetes. Il permet de
simplifier et d'automatiser le déploiement d'applications et de services dans un cluster
Kubernetes en utilisant des charts. Les charts sont des packages préconfigurés qui contiennent
tous les fichiers nécessaires pour déployer une application dans Kubernetes, y compris les
manifestes Kubernetes, les images Docker, les scripts d'installation et les fichiers de
configuration.

Avec Helm, les développeurs peuvent facilement créer, publier et partager des charts
pour leurs applications et les déployer rapidement dans un cluster Kubernetes. Les opérateurs
peuvent également utiliser Helm pour gérer les mises à jour, les versions et les configurations
des applications déployées dans Kubernetes.

En résumé, Helm simplifie le déploiement et la gestion d'applications dans Kubernetes

en fournissant des packages préconfigurés appelés charts. Cela permet aux développeurs et
aux opérateurs de Kubernetes de travailler plus efficacement et de se concentrer sur le
développement d'applications plutôt que sur la gestion de l'infrastructure.
 Demo: Creating the PVC
• Type kubectl get pv to verify that currently no PVs are available
• Use kubectl apply -f nfs-provisioner-pvc-test.yaml to create a PVC
• Use kubectl get pvc, pv to verify the PVC is created and bound to an automatically
created PV
• Create any Pod that mounts the PVC storage, and verify data end up in the NFS share

Demo: Understanding Default StorageClass

• Use kubectl apply -f another-pvc-test.yaml
• kubectl get pvc will show pending: there is no default StorageClass
• kubectl patch storageclass mysc -p '{"metadata":
{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
• kubectl get pvc will now work

Kubernetes, ConfigMap et Secret

Dans Kubernetes, ConfigMap et Secret sont des objets qui permettent de stocker des
données de configuration et des secrets sensibles respectivement, et de les rendre disponibles
aux conteneurs s'exécutant dans les pods.

Un ConfigMap est un objet Kubernetes qui stocke des paires clé-valeur de données de
configuration, telles que des fichiers de configuration de l'application, des variables
d'environnement, des chaînes de connexion de bases de données, etc. Les ConfigMaps sont
créés à partir de données stockées dans des fichiers ou à partir de données stockées en ligne de
commande et peuvent être montés dans un conteneur en tant que volume ou en tant que
variables d'environnement.

Un Secret est un objet Kubernetes qui stocke des données sensibles, telles que des clés
d'API, des certificats, des mots de passe, etc. Les Secrets sont créés à partir de données
stockées dans des fichiers ou à partir de données stockées en ligne de commande et peuvent
être montés dans un conteneur en tant que volume ou en tant que variables d'environnement.
 Les ConfigMaps et les Secrets sont gérés par l'administrateur système et peuvent être
partagés entre différents pods et services. Ils permettent de séparer la configuration de
l'application des images de conteneurs, de rendre les configurations plus flexibles et de
faciliter la gestion des secrets sensibles.

Demo: Creating a ConfigMap

• echo "hello world" > index.html
• kubectl create cm webindex --from-file=index.html
• kubectl describe cm webindex
• kubectl create deploy webserver --image=nginx
• kubectl edit deploy webserver

spec.template.spec
volumes:
- name: cmvol
configMap:
name: webindex

spec.template.spec.containers
volumeMounts:
- mountPath: /usr/share/nginx/html
name: cmlvol

Lesson 4 Lab: Setting up Storage

• Create a Persistent Volume, using the HostPath storage type to access the directory
/storage
• Create a file /storage/index.html, containing the text "hello lab4"
• Run a Pod that uses an Nginx image and mounts the HostPath storage on the directory
/usr/share/nginx/html
• On the running Pod, use kubectl exec to verify the existence of the file
/usr/share/nginx/html
 Managing Application Access
Service Types in Kubernetes?
Un service est une abstraction qui définit un ensemble logique de pods et une
politique d'accès à ces derniers. Il fournit une adresse IP et un nom DNS stables pour un
ensemble de pods qui appartiennent à un déploiement ou une série, permettant aux autres
composants du cluster de communiquer avec eux.
Un Service agit en tant qu’un load balancer, acheminant le trafic vers le pod approprié
en fonction des règles définies dans sa configuration. La configuration peut spécifier le type
d'algorithme de répartition de charge utilisé (par exemple, round-robin ou affinité de session),
les ports à exposer et les ports cibles des pods.

A deployment is responsible for keeping a set of pods running in a cluster

A service is responsible for enabling network access to a set of pods in a cluster

 Exploring Kubernetes Networking

Here are brief explanations of each term related to Kubernetes networking:

1. External Load Balancer (LB): An external load balancer is a service that routes
external traffic to the Kubernetes cluster's services. An external LB is typically
provided by a cloud provider or can be set up manually.
2. Ingress: Kubernetes Ingress is a resource that manages external access to the services
in a cluster. It acts as a layer 7 (HTTP/HTTPS) load balancer and can route traffic
based on URL path, domain name, and other criteria.
3. NodePort: NodePort is a Kubernetes service that exposes a service on a static port on
each node's IP address. It enables external access to the service by forwarding the
traffic from the node's IP address to the service's pod.
4. ClusterIP: A ClusterIP is a Kubernetes service that exposes a service internally
within the cluster. It provides a stable IP address for the service to access it from
within the cluster.
5. Cluster network: The cluster network is the network used by the Kubernetes nodes to
communicate with each other and manage the cluster's internal state.
6. Pod network: The pod network is the network used by the pods to communicate with
each other within the cluster. Each pod has its unique IP address within this network.
7. SDN (Software-Defined Networking): Kubernetes SDN is a networking model that
uses software to manage the network instead of physical devices. SDN enables the
Kubernetes cluster's components to communicate with each other efficiently and
securely.
8. External network: The external network refers to the network outside the Kubernetes
cluster, which can be used to communicate with the services or pods running in the
cluster. This can be through an external load balancer, node ports, or ingress.
 In summary, Kubernetes networking involves managing network connectivity and
communication between various components of a Kubernetes cluster. Understanding these
networking concepts and components is essential for deploying and managing applications in
Kubernetes.
 Understanding Services

• A Service resources are used to provide access to Pods

• If multiple Pods are used as Service endpoint, the Service will load balance traffic to
the Pods
• Different types of Service can be configured:
o ClusterIP: the Service is internally exposed and is reachable only from within
the cluster
o NodePort: the Service is exposed at each node's IP address as a port. The
Service can be reached from outside the cluster at nodeip:nodeport
o LoadBalancer: the cloud provider offers a load balancer that routes traffic to
either NodePort- or ClusterIP-based Services
o ExternalName: the Service is mapped to an external name that is
implementedas a DNS CNAME record

Configuring Services
• Use kubectl expose to expose applications through their Pods, ReplicaSet or
Deployment (recommended)
• Use kubectl create service as an alternative

Demo: Creating Services

• kubectl create deploy webshop --image=nginx --replicas=3
• kubectl get pods --selector app=webshop -o wide
• kubectl expose deploy webshop --type=NodePort --port=80
• kubectl describe svc webshop
• kubectl get svc
• curl nodeip:nodeport
 Running an Ingress
Controller
Understanding Ingress
• Ingress is an API object that manages external access to services in a cluster
• Ingress works with external DNS to provide URL-based access to Kubernetes
applications
• Ingress consists of two parts
o A load balancer available on the external network
o An API resource that contacts the Service resources to find out about available
back-end Pods
• Ingress load balancers are provided by the Kubernetes ecosystem, different load
balancers are available

Understanding Ingress
• Ingress exposes HTTP and HTTPS routes from outside the cluster to Services within
the cluster
• Ingress uses the selector label in Services to connect to the Pod endpoints
• Traffic routing is controlled by rules defined on the Ingress resource
• Ingress can be configured to do the following, according to functionality provided by
the load balancer
o Give Services externally-reachable URLs
o Load balance traffic
o Terminate SSL/TLS
o Offer name based virtual hosting

Demo: Installing the Nginx Ingress Controller

• helm upgrade --install ingress-nginx ingress-nginx --repo
https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create
namespace
• kubectl get pods -n ingress-nginx
• kubectl create deploy nginxsvc --image=nginx --port=80
• kubectl expose deploy nginxsvc

Les explications pour chaque commande :

1. helm upgrade --install ingress-nginx ingress-nginx --repo

https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx
--create namespace : Cette commande utilise Helm pour installer ou mettre à jour
une charte nommée ingress-nginx en utilisant le référentiel spécifié
 https://kubernetes.github.io/ingress-nginx. Elle crée également un espace de
noms ingress-nginx s'il n'existe pas encore.
2. kubectl get pods -n ingress-nginx : Cette commande récupère tous les pods en
cours d'exécution dans l'espace de noms ingress-nginx. Cela vous permet de vérifier
l'état des pods pour vous assurer que les composants du contrôleur de l'ingress
fonctionnent correctement.
3. kubectl create deploy nginxsvc --image=nginx --port=80 : Cette commande
crée un déploiement nommé nginxsvc en utilisant l'image Docker nginx. Elle expose
également le port 80 du conteneur Docker.
4. kubectl expose deploy nginxsvc : Cette commande expose le déploiement
nginxsvc en créant un service Kubernetes pour exposer le déploiement aux autres
services et pods. Le service utilise les paramètres par défaut pour mapper les ports du
conteneur sur les ports du service.

Demo: Installing the Nginx Ingress Controller

• kubectl create ingress nginxsvc --class=nginx --rule=nginxsvc.info/*=nginxsvc:80
• kubectl port-forward -n ingress-nginx svc/ingress-nginx-controller 8080:80
• echo "127.0.0.1 nginxsvc.info" >> /etc/hosts
• curl nginxsvc.info:8080

Les explications pour chaque commande :

1. kubectl create ingress nginxsvc --class=nginx --

rule=nginxsvc.info/*=nginxsvc:80 : Cette commande crée une ressource
d'ingress appelée nginxsvc qui utilise la classe nginx pour rediriger le trafic entrant
de l'URL nginxsvc.info vers le service nginxsvc sur le port 80.
2. kubectl port-forward -n ingress-nginx svc/ingress-nginx-controller
8080:80 : Cette commande crée un tunnel de port entre le port 8080 de votre machine
locale et le port 80 du service ingress-nginx-controller dans l'espace de noms
ingress-nginx. Cela vous permet d'accéder au serveur Web de ce service via votre
navigateur en ouvrant l'URL http://localhost:8080.
3. echo "127.0.0.1 nginxsvc.info" >> /etc/hosts : Cette commande ajoute
l'entrée 127.0.0.1 nginxsvc.info dans le fichier /etc/hosts de votre système.
Cela permet à votre machine de résoudre l'adresse nginxsvc.info en utilisant
l'adresse IP 127.0.0.1 de votre propre machine.
4. curl nginxsvc.info:8080 : Cette commande envoie une requête HTTP GET à
l'URL nginxsvc.info:8080 pour récupérer le contenu du serveur Web qui a été
redirigé par l'ingress. Cela vous permet de tester la connectivité et de vous assurer que
le serveur fonctionne correctement.
 Managing Rules
• Ingress rules catch incoming traffic that matches a specific path and optional hostname
and connects that to a Service and port
• Use kubectl create ingress to create rules
• Different paths can be defined on the same host
o kubectl create ingress mygress --rule="/mygress=mygress:80"
--rule="/vourgress=yourgress:80"
• Different virtual hosts can be defined in the same Ingress
o kubectl create ingress nginxsvc --class=nginx --
rule=nginxsvc.info/*=nginxsvc:80 --
rule=otherserver.org/*=otherserver:80

Understanding IngressClass
• In one cluster, different Ingress controllers can be hosted, each with its own
configuration
• Controllers can be included in an IngressClass
• While defining Ingress rules, the -class option should be used to implement the role on
a specific Ingress controller
o If this option is not used, a default IngressClass must be defined
o Set ingressclass.kubernetes.io/is-default-class: true as an annotation on the
IngressClass to make it the default
• After creating the Ingress controller as described before, an IngressClass API resource
has been created
• Use kubectl get ingressclass -o yaml to investigate its content

Demo: Configuring Ingress Rules

Note: this demo continues on the demo in Lesson 5.3
• kubectl get deployment
• kubectl get svc webshop
• kubectl create ingress webshop-ingress --rule="/=webshop:80" --
rule="/hello=newdep:8080"
• sudo vim /etc/hosts
o 127.0.0.1 webshop.info
• kubectl get ingress
• kubectl describe ingress webshop-ingress
 Demo: Configuring Ingress Rules
• kubectl create deployment newdep --image=gcr.io/google-samples/hello-app:2.0
• kubectl expose deployment newdep --port=8080
• kubectl describe ingress webshop-ingress

Using Port Forwarding

• kubectl port-forward can be used to connect to applications for analyzingand
troubleshooting
• It forwards traffic coming in to a local port on the kubectl client machine to a port that
is available in a Pod
• Using port forwarding allows you to test application access without the need to
configure Services and Ingress
• Use kubectl port-forward mypod 1234:80 to forward local port 1234 to Pod port 80
• To run in the background, use Ctrl-z or start with a & at the end of the kubectl port-
forward command

Lesson 5 Lab: Managing Networking

• Run a deployment with the name apples, using 3 replicas and the Nginx image
• Expose this deployment in such a way that it is accessible on my.fruit
• Use port fowarding to test

Lab Solution
• $ kubectl create deployment apples --replicas=3 --image=nginx
• $ kubectl expose deployment apples --port=80
• $ kubectl create ingress apples --rule="my.fruit/*=apples:80"
• Edit /etc/hosts:

127.0.0.1 localhost my.fuit

127.0.1.1 k8s-master

192.168.232.135 k8s-master.it24.lan k8s-master

192.168.232.136 k8s-worker-node1.it24.lan k8s-worker-node1

192.168.232.137 k8s-worker-node2.it24.lan k8s-worker-node2

 Configuring Ingress
In Kubernetes, Ingress is a resource that allows external access to the services in a cluster. It
provides a way to route traffic to different services based on the request's URL path or host
header.

To use Ingress in a Kubernetes cluster, you need to set up an Ingress controller that handles
the traffic and routes it to the appropriate services. There are several Ingress controllers
available, such as NGINX, Traefik, and Istio.

In this article, we will focus on configuring Ingress using NGINX as the Ingress controller.

Step 1: Set up an Ingress Controller

Before you can start using Ingress, you need to set up an Ingress controller in your Kubernetes
cluster. In this example, we will use the NGINX Ingress controller.

You can install the NGINX Ingress controller using a Helm chart or by creating a Kubernetes
deployment manually.

To install the NGINX Ingress controller using a Helm chart, run the following commands:

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

$ helm install nginx-ingress ingress-nginx/ingress-nginx

This will install the NGINX Ingress controller in your Kubernetes cluster.

Step 2: Create a Service

To expose a service through Ingress, you first need to create a Kubernetes Service resource
that points to the pods running the service.

For example, suppose you have a deployment running a web application with the label
app=webapp. You can create a service that exposes this deployment using the following
command:

$ kubectl expose deployment webapp --port=80 --target-port=8080 --

type=ClusterIP

This creates a service with the name webapp that maps port 80 to port 8080 on the pods with
the label app=webapp.

Step 3: Create an Ingress Resource

Once you have set up the Ingress controller and created a service, you can create an Ingress
resource to define how traffic should be routed to the service.
For example, suppose you want to route traffic for the domain example.com to the webapp
service. You can create an Ingress resource using the following YAML configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: webapp
port:
name: http

This Ingress resource defines a rule that routes traffic for example.com to the webapp service.
The path: / line specifies that requests to the root URL should be routed to the service. The
pathType: Prefix line specifies that the path should match the prefix of the URL. The
backend section specifies the service that should receive the traffic.

Step 4: Verify the Ingress Configuration

To verify that the Ingress configuration is working correctly, you can use curl to send a
request to the Ingress endpoint.

For example, if you have set up the Ingress to route traffic for example.com to the webapp
service, you can use the following command to send a request to the Ingress endpoint:

$ curl -H "Host: example.com" http://<ingress-ip>/

Replace <ingress-ip> with the IP address of the Ingress controller.

If everything is set up correctly, you should receive a response from the web application.

Conclusion

Ingress is a powerful resource that allows you to expose your services to the outside world in
a flexible and configurable way. By setting up
 Lesson 6 : Managing Clusters
6.1 Analyzing Cluster Nodes

6.2 Using crictl to manage node containers

6.3 Running static pods

6.4 Managing Node state

6.5 Managing Node services

Lab: Runing statis pods

Analyzing Cluster Nodes

• Kubernetes cluster nodes run Linux processes. To monitor these processes, generic
Linux rules apply
o Use systemctl status kubelet to get runtime information about the kubelet
o Use log files in /var/log as well as journalctl output to get access to logs
• Generic node information is obtained through kubectl describe
• If the Metrics Server is installed, use kubectl top nodes to get a summary of
CPU/memory usage on a node. See Lesson 7.1 for more about this

Demo: Analyzing Node State

• Is-Irt/var/log
• journalctl
• systemctl status kubelet

Understanding crictl
• All Pods are started as containers on the nodes
• crictl is a generic tool that communicates to the container runtime to get information
about running containers
• As such, it replaces generic tools like docker and podman
• To use it, a runtime-endpoint and image-endpoint need to be set
• The most convenient way to do so, is by defining the /etc/crictl.yam file on the nodes
where you want to run crictl
• This file is provided in the course git repository at
https:/github.com/sandervanvugt/cka

Demo: Using crictl

• List containers: sudo crictl ps
• List Pods that have been scheduled on this node: sudo crictl pods
• Inspect container configuration: sudo crictl inspect <name-or-id>
• Pull an image: sudo crictl pull <imagename>
• List images: sudo crictl images
• For more options, use crictl—help

Understanding Static Pods

• The kubelet systemd process is configured to run static Pods from the
/etc/kubernetes/manifests directory
• On the control node, static Pods are an essential part of how Kubernetes works: system
starts kubelet, and kubelet starts core Kubernetes services as static Pods
• Administrators can manually add static Pods if so desired, just copy a manifest file
into the /etc/kubernetes/manifests directory and the kubelet process will pick it up
• To modify the path where Kubelet picks up the static Pods, edit staticPodPath in
/var/lib/kubelet/config.yaml and use sudo systemctl restart kubelet to restart
• Never do this on the control node!

Demo: Running Static Pods

• kubectl run staticpod --image=nginx --dry-run=client -o yaml > staticpod.yaml
• sudo cp staticpod.yaml /etc/kubernetes/manifests/
• kubectl get pods -o wide

Managing Node State

• kubectl cordon is used to mark a node as unschedulable
• kubectl drain is used to mark a node as unschedulable and remove all running Pods
from it
o Pods that have been started from a DaemonSet will not be removed while
using kubectl drain, add --ignore-daemonsets to ignore that
o Add --delete-emptydir-data to delete data from emptyDir Pod volumes
 Managing Node State
• While using cordon or drain, a taint is set on the nodes (see Lesson 8.4 for more
information)
• Use kubectl uncordon to get the node back in a schedulable state

Demo: Managing Node State

• kubectl cordon worker2
• kubectl describe node worker2 # look for taints
• kubectl get nodes
• kubectl uncordon worker2

Managing Node Services

• The container runtime (often containerd) and kubelet are managed by the Linux
system service manager
• Use systemctl status kubelet to check the current status of the kubelet
• To manually start it, use sudo systemctl start kubelet
• Notice that Pods that are scheduled on a node show as container processes in ps aux
output. Don't use Linux tools to manage Pods!

Demo: Managing Node Services

• ps aux grep kubelet
• ps aux grep containerd
• systemctl status kubelet
• sudo systemctl stop kubelet
• sudo systemctl start kubelet

Lesson 6 Lab: Managing Static Pods

• On node worker1, run a static Pod with the name mypod, using an Nginx image and
no further configuration
• Use the appropriate tools to verify that the static Pod has started
• successfully
 Understanding Kubernetes Monitoring
• Kubernetes monitoring is offered by the integrated Metrics Server
• The server, after installation, exposes a standard API and can be used to expose
custom metrics
• Use kubectl top to see a top-like interface to provide resource usage information

Demo: Setting up Metrics Server

• See https://github.com/kubernetes-sigs/metrics-server.git
• Read github documentation!
• kubectl apply -f https://github.com/kubernetes-sigs/metrics-
server/releases/latest/download/components.yaml
• kubectl -n kube-system get pods # look for metrics-server.
• kubectl -n kube-system edit deployment metrics-server
o In spec.template.spec.containers.args, use the following
o ---kubelet-insecure-tls
o --kubelet-preferred-address-types=InternalIP,ExternallP,Hostname
• kubectl -n kube-system logs metrics-server<TAB> should show "Generating self-
signed cert" and "Serving securely on [:]443
• kubectl top pods --all-namespaces will show most active Pods

Understanding the Etcd

• The etcd is a core Kubernetes service that contains all resources that have been created
• It is started by the kubelet as a static Pod on the control node
• Losing the etc means losing all your configuration

Understanding Etc Backup

• To back up the etcd, root access is required to run the etcdctl tool
• Use sudo apt install etcd-client to install this tool
• etcdctl uses the wrong API version by default, fix this by using sudo ETCDCTL
API=3 etcoctl ... snapshot save
• to use etcdctl, you need to specify the etc service API endpoint, as well as cacert, cert
and key to be used
• Values for all of these can be obtained by using ps aux | grep etcd

Demo: Backing up the Etcd

• sudo apt install etcd-client
• sudo etcdctl --help; sudo ETCDCTL_API=3 etcdctl --help
• ps aux | grep etcd
• sudo ETCDCTL API=3 etcdctl --endpoints=localhost:2379 --cacert
/etc/kubernetes/pki/etcd/ca.crt--cert
/etc/kubernetes/pki/etcd/server.crt--key
/etc/kubernetes/pki/etcd/server.key get / --prefix --keys-only
• sudo ETCDCTL API=3 etcdctl --endpoints=localhost:2379 --cacert
/etc/kubernetes/pki/etcd/ca.crt--cert
/etc/kubernetes/pki/etcd/server.crt--key
/etc/kubernetes/pki/etcd/server.key snapshot save /tmp/etcdbackup.db

Demo: Verifying the Etcd Backup

• sudo ETCDCTL _API=3 etcdctl --write-out=table snapshot status
/tmp/etcdbackup.db
• Just to be sure: cp /tmp/etcdbackup.db /tmp/etcdbackup.db.2

Understanding the Procedure

• sudo ETCDCTL API=3 etcdctl snapshot restore /tmp/etcdbackup.db -- data-dir
/var/lib/etcd-backup restores the etcd backup in a non-default folder
• To start using it, the Kubernetes core services must be stopped, after which the etc can
be reconfigured to use the new directory
• To stop the core services, temporarily move /etc/kubernetes/manifests/*.yaml to
/etc/kubernetes/
• As the kubelet process temporarily polls for static Pod files, the etcd process will
disappear within a minute
• Use sudo crictl ps to verify that is has been stopped
 Understanding the Procedure
• Once the etcd Pod has stopped, reconfigure the etcd to use the non- default etcd path
• In etc.yaml you'll find a HostPath volume with the name etcd-data, pointing to the
location where the Etcd files are found. Change this to the location where the restored
files are
• Move back the static Pod files to /etc/kubernetes/manifests/
• Use sudo crictl ps to verify the Pods have restarted successfully
• Next, kubectl get all should show the original Etc resources

Demo: Restoring the Etcd

• kubectl delete -all deploy
• cd/etc/kubernetes/manifests/
• sudo mv * .. # this will stop all running pods
• sudo crictl ps
• sudo ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcdbackup.db --data-dir
/var/lib/etcd-backup
• sudo Is -l /var/lib/etcd-backup/
• sudo vi /etc/kubernetes/etcd.yaml # change etcd-data HostPath volume to
/var/lib/etcd-backup
• sudo mv ../*.yaml .
• sudo crictl ps # should show all resources
• kubectl get deploy -A

Upgrade Cluster
Understanding the Procedure
• Kubernetes clusters can be upgraded from one to another minor versions
• Skipping minor versions (1.23 to 1.25) is not supported
• First, you'll have to upgrade kubeadm
• Next, you'll need to upgrade the control plane node
• After that, the worker nodes are upgraded

Exam Tip! Use "Upgrading kubeadm clusters" from the documentation

 Control Plane Node Upgrade Overview
• upgrade kubeadm
• use kubeadm upgrade plan to check available versions
• use kubeadm upgrade apply v1.xx.y to run the upgrade
• use kubectl drain controlnode --ignore-daemonsets
• upgrade and restart kubelet and kubectl
• use kubectl uncordon controlnode to bring back the control node
• proceed with other nodes

Lesson 7: Performing Node Maintenance Tasks

Understanding HA Options
• Stacked control plane nodes requires less infrastructure as the etcd members, and
control plane nodes are co-located
o Control planes and etcd members are running together on the same node
o For optimal protection, requires a minimum of 3 stacked control plane nodes
• External etcd cluster requires more infrastructure as the control plane nodes and etcd
members are separated
o Eted service is running on external nodes, so this requires twice the number of
nodes
 HA Requirements
• In a Kubernetes HA cluster, a load balancer is needed to distribute the workload
between the cluster nodes
• The load balancer can be externally provided using open-source software, or a load
balancer appliance
• Knowledge of setting up the load balancer is not required on the CKA exam: in this
course a load balancer setup script is provided
 Exploring Load Balancer Configuration
• In the load balancer setup, HAProxy is running on each server to provide access to
port 8443 on all IP addresses on that server
• Incoming traffic on port 8443 is forwarded to the kube-apiserver port 6443
• The keepalived service is running on all HA nodes to provide a virtual IP address on
one of the nodes
• kubectl clients connect to this VIP:8443,
• Use the setup-Ib-ubuntu.sh script provided in the GitHub repository for easy setup
• Additional instructions are in the script
• After running the load balancer setup, use nc 192.168.29.100 8443 to verify the
availability of the load balancer IP and port

Cluster Node Requirements

• 3 VMs to be used as controllers in the cluster; Install K8s software but don't set up the
cluster yet
• 2 VMs to be used as worker nodes; Install K8s software
• Ensure /etc/hosts is set up for name resolution of all nodes and copy to all nodes
• Disable selinux on all nodes if applicable
• Disable firewall if applicable

Initializing the HA Setup

• sudo kubeadm init --control-plane-endpoint "192.168.29.100:8443" --upload-
certs
o Save the output of the command which shows next steps
• Configure networking
o kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
• Copy the kubectl join command that was printed after successfully initializing the
first control node
o Make sure to use the command that has --control-plane in it!
• Complete setup on other control nodes as instructed
• Use kubectl get nodes to verify setup
• Continue and join worker nodes as instructed
 Configuring the HA Client
• On the machine you want to use as operator workstation, create a .kube directory and
copy /etc/kubernetes/admin.conf from any control node to the client machine
• Install the kubectl utility
• Ensure that host name resolution goes to the new control plane VIP
• Verify using kubectl get nodes

Testing it
• On all nodes: find the VIP using ip a
• On all nodes with a kubectl, use kubectl get all to verify client working
• Shut down the node that has the VIP
• Verify that kubectl get all still works
• Troubleshooting: consider using sudo systemctl restart haproxy

Lesson 7 Lab: Etcd Backup and Restore

• Create a backup of the etcd
• Remove a few resources (Pods and/or Deployments)
• Restore the backup of the eted and verify that gets your resources back

Understanding Scheduling
• Kube-scheduler takes care of finding a node to schedule new Pods
• Nodes are filtered according to specific requirements that may be set
o Resource requirements
o Affinity and anti-affinity
o Taints and tolerations and more
• The scheduler first finds feasible nodes then scores them; it then picks the node with
the highest score
• Once this node is found, the scheduler notifies the API server in a process called
binding
 From Scheduler to Kubelet
• Once the scheduler decision has been made, it is picked up by the kubelet
• The kubelet will instruct the CRI to fetch the image of the required container
• After fetching the image, the container is created and started

Setting Node Preferences

• The nodeSelector field in the pod.spec specifies a key-value pair that must match a
label which is set on nodes that are eligible to run the Pod
• Use kubectl label nodes worker1.example.com disktype=ssd to set the label on a
node
• Use nodeSelector: disktype: ssd in the pod.spec to match the Pod to the specific
node
• nodeName is part of the pod.spec and can be used to always run a Pod on a node with
a specific name
o Not recommended: if that node is not currently available; the Pod will never
run

Demo: Using Node Preferences

• kubectl label nodes worker2 disktype=ssd
• kubectl apply -f selector-pod.yaml

Understanding Affinity and Anti-Affinity

• (Anti-)Affinity is used to define advanced scheduler rules
• Node affinity is used to constrain a node that can receive a Pod by matching labels of
these nodes
• Inter-pod affinity constrains nodes to receive Pods by matching labels of existing Pods
already running on that node
• Anti-affinity can only be applied between Pods
 Understanding Affinity and Anti-Affinity
• (Anti-)Affinity is used to define advanced scheduler rules
• Node affinity is used to constrain a node that can receive a Pod by matching labels of
these nodes
• Inter-pod affinity constrains nodes to receive Pods by matching labels of existing Pods
already running on that node
• Anti-affinity can only be applied between Pods

How it Works
• A Pod that has a node affinity label of key=value will only be scheduled to nodes with
a matching label
• A Pod that has a Pod affinity label of key=value will only be scheduled to nodes
running Pods with the matching label

Setting Node Affinity

• To define node affinity, two different statements can be used
• requiredDuringSchedulinglgnoredDuringExecution requires the node to
• meet the constraint that is defined
• preferredDuringSchedulingIgnoredDuringExecution defines a soft affinity that is
ignored if it cannot be fulfilled
• At the moment, affinity is only applied while scheduling Pods, and cannot be used to
change where Pods are already running
 Defining Affinity Labels
• Affinity rules go beyond labels that use a key=value label
• A matchexpression is used to define a key (the label), an operator as well as optionally
one or more values
affinity:
nodeAffinity:
required DuringScheduling|gnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: type
operator: In
values:
- blue
- green
• Matches any node that has type set to either blue or green

Defining Affinity Labels

nodeSelectorTerms:
- matchExpressions:
- key: storage
operator: Exists
• Matches any node where the key storage is defined

Demo: Checking Out Some Examples

• pod-with-node-affinity.yaml
• pod-with-node-anti-affinity.yaml
• pod-with-pod-affinity.yaml
 Understanding TopologyKey
• When defining Pod affinity and anti-affinity, a toplogyKey property is required
• The topologyKey refers to a label that exists on nodes, and typically has a format
containing a slash
o kubernetes.io/host
• Using topologyKeys allows the Pods only to be assigned to hosts matching the
topologyKey
• This allows administrators to use zones where the workloads are implemented
• If no matching topologyKey is found on the host, the specified topologyKey will be
ignored in the affinity

Demo: Using Pod Anti-Affinity

• kubectl create -f redis-with-pod-affinity.yaml
• On a two-node cluster, one Pod stays in a state of pending
• kubectl create -f web-with-pod-affinity.yaml
• This will run web instances only on nodes where redis is running as well

Understanding Taints
• Taints are applied to a node to mark that the node should not accept any Pod that
doesn't tolerate the taint
• Tolerations are applied to Pods and allow (but do not require) Pods to schedule on
nodes with matching Taints so they are an exception to taints that are applied
• Where Affinities are used on Pods to attract them to specific nodes, Taints allow a
node to repel a set of Pods
• Taints and Tolerations are used to ensure Pods are not scheduled on inappropriate
nodes, and thus make sure that dedicated nodes can be configured for dedicated tasks

Understanding Taint Types

• Three types of Taint can be applied:
o NoSchedule: does not schedule new Pods
o PreferNoSchedule: does not schedule new Pods, unless there is no other
option
o NoExecute: migrates all Pods away from this node
• If the Pod has a toleration however, it will ignore the taint
 Setting Taints
• Taints are set in different ways
• Control plane nodes automatically get taints that won't schedule user Pods
• When kubectl drain and kubectl cordon are used, a taint is applied on the target node
• Taints can be set automatically by the cluster when critical conditions arise, such as a
node running out of disk space
• Administrators can use kubectl taint to set taints:
o kubectl taint nodes worker1 key1=value1:NoSchedule
o kubectl taint nodes worker1 key1=value1:NoSchedule-

Understanding Tolerations
• To allow a Pod to run on a node with a specific taint, a toleration can be used
• This is essential for running core Kubernetes Pods on the control plane nodes
• While creating taints and tolerations, a key and value are defined to allow for more
specific access
o kubectl taint nodes worker1 storage=ssd:NoSchedule
• This will allow a Pod to run if it has a toleration containing the key storage
• and the value ssd

Understanding Taint Key and Value

• While defining a toleration, the Pod needs a key, operator, and value:
tolerations:
- key: "storage"
operator: "Equal"
value: "ssd"
• The default value for the operator is "Equal"; as an alternative, "Exists" is commonly
used
• If the operator "Exists" is used, the key should match the taint key and the value is
ignored
• If the operator "Equal" is used, the key and value must match
 Node Conditions and Taints
• Node conditions can automatically create taints on nodes if one of the following
applies
o memory-pressure
o disk-pressure
o pid-pressure
o unschedulable
o network-unavailable
• If any of these conditions apply, a taint is automatically set
• Node conditions can be ignored by adding corresponding Pod tolerations

Demo: Using Taints

• kubectl taint nodes worker1 storage=ssd:NoSchedule
• kubectl describe nodes worker1
• kubectl create deployment nginx-taint--image=nginx
• kubectl scale deployment nginx-taint-replicas=3
• kubectl get pods -o wide # will show that pods are all on worker2
• kubectl create -f taint-toleration.yaml # will run
• kubectl create -f taint-toleration2.yaml # will not run

Understanding LimitRange
• LimitRange is an API object that limits resource usage per container or Pod in a
Namespace
• It uses three relevant options:
o type: specifies whether it applies to Pods or containers
o defaultRequest: the default resources the application will request
o default: the maximum resources the application can use
 Understanding Quota
• Quota is an API object that limits total resources available in a Namespace
• If a Namespace is configured with Quota, applications in that Namespace must be
configured with resource settings in pod.spec.containers.resources
• Where the goal of the LimitRange is to set default restrictions for each application
running in a Namespace, the goal of Quota is to define maximum resources that can be
consumed within a Namespace by all applications

Demo: Managing Quota

• kubectl create quota qtest --hard pods=3, cpu=100m, memory=500Mi --
namespace limited
• kubectl describe quota -namespace limited
• kubectl create deploy nginx -image=nginx:latest --replicas=3 -n limited
• kubectl get all -n limited # no pods
• kubectl describe rs/nginx-xxx -n limited # it fails because no quota have been set on
the deployment
• kubectl set resources deploy nginx --requests cpu=100m, memory=5Mi --limits
cpu=200m,memory=20Mi -n limited
• kubectl get pods -n limited

Demo: Defining Limitrange

• kubectl explain limitrange.spec
• kubectl create ns limited
• kubectl apply -f limitrange.yaml -n limited
• kubectl describe ns limited
• kubectl run limitpod -image=nginx -n limited
• kubectl describe pod limitpod -n limited
 Lesson 8 Lab: Configuring Taints
• Create a taint on node worker2, that doesn't allow new Pods to be scheduled that don't
have an SSD hard disk, unless they have the appropriate toleration set
• Remove the taint after verifying that it works

Understanding the CNI

• The Container Network Interface (CNI) is the common interface used for networking
when starting kubelet on a worker node
• The CNI doesn't take care of networking, that is done by the network plugin
• CNI ensures the pluggable nature of networking, and makes it easy to select between
different network plugins provided by the ecosystem

Exploring CNI Configuration

• The CNI plugin configuration is in /etc/cni/net.d
• Some plugins have the complete network setup in this directory
• Other plugins have generic settings, and are using additional configuration
• Often, the additional configuration is implemented by Pods
• Generic CNI documentation is on https://github.com/containernetworking/cni

Understanding Service Auto Registration

• Kubernetes runs the coredns Pods in the kube-system Namespace as internal DNS
servers
• These Pods are exposed by the kubedns Service
• Service register with this kubedns Service
• Pods are automatically configured with the IP address of the kubedns Service as their
DNS resolver
• As a result, all Pods can access all Services by name
 Accessing Service in other Namespaces
• If a Service is running in the same Namespace, it can be reached by the short
hostname
• If a Service is running in another Namespace, an FQDN consisting of
servicename.namespace.svc.clustername must be used
• The clustername is defined in the coredns Corefile and set to cluster.local if it hasn't
been changed, use kubectl get cm -n kube-system coredns -o yaml to verify

Demo: Accessing Services by Name

• kubectl run webserver --image=nginx
• kubectl expose pod webserver --port=80
• kubectl run testpod --image=busybox -- sleep 3600
• kubectl get svc
• kubectl exec -it testpod -- wget webserver

Demo: Accessing Pods in other Namespaces

• kubectl create ns remote
• kubectl run interginx --image=nginx
• kubectl run remotebox --image=busybox -n remote -- sleep 3600
• kubectl expose pod interginx --port=80
• kubectl exec -it remotebox -n remote -- cat /etc/resolv.conf
• kubectl exec -it remotebox -n remote -- nslookup interginx # fails
• kubectl exec -it remotebox -n remote – nslookup
interginx.default.svc.cluster.local

Understanding NetworkPolicy
• By default, there are no restrictions to network traffic in K8s
• Pods can always communicate, even if they're in other Namespaces
• To limit this, NetworkPolicies can be used
• NetworkPolicies need to be supported by the network plugin though
o The weave plugin does NOT support NetworkPolicies!
• If in a policy there is no match, traffic will be denied
• If no NetworkPolicy is used, all traffic is allowed
 Using NetworkPolicy Identifiers
• In NetworkPolicy, three different identifiers can be used
o Pods: (podSelector) note that a Pod cannot block access to itself
o Namespaces: (namespaceSelector) to grant access to specific Namespaces
o IP blocks: (ipBlock) notice that traffic to and from the node where a Pod is
running is always allowed
• When defining a Pod- or Namespace-based NetworkPolicy, a selector label is used to
specify what traffic is allowed to and from the Pods that match the selector
• NetworkPolicies do not conflict, they are additive

Demo: Exploring NetworkPolicy

• kubectl apply -f nwpolicy-complete-example.yaml
• kubectl expose pod nginx --port=80
• kubectl exec -it busybox -- wget --spider --timeout=1 nginx will fail
• kubectl label pod busybox access=true
• kubectl exec -it busybox -- wget -spider --timeout=1 nginx will work

Applying NetworkPolicy to Namespaces

• To apply a NetworkPolicy to a Namespace, use -n namespace in the definition of the
NetworkPolicy
• To allow ingress and egress traffic, use the namespaceSelector to match
• the traffic

Demo: Using NetworkPolicy between Namespaces

• kubectl create ns nwp-namespace
• kubectl create -f nwp-lab9-1.yaml
• kubectl expose pod nwp-nginx --port=80
• kubectl exec -it nwp-busybox -n nwp-namespace -- wget -spider -- timeout=1
nwp-nginx: gives a bad address error
• kubectl exec -it nwp-busybox -n nwp-namespace -- nslookup nwp-nginx
explains that it's looking in the wrong ns
• kubectl exec -it nwp-busybox -n nwp-namespace -- wget --spider -- timeout=1
nwp-nginx.default.svc.cluster.local is allowed
 Demo: Using NetworkPolicy between Namespaces
• kubectl create -f nwp-lab9-2.yaml
• kubectl exec -it nwp-busybox -n nwp-namespace -- wget --spider -- timeout=1
nwp-nginx.default.svc.cluster.local is not allowed
• kubectl create deployment busybox --image=busybox -- sleep 3600
• kubectl exec -it busybox[Tab] - wget --spider --timeout=1 nwp-nginx

Lesson 9 Lab: Using NetworkPolicies

• Run a webserver with the name lab9server in Namespace restricted, using the Nginx
image and ensure it is exposed by a Service
• From the default Namepsace start two Pods: sleepybox1 and sleepybox2, each based
on the Busybox image using the sleep 3600 command as the command
• Create a NetworkPolicy that limits Ingress traffic to restricted, in such a way that only
the sleepybox1 Pod from the default Namespace has access and all other access is
forbidden

Understanding API Access

 Understanding SecurityContext
• A SecurityContext defines privilege and access control settings for Pods or containers
and can include the following:
o UID- and GID-based Discretionary Access Control
o SEinux security labels
o Linux Capabilities
o AppArmor
o Seccomp
o The AllowPrivilege Escalation setting
o The runAsNonRoot setting

Setting SecurityContext
• SecurityContext can be set at Pod level as well as container level
• See kubectl explain pod.spec.securityContext
• Also see kubectl explain pod.spec.containers.securityContext
• Settings applied at the container level will overwrite settings applied at the Pod level

Demo: Setting SecurityContext

• kubectl apply -f security-context.yaml
• kubectl get pod security-context-demo
• kubectl exec -it security-context-demo--sh
o ps #will show processes running UID 1000
o cd /data; ls -l #will show fsGroup as owning GID
o id
o exit

Understanding Kubernetes Users

• The Kubernetes API doesn't define users for people to authenticate and authorize
• Users are obtained externally
o Defined by X.509 certificates
o Obtained from external OpenlD-based authentication (Google, AD and many
more)
• ServiceAccounts are used to authorize Pods to get access to specific API resources
 Cordon a node in Kubernetes

In Kubernetes, marking a node as "cordon" is a way of telling the cluster that the node should
not be scheduled with any new pods. This is typically done when a node is undergoing
maintenance or is experiencing issues that make it unsuitable for running new workloads.

When a node is marked as "cordon", the Kubernetes scheduler will no longer consider it as a
candidate for placing new pods. However, any existing pods running on the node will
continue to run until they complete or are terminated. This allows for graceful draining of the
node and prevents new workloads from being scheduled on an already problematic node.

Once the maintenance or issue with the node is resolved, it can be marked as "uncordon" to
allow the Kubernetes scheduler to again consider it as a candidate for scheduling new pods.
This ensures that the cluster can efficiently use all available resources while also maintaining
high availability and reliability of workloads.

HA Options in Kubernetes
In Kubernetes, the control plane components, including the API server, etcd, and scheduler,
are responsible for managing the cluster state and scheduling workloads. When it comes to
High Availability (HA), it is recommended to replicate these components across multiple
nodes or machines to ensure that the system remains operational even in the face of failures or
outages.

One option for achieving HA with the control plane is to use stacked control plane nodes. In
this configuration, multiple control plane nodes are deployed on separate machines, and each
node contains a replica of all control plane components. This provides redundancy at the
control plane level and allows the system to continue functioning even if one or more nodes
fail.

Another option for achieving HA is to use an external etcd cluster. etcd is a distributed key-
value store that Kubernetes uses to store the cluster state. In this configuration, an external
etcd cluster is set up and integrated with the Kubernetes control plane. This allows the etcd
cluster to be managed separately from the Kubernetes cluster, providing additional fault
tolerance and allowing for easier maintenance and upgrades.

When using an external etcd cluster, it is important to ensure that the etcd cluster itself is
highly available and has redundancy built in. This can be achieved by deploying multiple etcd
nodes across different machines or using a distributed datastore solution.

Overall, using stacked control plane nodes and/or an external etcd cluster are both viable
options for achieving HA in Kubernetes. The choice of which option to use will depend on the
specific requirements and constraints of the deployment environment, as well as the level of
expertise and resources available to manage and maintain the system.
 HA Kubernetes

Setting Node Preferences

NodeSelector and NodeName are used in Kubernetes to schedule pods onto specific nodes in
the cluster.

NodeSelector allows you to specify a set of key-value pairs that must match the labels on
a node for a pod to be scheduled on that node. This is useful when you want to schedule
pods onto nodes with specific characteristics or hardware capabilities. For example, if
you have nodes with GPUs, you can use NodeSelector to ensure that pods that require GPUs
are only scheduled on those nodes.

NodeName, on the other hand, allows you to specify the name of a specific node on
which a pod should be scheduled. This is useful when you have a specific node that you
want to use for a particular pod. For example, if you have a node that is dedicated to
running a specific database, you can use NodeName to ensure that the pod for that database is
always scheduled on that node.

In summary, NodeSelector and NodeName are used in Kubernetes to give you more control
over where your pods are scheduled in the cluster, based on specific requirements or
constraints.
 Affinity and Anti-Affinity
In Kubernetes, Affinity and Anti-Affinity are used to influence the scheduling of pods on
nodes in a cluster.

Affinity is a way to specify preferences for scheduling pods based on the characteristics of the
nodes in the cluster. There are two types of Affinity:

1. Node Affinity: This allows you to specify rules for scheduling pods on nodes based
on node labels, which are key-value pairs that are attached to nodes. For example, you
can use Node Affinity to ensure that pods are scheduled only on nodes that have
specific hardware capabilities, such as GPUs.
2. Pod Affinity: This allows you to specify rules for scheduling pods based on the labels
of other pods running on the same node. For example, you can use Pod Affinity to
ensure that related services are co-located on the same node to reduce latency.

Good example of Pod Affinity: Suppose you have two microservices in your cluster, a web
frontend and a backend API, and you want to ensure that they are co-located on the same
node to reduce latency and improve performance. You can use Pod Affinity to achieve this.

Anti-Affinity is the opposite of Affinity and is used to specify rules for scheduling pods so
that they are not co-located on the same node. This is useful when you want to ensure high
availability and fault tolerance by ensuring that pods are not running on the same node and are
distributed across the cluster. There are two types of Anti-Affinity:

1. Node Anti-Affinity: This allows you to specify rules for scheduling pods on nodes
such that they are not scheduled on nodes that have specific labels. This is useful when
you want to ensure that pods are not scheduled on nodes that have low capacity or
are experiencing issues.
2. Pod Anti-Affinity: This allows you to specify rules for scheduling pods so that they
are not scheduled on the same node as other pods with specific labels. This is useful
when you want to ensure that related services are not co-located on the same
node to reduce the risk of downtime.

Good Example of Anti-Affinity: Suppose you have a stateful application that requires high
availability and fault tolerance, and you want to ensure that replicas of the same stateful
application are not running on the same node to avoid a single point of failure. You can use
Pod Anti-Affinity to achieve this.

In summary, Affinity and Anti-Affinity are used to specify rules for scheduling pods on nodes
in a Kubernetes cluster, based on node or pod labels. Affinity is used to specify preferences
for scheduling, while Anti-Affinity is used to avoid co-locating pods on the same node.
 Types of Node Affinity in Kubernetes with examples:
1. requiredDuringSchedulingIgnoredDuringExecution: This type of Node Affinity
is used to ensure that a pod is scheduled on a node that matches the specified label
selectors. If no matching node is available, the pod will not be scheduled. For
example, the following rule specifies that the pod should be scheduled on a node that
has the label disktype=ssd
2. preferredDuringSchedulingIgnoredDuringExecution: This type of Node
Affinity is used to express a preference for scheduling a pod on a node that matches
the specified label selectors. If no matching node is available, the pod can still be
scheduled on a node that does not match the label selectors. For example, the
following rule specifies that the pod should be scheduled on a node that has the label
disktype=ssd, but if no such node is available, it can be scheduled on any node:

Topology Key
In Kubernetes, Topology Key is a property of a Node that is used to specify the
topology domain of the Node. It is used in Node Affinity rules to schedule a pod on a Node
that matches the topology domain of the pod.

Topology Key is used to express the hierarchical relationships between nodes in a

cluster. For example, you might have a cluster with nodes in different regions, availability
zones, or rack locations. In this case, you can use Topology Key to ensure that a pod is
scheduled on a node that is in the same region, availability zone, or rack location as other
pods.
 Taints and Tolerations
In Kubernetes, Taints and Tolerations are used to control which nodes are eligible to schedule
a pod. A Taint is a label that is applied to a node, while a Toleration is a property of a pod that
allows it to be scheduled on nodes with specific Taints.

Taints
Taints are used to mark a node as unsuitable for scheduling a pod. When a Taint is applied to
a node, it tells Kubernetes to not schedule any pod on that node unless the pod has a
corresponding Toleration that matches the Taint.

A Taint consists of three parts:

1. Key: A string that identifies the Taint.

2. Value: A string that provides additional information about the Taint.
3. Effect: A string that specifies the effect of the Taint. There are three possible values
for the effect: NoSchedule, PreferNoSchedule, and NoExecute.

Here's an example of how to apply a Taint to a node:

kubectl taint nodes node-name key=value:effect

In this example, the node-name parameter specifies the name of the node, key=value
specifies the key-value pair for the Taint, and effect specifies the effect of the Taint.

Tolerations
Tolerations are used to specify which Taints a pod can tolerate. When a pod has a Toleration
that matches a Taint on a node, Kubernetes can schedule the pod on that node.

A Toleration consists of three parts:

1. Key: A string that identifies the Taint that the Toleration matches.
2. Value: A string that matches the value of the Taint, if the Taint has a value.
3. Effect: A string that specifies the effect of the Taint that the Toleration matches.
Here's an example of how to specify a Toleration in a pod:

yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
tolerations:
- key: key
operator: Equal
value: value
effect: NoSchedule

In this example, the key parameter specifies the key of the Taint, the value parameter
specifies the value of the Taint (if any), and the effect parameter specifies the effect of the
Taint.

Together, Taints and Tolerations provide a powerful way to control which nodes are eligible
to schedule a pod. By applying Taints to nodes and specifying Tolerations in pods, you can
ensure that your pods are scheduled on the nodes that meet your specific requirements.

LimitRange and Quota

LimitRange and Quota are Kubernetes resource management objects that help
administrators control resource usage in a cluster.

LimitRange is used to specify resource limits for a particular namespace. It allows you to set
minimum and maximum values for CPU, memory, and storage resources for all the pods
within a namespace. LimitRanges can be defined for any resource that is stored in the
Kubernetes API server.

For example, a LimitRange could be defined to ensure that all pods within a namespace use
no more than 1GB of memory and 1 CPU.

Quota, on the other hand, is used to set a hard limit on the total amount of resources that can
be used by all pods in a namespace. Quota can be defined for CPU, memory, storage, and
other resources, and it can be applied to any namespace.

For example, a Quota could be defined to limit the total amount of memory used by all pods
in a namespace to 4GB.

The difference between LimitRange and Quota is that LimitRange sets limits on a per-pod
basis within a namespace, while Quota sets limits on the total amount of resources used by all
pods within a namespace.
Both LimitRange and Quota can be used to prevent resource starvation, ensure fair allocation
of resources among pods, and prevent runaway pods from consuming too many resources.
They are both useful tools for managing resource usage in a Kubernetes cluster.

A "limit" refers to the maximum amount of a resource that a container in a pod can consume.
When a container reaches its limit, Kubernetes will automatically kill the container and
attempt to restart it. The limit is specified in the pod's configuration using the limits field.

A "request" refers to the amount of a resource that a container in a pod requests as a

minimum. Kubernetes will ensure that this amount of the resource is always available to the
container. The request is specified in the pod's configuration using the requests field.

Le service d'enregistrement automatique dans

Kubernetes
Le service d'enregistrement automatique dans Kubernetes est une fonctionnalité qui
permet aux pods (les unités de base dans Kubernetes) de s'inscrire automatiquement auprès
d'un service DNS interne.

Concrètement, lorsqu'un pod est créé, il peut enregistrer automatiquement son adresse IP et
son nom auprès du service DNS Kubernetes, qui peut alors être utilisé pour découvrir et
communiquer avec le pod.

Le service d'enregistrement automatique dans Kubernetes est réalisé à l'aide du contrôleur

Kubernetes appelé kubelet, qui surveille l'état des pods et les enregistre automatiquement
auprès du service DNS Kubernetes.

Cette fonctionnalité simplifie la configuration et la gestion des pods dans Kubernetes, en

évitant aux administrateurs de devoir configurer manuellement les adresses IP et les noms de
chaque pod dans les fichiers de configuration.
 Understanding API Access

Sure, let me break down the different concepts you've mentioned:

1. API: An API (Application Programming Interface) is a set of protocols, routines, and

tools for building software applications. It specifies how software components should
interact and enables communication between different software applications.
2. Pod: A Pod is the smallest deployable unit in Kubernetes. A Pod is a single instance of
a running process in a cluster.
3. Service Account: A Service Account is an identity that is attached to a Pod. It provides
a way to authenticate and authorize access to the Kubernetes API server.
4. kubectl: kubectl is the command-line interface for interacting with a Kubernetes
cluster. It allows you to deploy, inspect, and manage applications in a Kubernetes
cluster.
5. RoleBinding: A RoleBinding is a Kubernetes object that binds a role to a user or
group, providing them with permissions to perform certain actions in a cluster.
6. Role/ClusterRole: A Role or ClusterRole is a Kubernetes object that defines a set of
permissions or access control rules for a specific set of resources in a namespace or
cluster-wide, respectively.
7. API Server: The API Server is the component in a Kubernetes cluster that exposes the
Kubernetes API. It is the primary interface for managing and interacting with a
Kubernetes cluster.
8. etcd: etcd is a distributed key-value store that is used by Kubernetes to store and
manage cluster configuration data.

In summary, understanding how to access the Kubernetes API server, managing Kubernetes
objects like Roles and RoleBindings, and understanding the different components in a
Kubernetes cluster like Pods and Services Accounts are all essential for working with
Kubernetes.
 SecurityContext:
Le "security context" dans Kubernetes est une fonctionnalité qui permet de définir et de
contrôler les niveaux de sécurité des conteneurs s'exécutant dans un cluster Kubernetes.

En définissant un "security context", vous pouvez spécifier divers paramètres de sécurité pour
un conteneur, tels que l'utilisateur et le groupe d'utilisateur qui exécute le conteneur, les
privilèges et les capacités du conteneur, les politiques de sécurité du système de fichiers, etc.

Ces paramètres de sécurité peuvent être définis à différents niveaux, tels que le niveau du
conteneur, du pod ou du namespace. En outre, vous pouvez également utiliser des "security
contexts" pour contrôler l'accès à certains objets Kubernetes, tels que les secrets et les
ConfigMaps.

En résumé, les "security contexts" dans Kubernetes permettent aux administrateurs de cluster
de contrôler les niveaux de sécurité des conteneurs s'exécutant dans un cluster Kubernetes, ce
qui contribue à réduire les risques de sécurité et à protéger les applications s'exécutant dans le
cluster.

ServiceAccount
En Kubernetes, un "ServiceAccount" est un objet qui permet à un pod ou à un ensemble de
pods d'interagir avec l'API Kubernetes et d'accéder à des ressources spécifiques. Il sert à
autoriser et à identifier les applications s'exécutant dans le cluster.

Un exemple concret d'utilisation de ServiceAccount pourrait être un déploiement d'application

qui a besoin d'accéder à certaines ressources Kubernetes, telles que des secrets, des
ConfigMaps ou des volumes partagés. Au lieu d'utiliser les informations d'identification de
l'utilisateur ou du cluster, vous pouvez créer un ServiceAccount pour cette application et
l'utiliser pour accéder aux ressources nécessaires.

Prenons un exemple plus concret. Supposons que vous ayez une application web déployée
dans un cluster Kubernetes qui doit accéder à un secret contenant des informations sensibles
telles que des clés d'API ou des informations d'identification. Pour accéder à ce secret, vous
pouvez créer un ServiceAccount pour l'application et lui donner les autorisations appropriées
pour accéder au secret.

Une fois le ServiceAccount créé, vous pouvez l'associer à la définition de déploiement de

l'application pour qu'il soit automatiquement injecté dans chaque pod de l'application. Le pod
peut ensuite utiliser les informations d'identification du ServiceAccount pour accéder au
secret et ainsi éviter d'avoir à stocker ces informations sensibles directement dans le code ou
les fichiers de configuration de l'application.

En résumé, ServiceAccount est utilisé pour autoriser et identifier les applications s'exécutant
dans le cluster Kubernetes, en particulier lorsqu'elles ont besoin d'accéder à des ressources
spécifiques, telles que des secrets ou des ConfigMaps. Cela permet de renforcer la sécurité
des applications et de mieux contrôler l'accès aux ressources du cluster.
Je vais essayer de vous expliquer la relation entre les différents concepts que vous avez
mentionnés dans le contexte de Kubernetes :

• API Server : Le serveur API Kubernetes est le point d'entrée pour toutes les
opérations liées à Kubernetes. Il expose l'API Kubernetes et traite les requêtes des
utilisateurs.
• Kubectl : Kubectl est l'interface en ligne de commande (CLI) que vous pouvez utiliser
pour interagir avec l'API Kubernetes et gérer les ressources Kubernetes telles que les
pods, les services, les deployments, les etc.
• kube/config : Le fichier kube/config contient les informations d'authentification et de
configuration de votre cluster Kubernetes. Il est utilisé par kubectl pour accéder à
l'API Kubernetes.
• Service Account : Un compte de service est une identité de sécurité utilisée par les
applications pour accéder aux ressources Kubernetes. Les comptes de service sont
associés à des autorisations pour accéder à des ressources spécifiques du cluster.
• Rôles (Roles) : Les rôles Kubernetes sont des objets qui définissent un ensemble de
permissions pour accéder à des ressources spécifiques dans un espace de noms
(namespace) particulier. Par exemple, un rôle peut être défini pour accorder
l'autorisation de créer des pods dans un espace de noms donné.
• Cluster Roles : Les cluster roles Kubernetes sont similaires aux rôles, mais ils sont
définis pour l'ensemble du cluster, plutôt que pour un espace de noms particulier. Ils
sont utilisés pour définir des autorisations qui s'appliquent à l'ensemble du cluster,
telles que l'accès en lecture seule à tous les pods du cluster.
• Role Bindings (Liaison de rôles) : Les liaisons de rôles sont des objets qui lient un
rôle à un ou plusieurs utilisateurs ou comptes de service. Elles définissent les
autorisations d'accès pour un utilisateur ou un compte de service dans un espace de
noms donné.
• Cluster Role Bindings (Liaison de rôles de cluster) : Les liaisons de rôles de cluster
sont similaires aux liaisons de rôles, mais elles sont utilisées pour lier des cluster roles
à des utilisateurs ou des comptes de service. Elles définissent les autorisations d'accès
pour un utilisateur ou un compte de service à l'échelle du cluster.
• Pods : Les pods sont les unités de base du déploiement des applications Kubernetes.
Ils sont utilisés pour exécuter des conteneurs sur des nœuds du cluster.

En résumé, l'API Kubernetes fournit des objets de sécurité tels que les rôles et les cluster roles
qui définissent des autorisations d'accès pour les utilisateurs et les comptes de service. Les
liaisons de rôles et les liaisons de rôles de cluster sont utilisées pour lier ces rôles aux
utilisateurs et aux comptes de service. Les comptes de service sont utilisés pour permettre aux
applications d'accéder aux ressources Kubernetes. Kubectl et kube/config sont utilisés pour
interagir avec l'API Kubernetes et gérer les ressources Kubernetes, y compris les rôles, les
comptes de service et les pods.
 Best practices to follow when deploying applications in
Kubernetes
1. Use version control: Use a version control system to track changes to your application
code, Kubernetes configurations, and other deployment artifacts. This will help you
keep track of changes and enable you to roll back to a previous version if necessary.
2. Create a staging environment: Set up a staging environment to test your application
before deploying it to production. This will allow you to catch any issues or bugs
before they impact users in the production environment.
3. Use a CI/CD pipeline: Automate your deployment process using a Continuous
Integration/Continuous Deployment (CI/CD) pipeline. This will help you ensure that
your application is tested and deployed consistently and reliably.
4. Use health checks: Use Kubernetes health checks to ensure that your application is
running correctly. This will allow Kubernetes to automatically restart your application
if it crashes or becomes unresponsive.
5. Use resource limits: Set resource limits for your application to ensure that it doesn't
consume too many resources and impact other applications running in the same
cluster.
6. Use a horizontal scaling strategy: Use a horizontal scaling strategy to ensure that your
application can handle increasing traffic. This will allow Kubernetes to automatically
scale up your application when traffic increases and scale it down when traffic
decreases.
7. Secure your deployments: Implement security best practices for your Kubernetes
clusters, such as using RBAC (Role-Based Access Control) to limit access to your
resources, using TLS certificates for secure communication, and regularly patching
and updating your software.
8. Monitor your deployments: Use Kubernetes monitoring and logging tools to monitor
the health and performance of your application. This will allow you to detect and
resolve issues before they impact users.

By following these best practices, you can ensure that your Kubernetes deployments are
reliable, secure, and scalable.