10.Service资源发现

Kubernetes Pods是不可控的。每当一个pod停止后，他不是重启，而是重建。ReplicaSets特别是Pods动态地创建和销毁（例如，当向外扩展或向内扩展时）。虽然每个PodIP地址都有自己的IP地址，但即使这些IP地址也不能依赖它们保持稳定。这会导致一个问题：如果某些Pods（让我们称之为后端）Pods在Kubernetes集群内向其他人（让我们称之为前端）提供功能，那些前端如何找出并跟踪该集合中的哪些后端？

依靠Service

Kubernetes Service是一个抽象，它定义了一个逻辑集Pods 和一个访问它们的策略 - 有时称为微服务。Podsa 的目标集合Service（通常）由标签选择器选中的一组Pod。

例如，考虑一个运行3个副本的图像处理后端。那些复制品是可替代的 - 前端并不关心它们使用哪个后端。虽然Pods组成后端集的实际情况可能会发生变化，但前端客户端不应该知道这一点，也不需要跟踪后端列表本身。该Service抽象可实现这种分离。

对于Kubernetes本地应用程序，Kubernetes提供了一个简单的Endpoints被更新的API，每当一组Pods中Service的变化。对于非本机应用程序，Kubernetes提供了一个基于虚拟IP的桥接服务，可以重定向到后端Pods。

定义服务

Service在Kubernetes是一个REST对象，类似于Pod。与所有REST对象一样，Service可以将定义POST到apiserver以创建新实例。例如，假设您有一组Pods每个公开端口9376并带有标签"app=MyApp"。

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

此规范将创建一个Service名为“my-service” 的新对象，该对象以任何Pod带有"app=MyApp"标签的TCP端口9376为目标。这Service 也将被分配一个IP地址（有时称为“ClusterIP”），由服务代理使用。本Service的选择将不断进行评估，其结果将被张贴到一个Endpoints还名为‘我的服务’的对象。

请注意，Service可以将传入端口映射到任何端口targetPort。默认情况下，targetPort将设置为与port字段相同的值。也许更有趣的是，它targetPort可以是一个字符串，指的是后端端口的名称Pods。分配给该名称的实际端口号在每个后端可以不同Pod。这为您的部署和发展提供了很大的灵活性Services。例如，您可以更改pod在下一版本的后端软件中公开的端口号，而不会破坏客户端。

注意： SCTP支持是自Kubernetes 1.12以来的alpha功能

没有选择器的服务

服务通常抽象访问Kubernetes Pods，但它们也可以抽象其他类型的后端。例如：

• 您希望在生产中拥有外部数据库集群，但在测试中您使用自己的数据库。
• 您希望将服务指向另一个Namespace或另一个群集上的服务 。
• 您正在将工作负载迁移到Kubernetes，并且您的一些后端在Kubernetes之外运行。

在任何这些场景中，您都可以定义不带选择器的服务：

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

由于此服务没有选择器，因此Endpoints不会创建相应的对象。您可以手动将服务映射到您自己的特定端点：

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

注意：端点IP可能不是环回（127.0.0.0/8），链路本地（169.254.0.0/16）或链路本地多播（224.0.0.0/24）。它们不能是其他Kubernetes服务的集群IP，因为该kube-proxy 组件尚不支持虚拟IP作为目标。

访问Service没有选择器的方法与具有选择器的方式相同。流量将路由到用户定义的端点（1.2.3.4:9376在此示例中）。

ExternalName服务是一种特殊情况的服务，它没有选择器而是使用DNS名称。有关详细信息，请参阅本文档后面的 ExternalName部分。

虚拟IP和服务代理

Kubernetes集群中的每个节点都运行一个kube-proxy。kube-proxy负责实现Services除以外类型的虚拟IP形式ExternalName。

在Kubernetes v1.0中，Services是一个“第4层”（TCP / UDP over IP）构造，代理纯粹在用户空间。在Kubernetes v1.1中，Ingress添加了API（beta）来表示“第7层”（HTTP）服务，也添加了iptables代理，并成为自Kubernetes v1.2以来的默认操作模式。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理。

代理模式：用户空间

在这种模式下，KUBE代理手表的添加和去除Kubernetes主Service和Endpoints对象。对于每个Service它，它在本地节点上打开一个端口（随机选择）。与此“代理端口”的任何连接都将代理到其中一个Service后端Pods（如报告中所述 Endpoints）。使用哪个后端Pod是基于 SessionAffinity的Service。最后，它安装的防火墙规则，其捕获流量的Service的clusterIP（这是虚拟的），并Port 和重定向的流量到代理服务器与后端的代理端口Pod。默认情况下，后端的选择是循环

代理模式：iptables

在这种模式下，KUBE代理手表的添加和去除Kubernetes主Service和Endpoints对象。对于每一个Service，它安装的防火墙规则，其捕获业务到Service的clusterIP（这是虚拟的）和Port与该通信重定向到的一个Service的后端集。对于每个Endpoints对象，它会安装选择后端的iptables规则Pod。默认情况下，后端的选择是随机的。

显然，iptables不需要在用户空间和内核空间之间切换，它应该比用户空间代理更快，更可靠。但是，与用户空间proxier不同，如果iptables proxier Pod最初选择的那个没有响应，则它不能自动重试另一个 ，因此它取决于具有工作就绪探测器

代理模式：ipvs

特征状态： Kubernetes v1.9 公测

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

与iptables类似，Ipvs基于netfilter钩子函数，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如：rr 轮询  lc 最少连接 nq 没有队列  sha 源哈希  dha目标哈希     sed（最少时间）

多端口服务

许多人Services需要暴露多个端口。对于这种情况，Kubernetes支持Service对象的多个端口定义。使用多个端口时，必须提供所有端口名称，以便可以消除端点的歧义。例如：

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

请注意，端口名称只能包含小写字母数字字符-，并且必须以字母数字字符开头和结尾。123-abc并且web是有效的，但123_abc并-web不能有效名称。

 

发现服务

两种方式一个实在pod的镜像模板中指出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

另一种是采用DNS解析方式

Serviename+namespace+集群默认域  通常为 svc.cluster.local.

发布服务 - 服务类型

对于应用程序的某些部分（例如前端），您可能希望将服务公开到外部（群集外部）IP地址。

Kubernetes ServiceTypes允许您指定所需的服务类型。默认是ClusterIP。

Type 价值观及其行为是：

• ClusterIP：在集群内部IP上公开服务。选择此值使服务只能从群集中访问。这是默认值ServiceType。
• NodePort：在静态端口（NodePort）上公开每个节点IP上的服务。一个ClusterIP服务，该NodePort服务将路由，自动创建。您可以NodePort通过请求从群集外部联系服务<NodeIP>:<NodePort>。
• LoadBalancer：使用云提供商的负载均衡器在外部公开服务。NodePort和ClusterIP服务，其外部负载平衡器将路线，自动创建。
• ExternalName：通过返回包含其值的记录，将服务映射到externalName字段的内容 （例如foo.bar.example.com）CNAME。没有设置任何类型的代理。这需要1.7或更高版本kube-dns