Aller au contenu

Déployer AKKO sur OpenShift

OpenShift 4.14+ est une cible AKKO supportée. L'overlay values-openshift.yaml gère les trois spécificités OpenShift : Security Context Constraints (SCC), Routes vs Ingress, et politiques de pull registry.

Prérequis

Élément Version
OpenShift 4.14+ (testé OKD, ROSA, ARO)
Helm ≥ 3.14
CLI oc version correspondant au cluster
Projet pré-créé, rôle admin dessus
cert-manager pour les Routes Let's Encrypt (optionnel)

Installation en une commande

oc new-project akko

AKKO_DOMAIN=apps.client.example \
AKKO_VERSION=2026.04 \
AKKO_NAMESPACE=akko \
AKKO_VALUES_EXTRA=helm/examples/values-openshift.yaml \
  bash deploy-from-harbor.sh

L'overlay active les Routes (HAProxy) et désactive Traefik. Il positionne le bon SCC (anyuid n'est pas requis — AKKO v2026.04 tourne non-root partout, sauf les composants directory service/Dashboards en cours de migration qui sont remplacés par les alternatives Apache 2.0 d'ADR-020).

Spécificités OpenShift

Security Context Constraints

AKKO 2026.04 tourne sous le SCC restricted-v2 par défaut, sauf :

  • akko-lldap — requiert anyuid (runAsUser: 0 historique). Désactivé par défaut dans values-openshift.yaml ; utilisez plutôt la federation LDAP externe via Keycloak. Remplacement complet (389-DS) prévu Sprint 39.5.
  • kube-prometheus-stack[grafana] — requiert anyuid. Désactivé par défaut ; migration vers VictoriaMetrics + vmui (Apache 2.0, ADR-020).

Si vous devez quand même activer ces composants legacy sur OpenShift, accordez anyuid à leurs service accounts :

oc adm policy add-scc-to-user anyuid -z akko-akko-lldap -n akko
oc adm policy add-scc-to-user anyuid -z akko-grafana -n akko

Routes vs Ingress

L'overlay expose les services via des objets Route gérés par HAProxy (natif OpenShift) plutôt qu'un ingress controller externe. La terminaison TLS passthrough ou edge est configurable par service.

Pull d'images

Harbor harbor.akko-ai.com est public pour le projet AKKO : pas de pull secret requis. Si vous miroir sur un Quay / ImageStreams interne :

oc create secret docker-registry akko-pull \
  --docker-server=quay.interne.example \
  --docker-username=<user> \
  --docker-password=<token> \
  -n akko
oc secrets link default akko-pull --for=pull

Puis surchargez global.image.registry pour pointer sur votre miroir.

Machine Config (si tuning Node)

Certains workloads lourds (OpenMetadata, Spark Connect) bénéficient d'un tuning kernel. AKKO ne livre pas de MachineConfig — appliquez le profil standard de votre cluster. Commencez avec des workers 4 vCPU / 16 Gio.

Vérifier l'installation

oc -n akko get pods
oc -n akko get routes
oc -n akko exec svc/akko-trino -c trino -- trino --execute "SHOW CATALOGS"

Post-installation

  • Le pull Harbor fonctionne out-of-the-box pour le projet AKKO public
  • Configurer la federation LDAP Keycloak vers votre AD d'entreprise
  • Brancher la première source de données client via Admin → Data Catalogs

Dépannage

Symptôme Cause Correctif
Pod CrashLoopBackOff avec erreur runAsNonRoot Le chart exige non-root mais l'image tourne root par défaut Vérifier le podSecurityContext du sub-chart concerné — 2026.04 le corrige pour toutes les images first-party
Route renvoie 503 Service backend pas prêt oc describe pod pour le service correspondant
Erreurs certificat TLS cert-manager non installé ou DNS non résolu oc describe certificate -n akko + vérifier le DNS *.apps.client.example
PVC bloqué Pending SC par défaut ne supporte pas RWX AKKO 2026.04 réconcilie tous les PVC en RWO — vérifier avec oc get pvc