k8s externaltrafficpolicy相关说明

k8s externaltrafficpolicy相关说明

1.背景描述

生产环境之前使用aws的eks来作为托管集群，突然看到externaltrafficpolicy参数，听说可以少一次转发，所以对这个参数的理解参考其他文档做一个记录，这里解释一下local模式和cluster模式的区别。

2.什么是external-traffic-policy

在k8s的Service对象（申明一条访问通道）中，有一个“externalTrafficPolicy”字段可以设置。有2个值可以设置：Cluster或者Local。

1）Cluster表示：流量可以转发到其他节点上的Pod。

2）Local表示：流量只发给本机的Pod。

图示一下

3.这2种模式有什么区别

存在这2种模式的原因就是：当前节点的Kube-proxy在转发报文的时候，会不会保留原始访问者的IP。

以及使用cluster模式时，只要节点开放nodeport都可以访问，而local模式，只有有pod的节点才可以访问，当初就是在这里，一直以为aws的lb出现问题，为何有3个节点，为什么后端负载均衡后端存活节点只有一个。所以这里比较重要，不要造成误解。

3.1 Cluster

注：这个是默认模式，Kube-proxy不管容器实例在哪，公平转发。

Kube-proxy转发时会替换掉报文的源IP。即：容器收的报文，源IP地址，已经被替换为上一个转发节点的了。

原因是Kube-proxy在做转发的时候，会做一次SNAT (source network address translation)，所以源IP变成了节点1的IP地址。

注意：snat确保回去的报文可以原路返回，不然回去的路径不一样，客户会认为非法报文的。（我发给张三的，怎么李四给我回应？丢弃！）

这种模式好处是负载均衡会比较好，因为无论容器实例怎么分布在多个节点上，它都会转发过去。当然，由于多了一次转发，性能会损失一丢丢。

3.2 Local

这种情况下，只转发给本机的容器，绝不跨节点转发。简单说就是本章开头说的，只有有pod的节点才会开放端口，才会接收请求。

Kube-proxy转发时会保留源IP。即：容器收到的报文，看到源IP地址还是用户的。

缺点是负载均衡可能不是很好，因为一旦容器实例分布在多个节点上，它只转发给本机，不跨节点转发流量。当然，少了一次转发，性能会相对好一丢丢。

注：这种模式下的Service类型只能为外部流量，即：LoadBalancer 或者 NodePort 两种，否则会报错。

同时，由于本机不会跨节点转发报文，所以要想所有节点上的容器有负载均衡，就需要上一级的Loadbalancer来做了。

不过流量还是会不太均衡，如上图，Loadbalancer看到的是2个后端（把节点的IP），每个Node上面几个Pod对Loadbalancer来说是不知道的。

想要解决负载不均衡的问题：可以给Pod容器设置反亲和，让这些容器平均的分布在各个节点上（不要聚在一起）。

affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - my-app topologyKey: kubernetes.io/hostname

像下面这样，负载均衡情况就会好很多。

4.两种模式该怎么选

要想性能（时延）好，当然应该选 Local 模式喽，毕竟流量转发少一次SNAT嘛。

不过注意，选了这个就得考虑好怎么处理好负载均衡问题（ps：通常我们使用Pod间反亲和来达成）。

如果你是从外部LB接收流量的，那么使用：Local模式 + Pod反亲和，一般是足够的

5.总结

同上上述的理论学习，问题可以明确的得出答案：externaltrafficpolicy的local模式，只转发给本机的容器，绝不跨节点转发，再次强调，只有有pod的node节点才会开放端口和接收请求。

作者：​​小家电维修​​

​

转世燕还故榻,为你衔来二月的花。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。