承接上文深入理解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设置为ingressingress提供的主要功能是七层反向代理 如果暴露的是四层服务还是需要走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集群 配置复杂