一直没有写过,通过自己学习的一些感悟,记录下来,期望一起学习的小伙伴共同维护成长
直戳主题
kubernetes 在网络方面提出 service 概念 ,实现原理通过 node节点上的proxy 进程调用 iptables进行网络均衡 简单说 就是 每个node 上面都有同样的iptables 规则 帮你轮转 到后端的pod上 这点 有点像 lvs 的 nat模式
再说 kubernetes 从pod 访问 service 同样的使用iptables 做了如上同样规则 ,node访问也一样
重点, 从外部访问 官方提供 2种办法
a,使用 给本机通过iptalbes 映射一个端口 访问到 service (每个机器都映射)nodeport 方式
b,通过 官方提供lb 但是 目前这种lb 只支持 google 的 与aws的 (普通用户无法访问)
那问题来了
我们如何从外面 访问 到里面service 或者pod
方法 1,直接从etcd 里面调用后端pod地址实现 目前大部分同学都是这种办法
方法2, 直接从外面访问 service (我这里做的是直连路由模式)
5 台机器
master 10.1.11.250 网关10.1.11.254
添加2条路由 10.1.51.0/24 gw 10.1.11.1 (通过 ospf 软件直接学习 quagga)
10.1.52.0/24 gw 10.1.11.2
node1 10.1.11.1 网关10.1.11.254 docker 网络 10.1.51.1 在额外起一片虚拟网卡 10.1.200.253
10.1.52.0/24 10.1.11.2 (quagga)
node2 10.1.11.2 网关10.1.11.254 docker 网络 10.1.52.1 在额外起一片虚拟网卡 10.1.200.253
10.1.51.0/24 10.1.11.1 (quagga)
网关路由器 10.1.11.254 外网10.1.10.1 (quagga)
10.1.51.0/24 gw 10.1.11.1
10.1.52.0/24 gw 10.1.11.2
客户端地址 10.1.10.200
加静态 route 10.1.200.0 gw 10.1.10.1
route 10.1.11.0 gw 10.1.10.1
kubernetes 虚拟网络 10.1.200.0/24
通过上面的设置 路由器 上面 到达 10.1.200.0/24 nexttop 10.1.11.1
nexttop 10.1.12.1
通过session cache 可以 完成简单的轮训分发 并保证session一致性
这样我用session 放出的服务 10.1.200.200 5000端口 当路由转到 10.1.11.1 或者 11.2 由于proxy 预先有5000端口的 dnat 那么访问就直接被调度到后端 pod上面 (service 谷歌本身就做了 负载均衡 )
通过上面放置路由器 实现等价路由 来访问不同的 node1 实现负载。
文字功底不行,简单说到这里 ,谷歌service 感觉其实现与 lvs fullnat 差不多 顾采用 相同 直连路由方案。
本文出自 “慢慢的走” 博客,请务必保留此出处http://byebye758.blog.51cto.com/1041315/1753636
原文地址:http://byebye758.blog.51cto.com/1041315/1753636