k8s Service学习

service的概念

kubernetes service定义了一个抽象概念，一个pod的逻辑分组，一种可以访问的策略---通常称为服务。这组pod能够被service访问到，通常通过label selector

service能够提供负载均衡能力，但是在使用上有限制：

　　只能提供四种负载能力，而没有7层功能。但有时我们需要更多匹配规则来转发请求，这点上4层负载均衡是不支持的

service类型

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

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

Nodeport:在 Cluster基础上为 Service在每台机器上绑定一个端口,这样就可以通过: Nodeport来访问该服务

Loadbalancer:在 Nodeport的基础上,借助 cloud provider创建一个外部负载均衡器,并将请求转发到: Nodeport

Externalname:把集群外部的服务引入到集群内部来,在集群内部直接使用。没有任何类型代理被创建这只有 kubernetes1.7或更高版本的kube-dns才支持

VIP和 Service代理

在 Kubernetes集群中,每个Node运行一个kube- proxy进程。 kube-proxy负责为 Service实现了ー种VIP(虚拟IP)的形式,而不是 Externalname的形式。在 Kubernetes v1.版本,代理完全在 userspace。在Kubernetes v1.1版本,新増了 iptables代理,但并不是默认的运行模式。从 Kubernetes v1.2起,默认就是iptables代理。

在 Kubernetes v1.8.0-beta.0中,添加了ipvs代理

在 Kubernetes1.14版本开始默认使用ipvs代理

在 Kubernetes v1.0版本, Service是“4层"(TCP/ UDP over P)概念。在 Kubernetes v'1.1版本,新増了gressAP(beta版),用来表示“7层"(HTTP)服务

代理模式分类

1.username模式

 2.iptables

 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:源哈希

ed:最短期延迟

nq:不排队调度

ClusterIP

ClusterIP主要在每个node使用iptables将发向 clusterIP对应端口的数据,转发到kube- proxy中。然后kube- proxy自己内部实现有负載均衡的方法,并可以查询到这个 service下对应pod的地址和端口,进而把数据转发给对应的pod的地址和端口

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

api-server 用户通过 kubectl命令向 aipserver发送创建 service的命令, apiserver接收到请求后将数据存储到etcd中

kube- proxy kubernetesl的每个节点中都有一个叫做kube- porxy的进程,这个进程负责感知 service,pod的变化,并将变化的信息写入本地的 iptables规则中

iptables使用NAT等技术将 virtualIP的流量转至 endpoint中

创建 myapp- deploy.yaml文件

service:myapp-service.yaml

$ ipvsadm -Ln //产看也是关系

Headless Service

有时不需要或不想要负载均衡,以及单独的 Service IP。遇到这种情况,可以通过指定 ClusterIP(spec.clusterIP)的值为"None"来创建 Headless Service。这类 Service并不会分配 Cluster IP.kube-proxy不会处理它们,而且平台也不会为它们进行负载均衡和路由

Nodeport

nodeport的原理在于在node上开了一个端口,将向该端口的流量导入到 kube-proxy,然后由 kube-proxy进一步到给对应的pod

查询流程：

Load Balancer

Load Balancer和 nodePort其实是同一种式。区别在于 loadBalancer比 nodeport多了一步,就是可以调用cloud provider去刨建LB来向节点导流

Externalname

这种类型的 Service通过返回 CNAME和它的值,可以将服务映射到 externalname字段的内容(例如xxxx.com)。Externalname Service是Service的持例,它没有selector,也没有定义任何的端口和Endpoint。相反的,对于运行在集群外部的服务,它通过返回该外部务的别名这种方式来提供服务

当查询主机my- service. defalut.svc. cluster. local( SVC NAMSPACE.svc cluste)时,集群的DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同,唯一不同的是重定向发生在DNS层。而且不会进行代理戓转发