k8s 的 CNI 网络模型

k8s网络模型产生的背景和目的

k8s 作为编排引擎管理着分布在不同节点上的容器和 Pod。而 Pod、Service 以及外部组件之间需要一种可靠的方式找到批次并进行互相通信，此时 k8s 网络则负责提供这个保障。下面将介绍如下内容：

k8s 网络模型；
k8s 基于 CNI 实现的各种网络方案；
Network Policy 网络策略；

k8s的网络模型下集群中的各种实体如何通信？

=》1.Pod内容器之间的通信

当 Pod 被调度到某个节点，Pod 中的所有容器都在这个节点上运行，这些容器共享相同的本地文件系统、IPC 和网络命名空间。
不同 Pod 之间不存在端口冲突的问题，因为每个 Pod 都有自己的 IP 地址。当某个容器使用 lalhost 时，意味着使用的是容器所属 Pod 的地址空间。
比如 PodA 有两个容器 container-AI 和 container-A2，container-A1 在端口1234 上监听，当 container-A2 连接到 laltost:12324 时，实际上就是在访问 cntaine-Al。这不会与同个节点上的 PodB 冲突，即使 PodB 中的容器 container-BI 也在监听1234端口。

=》2.Pod之间的通信

Pod的IP是集群可见的，即集群中的任何其他Pod和节点都可以通过IP直接与Pod通信，这种通信不需要借助任何网络地址转换、隧道或代理技术。Pod 内部和外部使用的是网个 IP，这也意味着标准的命名服务和发现机制，比如DNS可以直接使用。

=》3.Pod与Service的通信

Pod 间可以直接通过 IP 地址通信，但前提是 Pod 知道对方的 IP。在 Kabenete 集群中，Pod 可能会频繁地销级和创建，也就是说 Pod 的 IP 不是固定的。为了解决这个问题，Service 提供了访问 Pod 的抽象层。无论后端的 Pod 如何变化，Service 都作为稳定的前端对外提供服务。同时 Serice 还提供了高可用和负载均衡功能，Service 负责将请求转发给正确的Pod。

=》4.外部访问

无论是 Pod 的 IP 还是 Service 的 Cluster IP，它们只能在 Kubermetes 集群中可见，对集群之外的世界，这些 IP 都是私有的。
Kubermetes 提供了两种方式让外界能够与 Pod 通信：

●【NodePort<->Service】通过 Cluster 节点的静态端口对外提供服务。外部可以通过 <NodelP>:<NodePort> 访问 Service。
●【LodBalancer<->Service】利用 cloud provider 提供的 load balancer 对外提供服务，cloud prorider 负贵将 load balancer 的流量导向 Service, 目前支持的 cloud provider 有 GCP、AWS、Azure、Aliyun、Tencent cloud 等。

CNI（Container Network Interface/容器网络接口）网络模型

=》CNI是由CoreOS提出的容器网络规范，使用了插件(Pugin) 模型创建容器的网络栈，k8s网络采用的就是这个CNI网络模型规范；

一直以来，k8s 并没有专门的网络模块负责网络配置，它需要用户在主机上已经配置好网络。

kubernetes 对网络的要求：

一个 Pod 一个 IP，并且 IP 全局集群环境唯一；
所有的 Pod 可以与任何其他的 Pod 直接通信；
Pod 内部获取到的 IP 地址与其他 Pod 或节点与其通信是的 IP 地址是同一个；
容器之间（包括同一台主机上的容器，和不同主机的容器）可以互相通信；
容器和集群中所有的节点也能直接通信；

k8s 采用的是基于扁平地址空间的网络模型，集群中的每个 Pod 都有自己的 IP 地址，Pod 之间不需要配置 NAT 就能直接通信；另外同一个 Pod 中的容器共享 Pod 的 IP，能够通过 localhost 通信；

k8s 网络的发展方向是希望通过插件的方式来集成不同的网络方案， CNI 就是这一努力的结果。CNI 只专注解决容器网络连接和容器销毁时的资源释放，提供一套框架，所以 CNI 可以支持大量不同的网络模式，并且容易实现，这种网络模型对应用开发者和管理员相当友好，应用可以非常方便的从传统网络迁移到 k8s。每个 Pod 可以看作是一个个独立的系统，而 Pod 中的容器则可以看作同一系统中的不同进程。

CNI的优点

CNI 的优点是支持多种容器 runtime，不仅仅是 Docker。 CNI的插件模型支持不同组织和公司开发的第三方插件，这对运维人员来说很有吸引力，可以灵活选择适合的网络方案。
目前已有多种支持 k8s 的网络方案，比如 Flannel、 Calico、Canal、 Weave Net 等。因为它们都实现了 CNI 规范，用户无论选择哪种方案，得到的网络模型都一样，即每个Pod都有独立的IP，可以直接通信。
区别在于不同方案的底层实现不同，有的采用基于 VxLAN 的 Overlay 实现，有的则是 Underay，性能上有区别。再有就是是否支持 Network Policy。

Network Policy/网络策略

Network Policy 是 k8s 的一种资源。 Network Policy 通过 Label 选择 Pod，并指定其他 Pod 或外界如何与这些 Pod 通信。
默认情况下，所有Pod是非隔离的，即任何来源的网络流量都能够访问 Pod, 没有任何限制。当为 Pod 定义了 Network Policy 时，只有 Policy 允许的流量才能访问 Pod。
不过，不是所有的 Kubernetes 网络方案都支持 Network Policy。比如 Flannel 就不支持，Calico 是支持的。我们接下来将用 Canal 来演示 Network Poliy。Canal 这个开源项目很有意思，它用 Flannel 实现 Kubernetes 集群网络，同时又用 Calico 实现 Network Poliy。

k8s基于CNI网络模型实现的网络方案

网络模型有了，接下来如何实现呢?

网络实现步骤=》https://blog.csdn.net/liukuan73/article/details/78883847

基于kubeadm安装的各种网络方案：

部署Canal
部署Canal 与部署其他Kubernetes网络方案非常类似，都是在执行了kubeadm init 初的化Rsbenee集群之后通过klee 4安装相应的网络方案，也就是说，没有太好的办法直接切换使用不同的网络方案，基本上只能重新创建集群。