Kubernetes中的Service种类

Service的概念

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

Service能够提供负载均衡能力，但是在使用上有以下限制：

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

Service的类型

Service的四种类型：

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

VIP和Service代理

  在Kubernetes集群中，每个Node运行一个kube-proxy进程。kube-proxy 负载Service 实现了一种VIP（虚拟IP）的形式，而不是ExternalName 的形式，在Kubernetes v1.0版本，代理完全是userspace。v1.1中，增加了iptables，但并不是默认的运行模式，v1.2起，默认就是iptables代理。kubernetes1.8.0-beta中，添加了IPVS代理。

在kubernetes 1.14版本开始默认使用IPVS代理

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

代理模式的分类：userspace、iptables、ipvs（推荐使用）

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 代理模式 -->

ClusterIP：

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

为例实现该流程，主要需要以下几个组件的协同工作：

• apiserver 用户通过kubectl命令向apiserver发送创建service的命令，apiserver接受到请求后将数据写入到etcd中。

• kube-proxy kubernetes的每一个节点中都有一个kube-proxy进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables/ipvs规则中。

• iptables/ipvs使用NAT技术将virtualIP的流量转发至Endpoint中

1、创建Deployment信息：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: stabel
  templates:
    metadata:
      lables:
        app: myapp
        release: stabel
        env: test
    spec:
      containers:
        - name: myapp
          image: nginx:1.17.1
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
          

2、创建Service信息

  将此service绑定至Deployment创建的Pod上，利用label selector（标签选择器）

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP    # 默认值
  selector:        # 标签选择器，选择管理的pod
    app: myapp
    release: stabel
  ports:
    - name: http
      port: 80           # service暴露的端口
      targetPort: 80    # pod里面的进程暴露的端口
    

3、执行命令

kubectl apply -f myapp-deploy.yaml
kubectl apply -f myapp-svc-clusterip.yaml
ipadm -Ln
    - 查询到后端暴露的endpoints

Headless Service

  特殊的ClusterIP

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

  经常在StatefulSet控制器中使用,pod的ip不断变化的，但是可以通过固定域名让他持续被访问

1、创建myapp-svc-handless.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc-handless
  namespace: default
spec:
  type: ClusterIP
  clusterIP: "None"
  selector:
    app: myapp
    release: stabel
  ports:
    - name: http
      port: 80
      targetPort: 80

 2、命令查看

# 每个service都会在coredns中插入一条A记录
# 获取coredns的地址
$ kubectl get pod -n kube-system -o wide
# 查看myapp-svc-handless的A记录
$ dig -t -A myapp-svc-handless.default.svc.cluster.local.@crondbs的ip
- myapp-svc-handless: service的名称
- default：名称空间
- svc.cluster.local:域名

NodePort

NodePort的原理就是在每个Node节点上开了一个端口，将向该端口的流量导入kube-proxy，然后由kube-proxy进一步给到对应的Pod。

myapp-svc-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc-nodeport
  namespace: default
spec:
  type: NodePort
  selector:
    app: myapp
    release: stabel
  ports:
    - name: http
      port: 80
      targetPort: 80
      

执行命令：

$ kubectl apply -f myapp-svc-nodeport.yaml
$ kubectl get svc myapp-svc-nodeport
# 通过外部主机进行访问 任意node节点地址:80
# 最好再所有node节点外，再加上一层负载均衡器，就可以实现高可用。
$ ipvsadm -Ln

LoadBalancer

LoadBalancer和NodePode其实是同一种方式，区别在于loadBalancer比NodePort多了一步，就是可以调用cloud provider去创建LB来向节点导流（收费，laas:负载均衡即服务）

ExternalName

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

myapp-svc-externalname.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc-externalname
  namespace: default
spec:
  type: ExternalName
  externalName: 192.168.66.20

当查询主机my-service.default.svc.cluster.local (SVC_NAME.NAMESPACE.svc.cluster.local)

集群的DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理和转发

CNAME: 就是将域名解析为ip地址

my.database.example.com - 192.168.66.20

创建这个svc，就会在coredns中创建一个myapp-svc-externalname.default.svc.cluster.local 这个，当访问这个域名是，就会被重定向到externalName 指定的这个参数中（my.database.example.com)

其实就是将用户访问myapp-svc-externalname 这个service时，将其转发至192.168.66.20