其他分享
首页 > 其他分享> > k8s的service端口暴露与代理

k8s的service端口暴露与代理

作者:互联网

文章目录

1 Service

Kubernetes Service定义了这样一种抽象:逻辑上的一组 Pod,一种能够访问它们的策略 —— 一般被称为微服务。这一组 Pod 可以被 Service 访问到,一般是经过selector实现的。

举例:考虑一个图片处理 backend,它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪一个 backend 副本。 然而组成这一组 backend 程序的 Pod 实际上可能会发生变化,frontend 客户端不必知道,并且也不需要跟踪这一组 backend 的状态。Service 定义的抽象可以解耦这种关联。

Service能够提供负载均衡的能力,可是使用上存在以下限制

web访问的service服务示例图
在这里插入图片描述

2 service暴露端口的方式

2.1 clusterIP

此类型会提供一个集群内部的虚拟IP(与pod不在同一网段),以供集群内部的pod之间通信使用。clusterIP也是kubernetes service的默认类型,主要需要以下几个组件的协同工作

2.2 NodePort

NodePort模式除了使用clusterip外,也将service的port映射到每个node的一个指定内部的port上,映射的每个node的内部port都一样。为每个节点暴露一个端口,通过nodeIP+nodeport可以访问你这个服务,同时服务依然会有cluster类型的ip+port。内部通过clusterip方式访问,外部通过nodeport方式访问

2.3 loadbalancer

loadbalancernodeport基础上,k8s可以请求底层云平台创建一个负载均衡器,将每个node作为后端,进行服务分发,该模式需要底层云平台(例如GCE)支持

2.4 lngress

lngress是一种http方式的路由转发机制由lngress controllerhttp代理服务器组合而成,lngress controller实例监控kubernetes api实时更新http代理服务器的转发规则。http代理服务器有GCE load-balancer、haproxy、nginx等开源方案

service是一个抽象概念,定义了一个服务的多个pod逻辑合集和访问pod的策略,一般把service称为微服务.举个例子一个a服务运行3个pod,b服务怎么访问a服务的pod,pod的ip都不是持久化的重启之后就会有变化。这时候b服务可以访问跟a服务绑定的serviceservice信息是固定的提前告诉b就行了,service通过Label Selector跟a服务的pod绑定,无论a的pod如何变化对b来说都是透明的

3 kubernetes代理方式

Kubernetes集群中,每一个 Node 运行一个kube-proxy进程。kube-proxy负责为 Service实现了一种 VIP(虚拟 IP)的形式,而不是 ExternalName的形式

Kubernetes v1.0开始,已经可使用 userspace代理模式。Kubernetes v1.1添加了 iptables 代理模式,在Kubernetes v1.2kube-proxyiptables模式成为默认设置。Kubernetes v1.8添加了ipvs代理模式

3.1 userspace代理模式

这种模式kube-proxy会监视 Kubernetes masterService对象和 Endpoints对象的添加和移除。 对每一个 Service它会在本地 Node 上打开一个端口(随机选择)。 任何链接到代理端口的请求,都会被代理到 Servicebackend Pods中的某个上面(如 Endpoints所报告的同样)。 使用哪一个 backend Pod,是 kube-proxy基于 SessionAffinity来肯定的

它配置iptables规则,捕获到达该 ServiceclusterIP(是虚拟 IP)和 Port 的请求,并重定向到代理端口,代理端口再代理请求到 backend Pod

默认状况下,userspace模式下的kube-proxy经过循环算法选择后端,默认的策略是,经过round-robin算法来选择 backend Pod

在这里插入图片描述

3.2 iptables 代理模式

这种模式,kube-proxy会监视Kubernetes控制节点对 Service对象和 Endpoints对象的添加和移除。 对每一个 Service它会配置iptables规则,从而捕获到达该ServiceclusterIP和端口的请求进而将请求重定向到Service的一组 backend中的某个上面。对于每一个 Endpoints对象,它也会配置 iptables规则,这个规则会选择一个backend组合。

默认的策略是kube-proxyiptables模式下随机选择一个backend

使用iptables处理流量具备较低的系统开销,由于流量由Linux netfilter处理,而无需在用户空间和内核空间之间切换。 这种方法也可能更可靠。

若是kube-proxyiptables模式下运行,而且所选的第一个Pod 没有响应,则链接失败。 这与userspace模式不一样;在这种状况下kube-proxy将检测到与第一个 Pod 的链接已失败,并会自动使用其余后端 Pod 重试。

咱们可使用Pod readiness探测器 验证后端 Pod 是否能够正常工做,以便 iptables模式下的kube-proxy仅看到测试正常的后端。这样作意味着能够避免将流量经过kube-proxy发送到已知已失败的Pod

在这里插入图片描述

3.3 IPVS 代理模式

ipvs模式下kube-proxy监视Kubernetes服务Service和端点Endpoints调用 netlink接口相应地建立 IPVS规则, 并按期将 IPVS规则与Kubernetes服务Service和端点Endpoints同步。该控制循环可确保IPVS状态与所需状态匹配。访问服务Service时,IPVS 将流量定向到后端Pod之一

IPVS代理模式基于相似于iptables模式的 netfilter挂钩函数,可是使用哈希表做为基础数据结构,而且在内核空间中工做。 这意味着,与 iptables模式下的 kube-proxy相比,IPVS模式下的kube-proxy重定向通讯的延迟要短,而且在同步代理规则时具备更好的性能。与其余代理模式相比,IPVS模式还支持更高的网络流量吞吐量

IPVS提供了更多选项来平衡后端Pod的流量

注意: 要在IPVS模式下运行kube-proxy必须在启动kube-proxy以前使IPVS Linux在节点上可用。 当kube-proxyIPVS代理模式启动时,它将验证IPVS内核模块是否可用。 若是未检测到IPVS内核模块,则 kube-proxy将退回到以iptables代理模式运行

在这里插入图片描述

4 Service服务类型

5 实列

标签:iptables,k8s,Service,service,端口,IPVS,proxy,kube
来源: https://blog.csdn.net/weixin_46727129/article/details/122149555