关于kubernetes:Kubernetes中Service的种类

Service 的概念

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

Service 可能提供负载平衡能力，然而在应用上有以下限度：

• 只提供 4 层负载能力，而没有 7 层性能，然而有时咱们可能须要更多的匹配规定来转发申请，这点来说 4 层负载平衡时不反对的

Service 的类型

Service 的四种类型：

• ClusterIP：默认类型，主动调配一个仅 Cluster 外部可拜访的虚构 IP
• NodePort：在 ClusterIP 根底上为 Service 在每台机器上绑定一个端口，这样就能够通过 <NodeIP>:<NodePort> 来拜访该服务
• LoadBalance：在 NodePort 的根底上，借助 cloud provider 创立一个内部负载均衡器，并将申请转发到 <NodeIP>:<NodePort>
• ExternalName: 把集群内部的服务引入到集群外部来，在集群外部间接应用，没有任何类型代理被创立，这只有 Kubernetes1.7 以上版本的 kube-dns 才反对

VIP 和 Service 代理

在 Kubernetes 集群中，每个 Node 节点运行一个 kube-proxy 过程，kube-proxy 负责 Service 实现一种虚构 IP 的模式，而不是 ExternalName 的模式，在 Kubernetesv1.0 版本，代理齐全在 userspace，在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。从 Kubernetes v1.2 版本开始，默认就是 iptables 代理，在 Kubernetes v1.8.0-beta.0 中，增加了 ipvs 代理，在 Kubernetes v1.14 版本开始默认应用 ipvs 代理

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

ipvs 代理模式

这种模式，kube-proxy 会监督 Kubernetes Service 对象和 Endpoints，调用 netlink 接口以绝对应地创立 ipvs 规定并定期与 Kubernetes Service 对象和 Endpoint 对象同步 ipvs，以确保 ipvs 状态与冀望统一，拜访服务时，流量被重定向到其中一个后端 Pod，与 iptables 相似，ipvs 与 netfilter 的 hook 性能，但应用哈希表作为底层数据结构并在内核空间中工作，这意味着能够更快地重定向流量，并且在同步代理规定时具备更好的性能，此外，ipvs 为负载平衡算法提供更多选项，例如：

• rr: 轮训调度
• lc: 最小连接数
• dn: 指标哈希
• sh: 源哈希
• sed: 最短期望提早
• nq: 不排队调度

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 等技术将 VIP 的流量转至 endpoint 中

创立 Deployment 信息

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

创立 Service 信息

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: myapp  #标签选择器
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

查问命令

ipvsadm -Ln

Headless Service

有时不须要或不想要负载平衡，以及独自的 Service IP，遇到这种状况，能够通过指定 ClusterIP 的值为 None 来创立 Headless Service，这类 Service 并不会调配 ClusterIP，kube-proxy 不会解决它们，并且平台也不会为它们进行负载平衡和路由

apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
  ClusterIP: "None"
  ports:
  - port: 80
    targetPort: 80

NodePort

NodePort 的原理在于在 node 上开了一个端口，将向该端口的流量导入到 kube-proxy，而后有 kube-proxy 进一步给对应的 Pod

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: NodePort
  selector:
    app: myapp  #标签选择器
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

查问命令

ipvsadm -Ln

LoadBalancer

LoadBalancer 和 NodePode 其实是同一种形式，区别在于 loadBalancer 比 NodePort 多了一步，就是能够调用 cloud provider 去创立 LB 来向节点导流（免费，laas: 负载平衡即服务）

ExternalName

这种类型的 Service 通过返回 CNAME 和它的值，能够将服务映射到 ExternalName 字段的内容，ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和 endpoint，相同的，对于运行在集群内部的服务，它通过返回该内部服务的别名这种形式来提供服务

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

当查问主机 my-service.default.svc.cluster.local 时，集群的 DSN 服务将返回一个值 my.database.example.com 的 CNAM 记录，拜访这个服务的工作形式和其余的雷同，惟一不同的是重定向产生在 DNS 层，而且不会进行代理或转发