Entrada do GKE para balanceadores de carga de aplicativo

Nesta página, fornecemos uma visão geral do que é o Ingress para balanceadores de carga de aplicativo externos e como ele funciona. O Google Kubernetes Engine (GKE) fornece um controlador de Ingress gerenciado e integrado chamado GKE Ingress. Ele implementa recursos do Entrada como balanceadores de carga do Google Cloud para cargas de trabalho HTTP(S) no GKE.

Informações gerais

No GKE, um objeto Ingress define regras para rotear tráfego HTTP(S) para aplicativos executados em um cluster. Um objeto Ingress está associado a um ou mais objetos de serviço, e cada um deles está associado a um conjunto de pods. Para saber mais sobre como o Ingress expõe aplicativos usando Serviços, consulte Visão geral da rede de serviços.

Ao criar um objeto Ingress, o controlador Ingress do GKE gera um balanceador de carga HTTP(S) do Google Cloud e o configura de acordo com as informações do Ingress e dos serviços associados.

Para usar um Ingress, é preciso ativar o complemento de balanceamento de carga HTTP. Os clusters do GKE têm o balanceamento de carga HTTP ativado por padrão. Não o desative.

Ingress para tráfego externo e interno

Os recursos do Ingress do GKE vêm em dois tipos:

Comportamento do controlador de Ingress do GKE

Para clusters que executam a versão 1.18 e posteriores do GKE, se o controlador de Ingress do GKE processa ou não um Ingress depende do valor da anotação kubernetes.io/ingress.class:

Valor de kubernetes.io/ingress.class Valor de ingressClassName Comportamento do controlador de Ingress do GKE
Não definido Não definido Processe o manifesto do Ingress e crie um balanceador de carga de aplicativo externo.
Não definido Qualquer valor Não precisa fazer nada. O manifesto do Ingress poderá ser processado por um controlador de entrada de terceiros se ele tiver sido implantado.
gce Qualquer valor Este campo é ignorado. Processe o manifesto do Ingress e crie um balanceador de carga de aplicativo externo.
gce-internal Qualquer valor Este campo é ignorado. Processe o manifesto do Ingress e crie um balanceador de carga de aplicativo interno.
Defina com um valor diferente de gce ou gce-internal. Qualquer valor Não precisa fazer nada. O manifesto do Ingress poderá ser processado por um controlador de entrada de terceiros se ele tiver sido implantado.

Para clusters que executam versões mais antigas do GKE, o controlador do GKE processa qualquer Ingress que não tenha a anotação kubernetes.io/ingress.class ou que tenha a anotação com o valor gce ou gce-internal.

Descontinuação de anotação kubernetes.io/ingress.class

A anotação kubernetes.io/ingress.class é descontinuada no Kubernetes, mas o GKE continua a usar essa anotação.

Não é possível usar o campo ingressClassName para especificar um objeto Ingress do GKE. É preciso usar a anotação kubernetes.io/ingress.class.

Recursos dos balanceadores de carga de aplicativo externos

Um balanceador de carga de aplicativo externo, configurado pelo Ingress, inclui os seguintes recursos:

  • Configuração flexível para Serviços. Um objeto Ingress define como o tráfego chega aos seus objetos de Serviço e como ele é roteado para seu aplicativo. Além disso, um Ingress pode fornecer um único endereço IP para vários Serviços no cluster.
  • Integração com serviços de rede do Google Cloud
  • Suporte para vários certificados TLS. Um Ingress pode especificar o uso de vários certificados TLS para o encerramento da solicitação.

Para uma lista mais completa, consulte Configurações do Ingress.

Balanceamento de carga nativo de contêiner

O balanceamento de carga nativo do contêiner é a prática do balanceamento de carga diretamente para os endpoints do pod no GKE usando grupos de endpoint da rede (NEGs).

Ao usar grupos de instâncias, os balanceadores de carga do Compute Engine enviam tráfego para IPs de VM como back-ends. Ao executar contêineres em VMs, eles compartilharão a mesma interface de host. Isso introduz algumas limitações:

  • Há dois saltos de balanceamento de carga: um do balanceador de carga para a VM NodePort e outro pelo roteamento do kube-proxy para o IP do pod (que pode residir em uma VM diferente).
  • Saltos extras aumentam a latência e tornam o caminho de tráfego mais complexo.
  • O balanceador de carga do Compute Engine não tem visibilidade direta para os pods, resultando em um equilíbrio de tráfego abaixo do ideal.
  • Eventos de ambiente, como perda de VM ou de pod, têm maior probabilidade de causar perda intermitente de tráfego devido ao salto de tráfego duplo.

Com os NEGs, o tráfego é balanceado pelo balanceador de carga diretamente para o IP do pod, em vez de cruzar o IP da VM e a rede kube-proxy. Além disso, os portões de prontidão do pod são implementados para determinar a integridade dos pods da perspectiva do balanceador de carga, e não apenas das sondagens de integridade no cluster do Kubernetes. Isso melhora a estabilidade geral do tráfego, fazendo com que a infraestrutura do balanceador de carga reconheça eventos de ciclo de vida, como a inicialização do pod, a perda do pod ou a perda da VM. Esses recursos resolvem as limitações acima e resultam em uma rede estável e com melhor desempenho.

O balanceamento de carga nativo de contêiner é ativado por padrão nos Serviços quando todas as condições a seguir são verdadeiras:

  • Para Serviços criados nos clusters do GKE 1.17.6-gke.7 e superiores
  • Como usar clusters nativos de VPC
  • Não usar uma VPC compartilhada
  • Política de rede do GKE não está em uso

Nessas condições, os Serviços serão anotados automaticamente com cloud.google.com/neg: '{"ingress": true}', indicando que um NEG precisa ser criado para espelhar os IPs do pod no Serviço. O NEG é o que permite que os balanceadores de carga do Compute Engine se comuniquem diretamente com os pods. Os Serviços já existentes criados antes do GKE 1.17.6-gke.7 não serão anotados automaticamente pelo controlador do Serviço.

Para o GKE 1.17.6-gke.7 e anteriores em que a anotação NEG é automática, é possível desativar os NEGs e forçar o balanceador de carga externo do Compute Engine a usar um grupo de instâncias como back-ends, quando necessário. Isso pode ser feito anotando explicitamente os Serviços com cloud.google.com/neg: '{"ingress": false}'. Não é possível desativar NEGs com o Ingress para balanceadores de carga de aplicativo internos.

Para clusters em que os NEGs não são o padrão, ainda é altamente recomendado usar o balanceamento de carga nativo de contêiner, mas ele precisa ser ativado explicitamente em cada Serviço. A anotação deve ser aplicada aos Serviços da seguinte maneira:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

VPC compartilhada

Os recursos do Ingress e MultiClusterIngress têm suporte para VPC compartilhada, mas exigem preparação adicional.

O controlador de Ingress é executado no plano de controle do GKE e faz chamadas de API para o Google Cloud usando a conta de serviço do GKE do projeto do cluster. Por padrão, quando um cluster localizado em um projeto de serviço de VPC compartilhada usa uma rede VPC compartilhada, o controlador de Ingress não pode usar a conta de serviço do GKE do projeto de serviço para criar e atualizar regras de firewall de permissão de Ingress em projeto host.

É possível conceder permissões da conta de serviço do GKE do projeto de serviço para criar e gerenciar regras de firewall da VPC no projeto host. Ao conceder essas permissões, o GKE cria regras de permissão de entrada de firewall para:

Provisionar manualmente as regras de firewall do projeto host

Se suas políticas de segurança permitirem apenas o gerenciamento de firewall pelo projeto host, será possível provisionar essas regras de firewall manualmente. Ao implantar o Ingress em uma VPC compartilhada, o evento de recurso do Ingress fornece a regra de firewall específica que você precisa adicionar para conceder acesso.

Para provisionar uma regra manualmente:

  1. Visualize o evento do recurso do Ingress:

    kubectl describe ingress INGRESS_NAME

    Substitua INGRESS_NAME pelo nome do seu Ingress.

    O resultado será semelhante a:

    Events:
Type    Reason  Age                    From                     Message
----    ------  ----                   ----                     -------
Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`

    A regra de firewall necessária sugerida aparece na coluna Message.

  2. Copie e aplique as regras de firewall sugeridas do projeto host. A aplicação da regra concede acesso aos seus pods a partir do balanceador de carga e dos verificadores de integridade do Google Cloud.

Como dar permissão ao controlador de Ingress do GKE para gerenciar as regras de firewall do projeto host

Se você quer que um cluster do GKE em um projeto de serviço crie e gerencie os recursos de firewall no seu projeto host, a conta de serviço do GKE do projeto de serviço precisa receber as permissões de IAM apropriadas usando uma das estratégias a seguir:

  • Conceda à conta de serviço do GKE do projeto de serviço o papel de Administrador de segurança do Compute ao projeto host. O exemplo a seguir demonstra essa estratégia.

  • Para uma abordagem mais precisa, crie um papel de IAM personalizado que inclua apenas as seguintes permissões: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update e compute.firewalls.delete. Conceda à conta de serviço do GKE do projeto de serviço que atribui o papel personalizado ao projeto host.

Se você tiver clusters em mais de um projeto de serviço, precisará escolher uma das estratégias e repeti-la para cada conta de serviço do GKE do projeto de serviço.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

Substitua:

Vários serviços de back-end

Cada balanceador de carga de aplicativo externo ou interno usa um único mapa de URL, que faz referência a um ou mais serviços de back-end. Um serviço de back-end corresponde a cada Serviço referenciado pelo Ingress.

Por exemplo, você pode configurar o balanceador de carga para rotear solicitações para diferentes serviços de back-end dependendo do caminho do URL. As solicitações enviadas para "your-store.example" podem ser encaminhadas para um serviço de back-end que exibe itens com preço integral. Já as enviadas para "your-store.example/discounted" podem ser encaminhadas para um serviço de back-end que exibe itens com desconto.

Também é possível configurar o balanceador de carga para encaminhar solicitações de acordo com o nome do host. As solicitações enviadas para your-store.example poderiam ir para um serviço de back-end e as enviadas para your-experimental-store.example para outro.

Para criar e configurar um balanceador de carga HTTP(S), crie um objeto Ingress do Kubernetes em um cluster do GKE. O objeto Ingress precisa estar associado a um ou mais objetos de serviço, e cada um deles associado a um conjunto de pods.

Veja um manifesto para um Ingress chamado my-ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Quando você cria o Ingress, o controlador do Ingress do GKE cria e configura um balanceador de carga de aplicativo externo ou interno de acordo com as informações no Ingress e nos serviços associados. Além disso, o balanceador de carga recebe um endereço IP estável que pode ser associado a um nome de domínio.

No exemplo anterior, imagine que você associou o endereço IP do balanceador de carga ao nome de domínio your-store.example Quando um cliente envia uma solicitação para "your-store.example", ela é roteada para um serviço do Kubernetes chamado my-products na porta 60000. E quando um cliente envia uma solicitação para your-store.example/discounted, essa é roteada para um serviço do Kubernetes chamado my-discounted-products na porta 80.

O único caractere curinga aceito no campo path de um Ingress é *. O caractere * precisa vir depois de uma barra (/) e ser o último caractere no padrão. Por exemplo, /*, /foo/* e /foo/bar/* são padrões válidos, ao contrário de *, /foo/bar* e /foo/*/bar.

Um padrão mais específico tem precedência sobre um menos específico. Se você tiver os padrões /foo/* e /foo/bar/*, /foo/bar/bat será usado na correspondência com /foo/bar/*.

Para mais informações sobre limitações de caminho e correspondência de padrões, consulte a documentação dos mapas de URL.

O manifesto do serviço my-products ficaria da seguinte maneira:

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

No manifesto do Serviço, use type: NodePort a menos que esteja usando o balanceamento de carga nativo do contêiner. Se estiver usando o balanceamento de carga nativo de contêiner, use o type: ClusterIP.

No manifesto do serviço, o campo selector diz que qualquer pod que tenha os rótulos app: products e department: sales é membro deste serviço.

Quando uma solicitação chega ao serviço na porta 60000, ela é roteada para um dos pods de membro na porta TCP 50000.

Cada pod de membro precisa ter um contêiner escutando a porta TCP 50000.

O manifesto do serviço my-discounted-products ficaria da seguinte maneira:

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

No manifesto do serviço, o campo selector diz que qualquer pod que tenha os rótulos app: discounted-products e department: sales é membro deste serviço.

Quando uma solicitação chega ao serviço na porta 80, ela é roteada para um dos pods de membro na porta TCP 8080.

Todo pod membro precisa ter um contêiner escutando a porta TCP 8080.

Back-end padrão

Especifique um back-end padrão para o Ingress fornecendo um campo spec.defaultBackend no manifesto dele. Isso vai processar as solicitações que não corresponderem aos caminhos definidos no campo rules. Por exemplo, no Ingress a seguir, todas as solicitações que não correspondem a /discounted foram enviadas para um serviço chamado my-products na porta 60001.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  defaultBackend:
    service:
      name: my-products
      port:
        number: 60001
  rules:
  - http:
      paths:
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Se você não especificar um back-end padrão, o GKE fornecerá um back-end padrão que retorna 404. Ele é criado como um serviço NodePort default-http-backend no cluster no namespace kube-system.

A resposta HTTP 404 é semelhante a esta:

response 404 (backend NotFound), service rules for the path non-existent

Para configurar a Entrada do GKE com um back-end padrão do cliente, consulte Entrada do GKE com back-end padrão personalizado.

Ingress para os mapeamentos de recursos do Compute Engine

O controlador de Ingress do GKE implanta e gerencia os recursos do balanceador de carga do Compute Engine com base nos recursos da Ingress implantados no cluster. O mapeamento dos recursos do Compute Engine depende da estrutura do recurso Ingress.

O manifesto a seguir descreve um Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Esse manifesto do Ingress instrui o GKE a criar os seguintes recursos do Compute Engine:

  • Uma regra de encaminhamento e um endereço IP.
  • Regras de firewall do Compute Engine que permitem tráfego para verificações de integridade do balanceador de carga e para aplicativos dos proxies do Google Front End ou Envoy
  • Um proxy HTTP de destino e um proxy HTTPS de destino, se você tiver configurado o TLS.
  • Um mapa de URLs que, com uma única regra de host, refere-se a uma única correspondência de caminho. A correspondência de caminho tem duas regras de caminho, uma para /* e outra para /discounted. Cada regra de caminho mapeia um serviço de back-end exclusivo.
  • NEGs que contêm uma lista de endereços IP de pods de cada serviço como endpoints. Eles são criados como resultado dos serviços my-discounted-products e my-products.

Opções para fornecer certificados SSL

É possível fornecer certificados SSL a um balanceador de carga HTTP(S) usando os seguintes métodos:

Certificados gerenciados pelo Google
Os certificados SSL gerenciados pelo Google são provisionados, implantados, renovados e gerenciados para seus domínios. Os certificados gerenciados não são compatíveis com domínios curinga.
Certificados autogerenciados compartilhados com o Google Cloud
É possível provisionar seu próprio certificado SSL e criar um recurso de certificação no seu projeto do Google Cloud. Você pode então listar o recurso de certificação em uma anotação em um Ingress para criar um balanceador de carga HTTP(S) que usa o certificado. Consulte as instruções para certificados pré-compartilhados para mais informações.
Certificados autogerenciados como recursos de secret
É possível provisionar seu próprio certificado SSL e criar um Secret para mantê-lo. Em seguida, consulte o secret em uma especificação do Ingress para criar um balanceador de carga HTTP(S) que use o certificado. Para mais informações, consulte as instruções para usar certificados em secrets.

Verificações de integridade

Quando você expõe um ou mais serviços por meio de um Ingress usando o controlador padrão do Ingress, o GKE cria um balanceador de carga de aplicativo clássico ou um balanceador de carga de aplicativo interno. Esses dois balanceadores de carga são compatíveis com vários serviços de back-end em um único mapa de URLs. Cada um dos serviços de back-end corresponde a um serviço do Kubernetes, e cada serviço de back-end precisa fazer referência a uma verificação de integridade do Google Cloud. Essa verificação de integridade é diferente de uma sondagem de atividade ou prontidão do Kubernetes porque a verificação de integridade é implementada fora do cluster.

O GKE usa o procedimento a seguir para criar uma verificação de integridade para cada serviço de back-end correspondente a um serviço do Kubernetes:

  • Se o serviço referir-se a uma CRD BackendConfig com informações de healthCheck, o GKE usará isso para criar a verificação de integridade. Tanto o controlador do Ingress do GKE Enterprise quanto o controlador do Ingress do GKE dão suporte à criação de verificações de integridade dessa maneira.

  • Se o Serviço não referenciar um CRD BackendConfig:

    • O GKE poderá inferir alguns ou todos os parâmetros de uma verificação de integridade. Para isso, os pods de exibição precisam usar um modelo com um contêiner em que a sondagem de prontidão tenha atributos que possam ser interpretados como parâmetros de verificação de integridade. Consulte Parâmetros de uma sondagem de prontidão para ver detalhes de implementação e Parâmetros padrão e inferidos para ver uma lista de atributos que podem ser usados para criar parâmetros de verificações de integridade. Somente o controlador de Ingress do GKE tem suporte para inferência de parâmetros de uma sondagem de prontidão.

    • Se o modelo dos pods de exibição do Serviço não tiver um contêiner com uma sondagem de prontidão que tenha atributos que possam ser interpretados como parâmetros de verificação de integridade, os valores padrão serão usados para criar a verificação de integridade. O controlador do Ingress do GKE Enterprise e o controlador do Ingress do GKE podem criar uma verificação de integridade usando apenas os valores padrão.

Parâmetros padrão e inferidos

Os parâmetros a seguir são usados quando você não especificar os parâmetros da verificação de integridade do Serviço correspondente com um CRD BackendConfig.

Parâmetro de verificação de integridade Valor padrão Valor inferido
Protocolo HTTP se estiver presente na anotação Service cloud.google.com/app-protocols
Caminho da solicitação / se estiver presente no pod de exibição spec:
containers[].readinessProbe.httpGet.path
Cabeçalho do host da solicitação Host: backend-ip-address se estiver presente no pod de exibição spec:
containers[].readinessProbe.httpGet.httpHeaders
Resposta esperada HTTP 200 (OK) HTTP 200 (OK)
não pode ser alterado
Intervalo de verificação
  • para NEGs zonais: 15 segundos
  • para grupos de instâncias: 60 segundos
 se estiver presente no pod de exibição spec:
  • para NEGs zonais:
    containers[].readinessProbe.periodSeconds
  • para grupos de instâncias:
    containers[].readinessProbe.periodSeconds + 60 seconds
Tempo limite da verificação 5 segundos se estiver presente no pod de exibição spec:
containers[].readinessProbe.timeoutSeconds
Limite íntegro 1 1
não pode ser alterado
Limite não íntegro
  • para NEGs zonais: 2
  • para grupos de instâncias: 10
 o mesmo que o padrão:
  • para NEGs zonais: 2
  • para grupos de instâncias: 10
Especificação da porta
  • para NEGs zonais: o port do Serviço
  • para grupos de instâncias: o nodePort do Serviço
 As sondagens de verificação de integridade são enviadas para o número da porta especificado por spec.containers[].readinessProbe.httpGet.port, desde que todas as condições a seguir também sejam verdadeiras:
  • O número da porta da sondagem de prontidão precisa corresponder ao containers[].spec.ports.containerPort do pod de exibição
  • O containerPort do pod de exibição corresponde ao targetPort do serviço.
  • A especificação da porta de back-end do serviço de Ingress faz referência a uma porta válida de spec.ports[] do serviço. Isso pode ser feito de duas maneiras:
    • spec.rules[].http.paths[].backend.service.port.name no Ingress corresponde a spec.ports[].name definida no serviço correspondente
    • spec.rules[].http.paths[].backend.service.port.number na Ingress corresponde a spec.ports[].port definida no serviço correspondente
Endereço IP de destino
  • para NEGs zonais: o endereço IP do pod
  • para grupos de instâncias: o endereço IP do nó
 o mesmo que o padrão:
  • para NEGs zonais: o endereço IP do pod
  • para grupos de instâncias: o endereço IP do nó

Parâmetros de uma sondagem de prontidão

Quando o GKE cria a verificação de integridade para o serviço de back-end do Serviço, ele pode copiar determinados parâmetros da sondagem de prontidão de um contêiner usada pelos pods de exibição desse Serviço. Essa opção tem suporte somente com o controlador de Ingress do GKE.

Os atributos de sondagem de prontidão compatíveis que podem ser interpretados como parâmetros de verificação de integridade são listados com os valores padrão em Parâmetros padrão e inferidos. Os valores padrão serão usados para quaisquer atributos não especificados na sondagem de prontidão ou se você não especificar nenhuma sondagem.

Se os pods de disponibilização do serviço tiverem vários contêineres ou você estiver usando o controlador do Ingress do GKE Enterprise, use um CRD BackendConfig para definir os parâmetros da verificação de integridade. Para mais informações, consulte Quando usar um CRD BackendConfig.

Quando usar os CRDs BackendConfig

Em vez de depender de parâmetros das sondagens de prontidão do pod, defina explicitamente os parâmetros de verificação de integridade em um serviço de back-end. Para isso, crie um CRD BackendConfig para o Serviço nestas situações:

  • Ao usar o GKE Enterprise: o controlador do Ingress não dá suporte à coleta de parâmetros de verificação de integridade das sondagens de prontidão dos pods de disponibilização. Só é possível criar verificações de integridade por meio e parâmetros implícitos ou definidos em um CRD BackendConfig.

  • Se você tiver mais de um contêiner nos pods de exibição: o GKE não tem como selecionar a sondagem de prontidão de um contêiner específico em que inferir parâmetros da verificação de integridade. Como cada contêiner pode ter a própria sondagem de prontidão e uma sondagem de prontidão não é um parâmetro obrigatório para um contêiner, você precisa definir a verificação de integridade para o serviço de back-end correspondente mencionando uma consulta BackendConfig CRD no serviço correspondente.

  • Se você precisar de controle sobre a porta usada para as verificações de integridade do balanceador de carga: o GKE só usará o containers[].readinessProbe.httpGet.port da sondagem de prontidão para a verificação de integridade do serviço de back-end quando essa porta corresponder à porta de serviço no Serviço mencionado no Ingress spec.rules[].http.paths[].backend.servicePort.

Parâmetros de um CRD BackendConfig

É possível especificar os parâmetros da verificação de integridade do serviço de back-end usando o parâmetro healthCheck de um CRD BackendConfig referenciado pelo Serviço correspondente. Isso proporciona mais flexibilidade e controle sobre as verificações de integridade de um balanceador de carga de aplicativo clássico ou interno criado por um Ingress. Consulte Configurações do Ingress para ver a compatibilidade da versão do GKE.

Este exemplo e CRD BackendConfig define o protocolo de verificação de integridade (tipo), um caminho de solicitação, uma porta e um intervalo de verificação no atributo spec.healthCheck:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

Para definir todos os campos disponíveis ao configurar uma verificação de integridade BackendConfig, use o exemplo de configuração de verificação de integridade personalizada.

Para configurar a Entrada do GKE com uma verificação de integridade HTTP personalizada, consulte Entrada do GKE com verificação de integridade HTTP personalizada.

Como usar vários certificados TLS

Suponha que você queira que um balanceador de carga HTTP(S) atenda ao conteúdo de dois nomes de host: your-store.example e your-experimental-store.example. Além disso, você quer que o balanceador de carga use um certificado para your-store.example e outro para your-experimental-store.example.

É possível especificar vários certificados em um manifesto do Ingress. O balanceador de carga escolherá um certificado se o nome comum (CN, na sigla em inglês) no certificado corresponder ao nome do host usado na solicitação. Para informações detalhadas sobre como configurar vários certificados, consulte Como usar vários certificados SSL no balanceamento de carga HTTP(S) com a Ingress.

Serviço do Kubernetes em comparação com o serviço de back-end do Google Cloud

Um serviço (em inglês) do Kubernetes e um serviço de back-end do Google Cloud são coisas diferentes. Existe uma forte relação entre os dois, mas o relacionamento não é necessariamente de um para um. O controlador de Ingress do GKE cria um serviço de back-end do Google Cloud para cada par (service.name, service.port) em um manifesto de Ingress. Dessa forma, é possível que um objeto de serviço do Kubernetes esteja relacionado a vários serviços de back-end do Google Cloud.

Limitações

  • Em clusters que usam versões anteriores à 1.16, o tamanho total do namespace e o nome de um Ingress não pode exceder 40 caracteres. O não cumprimento desta diretriz pode fazer com que o controlador de Ingress do GKE atue de forma anormal. Para mais informações, confira este problema do GitHub sobre nomes longos.

  • Em clusters que usam NEGs, o tempo de reconciliação de entrada pode ser afetado pelo número de entradas. Por exemplo, um cluster com 20 entradas, cada um contendo 20 back-ends de NEG distintos, pode resultar em uma latência de mais de 30 minutos para que uma alteração de entrada seja reconciliada. Isso afeta especialmente os clusters regionais devido ao maior número de NEGs necessários.

  • Cotas para mapas de URL são aplicáveis.

  • Sujeito a cotas para recursos do Compute Engine.

  • Se você não estiver usando NEGs com o controlador de Ingress do GKE, os clusters do GKE terão um limite de 1.000 nós. Quando os serviços são implantados com NEGs, não há limite de nós do GKE. Todos os Serviços não NEG expostos por meio do Ingress não funcionam corretamente em clusters com mais de 1.000 nós.

  • Para que o controlador de Ingress do GKE use os readinessProbes como verificação de integridade, os pods de uma Ingress precisam existir no momento da criação dela. Se as réplicas forem dimensionadas para 0, a verificação de integridade padrão será aplicada. Para mais informações, consulte este comentário de problema do GitHub sobre verificações de integridade.

  • As alterações no readinessProbe de um Pod não afetam o Ingress após a criação.

  • Um balanceador de carga de aplicativo externo encerra o TLS em locais distribuídos globalmente, de modo a minimizar a latência entre os clientes e o balanceador de carga. Se você precisar de controle geográfico sobre o local em que o TLS é encerrado, use um controlador de Ingress personalizado exposto por meio de um Serviço do GKE do tipo LoadBalancer e encerre o TLS nos back-ends localizados em regiões adequadas às suas necessidades.

  • Não há suporte para combinar vários recursos do Ingress em um único balanceador de carga do Google Cloud.

  • É preciso desativar o TLS mútuo no aplicativo porque ele não tem suporte para balanceadores de carga de aplicativo externos.

Ingress externo e clusters baseados em rotas

Se você usa clusters baseados em rotas com Ingress externo, o controlador de Ingress do GKE não pode usar o balanceamento de carga nativo de contêiner usando grupos de endpoints de rede (NEGs, na sigla em inglês) GCE_VM_IP_PORT. Em vez disso, o controlador de Ingress usa back-ends de grupos de instâncias não gerenciadas que incluem todos os nós em todos os pools de nós. Se esses grupos de instâncias não gerenciadas também forem usados por LoadBalancer, isso poderá causar problemas relacionados à limitação do grupo de instâncias com balanceamento de carga único.

Alguns objetos mais antigos do Ingress externo criados em clusters nativos de VPC podem usar back-ends de grupos de instâncias nos serviços de back-end de cada balanceador de carga de aplicativo externo criado. Isso não é relevante para Ingress interno porque os recursos internos sempre usam GCE_VM_IP_PORT NEGs e exigem clusters nativos de VPC.

Para saber como resolver erros 502 com Ingress externo, consulte Ingress externo produz erros HTTP 502.

Detalhes de implementação

  • O controlador de Ingress realiza verificações periódicas das permissões da conta de serviço buscando um recurso de teste do projeto do Google Cloud. Você verá isso como um GET doBackendService global (não existente) com o nome k8s-ingress-svc-acct-permission-check-probe. Como esse recurso não deve existir normalmente, a solicitação GET retornará "não encontrado". Isso é esperado. O controlador está verificando se a chamada de API não foi rejeitada devido a problemas de autorização. Se você criar um BackendService com o mesmo nome, o GET será bem-sucedido em vez de retornar "não encontrado".

Modelos para a configuração da Entrada

A seguir