一、service(智能负载均衡器)
service主要是提供负载均衡和服务自动发现。它是 k8s 中最核心的资源之一, 每一个 Service 就是我们平常所说的一个“微服务”。命名空间级资源
如上图所示,Kubernetes 的 Service 定义了一个服务的访问入口,前端的应用(Pod)通过这个入口地址访 问其背后的一组由 Pod 副本组成的集群实例,Service 与其后端的 Pod 副本集群之间是通过 Label 来 实现关联的,而 Deployment 则是保证 Service 的服务能力和服务质量始终处于预期的标准。
通过分析,识别并建模系统中的所有服务为微服务,最终我们的系统是由多个提供不同业务能力而彼此独立 的微服务单元所组成,服务之间通过 TCP/IP 进行通信,从而形成了强大而又灵活的弹性网络,拥有强大的分布 式能力、弹性扩展能力、容错能力。
vim service.yaml
apiVersion: v1
kind: Service
metadata:
name: service
spec:
selector:
release: stable
ports:
- name: http
#负载均衡端口
port: 80
#容器内端口
targetPort: 80
#网络代理的类型默认tcp
protocol: "TCP"
- name: https
port: 443
targetPort: 443
protocol: "TCP"
二、service的工作方式
在 Kubernetes 迭代过程中,给 Service 设置里三种工作方式,分别是:Userspace 方式、Iptables 以及 Ipvs, 这三种方式到现在为止,官方推荐使用 IPVS, 当集群不支持 IPVS 的时候,集群会降级到 Iptables。
2.1.userspace
Client Pod 要访问 Server Pod 时,它先将请求发给本机内核空间中的 service 规则,由它再将请求,转给监听 在指定套接字上的 kube-proxy,kube-proxy 处理完请求,并分发请求到指定 Server Pod 后,再将请求递交给内 核空间中的 service,由 service 将请求转给指定的 Server Pod。由于其需要来回在用户空间和内核空间交互通信, 因此效率很差
2.2.Iptables 模型 (软件转发)
直接由内核中的 iptables 规则,接受 Client Pod 的请求,并处理完成后,直接转发给指定 ServerPod。这 种方式不再将请求转发给 kube-proxy,性能提升很多。
2.3.Ipvs 模型 (内核转发)
在 ipvs 模式下,kube-proxy 监视 Kubernetes 服务和端点,调用 netlink 接口相应地创建 IPVS 规则, 并 定期将 IPVS 规则与 Kubernetes 服务和端点同步。 该控制循环可确保 IPVS 状态与所需状态匹配。 访问服务 时,IPVS 将流量定向到后端 Pod 之一。 IPVS 代理模式基于类似于 iptables 模式的 netfilter 挂钩函数,但是使用哈希表作为基础数据结构,并且 在内核空间中工作。 这意味着,与 iptables 模式下的 kube-proxy 相比,IPVS 模式下的 kube-proxy 重定向 通信的延迟要短,并且在同步代理规则时具有更好的性能。与其他代理模式相比,IPVS 模式还支持更高的网络 流量吞吐量。
总结:kube-proxy 都通过 watch 的方式监控着 kube-APIServer 写入 etcd 中关于 Pod 的最新状态 信息,它一旦检查到一个 Pod 资源被删除了 或 新建,它将立即将这些变化,反应在 iptables 或 ipvs 规则中, 以便 iptables 和 ipvs 在调度 Clinet Pod 请求到 Server Pod 时,不会出现 Server Pod 不存在的情况。 自 k8s1.1 以后,service 默认使用 ipvs 规则,若 ipvs 没有被激活,则降级使用 iptables 规则. 但在 1.1 以前, service 使用的模式默认为 userspace。
三、service的类型
Service 是 Kubernetes 对外访问的窗口,针对不同的场景,kubernetes 为我们设置了四种 Service 的类型。
3.1.ClusterIp(向集群内部暴露一个ip)
kubernetes 默认就是这种方式,是集群内部访问的方式,外部是无法访问的。其主要用于为集群内 Pod 访 问时,提供的固定访问地址,默认是自动分配地址,可使用 ClusterIP 关键字指定固定 I