六 Service

一、Service 的观点

Kubernetes Service界说了这样一种抽象：一个Pod的逻辑分组，一种可以访谒它们的计谋 —— 凡是称为微处事。这一组Pod能够被Service访谒到，凡是是通过Label Selector

Service能够供给负载均衡的能力，但是在使用上有以下限制：

只供给 4 层负载均衡能力，而没有 7 层成果，但有时我们可能需要更多的匹配法则来转发请求，这点上 4 层负载均衡是不撑持的

二、Service 的类型

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

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

②　NodePort：在 ClusterIP 根本上为 Service 在每台机器上绑定一个端口，这样就可以通过:NodePort 来访谒该处事

③　LoadBalancer：在 NodePort 的根本上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort

④　ExternalName：把集群外部的处事引入到集群内部来，在集群内部直接使用。没有任何类型代办代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才撑持

svc根本导论

总结

客户端访谒节点时通过iptables实现的，

iptables法则是通过kube-proxy写入的，

apiserver通过监控kube-proxy去进行对处事和端点的监控，

kube-proxy通过pod的标签（lables）去判断这个断点信息是否写入到Endpoints里去。

三、VIP 和 Service 代办代理

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

在 Kubernetes 1.14 版本开始默认使用ipvs 代办代理

在 Kubernetes v1.0 版本，Service是 “4层”（TCP/UDP over IP）观点。在 Kubernetes v1.1 版本，新增了Ingress API（beta 版），用来暗示 “7层”（HTTP）处事

为何不使用 round-robin DNS？

DNS会在很多的客户端里进行缓存，很多处事在访谒DNS进行域名解析完成、得到地点后不会对DNS的解析进行断根缓存的操纵，所以一旦有他的地点信息后，不管访谒几次还是本来的地点信息，导致负载均衡无效。

四、代办代理模式的分类 1、userspace 代办代理模式

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

⑤　sed：最短期望延迟

⑥　nq：不排队调理

五、ClusterIP