k8s 我们已经从 NaMespace、Pod、PodContRolleR到VoluMn都介绍过了，相信看完的小伙伴们也会很有收获的~那么今天我们继续来到k8s的课堂，这节我们将要来说下 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。
然后我们输入 IPvsadM -Ln命令即可看到 IPvs规则策略：
10.108.230.12 是 seRvice 提供的访问入口，当访问这个入口的时候，可以发现后面有三个 pod 的服务在等待调用，kube-Proxy 会基于 RR(轮询)的策略，将请求分发到其中一个pod上去，这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以!
此模式必须安装 IPvs 内核模块，否则会降低为 IPtables
开启 IPvs：
kubectl edIT cM kube-Proxy -n kube-system
编辑后保存(:wq) 退出
kubectl delete pod -l k8s-app=kube-Proxy -n kube-sYsteM IPvsadM -Ln
2)SeRvice 使用
上面已经介绍完了 SeRvice 的几种工作模式。下面我们进入SeRvice 的使用阶段。我们上面已经做了简单的实践，创建了一个 Deploy ，一个 SeRvice ，然后我们可以通过 seRviceIP + taRgetPoRt 或 nodeIP + nodePoRt访问资源
但是在学习 SeRvice 的使用，仅仅这个是不够的，SeRvice又分为5种类型，下面将一一介绍。
1. ClUSteRIP
我们先看下 ClUSteRIP 类型的SeRvice的资源清单：
通过创建后测试访问 clUSteRIP + poRt
我们再查看下 IPvs 规则，可以看到该seRvice已经可以转发到对应的3个pod上
接下来我们可以通过 descRibe 指令查看该seRvice有哪些信息：
扫了一遍发现 Endpoints 和 SeSSion AFFinITy 都是我们之间没有见过的。那这个又是个什么东西呢?
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
之前我们用 IPvsadM -Ln 命令查看分发策略的时候，里面有个 RR 字段不知道你有没有注意到，没错，这个 RR 值得就是轮询的意思
如果我们想要开启会话保持的分发策略，那么只需要在spec中添加 seSSionAFFinITy:clientIP 选项
再次通过 IPvsadM -Ln 命令查看分发策略就可以发现结果已经发生变化了
我们简单测试一下：
这样子就已经实现了会话保持的分发策略!
注意：ClUSteRIP 的 SeRvice，不支持外部访问，也就是说通过浏览器访问是不生效的，只能在集群内部访问
2. HeadLineSS
很多服务都需要支持定制化，如果将产品定位为服务，那么这个产品毋庸是成功。在某些场景中，开发人员并不想要使用 seRvice 提供的负载均衡功能，而是希望自己来控制负载均衡策略。针对这种情况的发生，k8s也是很好的支持了，引入了 HeadLineSS SeRvice，这类 SeRvice 不会分配 ClUSteRIP，如果想要访问 seRvice，只能通过 SeRvice 域名进行查询。
我们来看下 HeadLineSS 的资源清单模板：
