一、Service

在 k8s 中，pod 是应用程序的载体，可以通过 pod的 IP 来访问我们的应用程序，但 pod 是具有生命周期的，一旦 pod 出现问题，pod控制器将会将pod销毁进行重新创建。那么这个时候 pod 的Ip就会发生变化，因此利用 pod IP 访问应用程序的方式直接 pass了，那么为了解决这个问题，k8s 引入了 Service 的资源概念，通过这个资源，可以整合多个pod，提供一个统一的入口地址，通过访问 Service 的入口地址就能访问到后面的 pod服务！

每个 Node 节点上都运行着一个 kube-proxy 服务进程，当创建 Service 的时候会通过 api-server 向 etc写入创建的 service 的信息，而 kube-proxy 会基于监听的机制发现这种 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 算法。

2）Service 使用

上面已经介绍完了 Service 的几种工作模式。下面进入Service 的使用阶段。

Service又分为5种类型，下面将一一介绍。

1. ClusterIP

我们先看下 ClusterIP 类型的Service的资源清单：

Endpoint

Endpoint 是 k8s 中的一个资源对象，存储在etcd中，用来记录一个 service 对应的所有Pod 的访问地址，它是根据 service 配置文件中 selector 描述产生的。一个Service由一组Pod组成，这些Pod通过 Endpoint 暴露出来，可以说 Endpoint 是实际实现服务的端口的集合。通俗来说，Endpoint 是 service 和 pod 之间的桥梁

既然是一个资源，那么我们就可以获取到

负载分发

我们上面已经成功的实现了通过 Service 访问到Pod 资源，那么我们再做一些修改，分别进入3个pod编辑 usr/share/nginx/index.html 文件：

# pod01
Pod01 :  ip - 10.244.1.73
# pod02
Pod01 :  ip - 10.244.1.73
# pod03
Pod03 :  ip - 10.244.2.63

然后我们再次尝试通过 curl 10.96.10.10:80命令查看结果：

是否有发现，者中负载分发策略不就是轮询吗！对于 Service 的访问，k8s提供了两种负载分发策略：

• 如果未定义分发策略，默认使用 kube-proxy 的策略，比如随机、轮询
• 基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个pod上。而这里就需要用到我们上面提到的没有见过的东西 sessionAffinity

注意：ClusterIp 的 Service，不支持外部访问，也就是说通过浏览器访问是不生效的，只能在集群内部访问

2. HeadLiness

很多服务都需要支持定制化，如果将产品定位为服务，那么这个产品毋庸是成功。在某些场景中，开发人员并不想要使用 service 提供的负载均衡功能，而是希望自己来控制负载均衡策略。针对这种情况的发生，k8s也是很好的支持了，引入了 HeadLiness Service，这类 Service 不会分配 ClusterIp，如果想要访问 service，只能通过 Service 域名进行查询。

唯一跟 ClusterIp 不同的便是 clusterIP: None 属性的变化。

通过创建后可以发现，ClusterIP并未分配，我们继续查看 Service 的详情

通过详情我们可以发现 Endpoints 已经生效了，然后我们任意进入到一个pod中，查看域名解析情况：

可以看到域名也已经解析完成，默认域名为service名称.命名空间.svc.cluster.local

3. NodePort

上面的两个service类型，都是只能在集群内部才能访问，但是我们部署服务肯定是想让用户通过集群外部可以使用的。那么这个时候就需要用到我们开头创建的service类型，那就是 NodePort service。

这种类型的Service的工作原理也不难，其实 就是将 service的端口映射到 Node 的一个端口上，然后通过 NodeIp+NodePort进行访问

我们通过以上资源清单创建service，然后访问：

可以看出是可以访问的，可以在浏览器试试看：

4. LoadBalancer

LoadBalancer 听名字就知道跟负载均衡有关。这个类型与 NodePort 很相似，目的都是向外部暴露一个端口，主要的区别在于 LoadBalancer 会在集群的外部再做一个负载均衡器，而这个设备是需要外部环境支持的，外部环境发送到这个设备的请求，会被设备负载之后转发到集群中。

图中有个Vip的概念，这里的Vip指的是 Vitual IP，也就是虚拟IP，外部用户通过访问这个虚拟IP，可以负载到我们不同的service上，达到负载均衡和高可用的特点

5. ExternalName

ExternalName 类型的service 是用于引入集群外部的服务，它通过 externalName 属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部服务了。

二、Ingress

1）工作模式

上面已经讲完了 Service几种类型的用法，已经知晓了想让外部用户访问到我们pod中的服务有两种类型的service是支持的，分别是：NodePort和LoadBalancer，但是其实认真分析一下，我们不难发现这两种service 的缺点:

• NodePort：会占用集群机器的很多端口，当集群服务变多的时候，这个缺点就越发明显
• LoadBalancer：每个Service都需要一个LB，比较麻烦和浪费资源，并且需要 k8s之外的负载均衡设备支持

这种缺点当然不只是我们能够发现，作为k8s的启动者早已意识到了，紧接着便推出了 Ingress 的概念。Ingress 仅需要一个 NodePort或 LB 就可以满足暴露多个Service的需求：

实际上，Ingress就相当于一个7层的负载均衡器，是 K8s 对反向代理的一个抽象，它的工作原理类似于 Nginx，可以理解成在 Ingress 里 建立诸多的隐射规则，然后 Ingress Controller通过监听这些配置规则转化成 Nginx 的反向代理配置，然后对外提供该服务。这边涉及到了两个重要的概念：

• Ingress：K8s 中的一个资源对象，作用是定义请求如何转发到 service 的规则
• Ingress Controller：具体实现反向代理及负载均衡的程序，对Ingress定义的规则进行解析，根据配置的规则来实现请求转发，有很多种实现方式，如 Nginx、Contor、Haproxy等

Ingress 控制器 有很多中可以实现请求转发的方式，我们通常上也会选择我们比较熟悉的 Nginx 作为负载，接下来我们就以 Nginx 为例，我们先来了解一下其工作原理：

1. 用户编写 Ingress Service规则， 说明每个域名对应 K8s集群中的哪个Service
2. Ingress控制器会动态感知到 Ingress 服务规则的变化，然后生成一段对应的Nginx反向代理配置
3. Ingress控制器会将生成的Nginx配置写入到一个运行中的Nginx服务中，并动态更新
4. 然后客户端通过访问域名，实际上Nginx会将请求转发到具体的Pod中，到此就完成了整个请求的过程