《thoughtworks林帆白话kubernetes网络》由会员分享，可在线阅读，更多相关《thoughtworks林帆白话kubernetes网络（29页珍藏版）》请在金锄头文库上搜索。
1、白话Kubernetes网络 Kubernetes落地实践专场 深圳站 林帆 ThoughtWorks DevOps技术咨询师 CoreOS实践之路书作者 内容提要 容器的网络是在CaaS集群中无法避免话题， 作为当下最主流的一种容器集群解决方案， Kubernetes对网络进行了合理的抽象，并 采用了开放的CNI模型。面对各种容器网络 实现，他们有什么不同，应该如何选择？这 个话题将带大家回顾Kubernetes各种主流 网络方案的发展历程，并透过现象清本质， 用形象的例子展示Weave、Flannel、Calico 和Romana等网络解决方案背后的原理。 白话Kubernetes网络 听
2、 了 很 多 大 道 理 ， 却 还 是 配 不 好 一 个 网 络 . 今天我们的目标线 那些年我们听过的容器网络. -二进制的协议世界- -神秘的内核空间- -危险的深水区- -舒适的浅水区- -美丽的海平面- Kubernetes网络的发展 还记得大明湖畔的CNI么？ v1.1版本以前 没有标准，只有假设 v1.1版本 没有实现，只有标准 v1.2版本 内置实现，多种扩展 v1.3版本以后 关注网络安全、网络策略 基本假设：每个Pod都拥有一个独立IP，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中。 基于此假设，用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑容器端
3、口映射到主机端口等问题 同一个Pod内部的所有容器共享一个网络堆栈即网络命名空间，Pod内的所有容器的端口是共享的 Kubernetes对集群网络要求： 所有容器都可以在不用NAT的方式下同别的容器通信 所有节点都可以在不用NAT的方式下同所有容器通信，反之亦然 容器的地址和别人看到的地址是同一个 这个假设作为Kubernetes网络的基本原则 现在依然成立 石器时代没有标准，只有假设 2014.06 - 2015.09 k8s诞生 v1.1版本 PodPod Ser vice PodPod Ser vice Ser vice Clu ste rIP No dePo rt Lo a dBala
4、nce r Exte r nalNam e 这个时期冒出来的名词 Pipework CalicoWeaveFlannel OVSPipework Open vSwitch 豪华自动挡 全能手动挡 青铜时代没有实现，只有标准 2015.09 - 2016.03 v1.1版本 v1.2版本 为什么Kubernetes不使用libnetwork： http:/ (Co ntain e r Netwo rk Inte rface) CNI CNI有多简单 一个配置文件 一个可执行文件 读取6个环境变量 接收1个命令行参数 实现2个操作（ADD/DEL） 完整的CNI规范内容：https:/ 将Dock
5、er network命令转换为CNI插件的例子：https:/ 非官方CNI网络性能测试（带宽） 测试环境： 亚马逊云首尔区 (实例类型 t2-small) 软件版本： Kubernetes Weave Romana Calico Flannel *这个一个非常不严谨的 测试环境，结果仅供参考 娱乐 Bare Romana Flannel(gw) Calico(bgp)Calico(ipip) Swarm(overlay) Flannel(vxlan) Weave(fastpath) Flannel(udp) Weave(sleeve) 理论结果： v1.6.2 v1.9.7 v1.1.0 v
6、2.3.0 v0.7.1 非官方CNI网络性能测试（丢包率） 125MBPS(1GB带宽)传输数据12.5MBPS(100MB带宽)传输数据 非官方CNI网络性能测试方法 测试过程： 1. 部署至少两个Node的Kubernetes集群 2. 部署一种CNI插件，获得跨节点网络 3. 创建一个包含两个Pod的Deployment 4. SSH分别登录两个节点，docker exec进入容器 5. 在两个容器中分别安装iper f3 6. 在其中一个容器启动iper f3服务端 7. 在另一个容器中使用iper f3客户端执行测试 apiVersion: apps/v1beta1 kind: D
7、eployment metadata: name: nginx-deployment spec: replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 测试工具：iperf3 安装方法： wget https:/iperf.fr/download/ubuntu/libiperf0_3.1.3-1_amd64.deb wget https:/iperf.fr/download/ubuntu/iperf3_3
8、.1.3-1_amd64.deb sudo dpkg -i libiperf0_3.1.3-1_amd64.deb iperf3_3.1.3-1_amd64.deb 使用方法： iperf3 -s -p 9999 #启动服务端 iperf3 -c $SERVER_IP -p 9999 -i 1 -b 0 #测试带宽 iperf3 -c $SERVER_IP -p 9999 -u -i 1 -b 1G #测试1G带宽丢包率 iperf3 -c $SERVER_IP -p 9999 -u -i 1 -b 100M #测试100M带宽丢包率 *可以是任意基于Ubuntu/Debian的镜像 为什么会
9、有各式各样的网络方案? 为什么会有各式各样的网络方案？ 因为跨节点的容器网络不通 因为Kubernetes只约定了规范 为什么有辣么多厂商要来实现这个规范？ 为什么跨节点的容器网络不通？ https:/ 为什么跨节点的网络不通？ 我的地址是 172.17.0.2问题一：容器地址重复 我们小区里 有10栋1单元 1楼101号 咦，这么巧 我们小区也 有10栋1单元 1楼101号 我的地址也是 172.17.0.2 从172.17.0.2 发往172.17.0.2 你在逗我咩!? 地址分配表 host1-172.17.x.x host2-172.18.x.x 为什么跨节点的网络不通？ 我的地址是
10、172.18.0.2 Flannel的解决方案： 中心化容器地址分配 我的地址是 172.17.0.2 从172.17.0.2 发往172.18.0.2 分配IP段：172.18.x.x 分配IP段：172.17.x.x Etcd配置存储服务 问题一：容器地址重复 为什么跨节点的网络不通？ 我的地址是 172.18.0.2问题二：容器地址不可达 发往： 172.18.0.2 路由表根本没有 172的网段地址， 垃圾信息，丢掉 在喵星好像没 有汪公馆 这个地址啊! 地址： 汪公馆12号 主机地址：10.2.0.3 主机地址：10.2.0.4 为什么跨节点的网络不通？ 我的地址是 172.18.0
11、.2问题二：容器地址不可达 发往： 172.18.0.2 拆包，发现里面 还有一个IP包， 地址是172.18.0.2 主机地址：10.2.0.3 主机地址：10.2.0.4 Flannel的解决方案： 方案1.覆盖网络 对应udp和vxlan运行模式 装包，发往 10.2.0.3 发往 10.2.0.3 UDP Overlay (IP in UDP) VXLAN Overlay (L2 in UDP) Host Mac Host IP UDP Real IP Data Host Mac Host IP UDPv x l an Real Mac Real IP Data 为什么跨节点的网络不通
12、？ 我的地址是 172.18.0.2问题二：容器地址不可达 发往： 172.18.0.2 收到一个地址是 172.18.0.2的包， 路由给容器 主机地址：10.2.0.3 主机地址：10.2.0.4 Flannel的解决方案： 方案2.主机路由 对应host-gw运行模式 172.18.x.x地址 都路由给10.2.0.3 发往 10.2.0.3 内核路 由表 内核路 由表 Flannel模式的改进 连接方式： 动态BGP路由 改进点： 1.BGP路由替代主机路由 2.支持网络策略 新的问题：部分内网和公网的局部区域不支持BGP Calico的妥协机制：IPIP模式（IP in IP Ove
13、rlay） Host Mac Host IP Real IP Data https:/ Flannel模式的改进 Weave 连接方式： 覆盖网络（fastpass模式即xvlan overlay，sleeve模式即udp overlay） 改进点： 1.去除额外的中心化容器地址分配器，将配置存储功能集成到服务内部 2.支持网络策略 https:/ Flannel模式的改进 连接方式： 完美保持Flannel原生的三种模式 扩展支持Calico的BGP和IPIP模式 改进点： 1.支持网络策略 https:/ Flannel模式的改进 连接方式： 主机路由（即Host-gw模式） 改进点： 1
14、.支持网络策略 https:/ 覆盖网络主机路由网络策略 去中心化的 IP地址分配 FlannelUDP/XVLANHostGWNN CalicoIPIPBGPYN CanalUDP/XVLANHostGWYN Romana N HostGW YN WeaveUDP/XVLANNYY 各主流CNI实现的总结 铸铁时代内置实现，多种扩展 2016.03 - 2016.07 v1.2版本 v1.3版本 极术 - 也许您的Kubernetes集群并不需要SDN： https:/jishu.io/kubernetes/your-kubernetes-cluster-may-not-need-sdn/
15、kubelet -network-plugin= Exe c (已在v1.6版本中移除) CNI Kube r n et -network-plugin-mtu=. -network-plugin-dir=. Kubernetes - Network Plugins： https:/kubernetes.io/docs/concepts/cluster-administration/network-plugins/ Kubernetes内置的kubernet实现了IP地址的自动分配，若配合 AWS、GCE等云平台的网络路由可以实现小规模网络的快速搭建 黄金时代关注网络安全、网络策略 2016.07 - 至今 v1.3版本 Kubernetes - Network Policies：
