今天我们来了解下K8S上的Service资源的相关话题，这是容器化体系的第1篇，基本的概念、基础理论不在本章描述。
众所周知，云原生现在越来越流行，已成为云计算发展的必然趋势，在云原生的4大核心领域中，容器化也必然成为不可或缺的一项伟大工程。
基于Google 2014年创建管理，其多年大规模容器管理技术Borg的开源版本的Kubernetes，可以在物理或虚拟机的上运行容器化应用，能提供一个以“容器为中心的基础架构”，满足在生产环境中运行应用的一些常见需求。
Service资源在编排系统K8S上主要用来解决Pod的访问问题。我们知道在K8S上Pod由于各种原因需要进行重建，此时，重建后的Pod的Ip地址和名称均已发生变更，这样一来使得应用服务访问Pod时就变得有些不便。为了解决Pod访问能有一个固定的端点，在K8S平台上，我们就借用Service资源进行解决。
简单来讲，Service对象就是工作在节点上的一组Iptables 或 Ipvs规则，用于将到达Service对象Ip地址的流量调度转发至相应Endpoint对象指向的Ip地址 和 端口之上。工作于每个节点的Kube-Proxy组件通过ApiServer持续监控着各Service及其关联的Pod对象，并将其创建或变动实时反映至当前工作节点上相应的Iptables 或 Ipvs规则。其实Service和Pod或其他资源的关联，本质上不是直接关联，它依靠一个中间组件Endpoint，Endpoint主要作用就是引用后端Pod或其他资源（比如K8S外部的服务也可以被Endpoint引用），所谓Endpoint就是Ip地址 + 端口。
如上图所示：在K8S平台上，Kube-Proxy会不断监视着ApiServer上的Service资源变动情况，及时将变动转化为本机的Iptables 或 Ipvs规则，对应客户端Pod访问对应Server Pod，报文首先会从本机的Iptables 或 Ipvs规则所匹配，然后再由对应规则逻辑把请求调度到对应的Pod上。
Service代理模式
截止目前，在K8S平台上Service代理模式主要包含以下三种：
1、userspace
早期的K8S平台版本（在version 1.1及之前的版本）所采用的默认代理模式。在 Kubernetes v1.1 版本，新增了 Iptables 代理，但并不是默认的运行模式。
2、iptables
从 Kubernetes v1.2 起，默认就是 Iptables 代理。在 Kubernetes v1.8.0-beta.0 中，添加了 Ipvs 代理。
3、ipvs
后面的版本（即 version 1.11开始及以后版本）默认代理模式为如果对应ipvs的模块没有加载，它会自动降级为Iptables 。在 Kubernetes 1.14 版本开始默认使用 Ipvs 代理。
此种模式，Kube-Proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建 Ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 Ipvs 规则，以确保 Ipvs 状态与期望一 致。访问服务时，流量将被重定向到其中一个后端 Pod。
与 Iptables 类似，Ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意 味着 Ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，Ipvs 为负载均衡算法提供了更多选项。
Service类型
截止目前，在K8S平台上Service类型主要包含以下四种：
1、Cluster IP，即 我们在创建Service资源时，如果不指定其type类型的话，默认为此种类型
2、NodePort
3、Load Balancer
4、ExternalName
不同类型的service，其功能和作用也有所不同。在 Kubernetes v1.0 版本， Service 是 “4层”（TCP/UDP over IP）概念。在 Kubernetes v1.1 版本，新增了 Ingress API（beta 版），用来表示 “7层”（HTTP）服务。