这节我们说下 k8S 搭建完服务后如何访问!
首先我们要清楚什么是Service 和 Ingress。简单来说,这两个组件都是用来做流量负载的。那么什么又是流量负载呢?当我们在集群内部已经通过 pod 部署了我们的应用服务,那么下一步要干啥?那就是让用户访问到我们的应用服务,这个才是最重要的,不然你部署完了,用户却访问不了,那岂不是无用功~
一、Service
在 k8s 中,pod 是应用程序的载体,我们可以通过 pod的 IP 来访问我们的应用程序,但是我们已经清楚了 pod 是具有生命周期的,一旦 pod 出现问题,pod控制器将会将pod销毁进行重新创建。那么这个时候 pod 的Ip就会发生变化,因此利用 pod IP 访问应用程序的方式直接 pass了,那么为了解决这个问题,k8s 引入了 Service 的资源概念,通过这个资源,可以整合多个pod,提供一个统一的入口地址,通过访问 Service 的入口地址就能访问到后面的 pod服务!
Service不是凭空出现的,不知道你是否还记得 Node 节点上的关键组件 kube-proxy!关键点来了哦~我们看个老图回忆一下:
这张图有看过之前的博文都不会陌生,是的!kube-proxy 在这里面起到了关键性的作用,每个 Node 节点上都运行着一个 kube-proxy 服务进程,当创建 Service 的时候会通过 api-server 向 etc写入创建的 service 的信息,而 kube-proxy 会基于监听的机制发现这种 Service 的变动,然后 它会将最新的Service信息转换成对应的访问规则
到这里,应该对Service有个大概的概念,起码知道了它的用处,接下来我们不妨更加深入的了解一下~
1)工作模式
kube-proxy 支持 3 种工作模式,如下:
1. userSpace
这个模式比较稳定,但是效率比较低!在 userSpace 模式下,kube-proxy 会为每一个 Service 创建一个监听端口,当有请求发往Cluster IP 的时候,会被 Iptables 规则重定向到 kube-proxy 监听的端口上,kube-proxy 会根据 LB 算法选择一个 Pod 提供服务并建立起连接。
这个模式下,kube-proxy 充当的角色是一个 四层负责均衡器,由于 kube-proxy 运行在 userSpace 模式下,在进行转发处理的时候会增加内核和用户空间之间的数据拷贝,因此效率比较低。
2. iptables
在 iptables 模式下,kube-proxy 会为 Service 后端的每个 pod 都创建对应的 iptable 规则,直接将发往 Cluster IP 的请求重定向到一个 pod IP 上。该模式下 kube-proxy 不承担四层负载均衡器的角色,只负责创建 iptables 的规则。该模式的优点便是较 userspace 模式来说效率更高,但是不能提供灵活的 LB 策略。当后端Pod不可用的时候也无法进行重试。
3. ipvs
这种模式与 iptables 模式形似,kube-proxy 会监控pod的变化并且创建相应的 ipvs 规则。但是 ipvs 规则相对于 iptables 来说转发效率更高,而且支持更多的 LB 算法。
实践
上面了解到3种工作模式。我们来简单试一下 ipvs 的作用。首先准备一份资源清单:
这份清单上半部分是创建一个 Pod控制器,下半部分是创建一个 Service。