Explore a documentação e os exemplos de utilização de redes do GKE

As redes no Google Kubernetes Engine (GKE) abrangem um vasto conjunto de conceitos, incluindo pods, serviços, DNS, equilíbrio de carga, segurança e gestão de endereços IP. Embora a documentação explique cada funcionalidade em detalhe, pode ser difícil saber por onde começar quando se depara com um problema do mundo real.

Este documento ajuda a navegar na documentação de rede do GKE associando desafios comuns às funcionalidades e secções que os resolvem. Cada exemplo de utilização apresenta um cenário, identifica o desafio e indica a documentação relevante. Este documento destina-se a arquitetos da nuvem, programadores e equipas de operações que têm de compreender e resolver desafios de rede comuns no GKE.

Se já conhece os desafios comuns de trabalho em rede e prefere aprofundar os detalhes técnicos, explore os seguintes recursos para criar os seus conhecimentos básicos sobre o trabalho em rede do GKE:

Exemplo de utilização: conceba a base de rede para o GKE

Neste exemplo de utilização, é um arquiteto de nuvem que precisa de criar uma base de rede escalável, segura e fiável para uma nova plataforma do GKE.

Desafio: impedir o esgotamento de endereços IP

Cenário: prevê-se que a complexidade e a utilização da sua aplicação aumentem, pelo que tem de criar uma rede que possa ser dimensionada para processar o aumento do tráfego e suportar o crescimento de pods, serviços e nós. Também tem de planear a atribuição de endereços IP para evitar o esgotamento

Solução: planeie o seu esquema de endereçamento IP para ter em conta o número de nós, pods e serviços de que vai precisar. Este plano inclui a escolha de intervalos de endereços IP adequados para cada um, tendo em conta a densidade de pods e evitando sobreposições com outras redes. Para mais informações, consulte o artigo Faça a gestão da migração de endereços IP no GKE.

Desafio: aplique a segurança de defesa em profundidade

Cenário: precisa de proteger os perímetros do cluster e aplicar a confiança zero, bem como regras de pod para pod.

Solução: use políticas de firewall para perímetros de cluster. Para mais informações, consulte o artigo Controle a comunicação entre Pods e Serviços através de políticas de rede.

Desafio: encaminhar tráfego para diferentes tipos de aplicações

Cenário: tem de se certificar de que outros serviços e utilizadores podem aceder a diferentes tipos de aplicações, como backends privados e aplicações HTTP(S) públicas.

Solução: use equilibradores de carga internos para back-ends privados. Para aplicações HTTP(S) públicas, use a API Ingress ou Gateway. Para mais informações, consulte o artigo Acerca do balanceamento de carga no GKE.

Desafio: use ferramentas de observabilidade para monitorizar e resolver problemas de cargas de trabalho

Cenário: tem de corrigir problemas com o tráfego de rede e compreender e monitorizar os fluxos de tráfego do GKE para diagnosticar problemas de forma eficaz.

Solução: implemente ferramentas de observabilidade para monitorizar e resolver problemas de tráfego de rede. Para mais informações, consulte o artigo Observe o seu tráfego através da observabilidade do GKE Dataplane V2.

Exemplo de utilização: exponha um novo microsserviço

Neste exemplo de utilização, é um programador que implementa um novo microsserviço no GKE. Tem de tornar o microsserviço acessível a outros serviços no cluster e, mais tarde, a clientes externos.

Desafio: fornecer um ponto final estável para a comunicação entre pods

Cenário: a sua aplicação precisa de Pods para comunicar com outros Pods, mas os endereços IP dinâmicos usados pelos Pods tornam esta comunicação não fiável.

Solução: crie um serviço do Kubernetes. Um serviço ClusterIP fornece um endereço IP virtual e um nome DNS estáveis, com equilíbrio de carga entre os pods. Para mais informações, consulte o artigo Compreenda os serviços Kubernetes.

Desafio: exponha o serviço para acesso externo

Cenário: o microsserviço tem de estar acessível a partir da Internet para uma demonstração.

Solução: crie um serviço LoadBalancer. O GKE aprovisiona um balanceador de carga de rede de encaminhamento regional externo com um endereço IP público. Para tráfego HTTP(S), considere usar a entrada ou o gateway, que oferecem funcionalidades da camada 7. Para mais informações, consulte o artigo Acerca dos serviços LoadBalancer.

Desafio: atribuir um URL permanente e intuitivo

Cenário: o serviço precisa de um nome de domínio estável para os clientes.

Solução: reserve um endereço IP estático e configure o DNS para um domínio personalizado. Para mais informações, consulte o artigo Configure nomes de domínios com endereços IP estáticos.

Desafio: faça a gestão do encaminhamento de tráfego avançado

Cenário: à medida que a sua aplicação cresce, precisa de um controlo mais sofisticado sobre como o tráfego é encaminhado. Por exemplo, pode ter de fazer o seguinte:

  • Alojamento de vários Websites (como api.example.com e shop.example.com) num único equilibrador de carga para poupar custos.
  • Encaminhar pedidos para diferentes serviços com base no caminho do URL (por exemplo, enviar / para a carga de trabalho de front-end e /api/v1 para a carga de trabalho de back-end).
  • Proteja a sua aplicação com HTTPS através da gestão de certificados TLS.
  • Implemente novas funcionalidades em segurança por fases através de lançamentos canary, em que envia uma pequena parte do tráfego para uma nova versão antes de uma implementação completa.

Solução: use a API Gateway. A implementação da API Gateway do GKE oferece uma forma poderosa e padronizada de gerir este tipo de tráfego norte-sul, suportando funcionalidades avançadas como o encaminhamento baseado em caminhos, a correspondência de cabeçalhos e a divisão de tráfego. Para mais informações, consulte o artigo Acerca da API Gateway.

Exemplo de utilização: escalar a descoberta de serviços para uma aplicação em crescimento

À medida que a sua aplicação baseada em microsserviços aumenta em termos de tráfego e complexidade, as consultas de DNS entre os serviços aumentam significativamente. Embora os programadores tenham de compreender como criar aplicações resilientes neste ambiente, as equipas de plataforma e operações são frequentemente responsáveis pela implementação de soluções de rede escaláveis.

Desafio: ativar a comunicação entre serviços

Cenário: os pods precisam de uma forma fiável de localizar outros serviços.

Solução: o GKE fornece um serviço DNS no cluster (como o kube-dns ou o Cloud DNS) que resolve nomes DNS estáveis para serviços, permitindo uma comunicação fiável entre pods. Para mais informações, consulte o artigo Deteção de serviços e DNS.

Desafio: melhorar o desempenho do DNS em grande escala

Cenário: o elevado volume de consultas causa atrasos na pesquisa.

Solução: ative a DNSCache local do nó. Cada nó armazena em cache as consultas de DNS localmente, o que reduz a latência. Para mais informações, consulte o artigo Configurar a vista geral da NodeLocal DNSCache.

Desafio: fornecer deteção de serviços na VPC

Cenário: as VMs do Compute Engine precisam de aceder a serviços no cluster.

Solução: faça a integração com o Cloud DNS para que os registos DNS do serviço sejam resolvidos na VPC. Para mais informações, consulte o artigo Use o Cloud DNS para o GKE.

Exemplo de utilização: proteger uma aplicação de vários níveis

Neste exemplo de utilização, faz parte de uma equipa de engenharia de plataformas que está a implementar uma aplicação de três camadas (interface, faturação e base de dados) e tem de aplicar a comunicação de confiança zero.

Desafio: aplique regras de trânsito rigorosas

Cenário: apenas serviços específicos devem comunicar entre si.

Solução: ative a aplicação de políticas de rede e aplique default deny políticas. Em seguida, defina regras de permissão explícitas (por exemplo, o front-end permite tráfego para a faturação, e a faturação permite tráfego para a base de dados). Para mais informações, consulte o artigo Configure políticas de rede para aplicações.

Desafio: audite e valide as políticas de rede

Cenário: a segurança requer um comprovativo de aplicação e visibilidade.

Solução: ative o registo da política de rede para registar as ligações permitidas e recusadas. Para mais informações, consulte o artigo Use o registo da política de rede.

Desafio: exponha um serviço de forma privada aos consumidores

Cenário: um serviço de back-end, como uma base de dados ou uma API, tem de estar acessível aos consumidores noutras redes VPC sem o expor à Internet pública nem lidar com as complexidades da interligação de VPCs.

Solução: use o Private Service Connect para publicar o serviço. Em seguida, os consumidores podem criar um ponto final do PSC na respetiva VPC para aceder ao seu serviço de forma privada e segura. Para mais informações, consulte o artigo Exponha serviços com o Private Service Connect.

Exemplo de utilização: alcançar uma elevada disponibilidade em vários clusters

Neste exemplo de utilização, é um EFS que executa cargas de trabalho para uma empresa de comércio eletrónico em vários clusters do GKE em diferentes regiões para melhorar a fiabilidade.

Desafio: ative a comunicação entre clusters

Cenário: os serviços num cluster têm de descobrir e chamar serviços noutro.

Solução: use os serviços de vários clusters (MCS) do GKE para criar um nome DNS global e encaminhar automaticamente o tráfego para back-ends em bom estado. Para mais informações, consulte os serviços multicluster.

Desafio: garantir uma comutação por falha resiliente

Cenário: se um serviço regional ficar indisponível, o tráfego tem de ser reencaminhado automaticamente.

Solução: o MCS oferece deteção de serviços com reconhecimento do estado de funcionamento, o que permite aos clientes resolver um único nome DNS para um back-end em bom estado de funcionamento no cluster disponível mais próximo. Esta abordagem permite uma comutação por falha resiliente. Para mais informações, consulte o artigo Serviços de vários clusters.

Exemplo de utilização: crie um ambiente GKE multi-inquilino seguro e eficiente

Como parte de uma equipa de engenharia de plataformas, fornece clusters do GKE a várias equipas de aplicações. Precisa de centralizar o controlo da rede, conservar os endereços IP e aplicar uma segurança rigorosa.

Desafio: centralizar o controlo da rede

Cenário: várias equipas de apps precisam dos seus próprios clusters, mas a rede tem de ser gerida centralmente.

Solução: use a VPC partilhada. Os recursos de rede residem num projeto anfitrião, mas os clusters de apps são executados em projetos de serviço. Para mais informações, consulte o artigo Configure clusters with Shared VPC.

Desafio: gerir de forma eficiente endereços IP limitados

Cenário: o espaço de endereços IP é limitado e tem de ser usado de forma eficiente.

Solução: ajuste o número máximo de agrupamentos por nó e, se necessário, use intervalos não RFC 1918 para endereços IP de agrupamentos. Para mais informações, consulte o artigo Faça a gestão da migração de endereços IP no GKE.

Desafio: use um plano de dados moderno e seguro, e aprovisione clusters com o novo plano de dados

Cenários:

  • A empresa requer um elevado desempenho e a aplicação de políticas incorporada para suportar cargas de trabalho exigentes e uma postura de segurança de confiança zero. Por exemplo, pode estar a executar microsserviços de grande escala sensíveis à latência da rede ou pode ter de aplicar limites de segurança rigorosos entre aplicações num cluster multi-inquilino para cumprir os requisitos de conformidade regulamentar.
  • Os clusters têm de ser configurados para usar um plano de dados de rede moderno para um elevado desempenho e segurança, e têm de ser implementados na estrutura de rede gerida centralmente da organização.

Solução: use o GKE Dataplane V2, que se baseia no eBPF e oferece um elevado desempenho e aplicação de políticas de rede incorporada. Para mais informações, consulte o artigo GKE Dataplane V2.

Exemplo de utilização: observe e resolva problemas de tráfego

Enquanto SRE, está a investigar o motivo pelo qual um serviço de pagamento não consegue estabelecer ligação a um serviço de pagamento.

Desafio: resolva problemas de conetividade

Cenário: os pacotes são ignorados, mas a causa não é clara.

Solução: ative a observabilidade do GKE Dataplane V2. As métricas, como hubble_drop_total, confirmam que os pacotes são recusados. Para mais informações, consulte o artigo Resolva problemas com o Hubble.

Desafio: identifique a causa principal dos pacotes ignorados

Cenário: depois de confirmar que os pacotes de rede estão a ser ignorados (por exemplo, usando hubble_drop_total), identifique que política de rede específica está a bloquear o tráfego entre serviços.

Solução: use a interface de linhas de comando ou a IU do Hubble para rastrear fluxos. A IU do Hubble oferece uma representação visual do tráfego, realçando a política configurada incorretamente que está a negar a ligação. Esta visualização permite à equipa identificar rapidamente a causa principal do problema e corrigir a política. Para mais informações, consulte o artigo Monitorize o seu tráfego com a observabilidade do GKE Dataplane V2.

Exemplo de utilização completo: implemente e dimensione uma aplicação de retalho segura

Neste cenário ponto a ponto, uma equipa de engenharia de plataformas cria uma plataforma GKE padronizada para várias equipas de aplicações. A equipa implementa e otimiza uma aplicação de retalho de três camadas (interface, faturação e base de dados). Este processo inclui proteger, dimensionar, melhorar o desempenho das cargas de trabalho de aprendizagem automática e integrar dispositivos de segurança avançados.

O diagrama seguinte ilustra a arquitetura ponto a ponto de uma aplicação de retalho segura de vários níveis implementada no GKE. A arquitetura evolui através de várias fases:

  • Fase 1: crie uma configuração fundamental através da VPC partilhada e do GKE Dataplane V2.
  • Fase 2: exponha a aplicação através da API Gateway e dos serviços de vários clusters para garantir a elevada disponibilidade.
  • Fase 3: acelere as tarefas de ML usando a gVNIC e a rede de nível 1.
  • Fase 4: implemente dispositivos de segurança avançados através do suporte de várias redes.
Diagrama que mostra a arquitetura ponto a ponto de uma aplicação de retalho segura de vários níveis no GKE, ilustrando os componentes de rede em seis fases de implementação e escalabilidade.
Figura 1. Uma arquitetura ponto a ponto para uma aplicação de retalho segura de vários níveis no GKE, que realça os principais componentes de rede usados em cada fase da implementação e do escalamento. Os detalhes de cada fase são descritos nas secções seguintes.

Fase 1: crie a base da plataforma

Desafio: centralizar a rede para várias equipas de aplicações e atribuir endereços IP suficientes para processar o dimensionamento.

Solução:

Fase 2: implemente e proteja a aplicação

Desafio: garantir uma comunicação fiável entre serviços e aplicar a segurança de confiança zero.

Solução:

Fase 3: exponha a aplicação e dimensione-a para o crescimento

Desafio: fornecer acesso externo e reduzir a latência de procura de DNS à medida que o tráfego aumenta.

Solução:

Fase 4: alcance uma elevada disponibilidade e resolva problemas

Desafio: garantir a comutação por falha regional e depurar o tráfego rejeitado.

Solução:

Fase 5: acelere as cargas de trabalho de aprendizagem automática

Desafio: eliminar gargalos de rede para a preparação de modelos baseados em GPU.

Solução:

  • Ative o gVNIC para uma largura de banda mais elevada.
  • Configure a rede de nível 1 em nós críticos para um débito máximo.

Fase 6: implemente dispositivos de segurança avançados

Desafio: implemente uma firewall e um IDS de terceiros com gestão e tráfego do plano de dados separados com uma latência ultrabaixa.

Solução:

O que se segue?