《Kubernetes》你需要掌握的 Service 和 Ingress，纯干货！

这节我们说下 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。