k8s集群service流量服务代理5大严肃思考？
k8s集群service流量服务代理5大严肃思考？
kube-proxy为service的服务代理提供了什么能力？
service 是利用服务代理的方式实现流控，那么有哪些服务代理呢？
思考下，iptables 模式下如何尽可能的避免将流量发送到失败的Pod呢？
k8s集群service服务代理IPVS的兜底策略是什么？
说说服务代理IPVS模式相比其他模式都有哪些优点？
如何确保每次都将来自特定客户端的连接传递到同一Pod呢?
囧么肥事-胡说八道
kube-proxy为service的服务代理提供了什么能力？
Kubernetes 依赖代理将入站流量转发到后端，而不是其他方法，如不使用 DNS 轮询。需要知道的是，k8s集群的service实现，依赖于kube-proxy 组件。kube-proxy 组件是k8s 基础能力之一，每个节点都有一个kube-proxy容器进程，在k8s中，kube-proxy容器位于kube-system名称空间的Pod中，它实现了k8s内部从pod到service、外部从node port到service 的访问。
简单理解：流量转发
举个简单的栗子🌰
kube-proxy 是某某学校的门卫大爷
上午10点，一名男子要进学校
门口大爷拦着说：”上课期间，闲人免进“
小明爸爸：”你好，大爷，我是学生小明的爸爸“
小明爸爸：”小明今天忘记带 k8s 课本了“
小明爸爸：”我过来送一下，让我进去吧“
门卫大爷经过...查询确认...
门卫大爷：”小明在3年级2班，进门左转”
小明爸爸：“谢谢大爷”
上午11点，一名头戴鸭舌帽，黑披风男子进学校
门口大爷拦着说：”上课期间，闲人免进“
路人甲：“你好大爷，我是kube老师的男朋友”
路人甲：“今天kube 生日，我给她送花花❀”
路人甲：“请问k8s教研办公室怎么走”
门卫大爷，瞪开火眼金睛...经过电话确认..
门卫大爷：“k8s教研办公室，进门左转，再右转”
下午3点，几名满脸凶煞的男子要进学校
门口大爷拦着说：”上课期间，闲人免进“
凶煞男子们：“老头，我们找学生ingress有点私事”
凶煞男子们：“告诉我，怎么走？”
门口大爷：“出门左转，坐5438路公交”
凶煞男子们：“我特么...”
上面简单的小例子应该很好理解 kube-proxy 的作用吧？核心就是流量转发
service 是利用服务代理的方式实现流控，那么有哪些服务代理呢？
kube-proxy当前支持三种不同的代理模式：
userspace（也叫用户空间代理模式）：这种模式之所以得名，是因为服务路由发生在kube-proxy用户进程空间，而不是内核网络堆栈中。它不常用，因为它运行缓慢且过时。iptables模式：此模式使用Linux内核级Netfilter规则为
Kubernetes Services配置所有路由，处理流量具有较低的系统开销。iptables是大多数平台上kube-proxy的默认模式。进行多个后端容器进行负载平衡时，它使用未加权的循环调度。IPVS（IP虚拟服务器）：基于
Netfilter框架，IPVS在Linux内核中实现第4层负载平衡，支持多种负载平衡算法，包括最少的连接和最短的预期延迟。这种kube-proxy模式在Kubernetes 1.11后变得普遍可用，但是它需要Linux内核加载IPVS模块。各种Kubernetes网络项目也没有像iptables模式那样广泛地支持它。
首先来看看 userspace 代理模式
userspace 模式，即用户空间模式，kube-proxy 会监视 Kubernetes 控制平面对 Service 对象和 Endpoints 对象的添加和移除操作。对每个 Service，它都会在本地 Node 上打开一个端口（随机选择）。任何连接到“代理端口”的请求，都会被代理到 Service 的后端，即 Endpoints 所定义的 Pods 中的某个Pod上面。
注意：至于最终会真正使用哪个后端 Pod，是 kube-proxy 基于
SessionAffinity来确定的。
此外，userspace模式下，它会配置 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP） 和 Port 的请求，并重定向到代理端口，代理端口再代理请求到后端Pod。
默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。
userspace 代理模式原理图
再来看下 iptables 代理模式
iptables模式，kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个后端组合。
默认的策略是，kube-proxy 在 iptables 模式下随机选择一个后端。
使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理， 而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。
如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应， 则连接失败。这一点与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败， 并会自动使用其他后端 Pod 重试。
你可以使用 Pod 就绪探测器验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。
最后来看看代理王者 IPVS 代理模式
在 ipvs 模式下，kube-proxy 监视 Kubernetes 服务和端点，调用 netlink 接口相应地创建 IPVS 规则， 并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保IPVS 状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端Pod之一。
IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数， 但是使用哈希表作为基础数据结构，并且在内核空间中工作。这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。
IPVS 提供了更多选项来平衡后端 Pod 的流量。这些是：
rr：轮替（Round-Robin）lc：最少链接（Least Connection），即打开链接数量最少者优先sed：最短预期延迟（Shortest Expected Delay）nq：从不排队（Never Queue）
看起来是不是IPVS模式更牛，更靠谱？但是实际使用来说，还是iptables更加广泛。
说说k8s集群service服务代理IPVS的兜底策略是什么？
IPVS的兜底策略是iptables模式。注意要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS 在节点上可用，必须先给Linux内核加载IPVS模块。当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。
说说服务代理IPVS模式相比其他模式都有哪些优点？
IPVS模式优点：
IPVS为大型集群提供了更好的可扩展性和性能。
IPVS支持比
iptables更复杂的负载平衡算法（最小负载，最少连接，位置，加权等）。IPVS支持服务器健康检查和连接重试以及
iptables模式替换的兜底策略。
如何确保每次都将来自特定客户端的连接传递到同一Pod呢?
在这些代理模型中，绑定到服务 IP 的流量：在客户端不了解 Kubernetes 或服务或 Pod 的任何信息的情况下，将 Port 代理到适当的后端。