GKE Ingress para balanceadores de carga de aplicações

Esta página oferece uma vista geral da entrada para balanceadores de carga de aplicações externos e do respetivo funcionamento.

Esta página pressupõe que tem conhecimentos sobre o Kubernetes.

O Google Kubernetes Engine (GKE) fornece um controlador de entrada integrado e gerido denominado entrada do GKE. Quando cria um recurso Ingress no GKE, o controlador configura automaticamente um balanceador de carga HTTPS que permite que o tráfego HTTP ou HTTPS alcance os seus serviços.

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 Trusted Cloud by S3NS conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Vista geral

No GKE, um objeto Ingress define regras para encaminhar o tráfego HTTP(S) para aplicações em execução num cluster. Um objeto Ingress está associado a um ou mais objetos Service, cada um dos quais está associado a um conjunto de pods. Para saber como o Ingress expõe aplicações através de serviços, consulte a vista geral da rede de serviços.

Quando cria um objeto Ingress, o controlador Ingress do GKE cria um Trusted Cloud by S3NS balanceador de carga HTTP(S) e configura-o de acordo com as informações no Ingress e nos respetivos serviços associados.

Para usar o Ingress, 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 pode desativar.

Entrada para tráfego externo e interno

Os recursos de entrada do GKE estão disponíveis em dois tipos:

• O Ingress para balanceadores de carga de aplicações externos implementa o balanceador de carga de aplicações clássico. Este balanceador de carga virado para a Internet é implementado globalmente na rede periférica da Google como um conjunto gerido e escalável de recursos de balanceamento de carga. Saiba como configurar e usar o Ingress para equilibradores de carga de aplicações externos.

• A entrada para balanceadores de carga de aplicações internos implementa o balanceador de carga de aplicações interno. Estes balanceadores de carga de aplicações internos são baseados em sistemas de proxy Envoy fora do seu cluster do GKE, mas na sua rede VPC. Saiba como configurar e usar o Ingress para equilibradores de carga de aplicações internos.

Comportamento do controlador de entrada do GKE

Para clusters que executam as versões 1.18 e posteriores do GKE, o processamento de um Ingress pelo controlador de Ingress do GKE depende ou não do valor da anotação kubernetes.io/ingress.class:

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.

kubernetes.io/ingress.class descontinuação das anotações

Embora a anotação kubernetes.io/ingress.class esteja descontinuada no Kubernetes, o GKE continua a usar esta anotação.

Não pode usar o campo ingressClassName para especificar um GKE Ingress. Tem de usar a anotação kubernetes.io/ingress.class.

Funcionalidades dos balanceadores de carga de aplicações externos

Um Application Load Balancer externo, configurado pela entrada, inclui as seguintes funcionalidades:

• Configuração flexível para serviços. Um Ingress define como o tráfego chega aos seus serviços e como o tráfego é encaminhado para a sua aplicação. Além disso, um Ingress pode fornecer um único endereço IP para vários serviços no seu cluster.
• Integração com Trusted Cloud serviços de rede
• Suporte para vários certificados TLS. Um Ingress pode especificar a utilização de vários certificados TLS para a terminação de pedidos.

Para ver uma lista abrangente, consulte o artigo Configuração de entrada.

Métodos de balanceamento de carga

O GKE suporta o balanceamento de carga nativa do contentor e os grupos de instâncias.

Balanceamento de carga nativa do contentor

O balanceamento de carga nativa do contentor é a prática de balanceamento de carga diretamente para os pontos finais do Pod no GKE. O balanceamento de carga nativa do contentor é um tipo de grupos de pontos finais da rede (NEGs).

Com os NEGs, o tráfego é balanceado de carga a partir do balanceador de carga diretamente para o IP do pod, em vez de atravessar o IP da VM e a rede kube-proxy. Além disso, as condições de disponibilidade de pods são implementadas para determinar o estado dos pods na perspetiva do balanceador de carga e não apenas das sondas de estado no cluster do Kubernetes. Isto melhora a estabilidade geral do tráfego ao tornar a infraestrutura do balanceador de carga consciente dos eventos do ciclo de vida, como o arranque do pod, a perda do pod ou a perda da VM. Estas capacidades resolvem as limitações anteriores e resultam numa rede mais estável e com melhor desempenho.

O balanceamento de carga nativa do contentor está ativado por predefinição para os serviços quando todas as seguintes condições forem verdadeiras:

• Para serviços criados em clusters do GKE 1.17.6-gke.7 e superior
• Usar clusters nativos de VPC
• Não usar uma rede de VPC partilhada
• Não usar a Política de Rede do GKE

Nestas condições, os serviços são anotados automaticamente com cloud.google.com/neg: '{"ingress": true}', o que indica que deve ser criado um NEG para replicar os IPs do agrupamento no serviço. O NEG é o que permite que os equilibradores de carga do Compute Engine comuniquem diretamente com os pods. Tenha em atenção que os serviços existentes criados antes do GKE 1.17.6-gke.7 não são anotados automaticamente pelo controlador de serviços.

Para o GKE 1.17.6-gke.7 e versões 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, se necessário. Isto pode ser feito anotando explicitamente os serviços com cloud.google.com/neg: '{"ingress": false}'. Não é possível desativar os NEGs com o Ingress para equilibradores de carga de aplicações internos.

Para clusters em que os NEGs não são a predefinição, recomenda-se vivamente a utilização do equilíbrio de carga nativo do contentor, mas tem de ser ativado explicitamente por serviço. A anotação deve ser aplicada aos serviços da seguinte forma:

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

Grupos de instâncias

Quando usa grupos de instâncias, os balanceadores de carga do Compute Engine enviam tráfego para endereços IP de VMs como back-ends. Quando executa contentores em VMs, em que os contentores partilham a mesma interface de anfitrião, isto introduz as seguintes limitações:

• Implica dois saltos de balanceamento de carga: um salto do balanceador de carga para a VM NodePort e outro salto através do encaminhamento kube-proxy para os endereços IP dos pods (que podem residir numa VM diferente).
• Os saltos adicionais aumentam a latência e tornam o caminho do tráfego mais complexo.
• O equilibrador de carga do Compute Engine não tem visibilidade direta dos pods, o que resulta num equilíbrio de tráfego abaixo do ideal.
• Os eventos ambientais, como a perda de VMs ou pods, têm maior probabilidade de causar perda de tráfego intermitente devido ao salto duplo de tráfego.

Entrada externa e clusters baseados em encaminhamento

Se usar clusters baseados em rotas com o Ingress externo, o controlador do Ingress do GKE não pode usar o balanceamento de carga nativo do contentor com GCE_VM_IP_PORT grupos de pontos finais de rede (NEGs). Em alternativa, o controlador Ingress usa back-ends de grupos de instâncias não geridos que incluem todos os nós em todos os conjuntos de nós. Se estes grupos de instâncias não geridos também forem usados por LoadBalancer serviços, podem causar problemas relacionados com a limitação de um único grupo de instâncias com balanceamento de carga.

Alguns objetos Ingress externos mais antigos criados em clusters nativos da VPC podem usar back-ends de grupos de instâncias nos serviços de back-end de cada balanceador de carga de aplicações externo que criam. Isto não é relevante para o Ingress interno porque os recursos de Ingress interno usam sempre NEGs e requerem clusters nativos da VPC.GCE_VM_IP_PORT

Para saber como resolver problemas de erros 502 com a entrada externa, consulte o artigo A entrada externa produz erros HTTP 502.

VPC partilhada

Os recursos Ingress e MultiClusterIngress são suportados na VPC partilhada, mas requerem uma preparação adicional.

O controlador Ingress é executado no plano de controlo do GKE e faz chamadas de API para Trusted Cloud by S3NS usando a conta de serviço do GKE do projeto do cluster. Por predefinição, quando um cluster localizado num projeto de serviço de VPC partilhada usa uma rede de VPC partilhada, o controlador de entrada 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 entrada no projeto anfitrião.

Pode conceder autorizações à conta de serviço do GKE do projeto de serviço para criar e gerir regras de firewall de VPC no projeto anfitrião. Ao conceder estas autorizações, o GKE cria regras de firewall de permissão de entrada para o seguinte:

• Proxies do front-end da Google (GFE) e sistemas de verificação de estado usados por equilibradores de carga de aplicações externos para entrada externa. Para mais informações, consulte a Vista geral do balanceador de carga de aplicações externo.

• Sistemas de verificação de funcionamento para balanceadores de carga de aplicações internos usados pela entrada interna.

Aprovisione manualmente regras de firewall a partir do projeto anfitrião

Se as suas políticas de segurança só permitirem a gestão da firewall a partir do projeto anfitrião, pode aprovisionar estas regras de firewall manualmente. Quando implementa o Ingress numa VPC partilhada, o evento de recurso Ingress fornece a regra de firewall específica que tem de adicionar para conceder acesso.

Para aprovisionar manualmente uma regra:

1. Veja o evento do recurso Ingress:

   kubectl describe ingress INGRESS_NAME
   

   Substitua INGRESS_NAME pelo nome do seu Ingress.

   Deverá ver uma saída semelhante ao seguinte exemplo:

   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 é apresentada na coluna Message.

2. Copie e aplique as regras de firewall sugeridas do projeto anfitrião. A aplicação da regra dá acesso aos seus pods a partir do equilibrador de carga e dos Trusted Cloud verificadores de funcionamento.

Conceder autorização ao controlador de entrada do GKE para gerir regras de firewall do projeto anfitrião

Se quiser que um cluster do GKE num projeto de serviço crie e faça a gestão dos recursos de firewall no seu projeto anfitrião, a conta de serviço do GKE do projeto de serviço tem de receber as autorizações do IAM adequadas através de uma das seguintes estratégias:

• Conceda à conta de serviço do projeto de serviço a função de administrador de segurança do Compute ao projeto anfitrião. O exemplo seguinte demonstra esta estratégia.

• Para uma abordagem mais detalhada, crie uma função de IAM personalizada que inclua apenas as seguintes autorizações: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete e compute.subnetworks.list. Conceda essa função personalizada à conta de serviço do GKE do projeto de serviço no projeto anfitrião.

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

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

Substitua o seguinte:

• HOST_PROJECT_ID: o ID do projeto do projeto anfitrião da VPC partilhada.
• SERVICE_PROJECT_NUMBER: o número do projeto do projeto de serviço que contém o seu cluster.

Vários serviços de back-end

Cada balanceador de carga de aplicações externo ou balanceador de carga de aplicações interno usa um único mapa de URLs, 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, pode configurar o balanceador de carga para encaminhar pedidos para diferentes serviços de back-end consoante o caminho do URL. Os pedidos enviados para o domínio your-store.example podem ser encaminhados para um serviço de back-end que apresenta artigos ao preço total, e os pedidos enviados para o domínio your-store.example/discounted podem ser encaminhados para um serviço de back-end que apresenta artigos com desconto.

Também pode configurar o balanceador de carga para encaminhar pedidos de acordo com o nome do anfitrião. As solicitações enviadas para o seu-store.example podem ser encaminhadas para um serviço de back-end e as solicitações enviadas para o seu-experimental-store.example podem ser encaminhadas para outro serviço de back-end.

Num cluster do GKE, cria e configura um balanceador de carga HTTP(S) criando um objeto Ingress do Kubernetes. Um objeto Ingress tem de estar associado a um ou mais objetos Service, cada um dos quais está associado a um conjunto de pods.

Se quiser configurar o GKE Ingress com vários back-ends para o mesmo anfitrião, tem de ter uma única regra com um único anfitrião e vários caminhos. Caso contrário, o controlador de entrada do GKE aprovisiona apenas um serviço de back-end

Segue-se um manifesto para um Ingress denominado my-ingress:

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

Quando cria o Ingress, o controlador de Ingress do GKE cria e configura um Application Load Balancer externo ou um Application Load Balancer interno de acordo com as informações no Ingress e nos serviços associados. Além disso, é atribuído ao equilibrador de carga um endereço IP estável que pode associar a um nome de domínio.

No exemplo anterior, suponha que associou o endereço IP do balanceador de carga ao nome do domínio your-store.example. Quando um cliente envia um pedido para o seu-store.example, o pedido é encaminhado para um serviço Kubernetes denominado my-products na porta 60000. Quando um cliente envia um pedido para your-store.example/discounted, o pedido é encaminhado para um serviço do Kubernetes denominado my-discounted-products na porta 80.

O único caráter universal suportado para o campo path de um Ingress é o caráter *. O caráter * tem de seguir uma barra (/) e tem de ser o último caráter no padrão. Por exemplo, /*, /foo/* e /foo/bar/* são padrões válidos, mas *, /foo/bar* e /foo/*/bar não são.

Um padrão mais específico tem precedência sobre um padrão menos específico. Se tiver /foo/* e /foo/bar/*, considera-se que /foo/bar/bat corresponde a /foo/bar/*.

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

O manifesto do my-products serviço pode ter o seguinte aspeto:

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, tem de usar type: NodePort, a menos que esteja a usar o balanceamento de carga nativo do contentor. Se usar o balanceamento de carga nativa do contentor, use o type: ClusterIP.

No manifesto do serviço, o campo selector indica que qualquer Pod que tenha a etiqueta app: products e a etiqueta department: sales é membro deste serviço.

Quando um pedido chega ao serviço na porta 60000, é encaminhado para um dos pods membros na porta TCP 50000.

Cada pod de membro tem de ter um contentor a ouvir na porta TCP 50000.

O manifesto do my-discounted-products serviço pode ter o seguinte aspeto:

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 indica que qualquer Pod que tenha a etiqueta app: discounted-products e a etiqueta department: sales é membro deste serviço.

Quando um pedido chega ao serviço na porta 80, é encaminhado para um dos pods membros na porta TCP 8080.

Cada pod de membro tem de ter um contentor a ouvir na porta TCP 8080.

Backend predefinido

Pode especificar um back-end predefinido para o seu Ingress fornecendo um campo spec.defaultBackend no manifesto do Ingress. Isto processa todos os pedidos que não correspondem aos caminhos definidos no campo rules. Por exemplo, no Ingress seguinte, todos os pedidos que não correspondam a /discounted são enviados para um serviço denominado 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 não especificar um back-end predefinido, o GKE fornece um back-end predefinido que devolve 404. Este é criado como um default-http-backend serviço NodePort no cluster no espaço de nomes kube-system.

A resposta HTTP 404 é semelhante à seguinte:

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

Para configurar o GKE Ingress com um back-end predefinido do cliente, consulte o artigo GKE Ingress com back-end predefinido personalizado.

Ingress para mapeamentos de recursos do Compute Engine

O controlador de entrada do GKE implementa e gere recursos do balanceador de carga do Compute Engine com base nos recursos de entrada implementados no cluster. O mapeamento dos recursos do Compute Engine depende da estrutura do recurso Ingress.

O manifesto seguinte 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

Este manifesto de entrada indica ao GKE que crie os seguintes recursos do Compute Engine:

• Uma regra de encaminhamento e um endereço IP.
• Regras de firewall do Compute Engine que permitem o tráfego para verificações de estado do balanceador de carga e tráfego de aplicações a partir de front-ends da Google ou proxies Envoy.
• Um proxy HTTP de destino e um proxy HTTPS de destino, se tiver configurado o TLS.
• Um mapa de URLs com uma única regra de anfitrião que faz referência a um único correspondente de caminho. O localizador de caminhos tem duas regras de caminho, uma para /* e outra para /discounted. Cada regra de caminho é mapeada para um serviço de back-end único.
• NEGs que contêm uma lista de endereços IP de pods de cada serviço como pontos finais. Estas são criadas como resultado dos serviços my-discounted-products e my-products.

Opções para fornecer certificados SSL

Pode fornecer certificados SSL a um balanceador de carga de HTTP(S) através dos seguintes métodos:

Certificados geridos pela Google

Os

certificados SSL geridos pela Google são aprovisionados, implementados, renovados e geridos para os seus domínios. Os certificados geridos não suportam domínios com carateres universais.

Certificados autogeridos partilhados com Trusted Cloud

Pode aprovisionar o seu próprio certificado SSL e criar um recurso de certificado no seu Trusted Cloud projeto. Em seguida, pode listar o recurso de certificado numa anotação num Ingress para criar um balanceador de carga HTTP(S) que use o certificado. Consulte as instruções para certificados pré-partilhados para mais informações.

Certificados autogeridos como recursos Secret

Pode aprovisionar o seu próprio certificado SSL e criar um segredo para o guardar. Em seguida, pode consultar o segredo numa especificação de entrada para criar um balanceador de carga de HTTP(S) que use o certificado. Consulte as instruções para usar certificados em segredos para mais informações.

Verificações de funcionamento

Quando expõe um ou mais serviços através de um Ingress com o controlador Ingress predefinido, o GKE cria um balanceador de carga de aplicações clássico ou um balanceador de carga de aplicações interno. Ambos os balanceadores de carga suportam vários serviços de back-end num ú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 tem de fazer referência a uma Trusted Cloud verificação de estado. Esta verificação de funcionamento é diferente de uma sondagem de atividade ou disponibilidade do Kubernetes, porque a verificação de funcionamento é implementada fora do cluster.

As verificações de funcionamento do balanceador de carga são especificadas por serviço de back-end. Embora seja possível usar a mesma verificação de estado para todos os serviços de back-end do equilibrador de carga, a referência de verificação de estado não é especificada para todo o equilibrador de carga (no próprio objeto Ingress).

O GKE cria verificações de funcionamento com base num dos seguintes métodos:

• BackendConfig CRD: uma definição de recurso personalizado (CRD) que lhe dá controlo preciso sobre a forma como os seus serviços interagem com o balanceador de carga. BackendConfig Os CRDs permitem-lhe especificar definições personalizadas para a verificação de estado associada ao serviço de back-end correspondente. Estas definições personalizadas oferecem maior flexibilidade e controlo sobre as verificações de funcionamento para o balanceador de carga de aplicações clássico e o balanceador de carga de aplicações interno criados por um Ingress.
• Sondagem de prontidão: uma verificação de diagnóstico que determina se um contentor num pod está pronto para publicar tráfego. O controlador de entrada do GKE cria a verificação de estado do serviço de back-end do serviço com base na sondagem de disponibilidade usada pelos pods de publicação desse serviço. Pode derivar os parâmetros de verificação de estado, como o caminho, a porta e o protocolo, da definição da sondagem de disponibilidade.
• Valores predefinidos: os parâmetros usados quando não configura um BackendConfig CRD ou define atributos para a sondagem de prontidão.

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

• Se o serviço fizer referência a um BackendConfig CRD com informações healthCheck, o GKE usa-o para criar a verificação de estado. Tanto o controlador de entrada do GKE Enterprise como o controlador de entrada do GKE suportam a criação de verificações de funcionamento desta forma.

• Se o serviço não fizer referência a um CRD BackendConfig:

  • O GKE pode inferir alguns ou todos os parâmetros para uma verificação de estado se os pods de serviço usarem um modelo de pod com um contentor cuja sonda de disponibilidade tenha atributos que possam ser interpretados como parâmetros de verificação de estado. Consulte Parâmetros de uma análise de prontidão para ver detalhes de implementação e Parâmetros predefinidos e inferidos para ver uma lista de atributos que podem ser usados para criar parâmetros de verificação de estado. Apenas o controlador GKE Ingress suporta a inferência de parâmetros a partir de uma análise de prontidão.

  • Se o modelo de pod dos pods de publicação do serviço não tiver um contentor com uma sonda de prontidão cujos atributos possam ser interpretados como parâmetros de verificação de estado, os valores predefinidos são usados para criar a verificação de estado. Tanto o controlador de entrada do GKE Enterprise como o controlador de entrada do GKE podem criar uma verificação de estado de funcionamento apenas com os valores predefinidos.

Parâmetros predefinidos e inferidos

Os seguintes parâmetros são usados quando não especifica parâmetros de verificação do estado de funcionamento para o serviço correspondente através de um BackendConfigCRD.

Parâmetros de uma sonda de prontidão

Quando o GKE cria a verificação de estado do serviço de back-end do serviço, o GKE pode copiar determinados parâmetros da sondagem de disponibilidade de um contentor usada pelos pods de fornecimento desse serviço. Esta opção só é suportada pelo controlador de entrada do GKE.

Os atributos de teste de prontidão suportados que podem ser interpretados como parâmetros de verificação de estado são apresentados juntamente com os valores predefinidos em Parâmetros predefinidos e inferidos. Os valores predefinidos são usados para todos os atributos não especificados na sondagem de disponibilidade ou se não especificar nenhuma sondagem de disponibilidade.

Se a apresentação de pods para o seu serviço contiver vários contentores ou se estiver a usar o controlador de entrada do GKE Enterprise, deve usar um BackendConfigCRD para definir os parâmetros de verificação de estado. Para mais informações, consulte Quando usar um CRD BackendConfig em alternativa.

Quando usar CRDs BackendConfig em alternativa

Em vez de depender de parâmetros de sondagens de prontidão de pods, deve definir explicitamente os parâmetros de verificação de estado de um serviço de back-end criando um CRD BackendConfig para o serviço nestas situações:

• Se estiver a usar o GKE Enterprise: o controlador de entrada do GKE Enterprise não suporta a obtenção de parâmetros de verificação de estado das sondas de disponibilidade dos pods de publicação. Só pode criar verificações de funcionamento com parâmetros implícitos ou conforme definido numa CRD BackendConfig.

• Se tiver mais do que um contentor nos pods de publicação: o GKE não tem forma de selecionar a sonda de prontidão de um contentor específico a partir do qual inferir parâmetros de verificação de estado. Uma vez que cada contentor pode ter a sua própria sondagem de disponibilidade e uma sondagem de disponibilidade não é um parâmetro obrigatório para um contentor, deve definir a verificação de estado do serviço de back-end correspondente referindo-se a um CRD BackendConfig no serviço correspondente.

• Se precisar de controlo sobre a porta usada para as verificações de funcionamento do balanceador de carga: o GKE usa apenas a porta da sonda de disponibilidadecontainers[].readinessProbe.httpGet.port para a verificação de funcionamento do serviço de back-end quando essa porta corresponde à porta de serviço do serviço referenciado no Ingressspec.rules[].http.paths[].backend.servicePort.

Parâmetros de um CRD BackendConfig

Pode especificar os parâmetros de verificação do estado do serviço de back-end através do parâmetro healthCheck de um BackendConfigCRD referenciado pelo serviço correspondente. Isto dá-lhe mais flexibilidade e controlo sobre as verificações de funcionamento de um balanceador de carga de aplicações clássico ou um balanceador de carga de aplicações interno criado por um Ingress. Consulte a configuração de entrada para a compatibilidade de versões do GKE.

Este CRD BackendConfig define o protocolo de verificação de funcionamento (tipo), um caminho de pedido, uma porta e um intervalo de verificação no respetivo 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 configurar todos os campos disponíveis quando configurar uma BackendConfigverificação de estado, use o exemplo de configuração de verificação de estado personalizada.

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.

Usar vários certificados TLS

Suponhamos que quer que um balanceador de carga HTTP(S) publique conteúdo a partir de dois nomes de anfitrião: your-store.example e your-experimental-store.example. Além disso, quer que o balanceador de carga use um certificado para o domínio your-store.example e um certificado diferente para o domínio your-experimental-store.example.

Pode fazê-lo especificando vários certificados num manifesto Ingress. O balanceador de carga escolhe um certificado se o nome comum (CN) no certificado corresponder ao nome de anfitrião usado no pedido. Para obter informações detalhadas sobre como configurar vários certificados, consulte o artigo Usar vários certificados SSL no equilíbrio de carga HTTPS com entrada.

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

Um serviço do Kubernetes e um Trusted Cloud serviço de back-end são coisas diferentes. Existe uma forte relação entre os dois, mas a relação não é necessariamente individual. O controlador de entrada do GKE cria um serviço de back-end para cada par (service.name, service.port) num manifesto de entrada. Trusted Cloud Assim, é possível que um objeto de serviço do Kubernetes esteja relacionado com vários serviços de back-end. Trusted Cloud

Limitações

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

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

• Aplicam-se quotas para mapas de URLs.

• Aplicam-se as quotas para recursos do Compute Engine.

• Se não estiver a usar NEGs com o controlador de entrada do GKE, os clusters do GKE têm um limite de 1000 nós. Quando os serviços são implementados com NEGs, não existe um limite de nós do GKE. Todos os serviços não NEG expostos através do Ingress não funcionam corretamente em clusters com mais de 1000 nós.

• Para que o controlador GKE Ingress use o seu readinessProbes como verificações de estado, os pods de um Ingress têm de existir no momento da criação do Ingress. Se as réplicas forem dimensionadas para 0, é aplicada a verificação de estado predefinida. Para mais informações, consulte este comentário sobre o problema do GitHub acerca das verificações de estado.

• As alterações ao readinessProbe de um Pod não afetam o Ingress depois de ser criado.

• Um Application Load Balancer externo termina o TLS em localizações distribuídas globalmente para minimizar a latência entre os clientes e o balanceador de carga. Se precisar de controlo geográfico sobre onde o TLS é terminado, deve usar um controlador de entrada personalizado exposto através de um serviço GKE do tipo LoadBalancer e terminar o TLS em back-ends localizados em regiões adequadas às suas necessidades.

• A combinação de vários recursos Ingress num único Trusted Cloud by S3NS equilibrador de carga não é suportada.

• Tem de desativar o TLS mútuo na sua aplicação porque não é suportado para equilibradores de carga de aplicações externos.

• O Ingress só pode expor as portas HTTP 80 e 443 para o respetivo front-end.

Detalhes da implementação

• O controlador de entrada faz verificações periódicas das autorizações da conta de serviço ao obter um recurso de teste do seu Trusted Cloud by S3NS projeto. Vai ver isto como um GET do BackendService global (inexistente) com o nome k8s-ingress-svc-acct-permission-check-probe. Uma vez que este recurso não deve existir normalmente, o pedido GET devolve "não encontrado". Isto é esperado; o controlador está a verificar se a chamada API não é rejeitada devido a problemas de autorização. Se criar um BackendService com o mesmo nome, a operação GET é bem-sucedida em vez de devolver "not found" (não encontrado).

Modelos para a configuração de entrada

• Em GKE Networking Recipes, pode encontrar modelos fornecidos pelo GKE para muitas utilizações comuns do Ingress na secção Ingress.

O que se segue?

• Saiba mais sobre as receitas de rede do GKE
• Saiba mais sobre o equilíbrio de carga no Trusted Cloud.
• Leia uma vista geral das redes no GKE.
• Saiba como configurar o Ingress para equilibradores de carga de aplicações internos.
• Saiba como configurar o Ingress para equilibradores de carga de aplicações externos.