一、通过 Service 访问 Pod：
我们不应该期望 Kubernetes Pod 是健壮的，而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。
每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP 地址。这样就产生了一个问题：
如果一组 Pod 对外提供服务（比如 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并访问这个服务呢？
Kubernetes 给出的解决方案是 Service。
在k8s里面，比如我们运行了一个服务，这个服务是启动了3副本，客户端要访问这个服务的时候，不是直接访问你的pod，而是访问pod对外提供的代表，service，service会固定一个IP地址，即使你的pod怎么去销毁重新创建，没关系，我service对外提供服务，你只要访问我service这个固定IP就好。（你访问service的时候，不是说三个pod同时对外提供服务，它会把你请求呢根据一定的算法，转发到你后端的三个pod里面，有可能你这个访问的是第一个pod给你提供的实际服务，有可能第二次就是第二个pod给你提供的服务，那
Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 label 来挑选。Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。
来看个例子，创建下面的这个 Deployment：
我们启动了两个 Pod，运行 httpd 镜像，label 是 run: httpd，Service 将会用这个 label 来挑选 Pod，怎么说，下图假如是一台主机，它里面运行了很多很多的pod，如上图的yml文件，我们只起了两个httpd的pod，另外三个pod运行的假如是nginx，那么service怎么去选择启动的httpd的pod呢？就是因为这两个pod里定义了label，run:httpd，在我service的yml文件中selector（选择器）也会有一个label，挑选run:httpd的pod。
Pod 分配了各自的 IP，这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问（这个IP是私有的IP，只能在我集群当中的节点来访问）。
接下来创建 Service，其配置文件如下：
① v1 是 Service 的 apiVersion。
② 指明当前资源的类型为 Service。
③ Service 的名字为 httpd-svc。
④ selector 指明挑选那些 label 为 run: httpd 的 Pod 作为 Service 的后端。
⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口，使用 TCP 协议。
执行 kubectl apply 创建 Service httpd-svc。
httpd-svc 分配到一个 CLUSTER-IP 10.68.236.129。为什么是这个IP呢，因为当初我们部署的时候配置文件定义了service的IP,我们看一下，可以通过该 IP 访问后端的 httpd Pod。
根据前面的端口映射，这里要使用 8080 端口。另外，除了我们创建的 httpd-svc，还有一个 Service kubernetes，Cluster 内部通过这个 Service 访问 kubernetes API Server。
通过 kubectl describe 可以查看 httpd-svc 与 Pod 的对应关系。
kubectl describe service httpd-svc kubectl get pod -o wide