Kubernetes

Kubernetes

Intégration maintenue par Orkyvo (non certifiée par la CNCF ni par un fournisseur de cloud) pour tout cluster Kubernetes conforme, version 1.24 ou ultérieure : EKS, GKE, AKS, k3s, RKE2, clusters sur site.

Connexion

Cluster privé. L'API server d'un cluster privé (ex. 10.0.12.4:6443) est refusée par défaut ; un administrateur de la plateforme peut autoriser cette plage et ce port pour cette organisation et cette connexion (Administration → Réseaux privés). Boucle locale, lien local et métadonnées cloud restent toujours refusés ; chaque redirection est revérifiée.

« Tester la connexion » lit /version, liste un pod de l'espace de noms, puis vérifie chaque droit utilisé par le nœud avec SelfSubjectAccessReview (lecture seule : rien n'est créé ni modifié) et affiche les droits manquants.

RBAC : droits limités, sans cluster-admin

Compte de service et rôle limités à un espace de noms :

apiVersion: v1
kind: ServiceAccount
metadata: { name: orkyvo, namespace: production }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: orkyvo, namespace: production }
rules:
  # Lecture et surveillance (actions de lecture, déclencheurs)
  - apiGroups: [""]
    resources: [pods, pods/log, services, events]
    verbs: [get, list, watch]
  - apiGroups: [apps]
    resources: [deployments]
    verbs: [get, list, watch]
  # Écritures : retirez les règles inutiles à vos workflows
  - apiGroups: [apps]
    resources: [deployments]
    verbs: [patch]          # redémarrage, image
  - apiGroups: [apps]
    resources: [deployments/scale]
    verbs: [patch]          # mise à l'échelle
  - apiGroups: [batch]
    resources: [jobs]
    verbs: [get, list, create]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: orkyvo, namespace: production }
subjects: [{ kind: ServiceAccount, name: orkyvo, namespace: production }]
roleRef: { kind: Role, name: orkyvo, apiGroup: rbac.authorization.k8s.io }

Lecture seule : ne gardez que le premier bloc de règles. Lister les espaces de noms et l'espace de noms * exigent un ClusterRole (ex. get, list, watch sur namespaces, pods…) : à n'accorder que si nécessaire.

Actions

Déclencheurs : fenêtres de watch (interrogation explicite)

Le moteur de workflows exécute les déclencheurs sous forme de passages courts et persistants ; un watch Kubernetes ouvert en continu n'est pas utilisé. Le mécanisme, explicite et documenté, est le suivant :

1. Premier passage : liste (resourceVersion de la collection, état connu des objets) ; aucun événement émis.
2. Passages suivants (30 s par défaut, 15 s minimum) : watch=1&resourceVersion=<curseur>&timeoutSeconds=3&allowWatchBookmarks=true. Les événements reçus pendant la fenêtre sont traités, les marque-pages font avancer le curseur.
3. Reprise : le resourceVersion est conservé en base ; après un redémarrage, le watch reprend depuis cette version.
4. Expiration (410 Gone) : la liste est relue et comparée à l'état connu ; créations, modifications et suppressions intervenues pendant l'interruption sont signalées, puis le watch reprend.
5. Dédoublonnage : identifiant stable par événement (uid + resourceVersion, ou nombre d'occurrences pour les événements Warning).

300 objets au plus sont suivis par déclencheur pour la resynchronisation : restreignez avec un espace de noms et un sélecteur de libellés.

Erreurs

401 jeton refusé ou expiré · 403 droit RBAC manquant (règle à ajouter indiquée) · 404 ressource ou espace de noms introuvable · 409 conflit / déjà existant · 410 version expirée (resynchronisation) · 429 et 5xx temporaires (lectures relancées selon Retry-After). Certificat refusé : ajoutez l'autorité du cluster.

Limites

• Tests automatisés sur API simulées. Test réel recommandé sur un cluster jetable (kind, k3d) : voir docs/INTEGRATIONS.md.