Configuração de entrada

---

Vista geral

Esta página oferece uma vista geral abrangente do que pode configurar através da entrada do Kubernetes noGoogle Cloud. O documento também compara as funcionalidades suportadas para a entrada no Google Cloud e fornece instruções para configurar a entrada através do controlador predefinido, dos parâmetros FrontendConfig e dos parâmetros BackendConfig.

Esta página destina-se a especialistas de redes que concebem e arquitetam a rede para a respetiva organização, bem como instalam, configuram e suportam equipamento de rede. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Comparação de funcionalidades

A tabela seguinte apresenta uma lista das funcionalidades suportadas para o Ingress no Google Cloud. A disponibilidade da funcionalidade, disponibilidade geral (DG) ou versão beta, também é indicada.

Classe de entrada	Entrada externa	Entrada interna	Entrada em vários clusters
Controlador de entrada	Controlador de entrada alojado na Google
Google Cloud tipo de balanceador de carga	Balanceador de carga HTTP(S) externo	Balanceador de carga HTTP(S) interno	Balanceador de carga HTTP(S) externo
Âmbito do cluster	Cluster único	Cluster único	Vários clusters
Âmbito do balanceador de carga	Global	Regional	Global
Apoio técnico do ambiente	GKE	GKE	GKE
Suporte da VPC partilhada	GA	GA	GA
Anotações de serviços
Balanceamento de carga nativa do contentor (NEGs)	GA	GA	GA
HTTPS do balanceador de carga para os back-ends	GA	GA	GA
HTTP/2	GA	GA Apenas TLS	GA
Anotações de entrada
Endereços IP estáticos	GA	GA	GA
Certificados baseados em secrets do Kubernetes	GA	GA	GA
Certificados SSL autogeridos	GA	GA	GA
Certificados SSL geridos pela Google	GA		GA
FrontendConfig
Política de SSL	GA	GA com gateway	GA
Redirecionamento de HTTP para HTTPS	GA 1.17.13-gke.2600+^GA		GA
BackendConfig
Limite de tempo do serviço de back-end	GA	GA	GA
Cloud CDN	GA		GA
Limite de tempo de drenagem da ligação	GA	GA	GA
Configuração personalizada da verificação de funcionamento do balanceador de carga	GA	GA	GA
Política de segurança do Google Cloud Armor	GA 1.19.10-gke.700^G		GA
Configuração do registo de acesso HTTP	GA	GA	GA
Identity-Aware Proxy (IAP)	GA	GA	GA
Afinidade com a sessão	GA	GA	GA
Cabeçalhos de pedidos definidos pelo utilizador	GA		GA
Cabeçalhos de resposta personalizados	GA 1.25-gke+^G	GA 1.25-gke+^G

^BEsta funcionalidade está disponível na versão beta a partir da versão especificada. As funcionalidades sem uma versão listada são suportadas para todas as versões do GKE disponíveis.

^GEsta funcionalidade é suportada como GA a partir da versão especificada.

Configurar o Ingress através do controlador predefinido

Não pode configurar manualmente as funcionalidades do LoadBalancer através do Google Cloud SDK nem da Google Cloud consola. Tem de usar recursos do Kubernetes BackendConfig ou FrontendConfig.

Quando cria uma entrada com o controlador predefinido, pode escolher o tipo de balanceador de carga (um balanceador de carga de aplicações externo ou um balanceador de carga de aplicações interno) através de uma anotação no objeto de entrada. Pode escolher se o GKE cria NEGs zonais ou se usa grupos de instâncias através de uma anotação em cada objeto de serviço.

As definições de recursos personalizados (CRDs) FrontendConfig e BackendConfig permitem personalizar ainda mais o equilibrador de carga. Estes CRDs permitem-lhe definir funcionalidades do equilibrador de carga hierarquicamente, de uma forma mais estruturada do que as anotações. Para usar o Ingress (e estes CRDs), tem de ter o suplemento de balanceamento de carga HTTP ativado. Os clusters do GKE têm o balanceamento de carga HTTP ativado por predefinição. Não o deve desativar.

As FrontendConfigs são referenciadas num objeto Ingress e só podem ser usadas com Ingresses externos. Os BackendConfigs são referenciados por um objeto Service. Os mesmos CRDs podem ser referenciados por vários objetos Service ou Ingress para garantir a consistência da configuração. Os CRDs FrontendConfig e BackendConfig partilham o mesmo ciclo de vida que os respetivos recursos Ingress e Service e são frequentemente implementados em conjunto.

O diagrama seguinte ilustra como:

• Uma anotação num objeto Ingress ou MultiClusterIngress faz referência a um CRD FrontendConfig. O CRD FrontendConfig faz referência a uma Google Cloud política de SSL.

• Uma anotação num objeto Service ou MultiClusterService faz referência a um CRD BackendConfig. O CRD BackendConfig especifica definições personalizadas para a verificação de estado do serviço de back-end correspondente.

Figura: vista geral de BackendConfig e FrontendConfig

Associar FrontendConfig ao seu Ingress

Só é possível usar o FrontendConfig com entradas externas.

Pode associar um FrontendConfig a um Ingress ou a um MultiClusterIngress.

Entrada

Use a anotação networking.gke.io/v1beta1.FrontendConfig:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...

Substitua FRONTENDCONFIG_NAME pelo nome do seu FrontendConfig.

MultiClusterIngress

Use a anotação networking.gke.io/frontend-config:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "FRONTENDCONFIG_NAME"
...

Substitua FRONTENDCONFIG_NAME pelo nome do seu FrontendConfig.

Associar BackendConfig ao seu Ingress

Pode usar a anotação cloud.google.com/backend-config ou beta.cloud.google.com/backend-config para especificar o nome de um BackendConfig.

O mesmo BackendConfig para todas as portas de serviço

Para usar o mesmo BackendConfig para todas as portas, use a chave default na anotação. O controlador Ingress usa o mesmo BackendConfig sempre que cria um serviço de back-end do balanceador de carga para referenciar uma das portas do serviço.

Pode usar a chave default para recursos Ingress e MultiClusterIngress.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

BackendConfig único por porta de serviço

Para o Ingress e o MultiClusterIngress, pode especificar um BackendConfig personalizado para uma ou mais portas através de uma chave que corresponda ao nome ou ao número da porta. O controlador Ingress usa o BackendConfig específico quando cria um serviço de back-end do balanceador de carga para uma porta de serviço referenciada.

GKE 1.16-gke.3 e posteriores

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Todas as versões suportadas

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
      PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
      PORT_NAME_2:"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Substitua o seguinte:

• BACKENDCONFIG_REFERENCE_A: o nome de um BackendConfig existente.
• BACKENDCONFIG_REFERENCE_B: o nome de um BackendConfig existente.
• SERVICE_REFERENCE_A: use o valor de PORT_NUMBER_1 ou PORT_NAME_1. Isto deve-se ao facto de uma anotação BackendConfig de um serviço poder referir-se ao nome da porta (spec.ports[].name) ou ao número da porta (spec.ports[].port).
• SERVICE_REFERENCE_B: use o valor de PORT_NUMBER_2 ou PORT_NAME_2. Isto deve-se ao facto de uma anotação BackendConfig de um serviço poder referir-se ao nome da porta (spec.ports[].name) ou ao número da porta (spec.ports[].port).

Quando se refere à porta do serviço por número, tem de usar o valor port em vez do valor targetPort. O número da porta usado aqui destina-se apenas à associação do BackendConfig. Não controla a porta para a qual o balanceador de carga envia tráfego ou sondas de verificação de funcionamento:

• Quando usar o equilíbrio de carga nativo do contentor, o equilibrador de carga envia tráfego para um ponto final num grupo de pontos finais de rede (que corresponde a um endereço IP do pod) na porta do serviço referenciado targetPort (que tem de corresponder a um containerPort para um pod de publicação). Caso contrário, o balanceador de carga envia tráfego para o endereço IP de um nó na porta de serviço referenciadanodePort.

• Quando usa um BackendConfig para fornecer uma verificação de estado do balanceador de carga personalizada, o número da porta que usa para a verificação de estado do balanceador de carga pode diferir do número spec.ports[].port do serviço. Para ver detalhes sobre os números das portas para verificações de funcionamento, consulte o artigo Configuração personalizada de verificações de funcionamento.

Nota: a porta de serviço associada ao BackendConfig também tem de ser usada no campo de definição do Ingress backend.service.port. Se a porta de serviço não for usada em nenhum objeto Ingress, o BackendConfig é ignorado.

Configurar funcionalidades de entrada através de parâmetros FrontendConfig

A secção seguinte mostra como definir o FrontendConfig para ativar funcionalidades específicas do Ingress.

Políticas de SSL

As políticas SSL permitem especificar um conjunto de versões TLS e cifras que o equilibrador de carga usa para terminar o tráfego HTTPS dos clientes. Primeiro, tem de criar uma política de SSL fora do GKE. Depois de criado, pode fazer referência ao mesmo num FrontendConfig CRD.

O campo sslPolicy no FrontendConfig faz referência ao nome de uma política SSL no mesmo Google Cloud projeto que o cluster do GKE. Associa a política SSL ao proxy HTTPS de destino, que foi criado para o balanceador de carga HTTP(S) externo pelo Ingress. O mesmo recurso FrontendConfig e política SSL podem ser referenciados por vários recursos Ingress. Se uma política SSL referenciada for alterada, a alteração é propagada para os Google Front Ends (GFEs) que alimentam o balanceador de carga de HTTP(S) externo criado pelo Ingress.

O manifesto FrontendConfig seguinte ativa uma política SSL denominada gke-ingress-ssl-policy:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

Redirecionamentos de HTTP para HTTPS

Um balanceador de carga HTTP externo pode redirecionar pedidos HTTP não encriptados para um balanceador de carga HTTPS que use o mesmo endereço IP. Quando cria um Ingress com redirecionamentos de HTTP para HTTPS ativados, ambos os balanceadores de carga são criados automaticamente. Os pedidos para o endereço IP externo do Ingress na porta 80 são automaticamente redirecionados para o mesmo endereço IP externo na porta 443. Esta funcionalidade baseia-se nos redirecionamentos de HTTP para HTTPS fornecidos pelo Cloud Load Balancing.

Para suportar o redirecionamento de HTTP para HTTPS, um Ingress tem de ser configurado para publicar tráfego HTTP e HTTPS. Se o HTTP ou o HTTPS estiver desativado, o redirecionamento não funciona.

Os redirecionamentos de HTTP para HTTPS são configurados através do campo redirectToHttps num recurso personalizado FrontendConfig. Os redirecionamentos estão ativados para todo o recurso Ingress, pelo que todos os serviços referenciados pelo Ingress têm os redirecionamentos HTTPS ativados.

O seguinte manifesto FrontendConfig permite redirecionamentos de HTTP para HTTPS. Defina o campo spec.redirectToHttps.enabled como true para ativar os redirecionamentos HTTPS. O campo spec.responseCodeName é opcional. Se for omitido, é usado um redirecionamento 301 Moved Permanently.

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: RESPONSE_CODE

Substitua RESPONSE_CODE por uma das seguintes opções:

• MOVED_PERMANENTLY_DEFAULT para devolver um código de resposta de redirecionamento 301 (predefinição se responseCodeName não for especificado).
• FOUND para devolver um código de resposta de redirecionamento 302.
• SEE_OTHER para devolver um código de resposta de redirecionamento 303.
• TEMPORARY_REDIRECT para devolver um código de resposta de redirecionamento 307.
• PERMANENT_REDIRECT para devolver um código de resposta de redirecionamento 308.

Quando os redirecionamentos estão ativados, o controlador de entrada cria um equilibrador de carga, conforme mostrado no seguinte diagrama:

Para validar se o redirecionamento está a funcionar, use um comando curl:

curl http://IP_ADDRESS

Substitua IP_ADDRESS pelo endereço IP do seu Ingress.

A resposta mostra o código de resposta de redirecionamento que configurou. Por exemplo, o seguinte exemplo destina-se a um FrontendConfig configurado com um redirecionamento 301: MovedPermanently:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>

Configurar funcionalidades de entrada através de parâmetros BackendConfig

As secções seguintes mostram como definir o BackendConfig para ativar funcionalidades específicas do Ingress. As alterações a um recurso BackendConfig são reconciliadas constantemente, pelo que não precisa de eliminar e recriar o seu Ingress para ver as alterações do BackendConfig refletidas.

Para informações sobre as limitações do BackendConfig, consulte a secção Limitações.

Limite de tempo do serviço de back-end

Pode usar um BackendConfig para definir um período de tempo limite do serviço de back-end em segundos. Se não especificar um valor, o valor predefinido é 30 segundos.

O manifesto BackendConfig seguinte especifica um limite de tempo de 40 segundos:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

Pode ativar o Cloud CDN através de um BackendConfig.

Nota: não pode ativar o IAP e o Cloud CDN num BackendConfig. Se o BackendConfig não tiver um bloco iap, as definições de IAP existentes no serviço de back-end são herdadas.

O manifesto BackendConfig seguinte mostra todos os campos disponíveis quando ativa o Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: CDN_ENABLED
    cachePolicy:
      includeHost: INCLUDE_HOST
      includeProtocol: INCLUDE_PROTOCOL
      includeQueryString: INCLUDE_QUERY_STRING
      # Specify only one of queryStringBlacklist and queryStringWhitelist.
      queryStringBlacklist: QUERY_STRING_DENYLIST
      queryStringWhitelist: QUERY_STRING_ALLOWLIST
    cacheMode: CACHE_MODE
    clientTtl: CLIENT_TTL
    defaultTtl: DEFAULT_TTL
    maxTtl: MAX_TTL
    negativeCaching: NEGATIVE_CACHING
    negativeCachingPolicy:
      code: NEGATIVE_CACHING_CODE
      ttl: NEGATIVE_CACHING_TTL
    requestCoalescing: REQ_COALESCING
    # Time, in seconds, to continue serving a stale version after request expiry.
    serveWhileStale: SERVE_WHILE_STALE
    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
    signedUrlKeys:
      keyName: KEY_NAME
      keyValue: KEY_VALUE
      secretName: SECRET_NAME

Substitua o seguinte:

• CDN_ENABLED: se estiver definido como true, o Cloud CDN está ativado para este back-end do Ingress.
• INCLUDE_HOST: se estiver definido como true, os pedidos a diferentes anfitriões são colocados em cache separadamente.
• INCLUDE_PROTOCOL: se estiver definido como true, os pedidos HTTP e HTTPS são colocados em cache separadamente.
• INCLUDE_QUERY_STRING: se estiver definido como true, os parâmetros da sequência de carateres de consulta são incluídos na chave da cache de acordo com queryStringBlacklist ou queryStringWhitelist. Se nenhuma estiver definida, toda a string de consulta é incluída. Se estiver definido como false, toda a string de consulta é excluída da chave da cache.
• QUERY_STRING_DENYLIST: especifique uma matriz de strings com os nomes dos parâmetros de string de consulta a excluir das chaves de cache. Todos os outros parâmetros estão incluídos. Pode especificar queryStringBlacklist ou queryStringWhitelist, mas não ambos.
• QUERY_STRING_ALLOWLIST: especifique uma matriz de strings com os nomes dos parâmetros de string de consulta a incluir nas chaves da cache. Todos os outros parâmetros são excluídos. Pode queryStringBlacklist ou queryStringWhitelist, mas não ambos.

Os seguintes campos só são suportados nas versões do GKE 1.23.3-gke.900 e posteriores através do GKE Ingress. Não são suportados com a entrada em vários clusters:

• CACHE_MODE: O modo de cache.
• CLIENT_TTL, DEFAULT_TTL, e MAX_TTL: configuração de TTL. Para mais informações, consulte o artigo Usar definições e substituições de TTL.
• NEGATIVE_CACHING: se estiver definido como true, a colocação em cache negativa é ativada. Para mais informações, consulte o artigo Usar o armazenamento em cache negativo.
• NEGATIVE_CACHING_CODE e NEGATIVE_CACHING_TTL: configuração de colocação em cache negativa. Para mais informações, consulte o artigo Usar o armazenamento em cache negativo.
• REQ_COALESCING: se estiver definido como true, a redução está ativada. Para mais informações, consulte o artigo Redução de pedidos (união).
• SERVE_WHILE_STALE: tempo, em segundos, após a expiração da resposta, durante o qual o Cloud CDN continua a publicar uma versão desatualizada. Para mais informações, consulte o artigo Apresentar conteúdo desatualizado.
• SIGNED_MAX_AGE: tempo máximo durante o qual as respostas podem ser armazenadas em cache, em segundos. Para mais informações, consulte a secção Personalizar opcionalmente o tempo máximo de cache.
• KEY_NAME, KEY_VALUE e SECRET_NAME: configuração da chave do URL assinado. Para mais informações, consulte o artigo Criar chaves de pedidos assinados.

Expanda a secção seguinte para ver um exemplo que implementa a RFC de multimédia na nuvem através do Ingress e, em seguida, valida se o conteúdo da aplicação está a ser colocado em cache.

Exemplo do Cloud CDN

Para usar um BackendConfig para configurar a RFC do Google Cloud, execute as seguintes tarefas:

1. Crie um espaço de nomes dedicado para executar este exemplo:
   

   kubectl create namespace cdn-how-to
   

2. Crie um ficheiro de implementação denominado my-deployment.yaml com base no seguinte manifesto de implementação. Este manifesto declara que quer executar duas réplicas da aplicação Web ingress-gce-echo-amd64.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     namespace: cdn-how-to
     name: my-deployment
   spec:
     selector:
       matchLabels:
         purpose: demonstrate-cdn
     replicas: 2
     template:
       metadata:
         labels:
           purpose: demonstrate-cdn
       spec:
         containers:
         - name: echo-amd64
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app-cdn:1.0

3. Crie o recurso de implementação:

   kubectl apply -f my-deployment.yaml
   

4. Crie um BackendConfig denominado my-backendconfig.yaml com base no seguinte manifesto BackendConfig. O manifesto especifica uma política de cache do Cloud CDN e declara que o Cloud CDN deve ser ativado:

     apiVersion: cloud.google.com/v1
     kind: BackendConfig
     metadata:
       namespace: cdn-how-to
       name: my-backendconfig
     spec:
       cdn:
         enabled: true
         cachePolicy:
           includeHost: true
           includeProtocol: true
           includeQueryString: false

5. Crie o recurso BackendConfig:

   kubectl apply -f my-backendconfig.yaml
   

6. Crie um ficheiro denominado my-service.yaml com base no seguinte manifesto de serviço:

   apiVersion: v1
   kind: Service
   metadata:
     namespace: cdn-how-to
     name: my-service
     labels:
       purpose: demonstrate-cdn
     # Use a custom BackendConfig for port 80 in the Service.
     annotations:
       cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
   spec:
     type: NodePort
     selector:
       purpose: demonstrate-cdn
     ports:
     - port: 80
       protocol: TCP
       targetPort: 8080

7. Crie o recurso Service:

   kubectl apply -f my-service.yaml
   

8. Crie um endereço IP reservado:

   gcloud compute addresses create cdn-how-to-address --global
   

9. Crie um ficheiro denominado my-ingress.yaml com base no seguinte manifesto de entrada:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     namespace: cdn-how-to
     name: my-ingress
     annotations:
       kubernetes.io/ingress.global-static-ip-name: "cdn-how-to-address"
   spec:
     rules:
     # Route all incoming HTTP requests to port 80 in the example Service.
     - http:
         paths:
         - path: /*
           pathType: ImplementationSpecific
           backend:
             service:
               name: my-service
               port:
                 number: 80

10. Crie o recurso Ingress:

    kubectl apply -f my-ingress.yaml
    

11. Aguarde aproximadamente dez minutos para que o controlador de entrada do Kubernetes configure um balanceador de carga e, em seguida, obtenha o endereço IP usado pelas regras de encaminhamento do balanceador de carga a partir do recurso de entrada. Google Cloud

    kubectl describe ingress my-ingress --namespace=cdn-how-to | grep "Address"
    

    Saída:

    Address:         ADDRESS
    

    ADDRESS é o seu endereço IP externo de entrada.

Valide o armazenamento em cache do Cloud CDN

Para validar se o seu conteúdo está a ser colocado em cache, introduza este curl comando duas vezes:

curl -v ADDRESS/?cache=true

Substitua ADDRESS pelo endereço IP externo do Ingress.

O resultado mostra os cabeçalhos e o corpo da resposta. Nos cabeçalhos de resposta, pode ver que o conteúdo foi colocado em cache. O cabeçalho Age indica durante quantos segundos o conteúdo foi colocado em cache:

HTTP/1.1 200 OK
Date: Fri, 25 Jan 2019 02:34:08 GMT
Content-Length: 70
Content-Type: text/plain; charset=utf-8
Via: 1.1 google
Cache-Control: max-age=86400,public
Age: 2716

Hello, world!
Version: 1.0.0
Hostname: my-deployment-7f589cc5bc-l8kr8
...

Se verificar que o seu conteúdo não está a ser colocado em cache, certifique-se de que a sua aplicação está configurada corretamente para ativar a colocação em cache de conteúdo. Para mais informações, consulte o artigo Conteúdo em cache.

Limpar

Para evitar cobranças indesejadas na sua conta, liberte o endereço IP estático que reservou:

gcloud compute addresses delete cdn-how-to-address --global

Limite de tempo de drenagem da ligação

Pode configurar o tempo limite de esgotamento de ligações através de um BackendConfig. O limite de tempo de drenagem da ligação é o tempo, em segundos, a aguardar que as ligações sejam drenadas. Durante a duração especificada do limite de tempo, os pedidos existentes ao back-end removido têm tempo para serem concluídos. O equilibrador de carga não envia novos pedidos ao back-end removido. Quando a duração do tempo limite é atingida, todas as ligações restantes ao back-end são fechadas. A duração do limite de tempo pode ser de 0 a 3600 segundos. O valor predefinido é 0, o que também desativa a drenagem de ligações.

Aviso: definir um valor elevado para drainingTimeoutSec (por exemplo, 3600 segundos) num Ingress ou num serviço que use grupos de instâncias vai causar atrasos proporcionais à duração definida em drainingTimeoutSec quando atualizar outros recursos Ingress no cluster. Isto deve-se ao facto de todos os recursos de entrada baseados em grupos de instâncias num cluster partilharem o mesmo grupo de instâncias. Se precisar de um valor elevado, considere usar serviços suportados por grupos de pontos finais de rede.

O manifesto BackendConfig seguinte especifica um limite de tempo de esgotamento da ligação de 60 segundos:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

Configuração personalizada da verificação de funcionamento

Existem várias formas de o GKE configurar as verificações de estado do balanceador de carga quando a implementação é feita através do Ingress.Google Cloud Para saber como o GKE Ingress implementa verificações de estado, consulte o artigo Verificações de estado do Ingress.

Um BackendConfig permite-lhe controlar com precisão as definições de verificação de funcionamento do balanceador de carga.

Nota: o Ingress não suporta gRPC para configurações de verificação de estado personalizadas.

Pode configurar vários serviços GKE para referenciar o mesmo BackendConfig como um modelo reutilizável. Para parâmetros healthCheck, é criada uma verificação de estado única para cada serviço de back-end correspondente a cada serviço do GKE.Google Cloud

O manifesto BackendConfig seguinte mostra todos os campos disponíveis quando configura uma verificação de estado do BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    # Time, in seconds, between prober checks. Default is `5`.
    checkIntervalSec: INTERVAL
    # Probe timeout period. Must be less than or equal to checkIntervalSec.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    # Protocol to use. Must be `HTTP`, `HTTP2`, or `HTTPS`.
    type: PROTOCOL
    # Path for probe to use. Default is `/`.
    requestPath: PATH
    # Port number of the load balancer health check port. Default is `80`.
    port: PORT

Substitua o seguinte:

• INTERVAL: especifique o check-interval, em segundos, para cada verificador de estado. Este é o tempo desde o início da verificação de um verificador até ao início da sua verificação seguinte. Se omitir este parâmetro, é usada a predefinição de 5 segundos. Google Cloud Para ver detalhes de implementação adicionais, consulte o artigo Várias sondagens e frequência.
• TIMEOUT: especifique o tempo que Google Cloud espera por uma resposta a uma sondagem. O valor de TIMEOUT tem de ser inferior ou igual a INTERVAL. As unidades são segundos. Cada teste requer um código de resposta HTTP 200 (OK) a ser enviado antes do limite de tempo do teste.
• HEALTH_THRESHOLD e UNHEALTHY_THRESHOLD: especifique o número de tentativas de ligação sequenciais que têm de ser bem-sucedidas ou falhar, para, pelo menos, um verificador, de modo a alterar o estado de funcionamento de bom para mau ou vice-versa. Se omitir um destes parâmetros, o valor predefinido de 2 é usado.Google Cloud
• PROTOCOL: especifique um protocolo usado pelos sistemas de sondagem para a verificação do estado. O BackendConfig só suporta a criação de verificações de estado de funcionamento através dos protocolos HTTP, HTTPS ou HTTP2. Para mais informações, consulte os critérios de êxito para HTTP, HTTPS e HTTP/2. Não pode omitir este parâmetro.
• PATH: para verificações de estado de HTTP, HTTPS ou HTTP2, especifique a request-path à qual o sistema de sondagem deve estabelecer ligação. Se omitir este parâmetro, oGoogle Cloud usa a predefinição de /.

• PORT: um BackendConfig só suporta a especificação da porta de verificação do estado do balanceador de carga através de um número de porta. Se omitir este parâmetro, Google Cloud usa o valor predefinido 80.

  • Quando usar o equilíbrio de carga nativo do contentor, deve selecionar uma porta que corresponda a um containerPort de um pod de publicação (quer esse containerPort seja ou não referenciado por um targetPort do serviço). Uma vez que o balanceador de carga envia sondagens diretamente para o endereço IP do pod, não está limitado aos containerPorts referenciados pelo targetPort de um serviço. Os sistemas de sondagem de verificação do estado de funcionamento ligam-se ao endereço IP do pod de publicação na porta especificada.

  • Por exemplo, para grupos de back-ends, tem de selecionar uma porta que corresponda a nodePort exposta pelo serviço. Os sistemas de sondagem de verificação de saúde estabelecem ligação a cada nó nessa porta.

Para configurar o GKE Ingress com uma verificação de funcionamento de HTTP personalizada, consulte o artigo GKE Ingress com verificação de funcionamento de HTTP personalizada.

Política de segurança de entrada do Google Cloud Armor

As políticas de segurança do Google Cloud Armor ajudam a proteger as suas aplicações com balanceamento de carga contra ataques baseados na Web. Depois de configurar uma política de segurança do Google Cloud Armor, pode fazer referência à mesma através de um BackendConfig.

Adicione o nome da sua política de segurança ao BackendConfig. O manifesto BackendConfig seguinte especifica uma política de segurança denominada example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Aviso: não deve modificar diretamente os recursos BackendService no Compute Engine para anexar as suas políticas do Cloud Armor aos serviços de back-end geridos pelo GKE.

Duas fontes de informações verdadeiras

Embora configuradas através do GKE, as APIs BackendService do Compute Engine subjacentes podem continuar a ser usadas para modificar diretamente a política de segurança a aplicar. Isto cria duas fontes de verdade: GKE e Compute Engine. O comportamento do controlador de entrada do GKE em resposta ao campo securityPolicy em BackendConfig está documentado na tabela abaixo. Para evitar conflitos e comportamentos inesperados, recomendamos que use o GKE BackendConfig para gerir a política de segurança a usar.

Campo BackendConfig	Valor	Comportamento
spec.securityPolicy.name	CloudArmorPolicyName	O controlador de entrada do GKE define a política do Cloud Armor denominada CloudArmorPolicyName para o equilibrador de carga. O controlador de entrada do GKE substitui qualquer política definida anteriormente.
spec.securityPolicy.name	String vazia ("")	O controlador de entrada do GKE remove qualquer política do Cloud Armor configurada do balanceador de carga.
spec.securityPolicy	nil	O controlador de entrada do GKE usa a configuração definida no objeto BackendService configurado através da API Compute Engine usando a consola, a CLI gcloud ou o Terraform. Google Cloud

Para configurar o GKE Ingress com a proteção do Google Cloud Armor, consulte o artigo Ingress com o Google Cloud Armor ativado.

Registo de acesso HTTP

Nota: por predefinição, o GKE ativa o registo de acesso para todos os tipos de entrada (incluindo a entrada de vários clusters). A definição de registo de acesso para o GKE Ingress não era suportada para versões do GKE anteriores a 1.16.8-gke.10. Para as versões 1.16.8-gke.10 ou posteriores do GKE, pode configurar a definição de registo de acesso para o GKE Ingress através do BackendConfig.

O Ingress pode registar todos os pedidos HTTP de clientes no Cloud Logging. Pode ativar e desativar o registo de acesso através do BackendConfig, juntamente com a definição da taxa de amostragem do registo de acesso.

Para configurar o registo de acesso, use o campo logging no seu BackendConfig. Se logging for omitido, o registo de acesso assume o comportamento predefinido. Isto depende da versão do GKE.

Pode configurar os seguintes campos:

• enable: se estiver definida como true, o registo de acesso é ativado para este Ingress e os registos estão disponíveis no Cloud Logging. Caso contrário, o registo de acesso está desativado para este Ingress.
• sampleRate: especifique um valor de 0,0 a 1,0, em que 0,0 significa que não são registados pacotes e 1,0 significa que 100% dos pacotes são registados. Este campo só é relevante se enable estiver definido como true. sampleRate é um campo opcional, mas se estiver configurado, enable: true também tem de ser definido. Caso contrário, é interpretado como enable: false.

O manifesto BackendConfig seguinte ativa o registo de acesso e define a taxa de amostragem para 50% dos pedidos HTTP de um determinado recurso Ingress:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

Para configurar o BackendConfig para o Identity-Aware Proxy IAP, tem de especificar os valores enabled e secretName no bloco iap do BackendConfig. Para especificar estes valores, certifique-se de que o agente do serviço do GKE tem a autorização compute.backendServices.update.

Nota: não pode ativar o IAP e o Cloud CDN num BackendConfig. Se o BackendConfig não tiver um bloco iap, as definições de IAP existentes no serviço de back-end são herdadas.

O seguinte manifesto BackendConfig ativa o Identity-Aware Proxy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Ative a IAP com o cliente OAuth gerido pela Google

A partir do GKE 1.29.4-gke.1043000, o IAP pode ser configurado para usar o cliente OAuth gerido pela Google através de um BackendConfig. Para decidir se deve usar o cliente OAuth gerido pela Google ou um cliente OAuth personalizado, consulte o artigo Quando usar uma configuração OAuth personalizada na documentação do IAP.

Para ativar as IAP com o cliente OAuth gerido pela Google, não faculte as OAuthCredentials no BackendConfig. Para os utilizadores que já configuraram a IAP através de OAuthCredentials, não existe um caminho de migração para mudar para a utilização do cliente OAuth gerido pela Google: tem de recriar o back-end (remover o serviço do Ingress e voltar a anexá-lo). Sugerimos que realize esta operação durante um período de manutenção, uma vez que vai causar tempo de inatividade. O caminho de migração oposto, a mudança do cliente OAuth gerido pela Google para OAuthCredentials, é possível.

O manifesto BackendConfig seguinte ativa o Identity-Aware Proxy com o cliente OAuth gerido pela Google:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true

Para ver instruções completas, consulte o artigo Ativar a IAP para o GKE na documentação da IAP.

Nota: se estiver a usar CNAs nas versões 1.29.2-gke.1521000, 1.29.3-gke.1093000, 1.29.3-gke.1093002 ou 1.29.3-gke.1282000 do cluster do GKE, para garantir que não há interrupções, atualize para a versão 1.29.4-gke.1043000 do cluster do GKE.

Identity-Aware Proxy com entrada interna

Para configurar a entrada interna para as CAs, tem de usar o nível Premium. Se não usar o nível Premium, não pode ver nem criar balanceadores de carga de aplicações internos com o Identity-Aware Proxy. Também tem de ter uma subscrição do Chrome Enterprise Premium para usar o Ingress interno para o IAP.

Para configurar o GKE Ingress seguro com autenticação baseada no Identity-Aware Proxy, consulte o exemplo Ingress ativado para o IAP.

Afinidade de sessão

Pode usar um BackendConfig para definir a afinidade de sessão para o IP do cliente ou o cookie gerado.

Importante: use um cluster nativo da VPC se quiser configurar a afinidade de sessão. A afinidade de sessão só é útil para serviços suportados por grupos de pontos finais da rede e os grupos de pontos finais da rede requerem um cluster nativo da VPC.

Afinidade de IP do cliente

Para usar um BackendConfig para definir a afinidade de IP do cliente, defina affinityType como "CLIENT_IP", conforme no exemplo seguinte:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

Afinidade de cookie gerado

Para usar um BackendConfig para definir a afinidade de cookies gerada , defina affinityType como GENERATED_COOKIE no manifesto do BackendConfig. Também pode usar affinityCookieTtlSec para definir o período durante o qual o cookie permanece ativo.

O manifesto seguinte define o tipo de afinidade como cookie gerado e atribui aos cookies um TTL de 50 segundos:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

Cabeçalhos de pedidos definidos pelo utilizador

Pode usar um BackendConfig para configurar cabeçalhos de pedidos definidos pelo utilizador. O equilibrador de carga adiciona os cabeçalhos especificados aos pedidos que encaminha para os back-ends.

O equilibrador de carga adiciona cabeçalhos de pedidos personalizados apenas aos pedidos do cliente e não às sondagens de verificação do estado. Se o seu back-end exigir um cabeçalho específico para autorização que esteja em falta no pacote de verificação de funcionamento, a verificação de funcionamento pode falhar.

Para ativar os cabeçalhos de pedidos definidos pelo utilizador, especifique uma lista de cabeçalhos na propriedade customRequestHeaders do recurso BackendConfig. Especifique cada cabeçalho como uma string header-name:header-value.

O manifesto BackendConfig seguinte adiciona três cabeçalhos de pedidos:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

Cabeçalhos das respostas personalizados

Para ativar os cabeçalhos de resposta personalizados, especifique uma lista de cabeçalhos na propriedade customResponseHeaders do recurso BackendConfig. Especifique cada cabeçalho como uma string header-name:header-value.

Os cabeçalhos de resposta personalizados só estão disponíveis em clusters do GKE na versão 1.25 e posteriores.

O seguinte manifesto BackendConfig é um exemplo para adicionar um cabeçalho de resposta HTTP Strict Transport Security (HSTS):

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customResponseHeaders:
    headers:
    - "Strict-Transport-Security: max-age=28800; includeSubDomains"

Exercício: definir limites de tempo de Ingress com um serviço de back-end

O exercício seguinte mostra os passos necessários para configurar os limites de tempo e a drenagem de ligações com um Ingress com um recurso BackendConfig.

Para configurar as propriedades de back-end de um Ingress, conclua as seguintes tarefas:

1. Crie uma implementação.
2. Crie um BackendConfig.
3. Crie um serviço e associe uma das respetivas portas ao BackendConfig.
4. Crie um Ingress e associe-o ao par (serviço, porta).
5. Valide as propriedades do serviço de back-end.
6. Limpar.

Criar uma implementação

Antes de criar um BackendConfig e um serviço, tem de criar uma implementação.

O manifesto de exemplo seguinte destina-se a uma implementação denominada my-deployment.yaml:

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Crie a implementação executando o seguinte comando:

kubectl apply -f my-deployment.yaml

Criar um BackendConfig

Use o BackendConfig para especificar as funcionalidades do Ingress que quer usar.

Este manifesto BackendConfig, denominado my-backendconfig.yaml, especifica:

• Um limite de tempo de 40 segundos.
• Um limite de tempo de drenagem da ligação de 60 segundos.

# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

Crie o BackendConfig executando o seguinte comando:

kubectl apply -f my-backendconfig.yaml

Criar um serviço

Um BackendConfig corresponde a uma única combinação de Service-Port, mesmo que um Service tenha várias portas. Cada porta pode ser associada a um único CRD BackendConfig. Se uma porta de serviço for referenciada por um Ingress e se a porta de serviço estiver associada a um BackendConfig, o serviço de back-end de balanceamento de carga HTTP(S) recebe parte da respetiva configuração do BackendConfig.

Segue-se um exemplo de um manifesto de serviço denominado my-service.yaml:

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  # Associate the Service with Pods that have the same label.
  labels:
    purpose: bsc-config-demo
  annotations:
    # Associate TCP port 80 with a BackendConfig.
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  # Forward requests from port 80 in the Service to port 8080 in a member Pod.
  - port: 80
    protocol: TCP
    targetPort: 8080

A anotação cloud.google.com/backend-config especifica um mapeamento entre portas e objetos BackendConfig. Em my-service.yaml:

• Qualquer Pod com a etiqueta purpose: bsc-config-demo é membro do serviço.
• A porta TCP 80 do serviço está associada a um BackendConfig denominado my-backendconfig. A anotação cloud.google.com/backend-config especifica esta informação.
• Um pedido enviado para a porta 80 do serviço é encaminhado para um dos pods membros na porta 8080.

Para criar o serviço, execute o seguinte comando:

kubectl apply -f my-service.yaml

Criar uma entrada

Segue-se um manifesto de entrada denominado my-ingress.yaml.. Neste exemplo, os pedidos recebidos são encaminhados para a porta 80 do serviço denominado my-service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  # Route all HTTP requests to port 80 in a Service.
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-service
            port:
              number: 80

Para criar o Ingress, execute o seguinte comando:

kubectl apply -f my-ingress.yaml

Aguarde alguns minutos para que o controlador de entrada configure um balanceador de carga de aplicações externo e um serviço de back-end associado. Quando este processo estiver concluído, configurou o Ingress para usar um limite de tempo de 40 segundos e um limite de tempo de esgotamento da ligação de 60 segundos.

A validar as propriedades do serviço de back-end

Pode validar se as definições do equilibrador de carga corretas foram aplicadas através do BackendConfig. Para o fazer, identifique o serviço de back-end que o Ingress implementou e inspecione as respetivas definições para validar se correspondem aos manifestos de implementação.

Primeiro, descreva o recurso my-ingress e filtre a anotação que apresenta os serviços de back-end associados ao Ingress. Por exemplo:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

Deverá ver uma saída semelhante à seguinte:

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

O resultado fornece informações sobre os seus serviços de back-end. Por exemplo, esta anotação contém dois serviços de back-end:

• "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" fornece informações acerca do serviço de back-end associado ao my-service Kubernetes Service.
  • k8s1-27fde173 é um hash usado para descrever o cluster.
  • default é o espaço de nomes do Kubernetes.
  • HEALTHY indica que o back-end está em bom estado.
• "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" fornece informações sobre o serviço de back-end associado ao back-end predefinido (404-server).
  • k8s1-27fde173 é um hash usado para descrever o cluster.
  • kube-system é o espaço de nomes.
  • default-http-backend é o nome do serviço Kubernetes.
  • 80 é a porta do anfitrião.
  • HEALTHY indica que o back-end está em bom estado.

Em seguida, inspecione o serviço de back-end associado a my-service através do gcloud. Filtre por "drainingTimeoutSec" e "timeoutSec" para confirmar que foram definidos no plano de controlo do equilibrador de carga. Google Cloud Por exemplo:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

Saída:

  drainingTimeoutSec: 60
  timeoutSec: 40

A apresentação de drainingTimeoutSec e timeoutSec no resultado confirma que os respetivos valores foram definidos corretamente através do BackendConfig.

Limpar

Para evitar cobranças indesejadas na sua conta, elimine os objetos do Kubernetes que criou para este exercício:

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

Limitações do BackendConfig

As BackendConfigs têm as seguintes limitações:

• Apenas um par (serviço, porta) pode consumir apenas um BackendConfig, mesmo que vários objetos Ingress referenciem o par (serviço, porta). Isto significa que todos os objetos Ingress que referenciam o mesmo (serviço, porta) têm de usar a mesma configuração para o Cloud Armor, o IAP e o Cloud CDN.

• Não é possível ativar o IAP e o Cloud CDN para o mesmo serviço de back-end do balanceamento de carga de HTTP(S). Isto significa que não pode configurar o IAP e a RFC na nuvem no mesmo BackendConfig.

• Tem de usar a versão kubectl 1.7 ou posterior para interagir com o BackendConfig.

Remover a configuração especificada num FrontendConfig ou num BackendConfig

Para revogar uma funcionalidade do Ingress, tem de desativar explicitamente a configuração da funcionalidade no CRD FrontendConfig ou BackendConfig. O controlador Ingress reconcilia apenas as configurações especificadas nestes CRDs.

Para limpar ou desativar uma configuração ativada anteriormente, defina o valor do campo como uma string vazia ("") ou como um valor booleano de false, consoante o tipo de campo.

O seguinte manifesto BackendConfig desativa uma política de segurança do Google Cloud Armor e o Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

Eliminar um FrontendConfig ou um BackendConfig

FrontendConfig

Para eliminar uma FrontendConfig, siga estes passos:

1. Remova o nome do FrontendConfig da anotação networking.gke.io/v1beta1.FrontendConfig no manifesto do Ingress.

2. Aplique o manifesto de entrada alterado ao cluster. Por exemplo, use kubectl apply.

3. Elimine o FrontendConfig. Por exemplo, use kubectl delete frontendconfig config my-frontendconfig.

Aviso: não elimine um objeto FrontendConfig antes de remover o respetivo nome da anotação networking.gke.io/v1beta1.FrontendConfig e aplicar o manifesto Ingress atualizado. Se o fizer, a configuração não é removida do serviço de back-end do balanceamento de carga HTTP(S). Além disso, verá erros como eventos do Kubernetes no objeto Ingress.

BackendConfig

Para eliminar um BackedConfig, siga estes passos:

1. Remova o nome do BackendConfig da anotação cloud.google.com/backend-config no manifesto do serviço.

2. Aplique o manifesto do serviço alterado ao cluster. Por exemplo, use kubectl apply.

3. Elimine o BackendConfig. Por exemplo, use kubectl delete backendconfig my-backendconfig.

Aviso: não elimine um objeto BackendConfig antes de remover o respetivo nome da anotação cloud.google.com/backend-config e aplicar o manifesto do serviço atualizado. Se o fizer, a configuração não é removida do serviço de back-end do balanceamento de carga HTTP(S). Além disso, verá erros como eventos do Kubernetes no objeto Ingress.

Resolução de problemas

Pode detetar configurações incorretas comuns através da ferramenta de diagnóstico de entrada. Também deve garantir que as verificações de funcionamento estão configuradas corretamente.

BackendConfig não encontrado

Este erro ocorre quando um BackendConfig para uma porta de serviço é especificado na anotação de serviço, mas o recurso BackendConfig real não foi encontrado.

Para avaliar um evento do Kubernetes, execute o seguinte comando:

kubectl get event

O exemplo de saída que se segue indica que o BackendConfig não foi encontrado:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

Para resolver este problema, certifique-se de que não criou o recurso BackendConfig no espaço de nomes errado nem escreveu incorretamente a respetiva referência na anotação Service.

Política de segurança de entrada não encontrada

Depois de criar o objeto Ingress, se a política de segurança não estiver associada corretamente ao serviço LoadBalancer, avalie o evento do Kubernetes para ver se existe um erro de configuração. Se o seu BackendConfig especificar uma política de segurança que não existe, é emitido periodicamente um evento de aviso.

Para avaliar um evento do Kubernetes, execute o seguinte comando:

kubectl get event

O seguinte resultado de exemplo indica que a sua política de segurança não foi encontrada:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

Para resolver este problema, especifique o nome da política de segurança correto no seu BackendConfig.

Resolver erros da série 500 com NEGs durante o dimensionamento da carga de trabalho no GKE

Sintoma:

Quando usa NEGs aprovisionados pelo GKE para o equilíbrio de carga, pode ter erros 502 ou 503 para os serviços durante a redução da escala da carga de trabalho. Os erros 502 ocorrem quando os pods são terminados antes de as ligações existentes serem fechadas, enquanto os erros 503 ocorrem quando o tráfego é direcionado para pods eliminados.

Este problema pode afetar os clusters se estiver a usar produtos de equilíbrio de carga geridos pelo GKE que usam NEGs, incluindo o Gateway, o Ingress e os NEGs autónomos. Se dimensionar frequentemente as suas cargas de trabalho, o cluster corre um risco mais elevado de ser afetado.

Diagnóstico:

A remoção de um pod no Kubernetes sem esvaziar o respetivo ponto final e removê-lo primeiro do NEG resulta em erros da série 500. Para evitar problemas durante a terminação do pod, tem de considerar a ordem das operações. As imagens seguintes mostram cenários quando BackendService Drain Timeout não está definido e BackendService Drain Timeout está definido com BackendConfig.

Nota: a seguinte resolução não é eficaz na resolução de outros erros da série 500 resultantes de preemptions de nós ou pods no GKE, particularmente no caso do GKE com VMs Spot e VMs preemptíveis.

Cenário 1: BackendService Drain Timeout não está definido.

A imagem seguinte apresenta um cenário em que o elemento BackendService Drain Timeout não está definido.

Cenário 2: BackendService Drain Timeout está definido.

A imagem seguinte apresenta um cenário em que o BackendService Drain Timeout está definido.

A altura exata em que ocorrem os erros da série 500 depende dos seguintes fatores:

• Latência de desassociação da API NEG: a latência de desassociação da API NEG representa o tempo atual necessário para a operação de desassociação ser finalizada no Google Cloud. Isto é influenciado por vários fatores externos ao Kubernetes, incluindo o tipo de equilibrador de carga e a zona específica.

• Latência de esgotamento: a latência de esgotamento é o tempo que o equilibrador de carga demora a começar a direcionar o tráfego para longe de uma parte específica do seu sistema. Depois de o esgotamento ser iniciado, o equilibrador de carga deixa de enviar novos pedidos para o ponto final. No entanto, ainda existe uma latência no acionamento do esgotamento (latência de esgotamento), o que pode causar erros 503 temporários se o pod já não existir.

• Configuração da verificação de funcionamento: os limites de verificação de funcionamento mais sensíveis mitigam a duração dos erros 503, uma vez que podem sinalizar ao balanceador de carga que pare de enviar pedidos para os pontos finais, mesmo que a operação de desanexação não tenha terminado.

• Período de tolerância para rescisão: o período de tolerância para rescisão determina o tempo máximo que um pod tem para sair. No entanto, um Pod pode sair antes de o período de tolerância de encerramento ser concluído. Se um agrupamento demorar mais do que este período, o agrupamento é forçado a sair no final deste período. Esta é uma definição no pod e tem de ser configurada na definição da carga de trabalho.

Potencial resolução:

Para evitar esses erros 5XX, aplique as seguintes definições. Os valores de tempo limite são sugestivos e pode ter de os ajustar para a sua aplicação específica. A secção seguinte explica o processo de personalização.

A imagem seguinte mostra como manter o Pod ativo com um gancho preStop:

Para evitar erros da série 500, siga estes passos:

1. Defina o BackendService Drain Timeout para o seu serviço como 1 minuto.

   Nota: se o tempo médio de pedido for superior a 30 segundos, consulte a secção Personalizar limites de tempo para personalizar o BackendService Drain Timeout.

   • Para utilizadores de entrada, consulte defina o limite de tempo no BackendConfig.

   • Para utilizadores do Gateway, consulte configure o limite de tempo na GCPBackendPolicy.

   • Para quem gere os respetivos BackendServices diretamente quando usa NEGs autónomos, consulte defina o limite de tempo diretamente no serviço de back-end.

2. Prolongue a terminationGracePeriod no Pod.

   Defina o terminationGracePeriodSeconds no Pod para 3,5 minutos. Quando combinado com as definições recomendadas, isto permite que os seus Pods tenham uma janela de 30 a 45 segundos para um encerramento normal após o ponto final do Pod ter sido removido do NEG. Se precisar de mais tempo para o encerramento gradual, pode prolongar o período de tolerância ou seguir as instruções mencionadas na secção Personalizar limites de tempo.

   O manifesto do pod seguinte especifica um limite de tempo de esgotamento da ligação de 210 segundos (3,5 minutos):

   spec:
     terminationGracePeriodSeconds: 210
     containers:
     - name: my-app
       ...
     ...
   

3. Aplique um gancho preStop a todos os contentores.

   Aplique um gancho preStop que garanta que o pod está ativo durante mais 120 segundos enquanto o ponto final do pod é esgotado no equilibrador de carga e o ponto final é removido do NEG.

   Nota: aplique o gancho preStop a todos os contentores no seu agrupamento. Os contentores sem o comando vão sair assim que o pod for eliminado. Se usar uma ferramenta que injeta contentores, certifique-se de que os contentores injetados têm o gancho preStop
   necessário.

   spec:
     containers:
     - name: my-app
       ...
       lifecycle:
         preStop:
           exec:
             command: ["/bin/sh", "-c", "sleep 120s"]
     ...
   

Personalize os limites de tempo

Para garantir a continuidade do Pod e evitar erros da série 500, o Pod tem de estar ativo até o ponto final ser removido do NEG. Especificamente para evitar erros 502 e 503, considere implementar uma combinação de limites de tempo e um gancho preStop.

Nota: se a configuração da verificação de funcionamento estiver definida para detetar falhas imediatamente, pode levar os equilibradores de carga a deixarem de enviar pedidos mais cedo, o que pode reduzir a ocorrência de erros 503. No entanto, tenha em atenção que podem continuar a ocorrer erros 503 durante o período do limite não saudável. É essencial compreender que a configuração das verificações de funcionamento não impede os erros 502, que ocorrem quando as ligações existentes são terminadas prematuramente.

Para manter o Pod ativo durante mais tempo durante o processo de encerramento, adicione um gancho preStop ao Pod. Execute o gancho preStop antes de um pod ser sinalizado para sair, para que o gancho preStop possa ser usado para manter o pod ativo até que o respetivo ponto final seja removido do NEG.

Para prolongar a duração durante a qual um Pod permanece ativo durante o processo de encerramento, insira um gancho preStop na configuração do Pod da seguinte forma:

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

Nota: em pods com vários contentores, certifique-se de que adiciona o gancho preStop a cada contentor para manter todos os contentores ativos. Apenas os contentores com o gancho são executados e os restantes são parados. Se estiver a usar uma ferramenta que adiciona contentores, certifique-se de que esses contentores adicionados também têm o gancho preStop necessário.

Pode configurar os limites de tempo e as definições relacionadas para gerir o encerramento controlado dos pods durante as reduções da escala da carga de trabalho. Pode ajustar os limites de tempo com base em exemplos de utilização específicos. Recomendamos que comece com limites de tempo mais longos e reduza a duração conforme necessário. Pode personalizar os limites de tempo configurando os parâmetros relacionados com o limite de tempo e o gancho preStop das seguintes formas:

Limite de tempo de esgotamento do serviço de back-end

O parâmetro Backend Service Drain Timeout não está definido por predefinição e não tem qualquer efeito. Se definir o parâmetro Backend Service Drain Timeout e o ativar, o balanceador de carga deixa de encaminhar novos pedidos para o ponto final e aguarda o limite de tempo antes de terminar as ligações existentes.

Pode definir o parâmetro Backend Service Drain Timeout usando o BackendConfig com o Ingress, o GCPBackendPolicy com o Gateway ou manualmente no BackendService com NEGs autónomos. O limite de tempo deve ser 1,5 a 2 vezes superior ao tempo necessário para processar um pedido. Isto garante que, se um pedido for recebido imediatamente antes de o esgotamento ser iniciado, é concluído antes de o limite de tempo se esgotar. Definir o parâmetro Backend Service Drain Timeout para um valor superior a 0 ajuda a mitigar os erros 503, porque não são enviados novos pedidos para os pontos finais agendados para remoção. Para que este limite de tempo seja eficaz, tem de o usar com o comando preStop para garantir que o Pod permanece ativo enquanto ocorre a drenagem. Sem esta combinação, os pedidos existentes que não foram concluídos recebem um erro 502.

preStop tempo de gancho

O comando preStop tem de atrasar o encerramento do pod o suficiente para que a latência de esgotamento e o limite de tempo de esgotamento do serviço de back-end sejam concluídos, garantindo o esgotamento adequado das ligações e a remoção do ponto final do NEG antes de o pod ser encerrado.

Para obter os melhores resultados, certifique-se de que o tempo de execução do gancho preStop é superior ou igual à soma da latência de Backend Service Drain Timeout e de esgotamento.

Calcule o tempo de execução ideal do preStop gancho com a seguinte fórmula:

preStop hook execution time >= BACKEND_SERVICE_DRAIN_TIMEOUT + DRAIN_LATENCY

Substitua o seguinte:

• BACKEND_SERVICE_DRAIN_TIMEOUT: a hora que configurou para o Backend Service Drain Timeout.
• DRAIN_LATENCY: um tempo estimado para a latência de esgotamento. Recomendamos que use um minuto como estimativa.

Se os erros 500 persistirem, estime a duração total da ocorrência e adicione o dobro desse tempo à latência de esgotamento estimada. Isto garante que o Pod tem tempo suficiente para esvaziar a bateria antes de ser removido do serviço. Pode ajustar este valor se for demasiado longo para o seu exemplo de utilização específico.

Em alternativa, pode estimar a data/hora examinando a data/hora da eliminação do pod e a data/hora em que o ponto final foi removido do NEG nos registos de auditoria do Google Cloud.

Parâmetro do período de tolerância de rescisão

Tem de configurar o parâmetro terminationGracePeriod para permitir tempo suficiente para a conclusão do gancho preStop e para que o pod conclua um encerramento normal.

Por predefinição, quando não é definido explicitamente, o valor de terminationGracePeriod é 30 segundos. Pode calcular o valor terminationGracePeriod ideal através da seguinte fórmula:

terminationGracePeriod >= preStop hook time + Pod shutdown time

Para definir terminationGracePeriod na configuração do pod da seguinte forma:

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

Não foi encontrado um NEG ao criar um recurso Internal Ingress

O seguinte erro pode ocorrer quando cria um Ingress interno no GKE:

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

Este erro ocorre porque o Ingress para equilibradores de carga de aplicações internos requer grupos de pontos finais de rede (NEGs) como back-ends.

Em ambientes de VPC partilhada ou clusters com políticas de rede ativadas, adicione a anotação cloud.google.com/neg: '{"ingress": true}' ao manifesto do serviço.

504 Tempo limite do gateway: tempo limite do pedido a montante

Pode ocorrer o seguinte erro quando acede a um serviço a partir de um Ingress interno no GKE:

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

Este erro ocorre porque o tráfego enviado para equilibradores de carga de aplicações internos é encaminhado por proxy através de proxies do Envoy no intervalo de sub-rede apenas de proxy.

Para permitir o tráfego do intervalo de sub-rede só de proxy, crie uma regra de firewall no targetPort do serviço.

Erro 400: valor inválido para o campo "resource.target"

Pode ocorrer o seguinte erro quando acede a um serviço a partir de um Ingress interno no GKE:

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

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

Erro durante a sincronização: erro ao executar a rotina de sincronização do equilibrador de carga: o equilibrador de carga não existe

Pode ocorrer um dos seguintes erros quando atualiza o plano de controlo do GKE ou quando modifica um objeto Ingress:

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

Ou:

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

Para resolver estes problemas, experimente os seguintes passos:

• Adicione o campo hosts na secção tls do manifesto do Ingress e, em seguida, elimine o Ingress. Aguarde cinco minutos para que o GKE elimine os recursos Ingress não usados. Em seguida, recrie o Ingress. Para mais informações, consulte O campo hosts de um objeto Ingress.
• Reverta as alterações feitas ao Ingress. Em seguida, adicione um certificado através de uma anotação ou um secret do Kubernetes.

Problemas conhecidos

Não é possível ativar os redirecionamentos HTTPS com o esquema de nomenclatura do Ingress V1

Não pode ativar redirecionamentos HTTPS em recursos do GKE Ingress criados nas versões 1.16.8-gke.12 e anteriores do GKE. Tem de recriar o Ingress antes de poder ativar os redirecionamentos HTTPS ou é criado um evento de erro e o Ingress não é sincronizado.

A mensagem do evento de erro é semelhante à seguinte:

Error syncing: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

Campos da política de segurança do Google Cloud Armor removidos do BackendConfig

Existe um problema conhecido em que a atualização de um recurso BackendConfig através da API remove uma política de segurança do Cloud Armor ativa do respetivo serviço.v1beta1 Este problema afeta as seguintes versões do GKE:

• 1.18.19-gke.1400 a 1.18.20-gke.5099
• 1.19.10-gke.700 a 1.19.14-gke.299
• 1.20.6-gke.700 a 1.20.9-gke.899

Se não configurar o Cloud Armor nos seus recursos de entrada através do BackendConfig, este problema não afeta os seus clusters.

Para clusters do GKE que configuram o Cloud Armor através do BackendConfig, é fortemente recomendado que atualize apenas os recursos do BackendConfig através da API v1. A aplicação de um BackendConfig ao cluster através de v1beta1 recursos BackendConfig remove a política de segurança do Cloud Armor do serviço ao qual faz referência.

Para mitigar este problema, faça atualizações ao BackendConfig apenas através da v1 API BackendConfig. O v1 BackendConfig suporta todos os mesmos campos que v1beta1 e não faz alterações significativas, pelo que o campo da API pode ser atualizado de forma transparente. Substitua o campo apiVersion de todos os manifestos BackendConfig ativos por cloud.google.com/v1 e não use cloud.google.com/v1beta1. O exemplo de manifesto seguinte descreve um recurso BackendConfig que usa a v1API:

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: my-backend-config
  spec:
    securityPolicy:
      name: "ca-how-to-security-policy"

Se tiver sistemas ou ferramentas de CI/CD que atualizam regularmente os recursos BackendConfig, certifique-se de que está a usar o grupo de APIs cloud.google.com/v1 nesses sistemas.

Se o BackendConfig já tiver sido atualizado com a API v1beta1, a sua política de segurança do Cloud Armor pode ter sido removida. Pode determinar se isto aconteceu executando o seguinte comando:

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'

Se a resposta devolver resultados, o seu cluster é afetado pelo problema. O resultado deste comando devolve uma lista de recursos BackendConfig (<namespace>/<name>) que são afetados pelo problema. Se o resultado estiver vazio, significa que o BackendConfig não foi atualizado através da API v1beta1 desde que o problema foi introduzido. Todas as atualizações futuras à sua BackendConfig devem usar apenas v1.

Se a sua política de segurança do Cloud Armor foi removida, pode determinar quando foi removida através da seguinte consulta de registo:

resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"

Se algum dos seus clusters tiver sido afetado, pode corrigir a situação enviando uma atualização para o recurso BackendConfig que usa a API v1.

Atualize o plano de controlo do GKE para uma das seguintes versões atualizadas que corrigem este problema e permitem que os recursos v1beta1BackendConfig sejam usados em segurança:

• 1.18.20-gke.5100 e posterior
• 1.19.14-gke.300 e posteriores
• 1.20.9-gke.900 e posteriores

O que se segue?

• Entrada do GKE para balanceamento de carga de cluster único.

• Tutorial do Ingress para implementar o encaminhamento HTTP(S) para apps do GKE.

• Implemente o GKE Ingress com uma verificação de funcionamento de HTTP personalizada