为什么需要服务发现
Pod 生命周期不等于应用的生命周期，Pod 创建和销毁会导致它的 ip 地址发生变化
Service：Kubernetes 中的服务发现与负载均衡
Service 语法
- port：外部访问这个 service 的端口
- targetPort：service 访问后端服务的端口
查看 service
kubectl discribe service
- 当 pod 销毁时，service 就会自动从后端摘除这个 pod
集群内访问 Service
- 通过 service 的虚拟 IP 去访问
- 直接访问服务名，依靠 DNS 解析：{service}.{namespace}
- 通过环境变量访问，同一个 namespace 里的 pod 启动时，K8s 会把 service 的一些 IP 地址、端口，以及一些简单的配置，通过环境变量的方式放到 K8s 的 pod 里面。
Headless Service
- 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。
架构设计
- 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。
- 通过 Coredns 这里去解析出 ServiceIP
- Pod3 请求 Service IP
- 请求到宿主机的网络之后，被 kube-proxy 所配置的 iptables 或者 IPVS 拦截处理
- 负载均衡到每一个实际的后端 pod
集群外部访问链路
- 通过 Cloud Controller Manager 配置的负载均衡器，转发到 node 上
- 请求到宿主机的网络之后，被 kube-proxy 所配置的 iptables 或者 IPVS 拦截处理
- 负载均衡到每一个实际的后端 pod
