kubernetes 网络
目录
一、Kubernetes 网络模型
1、Kubernetes的网络模型设计目标
2、容器间通信
3、Pod间通信
1、Pod间通信
2、Pod间通信示意图
4、Service 与 Pod间的通信
5、集群外部访问
6、Node 与 Pod之间通信实验
1. 创建一个pod
2. 查看该pod的ip地址及所处节点
3. 从master节点访问该pod（集群任何节点都可访问，但是物理机无法访问）
4. 查看主机上的路由可知，主机通过cali网络与pod通信
7、Pod 和 Pod间通信实验
1. 紧接上一个实验，创建一个client pod
2. 连通性测试
3. 在容器中访问nginx服务
8、集群外访问实验
1. 查看已经运行的pod的label
2. 创建type为 nodePort 的 Service 的yaml文件
3. 查看该service状态
4. 通过集群外主机访问该网络（任何一台node主机均可）
二、Pod网络实现方式
1、Pod网络的实现方式
2、虚拟网络接口的实现方式
3、虚拟网络接口实现原理
三、CNI 插件及常见的实现
1、容器网络模型规范CNI
2、CNI Drivers
3、CNI 插件种类
4、主流CNI插件项目
1. Flannel：
2. Calico：
3. Canal：
5、主流CNI插件项目
1. Weave Net
2. Contiv
3. OpenContrail
4. Romana
5. NSX-T
6. kube-router
一、Kubernetes 网络模型
1、Kubernetes的网络模型设计目标
Kubernetes 网络模型用于满足以下四类通信需求： ① 同一Pod内容器的通信（Contarner to Contarner） ② Pod间的通信（Pod to Pod） ③ Service 到 Pod间的通信（Service to Pod） ④ 集群外部与 Service 之间的通信（External to Service）
2、容器间通信
1. Pod内各容器共享同一网络名称空间，该名称空间通常由基础架构容器所提供
- 例如：由pause镜像启动的容器。
所有运行于同一Pod内的容器与同一主机上的多个进程类似，彼此之间通过环回端口（Loopback）完成交互，如下图所示，Pod N 内的Contarner1、Container2、Container3之间通信即为容器通信
2. 不同Pod之间不存在端口冲突的问题，因为每个Pod都有自己的IP地址
3、Pod间通信
1、Pod间通信
1. Pod的IP是集群可见的，即集群中的任何其他Pod和节点都可以通过IP直接与Pod通信，这种通信不需要借助任何的网络地址转换、隧道或代理技术
2. Pod内部和外部使用的是同一个IP，
这也意味着标准的命名服务和发现机制，比如DNS可以直接使用
2、Pod间通信示意图
每一个工作节点都有一个cbr0（容器的桥接网卡），将物理机的真实网卡和pod网卡进行桥接；
4、Service 与 Pod间的通信
1. Service资源的专用网络也称为集群网络（Cluster Network）
2. Pod间可以直接通过IP地址通信，但前提是Pod得知道对方的IP。在Kubernetes集群中，
Pod可能会频繁的销毁和创建，也就是说Pod的IP不是固定的
3. 为了解决这个问题，Service 提供了访问 Pod 的抽象层。无论后端的Pod如何变化，Service 都作为稳定的前端对外提供服务。同时，Service还提供了高可用和负载均衡功能，Service 负责将请求转发给正确的Pod
5、集群外部访问
1. Kubernetes提供了两种方式让外界能够与Pod通信：
① NodePort：
Service通过Cluster节点的静态端口对外提供服务。外部可以通过
<NodeIP>:<NodePort>访问Service
② LoadBalancer：
Service利用load balancer （服务或设备）对外提供服务，LB负责将流量导向service
6、Node 与 Pod之间通信实验
1. 创建一个pod
$ kubectl run nginx --image=nginx --port 802. 查看该pod的ip地址及所处节点
$ k get pods nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 79s 172.16.126.9 k8s-worker2 <none> <none>3. 从master节点访问该pod（集群任何节点都可访问，但是物理机无法访问）
$ curl 172.16.126.9
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
4. 查看主机上的路由可知，主机通过cali网络与pod通信
cali 是calico插件生成的逻辑接口
$ ip route ... 172.16.235.199 dev cali3141926d627 scope link 172.16.235.200 dev cali5c0f36aa90a scope link 172.16.235.201 dev cali9f7d3bffcdd scope link ...
7、Pod 和 Pod间通信实验
1. 紧接上一个实验，创建一个client pod
$ kubectl run busybox --image=busybox -- sleep 6h
pod/busybox created
$ kubectl get pods busybox -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox 1/1 Running 0 14s 172.16.194.73 k8s-worker1 <none> <none>
2. 连通性测试
$ kubectl exec -it busybox -- /bin/sh
/ # ping 172.16.126.9 #ping上一个podIP
PING 172.16.126.9 (172.16.126.9): 56 data bytes
64 bytes from 172.16.126.9: seq=0 ttl=62 time=1.252 ms
64 bytes from 172.16.126.9: seq=1 ttl=62 time=0.911 ms3. 在容器中访问nginx服务
/ # telnet 172.16.126.9 80 #telnet默认是23端口，所以要指定访问80端口
Connected to 172.16.126.9
get #获取信息
HTTP/1.1 400 Bad Request
Server: nginx/1.23.1
Date: Sun, 25 Sep 2022 03:29:42 GMT
Content-Type: text/html
Content-Length: 157
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.23.1</center>
</body>
</html>
Connection closed by foreign host
8、集群外访问实验
1. 查看已经运行的pod的label
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
busybox 1/1 Running 0 90m run=busybox
nginx 1/1 Running 0 142m run=nginx2. 创建type为 nodePort 的 Service 的yaml文件
$ kubectl apply -f- <<EOF
apiVersion: v1
kind: Service
metadata:
name: nginx-access
spec:
selector:
run: nginx
type: NodePort #类型为NodePort
ports:
- port: 80
targetPort: 80
nodePort: 30080
EOF
把nginx这个pod导成service（使用标签选择器run:nginx），
这个上边做NodePort，在所有master和工作节点上放行30080端口，
当选择master和工作节点时，他会通过service将端口转到相应pod的80端口3. 查看该service状态
$ kubectl get service nginx-access
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-access NodePort 10.108.232.110 <none> 80:30080/TCP 9m59s4. 通过集群外主机访问该网络（任何一台node主机均可）
使用浏览器访问物理机IP:30080
二、Pod网络实现方式
1、Pod网络的实现方式
1. 每个Pod对象内的基础建构容器均使用一个独立的网络名称空间 2. 该名称空间会共享给同一Pod内其他容器使用 3. 每个网络名称空间均有其专用的独立网络协议栈及其相关的网络接口设备 4. 一个网络接口仅能属于一个网络名称空间 5. 运行多个Pod必然要求使用多个网络名称空间，也就需要多个网络接口设备
2、虚拟网络接口的实现方式
1. 用软件实现的虚拟网络接口及虚拟线缆将其连接至物理接口是一种较为流行的方案 2. 虚拟网络接口的实现方案常见的有虚拟网桥、多路复用及硬件交换三种
3、虚拟网络接口实现原理
三、CNI 插件及常见的实现
1、容器网络模型规范CNI
1. Kubernetes设计了网络模型
2. CoreOS和Google 联合制定了 CNI（Container Network Interface）标准，
连接了两个组件：容器管理系统和网络插件
3. CNI 的设计思想是：
容器runtime在创建容器时，
提前创建好网络的名称空间（netns），
然后调用CNI 插件为这个nets配置网络，然后再启动容器内的进程
2、CNI Drivers
CNI 的优点是支持多种容器runtime，不仅仅是Docker。
CNI 的插件模型支持不同组织和公司开发的第三方插件，这对运维人员来说很有吸引力，可以灵活选择适合的网络方案
3、CNI 插件种类
1. CNI本事只是规范，付诸生产还需要有特定的实现
2. 插件分为三类：
4、主流CNI插件项目
1. Flannel：
一个为Kubernetes提供叠加网络的网络插件， 它基于Linux TUN/TAP，用 UDP 封装IP报文来创建叠加网络，并借助etcd维护网络的分配情况
2. Calico：
一个基于BGP的三层网络插件，并且也支持网络策略来实现网络的访问控制；
它在每台机器上运行一个vRouter，
利用Linux内核来转发网络数据包，并借助iptables实现防火墙等功能
3. Canal：
由Flannel 和 caco 联合发布的一个统一网络插件，提供CNI 网络插件，并支持网络策略
5、主流CNI插件项目
1. Weave Net
一个多主机容器的网络方案，支持去中心化的控制平面，在各个host 上的 vRouter 间建立Full mesh 的 TCP连接，并通过Gossip同步控制信息
2. Contiv
思科开源的容器网络解决方案，主要提供基于Policy的网络管理，
并与主流容器编排系统集成；Contiv最主要的优势是直接提供了多租户网络，
并支持L2（VLAN）、L3（BGP）、Overlay（VXLAN）等
3. OpenContrail
Juniper 推出的开源网络虚拟化平台，其商业版本为Contrail。
由控制器和vRouter组成，控制器提供虚拟网络的配置、控制盒分析功能，
vRouter则提供分布式路由，负责虚拟路由器、虚拟网络的建立及数据转发
4. Romana
由Panic Networks 于 2016年释出的开源项目，旨在借鉴路由汇聚（route aggregation）的思路来解决叠加方案为网络带来的开销
5. NSX-T
用于定义敏捷SDI（Software-Defined Infrastructure）以构建云原生应用环境；
其旨在合并异构端点（不同虚拟化）或技术栈的应用框架和架构，
如vSphere、KVM、容器和bare metal 等
6. kube-router
kube-router 是 kubernetes 网络的一体化解决方案，
它可取代kube-proxy实现基于ipvs的Service，能为pod提供网络，
支持网络策略以及拥有完美兼容BGP的高级特性