K8S之Service介绍

旧城等待， 2023-01-11 15:26 208阅读 0赞

## 一、Service定义 ##

Kubernetes Service定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略----通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Selector

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]  
Service能够提供负载均衡能力，但在使用时具有以下限制：

*  只提供四层负载均衡能力，而没有七层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上四层负载均衡是不支持的

### 1.1 Service的类型 ###

Service在Kubernetes中有以下四种类型

*  ClusterIP：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟IP
 *  NodePort：在 ClusterIP 基础上为Service在每台机器上绑定一个端口，这样可以通过 NodeIP：NodePort来访问服务
 *  LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到 NodeIP：NodePort
 *  ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用，没有任何类型代理被创建，这只有Kubernetes 1.7或更高版本的kube-dns才支持

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 1]

#### 1.1.1 ClusterIP ####

ClusterIP主要在每个node节点使用iptables（或ipvs），将发向ClusterIP对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应Pod的地址和端口，进而把数据转发给对应的Pod

**为了实现图上的功能，主要需要以下几个组件的协同工作：**

*  apiserver：用户通过kubectl命令向apiserver发送创建service（svc）的命令，apiserver接收到请求后将数据存储到etcd中
 *  kube-proxy：Kubernetes的每个节点中都有一个叫做kube-proxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中
 *  iptables：使用NAT等技术将VIP的流量转至endpoint中

#### 1.1.2 Headless Service ####

有时候不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定ClusterIP（spec.clusterIP）的值为“None”来创建 Headless Service。这类 Service 并不会分配 ClusterIP ，kube-proxy 不会处理他们，而且平台也不会为它们进行负载均衡和路由

#### 1.1.3 NodePort ####

NodePort的原理是在 node 上开了一个端口，将访问该端口的流量导入到kube-proxy，然后由kube-proxy进一步给到对应的Pod

#### 1.1.4 LoadBalancer ####

LoadBalancer和NodePort其实是同一种方式，区别在于LoadBalancer比NodePort多了一步，就是可以调用cloud provider去创建LB来向节点导流  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 2]

#### 1.1.5 ExternalName ####

这种类型的Service通过返回 CNAME（别名）和它的值，可以将服务映射到 externalName 字段的内容。ExternalName Service是Service的特例，它没有selector，也没有定义任何的端口和Endpoint。相反，对于运行在集群外部的服务，通过返回该外部服务的别名这种方式来为集群内部提供服务

**举例：**

kind:Service
    apiVersion:v1
    metadata:
      name:my-service-1
      namespace:default
    spec:
      type:ExternalName
      externalName:www.baidu.com

当查询主机my-service-1.default.svc.cluster.local（SVC\_NAME.NAMESPACE.svc.cluster.local）时，集群的DNS服务将返回一个值 www.baidu.com 的CNAME记录。访问这个服务的工作方式和其他Service是一样，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发

## 二、代理模式分类 ##

### 2.1 VIP（虚IP）和Service代理 ###

在Kubernetes集群中，**每个Node**运行**一个 “kube-proxy” 进程**。“kube-proxy” 负责为 “Service” 实现了一种VIP的形式，而不是 “ExternalName” 的形式。在Kubernetes v1.0版本，代理完全在userspace。在Kubernetes v1.1版本，新增了iptables代理，但并不是默认的运行模式。从Kubernetes v1.2起，默认就是iptables代理。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理

在Kubernetes 1.14版本开始默认使用ipvs代理

在Kubernetes v1.0版本，\*\* “Service”是4层（TCP/UDP over IP）\*\*概念。在Kubernetes v1.1版本，**新增了“Ingress”API（beta版本），用来表示7层（HTTP）服务**

**不使用round-robin DNS进行负载均衡的原因：**  
由于DNS存在缓存问题，多次访问都是同一个缓存地址，不能达到期望的负载均衡效果

### 2.2 代理模式分类 ###

#### 2.2.1 userspace代理模式 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 3]

#### 2.2.2 iptables代理模式 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 4]

#### 2.2.3 ipvs代理模式 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 5]

这种模式，kube-proxy会监视Kubernetes Service对象和Endpoints，调用netlink接口以相应地创建 ipvs 规则并定期与Kubernetes Service对象和Endpoints同步 ipvs 规则，以确保 ipvs 状态与期望一致，访问服务时，流量将被重定向到其中一个后端Pod

与iptables类似，ipvs 有 netfilter 的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如：

*  rr：轮询调度
 *  lc：最小连接数
 *  dh：目标哈希
 *  sh：源哈希
 *  sed：最短期望延迟
 *  nq：不排队调度

⚠️注意：ipvs模式假定在运行 kube-proxy 之前，在节点上都已经安装了 ipvs 内核模块。当 kube-proxy 以 ipvs 代理模式启动时，kube-proxy 将验证节点上是否安装了 ipvs 模块，如果未安装，则 kube-proxy 将回退到 iptables代理模式

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]: /images/20221119/e54cb0d6262a4a099ca7236ad10ad671.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210127111910512.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210127123915123.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210127111954735.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20210127112230164.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20210127112307691.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx,size_16,color_FFFFFF,t_70