【K8S系列】Kubernetes的网络模型

一、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 插件。