Kubernetes服务发布基础

Service用于为一组提供服务的Pod抽象一个稳定的网络访问地址，是k8s实现微服务的核心概念。通过Service的定义设置的访问地址是DNS域名格式的服务名称，对于客户端应用来说，网络访问方式并没有改变。Service还提供了负载均衡器的功能，将客户端请求负载分发到后端提供具体服务的各个Pod上。

Service主要用于提供网络服务，通过Service的定义，能够为客户端应用提供稳定的访问地址（域名或IP地址）和负载均衡功能，以及屏蔽后端EndPoint的变化，是Kubernetes实现微服务的核心资源。

总之，service是kubernetes中一个非常重要的概念，service用于将外部请求代理到内部pod上，提供4层负载均衡和服务发现的功能，使得我们可以构建高可用和可扩展的应用程序。

二：Service工作原理

1：service基本原理介绍

在kubernetes中，pod的IP地址是动态变化的，因此无法直接通过pod的IP地址进行访问。service的出现正式为了解决这个问题的。service会为一组pod创建一个虚拟的IP地址，通过这个IP地址可以访问这组pod中的任意一个pod。当客户端请求这个虚拟IP地址时，请求会被负载均衡到一组pod中的某一个pod上，从而完成对pod的访问。

service的实现依赖于kube-proxy组件。kube-proxy会在每个节点上监听service的变化，一旦有service发生变化，kube-proxy会更新本地的iptables规则，从而实现流量的转发和负载均衡。

另外，service还与CoreDNS有关。CoreDNS是kubernetes集群中的DNS解析服务。在kubernetes中service的虚拟IP地址还会注册到CoreDNS中，从而使得客户端还可以通过service名称访问service的虚拟IP地址。在service的定义中，可以通过spec.selector字段指定哪些pod属于这个service，这样，就可以将请求负载均衡到这些pod中。

总之，service是kubernetes中一种非常重要的资源对象，它可以让pod对外提供服务，并提供负载均衡、服务发现等功能。service的实现依赖于kube-proxy和CoreDNS组件，他们共同协作，将service与pod连接起来，实现对pod的代理访问，如下图所示。

2：Service的负载均衡机制

当一个Service对象在Kubernetes集群中被定义出来时，集群内的客户端应用就可以通过服务IP访问到具体的Pod容器提供的服务了。从服务IP到后端Pod的负载均衡机制，则是由每个node上的kube - proxy代理来负责实现的。

kube - proxy的代理模式有：userspace、iptables、ipvs和kernelspace。

(1) userspace

起初，kube - proxy进程是一个真实的TCP/UDP代理，当某个pod以clusterIP方式访问某个service的时候，这个流量会被pod所在的本机的iptables转发到本机的kube - proxy进程，然后将请求转发到后端某个pod上。具体过程为：

kube - proxy为每个service在node上打开一个随机端口作为代理端口
建立iptables规则，将clusterip的请求重定向到代理端口（用户空间）
到达代理端口的请求再由kube - proxy转发到后端

clusterip重定向到kube - proxy服务的过程存在内核态到用户态的切换，开销很大，因此有了iptables模式，而userspace模式也被废弃了。

(2) iptables

kubernetes从1.2版本开始将iptables模式作为默认模式，这种模式下kube - proxy不再起到proxy的作用。其核心功能：通过API Server的Watch接口实时跟踪Service和Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量通过iptables的NAT机制"直接路由"到目标Pod。

不同于userspace，在iptables的模式中，kube - proxy不再负责转发数据包，kube - proxy主要完成对iptables策略的动态管理。数据包的走向完全由iptables规则决定，这样的过程不存在内核态到用户态的切换，效率明显会高很多。但是随着service的增加，iptables规则会不断增加，导致内核十分繁忙（等于在读一张很大的没建索引的表）。

(3) ipvs

从kubernetes 1.8版本开始引入第三代的IPVS模式，它也是基于netfilter实现的，但定位不同：iptables是为防火墙设计的，IPVS则专门用于高性能负载均衡，并使用高效的数据结构Hash表，允许几乎无限的规模扩张。

ipvs为负载均衡提供了更多的算法：

算法	含义
rr	轮训
lc	最小连接数
df	目标哈希
sh	源哈希
sed	预计延迟最短
nq	从不排队

一句话说明：ipvs使用ipset存储iptables规则，在查找时类似hash表查找，时间复杂度为O(1)，而iptables时间复杂度则为O(n)。时间复杂度用字母O表示。

可以将ipset简单理解为ip集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个可变集合进行操作，这样做的好处可以大大减少iptables规则的数量，从而减少性能损耗。

如果操作系统没有启用IPVS内核模块，kube - proxy会自动运行为iptables模式，如果操作系统启用了ipvs模块，则kube - proxy会运行为ipvs模式。查看系统是否开启了ipvs模块，可以使用命令：lsmod | grep ip_vs

(4) kernelspace

Windows Server上的代理模式，此处不作介绍。

3: service的4种类型

kubernetes支持4种service类型。

(1) ClusterIP

这是最常用的Service类型，它为Pod提供了一个虚拟的IP地址。当其他Pod需要访问该Service时，它们只需要使用该虚拟IP地址即可。Kubernetes会自动将请求路由到相应的Pod上

(2) NodePort

这种Service类型将Pod公开为集群中所有节点上的某个端口。当外部请求到达任何一个节点上的该端口时，Kubernetes会将请求路由到相应的Pod上。

(3) LoadBalancer

LoadBalancer Service：这种Service类型使用云提供商的负载均衡器将请求路由到后端Pod。Kubernetes会自动创建和配置负载均衡器，并将其绑定到Service上。

(4) externalName

ExternalName Service：这种Service类型允许你将Service映射到集群外部的某个名称。当Pod需要访问该Service时，它们将使用该名称来解析出相应的IP地址。

三：生成用于测试service的Deployment

编写 Deployment，用于各种 service 的验证。

在应用 Service 概念之前，先创建一个提供 web 服务的 Pod 集合，有两个 Tomcat 容器副本组成每个容器提供的服务端口都为 8080.

1.编辑deployment

selector(选择器)主要用于资源的匹配，只有符合条件的资源才会被调用或使用，可以使用该方式对集群中的各类资源进行分配。Kubernetes 和核心资源 Deployment、statefulset 管理的 Pod 是通过选择器字段决定的，通过 Service 访问这些后端 Pod 也是通过选择器字段决定的。label(标签)可以对 Kubernetes 的其他资源进行配置，当 Kubernetes 对系统的任何 API 对象如Pod 进行分组时，会对其添加标签，用以精准的选择对应的API对象。

创建该deployment