k8s-shared

Ce dépôt est conçu pour gérer le flux de travail GitOps pour le cluster shared. Il prend spécifiquement en charge les déploiements d'applications offerts à la communauté étudiante et non seulement à un club.

Liens Utiles

• Wiki : CEDILLE WIKI

• Portail des clusters : Omni Sidero – Récupérer les fichiers kubeconfig ici.

• Site web : cedille.etsmtl.ca

Prise en Main

Flux de Travail

Si vous êtes membres de l'organisation GitHub ClubCedille, vous pouvez cloner le dépôt localement, apporter vos modifications sur une branche (de préférence une branche liée à un issue), puis pousser vos changements sur cette branche. Ensuite, vous pouvez soumettre une demande de pull (une pull request) vers la branche main ou master.

Politique kube-score

kube-score s'exécute en CI (via ClubCedille/cedille-workflows, kubernetes-repo-standards.yml → kube-score-validator.yml) sur les manifestes rendus de chaque kustomization. Un finding [CRITICAL] fait échouer le build.

Le problème

De nombreuses apps de ce dépôt utilisent helmCharts: pour consommer un chart Helm upstream (Authentik, Grafana, Loki/Mimir, NetBox, Nextcloud, SonarQube, Forgejo, Matomo, SCM-Manager, etc.) ou une base kustomize distante (MetalLB). Le club ne contrôle pas les templates de ces charts : container-resources, les uid/gid de securityContext, l'absence de NetworkPolicy par défaut ou le tag d'image utilisé par un sous-chart sont hors de notre portée directe. Historiquement, ça s'est traduit par un cycle chronique "push → CI échoue sur des findings sans rapport avec le changement → patch au cas par cas → re-push" (56 commits mentionnant kube-score/kubescore dans l'historique de ce dépôt depuis juin 2025).

Le pattern retenu : patch kustomize + annotation kube-score/ignore

kube-score respecte une annotation kube-score/ignore: <check-1>, <check-2>, ... posée sur la ressource elle-même (pas sur le pod template). Pour les ressources issues d'un chart Helm, on ne peut pas éditer le template directement : on utilise donc un patch kustomize ciblé (patches: dans le kustomization.yaml) qui réinjecte cette annotation après le rendu du chart. Exemple de référence : apps/clubs/capra/wiki/base/kustomization.yaml.

Checks systématiquement ignorés sur les workloads issus de helmCharts: (ou d'une base distante non éditable) dans ce dépôt et dans k8s-base :

• container-resources
• container-ephemeral-storage-request-and-limit
• container-security-context-user-group-id
• pod-networkpolicy
• container-image-tag
• container-image-pull-policy

Ces checks restent actifs et bloquants pour tout manifeste écrit directement par le club (hors helmCharts:), et pour les checks suivants même sur les ressources issues d'un chart, qui restent volontairement non ignorés :

• container-security-context-privileged (containers privilégiés)
• pod-probes / pod-probes-identical (absence totale de liveness/readiness)
• container-security-context-readonlyrootfilesystem

Apps couvertes à ce jour par ce pattern (voir aussi k8s-base/common/*) : apps/clubs/capra/wiki, apps/clubs/sonia/wiki, apps/clubs/synapsets/wiki, apps/authentik, k8s-base/common/vault/base, k8s-base/common/external-dns, k8s-base/common/external-dns-cedille, k8s-base/common/rook, k8s-base/common/netdata, k8s-base/common/metallb. Les 20+ apps helmCharts: restantes (Grafana, Loki, Mimir, NetBox, Nextcloud, SonarQube, Forgejo, Matomo, SCM-Manager, Penpot, Supabase, ...) doivent recevoir le même traitement au fil de l'eau — voir les notes d'audit CI locales (hors dépôt, docs/revue-infra-2026-09/05-kubescore-ci-fix.md) pour le suivi.

Échappatoires existantes (à éviter en usage courant)

• Commentaire PR /kube-score skip : bypass ponctuel du gate CI sans trace pérenne dans le repo. À réserver aux urgences, pas à un contournement récurrent d'un chart connu.
• kube-score/ignore posé directement dans un manifeste écrit par le club : à utiliser au cas par cas, avec justification en commentaire, jamais pour blanket-ignorer une ressource entière.

Proposition en cours côté cedille-workflows

Le gate CI actuel (grep '^[CRITICAL]' ... => exit 1) ne fait pas la distinction entre repos/ressources. Une proposition de split blocking/non-blocking, scopée aux kustomizations contenant helmCharts:, est documentée dans les notes d'audit CI locales (hors dépôt, docs/revue-infra-2026-09/05-kubescore-ci-fix.md) et dans une branche locale non poussée de cedille-workflows. Une fois ce gate corrigé et son taux de faux positifs mesuré, scripts/kube-validate.sh doit perdre son || true sur kube-score pour revenir à une parité stricte local/CI.