Service 介绍
Deployment 只是保证了支撑服务的微服务 Pod 的数量，但是没有解决如何访问这些服务的问题。一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 IP 启动一个新的 Pod，因此不能以确定的IP和端口号提供服务。
要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在 K8S 集群中，客户端需要访问的服务就是 Service 对象。每个Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。
在 K8S 集群中，微服务的负载均衡是由 kube-proxy 实现的。kube-proxy 是 k8s 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 kube-proxy 就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决反向代理的高可用问题。
在 kubernetes 中，pod 是应用程序的载体，我们可以通过 pod 的 ip 来访问应用程序，但是 pod 的 ip 地址不是固定的，这也就意味着不方便直接采用 pod 的 ip 对服务进行访问。
为了解决这个问题，kubernetes 提供了 Service 资源，Service 会对提供同一个服务的多个 pod 进行聚合，并且提供一个统一的入口地址。通过访问 Service 的入口地址就能访问到后面的 pod 服务。
Service 在很多情况下只是一个概念，真正起作用的其实是 kube-proxy 服务进程，每个 Node 节点上都运行着一个 kube-proxy 服务进程。当创建 Service 的时候会通过 api-server 向 etcd 写入创建的 service 的信息，而 kube-proxy 会基于监听的机制发现这种 Service 的变动，然后它会将最新的 Service 信息转换成对应的访问规则。
执行 ipvsadm -Ln 查看，如果没有需要 yum 进行安装
# 10.97.97.97:80 是 service 提供的访问入口 # 当访问这个入口的时候，可以发现后面有三个 pod 的服务在等待调用， # kube-proxy 会基于 rr（轮询）的策略，将请求分发到其中一个 pod 上去 # 这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以。 [root@dce-10-6-215-215 tmp]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.97.97.97:80 rr -> 10.244.1.39:80 Masq 1 0 0 -> 10.244.1.40:80 Masq 1 0 0 -> 10.244.2.33:80 Masq 1 0 0
Service 存在的意义
防止 Pod 失联【服务发现】
因为 Pod 每次创建都对应一个 IP 地址，而这个 IP 地址是短暂的，每次随着 Pod 的更新都会变化，假设当我们的前端页面有多个 pod 时候，同时后端也多个 Pod，这个时候，他们之间的相互访问，就需要通过注册中心，拿到 Pod 的 IP 地址，然后去访问对应的 Pod
定义 Pod 访问策略【负载均衡】
页面前端的 Pod 访问到后端的 Pod，中间会通过 Service 一层，而 Service 在这里还能做负载均衡，负载均衡的策略有很多种实现策略，例如：
- 随机
- 轮询
- 响应比
kube-proxy 目前支持三种工作模式
userspace 模式
userspace 模式下，kube-proxy 会为每一个 Service 创建一个监听端口，发向 Cluster IP 的请求被 Iptables 规则重定向到 kube-proxy 监听的端口上，kube-proxy 根据 LB 算法选择一个提供服务的 Pod 并和其建立链接，以将请求转发到 Pod 上。 该模式下，kube-proxy 充当了一个四层负责均衡器的角色。由于 kube-proxy 运行在 userspace 中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。
iptables 模式
iptables 模式下，kube-proxy 为 service 后端的每个 Pod 创建对应的 iptables 规则，直接将发向 Cluster IP 的请求重定向到一个 Pod IP。 该模式下 kube-proxy 不承担四层负责均衡器的角色，只负责创建 iptables 规则。该模式的优点是较 userspace 模式效率更高，但不能提供灵活的 LB 策略，当后端 Pod 不可用时也无法进行重试。
ipvs 模式
ipvs 模式和 iptables 类似，kube-proxy 监控 Pod 的变化并创建相应的 ipvs 规则。ipvs 相对 iptables 转发效率更高。除此以外，ipvs 支持更多的 LB 算法。
# 此模式必须安装 ipvs 内核模块，否则会降级为 iptables # 开启ipvs [root@dce-10-6-215-215 tmp]# kubectl edit cm kube-proxy -n kube-system # 修改 mode: "ipvs" # 删除 kube-proxy 下，重新创建 [root@dce-10-6-215-215 tmp]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system [root@dce-10-6-215-215 tmp]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.97.97.97:80 rr -> 10.244.1.39:80 Masq 1 0 0 -> 10.244.1.40:80 Masq 1 0 0 -> 10.244.2.33:80 Masq 1 0 0
资源清单
Service的资源清单文件如下
kind: Service # 资源类型 apiVersion: v1 # 资源版本 metadata: # 元数据 name: service # 资源名称 namespace: dev # 命名空间 spec: # 描述 selector: # 标签选择器，用于确定当前 service 代理哪些 pod app: nginx type: # Service 类型，指定 service 的访问方式 clusterIP: # 虚拟服务的 ip 地址 sessionAffinity: # session 亲和性，支持 ClientIP、None 两个选项 ports: # 端口信息 - protocol: TCP port: 3017 # service 端口 targetPort: 5003 # pod 端口 nodePort: 31122 # 主机端口
type 的类型有下面几种
- ClusterIP：默认值，它是 Kubernetes 系统自动分配的虚拟 IP，只能在集群内部访问
- NodePort：将 Service 通过指定的 Node 上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
- LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
- ExternalName： 把集群外部的服务引入集群内部，直接使用
