Gateway

Autopilot Standard

Nesta página, você verá a implementação do Google Kubernetes Engine (GKE) da API Kubernetes Gateway usando o GKE Gateway Controller.

A API Gateway é um padrão de código aberto para redes de serviços. A API Gateway evolui o recurso de Entrada e o melhora das seguintes maneiras:

Orientado por papéis: o gateway é composto de recursos de API que correspondem aos papéis organizacionais "Operador do cluster", "Desenvolvedor" e "Provedor de infraestrutura". Isso permite que os operadores de cluster definam como a infraestrutura compartilhada pode ser usada por muitas equipes de desenvolvedores diferentes e sem coordenação.
Portabilidade: a API Gateway é um padrão de código aberto com muitas implementações. Ela foi projetada usando o conceito de conformidade flexível, que promove uma API de núcleo altamente portátil (como o Ingress), flexível, extensível e compatível com recursos nativos do ambiente e da implementação. Isso permite que os conceitos e recursos principais sejam consistentes em todas as implementações e ambientes, reduzindo a complexidade e aumentando a familiaridade do usuário.
Expressivo: os recursos da API Gateway oferecem funcionalidade integrada para correspondência baseada em cabeçalho, ponderação de tráfego e outros recursos que só são possíveis no Ingress com anotações personalizadas.

Recursos da API Gateway

A API Gateway é um modelo de recursos orientado por papéis, projetado para os perfis que interagem com a rede do Kubernetes. Conforme mostrado no diagrama a seguir, esse modelo permite que diferentes proprietários de serviços não coordenados compartilhem a mesma infraestrutura de rede subjacente de maneira a centralizar a política e o controle para o administrador da plataforma.

O GKE fornece classes de gateway. Operadores de cluster criam recursos de gateway com base nessas classes. Desenvolvedores de aplicativos criam recursos HTTPRoute vinculados a recursos de gateway. — **Figura:** visão geral da API Gateway

A API Gateway contém os seguintes tipos de recursos:

GatewayClass: define um recurso com escopo no cluster que é um modelo para criar balanceadores de carga em um cluster. O GKE fornece GatewayClasses que podem ser usadas em clusters do GKE.
Gateway: define onde e como os balanceadores de carga detectam tráfego. Os operadores de clusters criam gateways nos clusters com base em um GatewayClass. O GKE cria balanceadores de carga que implementam a configuração definida no recurso Gateway.
HTTPRoute: define regras específicas do protocolo para rotear solicitações de um gateway para serviços do Kubernetes. O GKE aceita HTTPRoutes para roteamento de tráfego baseado em HTTP(S). Os desenvolvedores de aplicativos criam HTTPRoutes para expor os aplicativos HTTP usando gateways.
Política: define um conjunto de características específicas da implementação de um recurso de gateway. É possível anexar uma política a um gateway, uma rota ou um serviço do Kubernetes.

GatewayClass

Um GatewayClass é um recurso que define um modelo para balanceadores de carga HTTP(S) (nível 7) em um cluster do Kubernetes. O GKE fornece GatewayClasses como recursos com escopo de cluster. Os operadores de cluster especificam um GatewayClass ao criar gateways nos clusters.

Os GatewayClasses diferentes correspondem a diferentes balanceadores de carga do Google Cloud. Ao criar um Gateway com base em um GatewayClass, um balanceador de carga correspondente é criado para implementar a configuração especificada.

Alguns GatewayClasses são compatíveis com balanceamento de carga de vários clusters.

Veja na tabela a seguir os GatewayClasses disponíveis nos clusters do GKE e o tipo correspondente de balanceador de carga subjacente. Para detalhes completos sobre os GatewayClasses, consulte os recursos e especificações do GatewayClass.

Nome da GatewayClass	Descrição
`gke-l7-global-external-managed`	Balanceadores de carga de aplicativo externos globais criados no balanceador de carga de aplicativo externo global
`gke-l7-regional-external-managed`	Balanceadores de carga de aplicativo externos regionais criados no balanceador de carga de aplicativo externo regional
`gke-l7-rilb`	Balanceadores de carga de aplicativo internos criados no balanceador de carga de aplicativo interno
`gke-l7-gxlb`	Balanceadores de carga de aplicativo externos globais criados no balanceador de carga de aplicativo clássico
`gke-l7-global-external-managed-mc`	Balanceadores de carga de aplicativo externos globais de vários clusters criados no balanceador de carga de aplicativo externo global
`gke-l7-regional-external-managed-mc`	Balanceadores de carga de aplicativo externos regionais de vários clusters criados no balanceador de carga de aplicativo externo global
`gke-l7-rilb-mc`	Balanceadores de carga de aplicativo internos de vários clusters criados no balanceador de carga de aplicativo interno
`gke-l7-gxlb-mc`	Balanceadores de carga de aplicativo externos globais de vários clusters criados no balanceador de carga de aplicativo clássico
`gke-td`	Malha de serviço do Cloud Service Mesh com vários clusters
`asm-l7-gxlb`	Balanceadores de carga de aplicativo externos globais criados no Cloud Service Mesh

Cada GatewayClass está sujeito às limitações do balanceador de carga subjacente.

Gateway

Os operadores de cluster criam gateways para definir onde e como os balanceadores de carga detectam tráfego. Os gateways usam o comportamento (ou seja, como são implementados) do GatewayClass associado.

A especificação do gateway inclui o GatewayClass do gateway, quais portas e protocolos detectar e que rotas podem se vincular ao gateway. Um gateway seleciona rotas com base nos metadados da rota. Especificamente o tipo, namespace e rótulos dos recursos de rota.

Para um exemplo de implantação de um gateway, consulte Como implantar gateways.

Para ver um exemplo de como implantar um gateway de vários clusters, consulte Como implantar gateways de vários clusters.

HTTPRoute

Um HTTPRoute define como as solicitações HTTP e HTTPS recebidas por um gateway são direcionadas para serviços. Os desenvolvedores de aplicativos criam HTTPRoutes para expor os aplicativos nos gateways.

Um HTTPRoute define de quais gateways é possível rotear o tráfego, os serviços ao qual rotear e as regras que definem o tráfego a que o HTTPRoute corresponde. A vinculação de gateway e rota é bidirecional. Isso significa que os dois recursos precisam selecionar um ao outro para serem vinculados. Os HTTPRoutes podem corresponder solicitações com base em detalhes no cabeçalho da solicitação.

Política

Uma política define as características de um recurso de gateway, geralmente específico da implementação, que os operadores de cluster podem anexar a um gateway, uma rota ou um serviço do Kubernetes. Uma política define como a infraestrutura subjacente do Google Cloud deve funcionar.

Uma política geralmente é anexada a um namespace e pode referenciar um recurso no mesmo namespace, e o acesso é concedido usando o RBAC. Com a natureza hierárquica da API Gateway, você anexa uma política a um recurso principal (gateway) em um namespace e faz com que todos os recursos inferiores nos namespaces diferentes recebam as características dessa política.

O controlador de gateway do GKE é compatível com as seguintes políticas:

HealthCheckPolicy: define os parâmetros e o comportamento da verificação de integridade usados para verificar o status de integridade dos pods de back-end.
GCPGatewayPolicy: define parâmetros específicos do front-end do balanceador de carga do Google Cloud. Isso é semelhante a um FrontendConfig de um recurso de Entrada.
GCPBackendPolicy: define como os serviços de back-end do balanceador de carga devem distribuir o tráfego para os endpoints. Isso é semelhante a um BackendConfig de um recurso de Entrada.

Padrões de uso e propriedade de gateway

Os recursos de gateway e rota fornecem flexibilidade na forma como pertencem e são implantados em uma organização. Isso significa que um único balanceador de carga pode ser implantado e gerenciado por uma equipe de infraestrutura, mas o roteamento em um domínio ou caminho específico pode ser delegado a outra equipe em outro namespace do Kubernetes. O controlador de gateway do GKE é compatível com o uso multilocatário de um balanceador de carga, compartilhado entre namespaces, clusters e regiões. Eles também não precisam ser compartilhados se for preciso ter mais propriedade distribuída. Veja a seguir alguns dos padrões de uso mais comuns para gateways no GKE.

Gateway autogerenciado

Um único proprietário pode implantar um gateway e uma rota apenas para os aplicativos e usá-los exclusivamente. Os gateways e as rotas implantados dessa maneira são semelhantes à Entrada. O diagrama a seguir mostra dois proprietários de serviço diferentes que implantam e gerenciam os próprios gateways. Assim como a Entrada, cada gateway corresponde ao próprio endereço IP exclusivo e balanceador de carga. O TLS, o roteamento e outras políticas são totalmente controladas pelo proprietário do serviço.

Um único proprietário pode ter controle total sobre o gateway e a rota.

Esse padrão de uso é comum para a Entrada, mas é um desafio escalonar para várias equipes devido à falta de recursos compartilhados. O modelo de recursos da API Gateway permite os seguintes padrões de uso, que fornecem um espectro de opções para controle e propriedade distribuídos.

Gateway gerenciado pela plataforma por namespace

A separação entre os recursos de gateway e rota permite que os administradores da plataforma controlem os gateways em nome dos proprietários do serviço. Os administradores da plataforma podem implantar um gateway por namespace ou por equipe, concedendo a esse acesso exclusivo de namespace para usar o gateway. Isso dá ao proprietário do serviço controle total sobre as regras de roteamento sem o risco de conflito com outras equipes. Isso permite que o administrador da plataforma controle aspectos como alocação de IP, exposição de porta, protocolos, domínios e TLS. Os administradores da plataforma também podem decidir quais tipos de gateways estão disponíveis para as equipes, como gateways internos ou externos/públicos. Esse padrão de uso cria uma separação clara de responsabilidades entre diferentes papéis.

O roteamento entre namespaces é o que permite que as rotas sejam anexadas a gateways em limites de namespace. Os gateways podem restringir de onde as rotas de namespaces podem ser anexadas. Da mesma forma, as rotas especificam os gateways a que estão anexados, mas só podem ser anexados a um gateway que tenha permitido o namespace da rota. Com esse anexo bidirecional, cada lado tem controles flexíveis que permitem essa diversidade de padrões de uso.

No diagrama a seguir, o administrador da plataforma implantou um gateway para acesso exclusivo a cada namespace. Por exemplo, o gateway store é configurado para que apenas rotas do namespace store sejam anexadas a ele. Cada gateway representa um endereço IP exclusivo e com carga balanceada. Assim, cada equipe implanta qualquer número de rotas no gateway para todos os domínios ou rotas que ele escolher.

Um gateway por namespace fornece acesso exclusivo a um gateway para esse namespace.

Gateway compartilhado por cluster

O compartilhamento de gateways entre namespaces oferece uma forma ainda mais centralizada de propriedade de administradores da plataforma. Isso permite que diferentes proprietários de serviços, em execução em namespaces diferentes, compartilhem o mesmo endereço IP, domínio DNS, certificados ou caminhos para roteamento refinado entre serviços. Os gateways oferecem controle aos administradores da plataforma pelos quais os namespaces podem rotear para um domínio específico. Isso é semelhante ao exemplo anterior, mas os gateways permitem o anexo de rota de mais de um namespace.

No diagrama a seguir, o administrador da plataforma implantou dois gateways no namespace infra. O gateway external permite que as rotas dos namespaces web e mobile sejam anexadas ao gateway. Rotas do namespace accounts não podem usar o Gateway external porque o namespace accounts é apenas para serviços internos. O gateway internal permite que clientes internos se comuniquem de maneira particular na VPC usando endereços IP particulares.

Um gateway por cluster permite que namespaces diferentes em um cluster compartilhem um único gateway

O domínio m.example.com é delegado ao namespace mobile, que permite aos proprietários de serviços móveis configurar regras de roteamento de que precisem no domínio m.example.com. Com isso, os proprietários de serviços têm mais controle para introduzir novos endpoints da API e controlar o tráfego sem solicitar uma alteração dos administradores.

Gateway compartilhado por frota

Com os gateways de vários clusters, um gateway pode ser compartilhado entre namespaces, clusters e regiões. Grandes organizações com aplicativos distribuídos geograficamente podem se beneficiar dos Gateways de vários clusters porque podem controlar de maneira granular o tráfego global e, ao mesmo tempo, delegar a propriedade do roteamento. Semelhante aos exemplos anteriores, um administrador de plataforma gerencia o gateway e delega o roteamento. O principal acontecimento desse caso de uso é que as rotas referem-se a serviços de vários clusters, que são implantados em clusters. O tráfego pode ser roteado de maneira explícita, o tráfego para store.example.com/us vai para os pods gke-us ou, de maneira implícita, o tráfego para example.com/* é roteado para o cluster mais próximo para o cliente. Essa flexibilidade permite que os proprietários de serviços definam a estratégia de roteamento ideal para os aplicativos.

Um gateway por frota fornece balanceamento de carga multirregional e de vários clusters.

GKE Gateway Controller

O GKE Gateway Controller é a implementação do Google da API Gateway para o Cloud Load Balancing. Semelhante ao controlador Ingress do GKE, o controlador de gateway observa uma API Kubernetes para recursos da API Gateway e reconcilia os recursos do Cloud Load Balancing para implementar o comportamento de rede especificado pelos recursos do gateway.

Há duas versões do GKE Gateway Controller:

Cluster único: gerencia Gateways de cluster único para um único cluster do GKE.
Vários clusters: gerencia gateways de vários clusters para um ou mais clusters do GKE.

Os dois são controladores hospedados pelo Google que observam a API Kubernetes para clusters do GKE. Ao contrário do controlador de Entrada do GKE, os controladores de Gateway não são hospedados em planos de controle do GKE ou no projeto do usuário, permitindo que eles sejam mais escalonáveis e robustos. Os dois controladores de gateway estão em disponibilidade geral.

Os próprios controladores de gateway não são um plano de dados de rede e não processam tráfego. Eles estão fora da banda do tráfego e gerenciam vários planos de dados que processam o tráfego. O diagrama a seguir mostra a arquitetura dos controladores do gateway do GKE de cluster único e de vários clusters. O controlador subjacente usado depende da GatewayClass do gateway implantado.

Os controladores de gateway de vários clusters e de cluster único implantam e gerenciam balanceadores de carga para o GKE, mas não processam o tráfego de rede por conta própria.

Controlador	Controlador de gateway de cluster único	Controlador do gateway de vários clusters
Gerenciado por	Google Cloud	Google Cloud
Escopo do cluster	Gateways de cluster único	Gateways de vários clusters
Local de implantação	Implantado regionalmente na mesma região do cluster do GKE.	Implantado globalmente em várias regiões do Google Cloud.
Como ativar	Ativado por padrão no GKE.	Ativado pela API de entrada de vários clusters e registrado em uma frota. Consulte Como ativar gateways de vários clusters.
GatewayClasses compatíveis	gke-l7-global-external-managed GA gke-l7-regional-external-managed GA gke-l7-rilb GA gke-l7-gxlb GA asm-l7-gxlb Pré-lançamento	gke-l7-global-external-managed-mc GA gke-l7-regional-external-managed-mc GA gke-l7-rilb-mc GA gke-l7-gxlb-mc GA gke-td Visualização

É possível usar vários controladores de gateway, incluindo controladores não fornecidos pelo Google, em um cluster do GKE simultaneamente. Cada GatewayClass é compatível com apenas um controlador de gateway, o que permite que o balanceamento de carga único e de vários clusters seja usado simultaneamente.

Entrada e gateway

Comparação entre o Ingress e o gateway

O Ingress e o gateway são padrões de código aberto para rotear tráfego. O gateway foi projetado pela comunidade do Kubernetes, aproveitando as lições aprendidas com o Ingress e os ecossistemas da malha de serviço. O Gateway é uma evolução do Ingress que fornece a mesma função, exibida como um superconjunto dos recursos do Ingress. Ambos podem ser usados simultaneamente sem conflito, mas, ao longo do tempo, os recursos de gateway e de rota fornecerão mais funcionalidades não disponíveis no Ingress. Isso incentiva os usuários a começarem a usar o gateway onde antes usavam o Ingress.

No GKE, todos os recursos da Entrada podem ser convertidos diretamente em recursos de gateway e HTTPRoute. Uma única entrada corresponde a um gateway (para configuração de front-end) e a um HTTPRoute (para configuração de roteamento). O exemplo a seguir mostra como é a configuração correspondente do gateway e HTTPRoute. Os recursos de gateway e HTTPRoute podem ser criados separadamente, também por usuários diferentes. Os gateways podem ter muitas rotas, e uma rota também pode ser anexada a mais de um gateway. As relações entre gateways e rotas são discutidas em Padrões de uso de gateway.

Entrada

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: site
            port:
              number: 80
      - pathType: Prefix
        path: /shop
        backend:
          service:
            name: store
            port:
              number: 80

Gateway

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

Rota

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: site
      port: 80
  - matches:
    - path:
        value: /shop
    backendRefs:
    - name: store
      port: 80

Como integrar a API Gateway com malhas de serviço

É possível configurar uma malha de serviço do Cloud Service Mesh usando a API Gateway. Isso permite comunicações de serviço a serviço, gerenciamento de tráfego, balanceamento de carga global e aplicação da política de segurança para casos de uso de malha de serviço. Para informações completas sobre o uso do Cloud Service Mesh com a API Gateway, incluindo guias de configuração da implantação, consulte Visão geral da malha de serviço do GKE do Cloud Service Mesh

Preços

Todos os recursos do Compute Engine implantados usando o controlador de gateway são cobrados no projeto em que os clusters do GKE residem. O controlador de gateway regional é oferecido sem custo adicional como parte do GKE Standard e Autopilot. Os preços dos gateways de vários clusters são descritos na página de preços de gateway e entrada de vários clusters.

A seguir

Saiba como Configurar recursos de gateway usando políticas
Saiba mais sobre Como implantar gateways.

Saiba mais sobre Como implantar gateways de vários clusters.

Para informações completas sobre como usar o Cloud Service Mesh com a API Gateway, consulte Visão geral da malha de serviço do GKE do Cloud Service Mesh.