Kubernetes之所以需要Service，一方面是因为Pod的IP不是固定的，另一方面则是因为一组Pod实例之间总会有负载均衡的需求

被selector选中的Pod，就称为Service的Endpoints，查看方式：

kubectl get endpoints hostnames

需要注意的是，只有处于Running状态，且readinessProbe检查通过的Pod，才会出现在Service的Endpoints列表里。

vip地址查看，svc - 是 service 的缩写

kubectl get svc hostnames
NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
hostnames   ClusterIP   10.0.1.175   <none>        80/TCP    5s

输出信息包含：
NAME: Service 的名称
TYPE: Service 的类型（如 ClusterIP, NodePort, LoadBalancer 等）
CLUSTER-IP: 集群内部的 IP 地址
EXTERNAL-IP: 外部可访问的 IP 地址（如果有的话）
PORT(S): Service 暴露的端口
AGE: Service 创建后的运行时间

这个命令常用于：
检查服务是否正常运行
获取服务的 IP 地址和端口信息
验证服务的配置是否正确
故障排查时查看服务状态

Service是由kube-proxy组件，加上iptables来共同实现的。

不难想到，当你的宿主机上有大量Pod的时候，成百上千条iptables规则不断地被刷新，会大量占用该宿主机的CPU资源，甚至会让宿主机“卡”在这个过程中。所以说，一直以来，基于iptables的Service实现，都是制约Kubernetes项目承载更多量级的Pod的主要障碍。