Balanceamento de carga e dimensionamento de conexões de longa duração do Kubernetes

Um pouco sobre como o tráfego é redistribuído no Kubernetes 

1. No diagrama abaixo, você vê três instâncias do mesmo aplicativo e um balanceador de carga:
   
   
   
2. O balanceador de carga é chamado de Serviço, recebe um endereço IP. Qualquer solicitação recebida é redirecionada para um dos pods:
   
   
   
3. O script de implantação determina o número de instâncias do aplicativo. Você quase nunca precisará implantar diretamente em:
   
   
   
4. Cada pod possui um endereço IP próprio:
   
   
   

1. Há uma solicitação de ondulação 10.96.45.152 para o serviço:
   
   
   
2. O serviço seleciona um dos três endereços de pod como o destino:
   
   
   
3. O tráfego é redirecionado para um pod específico:
   
   
   

1. Em 1 solicita o componente interno de back-end. Em vez de escolher um específico para o back-end, ele executa uma solicitação de serviço:
   
   
   
2. O serviço seleciona um dos pods de back-end como o endereço de destino:
   
   
   
3. O tráfego vai da lareira 1 à lareira 5 selecionada pelo serviço:
   
   
   
4. Em 1, ele não sabe exatamente quantos lares menores de 5 estão ocultos atrás do serviço:
   
   
   

Balanceamento nos serviços Kubernetes

1. Considere um cluster de três nós. Existem pods em cada nó:
   
   
   
2. Lareiras tricotadas em bege fazem parte do serviço. Como o serviço não existe como um processo, fica acinzentado:
   
   
   
3. O primeiro solicita o serviço e deve recair em um dos lares relacionados:
   
   
   
4. Mas o serviço não existe, não há processo. Como funciona?
   
   
   
5. Antes de a solicitação sair do nó, ela passa pelas regras do iptables:
   
   
   
6. As regras do iptables sabem que não há serviço e substituem seu endereço IP por um dos endereços IP dos pods associados a este serviço:
   
   
   
7. A solicitação recebe um endereço IP válido como o endereço de destino e é normalmente processada:
   
   
   
8. Dependendo da topologia da rede, a solicitação finalmente chega ao coração:
   
   
   

O iptables é capaz de equilibrar a carga?

1. Escolha o primeiro com uma probabilidade de 33%, caso contrário, vá para a próxima regra.
2. Escolha o segundo com uma probabilidade de 50%, caso contrário, vá para a próxima regra.
3. Escolha o terceiro em.

As conexões de longa duração no Kubernetes não são dimensionadas por padrão

• Manter vivo no Node.js
• Manter vivo na bota de mola
• Manter vivo em python
• Manter vivo no .NET

1. O primeiro sub envia uma solicitação ao serviço:
   
   
   
2. Você já sabe o que vai acontecer a seguir. O serviço não existe, mas existem regras do iptables que manipularão a solicitação:
   
   
   
3. Um dos pods de back-end será selecionado como o endereço de destino:
   
   
   
4. A solicitação chega à lareira. Nesse ponto, uma conexão TCP permanente entre os dois pods será estabelecida:
   
   
   
5. Qualquer próxima solicitação do primeiro pod passará por uma conexão já estabelecida:
   
   
   

1. Obtenha a lista de pontos de extremidade do serviço.
2. Para cada nó de extremidade, abra uma conexão persistente.
3. Quando você precisar fazer uma solicitação, use uma das conexões abertas.
4. Atualize regularmente a lista de terminais, crie novos ou feche as conexões persistentes antigas, se a lista mudar.

1. Em vez de enviar a primeira solicitação para o serviço, você pode equilibrar as solicitações no lado do cliente:
   
   
   
2. Você precisa escrever um código que pergunte quais pods fazem parte do serviço:
   
   
   
3. Assim que você receber a lista, salve-a no lado do cliente e use-a para conectar-se aos pods:
   
   
   
4. Você é responsável pelo algoritmo de balanceamento de carga:
   
   
   

Balanceamento de carga no lado do cliente

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

• WebSockets e WebSockets protegidos
• HTTP / 2
• gRPC
• RSockets
• AMQP

Balanceamento de conexões de longa duração em Kubernetes

1. Clusterip
2. NodePort
3. Balanceador de carga
4. Sem cabeça

1. A camada de gerenciamento atribui a ele um endereço IP.
2. O Kube-proxy forma as regras necessárias do iptables.

O Service Mesh o ajudará

1. Obtém uma lista de endereços IP do serviço.
2. Abre e mantém um conjunto de conexões.
3. Atualiza periodicamente o pool, adicionando ou removendo pontos de extremidade.

1. Seleciona uma conexão disponível usando algum tipo de lógica (por exemplo, round-robin).
2. Atende à solicitação.

1. Pesquisa automaticamente endereços IP de serviços.
2. Verifica conexões como WebSockets e gRPC.
3. Equilibra solicitações usando o protocolo correto.

O que acontece se você ignorar problemas de balanceamento?

Conclusão

1. Três níveis de dimensionamento automático no Kubernetes e como usá-los efetivamente . 
2. Kubernetes no espírito de pirataria com um modelo de implementação .
3. Kubernetes .