Cloud Native avec ODP — Vue d'ensemble de Kubernetes

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 vision : un plan de contrôle unique pour Hadoop et Kubernetes

ODP est construit sur le principe que votre équipe opérationnelle ne devrait pas avoir à gérer deux mondes entièrement séparés — un cluster Hadoop traditionnel d'un côté, et une plateforme Kubernetes de l'autre — avec des outils différents, des contrôles d'accès différents et des systèmes de supervision différents.

Avec Ambari 2.8.2.0, ODP introduit la vue Kubernetes Manager : un plugin qui étend le plan de contrôle Ambari pour orchestrer des charges de travail Kubernetes aux côtés de vos services de cluster HDFS, YARN, Hive, HBase et autres existants. La même interface Ambari que votre équipe utilise déjà pour l'administration du cluster acquiert la capacité de déployer, configurer, mettre à niveau et superviser des applications hébergées sur Kubernetes — aujourd'hui Trino et Apache Superset — en utilisant des charts Helm.

Il ne s'agit pas d'une réimplémentation de Kubernetes. Ambari ne remplace pas kubectl ni votre outillage Kubernetes existant. Ce qu'il fait, c'est fournir un chemin de déploiement gouverné et intégré qui connecte automatiquement les charges de travail Kubernetes au modèle de sécurité d'ODP (Kerberos, Ranger, LDAP), éliminant le travail d'intégration manuel qui fait typiquement du déploiement d'outils analytiques sur Kubernetes un projet de plusieurs semaines.

Quel problème cela résout-il ?

Les plateformes de données modernes ont de plus en plus besoin d'outils mieux adaptés au déploiement natif en conteneurs qu'aux services de cluster traditionnels :

• Trino (anciennement PrestoSQL) bénéficie d'une mise à l'échelle horizontale élastique des workers, que Kubernetes gère nativement.
• Apache Superset est une application web naturellement adaptée à une exécution en tant que service conteneurisé.

Sans l'intégration Kubernetes d'ODP, la connexion de ces outils à un cluster Hadoop sécurisé par Kerberos nécessite une gestion manuelle des keytabs, une configuration des politiques Ranger, un câblage LDAP et une synchronisation continue de la configuration entre systèmes. Un changement dans l'URI du Hive Metastore, par exemple, doit être répercuté à la fois dans la configuration du cluster et dans les valeurs Helm de Trino.

La vue Kubernetes Manager d'Ambari matérialise la configuration du cluster ODP et les paramètres de sécurité directement dans les valeurs du chart Helm au moment du déploiement. Vos charges de travail Kubernetes restent synchronisées avec le cluster dont elles dépendent.

Vue d'ensemble de l'architecture

┌─────────────────────────────────────────────────────────┐
│                  Serveur Ambari (2.8.2.0)                │
│                                                          │
│  ┌─────────────────┐    ┌──────────────────────────┐    │
│  │  Gestion cluster │    │  Vue Kubernetes Manager  │    │
│  │  (HDFS, YARN,   │    │  (Aperçu technique)       │    │
│  │   Hive, HBase,  │    │  - Déploiement chart Helm │    │
│  │   Ranger, …)    │    │  - Statut GitOps / Flux   │    │
│  └────────┬────────┘    └────────────┬─────────────┘    │
│           │                          │                    │
└───────────┼──────────────────────────┼────────────────── ┘
            │                          │
     ┌──────▼──────┐          ┌────────▼────────┐
     │  Cluster ODP │          │  Kubernetes /   │
     │  (HDFS, YARN,│◄────────►  OpenShift       │
     │   Hive Meta, │  infra   │                 │
     │   Kerberos,  │  partagée│  ┌───────────┐  │
     │   Ranger,    │          │  │  Trino    │  │
     │   LDAP)      │          │  ├───────────┤  │
     └──────────────┘          │  │  Superset │  │
                               └─────────────────┘

Ambari gère les deux côtés. La configuration de sécurité (realm Kerberos, keytabs, politiques Ranger, connexion LDAP/AD) est définie une seule fois et appliquée de façon cohérente à la fois aux services de cluster traditionnels et aux charges de travail déployées sur Kubernetes.

Ce qui est déployé sur Kubernetes

Dans ODP 1.3.2.0 (Aperçu technique), Ambari peut déployer et gérer les charges de travail Kubernetes suivantes :

Charge de travail	Version	Description
Trino	Actuelle	Moteur de requêtes SQL distribué avec connectivité Iceberg/Hive Metastore
Apache Superset	4.1.4	Plateforme de business intelligence et de visualisation de données

Les deux sont déployés via des charts Helm. Ambari gère le cycle de vie des charts (installation, mise à niveau, rollback, désinstallation) et intègre chaque charge de travail avec l'infrastructure de sécurité du cluster.

Prérequis

Avant d'utiliser la vue Kubernetes Manager, assurez-vous que les prérequis suivants sont satisfaits :

Cluster Kubernetes

• Kubernetes 1.20 ou ultérieur, ou OpenShift 4.8 ou ultérieur
• Helm 3.x installé et accessible depuis le serveur Ambari
• Un namespace dédié pour les charges de travail gérées par ODP (recommandé : odp-apps)
• Un compte de service avec des permissions suffisantes pour créer des déploiements, services, configmaps et secrets dans ce namespace
• Prise en charge des volumes persistants (pour la base de données de métadonnées de Superset)
• Contrôleur Ingress ou support LoadBalancer pour l'accès externe

Cluster ODP

• Ambari 2.8.2.0 ou ultérieur (la vue Kubernetes Manager est fournie en tant que plugin)
• Kerberos activé (l'intégration est conçue pour les clusters sécurisés)
• Ranger activé et configuré
• Hive Metastore en cours d'exécution (requis pour la connectivité Trino)
• Connectivité réseau entre les nœuds workers Kubernetes et les nœuds du cluster ODP (port Hive Metastore, HDFS NameNode, KDC)

Réseau

• Les nœuds Kubernetes doivent pouvoir atteindre le KDC Kerberos
• Les nœuds Kubernetes doivent pouvoir atteindre le Hive Metastore (port par défaut : 9083)
• Les nœuds Kubernetes doivent pouvoir atteindre le NameNode HDFS et les DataNodes si Trino lit les données directement depuis HDFS

Conseils pour l'aperçu technique

L'intégration Kubernetes est pleinement fonctionnelle et adaptée à l'évaluation et à un usage en pré-production. Plus précisément :

Ce qui est stable :

• Déploiement de charts Helm et gestion du cycle de vie depuis Ambari
• Provisionnement des keytabs Kerberos pour Trino
• Autorisation Ranger pour les requêtes Trino
• Connectivité Hive Metastore / catalogue Iceberg depuis Trino
• Connectivité Superset vers Trino et Hive

Ce qui peut évoluer :

• La disposition de l'interface et les formulaires de configuration de la vue Kubernetes Manager dans Ambari
• Le schéma des valeurs Helm pour les charts Trino et Superset
• La syntaxe de configuration de l'intégration GitOps/Flux

Limitations connues :

• Les quotas de ressources YARN ne sont pas appliqués aux charges de travail Kubernetes (Trino dispose de sa propre gestion des ressources)
• La traçabilité Atlas n'est pas capturée pour les requêtes routées via Trino dans cette version
• La haute disponibilité pour Superset n'est pas encore configurée via Ambari (remplacement manuel des valeurs Helm possible)

Pour les déploiements en production, évaluez l'intégration de manière approfondie dans un environnement de staging et abonnez-vous aux notes de version d'ODP pour les mises à jour de cette fonctionnalité.