DEV Community: Florian Cartron

How to simulate a Worker Node failure in your Kubernetes Cluster without direct access

Florian Cartron — Fri, 02 May 2025 09:19:45 +0000

I pondered: How can I simulate a node outage due to misconfiguration using only kubectl? This approach can be valuable for preparing training sessions or technical interviews.

Suppose I aim to alter the kubelet service configuration to prevent it from starting.

First, I need a method to access the node and modify the kubelet service configuration. I can utilize the kubectl debug command to create an ephemeral container that shares its Linux namespaces with the node. While this feature is commonly used for debugging distroless containers, it can also be employed for node debugging.

I also would like to be able to use commands like systemctl as if i were directly on the node.
Let's try with the general profile:

$ kubectl debug node/node01 --profile=general --image=busybox -it
# Creating debugging pod node-debugger-node01-2zpm8 with container debugger on node node01.
# If you don't see a command prompt, try pressing enter.

/ $ df -h
# Filesystem                Size      Used Available Use% Mounted on
# overlay                  18.3G      5.9G     12.4G  32% /
# tmpfs                    64.0M         0     64.0M   0% /dev
# /dev/vda1                18.3G      5.9G     12.4G  32% /host
# ...

/ $ cat /host/etc/os-release | head -n1
# PRETTY_NAME="Ubuntu 24.04.1 LTS"

/ $ ps aux | grep kubelet
# 736 root      0:42 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/# bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/# lib/kubelet/config.yaml --container-runtime-endpoint=unix:///var/run/containerd/# containerd.sock --pod-infra-container-image=registry.k8s.io/pause:3.10 # --container-runtime-endpoint unix:///run/containerd/containerd.sock # --cgroup-driver=systemd --eviction-hard imagefs.available<5%,memory.# available<100Mi,nodefs.available<5% --fail-swap-on=false
# 18233 root      0:00 grep kubelet

Yeah ! I can access the host filesystem and view its processes, but I still can't use systemctl commands. Let's chroot into the host filesystem and intentionally disrupt the kubelet service:

/ $ chroot /host
node01:/ $ sed -i 's/config\.yaml/conf1g.yaml/g' /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
node01:/$ systemctl daemon-reload
node01:/$ systemctl restart kubelet

I was immediately ejected from the node, and after a few seconds—the duration of the controller manager's grace period—the node was marked as NotReady.

Let's encapsulate this process into a concise one-liner to simulate a failure on a random node in the cluster:

$ kubectl debug $(kubectl get nodes -l '!node-role.kubernetes.io/control-plane' -o name | shuf -n1) \
  --profile=general --image=busybox -- \
  chroot /host sh -c "sed -i 's/config\\.yaml/conf1g.yaml/g' /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf && \
  systemctl daemon-reload && \
  systemctl restart kubelet"

The key takeaway from this test is the critical importance of exercising caution when assigning the pods/ephemeralcontainers permission to users. Granting this permission allows users to inject ephemeral containers into existing pods/nodes, which can bypass standard admission controls and security policies such as Pod Security Admission, OPA Gatekeeper, or Kyverno. This capability poses a significant security risk, as it enables the creation of privileged containers without undergoing the usual validation processes, potentially compromising the cluster's security posture.

kuberc: an exciting new feature for kubectl

Florian Cartron — Tue, 08 Apr 2025 14:28:51 +0000

Kubernetes 1.33, scheduled for late April, introduces kuberc, a new feature that allows you to customize kubectl. This feature, described in KEP-3104, enables you to create aliases and enforce options for kubectl subcommands.

This customization is possible through a .kube/kuberc file in your home directory (the path can be modified with the --kuberc flag).

The example below demonstrates how to create an alias for creating a namespace with a predefined name, and how to force the interactive behavior of the kubectl delete command:

apiVersion: kubectl.config.k8s.io/v1alpha1
kind: Preference
# alias "kubectl crns" for "kubectl create namespace test-kuberc-ns"
aliases:
  - name: crns
    command: create namespace
    appendArgs:
      - test-kuberc-ns
# Force the --interactive=true flag for kubectl delete
overrides:
  - command: delete
    flags:
      - name: interactive
        default: "true"

Let’s take the example of the kubectl delete command. Kubernetes maintainers cannot enable confirmation before deletion by default, as it would disrupt many CI/CD processes. However, with kuberc’s customization options, you can enable this feature when needed, without affecting other users.

This feature will be available in alpha with Kubernetes 1.33 and can be activated using the environment variable KUBECTL_KUBERC=true. Note that, for now, kubectl’s auto-completion does not work with aliases defined by kuberc.

Cloud Run Revision Tags: Secure Routing and Automation

Florian Cartron — Tue, 11 Mar 2025 11:06:15 +0000

Cloud Run is a fully managed service by Google Cloud that allows you to run containerized applications in a scalable environment without the need to manage the underlying infrastructure. It combines the simplicity of serverless with the flexibility of containers, enabling rapid deployments, precise pay-as-you-go billing, and automatic scaling based on demand. Ideal for web applications, APIs, or background processing tasks, Cloud Run streamlines development and deployment while ensuring a seamless user experience.

Cloud Run enables you to run multiple revisions of your application in parallel and intelligently split traffic between them. Revision tags allow you to access specific versions in preview mode for testing or demonstration purposes.

However, it's important to note that anyone who knows or can predict the URL of a Cloud Run service can access it, as these URLs are publicly accessible by default. This is especially critical for revision tag URLs, which are often used for previewing specific versions and are not meant to be publicly accessible. To address this, it is common practice to place the Cloud Run service behind a load balancer. This setup not only centralizes traffic management but also enables the use of Identity-Aware Proxy (IAP) to secure access. With IAP, you can enforce authentication and authorization, ensuring that only authorized users or systems can access the revision tag URLs, adding an essential layer of security to your deployment.

Placing a Cloud Run service behind a load balancer, while providing enhanced security, can introduce additional complexity—particularly when dealing with revision tags. Configuring the URL map to correctly route traffic to specific revision tags requires careful setup and maintenance. Each tag URL needs to be explicitly mapped, which can become cumbersome as the number of revisions and tags grows or changes. This complexity can also impact the flexibility and speed of deployment, making it important to weigh the trade-offs between security and operational simplicity when adopting this approach.

What are URL masks?

Serverless Network Endpoint Groups (NEGs) in Cloud Run provide URL masks, which enable you to configure custom routing for incoming requests. URL masks enable you to define specific paths that route traffic to distinct Cloud Run revisions or services, providing flexibility in managing traffic distribution. This feature is especially useful when using load balancers, as it helps manage traffic across different versions of an application without having to update the url map.
URL masks let you use placeholders to dynamically route requests to the right service/revision tag, with this kind of syntax:

Let’s demonstrate the power of URL Masks

Scenario: we have two services, named Hello and Hola, and both of them have two tagged revisions, but traffic is sent to only one, as the other tag is a preview version only accessible with access restrained by IAP(IAP configuration will not be a part of this demonstration):

We will deploy this infrastructure with gcloud cli, but you can use terraform as well.

Deploying Cloud Run Services with Tagged Revisions

Let's start with the hello service with 2 revisions respectively named/tagged green and blue.

PROJECT="your-project-id"
REGION="any-googlecloud-region"

gcloud config set project $PROJECT

# Deploy the "hello" Cloud Run service
gcloud run deploy hello \
    --region $REGION \
    --image us-docker.pkg.dev/cloudrun/container/hello \
    --revision-suffix green --tag green \
    --set-env-vars COLOR=green --allow-unauthenticated

# Create "blue" revision without traffic
gcloud run deploy hello \
    --region $REGION \
    --image us-docker.pkg.dev/cloudrun/container/hello \
    --revision-suffix blue --tag \
    --no-traffic --set-env-vars COLOR=blue

This service should be accessible directly from the public url(green will be served) and both revisions can be accessed through their revision tag url:

We want our services to be deployed behind a load balancer, and not directly accessed from the internet, so we will disable external access:

# Disable external access
gcloud run services update hello \
    --region $REGION \
    --ingress=internal-and-cloud-load-balancing

And now, the hola service and its 2 revisions:

# Deploy the "hola" Cloud Run service
gcloud run deploy hola \
    --region $REGION \
    --image us-docker.pkg.dev/cloudrun/container/hello \
    --revision-suffix red --tag red \
    --set-env-vars COLOR=red \
    --allow-unauthenticated \
    --ingress=internal-and-cloud-load-balancing

# Create "yellow" revision without traffic
gcloud run deploy hola \
    --region $REGION \
    --image us-docker.pkg.dev/cloudrun/container/hello \
    --revision-suffix yellow --tag yellow \
    --no-traffic --set-env-vars COLOR=yellow

Managing our domain name

By combining URL masks with a DNS wildcard, you can fully automate your URL mapping process. This setup allows you to dynamically route traffic to various revision tags without manual intervention, streamlining deployment and minimizing errors. With this combination, you can efficiently manage large-scale applications with multiple revisions, ensuring both security and scalability while reducing operational complexity.

We reserve an IP address so we can know it and use sslip.io to get a domain with a wildcard DNS based on our IP, and then create the self-signed SSL certificate that our load balancer will use later:

# Reserve a regional IP for the load balancer
gcloud compute addresses create hello-ip --global
IP_ADDRESS=$(gcloud compute addresses describe hello-ip --global --format="get(address)")
DOMAIN="${IP_ADDRESS}.sslip.io"

# Generate self-signed SSL certificate
openssl genrsa -out wildcard.key 2048
openssl req -new -key wildcard.key -out wildcard.csr -subj "/CN=*.$DOMAIN"
openssl x509 -req -days 365 -in wildcard.csr \
    -signkey wildcard.key \
    -out wildcard.crt \
    -extfile <(printf "subjectAltName=DNS:*.$DOMAIN,DNS:$DOMAIN,DNS:*.preview.$DOMAIN")

# Create SSL certificate in Google Cloud
gcloud compute ssl-certificates create hello-certificate \
    --certificate wildcard.crt \
    --private-key wildcard.key \
    --global

Configuring Serverless NEGs for URL Masks

Now that we know our base domain name, we can create our serveless network endpoint groups with the url masks, as defined in the diagram, as well as the backend services that will be used by the load balancer:

# Create a serverless NEG for tagged revisions
gcloud compute network-endpoint-groups create preview-neg \
    --region=$REGION \
    --network-endpoint-type=SERVERLESS \
    --cloud-run-url-mask="<tag>-<service>.preview.${DOMAIN}"

# Create backend service and attach NEG
gcloud compute backend-services create preview-backend \
    --global \
    --load-balancing-scheme=EXTERNAL_MANAGED
gcloud compute backend-services add-backend preview-backend \
    --global \
    --network-endpoint-group=preview-neg \
    --network-endpoint-group-region=$REGION

# Create a serverless neg for services
gcloud compute network-endpoint-groups create service-neg \
    --region=$REGION \
    --network-endpoint-type=SERVERLESS \
    --cloud-run-url-mask="<service>.${DOMAIN}"
gcloud compute backend-services create service-backend \
    --global \
    --load-balancing-scheme=EXTERNAL_MANAGED
gcloud compute backend-services add-backend service-backend \
    --global \
    --network-endpoint-group=service-neg \
    --network-endpoint-group-region=$REGION

Setting Up Load Balancing for Secure Routing

Finally, we create a load balancer to expose securely our dynamic URLs:

# Create the url map with the "service" access as default
gcloud compute url-maps create hello-urlmap --default-service service-backend --global
# Add a path matcher for preview urls
gcloud compute url-maps add-path-matcher hello-urlmap \
  --path-matcher-name=preview-matcher \
  --default-service=preview-backend \
  --new-hosts="*.preview.$DOMAIN"

# Create the target proxy
gcloud compute target-https-proxies create hello-target-proxy --url-map=hello-urlmap --ssl-certificates=hello-certificate --global

# Create the forwarding rule
gcloud compute forwarding-rules create hello-forwarding-rule \
  --address=$IP_ADDRESS \
  --global-address \
  --ip-protocol=TCP \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --ports=443 \
  --target-https-proxy=hello-target-proxy \
  --global-target-https-proxy \
  --global

After a few minutes, the services will be accessible through these URLs:

https://hello.${IP_ADDRESS}.sslip.io/ # green
https://green-hello.preview.${IP_ADDRESS}.sslip.io/
https://blue-hello.preview.${IP_ADDRESS}.sslip.io/

https://hola.${IP_ADDRESS}.sslip.io/ # red
https://red-hola.preview.${IP_ADDRESS}.sslip.io/
https://yellow-hola.preview.${IP_ADDRESS}.sslip.io/

Demo scripts are available:

Going Further: Securing and Optimizing

Protecting the Backend Service with IAP

To enhance the security of your Cloud Run deployment, you can use Identity-Aware Proxy (IAP) to protect your backend services. IAP acts as a gatekeeper, ensuring that only authenticated and authorized users or systems can access your Cloud Run services. By enabling IAP, you can restrict access to specific revision tags or service versions, providing an additional layer of security for your application. This is particularly useful when you want to prevent unauthorized access to your preview environments.
It's important to note that the same IAP configuration applies to all services accessed via your URL map/URL mask combination. Since IAP is enforced at the backend service level, any service or revision mapped through this configuration will inherit the same access controls, ensuring a consistent and secure authentication policy across all your deployed versions.
Additionally, to use IAP, your services must be accessed over HTTPS, meaning you need a valid SSL/TLS certificate. If you've used a DNS wildcard for your load balancer configuration, a wildcard certificate is essential for securing all your subdomains. This ensures secure communication while maintaining the flexibility to manage multiple services and revision tags under the same domain.

Managing Costs with Tagged Revisions

While revision tags offer significant advantages in managing versions and traffic, it’s important to keep an eye on the associated costs, especially when using features like min instances > 0. Setting a minimum number of instances ensures that a certain number of instances are always running, even when traffic is low, which avoids cold starts but can lead to increased costs. This is especially important when working with revision tags, as each tagged revision will incur charges based on the minimum instance settings, even if no traffic is routed to it. If you're using revision tags in a staging or preview environment, be mindful of these settings to avoid unexpected costs. Carefully managing the number of active instances for each revision tag can help optimize costs while maintaining the required service levels.

Viewing Revision Tag URLs

With the URL mask pattern, it can be difficult to predict and construct dynamically generated URLs, as it won't appear with a simple link in the Google Cloud console. I have developed a simple tool to visualize the available URLs: Cloud Run Revision Tag URL Viewer.

🧑‍🚀 Road to be a Kubestronaut, C'est parti ! 🚀

Florian Cartron — Fri, 22 Nov 2024 16:01:46 +0000

Par Hugues Connan et Florian Cartron

Réussir la certification Certified Kubernetes Security Specialist (CKS) peut sembler être une consécration dans le parcours des certifications Kubernetes tant elle est réputée la plus difficile de toutes et vue comme le niveau ultime en matière d’administration et sécurité. Cependant, la Cloud Native Computing Foundation (CNCF) a ajouté un nouveau défi avec le lancement du programme Kubestronaut lors de la dernière KubeCon Europe 2024 à Paris, définissant ainsi ce qu'il signifie d'être un expert Kubernetes complet.

Comment devient-on un "Kubestronaut" et qu’est-ce que cela peut vous apporter ? Dans cet article, nous vous partageons notre parcours, les conseils pratiques et les étapes nécessaires pour atteindre ce titre honorifique (et non, on ne finit pas réellement dans l’espace !) et être reconnus comme experts certifiés Kubernetes.

Le programme Kubestronaut, c’est quoi ?

Le programme Kubestronaut a été créé par la CNCF pour encourager les professionnels Kubernetes à démontrer leur expertise à travers un ensemble complet de certifications. Kubestronaut est un titre accordé à ceux qui réussissent les cinq certifications majeures : KCNA (Kubernetes and Cloud Native Associate), KCSA (Kubernetes Cloud Security Associate), CKAD (Certified Kubernetes Application Developer), CKA (Certified Kubernetes Administrator), et CKS (Certified Kubernetes Security Specialist).

Les avantages

En devenant Kubestronaut, on n’obtient pas qu’un titre honorifique, cela apporte une validation en matière de maîtrise de Kubernetes. Aussi, ce parcours permet d’approfondir certains concepts de l’orchestrateur même s’il ne remplace pas pour autant l’expérience en production. Le programme offre aussi des réductions sur des certifications CNCF, l’accès à des événements comme la KubeCon à des tarifs préférentiels, des coupons (partageables, ou pas !) pour toutes les certifications proposées par la CNCF, et même une veste permettant d’arborer fièrement le logo Kubestronaut.

Comment sommes-nous devenus Kubestronaut ?

Les 5 certifications Kubernetes

Le programme demande de réussir cinq certifications différentes, chacune abordant des aspects spécifiques de Kubernetes et de l’écosystème Cloud Native. Il se découpe en 2 grandes familles, tout d’abord, tout d’abord les 2 certifications QCM de niveau pré-professionnel (KC*):

KCNA : Introduction à Kubernetes et au Cloud Native
KCSA : Notions de sécurité Cloud Native appliquées à Kubernetes

Puis Les 3 certifications pratiques de niveau professionnel (CK*) :

CKAD : Développement d’applications Kubernetes
CKA : Administration de clusters Kubernetes
CKS : Sécurité avancée dans Kubernetes

Pour être Kubestronaut, il faut avoir ces 5 certifications en cours de validité, elles ont toutes une durée de validité de 2 ans.

Les certifications Kubernetes sont disponibles à l'achat sur le site training.linuxfoundation.org, où l'on peut retrouver l'ensemble des certifications requises pour le programme Kubestronaut. Divers bundles permettent de réduire les coûts, et il y a souvent de bonnes offres pendant les événements comme la KubeCon et le Cyber Monday. Les promotions régulières sont également répertoriées dans ce repository GitHub. Il est également possible d’acheter un bundle contenant le cours (autoformation en ligne) correspondant à la certification.

Chacune des certifications peut être planifiée pendant 1 an à compter de la date d’achat. Vous avez aussi le droit à une nouvelle tentative gratuite en cas d’échec. Afin de pouvoir en profiter dans de bonnes conditions, nous vous conseillons de vous fixer une date afin d’avoir un objectif établi. Cela vous permettra également d’éviter la procrastination, vous pourrez toujours déplacer votre créneau d’examen si tout ne se passe pas comme prévu.

La liste des domaines de compétences évalués est disponible sur la page de chacune des certifications.

Il existe une page recensant les FAQ et les instructions importantes pour se préparer au mieux au format de l’examen.

Choisir son parcours de certification

Le parcours idéal varie selon le niveau de départ en Kubernetes :

Débutants : KCNA > KCSA > CKAD > CKA > CKS. Ainsi vous aurez un vernis théorique global avant de vous attaquer à la pratique.
Utilisateurs expérimentés : KCNA > CKAD > CKA > KCSA > CKS. Ce parcours permet d’aller de plus en plus en profondeur sur les axes administration et sécurité, en commençant par la théorie, puis la pratique.
Axé sur la pratique : CKAD > CKA > KCNA > CKS > KCSA. Comme pour le parcours précédent, d’abord les certifications générales, puis celles portant sur la sécurité. Par contre, l’idée ici est de commencer par la pratique, puis d’enchainer avec la certification KC* associée, le périmètre y étant certes plus théorique, mais aussi et surtout plus large.

Ces suggestions permettent d’adapter le parcours selon la connaissance initiale de Kubernetes et les objectifs et contextes personnels. Vous pouvez toutefois les passer dans l’ordre que vous souhaitez, le seul prérequis est qu’il faut être certifié CKA pour pouvoir passer la CKS.

Nos parcours

Hugues Connan : Je suis passé de 0 à 5 certifications en un peu moins de 2 ans. J’avais une première expérience dans l’administration de Kubernetes mais je souhaitais valider mes compétences à travers la CKA, première certification passée. Puis, j’ai enchaîné avec la CKAD, puis la CKS. A ce moment-là, je pensais que les certifications Kubernetes étaient terminées pour moi. Puis, il y a eu le parcours Kubestronaut qui m’a amené à passer la KCNA puis la KCSA.
Florian Cartron : Je suis passé de 0 à 5 certifications en 1 mois, avec un peu d’expérience sur Kubernetes, en filigrane sur les 5 dernières années et beaucoup de temps investi : environ 10h par certification QCM et 30h par certification pratique. J’ai choisi le parcours axé sur la pratique, cela correspond à ma méthode d’apprentissage, et la plupart des connaissances acquises sont utiles pour les questionnaires QCM, il faut simplement approfondir les sujets Cloud Native hors Kubernetes.

Comment préparer les certifications ?

Examens en ligne avec PSI

Tous les examens ont lieu à distance via le “Bridge Secure Browser” fourni par l’organisme certifiant PSI. Le binaire est à télécharger au début de chaque examen sur votre espace Training portal de la Linux Foundation. Vous pouvez donc les passer depuis chez vous, ou bien au bureau tant que vous respectez quelques contraintes non exhaustives :

être dans une pièce fermée sans mur vitré
avoir un bureau sur lequel il n’y a que votre ordinateur et de l’eau dans un contenant transparent
impossible d’avoir un écran externe
pas de poubelle au pied
ne pas avoir un chat qui sait ouvrir les portes et qui vient dire coucou à l’examinateur (true story).

Bref, vous pourrez retrouver toutes les règles ici.

Dans le processus, il y a l’étape de vérification de votre environnement de test et de votre identité. Une fois cette étape validée, vous avez un écran vous demandant d’attendre que votre examen commence. En théorie, vous devez normalement avoir accès à l’interface d’examen au bout de 5 min maximum. Si vous sentez que l’attente est trop longue à votre goût, n’hésitez pas à contacter le support via le chat intégré. Un simple redémarrage du navigateur suffit parfois à débloquer la situation. Si vous le relancez, vous retomber sur l’examen en cours.

Il est possible de lancer l’examen, étapes de vérification comprises, jusqu'à 30 minutes avant l’heure programmée.

Les certifications QCM

KCNA et KCSA sont 2 certifications assez généralistes sous forme de Questionnaire à Choix Multiples. Ce QCM comprend 60 questions à réponses uniques pour 1h30 d’examen. Sur le papier, elles sont destinées à être des certifications pré-professionnelles qu’on peut aussi qualifiées “d’entrée”. A la différence des CK*, celles-ci ne testent pas uniquement vos connaissances sur Kubernetes. Bien sûr, quasiment une question sur 2 concerne directement Kubernetes, ce qui a donc un poids important dans la note finale. Pour autant, elles vont aussi vérifier vos connaissances sur l’écosystème du Cloud Native et de la sécurité appliqué à Kubernetes.

Pour réussir, il faut avoir bien répondu à au moins 75% des questions.

Comme dans beaucoup de certifications de cette forme, le meilleur conseil est de bien lire les questions. Cela peut paraître évident mais certaines questions ont des indices dans leur énoncé. N’hésitez pas non plus à mettre un petit drapeau sur les questions où vous avez un doute car vous pourrez revenir dessus par la suite. Et enfin, nous vous conseillons aussi, si vous avez le temps, de parcourir à nouveau toutes les questions, certaines questions peuvent vous aider à répondre à celles où vous aviez un doute.

Les certifications pratiques

La CKAD, CKA et CKS sont 3 examens qui comportent entre 15 et 20 questions à résoudre en 2h, via le terminal du bureau à distance d’une machine virtuelle Linux. Vous aurez le droit d’accéder à la documentation officielle de Kubernetes (via le navigateur dans le bureau à distance, dans le navigateur sécurisé PSI). Pour réussir, il faut avoir bien répondu à au moins 66% des questions.

Ici, il va falloir manipuler entre autres le client kubectl pour répondre aux questions, les compétences et l’expérience pratiques sont donc ici essentielles. Un bon moyen de se tester est d’utiliser une plateforme d’entraînement telle que killercoda.com pour des mises en situation concrètes proches des examens, la liste des scénarios y est plutôt exhaustive.

Avec chacune de ces certifications sont fournies 2 sessions identiques d’un examen blanc sur killer.sh : c’est exactement le même environnement que pour l’examen réel, profitez en pour vous familiariser avec. Nous vous conseillons de garder la seconde session d’examen blanc pour préparer votre nouvelle tentative d’examen en cas d’échec. Attention : les examens blancs comportent plus de questions, et les questions sont plus complexes. Pas grave, tout ne s’arrête pas à la fin du décompte de 2h, vous pouvez y revenir autant que vous voulez pour corriger vos erreurs et traiter toutes les questions pendant 36h. Les questions sont très exhaustives et couvrent tout ce sur quoi vous pourrez tomber lors de l’examen.

Pour vous préparer au mieux, Zenika propose également des sessions de préparation sur une journée pour les examens CKAD et CKA.

Dans ces certifications, le temps est précieux. Voici quelques conseils pour vous permettre d’avoir toutes les chances de réussir :

kubectl : Familiarisez-vous avec les commandes impératives pour accélérer la création de configurations, et exploitez au maximum l’aide des commandes (--help), qui comporte de nombreux exemples d’utilisation très pratiques. Utilisez l'option “--dry-run=client -o yaml” pour générer rapidement des configurations en YAML, ce qui vous fera gagner un temps précieux.
Édition avec Vim : Devenez rapide et efficace avec Vim pour pouvoir éditer des fichiers en toute agilité pendant l'examen. Savoir se déplacer dans le fichier, indenter, copier, coller, supprimer des mots ou des lignes. Il y a plusieurs manières de faire ces actions, le tout est d’être à l’aise avec quelques raccourcis. Si vous préférez Nano, les mêmes conseils doivent s’appliquer, mais nous ne serons pas capables de le confirmer !
Aide de la documentation : Pendant l'examen, la documentation officielle de Kubernetes est accessible. C'est un atout majeur : entraînez-vous à repérer rapidement les sections importantes pour trouver les informations essentielles en un clin d'œil grâce à la recherche, notamment pour copier les descripteurs de ressources qu’il n’est pas possible de générer avec kubectl.
Ne pas rester bloqué : Si vous ne voyez pas du tout comment résoudre une question, mettez un drapeau pour y revenir plus tard. Idem si vous avez tenté une solution qui ne fonctionne pas et que vous ne comprenez pas pourquoi.

A noter qu’en plus d’être plus pointue techniquement, la certification CKS est bien plus longue, 2h ne seront pas de trop !

Conclusion

Devenir un Kubestronaut est un parcours exigeant, mais stimulant et très enrichissant pour tout professionnel souhaitant maîtriser Kubernetes et l'écosystème Cloud Native. Grâce à des étapes de certification progressives et un entraînement régulier, nous avons pu acquérir une expertise complète et reconnaître notre engagement dans ce domaine en pleine expansion.

Pour celles et ceux qui se lancent dans cette aventure, préparez-vous bien, investissez le temps nécessaire pour chaque certification, et n'hésitez pas à chercher les bonnes ressources pour vous permettre de préparer individuellement chaque certification : One step at a time!

Bon courage, futurs Kubestronauts !