k8s 的 CNI 网络模型

目录

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

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

CNI 网络模型

CNI 的优点

CNI 插件的分类及选型参考

Network Policy/网络策略

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

---

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

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

1. k8s 网络模型；
2. k8s 基于 CNI 实现的各种网络方案；
3. 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 通信：

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

CNI 网络模型

CNI 全称是 Container Network Interface，即容器网络的 API 接口。CNI 是由 CoreOS 提出的容器网络规范，使用了插件(Pugin) 模型创建容器的网络栈，k8s 网络采用的就是这个 CNI 网络模型规范；

它是 K8s 中标准的一个调用网络实现的接口。Kubelet 通过这个标准的 API 来调用不同的网络插件以实现不同的网络配置方式。

CNI 插件就是实现了一系列的 CNI API 接口。常见的 CNI 插件包括 Calico、Flannel、Terway、Weave Net 、Canal 以及 Contiv。

一直以来，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 、Canal等。因为它们都实现了 CNI 规范，用户无论选择哪种方案，得到的网络模型都一样，即每个Pod都有独立的IP，可以直接通信。
• 区别在于不同方案的底层实现不同，有的采用基于 VxLAN 的 Overlay 实现，有的则是 Underay，性能上有区别。再有就是是否支持 Network Policy。

CNI 插件的分类及选型参考

CNI 插件可以分为三种：Overlay、路由及 Underlay。

• 【Overlay 模式】的典型特征是容器独立于主机的 IP 段，这个 IP 段进行跨主机网络通信时是通过在主机之间创建隧道的方式，将整个容器网段的包全都封装成底层的物理网络中主机之间的包。该方式的好处在于它不依赖于底层网络；
• 【路由模式】中主机和容器也分属不同的网段，它与 Overlay 模式的主要区别在于它的跨主机通信是通过路由打通，无需在不同主机之间做一个隧道封包。但路由打通就需要部分依赖于底层网络，比如说要求底层网络有二层可达的一个能力；
• 【Underlay 模式】中容器和宿主机位于同一层网络，两者拥有相同的地位。容器之间网络的打通主要依靠于底层网络。因此该模式是强依赖于底层能力的。
   

对于 CNI 插件的选择，有以下几个维度参考：

• 环境限制，比如：虚拟化环境，物理机环境，公有云环境，不同环境中所支持的底层能力是不同的。
• 功能需求，比如：安全需求，是否需要集群外的资源与集群内的资源互联互通，K8s 的服务发现与负载均衡的能力。
• 性能需求，比如：Pod 的创建速度，Pod 的网络性能。

了解更多可以参考 =》https://www.kubernetes.org.cn/6908.html

注意：CNI 插件只需要部署其中一个即可，这里推荐 Calico 或 Flannel。

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。

更多查看：网络策略 | Kubernetes

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

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

网络实现步骤=》kubernetes cni网络详解_liukuan73的博客-CSDN博客_cni网络

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

• 英文：Creating a cluster with kubeadm | Kubernetes
• 中文：使用 kubeadm 创建集群 | Kubernetes

部署 Canal 插件

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