k8s网络架构k8s实战实现原理kube-proxy架构和Kubernetes分享
Posted 江南飞羽
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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 <vs> NodePort模式
loadbalance 的service模式其实跟nodePort模式几乎完全一样, 都是在node上监听某个3xxxx端口,流量到达3xxxx后转发给ipvs再分发到pod
nodePort 名字跟loadbalance有区别, 但TMD实际上是完全一样的。 希望K8S官方以后能统一一下口径体谅一下用户体验,不要搞那么多新名词。
4) 总结
- 小结: K8S网络实现原理基本情况如上, 如由疑问的小伙伴 ,可加本人微信咨询交流
- 联系: 微信号q613230000
以上是关于k8s网络架构k8s实战实现原理kube-proxy架构和Kubernetes分享的主要内容,如果未能解决你的问题,请参考以下文章