Partager via

Créer et gérer un runtime d’intégration auto-hébergé pris en charge par Kubernetes

  • Article

Cet article couvre les détails de la nouvelle fonctionnalité SHIR basée sur Kubernetes pour Linux, qui améliore l’infrastructure sous-jacente pour offrir plusieurs avantages :

  • Scalabilité : possibilité de mettre à l’échelle des centaines de machines.
  • Performances : amélioration des performances dans les charges de travail d’analyse.
  • Sécurité (conteneurisé) : possibilité d’avoir une sécurité conteneurisée sur un cluster Kubernetes, au lieu d’héberger SHIR directement sur un ordinateur Windows

Cet article décrit les détails de l’installation et de la gestion d’un runtime d’intégration auto-hébergé pris en charge par Kubernetes.

Sources de données prises en charge

Pour obtenir la liste de toutes les sources prises en charge, consultez les sources de données prises en charge pour chaque table de runtime d’intégration.

Architecture

Dans une vue architecturale de haut niveau, lorsqu’un SHIR basé sur Kubernetes est installé, plusieurs pods sont automatiquement créés sur les nœuds du cluster Kubernetes des utilisateurs. Cette installation peut être déclenchée par un outil en ligne de commande nommé IRCTL (plus de détails dans les sections suivantes). IRCTL se connecte au service Microsoft Purview pour inscrire le SHIR et se connecter au cluster Kubernetes pour installer le SHIR. 

Pendant l’installation, les images SHIR sont téléchargées à partir de MCR (Microsoft Container Registrys) vers les pods SHIR. Une fois l’installation terminée, les pods du cluster des utilisateurs se connectent au service Microsoft Purview pour extraire des tâches d’analyse. À mesure qu’un travail d’analyse est extrait, il peut connecter la source de données locale des utilisateurs pour l’analyse des données.

Infographie de l’architecture réseau pour le runtime d’intégration auto-hébergé pris en charge par Kubernetes.

Configuration requise

  • Un compte Microsoft Purview utilisant des solutions de gouvernance des données d’entreprise .

  • Cluster Kubernetes : vous devez disposer d’un cluster Kubernetes linux existant ou en préparer un. Les nœuds peuvent être identifiés par le sélecteur de nœud, qui suit la définition du sélecteur de nœud Kubernetes. Configuration minimale :

    • Type de conteneur : Linux
    • Version de Kubernetes : 1.24.9 ou ultérieure
    • Système d’exploitation de nœud : système d’exploitation Linux s’exécutant sur l’architecture x86
    • Spécification du nœud : processeur minimal de huit cœurs, 32 Go de mémoire et au moins 80 Go d’espace disque disponible
    • Nombre de nœuds : >=1 (doit être résolu, pas activer le scaler automatique de cluster)
    • Nombre de pods par nœud : >= 20 (nombre maximal de pods – nombre d’autres pods n’appartenant pas à Self-Hosted IR)

    Remarque

    Le dossier /var/irstorage/ de chaque nœud est réservé à SHIR. Il est lisible et accessible en écriture pour SHIR. Vous pouvez obtenir les journaux conservés à partir de ce dossier ou charger des pilotes externes dans ce dossier. Il sera créé par SHIR s’il n’existe pas et ne sera pas supprimé après la suppression de SHIR. Les images conteneur utilisées par SHIR sont gérées par le garbage collection Kubernetes, qui ne sera pas nettoyé par SHIR. Configurez le seuil approprié pour votre cluster Kubernetes.

  • Réseau de cluster Kubernetes : le cluster Kubernetes dont vous disposez doit être en mesure de se connecter au point de terminaison répertorié dans Configuration réseau requise.

  • Outil en ligne de commande du runtime d’intégration : pour gérer votre SHIR Kubernetes Microsoft Purview localement, vous avez besoin d’un outil en ligne de commande nommé IRCTL. Vous pouvez télécharger cet outil pendant le processus de création de SHIR. IRCTL est un outil en ligne de commande qui permet de gérer votre SHIR Microsoft Purview. Pour plus d’informations, consultez la documentation IRCTL.

  • Contexte Kubernetes : le contexte Kubernetes, qui contient des informations sur le cluster Kubernetes et les autorisations et informations d’identification de l’utilisateur pour ce cluster, est nécessaire pour communiquer avec votre cluster Kubernetes. Pour faciliter la configuration des autorisations de l’utilisateur pour la gestion SHIR, vous pouvez commencer par Kubernetes Administration rôle. Ce contexte est généré avec la configuration de votre cluster Kubernetes et enregistré dans un fichier de configuration. L’emplacement et la façon dont vous pouvez obtenir ce fichier dépendent de votre configuration du cluster Kubernetes.
    • Si vous utilisez kubeadm init pour configurer le cluster Kubernetes, vous trouverez le fichier de configuration sous /etc/Kubernetes/admin.conf.
    • Si vous utilisez AKS, vous pouvez suivre les instructions d’AKS pour utiliser la commande du module Az PowerShell pour obtenir les informations d’identification de ce cluster sur votre ordinateur local. Le contexte peut être fusionné dans le fichier de configuration sous $HOME/.kube/config directement.
    • Si vous utilisez d’autres outils pour configurer un cluster Kubernetes, reportez-vous à la documentation Kubernetes.
    • Comme vous avez le fichier de configuration du contexte Kubernetes, fusionnez-le avec le fichier config, qui est $HOME/.kube/config, sur l’ordinateur que vous souhaitez exécuter la commande IRCTL. Vous pouvez également définir le fichier de configuration du contexte Kubernetes dans une variable d’environnement nommée KUBECONFIG. Pour plus d’informations sur le contexte Kubernetes, consultez Configurer l’accès à plusieurs clusters.

Créer un runtime d’intégration auto-hébergé kubernetes pris en charge

Pour contrôler et gérer un SHIR Kubernetes, les utilisateurs peuvent télécharger un outil en ligne de commande nommé IRCTL. Voici les étapes de votre runtime d’intégration auto-hébergé pris en charge par Kubernetes.

Les étapes vous aideront à télécharger IRCTL, mais pour obtenir des liens directs, consultez la documentation IRCTL.

Configurer un runtime d’intégration auto-hébergé pris en charge par Kubernetes

  1. Ouvrez la fenêtre Runtimes d’intégration dans le Mappage de données Microsoft Purview

  2. Sélectionnez le bouton + Nouveau

    Capture d’écran de la fenêtre runtimes d’intégration dans le Mappage de données Microsoft Purview.

  3. Sélectionnez Auto-hébergé , puis Continuer

    Capture d’écran de la nouvelle fenêtre du runtime d’intégration, avec auto-hébergé sélectionné.

  4. Donnez un nom à votre runtime, puis sélectionnez le bouton bascule Prise en charge du service Kubernetes pour activer

    Capture d’écran de la nouvelle fenêtre du runtime d’intégration avec le bouton bascule Kubernetes activé.

  5. Sélectionnez Créer.

  6. Sélectionnez Obtenir la clé d’inscription.

    Capture d’écran de la page d’affichage du runtime d’intégration avec le bouton Obtenir la clé d’inscription mis en évidence.

  7. Copiez la valeur de la clé. Vous en aurez besoin pour exécuter des commandes dans IRCTL ultérieurement.

    Conseil

    Si nécessaire, vous pouvez régénérer une clé ou révoquer une clé générée.

  8. Sélectionnez le lien Télécharger IRCTL et installer le runtime d’intégration pour télécharger l’outil IRCTL. (Vous pouvez également suivre ces étapes pour télécharger IRCTL directement.)

  9. Sur l’ordinateur sur lequel vous souhaitez exécuter la ligne de commande IRCTL, installez IRCTL à partir du téléchargement. IRCTL se connecte à votre cluster Kubernetes par contexte de la configuration Kube. Si context n’est pas spécifié, IRCTL utilise le contexte actuel. Vous pouvez définir le contexte de l’une des deux manières suivantes :

    • Exécutez la ligne de commande kubectl et exécutez cette commande pour confirmer le contexte actuel :

      kubectl config get-contexts – List all contexts configured on the machine

      kubectl config current-context – Get the current context name

      kubectl config use-context <name of context>

    • Exécutez IRCTL et exécutez --context pour spécifier le contexte dans la configuration Kube

  10. Exécutez la ligne de commande IRCTL et exécutez cette commande avec la clé d’inscription que vous avez copiée.

    ./irctl create --registration-key <registration key copied from the portal>

    Remarque

    Si le sélecteur de nœud n’est pas spécifié, utilise tous les nœuds du cluster Kubernetes. Pour AKS, suggérez d’utiliser l’étiquette du pool de nœuds AKS comme sélecteur de nœud ou vous pouvez personnaliser différentes étiquettes pour les nœuds SHIR.

  11. Vous verrez cette impression :

    [Info] Start to create SHIR with Kubernetes context [your-context]......
[Info] Environment validation passed!
[Info] Registering SHIR[example-k8s-shir] for Microsoft Purview Account [yourpurviewaccount]......
[Info] SHIR Registration done!
[Info] Provisioning SHIR, it may take about 5-30 minutes......done!
[Info] SHIR creation succeeded!

    Conseil

    Si la progression de l’installation est interrompue par Ctrl+C ou d’autres raisons, la commande suivante peut être utilisée pour surveiller la progression de l’installation : ./irctl install status

  12. Une fois l’installation terminée, pour case activée la status actuelle du SHIR, exécutez la commande suivante :

    ./irctl describe

  13. Vous pouvez également case activée la status de votre SHIR dans le portail Microsoft Purview, dans la page Runtimes d’intégration.

Configurer une analyse avec des pilotes externes

Lors de l’analyse de certaines sources de données, vous devez installer le pilote correspondant sur l’ordinateur sur lequel le SHIR est installé pour que Microsoft Purview se connecte à la source de données. Voici un exemple d’analyse Db2. Reportez-vous à l’article sur les connecteurs respectifs pour connaître les prérequis spécifiques.

Remarque

Les sources de données qui ont besoin de ces pilotes externes auront les informations répertoriées dans leurs conditions préalables.

Dans cet exemple, nous allons installer le pilote Db2. Les étapes pour les autres pilotes seront similaires.

  1. Tout d’abord, installez le runtime d’intégration.

  2. Téléchargez le pilote (chaque source aura son pilote individuel répertorié.) Par exemple, vous trouverez le pilote DB2 ici : Se connecter à Db2 et le gérer.

  3. Chargez le pilote sur chaque nœud de votre runtime d’intégration. Vous pouvez utiliser une commande comme suit :

    ./irctl storage upload --source jdbc_sqlj/db2_driver --destination driver/db2

    Une confirmation de chargement réussie se présente comme suit :

    ========== Context ========== 
Kubernetes Context             : k8s-shir-test-cluster 
Purview Account                : test-purview-1 
Self-hosted Intrgration Runtime: k8s-shir-demo 
========== Progress ========== 
Processing 2/2 nodes... 
aks-shirpool-27141791-vmss000000: SUCCEEDED 
aks-shirpool-27141791-vmss000001: SUCCEEDED 
========== Results ========== 
jdbc_sqlj/db2_driver -> /var/irstorage/driver/db2

    Remarque

    Si vous remplacez des nœuds ou effectuez un scale-out vers de nouveaux nœuds, vous devez charger à nouveau le pilote externe.

  4. Vérifiez les fichiers chargés avec cette commande :

    ./irctl storage list driver/db2

    Une réponse semblable à celle-ci doit s’afficher :

    ========== Context ========== 
Kubernetes Context             : k8s-shir-test-cluster 
Purview Account                : test-purview-1 
Self-hosted Intrgration Runtime: k8s-shir-demo 
========== Progress ========== 
Processing 2/2 nodes... 
aks-shirpool-27141791-vmss000000: SUCCEEDED 
aks-shirpool-27141791-vmss000001: SUCCEEDED 
========== Results ========== 
Node: aks-shirpool-27141791-vmss000000 - Succeeded 
/var/irstorage/driver/db2 
total 9364 
drwxr-xr-x    2 root     root          4096 May 15 14:23 . 
drwxr-xr-x    3 root     root          4096 May 15 14:23 .. 
-rwxrwxr-x    1 root     root       6568346 May 15 14:23 db2jcc4.jar 
Node: aks-shirpool-27141791-vmss000001 - Succeeded 
/var/irstorage/driver/db2 
total 9364 
drwxr-xr-x    2 root     root          4096 May 15 14:23 . 
drwxr-xr-x    3 root     root          4096 May 15 14:23 .. 
-rwxrwxr-x    1 root     root       6568346 May 15 14:23 db2jcc4.jar

  5. Créez une analyse avec la valeur de DriverLocation avec la valeur Destination de l’étape 3.

    Capture d’écran de la fenêtre de configuration de l’analyse, montrant l’emplacement du pilote répertorié comme driver/db2.

Haute disponibilité et scalabilité

Vous pouvez affecter plusieurs nœuds du cluster Kubernetes à une haute disponibilité à l’aide du sélecteur de nœuds pendant l’installation du runtime d’intégration auto-hébergé pris en charge par Kubernetes. Les avantages d’avoir plusieurs nœuds sont les suivants :

  • Plus grande disponibilité du runtime d’intégration auto-hébergé afin qu’il ne soit plus le point de défaillance unique pour les analyses.
  • Exécutez d’autres analyses simultanées. Chaque nœud peut permettre de nombreuses exécutions d’analyse en même temps. Vous pouvez effectuer un scale-out manuel des nœuds du cluster Kubernetes si vous avez besoin d’analyses simultanées supplémentaires.
  • Lors de l’analyse de certaines sources telles que Blob Azure, Azure Data Lake Storage Gen2 et Azure Files, chaque exécution d’analyse peut utiliser plusieurs nœuds pour améliorer les performances de l’analyse. Pour les autres sources, les analyses sont exécutées sur un seul des nœuds.

La fonctionnalité du runtime d’intégration auto-hébergé pris en charge par Kubernetes peut être mise à jour en effectuant un scale-out/in manuel des nœuds du cluster Kubernetes.

Remarque

Vous devez charger tous les pilotes nécessaires pour l’analyse sur chaque nouveau nœud.

Configuration de réseau requise

Nom du domaine Ports sortants Description
Cloud public : <tenantID>-api.purview-service.microsoft.com
Azure Government :<tenantID>-api.purview-service.microsoft.us
Chine: <tenantID>-api.purview-service.microsoft.cn		 443 Requis pour se connecter au service Microsoft Purview. Si vous utilisez des points de terminaison privés Microsoft Purview, ce point de terminaison est couvert par un point de terminaison privé de compte.
Cloud public : <purview_account>.purview.azure.com
Azure Government :<purview_account>.purview.azure.us
Chine: <purview_account>.purview.azure.cn		 443 Requis pour se connecter au service Microsoft Purview. Si vous utilisez des points de terminaison privés Microsoft Purview, ce point de terminaison est couvert par un point de terminaison privé de compte.
Cloud public : <managed_storage_account>.blob.core.windows.net ou <ingestion_storage_account>.*.blob.storage.azure.net
Azure Government : <managed_storage_account>. blob.core.usgovcloudapi.net ou<ingestion_storage_account>. blob.core.usgovcloudapi.net
Chine : <managed_storage_account>.blob.core.chinacloudapi.cnou <ingestion_storage_account>.blob.core.chinacloudapi.cn		 443 Requis pour se connecter au compte de stockage d’objets blob Azure géré par Microsoft Purview.
Cloud public : <managed_storage_account>.queue.core.windows.net ou <ingestion_storage_account>.*.queue.storage.azure.net
Azure Government : <managed_storage_account>. queue.core.usgovcloudapi.net ou<ingestion_storage_account>. queue.core.usgovcloudapi.net
Chine : <managed_storage_account>.queue.core.chinacloudapi.cnou <ingestion_storage_account>.queue.core.chinacloudapi.cn		 443 Requis pour se connecter au compte de stockage File d’attente Azure géré par Microsoft Purview.
Cloud public : *.compute.governance.azure.com
Azure Government :*.compute.governance.azure.us
Chine: *.compute.governance.azure.cn		 443 Requis pour se connecter au service Microsoft Purview. Actuellement, un caractère générique est requis, car il n’existe aucune ressource dédiée.
mcr.microsoft.com 443 Requis pour télécharger des images.
*.data.mcr.microsoft.com 443 Requis pour télécharger des images.

Remarque

Selon les sources que les utilisateurs souhaitent analyser, ils doivent également autoriser d’autres domaines et ports sortants pour d’autres sources Azure ou externes.

Version

En règle générale, nous publions chaque mois une nouvelle version mineure du runtime d’intégration auto-hébergé, qui inclut des fonctionnalités, des améliorations et des correctifs de bogues.

Chaque version du runtime d’intégration auto-hébergé expire dans un an.

Guide pratique pour case activée la version actuelle

Vous pouvez case activée la version de votre runtime d’intégration auto-hébergé Kubernetes sur le portail ou avec l’IRCTL.

Portail

  1. Dans le portail Microsoft Purview, accédez à Data Map.
  2. Sélectionnez Runtimes d’intégration
  3. La quatrième colonne de la ligne de description de votre runtime d’intégration sera Version, et vous pouvez case activée la version.

IRCTL (1.1.0 et versions ultérieures)

La commande describe retourne la version du runtime d’intégration.

./irctl describe

Mise à jour automatique

À partir de la version 1.1.0, le runtime d’intégration auto-hébergé Kubernetes prend en charge la mise à jour automatique, qui est activée par défaut. Cette fonctionnalité garantit que votre runtime d’intégration est automatiquement mis à niveau vers la dernière version gérée par Microsoft environ une fois par mois.

Exclure

Nous vous recommandons d’activer la mise à jour automatique pour bénéficier des dernières fonctionnalités et améliorations. Toutefois, vous avez la possibilité de refuser la mise à jour automatique à l’aide d’IRCTL. La configuration de la mise à jour automatique persiste lors de la réinstallation, vous n’avez donc pas besoin de la désactiver à chaque installation.

./irctl config set autoUpdate.enabled false
./irctl config view

Mise à jour automatique de la version et de la dernière version

Pour garantir la stabilité, la mise à jour automatique se trouve généralement derrière la dernière version avec un délai d’un mois. La version de mise à jour automatique est gérée par Microsoft.

Si vous souhaitez mettre à niveau votre runtime d’intégration vers des versions plus récentes, une mise à niveau manuelle doit être effectuée avec IRCTL de la version spécifique.

Étapes suivantes