Kubernetes服务发现之Service详解

时间  2019-11-20 标签 kubernetes 服务 发现 service 详解

1、引子

Kubernetes Pod 是有生命周期的，它们能够被建立，也能够被销毁，而后一旦被销毁生命就永远结束。经过ReplicationController 可以动态地建立和销毁Pod（列如，须要进行扩缩容，或者执行滚动升级）；每一个Pod都会获取它本身的IP地址，即便这些IP地址不老是稳定可依赖的。这会致使一个问题；在Kubernetes集群中，若是一组Pod（称为backend）为其余Pod（称为frontend）提供服务，那么哪些frontend该如何发现，并链接到这组Pod中的那些backend呢？node

关于Serviceredis

Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种能够访问它们不一样的策略--一般称为微服务。这一组Pod可以被Service访问到，一般是经过Label Sekector实现的；算法

举个例子，考虑一个图片处理backend，它运行了3个副本。这些副本是可交换的 -- frontend不须要关心它们调用了哪一个backend副本。而后组成这一组backend程序的Pod实际上可能会发生变化，frontend客户端不该该也不必知道，并且也不须要跟踪这一组backend的状态。Service定义的抽象可以解耦这种关联。数据库

对Kubernetes集群中的应用，Kubernetes提供了简单的Endpoints API，只要service中的一组Pod发生变动，应用程序就会被更新。对非Kubernetes集群中的应用，Kubernetes提供了基本VIP的网桥的方式访问Service，再由Service重定向到backend Pod。后端

2、定义Service

一个Service在Kubernetes中是一个REST对象，和Pod相似。像全部的REST对象同样，Service定义能够基于POST方式，请求apiserver建立新的实例。例如，假定有一组Pod，它们对外暴漏了9376端口，同时还被打上“app=MyApp”标签。api

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

上述配置将建立一个名称为“my-service”的Service对象，它会将请求代理到使用TCP端口9376，而且具备标签“app=MyApp”的pod上。这个Service将被指派一个IP地址（一般为“Cluster IP”）它会被服务的代理使用。该Service的selector将会持续评估，处理结果将被POST到一个名称为"my-service"的Endpoints对象上。缓存

须要注意的是，Servie可以将一个接收端口映射到任意的targetPort。默认状况下，targetPort将被设置为与port字段相同的值。可能更有趣的是，targetPort能够是一个字符串，引用了backend Pod的一个端口的名称；可是，实际指派给该端口名称的端口号，在每一个backend Pod中可能并不相同。对于部署和设计Service，这种方式会提供更大的灵活性。例如，能够在backend软件下一个版本中，修改Pod暴露的端口，并不会中断客户端的调用。服务器

Kubernetes service可以支持TCP和UDP协议，默认TCP协议网络

3、没有selector的Service

Service抽象了该如何访问Kubernetes Pod，但也能抽象其余类型的backend，例如：session

  • 但愿在生产环境中使用外部的数据库集群，但测试环境使用本身的数据库。
  • 但愿服务指向另外一个Namespace中或其余集群中的服务。
  • 正在将工做负载转移到Kubernetes集群，和运行在Kubernetes集群以外的backend。

在任何这些场景中，都可以定义没有selector 的 Service ：

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

因为这个Service没有selector，就不会建立相关的Endpoints对象。能够手动将Service映射到指定的Endpoints：

kind: Endpoints
apiVersion: v1
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 1.2.3.4
    ports:
      - port: 9376

注意：Endpoint IP地址不能loopback（127.0.0.0/8），link-local(169.254.0.0/16),或者link-local多播（224.0.0.0/24）。

访问没有selector的Service，与selector的Service的原理相同。请求被路由到用户定义的Endpoint（该示例中为1.2.3.4:9376）

ExternalName service是Service的特别，它没有selector，也没有定义任何的端口和Endpoint。相反地，对于运行在集群外部的服务，它经过返回该外部服务的别名这种方式来提供服务。

kind: Service
apiVersion: v1
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

当查询主机 my-service.prod.svc.CLUSTER时，集群的DNS服务将返回一个值为my.database.example.com的CNAME记录，访问这个服务的功能方式与其余的相同，惟一不一样的是重定向发生的DNS层，并且不会进行代理或转发。若是后续决定要将数据库迁移到Kubetnetes中，能够启动对应的Pod，增长合适的Selector或Endpoint，修改service的typt。

4、VIP和Service代理

在Kubernetes集群中，每一个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP（虚拟IP）的形式，而不是ExternalName的形式。在Kubernetes v1.0版本，代理彻底在userspace。在Kubernetes v1.1版本，新增了iptables代理，但并非默认的运行模式。从Kubernetes v1.2起，默认就是iptables代理。

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

5、userspace代理模式

这种模式，kube-proxy会监视Kubernetes master对service对象和Endpoints对象的添加和移除。对每一个Service，它会在本地Node上打开一个端口（随机选择）。任何链接到“代理端口”的请求，都会被代理到Service的backend Pods中的某一个上面（如 Endpoints 所报告的同样）。使用哪一个backend Pod，是基于Service的SessionAffinity来肯定的。最后，它安装iptables规则，捕获到达该Service的clusterIP（是虚拟IP）和Port的请求，并重定向到代理端口，代理端口再代理请求到backend Pod。

网络返回的结果是，任何到达Service的IP：Port的请求，都会被代理到一个合适的backend，不须要客户端知道关于Kubernetes，service或pod的任何信息。

默认的策略是，经过round-robin算法来选择backend Pod。实现基于客户端IP的会话亲和性，能够经过设置service.spec.sessionAffinity的值为“ClientIP”（默认值为“None”）；

6、iptables代理模式

这种模式，kube-proxy会监视Kubernetes master对象和Endpoinnts对象的添加和移除。对每一个Service，它会安装iptables规则，从而捕获到达该Service的clusterIP（虚拟IP）和端口的请求，进而将请求重定向到Service的一组backend中某个上面。对于每一个Endpoints对象，它也会安装iptables规则，这个规则会选择一个backend Pod。

默认的策略是，随机选择一个backend。实现基于客户端IP的会话亲和性，能够将service.spec.sessionAffinity的值设置为“ClientIP”（默认值为“None”）

和userspace代理相似，网络返回的结果是，任何到达Service的IP：Port的请求，都会被代理到一个合适的backend，不须要客户端知道关于Kubernetes，service或Pod的任何信息。这应该比userspace代理更快，更可靠。然而，不想userspace代理，若是始出选择的Pod没有响应，iptables代理不能自动地重试另外一个Pod，因此它须要依赖readiness probes；

https://jimmysong.io/kubernetes-handbook/images/services-iptables-overview.jpg

7、ipvs代理模式

这种模式，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代理模式。

8、多端口Service

不少Service须要暴露多个端口。对于这种状况，Kubernetes 支持在Service对象中定义多个端口。当使用多个端口时，必须给出全部端口的名称，这样Endpoint就不会产生歧义，例如：

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
    selector:
      app: MyApp
    ports:
      - name: http
        protocol: TCP
        port: 80
        targetPort: 9376
      - name: https
        protocol: TCP
        port: 443
        targetPort: 9377

9、选择本身的IP地址

在Service建立的请求中，能够经过设置spec.cluster IP字段来指定本身的集群IP地址。好比，但愿替换一个已经存在的DNS条目，或者遗留系统已经配置了一个固定IP且很难从新配置。用户选择的IP地址必须合法，而且这个IP地址在service-cluster-ip-range CIDR 范围内，这对 API Server 来讲是经过一个标识来指定的。 若是 IP 地址不合法，API Server 会返回 HTTP 状态码 422，表示值不合法。

10、为什么不使用round-robin DNS？

一个不时出现的问题是，为何咱们都使用VIP的方式，而不使用标准的round-robin DNS，有以下几个缘由：

  • 长久以来，DNS 库都没能认真对待 DNS TTL、缓存域名查询结果
  • 不少应用只查询一次 DNS 并缓存告终果
  • 就算应用和库可以正确查询解析，每一个客户端反复重解析形成的负载也是很是难以管理的

咱们尽力阻止用户作那些对他们没有好处的事情，若是不少人都来问这个问题，咱们可能会选择实现它。

11、服务发现

Kubernetes 支持2种基本的服务发现模式 —— 环境变量和 DNS。

12、环境变量

当Pod运行在NOde上，kubelet会为每一个活跃的Service添加一组环境变量。它同时支持Docker links兼容变量，简单的{SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 变量，这里 Service 的名称需大写，横线被转换成下划线。

举个例子，一个名称为 "redis-master" 的 Service 暴露了 TCP 端口 6379，同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了以下环境变量：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

这意味着须要有顺序的要求 —— Pod 想要访问的任何 Service 必须在 Pod 本身以前被建立，不然这些环境变量就不会被赋值。DNS 并无这个限制。

十3、DNS

一个可选（尽管强烈推荐）集群插件 是 DNS 服务器。 DNS 服务器监视着建立新 Service 的 Kubernetes API，从而为每个 Service 建立一组 DNS 记录。 若是整个集群的 DNS 一直被启用，那么全部的 Pod 应该可以自动对 Service 进行名称解析。

例如，有一个名称为 "my-service" 的 Service，它在 Kubernetes 集群中名为 "my-ns" 的 Namespace 中，为 "my-service.my-ns" 建立了一条 DNS 记录。 在名称为 "my-ns" 的 Namespace 中的 Pod 应该可以简单地经过名称查询找到 "my-service"。 在另外一个 Namespace 中的 Pod 必须限定名称为 "my-service.my-ns"。 这些名称查询的结果是 Cluster IP。

Kubernetes 也支持对端口名称的 DNS SRV（Service）记录。 若是名称为 "my-service.my-ns" 的 Service 有一个名为 "http" 的 TCP 端口，能够对 "_http._tcp.my-service.my-ns" 执行 DNS SRV 查询，获得 "http" 的端口号。

Kubernetes DNS 服务器是惟一的一种可以访问 ExternalName 类型的 Service 的方式。 更多信息能够查看 DNS Pod 和 Service。

十4、发布服务 —— 服务类型

对一些应用（如 Frontend）的某些部分，可能但愿经过外部（Kubernetes 集群外部）IP 地址暴露 Service。

Kubernetes ServiceTypes 容许指定一个须要的类型的 Service，默认是 ClusterIP 类型。

Type 的取值以及行为以下：

  • ClusterIP：经过集群的内部 IP 暴露服务，选择该值，服务只可以在集群内部能够访问，这也是默认的 ServiceType。
  • NodePort：经过每一个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动建立。经过请求 : ，能够从集群的外部访问一个 NodePort 服务。
  • LoadBalancer：使用云提供商的负载均衡器，能够向外部暴露服务。外部的负载均衡器能够路由到 NodePort 服务和 ClusterIP 服务。
  • ExternalName：经过返回 CNAME 和它的值，能够将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。 没有任何类型代理被建立，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

十5、NodePort 类型

若是设置 type 的值为 "NodePort"，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每一个 Node 将从该端口（每一个 Node 上的同一端口）代理到 Service。该端口将经过 Service 的 spec.ports[*].nodePort 字段被指定。

若是须要指定的端口号，能够配置 nodePort 的值，系统将分配这个端口，不然调用 API 将会失败（好比，须要关心端口冲突的可能性）。

这可让开发人员自由地安装他们本身的负载均衡器，并配置 Kubernetes 不能彻底支持的环境参数，或者直接暴露一个或多个 Node 的 IP 地址。

须要注意的是，Service 将可以经过 :spec.ports[*].nodePort 和 spec.clusterIp:spec.ports[*].port 而对外可见。

十6、LoadBalancer 类型

使用支持外部负载均衡器的云提供商的服务，设置 type 的值为 "LoadBalancer"，将为 Service 提供负载均衡器。 负载均衡器是异步建立的，关于被提供的负载均衡器的信息将会经过 Service 的 status.loadBalancer 字段被发布出去。

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30061
  clusterIP: 10.0.171.239
  loadBalancerIP: 78.11.24.19
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
      - ip: 146.148.47.155

来自外部负载均衡器的流量将直接打到 backend Pod 上，不过实际它们是如何工做的，这要依赖于云提供商。 在这些状况下，将根据用户设置的 loadBalancerIP 来建立负载均衡器。 某些云提供商容许设置 loadBalancerIP。若是没有设置 loadBalancerIP，将会给负载均衡器指派一个临时 IP。 若是设置了 loadBalancerIP，但云提供商并不支持这种特性，那么设置的 loadBalancerIP 值将会被忽略掉。

联系我们 沪ICP备13005482号-10