Configure a entrada para balanceadores de carga de aplicações externos

Esta página mostra como configurar um balanceador de carga de aplicações externo criando um objeto Kubernetes Ingress.

Antes de ler esta página, certifique-se de que conhece os conceitos de rede do GKE.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

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

Ative o suplemento HttpLoadBalancing

O seu cluster tem de ter o suplemento HttpLoadBalancing ativado. Este suplemento está ativado por predefinição. Nos clusters do Autopilot, não pode desativar este suplemento.

Pode ativar o suplemento HttpLoadBalancing através da consola Trusted Cloud ou da Google Cloud CLI.

gcloud container clusters update CLUSTER_NAME --update-addons=HttpLoadBalancing=ENABLED

Crie um endereço IP estático

Um Application Load Balancer externo fornece um endereço IP estável que pode usar para encaminhar pedidos para um ou mais serviços. Se quiser um endereço IP permanente, tem de reservar um endereço IP externo estático global antes de criar uma entrada.

Se modificar um Ingress existente para usar um endereço IP estático em vez de um endereço IP efémero, o GKE pode alterar o endereço IP do balanceador de carga quando o GKE recria a regra de encaminhamento do balanceador de carga.

Crie um balanceador de carga de aplicações externo

Neste exercício, vai configurar um Application Load Balancer externo para encaminhar pedidos para diferentes serviços consoante o caminho do URL.

Crie implementações e serviços

Crie duas implementações com serviços denominados hello-world-1 e hello-world-2:

1. Guarde o seguinte manifesto como hello-world-deployment-1.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: hello-world-deployment-1
   spec:
     selector:
       matchLabels:
         greeting: hello
         version: one
     replicas: 3
     template:
       metadata:
         labels:
           greeting: hello
           version: one
       spec:
         containers:
         - name: hello-app-1
           image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0"
           env:
           - name: "PORT"
             value: "50000"
   

   Este manifesto descreve uma implementação de exemplo com três réplicas.

2. Aplique o manifesto ao cluster:

   kubectl apply -f hello-world-deployment-1.yaml
   

3. Guarde o seguinte manifesto como hello-world-service-1.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: hello-world-1
   spec:
     type: NodePort
     selector:
       greeting: hello
       version: one
     ports:
     - protocol: TCP
       port: 60000
       targetPort: 50000
   

   Este manifesto descreve um serviço com as seguintes propriedades:

   • Qualquer Pod que tenha a etiqueta greeting: hello e a etiqueta version: one é membro do serviço.
   • O GKE encaminha os pedidos enviados para o serviço na porta TCP 60000 para um dos pods membros na porta TCP 50000.
   • O tipo de serviço é NodePort, que é obrigatório, a menos que esteja a usar o balanceamento de carga nativa do contentor. Se usar o balanceamento de carga nativa do contentor, não existe restrição quanto ao tipo de serviço. Recomendamos que use type: ClusterIP.

4. Aplique o manifesto ao cluster:

   kubectl apply -f hello-world-service-1.yaml
   

5. Guarde o seguinte manifesto como hello-world-deployment-2.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: hello-world-deployment-2
   spec:
     selector:
       matchLabels:
         greeting: hello
         version: two
     replicas: 3
     template:
       metadata:
         labels:
           greeting: hello
           version: two
       spec:
         containers:
         - name: hello-app-2
           image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"
           env:
           - name: "PORT"
             value: "8080"
   

   Este manifesto descreve uma implementação de exemplo com três réplicas.

6. Aplique o manifesto ao cluster:

   kubectl apply -f hello-world-deployment-2.yaml
   

7. Guarde o seguinte manifesto como hello-world-service-2.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: hello-world-2
   spec:
     type: NodePort
     selector:
       greeting: hello
       version: two
     ports:
     - protocol: TCP
       port: 80
       targetPort: 8080
   

   Este manifesto descreve um serviço com as seguintes propriedades:

   • Qualquer Pod que tenha a etiqueta greeting: hello e a etiqueta version: two é membro do serviço.
   • O GKE encaminha os pedidos enviados para o serviço na porta TCP 80 para um dos pods membros na porta TCP 8080.

8. Aplique o manifesto ao cluster:

   kubectl apply -f hello-world-service-2.yaml
   

Crie um Ingress

Crie um Ingress que especifique regras para encaminhar pedidos consoante o caminho do URL no pedido. Quando cria a entrada, o controlador de entrada do GKE cria e configura um equilibrador de carga de aplicações externo.

1. Guarde o seguinte manifesto como my-ingress.yaml:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-ingress
     annotations:
       # If the class annotation is not specified it defaults to "gce".
       kubernetes.io/ingress.class: "gce"
   spec:
     rules:
     - http:
         paths:
         - path: /*
           pathType: ImplementationSpecific
           backend:
             service:
               name: hello-world-1
               port:
                 number: 60000
         - path: /v2
           pathType: ImplementationSpecific
           backend:
             service:
               name: hello-world-2
               port:
                 number: 80
   

   Este manifesto descreve um Ingress com as seguintes propriedades:

   • Existem duas classes de GKE Ingress. Para especificar uma classe Ingress, tem de usar a anotação kubernetes.io/ingress.class. Não pode especificar um GKE Ingress através de spec.ingressClassName.

   • A classe gce implementa um balanceador de carga de aplicações externo.

   • A classe gce-internal implementa um balanceador de carga de aplicações interno.

   • Quando implementa um recurso Ingress sem as anotações spec.ingressClassName e kubernetes.io/ingress.class, o GKE cria um Application Load Balancer externo. Este é o mesmo comportamento que ocorre se especificar a anotação kubernetes.io/ingress.class: gce. Para mais informações, consulte Comportamento do controlador de entrada do GKE.

   • O GKE cria um Trusted Cloud serviço de back-end para cada backend.service. 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. Para saber mais, consulte Verificações de saúde

   • Quando um cliente envia um pedido para o balanceador de carga com o caminho do URL /, o GKE encaminha o pedido para o serviço hello-world-1 na porta 60000. Quando um cliente envia um pedido para o balanceador de carga através do caminho do URL /v2, o GKE encaminha o pedido para o hello-world-2 serviço na porta 80. Para mais informações sobre as propriedades path e pathType, consulte o artigo Caminhos de URL.

2. Aplique o manifesto ao cluster:

   kubectl apply -f my-ingress.yaml
   

Teste o balanceador de carga de aplicações externo

Aguarde cerca de cinco minutos para que o balanceador de carga seja configurado e, em seguida, teste o balanceador de carga de aplicações externo:

1. Veja a entrada:

   kubectl get ingress my-ingress --output yaml
   

   A saída mostra o endereço IP do Application Load Balancer externo:

   status:
     loadBalancer:
       ingress:
       - ip: 203.0.113.1
   

2. Teste o caminho /:

   curl LOAD_BALANCER_IP_ADDRESS/
   

   Substitua LOAD_BALANCER_IP_ADDRESS pelo endereço IP externo do balanceador de carga.

   O resultado é semelhante ao seguinte:

   Hello, world!
   Version: 1.0.0
   Hostname: ...
   

   Se o resultado incluir um erro 404, aguarde alguns minutos.

3. Teste o caminho /v2:

   curl load-balancer-ip/v2
   

   O resultado é semelhante ao seguinte:

   Hello, world!
   Version: 2.0.0
   Hostname: ...
   

Como funciona a entrada para o balanceamento de carga externo

Um balanceador de carga de aplicações externo funciona como um proxy entre os seus clientes e a sua aplicação. Se quiser aceitar pedidos HTTPS dos seus clientes, o equilibrador de carga tem de ter um certificado para poder comprovar a sua identidade aos clientes. O balanceador de carga também tem de ter uma chave privada para concluir o handshake HTTPS. Para mais informações, consulte:

• Configurar o HTTPS (TLS) entre o cliente e o balanceador de carga.
• Usar vários certificados SSL no balanceamento de carga HTTPS com entrada.

Caminhos de URLs

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 limitações de caminhos e correspondência de padrões, consulte a documentação dos mapas de URLs.

Para clusters do GKE com versões anteriores a 1.21.3-gke.1600, o único valor suportado para o campo pathType é ImplementationSpecific. Para clusters com a versão 1.21.3-gke.1600 ou posterior, os valores Prefix e Exact também são suportados para pathType.

Desativar HTTP

Se quiser que todo o tráfego entre o cliente e o equilibrador de carga use HTTPS, pode desativar o HTTP. Para mais informações, consulte o artigo Desativar HTTP.

HTTPS entre o balanceador de carga e a aplicação

Se a sua aplicação, executada num pod do GKE, for capaz de receber pedidos HTTPS, pode configurar o balanceador de carga para usar HTTPS quando encaminha pedidos para a sua aplicação. Para mais informações, consulte o artigo HTTPS (TLS) entre o balanceador de carga e a sua aplicação.

HTTP/2 entre o cliente e o balanceador de carga

Os clientes podem usar HTTP/2 para enviar pedidos para o balanceador de carga. Não é necessária qualquer configuração.

HTTP/2 entre o balanceador de carga e a aplicação

Se a sua aplicação, em execução num pod do GKE, for capaz de receber pedidos HTTP/2, pode configurar o balanceador de carga para usar HTTP/2 quando encaminha pedidos para a sua aplicação. Para mais informações, consulte o artigo HTTP/2 para balanceamento de carga com entrada.

Grupos de pontos finais da rede

Se o seu cluster suportar o equilíbrio de carga nativo de contentores, é recomendável usar grupos de pontos finais de rede (NEGs). Para clusters do GKE 1.17 e posteriores e em determinadas condições, o equilíbrio de carga nativo de contentores é predefinido e não requer uma anotação de serviço cloud.google.com/neg: '{"ingress": true}'explícita.

VPC partilhada

Se o cluster do GKE no qual está a implementar os recursos do Ingress estiver num projeto de serviço e quiser que o plano de controlo do GKE faça a gestão dos recursos da 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 no projeto anfitrião, conforme descrito no artigo Gerir recursos da firewall para clusters com VPC partilhada. Isto permite que o controlador de entrada crie regras de firewall para permitir o tráfego de entrada e o tráfego para Trusted Cloud verificações de funcionamento.

Segue-se um exemplo de um evento que pode estar presente nos registos de recursos de entrada. Este erro ocorre quando o controlador de entrada não consegue criar uma regra de firewall para permitir o tráfego de entrada para as verificações de funcionamento se as autorizações não estiverem configuradas corretamente. Trusted Cloud

Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>

Se preferir aprovisionar manualmente regras de firewall a partir do projeto anfitrião, pode desativar os eventos firewallXPNError adicionando a anotação networking.gke.io/suppress-firewall-xpn-error: "true" ao recurso de entrada.

Resumo das anotações de entrada externas

Anotações de entrada

Anotações de serviço relacionadas com o Ingress

O que se segue?

• Leia uma vista geral conceptual da entrada para balanceadores de carga de aplicações externos no GKE.

• Realize o tutorial sobre como configurar um balanceador de carga de aplicações externo com a entrada.

• Leia uma vista geral conceptual dos serviços no GKE.

• Implemente uma entrada externa básica.