Fédération Lakehouse externe (style Cloudera)¶

AKKO se connecte aux data lakes legacy que vous possédez déjà, sans déplacer le moindre octet. Fédération, pas migration. Sprint 82 A2.

Ce que ça fait¶

Le catalogue Trino cloudera lit des tables Hive qui vivent dans un cluster Hadoop appartenant au client (HDFS NameNode + DataNode + Hive Metastore + KDC Kerberos optionnel). Une fois fédérées, ces tables apparaissent à côté de vos autres sources AKKO — même SQL, même RBAC, même gouvernance.

Formulation layer-first côté utilisateur : Lakehouse externe. Le nom de l'éditeur Cloudera n'apparaît que sur la page Architecture (vue admin expert) et dans ce mémo de gouvernance. Le pattern fonctionne contre n'importe quel déploiement qui expose un endpoint Hive Metastore Thrift : Cloudera CDH/CDP, Cloudera Data Platform, Amazon EMR, Google Dataproc, Hortonworks HDP, ou une installation Apache Hive sur-mesure.

Architecture¶

┌─────────────────────────────────────────┐    ┌──────────────────────────────────────┐
│ Namespace AKKO                          │    │ Namespace akko-demo-cloudera          │
│                                          │    │  (appartenant au client, intouché)   │
│  Coordinator Trino                       │    │                                       │
│    /etc/trino/catalog/cloudera.properties│    │  Hive Metastore (Thrift :9083) ◄─┐   │
│    /etc/trino/cloudera-conf/             │    │  HDFS NameNode (RPC :9000)       │   │
│    /etc/security/cloudera-keytabs/       │────►  KDC (Kerberos :88)              │   │
│                                          │    │                                   │   │
│  NetworkPolicy : `part-of: akko` ───────►│    │  Whitelist : ns=akko + label     │   │
│                                          │    │              `part-of: akko`     │   │
└─────────────────────────────────────────┘    └──────────────────────────────────────┘

Deux modes d'authentification¶

Le corps du catalogue est rendu conditionnellement selon global.cloudera.authentication (valeur Helm).

`NONE` (par défaut — le cluster demo actuel l'utilise)¶

Trino ouvre une connexion TCP Thrift en clair vers le Hive Metastore. Le hive-site.xml du Metastore NE active PAS SASL/Kerberos sur l'écouteur Thrift ; positionner hive.metastore.authentication.type=NONE côté Trino est obligatoire, sinon le handshake échoue immédiatement.

connector.name=hive
hive.metastore=thrift
hive.metastore.uri=thrift://akko-demo-cloudera-hive-metastore.akko-demo-cloudera.svc.cluster.local:9083
hive.metastore.authentication.type=NONE
hive.hdfs.authentication.type=NONE

`KERBEROS`¶

Trino effectue un handshake SPNEGO / GSSAPI contre le Hive Metastore en utilisant un keytab provisionné par le cloudera-keytab-job (hook post-install d'akko-init). Le Job s'exec dans le pod KDC, appelle kadmin.local addprinc -randkey trino@AKKO.LOCAL, ktadd le keytab, le renvoie via base64, et crée le Secret akko-cloudera-trino-keytab dans le namespace akko. Le coordinator Trino monte le Secret sur /etc/security/cloudera-keytabs/ et le référence depuis le corps du catalogue :

connector.name=hive
hive.metastore=thrift
hive.metastore.uri=thrift://<fqdn-hive-metastore>:9083
hive.metastore.authentication.type=KERBEROS
hive.metastore.service.principal=hive/<fqdn-hive-metastore>@AKKO.LOCAL
hive.metastore.client.principal=trino@AKKO.LOCAL
hive.metastore.client.keytab=/etc/security/cloudera-keytabs/trino-cloudera.keytab
hive.hdfs.authentication.type=KERBEROS
hive.hdfs.trino.principal=trino@AKKO.LOCAL
hive.hdfs.trino.keytab=/etc/security/cloudera-keytabs/trino-cloudera.keytab
hive.config.resources=/etc/trino/cloudera-conf/core-site.xml,/etc/trino/cloudera-conf/hdfs-site.xml

L'activation nécessite de re-déployer le Hive Metastore upstream avec hive.metastore.sasl.enabled=true — actuellement TODO dans le chart akko-demo-cloudera (Sprint 61.2.4).

Activer le catalogue¶

Dans votre overlay de values :

global:
  cloudera:
    enabled: true
    # Pointer vers votre endpoint Cloudera / CDP / EMR réel
    metastoreUri: "thrift://<votre-hive-metastore>:9083"
    hdfsUri: "hdfs://<votre-namenode>:9000"
    # Passer à KERBEROS une fois le cluster source durci
    authentication: NONE
    kerberos:
      bootstrap: true     # auto-provisionner le keytab trino@<realm>
      realm: "<VOTRE.REALM>"
      kdcHost: "<fqdn-kdc>"
      kdcPort: 88
      hiveServicePrincipal: "hive/<fqdn-hive>@<VOTRE.REALM>"
      hdfsServicePrincipal: "hdfs/<fqdn-namenode>@<VOTRE.REALM>"
      clientPrincipal: "trino@<VOTRE.REALM>"

puis :

helm upgrade akko helm/akko/ -n akko \
  --reuse-values \
  -f helm/examples/values-netcup.yaml

Le coordinator Trino récupère le nouveau mount + catalogue lors du rolling restart. Le Job de bootstrap s'exécute après chaque upgrade et enregistre le catalogue de manière idempotente via CREATE CATALOG cloudera USING hive WITH (...).

NetworkPolicy¶

Les pods Trino doivent porter le label app.kubernetes.io/part-of: akko pour que la NetworkPolicy du namespace akko-demo-cloudera autorise l'ingress sur les ports 9083 (Hive Thrift), 9000 (HDFS NameNode RPC), 88 (Kerberos KDC). Ce label est positionné automatiquement par l'umbrella AKKO via l'override trino.coordinator.labels dans values-trino.yaml.

Sans ce label, nc -z <hive-metastore> 9083 retourne Connection refused (RST post-DNAT depuis kube-router qui applique la NP). Voir gotcha_kube_router_np_post_dnat.md pour l'analyse cause racine.

OPA — override compte de service¶

Le Job de bootstrap enregistre le catalogue via SQL CREATE CATALOG en utilisant le compte de service svc-catalog-manager. OPA refuse CreateCatalog par défaut sauf si l'appelant porte le groupe akko-admin ; le group provider file-based de Trino NE peuple PAS les groupes pour les requêtes header-only (sans JWT), donc un override d'une ligne dans le fichier de données user_overrides d'OPA est requis :

akko-opa:
  groupPolicies:
    user_overrides:
      svc-catalog-manager:
        data_scope: ["*"]

Cela promeut svc-catalog-manager au rang d'admin via la règle wildcard existante data.user_overrides[user].data_scope = ["*"] (deep-dive ADEN Sprint 68). Aucune modification du Rego OPA upstream nécessaire.

Smoke test¶

Après déploiement, depuis un pod avec accès Trino interne au cluster :

# En tant que svc-catalog-manager (utilisé par le Job de bootstrap)
curl -s -X POST \
  -H 'X-Trino-User: svc-catalog-manager' \
  -H 'Content-Type: text/plain' \
  --data 'SHOW SCHEMAS FROM cloudera' \
  http://akko-trino:8080/v1/statement

Une réponse réussie retourne au moins le schéma default.

Dépannage¶

`Connection refused` sur le port 9083¶

Les pods Trino n'ont pas le label app.kubernetes.io/part-of: akko → la NetworkPolicy cross-namespace refuse l'ingress. Vérifier avec :

kubectl -n akko get pod -l app.kubernetes.io/name=trino \
  -o jsonpath='{.items[0].metadata.labels}' | tr ',' '\n' | grep part-of

Si manquant, s'assurer que coordinator.labels.app.kubernetes.io/part-of: akko est positionné dans values-trino.yaml et re-upgrade.

`Access Denied: Cannot create catalog cloudera`¶

L'override OPA user_overrides.svc-catalog-manager n'est pas positionné. Ajouter l'override dans votre overlay de values et re-upgrade. L'override survit aux restarts de Trino car OPA recharge ses données à chaque helm upgrade.

`Cannot obtain metadata` à la première requête¶

Le hive-site.xml du Hive Metastore impose SASL mais le catalogue tourne en mode NONE (ou l'inverse). Vérifier par kubectl exec -n akko-demo-cloudera deploy/akko-demo-cloudera-hive-metastore -- grep sasl /opt/hive/conf/hive-site.xml — si sasl.enabled=true, votre catalogue DOIT tourner en mode KERBEROS.

Handshake Kerberos échoue avec `Server not found in Kerberos database`¶

Le principal de service dans le corps du catalogue utilise la substitution _HOST mais Trino ne la développe pas (il attend le FQDN complet). Utiliser la forme explicite hive/<fqdn-service-complet>@<REALM> partout.

`Server certificate validation failed`¶

Le KDC émet des tickets pour kdc-fqdn:88 mais le pod Trino résout kdc-fqdn vers une IP différente de celle inscrite dans krb5.conf. Vérifier /etc/trino/cloudera-conf/krb5.conf (rendu depuis le ConfigMap akko-trino-cloudera-conf) et s'assurer que le bloc [realms] référence le même FQDN qui résout en interne du cluster.

Voir aussi¶

Chart akko-demo-cloudera — le périmètre Hadoop simulé (HDFS + Hive Metastore + KDC) utilisé pour la démo
Fédération Climscore — autre pattern de source client externe (connexion Postgres directe, sans couche Hive)
Matrice RBAC — comment les 5 rôles AKKO voient le catalogue cloudera