Docs

Cluster Console

À quoi sert cet écran

Cluster Console donne un accès direct à vos clusters Kubernetes depuis Fenwave : parcourir n’importe quel type de ressource, en lire une intégralement, et agir dessus.

C’est la seule surface de Deploy qui modifie directement l’état d’un cluster, sans passer par un environnement ni par une release. Cela en fait l’écran le plus utile quand quelque chose ne va pas, et celui à manier avec le plus de précaution.

Avant de commencer

Pour faire ceci Il vous faut
Ouvrir la console et parcourir les ressources cluster-console.read
Éditer, cloner, scaler, redémarrer, cordon, uncordon, drain cluster-console.write
Supprimer une ressource cluster-console.delete
Ouvrir un terminal dans un pod cluster-console.exec
Faire un port-forward cluster-console.portforward
Lire le contenu d’un Secret cluster-console.secret.read
Agir sur un namespace ou un kind protégé cluster-console.protected.override

Deux de ces permissions ne sont volontairement pas impliquées par write :

  • cluster-console.exec est un droit à part entière. Un shell dans un pod contourne toutes les autres permissions de cette liste : détenir write ne doit donc jamais impliquer de le détenir.
  • cluster-console.secret.read est distincte de la lecture des ressources, car voir qu’un Secret existe et voir ce qu’il contient sont deux choses différentes.

Les clusters que vous voyez sont déterminés cluster par cluster par le backend, et non par le menu. Deux personnes détenant toutes deux cluster-console.read peuvent légitimement voir des clusters différents.

L'interface est un confort ; c'est le serveur qui décide

Les boutons sont masqués lorsque la permission manque, mais chaque action est de nouveau autorisée côté serveur. Un bouton masqué est une commodité, pas le contrôle.

Ouvrir l’écran

  1. Deploy › Cluster Console dans la barre latérale.

URL directe : /cluster-console. Le journal d’audit se trouve sur /cluster-console/audit.

L’interface

📸 Capture d’écran : Cluster Console affichant des pods. Repères : (1) le rail des types de ressources, (2) le sélecteur de cluster, (3) le sélecteur de namespace, (4) la recherche et les filtres de labels, (5) le compteur de résultats, (6) le menu d’actions d’une ligne.

# Élément Ce qu’il fait Quand l’utiliser
1 Rail des types de ressources Choisit le type parcouru Toujours ; repliable pour gagner de la place
2 Sélecteur de cluster Quel cluster Toujours
3 Sélecteur de namespace Un namespace, ou tous Restreindre une recherche
4 Recherche et Labels Recherche libre, plus des sélecteurs de labels comme app=web,tier=api Trouver une ressource parmi beaucoup
5 Compteur de résultats Combien de ressources correspondent Vérifier un filtre
6 Menu d’actions Les actions disponibles sur cette ressource Agir

Les actions

Action Nécessite Disponible sur
Edit YAML write Tout type
Clone write Tout type — produit un manifeste que vous éditez avant tout envoi
Scale write Les types scalables
Restart write Les types redémarrables
Cordon / Uncordon write Les nodes — seule celle qui a du sens est proposée
Drain write Les nodes
Terminal exec Les pods
Delete delete Tout type

Garde-fous

Deux protections précèdent chaque mutation, côté serveur :

  1. Namespaces et kinds protégés. Les namespaces et types configurés refusent toute mutation, sauf si vous détenez cluster-console.protected.override. L’erreur nomme la protection qui vous a arrêté.
  2. Confirmation par saisie du nom. Delete, Drain et Cordon exigent de saisir le nom exact de la ressource. Une divergence est refusée. Ce garde-fou existe parce que ce sont les trois actions dont les conséquences sont les plus difficiles à annuler.

Procédures

Trouver une ressource

  1. Deploy › Cluster Console, choisissez le cluster.
  2. Choisissez le type dans le rail.
  3. Restreignez avec le sélecteur de namespace, puis la recherche ou les sélecteurs de labels.
  4. Vérifiez que le compteur de résultats correspond à vos attentes avant d’agir.

Éditer une ressource

Nécessite cluster-console.write.

  1. Trouvez-la, ouvrez le menu d’actions, choisissez Edit YAML.
  2. Modifiez et appliquez.

Préférez Clone quand vous voulez une variante : cela produit un manifeste que vous éditez avant tout envoi, si bien qu’une erreur ne coûte rien.

Supprimer une ressource

Nécessite cluster-console.delete.

  1. Trouvez-la et choisissez Delete.
  2. Saisissez le nom exact de la ressource pour confirmer.

Si le namespace ou le type est protégé, l’action est refusée quelle que soit votre permission de suppression. C’est le garde-fou qui fonctionne.

Ouvrir un terminal

Nécessite cluster-console.exec — indépendamment de write.

Trouvez le pod et choisissez Terminal. Tout ce que vous y faites s’exécute avec l’identité du pod, et est consigné dans le journal d’audit.

Scénario

Un pod boucle en crash sur le staging.

  1. Deploy › Cluster Console, sélectionnez le cluster de staging, choisissez Pods.
  2. Renseignez le namespace, ou recherchez par nom. Utilisez un sélecteur de labels comme app=web si vous les connaissez : c’est plus rapide que de faire défiler.
  3. Ouvrez le pod et lisez son statut et ses événements. La plupart des boucles de crash y nomment leur propre cause : une probe en échec, une configuration absente, une image qui ne se télécharge pas.
  4. Comparez les limites de ressources du conteneur à sa consommation. Un pod qui redémarre cycliquement sans erreur applicative est généralement tué par l’OOM.
  5. Déterminez la nature du problème avant d’agir :
    • Configuration — corrigez à la source, dans Détail d’un environnement ou DevOps Config, et non en éditant le pod en direct. Une édition ici est écrasée à la prochaine réconciliation.
    • Transitoire — Restart le workload propriétaire plutôt que de supprimer le pod.
    • À investiguer de l’intérieur — Terminal, si vous détenez exec.
  6. Si vous avez modifié quelque chose en direct, allez faire la même modification à la source. Sinon, le prochain déploiement annule silencieusement votre correctif et le problème revient sous une apparence neuve.

L’étape 5 constitue tout le scénario. Cluster Console rend facile la correction du symptôme dans le cluster, et cette correction dure exactement jusqu’à la prochaine réconciliation.

En cas de problème

Symptôme Cause Comment vérifier Solution
Cluster Console n’est pas dans le sous-menu Il manque cluster-console.read Access Explorer Demandez un rôle qui l’accorde
Un collègue voit un cluster que vous ne voyez pas La visibilité est déterminée cluster par cluster par le backend — Comportement attendu ; demandez l’accès à ce cluster
Le menu d’actions est vide Vous avez read mais ni write, ni delete, ni exec Access Explorer Demandez la permission précise
Terminal absent alors que vous pouvez éditer exec est un droit distinct, jamais impliqué par write Access Explorer Demandez explicitement cluster-console.exec
Le contenu des Secrets est masqué secret.read est distincte de la lecture des ressources Access Explorer Demandez cluster-console.secret.read
Action refusée : « namespace/kind protégé » Un garde-fou, pas un défaut de permission L’erreur nomme la protection Nécessite cluster-console.protected.override — ou, mieux, agissez ailleurs
Confirmation rejetée Delete, drain et cordon exigent le nom exact de la ressource La boîte de dialogue Saisissez le nom à l’identique
Votre modification a disparu L’environnement s’est réconcilié et l’a écrasée Détail d’un environnement Faites la modification à la source
Le bouton était visible mais l’action a échoué Le serveur réautorise indépendamment de l’interface L’erreur, puis le journal d’audit Faites confiance à la réponse du serveur

Pour aller plus loin