Kubernetes Service

目录

• 基本概念
• 服务发现与负载均衡
• 配置Service
  • 建立一个ClusterIP类型的Service
  • 建立一个指定ClusterIP的Service
  • 建立一个headless service
  • 建立一个nodeport的service
• 配置service使用session affinity

基本概念

当应用由单体架构转向微服务架构时，应用被拆成不少小的互相协做的微服务，每一个服务会以多个副本运行，副本数量会随着系统所需的处理能力进行变化，这就是微服务的伸缩性。 微服务的负载均衡器对实现伸缩性起了十分重要的做用。

Service是Kubernetes最重要的资源对象。Kubernetes中的Service对象能够对应微服务架构中的微服务。Service定义了服务的访问入口，服务的调用者Pod经过这个地址访问Service后端的Pod副本实例。 Service经过Label Selector同后端的Pod副本创建关系，Replication Controller保证后端Pod副本的数量，也就是保证服务的伸缩性。

服务发现与负载均衡

咱们知道，kubernetes的node节点运行的时候，须要启动两个进程，分别是kubelet和kube-proxy。其中kubeproxy实际上就是一个智能的负载均衡器。发送到service的请求由kube-proxy转发到后端在的某个pod实例上，同时支持不一样的负载均衡策略和会话保持机制。kubernetes为每一个service分配一个全局惟一的虚拟IP，叫作ClusterIP，这样在整个集群中，服务的调用者都经过ClusterIP和服务进行通讯。

Service建立完毕后，在Service的整个生命周期内Service的名称和ClusterIP保持不变，所以经过引入域名服务将Service的名称和ClusterIP创建DNS域名映射，服务的调用者能够经过使用服务的名称来访问服务。服务发布机制完美支持。

当前kubernetes支持两种负载均衡策略：

• RoundRobin：默认策略，请求被轮循转发到后端的pod实例副本上。
• SessionAffinilty：基于客户端的IP进行会话保持的模式，实现粘性session，客户端请求第一次被转发到某个pod之后，后边全部的请求都固定转发到这个Pod上。SessionAffinilty经过服务的定义service.spec.session.Affinity设备

配置Service

kubrenetes支持三种类型的service，能够经过ServicesTypes指定：

• ClusterIP：仅仅使用一个集群内部的地址，这也是默认值，使用该类型，意味着，service只能在集群内部被访问
• NodePort：在集群内部的每一个节点上，都开放这个服务。能够在任意的 :NodePort地址上访问到这个服务
• LoadBalancer：这是当kubernetes部署到公有云上时才会使用到的选项，是向云提供商申请一个负载均衡器，将流量转发到已经以NodePort形式开放的service上。

下面示例建立一个nginx的deployment，包含三个pod，后面全部建立的service都会与之关联：

建立一个nginx的Deployment：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
  spec:
    containers:
      - name: nginx
        image: nginx
        ports:
          - containerPort:80

能够经过以下指令查看建立的pod：

kubectl get pod -l app=nginx -o wide

建立一个ClusterIP类型的Service

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
    - port: 80 
      targetPort: 80
  selector:
    app: nginx

须要说明下三个端口的意义，其中port表示service监听的端口，targetPort表示后端Pod监听的端口，nodePort表示若是要将service暴露出来，外部访问的端口。不指定ClusterIP，则默认使用ClusterIP方式建立Service，并自动生成一个ClusterIP。能够经过查看service来看到ClusterIP。

查看service：

kubectl get svc nginx

建立一个指定ClusterIP的Service

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  clusterIP: 10.254.0.100
  ports:
    - port: 80 
      targetPort: 80
  selector:
    app: nginx

默认状况下，ClusterIP的值是由k8s自动建立的，咱们能够经过ClusterIP指定，在建立k8s中的dns的时候会用到。

建立一个headless service

建立一个headless service，即指定ClusterIP为None，这个时候，建立的Service没有IP地址。

咱们知道，在默认状况下建立的service，k8s会自动为其生成一个ip地址，并在dns中生成一条域名记录指向该ip，当外部有请求到达时，由kubeproxy组件接受请求并转发到后端的pods。而当ClusterIP为None时，k8s并不会为service生成一个IP，可是仍然会往dns里生成一条域名记录，而这个域名的值会直接指向service所关联的pods的IP地址，有多个pods，就会生成多条A记录。这样的好处是，当有请求到达时，会直接请求到指定的pods，而无需再经过kubeproxy转发，从而提升了响应效率。缺点是负载均衡依赖于dns轮循，没有更灵活的均衡方案。

示例：

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  clusterIP: None
  ports:
    - port: 80 
      targetPort: 80
  selector:
    app: nginx

建立一个nodeport的service

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: NodePort
  ports:
    - port: 80 
      targetPort: 80
      nodePort: 80
  selector:
    app: nginx

配置service使用session affinity

apiVersion: v1
kind: Service
metadata:
  name: nginx-app
  labels:
    app: nginx-app
    tier: nginx-app
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx-app
    tier: nginx-app
  type: LoadBalancer
  sessionAffinity: ClientIP
  loadBalancerIP: 123.123.123.123