十三、Kubernetes Services

为什么需要服务发现

Pod 生命周期不等于应用的生命周期，Pod 创建和销毁会导致它的 ip 地址发生变化

Service：Kubernetes 中的服务发现与负载均衡

img

Service 语法

img

• port：外部访问这个 service 的端口
• targetPort：service 访问后端服务的端口

查看 service

kubectl discribe service

img

• 当 pod 销毁时，service 就会自动从后端摘除这个 pod

集群内访问 Service

1. 通过 service 的虚拟 IP 去访问
2. 直接访问服务名，依靠 DNS 解析：{service}.{namespace}
3. 通过环境变量访问，同一个 namespace 里的 pod 启动时，K8s 会把 service 的一些 IP 地址、端口，以及一些简单的配置，通过环境变量的方式放到 K8s 的 pod 里面。

Headless Service

img

• service 创建的时候可以指定 clusterIP:None，告诉 K8s 说我不需要 clusterIP（就是刚才所说的集群里面的一个虚拟 IP），然后 K8s 就不会分配给这个 service 一个虚拟 IP 地址。
• pod 可以直接通过 service_name 用 DNS的 A 记录的方式会解析到所有后端的 Pod 的地址，由客户端选择一个后端的 IP 地址。

向集群外暴露 Service

• NodePort 的方式就是在集群的 node 上面（即集群的节点的宿主机上面）去暴露节点上的一个端口，这样相当于在节点的一个端口上面访问到之后就会再去做一层转发，转发到 service 虚拟 IP 地址上面。 注意是node上的端口，用minikube模拟多节点时，访问service得先看看在哪个node上的，不然无法访问
• LoadBalancer 类型，提供一个供外部访问的 ip。

架构设计

img

• Cloud Controller Manager，负责配置 LoadBalancer 给外部访问
• Coredns，观测 APIServer 里面的 service 后端 pod 的变化，去配置 service 的 DNS 解析，实现可以通过 service 的名字直接访问到 service 的虚拟 IP，或者是 Headless 类型的 Service 中的 IP 列表的解析
• 每个 node 里面会有 kube-proxy 这个组件，通过监听 service 以及 pod 变化，去配置iptables 或者 IPVS。

集群内部访问链路

假如 Pod3 去访问 Service。

1. 通过 Coredns 这里去解析出 ServiceIP
2. Pod3 请求 Service IP
3. 请求到宿主机的网络之后，被 kube-proxy 所配置的 iptables 或者 IPVS 拦截处理
4. 负载均衡到每一个实际的后端 pod

集群外部访问链路

1. 通过 Cloud Controller Manager 配置的负载均衡器，转发到 node 上
2. 请求到宿主机的网络之后，被 kube-proxy 所配置的 iptables 或者 IPVS 拦截处理
3. 负载均衡到每一个实际的后端 pod