image.png

    Kubernetes Pod 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束，通过 ReplicationController 能够动态地创建和销毁 Pod（例如，需要进行扩缩容，或者执行 滚动升级）

    每个 Pod 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的，这会导致一个问题：在Kubernetes 集群中，如果一组 Pod（称为 backend）为其它 Pod （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 Pod 中的哪些 backend 呢？

    Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务

    这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector（查看下面了解，为什么可能需要没有 selector 的 Service）实现的

    举个例子，考虑一个图片处理 backend，它运行了3个副本，这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本，然而组成这一组 backend 程序的 Pod 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态，Service 定义的抽象能够解耦这种关联

    对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 Endpoints API，只要 Service 中的一组 Pod发生变更，应用程序就会被更新，对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方式访问 Service，再由 Service 重定向到 backend Pod

    相关文档：https://blog.csdn.net/kenkao/article/details/87375435
    相关文档：https://www.cnblogs.com/wlbl/p/10694316.html