Explicação detalhada do modo de proxy kube-proxy
Atualmente, o kube-proxy oferece suporte aos seguintes modos de proxy:
1. Userspace: A solução de balanceamento de carga mais antiga, ela escuta uma porta no espaço do usuário e todos os serviços são encaminhados para essa porta por meio do iptables e, em seguida, a carga interna é balanceada para o Pod real. O principal problema desse método é a baixa eficiência e o óbvio gargalo de desempenho, por isso não é mais recomendado.
Por exemplo, para criar um serviço, o IP correspondente: 1.2.3.4, porta: 8888, a porta selecionada aleatoriamente pelo kube-proxy é 32890, ela será adicionada em iptables
-A PREROUTING -j KUBE-PORTALS-CONTAINER
-A KUBE-PORTALS-CONTAINER -d 1.2.3.4/32 -p tcp --dport 8888 -j REDIRECT --to-ports 32890
KUBE-PORTALS-CONTAINER é a cadeia de regras criada pelo kube-proxy no iptable, que é executada na fase PREROUTING
Processo de implementação:
- Quando houver solicitação de acesso ao serviço, na etapa PREROUTING, será solicitado jumpKUBE-PORTALS-CONTAINER;
- Esse registro no KUBE-PORTALS-CONTAINER funciona, redirecionando a requisição para a porta 32890 que o kube-proxy acabou de escutar, e o pacote de dados entra no processo do kube-proxy;
- Em seguida, o kube-proxy selecionará um do endpoint correspondente ao serviço de acordo com o SessionAffinity como a solicitação de resposta do serviço real.
2. iptables: A solução atualmente recomendada usa as regras do iptables para obter o balanceamento de carga do serviço. O principal problema com esse método é que muitas regras de iptables são geradas quando há muitos serviços, e as atualizações não incrementais introduzirão um certo atraso e há problemas óbvios de desempenho em casos de grande escala.
Por exemplo, se um serviço for criado, o IP correspondente: 1.2.3.4, porta:8888 e um endereço de back-end correspondente: 10.1.0.8:8080, ele será adicionado em iptables (regras principais):
-A PREROUTING -j KUBE-SERVICES
-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX
-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX
-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080
KUBE-SERVICES é a cadeia de regras criada pelo kube-proxy no iptable, que é executada no estágio PREROUTING
Processo de implementação:
- Ao solicitar acesso ao serviço, o iptables pulará para KUBE-SERVICES durante o estágio de pré-roteamento;
- Corresponda ao primeiro critério acima em KUBE-SERVICES, continue para KUBE-SVC-XXXXXXXXXXXXXXXX;
- Vá para KUBE-SEP-XXXXXXXXXXXXXXXX de acordo com esta regra;
- Na regra KUBE-SEP-XXXXXXXXXXXXXXXX, acesse o endereço real do pod 10.1.0.8:8080 por meio da ação DNAT.
3. ipvs: Para resolver o problema de desempenho do modo iptables, v1.11 adicionou o modo ipvs (v1.8 começou a suportar a versão beta e v1.11 GA), usando atualização incremental e pode garantir a conexão durante o serviço atualização Mantenha-o ininterrupto.
No modo IPVS, o kube-proxy observa as alterações dos objetos de serviço e endpoint no Kubernetes, cria as regras IPVS correspondentes chamando a interface netlink e sincroniza periodicamente o serviço, o endpoint e as regras IPVS do Kubernetes. Ao acessar um serviço, o IPVS é responsável por selecionar um back-end real para fornecer serviços.
O modo IPVS também é baseado na função hook do netfilter (estágio INPUT), que é igual ao modo iptables, mas usa a tabela hash do espaço de trabalho do kernel como a estrutura de dados armazenada. pedido satisfaz uma regra. Quando o serviço muda, apenas os registros no ipset precisam ser atualizados, e a cadeia de regras do iptables não precisa ser alterada. Portanto, pode-se garantir que as regras no iptables não aumentarão com o aumento dos serviços e fornecerão desempenho consistente no caso de clusters de serviço de escala ultralarga Efeito.
O desempenho ao sincronizar regras também é superior ao iptables (apenas uma tabela de hash específica é atualizada, em vez de operar em toda a tabela de regras no modo iptables), portanto, pode fornecer tráfego de rede mais alto.
O IPVS também fornece algoritmos mais flexíveis na seleção de serviços de back-end:
- rr: round-robin (algoritmo round-robin)
- lc: conexão mínima (algoritmo do número mínimo de conexão)
- dh: hash de destino (algoritmo de hash do endereço de destino)
- sh: fonte de hash (algoritmo de hash de endereço original)
- sed: menor atraso esperado (algoritmo de menor atraso esperado)
- nq: nunca fila (algoritmo nunca fila)
4. winuserspace: O mesmo que userspace, mas só funciona em nós do Windows.
Este é o fim do compartilhamento de hoje
