Como configurar o Ingress para balanceamento de carga externo

Nesta página, você verá como configurar um balanceador de carga HTTP(S) externo criando um objeto Ingress do Kubernetes. O objeto Ingress precisa estar associado a um ou mais objetos Service e, cada um deles, associado a um conjunto de pods.

Um objeto Service tem uma ou mais estruturas servicePort (em inglês). Cada servicePort segmentado por um Ingress está associado a um recurso do serviço de back-end do Google Cloud.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

Defina configurações gcloud padrão usando um dos métodos a seguir:

  • Use gcloud init se você quiser ser orientado sobre como definir padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão:
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Vários serviços de back-end

Um balanceador de carga HTTP(S) fornece um endereço IP estável que pode ser usado para rotear solicitações para diversos serviços de back-end.

Neste exercício, você configura o balanceador de carga para rotear solicitações para diferentes serviços de back-end, dependendo do caminho do URL. Solicitações que têm o caminho / são roteadas para um serviço de back-end, e as solicitações que têm o caminho /kube são roteadas para um serviço de back-end diferente.

Veja a ideia geral dos passos neste exercício:

  1. Crie um Deployment e o exponha a um Service chamado hello-world.
  2. Crie um segundo Deployment e o exponha com um Service chamado hello-kubernetes.
  3. Crie um Ingress que especifique regras para rotear solicitações para um Service ou outro, dependendo do caminho do URL na solicitação. Quando você cria o Ingress, o controlador de entrada GKE cria e configura um balanceador de carga HTTP(S).
  4. Teste o balanceador de carga HTTP(S).

Veja aqui um manifesto de um Deployment:

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-world-deployment
    spec:
      selector:
        matchLabels:
          greeting: hello
          department: world
      replicas: 3
      template:
        metadata:
          labels:
            greeting: hello
            department: world
        spec:
          containers:
          - name: hello
            image: "gcr.io/google-samples/hello-app:2.0"
            env:
            - name: "PORT"
              value: "50000"
    

Copie o manifesto em um arquivo chamado hello-world-deployment.yaml e crie o Deployment:

kubectl apply -f hello-world-deployment.yaml
    

Veja aqui um manifesto para um Service que expõe seu primeiro Deployment:

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

Para os fins deste exercício, estes são os pontos importantes que você precisa entender sobre o Service:

  • Qualquer pod que tenha os rótulos greeting: hello e department: world é membro do Service.

  • Quando uma solicitação é enviada ao Service na porta TCP 60.000, ela é encaminhada para um dos pods membros na porta TCP 50.000.

O único caractere curinga aceito no campo path de um Ingress é o *. 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/*, então /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.

Copie o manifesto em um arquivo chamado hello-world-service.yaml e crie o Service:

kubectl apply -f hello-world-service.yaml
    

Veja aqui um manifesto para um segundo Deployment:

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-kubernetes-deployment
    spec:
      selector:
        matchLabels:
          greeting: hello
          department: kubernetes
      replicas: 3
      template:
        metadata:
          labels:
            greeting: hello
            department: kubernetes
        spec:
          containers:
          - name: hello-again
            image: "gcr.io/google-samples/node-hello:1.0"
            env:
            - name: "PORT"
              value: "8080"
    

Copie o manifesto em um arquivo chamado hello-kubernetes-deployment.yaml e crie o Deployment:

kubectl apply -f hello-kubernetes-deployment.yaml
    

Veja aqui um manifesto para um Service que expõe seu segundo Deployment:

apiVersion: v1
    kind: Service
    metadata:
      name: hello-kubernetes
    spec:
      type: NodePort
      selector:
        greeting: hello
        department: kubernetes
      ports:
      - protocol: TCP
        port: 80
        targetPort: 8080
    

Para os fins deste exercício, estes são os pontos importantes que você precisa entender sobre o Service:

  • Qualquer pod que tenha os rótulos greeting: hello e department: kubernetes é membro do Service.

  • Quando uma solicitação é enviada ao Service na porta TCP 80, ela é encaminhada para um dos pods membros na porta TCP 8080.

Copie o manifesto em um arquivo chamado hello-kubernetes-service.yaml e crie o Service:

kubectl apply -f hello-kubernetes-service.yaml
    

Veja aqui um manifesto de um Ingress:

apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: my-ingress
    spec:
      rules:
      - http:
          paths:
          - path: /*
            backend:
              serviceName: hello-world
              servicePort: 60000
          - path: /kube
            backend:
              serviceName: hello-kubernetes
              servicePort: 80
    

Observe que o manifesto de Ingress tem dois pares: serviceName e servicePort. Cada um deles (serviceName, servicePort) está associado a um serviço de back-end do Google Cloud.

Copie o manifesto para um arquivo chamado my-ingress.yaml e crie o Ingress:

kubectl apply -f my-ingress.yaml
    

Quando você cria o Ingress, o controlador de entrada do GKE cria um balanceador de carga HTTP(S) e o configura da maneira a seguir:

  • Quando um cliente envia uma solicitação ao balanceador de carga com o caminho do URL /, a solicitação é encaminhada para o Service hello-world na porta 60.000.

  • Quando um cliente envia uma solicitação ao balanceador de carga usando o caminho do URL /kube, a solicitação é encaminhada para o Service hello-kubernetes na porta 80.

Aguarde cerca de cinco minutos até que o balanceador de carga seja configurado.

Veja o Ingress:

kubectl get ingress my-ingress --output yaml
    

A saída mostra o endereço IP externo do balanceador de carga HTTP(S).

status:
      loadBalancer:
        ingress:
        - ip: 203.0.113.1
    

Teste o caminho /:

curl [LOAD_BALANCER_IP]/
    

em que [LOAD_BALANCER_IP] é o endereço IP externo do balanceador de carga.

A saída mostra uma mensagem Hello, world!:

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

Teste o caminho /kube:

curl [LOAD_BALANCER_IP]/kube
    

A saída mostra uma mensagem Hello Kubernetes:

Hello Kubernetes!
    

HTTPS entre o cliente e o balanceador de carga

Um balanceador de carga HTTP(S) atua como um proxy entre seus clientes e o aplicativo. Se você quiser aceitar solicitações HTTPS dos seus clientes, o balanceador de carga precisará ter um certificado para provar sua identidade a eles. Além disso, ele precisa ter uma chave privada para concluir o handshake HTTPS. Veja mais informações em:

Como desativar o HTTP

Se você quiser que todo o tráfego entre o cliente e o balanceador de carga use HTTPS, é possível desativar o HTTP. Para mais informações, consulte Como desativar o HTTP.

HTTPS entre o balanceador de carga e o cliente

Se o aplicativo, em execução em um pod do GKE, for capaz de receber solicitações HTTPS, é possível configurar o balanceador de carga para usar HTTPS quando encaminhar solicitações para o aplicativo. Para mais informações, consulte HTTPS (TLS) entre o balanceador de carga e o aplicativo.

HTTP/2 entre o cliente e o balanceador de carga

Os clientes podem usar HTTP/2 para enviar solicitações ao balanceador de carga. Nenhuma configuração é necessária.

HTTP/2 entre o balanceador de carga e o aplicativo

Se seu aplicativo em execução em um pod do GKE for capaz de receber solicitações HTTP/2, é possível configurar o balanceador de carga para usar HTTP/2 ao encaminhar solicitações para o aplicativo. Para mais informações, consulte HTTP/2 para balanceamento de carga com Ingress.

Grupos de endpoint de rede

Se o cluster for compatível com balanceamento de carga nativo de contêiner, é possível configurar o balanceador de carga para usar grupos de endpoint de rede. Para mais informações, consulte Como usar balanceamento de carga nativo de contêiner.

Resumo das anotações de Ingress externo

Anotações do Ingress

Anotação Descrição
kubernetes.io/ingress.allow-http Especifica se o tráfego HTTP será permitido entre o cliente e o balanceador de carga HTTP(S). Os valores possíveis são "verdadeiro" e "falso". O padrão é "verdadeiro". Consulte Como desativar o HTTP.
ingress.gcp.kubernetes.io/pre-shared-cert É possível fazer upload de certificados e chaves para seu projeto do Google Cloud. Use essa anotação para fazer referência aos certificados e às chaves. Consulte Como usar vários certificados SSL no balanceamento de carga HTTP(S).
kubernetes.io/ingress.global-static-ip-name Use essa anotação para especificar que o balanceador de carga usará um endereço IP externo e estático que você criou anteriormente. Consulte Endereços IP estáticos para balanceadores de carga HTTP(S).
Anotação Descrição
service.alpha.kubernetes.io/app-protocols Use essa anotação para definir o protocolo de comunicação entre o balanceador de carga e o aplicativo. Os protocolos possíveis são HTTP, HTTPS e HTTP/2. Consulte HTTPS entre o balanceador de carga e o aplicativo e HTTP/2 para balanceamento de carga com Ingress.
beta.cloud.google.com/backend-config Use essa anotação para configurar o serviço de back-end associado a um servicePort. Consulte Recurso personalizado BackendConfig.
cloud.google.com/neg Use essa anotação para especificar que o balanceador de carga usará grupos de endpoint de rede. Consulte Como usar o balanceamento de carga nativo de contêiner.

A seguir