Vue Kubernetes Manager d'Ambari (Aperçu technique)

Tech Preview — ODP 1.3.2.0

Cette fonctionnalité sera incluse dans ODP 1.3.2.0 en Tech Preview, actuellement en phase de qualification. Elle est disponible pour les tests entreprise en accès anticipé.

Intéressé par un accès anticipé ? Contactez notre équipe pour rejoindre le programme d'accès anticipé entreprise.

La vue Kubernetes Manager d'Ambari est un plugin Ambari qui étend la gestion du cluster aux charges de travail Kubernetes. Elle fournit une interface unifiée pour déployer, configurer, superviser et gérer le cycle de vie complet d'applications basées sur Helm s'exécutant sur un cluster Kubernetes ou OpenShift connecté — le tout dans la même interface Ambari utilisée pour gérer HDFS, YARN, Hive et les autres services du cluster.

Fonctionnement de la vue Kubernetes

La vue Kubernetes opère en tant que plugin côté serveur dans Ambari. Lorsque vous déployez une application via la vue, Ambari :

1. Lit la configuration actuelle du cluster (URI du Hive Metastore, realm Kerberos, URL REST de Ranger, paramètres LDAP, etc.)
2. Génère les valeurs Helm appropriées, en fusionnant les paramètres dérivés du cluster avec les remplacements fournis par l'utilisateur
3. Exécute l'installation ou la mise à niveau Helm contre le cluster Kubernetes configuré
4. Suit l'opération de déploiement de façon asynchrone et rapporte la progression via l'interface des opérations en arrière-plan d'Ambari
5. Surveille la release Helm déployée via Flux pour le statut continu

Cette approche garantit que les valeurs de configuration dérivées du cluster ODP (URIs, noms d'hôtes, paramètres de sécurité) sont toujours cohérentes avec l'état réel du cluster, plutôt que d'être dupliquées et potentiellement divergentes.

Installation du plugin Vue Kubernetes

La vue Kubernetes Manager est fournie avec Ambari 2.8.2.0. Si vous exécutez Ambari 2.8.2.0, la vue est disponible dans votre installation Ambari.

Pour activer la vue :

1. Connectez-vous à Ambari en tant qu'administrateur du cluster.
2. Naviguez vers Admin > Views.
3. Localisez KUBERNETES_MANAGER dans la liste des vues disponibles.
4. Cliquez sur Create Instance et renseignez :
   • Instance Name : un libellé pour cette instance de vue (ex. k8s-prod)
   • Display Name : le libellé affiché dans la barre latérale de l'interface Ambari
   • Description : description optionnelle

Une fois l'instance créée, la vue apparaît dans le menu Views d'Ambari et est accessible aux utilisateurs disposant du rôle Ambari approprié.

Connexion d'Ambari à un cluster Kubernetes

Avant de déployer des charges de travail, vous devez configurer la connexion entre Ambari et votre cluster Kubernetes.

Configuration du compte de service

Créez un compte de service dédié dans votre cluster Kubernetes pour qu'Ambari l'utilise :

# Créer le namespace pour les applications gérées par ODP
kubectl create namespace odp-apps

# Créer le compte de service
kubectl create serviceaccount ambari-manager -n odp-apps

# Créer un ClusterRole (ou un Role limité au namespace) avec les permissions requises
kubectl create clusterrolebinding ambari-manager-binding \
  --clusterrole=cluster-admin \
  --serviceaccount=odp-apps:ambari-manager

Moindre privilège

Le binding cluster-admin ci-dessus est utilisé par souci de simplicité. En production, restreignez le rôle aux groupes API et ressources spécifiquement requis : apps/deployments, core/services, core/configmaps, core/secrets, core/persistentvolumeclaims et batch/jobs.

Configuration du kubeconfig

Dans les paramètres de la vue Kubernetes, fournissez le kubeconfig ou les paramètres de connexion :

Paramètre	Description
URL de l'API Kubernetes	L'endpoint du serveur API (ex. https://k8s-api.example.com:6443)
Certificat CA	Le certificat CA du cluster (format PEM)
Token du compte de service	Token pour le compte de service ambari-manager
Namespace	Namespace cible pour les déploiements (ex. odp-apps)
Chemin du binaire Helm	Chemin vers le binaire Helm 3 sur le serveur Ambari

Ambari stocke le token du compte de service chiffré dans la base de données Ambari.

Vérification de la connexion

Après avoir enregistré les paramètres de connexion, cliquez sur Test Connection dans la vue Kubernetes. Ambari tentera de lister les ressources dans le namespace configuré. Un test réussi confirme que l'URL de l'API, les identifiants et la connectivité réseau fonctionnent correctement.

L'interface Kubernetes Manager

Une fois connectée, la vue Kubernetes fournit les flux de gestion suivants :

Catalogue d'applications

L'écran principal liste les applications disponibles au déploiement : actuellement Trino et Apache Superset. Chaque entrée affiche :

• Nom et version de l'application
• Statut du déploiement (Non déployé / Déployé / En cours de mise à niveau / Échec)
• Nom de la release Helm
• Horodatage de la dernière opération

Flux de déploiement

1. Sélectionnez une application dans le catalogue.
2. Cliquez sur Deploy.
3. L'assistant de configuration présente des paramètres regroupés :
   • Général : nombre de réplicas, demandes et limites de ressources
   • Sécurité : paramètres Kerberos (pré-remplis depuis le cluster), paramètres OIDC
   • Connectivité : URIs des connecteurs (pré-remplis depuis le cluster)
   • Avancé : remplacement brut des valeurs Helm (éditeur YAML)
4. Cliquez sur Deploy pour soumettre. Ambari crée une opération en arrière-plan.

Flux de mise à niveau

Lorsqu'une nouvelle version du chart est disponible :

1. Sélectionnez l'application déployée.
2. Cliquez sur Upgrade.
3. Examinez le diff de configuration entre la version actuelle et la nouvelle version.
4. Confirmez et soumettez. Ambari exécute helm upgrade et suit le déploiement.

Rollback

Si une mise à niveau échoue ou produit des problèmes :

1. Sélectionnez l'application déployée.
2. Cliquez sur Rollback.
3. Sélectionnez la révision cible dans l'historique de la release Helm.
4. Confirmez. Ambari exécute helm rollback et ramène la release à la révision sélectionnée.

Désinstallation

Pour supprimer une application déployée :

1. Sélectionnez l'application déployée.
2. Cliquez sur Uninstall.
3. Confirmez. Ambari exécute helm uninstall et supprime toutes les ressources Kubernetes créées par le chart.

Opérations en arrière-plan et suivi de la progression

Toutes les opérations Helm (installation, mise à niveau, rollback, désinstallation) s'exécutent en tant qu'opérations en arrière-plan dans Ambari. Cela signifie :

• Vous n'avez pas besoin de garder la fenêtre du navigateur ouverte pour que l'opération se termine.
• La progression est visible dans le panneau Background Operations d'Ambari (l'icône horloge dans la barre d'outils).
• Chaque opération produit un journal structuré qui affiche la sortie Helm et les éventuelles erreurs.
• Les opérations ont un timeout configurable (par défaut : 10 minutes).

Si une opération échoue, le journal de l'opération en arrière-plan contient la sortie d'erreur complète de Helm, essentielle pour le dépannage.

Surveillance du statut des releases GitOps et Flux

La vue Kubernetes s'intègre avec Flux (kit d'outils GitOps) pour fournir une surveillance continue du statut des releases. Lorsque Flux est configuré dans votre cluster Kubernetes et gère les releases Helm déployées par Ambari, la vue affiche :

• Statut HelmRelease Flux : si la release est réconciliée, en attente ou en erreur
• Heure de dernière réconciliation : quand Flux a vérifié la release par rapport à l'état désiré pour la dernière fois
• Détection de dérive : si des modifications manuelles ont été apportées aux ressources Kubernetes en dehors d'Ambari/Flux, le statut reflète la dérive

Cela est particulièrement utile dans les environnements où les changements d'infrastructure passent par un processus de révision GitOps. L'installation Helm d'Ambari crée ou met à jour la ressource personnalisée HelmRelease de Flux ; Flux gère la réconciliation effective depuis le dépôt Git.

Pour utiliser l'intégration Flux, installez Flux dans votre cluster Kubernetes avant de le connecter à Ambari :

flux install

La vue Kubernetes détectera automatiquement Flux si les CRDs Flux sont présents dans le cluster.

Délégation des keytabs Kerberos

Pour les applications qui ont besoin de s'authentifier auprès des services ODP (Hive Metastore, HDFS, Ranger), Ambari gère le provisionnement des keytabs :

1. Ambari génère ou récupère un keytab de service auprès de l'infrastructure Kerberos du cluster (FreeIPA ou MIT KDC).
2. Le keytab est stocké en tant que Secret Kubernetes dans le namespace de l'application.
3. Le chart Helm monte le secret keytab dans les conteneurs de l'application.
4. La configuration de l'application (ex. core-site.xml de Trino) référence le chemin du keytab.

Le principal de service utilisé pour chaque application est configurable dans l'assistant de déploiement. La convention de nommage par défaut suit : <service>/<hostname>@<REALM>.

Rotation des keytabs : lorsque le keytab est renouvelé dans Kerberos, le re-déclenchement de la mise à niveau Helm depuis Ambari mettra à jour le Secret Kubernetes avec le nouveau keytab.

Intégration de l'authentification OIDC

Pour les charges de travail exposant une interface web (Apache Superset), Ambari prend en charge la configuration de l'authentification OIDC (OpenID Connect) :

Paramètre	Description
URL du fournisseur OIDC	L'URL de l'émetteur du fournisseur OIDC (ex. votre instance Keycloak ou Dex)
Client ID	L'ID client OAuth2 enregistré pour cette application
Secret client	Le secret client OAuth2 (stocké chiffré dans Ambari)
Groupes autorisés	Groupes LDAP/AD dont les membres sont autorisés à accéder à l'application
Groupes admin	Groupes bénéficiant d'un accès administrateur dans l'application

Lorsque OIDC est configuré, le chart Helm est déployé avec le sidecar proxy OIDC ou la configuration OIDC native (selon l'application). Les utilisateurs accédant à Superset sont redirigés vers le fournisseur OIDC pour l'authentification.

OIDC et Kerberos sont complémentaires dans cette architecture : Kerberos sécurise les communications service-à-service en arrière-plan, tandis qu'OIDC sécurise les interfaces web orientées utilisateurs.

Matérialisation de la configuration Ranger et LDAP

L'un des principaux avantages de la vue Kubernetes est qu'elle lit la configuration de sécurité ODP existante et l'injecte automatiquement dans les valeurs Helm. Au moment du déploiement, Ambari matérialise :

Source de configuration ODP	Matérialisé dans
URL REST Ranger et identifiants admin	Configuration du plugin Ranger de Trino
URIs du Hive Metastore (depuis la config Hive)	hive.metastore.uri du catalogue Hive de Trino
Realm Kerberos et adresse KDC	ConfigMap krb5.conf dans Kubernetes
URL du serveur LDAP/AD et DN de liaison	Configuration d'authentification de Superset
URI du NameNode HDFS	Configuration HDFS de Trino

Cela élimine le besoin de copier manuellement les valeurs de configuration depuis vos configs Ambari dans les fichiers de valeurs Helm — un processus sujet aux erreurs qui conduit souvent à des mauvaises configurations.

Limitations connues (Aperçu technique)

Limitation	Notes
Pas d'intégration YARN	La gestion des ressources Trino est indépendante des files d'attente YARN
Pas de traçabilité Atlas pour Trino	Les requêtes via Trino ne sont pas capturées dans Atlas dans cette version
HA Superset non configurée via Ambari	Plusieurs réplicas Superset nécessitent un remplacement manuel des valeurs Helm
La rotation des keytabs nécessite un redéploiement manuel	Pas encore de déclencheur automatique de renouvellement des keytabs
Limité à un cluster Kubernetes par instance de vue Ambari	La prise en charge multi-cluster est prévue
Contraintes de contexte de sécurité OpenShift	Peut nécessiter une configuration SCC supplémentaire pour certains charts sur OpenShift

Ces limitations seront traitées dans les futures versions d'ODP au fur et à mesure que l'intégration Kubernetes passe de l'aperçu technique à la disponibilité générale.