Some or all of the information on this page might not apply to Trusted Cloud by S3NS. See Differences from Google Cloud for more details.

Esta página foi traduzida pela API Cloud Translation.

Implementar gateways

Autopilot Padrão

Esta página descreve como implementar recursos Gateway do Kubernetes para o tráfego de entrada de balanceamento de carga para um único cluster do Google Kubernetes Engine (GKE).

Para implementar gateways para equilibrar a carga do tráfego de entrada em vários clusters (ou frota), consulte o artigo Implementar gateways de vários clusters.

Para configurações de Gateway mais específicas, como o encaminhamento entre espaços de nomes e a divisão do tráfego HTTP, consulte os guias do utilizador da API Gateway.

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 gcloud components update para obter a versão mais recente.
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.

Certifique-se de que tem um cluster do Autopilot ou Standard existente. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.

Requisitos do GKE Gateway Controller

A API Gateway é suportada apenas em clusters nativos de VPC.
Se estiver a usar as GatewayClasses internas, tem de ativar uma sub-rede apenas de proxy.
O seu cluster tem de ter o suplemento HttpLoadBalancing ativado.
Se estiver a usar o Istio, tem de atualizar o Istio para uma das seguintes versões:
- 1.15.2 ou posterior
- 1.14.5 ou posterior
- 1.13.9 ou posterior.
Se estiver a usar a VPC partilhada, no projeto anfitrião, tem de atribuir a função Compute Network User à conta de serviço do GKE para o projeto de serviço.

Restrições e limitações

Quando usar o GKE Gateway, compreenda as seguintes limitações e restrições:

As GKE GatewayClasses suportam diferentes capacidades consoante o equilibrador de carga que usam. Para saber mais sobre as diferentes funcionalidades suportadas por cada GatewayClass, consulte Capacidades da GatewayClass.

Prática recomendada:
Para um desempenho ideal, limite o número de gateways a um máximo de 100. Exceder este limite pode afetar o desempenho ou resultar num aumento da latência.
Não pode usar um FrontendConfig ou um BackendConfig para configurar um gateway. Tem de usar uma Política.
O GKE Gateway tem um comportamento diferente do Ingress, uma vez que o Gateway não infere parâmetros de verificação de estado. Se o seu serviço não devolver 200 para pedidos a GET / ou tiver outras verificações de prontidão do pod ajustadas, tem de configurar uma HealthCheckPolicy para o seu serviço.
Não pode especificar um número de porta diretamente no nome de anfitrião (por exemplo, web.example.com:80) para o encaminhamento de tráfego.
Pode ver os recursos do balanceador de carga que o GKE cria para gateways na consola Trusted Cloud , mas estes recursos não fazem referência ao gateway nem ao cluster do GKE ao qual estão anexados.
Não pode gerar automaticamente um certificado SSL gerido pela Google com gateways, mas pode criar e referenciar manualmente um certificado SSL gerido pela Google. Para mais informações, consulte o artigo Proteja um gateway.
HTTPRoute é o único tipo de rota suportado. TCPRoutes, UDPRoutes e TLSRoutes não são suportados. Para ver uma lista dos campos suportados pelo controlador do GKE Gateway, consulte as capacidades da GatewayClass.
Os cabeçalhos de pedidos e respostas personalizados com redirecionamentos de gateway ou de caminho e reescritas de URLs com gateway só estão disponíveis na versão 1.27 ou posterior do GKE.
Para cabeçalhos de pedidos e respostas personalizados com redirecionamentos de gateway e de caminho, e reescritas de URLs com gateway, a GatewayClass gke-l7-gxlb não é suportada.
Quando configurar cabeçalhos de pedidos e respostas personalizados de HTTPRoute, as seguintes Trusted Cloud variáveis não são suportadas:
- cdn_cache_id (O Cloud CDN não é suportado com o GKE Gateway)
- cdn_cache_status (O Cloud CDN não é suportado com o GKE Gateway)
- origin_request_header (As políticas de CORS não são suportadas com o GKE Gateway)
O GKE Gateway não suporta a funcionalidade de equilíbrio de carga do Cloud CDN.
Os cabeçalhos personalizados de TLS mútuo não são suportados (o mTLS com o GKE Gateway não é suportado)
Trusted Cloud by S3NS As limitações do balanceador de carga de aplicações clássico aplicam-se ao GKE Gateway. Além disso, não pode configurar um cabeçalho de resposta do anfitrião personalizado no serviço de back-end.
Os redirecionamentos de caminhos e as reescritas de URLs são mutuamente exclusivos. Não pode usar ambos os filtros em simultâneo nas mesmas regras.
O redirecionamento de tráfego para uma porta diferente não é suportado com o Cloud Load Balancing. Para ver a lista de campos suportados pelo controlador do GKE Gateway, consulte as capacidades da GatewayClass.
O GKE Gateway não suporta carateres universais, expressões regulares nem URLs dinâmicos.
Se especificar um gateway com uma classe de gateway externo regional, o controlador aprovisiona um endereço IP interno em vez do endereço externo. Para saber como usar um endereço com nome com o Application Load Balancer externo regional, consulte o artigo Implemente um gateway externo regional.
O gateway usa NEGs autónomos para o aprovisionamento de grupos de pontos finais da rede. Para garantir que o controlador do Gateway reconcilia corretamente a configuração do equilibrador de carga, não pode modificar a anotação cloud.google.com/neg para um serviço que faça parte do Gateway.
O GKE Gateway não suporta a referência a um serviço que também seja referenciado por um GKE Ingress.
Quando um Gateway está configurado para aprovisionar um endereço IP, não é suportada a alteração do Gateway.spec.gatewayClass. Para garantir que o controlador de gateway reconcilia corretamente o equilibrador de carga, elimine o gateway existente e volte a implementar o manifesto com o valor gatewayClass atualizado.
A anotação networking.gke.io/app-protocols não é suportada. Em alternativa, use o campo appProtocol para alcançar o mesmo resultado.
Se usar o GKE Gateway com o external-dns e o estado de saúde do Gateway for mau, por predefinição, todos os registos DNS associados ao Gateway são eliminados das suas zonas DNS.

Prática recomendada:
Quando executar o external-dns, defina o sinalizador policy=upsert-only. Esta configuração ajuda a evitar a eliminação de registos DNS existentes.
Se uma porta for removida de um Service que o GKE Gateway referencie através de uma rota, a anotação Standalone NEG no serviço também tem de atualizar o controlador Standalone NEG no serviço para remover essa porta. Caso contrário, o controlador do NEG acaba por parar de sincronizar os pontos finais do pod para este serviço. Para mais detalhes, consulte o artigo O controlador NEG deixa de gerir os pontos finais quando a porta é removida do serviço.
As implementações que usam gateways de vários clusters (MCG) que usam clusters zonais são suscetíveis a interrupções do serviço durante as atualizações de clusters. Este problema ocorre porque um mecanismo de deteção do grupo de pontos finais de rede (NEG) antigo pode comunicar incorretamente zero back-ends quando o plano de controlo do cluster zonal está temporariamente indisponível. Está em curso uma correção a longo prazo. Para evitar este único ponto de falha, use clusters do GKE regionais com o MCG.

Ative a API Gateway no seu cluster

Antes de usar recursos de gateway no GKE, o cluster tem de ter a API Gateway ativada.

Antes de atualizar um cluster do GKE existente para ativar a API Gateway, certifique-se de que os requisitos mínimos são cumpridos antes de continuar com a atualização.

Para ativar a API Gateway num cluster do GKE existente (Autopilot ou Standard), use o seguinte comando. Esta operação pode demorar até 45 minutos para que o cluster reconcilie e instale os CRDs.

gcloud container clusters update CLUSTER_NAME \
    --location=CLUSTER_LOCATION\
    --gateway-api=standard

Substitua o seguinte:

CLUSTER_NAME: o nome do cluster existente.
CLUSTER_LOCATION: a região ou zona do Compute Engine do cluster.

A flag --gateway-api=standard indica ao GKE que instale as CRDs v1beta1 com o cluster.

Valide o seu cluster

Depois de criar ou atualizar o cluster, o controlador do GKE Gateway instala automaticamente GatewayClasses. Pode demorar alguns minutos para que o controlador reconheça os CRDs e instale as GatewayClasses.

Confirme que a API Gateway está ativada no plano de controlo do GKE:

gcloud container clusters describe CLUSTER_NAME \
  --location=CLUSTER_LOCATION \
  --format json

O resultado é semelhante ao seguinte. Se este resultado estiver vazio, volte a executar o comando de atualização do cluster.

"networkConfig": {
  ...
  "gatewayApiConfig": {
    "channel": "CHANNEL_STANDARD"
  },
  ...
},

Confirme se as GatewayClasses estão instaladas no cluster:

kubectl get gatewayclass

O resultado é semelhante ao seguinte:

NAME                             CONTROLLER                  ACCEPTED   AGE
gke-l7-global-external-managed   networking.gke.io/gateway   True       16h
gke-l7-regional-external-managed networking.gke.io/gateway   True       16h
gke-l7-gxlb                      networking.gke.io/gateway   True       16h
gke-l7-rilb                      networking.gke.io/gateway   True       16h

Para compreender as capacidades de cada GatewayClass, consulte o artigo Capacidades da GatewayClass.

Apenas as GatewayClasses de cluster único são instaladas automaticamente. Para instalar e usar as GatewayClasses de vários clusters para o balanceamento de carga de vários clusters interno e externo, consulte Ativar gateways de vários clusters.

Implemente um gateway interno

Um gateway interno expõe aplicações que só são acessíveis a partir da VPC ou das redes ligadas à VPC.

Implemente um gateway interno regional

O exemplo seguinte mostra como implementar um gateway interno regional que permite uma comunicação eficiente e segura entre serviços numa região geográfica específica.

Configure uma sub-rede só de proxy

Tem de configurar uma sub-rede apenas de proxy antes de criar um gateway que use um Application Load Balancer interno. Cada região de uma VPC na qual usa equilibradores de carga de aplicações internos tem de ter uma sub-rede apenas de proxy. Esta sub-rede fornece endereços IP internos aos proxies do balanceador de carga.

Crie uma sub-rede só de proxy:
```
gcloud compute networks subnets create SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE
```
Substitua o seguinte:
- SUBNET_NAME: o nome da sub-rede só de proxy.
- COMPUTE_REGION: a região da sub-rede só de proxy.
- VPC_NETWORK_NAME: o nome da rede VPC na qual cria esta sub-rede só de proxy. Certifique-se de que é a mesma rede VPC onde reside o cluster do GKE e onde implementa o gateway. Isto é importante para uma comunicação perfeita entre o balanceador de carga e os seus serviços de back-end.
- CIDR_RANGE: o intervalo de endereços IP principal da sub-rede. Tem de usar uma máscara de sub-rede não superior a /26 para que estejam disponíveis, pelo menos, 64 endereços IP para proxies na região. A máscara de sub-rede recomendada é /23.

Valide a sua sub-rede apenas de proxy:

gcloud compute networks subnets describe SUBNET_NAME \
    --region=COMPUTE_REGION

O resultado é semelhante ao seguinte:

...
gatewayAddress: 10.1.1.1
ipCidrRange: 10.1.1.0/24
kind: compute#subnetwork
name: proxy-subnet
network: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/default
privateIpGoogleAccess: false
privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
purpose: REGIONAL_MANAGED_PROXY
region: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION
role: ACTIVE
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION/subnetworks/proxy-subnet
state: READY

Crie um gateway

Um recurso Gateway representa um plano de dados que encaminha o tráfego no Kubernetes. Um gateway pode representar muitos tipos diferentes de equilíbrio de carga e encaminhamento, dependendo da GatewayClass da qual deriva. Para saber mais acerca do recurso Gateway, consulte a descrição do recurso Gateway ou a especificação da API.

Neste caso, o administrador do cluster do GKE quer criar um gateway que possa ser usado por diferentes equipas para expor as respetivas aplicações internamente. O administrador implementa o gateway e as equipas de aplicações implementam as respetivas rotas de forma independente e associam-nas a este gateway.

Guarde o seguinte manifesto do gateway num ficheiro com o nome gateway.yaml:
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
   name: internal-http
spec:
  # Specify an existing GatewayClass.
  gatewayClassName: gke-l7-rilb
  listeners:
  # Listen for HTTP traffic on port 80.
  - name: http
    protocol: HTTP
    port: 80
```
Este manifesto inclui os seguintes campos:
- gatewayClassName: gke-l7-rilb: especifica a GatewayClass da qual este Gateway é derivado. gke-l7-rilb corresponde ao balanceador de carga de aplicações interno.
- port: 80: especifica que o gateway expõe apenas a porta 80 para escutar o tráfego HTTP.
Este gateway está configurado para processar tráfego HTTP apenas na porta 80. Não suporta HTTPS (porta 443) por predefinição e, se tentar estabelecer ligação através de HTTPS, o pedido pode falhar.
Implemente o Gateway no cluster:
```
kubectl apply -f gateway.yaml
```

Valide se o gateway foi implementado corretamente. A implementação de todos os recursos pode demorar alguns minutos.

kubectl describe gateways.gateway.networking.k8s.io internal-http

O resultado é semelhante ao seguinte:

Name:         internal-http
Namespace:    default
Spec:
  Gateway Class Name:  gke-l7-rilb
  Listeners:
    Allowed Routes:
      Kinds:
        Group:  gateway.networking.k8s.io
        Kind:   HTTPRoute
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
 Status:
   Addresses:
     Type:   IPAddress
     Value:  192.168.1.14
   Conditions:
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
     Observed Generation:   1
     Reason:                Scheduled
     Status:                True
     Type:                  Scheduled
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Accepted
     Status:                True
     Type:                  Accepted
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Programmed
     Status:                True # Indicates that the Gateway is ready.
     Type:                  Programmed
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:               The OSS Gateway API has altered the "Ready" condition semantics and reserved it for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
     Observed Generation:   1
     Reason:                Ready
     Status:                True
     Type:                  Ready
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Healthy
     Status:                True
     Type:                  networking.gke.io/GatewayHealthy
Events:
  Type    Reason  Age                From                       Message
  ----    ------  ----               ----                       -------
  Normal  ADD     92s                networking.gke.io/gateway  test/internal-http
  Normal  UPDATE  45s (x3 over 91s)  networking.gke.io/gateway  test/internal-http
  Normal  SYNC    45s                networking.gke.io/gateway  SYNC on test/internal-http was a success

Neste resultado, o estado de True para a condição Programmed indica que o gateway está pronto.

Neste ponto, existe um gateway implementado no seu cluster que aprovisionou um balanceador de carga e um endereço IP. No entanto, o gateway não tem rotas e, por isso, não sabe como deve enviar tráfego para os back-ends. Sem rotas, todo o tráfego é encaminhado para um back-end predefinido, que devolve um erro HTTP 404. Em seguida, implementa uma aplicação e rotas, que indicam ao gateway como aceder aos back-ends da aplicação.

Implemente as aplicações de demonstração

As equipas de aplicações podem implementar as respetivas aplicações e rotas independentemente da implementação de gateways. Em alguns casos, a equipa de aplicações também pode querer ser proprietária do gateway e implementá-lo como um recurso dedicado às respetivas aplicações. Consulte a associação de trajetos para diferentes modelos de propriedade de gateways e trajetos. No entanto, neste exemplo, a equipa da loja implementa a respetiva aplicação e uma HTTPRoute associada para expor a app através do gateway criado na secção anterior.internal-http

O recurso HTTPRoute tem muitos campos configuráveis para a correspondência de tráfego. Para uma explicação dos campos de HTTPRoute, consulte a especificação da API.

Implemente a aplicação de loja (implementações store-v1, store-v2 e store-german) no seu cluster:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
```
Isto cria três implementações e três serviços denominados store-v1, store-v2 e store-german.

Valide se a aplicação foi implementada com êxito:

kubectl get pod

O resultado é semelhante ao seguinte após a execução da aplicação:

NAME                        READY   STATUS    RESTARTS   AGE
store-german-66dcb75977-5gr2n   1/1     Running   0          38s
store-v1-65b47557df-jkjbm       1/1     Running   0          14m
store-v2-6856f59f7f-sq889       1/1     Running   0          14m

Valide se os serviços foram implementados:

kubectl get service

A saída mostra um serviço para cada implementação da loja:

NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s

Implemente o HTTPRoute

Os recursos de Route definem regras específicas do protocolo para mapear o tráfego de um Gateway para back-ends do Kubernetes. O recurso HTTPRoute faz a correspondência e a filtragem do tráfego HTTP e HTTPS, e é suportado por todas as gke-l7GatewayClasses.

Nesta secção, implementa um HTTPRoute, que programa o gateway com as regras de encaminhamento necessárias para alcançar a sua aplicação de loja.

Guarde o manifesto HTTPRoute seguinte num ficheiro denominado store-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store
spec:
  # Attach the HTTPRoute to a Gateway.
  parentRefs:
  - kind: Gateway
    name: internal-http
  # Route requests that have `store.example.com` in the Host header.
  hostnames:
  - "store.example.com"
  rules:
  # Send requests with the `env: canary` header to the `store-v2` Service.
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  # Send requests with `/de` in the path to the `store-german` Service.
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080
  # Send unmatched requests to the store-v1 Service.
  - backendRefs:
    - name: store-v1
      port: 8080

Implemente o HTTProute no seu cluster:
```
kubectl apply -f store-route.yaml
```
A store HTTPRoute está associada ao internal-http Gateway através da propriedade parentRefs. Estas regras de encaminhamento são configuradas no equilibrador de carga subjacente, conforme neste diagrama:

Estas regras de encaminhamento processam o tráfego HTTP da seguinte forma:
- O tráfego para store.example.com/de vai para o serviço store-german.
- O tráfego para store.example.com com o cabeçalho HTTP "env: canary" é encaminhado para o serviço store-v2.
- O tráfego restante para store.example.com é direcionado para o serviço store-v1.

Verifique se o HTTPRoute foi implementado:

kubectl describe httproute store

O resultado é semelhante ao seguinte:

Name:         store
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         HTTPRoute
# Multiple lines are omitted here.
Spec:
  Hostnames:
    store.example.com
  Parent Refs:
    Group:  gateway.networking.k8s.io
    Kind:   Gateway
    Name:   internal-http
  Rules:
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v1
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v2
      Port:    8080
      Weight:  1
    Matches:
      Headers:
        Name:   env
        Type:   Exact
        Value:  canary
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-german
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /de
Status:
  Parents:
    Conditions:
      Last Transition Time:  2022-11-01T04:18:52Z
      Message:
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2022-11-01T04:18:52Z
      Message:
      Reason:                ReconciliationSucceeded
      Status:                True
      Type:                  Reconciled
    Controller Name:         networking.gke.io/gateway
    Parent Ref:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   internal-http
Events:
  Type    Reason  Age                From                   Message
  ----    ------  ----               ----                   -------
  Normal  ADD     24m                sc-gateway-controller  default/store
  Normal  SYNC    16m (x4 over 23m)  sc-gateway-controller  Bind of HTTPRoute "default/store" to ParentRef {Group:       gateway.networking.k8s.io",
  # Multiple lines are omitted here.

Verifique se o HTTPRoute está associado ao Gateway:

kubectl describe gateway

O resultado é semelhante ao seguinte:

Name:         internal-http
Namespace:    default
Labels:       <none>
<...>
Status:
  Addresses:
    Type:   IPAddress
    Value:  10.128.15.203
  Conditions:
    Last Transition Time:  2022-11-01T03:47:01Z
    Message:
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2022-11-01T03:47:01Z
    Message:
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2022-11-01T03:47:01Z
      Message:
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    http
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
      <...>

Envie tráfego para a sua aplicação

Agora que o gateway, a rota e a aplicação estão implementados no cluster, pode passar tráfego para a aplicação. O gateway está configurado para publicar tráfego HTTP apenas na porta 80. Os pedidos feitos com HTTPS podem falhar, a menos que o TLS tenha sido configurado separadamente.

Obtenha o endereço IP do gateway para poder enviar tráfego para a sua aplicação:
```
kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}"
```
O resultado é um endereço IP.
Envie tráfego para este endereço IP a partir da shell numa instância de máquina virtual (VM) com conetividade ao cluster. Pode criar uma VM para este fim. Isto é necessário porque o gateway tem um endereço IP interno e só é acessível a partir da sua rede VPC. Uma vez que o internal-http é um equilibrador de carga regional, o shell do cliente tem de estar na mesma região que o cluster do GKE.

Fazer um pedido a store.example.com:
```
curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
```
Substitua GATEWAY_IP_ADDRESS pelo endereço IP do passo anterior.

O resultado da app de demonstração mostra informações sobre a localização onde a app está a ser executada:
```
{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v1-84b47c7f58-pmgmk",
  "pod_name_emoji": "💇🏼‍♀️",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-10-25T13:31:17",
  "zone": "ZONE_NAME"
}
```

Teste a correspondência de caminhos acedendo à versão alemã do serviço de loja em store.example.com/de:

curl http://store.example.com/de --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

O resultado confirma que o pedido foi publicado por um store-german pod:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "Gutentag!", 
  "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
  "pod_name": "store-german-5cb6474c55-lq5pl", 
  "pod_name_emoji": "🧞‍♀",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-10-25T13:35:37",
  "zone": "ZONE_NAME"
}

Por último, use o cabeçalho HTTP env: canary para enviar tráfego para a versão canary do serviço de loja:

curl -H "env: canary" http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

O resultado confirma que o pedido foi publicado por um store-v2 pod:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v2", 
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v2-5788476cbd-s9thb", 
  "pod_name_emoji": "🦰",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-10-25T13:38:26",
  "zone": "ZONE_NAME"
}

Implemente um gateway externo

Um gateway externo expõe aplicações acessíveis a partir da Internet ou de redes fora da sua rede VPC. A implementação é semelhante a uma implementação de gateway interno, exceto que tem de proteger as suas aplicações porque o gateway está acessível à Internet pública.

Tem duas opções para criar um gateway externo: um gateway externo global ou um gateway externo regional.

Gateway externo global: este gateway usa um endereço IP global (ou um endereço IP Anycast) como a interface do gateway. Este endereço IP é anunciado em todas as Trusted Cloud by S3NS regiões de computação. Os clientes que enviam tráfego para este endereço IP Anycast são encaminhados para a localização da Google mais próxima onde o endereço IP é anunciado. O gateway externo global só está disponível no nível de serviço de rede Premium.
Gateway externo regional: este gateway usa um endereço IP regional como a interface do gateway. O comportamento deste gateway depende do nível de serviço de rede que selecionar:
- Se escolher o nível de serviço de rede padrão (predefinição), o endereço IP regional é anunciado apenas na região de computação local Trusted Cloud by S3NS onde o gateway externo regional está implementado. Os clientes que enviam tráfego para este endereço IP são encaminhados pelo respetivo ISP local e através da Internet pública antes de chegarem à região da Google onde o endereço IP é anunciado.
- Se escolher o nível de serviço de rede Premium, o endereço IP regional é anunciado na rede global da Google. Isto significa que o tráfego do cliente entra na infraestrutura global de alta qualidade da Google num ponto de peering na periferia da Google o mais próximo possível do cliente, mesmo que o destino seja um endereço IP regional. Esta localização reduz significativamente a latência e melhora o desempenho, minimizando a distância que o tráfego percorre na Internet pública.

Implemente um gateway externo global

O exemplo seguinte mostra como expor uma aplicação de loja com vários certificados anexados ao gateway externo global e agrupados num mapa de certificados através do Gestor de certificados e de uma HTTPRoute.

Crie um mapa de certificados

A Google recomenda que use o gestor de certificados para gerir certificados quando precisar de 15 ou mais certificados por gateway ou precisar de usar certificados universais.

Também pode proteger o gateway externo através de segredos do Kubernetes ou certificados SSL geridos pela Google. Para mais informações, consulte o artigo Segurança do gateway.

Nesta secção, cria certificados através do Certificate Manager para proteger as aplicações em execução no cluster.

Ative a API Certificate Manager:

gcloud services enable certificatemanager.googleapis.com

Crie um mapa de certificados:

gcloud beta certificate-manager maps create store-example-com-map

Carregue o certificado e as chaves geridos pela Google num certificado:
```
gcloud beta certificate-manager certificates create store-example-com-cert \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE"
```
Substitua o seguinte:
- CERTIFICATE_FILE: o nome do ficheiro do certificado. O ficheiro tem de ter a extensão .pem. Por exemplo, cert.pem.
- PRIVATE_KEY_FILE: o nome do ficheiro da chave privada.
Para mais informações, consulte o artigo Crie uma chave privada e um certificado.

Crie um CertificateMapEntry que atribua o certificado ao mapa de certificados:

gcloud beta certificate-manager maps entries create store-example-com-map-entry \
    --map=store-example-com-map \
    --hostname=store.example.com \
    --certificates=store-example-com-cert

Para saber como proteger um gateway com outras origens de certificados, como segredos do Kubernetes ou certificados SSL, consulte o artigo Proteger um gateway.

Crie um gateway

Para saber mais acerca do recurso Gateway, consulte a descrição do recurso Gateway ou a especificação da API.

Nesta secção, cria um gateway. As equipas de aplicações podem usar o gateway para expor as respetivas aplicações à Internet implementando rotas de forma independente e anexando-as de forma segura ao gateway.

Guarde o seguinte manifesto num ficheiro com o nome gateway.yaml:
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  # This GatewayClass uses a global external Application Load Balancer.
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
```
Este manifesto descreve um Gateway com os seguintes campos:
- gatewayClassName: gke-l7-global-external-managed: especifica a GatewayClass para este gateway. Esta classe de gateway usa um Application Load Balancer externo global.
- protocol: HTTPS e port: 443: especificam que o gateway expõe a porta 443 para tráfego HTTPS. Estes campos ativam o TLS.
- networking.gke.io/certmap: store-example-com-map: especifica o nome do mapa de certificados no Gestor de certificados.
Não existe uma secção TLS porque o TLS está configurado com o Certificate Manager usando a anotação networking.gke.io/certmap.
Aplique o manifesto ao cluster:
```
kubectl apply -f gateway.yaml
```
A implementação dos recursos pelo GKE pode demorar alguns minutos.
Verifique se a implementação do gateway foi bem-sucedida:
```
kubectl describe gateway
```
O resultado é semelhante ao seguinte:
```
Name:         external-http
Namespace:    default
Labels:       <none>
...
Spec:
  Gateway Class Name:  gke-l7-global-external-managed
  Listeners:
    Allowed Routes:
      Namespaces:
        From:  Same
    Name:      https
    Port:      443
    Protocol:  HTTPS
    Tls:
      Certificate Refs:
        Group:
        Kind:   Secret
        Name:   store-example-com
      Mode:     Terminate
 ...
```
Este resultado mostra que o gateway implementado no seu cluster tem um equilibrador de carga e um endereço IP público. O gateway não tem rotas, o que significa que não pode enviar tráfego para back-ends. Sem rotas, todo o tráfego é encaminhado para um back-end predefinido, que devolve uma resposta HTTP 404. Na secção seguinte, implementa as rotas, que indicam ao gateway para enviar tráfego para os back-ends.

Implemente as aplicações de demonstração

As equipas de aplicações podem implementar as respetivas aplicações e rotas independentemente da implementação de gateways. Em alguns casos, a equipa da aplicação também pode querer ter a propriedade do gateway e implementá-lo como um recurso dedicado às respetivas aplicações. Consulte o artigo Associação de rotas para ver diferentes modelos de propriedade de gateways e rotas. Neste exemplo, a equipa da loja implementa a respetiva aplicação e uma HTTPRoute associada para expor a app através do gateway external-httpcriado na secção anterior.

Para mais informações sobre os campos HTTPRoute, consulte a especificação da API.

Implemente a aplicação de exemplo no seu cluster:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
```
Esta aplicação de exemplo cria três implementações e três serviços com os nomes store-v1, store-v2 e store-german.

Verifique se a aplicação foi implementada com êxito:

kubectl get pod

O resultado é semelhante ao seguinte:

NAME                            READY   STATUS    RESTARTS   AGE
store-german-66dcb75977-5gr2n   1/1     Running   0          38s
store-v1-65b47557df-jkjbm       1/1     Running   0          14m
store-v2-6856f59f7f-sq889       1/1     Running   0          14m

Verifique se os serviços foram implementados com êxito:

kubectl get service

O resultado é semelhante ao seguinte:

NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s

Crie um HTTPRoute

Nesta secção, implementa um HTTPRoute, que configura o gateway com as regras de encaminhamento necessárias para alcançar a aplicação de exemplo.

Guarde o seguinte manifesto num ficheiro com o nome store-route-external.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-external
spec:
  parentRefs:
  # Bind the route to the 'external-http' Gateway.
  - kind: Gateway
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  # Default rule for store.example.com that sends traffic to the store-v1 service.
  - backendRefs:
    - name: store-v1
      port: 8080
  # Match requests with the "env: canary" header and send them to the store-v2 service.
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  # Match requests with the path "/de" and sends them to the store-german service.
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080

Este manifesto descreve uma HTTPRoute que faz referência ao external-httpGateway.

Aplique o manifesto ao cluster:
```
kubectl apply -f store-route-external.yaml
```
A store HTTPRoute está associada ao external-http Gateway através da propriedade parentRefs. O diagrama seguinte mostra as regras de encaminhamento configuradas no equilibrador de carga subjacente:

As regras de encaminhamento processam o tráfego HTTP da seguinte forma:
- O tráfego para store.example.com/de é encaminhado para o serviço store-german.
- O tráfego para store.example.com com o cabeçalho HTTP "env: canary" é encaminhado para o serviço store-v2.
- O tráfego restante para store.example.com é encaminhado para o serviço store-v1.

Verifique se o HTTPRoute foi implementado:

kubectl describe httproute store-external

O resultado é semelhante ao seguinte:

Name:         store-external
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         HTTPRoute
# Multiple lines are omitted here.
Spec:
  Hostnames:
    store.example.com
  Parent Refs:
    Group:  gateway.networking.k8s.io
    Kind:   Gateway
    Name:   external-http
  Rules:
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v1
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v2
      Port:    8080
      Weight:  1
    Matches:
      Headers:
        Name:   env
        Type:   Exact
        Value:  canary
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-german
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /de
Status:
  Parents:
    # This section shows the status of this route in relation to each Gateway attached.
    Conditions:
      Last Transition Time:  2022-11-01T05:42:31Z
      Message:
      Reason:                Accepted
      Status:                True # Means that the Gateway has validated and accepted this route's configuration.
      Type:                  Accepted
      Last Transition Time:  2022-11-01T05:43:18Z
      Message:
      Reason:                ReconciliationSucceeded
      Status:                True
      Type:                  Reconciled
    Controller Name:         networking.gke.io/gateway
    Parent Ref:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   external-http
Events:
  Type     Reason  Age    From                   Message
  ----     ------  ----   ----                   -------
  Normal   ADD     2m48s  sc-gateway-controller  default/store-external
  Normal  SYNC  61s (x3 over 2m27s)  sc-gateway-controller  Bind of HTTPRoute "default/store-external" to ParentRef Group:       "gateway.networking.k8s.io",
  ...

Verifique se o HTTPRoute está associado ao Gateway:

kubectl describe gateway external-http

O resultado é semelhante ao seguinte:

Name:         external-http
Namespace:    default
Labels:       <none>
# Multiple lines are omitted here.
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.149.207.45
  Conditions:
    Last Transition Time:  2022-11-01T05:37:21Z
    Message:
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2022-11-01T05:43:18Z
    Message:
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2022-11-01T05:43:18Z
      Message:
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    https
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
      # Multiple lines are omitted here.

Envie tráfego para a sua aplicação

Agora que o gateway, a rota e a aplicação estão implementados no cluster, pode passar tráfego para a aplicação.

Obtenha o endereço IP do gateway:

kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}"

O resultado é um endereço IP.

Crie uma VM:
```
gcloud cloud-shell ssh
```
Envie tráfego para o endereço IP do gateway a partir da VM. Tem de definir o cabeçalho de anfitrião manualmente porque não é proprietário do nome de anfitrião example.com.
```
curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
```
Substitua GATEWAY_IP_ADDRESS pelo endereço IP do gateway do passo anterior.

cacert.pem: o ficheiro de certificado que gerou. Tem de guardar este ficheiro no computador que usa para estabelecer ligação ao gateway.

O resultado mostra informações da app de demonstração sobre a localização onde a app está a ser executada:
```
{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v1-84b47c7f58-pmgmk",
  "pod_name_emoji": "💇🏼‍♀️",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-09-25T13:31:17",
  "zone": "us-central1-a"
}
```

Teste a correspondência de caminhos acedendo à versão alemã do serviço store em store.example.com/de:

curl https://store.example.com/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v

O resultado confirma que o pedido foi publicado por um store-german pod:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "Gutentag!",
  "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
  "pod_name": "store-german-5cb6474c55-lq5pl",
  "pod_name_emoji": "🧞‍♀",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-09-25T13:35:37",
  "zone": "us-central1-a"
}

Envie tráfego para a versão canary do serviço store usando o cabeçalho HTTP env: canary:

curl -H "env: canary" https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v

O resultado confirma que o pedido foi publicado por um store-v2 pod:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v2",
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v2-5788476cbd-s9thb",
  "pod_name_emoji": "👩🏿",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-09-25T13:38:26",
  "zone": "us-central1-a"
}

Implemente um gateway externo regional

O exemplo seguinte mostra como expor uma aplicação de loja com vários certificados anexados ao gateway externo regional através de certificados autogeridos e um HTTPRoute.

Crie uma sub-rede de proxy para o seu gateway regional

Tem de configurar uma sub-rede apenas de proxy antes de criar um gateway que use um Application Load Balancer externo regional. Cada região de uma VPC na qual usa o Application Load Balancer externo regional tem de ter uma sub-rede external_managed_proxy. Esta sub-rede fornece endereços IP internos aos proxies do balanceador de carga.

Crie um certificado para proteger o tráfego de clientes

Pode usar um certificado emitido e validado pela sua autoridade de certificação (AC) ou criar um certificado autoassinado. Para mais informações sobre como criar um certificado, consulte o artigo Armazene um certificado num segredo do Kubernetes.

Para proteger o tráfego entre os seus clientes e o gateway regional, pode usar os seguintes métodos:

Certificados do Certificate Manager geridos pela Google ou autogeridos
Certificados SSL regionais autogeridos
Segredos do Kubernetes

CertificateMap ou os certificados SSL geridos pela Google não são suportados com gateways regionais.

Para mais informações, consulte o artigo Certificados e Trusted Cloud by S3NS equilibradores de carga

Crie um gateway HTTP(S) externo regional

Crie um endereço IP estático regional para o balanceador de carga externo.
```
gcloud compute addresses create IP_ADDRESS_NAME \
  --region=COMPUTE_REGION \
  --network-tier=STANDARD
```
Substitua o seguinte:
- IP_ADDRESS_NAME: o nome do novo endereço IP estático.
- COMPUTE_REGION: a região do Compute Engine onde o cluster está a ser executado.

Crie um gateway do Application Load Balancer externo regional com um certificado autogerido da seguinte forma e guarde o manifesto como regional-gateway.yaml:

  kind: Gateway
  apiVersion: gateway.networking.k8s.io/v1beta1
  metadata:
    name: external-regional-http
  spec:
    # Name of an existing GatewayClass.
    gatewayClassName: gke-l7-regional-external-managed
    # Listen for HTTPS traffic on port 443
    listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        # Terminate the TLS session with the client at the Gateway.
        mode: Terminate
        # Certificates for the Gateway to use to create a new TLS session.
        certificateRefs:
        - name: store-example-com
    # The name of the static IP address of the external load balancer.
    # You can also use the `IPAddress` type to specify the actual IP address.
    addresses:
    - type: NamedAddress
      value: IP_ADDRESS_NAME

Aplique o manifesto regional-gateway:

  kubectl apply -f regional-gateway.yaml

Valide a configuração.

  kubectl get gateway

O resultado é semelhante ao seguinte:

NAME            CLASS                              ADDRESS         READY   AGE
external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s

Para ver mais detalhes, use um comando de descrição:

kubectl describe gateway

O resultado é semelhante ao seguinte:

Name:         external-regional-http
Namespace:    default
Labels:       <none>
...
Spec:
  Gateway Class Name:  gke-l7-regional-external-managed
  Listeners:
    Allowed Routes:
      Namespaces:
        From:  Same
    Name:      https
    Port:      443
    Protocol:  HTTPS
    Tls:
      Certificate Refs:
        Group:
        Kind:   Secret
        Name:   store-example-com
      Mode:     Terminate
  ...

Implemente a aplicação de demonstração

Pode implementar as suas aplicações e rotas independentemente da implementação de gateways.

Para mais informações sobre como implementar as aplicações de demonstração, consulte o artigo Implemente as aplicações de demonstração.

Crie um HTTPRoute

Tem de criar um HTTPRoute para fazer a correspondência e a filtragem de tráfego HTTP e HTTPS.

Envie tráfego para a sua aplicação

Depois de implementar a aplicação e criar HTTPRoutes, pode transmitir tráfego para a aplicação.

Para mais informações sobre como enviar tráfego para a sua aplicação, consulte o artigo Envie tráfego para a sua aplicação.

Use gateways partilhados

A API Gateway usa recursos separados, recursos Gateways e Route, para implementar equilibradores de carga e regras de encaminhamento. Isto difere do Ingress, que combina tudo num único recurso. Ao dividir a responsabilidade entre os recursos, o gateway permite que o equilibrador de carga e as respetivas regras de encaminhamento sejam implementados separadamente e por diferentes utilizadores ou equipas. Isto permite que os gateways se tornem gateways partilhados que se associam a muitas rotas diferentes que podem ser totalmente detidas e geridas por equipas independentes, mesmo em espaços de nomes diferentes.

Implemente rotas num gateway partilhado

Este exemplo baseia-se no internal-httpgateway implementado em Implemente um gateway interno.

Neste exemplo, a equipa do site implementa a respetiva aplicação, serviços e um HTTPRoute para corresponder ao tráfego do gateway a esses serviços.

Implemente a aplicação de exemplo:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml

Guarde o seguinte manifesto num ficheiro com o nome site-route-internal.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: site-internal
spec:
  # Attach the HTTPRoute to the `internal-http` Gateway.
  parentRefs:
  - kind: Gateway
    name: internal-http
  # Route requests that have `site.example.com` in the Host header.
  hostnames:
  - "site.example.com"
  # Send all requests to the `site-v1` Service.
  rules:
  - backendRefs:
    - name: site-v1
      port: 8080

Este manifesto descreve uma HTTPRoute que corresponde a todo o tráfego para site.example.com e encaminha-o para o serviço site-v1.

Aplique o manifesto ao cluster:

kubectl apply -f site-route-internal.yaml

Verifique se o HTTPRoute está associado ao Gateway:

kubectl describe httproute.gateway.networking.k8s.io site-internal

O resultado é semelhante ao seguinte:

Status:
  Parents:
    Conditions:
      Last Transition Time:  2023-01-09T15:05:43Z
      Message:
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2023-01-09T15:05:43Z
      Message:
      Reason:                ReconciliationSucceeded
      Status:                True
      Type:                  Reconciled
    Controller Name:         networking.gke.io/gateway
    Parent Ref:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   internal-http
      ...

Se a condição Accepted para o Gateway for True, o HTTPRoute foi associado com êxito ao Gateway. Para saber mais acerca do campo Status, consulte o estado do trajeto.

Verifique se o tráfego para o gateway é encaminhado corretamente:

curl -H "host: site.example.com" GATEWAY_IP_ADDRESS
curl -H "host: store.example.com" GATEWAY_IP_ADDRESS

Substitua GATEWAY_IP_ADDRESS pelo endereço IP do gateway interno.

Tem de usar uma máquina virtual (VM) na mesma VPC que o gateway.

O resultado é semelhante ao seguinte:

{
  "cluster_name": "CLUSTER_NAME",
  "host_header": "site.example.com",
  "metadata": "site-v1",
  "pod_name": "site-v1-5d64fc4d7d-fz6f6",
  "pod_name_emoji": "👩🏼‍🍳",
  "project_id": "PROJECT_ID",
  "timestamp": "2022-11-02T19:07:01",
  "zone": "ZONE_NAME"
}
...
{
  "cluster_name": "CLUSTER_NAME",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "pod_name": "store-v1-6d8d58d78-vz8pn",
  "pod_name_emoji": "🧝🏻‍♂️",
  "project_id": "PROJECT_ID",
  "timestamp": "2022-11-02T19:07:01",
  "zone": "ZONE_NAME"
}

Este resultado indica que os pedidos com o cabeçalho site.example.com Host chegam ao serviço site-v1, enquanto os pedidos com o cabeçalho store.example.com Host chegam ao serviço store-v1.

Configure o nível da rede

Pode especificar o nível de rede para o endereço do ouvinte de um Application Load Balancer externo regional usando o campo type na matriz addresses[] na definição de Gateway. Se não especificar um nível de rede, o gateway usa por predefinição um endereço IP efémero de nível padrão.

Use os seguintes valores para o campo type:

networking.gke.io/premium-ephemeral-ipv4-address: atribui um endereço IP de nível Premium.
networking.gke.io/standard-ephemeral-ipv4-address: atribui um endereço IP de nível padrão.

Para atribuir endereços IP de ambos os níveis da rede, especifique ambos os tipos no campo addresses.

O exemplo seguinte mostra como Trusted Cloud by S3NS atribuir um endereço IP de nível Premium a um gateway. Para aprovisionar um endereço IP de nível padrão, use networking.gke.io/standard-ephemeral-ipv4-address.

Guarde o seguinte manifesto de exemplo como external-regional-http.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-regional-http
spec:
  # Name of an existing GatewayClass.
  gatewayClassName: gke-l7-regional-external-managed
  # Listen for HTTPS traffic on port 443.
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      # Terminate the TLS session with the client at the Gateway.
      mode: Terminate
      # Certificates for the Gateway to use to create a new TLS session.
      certificateRefs:
      - name: store-example-com
    addresses:
    # Request a Premium Tier ephemeral IPv4 address for the Gateway.
    - type: networking.gke.io/premium-ephemeral-ipv4-address

Aplique o manifesto de exemplo:

kubectl apply -f external-regional-http.yaml

Configure o back-end predefinido do gateway

Todas as gke-l7-* GatewayClasses devolvem HTTP 404 ao tráfego não correspondente. Pode configurar o back-end predefinido através de uma rota predefinida explícita que envia tráfego não correspondente para um serviço fornecido pelo utilizador.

Os gateways estão configurados para processar códigos de erro como 404 (Não encontrado) e 500 (Erro no servidor), mesmo sem definições explícitas de back-end. O comportamento predefinido pode variar entre implementações de gateways. Para um maior controlo sobre o processamento de erros, pondere configurar back-ends personalizados.

A HTTPRoute seguinte é um exemplo de como personalizar o back-end predefinido. Se aplicar um HTTPRoute semelhante ao seguinte, tem precedência sobre o backend predefinido implícito:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  # Omit the `hostnames` field to route all unmatched traffic from the
  # attached Gateway.
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Esta HTTPRoute corresponde a todo o tráfego de um Gateway específico. Só pode ter uma regra deste tipo para cada gateway. Caso contrário, as regras entram em conflito e aplica-se a ordenação por precedência.

Pode usar um back-end predefinido para impedir que alguém crie um back-end de rota predefinida que encaminhe todo o tráfego do gateway. Uma HTTPRoute explícita tem sempre precedência sobre novas HTTPRoutes com regras de encaminhamento em conflito.

Configure um endereço IP estático para um gateway

Cada gateway tem um endereço IP que usa para ouvir o tráfego. Se não especificar um endereço IP no gateway, o controlador do gateway fornece automaticamente um endereço IP. Também pode criar um endereço IP estático para que o endereço IP exista independentemente do ciclo de vida do gateway.

Depois de uma entrada ser implementada, o respetivo endereço IP é apresentado no campo de estado:

kind: Gateway
...
status:
  addresses:
    - value: 10.15.32.3

Consoante a GatewayClass, o endereço IP é atribuído a partir das seguintes sub-redes:

GatewayClasses	Conjunto de endereços IP predefinido
gke-l7-rilb gke-l7-rilb-mc	Endereços IP privados regionais do intervalo de endereços IPv4/IPv6 do nó principal
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Endereços IP públicos regionais dos intervalos IPv4/IPv6 externos regionais da Google
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Endereços IP públicos globais dos intervalos IPv4/IPv6 externos globais da Google

O campo addresses.NamedAddress permite especificar um endereço IP independentemente do gateway. Pode criar um recurso de endereço IP estático antes da implementação do gateway e o recurso é referenciado pelo NamedAddress. Pode reutilizar o endereço IP estático mesmo que o gateway seja eliminado.

Use um endereço IP com nome

Pode configurar um endereço IPv4 ou IPv6 especificando um NamedAddress. Tem de aprovisionar um endereço IP estático antes de criar um gateway.

Crie um recurso de endereço IP estático:
```
gcloud compute addresses create IP_ADDRESS_NAME \
    --purpose=SHARED_LOADBALANCER_VIP \
    --region=COMPUTE_REGION \
    --subnet=SUBNET \
    --project=PROJECT_ID
```
Substitua o seguinte:
- IP_ADDRESS_NAME: o nome do novo endereço IP estático
- COMPUTE_REGION: para gateways regionais, a região do Compute Engine onde o cluster está a ser executado. Esta flag não é necessária para gateways externos globais.
- SUBNET: a sub-rede do endereço IP. Esta flag não é necessária para gateways externos globais.
- PROJECT_ID: o projeto onde o seu cluster do GKE está a ser executado.

Guarde o seguinte manifesto num ficheiro com o nome named-ip-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-http
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
  addresses:
  - type: NamedAddress
    value: IP_ADDRESS_NAME

Este manifesto descreve um Gateway que faz referência ao endereço IP com nome.

Aplique o manifesto ao cluster:
```
kubectl apply -f named-ip-gateway.yaml
```

Valide o endereço IP do gateway:

kubectl describe gateway internal-http

O resultado é semelhante ao seguinte:

Name:         internal-http
Namespace:    default
Labels:       <none>
...
Spec:
  Addresses:
    Type:              NamedAddress
    Value:             IP_ADDRESS_NAME
  Gateway Class Name:  gke-l7-rilb
  Listeners:
    Allowed Routes:
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
Status:
  Addresses:
    Type:   IPAddress
    Value:  10.15.32.103

Configure redirecionamentos de HTTP para HTTPS

O Cloud Load Balancing oferece a funcionalidade de redirecionamento de HTTP para HTTPS. Um balanceador de carga de aplicações externo redireciona pedidos HTTP não encriptados para um balanceador de carga HTTPS que usa o mesmo endereço IP. Quando cria um Gateway com redirecionamentos de HTTP para HTTPS ativados, estes dois equilibradores de carga são criados automaticamente. Os pedidos para o endereço IP externo do gateway na porta 80 são automaticamente redirecionados para o mesmo endereço IP externo na porta 443.

Por predefinição, os redirecionamentos de HTTP para HTTPS não estão definidos no gateway.

Para redirecionar o tráfego HTTP para HTTPS, configure um gateway para processar o tráfego HTTP e HTTPS. Se desativar o HTTP ou o HTTPS, o gateway não redireciona o tráfego.

O exemplo seguinte mostra como pode usar o redirecionamento de HTTP para HTTPS como um meio de garantir que o tráfego dos seus clientes que acedem às suas aplicações Web é sempre redirecionado para uma página segura.

Os redirecionamentos de HTTP para HTTPS não são suportados com as GatewayClasses gke-l7-gxlb e gke-l7-gxlb-mc. Para saber mais sobre as diferentes funcionalidades suportadas por cada GatewayClass, consulte Capacidades da GatewayClass.

Redirecione o tráfego HTTP de um espaço de nomes de infraestrutura

Em alguns casos, não existe uma distinção clara entre a equipa de administração da infraestrutura ou da plataforma e as equipas de aplicações, e a prevenção da utilização indevida da Gateway pode tornar-se um desafio.

O exemplo seguinte restringe ainda mais a utilização do ouvinte HTTP para impedir a utilização não intencional do protocolo não seguro por parte das equipas de aplicações. Este exemplo configura o gateway para permitir que um HTTPRoute use o ouvinte HTTP apenas se a rota estiver num espaço de nomes com a etiqueta otherInfra: httpToHttps. No entanto, o Gateway permite que as HTTPRoutes em qualquer espaço de nomes usem o ouvinte HTTPS. Pode restringir o espaço de nomes http-redirect através do RBAC do Kubernetes para que as equipas de aplicações não criem um HTTPRoute neste espaço de nomes por engano.

Crie o espaço de nomes de um gateway. Guarde o manifesto como gateway-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-infra
```

Aplique o manifesto:

kubectl apply -f gateway-namespace.yaml

Crie o espaço de nomes de um gateway e guarde o manifesto como redirect-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: http-redirect
  labels:
    otherInfra: httpToHttps
```
Este espaço de nomes http-redirect tem a etiqueta otherInfra: httpToHttps.

Aplique o manifesto:

kubectl apply -f redirect-namespace.yaml

Para restringir a utilização do ouvinte http, crie um gateway com o seguinte manifesto. Guarde o manifesto como external-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  namespace: gateway-infra
spec:
  # Name of an existing GatewayClass.
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    #  Allow only HTTPRoutes from namespaces that have the
    # `otherInfra: httpToHttps` label to use this listener.
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: Selector
        selector:
          matchLabels:
            otherInfra: httpToHttps
  - name: https
    protocol: HTTPS
    port: 443
    # Allow HTTPRoutes from any namespace to use this listener.
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: All
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: store-example-com

O campo namespace especifica que o Gateway é criado no espaço de nomes gateway-infra.
O campo namespaces na secção allowedRoutes restringe o ouvinte http ao espaço de nomes correspondente à etiqueta otherInfra: httpToHttps.

Aplique o manifesto:
```
kubectl apply -f external-gateway.yaml
```

Para forçar o redirecionamento HTTPS, crie um HTTPRoute predefinido com o seguinte manifesto. Guarde o manifesto como http-redirect.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: redirect
  # Create the HTTPRoute in the `http-redirect` namespace.
  namespace: http-redirect
spec:
  # Attach the HTTPRoute to the `http` listener in the `external-http`
  # Gateway.
  parentRefs:
  - namespace: gateway-infra
    name: external-http
    sectionName: http
  rules:
  # Respond to the request with an HTTPS redirection.
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https

O campo sectionName indica ao gateway que só deve haver correspondência no ouvinte http. O filtro RequestRedirect força o redirecionamento para o ouvinte https.

Aplique o manifesto:
```
kubectl apply -f http-redirect.yaml
```

Crie um serviço para uma aplicação com o seguinte manifesto. Guarde o manifesto como service-deployment.yaml:

apiVersion: v1
kind: Service
metadata:
  name: store-v1
spec:
  selector:
    app: store
    version: v1
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: store
      version: v1
  template:
    metadata:
      labels:
        app: store
        version: v1
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
        - containerPort: 8080
        env:
        - name: METADATA
          value: "store-v1"

Aplique o manifesto:

kubectl apply -f service-deployment.yaml

Crie um HTTPRoute para uma aplicação que só permita HTTPS através do seguinte manifesto. Guarde o manifesto como http-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  # Attach the HTTPRoute to the HTTPS listener in the `external-http`
  # Gateway.
  parentRefs:
  - name: external-http
    namespace: gateway-infra
    sectionName: https
  # Match requests that have the `store.example.com` Host header.
  hostnames:
  - "store.example.com"
  # Route requests to the `store-v1` Service.
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

Aplique o manifesto:
```
kubectl apply -f http-route.yaml
```

Configure redirecionamentos de caminhos e reescritas de URLs

Os redirecionamentos de caminhos consistem em redirecionar um pedido recebido de um caminho de URL para outro. Os redirecionamentos de caminho permitem-lhe alterar a estrutura do URL quando precisa de processar URLs desatualizados ou descontinuados.

As reescritas de URLs ajudam a modificar o URL recebido antes de o processar no servidor. Permite-lhe alterar a estrutura ou o formato do URL sem alterar efetivamente o conteúdo ou a estrutura do ficheiro subjacente. A reescrita de URLs é vantajosa para criar URLs fáceis de usar e otimizados para SEO, que são fáceis de memorizar e compreender. Por predefinição, os redirecionamentos de caminhos e as reescritas de URLs não estão configurados. Tem de configurar explicitamente esses redirecionamentos ou reescritas através de um filtro no seu HTTPRoute.

O GKE Gateway suporta redirecionamentos de caminhos e reescritas de URLs. Para mais informações, consulte o artigo Redirecionamentos e reescritas de caminhos HTTP.

Configure redirecionamentos de caminhos

Pode configurar redirecionamentos de caminhos para substituir o caminho completo ou apenas um prefixo no URL.

Substituir todo o caminho

Para substituir um caminho completo, configure um filtro numa HTTPRoute que substitua qualquer URL que contenha o prefixo /any-path no caminho do URL pelo valor estrito /new-path.

Crie um HTTPRoute manifesto da seguinte forma e atribua-lhe o nome store.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
    - kind: Gateway
      name: external-http
    hostnames:
    - store.example.com
    rules:
    - matches:
      - path:
          # Match requests by a prefix, like `/any-path` and `/any-path/home`.
          type: PathPrefix
          value: /any-path
      filters:
      - type: RequestRedirect
        requestRedirect:
          path:
            # Replace the full path with `/new-path`. For example, both
            # `/any-path/home` and `/any-path` become `/new-path`.
            type: ReplaceFullPath
            replaceFullPath: /new-path
          statusCode: 302

Por exemplo, este manifesto define uma regra de encaminhamento para um HTTPRoute da seguinte forma: Qualquer rota para o URL https://store.example.com/any-path/... deve ser redirecionada para uma nova localização, https://store.example.com/new-path/ (estrita).

Aplique o manifesto:
```
kubectl apply -f store.yaml
```

Esta regra de encaminhamento segue uma regra de redirecionamento rigorosa, o que significa que o navegador não tenta colocar o redirecionamento em cache. Em vez disso, redireciona para a versão mais recente.

Substituir apenas um prefixo

Para substituir apenas um prefixo, configure um filtro numa HTTPRoute que substitua qualquer URL que contenha o prefixo /any-prefix no caminho do URL pelo valor estrito /new-prefix.

Crie um HTTPRoute manifesto da seguinte forma e atribua-lhe o nome store.yaml:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  parentRefs:
    - kind: Gateway
      name: external-http
  hostnames:
  - store.example.com
  rules:
  - matches:
      - path:
          # Match requests by prefix, like `/any-prefix` and
          # `/any-prefix/home`.
          type: PathPrefix
          value: /any-prefix
    filters:
    - type: RequestRedirect
      requestRedirect:
        path:
          # Replace the matched prefix with `/new-prefix`. For example,
          # `/any-prefix` becomes `/new-prefix` and `/any-prefix/home`
          # becomes `/new-prefix/home`.
          type: ReplacePrefixMatch
          replacePrefixMatch: /new-prefix
        statusCode: 302

Por exemplo, este manifesto define uma regra de encaminhamento para um HTTPRoute da seguinte forma: Qualquer rota para o URL https://store.example.com/any-path/v1/... deve ser redirecionada para uma nova localização, https://store.example.com/new-path/v1/... (apenas).

Aplique o manifesto:
```
  kubectl apply -f store.yaml
```

Esta regra de encaminhamento segue a única regra de redirecionamento, o que garante que o navegador redireciona sempre para a mesma página pretendida.

Configure reescritas de URLs

Defina reescritas de URLs para alterar a forma como um URL é apresentado aos utilizadores. Pode usar a reescrita de URLs para tornar os URLs mais fáceis de usar, melhorar o SEO ou redirecionar os utilizadores para uma nova página.

Reescrever o nome do anfitrião completo

Para reescrever o nome do anfitrião completo:

Configure um filtro numa HTTPRoute que instrua a gateway a substituir as informações Host no cabeçalho do pedido de www.example.com para store.example.com antes de encaminhar o pedido para o serviço de back-end.

Crie um HTTPRoute manifesto da seguinte forma e atribua-lhe o nome www.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: www
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - www.example.com
    rules:
    - filters:
      - type: URLRewrite
        # Replace the hostname in the URL with `store.example.com`.
        urlRewrite:
          hostname: store.example.com
      backendRefs:
      - name: store-v1
        port: 8080

Por exemplo, com a configuração acima, qualquer pedido para https://www.example.com é encaminhado para o serviço de back-end com o cabeçalho Host: store.example.com, em vez de Host: www.example.com.

Aplique o manifesto:
```
  kubectl apply -f www.yaml
```

Reescreva usando modificadores de caminho

Pode combinar reescritas com modificadores de caminho para fornecer modificações avançadas de URL e caminho antes de retransmitir o pedido para o serviço de back-end.

Para reescrever usando modificadores de caminho:

Configure um filtro numa HTTPRoute que instrua o gateway a substituir as informações "Host" no cabeçalho do pedido de www.example.comto store.example.com e substitua o valor /store por / antes de encaminhar o pedido para o serviço de back-end.

Crie um HTTPRoute manifesto da seguinte forma e atribua-lhe o nome www.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: www
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - www.example.com
    rules:
    - matches:
      - path:
          type: PathPrefix
          value: /store
      filters:
      - type: URLRewrite
        # For URLs that have `/store` in the path, replace the hostname with
        # store.example.com and replace the `/store` prefix with `/de`.
        urlRewrite:
          hostname: store.example.com
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /de
      backendRefs:
      - name: store-german
        port: 8080

Por exemplo, com a configuração acima, qualquer pedido para https://www.example.com/store/... é encaminhado para o serviço de back-end com Host: store.example.com no cabeçalho do pedido (em vez de Host: www.example.com) e o /store é reescrito para /de.

Aplique o manifesto:
```
kubectl apply -f www.yaml
```

Valide a configuração

Para verificar se o filtro foi aplicado após a criação da HTTPRoute com filtros de reescrita de URL ou redirecionamentos de caminhos, faça o seguinte:

kubectl get httproute www -o yaml

O resultado é semelhante ao seguinte:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1beta1","kind":"HTTPRoute","metadata":{"annotations":{},"name":"www","namespace":"default"},"spec":{"hostnames":["www.example.com"],"parentRefs":[{"kind":"Gateway","name":"external-http"}],"rules":[{"backendRefs":[{"name":"store-german","port":8080}],"filters":[{"type":"URLRewrite","urlRewrite":{"hostname":"store.example.com","path":{"replacePrefixMatch":"/de","type":"ReplacePrefixMatch"}}}],"matches":[{"path":{"type":"PathPrefix","value":"/store"}}]}]}}
    creationTimestamp: "2023-06-22T01:00:42Z"
    generation: 3
    name: www
    namespace: default
    resourceVersion: "51268631"
    uid: e516493e-806d-44d6-ae0d-1c9ff25682cf
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: external-http
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: store-german
        port: 8080
        weight: 1
      filters:
      - type: URLRewrite
        urlRewrite:
          hostname: store.example.com
          path:
            replacePrefixMatch: /de
            type: ReplacePrefixMatch
      matches:
      - path:
          type: PathPrefix
          value: /store
  status:
    parents:
    - conditions:
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: Accepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: ReconciliationSucceeded
        status: "True"
        type: Reconciled
      controllerName: networking.gke.io/gateway
      parentRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: external-http

Para ver mais detalhes, use o comando describe:

kubectl describe httproute

Configure cabeçalhos de pedidos e respostas personalizados

Os cabeçalhos de pedidos e respostas personalizados permitem-lhe especificar cabeçalhos adicionais para pedidos e respostas HTTP(S). Consoante as informações detetadas pelo equilibrador de carga, estes cabeçalhos podem incluir as seguintes informações:

Latência para o cliente
Localização geográfica do endereço IP do cliente
Parâmetros da ligação TLS

Por predefinição, não são adicionados cabeçalhos personalizados ao pedido enviado/recebido para/dos seus serviços de back-end. Tem de configurar explicitamente cabeçalhos personalizados através de um filtro no seu HTTPRoute.

Pode configurar cabeçalhos personalizados adicionando uma secção de filtro às regras do HTTPRoute da seguinte forma:

Configure cabeçalhos de pedidos personalizados

Crie um manifesto HTTPRoute com um filtro RequestHeaderModifier e guarde-o como http-route-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    <...>
    rules:
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              <...>

Aplique o manifesto:

  kubectl apply -f http-route-request.yaml

Configure cabeçalhos das respostas personalizados

Crie um manifesto HTTPRoute com um filtro ResponseHeaderModifier e guarde-o como http-route-response.yaml:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Aplique o manifesto:

  kubectl apply -f http-route-response.yaml

Pode adicionar, definir e remover cabeçalhos, conforme descrito na implementação da API Gateway. Pode configurar a sua HTTPRoute com um cabeçalho personalizado através de Trusted Cloud variáveis suportadas.

Exemplo 1:

Para configurar uma HTTPRoute que adicione informações de localização do cliente ao pedido HTTP antes de o enviar para o serviço de back-end, crie um manifesto HTTPRoute e atribua-lhe o nome external-http-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          # Add custom headers to requests that have `/fr` in the path.
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

Por exemplo, para clientes localizados em Estrasburgo, França, o gateway adiciona um cabeçalho como X-Client-Geo-Location:FR,Strasbourg.

Exemplo 2:

Para configurar um HTTPRoute que adicione um cabeçalho de resposta personalizado para suportar a política HTTP Strict Transport Security, crie um manifesto HTTPRoute e atribua-lhe o nome external-http-response.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          # Add custom headers to responses to requests that have `/de` in the
          # path.
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Valide a configuração

Para validar a configuração depois de configurar cabeçalhos de pedidos e respostas personalizados, faça o seguinte:
```
  kubectl get httproute
```
O resultado é semelhante ao seguinte:
```
  NAME    HOSTNAMES               AGE
  store   ["store.example.com"]   4d23h
```

Para ver mais detalhes, use o comando describe:

  kubectl describe httproute

O resultado é semelhante ao seguinte:

  Name:         store
  Namespace:    default
  Labels:       <none>
  Annotations:  <none>
  API Version:  gateway.networking.k8s.io/v1beta1
  Kind:         HTTPRoute
  Metadata:
    Creation Timestamp:  2023-05-27T00:51:01Z
    Generation:          5
    Resource Version:    25418887
    UID:                 2e07a1b8-420b-41b4-acd1-cecbfcd39f42
  Spec:
    Hostnames:
      store.example.com
    Parent Refs:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   external-http
    Rules:
      Backend Refs:
        Group:
        Kind:    Service
        Name:    store-v1
        Port:    8080
        Weight:  1
      Matches:
        Path:
          Type:   PathPrefix
          Value:  /
      Backend Refs:
        Group:
        Kind:    Service
        Name:    store-v2
        Port:    8080
        Weight:  1
      Matches:
        Headers:
          Name:   env
          Type:   Exact
          Value:  canary
        Path:
          Type:   PathPrefix
          Value:  /
      Backend Refs:
        Group:
        Kind:    Service
        Name:    store-german
        Port:    8080
        Weight:  1
      Filters:
        Request Header Modifier:
          Add:
            Name:   X-Client-Geo-Location
            Value:  {client_region},{client_city}
        Type:       RequestHeaderModifier
      Matches:
        Path:
          Type:   PathPrefix
          Value:  /de
  Status:
    <...>

Estado do trajeto

Os recursos HTTPRoute emitem condições e eventos para ajudar os utilizadores a compreender se um HTTPRoute foi associado com êxito a uma ou mais Gateways ou se foi rejeitado.

Condições HTTPRoute

As condições HTTPRoute indicam o estado da rota e os gateways aos quais está associada. Uma vez que um Route pode estar associado a vários Gateways, esta é uma lista de Gateways e das condições individuais entre o Route e cada Gateway.

Accepted=True indica que o HTTPRoute está associado com êxito a um gateway.
Accepted=False indica que o HTTPRoute foi rejeitado da associação a este Gateway.

Se não existirem gateways listados no cabeçalho Gateway bindings, as etiquetas HTTPRoute e os seletores de etiquetas de gateway podem não corresponder. Isto pode ocorrer se nenhum gateway selecionar o seu caminho.

Eventos HTTPRoute

Os eventos HTTPRoute fornecem detalhes sobre o estado da HTTPRoute. Os eventos são agrupados pelos seguintes motivos:

Os eventos ADD são acionados quando é adicionado um recurso.
Os eventos UPDATE são acionados quando um recurso é atualizado.
Os eventos SYNC são acionados pela conciliação periódica.

União, precedência e validação de rotas

Precedência do trajeto

A API Gateway define regras de precedência rigorosas sobre a forma como o tráfego é correspondido por rotas com regras de encaminhamento sobrepostas. A precedência entre duas HTTPRoutes sobrepostas é a seguinte:

União de nomes de anfitriões: a correspondência de nome de anfitrião mais longa/específica.
União de caminhos: a correspondência de caminho mais longa/específica.
União de cabeçalhos: o maior número de cabeçalhos HTTP que correspondem.
Conflito: se as três regras anteriores não estabelecerem precedência, a precedência é atribuída ao recurso HTTPRoute com a data/hora mais antiga.

União de trajetos

Para gke-l7 GatewayClasses, todas as HTTPRoutes para um determinado Gateway são unidas no mesmo recurso de mapa de URLs. A forma como os HTTPRoutes são unidos depende do tipo de sobreposição entre os HTTPRoutes. A HTTPRoute do exemplo anterior pode ser dividida em três HTTPRoutes separadas para ilustrar a união e a precedência de rotas:

União de rotas: todas as três HTTPRoutes estão associadas ao mesmo Gateway, pelo que são unidas.internal-http
União de nomes de anfitriões: todas as três rotas correspondem a store.example.com, pelo que as respetivas regras de nome de anfitrião são unidas.
Fusão de caminhos: store-german-route tem um caminho mais específico /de, pelo que não é fundido mais. store-v1-route e store-v2-route também correspondem ao mesmo caminho /*, pelo que são fundidos no caminho.
União de cabeçalhos: store-v2-route tem um conjunto mais específico de correspondências de cabeçalhos HTTP do que store-v1-route, pelo que não são unidos mais.
Conflito: uma vez que é possível unir os trajetos no nome do anfitrião, no caminho e nos cabeçalhos, não existem conflitos, e todas as regras de encaminhamento são aplicadas ao tráfego.

A única HTTPRoute usada no exemplo anterior é equivalente a estas três rotas separadas:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-v1-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - kind: Service
      name: store-v1
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-v2-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - kind: Service
      name: store-v2
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-german-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /de
    backendRefs:
    - kind: Service
      name: store-german
      port: 8080

Gateways do Kubernetes e gateways do Istio

Tenha em atenção que a API Kubernetes Gateway e a API Istio têm ambas um recurso com o nome Gateway. Embora desempenhem funções semelhantes, não são o mesmo recurso. Se estiver a usar o Istio e a API Gateway no mesmo cluster do Kubernetes, estes nomes sobrepõem-se quando usa o kubectl na linha de comandos. kubectl get gateway pode devolver os recursos do gateway do Kubernetes e não os recursos do gateway do Istio ou vice-versa.

$ kubectl api-resources
NAME       SHORTNAMES   APIGROUP                       NAMESPACED   KIND
gateways   gw           networking.istio.io/v1beta1    true         Gateway
gateways   gtw          networking.k8s.io/v1beta1      true         Gateway

Se estiver a usar o Istio e atualizar para o GKE 1.20 e posterior, é recomendado começar a usar o nome abreviado do recurso Gateway ou especificar o grupo da API. O nome abreviado de um gateway do Kubernetes é gtw e o nome abreviado de um gateway do Istio é gw. Os seguintes comandos devolvem os recursos do Kubernetes Gateway e do Istio Gateway, respetivamente.

# Kubernetes Gateway
$ kubectl get gtw
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

$ kubectl get gateway.networking.x-k8s.io
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

# Istio Gateway
$ kubectl get gw
NAME               AGE
bookinfo-gateway   64m

$ kubectl get gateway.networking.istio.io
NAME               AGE
bookinfo-gateway   64m

Resolução de problemas

Falta a sub-rede só de proxy na região

Sintoma:

O seguinte problema pode ocorrer quando cria um gateway regional (interno ou externo):

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/[REGION_NAME]/targetHttpProxies/gkegw-x5vt-default-internal-http-[ID]'. A reserved managed proxy subnetwork with purpose REGIONAL_MANAGED_PROXY is required.

Motivo:

Esta mensagem de erro indica que não existe nenhuma sub-rede apenas de proxy na região para o seu gateway.

Solução alternativa:

Para resolver este problema, configure uma sub-rede apenas de proxy.

Já existe uma sub-rede só de proxy na região com a finalidade errada

Sintoma:

O seguinte problema pode ocorrer quando cria uma sub-rede apenas de proxy para o seu gateway regional (interno ou externo):

ERROR: (gcloud.compute.networks.subnets.create) Could not fetch resource:
 - The resource 'projects/[PROJECT_NAME]/regions/[REGION_NAME]/subnetworks/[PROXY_ONLY_SUBNET_NAME]' already exists

Motivo:

Esta mensagem de erro indica que tentou criar uma sub-rede apenas de proxy regional numa região que já tem uma sub-rede apenas de proxy.

Solução alternativa:

Para resolver este problema, siga estes passos:

Verifique se já existe uma sub-rede apenas de proxy na região e confirme se tem a finalidade correta:
1. Liste as suas sub-redes para saber qual é a sub-rede só de proxy na região:
```
gcloud compute networks subnets list --regions=COMPUTE_REGION
```
  Substitua COMPUTE_REGION pela região do Compute Engine onde quer criar o gateway regional.
2. Descreva a sua sub-rede apenas de proxy na região para encontrar a respetiva finalidade:
```
gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
    --region COMPUTE_REGION | grep -E 'name|purpose'
```
  Substitua PROXY_ONLY_SUBNET pela sub-rede só de proxy.
O GKE Gateway só suporta sub-redes REGIONAL_MANAGED_PROXYapenas proxy para gateways regionais (internos ou regionais).
Se a sub-rede só de proxy existente na região tiver sido criada com um INTERNAL_HTTPS_LOAD_BALANCER objetivo, migre o respetivo objetivo para REGIONAL_MANAGED_PROXY.

Não existe nenhuma origem em bom estado

Sintoma:

O seguinte problema pode ocorrer quando cria um gateway, mas não consegue aceder aos serviços de back-end (código de resposta 503):

no healthy upstream

Motivo:

Esta mensagem de erro indica que o verificador de estado de funcionamento não consegue encontrar serviços de back-end em bom estado. É possível que os seus serviços de back-end estejam em bom estado, mas pode ter de personalizar as verificações de funcionamento.

Solução alternativa:

Para resolver este problema, personalize a verificação de estado com base nos requisitos da sua aplicação (por exemplo, /health) através de um HealthCheckPolicy.

O que se segue?

Saiba mais sobre o controlador de gateway.
Saiba como configurar recursos do gateway através de políticas.
Saiba mais acerca de outras configurações da Gateway na documentação da API Gateway.