k8s service服务发现
k8s service服务发现
k8s service 概念
Kubernetes Service定义了这样一种抽象： Service是一种可以访问 Pod逻辑分组的策略， Service通常是通过 Label Selector访问 Pod组
Service能够提供负载均衡的能力，但是在使用上有以下限制：只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的
Service 的类型
ClusterIp类型
- ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP,在集群内部，给k8s提供一个内部集群的方案，指定虚拟Ip就可以访问到后端的服务
案例
[root@master manifests]# vim myapp-service.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
NodePort 类型
- NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过: NodePort来访问该服务。
案例
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
type: NodePort
selector:
app: myapp
release: stabel
ports:
- name: http
port: 80
targetPort: 80
nodePort: //不指定端口会随机分配
nodePort对外暴露的端口在生产中一般不会直接暴露在公网，而是有三种方案：
- 1.前面加个路由器
- 2.前面加个LB（阿里云卖的服务）
- 3.前面加个ipvs（自己搭建）
LoadBalancer 类型
- LoadBalancer：在NodePort的基础上，借助Cloud Provider创建一个外部负载均衡器，并将请求转发到NodePort
案例
ExternalName 类型
- ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持。
案例
//集群内部访问的时候是 my-service.defalut.svc.cluster.local
//会解析到外部的 hub.hongfu.com
kind: Service
apiVersion: v1
metadata:
name: my-service
namespace: default
spec:
type: ExternalName
externalName: hub.hongfu.com
当查询主机 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的 DNS 服务将返回一个值 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发
工作组件
为了实现图上的功能，主要需要以下几个组件的协同工作：
- apiserver：用户通过 kubectl 命令向 apiserver 发送创建 service 的命令，apiserver 接收到请求后将数据存储到 etcd 中
- kube-proxy：kubernetes 的每个节点中都有一个叫做 kube-porxy 的进程，这个进程负责感知service，pod 的变化，并将变化的信息写入本地的 ipvs 规则中
- ipvs：基于内核的钩子函数机制实现负载
简而言之就是：
客户端访问节点时通过 iptables实现的
iptables规则是通过 kube-proxy写入的
apiserver通过监控 kube-proxy去进行对服务和端点的监控
kube-proxy通过 pod的标签（ lables）去判断这个断点信息是否写入到 Endpoints里
vip 和 proxy模式演变
在 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代理。
ipvs
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：不排队调度
ingress 请移步 k8s ingress
