Esta página descreve a implementação da API Kubernetes Gateway do Google Kubernetes Engine (GKE) através do GKE Gateway Controller.
Esta página destina-se a arquitetos da nuvem e especialistas em redes que concebem e arquitetam a rede da respetiva organização. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.
A API Gateway é uma norma de código aberto para redes de serviços. A API Gateway evolui o recurso Ingress e melhora-o das seguintes formas:
Orientada para funções: a API Gateway é composta por recursos da API que correspondem às funções organizacionais do operador do cluster, do programador e do fornecedor de infraestrutura. Isto permite que os operadores de clusters definam como a infraestrutura partilhada pode ser usada por muitas equipas de programadores diferentes e não coordenadas.
Portátil: a API Gateway é uma norma de código aberto com muitas implementações, o que permite que os conceitos e os recursos principais sejam consistentes nas implementações e nos ambientes, reduzindo a complexidade e aumentando a familiaridade do utilizador. O respetivo design usa o conceito de conformidade flexível, usando uma API principal altamente portátil (como o Ingress) que ainda tem a flexibilidade e a extensibilidade para suportar as capacidades nativas do ambiente e da implementação.
Expressivo: os recursos da API Gateway oferecem capacidades incorporadas para a correspondência baseada em cabeçalhos, a ponderação do tráfego e outras capacidades que só são possíveis no Ingress através de anotações personalizadas.
Recursos da API Gateway
A API Gateway é um modelo de recursos orientado para funções, concebido para arquitetos da nuvem e especialistas em redes que interagem com as redes do Kubernetes. Conforme mostrado no diagrama seguinte, este modelo permite que diferentes proprietários de serviços não coordenados partilhem a mesma infraestrutura de rede subjacente de forma segura, centralizando a política e o controlo para o administrador da plataforma.
A API Gateway contém os seguintes tipos de recursos:
- GatewayClass: define um recurso com âmbito de cluster que é um modelo para criar equilibradores de carga num cluster. O GKE fornece GatewayClasses que podem ser usadas em clusters do GKE.
- Gateway: define onde e como os balanceadores de carga ouvem o tráfego. Os operadores de clusters criam gateways nos respetivos clusters com base numa GatewayClass. O GKE cria balanceadores de carga que implementam a configuração definida no recurso Gateway.
- HTTPRoute: define regras específicas do protocolo para o encaminhamento de pedidos de um gateway para serviços Kubernetes. O GKE suporta HTTPRoutes para o encaminhamento de tráfego baseado em HTTP(S). Os programadores de aplicações criam HTTPRoutes para expor as respetivas aplicações HTTP através de gateways.
- Política: define um conjunto de características específicas da implementação de um recurso Gateway. Pode anexar uma política a um Gateway, a uma rota ou a um serviço Kubernetes.
- ReferenceGrant: permite referências entre espaços de nomes na API Gateway. Para fazer referência a um objeto fora do respetivo espaço de nomes, tem de criar um recurso ReferenceGrant.
GatewayClass
Uma GatewayClass é um recurso que define um modelo para balanceadores de carga HTTP(S) (camada 7) num cluster do Kubernetes. O GKE fornece GatewayClasses como recursos com âmbito de cluster. Os operadores de clusters especificam uma GatewayClass quando criam gateways nos respetivos clusters.
As diferentes GatewayClasses correspondem a diferentes Google Cloud equilibradores de carga. Quando cria um Gateway com base numa GatewayClass, é criado um balanceador de carga correspondente para implementar a configuração especificada.
Algumas GatewayClasses suportam o equilíbrio de carga de vários clusters.
A tabela seguinte apresenta as GatewayClasses disponíveis nos clusters do GKE e o respetivo tipo de equilibrador de carga subjacente. Para ver detalhes completos sobre as GatewayClasses, consulte as capacidades e as especificações da GatewayClass.
| Nome da GatewayClass | Descrição |
|---|---|
gke-l7-global-external-managed |
Balanceadores de carga de aplicações externos globais criados no balanceador de carga de aplicações externo global |
gke-l7-regional-external-managed |
Balanceadores de carga de aplicações externos regionais criados no balanceador de carga de aplicações externo regional |
gke-l7-rilb |
Balanceadores de carga de aplicações internos criados no balanceador de carga de aplicações interno |
gke-l7-gxlb |
Balanceadores de carga de aplicações externos globais criados no balanceador de carga de aplicações clássico |
gke-l7-cross-regional-internal-managed-mc |
Balanceadores de carga de aplicações internos multicluster de várias regiões criados no balanceador de carga de aplicações interno de várias regiões |
gke-l7-global-external-managed-mc |
Balanceadores de carga de aplicações externos globais de vários clusters criados no balanceador de carga de aplicações externo global |
gke-l7-regional-external-managed-mc |
Balanceadores de carga de aplicações externos regionais de vários clusters criados no balanceador de carga de aplicações externo regional |
gke-l7-rilb-mc |
Balanceadores de carga de aplicações internos de vários clusters criados no balanceador de carga de aplicações interno |
gke-l7-gxlb-mc |
Balanceadores de carga de aplicações externos globais de vários clusters criados no balanceador de carga de aplicações clássico |
gke-td |
Cloud Service Mesh em vários clusters |
asm-l7-gxlb |
Balanceadores de carga de aplicações externos globais criados no Cloud Service Mesh |
Cada GatewayClass está sujeita às limitações do balanceador de carga subjacente.
Gateway
Os operadores de clusters criam gateways para definir onde e como os balanceadores de carga ouvem o tráfego. Os gateways baseiam o respetivo comportamento (ou seja, como são implementados) na GatewayClass associada.
A especificação do gateway inclui a GatewayClass para o gateway, que portas e protocolos a ouvir, e que rotas podem ser associadas ao gateway. Um gateway seleciona rotas com base nos metadados de rotas, especificamente no tipo, no espaço de nomes e nas etiquetas dos recursos de rotas.
Para ver um exemplo de implementação de um gateway, consulte o artigo Implementar gateways.
Para ver um exemplo de implementação de um gateway de vários clusters, consulte o artigo Implementar gateways de vários clusters.
HTTPRoute
Uma HTTPRoute define como os pedidos HTTP e HTTPS recebidos por um Gateway são direcionados para os Serviços. Os programadores de aplicações criam HTTPRoutes para expor as respetivas aplicações através de gateways.
Uma HTTPRoute define a partir de que Gateways pode encaminhar tráfego, para que Services encaminhar e regras que definem a que tráfego a HTTPRoute corresponde. A associação de Gateway e Route é bidirecional, o que significa que ambos os recursos têm de se selecionar mutuamente para serem associados. As HTTPRoutes podem corresponder a pedidos com base nos detalhes no cabeçalho do pedido.
Política
Uma política define as caraterísticas de um recurso de gateway, normalmente específico da implementação, que os operadores de cluster podem anexar a um gateway, a uma rota ou a um serviço Kubernetes. Uma política define como a infraestrutura subjacente deve funcionar.Google Cloud
Normalmente, uma política está associada a um espaço de nomes e pode fazer referência a um recurso no mesmo espaço de nomes. O acesso é concedido através do RBAC. A natureza hierárquica da API Gateway permite-lhe anexar uma política a um recurso superior (gateway) num espaço de nomes e fazer com que todos os recursos abaixo em espaços de nomes diferentes recebam as caraterísticas dessa política.
O controlador do GKE Gateway suporta as seguintes políticas:
HealthCheckPolicy: define os parâmetros e o comportamento da verificação de funcionamento usada para verificar o estado de funcionamento dos pods de back-end.GCPGatewayPolicy: define parâmetros específicos da interface do Google Cloud balanceador de carga. Esta política é semelhante a umFrontendConfigpara um recurso Ingress.GCPBackendPolicy: define como os serviços de back-end do balanceador de carga devem distribuir o tráfego para os pontos finais. Esta política é semelhante a uma política deBackendConfigpara um recurso Ingress.GCPBackendPolicy: define como os serviços de back-end do balanceador de carga distribuem o tráfego para os back-ends. A políticaGCPBackendPolicysuporta o modo de equilíbrio de cargaCUSTOM_METRICS, que permite decisões de encaminhamento com base em métricas de aplicações definidas pelo utilizador que são comunicadas através dos relatórios de carga da ORCA.GCPTrafficDistributionPolicy: define como o tráfego é distribuído pelos pontos finais num back-end. Esta política é semelhante à forma como configuraria algoritmos de equilíbrio de carga específicos para o serviço de back-end referenciado por um recurso Ingress.
ReferenceGrant
ReferenceGrant permite que recursos como HTTPRoute ou Gateway referenciem serviços ou segredos de back-end localizados em diferentes espaços de nomes através de referências entre espaços de nomes. ReferenceGrant atua como um fornecedor de autorizações, especificando a que recursos (from) é permitido fazer referência a outros recursos (to). Para ativar referências entre espaços de nomes, precisa de um ReferenceGrant no espaço de nomes do recurso ao qual está a fazer referência.
No exemplo seguinte, o HTTPRoute no espaço de nomes frontend tem de
encaminhar o tráfego para um serviço no espaço de nomes backend. Cria um
ReferenceGrant no espaço de nomes backend onde:
- O campo
fromlista o espaço de nomes de origem e o tipo de recurso permitidos para fazer referências, ou seja, HTTPRoute no espaço de nomesfrontend. - O campo
toespecifica o tipo de recurso de destino que pode ser referenciado, ou seja, os serviços no espaço de nomesbackend.
apiVersion: networking.gke.io/v1beta1
kind: ReferenceGrant
metadata:
name: allow-frontend-to-access-backend
namespace: backend
spec:
from:
- group: gateway.networking.k8s.io
kind: HTTPRoute
namespace: frontend
to:
- group: ""
kind: Service
Se receber a mensagem de erro "No valid reference grant found" (Não foi encontrada nenhuma concessão de referência válida) no estado do gateway, verifique se os valores group, kind, namespace e name definidos nas secções from e to são válidos.
Padrões de utilização e propriedade do gateway
Os recursos Gateway e Route oferecem flexibilidade na forma como são detidos e implementados numa organização. Isto significa que um único equilibrador de carga pode ser implementado e gerido por uma equipa de infraestrutura, mas o encaminhamento num domínio ou caminho específico pode ser delegado a outra equipa noutro espaço de nomes do Kubernetes. O controlador do GKE Gateway suporta a utilização multi-inquilino de um balanceador de carga, partilhado entre namespaces, clusters e regiões. Os gateways também não têm de ser partilhados se for necessária uma propriedade mais distribuída. Seguem-se alguns dos padrões de utilização mais comuns para gateways no GKE.
Gateway autogerido
Um único proprietário pode implementar um Gateway e uma Route apenas para as respetivas aplicações e usá-los exclusivamente. Os gateways e os trajetos implementados desta forma são semelhantes ao Ingress. O diagrama seguinte mostra dois proprietários de serviços diferentes que implementam e gerem as suas próprias gateways. Semelhante ao Ingress, cada Gateway corresponde ao seu próprio endereço IP exclusivo e equilibrador de carga. O TLS, o encaminhamento e outras políticas são totalmente controlados pelo proprietário do serviço.
Este padrão de utilização é comum para o Ingress, mas é difícil de dimensionar em muitas equipas devido à falta de recursos partilhados. O modelo de recurso da API Gateway permite os seguintes padrões de utilização, que oferecem um espetro de opções para controlo e propriedade distribuídos.
Gateway gerido pela plataforma por espaço de nomes
A separação entre os recursos de gateway e de rota permite que os administradores da plataforma controlem os gateways em nome dos proprietários dos serviços. Os administradores da plataforma podem implementar um gateway por espaço de nomes ou equipa, concedendo a esse espaço de nomes acesso exclusivo à utilização do gateway. Isto dá ao proprietário do serviço controlo total sobre as regras de encaminhamento sem qualquer risco de conflito com outras equipas. Isto permite ao administrador da plataforma controlar aspetos como a atribuição de IP, a exposição de portas, os protocolos, os domínios e o TLS. Os administradores da plataforma também podem decidir que tipos de gateways estão disponíveis para as equipas, como gateways internos ou externos. Este padrão de utilização cria uma separação clara de responsabilidades entre diferentes funções.
O encaminhamento entre espaços de nomes permite que os trajetos se associem a gateways em limites de espaços de nomes. Os gateways podem restringir os Namespaces aos quais os trajetos podem ser anexados. Da mesma forma, os trajetos especificam os gateways aos quais se associam, mas só se podem associar a um gateway que tenha permitido o espaço de nomes do trajeto. Esta associação bidirecional oferece a cada lado controlos flexíveis que permitem esta diversidade de padrões de utilização.
No diagrama seguinte, o administrador da plataforma implementou um gateway para acesso exclusivo para cada espaço de nomes. Por exemplo, o store Gateway está configurado para que apenas as rotas do store Namespace possam ser anexadas ao mesmo. Cada gateway representa um endereço IP com equilíbrio de carga exclusivo e, por isso, permite que cada equipa implemente qualquer número de rotas em relação ao gateway para quaisquer domínios ou rotas que escolher.
Gateway partilhado por cluster
A partilha de gateways entre espaços de nomes oferece uma forma de propriedade ainda mais centralizada aos administradores da plataforma. Isto permite que diferentes proprietários de serviços, em execução em diferentes espaços de nomes, partilhem o mesmo endereço IP, domínio DNS, certificados ou caminhos para um encaminhamento detalhado entre serviços. As gateways fornecem controlo aos administradores da plataforma sobre os espaços de nomes que podem encaminhar para um domínio específico. Isto é semelhante ao exemplo anterior, exceto que os gateways permitem a associação de rotas a partir de vários espaços de nomes.
No diagrama seguinte, o administrador da plataforma implementou dois gateways no espaço de nomes infra. O gateway permite que as rotas dos espaços de nomes web e mobile sejam anexadas ao gateway.external As rotas do espaço de nomes accounts não podem usar o gateway external porque o espaço de nomes accounts destina-se apenas a serviços internos. O gateway internal permite que os clientes internos comuniquem de forma privada na VPC através de endereços IP privados.
O domínio m.example.com é delegado ao espaço de nomes mobile, o que permite aos proprietários de serviços móveis configurar as regras de encaminhamento de que necessitam no domínio m.example.com. Isto dá aos proprietários dos serviços um maior grau de controlo para introduzir novos pontos finais da API e controlar o tráfego sem pedir uma alteração aos administradores.
Gateway partilhado por frota
Usando Gateways de vários clusters,
um Gateway pode ser partilhado em Namespaces, clusters e
regiões. As grandes organizações com apps distribuídas geograficamente podem beneficiar
de gateways de vários clusters, uma vez que podem controlar detalhadamente o tráfego global
e delegar a propriedade do encaminhamento. Semelhante aos exemplos anteriores, um administrador da plataforma gere o gateway e delega o encaminhamento. A principal adição a este exemplo de utilização é que as rotas fazem referência a serviços de vários clusters, que são implementados em vários clusters. O tráfego pode ser encaminhado de forma explícita, o tráfego para store.example.com/us vai para os pods gke-us, ou de forma implícita, o tráfego para example.com/* é encaminhado para o cluster mais próximo do cliente. Esta flexibilidade permite que os proprietários de serviços definam a estratégia de encaminhamento ideal para a respetiva aplicação.
GKE Gateway Controller
O controlador do GKE Gateway é a implementação da Google da API Gateway para o Cloud Load Balancing. Semelhante ao controlador de entrada do GKE, o controlador do gateway monitoriza 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.
Existem duas versões do controlador do GKE Gateway:
- Cluster único: gere gateways de cluster único para um único cluster do GKE.
- Vários clusters: gere gateways de vários clusters para um ou mais clusters do GKE.
Ambos os controladores de gateway são controladores alojados pela Google que monitorizam a API Kubernetes para clusters do GKE. Ao contrário do controlador GKE Ingress, os controladores Gateway não estão alojados em planos de controlo do GKE nem no projeto do utilizador, o que lhes permite ser mais escaláveis e robustos. Ambos os controladores de gateway estão geralmente disponíveis (GA).
Os controladores da gateway em si não são um plano de dados de rede e não processam tráfego. Estão fora da banda do tráfego e gerem vários planos de dados que processam o tráfego. O diagrama seguinte mostra a arquitetura dos controladores do GKE Gateway de cluster único e de vários clusters. O controlador subjacente usado depende da GatewayClass do gateway implementado.
| Controlador | Controlador de gateway de cluster único | Controlador do gateway em vários clusters |
|---|---|---|
| Gerida por | Google Cloud | Google Cloud |
| Âmbito do cluster | Gateways de cluster único | Gateways em vários clusters |
| Localização da implementação | Implementado regionalmente na mesma região que o respetivo cluster do GKE. | Implementado globalmente em várias Google Cloud regiões. |
| Como ativar | Ativado por predefinição no GKE. | Ativado através da API Multi Cluster Ingress e do registo numa frota. Consulte o artigo Ativar gateways de vários clusters. |
| GatewayClasses suportadas |
|
Pode usar vários controladores de gateway, incluindo controladores não fornecidos pela Google, num cluster do GKE em simultâneo. Cada GatewayClass é suportada por um e apenas um controlador de gateway, o que permite usar o equilíbrio de carga de cluster único e de vários clusters em simultâneo.
Extensões de serviço
O controlador do GKE Gateway suporta extensões de serviço, que lhe permitem adicionar lógica personalizada ao Cloud Load Balancing.
O controlador do GKE Gateway suporta dois tipos de extensões:
- GCPTrafficExtension: esta extensão oferece uma forma de adicionar lógica personalizada ao Cloud Load Balancing. O serviço de extensão pode modificar os cabeçalhos e os payloads dos pedidos e das respostas sem afetar a escolha dos serviços de back-end nem quaisquer outras políticas de segurança associadas ao serviço de back-end.
- GCPRoutingExtension: esta extensão oferece uma forma de adicionar lógica personalizada ao Cloud Load Balancing para controlar para onde o tráfego é encaminhado para um determinado pedido.
Para mais informações sobre como configurar os controladores do GKE Gateway, consulte o artigo Personalize o tráfego do GKE Gateway com extensões de serviço.
Entrada e gateway
O Ingress e o Gateway são ambos padrões de código aberto para encaminhar tráfego, mas têm diferenças importantes.
Comparação entre o Ingress e o Gateway
O Gateway e o Ingress são ambos padrões de código aberto para encaminhar tráfego e podem ser usados em simultâneo sem conflitos. Ao longo do tempo, recomendamos que faça a transição para a utilização de recursos Gateway e Route devido às suas capacidades aumentadas. O Gateway foi concebido pela comunidade Kubernetes, com base nas lições aprendidas com o Ingress e os ecossistemas de malha de serviços. O Gateway é uma evolução do Ingress que cumpre a mesma função, fornecido como um superconjunto das capacidades do Ingress.
No GKE, todos os recursos Ingress são diretamente convertíveis em recursos Gateway e HTTPRoute. Um único Ingress corresponde a um Gateway (para configuração de front-end) e a um HTTPRoute (para configuração de encaminhamento). O exemplo seguinte mostra o aspeto da configuração correspondente de Gateway e HTTPRoute. Tenha em atenção que os recursos Gateway e HTTPRoute podem ser criados separadamente, também por utilizadores diferentes. As gateways podem ter muitos itinerários e um itinerário também pode ser anexado a mais do que uma gateway. As relações entre gateways e rotas são abordadas em Padrões de utilização de gateways.
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
Integrar a API Gateway com as malhas de serviço
Pode configurar uma malha de serviços na nuvem através da API Gateway. Isto permite comunicações de serviço a serviço, gestão de tráfego, balanceamento de carga global e aplicação de políticas de segurança para exemplos de utilização de malhas de serviços. Para obter informações completas sobre a utilização da Cloud Service Mesh com a API Gateway, incluindo guias de configuração de implementação, consulte o artigo Configurar com a vista geral da API Gateway.
Preços
Todos os recursos do Compute Engine implementados através dos controladores do gateway são cobrados ao projeto no qual os seus clusters do GKE residem. O controlador de gateway de cluster único é oferecido sem custo adicional como parte dos preços do GKE Standard e Autopilot. Os preços das gateways de vários clusters são descritos na página de preços da entrada e da gateway de vários clusters.
O que se segue?
- Saiba como configurar recursos do gateway através de políticas
- Saiba mais sobre a Implementação de gateways.
- Saiba como implementar gateways de vários clusters.
- Para obter informações completas sobre a utilização do Cloud Service Mesh com a API Gateway, consulte a vista geral do Cloud Service Mesh GKE service mesh.