【K8S系列】Kubernetes的网络模型
目录
一、k8s的三种网络
二、service网络
2.1 netfilter
2.2 iptables
2.3 clustip
一、k8s的三种网络
Node Network: 与外部网络接口
Service Network： ipvs规则当中的网络、路由提供调度
Pod Network： 节点当中pod的内部网络无法与外界通信
其中：
Node Network： 集群节点所在的网络，这个网络就是你的主机所在的网络，通常情况下是你的网络基础设施提供。
如果node处于不同的网段，那么你需要保证路由可达。如上图中的 192.168.10.0/24和10.0.0.0/8这两个网络
Service Network：第二个是K8S服务网络, service_cluster_ip_range（如图，默认的配置是的10.0.0.1/24)
在上图中，扩充的节点（基础网络是10.0.0.0/8)和 服务网络（10.0.0.1/24)冲突，会造网络问题。
Pod Network：第三个网络是Pod的网络， K8s中一个Pod由多个容器组成，但是一个pod只有一个IP地址，Pod中所有的容器共享同一个IP。
这个IP启动pod时从一个IP池中分配的， 叫做 pod CIDR, 或者叫network_cidr（如图，默认配置是10.1.0.0/16)。 可以在配置文件中配置。
kubernetes对于pod的网络定制了下列三个要求，所有网络插件支持这几个要求即可：
- 所有节点上所有的pod可以互相通信，并且不依赖NAT
- 节点上的进程可以和该节点上的所有pod通信
- 运行在主机网络空间下的pod可以和所有节点上的所有pod互相通信，并且不依赖NAT
注意： 一个Pod会包含多个container， 但是这些containers共享一个网路IP，也就是说，Container A如果占了80， Container B就不能用80 了。
用一个pod
优点：
- 在同一个pod，将关系紧密的容器放在一起，通过挂载同一数据卷来共享数据
- 共享网络，内部相互调用访问更高效
缺点：
- 共享网络，每个容器的端口需要规划
- 一个容器需要升级，会影响到整个pod滚动升级
二、service网络
为了解决Pod IP地址不是持久性的，可能会进行更改，k8s采用service对pod进行抽象，
service为pod组提供虚拟ip，任何路由到这个虚拟ip的，都将转发到对应关联的pod上，而且service还提供高可用与负载均衡
2.1 netfilter
为了在群集内执行负载平衡，Kubernetes依赖于Linux内置的网络框架netfilter；
Netfilter是Linux提供的框架，它允许以自定义处理程序的形式实现与网络相关的各种操作。数据包筛选，网络地址转换和端口转换的操作，提供了通过网络引导数据包所需的功能，并提供了禁止数据包到达计算机网络内敏感位置的功能。
2.2 iptables
默认采用iptables，其是一个用户空间程序，它提供了一个基于表的系统，用于定义netfilter模块的处理和转换数据包的规则；
iptables规则监视发往服务虚拟的流量IP，并从一组可用的Pod中随机选择一个Pod IP地址，并且iptables规则将数据包的目标IP地址从服务的虚拟IP更改为所选Pod的IP。
2.3 clustip
nodeport，在node上面开启一个监听端口，负责将service暴露给外面访问，通过访问这个service的这个端口可以确认访问这个service，会有iptables做地址转换
pod去访问service是需要通过宿主机的，不然没法通过宿主机的内核net_filter模块做nat地址转换
如上图：
- 数据包通过eth0离开pod1
- 数据包来到网桥，arp协议不了解服务，发往默认路由eth0
- 在到达eth0前，iptables改写目标ip为特点的pod ip，并记录下来这次的pod选择，以便将来的相同事件
基于 IP-per-Pod 的基本网络原则，Kubernetes 设计出了 Pod - Deployment - Service 这样经典的 3 层服务访问机制，极大地方便开发者在 Kubernetes 部署自己的服务。在生产实践中，可以根据自己的业务需要选择合适的 CNI 插件。