service-k8s

Service

Kubernetes Pod 是有⽣命周期的，它们可以被创建，也可以被销毁，然⽽⼀旦被销毁⽣命就永远结束。 通过
ReplicationController 能够动态地创建和销毁 Pod 。 每个 Pod 都会获取它⾃⼰的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。 这会导致⼀个问题：在 Kubernetes 集群中，如果⼀组 Pod （称为 backend）为其它 Pod （称为
frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 Pod 中的哪些 backend 呢

Kubernetes Service 定义了这样⼀种抽象：⼀个 Pod 的逻辑分组，⼀种可以访问它们的策略 —— 通常称为微服务。
这⼀组 Pod 能够被 Service 访问到，通常是通过 Label Selector （查看下⾯了解，为什么可能需要没有 selector 的
Service ）实现的

Kubernetes 提供了简单的 Endpoints API，只要 Service 中的⼀组 Pod 发⽣变更，应⽤程序就会被更新。 对⾮ Kubernetes 集群中的应⽤，Kubernetes 提供了基于 VIP 的⽹桥的⽅式访问 Service ，再由Service 重定向到 backend Pod

三种ip

• Node IP：Node节点的IP地址
• Pod IP: Pod的IP地址
• Cluster IP: Service的IP地址

Node IP是Kubernetes集群中节点的物理网卡IP地址(一般为内网)，所有属于这个网络的服务器之间都可以直接通信，所以Kubernetes集群外要想访问Kubernetes集群内部的某个节点或者服务，肯定得通过Node IP进行通信

Pod IP是每个Pod的IP地址，它是Docker Engine根据docker0网桥的IP地址段进行分配的

Cluster IP是一个虚拟的IP，仅仅作用于Kubernetes Service这个对象，由Kubernetes自己来进行管理和分配地址，当然我们也无法ping这个地址，他没有一个真正的实体对象来响应，他只能结合Service Port来组成一个可以通信的服务。

定义 Service

⼀个 Service 在 Kubernetes 中是⼀个 REST 对象，和 Pod 类似。 像所有的 REST 对象⼀样， Service 定义可以基
于 POST ⽅式，请求 apiserver 创建新的实例。 例如，假定有⼀组 Pod ，它们对外暴露了 9376 端⼝，同时还被打上
"app=MyApp" 标签

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376    #pod端口
     
     kubectl create -f myservice.yaml
     
将创建⼀个名称为 “my-service” 的 Service 对象，它会将请求代理到使⽤ TCP 端⼝ 9376，并且具有标签
"app=MyApp" 的 Pod 上。 这个 Service 将被指派⼀个 IP 地址（通常称为 “Cluster IP”），它会被服务的代理使⽤（⻅下⾯）。 该 Service 的 selector 将会持续评估，处理结果将被 POST 到⼀个名称为 “my-service” 的 Endpoints 对象上
Service 能够将⼀个接收端⼝映射到任意的 targetPort 。 默认情况下， targetPort 将被设置为与
port 字段相同的值。 可能更有趣的是， targetPort 可以是⼀个字符串，引⽤了 backend Pod 的⼀个端⼝的名称。 但
是，实际指派给该端⼝名称的端⼝号，在每个 backend Pod 中可能并不相同。 对于部署和设计 Service ，这种⽅式会
提供更⼤的灵活性。 例如，可以在 backend 软件下⼀个版本中，修改 Pod 暴露的端⼝，并不会中断客户端的调⽤。
Kubernetes Service 能够⽀持 TCP 和 UDP 协议，默认 TCP 协议。

没有 selector 的 Service
Service 抽象了该如何访问 Kubernetes Pod ，但也能够抽象其它类型的 backend，例如：

• 希望在⽣产环境中使⽤外部的数据库集群，但测试环境使⽤⾃⼰的数据库。
• 希望服务指向另⼀个 Namespace 中或其它集群中的服务。
• 正在将⼯作负载转移到 Kubernetes 集群，和运⾏在 Kubernetes 集群之外的 backend。

kube-proxy

在Kubernetes集群中，每个Node会运行一个kube-proxy进程, 负责为Service实现一种 VIP（虚拟 IP，就是我们上面说的clusterIP）的代理形式，现在的Kubernetes中默认是使用的iptables这种模式来代理。这种模式，kube-proxy会监视Kubernetes master对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会添加上 iptables 规则，从而捕获到达该 Service 的 clusterIP（虚拟 IP）和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某一个个上面。 对于每个 Endpoints 对象，它也会安装 iptables 规则，这个规则会选择一个 backend Pod。

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

Service 类型

定义Service的时候可以指定一个自己需要的类型的Service，如果不指定的话默认是ClusterIP类型

可以使用的服务类型如下：

• 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 才支持。

NodePort 类型

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

需要注意的是，Service 将能够通过 :spec.ports[].nodePort 和 spec.clusterIp:spec.ports[].port 而对外可见

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    name: myapp-http
    
创建该服务
$ kubectl create -f service-demo.yaml
查看Service对象信息：
$ kubectl get svc

ExternalName

ExternalName 是 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.local （后面服务发现的时候我们会再深入讲解）时，集群的 DNS 服务将返回一个值为 my.database.example.com 的 CNAME 记录。 访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。 如果后续决定要将数据库迁移到 Kubernetes 集群中，可以启动对应的 Pod，增加合适的 Selector 或 Endpoint，修改 Service 的 type，完全不需要修改调用的代码