K8s的网络详解

Posted 2023-03-15

参考技术A

其实操作到这里，有必要深入的了解K8s的网络运行机制和基本结构，否则当真的遇到问题的时候会比较郁闷。
首先，要理解K8s的用处其实是容器的编排和管理，最小组成其实不是容器，是pod，物理机或者虚拟机叫node，pod是基础单元，pod里可以有多个容器，也可以只有一个容器，同一个pod的容器彼此是共享网络和主机配置的，换句话说，彼此是可以直接localhost通信的，类似于同一台机器上进行通信，所以这里面是无所谓隔离和安全一说，对外而言就是一个环境，所以pod就是这个环境的业务实体。所以，第一个问题来了，同一个pod的不同容器可以位于不同的node上吗？当然不行，必须在同一个node上，因为共享主机和网络。那么怎么才能知道一个pod有多个容器？kubectl exec的时候是否可以指定需要运行的容器？当然可以，参考如下指令：

所以，这里可以忽略容器的概念，单单考虑pod，毕竟pod才是k8s最小的调度单元。那pod和pod是怎么通信的呢？

pod的通信离不开K8s的网络模型：

flannel组建一个大二层扁平网络，pod的ip分配由flannel统一分配，通讯过程也是走flannel的网桥。
每个node上面都会创建一个flannel0虚拟网卡，用于跨node之间通讯。所以容器直接可以直接使用pod id进行通讯。
跨节点通讯时，发送端数据会从docker0路由到flannel0虚拟网卡，接收端数据会从flannel0路由到docker0。

如果Pod是一组应用容器的集合，那Service是不是就没有意义了，他的意义在于当应用服务需要做负载、需要做全生命周期的跟踪和管理时就体现出来了，所以Service是一个抽象的概念，它定义了Pod逻辑集合和访问这些Pod的策略。
一个非常常见的场景，当一个Pod因为某种原因停止运行了，kubelet根据deployment的需求重新启动一个新的Pod来提供之前Pod的功能，但是flannel会给这个新的Pod分配一个新的IP，这会带来很大的Effort，应用服务的很多配置项都需要调整，如果有了Service呢，这就不是问题，看下Service的运行原理。

这张图解释了Service的运行机制，当Service A创建的时候，Service Controller和EndPoints Controller就会被触发更新一些资源，例如基于Service中配置的Pod的selector给每一个Pod创建一个EndPoint资源并存入etcd，kube-proxy还会更新iptables的chain规则生成基于Service的Cluster IP链路到对应Pod的链路规则，接下来集群内的一个pod想访问某个服务，直接cluster ip:port即可基于iptables的链路将请求发送到对应的Pod，这一层有两种挑选pod的算法，轮询(Round Robin)和亲和度匹配(Session Affinity)。当然，除了这种 iptabels的模式 ，还有一种比较原始的方式就是 用户态的转发 ，Kube-Proxy 会为每个 Service 随机监听一个端口 (Proxy Port)，并增加一条 IPtables 规则。从客户端到 ClusterIP:Port 的报文都会被重定向到 Proxy Port，Kube-Proxy 收到报文后，通过 Round Robin (轮询) 或者 Session Affinity（会话亲和力，即同一 Client IP 都走同一链路给同一 Pod 服务）分发给对应的 Pod。

当然，新版本的k8s开始基于 ipvs来替换iptables 了，但是形式和iptables是类似的。
概念图可以参看：

这是最原始的方式，参看下图：

IPVS是 LVS 项目的一部分，是一款运行在 Linux Kernel 当中的 4 层负载均衡器，性能异常优秀。使用调优后的内核，可以轻松处理每秒 10 万次以上的转发请求。目前在中大型互联网项目中，IPVS 被广泛的用于承接网站入口处的流量。