Criar e gerenciar um runtime de integração auto-hospedada com suporte do Kubernetes

Este artigo aborda os detalhes do novo recurso SHIR baseado em Kubernetes para Linux que melhora a infraestrutura subjacente para fornecer vários benefícios:

  • Escalabilidade: capacidade de escalar para centenas de máquinas.
  • Desempenho: Melhoria do desempenho na digitalização de cargas de trabalho.
  • Segurança (conteinerizada): capacidade de ter segurança conteinerizada em um cluster Kubernetes, em vez de hospedar o SHIR diretamente em uma máquina Windows

Este artigo aborda os detalhes para instalar e gerenciar um runtime de integração auto-hospedada com suporte do Kubernetes.

Fontes de dados com suporte

Para obter uma lista de todas as fontes com suporte, consulte as fontes de dados com suporte para cada tabela de runtime de integração.

Arquitetura

Em uma visão arquitetônica de alto nível, quando um SHIR baseado em Kubernetes é instalado, vários pods são criados automaticamente nos nós do cluster Kubernetes dos usuários. Essa instalação pode ser acionada por uma ferramenta de linha de comando chamada IRCTL (mais detalhes nas seções a seguir). O IRCTL se conecta ao Serviço Microsoft Purview para registrar o SHIR e se conecta ao cluster do Kubernetes para instalar o SHIR. 

Durante a instalação, as imagens SHIR são baixadas do MCR (Microsoft Container Registries) para os pods SHIR. Após a conclusão da instalação, os pods no cluster dos usuários se conectarão ao Serviço Microsoft Purview para extrair trabalhos de verificação. Quando um trabalho de verificação é efetuado, ele pode conectar a Fonte de Dados local dos usuários para Verificação de Dados.

Infográfico da arquitetura de rede do tempo de execução de integração auto-hospedada com suporte do Kubernetes.

Pré-requisitos

  • Uma conta do Microsoft Purview usando soluções de governança de dados empresariais .

  • Cluster do Kubernetes: você precisa ter um cluster do Kubernetes baseado em Linux existente ou preparar um. Os nós podem ser identificados pelo seletor de nó, que segue a definição do seletor de nó do Kubernetes. Configuração mínima:

    • Tipo de contêiner: Linux
    • Versão do Kubernetes: 1.24.9 ou superior
    • Sistema operacional Node: sistema operacional baseado em Linux em execução na arquitetura x86
    • Especificação do nó: CPU mínima de oito núcleos, memória de 32 GB e pelo menos 80 GB de espaço disponível no disco rígido
    • Contagem de nós: >=1 (deve ser corrigido, não habilitar o dimensionador automático do cluster)
    • Número de pods por nó: >= 20 (número máximo de pods – contagem de outros pods não pertencentes a Self-Hosted IR)

    Observação

    A pasta /var/irstorage/ de cada nó é reservada para SHIR. É legível e gravável para SHIR. Você pode obter logs persistentes dessa pasta ou carregar drivers externos nessa pasta. Ele será criado pelo SHIR se não existir e não será excluído após o SHIR ser excluído. As imagens de contêiner usadas pelo SHIR são gerenciadas pela Coleta de Lixo do Kubernetes, que não será limpa pelo SHIR. Configure o limite adequado para o cluster do Kubernetes.

  • Rede do cluster Kubernetes: O cluster Kubernetes que você tem deve ser capaz de se conectar ao ponto de extremidade listado nos requisitos de rede.

  • Ferramenta de linha de comando de runtime de integração: Para gerenciar seu Microsoft Purview Kubernetes SHIR localmente, você precisa de uma ferramenta de linha de comando chamada IRCTL. Você pode baixar esta ferramenta durante o processo de criação do SHIR. O IRCTL é uma ferramenta de linha de comando para gerenciar seu SHIR do Microsoft Purview. Para obter mais informações, consulte a documentação do IRCTL.

  • Contexto do Kubernetes: O contexto do Kubernetes, que contém informações do cluster Kubernetes e permissões e credenciais do usuário para este cluster, é necessário para se comunicar com o cluster do Kubernetes. Para facilitar a configuração das permissões do usuário para gerenciamento SHIR, você pode começar com a função de Administração do Kubernetes. Esse contexto é gerado com a configuração do cluster Kubernetes e salvo em um arquivo de configuração. Onde e como você pode obter esse arquivo depende da configuração do cluster Kubernetes.
    • Se você usa kubeadm init para configurar o cluster do Kubernetes, pode encontrar o arquivo de configuração em /etc/Kubernetes/admin.conf.
    • Se você usar o AKS, poderá seguir as diretrizes do AKS para usar o comando do módulo Az PowerShell para obter credenciais desse cluster para seu computador local. O contexto pode ser mesclado ao arquivo $HOME/.kube/config de configuração diretamente.
    • Se você estiver usando outras ferramentas para configurar um cluster do Kubernetes, consulte a documentação do Kubernetes.
    • Como você tem o arquivo de configuração do contexto do Kubernetes, mescle-o ao arquivo de configuração, que é $HOME/.kube/config, na máquina em que você gostaria de executar o comando IRCTL. Ou você também pode definir o arquivo de configuração do contexto do Kubernetes em uma variável de ambiente chamada KUBECONFIG. Para obter mais informações sobre o contexto do Kubernetes, consulte Configurar o acesso a vários clusters.

Criar o runtime de integração auto-hospedada com suporte do Kubernetes

Para controlar e gerenciar um SHIR do Kubernetes, os usuários podem fazer download de uma ferramenta de linha de comando chamada IRCTL. Veja a seguir as etapas para o runtime de integração auto-hospedada com suporte do Kubernetes.

As etapas levam você a baixar o IRCTL, mas para links diretos, consulte a documentação do IRCTL.

Configurar um runtime de integração auto-hospedada com suporte do Kubernetes

  1. Abra a janela Runtimes de integração no Mapa de Dados do Microsoft Purview

  2. Selecione o botão + Novo

    Captura de tela da janela de tempos de execução de integração no Mapa de Dados do Microsoft Purview.

  3. Selecione Auto-hospedado e, em seguida, selecione Continuar

    Captura de tela da nova janela de runtime de integração, com a opção auto-hospedada selecionada.

  4. Dê um nome ao seu tempo de execução e selecione o botão de alternância de suporte do serviço de Kubernetes para habilitar

    Captura de tela da nova janela de tempo de execução de integração com a alternância do Kubernetes habilitada.

  5. Selecione Criar

  6. Selecione Obter chave de registro

    Captura de tela da página exibir runtime de integração com o botão Obter chave de registro realçado.

  7. Copie o valor da chave. Você precisará dele para executar comandos no IRCTL mais tarde.

    Dica

    Se necessário, você pode regenerar uma chave ou revogar uma chave gerada.

  8. Selecione o link Baixar IRCTL e instalar o runtime de integração para baixar a ferramenta IRCTL. (Você também pode seguir estas etapas para baixar o IRCTL diretamente.)

  9. No computador em que você deseja executar a linha de comando IRCTL, instale o IRCTL a partir do download. O IRCTL se conecta ao cluster do Kubernetes pelo contexto da configuração do Kube. Se o contexto não for especificado, o IRCTL usará o contexto atual. Você pode definir o contexto de duas maneiras:

    • Execute a linha de comando kubectl e execute este comando para confirmar o contexto atual:

      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>

    • Execute o IRCTL e execute --context para especificar o contexto na configuração do Kube

  10. Execute a linha de comando IRCTL e execute esse comando com a chave de registro que você copiou.

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

    Observação

    Se o seletor de nós não for especificado, usará todos os nós do cluster do Kubernetes. Para o AKS, sugerimos usar o rótulo do pool de nós do AKS como seletor de nó ou você pode personalizar rótulos diferentes para os nós SHIR.

  11. Você vê esta impressão:

    [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!

    Dica

    Se o progresso da instalação for interrompido por Ctrl-C ou outros motivos, o seguinte comando poderá ser usado para monitorar o progresso da instalação: ./irctl install status

  12. Quando a instalação estiver concluída, para marcar o status atual do SHIR, execute este comando:

    ./irctl describe

  13. Você também pode marcar o status do seu SHIR no portal do Microsoft Purview, na página Runtimes de integração.

Configurar uma verificação com drivers externos

Ao verificar algumas fontes de dados, você precisa instalar o driver correspondente no computador em que o SHIR está instalado para que o Microsoft Purview se conecte com a fonte de dados. Abaixo está um exemplo para varredura do Db2. Consulte o respectivo artigo do conector para obter pré-requisitos específicos.

Observação

As fontes de dados que precisam desses drivers externos têm as informações listadas em seus pré-requisitos.

Neste exemplo, estamos instalando o driver Db2. As etapas para outros drivers são semelhantes.

  1. Primeiro, instale o runtime de integração.

  2. Baixe o driver (cada fonte tem seu driver individual listado). Por exemplo, é possível localizar o driver do DB2 aqui: Conecte-se e gerencie o Db2.

  3. Carregue o driver em cada nó para o runtime de integração. Você pode usar um comando como este:

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

    Uma confirmação de upload bem-sucedida tem esta aparência:

    ========== 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

    Observação

    Se você substituir nós ou escalar horizontalmente para novos nós, precisará carregar o driver externo novamente.

  4. Verifique os arquivos carregados com este comando:

    ./irctl storage list driver/db2

    Você deve ver uma resposta como esta:

    ========== 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. Crie uma verificação com o valor de DriverLocation com o valor Destination da etapa 3.

    Captura de tela da janela de configuração de varredura, mostrando o local do driver listado como driver/db2.

Alta disponibilidade e escalabilidade

Você pode atribuir vários nós do cluster do Kubernetes para ter alta disponibilidade usando o seletor de nós durante a instalação do runtime de integração auto-hospedada com suporte do Kubernetes. Os benefícios de ter vários nós são:

  • Maior disponibilidade do runtime de integração auto-hospedada para que ele não seja mais o único ponto de falha para verificações.
  • Execute mais verificações simultâneas. Cada nó pode capacitar muitas execuções de verificação ao mesmo tempo. Você pode escalar horizontalmente manualmente os nós do cluster Kubernetes se precisar de mais verificações simultâneas.
  • Ao verificar algumas fontes, como o Blob do Azure, o Azure Data Lake Storage Gen2 e os Arquivos do Azure, cada execução de verificação pode usar vários nós para aumentar o desempenho da verificação. Para outras fontes, as verificações são executadas em apenas um dos nós.

A funcionalidade do runtime de integração auto-hospedada com suporte do Kubernetes pode ser atualizada expandindo manualmente os nós de saída/entrada do cluster do Kubernetes.

Observação

Você deve fazer upload de todos os drivers necessários para a verificação em cada novo nó.

Requisitos de rede

Nome de domínio Portas de saída Descrição
Nuvem pública: <tenantID>-api.purview-service.microsoft.com
Azure Governamental:<tenantID>-api.purview-service.microsoft.us
China: <tenantID>-api.purview-service.microsoft.cn		 443 Necessário para se conectar ao serviço Microsoft Purview. Se você usar Pontos de Extremidade Privados do Microsoft Purview, esse ponto de extremidade será coberto pelo ponto de extremidade privado da conta.
Nuvem pública: <purview_account>.purview.azure.com
Azure Governamental:<purview_account>.purview.azure.us
China: <purview_account>.purview.azure.cn		 443 Necessário para se conectar ao serviço Microsoft Purview. Se você usar Pontos de Extremidade Privados do Microsoft Purview, esse ponto de extremidade será coberto pelo ponto de extremidade privado da conta.
Nuvem pública: <managed_storage_account>.blob.core.windows.net ou <ingestion_storage_account>.*.blob.storage.azure.net
Azure Governamental: <managed_storage_account>. blob.core.usgovcloudapi.net ou<ingestion_storage_account>. blob.core.usgovcloudapi.net
China: <managed_storage_account>.blob.core.chinacloudapi.cnou <ingestion_storage_account>.blob.core.chinacloudapi.cn		 443 Necessário para se conectar à conta de Armazenamento de Blobs do Azure gerenciada pelo Microsoft Purview.
Nuvem pública: <managed_storage_account>.queue.core.windows.net ou <ingestion_storage_account>.*.queue.storage.azure.net
Azure Governamental: <managed_storage_account>. queue.core.usgovcloudapi.net ou<ingestion_storage_account>. queue.core.usgovcloudapi.net
China: <managed_storage_account>.queue.core.chinacloudapi.cnou <ingestion_storage_account>.queue.core.chinacloudapi.cn		 443 Necessário para se conectar à conta de armazenamento de Fila do Azure gerenciada pelo Microsoft Purview.
Nuvem pública: *.compute.governance.azure.com
Azure Governamental:*.compute.governance.azure.us
China: *.compute.governance.azure.cn		 443 Necessário para se conectar ao serviço Microsoft Purview. Atualmente, o curinga é necessário, pois não há recurso dedicado.
mcr.microsoft.com 443 Necessário para baixar imagens.
*.data.mcr.microsoft.com 443 Necessário para baixar imagens.

Observação

Dependendo das fontes que os usuários desejam verificar, eles também precisam permitir outros domínios e portas de saída para outras fontes externas ou do Azure.

Versão

Normalmente, lançamos uma nova versão secundária do runtime de integração auto-hospedada todos os meses, que inclui recursos, aprimoramentos e correções de bugs.

Cada versão do runtime de integração auto-hospedada expira em um ano.

Como marcar a versão atual

Você pode marcar a versão do seu runtime de integração auto-hospedada do Kubernetes no portal ou com o IRCTL.

Portal

  1. No portal do Microsoft Purview, navegue até o Mapa de Dados.
  2. Selecionar Runtimes de integração
  3. A quarta coluna na linha de descrição do runtime de integração será Versão e você poderá marcar a versão lá.

IRCTL (1.1.0 e superior)

O comando describe retorna a versão do runtime de integração.

./irctl describe

Atualização automática

A partir da versão 1.1.0, o runtime de integração auto-hospedada do Kubernetes dá suporte à atualização automática, que é habilitada por padrão. Esse recurso garante que o runtime de integração seja atualizado automaticamente para a versão mais recente gerenciada pela Microsoft aproximadamente uma vez por mês.

Recusar

Recomendamos manter a atualização automática habilitada para se beneficiar dos recursos e aprimoramentos mais recentes. No entanto, você tem a opção de recusar a atualização automática usando o IRCTL. A configuração de atualização automática persiste até a reinstalação, portanto, você não precisa desabilitá-la a cada instalação.

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

Versão de atualização automática versus versão mais recente

Para garantir a estabilidade, a atualização automática geralmente está atrasada em relação à versão mais recente, com um atraso de um mês. A versão de atualização automática é gerenciada pela Microsoft.

Se você quiser atualizar seu runtime de integração para versões mais recentes, uma atualização manual deverá ser executada com o IRCTL da versão específica.

Próximas etapas

  • Last updated on