本文最后更新于 413 天前，其中的信息可能已经有所发展或是发生改变。
为什么需要服务发现
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
