云原生架构系列——kubernetes服务发现与集群负载均衡

1 什么是Service

首先我们看下两个问题

现在有一个node节点，node上有四个pod，每个pod都有自己的IP地址和端口：

• 现在客户端发送了一个请求，能不能通过10.0.0.0:80这个地址来访问服务。显然是不行的，因为pod是一个进程，进程要想与外界通信只能通过服务器的物理地址加进程的端口进行通信。
• Nginx能不能作为App1-3的代理？如果App1-3的地址不会改变，那是没有问题的。pod的IP是网络插件动态随机分配，在pod重启后IP会发生改变，但Nginx感知不到pod的地址变化。所以不能用Nginx做负载均衡。
  基于以上两个问题，k8s提出了Service的概念。Service的作用就相当于Nginx，用来代理一组pod，每组pod会有不同的Service。通过kube-proxy监听pod的IP地址变化，然后注册到Service上。

2 Service外网服务及pod服务发现

k8s资源对象的几种IP：

• Node IP：物理机节点的IP；
• Pod IP：pod的IP地址，由网络插件动态生成；
• Cluster IP：Service资源的IP，是一个虚拟IP地址，不能直接与外网进行通信。
  Service不能直接与外网通信，需要开辟一个物理端口，然后将物理端口与Service端口进行映射，从而实现将请求转发给Service，再由Service转发给pod。
  
  每一个node节点都存在一个kube-proxy进程，由kube-proxy都会监控pod的IP地址变化，把变化的IP更新到service资源对象的endpoints里。使得service vip可以及时感知到pod ip的变化，从而可以实现更好的，及时的，稳定的访问。

3 负载均衡

3.1 userspace负载均衡策略

这种策略的负载均衡是由kube-proxy来实现的，而不是service VIP来实现的。此时kube-proxy不仅仅需要实现负载均衡，还需要实现服务发现及注册，实现路由规则的改写。因此kube-proxy负载压力较大，性能不会太好。

3.2 Iptables负载均衡策略

Iptables模式为Services的默认代理模式。在iptables 代理模式中，kube-proxy不在作为反向代理在Service和backend Pods之间进行负载均衡的分发。由iptables来实现负载均衡。iptables 和netfilter紧密集成，密切合作，都在kernelspace 就实现了包的转发。
iptables负载均衡有两种模式：随机和轮询。

3.3 Ipvs负载均衡策略

IPVS（IP虚拟服务器）实现传输层负载平衡，通常称为第4层LAN交换，是Linux内核的一部分。
IPVS的结构图类似，只是把iptables换成了ipvs。

IPVS支持的负载均衡算法有以下几种：

• rr: 轮询
• lc: 最小连接数
• dh: 目的地址hash
• sh: 源地址hash
• sed: 最短期望延迟
• nq: 无须队列等待

IPVS模式和IPTABLES模式之间的差异如下：

• IPVS为大型集群提供了更好的可扩展性和性能。
• IPVS支持比iptables更复杂的负载平衡算法。
• IPVS支持服务器健康检查和连接重试等。

在Linux 中iptables设计是用于防火墙服务的，对于比较少规则的来说，没有太多的性能影响。但是对于，一个K8S集群来说，会有上千个Services服务，当然也会转发到Pods，每个都是一条iptables规则，对集群来说，每个node上会有大量的iptables规则，简直是噩梦。
同样IPVS可以解决可能也会遇见这样大规模的网络转发需求，但是IPVS用hash tabels来存储网络转发规则，比iptables 在这上面更有优势，而且它主要工作在kernelspace，减少了上下文切换带来的开销。