标签：K8S Kube 端口 深入 Proxy 转发 原理 pod k8s
承接上文深入理解K8S网络原理上
Service 应用是K8s集群内部可见的
而我们发布的应用需要外网甚至公网可以访问
K8s如何将内部服务暴露出去？
四层网络只有Node节点网络可以对外通讯
现在问题是第2层的Service网络如何通过第0层Node节点网络暴露出去呢？
需要再思考一个问题 在k8s服务发现原理图中 哪个组件既知道
service网络的所有信息又可以和pod网络互通互联同时又可以与节点网络打通呢？
那就是Kube-Proxy 对外暴露服务也是通过这个组件实现的
只需要让Kube-Proxy在节点上暴露一个监听端口就可以了
所以NodePort就闪亮登场了
NodePort
将service type设置为NodePort 端口范围在30000～32767之间
k8s发布以后 会在每个节点上都会开通NodePort端口 这个端口的背后就是Kube-Proxy
当外部流量想要访问k8s服务的时候
先访问NodePort端口 然后通过Kube-Proxy转发到内部的Service抽象层
然后再转发到目标Pod上去
LoadBalancer 负载均衡器
如果在阿里云上有一套k8s环境
将service type设置为LoadBalancer
阿里云K8s会自动创建NodePort进行端口转发 同时也会
申请一个SLB 有独立的公网IP 并且也会自动映射K8s集群的NodePort上
以上是生产环境 就可以通过SLB暴露出去的公网IP访问到K8s集群内部的NodePort
但在开发测试环境可以直接通过NodePort访问
这种方式的劣势：
如果暴露一个服务就需要购买一个LB+IP
如果暴露10个服务就需要购买10个LB+IP
所以成本比较高
那有没有办法购买一个LB+IP能不能将更多的服务暴露出去呢？
那么Ingress就闪亮登场了
也就是在K8s内部部署一个独立的反向代理服务 让它做代理转发
Ingress
Ingress是一个特殊的service 通过节点80/443暴露出去
Ingress可以通过path或者域名转发到Service抽象层然后转发到Pod
只需要设置好转发的路由表即可
本质上和Nginx没有差别
service kind设置为ingress
ingress提供的主要功能是七层反向代理 如果暴露的是四层服务还是需要走LB+IP方式
还可以做安全认证、监控、限流、证书等高级功能
有了Ingress就可以购买一个LB+IP就可以将k8s集群中的多个service暴露出来
本地环境想要快速的开发调试方法
kubectl proxy
通过kubectl proxy在本机创建一个代理服务
通过这个代理服务可以访问k8s集群内任意的http服务
通过master上的api server间接的去访问k8s集群内的服务
因为master是知道集群内所有服务的信息
这种方式仅限于七层的http转发
kubectl Port-Forwarding
在本机上开启一个转发端口间接转发到k8s内部某个pod端口上去
这种方式支持http转发和tcp转发
kubectl exec
通过该命令直接连接到pod上去执行命令
小结
深入理解Kube-Proxy
Kube-Proxy主要实现服务发现和负载均衡以及ClusterIP到PodIP的转换
Kube-Proxy通过linux内核提供的2个机制间接实现
"Netfilter"和"iptables"
通过这2个机制的配合来实现IP地址的转换以及流量的路由
Netfilter是linux内核支持的一种钩子方法 允许内核的其他模块注册回调方法
这些回调方法可以截获网络包 可以改变它们的目的地路由
iptables是一组用户空间程序
通过它可以设置Netfilter中的路由规则
iptables程序可以检查、转发、修改、重定向或者丢弃ip网络包
iptables是Netfilter用户空间接口 可以间接操作Netfilter中的路由规则
Kube-Proxy可以通过iptabels程序可以去操作内核空间的Netfilter里面的路由规则
而Netfilter可以截获底层的IP网络包就可以修改它们的路由
Kube-Proxy的工作模式
-
用户空间代理模式
大部分的网络功能 包括设置包路由规则、负载均衡都是由运行在用户空间的Kube-Proxy直接完成的
它监听请求 执行路由和负载均衡 将请求转发到目标pod
在该模式下 kube-proxy还需要频繁在用户空间和内核空间切换
因为它需要和iptables交互来实现负载均衡
1、kube-proxy 监听 master 服务创建、更新、删除事件
也监听这些服务对应的端点的地址
如果pod ip发生了变化 kube-proxy也会同步这种变化
2、当有一个类型为ClusterIp的新服务被创建 Kube-Proxy会在节点上创建一个随机的端口 比如在10.100.0.2上开启一个随机端口10400
通过这个端口可以将目标请求转发到对应的端点上即pod上面
3、通过iptables设置转发规则 比如请求ip是10.104.14.67:80这个请求转发到10.100.0.2:10400这个地址上去
4、当节点上面有客户端对10.104.14.67:80这个service ip以及对应的podip10.100.0.2:10400发起调用的话
5、这个请求会被netfilter截获到并且转发到10.100.0.2:10400这个上面 也就是kube-proxy正在监听的端口
6、kube-proxy接受这个请求 通过负载均衡 转发到pod上面
上面1-3步是服务发现阶段
4-6部是运行阶段
将请求转发到10400端口 kube-proxy先切换到内核接受这个请求包
然后切换到用户空间进行负载均衡调用
由于频繁的上下文切换 这种模式的性能并不理想
所以又引入了iptabels模式
iptables模式
1、kube-proxy会监听master上面的服务创建或者删除
也会监听服务背后所对应的pod ip地址
2、当有一个类型为clusterip的新服务被创建 kube-proxy通过iptables直接设置转发规则 并直接负载均衡转发到目标pod上面
不穿透kube-proxy 性能高
但iptables不支持高级的负载均衡策略也不支持失效自动重试机制
一般需要就绪探针进行配合
这种模式仅适用于中小模式的k8s集群 不适用大规模的k8s集群
假设有5000个节点的集群 集群有2000个服务 每个服务有10个pod 就需要在每个节点同步大约2万条记录 同时在云环境中 后端pod ip可能会随时变化 会给linux内核带来巨大的开销
为了支持更大规模的k8s集群 引入了IPVS Proxy模式
IPVS Proxy模式
该模式是linux内核支持的虚拟化构建技术 是建立在netfilter基础之上的 是为了内核传输层高性能的负载均衡设计的技术
也是LVS主要的组成技术
不仅支持缺省的Round Robbon(加权轮询)还支持最小连接、目标源hash 负载均衡算法
使用高效的hash算法来存储网络路由规则 可以显著减少iptables的同步开销 大大提升集群的扩展规模
Kube-Proxy通过调用Netfilter接口来创建和同步IPVS规则的
实际的路由转发和负载均衡由IPVS负责
IPVS效率最高 扩展性最好 配置也是最复杂的
小结
-
用户空间代理模式 已淘汰 -
Iptables模式 生产适用 中小规模k8s集群 -
IPVS模式 生产使用 大规模K8s集群 配置复杂
标签：K8S,Kube,端口,深入,Proxy,转发,原理,pod,k8s 来源： https://blog.csdn.net/qq_16485855/article/details/120734636
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。