Gateway

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.

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.

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.

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.

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.

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.

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.

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.

GKE Gateway Controller

O controlador de gateway de cluster único do GKE observa uma API Kubernetes em busca de recursos da API Gateway e reconcilia os recursos do Cloud Load Balancing para implementar o comportamento de rede especificado pelos recursos do Gateway.

O controlador de Gateway de cluster único não é um plano de dados de rede e não processa nenhum tráfego.

No diagrama a seguir, mostramos a arquitetura do controlador de Gateway do GKE de cluster único. O controlador subjacente usado depende da GatewayClass do gateway implantado.

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.

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

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

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

A seguir

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