Partilhar via

Criar e gerir um runtime de integração autoalojado suportado pelo Kubernetes

  • Artigo

Este artigo aborda os detalhes da nova funcionalidade SHIR baseada no Kubernetes para Linux que melhora a infraestrutura subjacente para proporcionar vários benefícios:

  • Escalabilidade: capacidade de dimensionar para centenas de máquinas.
  • Desempenho: desempenho melhorado na análise de cargas de trabalho.
  • Segurança (em contentores): capacidade de ter segurança em contentores num cluster do Kubernetes, em vez de alojar o SHIR diretamente num computador Windows

Este artigo aborda os detalhes para instalar e gerir um runtime de integração autoalojado suportado pelo Kubernetes.

Origens de dados suportadas

Para obter uma lista de todas as origens suportadas, veja as origens de dados suportadas para cada tabela de runtime de integração.

Arquitetura

Numa vista de arquitetura de alto nível, quando é instalado um SHIR baseado no Kubernetes, vários pods são automaticamente configurados nos nós do cluster do Kubernetes dos utilizadores. Esta instalação pode ser acionada por uma ferramenta de linha de comandos denominada IRCTL (mais detalhes nas secções seguintes). A IRCTL liga-se ao Serviço Microsoft Purview para registar o SHIR e ligar ao cluster do Kubernetes para instalar o SHIR. 

Durante a instalação, as imagens SHIR são transferidas do MCR (Microsoft Container Registries) para os pods SHIR. Após a instalação estar concluída, os pods no cluster dos utilizadores ligar-se-ão ao Serviço Microsoft Purview para solicitar tarefas de análise. À medida que uma tarefa de análise é solicitada, pode ligar a Origem de Dados no local dos utilizadores para a Análise de Dados.

Infográfico da arquitetura de rede para o runtime de integração autoalojado suportado pelo Kubernetes.

Pré-requisitos

  • Uma conta do Microsoft Purview com soluções de governação de dados empresariais .

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

    • Tipo de contentor: Linux
    • Versão do Kubernetes: 1.24.9 ou superior
    • SO do nó: SO baseado em Linux em execução na arquitetura x86
    • Especificação de 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 ativar o dimensionador automático de clusters)
    • Número do pod por Nó: >= 20 (número máximo do Pod – contagem de outros Pods que não pertencem a Self-Hosted IR)

    Observação

    A pasta /var/irstorage/ de cada Nó está reservada para SHIR. É legível e gravável para o SHIR. Pode fazer com que os registos sejam mantidos a partir desta pasta ou carregar controladores externos para esta pasta. Será criado pelo SHIR se não existir e não será eliminado após a eliminação do SHIR. As imagens de contentor utilizadas pelo SHIR são geridas pela Libertação da Memória do Kubernetes, que não será limpa pelo SHIR. Configure o limiar adequado para o cluster do Kubernetes.

  • Rede de cluster do Kubernetes: o cluster do Kubernetes que tem deve conseguir ligar-se ao ponto final listado nos requisitos de rede.

  • Ferramenta de linha de comandos do runtime de integração: para gerir o SHIR do Microsoft Purview Kubernetes localmente, precisa de uma ferramenta de linha de comandos denominada IRCTL. Pode transferir esta ferramenta durante o processo de criação do SHIR. IRCTL é uma ferramenta de linha de comandos para gerir o seu SHIR do Microsoft Purview. Para obter mais informações, veja a documentação IRCTL.

  • Contexto do Kubernetes: o contexto do Kubernetes, que contém informações do cluster do Kubernetes e as permissões e credenciais do utilizador para este cluster, é necessário para comunicar com o cluster do Kubernetes. Para facilitar a configuração das permissões do utilizador para a gestão do SHIR, pode começar com o Kubernetes Administração função. Este contexto é gerado com a configuração do cluster do Kubernetes e guardado num ficheiro de configuração. Onde e como pode obter este ficheiro depende da configuração do cluster do Kubernetes.
    • Se utilizar kubeadm init para configurar o cluster do Kubernetes, pode encontrar o ficheiro /etc/Kubernetes/admin.confde configuração em .
    • Se utilizar o AKS, pode seguir a documentação de orientação do AKS para utilizar o comando do módulo Az PowerShell para obter as credenciais deste cluster para o seu computador local. O contexto pode ser intercalado com o ficheiro $HOME/.kube/config de configuração em diretamente.
    • Se estiver a utilizar outras ferramentas para configurar um cluster do Kubernetes, veja a documentação do Kubernetes.
    • Como tem o ficheiro de configuração do contexto do Kubernetes, intercale-o no ficheiro de configuração, que é $HOME/.kube/config, no computador que pretende executar o comando IRCTL. Em alternativa, também pode definir o ficheiro de configuração do contexto do Kubernetes numa variável de ambiente denominada KUBECONFIG. Para obter mais informações sobre o contexto do Kubernetes, veja Configurar o Acesso a Múltiplos Clusters.

Criar o runtime de integração autoalojado suportado pelo Kubernetes

Para controlar e gerir um SHIR do Kubernetes, os utilizadores podem transferir uma ferramenta de linha de comandos chamada IRCTL. Seguem-se os passos para o runtime de integração autoalojado suportado pelo Kubernetes.

Os passos irão orientá-lo através da transferência de IRCTL, mas para obter ligações diretas, veja a documentação irCTL.

Configurar um runtime de integração autoalojado suportado pelo Kubernetes

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

  2. Selecione o botão + Novo

    Captura de ecrã a mostrar a janela runtimes de integração no Mapa de Dados do Microsoft Purview.

  3. Selecione Autoalojado e, em seguida, selecione Continuar

    Captura de ecrã a mostrar a nova janela do runtime de integração, com a opção autoalojada selecionada.

  4. Dê um nome ao runtime e, em seguida, selecione o botão de alternar do suporte do serviço Kubernetes para ativar

    Captura de ecrã da nova janela do runtime de integração com o botão de alternar do Kubernetes ativado.

  5. Selecione Criar

  6. Selecione Obter chave de registo

    Captura de ecrã da página ver o runtime de integração com o botão Obter chave de registo realçado.

  7. Copie o valor da chave. Precisa dele para executar comandos em IRCTL mais tarde.

    Dica

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

  8. Selecione a ligação Transferir IRCTL e instalar o runtime de integração para transferir a ferramenta IRCTL. (Também pode seguir estes passos para transferir a IRCTL diretamente.)

  9. No computador onde pretende executar a linha de comandos IRCTL, instale IRCTL a partir da transferência. A IRCTL liga-se ao cluster do Kubernetes através do contexto da configuração do Kube. Se o contexto não for especificado, IRCTL utiliza o contexto atual. Pode definir o contexto de uma de duas formas:

    • Execute a linha de comandos 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 IRCTL e execute --context para especificar o contexto na configuração do Kube

  10. Execute a linha de comandos IRCTL e execute este comando com a chave de registo que copiou.

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

    Observação

    Se o seletor de nós não for especificado, utilizará todos os nós do cluster do Kubernetes. Para o AKS, sugira utilizar a etiqueta do conjunto de nós do AKS como seletor de nós ou pode personalizar etiquetas diferentes para os nós SHIR.

  11. Verá 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 pode ser utilizado para monitorizar o progresso da instalação: ./irctl install status

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

    ./irctl describe

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

Configurar uma análise com controladores externos

Ao analisar algumas origens de dados, tem de instalar o controlador correspondente no computador onde o SHIR está instalado para que o Microsoft Purview se ligue à origem de dados. Segue-se um exemplo de análise Db2. Veja o respetivo artigo de conector para obter pré-requisitos específicos.

Observação

As origens de dados que precisam destes controladores externos terão as informações listadas nos respetivos pré-requisitos.

Neste exemplo, vamos instalar o controlador Db2. Os passos para outros controladores serão semelhantes.

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

  2. Transfira o controlador (cada origem terá o controlador individual listado.) Por exemplo, pode encontrar o controlador DB2 aqui: Ligar e gerir a Db2.

  3. Carregue o controlador para cada nó do runtime de integração. Pode utilizar um comando como este:

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

    Uma confirmação de carregamento bem-sucedida terá o seguinte aspeto:

    ========== 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 substituir nós ou aumentar horizontalmente para novos nós, terá de carregar o controlador externo novamente.

  4. Verifique os ficheiros carregados com este comando:

    ./irctl storage list driver/db2

    Deverá 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 a análise com o valor de DriverLocation com o valor Destino do passo 3.

    Captura de ecrã a mostrar a janela de configuração da análise, com a localização do controlador listada como controlador/db2.

Elevada disponibilidade e escalabilidade

Pode atribuir vários nós do cluster do Kubernetes para terem elevada disponibilidade ao utilizar o seletor de nós durante a instalação do runtime de integração autoalojado suportado pelo Kubernetes. As vantagens de ter vários nós são:

  • Maior disponibilidade do runtime de integração autoalojado para que deixe de ser o ponto único de falha para análises.
  • Execute mais análises simultâneas. Cada nó pode capacitar muitas execuções de análise ao mesmo tempo. Se precisar de mais análises simultâneas, pode aumentar horizontalmente os nós do cluster do Kubernetes.
  • Ao analisar algumas origens, como o Blob do Azure, Azure Data Lake Storage Gen2 e Arquivos do Azure, cada execução de análise pode utilizar vários nós para aumentar o desempenho da análise. Para outras origens, as análises são executadas apenas num dos nós.

A capacidade do runtime de integração autoalojado suportado pelo Kubernetes pode ser atualizada ao aumentar/reduzir horizontalmente manualmente os nós do cluster do Kubernetes.

Observação

Tem de carregar todos os controladores necessários para a análise em cada novo nó.

Requisitos de rede

Nome de domínio Portas de saída Descrição
Cloud 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 ligar ao serviço Microsoft Purview. Se utilizar os Pontos Finais Privados do Microsoft Purview, este ponto final é abrangido pelo ponto final privado da conta.
Cloud pública: <purview_account>.purview.azure.com
Azure Governamental:<purview_account>.purview.azure.us
China: <purview_account>.purview.azure.cn		 443 Necessário para ligar ao serviço Microsoft Purview. Se utilizar os Pontos Finais Privados do Microsoft Purview, este ponto final é abrangido pelo ponto final privado da conta.
Cloud 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 ligar à conta de armazenamento de Blobs do Azure gerida pelo Microsoft Purview.
Cloud 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 ligar à conta de armazenamento de Filas do Azure gerida pelo Microsoft Purview.
Cloud pública: *.compute.governance.azure.com
Azure Governamental:*.compute.governance.azure.us
China: *.compute.governance.azure.cn		 443 Necessário para ligar ao serviço Microsoft Purview. Atualmente, é necessário um caráter universal, uma vez que não existe nenhum recurso dedicado.
mcr.microsoft.com 443 Necessário para transferir imagens.
*.data.mcr.microsoft.com 443 Necessário para transferir imagens.

Observação

Consoante as origens que os utilizadores pretendam analisar, também precisam de permitir outros domínios e portas de saída para outras origens externas ou do Azure.

Versão

Normalmente, lançamos uma nova versão secundária do runtime de integração autoalojado todos os meses, que inclui funcionalidades, melhoramentos e correções de erros.

Cada versão do runtime de integração autoalojado expira dentro de um ano.

Como marcar a versão atual

Pode marcar a versão do runtime de integração autoalojado do Kubernetes no portal ou com a IRCTL.

Portal

  1. No portal do Microsoft Purview, navegue para o Mapa de Dados.
  2. Selecione Runtimes de integração
  3. A quarta coluna na linha de descrição do runtime de integração será Versão e pode marcar a versão aí.

IRCTL (1.1.0 e superior)

O comando describe devolverá 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 autoalojado do Kubernetes suporta a atualização automática, que está ativada por predefinição. Esta funcionalidade garante que o runtime de integração é atualizado automaticamente para a versão gerida pela Microsoft mais recente aproximadamente uma vez por mês.

Optar ativamente por não participar

Recomendamos que mantenha a atualização automática ativada para beneficiar das funcionalidades e melhorias mais recentes. No entanto, tem a opção de optar ativamente por não atualizar automaticamente com IRCTL. A configuração da atualização automática persiste através da reinstalação, pelo que não precisa de a desativar com cada instalação.

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

Atualização automática da versão vs. versão mais recente

Para garantir a estabilidade, a atualização automática está normalmente por detrás da versão mais recente com um atraso de um mês. A versão de atualização automática é gerida pela Microsoft.

Se quiser atualizar o runtime de integração para versões mais recentes, deve ser efetuada uma atualização manual com IRCTL da versão específica.

Próximas etapas