Acerca dos endereços IP persistentes para pods

Este documento explica como pode configurar uma comunicação fiável atribuindo um ou mais endereços IP persistentes a Pods específicos nos seus clusters do Google Kubernetes Engine (GKE). Para aplicações que requerem elevada disponibilidade, também pode configurar estes endereços IP persistentes para suportar a comutação por falha rápida.

Em determinados casos, quando está a executar uma solução de tradução de endereços de rede (NAT) personalizada, pode querer um endereço IP persistente estático para ligações de saída e de entrada, quer quando a solução NAT inicia a ligação, quer quando a recebe. Também pode querer ter controlo sobre os endereços IP atribuídos à aplicação para gerir a forma como interage com outros sistemas ou como processa tipos específicos de pedidos com base nos requisitos da sua empresa.

Por predefinição, o pod usa os endereços IP da respetiva interface para o tráfego de saída. Os endereços IP da interface mudam quando o Pod é reiniciado ou movido. Para ter mais controlo sobre a comunicação de encaminhamento, pode configurar manualmente endereços IP persistentes para os seus pods no GKE.

Estes endereços IP podem ser endereços IP externos para comunicar através da Internet ou endereços IP internos para comunicar na sua rede Google Cloud. Pode usar endereços IP fornecidos pela Google ou usar os seus próprios endereços IP (BYOIP).

Ao configurar endereços IP persistentes para pods no GKE, pode mapear a aplicação e a lógica empresarial para permitir que pods específicos enviem e recebam tráfego para ou a partir de qualquer um dos endereços IP persistentes.

O diagrama seguinte ilustra como um pod com várias interfaces de rede pode usar um endereço IP persistente de uma rede secundária enquanto comunica na rede predefinida:

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

Terminologia e conceitos

Esta página usa os seguintes conceitos:

Classes de gateway

As classes de gateway, que gerem as suas atribuições de endereços IP persistentes, estão disponíveis nas seguintes classes:

  • gke-persistent-regional-external-managed para endereços IP externos
  • gke-persistent-regional-internal-managed para endereços IP internos (Google Cloudapenas)
  • gke-persistent-fast-regional-external-managed para endereços IP externos com comutação por falha rápida

  • gke-persistent-fast-regional-internal-managed para endereços IP internos (apenas na Google Cloud) com comutação por falha rápida

    As classes de gateway funcionam em regiões específicas. As classes de gateway oferecem gestão básica de endereços IP e estão focadas no encaminhamento de rede da camada 3 (L3).

Objetos de gateway

Os objetos de gateway funcionam como o ponto central para gerir e configurar endereços IP persistentes. Os objetos Gateway no GKE gerem um conjunto de endereços IP persistentes. Estas listam os endereços e definem regras sobre como estes endereços IP podem ser atribuídos ao GKEIPRoute.

Ouvinte

Um Listener faz parte da configuração do GKE Gateway que controla que pods nos espaços de nomes do Gateway podem usar os endereços IP persistentes detidos pelo Gateway. O Listener permite-lhe personalizar o acesso para maior flexibilidade e segurança. Cada Listener precisa de um nome exclusivo e permite-lhe filtrar o acesso por espaço de nomes (todos, com base em etiquetas ou apenas o espaço de nomes do Gateway).

Objeto GKEIPRoute

O objeto GKEIPRoute é um recurso personalizado que configura para atribuir um endereço IP persistente a um pod específico no seu cluster do GKE. Pode usar a secção de estado do objeto GKEIPRoute para monitorizar a configuração do endereço IP persistente, que fornece informações importantes através dos seguintes campos:

  • Agrupamento

    O campo Pod mostra o nome exato do Pod associado aos endereços IP persistentes. Um único Pod pode usar vários endereços IP persistentes.

  • Condições

    O campo Condições indica se a configuração do endereço IP externo está a funcionar corretamente e também pode ajudar a diagnosticar problemas se a configuração não for válida. Existem quatro condições:

    • Accepted: indica se a especificação do recurso GKEIPRoute é válida. Se a configuração tiver erros, a condição Accepted é False com um motivo.
    • GCPReady: denota que Google Cloud preparou todos os recursos necessários. Os erros durante o processo de aprovisionamento de recursos são refletidos no estado da condição GCPReady. Google Cloud
    • DPV2Ready: indica o estado da programação do caminho de dados, como o caminho de dados estar pronto e programado para permitir ligações de rede nos endereços IP persistentes configurados.
    • Ready: indica que a configuração do endereço IP persistente é válida e funcional. Os pods podem ser alcançados nos endereços IP persistentes fornecidos, desde que tenha configurado a sua aplicação para os usar. Esta opção está definida como True quando todas as outras três condições anteriores também estão True.

  • nodeSelector

    Quando usar a comutação por falha rápida, tem de usar o campo nodeSelector para especificar que nós estão pré-configurados para a comutação por falha rápida. Isto garante que, quando ocorre uma comutação por falha, pode colocar rapidamente o novo pod online num nó designado com o endereço IP persistente. Tem de garantir que agenda os seus pods com endereços IP persistentes nestes nós. Normalmente, faz isto usando o nodeSelector do pod para corresponder às etiquetas nos nós. Use o campo nodeSelector ao configurar a comutação por falha rápida e certifique-se de que as etiquetas especificadas não selecionam mais de 64 nós.

Modos de reação

Os modos de reação determinam o comportamento do sistema quando o pod associado a um endereço IP persistente sofre alterações, como a deslocação entre nós ou quando um pod correspondente criado recentemente fica disponível. Pode usar os modos de reação para manter os seus endereços IP persistentes utilizáveis, mesmo que os seus pods mudem.

Os modos de reação são um dos seguintes:

  • ReadyCondition

    No modo ReadyCondition, o sistema de endereços IP persistentes dá prioridade ao estado de funcionamento do pod. O sistema de endereços IP persistentes só atribui endereços IP a pods que correspondam às etiquetas especificadas e tenham passado nas sondas de integridade do Kubernetes, sinalizando o respetivo estado Ready como True. Este modo é ideal para aplicações em que é fundamental que o pod que recebe o endereço IP persistente esteja totalmente preparado para processar o tráfego de entrada e saída.

  • Existe

    O modo Exists dá prioridade à presença de um agrupamento. O endereço IP persistente é anexado a um pod se esse pod corresponder às etiquetas na sua configuração e tiver sido agendado num nó específico no seu cluster. Isto significa que o Pod existe e tem um local designado para ser executado. Este modo é adequado para cenários em que a atribuição rápida do endereço IP persistente tem prioridade sobre a disponibilidade rigorosa ou em ambientes como o desenvolvimento e os testes, em que a conetividade imediata pode ser mais importante do que o estado de funcionamento total da aplicação.

StatefulSets

Os StatefulSets são um tipo de carga de trabalho do Kubernetes concebido para aplicações que precisam de identificadores estáveis e armazenamento persistente. Os pods num StatefulSet têm nomes previsíveis (por exemplo: my-app-0, my-app-1).

Implementações

As implementações são um tipo de carga de trabalho do Kubernetes para gerir aplicações sem estado em que os pods são geralmente intermutáveis. Os nomes dos pods nas implementações não são totalmente previsíveis.

Exemplos de utilização

Os endereços IP persistentes para pods do GKE resolvem vários exemplos de utilização para fornecedores de serviços de rede e segurança que executam aplicações relacionadas com a rede no GKE.

Os endereços IP persistentes para pods do GKE resolvem os seguintes exemplos de utilização:

  • Controlo sobre o NAT: ao atribuir endereços IP persistentes a pods que executam funções de rede, obtém um controlo detalhado sobre os endereços IP de origem usados para o tráfego de saída. Isto permite-lhe integrar a sua lógica NAT proprietária.
  • Pools de endereços IP dedicados: os endereços IP dedicados permitem-lhe fazer corresponder endereços específicos a pods 5G Core individuais, garantindo a compatibilidade com software de fornecedores especializados.
  • Fluxos de tráfego fiáveis: uma vez que o tráfego de retorno tem de ser encaminhado novamente através da mesma função de rede, os endereços IP persistentes garantem que os sistemas externos reconhecem e respondem ao pod correto sem interrupções na comunicação.
  • Elevada disponibilidade para aplicações sensíveis ao tempo: para aplicações com requisitos de tempo de atividade rigorosos, como na indústria das telecomunicações, pode usar endereços IP persistentes com comutação por falha rápida para redirecionar rapidamente o tráfego para um pod em bom estado no caso de uma falha, o que pode minimizar o tempo de inatividade para apenas alguns segundos.

Vantagens

As moradas IP persistentes para pods do GKE oferecem as seguintes vantagens:

  • Identidade externa: se atribuir um endereço IP persistente externo a um Pod, os sistemas externos podem alcançar esse Pod de forma consistente, mesmo que seja reiniciado ou movido no cluster. Isto é útil para serviços que precisam de um ponto final detetável externamente.
  • Comunicação fiável: as aplicações que dependem de outros recursos com endereços IP específicos podem estabelecer ligações de forma fiável através de endereços IP persistentes. Os endereços IP persistentes são importantes para sistemas ou aplicações antigos com dependências de endereços IP codificadas.
  • Migrações antigas: as migrações antigas podem ajudar na migração de aplicações que dependem de ter endereços IP específicos durante o processo de transição.
  • BYOIP: o BYOIP permite-lhe manter o controlo sobre intervalos de endereços IP específicos que já possui, usando-os nos seus clusters do GKE.
  • Tempo de atividade da aplicação melhorado: com a capacidade de comutação por falha rápida, pode melhorar significativamente o tempo de atividade das suas aplicações críticas minimizando o tempo de inatividade para apenas alguns segundos em caso de falha de um Pod.

O que se segue?