Pour installer le graphique avec le nom de la version ilum-core:
$ helm install ilum-core ilum/ilum-core
La commande se déploie ilum-core sur le cluster Kubernetes dans la configuration par défaut. Le Paramètres
liste les paramètres qui peuvent être configurés lors de l’installation.
The two flags above govern how the bundled faire défaut Spark cluster is reconciled from chart values. The faire défaut cluster is bootstrap-once. When kubernetes.initClusterOnStartup est vrai (the default), the cluster is created on first startup if it does not already exist. When a cluster named faire défaut is already present, its stored specification is re-synced from chart values only if kubernetes.upgradeClusterOnStartup est vrai. That flag defaults to faux, so a routine Mise à niveau Helm followed by a pod rollout does not push changed kubernetes.* values onto an existing default cluster. This preserves edits made through the UI or the dev API, at the cost of chart values no longer being authoritative once the cluster exists.
When kubernetes.upgradeClusterOnStartup is enabled, the reconciliation is partial:
scalaVersion, TLS certificates, credentials, cluster id et description
The fields in the right-hand column are always preserved from the stored cluster, even with the flag enabled. They can only be changed by editing the cluster through the UI or the dev API.
Metastore is reconciled independently
The bundled faire défaut metastore row (metastore.type and the corresponding metastore..config) is reconciled unconditionally on every startup, independent of kubernetes.upgradeClusterOnStartup. A ruche À nessie switch therefore takes effect on a plain pod rollout.
To apply changed default-cluster values, either enable reconciliation:
and run Mise à niveau Helm followed by kubectl rollout restart deploy/ilum-core, or delete the existing cluster and re-bootstrap it from current chart values.
After the faire défaut cluster is deleted from the Clusters list under Charges, it can be rebuilt from chart values without restarting ilum-core: while no clusters remain, the Clusters list shows a Restore Default Cluster button that re-creates it from chart values. The button is offered only when no faire défaut cluster exists; it never overwrites a cluster that is still present.
Restarting ilum-core after the delete has the equivalent effect, since the startup initializer recreates the missing cluster:
kubectl -n ilum rollout restart deploy/ilum-core
Enabling kubernetes.upgradeClusterOnStartup re-applies chart values on every boot, which overwrites subsequent UI or dev-API edits to the default cluster, and still does not migrate scalaVersion, certificates, or credentials.
ilum-core cluster kubernetes par défaut HDFS stockage hadoop nom d’utilisateur
""
kubernetes.hdfs.config
ilum-core Cluster Kubernetes par défaut Stockage HDFS Dictionnaire des fichiers de configuration avec le nom comme clé et le contenu encodé en base64 comme valeur
""
kubernetes.hdfs.sparkCatalog
Catalogue de stockage HDFS du cluster Kubernetes par défaut ilum-core pour stocker les ressources Spark
« ilum-files »
kubernetes.hdfs.dataCatalog
ilum-core cluster kubernetes par défaut Catalogue de stockage HDFS pour stocker les tables ilum
« Tables-ilum »
kubernetes.hdfs.keyTab
ilum-core cluster kubernetes par défaut HDFS stockage keytab fichier contenu encodé en base64
""
kubernetes.hdfs.principal
ilum-core cluster kubernetes par défaut Nom principal de stockage HDFS
""
kubernetes.hdfs.krb5
ilum-core cluster kubernetes par défaut stockage HDFS fichier krb5 contenu encodé en base64
""
kubernetes.hdfs.trustStore
ilum-core cluster kubernetes par défaut confiance pour le stockage du contenu encodé en base64
""
kubernetes.hdfs.logRépertoire
ilum-core cluster kubernetes par défaut HDFS répertoire de stockage chemin d’accès à l’événement de stockageLog pour le serveur d’historique
""
Important! Assurez-vous que les compartiments S3/GCS ou les conteneurs WASBS sont déjà créés et accessibles !
Important! Assurez-vous que HDFS logDirectory est le chemin absolu de sparkCatalog configuré avec le suffixe /ilum/logs ! Par exemple hdfs://name-node/user/username/spark-catalog/ilum/logs
Configuration des règles de mappage des autorités ilum-core. Utilisé lorsque l’autorisation est LDAP ou oauth2. Permet de traduire des groupes et des étendues de fournisseurs d’authentification externes en rôles ilum
autorités: Rôles: préfixe : ROLE_ claim-name : groupes Étendues: préfixe : SCOPE__ Nom de la revendication : SCP
security.authorities.roles.prefix
Préfixe de rôle d’authentification ilum-core
RÔLE_
security.authorities.roles.claimName
Identifiant du fournisseur d’authentification externe ilum-core de la revendication jwt qui contient la liste des rôles/groupes
groupe
security.authorities.roles.mappings
Définitions de la cartographie des rôles d’ILUM-Core sous la forme d’une carte external_role : ilum_role
{}
security.authorities.scopes.prefix
Préfixe de portée d’authentification ilum-core
PORTÉE_
security.authorities.scopes.claimName
Fournisseur d’authentification externe ilum-core ID de la revendication jwt qui contient la liste des étendues
Scp
security.authorities.scopes.mappings
Définitions de la cartographie du champ d’application d’ilum-core sous la forme d’une carte external_scope : ilum_scope
{}
Paramètres d’authentification internes basés sur config-map
Nom
Description
Valeur
sécurité.interne.utilisateurs
Configuration des utilisateurs internes d’ilum-core
Utilisateurs: - Nom d’utilisateur : « admin » Mot de passe : « admin » Rôles: - « ADMIN »
suffixe de base LDAP ilum-core à partir duquel toutes les opérations doivent provenir
""
security.ldap.nom_utilisateur
ilum-core LDAP login nom d’utilisateur du serveur
""
security.ldap.password
Mot de passe de connexion LDAP ilum-core du serveur
""
security.ldap.passwordEncodeur
Encodeur de mot de passe LDAP ilum-core. Le serveur LDAP authentifie les utilisateurs (opérations de liaison) s’il est vide, les options disponibles : adaptatif - encodeur de mot de passe qui délègue à un autre encodeur sur la base d’un identificateur préfixé bcrypt MD5 sha256
""
security.ldap.userSearch.base
DN de base LDAP ilum-core à partir duquel la recherche d’un utilisateur doit être effectuée
""
security.ldap.userSearch.filter
Modèle LDAP ilum-core à utiliser pour la recherche de l’utilisateur. 0 est le nom d’utilisateur
uid={0}
security.ldap.userSearch.passwordAttr
ilum-core LDAP ID de l’attribut qui contient le mot de passe d’un utilisateur
userPassword
security.ldap.groupSearch.base
DN de base LDAP ilum-core à partir duquel la recherche d’appartenance au groupe doit être effectuée
""
security.ldap.groupSearch.filter
Modèle LDAP ilum-core à utiliser pour la recherche de groupe. 0 est le DN de l’utilisateur
(membre = {0})
security.ldap.groupSearch.roleAttr
ilum-core LDAP ID de l’attribut qui contient le nom de rôle d’un groupe
URI oauth2 ilum-core qui peut être un point de terminaison de découverte OpenID Connect ou un point de terminaison de métadonnées du serveur d’autorisation OAuth 2.0 défini par la RFC 8414.
Le contenu de la clé privée doit ressembler à ce qui suit :
-----DÉBUT DE LA CLÉ PRIVÉE----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCsRnE83rm6BJya nTyzVqX0SG+D4zBjkyWsOmGG+CoDdgQ6Z8AaocmnjP1SbRykQsQSMf6SeW+fdpH+ ccmzuHe7pZIa2o2Mg8xbk/UszJDaPztwoQbUt/2gHi/rZP8cIVkquzhnN/yxrMls ... -----FIN DE LA CLÉ PRIVÉE-----
Afin d’utiliser la clé privée comme paramètre security.jwt.privateKey, supprimez l’en-tête et le pied de page de la clé.
Le contenu de la clé publique doit ressembler à ce qui suit :
-----DÉBUT DE LA CLÉ PUBLIQUE----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArEZxPN65ugScmp08s1al 9Ehvg+MwY5MlrDphhvgqA3YEOmfAGqHJp4z9Um0cpELEEjH+knlvn3aR/nHJs7h3 u6WSGtqNjIPMW5P1LMyQ2j87cKEG1Lf9oB4v62T/HCFZKrs4Zzf8sazJbMN3E/mJ ... -----FIN DE LA CLÉ PUBLIQUE-----
Afin d’utiliser la clé publique comme paramètre security.jwt.publicKey, supprimez l’en-tête et le pied de page de la clé.