Entrada para balanceadores de carga de aplicações externos

Esta página explica como funciona a entrada para balanceadores de carga de aplicações externos no Google Kubernetes Engine (GKE). Também pode saber como configurar e usar o Ingress para o equilíbrio de carga externo.

Para ver informações gerais sobre a utilização do balanceamento de carga no GKE, consulte o artigo Entrada para balanceadores de carga de aplicações externos.

A rede do Google Kubernetes Engine (GKE) baseia-se no Cloud Load Balancing. Com o Cloud Load Balancing, um único endereço IP anycast permite que o encaminhamento determine o caminho de menor custo para o Trusted Cloud balanceador de carga mais próximo.

Suporte para Trusted Cloud funcionalidades

Pode usar um BackendConfig para configurar um Application Load Balancer externo para usar funcionalidades como:

O BackendConfig é um recurso personalizado que contém informações de configuração para Trusted Cloud funcionalidades. Para saber mais acerca das funcionalidades suportadas, consulte o artigo Configuração de entrada.

Suporte para WebSocket

Com os balanceadores de carga de aplicações externos, o protocolo WebSocket funciona sem qualquer configuração.

Se pretender usar o protocolo WebSocket, é recomendável usar um valor de limite de tempo superior aos 30 segundos predefinidos. Para o tráfego WebSocket enviado através de um Trusted Cloud Application Load Balancer externo, o limite de tempo do serviço de back-end é interpretado como o tempo máximo durante o qual uma ligação WebSocket pode permanecer aberta, quer esteja inativa ou não.

Para definir o valor de tempo limite para um serviço de back-end configurado através do Ingress, crie um objeto BackendConfig e use a anotação beta.cloud.google.com/backend-config no manifesto do serviço.

Para ver informações de configuração, consulte o artigo Limite de tempo de resposta do back-end.

Endereços IP estáticos para balanceadores de carga HTTPS

Quando cria um objeto Ingress, recebe um endereço IP externo estável que os clientes podem usar para aceder aos seus serviços e, por sua vez, aos seus contentores em execução. O endereço IP é estável no sentido de que dura durante a duração total do objeto Ingress. Se eliminar o Ingress e criar um novo Ingress a partir do mesmo ficheiro de manifesto, não tem a garantia de receber o mesmo endereço IP externo.

Se quiser um endereço IP permanente que se mantenha o mesmo mesmo depois de eliminar a entrada e criar uma nova, tem de reservar um endereço IP externo estático global. Em seguida, no manifesto de entrada, inclua uma anotação que indique o nome do endereço IP estático reservado. 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 equilibrador de carga quando o GKE recria a regra de encaminhamento do equilibrador de carga.

Por exemplo, suponhamos que reservou um endereço IP externo estático global denominado my-static-address. No manifesto do Ingress, inclua uma anotação kubernetes.io/ingress.global-static-ip-name, conforme mostrado aqui:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: my-static-address

Configurar HTTPS (TLS) entre o cliente e o balanceador de carga

Um balanceador de carga HTTP(S) 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.

Quando o balanceador de carga aceita um pedido HTTPS de um cliente, o tráfego entre o cliente e o balanceador de carga é encriptado através do protocolo TLS. No entanto, o balanceador de carga termina a encriptação TLS e encaminha o pedido sem encriptação para a aplicação. Para ver informações sobre como encriptar o tráfego entre o balanceador de carga e a sua aplicação, consulte o artigo HTTPS entre o balanceador de carga e a sua aplicação.

Pode usar certificados SSL geridos pela Google ou certificados que gere de forma autónoma. Para mais informações sobre a criação de um Ingress que usa certificados geridos pela Google, consulte o artigo Usar certificados SSL geridos pela Google.

Para fornecer um balanceador de carga HTTP(S) com um certificado e uma chave que criou você mesmo, crie um objeto Kubernetes Secret. O segredo contém o certificado e a chave. Adicione o segredo ao campo tls do manifesto Ingress, como no exemplo seguinte:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
spec:
  tls:
  - secretName: SECRET_NAME
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 60000

Este manifesto inclui os seguintes valores:

  • SECRET_NAME: o nome do segredo que criou.
  • SERVICE_NAME: o nome do seu serviço de back-end.

As alterações aos segredos são detetadas periodicamente. Por isso, se modificar os dados no interior do segredo, estas alterações demoram um máximo de 10 minutos a serem aplicadas ao equilibrador de carga.

Para mais informações, consulte o artigo Usar vários certificados SSL no balanceamento de carga HTTPS com o Ingress.

Para proteger o Ingress encriptado por HTTPS para os seus clusters do GKE, consulte o exemplo Ingress seguro.

Desativar HTTP

Se quiser que todo o tráfego entre o cliente e o balanceador de carga de HTTP(S) use HTTPS, pode desativar o HTTP incluindo a anotação kubernetes.io/ingress.allow-http no manifesto do Ingress. Defina o valor da anotação como "false".

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

Este manifesto inclui o SECRET_NAME, que é o nome do Secret que criou.

Certificados pré-partilhados para balanceadores de carga

Em alternativa à utilização de segredos do Kubernetes para fornecer certificados ao balanceador de carga para a terminação de HTTP(S), pode usar certificados carregados anteriormente para o seu Trusted Cloud projeto. Para mais informações, consulte os artigos Usar certificados pré-partilhados e Usar vários certificados SSL no balanceamento de carga HTTPS com Ingress.

HTTPS (TLS) entre o balanceador de carga e a sua aplicação

Um balanceador de carga HTTP(S) funciona como um proxy entre os seus clientes e a sua aplicação. Os clientes podem usar HTTP ou HTTPS para comunicar com o proxy do balanceador de carga. A ligação do proxy do balanceador de carga à sua aplicação usa HTTP por predefinição. No entanto, se a sua aplicação, em execução 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 configurar o protocolo usado entre o balanceador de carga e a sua aplicação, use a anotação cloud.google.com/app-protocols no manifesto do serviço. Este manifesto de serviço tem de incluir type: NodePort, a menos que esteja a usar o equilíbrio de carga nativo do contentor. Se usar o balanceamento de carga nativa do contentor, use o type: ClusterIP.

O manifesto de serviço seguinte especifica duas portas. A anotação indica que, quando um balanceador de carga de HTTP(S) segmenta a porta 80 do serviço, deve usar HTTP. Além disso, quando o balanceador de carga segmenta a porta 443 do serviço, deve usar HTTPS.

O manifesto do serviço tem de incluir um valor name na anotação da porta. Só pode editar a porta de serviço consultando o respetivo name atribuído e não o valor targetPort.

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

O que se segue?