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/v1kind: Deploymentmetadata:  name: myapp-deploy  namespace: defaultspec:  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: v1kind: Servicemetadata:  name: myapp  namespace: defaultspec:  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: v1kind: Servicemetadata:  name: myapp-headless  namespace: defaultspec:  selector:    app: myapp  ClusterIP: "None"  ports:  - port: 80    targetPort: 80

NodePort

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

apiVersion: v1kind: Servicemetadata:  name: myapp  namespace: defaultspec:  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: v1kind: Servicemetadata:  name: my-service  namespace: defaultspec:  type: ExternalName  externalName: www.example.com

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