Configurar a rede para o Serviço gerenciado para Apache Kafka

Os clientes podem se conectar a um cluster do Serviço gerenciado do Google Cloud para Apache Kafka de qualquer rede de nuvem privada virtual (VPC) nos seus projetos Google Cloud . Também é possível ativar o acesso de intervalos de IP confiáveis pela Internet pública.

Nesta página, explicamos como a rede é configurada no Serviço gerenciado para Apache Kafka, como ativar conexões entre clientes do Kafka e seu cluster e como conectar clientes e clusters de forma particular em diferentes projetos.

Uma rede VPC é uma versão virtual de uma rede física, implementada dentro Google Cloud. Ela oferece conectividade de rede segura e privada para suas instâncias de VM, cargas de trabalho de contêineres e outros recursos. Para mais informações, consulte a visão geral das redes VPC.

Visão geral

Quando você cria um cluster, o serviço coloca os brokers e endpoints de rede em uma rede VPC dentro de um projeto gerenciado pelo Google. Esse projeto é chamado de projeto locatário, e a rede é chamada de rede locatário. Em contraste, seus recursos, aplicativos cliente e redes VPC do cliente residem no seu próprio projeto, chamado de projeto consumidor. Cada cluster do Serviço gerenciado para Apache Kafka tem a própria rede de locatário isolada.

As redes VPC são divididas em partições chamadas sub-redes. Cada sub-rede define um intervalo de endereços IP em uma região específica da sua rede de nuvem. Para permitir que os aplicativos cliente se comuniquem com o cluster, conecte sub-redes nas redes VPC à rede do locatário ou ative o acesso público ao cluster para se conectar pela Internet pública.

O diagrama a seguir mostra dois projetos Google Cloud , project-1 e project-2. Um cluster do Serviço Gerenciado para Apache Kafka está localizado em project-1.

Um cluster do Serviço gerenciado para Apache Kafka com três sub-redes conectadas

As seguintes sub-redes estão conectadas ao cluster:

  • subnet-1, na rede VPC vpc-1 em project-1.
  • subnet-2, na rede VPC vpc-2 em project-1.
  • subnet-3, na rede VPC vpc-3 em project-2.

Conectar sub-redes a um cluster

Ao criar um cluster do Serviço gerenciado para Apache Kafka, especifique pelo menos uma sub-rede. Depois, é possível atualizar o cluster para adicionar ou remover sub-redes.

As sub-redes conectadas podem pertencer ao mesmo projeto de consumidor do cluster ou a um projeto de consumidor diferente. Os aplicativos cliente em qualquer região dentro das redes VPC conectadas podem se conectar ao cluster. Para mais informações sobre locais e contagens de sub-redes, consulte Limitações.

Para mais informações sobre como ver sub-redes conectadas, consulte Ver um cluster.

Entradas de DNS do cluster

Quando você conecta uma sub-rede a um cluster, o serviço cria entradas DNS nessa rede de sub-rede para o endereço de inicialização e os brokers do cluster. Os clientes do Kafka usam o endereço de bootstrap para localizar os brokers e estabelecer uma conexão. Quando o servidor de bootstrap redireciona um cliente para um broker específico, ele usa o URL do broker em vez de um endereço IP.

Os URLs de inicialização e de agente são fixos durante a vida útil de um cluster, mas o formato deles pode variar de acordo com o cluster. Para conferir o endereço de bootstrap de um cluster, consulte Conferir o endereço de bootstrap de um cluster.

Os nomes DNS são os mesmos em todas as sub-redes conectadas, embora correspondam a endereços IP diferentes em cada sub-rede. Como os nomes de DNS são consistentes, todos os aplicativos cliente do Kafka podem usar o mesmo endereço de inicialização.

Para exemplos de aplicativos cliente que se conectam ao Serviço gerenciado para Apache Kafka, consulte os seguintes tutoriais:

Dimensionamento de sub-rede

Ao adicionar uma sub-rede a um cluster, ela precisa ter endereços IP suficientes disponíveis. Cada sub-rede requer um endereço IP para cada broker do Kafka, além de um endereço IP para o endereço de bootstrap. O tamanho mínimo do cluster do Serviço gerenciado para Apache Kafka tem três brokers. Portanto, cada sub-rede precisa de pelo menos quatro endereços IP utilizáveis, incluindo o endereço de bootstrap.

Se o cluster tiver mais de 45 vCPUs, ele terá um broker para cada 15 vCPUs. Nesse caso, calcule o número mínimo de endereços IP para cada sub-rede da seguinte maneira:

  1. Divida o número de vCPUs por 15.
  2. Arredonde para o número inteiro mais próximo.
  3. Adicione 1 para considerar o endereço de inicialização.

Por exemplo, um cluster com 60 vCPUs precisa de pelo menos (60/15 + 1) = 5 endereços IP utilizáveis.

O Google pode mudar a proporção de corretores para vCPUs. Para acomodar mudanças, recomendamos que você aloque três vezes o número de endereços IP calculado na etapa anterior.

Ao planejar o tamanho da sub-rede, baseie seus cálculos no tamanho máximo que você espera que o cluster seja escalonado.

Se você planeja usar o Kafka Connect, considere também os requisitos de sub-rede para o cluster do Connect. Para mais informações, consulte sub-rede de worker.

Intervalos de IP públicos usados de maneira privada

É possível conectar o cluster a sub-redes que usam o espaço de endereço não RFC 1918. Esses intervalos de endereços IP são chamados de intervalos de IP público usado de modo privado (PUPI).

Não é necessário fazer configurações adicionais para se conectar a sub-redes PUPI. As sub-redes PUPI precisam usar um intervalo IPv4 válido que não seja um intervalo de sub-rede IPv4 proibido.

Conectar clientes e clusters de forma particular entre projetos

Se você quiser conectar clientes do Kafka em diferentes projetos do Google Cloud ao seu cluster de maneira particular, use um dos seguintes métodos:

As seções a seguir descrevem tais opções.

Conectar um cluster entre projetos

É possível conectar sub-redes de outros projetos ao seu cluster. Para ativar o acesso entre projetos, conceda permissões à conta de serviço gerenciado pelo Google associada ao cluster. Em cada projeto em que você quer que os clientes do Kafka acessem o cluster, a conta de serviço precisa ter o papel do IAM Agente do serviço gerenciado do Kafka nesse projeto. Esse papel permite que o cluster acesse recursosGoogle Cloud para criar recursos de rede e entradas de DNS.

Por exemplo, se project-1 contiver o cluster e você quiser que os clientes em project-2 acessem o cluster, conceda à conta de serviço do Kafka gerenciado para project-1 o papel de agente de serviço do Kafka gerenciado em project-2. Em seguida, conecte uma sub-rede de project-2 ao cluster, conforme descrito em Conectar sub-redes ao cluster.

Para conceder os papéis necessários, siga estas etapas:

Console

  1. Determine os Google Cloud projetos em que você quer que os clientes do Kafka acessem o cluster do Serviço gerenciado para Apache Kafka.

  2. Para cada projeto, no console Google Cloud , acesse a página IAM:

    Acessar IAM

  3. Clique em Conceder acesso.

  4. No campo Novos principais, insira o seguinte:

    service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com

    Substitua CLUSTER_PROJECT_NUMBER pelo número do projeto que contém o cluster do Serviço gerenciado para Apache Kafka.

  5. Clique em Adicionar funções.

  6. No campo Pesquisar papéis, insira Managed Kafka Service Agent. O nome do agente de serviço aparece nos resultados da pesquisa.

  7. Nos resultados da pesquisa, selecione Agente de serviço do Kafka gerenciado.

  8. Clique em Aplicar.

  9. Clique em Salvar.

gcloud

  1. Determine os Google Cloud projetos em que você quer que os clientes do Kafka acessem o cluster do Serviço gerenciado para Apache Kafka.

  2. Para cada projeto, execute o comando gcloud projects add-iam-policy-binding:

    gcloud projects add-iam-policy-binding CLIENT_PROJECT_ID \
    --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \
    --role=roles/managedkafka.serviceAgent

    Substitua:

    • CLIENT_PROJECT_ID: o nome do projeto que contém a rede VPC a ser conectada.
    • CLUSTER_PROJECT_NUMBER: o número do projeto do projeto que contém o cluster do Serviço Gerenciado para Apache Kafka.

Usar a VPC compartilhada para conectar projetos

Com a VPC compartilhada, uma organização pode conectar recursos de vários projetos a uma rede VPC comum. Para usar a VPC compartilhada com o Serviço gerenciado para Apache Kafka, siga estas etapas:

  1. Crie um cluster do Serviço gerenciado para Apache Kafka.

  2. Provisione a VPC compartilhada.

  3. Conceda à conta de serviço do Kafka gerenciado os papéis necessários no projeto host da VPC compartilhada, conforme descrito na seção anterior.

  4. Conecte o cluster do Serviço Gerenciado para Apache Kafka a uma sub-rede na rede VPC compartilhada.

Os clientes no projeto host da VPC compartilhada ou nos projetos de serviço podem se conectar ao cluster.

Para saber quando usar a VPC compartilhada nas arquiteturas de rede, consulte Práticas recomendadas e arquiteturas de referência para o design da VPC.

Conectar clientes a um cluster público

Se você tiver aplicativos cliente fora da sua rede VPC, ative o acesso público ao cluster. Um cluster público ainda exige uma sub-rede conectada. No entanto, não é necessário enviar tráfego por ele.

Quando você ativa o recurso de cluster público, o serviço provisiona endereços IPv4 externos para os endpoints de bootstrap e broker do cluster. O serviço também torna as entradas de DNS do cluster resolvíveis publicamente para esses endereços IP públicos. Isso significa que clientes externos podem usar o mesmo endereço de bootstrap para localizar os brokers e estabelecer uma conexão. Essa implementação usa o DNS split horizon. Os clientes em redes VPC que contêm uma sub-rede conectada continuam resolvendo os endpoints particulares, enquanto os clientes em outras redes resolvem os endpoints públicos. Ativar o recurso de cluster público não cria recursos adicionais no seu projeto de consumidor.

Ao ativar o recurso de cluster público, é necessário fornecer um ou mais intervalos de IP de origem permitidos. Para mais informações sobre tamanhos e limites de intervalos permitidos, consulte Clusters públicos ou Limitações.

É possível adicionar ou remover intervalos de IP de origem permitidos atualizando seu cluster. O Serviço Gerenciado para Apache Kafka usa o Cloud Next Generation Firewall para restringir o acesso a clusters públicos. A remoção de intervalos de IP de origem permitidos se aplica apenas a novas conexões (consulte efeitos no tráfego atual).

O serviço toma várias precauções para ajudar a garantir a segurança dos seus clusters públicos. Todas as conexões são criptografadas em trânsito usando TLS e exigem autenticação. É necessário fazer a autenticação usando uma identidade do IAM com SASL ou um certificado do cliente com mTLS. O acesso anônimo não é permitido. Para mais informações, consulte Tipos de autenticação para brokers do Kafka.

Os administradores de segurança podem proibir clusters públicos ativando a restrição de política organizacional gerenciada Restringir clusters públicos gerenciados do Kafka (constraints/managedkafka.managed.restrictPublicClusters). Para mais informações sobre restrições gerenciadas, consulte Restrições gerenciadas.

Configurar firewalls de saída de redes externas

Em alguns casos, talvez seja necessário determinar os endereços IPv4 externos dos endpoints de bootstrap e do broker. Para instruções sobre como recuperar esses valores, consulte Detalhes do cluster público.

O serviço disponibiliza essas informações das seguintes maneiras:

  1. Os endereços IPv4 externos associados ao cluster estão disponíveis na API Serviço Gerenciado para Apache Kafka, gcloud e Terraform.

  2. O serviço mantém um ou mais registros DNS de descoberta. São registros DNS A que contêm todos os endereços IPv4 externos associados ao seu cluster. É possível usar esses registros em firewalls baseados em FQDN, como o Cloud NGFW, que atualiza automaticamente as regras quando a lista de endpoints muda. A lista de endpoints de descoberta está disponível na API, gcloud e Terraform.

Considere o seguinte ao usar os endereços IP públicos associados ao seu cluster:

  1. A lista de endereços IPv4 públicos associados ao cluster pode mudar ou aumentar. Por isso, automatize a forma como você consome essas informações ou defina um processo para considerar novos registros DNS de descoberta ao aumentar a escala do cluster. As mudanças podem ocorrer quando:

    • Você escalona o cluster. O escalonamento vertical pode adicionar um ou mais endereços IPv4 externos à medida que novos brokers são adicionados. Para entender como a contagem de vCPUs influencia o número de brokers, consulte Dimensionamento de sub-rede.

    • Você desativa e ativa o recurso de cluster público. Essa ação atribui um novo conjunto de endereços IPv4 externos ao cluster.

  2. Cada registro DNS de descoberta contém no máximo 30 endereços IP. Isso fica dentro dos limites comuns aplicados pelos firewalls de FQDN. Clusters com 29 ou menos brokers têm um registro DNS de descoberta que contém 30 endereços IPv4 externos (incluindo o registro de inicialização). O serviço adiciona um registro DNS de descoberta para cada 30 brokers extras. Para entender como a contagem de vCPUs influencia o número de brokers, consulte Dimensionamento de sub-rede.

  3. Não configure os clientes do Kafka para se conectarem a registros DNS de descoberta. Em vez disso, configure os clientes para se conectarem ao endereço de inicialização. Saiba mais em Limitações.

  4. Se você usar essas informações para configurar firewalls de saída, permita a conectividade com as portas TCP 9092 (SASL) e 9192 (mTLS).

Arquitetura de rede de um cluster

Esta seção descreve os detalhes da arquitetura de rede usada no Serviço Gerenciado para Apache Kafka.

  • Um cluster do Kafka abrange uma rede de locatário e uma ou mais redes de consumidores.

  • Na rede do locatário, o cluster tem um único endereço IP e URL de inicialização. Esse endereço de inicialização corresponde a um balanceador de carga conectado a todos os brokers no cluster. Cada broker também pode agir individualmente como um servidor de inicialização, mas recomendamos que você use o endereço de inicialização para ter mais confiabilidade.

  • Em cada rede do consumidor, o serviço cria um endpoint do Private Service Connect para o endereço de bootstrap e um endpoint para cada broker.

  • O URL do endereço de bootstrap é o mesmo em todas as redes VPC a que um cluster está conectado. O endereço IP é local para a rede do consumidor.

  • Os clientes se conectam aos agentes do Kafka usando nomes DNS. Esses nomes são registrados automaticamente em todas as rede VPC a que um cluster do Kafka está conectado. O endereço de bootstrap e o número da porta estão disponíveis como uma propriedade do cluster.

  • Os clientes usam o endereço de bootstrap para recuperar URLs de broker, que são resolvidos para endereços IP locais de cada rede VPC. Você pode encontrar os endereços IP e URLs reais do broker no Cloud DNS.

O diagrama a seguir mostra um exemplo de arquitetura de uma rede de cluster do Serviço Gerenciado para Apache Kafka.

Uma rede do Serviço gerenciado para Apache Kafka. * Neste exemplo, o cluster tem três brokers e está na VPC do locatário.

  • Os agentes se comunicam com os clientes pela porta padrão do Kafka (9092) e têm endereços IP exclusivos. Neste exemplo, os três brokers têm endereços IP 10.128.10.2, 10.128.10.3 e 10.128.10.4, respectivamente.

  • Todos os três brokers se conectam ao balanceador de carga de bootstrap. Isso garante alta disponibilidade e tolerância a falhas regionais, porque o endereço de inicialização não fica restrito a um único broker ou zona.

Limitações

As seguintes limitações se aplicam a conexões VPC e clusters públicos:

  • Região da sub-rede. As sub-redes conectadas precisam estar na mesma região que o cluster.

  • Contagem de sub-redes. É possível conectar um mínimo de uma e um máximo de dez sub-redes a um cluster.

  • Sub-redes por rede. É possível conectar no máximo uma sub-rede por rede VPC a um cluster.

  • Tamanho da sub-rede. Cada sub-rede conectada exige pelo menos um endereço IP para cada broker e um endereço IP para o endereço de bootstrap. É necessário um mínimo de quatro endereços IP utilizáveis. Para mais informações, consulte Dimensionamento de sub-rede.

  • Sub-redes conectadas para clusters públicos. Para ativar o acesso público, seu cluster ainda precisa ter pelo menos uma sub-rede conectada, embora não seja necessário enviar tráfego por ela.

  • Intervalos de IP de origem permitidos. Cada intervalo de IP de origem permitido para um cluster público precisa ser especificado na notação CIDR IPv4. Cada tamanho de sub-rede CIDR precisa estar entre /16 e /32. Os intervalos CIDR não podem se sobrepor. Os endereços IPv6 não são aceitos. É possível especificar no máximo 500 intervalos de IP de origem permitidos.

  • Resolução de DNS do registro de descoberta. Os registros DNS de descoberta são projetados apenas para configurar firewalls de saída baseados em FQDN. Não configure os clientes do Kafka para se conectarem a esses registros de descoberta. Em vez disso, configure os clientes para se conectarem ao endereço de inicialização.

Resolver problemas

Para informações sobre como resolver problemas de rede, consulte Erros de rede.

A seguir