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的主要障碍。
