1. 网络概述

# 一、概述
1. k8s网络特征
- 每个POD 具有集群内唯一IP
- 所有POD 通过IP 直接访问其他POD，不管POD 是否在同一台物理机上
- POD 内的所有容器共享一个网络堆栈, POD 内的容器, 都可以使用localhost 来访问pod 内的其他容器。
2. Kubernetes的网络通信主要分为以下几种情况：
- Pod内容器之间的通信
- Pod到Pod之间的通信
- Pod到Service之间的通信
- 集群外部与内部组件之间的通信

# 二、KubeProxy的实现模式

1. 当service account创建的时候，Service Controller和EndPoints Controller就会被触发更新一些资源，例如基于Service中配置的Pod的selector给每一个Pod创建一个EndPoint资源并存入etcd，kube-proxy还会更新iptables的chain规则生成基于Service的Cluster IP链路到对应Pod的链路规则。
2. 接下来集群内的一个pod想访问某个服务，直接cluster ip:port即可基于iptables的链路将请求发送到对应的Pod，这一层有两种挑选pod的算法，轮询(Round Robin)和亲和度匹配(Session Affinity)。当然，除了这种iptabels的模式，还有一种比较原始的方式就是用户态的转发。
3. Kube-Proxy 会为每个 Service 随机监听一个端口 (Proxy Port)，并增加一条IPtables 规则。从客户端到 ClusterIP:Port 的报文都会被重定向到 Proxy Port，Kube-Proxy 收到报文后，通过 Round Robin (轮询) 或者 Session Affinity（会话亲和力，即同一 Client IP 都走同一链路给同一 Pod 服务）分发给对应的 Pod。

![未命名图片.png](/media/202406/10.1.15282423_image1.png)

# 三、CNI插件

1. Kubernetes设计了网络模型，但将其实现交给了网络插件。于是，各种解决方案不断涌现。为了规范及兼容各种解决方案，CoreOS和Google联合制定了CNI（Container Network Interface）标准，旨在定义容器网络模型规范。
2. 它连接了两个组件：容器管理系统和网络插件。它们之间通过JSON格式的文件进行通信，以实现容器的网络功能。具体的工作均由插件来实现，包括创建容器netns、关联网络接口到对应的netns以及为网络接口分配IP等。
3. CNI的基本思想是：容器运行时环境在创建容器时，先创建好网络名称空间（netns），然后调用CNI插件为这个netns配置网络，而后再启动容器内的进程。
4. 常用插件
- Flannel（简单、使用居多）：基于Vxlan技术（叠加网络+二层隧道），不支持网络策略
- Calico（较复杂，使用率少于Flannel）：也可以支持隧道网络，但是是三层隧道（IPIP），支持网络策略
- Calico项目既能够独立地为Kubernetes集群提供网络解决方案和网络策略，也能与flannel结合在一起，由flannel提供网络解决方案，而Calico此时仅用于提供网络策略，这时我们也可以将Calico称为Canal。