Sobre endereços IP permanentes para pods

Neste documento, explicamos como configurar uma comunicação confiável atribuindo um ou mais endereços IP persistentes a pods específicos nos clusters do Google Kubernetes Engine (GKE). Para aplicativos que exigem alta disponibilidade, também é possível configurar esses endereços IP permanentes para oferecer suporte a failover rápido ou usar o balanceamento de carga baseado em verificação de integridade.

Nos casos em que você executa uma conversão de endereços de rede personalizada (NAT), você pode querer um endereço IP persistente e estático para os endereços e nas conexões de entrada, seja quando a solução NAT inicia a conexão ou quando ele as recebe. Talvez você também queira ter controle sobre o IP alocados para o aplicativo para gerenciar a forma como ele interage com outros ou como ela lida com tipos específicos de solicitações com base nos seus negócios e cumprimento de requisitos regulatórios.

Por padrão, o pod usa os endereços IP da interface para o tráfego de saída. Os endereços IP da interface mudam quando o pod é reiniciado ou movido. Para ter mais sobre a comunicação de roteamento, é possível configurar endereços IP manualmente para seus pods no GKE.

Esses endereços IP podem ser IP externo para comunicação pela com a Internet ou internos para comunicação em uma rede Google Cloud. Você pode usar os endereços IP fornecidos pelo Google ou trazer seu próprio IP endereços IP (BYOIP).

Ao configurar endereços IP permanentes para pods no GKE, é possível aplicativo de mapeamento e lógica de negócios para permitir que pods específicos enviem e recebam tráfego de entrada e saída de qualquer um dos endereços IP persistentes.

O diagrama a seguir ilustra como um pod com várias interfaces de rede pode usar um endereço IP permanente de uma rede secundária enquanto ainda se comunica na rede padrão:

Arquitetura de várias redes
Arquitetura de várias redes

Terminologia e conceitos

Esta página usa os seguintes conceitos:

Balanceamento de carga com base em verificação de integridade

Use o balanceamento de carga com base em verificações de integridade quando quiser distribuir o tráfego de um endereço IP persistente entre vários pods ativos que correspondem a um seletor de rótulo específico. Esse recurso usa verificações de integridade regionais que você cria para monitorar constantemente os pods e garantir que o tráfego seja roteado apenas para endpoints íntegros. Também é possível configurar pods de espera (backup) para o endereço IP permanente. O GKE distribui automaticamente o tráfego para esses pods em espera somente se todos os pods ativos principais falharem nas verificações de integridade. Essa configuração evita que os pods individuais sejam sobrecarregados durante uma falha e garante a disponibilidade contínua do serviço.

Classes do Gateway

Classes de gateway, que gerenciam as atribuições de endereço IP persistentes, têm as seguintes classes:

  • gke-persistent-regional-external-managed para endereços IP externos
  • gke-persistent-regional-internal-managed para endereços IP internos (somenteGoogle Cloud)
  • gke-persistent-fast-regional-external-managed para endereços IP externo com failover rápido
  • gke-persistent-fast-regional-internal-managed para endereços IP internos (somenteGoogle Cloud) com failover rápido

As seguintes classes de gateway se aplicam ao balanceamento de carga baseado em verificação de integridade:

  • gke-passthrough-lb-internal-managed para endereços IP persistentes internos (somenteGoogle Cloud) compartilhados entre vários pods.

  • gke-passthrough-lb-external-managed para endereços IP persistentes externos compartilhados entre vários pods.

    As classes de gateway funcionam em regiões específicas. As classes de gateway oferecem gerenciamento básico de endereços IP e têm como foco o roteamento de rede na camada 3 (L3).

A tabela a seguir compara os recursos de cada classe de gateway:

Recurso Classes de gateway gke-persistent-* Classes de gateway gke-passthrough-lb-*
Meta principal Endereço IP permanente para uma única carga de trabalho. Balanceamento de carga em várias cargas de trabalho.
Mapeamento de pods 1:1 (roteia para o pod correspondente criado mais recentemente). 1:N (distribui o tráfego para todos os pods correspondentes íntegros).
Verificações de integridade Não é compatível com decisões de roteamento. Obrigatório (usa verificações de integridade regionais).
Pods de backup Incompatível. Compatível (usa pods de espera para failover).
Velocidade de failover Padrão ou rápido (usa classes *-fast-*). Configurável com parâmetros de verificação de integridade

Objetos de gateway

Os objetos de gateway servem como o ponto central para gerenciar e configurar endereços IP permanentes. Os objetos de gateway no GKE gerenciam um pool de endereços IP persistentes. Eles listam esses endereços e definem regras esses endereços IP podem ser atribuídos a GKEIPRoute.

Listener

Um listener é uma parte da configuração do gateway do GKE que controla quais pods nos namespaces do gateway podem usar o IP persistente endereços IP mantidos pelo gateway. O Listener permite personalizar o acesso a flexibilidade e segurança. Cada listener precisa de um nome exclusivo e permite filtrar acesso por namespace (todos, com base em rótulos ou somente o namespace do gateway).

Objeto GKEIPRoute

O objeto GKEIPRoute é um recurso personalizado que você configura para atribuir um endereço IP persistente a um pod específico no aglomerado. É possível usar a seção de status do objeto GKEIPRoute para monitorar sua configuração de endereço IP persistente, que fornece informações importantes por meio do seguintes campos:

  • Pod

    O campo Pod mostra o nome exato do pod vinculado ao usando os endereços IP internos. Um único pod pode usar vários endereços IP persistentes.

  • Condições

    O campo Condições informa se a configuração do seu endereço IP externo está funcionando corretamente e também pode ajudar a diagnosticar problemas caso sua configuração é inválido. Há quatro condições:

    • Accepted:indica se a especificação de recurso GKEIPRoute é válida. Se a configuração tiver erros, a condição Accepted será False com uma e por um bom motivo.
    • GCPReady:indica que Google Cloud preparou todos os recursos necessários. Os erros durante o processo de provisionamento de recursos do Google Cloud são refletidos no status da condição GCPReady.
    • DPV2Ready:indica o status da programação do caminho de dados, como o caminho de dados está pronto e programado para permitir conexões de rede no e configurar endereços IP permanentes.
    • Ready:indica que a configuração do seu endereço IP permanente é válida e funcional. É possível acessar os pods usando os endereços IP persistentes fornecidos você configurou seu aplicativo para usá-los. Ele é definido como True quando todas as outras três condições anteriores também são True.

  • nodeSelector

    Ao usar a failover rápida, é necessário usar o campo nodeSelector para especificar quais nós estão pré-configurados para failover rápida. Isso garante que, quando um failover ocorrer, você possa colocar o novo pod on-line rapidamente em um nó designado com o endereço IP persistente. É necessário programar os pods com endereços IP permanentes nesses nós. Normalmente, isso é feito usando o nodeSelector do pod para corresponder aos rótulos nos nós. Use o campo nodeSelector ao configurar o failover rápido e verifique se os rótulos especificados não selecionam mais de 64 nós.

Os campos a seguir são aplicáveis apenas ao balanceamento de carga baseado em verificação de integridade:

  • loadBalancing: especifica o nome da verificação de integridade regional que monitora a integridade dos pods.
  • backupPodSelector: define o conjunto de pods que recebem tráfego se todos os pods principais não estiverem íntegros.

Modos de reação

Os modos de reação determinam como o sistema se comporta quando o pod vinculado a um endereço IP permanente passa por mudanças, como mover-se entre nós ou quando uma um pod correspondente recém-criado fica disponível. Você pode usar os modos de reação para manter os endereços IP permanentes utilizáveis mesmo quando os pods mudam.

Os modos de reação são:

  • ReadyCondition

    No modo ReadyCondition, o sistema de endereços IP persistentes prioriza o pod a integridade dos dados. O sistema de endereços IP persistentes só atribui endereços IP a pods que correspondam aos rótulos especificados e que tenham passado pelas sondagens de integridade do Kubernetes, sinalizando o status Ready como True. Esse modo é ideal para aplicativos em que é crucial que o pod que recebe o IP persistente está totalmente preparado para lidar com o tráfego de entrada e saída.

  • Existe

    O modo Existe prioriza a presença de um pod. O IP permanente será anexado a um pod se ele corresponder aos rótulos e foi programada em um nó específico do cluster. Isso significa que o pod existe e tem um local designado para ser executado. Este modo é ideal para cenários em que a atribuição rápida de instâncias de IP persistentes tem prioridade sobre a prontidão rigorosa ou em ambientes como desenvolvimento e teste em que a conectividade imediata pode ser mais importante do que a integridade completa do aplicativo.

StatefulSets

StatefulSets são um tipo de carga de trabalho do Kubernetes projetado para aplicativos que precisam de identificadores estáveis e armazenamento permanente. Os pods em um StatefulSet têm nomes previsíveis (por exemplo: my-app-0, my-app-1).

Implantações

As implantações são um tipo de carga de trabalho do Kubernetes para gerenciar aplicativos em que os pods costumam ser intercambiáveis. nomes de pods em As implantações não são totalmente previsíveis.

Casos de uso

Endereços IP permanentes para pods do GKE abordam vários casos de uso para provedores de serviços de rede e segurança que executam aplicativos relacionados à rede no GKE.

Endereços IP permanentes para pods do GKE lidam com o uso a seguir casos:

  • Controle sobre NAT:ao atribuir endereços IP persistentes a pods que executam funções de rede, você tem controle granular sobre os endereços IP de origem usados para o tráfego de saída. Isso permite que você integre lógica NAT proprietária.
  • Pools de endereços IP dedicados:com os endereços IP dedicados, é possível associar endereços específicos a pods principais 5G individuais, garantindo a compatibilidade com softwares de fornecedores especializados.
  • Fluxos de tráfego confiáveis:já que o tráfego de retorno precisa ser roteado usando a mesma função de rede, os endereços IP persistentes garantem sistemas externos reconhecem e respondem ao pod correto sem interrupções e comunicação.
  • Alta disponibilidade para aplicativos sensíveis ao tempo:para aplicativos com requisitos de tempo de atividade rigorosos, como no setor de telecomunicações, é possível usar endereços IP permanentes com failover rápido para redirecionar rapidamente o tráfego para um pod íntegro em caso de falha, o que pode minimizar o tempo de inatividade para apenas alguns segundos.
  • Distribuição de carga:quando você usa o balanceamento de carga baseado em verificação de integridade, o GKE distribui o tráfego em vários pods ativos para evitar sobrecarregar uma única instância. Se não houver pods íntegros disponíveis, configure pods de backup em namespaces ou nós diferentes.

Vantagens

Os endereços IP permanentes para pods do GKE oferecem o seguinte benefícios:

  • Identidade externa:se você atribuir um endereço IP externo permanente a um pod, sistemas externos poderão alcançar esse pod de maneira consistente, mesmo que ele seja reiniciado ou movido para dentro do cluster. Isso é útil para serviços que precisam de um endpoint detectável externamente.
  • Comunicação confiável:os aplicativos que dependem de outros recursos com endereços IP específicos podem estabelecer conexões usando os endereços IP persistentes. Endereços IP persistentes são importantes para sistemas ou aplicativos legados com dependências de endereços IP fixados no código.
  • Migrações legadas: as migrações legadas podem ajudar na migração. aplicativos que dependem de endereços IP específicos durante a transição de desenvolvimento de software.
  • BYOIP: o BYOIP permite manter o controle sobre um endereço IP específico dos intervalos que você já tem usando-os nos clusters do GKE.
  • Melhoria no tempo de atividade do aplicativo: com a capacidade de failover rápido, é possível melhorar significativamente o tempo de atividade dos seus aplicativos críticos, minimizando o tempo de inatividade para apenas alguns segundos em caso de falha do pod.
  • Alta disponibilidade com failover automático: alcance a disponibilidade do serviço redirecionando automaticamente o tráfego para pods de espera íntegros quando os pods principais não passam nas verificações de integridade.

A seguir