Salut les amis, je vais vous parler de mon parcours semé d’embûches pour passer la CKA. Je pourrais répéter et compiler tout ce qui existe déjà sur le sujet, mais je préfère vous donner mon avis personnel sur cette certification et vous donner un avant-goût de ma préparation.

Mon parcours est un peu différent car j’ai fait plusieurs tentatives qui n’ont pas abouti. J’ai eu des problèmes techniques que je vais détailler par la suite, mais certains diront que je suis mauvais et que j’aurais dû lire les conditions de préparation à l’examen :)

Au final, j’ai fait trois tentatives qui se résument en deux problèmes techniques et une réussite. Je vous mets donc ici un condensé d’expérience réelle sur mes conditions de passage de l’examen et quelques clés qui, je l’espère, pourront vous aider.

J’ai toujours aimé jouer Zerg sur StarCraft. Je vais juste cracher un peu plus d’acide que d’habitude, pensez bien à mettre votre combinaison anti-acide !

Mes conditions d’examen

passage 1

Il y a 2 ans, j’accède à l’examen, payé de ma poche. Je fais le check-in, je réponds à quelques questions, je prends un terminal qui ne répond plus, l’interface crash. Je lance la console dev et je vois des erreurs 500 dans le terminal. L’examinateur me dit que ce n’est pas autorisé, mais j’ai la preuve que la plateforme déconne. J’ai fait une erreur avec le recul, j’aurais dû garder mon calme et faire un ticket. J’étais tellement aveuglé par la haine que j’ai rage quit et je m’étais promis de ne plus jamais repasser cet examen.

Si j’avais fait un ticket ce jour-là, j’aurais peut-être pu avoir un repassage et un lavage à sec…

passage 2

Deux ans plus tard, après trois semaines de préparations non-stop, à manger du lab matin, midi et soir, déterminé comme jamais.

J’avais bien dormi, je me suis levé à 6h30 (parce que je n’ai pas réussi à dormir plus), j’avais mangé sainement et pas d’alcool le week-end, j’avais tout le temps du monde devant moi. J’ai fait quelques étirements, pris un bol de fruits frais, un café. Je suis parti en avance pour être sûr d’être à l’heure. On m’avait réservé une salle dans un espace de coworking avec une connexion stable, personne autour, pas de bruits.

Je me connecte sur la plateforme, 30 minutes en avance, et c’est là que la fête commence. J’installe le navigateur de l’examen, et rien ne fonctionne. J’ai juste une page blanche et aucun moyen d’obtenir un message d’erreur, pas moyen de signaler quoi que ce soit.

Trois semaines de préparations intensives… pour en arriver à rester coincé à la porte de l’examen. Les minutes passent, j’essaie plusieurs fois, je tente en 4G avec mon téléphone. J’arrive à 10h01, examen périmé, terminé, bonsoir.

J’ai envie de retourner la table et de tout péter dans la pièce, mais ça ne résoudra en rien mon problème. Donc, je redescends, je prends un espresso et essaie de digérer la nouvelle.

Alors, j’ai fait un ticket.

Trois semaines de préparation intensive, foutues à la poubelle, comme si j’avais oublié de me lever pour me présenter à l’examen, parce que PSI ne sait pas assurer une qualité de service pendant leurs examens. (c’est ce que je pensais, mais c’était partiellement de ma faute, on y revient ensuite)

Je suis profondément écœuré et je n’ai pas les mots pour vous dire à quel point je suis déçu.

C’est encore pire que la première fois où j’avais eu accès à l’examen et que j’avais des erreurs 500 dans mon navigateur, j’avais pu répondre à quelques questions. Une semaine passe et j’ai une réponse à mon ticket, mon OS n’est pas dans la liste des OS supportés. J’accepte ma part de responsabilité, parce que Linux Mint c’est Ubuntu avec deux-trois différences en plus et en moins. Je lis le ticket qui dit qu’en gros, je suis un idiot, je n’ai pas utilisé un OS qui est dans la liste des OS supportés, mais dans son infinie bonté, la Linux Foundation me fait cadeau d’un retake. Ça m’énerve, c’est un peu ma faute, mais PSI fournit un moyen de tester les prérequis de la machine, et cet outil a fonctionné parfaitement, par contre le navigateur de l’examen que cet outil vérifie ne fonctionne pas. (une part immense de ma frustration c’est que cet outil ne peut être installé et donc testé que 30 minutes avant le début de l’exam)

passage 3

Je redescends un peu en pression, je refais quelques drills pour maintenir mon niveau. J’ai eu droit à un repassage, cette fois-ci j’essaie sur ma machine Windows de jeux :

J’avais tout prévu à nouveau :

• Personne dans la pièce
• Un câble Ethernet qui traverse mon appartement pour être branché directement sur la box
• Un déménagement de tout mon bazar sur et autour de mon bureau
• J’ai acheté un micro cravate pour que l’examinateur puisse m’entendre
• Testé mon installation plusieurs jours avant au cas où
• J’ai quand même mis beaucoup d’argent dans cette machine, une bonne alimentation, un Ryzen 7 et une 2080, une vraie bonne machine de jeux, plutôt fiable et de confiance.

Je passe le check-in, un peu énervant. Le mec détaille chacun de mes murs, mon bureau dessus, dessous, la couleur de mes murs. Ça prend facile 20 minutes, mais j’avais prévu le coup, j’étais connecté à 8h01, pas trop dur puisque j’étais déjà réveillé à 6h (je n’ai pas réussi à dormir plus). Je commence deux questions, mon PC s’éteint sauvagement sans raison. Je pète mon petit câble, je vérifie les câbles, je fais un reset électrique. Rallumage, boot loop, super.

Je refais un reset à nouveau, je retourne sur l’outil de l’examen (le navigateur web PSI). Je refais le check-in à l’identique avec les murs, le clavier, le tapis de souris.

Résultat de l’opération : 40 minutes sur les deux heures d’examen consommées. Très bien, ça m’énerve, mais je continue, je me dis que foutu pour foutu je peux tenter de répondre comme un fou, le plus vite possible et peut-être avoir de la chance. Je réponds à 3 questions, re-crash d’ordinateur, autant vous dire qu’à ce moment-là, j’ai donné des gros coups de poings sur mon clavier et des coups de pieds dans ma tour.

À cet instant, j’ai quelques réserves sur l’envie de repasser les certifications de la Linux Foundation…

passage 4

Je repasse à 18h30 le samedi.

Le chien vomit une heure avant, des manifestations dans les rues, les pompiers, les camions de CRS. Une ambiance un peu dégoûtée et fatiguée, un sentiment de dernière chance, now or never !

J’veux dire, il peut arriver quoi de plus maintenant. Je n’utilise plus mon PC de jeux Windows, je crois que mon alimentation est morte. J’ai réinstallé la dernière LTS d’Ubuntu sur ma machine de travail. Je me suis mis dans le salon, ça m’évite de déménager toutes les choses autour de mon bureau.

Ça ira maintenant, merde à la fin !

Je vais vous mettre ici les étapes du checking, pour vous donner une idée de l’ambiance de l’examen.

On installe l’outil de remote proctor au tout dernier moment. Vous ne pouvez le faire qu’au moment du checking, 30 minutes avant l’heure annoncée de l’examen. On me demande de redémarrer en utilisant X11 plutôt que Wayland, si ça te fait plaisir …

Le système vérifie le micro, la webcam et le réseau. Vous devez prendre en photo votre carte d’identité avec la webcam et un selfie de votre visage. Le mec vous demande de fermer toutes les portes et de faire le tour de toute la pièce avec votre webcam. Les plafonds, les coins de la pièce, il peut demander des détails sur chaque objet qui traîne. Une vue du bureau, en dessous du bureau. Très chiant avec la webcam intégrée !

Vos deux oreilles, au cas où j’ai une oreillette Bluetooth et une caméra espion dans mes lunettes. Très long et fastidieux et plutôt stressant, ça participe particulièrement à la bonne ambiance pour passer l’examen…

L’examen démarre enfin :

Ma stratégie a été de faire toutes les questions dans l’ordre et de sauter les questions dès que j’ai un doute et que ça dure trop longtemps. Je me suis posé, pépère, dans le canapé, au fur et à mesure des questions, j’ai pris un vieux mal de crâne. À la fin de ma première revue de questions, il me restait 30 minutes, que j’ai engloutis au final sur une question qui nécessite de bien lire la doc.

J’ai fini mon examen, j’attendais un score ou au moins une estimation de ma réussite, tout ce qu’on a, c’est le droit d’attendre 24h. Ça ne m’a pas empêché de me réveiller à 2h du mat pour checker au cas ou, j’ai eu mon résultat à 18h34 le dimanche matin, 24h et 4 minutes !

Et encore, on à pas eu les camions a Angoulême !

Mes motivations, et mes réserves au sujet de cette certification

Mon mindset personnel est d’être reconnu comme professionnel dans l’administration de clusters Kubernetes, bien que j’ai par le passé dèja travaillé sur des clusters de production. En fait, en réalité, je pense que la certification est très bien pour comprendre les rouages du fonctionnement technique d’un cluster Kubernetes, mais dans la réalité des faits, on doit s’en foutre complètement de la tambouille interne de kube.

La seule et unique valeur qui faut toujours avoir en tête, c’est la disponibilité de services des pods et toutes les problèmes que l’outils résout. J’y reviens plus tard, mais pour moi la certification ne prépare en aucun cas à travailler dans un environnement Kubernetes de production ou à la sensibilisation à travailler avec des contraintes de haute disponibilité et ou de haute performance.

La certification n’a du sens que si on pratique Kubernetes ensuite et qu’on ne perd pas nos acquis. Mon but étant d’avoir cette certif pour arrêter d’avoir à me justifier sans cesse sur mes compétences Kubernetes.

Une préparation en conditions dégradées voir extrême

La forme de l’examen et la plateforme technique est particulièrement exécrable et frustrante sur certains aspects :

Impossible de réserver un centre d’examen physique, si un problème technique survient, c’est au bon vouloir de l’examinateur de faire un remboursement ou une replanification gratuite. On a le droit à la documentation Kubernetes.io, avec une barre de recherche qui utilise Bing Research (ironique quand on y pense quand on représente la CNCF) et qui peut être indisponible le jour de l’examen. La plateforme peut laguer ou être instable, il faudra garder son calme et éviter de taper les poings sur la table en insultant l’examinateur de tout les noms d’oiseaux possible.

On peut rester bloqué longuement sur une question et se faire prendre par le temps, si c’est trop dur ou trop long, revenez plus tard (titre). Pour les problèmes techniques de la plateforme, si vous drillez vos exercices sur Kodecloud, la plateforme lag souvent et faut éviter de taper sur votre clavier comme un joueur de baseball qui tente un homerun.

Ça permet de travailler le self-contrôle. Répétez souvent les exercices dur avec un environnement bruyant et distrayant. J’ai fait mon premier backup ETCD réussi sans aide dans un hall d’immeuble, en plein exercice incendie. 30 personnes qui parlent sans en avoir rien à foutre et un mec qui donne des instructions incendies dans un bordel total en parlant fort.

Si en situation de stress et d’inconfort vous ne savez pas faire des actions compliquées, vous allez mal gérer votre stress quand vous en aurez le plus besoin. Dans le cas contraire, si une météorite tombe et que vous avez backupé votre base etcd, félicitations. C’est complètement inutile si c’est dans le même nœud que vous voulez restaurer, mais c’est une question qui tombe souvent à l’examen, se sont des points gagnés facilement.

Pour la barre de recherche de Kubernetes.io, il faut savoir chercher dans l’arborescence de la documentation directement pour les objets ou les conf YAML qui ne peuvent pas être gérés en ligne de commande. Vous allez perdre un temps conséquent à chercher l’information si vous n’y êtes pas habitué à le faire manuellement. A priori, ce n’est pas forcément si rare que ça, puisque le cours Udemy Kodecloud en parle et j’en ai fait l’expérience pendant mes drills.

Un bon exercice est de driller les labs Kodecloud au point d’en vomir et de se réveiller la nuit. Tous les jours, vous lancez des labs par 10 ou 20 (si vous avez du temps libre et de la détermination). Au moment où vous lancez n’importe quel lab et que ça devient complètement ennuyeux et rapide pour vous, vous êtes prêts.

Travaillez les labs d’administration qui sont ceux qui ont de la plus-value après l’examen. Une fois que vous êtes confortable, dégradez votre pratique, pas de barre de recherche, environnement bruyant, distraction de vos collègues, lab surprise. Essayez de voir plus loin que le sujet de l’examen et prenez plaisir à manger du Kubernetes jusqu’à en faire une indigestion.

Essayer autant que possible de dérisquer vos conditions d’examen:

• Prendre un OS de la liste officiellement supportée.
• Vérifier en amont, webcam, micro, disponibilité de votre appartement tout seul.
• Mangez bien, dormez bien, c’est con mais ça aide à avoir de bonne condition physique pour l’exam.
• Mangez un moine shaolin ne vous aidera pas à rester zen si un problème technique arrive, mais faire un ticket de support peu vous aider à au moins obtenir un retake en cas de problème de plateforme.

Peut importe le niveau de préparation que vous avez, si un problème technique arrive, ne vous niquez pas bêtement les pieds et les mains, j’ai essayé ça ne résout absolument rien.

Points d’attentions particuliers

Voici les sujets qui sont difficiles à mon sens, pas forcément trié dans mon ordre de galère, mais je vais vous détailler mes arguments.

Affinity et anti-affinity:

• Les morceaux de YAML à ajouter sont profonds et peuvent faire perdre un temps important à déboguer.
• Ce n’est pas très simple à vérifier, il faut bien checker et comprendre la demande.
• Les exemples sont plutôt bons dans la doc, mais il faut faire attention à la profondeur du YAML en fonction de si on travaille directement sur un pod static ou un deploy.

CertificateSigningRequest:

• Ce n’est pas une action qu’on fait souvent et la doc nous donne un exemple un peu pourri et confusant.
• Pourquoi on ne peut pas avoir un exemple de YAML propre, il faut nous mettre un HEREDOC bien dégueulasse avec un cat pipé sur kubectl apply ?
• C’était compliqué de mettre un YAML simple à copier et nous dire de remplacer la clé request avec une chaîne b64 ? De toute façon on va devoir composer un YAML avec une chaîne b64 ? Pourquoi tu nous compliques la vie sérieux ?
• Les commandes sont confusantes entre certificate approve/deny et get certificatesigningrequest.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

cat \<\<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth
EOF

Dégueux non ? C’est compliqué de faire comme ça ? Bon c’est pas grand chose, mais ça m’énerve :)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: <your_b64_encoded_crt>
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth

persistentVolume et persistentVolume binding:

• Pas de commande impérative pour créer des volumes.
• Le binding PV et PVC doit être absolument exacte.
• Complètement contre-productif de créer des volumes et des binding manuel sur les noeuds, c’est une mauvaise pratique personne ne devrait faire ça.
  • il faut traiter les nodes comme des pods et considéré qu’il sont destructible sans perte d’information.
  • les volumes doivent être gérés sur un système distribué.

networkPolicy:

• Pas de commande impérative pour générer des YAML facilement.
• Si on n’est pas habitué à faire des règles de firewall, le YAML est super chiant à écrire et à déboguer.
• Exemple dans la doc, soit trop simpliste, soit trop compliqué. -Sujet un peu boudé parce qu’il peut être bloquant sur la prod si on fait des erreurs de configuration et qu’on n’est pas habitué.

Backup restore ETCD:

• L’action n’est pas difficile en soi une fois qu’on connaît bien les paramètres obligatoires, mais c’est facile de perdre du temps bêtement si on ne fait pas les choses dans l’ordre.
• Oublier d’exporter la variable ETCDCTL_API=3, débile d’avoir à encore le faire, je comprends pas pourquoi on n’utilise pas directement la version 3 par défaut, mais c’est un piège facile :)
• Se mélanger les pinceaux entre certificat, CA certificat et clé du serveur et du client ETCD.
• Oublier que la commande de restore est asymétrique et n’a pas besoin d’authentification pour restorer vers un autre dossier.
• Éditer correctement le manifest YAML pour changer proprement le path du volume.
• Paniquer et faire n’importe quoi si le cluster ne remonte pas dans un délai qui semble rapide.
• La doc est OK quand on sait où chercher et que les chemins des certificats sont standards.
• On en fait tout un foin mais un versionning des yaml est tout aussi efficace. kube-backup, simple et sécurisé avec git-crypt pour les secrets. https://github.com/pieterlange/kube-backup
• Je pars du principe que si ETCD est mort en prod, autant refaire un cluster sain avec les derniers manifests et des backups de données saines.

Une facon simple de géré le backup c’est de prendre dans la doc la commande de list members, de virer l’entrypoint, remplacer list member par snapshot save /opt/backup.db. La méthode de Mumshad de lister les certs dans le manifest ETCD et de copier un part un les bon chemins, fonctionnera toujours mais c’est une perte de temps considérable.

RBAC:

• Ce n’est pas tant compliqué, c’est juste que ce n’est pas une action qu’on fait souvent.
• Ça prend du temps de le faire juste et du temp pour le vérifier.
• C’est réputé comme compliqué, moi je dirais juste que c’est chiant :)
• Bien penser à tester les permissions en mode –as user et tout ira bien.

En fait, on s’en tape que tu sais lancer des YAML rapidement, que tu connaisse l’administration des briques de base de kubernetes aussi

Tout le monde s’en fout que vous pouvez lancer des YAML rapidement dans un cluster, si ce n’est pas tracé et versionné, ça n’a aucune valeur dans un contexte GitOps. On veux des yaml versionnés et déployer dans un contexte de CI/CD ou en mode pull avec argocd.

Lancer des pods en dur, personne ne fait ça et c’est complètement con. Lancer des deployments sans réservations de ressources et sans probes, c’est parfaitement débile aussi. Monter des volumes hostpath sur des nœuds qu’on considère comme destructibles, c’est la porte ouverte aux incidents de production et à la perte de données catastrophique.

Pourquoi on vous demande ça à la certification ? Parce que c’est le moyen le plus rapide de manipuler des PV et PVC et de faire de l’accrochage de volume manuel. Est-ce qu’on s’en tape pas comme de l’an 40 que vous avez fait un schedule statique sur l’un de vos pods ? Pire encore, ne faites jamais ça dans un contexte de production, laisser kubernetes gérer ces trucs là. Ok, c’est peut-être un peu rigolo de jouer avec les briques de base de Kubernetes, mais ça ne devrait jamais vous occuper plus que quelques incidents dans l’année, avec un cluster qui crashe à cause d’une mise à jour daubé.

Mais dans la pratique, on s’en balance royalement. Ce n’est pas plus important de maîtriser l’administration des briques de base Kubernetes et les mises à jour de cluster que de maintenir la disponibilité de vos services métier. Je n’ai pas envie d’être réveillé en astreinte pour redémarrer un service kubelet qui décide de partir en live en pleine nuit.

Par contre, savoir gérer la densité de pods sur les nœuds, le reste de ressources disponibles, les pods qui partent en live, des services mal dimensionnés, la haute disponibilité des services, les HPA, PDD, bricoler du Kustomize, ArgoCD, Helm, on n’en parle zéro pendant la certification. Et c’est sacrément dommage, parce que c’est la seule plus-value de Kubernetes : gérer toutes ces problématiques en dehors du stupide cluster Kubernetes et de sa base etcd du démon :)

La CKA, c’est inutile du coup ?

Je viens de faire 10 lignes qui démontent la certification. Maintenant, je vais vous dire ce qui a de la valeur à mon sens dans cette certification.

• Je n’ai pas le choix, je n’ai pas de services managés trop stylés qui font tout pour moi. Là, oui, c’est important de comprendre le fonctionnement global de Kubernetes, kubeadm, la gestion des nœuds, des versions.
• J’ai besoin de rassurer mon client sur mes capacités à prendre en main son cluster maison.
• Je débute sur Kubernetes et c’est une très bonne entrée en matière du sujet.
• J’ai envie de passer un examen technique un peu exigeant et prendre plaisir à faire un examen réputé comme difficile.
• J’ai beaucoup trop de temps et de détermination pour passer à côté d’une opportunité de progresser.

Post-CKA, que faire ?

Si tu as la CKA, ne t’arrête pas là, utilise tes compétences pour les garder en mémoire et travailler sur Kubernetes. Essaye les services managés des clouds providers pour comprendre comment ils fonctionnent et ce qu’ils apportent. Coeur énorme sur GKE Autopilot ! Apprends à faire des tests de charges, delete des pods au hasard et regarde comment ça se passe. Fais un cluster HA avec plusieurs serveurs physiques dans des zones différentes. Apprends à faire du Flux ou de l’ArgoCD, le GitOps est désormais incontournable pour l’administration de cluster. Regarde les 12 facteurs App pour construire des microservices pas trop débiles. Regarde les scanners de containers pour patcher les containers vulnérables avant qu’ils ne trainent trop en production. Suivis les bonnes pratiques de construction de containers.

Pas de fork dans le container, il bind le pid 1. Pas de multiples processus dans le container, autant que possible. (genre nginx php dans le même container c’est non !) Pas d’user root qui fait tourner le service. Assure-toi que tes pods ne fassent pas d’écriture des logs sur disques, ou autre donnée non persistée. Liveness avec un timeout permissif, readiness un peu plus serré. Utilise des statefulsets si tu attaches des volumes et utilise des volumes distribués sur Ceph ou NFS (ou disque managé un peu large, pour éviter d’avoir à les redimentionner si tu fait du cloud). Fais des tests de charges représentatifs de ta production pour configurer des HPA au plus juste et avoir un cluster élastique à la charge.

Apprends à gérer les services externes et les bases de données à l’extérieur de ton cluster. Considère ces nœuds comme des serveurs snowflakes, mais automatise les et rends-les les plus solides possibles. Tes services externes legacy peuvent parfois être proxifiés et mis en cache en reverse proxy cache. Ça permet de survivre à certaines indispo de backends externes à ton cluster et de donner un peu de répit à ton legacy moisi. Petit article, condensé d’expérience et de haine en barre (au fond je sais que c’est ce que vous aimez), mais je pense qu’il fallait ma petite pierre aérodynamique lancée dans la tête de la CKA.

Prends plaisir, amuse-toi et défonce moi cette certif :)