Reconciliação do DNS do Active Directory e do Kubernetes em implantações de Clusters de Big Data

Este artigo descreve alguns dos desafios e as soluções para acomodar a integração do Active Directory ao implantar clusters de Big Data.

Overview

Quando o cluster de Big Data não é implantado com a integração do Active Directory, contamos com o serviço do CoreDNS do Kubernetes para as resoluções internas de DNS. O Kubernetes usa um domínio interno, como <namespace>.svc.cluster.local. Ele cria registros A (pesquisa avançada) e PTR (pesquisa inversa) no servidor DNS com nomes neste domínio.

No entanto, quando o modo Active Directory está habilitado, um novo domínio entra em cena com seu próprio conjunto de servidores DNS. Durante a resolução de nome interno, isso pode resultar em confusão sobre qual conjunto de servidores DNS acessar para pesquisas de encaminhamento e reversas.

Challenges

• Quando novos pods Kubernetes forem implantados, será necessário adicionar as entradas DNS em ambos os conjuntos de servidores DNS. O Kubernetes cuida da gravação das entradas em seu CoreDNS, no entanto, o fluxo de trabalho de implantação do BDC é responsável por adicionar as entradas necessárias em servidores DNS do Controlador de Domínio do Active Directory. Da mesma forma, quando um cluster de Big Data é excluído, o fluxo de trabalho deve garantir que essas entradas sejam removidas.
• Os servidores DNS do Active Directory são externos ao cluster do Kubernetes. Mas o BDC tem seu próprio espaço IP dentro do Kubernetes e não pode criar registros para esse espaço IP em um servidor DNS situado externamente, pois esse espaço IP não está visível fora dos limites do cluster.
• Quando ocorrem eventos de failover no cluster do Kubernetes, os registros nos servidores DNS do AD também devem ser atualizados.
• Além dos nomes de pod, os nomes de serviço do Kubernetes também devem ser endereçáveis por meio das pesquisas de nome de domínio do AD. Isso cria um desafio adicional no DNS do Active Directory, pois um nome de serviço pode ser mapeado para vários endereços IP de pod.
• Os atrasos de propagação e replicação de atualização de registro em servidores DNS organizacionais do Active Directory podem ser significativos e além do controle dos fluxos de trabalho de gerenciamento do BDC. Isso pode impactar a funcionalidade do BDC imediatamente após a implantação e o failover. Pelo contrário, o CoreDNS do Kubernetes é mais rápido e eficiente devido à sua localidade.

Solution

Para contornar os desafios mencionados acima, a solução implementada no BDC envolve um novo serviço CoreDNS interno gerenciado dentro do namespace BDC. Esse é o único serviço DNS que os pods no namespace do BDC acessarão para resolução de nomes. A complexidade de vários domínios está oculta por trás do novo serviço CoreDNS.

Por exemplo, no diagrama a seguir, os pods usam o servidor CoreDNS do BDC para resolver nomes. Os pods não interagem diretamente com o servidor CoreDNS do Kubernetes ou com o Servidor DNS do AD.

Aqui estão alguns dos detalhes de implementação que esclarecem como esse design funciona no BDC:

Gerenciamento centralizado de vários domínios

A complexidade do que acontece em pesquisas de nome permanece oculta atrás do serviço DNS interno de forma centralizada. Isso evita colocar a carga de gerenciar vários domínios em pods individuais e simplifica o design.

Nenhum registro para pods internos em servidores DNS externos

Como resultado desse princípio de design, o BDC não precisará criar e gerenciar registros A e PTR para pods no espaço IP do Kubernetes em servidores DNS externos.

Nenhuma duplicação de registros

Registros DNS internos em vários locais. O único armazenamento para esses registros é o CoreDNS do Kubernetes. O CoreDNS interno do BDC fará uma reescrita computacional e o encaminhamento de consultas DNS para o Kubernetes CoreDNS.

Computational rewriting

Como o BDC não armazena nenhum registro, o BDC é responsável pela tradução de consultas de pesquisa de entrada com nomes com domínio do AD para os nomes com domínio kubernetes e encaminhar essa consulta para o Kubernetes CoreDNS. Por exemplo, uma consulta de entrada para compute-0-0.contoso.local seria reescrita para compute-0-0.compute-0-svc.contoso.svc.cluster.local e essa solicitação seria encaminhada para o Kubernetes CoreDNS. No caso de pesquisas inversas, a solicitação é encaminhada com os IPs internos inalterados para o Kubernetes CoreDNS, e a resposta é reescrita para o nome de domínio do AD antes de ser enviada ao cliente.

Simplicidade nas configurações do pod

Como apenas o CoreDNS do BDC interno é referenciado em /etc/resolv.conf de todos os pods BDC, isso simplifica a visão de rede dos pods. Em vez disso, a complexidade ficará oculta no CoreDNS interno.

Endereço IP estático e confiável para o serviço DNS

O serviço CoreDNS implantado pelo BDC terá ip interno estático registrado que pode ser acessado de todos os pods. Isso garantirá que os valores em /etc/resolv.conf não precisarão ser atualizados.

O gerenciamento de balanceamento de carga de serviço é mantido pelo Kubernetes

Quando buscas forem feitas para serviços em vez de pods individuais, elas ainda irão para o Kubernetes CoreDNS, portanto, o BDC não é responsável por implementar o balanceamento de carga especificamente para o domínio AD.

Por exemplo, se uma solicitação de pesquisa direta for recebida para compute-0-svc.contoso.local, ela será reescrita para compute-0-svc.contoso.svc.cluster.local. Essa solicitação será encaminhada para o CoreDNS do Kubernetes e o balanceamento de carga ocorrerá lá. Uma resposta será um endereço IP para uma das várias instâncias do pool de computação (réplicas de pod).

Scalability

Como o BDC não armazena nenhum registro, o CoreDNS interno do BDC pode ser dimensionado sem preocupar-se com a retenção de estado ou a replicação de registro entre várias réplicas. Se os registros DNS forem armazenados no BDC, a replicação do estado em todos os pods também deverá ser gerenciada pelo BDC.

Entradas de serviço visíveis externamente permanecem no DNS do AD

Para pontos de extremidade de serviço que precisam ser acessíveis a clientes fora do cluster do Kubernetes, as entradas DNS serão criadas no servidor DNS do AD à medida que o BDC estiver sendo implantado. O usuário inserirá os nomes DNS a serem registrados por meio dos perfis de configuração de implantação.

Self-deprovisioning

Depois que o BDC é excluído, não há nenhum trabalho dinâmico adicional para excluir entradas DNS quando o cluster está sendo desprovisionado. As únicas entradas no DNS remoto do Active Directory que precisam ser limpas são para serviços externos e estão estáticas em número. As entradas DNS internas serão removidas automaticamente com o cluster.

Next steps

• Implantar Clusters de Big Data do SQL Server no modo do Active Directory
• Gerenciar o acesso ao cluster de Big Data no modo do Active Directory
• Implantar vários clusters de Big Data do SQL Server no mesmo domínio do Active Directory