google cloud http (s) balanceamento de carga com kubernetes

Question

A documentação aqui descreve como configurar uma carga baseada na utilização de http (s) balanceador com kubernetes na plataforma do Google Cloud.

A questão é como ela realmente consegue fazer o balanceamento de carga baseado na utilização. Por exemplo, com a seguinte configuração:

• grupo de instâncias de 10 nós
• Controlador de replicação de 3 pod implantado nesse grupo de instâncias
• um serviço NodePort que expõe a porta X em todos os nós do grupo de instâncias.

Assumindo que o LB escolherá o menos utilizado dos 10 nós, e rotear para ele na porta X, como um pod é escolhido para atender a requisição? O serviço de kubernetes seleciona o pod com base em algum outro algoritmo de balanceamento?

É evidente que algo interessante está acontecendo, porque a maioria das instâncias não terá um pod em execução (e, portanto, pode ser mais provável que seja menos utilizada).

    

Answer 1

Como descrito neste artigo :

GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB kube-proxy rules which would correctly balance across all endpoints.

With the new functionality, the external traffic will not be equally load balanced across pods, but rather equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability for specifying the weight per node, they balance equally across all target nodes, disregarding the number of pods on each node).

We can, however, state that for NumServicePods « NumNodes or NumServicePods » NumNodes, a fairly close-to-equal distribution will be seen, even without weights.

Once the external load balancers provide weights, this functionality can be added to the LB programming path. Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date

Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.