Controle a comunicação com endereços IP persistentes

Padrão

Esta página mostra como implementar endereços IP persistentes em pods do Google Kubernetes Engine (GKE). Pode assumir o controlo da rede de pods do GKE com o mapeamento de endereços IP persistentes personalizados. Para saber mais acerca dos endereços IP persistentes, dos respetivos exemplos de utilização e vantagens, consulte o artigo Acerca dos endereços IP persistentes para o GKE Pod.

Requisitos

• Versão 1.31 ou posterior do GKE.
• Escolha entre reservar endereços IP fornecidos pela Google ou usar os seus próprios endereços IP (BYOIP).
• Configure a sua aplicação em execução nos pods para reconhecer e usar endereços IP persistentes atribuídos.
• Os endereços IP persistentes para pods do GKE requerem clusters com o GKE Dataplane V2 e a API Gateway ativados.

Limitações

• Tem de configurar as suas aplicações para usar endereços IP persistentes atribuídos. O GKE não adiciona automaticamente a configuração do endereço IP às interfaces de rede do pod.
• Pode associar cada endereço IP persistente a um único pod de cada vez. Quando tem vários pods disponíveis, o GKE envia normalmente tráfego para o pod correspondente mais recente. No entanto, o GKE só o faz se o pod mais recente estiver em bom estado, o que significa que o pod tem o estado da condição Ready como True por predefinição. Pode configurar este comportamento e alterá-lo através da definição reactionMode em GKEIPRoute.
• O GKE só suporta endereços IPv4 como endereços IP persistentes.
• O GKE só suporta várias redes de camada 3 ou do tipo de dispositivo.
  • O suporte de alta disponibilidade (HA) através de endereços IP persistentes não é suportado para exemplos de utilização que não sejam DPDK.
• Pode especificar até 16 endereços IP num único GKEIPRoute. Para configurar mais moradas, pode criar vários objetos GKEIPRoute.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

• Leia acerca dos endereços IP.

• Reveja os requisitos e as limitações.

Implemente endereços IP persistentes para pods do GKE

Os endereços IP persistentes no GKE oferecem uma forma de dar aos seus pods uma identidade de rede estável, mesmo que os próprios pods sejam atualizados ou movidos.

Esta secção resume o fluxo de trabalho para implementar endereços IP persistentes para pods do GKE:

1. Crie um cluster: crie um cluster com a API Gateway e o GKE Dataplane V2.
2. Reserve um endereço IP: decida se precisa de um endereço IP externo (acessível publicamente) ou interno (apenas no Google Cloud) e reserve-o. Escolha a mesma região que o seu cluster do GKE.
3. Crie um gateway: configure o objeto de gateway do Kubernetes que contém os seus endereços IP persistentes reservados e permite-lhe criar regras (GKEIPRoutes) sobre que pods no seu cluster podem usar esses endereços IP persistentes.
4. Crie ou identifique cargas de trabalho para endereços IP persistentes: se usar endereços IP persistentes numa rede adicional, prepare os pods para usar endereços IP persistentes ativando várias interfaces de rede e definindo a rede onde os endereços IP persistentes residem.
5. Crie o objeto GKEIPRoute para cargas de trabalho selecionadas: configure GKEIPRoute para atribuir o endereço IP persistente a um pod específico. Pode usar etiquetas para segmentar os agrupamentos certos e, opcionalmente, configurar a forma como o encaminhamento reage às alterações de agrupamentos.
6. Configure a deteção de aplicações: configure a sua aplicação no pod para usar ativamente o endereço IP persistente.
7. Monitorização: acompanhe o estado da sua entrada e dos GKEIPRouteobjetos para garantir que tudo está a funcionar conforme esperado.

Para implementar um endereço IP persistente para os pods do GKE, siga os passos abaixo:

Passo 1: crie uma API Gateway e um cluster do GKE com o GKE Dataplane V2 ativado

Para ativar as capacidades avançadas de encaminhamento de rede e gestão de endereços IP necessárias para implementar endereços IP persistentes em pods do GKE, tem de criar um cluster do GKE Dataplane V2 da seguinte forma:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --gateway-api=standard

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster.
• CLUSTER_VERSION: a versão do cluster.

Nota: se necessário, pode ativar a funcionalidade de várias redes.

Passo 2: configure endereços IP persistentes

Para estabelecer identidades de rede fiáveis para os seus pods e configurar endereços IP persistentes, tem de adquirir primeiro endereços IP persistentes. Pode escolher entre reservar endereços IP fornecidos pela Google ou usar os seus próprios (BYOIP).

Passo 2a: reserve endereços IP fornecidos pela Google

Para reservar endereços IP externos, execute o seguinte comando:

gcloud compute addresses create ADDRESS_NAME \
   --region=REGION

Substitua o seguinte:

• ADDRESS_NAME: o nome que quer associar a esta morada.

• REGION: a região onde quer reservar esta morada. Esta região deve ser a mesma região que o pod ao qual quer anexar o endereço IP.

  Nota: tem de especificar uma região quando reservar um endereço IP porque as regras de encaminhamento, que processam o encaminhamento de tráfego para endereços IP persistentes, são regionais. O seu endereço IP e cluster do GKE têm de estar na mesma região para que o encaminhamento funcione corretamente.

Para reservar endereços IP internos, execute o seguinte comando:

gcloud compute addresses create ADDRESS_NAME \
    --region REGION
    --subnet SUBNETWORK \
    --addresses IP_ADDRESS

Substitua o seguinte:

• ADDRESS_NAME: os nomes de uma ou mais moradas que quer reservar. No caso de vários endereços, especifique todos os endereços como uma lista, separados por espaços. Por exemplo, example-address-1 example-address-2 example-address-3
• REGION: a região deste pedido.
• SUBNETWORK: a sub-rede para este endereço IPv4 interno.

Para garantir que o tráfego é encaminhado corretamente na sua rede privada, os endereços IP internos têm de pertencer à sub-rede predefinida do cluster ou à sub-rede de rede adicional.

Para mais informações sobre endereços IP externos e internos ou para ver como reservar endereços através da consola, consulte os artigos Reserve um endereço IP externo estático e Reserve um endereço IP interno estático.

Passo 2b: traga os seus próprios endereços IP (BYOIP)

Pode usar os seus próprios endereços IP (BYOIP), em vez de usar os endereços IP fornecidos pela Google. O BYOIP é útil se precisar de endereços IP específicos para as suas aplicações ou se estiver a mover sistemas existentes para o Google Cloud. Para usar o BYOIP, a Google valida se é proprietário do intervalo de endereços IP e, depois de os endereços IP serem importados para o Google Cloud, pode atribuí-los como os endereços IP persistentes para os pods do GKE. Para mais informações, consulte o artigo Use os seus próprios endereços IP.

Passo 3: crie objetos Gateway

Os objetos Gateway contêm os endereços IP e definem que pods são elegíveis para os usar. Para controlar a forma como os endereços IP persistentes são atribuídos aos seus pods do GKE, vai usar objetos Gateway.

1. Crie um objeto Kubernetes Gateway da classe adequada:
   • gke-persistent-regional-external-managed para endereços IP externos (públicos).
   • 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.
2. Na secção de endereços do gateway, liste os endereços IP persistentes (fornecidos pela Google ou BYOIP) que este gateway gere.

3. Use a secção Listeners para determinar que Pods (e os respetivos objetos GKEIPRoute associados) podem potencialmente usar os endereços IP do Gateway. Listeners atuam como um filtro com base no espaço de nomes de GKEIPRoute onde existe um objeto GKEIPRoute.

   Pode escolher entre as seguintes opções de seleção do espaço de nomes do Kubernetes:

   • Todos os espaços de nomes: qualquer GKEIPRoute no cluster.
   • Seletor: GKEIPRoute nos espaços de nomes de GKEIPRoute que correspondem a uma etiqueta específica.
   • Mesmo espaço de nomes: apenas GKEIPRoutes no espaço de nomes de GKEIPRoute's igual ao do gateway.

O exemplo seguinte fornece acesso ao nível do cluster a endereços IP persistentes externos, o que permite que qualquer Pod os use potencialmente.

Guarde o seguinte manifesto de exemplo como allowed-pod-ips.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  namespace: default
  name: allowed-pod-ips
spec:
  gatewayClassName: gke-persistent-regional-external-managed

  listeners:
    - name: default
      port: 443
      protocol: none
      allowedRoutes:
        namespaces:
          from: All

  addresses:
    - value: "34.123.10.1/32"
      type: "gke.networking.io/cidr"
    - value: "34.123.10.2/32"
      type: "gke.networking.io/cidr"

where:

• addresses: lista todos os endereços IP cujas autorizações são geridas pelo gateway específico.
• listeners: usado para identificar os espaços de nomes a partir dos quais os objetos GKEIPRoute podem referenciar este Gateway.

Nota: um endereço IP persistente não usa os campos "porta" e "protocolo" na configuração do ouvinte. Isto deve-se ao facto de a regra de encaminhamento associada a um endereço IP persistente usar a definição L3_DEFAULT, que permite o tráfego em todas as portas TCP/UDP. Para mais detalhes sobre os protocolos de regras de encaminhamento, consulte Protocolos de regras de encaminhamento.

Aplique o manifesto ao cluster:

kubectl apply -f allowed-pod-ips.yaml

Nota: alterar a classe de gateway associada a um GKEIPRoute não é suportado. Não pode direcionar um GKEIPRoute para um novo gateway com uma classe diferente nem alterar a classe no gateway atual.

Passo 4: (opcional) crie ou identifique cargas de trabalho com redes adicionais para endereços IP persistentes

Se planeia usar os seus endereços IP persistentes com Pods que requerem conetividade a várias redes, pode configurar Pods de várias redes e criar objetos de rede que indicam as redes às quais o endereço IP persistente pertence.

Passo 5: crie o objeto GKEIPRoute para cargas de trabalho selecionadas

Para atribuir um endereço IP persistente a um Pod selecionado, crie um objeto GKEIPRoute.

Guarde o seguinte manifesto de exemplo como my-ip-route.yaml:

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: default
  name: my-ip-route
spec:
  parentRefs:
  - name: allowed-pod-ips
    namespace: default
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  network: default
  reactionMode: ReadyCondition
  podSelector:
    matchLabels:
      component: proxy
  nodeSelector: # Can only be specified when using fast failover Gateway Classes.
    matchLabels:
      component: proxy

where:

• parentRefs: aponta para o gateway a partir do qual são usados os endereços IP persistentes. Este campo é imutável.
• addresses: lista todos os endereços IP persistentes encaminhados para o pod identificado com podSelector. Este campo é mutável. Para IPv4, apenas são suportados endereços /32.
• podSelector: especifica etiquetas que identificam o pod para o qual os endereços IP persistentes são encaminhados. Este campo é mutável e aplica-se ao mesmo espaço de nomes em que GKEIPRoute está posicionado. Se selecionar vários pods, são tidos em consideração dois fatores adicionais: a hora de criação do pod (o GKE escolhe o mais recente) e a definição do campo reactionMode.
• reactionMode: especifica o comportamento desta funcionalidade quando um Pod específico (selecionado por podSelector) é criado ou eliminado. Este campo é opcional e a predefinição é ReadyCondition. O campo ReadyCondition é imutável. Pode definir o reactionMode para controlar o comportamento da funcionalidade quando os pods são criados, eliminados ou atualizados.
• network: aponta para a interface de rede num Pod para a qual os endereços IP persistentes são encaminhados. Este campo é opcional e tem como predefinição default. Tenha em atenção que, se usar a rede predefinida, network tem de estar definido como default. Se usar redes adicionais, defina a rede para o nome do objeto de rede que criou anteriormente. Este campo é imutável.
• nodeSelector: especifica as etiquetas dos nós a pré-configurar para uma comutação por falha rápida. Este campo tem de ser definido quando usar classes de gateway de comutação por falha rápida e pode selecionar um máximo de 64 nós. Tem de garantir que os pods com endereços IP persistentes estão agendados nestes nós, normalmente através da utilização do nodeSelector do pod.

Aplique o manifesto ao cluster:

kubectl apply -f my-ip-route.yaml

Atribua endereços IP persistentes a pods StatefulSet

Para atribuir um endereço IP persistente a um Pod de várias redes específico num StatefulSet, use o nome do anfitrião previsível do Pod e a etiquetagem automática do Kubernetes, conforme mostrado no exemplo seguinte:

Guarde o seguinte manifesto de exemplo como my-pod-ips.yaml:

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: proxy-ss-ns
  name: my-pod-ips
spec:
  parentRefs:
  - name: allowed-pod-ips
    namespace: default
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  - value: "34.123.10.2/32"
    type: "gke.networking.io/cidr"
  network: blue-network
  reactionMode: ReadyCondition
  podSelector:
    matchLabels:
      statefulset.kubernetes.io/pod-name: proxy-ss-1
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: proxy-ss-ns
  name: proxy-ss
spec:
  selector:
    matchLabels:
      component: proxy
  serviceName: "proxy"
  replicas: 3
  template:
    metadata:
      annotations:
        networking.gke.io/default-interface: 'eth0'
        networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
      labels:
        component: proxy
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Aplique o manifesto ao cluster (certifique-se de que tem uma rede denominada "blue-network"):

kubectl apply -f my-pod-ips.yaml

Atribua endereços IP persistentes a pods de implementação

Para atribuir um endereço IP persistente ao Pod mais recente numa implementação, aplique um GKEIPRoute com a seguinte configuração:

Guarde o seguinte manifesto de exemplo como my-pod-ips.yaml:

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: proxy-deploy-ns
  name: my-pod-ips
spec:
  parentRefs:
  - name: allowed-pod-ips
    namespace: default
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  - value: "34.123.10.2/32"
    type: "gke.networking.io/cidr"
  network: blue-network # point to the right network if you intend to use persistent-ip on additional networks
  reactionMode: ReadyCondition
  podSelector:
    matchLabels:
      component: proxy
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: proxy-deploy-ns
  name: proxy-deploy
spec:
  selector:
    matchLabels:
      component: proxy
  replicas: 4 # Latest Pod is used
  template:
    metadata:
      # annotations:  <- Remove these lines if the pods are not multi-nic pods
      #   networking.gke.io/default-interface: 'eth0'
      #   networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
      labels:
        component: proxy
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Aplique o manifesto ao cluster:

kubectl apply -f my-ip-route.yaml

Certifique-se de que tem uma rede denominada "blue-network" se estiver a usar redes adicionais.

Passo 6: use endereços IP persistentes no Pod

A atribuição de um endereço IP persistente a um pod do GKE através de um GKEIPRoute não torna automaticamente os endereços IP utilizáveis pela sua aplicação. Os endereços IP persistentes são processados ao nível do encaminhamento de rede, mas a configuração predefinida do seu pod não tem conhecimento disso. Tem de configurar a configuração da sua aplicação para reconhecer e usar o endereço no Pod. Para o fazer, o seu Pod requer autorizações de privilégios.

Para configurar a sua aplicação, considere as seguintes opções:

• net.ipv4.ip_nonlocal_bind: modifique uma definição do sistema para permitir que a sua aplicação use endereços IP não atribuídos diretamente à respetiva interface.
• ip address add: use este comando na lógica da sua aplicação para adicionar manualmente o endereço IP persistente a uma interface.
• Sockets brutos: para um controlo ainda maior, a sua aplicação pode interagir diretamente com a pilha de rede (avançado).
• Conjunto de endereços IP do espaço do utilizador: em casos especializados, uma aplicação separada pode ser executada no Pod para gerir o endereço IP (muito avançado).

Passo 7: ative o ARP para endereços IP persistentes (apenas na rede predefinida)

Para gerar pedidos e respostas do Protocolo de Resolução de Endereços (ARP) válidos e para estabelecer uma nova ligação a um Pod através de um endereço IP persistente na rede predefinida, tem de configurar a variável arp_announce.

Para definir a variável arp_announce, execute o seguinte comando no seu pod:

echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce

onde a variável arp_announce controla a forma como os anúncios de ARP são processados. Se o definir como "2", garante que os anúncios ARP são feitos para o endereço IP persistente, o que permite que outros dispositivos na rede saibam da nova associação.

Passo 8: use a comutação por falha rápida

Se usar endereços IP persistentes com comutação por falha rápida, pode direcionar temporariamente o tráfego para um pod emitindo um GARP (Gratuitous ARP) a partir desse pod. OGoogle Cloud respeita esse GARP durante aproximadamente 20 minutos. Durante este período, tem de atualizar a configuração do cluster. Para o fazer, no campo GKEIPRoutespec.podSelector, substitua as etiquetas do Pod antigo pelas etiquetas do novo Pod.

Personalize o comportamento do endereço IP persistente durante as alterações do pod

Esta secção descreve o comportamento do endereço IP persistente do pod do GKE quando o pod segmentado é criado ou eliminado. O controlador do GKE monitoriza os seus pods e a configuração GKEIPRoute. Quando deteta que está a ocorrer uma atualização, reatribui automaticamente o endereço IP persistente a um Pod adequado de acordo com o reactionMode escolhido.

Compreenda como a funcionalidade de endereço IP persistente processa automaticamente as alterações de pods e as opções de configuração disponíveis:

• Decida entre ReadyCondition ou Exists no campo reactionMode da configuração do GKEIPRoute. Considere as necessidades da sua aplicação relativamente à rapidez com que o endereço IP é atribuído em comparação com os requisitos de prontidão rigorosos.
• Se estiver a usar ReadyCondition para garantir a disponibilidade, certifique-se de que os seus pods implementaram corretamente as sondas de disponibilidade do Kubernetes. Caso contrário, o endereço IP persistente pode não funcionar conforme previsto.
• Recomendamos que monitorize o estado dos seus pods e o campo Conditions do objeto GKEIPRoute para garantir que o sistema está a funcionar corretamente. O estado true da condição Ready indica que o sistema está a funcionar corretamente.

Resolva problemas de comunicação com endereços IP persistentes para pods

Esta secção mostra como resolver problemas relacionados com endereços IP persistentes para pods.

NoPodsFound quando não são encontrados pods correspondentes

Sintoma

O objeto GKEIPRoute especifica um podSelector (um conjunto de etiquetas) para identificar os pods associados ao endereço IP persistente. O estado NoPodsFound indica que não existem pods nos espaços de nomes GKEIPRoute's segmentados que tenham as etiquetas correspondentes.

Potenciais causas

• Etiquetas incorretas: o Pod que pretende usar com o endereço IP persistente pode ter as etiquetas erradas ou não ter etiquetas.
• Não existem pods: se o reactionMode == Exists, verifique se o pod está atribuído a um nó verificando o campo pod.Spec.nodeName. Pode não haver nenhum Pod em execução no espaço de nomes GKEIPRoute's que corresponda ao seletor.
• Pod não pronto: se reactionMode == ReadyCondition, verifique se o estado do pod é READY. Mesmo que exista um Pod correspondente, se não estiver num Ready state, não pode publicar tráfego e, por isso, não é selecionado.

Resolução

1. Verifique as etiquetas: verifique novamente se as etiquetas no ficheiro GKEIPRouteXMLpodSelector correspondem às etiquetas que aplicou ao podcast pretendido.
2. Verifique a existência do pod: certifique-se de que existe realmente um pod com as etiquetas corretas nos espaços de nomes do GKEIPRoute especificados pelo Listeners do gateway. Se for reactionMode == Exists, verifique se o pod está atribuído a um nó verificando o campo pod.Spec.nodeName

3. Confirme a disponibilidade do agrupamento: se reactionMode == ReadyCondition, verifique se o estado do agrupamento é READY. Certifique-se de que o pod está no estado Ready através do seguinte comando:

   kubectl get pods -n <namespace>
   

   Os pods noutros estados (por exemplo, "Pendente", "Erro") não são selecionados.

4. Configure os seus Pods para responderem no endereço IP persistente atribuído.

Mutated quando foi encontrado um Pod correspondente e a programação do endereço IP persistente está em curso

Sintoma

O estado GKEIPRoute mostra "Mutated", o que indica que a configuração do endereço IP persistente para um pod correspondente está em curso.

Potencial causa:

Pode esperar o estado "Mutated" durante a configuração, uma vez que o sistema está a configurar o caminho de dados do GKE e os Google Cloud recursos para o endereço IP persistente.

Resolução:

1. Aguarde e tente novamente: na maioria dos casos, o processo de configuração é concluído automaticamente num curto período de tempo. Verifique o estado após a espera. Quando for bem-sucedida, a opção passa a Ready.
2. Investigue mais a fundo (se necessário): se o estado "Mutated" persistir durante um período prolongado, pode indicar um erro de configuração. Examine as outras condições de estado no seu GKEIPRoute:
   • Aceite: indica se a configuração do GKEIPRoute é válida.
   • DPV2Ready: indica se o caminho de dados no nó está programado corretamente.
   • GCPReady: indica se os recursos estão configurados conforme esperado. Google Cloud

Procure mensagens de erro nestas condições para ajudar a resolver o problema.

O GARP foi enviado, mas o Pod não está a receber tráfego

Sintoma

Enviou um GARP a partir de um novo Pod, mas o fluxo de tráfego permanece inalterado. O estado GKEIPRoute permanece Pronto e não indica um erro.

Potenciais causas

O pod não está num nó que corresponda ao nodeSelector no GKEIPRoute. O GARP usa um endereço IP que não está associado ao GKEIPRoute.

Resolução

• Valide o nó do pod: certifique-se de que o pod é executado num nó que corresponda ao nodeSelector na sua configuração GKEIPRoute. Se o Pod não estiver num nó correspondente, o nó pode não estar programado para o GKEIPRoute.
• Valide o endereço IP do GARP: certifique-se de que o endereço IP no GARP é um dos endereços IP especificados no campo de endereço do GKEIPRoute. Se o endereço IP não estiver associado ao GKEIPRoute, o mecanismo de comutação rápida por falha não é acionado.

O que se segue?

• Leia o artigo Acerca dos endereços IP persistentes para pods do GKE
• Leia o artigo Configure o suporte de várias redes para os Pods