k8s-Service和endpoint

一、Service

         Kubernetes Service是为了管理具有相同功能的⼀组Pod⽽定义的⼀种资源对象，Service具体的作⽤和场景如下：

        通过Pod的Label Selector访问Pod组。

        Service的IP保持不变(Headless Servcie除外，下⾯会单独讲)，保证了访问接⼝的稳定性，屏蔽了Pod的IP地址变化带来的影响，进⽽实现解耦合。虽然这样，还是建议使⽤ServiceName进⾏访问。

        Service通过kube-proxy借助iptables/ipvs提供负载均衡的能⼒，实现反向代理，将请求转发到合适的Pod上；

1.service的工作机制

service工作流程

1）master上的kube-apiserver会处理service的创建，以及Service与通过label匹配与Pod绑定⽽产⽣的endpoints对象，并将这些元数据内容存储到etcd中。

2）node上的kube-proxy通过实时监听kube-apiserver上service以及endpoints的变化情况来感知相关事件并更新本地的service和endpoint的映射关系；同时node上的kubedns/coredns服务也会同时将service的域名信息与IP的对应关系存储起来供dns解析之⽤。

3）kube-proxy将从apiserver获取到的service和endpoint的映射关系保存在本地的iptables/ipvs中供后续查询使⽤

4）client发起对服务的访问，⾸先kubedns/coredns将服务名称解析成⼀个虚拟IP（ClusterIP）

5）然后使⽤这个IP去iptables/ipvs中去找service和endpoint的映射关系

6） 找到映射关系后，通过iptables/ipvs的负载均衡算法（典型也是最简单的就是roundrobin算法）匹配到 ⼀个合适的Pod进⾏访问即可

        ps：service提供pod的负载均衡的能⼒，但是只提供4层负载均衡的能⼒，⽽没有7层功能，只能到ip层⾯

示例

上图就是⼀个service的详细信息，先对照上⾯的流程找⼀下对应关系：

        1）service和endpoint的映射关系：my-service（10.111.86.105）=> 10.244.1.33:80,10.244.2.29:80，这些数据会存储到iptables/ipvs中

       2） service的域名信息与IP的对应关系：my-service => 10.111.86.105,这些数据会存储到kubedns/coredns中

        3）负载均衡反向代理： 10.244.1.33:80,10.244.2.29:80 这两个Pod就是需要进⾏负载均衡以及反向代理的两个Pod,iptables/ipvs会根据⾃身的负载均衡算法来完成此过程

        4）整体的数据访问流程即 my-service => 10.111.86.105 => 10.244.1.33:80

2.service的几种类型

K8S中Service分为四类，分别是ClusterIP，NodePort，LoadBalancer以及ExternalName。下⾯⼀张图描述了他们之间的关系以及服务类型；

        其中绿⾊的代表从外向内的访问模式；蓝⾊的代表从内向外的访问模式，⻩⾊代表集群内部的访问模式。可以看到，除了ExternalName类型之外，其余三种类型都是逐层封装⽽来的

1）ClusterIP

        默认类型，⾃动分配⼀个仅可在内部访问的虚拟IP。应⽤⽅式：内部服务访问

        这是K8S默认的服务类型，只能在K8S中进⾏服务通信。在ClusterIP中，K8S会在Service创建完毕后提供⼀个内部IP作为ClusterIP，K8S内部服务可以通过ClusterIP或者ServiceName来访问该服务

创建ClusterIP类型的service

[root@k8s-master service ] # cat nginx-svc.yaml

apiVersion: v1

kind: Service

metadata:

  name: nginx-svc-clusterip

spec:

  type: ClusterIP        # 类型

  selector:

    app: nginx                 # 选择 app=nginx 标签的 pod

  ports:

     - protocol: TCP

       port: 80                 # service 对外提供的端⼝

       targetPort: 80         # 代理的容器的端⼝

       # clusterIP: 10.233.3.127 ## 可配可不配，不配的话系统会分配⼀个随机的 IP 并保持不变

测试ClusterIP

         进入集群内的容器中，使用curl访问另外的pod；

        curl   IP:端口号    或者是 curl  servicename:端口号

2）NodePort

        在ClusterIP的基础之上，为集群内的每台物理机绑定⼀个端⼝，外⽹通过 任意节点的物理机IP:端⼝ 来访问服务。应⽤⽅式：外服访问服务

        1）将上述yaml文件中的类型改为NodePort即可；

        2）测试NodePort：浏览器输入node节点IP:端口号即可

3）LoadBalancer

        在NodePort基础之上，提供外部负载均衡器与外⽹统⼀IP，此IP可以将请求转发到对应服务上。这个是各个云⼚商提供的服务。应⽤⽅式：外服访问服务

4）ExternalName

        引⼊集群外部的服务，可以在集群内部通过别名⽅式访问（通过serviceName.namespaceName.svc.cluster.local访问）

配置文件

[root@k8s-master service ] # cat nginx-externalName.yaml

apiVersion: v1

kind: Service

metadata:

    name: service-ext

spec:

    type: ExternalName

    externalName: baidu.com          # 引⼊外部服务

测试

        任意一个pod来访问服务，进入容器内

5）Headless Service

示例

apiVersion: v1

kind: Service

metadata:

    name: service-headless

spec:

    # type: NodePort

    ports:

        - port: 3000

          protocol: TCP

          targetPort: 80

        # nodePort: 30080

    clusterIP: None

    selector:

        app: nginx

        headless service⼀般结合StatefulSet控制器来部署有状态的应⽤，⽐如⼤数据组件或者nosql数据库等，这种分布式的系统需要headless service来获取所有节点ip的列表供业务场景使⽤

         Service作为外部系统与K8S解耦合的关键组件，对外能够简化外系统调⽤K8S服务的复杂度，屏蔽K8S内部的实现细节；对内提供K8S内部的复杂均衡以及反向代理；

二、endpoint

        endpoint是k8s集群中的⼀个资源对象，存储在etcd中，⽤来记录⼀个service对应的所有pod的访问地址；

        service配置selector，endpoint controller才会⾃动创建对应的endpoint对象；否则，不会⽣成

endpoint对象

         例如，k8s集群中创建⼀个名为nginx-svc的service，就会⽣成⼀个同名的endpoint对象， ENDPOINTS就是service关联的pod的ip地址和端⼝