Balanceamento de carga interno

Nesta página, explicamos como criar um balanceador de carga interno no Kubernetes Engine e no Kubernetes.

O balanceamento de carga interno torna os serviços do cluster acessíveis para aplicativos em execução na mesma rede, mas fora do cluster. Por exemplo, se você executar um cluster junto de algumas instâncias de VM do Compute Engine na mesma rede e quiser que os serviços internos do cluster estejam disponíveis para as instâncias externas do cluster, será necessário configurar um dos recursos do serviço do cluster para adicionar um balanceador de carga interno.

Sem o balanceamento de carga interno, você precisará configurar balanceadores de carga externos, criar regras de firewall para limitar o acesso e configurar rotas de rede para tornar o endereço IP do aplicativo acessível fora do cluster.

O balanceamento de carga interno cria um endereço IP (RFC1918) LoadBalancer Ingress privado no cluster para receber o tráfego na rede dentro da mesma região de computação de um intervalo IP na sub-rede do usuário.

Você cria um balanceador de carga interno adicionando uma especificação LoadBalancer a um recurso do serviço. Se o cluster não tiver um serviço, você precisará criar um. Em seguida, você pode criar o balanceador de carga interno usando a interface de linha de comando kubectl do Kubernetes.

Antes de começar

Como gravar o arquivo de configuração do serviço

Veja a seguir um exemplo de um recurso do serviço que configura um balanceador de carga interno:

config.yaml

apiVersion: v1
kind: Service
metadata:
  name: [SERVICE-NAME]
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
  labels:
    app: echo
spec:
  type: LoadBalancer
  loadBalancerIP: [IP-ADDRESS]
  ports:
  - port: 9000
    protocol: TCP
  selector:
    [KEY]: [VALUE]

O arquivo de configuração do serviço precisa conter os seguintes elementos:

  • o tipo LoadBalancer e os campos port
  • uma anotação cloud.google.com/load-balancer-type: "Internal", que especifica que um balanceador de carga interno será configurado
  • [SERVICE-NAME], que é o nome escolhido para o serviço

O campo opcional spec: protocol define o protocolo de rede que o balanceador de carga interno usará. Se o campo for omitido, o protocolo será configurado como TCP.

O campo opcional spec: loadBalancerIP permite que você escolha um endereço IP específico. O endereço IP não pode ser utilizado por outro serviço ou balanceador de carga interno. Se o campo loadBalancerIP não for especificado, um IP temporário será atribuído a LoadBalancer.

O serviço também precisa ter um campo spec: selector para especificar os pods que ele precisa segmentar. Por exemplo, o selector pode segmentar pods marcados com app: echo.

Criar o balanceador de carga interno

Para criar o balanceador de carga interno, execute o seguinte comando no shell ou na janela de terminal:

kubectl apply -f config.yaml

Esse comando atualizará o serviço existente para adicionar um balanceador de carga interno ou criará um serviço novo com um balanceador de carga interno.

Inspecionar o serviço

Console

Para visualizar detalhes sobre o balanceador de carga interno, execute as etapas abaixo:

Console

  1. Acesse o menu "Descobertas e balanceamento de carga" do Kubernetes Engine no Console do Google Cloud Platform.

    Acessar o menu "Descobertas e balanceamento de carga"

  2. Selecione o serviço desejado.

gcloud

Para verificar se o serviço foi criado ou atualizado conforme o esperado, execute o seguinte comando:

kubectl describe service [SERVICE-NAME]

O resultado do comando é semelhante ao seguinte:

Name:     [SERVICE-NAME]
Namespace:    default
Labels:     app=echo
Annotations:    cloud.google.com/load-balancer-type=Internal
Selector:   app=echo
Type:     LoadBalancer
IP:     10.0.146.226
LoadBalancer Ingress: 10.128.0.6
Port:       9000/TCP
NodePort:   30387/TCP
Endpoints:    10.100.1.10:80,10.100.2.10:80,10.100.3.8:80
Session Affinity: ClientIP

Como usar o balanceador de carga interno

Os balanceadores de carga internos são compatíveis com parâmetros de serviços do Kubernetes, como externalTrafficPolicy, sessionAffinity e loadBalancerSourceRanges.

Você pode continuar acessando o serviço de dentro do cluster usando clusterIP (no exemplo acima, IP). Para acessar o serviço de fora do cluster, use o endereço IP LoadBalancer Ingress.

Para mais informações sobre como configurar os parâmetros do serviço, consulte Configurar os firewalls do provedor de nuvem.

Considerações para entradas existentes

Se o cluster tiver um recurso de entrada existente, esse recurso precisa usar o modo de balanceamento RATE. O modo de balanceamento UTILIZATION não é compatível.

Os recursos BackendService anteriores criados por objetos dos Recursos de entrada do Kubernetes foram gerados sem modo de balanceamento especificado. Por padrão, a API usou o modo de balanceamento UTILIZATION para balanceadores de carga HTTP. No entanto, balanceadores de carga internos não podem ser apontados para grupos de instâncias com outros balanceadores de carga usando UTILIZATION.

Para garantir a compatibilidade em um cluster do Kubernetes com um balanceador de carga interno e recursos de entrada, talvez seja necessário executar algumas etapas manuais.

Determinar se a entrada é compatível

Para determinar se a entrada é compatível, execute os seguintes comandos no shell ou na janela de terminal:

GROUPNAME=`kubectl get configmaps ingress-uid -o jsonpath='k8s-ig--{.data.uid}' --namespace=kube-system`
gcloud compute backend-services list --format="table(name,backends[].balancingMode,backends[].group)" | grep $GROUPNAME

Esses comandos exportam uma variável de shell, GROUPNAME, que busca o nome do grupo de instâncias do cluster. Então, os recursos BackendService do Kubernetes do seu projeto são pesquisados e os resultados são reduzidos com base no conteúdo de $GROUPNAME.

O resultado pode ser semelhante ao seguinte:

k8s-be-31210--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...
k8s-be-32125--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...

Se o resultado exibir RATE ou se nenhuma ocorrência for exibida, os balanceadores de carga internos serão compatíveis e nenhum trabalho adicional será necessário.

Se o resultado exibir ocorrências marcadas com UTILIZATION, as entradas não serão compatíveis.

Atualizar as entradas existentes

O tipo de modo de balanceamento só pode mudar quando não há balanceadores de carga HTTP(S) existentes apontando para o cluster.

Se você quer atualizar os recursos de entrada para que sejam compatíveis com um balanceador de carga interno, é preciso fazer um dos seguintes procedimentos:

  1. Se o mestre está executando a versão 1.5.8, 1.6.4 ou posterior do Kubernetes, é possível excluir todas as entradas e recriá-las. Em seguida, atualize o cluster para a versão 1.7.2 ou posterior do Kubernetes para que ele seja compatível com o balanceador de carga interno.
  2. É possível criar um novo cluster executando a versão 1.7.2 ou posterior do Kubernetes e depois migrar os serviços para esse cluster. A migração para o novo cluster garante que nenhuma entrada possa existir com o valor balancingMode incompatível.

Restrições para balanceadores de carga internos

  • O mestre e os nodes precisam estar executando a versão 1.7.2 ou posterior do Kubernetes.
  • Os balanceadores de carga internos só podem veicular tráfego em um tipo de protocolo (TCP ou UDP), e usam o protocolo da primeira porta especificada na definição do serviço.
  • Os balanceadores de carga internos só são acessíveis na mesma rede e região.
  • Em clusters que executam a versão 1.7.4 ou posterior do Kubernetes, você pode usar balanceadores de carga internos com sub-redes de modo personalizado, além de sub-redes de modo automático (disponíveis na versão 1.7.2 ou posterior).
  • O clusterIP permanece inalterado, mas os endereços IP do balanceador de carga interno não podem ser reservados. Portanto, as mudanças feitas em portas, protocolos ou afinidade de sessão podem causar alterações nos endereços IP.

Limites

Cada node do cluster é uma instância de back-end. Por isso, eles são contados em relação ao limite dessas instâncias. Por exemplo, se um cluster contém 300 nodes e há uma limitação de 250 instâncias de back-end, apenas 250 instâncias receberão tráfego. Isso pode afetar negativamente os serviços com externalTrafficPolicy definido como Local.

Para informações sobre as limitações dos balanceadores de carga internos, consulte a seção Limites do tópico de balanceamento de carga interno do Compute Engine.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…