kubernates学习笔记【12】：service介绍，service代理模式分类

一. Service定义

    Kubernetes Service 定义了这样一种概念: -个[Pod]的逻辑分组，-种可以访问它们的策略--通常称为微服务。这一组Pod能够被Service 访问到，通常是通过Label selector来访问

      

二. Service类型

      Service在K8s中有以下四种类型：

      1. Clusterlp: 默认类型，自动分配-个仅Cluster内部可以访问的虚拟IP

      2. NodePort: 在ClusterIP基础上为Service在每台机器.上绑定个端口，这样就可以通过: NodePort来访

      问该服务

      3. LoadBalancer: 在NodePort的基础上，借助cloud provider创建-一个外部负载均衡器，并将请求转发

      到: NodePort

      4. ExternalName: 把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，

      这只有kubernetes 1.7或更高版本的kube-dns才支持

三. Service代理

     在Kubernetes集群中，每个Node运行一个kube-proxy 进程。kube-proxy 负责为Service 实现了一种VIP (虚拟IP)的形式，而不是ExternalName 的形式。 在Kubernetes v1.0版本，代理完全在userspace. 在Kubernetes v1.1版本，新增了iptables代理，但并不是默认的运行模式。从Kubermetes v1.2起，默认就是iptables代理。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理在Kubernetes 1.14版本开始默认使用ipvs代理

     在Kubernetes v1.0版本，Service 是"4层”(TCP/UDP overIP)概念。在Kubernetesv1.1版本,新增了Ingress API (beta 版)，用来表示“7层”(HTTP) 服务。

     看下图：

四. Service代理模式分类

  1. userspace

这种方式是需要经过kube-proxy的，比较消耗时间

  2. iptables代理模式

     这种方式不需要经过kube-proxy，只需要经过iptables的防火墙，而它的pod信息还是有service，kube-proxy来维护的。

  3. 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:不排队调度