k8s网络架构、k8s实战、实现原理、kube-proxy架构和Kubernetes分享

前言：

近期在做K8S的技术积累，发现网络各个社区极少有经验化的介绍K8S架构，小弟才疏学浅，尝试跟大家分享

 

K8S各种Service

- LoadBalance: 请看下文，本质上跟NodePort完全一致，均是kube-proxy-bin进程在node上启动一个port如32080，请求到达32080后经kube-proxy如ipvs模块转发到后端的pod

- NodePort： 可对外提供服务， 通常关联Ingress、nginx-ingress、haproxy-ingress， 实测LB入口只能关联NodePort无法关联ClusterIP

- ClusterIP： 相信大家是非常熟悉的了，默认api-server就是用此方式访问

 

K8S网络架构大体如下（LB直通场景不在讨论范围）

 - 图解： 红色为控制路径、 黑色为生产流量路径

 - 业务平面： 此维度相信是绝大部分管理员所关心的， 也就是公网用户如何经过接入层LB-> K8S内部负载均衡 (kube-proxy) -> 业务Pod

 - 控制平面： 执行kubectl 时会先调用master的apiServer， 然后调用各个worker node上的kubelet（常驻）进程实现集群管理（如pod增删改，service/ingress管理）

 

上干货，实现原理实战和请求路径

 - 119.29.126.122： 公网LB入口， 用户请求首先到达这里。

 - nodePort：node上监听了30080端口，这个端口是谁创建的呢（可netstat -tunlp|grep 30080看看）， 事实上30080是有kube-proxy-bin创建的（kube-proxy pod里面的一个命令）

 - ipvs： kube-proxy有iptables和ipvs两种模式， 我司环境为后者。 请求到达ipvs后再分发到各个pod

 - kube-proxy 监听了nodePort

请求链路示意图

30080 nodePort 的ipvs， 关联了后端的pod （注意： 部分port可能部署不在本地node，需转发到其他node处理）

LoadBalance  NodePort模式

loadbalance 的service模式其实跟nodePort模式几乎完全一样， 都是在node上监听某个3xxxx端口，流量到达3xxxx后转发给ipvs再分发到pod

nodePort 名字跟loadbalance有区别， 但TMD实际上是完全一样的。 希望K8S官方以后能统一一下口径体谅一下用户体验，不要搞那么多新名词。 

 

4) 总结

 - 小结： K8S网络实现原理基本情况如上， 如由疑问的小伙伴 ，可加本人微信咨询交流

 - 联系： 微信号q613230000