Como implantar gateways

Autopilot Standard

Nesta página, descrevemos como implantar recursos de gateway do Kubernetes para o balanceamento de carga de tráfego de entrada em um único cluster do Google Kubernetes Engine (GKE).

Para implantar gateways para balancear a carga de tráfego de entrada em vários clusters (ou frotas), consulte e Como implantar gateways de vários clusters.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Requisitos do GKE Gateway Controller

Para o Standard, o GKE versão 1.24 ou posterior.

Para o Autopilot, o GKE versão 1.26 ou posterior.
Google Cloud CLI versão 407.0.0 ou mais recente.
A API Gateway é compatível apenas com clusters nativos da VPC.
Se você estiver usando o GatewayClasses interno, ative uma sub-rede somente proxy.
O cluster precisa ter o complemento HttpLoadBalancing ativado.
Se você estiver usando o Istio, será necessário fazer upgrade do Istio para uma das seguintes versões:
- 1.15.2 ou mais recente
- 1.14.5 ou mais recente
- 1.13.9 ou mais recente
Se você estiver usando a VPC compartilhada, será necessário atribuir o papel Compute Network User à conta de serviço do GKE referente ao projeto de serviço no projeto host.

Restrições e limitações

Ao usar o gateway do GKE, entenda as seguintes limitações e restrições:

Conheça as práticas recomendadas:

Para ter o melhor desempenho, limite o número de gateways a, no máximo, 100. Exceder esse limite pode afetar o desempenho ou aumentar a latência.

O GatewayClasses do GKE é compatível com diferentes recursos, dependendo do balanceador de carga que eles usam. Para saber mais sobre os diferentes recursos compatíveis com cada GatewayClass, consulte Recursos da GatewayClass.
Não é possível usar um FrontendConfig ou um BackendConfig para configurar um gateway. Você precisa usar uma política.
O gateway do GKE se comporta de maneira diferente da entrada, porque não infere parâmetros de verificação de integridade. Se o Serviço não retornar 200 para solicitações a GET / ou se você tiver outras verificações de prontidão de pod ajustadas, será necessário configurar uma HealthCheckPolicy para o serviço.
Não é possível especificar um número de porta diretamente no nome do host (por exemplo, web.example.com:80) para roteamento de tráfego.
É possível visualizar os recursos do balanceador de carga que o GKE cria para gateways no Console do Google Cloud, mas esses recursos não fazem referência ao gateway ou ao cluster do GKE ao qual estão anexados.

Não é possível gerar automaticamente um certificado SSL gerenciado pelo Google com gateways, mas é possível criar e referenciar manualmente um certificado SSL gerenciado pelo Google. Para mais informações, consulte Proteger um gateway.

O HTTPRoute é o único tipo de rota suportado. TCPRoutes, UDPRoutes e TLSRoutes não são compatíveis. Para ver uma lista de campos compatíveis com o controlador do gateway do GKE, consulte Recursos do GatewayClass.
Os cabeçalhos de solicitação e resposta personalizados com gateway ou redirecionamentos de caminho e substituições de URL com gateway só estão disponíveis no GKE versão 1.27 ou posterior.

Para cabeçalhos de solicitação e resposta personalizados com gateway e redirecionamentos de caminho e substituições de URL com gateway, o GatewayClass gke-l7-gxlb não é compatível.

Ao configurar cabeçalhos personalizados de solicitação e resposta do HTTPRoute, as seguintes variáveis do Google Cloud não são compatíveis:
- cdn_cache_id (o Cloud CDN não é compatível com o GKE Gateway)
- cdn_cache_status (o Cloud CDN não é compatível com o GKE Gateway)
- origin_request_header (as políticas CORS não são compatíveis com o gateway do GKE)
O GKE Gateway não é compatível com o recurso de balanceamento de carga do Cloud CDN.

Cabeçalhos personalizados TLS mútuos não são compatíveis (não é possível usar mTLS com o GKE Gateway)
As limitações do balanceador de carga de aplicativo clássico do Google Cloud se aplicam ao gateway do GKE, com uma limitação extra:
- Não é possível configurar um cabeçalho de resposta do host personalizado no serviço de back-end.
Os redirecionamentos de caminho e substituições de URL são mutuamente exclusivos. Não é possível usar os dois filtros ao mesmo tempo nas mesmas regras.
O Cloud Load Balancing não permite redirecionar o tráfego para uma porta diferente. Para ver uma lista de campos compatíveis com o controlador do gateway do GKE, consulte Recursos do GatewayClass.
O GKE Gateway não é compatível com caracteres curinga, expressões regulares e URLs dinâmicos.
Se você especificar um gateway com uma classe de gateway externo regional, o controlador provisionará um endereço IP interno em vez do endereço externo. Para saber como usar um endereço nomeado com o balanceador de carga de aplicativo externo regional, consulte Implantar um gateway externo regional.
O gateway usa NEGs autônomos para provisionar grupos de endpoints de rede. Para garantir que o Gateway Controller reconcilie corretamente a configuração do balanceador de carga, não é possível modificar a anotação cloud.google.com/neg de um Serviço que faz parte do gateway.
O GKE Gateway não permite referência a um Serviço que também é referenciado por um GKE Ingress.
Quando um Gateway é configurado para provisionar um endereço, não é possível alterar o Gateway.spec.gatewayClass. Para garantir que o Gateway Controller reconcilie corretamente o balanceador de carga, exclua o gateway que já existe e reimplante o manifesto com o valor gatewayClass atualizado.
A anotação networking.gke.io/app-protocols não é compatível. Use o campo appProtocol para ter o mesmo resultado.
Se você usar o gateway do GKE com external-dns e o estado de integridade do gateway não estiver íntegro, por padrão, todos os registros DNS associados ao gateway serão excluídos das suas zonas de DNS. Para evitar a exclusão de registros DNS existentes, recomendamos definir a flag --policy=upsert-only ao executar external-dns.

Ative a API Gateway no cluster

Antes de usar os recursos de gateway no GKE, seu cluster precisa ter a API Gateway ativada.

Criar um novo cluster com a API Gateway ativada

O GKE oferece suporte à API Gateway em clusters do Autopilot a partir da versão 1.26 do GKE. Se você criar novos clusters do Autopilot no GKE 1.26 ou em versões posteriores, a API Gateway vai ser ativada por padrão. Para clusters atuais no GKE versão 1.25 ou anterior, a API Gateway fica desativada por padrão.

Se você criar o cluster primeiro sem especificar uma rede (usando a flag --network), o GKE vai criar o cluster na rede padrão. Nesse caso, também é necessário criar a sub-rede somente proxy na rede padrão. Se você especificar uma rede durante a criação do cluster, verifique se você também criou a sub-rede somente proxy nessa mesma rede.

Piloto automático

Crie um novo cluster do GKE Autopilot com a API Gateway ativada:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=CLUSTER_LOCATION \
      --release-channel=RELEASE_CHANNEL \
      --cluster-version=VERSION

Substitua:

CLUSTER_NAME: o nome do cluster.
CLUSTER_LOCATION: a região ou zona do Compute Engine para o novo cluster.
RELEASE_CHANNEL: o nome do canal de lançamento.
VERSION: a versão do GKE, que precisa ser 1.26 ou posterior. Também é possível usar a sinalização --release-channel para selecionar um canal de lançamento. O canal de lançamento precisa ter a versão padrão 1.26 ou posterior.

Standard

Com o GKE Standard, a API Gateway é controlada pela sinalização --gateway-api. É possível usar o padrão de valor ao ativar e desativar ao desativar.

Crie um novo cluster nativo do VPC do GKE com a API Gateway ativada:

  gcloud container clusters create CLUSTER_NAME \
    --gateway-api=standard \
    --cluster-version=VERSION \
    --location=CLUSTER_LOCATION

Substitua:

RELEASE_CHANNEL: o nome do canal de lançamento.
CLUSTER_NAME: o nome do cluster.
VERSION: a versão do GKE, que precisa ser 1.24 ou posterior. Também é possível usar a sinalização --release-channel para selecionar um canal de lançamento. O canal de lançamento precisa ter a versão padrão 1.24 ou posterior.
CLUSTER_LOCATION: a região ou zona do Compute Engine para o novo cluster.

O flag --gateway-api=standard instrui o GKE a instalar os CRDs v1beta1 com o cluster.

Ativar a API Gateway em um cluster atual

Verifique se a versão do cluster do Autopilot é 1.26 ou mais recente e se a versão padrão do cluster é 1.24 ou mais recente.

Para ativar a API Gateway em um cluster do GKE atual (Autopilot ou Standard), use o seguinte:

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

Substitua:

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

O flag --gateway-api=standard instrui o GKE a instalar os CRDs v1beta1 com o cluster.

Verifique o cluster

Depois de criar ou fazer upgrade do cluster, o controlador de gateway do GKE instala automaticamente o GatewayClasses. Pode levar alguns minutos para que o controlador reconheça os CRDs e instale o GatewayClasses.

Confirme se a API Gateway está ativada no plano de controle do GKE:

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

A resposta será semelhante a esta: Se essa saída estiver vazia, execute novamente o comando de atualização do cluster.

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

Confirme se os GatewayClasses estão instalados no cluster:

kubectl get gatewayclass

O resultado será assim:

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 entender os recursos de cada GatewayClass do GKE, consulte Recursos do GatewayClass.

Implantar um gateway interno

Um gateway interno expõe aplicativos que só podem ser acessados pela VPC ou pelas redes conectadas a ela.

Implantar um gateway interno regional

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

Configurar uma sub-rede somente proxy

É preciso configurar uma sub-rede somente proxy antes de criar um gateway que use um balanceador de carga de aplicativo interno. Cada região de uma VPC em que você usa balanceadores de carga de aplicativo internos precisa ter uma sub-rede somente proxy. Essa sub-rede fornece endereços IP internos aos proxies do balanceador de carga.

Criar uma sub-rede somente 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:
- SUBNET_NAME: o nome da sub-rede somente proxy.
- COMPUTE_REGION: a região da sub-rede somente proxy.
- VPC_NETWORK_NAME: o nome da rede VPC em que você cria essa sub-rede somente proxy. Verifique se essa é a mesma rede VPC em que seu cluster do GKE está localizado e onde você implanta o gateway. Isso é importante para uma comunicação perfeita entre o balanceador de carga e os serviços de back-end.
- CIDR_RANGE: o intervalo de endereços IP principal da sub-rede. Use uma máscara de sub-rede de até /26 de comprimento para que ao menos 64 endereços IP estejam disponíveis para os proxies na região. A máscara de sub-rede recomendada é /23.

Verifique sua sub-rede somente proxy:

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

O resultado será assim:

...
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

Criar um gateway

Um recurso de gateway representa um plano de dados que roteia o tráfego no Kubernetes. Um Gateway pode representar vários tipos diferentes de balanceamento de carga e roteamento, dependendo do GatewayClass que o deriva. Para saber mais sobre o recurso Gateway, consulte a descrição do recurso Gateway ou a especificação da API.

Nesse caso, o administrador do cluster do GKE quer criar um gateway que possa ser usado por equipes diferentes para expor aplicativos internamente. O administrador implanta o gateway e as equipes de aplicativo implantam as rotas de maneira independente e as anexam a esse gateway.

Salve o seguinte manifesto de gateway em um arquivo chamado 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
```
Esse manifesto inclui os seguintes campos:
- gatewayClassName: gke-l7-rilb especifica o GatewayClass que deriva este gateway. gke-l7-rilb corresponde ao balanceador de carga interno do aplicativo.
- port: 80 especifica que o gateway expõe apenas a porta 80 para detectar o tráfego HTTP.
Para implantar o gateway no cluster:
```
kubectl apply -f gateway.yaml
```

Verifique se o gateway foi implantado corretamente. Pode levar alguns minutos para implantar todos os recursos.

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

O resultado será assim:

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:  1970-01-01T00:00:00Z
    Message:               Waiting for controller
    Reason:                NotReconciled
    Status:                False
    Type:                  Scheduled
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 ponto, um gateway implantado no cluster já provisionou um balanceador de carga e um endereço IP. No entanto, o gateway não tem rotas e não sabe como enviar tráfego para os back-ends. Sem as rotas, todo o tráfego vai para um back-end padrão, que retorna um HTTP 404. Em seguida, implante um aplicativo e rotas que informam ao gateway como acessar os back-ends do aplicativo.

Implante os aplicativos de demonstração

As equipes de aplicativos podem implantar os próprios aplicativos e rotas independentemente da implantação dos gateways. Em alguns casos, a equipe de aplicativos pode querer ser proprietária do gateway e implantá-lo por conta própria como um recurso dedicado aos aplicativos deles. Consulte Vinculação de rotas para ver diferentes modelos de propriedade de gateways e rotas. No entanto, neste exemplo, a equipe da loja implanta o aplicativo e um HTTPRoute associado para expor o aplicativo dela pelo gateway internal-http criado na seção anterior.

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

Para implantar o aplicativo da loja (store-v1, store-v2 e store-german) no cluster:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
```
Isso cria três implantações e três serviços, chamados store-v1, store-v2 e store-german.

Para validar a implantação do aplicativo:

kubectl get pod

A saída será semelhante à seguinte depois que o aplicativo estiver em execuçã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

Para confirmar que os serviços também foram implantados:

kubectl get service

A saída mostra um serviço para cada implantação de 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

Implante o HTTPRoute

Os recursos de rota definem regras específicas do protocolo que mapeiam o tráfego de um gateway para os back-ends do Kubernetes. O recurso HTTPRoute faz a correspondência e filtragem de tráfego HTTP e HTTPS e é compatível com todas os GatewayClasses gke-l7.

Nesta seção, você verá como implantar um HTTPRoute, que programa o gateway com as regras de roteamento necessárias para alcançar o aplicativo da loja.

Salve o seguinte manifesto HTTPRoute em um arquivo chamado store-route.yaml:

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

Implante o HTTPRoute no cluster:
```
kubectl apply -f store-route.yaml
```
O HTTPRoute store está vinculado ao gateway internal-http usando a propriedade parentRefs: Essas regras de roteamento são configuradas no balanceador de carga subjacente, como neste diagrama:

Essas regras de roteamento processarão o tráfego HTTP da seguinte maneira:
- 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" vai para o Serviço store-v2.
- O tráfego restante para store.example.com vai para o serviço store-v1.

Verifique se o HTTPRoute foi implantado:

kubectl describe httproute store

O resultado será assim:

Name:         store
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         HTTPRoute
<...>
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",
  <...>

Verifique se o HTTPRoute está vinculado ao Gateway:

kubectl describe gateway

O resultado será assim:

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
      <...>

Enviar tráfego para o aplicativo

Agora que o gateway, a rota e o aplicativo estão implantados no cluster, é possível transmitir o tráfego para o aplicativo.

Recuperar o endereço IP do gateway para enviar tráfego ao aplicativo:

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

A saída é um endereço IP.

Envie tráfego para esse endereço IP pelo shell em uma instância de máquina virtual (VM) conectada ao cluster. É possível criar uma VM para essa finalidade. Isso é necessário porque o gateway tem um endereço IP interno. Ele só é acessível na rede VPC. Como internal-http é um balanceador de carga regional, o shell do cliente precisa estar na mesma região que o cluster do GKE.

Faça uma solicitação para store.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 da etapa anterior.

A saída do app de demonstração mostra informações sobre o local em que o app está em execução:
```
{
  "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 caminho acessando a versão em alemão do serviço da loja em store.example.com/de:

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

A resposta confirma que a solicitação foi exibida por um pod store-german:

{
  "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 fim, use o cabeçalho HTTP env: canary para enviar o tráfego à versão canário do serviço de armazenamento:

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

A resposta confirma que a solicitação foi exibida por um pod store-v2:

{
  "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"
}

Implantar um gateway externo

Um gateway externo expõe aplicativos que podem ser acessados pela Internet ou por redes fora da sua VPC. A implantação é semelhante a uma implantação do gateway interno, mas você precisa proteger seus aplicativos porque o gateway é acessível à Internet pública.

Você tem duas opções para criar um gateway externo: um global ou um regional.

Um gateway externo global usa um endereço IP global (ou endereço IP anycast) como o front-end do gateway divulgado em todas as regiões do Google Cloud Compute. Os clientes que enviam tráfego para esse endereço IP anycast são roteados para o local do Google mais próximo em que o IP é divulgado. O gateway externo global só está disponível no Nível de serviço de rede Premium.

Um gateway externo regional usa um IP regional como o front-end do gateway divulgado apenas na região local do Google Cloud Compute em que o gateway externo regional é implantado. Os clientes que enviam tráfego para esse endereço IP regional são roteados pelo ISP local e pela Internet antes de chegar à região do Google em que o IP é divulgado. O gateway externo regional está disponível apenas no Nível de serviço de rede Standard.

Implantar um gateway externo global

O exemplo a seguir mostra como expor um aplicativo de loja com vários certificados anexados ao gateway externo global e agrupados em um mapa de certificados usando o Gerenciador de certificados e um HTTPRoute.

Criar um CertificateMap

O Google recomenda usar o Gerenciador de certificados para gerenciar os certificados quando você precisar de 15 ou mais certificados por gateway ou quando precisar usar certificados curinga.

Também é possível proteger o gateway externo usando secrets do Kubernetes ou certificados SSL gerenciados pelo Google. Para mais informações, consulte Segurança do gateway.

Nesta seção, você cria certificados usando o Gerenciador de certificados para proteger os aplicativos em execução no cluster.

Ative a API Certificate Manager:

gcloud services enable certificatemanager.googleapis.com

Criar um CertificateMap

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

Carregue suas chaves e seu certificado gerenciado pelo Google em um Certificado:
```
gcloud beta certificate-manager certificates create store-example-com-cert \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE"
```
Substitua:
- CERTIFICATE_FILE: o nome do novo arquivo escolhido. O arquivo precisa ter a extensão .pem. Por exemplo, cert.pem.
- PRIVATE_KEY_FILE: o nome do arquivo da chave privada.
Para mais informações, consulte Como criar 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 usando outras fontes de certificados, como secrets do Kubernetes ou certificados SSL, consulte Proteger um gateway.

Criar um gateway

Um recurso de gateway representa um plano de dados que roteia o tráfego no Kubernetes. Um Gateway pode representar muitos tipos diferentes de balanceamento de carga e roteamento, dependendo da GatewayClass usada.

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

Nesta seção, você vai criar um gateway. As equipes de aplicativos podem usar o gateway para expor seus aplicativos à Internet implantando as rotas de maneira independente e anexando-as com segurança ao gateway.

Salve o seguinte manifesto em um arquivo chamado gateway.yaml:
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  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 o GatewayClass para esse gateway. Esta classe de gateway usa um balanceador de carga de aplicativo externo global.
- protocol: HTTPS e port: 443: especifica que o gateway expõe a porta 443 para o tráfego HTTPS. Esses campos ativam o TLS.
- networking.gke.io/certmap: store-example-com-map: especifica o nome do mapa de certificados no Gerenciador de certificados.
Não há uma seção TLS porque o TLS está configurado com o Gerenciador de certificados usando a anotação networking.gke.io/certmap.
Aplique o manifesto ao cluster:
```
kubectl apply -f gateway.yaml
```
Pode levar alguns minutos para o GKE implantar os recursos.
Verifique se o gateway foi implantado:
```
kubectl describe gateway
```
O resultado será assim:
```
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
 ...
```
Esta saída mostra que o gateway implantado no cluster tem um balanceador 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 as rotas, todo o tráfego vai para um back-end padrão, que retorna um HTTP 404. Na próxima seção, você implantará rotas, que instrui o gateway a enviar tráfego para back-ends.

Implante os aplicativos de demonstração

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

Implante o aplicativo de amostra no cluster:

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

Esse aplicativo cria três implantações e três serviços, chamados store-v1, store-v2 e store-german.

Para validar a implantação do aplicativo:

kubectl get pod

O resultado será assim:

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 implantados:

kubectl get service

O resultado será assim:

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

Criar um HTTPRoute

Nesta seção, você implantará um HTTPRoute, que configura o Gateway com regras de roteamento necessárias para acessar o aplicativo de amostra.

Salve o seguinte manifesto em um arquivo chamado store-route-external.yaml:

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

Esse manifesto descreve um HTTPRoute que faz referência ao Gateway external-http.

Aplique o manifesto ao cluster:
```
kubectl apply -f store-route-external.yaml
```
O HTTPRoute store está vinculado ao gateway external-http usando a propriedade parentRefs: Veja no diagrama a seguir as regras de roteamento configuradas no balanceador de carga subjacente:

As regras de roteamento processam tráfego HTTP da seguinte maneira:
- Tráfego para store.example.com/de, trajeto para o serviço store-german.
- O tráfego para store.example.com com o cabeçalho HTTP "env: canary" encaminha para o serviço store-v2.
- O tráfego restante para os trajetos store.example.com é enviado para o serviço store-v1.

Verifique se o HTTPRoute foi implantado:

kubectl describe httproute store-external

O resultado será assim:

Name:         store-external
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         HTTPRoute
<...>
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:
    Conditions:
      Last Transition Time:  2022-11-01T05:42:31Z
      Message:
      Reason:                Accepted
      Status:                True
      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á vinculado ao Gateway:

kubectl describe gateway external-http

O resultado será assim:

Name:         external-http
Namespace:    default
Labels:       <none>
<...>
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
      <...>

Enviar tráfego para o aplicativo

Agora que o gateway, a rota e o aplicativo estão implantados no cluster, é possível transmitir o tráfego para o aplicativo.

Consiga o endereço IP do gateway:

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

A saída é um endereço IP.

Crie uma VM:
```
gcloud cloud-shell ssh
```

Enviar tráfego para o endereço IP do gateway a partir da VM. Defina o cabeçalho do host manualmente, porque você não é o proprietário do nome do host 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 da etapa anterior.

A saída mostra informações do app de demonstração sobre o local em que ele está em execução:

{
  "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 caminho acessando a versão em alemão do serviço store da loja em store.example.com/de:

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

A resposta confirma que a solicitação foi exibida por um pod store-german:

{
  "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 o tráfego para a versão canário do serviço store usando o cabeçalho HTTP env: canary:

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

A resposta confirma que a solicitação foi exibida por um pod store-v2:

{
  "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"
}

Implantar um gateway externo regional

O exemplo a seguir mostra como expor um aplicativo de loja com vários certificados anexados ao gateway externo regional usando certificados autogerenciados e um HTTPRoute.

Criar uma sub-rede proxy para o gateway regional

É preciso configurar uma sub-rede somente proxy antes de criar um gateway que usa um balanceador de carga de aplicativo externo regional. Cada região de uma VPC em que você usa o balanceador de carga de aplicativo externo regional precisa ter uma sub-rede external_managed_proxy. Essa sub-rede fornece endereços IP internos aos proxies do balanceador de carga.

Criar um certificado para proteger o tráfego de clientes

É possível usar um certificado emitido e validado pela autoridade certificadora (AC) ou criar um certificado autoassinado. Para mais informações sobre como criar um certificado, consulte Armazenar um certificado em um Secret do Kubernetes.

Criar 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:
- IP_ADDRESS_NAME: o nome do novo endereço IP estático.
- COMPUTE_REGION: a região do Compute Engine em que o cluster está em execução.

Crie um gateway de balanceador de carga de aplicativo externo regional usando um certificado autogerenciado da seguinte maneira e salve o manifesto como regional-gateway.yaml:

  kind: Gateway
  apiVersion: gateway.networking.k8s.io/v1beta1
  metadata:
    name: external-regional-http
  spec:
    gatewayClassName: gke-l7-regional-external-managed
    listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
        - name: store-example-com
    addresses:
    - type: NamedAddress
      value: IP_ADDRESS_NAME

Aplique o manifesto regional-gateway:

  kubectl apply -f regional-gateway.yaml

Verifique a configuração.

  kubectl get gateway

O resultado será assim:

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 será assim:

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
  ...

Implantar o aplicativo de demonstração

É possível implantar aplicativos e rotas independentemente da implantação de gateways.

Para mais informações sobre como implantar os aplicativos de demonstração, consulte este link.

Criar um HTTPRoute

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

Enviar tráfego para o aplicativo

Depois de implantar o aplicativo e criar HTTPRoutes, é possível transmitir tráfego para ele.

Para mais informações sobre como enviar tráfego para o aplicativo, consulte este link.

Usar gateways compartilhados

As APIs Gateway usam recursos separados, gateways e recursos de rota para implantar balanceadores de carga e regras de roteamento. Isso é diferente do Ingress, que combina tudo em um recurso. Ao dividir a responsabilidade entre recursos, o gateway permite que o balanceador de carga e as regras de roteamento dele sejam implantados separadamente e implantados por diferentes usuários ou equipes. Isso permite que gateways se tornem gateways compartilhados que se anexam a muitas rotas diferentes, que podem ser gerenciadas por equipes independentes e de propriedade total delas, mesmo em namespaces diferentes.

Implantar rotas em um gateway compartilhado

Este exemplo se baseia no gateway internal-http implantado em Implantar um gateway interno.

Neste exemplo, a equipe do site implanta o aplicativo dela, os serviços e um HTTPRoute correspondente ao tráfego do gateway a esses serviços.

Implantar o aplicativo de exemplo:

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

Salve o seguinte manifesto em um arquivo chamado site-route-internal.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: site-internal
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "site.example.com"
  rules:
  - backendRefs:
    - name: site-v1
      port: 8080

Esse manifesto descreve um HTTPRoute que corresponde a todo o tráfego de site.example.com e o encaminha ao serviço site-v1.

Aplique o manifesto ao cluster:

kubectl apply -f site-route-internal.yaml

Verifique se o HTTPRoute está vinculado ao Gateway:

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

O resultado será assim:

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 do gateway for True, o HTTPRoute foi vinculado corretamente ao gateway. Para saber mais sobre o campo "Status", consulte Status da rota.

Verifique se o tráfego para o gateway é roteado 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.

Use uma máquina virtual (VM) na mesma VPC que o gateway.

O resultado será assim:

{
  "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"
}

Configurar o back-end padrão do gateway

Todas as gke-l7-* GatewayClasses retornam HTTP 404 para tráfego sem correspondência. É possível configurar o back-end padrão usando uma rota padrão explícita que envia tráfego incomparável a um serviço fornecido pelo usuário.

O HTTPRoute a seguir é um exemplo de como personalizar o back-end padrão. Se você aplicar uma HTTPRoute semelhante às seguintes, ela terá precedência sobre o back-end padrão implícito:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Esse HTTPRoute corresponde a todo o tráfego de um gateway específico. Só é possível ter uma regra assim para cada gateway. Caso contrário, as regras entrarão em conflito, e a ordem de precedência será aplicada.

É possível usar um back-end padrão para evitar que alguém crie um back-end de rota padrão que direcione todo o tráfego do gateway. Um HTTPRoute explícito sempre tem precedência sobre novos HTTPRoutes com regras de roteamento conflitantes.

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

Cada gateway tem um endereço IP que usa para detectar o tráfego. Se você não especificar um endereço IP no Gateway, o controlador do Gateway fornecerá automaticamente um endereço IP. Também é possível criar um endereço IP estático para que ele exista, independentemente do ciclo de vida do gateway.

Depois que um gateway é implantado, o endereço IP dele é exibido no campo de status:

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

Dependendo da GatewayClass, o endereço IP é alocado das seguintes sub-redes:

GatewayClasses	Pool de endereços IP padrão
gke-l7-rilb gke-l7-rilb-mc	Endereços IP particulares 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 do 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 do Google

O campo addresses.NamedAddress permite especificar um endereço IP independentemente do gateway. É possível criar um recurso de endereço IP estático antes da implantação do gateway, e o recurso é referenciado pelo NamedAddress. Reutilize o endereço IP estático mesmo que o gateway seja excluído.

Usar um endereço IP nomeado

É possível configurar um endereço IPv4 ou IPv6 especificando um NamedAddress. É preciso provisionar 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:
- IP_ADDRESS_NAME: o nome do novo endereço IP estático.
- COMPUTE_REGION: para gateways regionais, a região do Compute Engine em que o cluster está em execução. Essa flag não é necessária para gateways globais externos.
- SUBNET: a sub-rede do endereço IP. Essa flag não é necessária para gateways globais externos.
- PROJECT_ID: o projeto em que o cluster do GKE está em execução.

Salve o seguinte manifesto em um arquivo chamado 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

Esse manifesto descreve um gateway que faz referência ao endereço IP nomeado.

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

Verifique o endereço IP do gateway:

kubectl describe gateway internal-http

O resultado será assim:

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

Configurar redirecionamentos de HTTP para HTTPS

O Cloud Load Balancing oferece redirecionamento de HTTP para HTTPS. Um balanceador de carga de aplicativo externo redireciona as solicitações HTTP não criptografadas para um balanceador de carga HTTPS que usa o mesmo endereço IP. Quando você cria um gateway com redirecionamentos de HTTP para HTTPS ativados, os dois balanceadores de carga são criados automaticamente. As solicitações para o endereço IP externo do Gateway na porta 80 são redirecionadas automaticamente para o mesmo endereço IP externo na porta 443.

Por padrão, os redirecionamentos de HTTP para HTTPS não são definidos no gateway.

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

Os exemplos a seguir mostram como usar o redirecionamento de HTTP para HTTPS para garantir que o tráfego dos clientes que vai para os aplicativos da Web seja sempre redirecionado para uma página segura.

Redirecionar o tráfego HTTP de um namespace de infraestrutura

Em alguns casos, não há uma distinção clara entre as equipes de administrador de infraestrutura ou de plataforma e a prevenção do uso indevido do Gateway.

O exemplo a seguir restringe ainda mais o uso do listener HTTP para impedir o uso não intencional de protocolos não seguros por parte das equipes do aplicativo. Este exemplo configura o gateway para permitir que um HTTPRoute use o listener HTTP apenas se a rota estiver em um determinado namespace (http-redirect) enquanto abre o listener HTTPS para todos os namespaces. É possível restringir o namespace http-redirect usando o RBAC do Kubernetes para que as equipes de aplicativo não possam criar um HTTPRoute nesse namespace por engano.

Crie o namespace de um gateway. Salve 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 namespace de um gateway e salve o manifesto como redirect-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: http-redirect
  labels:
    otherInfra: httpToHttps
```
- Identificadores específicos estão definidos para esse namespace.

Aplique o manifesto:

kubectl apply -f redirect-namespace.yaml

Para restringir o uso do listener http, crie um gateway usando o manifesto a seguir. Salve o manifesto como external-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  namespace: gateway-infra
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: selector
        selector:
          matchLabels:
            otherInfra: httpToHttps
  - name: https
    protocol: HTTPS
    port: 443
    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 namespace gateway-infra.
O campo namespaces na seção allowedRoutes restringe o listener HTTP ao namespace correspondente ao rótulo otherInfra: httpToHttps.

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

Para forçar o redirecionamento HTTPS, crie um HTTPRoute padrão usando o seguinte manifesto. Salve o manifesto como http-redirect.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: redirect
  namespace: http-redirect
spec:
  parentRefs:
  - namespace: gateway-infra
    name: external-http
    sectionName: http
  rules:
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https

O campo sectionName instrui o gateway a corresponder apenas ao listener http. O filtro RequestRedirect força o redirecionamento para o listener https.

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

Crie um serviço para um aplicativo que usa o manifesto a seguir. Salve 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.2.20
        ports:
        - containerPort: 8080
        env:
        - name: METADATA
          value: "store-v1"

Aplique o manifesto:

kubectl apply -f service-deployment.yaml

Crie um HTTPRoute para um aplicativo que só permita HTTPS usando o manifesto a seguir. Salve o manifesto como http-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  parentRefs:
  - name: external-http
    namespace: gateway-infra
    sectionName: https
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

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

Configurar redirecionamentos de caminho e substituições de URL

Os redirecionamentos de caminho envolvem redirecionar uma solicitação recebida de um caminho de URL para outro. Os redirecionamentos de caminho permitem alterar a estrutura do URL quando precisar lidar com URLs desatualizados ou descontinuados.

As substituições de URL ajudam a modificar o URL recebido antes de processá-lo no servidor. Isso permite alterar a estrutura ou o formato do URL sem alterar de fato a estrutura do arquivo ou o conteúdo subjacente. A substituição de URL é vantajosa para criar URLs fáceis de lembrar e de entender para usuários e SEO. Por padrão, os redirecionamentos de caminho e as substituições de URL não estão configurados. Você precisa configurar explicitamente esses redirecionamentos ou substituições usando um filtro no seu HTTPRoute.

O GKE Gateway é compatível com redirecionamentos de caminho e substituições de URL. Para mais informações, consulte Redirecionamentos de caminho HTTP e substituições.

Configurar redirecionamentos de caminho

É possível configurar redirecionamentos de caminho para substituir o caminho inteiro ou apenas um prefixo no URL.

Substituir o caminho inteiro

Para substituir um caminho inteiro, configure um filtro em um HTTPRoute que substitui qualquer URL contendo o prefixo /any-path no caminho do URL pelo valor restrito /new-path.

Crie um manifesto HTTPRoute da seguinte maneira e nomeie-o como 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:
          type: PathPrefix
          value: /any-path
      filters:
      - type: RequestRedirect
        requestRedirect:
          path:
            type: ReplaceFullPath
            replaceFullPath: /new-path
          statusCode: 302

Por exemplo, esse manifesto define uma regra de roteamento para um HTTPRoute da seguinte maneira: qualquer rota para o URL https://store.example.com/any-path/... será redirecionada para um novo local, https://store.example.com/new-path/ (restrito).

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

Essa regra de roteamento segue uma regra de redirecionamento restrito, o que significa que o navegador não tenta armazenar o redirecionamento em cache. Em vez disso, ele redireciona para a versão mais recente.

Substituir apenas um prefixo

Para substituir apenas um prefixo, configure um filtro em um HTTPRoute que substitui qualquer URL contendo o prefixo /any-prefix no caminho do URL pelo valor restrito /new-prefix.

Crie um manifesto HTTPRoute da seguinte maneira e nomeie-o como 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:
          type: PathPrefix
          value: /any-prefix
    filters:
    - type: RequestRedirect
      requestRedirect:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /new-prefix
        statusCode: 302

Por exemplo, esse manifesto define uma regra de roteamento para um HTTPRoute da seguinte maneira: qualquer rota para o URL https://store.example.com/any-path/v1/... será redirecionada para um novo local, https://store.example.com/new-path/v1/... (somente).

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

Essa regra de roteamento segue a regra de redirecionamento único, que garante que o navegador sempre redirecione você para a mesma página pretendida.

Configurar substituições de URL

Defina substituições de URL para alterar como o URL aparece para os usuários. É possível usar substituições de URL para torná-los mais fáceis de usar, melhorar SEO ou para redirecionar os usuários a uma nova página.

Substituir o nome do host inteiro

Para substituir o nome do host inteiro:

Configure um filtro em um HTTPRoute que instrui o gateway a substituir as informações do Host no cabeçalho da solicitação de www.example.com para store.example.com antes de encaminhar a solicitação ao serviço de back-end.

Crie um manifesto HTTPRoute da seguinte maneira e nomeie-o como 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
        urlRewrite:
          hostname: store.example.com
      backendRefs:
      - name: store-v1
        port: 8080

Por exemplo, com a configuração acima, qualquer solicitação para https://www.example.com é encaminhada para o serviço de back-end com o cabeçalho Host: store.example.com, no lugar de Host: www.example.com.

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

Substituir usando modificadores de caminho

É possível combinar substituições com modificadores de caminho para fornecer modificações avançadas de URL e caminho antes de redirecionar a solicitação para o serviço de back-end.

Para substituir usando modificadores de caminho:

Configure um filtro em um HTTPRoute que instrui o gateway a substituir as informações do "Host" no cabeçalho da solicitação de www.example.com para store.example.com e substitua o valor /store por / antes de encaminhar a solicitação ao serviço de back-end.

Crie um manifesto HTTPRoute da seguinte maneira e nomeie-o como 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
        urlRewrite:
          hostname: store.example.com
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /de
      backendRefs:
      - name: store-german
        port: 8080

Por exemplo, com a configuração acima, qualquer solicitação para https://www.example.com/store/... é encaminhada para o serviço de back-end com Host: store.example.com no cabeçalho da solicitação (no lugar de Host: www.example.com), e /store é substituído por /de.

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

Verifique a configuração

Para verificar se o filtro foi aplicado depois de criar seu HTTPRoute com filtros de substituição de URL ou redirecionamentos de caminho, faça isto:

kubectl get httproute www -o yaml

O resultado será assim:

  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

Configurar cabeçalhos de solicitação e resposta personalizados

Os cabeçalhos de solicitação e resposta personalizados permitem especificar cabeçalhos adicionais para solicitações e respostas HTTP(S). Dependendo das informações detectadas pelo balanceador de carga, esses 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 conexão TLS

Por padrão, não há cabeçalhos personalizados adicionados à solicitação enviada aos seus serviços de back-end ou recebida deles. É necessário configurar explicitamente os cabeçalhos personalizados usando um filtro no seu HTTPRoute.

É possível configurar cabeçalhos personalizados adicionando uma seção de filtro às regras do HTTPRoute da seguinte maneira:

Configurar cabeçalhos de solicitação personalizados

Crie um manifesto do HTTPRoute com um filtro RequestHeaderModifier e salve-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

Configurar cabeçalhos de resposta personalizados

Crie um manifesto do HTTPRoute com um filtro ResponseHeaderModifier e salve-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

É possível adicionar, definir e remover cabeçalhos conforme descrito na Implementação da API Gateway. É possível configurar o HTTPRoute com um cabeçalho personalizado usando as variáveis compatíveis do Google Cloud.

Exemplo 1:

Para configurar um HTTPRoute que adiciona informações de local do cliente à solicitação HTTP antes de enviá-las ao serviço de back-end, crie um manifesto do HTTPRoute e nomeie-o como 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:
          - 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, na França, o gateway adiciona um cabeçalho como X-Client-Geo-Location:FR,Strasbourg.

Exemplo 2:

Para configurar um HTTPRoute que adiciona um cabeçalho de resposta personalizado compatível com o HTTP Strict Transport Security, crie um manifesto do HTTPRoute e nomeie-o como 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:
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Verifique a configuração

Para verificar a configuração depois de configurar os cabeçalhos de solicitação e resposta personalizados, faça isto:
```
  kubectl get httproute
```
O resultado será assim:
```
  NAME    HOSTNAMES               AGE
  store   ["store.example.com"]   4d23h
```

Para ver mais detalhes, use o comando "describe":

  kubectl describe httproute

O resultado será assim:

  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:
    <...>

Status da rota

Os recursos de HTTPRoute emitem condições e eventos para ajudar os usuários a entender se um HTTPRoute foi vinculado a um ou mais Gateways ou se ele foi rejeitado.

Condições do HTTPRoute

As condições do HTTPRoute indicam o status da Rota e dos Gateways aos quais ela está vinculada. Como uma rota pode ser vinculada a vários gateways, mostraremos uma lista de gateways e as condições individuais entre a rota e cada gateway.

Accepted=True indica que o HTTPRoute está vinculado a um Gateway.
Accepted=False indica que a vinculação do HTTPRoute foi rejeitada com esse gateway.

Se não houver gateways listados no título Gateway bindings, os rótulos HTTPRoute e seletores de rótulos de gateway podem não corresponder. Isso pode ocorrer se a rota não está sendo selecionada por nenhum gateway.

Eventos do HTTPRoute

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

Eventos ADD são acionados por um recurso que está sendo adicionado.
Os eventos UPDATE são acionados por um recurso que está sendo atualizado.
Os eventos SYNC são acionados pela reconciliação periódica.

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

Precedência da rota

A API Gateway define regras de precedência rígidas que definem como o tráfego é correspondido por rotas que tenham regras de roteamento sobrepostas. A precedência entre dois HTTPRoutes sobrepostos é a seguinte:

Mesclagem de nomes do host: a correspondência de nome do host mais longa ou mais específica.
Mesclagem de caminho: a correspondência de caminho mais longa ou mais específica.
Mesclagem de cabeçalhos: o maior número de cabeçalhos HTTP correspondentes.
Conflito: se as três regras anteriores não estabelecerem precedência, a precedência irá para o recurso HTTPRoute com o carimbo de data/hora mais antigo.

Mesclagem de rotas

Para GatewayClasses gke-l7, todos os HTTPRoutes de um determinado gateway são mesclados no mesmo recurso de mapa de URL. A maneira como os HTTPRoutes são mesclados depende do tipo de sobreposição entre HTTPRoutes. O HTTPRoute do exemplo anterior pode ser dividido em três HTTPRoutes separados para ilustrar a mesclagem e a precedência de rotas:

Mesclagem de rotas: todas as três HTTPRoutes são anexadas com o mesmo gateway de internal-http para que sejam mescladas.
Mesclagem de nome do host: todas as três rotas correspondem a store.example.com. Portanto, as regras de nome de host delas são mescladas.
Mesclagem de caminhos: store-german-route tem um caminho /de mais específico. Portanto, ele não é mesclado. As rotas store-v1-route e store-v2-route também correspondem ao mesmo caminho /*, então são mesclados ao caminho.
Mesclagem de cabeçalho: store-v2-route tem um conjunto mais específico de correspondências de cabeçalho HTTP do que store-v1-route e, portanto, não são combinados.
Conflito: como as rotas podem ser mescladas no nome do host, no caminho e nos cabeçalhos, não há conflitos, e todas as regras de roteamento serão aplicadas ao tráfego.

O único HTTPRoute usado 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

Observe que a API Gateway do Kubernetes e a API do Istio têm um recurso chamado Gateway. Eles executam funções semelhantes, mas não são a mesma funcionalidade. Se você estiver usando o Istio e a API Gateway no mesmo cluster do Kubernetes, esses nomes serão sobrepostos ao usar o kubectl na linha de comando. kubectl get gateway pode retornar 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 usando o Istio e fizer upgrade para o GKE 1.20 e posterior, é recomendável começar a usar o nome curto do recurso do gateway ou especificar o grupo da API. A abreviação de um gateway do Kubernetes é gtw e a abreviação de um gateway do Istio é gw. Os comandos a seguir retornam os recursos do gateway do Kubernetes e do Istio, respectivamente.

# 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

Solução de problemas

Sub-rede somente proxy ausente na região

Sintoma:

O seguinte problema pode ocorrer ao criar 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:

Essa mensagem de erro indica que não existe sub-rede somente proxy na região do seu gateway.

Alternativa:

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

Já existe uma sub-rede somente proxy na região com a finalidade incorreta

Sintoma:

O seguinte problema pode ocorrer quando você cria uma sub-rede somente proxy para 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:

Essa mensagem de erro indica que você tentou criar uma sub-rede somente proxy regional em uma região que já tem uma sub-rede somente proxy.

Alternativa:

Para resolver esse problema, use os passos a seguir:

Verifique se já existe uma sub-rede somente proxy na região e se ela tem a finalidade correta:
1. Liste suas sub-redes para descobrir qual delas é a sub-rede somente proxy na região:
```
gcloud compute networks subnets list --regions=COMPUTE_REGION
```
  Substitua COMPUTE_REGION pela região do Compute Engine em que você quer criar o gateway regional.
2. Descreva a sub-rede somente proxy na região para encontrar a finalidade dela:
```
gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
    --region COMPUTE_REGION | grep -E 'name|purpose'
```
  Substitua PROXY_ONLY_SUBNET pela sub-rede somente proxy.
O gateway do GKE só oferece suporte a sub-redes somente proxy REGIONAL_MANAGED_PROXY para gateways regionais (internos ou regionais).
Se a sub-rede somente proxy atual na região foi criada com uma finalidade INTERNAL_HTTPS_LOAD_BALANCER, migre a finalidade dela para REGIONAL_MANAGED_PROXY.

Nenhum upstream íntegro

Sintoma:

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

no healthy upstream

Motivo:

Esta mensagem de erro indica que a sondagem da verificação de integridade não consegue encontrar a integridade dos serviços de back-end. É possível que os serviços de back-end estejam íntegros, mas talvez seja necessário personalizar as verificações de integridade.

Alternativa:

Para resolver esse problema, personalize a verificação de integridade com base nas condições (por exemplo, /health) usando um HealthCheckPolicy.

A seguir

Saiba mais sobre o controlador de gateway.
Saiba como Configurar recursos de gateway usando políticas.