承接上文深入理解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集群 配置复杂