Aller au contenu
English
English
medium

21 labs gratuits pour préparer le CKAD

2 min de lecture

21 labs pratiques pour préparer le Certified Kubernetes Application Developer, soit environ 6 heures de travail, chacun noté sur l'état réel de votre machine et non sur les commandes tapées. Ils se jouent chez vous avec la ligne de commande `dsoxlab`, et ne coûtent rien.

Le point de vue de qui déploie une application : conception des Pods, configuration, observabilité, mises à jour progressives et accès aux services.

  • 21labs
  • 6heures de pratique
  • 21sur machines virtuelles

Niveaux 6 débutant 13 intermédiaire 2 avancé

Objectifs officiels de l'examen publiés par CNCF

Ce ne sont pas des questions d'examen. Ce sont des exercices pratiques sur les compétences que l'examen mesure, notés sur l'état de votre machine.

Kubernetes, CKA, CKAD et CKS

21 labs chaque lab rejoué et noté

Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

CKA, Certified Kubernetes Administrator

  • Plafonner un namespace sans bloquer ceux qui oublient de se déclarer

    Un namespace sans plafond ni valeurs par défaut : une équipe peut prendre tout le cluster, et un Pod sans `requests` est placé à l'aveugle. Posez les deux, et prouvez chacun : un Pod qui demande trop est refusé, un Pod qui ne demande rien est accepté et complété.

    dsoxlab start cka-resourcequota-limitrange

    25m intermédiaire machines virtuelles Guide compagnon

CKAD, Certified Kubernetes Application Developer

  • Un Pod à deux conteneurs, avec budgets, labels et annotation

    Écrire à la main un Pod à deux conteneurs, chacun avec ses requests et ses limits, avec des labels et une annotation, et prouver depuis l'intérieur de chaque conteneur que la limite de mémoire est celle que le noyau applique.

    dsoxlab start ckad-pod-resources-labels

    10m débutant machines virtuelles Guide compagnon

  • Injecter configuration et secrets dans un Pod

    Donner à une application sa configuration par des variables d'environnement et par un fichier monté, et ses identifiants par un Secret, sans jamais écrire un mot de passe dans le manifeste du Pod. Prouver, de l'intérieur du conteneur, que tout est arrivé.

    dsoxlab start ckad-configmap-secret-injection

    15m débutant machines virtuelles Guide compagnon

  • Sortir un mot de passe d'un manifeste, sans que l'application s'en aperçoive

    Un mot de passe est écrit en clair dans un manifeste de Deployment, que quiconque peut lire le lit aussi. Déplacez-le dans un Secret, injectez-le à la fois en variable d'environnement et en fichier monté, et laissez l'application tourner.

    dsoxlab start ckad-secret-injection-protection

    20m intermédiaire machines virtuelles Guide compagnon

  • Trois sondes sur un Pod : startup, liveness, readiness

    Équiper une application des trois sondes, avec des réglages qui ont un sens : un démarrage lent toléré, une vivacité surveillée, un trafic qui n'arrive qu'une fois prête. Prouver que les sondes agissent : le Pod n'est Ready que parce qu'elles répondent.

    dsoxlab start ckad-probes-all-types

    15m débutant machines virtuelles Guide compagnon

  • Attendre une dépendance avec un init container

    Empêcher une application de démarrer avant que le Service dont elle dépend ne réponde, avec un init container qui attend. Observer le Pod bloqué en Init, poser la dépendance, et voir l'application partir toute seule.

    dsoxlab start ckad-init-container

    15m intermédiaire machines virtuelles Guide compagnon

  • Un sidecar natif qui suit les logs de l'application

    Faire lire par un second conteneur les logs qu'une application écrit dans un fichier, avec un sidecar natif, déclaré comme init container à restartPolicy Always, et un volume partagé. Prouver que le sidecar transmet réellement les lignes.

    dsoxlab start ckad-multi-container-sidecar

    15m intermédiaire machines virtuelles Guide compagnon

  • Faire lire à un conteneur ce qu'un autre écrit, et pas le reste

    Deux conteneurs dans un Pod, l'un qui écrit et l'autre qui lit, et rien de partagé entre eux. Donnez-leur un volume dont la durée de vie est celle du Pod, et prouvez-le dans les deux sens : ce qui est écrit dans le volume passe, ce qui est écrit à côté ne passe pas.

    dsoxlab start ckad-volumes-partage-entre-conteneurs

    20m intermédiaire machines virtuelles Guide compagnon

  • Exposer un Deployment par un Service ClusterIP

    Déployer trois replicas d'un serveur et les exposer par un Service interne. Prouver depuis un client que le Service répond par son nom, et qu'il répartit réellement les requêtes entre les trois Pods.

    dsoxlab start ckad-expose-service

    10m débutant machines virtuelles Guide compagnon

  • Durcir un Pod avec un securityContext

    Faire tourner un serveur web sans privilège : utilisateur non root, aucune escalade, racine en lecture seule, toutes les capabilities retirées. Et lui donner quand même de quoi écrire là où il en a besoin, sinon il ne démarre pas. Prouver, de l'intérieur, que le confinement agit et que l'application sert.

    dsoxlab start ckad-security-context-hardened

    15m intermédiaire machines virtuelles Guide compagnon

  • Donner un accès en lecture seule aux Pods avec RBAC

    Permettre à une utilisatrice de lire les Pods d'un namespace et leurs logs, et rien de plus : ni créer, ni supprimer, ni voir les autres namespaces. Prouver les deux côtés avec kubectl auth can-i, ce qui est permis et ce qui reste refusé.

    dsoxlab start ckad-rbac-role-rolebinding

    15m intermédiaire machines virtuelles Guide compagnon

  • Cloisonner trois tiers avec des NetworkPolicy ingress et egress

    Frontend, backend, base de données : n'autoriser que les flux prévus, dans les deux sens, DNS compris, et interdire tout le reste. Prouver chaque règle par une vraie connexion, celle qui passe et celle qui est bloquée.

    dsoxlab start ckad-networkpolicy-ingress-egress

    20m intermédiaire machines virtuelles Guide compagnon

  • Régler une mise à jour progressive : maxSurge et maxUnavailable

    Contraindre la façon dont un Deployment remplace ses Pods, jamais plus de deux en trop ni plus d'un indisponible, puis déclencher une mise à jour d'image et prouver qu'elle est allée au bout : ancienne révision à zéro, nouvelle au complet.

    dsoxlab start ckad-rolling-update-strategy

    15m intermédiaire machines virtuelles Guide compagnon

  • Basculer le trafic d'une version à l'autre : blue-green

    Faire tourner deux versions d'une application côte à côte, et basculer tout le trafic de l'une à l'autre en changeant le selector d'un Service. Prouver la bascule depuis un client : toutes les requêtes atteignent la nouvelle version, aucune l'ancienne.

    dsoxlab start ckad-blue-green-deployment

    15m intermédiaire machines virtuelles Guide compagnon

  • Une base Kustomize et deux overlays, dev et prod

    Décrire une application une seule fois, dans une base Kustomize, et la déployer dans deux namespaces avec des overlays qui changent le nombre de replicas, préfixent les noms et ajoutent un label d'environnement. Prouver que les deux environnements tournent et se ressemblent.

    dsoxlab start ckad-kustomize-overlays

    20m intermédiaire machines virtuelles Guide compagnon

  • Installer, mettre à jour et revenir en arrière avec Helm 4

    Déployer un chart avec Helm, le mettre à jour avec de nouvelles valeurs, puis revenir à la première révision. Prouver par l'historique de la release et par l'état du Deployment que les trois opérations ont eu lieu, dans cet ordre.

    dsoxlab start ckad-helm-install-upgrade

    15m intermédiaire machines virtuelles Guide compagnon

  • Un Job à complétions parallèles et un CronJob

    Exécuter un traitement quatre fois, deux à la fois, avec un Job, et prouver que les exécutions se sont bien chevauchées. Puis planifier un nettoyage toutes les cinq minutes avec un CronJob qui garde un historique borné.

    dsoxlab start ckad-job-cronjob

    15m débutant machines virtuelles Guide compagnon

  • Redimensionner un Pod en place, sans le redémarrer

    Augmenter le CPU et la mémoire d'un Pod qui tourne, sans le recréer ni redémarrer son conteneur, par la sous-ressource resize. Prouver que le noyau applique la nouvelle limite et que le conteneur est resté le même.

    dsoxlab start ckad-in-place-pod-vertical-scaling

    10m avancé machines virtuelles Guide compagnon

  • Un Pod bloqué par un ConfigMap qui n'existe pas

    Un Pod ne démarre pas et ne dit rien dans ses logs, parce qu'il n'a pas encore de conteneur : ce sont ses events qui parlent. Lire la cause, créer la ressource manquante avec le contenu attendu, et prouver que l'application sert.

    dsoxlab start ckad-troubleshoot-missing-configmap

    10m débutant machines virtuelles Guide compagnon

  • Trois Pods en CrashLoopBackOff, trois causes

    Trois Pods redémarrent en boucle pour trois raisons différentes : une commande qui n'existe pas, une variable d'environnement absente, une limite de mémoire trop basse. Lire pour chacun ce qui le tue, le corriger, et prouver que les trois tiennent.

    dsoxlab start ckad-troubleshoot-crashloop

    15m intermédiaire machines virtuelles Guide compagnon

  • Capstone : livrer la boutique, à partir du seul cahier des charges

    Une livraison complète, donnée comme un cahier des charges et non comme un mode d'emploi. Six exigences à satisfaire dans un namespace : configuration, secret, sondes, identité, exposition et isolation. Rien ne dit quel objet créer, et le dernier test vérifie la seule chose qui compte : un Pod frontend joint la boutique, un Pod qui n'en est pas un ne la joint pas.

    dsoxlab start ckad-capstone-boutique

    45m avancé machines virtuelles Guide compagnon

Revenir aux 352 labs Comment jouer un lab