kubernetes网络模型
Kubernetes网络模型设计的一个基础原则是：每个Pod都拥有一个独立的IP地址，并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node中，都要求它们可以直接通过对方的IP进行访问。
Kubernetes 的网络模型可以分为以下几个方面：
- Pod 网络模型：Kubernetes 中最小的调度单元是 Pod，每个 Pod 都有一个唯一的 IP 地址。Pod 网络模型定义了如何为 Pod 分配 IP 地址，并使它们能够在集群内相互通信。
- Service 网络模型：Kubernetes Service 是一种虚拟的网络抽象层，它为一组 Pod 提供了一个单一的 IP 地址和 DNS 名称。Service 网络模型定义了如何将请求从 Service 路由到后端 Pod。
- Ingress 网络模型：Kubernetes Ingress 是一种用于将外部流量路由到 Kubernetes Service 的 API 对象。Ingress 网络模型定义了如何将请求从外部路由到正确的 Service。
- CNI 网络模型：Kubernetes 采用容器网络接口 (CNI) 来实现 Pod 网络。CNI 插件是一个可插拔的网络解决方案，可以支持不同类型的网络，如 Linux bridge、Open vSwitch、flannel 等。
- Network Policy 网络模型：Kubernetes Network Policy 是一种安全机制，可以定义哪些 Pod 可以访问其他 Pod 和 Service，以及哪些端口可以访问。Network Policy 网络模型定义了如何实现网络策略并确保网络安全。
kubernetes网络实现
为了支持业务应用组件的通信，Kubernetes网络的设计主要致力于解决以下问题：
- 容器到容器之间的直接通信。
- 抽象的Pod到Pod之间的通信。
- Pod到Service之间的通信。
- 集群内部与外部组件之间的通信。
容器到容器之间通信
Kubernetes 使用容器网络接口 (CNI) 插件来实现 Pod 内的网络。
CNI 插件在 Pod 启动时会为该 Pod 分配一个唯一的 IP 地址，并创建一个名为“eth0”的网络接口。每个容器都会连接到该网络接口，从而共享该 IP 地址和网络接口。容器可以通过在本地主机上发送和接收网络数据包来与其他容器进行通信。
Pod之间的通信
Pod 之间的通信主要是通过网络实现的。每个 Pod 都有一个唯一的 IP 地址，Pod 中的容器可以通过该 IP 地址和它们的容器端口相互通信。
Pod到Service之间的通信
Pod 到 Service 之间的通信主要是通过 Service 的代理实现的。Service 是一种虚拟的网络抽象层，为一组 Pod 提供了一个单一的 IP 地址和 DNS 名称。
容器可以通过 Service 的 IP 地址和端口访问 Service 代理到的后端 Pod 中的容器。
假设有一个 Kubernetes 集群，其中有两个 Pod，每个 Pod 中都运行了一个简单的 Web 服务器容器，并且我们需要为这两个 Pod 创建一个 Service。我们可以使用以下 YAML 文件来创建这个 Service：
apiVersion: v1 kind: Service metadata: name: web-service spec: selector: app: web ports: - name: http port: 80 targetPort: 80 type: ClusterIP
它的 selector 为“app: web”，表示它将代理所有带有“app=web”的标签的 Pod。该 Service 监听了端口 80，并将所有来自该端口的请求转发到 Pod 中的容器的端口 80。
集群内部与外部组件之间的通信
集群外部的通信可以使用 Kubernetes 的 Ingress 资源来实现。Ingress 允许将外部请求路由到集群内部的 Service。与 Service 相比，Ingress 提供了更多的功能，如负载均衡、HTTPS 和基于主机名的路由等。在使用 Ingress 之前，必须先安装和配置 Ingress 控制器，例如 Nginx、Traefik 或 Istio 等。
开源容器网络方案
Flannel
Flannel 的实现原理基于 Linux 内核中的虚拟网络设备和路由表。
在 Flannel 中，每个节点（Node）都会运行一个叫做 flanneld 的守护进程，它负责为节点上的容器分配 IP 地址并建立网络通信。具体来说，Flannel 实现的过程如下：
Flannel 在每个节点上启动时，会创建一个名为 flannel0 的虚拟网络设备，该设备是一个 Layer 2 网桥。
每个节点都会被分配一个唯一的 Subnet，例如 10.1.0.0/16、10.2.0.0/16 等，这些 Subnet 通过 etcd 存储在集群中。
当容器需要创建网络连接时，Flannel 会从 Subnet 中选择一个未被分配的 IP 地址，并将其分配给容器。
为了实现跨节点通信，Flannel 还会为每个节点创建一个虚拟网络设备，例如 flannel.1、flannel.2 等，用于连接不同节点的网络。当两个节点需要通信时，它们会在各自的虚拟网络设备中创建一个对应的 VXLAN Tunnel，并通过该 Tunnel 互相发送网络数据包。
Flannel 还会修改节点的路由表，将目标 IP 地址为集群内其他节点的 IP 地址的流量转发到对应的 VXLAN Tunnel 中。这样，当一个容器需要访问另一个节点上的容器时，数据包会先通过节点本地的虚拟网络设备转发到目标节点的虚拟网络设备，然后再通过 VXLAN Tunnel 到达目标节点上的容器。
它能实现以下两点：
（1）它能协助Kubernetes，给每一个Node上的Docker容器都分配互不冲突的IP地址。
（2）它能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
Calico
Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。
Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP1协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则。
Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。
Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。
Calico基于iptables还提供了丰富的网络策略，实现了Kubernetes的Network Policy策略，提供容器间网络可达性限制的功能。
