Commandes essentielles CKA, Cheatsheet enrichie

Cette page est une référence opérationnelle pour la CKA. Elle contient les commandes essentielles organisées par domaine d'examen, avec le contexte d'usage et les pièges à éviter.

Pour les explications détaillées, consultez les guides dédiés (kubeadm, etcd, RBAC, etc.). Ici, l'objectif est de mémoriser les commandes et les réflexes.

Versions

Les exemples utilisent des versions comme v1.X.0. Adaptez à la version de l'environnement d'examen (actuellement Kubernetes v1.34 ou plus récent).

Configuration initiale

Ces alias sont indispensables. Configurez-les immédiatement au début de chaque session.

# Alias fondamentaux
alias k=kubectl
alias kn='kubectl config set-context --current --namespace'
export do="--dry-run=client -o yaml"

# Autocomplétion (OBLIGATOIRE)
source <(kubectl completion bash)
complete -F __start_kubectl k

# Éditeur
export KUBE_EDITOR=vim

Premier réflexe de chaque question :

# Vérifier et changer le contexte
kubectl config current-context
kubectl config use-context <cluster-name>
kubectl config get-contexts

Réflexes par situation

Ce tableau est votre outil de diagnostic rapide. Face à un symptôme, appliquez le premier réflexe.

Situation	Premier réflexe	Commande
Pod en erreur	Describe + logs previous	kubectl describe pod X puis kubectl logs X --previous
Node NotReady	Describe + logs kubelet	kubectl describe node X puis journalctl -u kubelet
Service ne répond pas	Vérifier endpoints	kubectl get endpoints X
PVC Pending	Vérifier PV et SC	kubectl get pv,pvc,sc puis kubectl describe pvc X
Scheduling échoue	Events du Pod	kubectl describe pod X → section Events
Cluster cassé	État global	kubectl get nodes + kubectl get pods -n kube-system
API server down	Static pods	crictl ps ou vérifier /etc/kubernetes/manifests/
etcd cassé	Logs etcd	kubectl logs -n kube-system etcd-master
DNS ne résout pas	CoreDNS up?	kubectl get pods -n kube-system -l k8s-app=kube-dns
Permissions refusées	Test RBAC	kubectl auth can-i <verb> <resource> --as=<user>

Glissez pour voir

À connaître par cœur

Ces éléments reviennent constamment. Ne les cherchez pas pendant l'examen.

Chemins critiques

Ces emplacements sont ceux d'un cluster installé par kubeadm. Le premier compte le plus en dépannage : le kubelet relit /etc/kubernetes/manifests/ en continu, déplacer un fichier hors de ce répertoire suffit à arrêter le composant correspondant.

# Static pods (control plane)
/etc/kubernetes/manifests/

# Certificats PKI
/etc/kubernetes/pki/

# Certificats etcd
/etc/kubernetes/pki/etcd/

# Configuration kubelet
/var/lib/kubelet/config.yaml
/etc/kubernetes/kubelet.conf

# Kubeconfig admin
/etc/kubernetes/admin.conf
~/.kube/config

Ordre d'upgrade cluster

L'ordre n'est pas négociable : l'API server ne doit jamais être plus ancien que les kubelets qui s'y connectent. Les workers passent un par un, chacun encadré d'un drain et d'un uncordon, pour que les applications restent disponibles pendant l'opération.

1. kubeadm sur le control plane
2. kube-apiserver, scheduler, controller-manager (automatique via kubeadm)
3. kubelet + kubectl sur le control plane
4. Drain le premier worker
5. kubeadm + kubelet + kubectl sur ce worker
6. Uncordon ce worker
7. Répéter pour chaque worker

Différences cordon / drain / uncordon

La confusion porte sur cordon, qui interdit l'arrivée de nouveaux pods mais laisse tourner ceux déjà présents. Seul drain évacue réellement le nœud, et il s'interrompt tant que les pods de DaemonSet ou les volumes emptyDir n'ont pas été explicitement acceptés par une option.

Action	Scheduling	Pods existants
cordon	❌ Bloqué	✅ Restent
drain	❌ Bloqué	❌ Évacués
uncordon	✅ Autorisé	sans objet

Glissez pour voir

Différences Role / ClusterRole

La troisième ligne est celle qui piège : un ClusterRole associé à un RoleBinding ne donne des droits que dans le namespace du binding. Ce montage sert à réutiliser une définition de permissions sans la recopier namespace par namespace.

Type	Portée	Ressources
Role + RoleBinding	1 namespace	Pods, Deployments, Secrets...
ClusterRole + ClusterRoleBinding	Tout le cluster	Nodes, PVs, Namespaces + tout
ClusterRole + RoleBinding	1 namespace	Réutilisation d'un ClusterRole, limité

Glissez pour voir

Labels PSA (Pod Security Admission)

Pod Security Admission s'active par un simple label de namespace, sans rien installer. Les modes enforce, audit et warn sont indépendants : seul enforce rejette réellement un pod non conforme.

# Appliquer la politique Restricted
kubectl label ns production pod-security.kubernetes.io/enforce=restricted

À retrouver dans la doc

Ces éléments sont plus complexes. Copiez-les depuis kubernetes.io le jour J.

• Syntaxe complète d'un Ingress avec TLS
• Champs avancés d'une NetworkPolicy (namespaceSelector, ipBlock)
• Options de kubeadm init avancées (HA, --upload-certs)
• Configuration EncryptionConfiguration pour secrets etcd
• Syntaxe PodDisruptionBudget

Bookmark recommandés :

• kubernetes.io/docs/reference/kubectl/quick-reference/
• kubernetes.io/docs/concepts/security/
• kubernetes.io/docs/tasks/administer-cluster/

Commandes par domaine

Les onglets reprennent le découpage des domaines de l'examen. Chacun regroupe les commandes réellement utilisées en épreuve, suivies des pièges signalés sous les blocs : ce sont eux qui coûtent des points, rarement la syntaxe de base.

Cluster Admin

kubeadm, Initialisation et upgrade

kubeadm init installe le control plane mais laisse le cluster sans réseau : les nœuds restent NotReady tant qu'aucun CNI n'est déployé. La valeur de --pod-network-cidr doit correspondre à celle attendue par ce CNI.

# Initialiser le control plane
kubeadm init --pod-network-cidr=10.244.0.0/16

# Configurer kubectl après init
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

# Générer la commande join
kubeadm token create --print-join-command

# Vérifier le plan d'upgrade
kubeadm upgrade plan

# Appliquer l'upgrade (adapter la version)
kubeadm upgrade apply v1.X.0

# Upgrade d'un worker
kubeadm upgrade node

Piège : Oublier de faire systemctl daemon-reload && systemctl restart kubelet après upgrade de kubelet.

Upgrade complet d'un worker

La séquence alterne entre deux machines : drain et uncordon s'exécutent depuis le control plane, l'installation des paquets sur le worker. kubeadm upgrade node met à jour la configuration locale, il ne remplace pas le paquet kubelet, d'où la ligne apt-get qui suit.

# Sur le control plane
kubectl drain worker1 --ignore-daemonsets --delete-emptydir-data

# Sur le worker
apt-get install -y kubeadm=1.X.0-1.1
kubeadm upgrade node
apt-get install -y kubelet=1.X.0-1.1 kubectl=1.X.0-1.1
systemctl daemon-reload
systemctl restart kubelet

# Sur le control plane
kubectl uncordon worker1

Guide kubeadm détaillé Installation et administration complète

etcd

Backup etcd

Les trois options de certificats sont obligatoires : etcd n'accepte que le TLS mutuel et refuse la connexion sans elles. Le snapshot porte sur le membre désigné par --endpoints, pas sur le cluster entier.

export ETCDCTL_API=3

etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Où trouver les certs ? Regardez dans /etc/kubernetes/manifests/etcd.yaml.

Vérifier le backup

snapshot status lit le fichier hors ligne, sans toucher au cluster, et affiche le hash, la révision et le nombre de clés. Un total de clés à zéro trahit une sauvegarde prise sur un endpoint vide.

etcdctl snapshot status /backup/etcd-snapshot.db --write-out=table

Restore etcd

La restauration crée une nouvelle arborescence de données : c'est ensuite le hostPath du manifest etcd.yaml qu'il faut faire pointer dessus. L'API server doit être arrêté pendant l'opération, d'où le déplacement de son manifest hors du répertoire surveillé par le kubelet.

# 1. Arrêter l'API server
mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/

# 2. Restaurer dans un NOUVEAU répertoire
etcdctl snapshot restore /backup/etcd-snapshot.db \
  --data-dir=/var/lib/etcd-restore

# 3. Modifier etcd.yaml → hostPath.path: /var/lib/etcd-restore

# 4. Relancer l'API server
mv /etc/kubernetes/kube-apiserver.yaml /etc/kubernetes/manifests/

Piège : Restaurer directement dans /var/lib/etcd au lieu d'un nouveau répertoire.

Health check

La sortie attendue tient en une ligne par endpoint, avec la mention is healthy et le temps de réponse. Les mêmes certificats que pour le snapshot restent exigés.

etcdctl endpoint health \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Nodes

Gestion des nodes

Le suffixe - est le détail à mémoriser : disktype- retire le label, et la même notation supprime un taint. Sur drain, l'option --ignore-daemonsets est presque toujours indispensable, tout cluster réel hébergeant des pods de DaemonSet.

# Lister avec détails
kubectl get nodes -o wide

# Diagnostic
kubectl describe node worker1

# Labels
kubectl label node worker1 disktype=ssd
kubectl label node worker1 disktype-   # Supprimer

# Taints
kubectl taint node worker1 dedicated=database:NoSchedule
kubectl taint node worker1 dedicated=database:NoSchedule-  # Supprimer

# Maintenance
kubectl cordon worker1
kubectl drain worker1 --ignore-daemonsets --delete-emptydir-data
kubectl uncordon worker1

# Métriques (Metrics Server requis)
kubectl top nodes
kubectl top pods --sort-by=memory

Effets des taints

NoExecute est le seul effet rétroactif : il évacue les pods déjà en place, là où NoSchedule se contente de bloquer les suivants. C'est cette distinction qui détermine l'impact immédiat d'un taint posé sur un nœud en production.

Effet	Comportement
NoSchedule	Nouveaux Pods bloqués, existants restent
PreferNoSchedule	Évite si possible (soft)
NoExecute	Évacue les existants + bloque nouveaux

Glissez pour voir

RBAC

Créer des Roles

La forme impérative évite d'écrire le YAML à la main, ce qui compte au chronomètre. Les verbes se listent séparés par des virgules sans espace, et l'oubli du -n place le Role dans le namespace courant.

# Role dans un namespace
kubectl create role pod-reader \
  --verb=get,list,watch \
  --resource=pods \
  -n development

# ClusterRole
kubectl create clusterrole node-reader \
  --verb=get,list,watch \
  --resource=nodes

Créer des Bindings

Le binding relie un Role à un sujet, désigné par --user, --group ou --serviceaccount. Pour un ServiceAccount, la syntaxe attendue est namespace:nom, à ne pas confondre avec le format complet utilisé par auth can-i.

# RoleBinding → user
kubectl create rolebinding reader-binding \
  --role=pod-reader \
  --user=jane \
  -n development

# RoleBinding → ServiceAccount
kubectl create rolebinding sa-binding \
  --role=pod-reader \
  --serviceaccount=development:myapp \
  -n development

# ClusterRoleBinding
kubectl create clusterrolebinding admin-binding \
  --clusterrole=cluster-admin \
  --user=admin

Tester les permissions

auth can-i interroge le module d'autorisation et répond yes ou no sans rien modifier. L'option --list donne toute l'étendue des droits d'un sujet, bien plus vite que de recomposer ses RoleBindings un par un.

# Mes permissions
kubectl auth can-i create pods

# Permissions d'un user
kubectl auth can-i delete pods --as=jane -n development

# Permissions d'un ServiceAccount
kubectl auth can-i list secrets \
  --as=system:serviceaccount:development:myapp \
  -n development

# Lister toutes les permissions
kubectl auth can-i --list --as=jane -n development

Format ServiceAccount : system:serviceaccount:NAMESPACE:NOM

Lister RBAC existant

Les Roles sont namespacés, d'où le -A pour les voir tous ; les ClusterRoles ne le sont pas. Un cluster fraîchement installé en compte déjà plusieurs dizaines, créés par le système lui-même.

kubectl get roles,rolebindings -A
kubectl get clusterroles,clusterrolebindings
kubectl describe role pod-reader -n development

Services

Créer des Services

kubectl expose reprend automatiquement le selector du Deployment, ce qui écarte la principale source d'erreur d'un Service écrit à la main. --target-port désigne le port du conteneur, --port celui du Service.

# ClusterIP (défaut)
kubectl expose deploy webapp --port=80 --target-port=8080

# NodePort
kubectl expose deploy webapp --port=80 --type=NodePort

# Avec nom personnalisé
kubectl expose deploy webapp --port=80 --name=webapp-svc

# Générer YAML
kubectl expose deploy webapp --port=80 $do > svc.yaml

Vérifier et débugger

La commande décisive est get endpoints : elle dit si le Service a trouvé des pods derrière son selector. Les deux kubectl run --rm -it créent un pod jetable, seul point d'observation depuis lequel la résolution DNS interne fonctionne.

# Lister
kubectl get svc -o wide

# Endpoints (IPs des Pods)
kubectl get endpoints webapp-svc

# Tester depuis un Pod
kubectl run test --image=busybox:1.36 --rm -it -- wget -qO- webapp-svc

# Test DNS
kubectl run test --image=busybox:1.36 --rm -it -- nslookup webapp-svc

Piège : Endpoints vide = selector ne matche aucun Pod.

DNS interne

Le nom court suffit à l'intérieur d'un même namespace ; ailleurs, il faut au minimum y accoler le namespace. Le suffixe complet n'est jamais obligatoire depuis un pod, la liste search du resolver le complétant automatiquement.

<service>.<namespace>.svc.cluster.local

• Même namespace : webapp-svc
• Cross-namespace : webapp-svc.production

Storage

PersistentVolume (admin)

Le PV est créé par l'administrateur et n'appartient à aucun namespace. La politique Retain conserve les données après suppression du PVC, au prix d'un volume qui reste en Released et qu'aucune nouvelle demande ne peut réclamer sans intervention manuelle.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-data
spec:
  capacity:
    storage: 10Gi
  accessModes: [ReadWriteOnce]
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: /data/pv

PersistentVolumeClaim (dev)

Le PVC exprime une demande, taille et mode d'accès, que Kubernetes confronte aux PV disponibles. Le storageClassName doit correspondre exactement à celui du volume visé, une chaîne vide et un champ absent n'ayant pas la même signification.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 5Gi
  storageClassName: manual

Commandes utiles

get pv,pvc montre d'un seul coup si la liaison a eu lieu, les deux objets passant en Bound. La dernière commande extrait la StorageClass marquée par défaut, celle qu'utilisera tout PVC dépourvu de storageClassName.

# Lister et vérifier binding
kubectl get pv,pvc

# Détails
kubectl describe pvc pvc-data

# StorageClasses
kubectl get sc

# SC par défaut
kubectl get sc -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")].metadata.name}'

Access Modes

Le mode demandé doit être supporté à la fois par le PV et par le stockage sous-jacent. RWX suppose un système de fichiers partagé, NFS ou CephFS par exemple : un disque bloc ne le fournira jamais, quelle que soit la déclaration du PV.

Mode	Description
RWO	Read/Write par 1 node
ROX	Read-only par plusieurs nodes
RWX	Read/Write par plusieurs nodes

Glissez pour voir

Piège : PVC Pending = taille ou accessMode ou storageClassName incompatible avec les PV disponibles.

NetworkPolicy

Deny all par défaut

Un podSelector: {} vide sélectionne tous les pods du namespace, et déclarer les deux policyTypes sans aucune règle coupe le trafic dans les deux sens. C'est la base sur laquelle viennent ensuite s'ajouter les autorisations.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Autoriser un trafic spécifique

Les NetworkPolicies s'additionnent : celle-ci ouvre un passage à travers le deny-all précédent sans l'annuler. Le podSelector de premier niveau désigne les pods protégés, celui du bloc from désigne les pods autorisés à les joindre.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080

Vérifier

describe affiche les règles avec leurs sélecteurs résolus, tels que le CNI doit les appliquer. Une policy présente dans cette liste n'est pas pour autant active : encore faut-il que le plugin réseau la prenne en charge.

kubectl get netpol -A
kubectl describe netpol allow-frontend -n production

Piège : NetworkPolicy nécessite un CNI compatible (Calico, Cilium). Flannel seul ne les applique pas.

Troubleshooting (30% de l'examen)

Les questions de ce domaine portent rarement sur une commande isolée : il faut localiser la panne avant de la corriger. La démarche descend du cluster vers le nœud puis vers le pod, chaque niveau ayant ses outils propres, kubectl d'un côté, journalctl et crictl de l'autre quand l'API ne répond plus.

Domaine le plus lourd

Le troubleshooting représente 30% de la CKA. Maîtrisez la méthodologie et les commandes de diagnostic.

Méthodologie

Ces cinq étapes écartent l'erreur la plus coûteuse en épreuve : corriger au hasard sans avoir lu les événements. Le niveau identifié à la deuxième étape commande les outils, un défaut de kubelet ne laissant aucune trace dans kubectl logs.

1. Identifier le symptôme : Que se passe-t-il exactement ?
2. Localiser le niveau : Pod, Node, ou Cluster ?
3. Collecter : describe, logs, events
4. Hypothèse : Quelle pourrait être la cause ?
5. Corriger et vérifier

État du cluster

cluster-info confirme que l'API server répond, get nodes que les kubelets s'y enregistrent. L'appel --raw='/readyz?verbose' détaille chaque contrôle interne du serveur et désigne le sous-système en échec.

# Vue d'ensemble
kubectl cluster-info
kubectl get nodes
kubectl get pods -n kube-system

# Health check
kubectl get --raw='/readyz?verbose'

Diagnostic Pod

describe passe avant logs : la section Events explique les échecs survenus avant même le démarrage du conteneur, image introuvable ou volume non monté, cas où aucun log n'existe. L'option --previous est le seul moyen de lire la sortie d'un conteneur déjà redémarré.

# État
kubectl get pod mypod -o wide

# Détails (ESSENTIEL)
kubectl describe pod mypod

# Logs
kubectl logs mypod
kubectl logs mypod --previous    # Après crash
kubectl logs mypod -c container  # Multi-container

# Shell
kubectl exec -it mypod -- /bin/sh

Diagnostic Node

Un nœud NotReady se diagnostique depuis la machine elle-même : describe node liste les conditions rapportées, mais la cause figure dans le journal du kubelet. Le filtre par fenêtre de temps évite de remonter des erreurs sans rapport avec l'incident en cours.

# Depuis le control plane
kubectl describe node worker1

# Sur le node problématique
systemctl status kubelet
journalctl -u kubelet | tail -50
journalctl -u kubelet --since "10 minutes ago" | grep -i error

Diagnostic composants control plane

Ces composants tournent en static pods, pilotés par le kubelet et non par l'API. Quand kubectl ne répond plus, crictl ps et les fichiers de /var/log/pods/ deviennent les seules sources d'information disponibles sur le nœud.

# Logs des static pods
kubectl logs -n kube-system kube-apiserver-master
kubectl logs -n kube-system etcd-master
kubectl logs -n kube-system kube-scheduler-master
kubectl logs -n kube-system kube-controller-manager-master

# Ou directement sur le node
crictl ps
cat /var/log/pods/kube-system_kube-apiserver-*/kube-apiserver/*.log

Problèmes courants et solutions

Ce tableau se lit du symptôme vers la cause : l'état affiché par kubectl get pods restreint déjà fortement les hypothèses. CreateContainerConfigError et ImagePullBackOff se distinguent ainsi d'emblée, le premier venant d'un ConfigMap ou d'un Secret absent, le second du registry.

Symptôme	Cause probable	Solution
Pod Pending	Pas de node eligible	Vérifier taints, resources, nodeSelector
Pod ImagePullBackOff	Image inexistante ou credentials	Vérifier nom image, registry secret
Pod CrashLoopBackOff	App crash	kubectl logs --previous
Pod CreateContainerConfigError	ConfigMap/Secret manquant	kubectl describe pod → Events
Node NotReady	kubelet down	systemctl restart kubelet
Node MemoryPressure	RAM saturée	Évacuer des Pods
Service non accessible	Endpoints vide	Vérifier selector vs labels Pods
DNS timeout	CoreDNS down	Vérifier Pods kube-dns
kubectl timeout	API server down	Vérifier /etc/kubernetes/manifests/

Glissez pour voir

Génération YAML rapide

La variable $do définie au début de la page ajoute --dry-run=client -o yaml : la ressource n'est pas créée, son manifest part sur la sortie standard. C'est la technique la plus rentable de l'épreuve, produire un squelette valide puis l'éditer coûtant bien moins de temps qu'écrire le YAML de mémoire.

# Pod
kubectl run nginx --image=nginx $do > pod.yaml

# Deployment
kubectl create deploy webapp --image=nginx --replicas=3 $do > deploy.yaml

# Service
kubectl expose deploy webapp --port=80 $do > svc.yaml

# Job
kubectl create job myjob --image=busybox -- /bin/sh -c "echo hello" $do

# CronJob
kubectl create cronjob mycron --image=busybox --schedule="*/5 * * * *" -- date $do

# ConfigMap
kubectl create cm myconfig --from-literal=key=value $do

# Secret
kubectl create secret generic mysecret --from-literal=password=secret $do

# Role
kubectl create role myrole --verb=get,list --resource=pods $do

# RoleBinding
kubectl create rolebinding mybinding --role=myrole --user=jane $do

# ServiceAccount
kubectl create sa mysa $do

Cheatsheet condensée

Ce bloc rassemble les commandes des sections précédentes pour une relecture rapide avant l'épreuve. Les valeurs entre chevrons sont à remplacer, et les points de suspension d'etcdctl masquent les options de certificats qui, elles, ne peuvent pas être omises.

# === CONTEXTE ===
kubectl config use-context <cluster>
kubectl config set-context --current --namespace=<ns>

# === CLUSTER ===
kubeadm init --pod-network-cidr=10.244.0.0/16
kubeadm token create --print-join-command
kubeadm upgrade plan && kubeadm upgrade apply v1.X.0

# === ETCD ===
export ETCDCTL_API=3
etcdctl snapshot save /backup/snap.db --endpoints=... --cacert=... --cert=... --key=...
etcdctl snapshot restore /backup/snap.db --data-dir=/var/lib/etcd-new

# === NODES ===
kubectl cordon/drain/uncordon <node>
kubectl taint node <node> key=value:NoSchedule
kubectl label node <node> disktype=ssd

# === RBAC ===
kubectl create role <name> --verb=get,list --resource=pods
kubectl create rolebinding <name> --role=<role> --user=<user>
kubectl auth can-i create pods --as=jane

# === TROUBLESHOOT ===
kubectl describe pod/node/svc <name>
kubectl logs <pod> --previous
journalctl -u kubelet | grep error
systemctl restart kubelet

À retenir

Les deux premiers points s'appliquent avant même de lire une question : sans alias ni autocomplétion le temps manque, et une réponse juste exécutée dans le mauvais contexte ne rapporte rien. Le reste se retient par la pratique, pas par la relecture.

1. Alias + autocomplétion : configurez-les immédiatement à chaque session
2. Contexte : vérifiez-le avant chaque question
3. etcd : mémorisez le chemin des certs (/etc/kubernetes/pki/etcd/)
4. Upgrade : control plane d'abord, puis workers avec drain/uncordon
5. RBAC : Role = namespace, ClusterRole = cluster
6. Troubleshooting = 30% : maîtrisez describe, logs, events, journalctl
7. Static pods : manifests dans /etc/kubernetes/manifests/
8. Génération YAML : utilisez $do systématiquement

Pour aller plus loin

• Parcours KCSA : Le versant sécurité, théorique, pour préparer la suite.
• Guide de préparation CKS : La certification sécurité, prochaine étape après la CKA.

×

📖 Voir la documentation →