A Kubernetes cluster is a set of machines (the nodes) hosting the execution of a wide variety of containers for several applications deployed by different users.
Users interact remotely with this cluster using the kubectl command.
Immediately try the kubectl config view command and note that it does not designate any cluster for the time being.
For the purposes of this tutorial, users have been prepared in advance with an associated namespace in order to keep each user's work separate.
The session supervisor should tell you which one you will use to interact with the cluster; it has the form gX-YY (g1-09, g2-17...)✍.
Then install the configuration file for the selected user in your account: Make sure to replace gX-YY with the name of the selected user.
Now run kubectl config view again and note that you will address the cluster at https://kube.enib.fr:6443 as the selected user, in a namespace reserved for that user.

As your first interactions with the cluster, try the following commands:

Write a file alpine.yaml with the following contents: Without dwelling on the rather verbose formalism (not detailed here), note that this file represents a deployment named alpine-dpl.
It is used to describe the containers whose execution is desired.
Here, we want a single replica of a container executing the shell command shown✍ in the alpine image.
In addition to the container, this deployment describes a volume referring to the storage space reserved for you, which will be mounted at /mnt by the container.

The cluster processes this file with the command kubectl apply -f alpine.yaml.
Immediately check that it has been taken into account with kubectl get deployments; the 1/1 information indicates that one container is running and that you requested one.
In Kubernetes terminology, containers are referred to as pods; check their status with kubectl get pods.
Note that the pod that was created was named based on the name of its deployment with additional distinctive characters appended.

For debugging purposes, it is possible to interact interactively with a pod.
Use kubectl exec -it alpine-dpl-DDDDDDDDDD-PPPPP -- sh, replacing precisely the name of the pod, to obtain an interactive shell in it.
In this shell, use df -h / /mnt to display the mounting of the system image and the dedicated storage.
Also enter echo 'File 1' >/root/file1.txt and echo 'File 2' >/mnt/file2.txt, then terminate this shell with exit or the key combination Ctrl d.

Delete this pod with kubectl delete pods alpine-dpl-DDDDDDDDDD-PPPPP, replacing precisely the name of the pod, then check again with kubectl get pods.
You should find that a new pod has immediately been recreated; it only exists for a few seconds and its name differs from that of the previous one.
This is a fundamental principle of Kubernetes: you describe a desired state for the various resources you need, and the cluster strives to orchestrate actions to move towards the desired state.
This may, for example, involve waiting for a missing resource to appear so that a container can then start, or restarting containers that have accidentally terminated...
Run a command again in this new pod with kubectl exec -it alpine-dpl-DDDDDDDDDD-PPPPP -- ls -la /root /mnt, replacing precisely the name of the pod; the /root directory from the system image has been recreated in its initial (empty) state, whereas the /mnt directory associated with a volume has retained its previous state (the file2.txt file).
That is precisely the purpose of volumes: to preserve data despite any stops and restarts of pods.

Complete the alpine.yaml file with the following contents: Make sure to replace gX-YY with the name of the selected user, and the port number 9XYY in the same way (9109 for g1-09, 9217 for g2-17...).
The --- marker is important, as it is used to separate the various resources in the same file.
The service alpine-svc described here indicates that the Kubernetes cluster (kube.enib.fr) should expose TCP port 9XYY and redirect connections to it towards port 9988 of your deployment.
This deployment is identified using the app: alpine label that you used previously.

Make the cluster process this file with the command kubectl apply -f alpine.yaml.
You should find that the deployment was already known and identical to this request, whereas the service needs to be created; this confirms that you are describing a desired state, rather than actions to be applied immediately.
Check with kubectl get services that your service has been created successfully.

To experiment with the connections, monitor the logs produced by your pod with kubectl logs -f alpine-dpl-DDDDDDDDDD-PPPPP, replacing precisely the name of the pod.
From another terminal, use the exposed TCP port with many commands as echo 'some text' | ncat kube.enib.fr 9XYY, replacing precisely the chosen port number.
You should see that the text sent through the connection appears in the pod's logs.

In the alpine.yaml file, modify the replicas property of the alpine-dpl deployment to request the execution of 2 pods for this deployment.
Apply this change with kubectl apply -f alpine.yaml and check that it has been taken into account with kubectl get deployments, which should indicate 2/2.
The kubectl get pods command should show you the names of the two pods belonging to this deployment.
You already have a terminal monitoring the logs of the first pod; in a new terminal, also monitor the logs of the second pod with a similar command.
In another terminal, run the command echo 'some text' | ncat kube.enib.fr 9XYY repeatedly, replacing the port number precisely as chosen, while observing the logs of the two pods.
Notice that the alpine-svc service distributes incoming connections on the chosen port by redirecting them arbitrarily to the various pods of the deployment.
This is one of the fundamental principles of Kubernetes: the number of pods can be dynamically adjusted on the cluster in order to adapt it to the workload generated by the varying number of clients joining the provided service.

To release the resources from this first experiment, use: Check, with kubectl get pods, kubectl get deployments and kubectl get services, that nothing remains.

Download the archive kube_demo.zip and extracting it into your working directory.
This archive creates a kube_demo directory in which you will work.

The sh_db_demo subdirectory contains the files for building the container image already created during this experiment.
Build this image with podman build -t sh_db_demo ./sh_db_demo and check that it is present on your local machine with podman image ls.
Until now, the Kubernetes cluster has simply searched for the desired images in the default registry, docker.io.
The image built on your local machine is not directly accessible to the Kubernetes cluster, so it must first be uploaded to a registry that the cluster will consult.
The registry registry.kube.enib.fr has been provided for this purpose as part of this tutorial; the ./kube_enib_registry.py script can be used to list its contents.
First, you need to tag your image as being intended for this registry with podman tag sh_db_demo registry.kube.enib.fr/gX-YY-sh_db_demo:1.0, replacing gX-YY with the name of the selected user.
Check with podman image ls that the image with this tag has the same identifier as the original.
Publish this image with podman push registry.kube.enib.fr/gX-YY-sh_db_demo:1.0, replacing gX-YY with the name of the selected user, and check that it is present in the registry with the ./kube_enib_registry.py script✍.
Note that you have taken care to prefix your image with your username (gX-YY); this makes it possible to distinguish the images belonging to each user since the registry is shared.

Since the container using this image is intended to work with a database, it is necessary to define the credentials that they have in common.
For this purpose, create a secret demo-sec containing them: Check that it is present with kubectl get secrets, and its description with kubectl describe secrets demo-sec.

Edit the contents of the supplied sh_db_demo.yaml file, replacing gX-YY in the name of your image and replacing the port number 9XYY in the same way (9109 for g1-09, 9217 for g2-17...).
Study the constituent elements of this file: Note that the contents of the secret have not been specified in this file but were supplied separately on the command line.
Indeed, private information should not be included in a configuration file that might be archived or transmitted to someone else.

Make the cluster process this file with the command kubectl apply -f sh_db_demo.yaml.
Check the status of these resources with:

It is now possible to interact with your application using ncat kube.enib.fr 9XYY, replacing the chosen port number precisely.
Check that the application works as expected.
Also check that when you delete the pods with kubectl delete pods demo-app-dpl-DDDDDDDDDD-PPPPP and kubectl delete pods demo-db-dpl-DDDDDDDDDD-PPPPP, replacing them precisely with the names of the pods, the recreated pods allow you to resume using the application in its previous state (the data has persisted in the storage volume).

To release the resources from this first experiment, use: Check, with kubectl get pods, kubectl get deployments, kubectl get services and kubectl get configmaps, that nothing remains✍.

Still in the kube_demo directory, there are the subdirectories mini_postgres, rs_backend and mini_nginx that were used to build the images for the web application in this tutorial.
Build these images and publish them to the registry, taking care to replace gX-YY with the name of the selected user:

Using a database requires the same credentials as in the previous experiment; specify them in the secret demo-sec✍: Check that it is present with kubectl get secrets, and its description with kubectl describe secrets demo-sec.

Edit the contents of the supplied mini_app_demo.yaml file, replacing gX-YY in the name of your images and in the host parameter of demo-ingress.
Study the constituent elements of this file: Note that the demo-frontend-dpl deployment relies on the demo-site config-map, which does not yet exist.
Indeed, it is a directory containing multiple files whose contents cannot be described by a few lines in the previous file.
Create demo-site from the command line so that it contains the contents of the subdirectory: Check that it is present with kubectl get configmaps, and its description with kubectl describe configmaps demo-site.

Make the cluster process the previous file with the command kubectl apply -f mini_app_demo.yaml.
Check the status of the resources with:

It is now possible to interact with your web application using firefox http://gX-YY.kube.enib.fr/, replacing with the name of the selected user.
Check that the application works as expected and that many clients can use your web application simultaneously.

In the mini_app_demo.yaml file, modify the replicas property of the demo-backend-dpl and demo-frontend-dpl deployments to request the execution of 2 pods for each of these deployment.
Be careful not to replicate the database; indeed, since data storage on disk is unique, simultaneous writes by several pods could compromise these files✍.
Apply this change with kubectl apply -f mini_app_demo.yaml and check that it has been taken into account with kubectl get deployments, which should indicate 2/2 for the backend and the frontend.
The kubectl get pods command should show you the names of the four pods belonging to these deployments.
In two terminals, monitor the logs produced by each of the two backend pods with kubectl logs -f demo-backend-dpl-DDDDDDDDDD-PPPPP, replacing precisely the name of the pods.
In two other terminals, do the same for the frontend pods with kubectl logs -f demo-frontend-dpl-DDDDDDDDDD-PPPPP, replacing precisely the name of the pods.
Make numerous requests to your web application from your browser (using “Reload” repeatedly, for example) and observe in the logs the distribution of processing across the multiple frontends and backends✍.
Les mécanismes de réplication dynamique et d'équilibrage de charge fournis par le cluster Kubernetes offrent la possibilité à votre application (ou au autre bien plus exigente) de passer à l'échelle pour réagir à une éventuelle très forte charge induite par les sollicitations de nombreux clients.

To release the resources from this first experiment, use: Check, with kubectl get pods, kubectl get deployments, kubectl get services, kubectl get configmaps and kubectl get ingresses , that nothing remains✍.