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