Aller au contenu

Module 2b · k9s approfondi & personnalisation

Objectifs

  • Configurer k9s à ton goût (défauts, skin, mode lecture seule).
  • Gagner en vitesse avec alias, hotkeys et plugins.
  • Jongler entre plusieurs clusters (ex. sandbox ↔ EKS) sans quitter k9s.
  • Faire de l'admin depuis k9s : opérations sur les nœuds, vues RBAC, audit.
  • Durée : ~45 min · Pré-requis : Module 2 et Module 3 : on règle la vitesse une fois qu'on a des objets à naviguer.

Où vivent les fichiers de config ? La seule réponse fiable : k9s info

Ne cherche jamais le dossier de config de mémoire : demande-le à ta machine.

k9s info

Config:            /home/sandbox/.k9s/config.yaml
Skins:             /home/sandbox/.k9s/skins
Context Configs:   /home/sandbox/.k9s/clusters

Ici, dans ta sandbox, tout est regroupé sous ~/.k9s/ parce que la variable K9S_CONFIG_DIR est posée pour toi. Ailleurs - ton poste, un bastion, un Cloud9 - cette variable n'existe pas, et k9s (depuis la v0.50) range ses fichiers selon la norme XDG, à trois endroits différents :

Ce que tu cherches Sans K9S_CONFIG_DIR (le cas général)
config.yaml, aliases.yaml, hotkeys.yaml, plugins.yaml, views.yaml, skins/ ~/.config/k9s/
Config par contexte (un réglage différent par cluster) ~/.local/share/k9s/clusters/
Journaux, captures d'écran ~/.local/state/k9s/

Le piège du « ça marchait dans la sandbox »

Le chemin ~/.k9s/ que tu vas manipuler ici est une commodité de la sandbox, pas une vérité de k9s. Sur la machine où tu travailleras vraiment, ~/.k9s/ n'existera probablement pas - et tu chercheras un dossier fantôme. Le réflexe qui te sauve à chaque fois, sur n'importe quelle machine : k9s info.

Dans ce module, on écrit ~/.k9s/… pour rester collé à ta sandbox. Traduis avec le tableau ci-dessus quand tu seras ailleurs. Ces fichiers s'éditent au terminal avec nano (ex. nano ~/.k9s/config.yaml).

Configuration de base - config.yaml

k9s:
  # Fréquence de rafraîchissement (secondes)
  refreshRate: 2
  # Démarre en lecture seule (aucune action destructive) - idéal pour observer/démontrer
  readOnly: false
  ui:
    # Skin appliqué (cf. Skins)
    skin: dracula
    # Masquer le logo ASCII pour gagner de la place
    headless: false
    logoless: true
  # Comportement des logs
  logger:
    tail: 200
    buffer: 5000
    sinceSeconds: 300

Mode lecture seule à la volée

k9s --readonly lance une session sans aucune action destructive : parfait pour explorer une prod ou faire une démo sans risque de fausse manip. La suite du module en fait un réglage permanent, par cluster.

Skins (thèmes) - skins/

Crée ~/.k9s/skins/dracula.yaml puis référence-le dans config.yaml (ui.skin: dracula).

k9s:
  body:
    fgColor: "#f8f8f2"
    bgColor: "#282a36"
    logoColor: "#bd93f9"
  frame:
    border:
      fgColor: "#6272a4"
    title:
      fgColor: "#f8f8f2"
      highlightColor: "#ffb86c"

De nombreux skins prêts à l'emploi existent dans le dépôt k9s (skins/).

Alias de ressources - aliases.yaml

Raccourcis perso pour la commande :.

aliases:
  dp: deployments
  sec: secrets
  pp: pods
  cm: configmaps
  # Filtres pré-mâchés possibles via les vues (voir Personnaliser les colonnes)

Désormais :dp ouvre les deployments. (Ctrl-a liste tous les alias, natifs + perso.)

Hotkeys - hotkeys.yaml

Associe une touche à une commande, pour sauter là où tu veux en 1 frappe.

hotKeys:
  shift-d:
    shortCut: Shift-D
    description: Deployments
    command: deployments
  shift-p:
    shortCut: Shift-P
    description: Pods
    command: pods

Deux pièges qui font croire que « la hotkey ne marche pas »

  • Utilise des lettres (Shift-D), pas des chiffres : Shift-1 dépend de la disposition du clavier (sur un AZERTY, Shift+1 ne déclenche pas la hotkey).
  • La command est une commande k9s (le nom d'une ressource, comme si tu tapais :deployments), pas une commande kubectl : --all-namespaces n'y a pas sa place. Pour voir toutes les namespaces dans une vue, appuie sur 0.
  • Vérifie tes hotkeys chargées avec ? dans k9s.
  • Le message « HotKeys load failed! » qui clignote pendant que tu édites le fichier est normal : k9s relit sa config à chaque sauvegarde et râle sur un fichier à moitié écrit. Dès que le fichier est sauvegardé et valide, il disparaît (relance k9s au besoin).

Plugins - plugins.yaml

Ajoute des actions custom déclenchées par une touche sur une ressource. Exemple : suivre les logs d'un pod avec un défilement enrichi.

plugins:
  # Sur un pod : Ctrl-L -> logs en suivi
  logs-follow:
    shortCut: Ctrl-L
    description: "Logs (follow)"
    scopes:
      - pods
    command: kubectl
    background: false
    args:
      - logs
      - -f
      - $NAME
      - -n
      - $NAMESPACE
      - --context
      - $CONTEXT

Les variables $NAME, $NAMESPACE, $CONTEXT, $RESOURCE_NAME… sont injectées par k9s.

Personnaliser les colonnes - views.yaml

Affiche exactement les colonnes utiles pour une ressource.

k9s:
  views:
    v1/pods:
      columns:
        - NAME
        - READY
        - STATUS
        - RESTARTS
        - NODE
        - IP

Multi-cluster : jongler entre sandbox et EKS

C'est le super-pouvoir pour le module 5 (EKS) : observer deux clusters dans la même interface.

:ctx           ← liste les contextes ; Entrée pour basculer
:ctx <nom>     ← bascule direct vers un contexte

k9s --context mon-eks       # démarrer sur un contexte précis
kubectl config get-contexts # voir tous les contextes disponibles

Tip

Le contexte courant est toujours affiché en haut à gauche. Vérifie-le avant toute action destructive : on ne supprime pas un pod d'EKS en croyant être sur la sandbox.

Ne pas casser la prod : un réglage par cluster

Le jour où le même k9s ouvre ta sandbox et une prod, la vitesse n'est plus le sujet : le sujet, c'est de ne pas taper Ctrl-D sur le mauvais cluster. k9s sait appliquer des réglages différents selon le contexte - c'est ce que k9s info appelle « Context Configs » :

<dossier de config>/clusters/<cluster>/<contexte>/config.yaml

# ~/.k9s/clusters/mon-eks/prod-eks/config.yaml   (ailleurs : ~/.local/share/k9s/clusters/…)
k9s:
  readOnly: true          # (1)!
  skin: red               # (2)!
  namespace:
    active: production
  1. Sur ce cluster précis, k9s refuse toute action destructive - même si ta config globale, elle, autorise tout. C'est le garde-fou qui survit à ta fatigue de 18 h.
  2. Un skin rouge réservé à la prod : tu vois que tu n'es pas chez toi, avant même de lire le nom du contexte. Combiné à la lecture seule, c'est la ceinture et les bretelles.

k9s crée ce fichier tout seul la première fois qu'il se connecte à un contexte : tu n'as qu'à l'ouvrir et ajouter tes lignes.

Le réflexe à emporter

Prod en lecture seule par défaut, sandbox en écriture. Si tu dois vraiment agir sur la prod, tu enlèves le filet consciemment - et c'est exactement la différence entre une intervention et un accident.

Administrer depuis k9s

Opérations sur les nœuds - vue :nodes

Sélectionne un nœud : k9s propose (voir la barre du haut) cordon (interdire la planification), uncordon, et drain (vider le nœud de ses pods). Indispensable pour une maintenance.

Warning

drain évince les pods : à ne faire que sur la sandbox pour s'exercer, ou en connaissance de cause en prod.

Vues d'audit & relations

Commande Effet
:rbac Inspecter les règles RBAC du cluster
:xray deploy Arbre des relations (deploy → rs → pod)
:pulses Tableau de bord temps réel (santé globale)

L'audit popeye a quitté k9s

:popeye a longtemps été une vue de k9s ; elle a été retirée à la refonte v0.50. Popeye est de nouveau un outil séparé (même auteur que k9s), lancé au terminal - il est installé dans la sandbox. C'est un bon réflexe de veille : les outils évoluent, et une commande d'hier peut avoir déménagé.

Exercice 2b.1 - Popeye

Au terminal de la sandbox : 

popeye              # audit du cluster : note globale + problèmes par ressource
Repère un pod sans requests/limits et un autre problème signalé. Corrige-en un, relance popeye, vérifie que le score s'améliore.

Pratique

Le TP de ce module, dans le terminal de ta sandbox - une fois la lecture faite :

tp start 01b-k9s-perso   # k9s en administration : scaler, éditer à chaud, débugger, réparer

k9s ne crée pas les objets (ça, c'est kubectl / YAML) : c'est ton cockpit pour les opérer. Le décor est posé (deux déploiements, un sain, un cassé) ; tu poses un alias de confort, tu scales, tu édites l'image à chaud (touche e), puis tu débugges (touche d, section Events) et tu répares un déploiement en échec - sans quitter k9s.

fais la manip puis tp check (k9s agit hors du terminal : c'est tp check qui valide) · tp hint / tp solution si tu bloques.

En séance, on fait d'abord le tour de ce qui se configure ensemble (en partage d'écran) ; le TP te fait ensuite administrer pour de vrai. En autonomie : repère les fichiers, puis enchaîne le TP.

Exercice 2b.2 - Le tour de ta config k9s (on regarde ensemble)

Où k9s se personnalise, dans ~/.k9s/ :

  1. config.yaml : le skin, refreshRate, le namespace par défaut.
  2. views.yaml : les colonnes d'une ressource (cf. l'exemple ci-dessus).
  3. aliases.yaml et hotkeys.yaml : tes raccourcis (:dp, une touche → un écran).

On repère où ça se règle ; poser ton alias :dp puis administrer depuis k9s (scaler, éditer à chaud, réparer), c'est le TP 01b-k9s-perso qui te le fait faire.

Exercice 2b.3 - Deux clusters (sans attendre le module 5)

Pas besoin d'un vrai second cluster pour s'entraîner à ne pas les confondre : on fabrique un deuxième contexte qui pointe sur le même cluster, et on joue la bascule.

CTX=$(kubectl config current-context)                                     # ton contexte actuel
CL=$(kubectl config view -o jsonpath="{.contexts[?(@.name==\"$CTX\")].context.cluster}")
US=$(kubectl config view -o jsonpath="{.contexts[?(@.name==\"$CTX\")].context.user}")
kubectl config set-context faux-prod --cluster "$CL" --user "$US"         # le sosie
kubectl config get-contexts                                               # tu en as deux
  1. Lance k9s, fais :ctx : les deux contextes apparaissent, bascule sur faux-prod.
  2. Sans regarder ton historique, réponds : sur quel contexte es-tu ? (l'indicateur en haut à gauche)
  3. Donne à faux-prod sa config de contexte (readOnly: true, section précédente), rebascule, et vérifie que k9s refuse maintenant de supprimer un pod.
  4. Ménage : kubectl config delete-context faux-prod.

C'est la répétition générale du module 5 - et de ton quotidien le jour où le même terminal ouvre une sandbox et une production.

Ce qu'il faut retenir

  • La config est du YAML côté client (config, skins, aliases, hotkeys, plugins, views) - k9s info dit où, et la réponse change d'une machine à l'autre : ~/.k9s/ ici (variable K9S_CONFIG_DIR), ~/.config/k9s/ + ~/.local/share/k9s/ ailleurs.
  • --readonly = filet à la volée · readOnly: true dans la config du contexte = filet permanent sur un cluster donné (prod en lecture seule, sandbox en écriture).
  • :ctx pour le multi-cluster ; vérifie toujours le contexte avant d'agir.
  • :nodes (cordon/drain), :rbac, :pulses, :xray = l'admin sans quitter k9s.
  • L'audit popeye est un outil séparé au terminal (plus une vue k9s depuis la v0.50).

Quiz éclair

Teste-toi : réponds de tête, puis déplie.

1. Sur une machine que tu ne connais pas, où vit la configuration de k9s ?

La question se pose à la machine : k9s info. Le chemin dépend de l'environnement - ~/.k9s/ quand K9S_CONFIG_DIR est posée (le cas de ta sandbox), sinon les dossiers XDG : ~/.config/k9s/ pour la config et les raccourcis, ~/.local/share/k9s/clusters/ pour les réglages par contexte. C'est toujours du YAML côté client, versionnable.

1 bis. Comment protéger un cluster de prod des fausses manips, durablement ?

En posant readOnly: true dans la config de CE contexte (…/clusters/<cluster>/<contexte>/config.yaml) : k9s y refuse toute action destructive, quels que soient tes réglages globaux. --readonly fait la même chose, mais seulement pour une session.

2. Comment passer de la sandbox à un autre cluster sans quitter k9s ?

Avec :ctx (liste des contextes, Entrée pour basculer). Et on vérifie toujours le contexte affiché en haut à gauche avant toute action destructive.

3. À quoi sert k9s --readonly ?

À ouvrir une session sans aucune action destructive possible : idéal pour observer une prod ou faire une démo sans risque de fausse manip.

➡️ Suite : Module 3y - Le déclaratif (YAML)