kubernetes学习之路（十三）service（一）

Service 概念

  service 是一种可以访问一组 pod 的访问策略，通过 Label Selector 标签匹配后端 pod，这样无论后端 pod 是增加还是减少，都可以通过 svc 访问到，例如 nginx 指定 svc 地址，那么就相当于代理后端 pod，而不会以为增加 pod 而修改 nginx 配置。

  轮询方式只有 rr ，只提供了4层负载能力，也就是不能通过域名或主机名的方式进行负载。

 

Service 类型

Clusterlp：默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP

NodePort：在ClusterIP基础上为Service在每台node节点上绑定一个端口，这样可以通过 NodeIP:Port 的方式来访问后端Pod，这种方法比较常见，nginx可以通过这种方式进行代理。

LoadBalancer：在NodePort的基础上，借助cloud provider创建一个外部负载均衡器，并将请求转发到 NodeIP:Port ，这种方式一般是通过云服务商的 LB 实现，也就是收费模式。

ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，需要1.7或更高版本的kube-dns才支持。简单来说，当前集群内的pod需要访问外部一个服务，如果外部服务更改了ip地址，那么pod的配置就需要更改，而使用此方法相当于定义了一个svc，指定外部ip地址，如果外部ip地址发生变化，只需要更新svc即可。

图中含义：

  客户端访问svc实际上是访问的iptables规则从而访问到后端pod，iptables的规则是通过kube-proxy写入的，apiserver通过监控kube-proxy实现服务和端点信息的发现，kube-proxy通过pod的标签判断信息是否写入到apiserver的Endpoints中

kubernetes 1.14 版本开始默认使用 ipvs 取代 iptables

注意：ipvs 模式假定在运行 kube-proxy 之前在节点上已经安装好了 IPVS 内核模块。当 kube-proxy 以 ipvs 代理模式启动时，kube-proxy 将验证节点上是否安装了 IPVS 模块，如果未安装，则 kube-proxy 将回退到 iptables 代理模式。

 

代理模式分类

userspace代理模式：

  例如一个Client Pod 要访问 Server Pod ，首先Client Pod 需要通过由 iptables 生成的 Service IP 访问到 kube-proxy ，再由 kube-proxy 代理到 Service Pod。

  这种模式的坏处是 kube-proxy 压力很大，而且因为 kube-apiserver 需要持续监听 kube-proxy ，所以造成 kube-apiserver 压力也很大。。

iptables代理模式：

  同样是 Client Pod 访问 Server Pod，但 iptables代理模式，只通过由 iptables 生成的 Service IP 代理，对比 userspace 代理模式更快，且 kube-proxy 和 kube-apiserver 压力降低。

  坏处是 iptables 性能不高。

ipvs代理模式：

  与 iptables 代理模式相同， 唯一不同是，由 ipvs模块 生成的 Service IP 代替了 iptables

  三种模式中性能最高的方式

 

示例：

实现上图的功能，需要以下几个组件的协同工作：

• apiserver ：用户通过 kubectl 命令向 apiserver 发送创建 service 的命令， apiserver 接收到请求后讲数据存储到 etcd 中
• kube-proxy：node 中的 kube-proxy 进程感知到 etcd 中 service，Pod 的变化，得到信息后，将变化的信息写入到本地的 iptables 或 ipvs 规则中
• iptables 或者 ipvs 使用 NAT 等技术将 virtualIP 的流量转至 endpoint 中

 

实验：

创建 myapp-deploy.yaml 文件

# vim myapp-deploy.yaml

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:v2
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80

创建 Service 信息

# vim svc.yaml

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

port 是 service 端口，targetPort 是 Pod 端口

查看 svc

kubectl get svc

查看 ipvs

ipvsadm -Ln

通过上面两个命令，可以查看到service创建结果以及转发规则

 

 

NodePort

在 node 上打开一个端口，外部通过该端口将流量发送到 kube-proxy 再进一步发送到对应的 Pod

# vim myapp-service.yaml

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

kubectl get svc   可以看到svc后面对应的node上开启的端口

netstat -antpl | grep 端口   可以看到每个node节点上都会开启这个端口

ipvsadm -Ln  | grep 端口   同样可以看到端口下的pod节点及轮询

 

LoadBalancer

由云供应商提供，收费功能，负责调度后端 node 上的端口，从而使用户可以访问到 Pod 提供的服务