k8s网络

pod 网络

在K8S集群里，多个节点上的Pod相互通信，要通过网络插件来完成，比如Calico网络插件。
使用kubeadm初始化K8S集群时，有指定一个参数–pod-network-cidr=10.18.0.0/16 它用来定义Pod的网段。
而我们在配置Calico的时候，同样也有定义一个CALICO_IPV4POOL_CIDR的参数，它的值同样也是Pod的网段。

容器网络尤其是在跨主机容器间的网络是非常复杂的。目前主流的容器网络模型主要有Docker公司提出的Container Network Model (CNM)模型和CoreOS公司提出的Container Network Interface (CNI)模型，而Kubernetes采用了由CoreOS公司提出的CNI模型。

1）CNI
首先我们介绍一下什么是 CNI，它的全称是 Container Network Interface，即容器网络的 API 接口。

CNI本身并不能提供网络服务，它只是定义了对容器网络进行操作和配置的规范。CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源，这使得CNI规范非常轻巧、易于实现，得到了广泛的支持。

而真正实现和落地这些规范的是CNI插件。常见的CNI插件包括Calico、flannel、Terway、Weave Net 以及 Contiv。

2）K8S如何使用CNI插件
K8s 通过 CNI 配置文件来决定使用什么 CNI插件。

基本的使用方法为：

1. 首先在每个节点上配置 CNI 配置文件(/etc/cni/net.d/xxnet.conf)，其中 xxnet.conf 是某一个网络配置文件的名称。
2. 安装CNI配置文件对应的二进制插件，在/opt/cni/bin目录中。
3. 在这个节点上创建pod之后，kubelet就会跟进CNI配置文件执行安装CNI插件。
   

在集群里面创建一个Pod的时候，首先会通过apiserver将Pod 的配置写入。apiserver的一些管控组件
(比如 Scheduler)会调度到某个具体的节点上去。Kubelet监听到这个Pod 的创建之后，会在本地进行
一些创建的操作。当执行到创建网络这一步骤时，它首先会读取刚才我们所说的配置目录中的配置文件，配置文件里面会声明所使用的是哪一个插件，然后去执行具体的CNI插件的二进制文件，再由 CNI插件进入 Pod 的网络空间去配置Pod 的网络。配置完成之后，Kuberlet也就完成了整个Pod 的创建过程，这个Pod 就在线了。

3）基于Calico的Pod网络

Service 网络

在介绍Service这个api资源对象时，我们已经汇总过Service的几个type：ClusterIP、NodePort、LoadeBalancer，除了这三个还有其它的类型，暂且不讨论。

这三种类型的Service，LoadBalancer依赖NodePort，而NodePort通常要和ClusterIP一起使用，如果在Service的yaml文件里定义type为LoadBalancer，则它会自动创建NodePort，而NodePort也会自动创建ClusterIP。

展示一下pod到service的网络变化情况（演绎通信流程）：
1）单个Pod之间通信
单个Pod和Pod之间通信只能通过Pod的IP和Port来通信，如下图

2）Pod有多个
当引入了Deployment，并为Pod设置多个副本时，那么提供某一个服务（如Nginx服务）的Pod就不止一个了，此时即使知道了这些Pod的IP，那访问起来也并不方便。所以，这里需要有一个统一入口，其它Pod通过这个统一入口去请求该服务（Nginx）对应的所有Pod。 这时就有了Service这个资源对象，它主要作用就是用来提供统一入口，也就是说只需要一个IP就能访问所有的Pod，而这个入口IP就是ClusterIP，也就是Service的IP。

3）外部资源访问内部Pod
有了Service，的确可以很方便为内部的Pod提供入口，但是在集群外面访问这个内部的资源就没办法了。于是，就有了这个NodePort，使用Service的NodePort类型，可以将Service的ClusterIP对应的Port映射到每一个Node的IP上，映射出去的Port范围为30000~32767

4）借助公有云的负载均衡器
使用这个NodePort并不方便，毕竟它带着一个长长的端口号，而且还有一个非常尴尬的问题，就是访问时还得带着Node的IP，如果这个Node挂掉，那么就无法访问此资源，虽然可以通过另外一个Node去访问，但这样太麻烦了！所以，此时的解决方案是：借助三方的负载均衡器，将请求分发到所有的Node上，其底层还是NodePort。

总结：Service为内部Pod的统一入口，内部资源之间可以通过最简单的ClusterIP进行通信，而外部资源访问需要借助NodePort的形式，但是带着长长端口不方便，于是又衍生了LoadBalancer的形式，这种形式需要借助三方的负载均衡器，将请求分发到每一个NodePort上。