redis - statefulset和headless service是如何工作的-K8s

Question

我明白了

• StatefulSet - 管理/维护稳定的主机名、网络 ID 和持久存储。
• HeadlessService - 为有状态应用程序定义 headless 服务所需的稳定网络 ID

FROM K8s Docs -> Sometimes you don’t need or want load-balancing and a single service IP. In this case, you can create “headless” services by specifying "None" for the cluster IP (.spec.clusterIP).

我对“有状态与无状态”应用/组件的看法

1. UI 属于无状态应用程序/组件，因为它不维护任何数据。但是它从数据库中获取并显示

2. DB, Cache(Redis) 是有状态的应用/组件，因为它要维护数据

我的问题。

1. 应用程序中的持久性存储 - 为什么我应该考虑将 postgress(例如)部署为 StatefulSet？我可以在 Deployement 中定义 PV 和 PVC 以将数据存储在 PV 中。即使 pod 重启，它也会获取它的 PV，因此不会丢失数据。

2. Network - Redis(例如)应该部署为 StatefulSet，这样即使在 pod 重启后我们也每次都能获得唯一的“网络 ID”/名称.例如; Redis-0、Redis-1在StatefulSet中，我可以定义Redis-0为master，所以master name 永远不会改变。现在为什么我应该为 StatefulSet 应用考虑 Headless Service？我可以直接访问/连接 POD 本身，对吧？ Headless Service有什么用？

3. 我听说过 Operators，这是管理 StatefulSet 应用程序的最佳方式。我在下面找到了一些例子。为什么这些(或其他一些)部署为 StatefulSet 很重要。例如，Prometheus 或 ElasticSearch；我可以定义 PVs 和 PVC 来存储数据而不丢失。

   • https://github.com/krallistic/kafka-operator
   • https://github.com/coreos/prometheus-operator
   • https://github.com/upmc-enterprises/elasticsearch-operator

我为什么/什么时候应该关心 StatefulSet 和 Headless Service？

Answer 1

在尝试回答您的一些问题之前，我必须添加免责声明:给猫剥皮的方法有很多种。由于我们在这里讨论 StatefulSets，请注意并非所有方法都最适合所有有状态应用程序。如果您需要具有单个 PV 的单个数据库 pod，您可以采用一种方法，如果您的 api pod 需要一些共享的和一些分离的 PV，然后是另一个等等。

Persistence storage in Apps - Why should I consider to deploy postgress (for example) as StatefulSet? I can define PVs and PVC in Deployement to store the data in PV.

如果您的所有 Pod 都在所有副本中使用相同的持久卷声明(并且供应商允许这样做)，则这适用。如果您尝试根据 Deployment 增加副本数量，您的所有 Pod 将使用完全相同的 PVC。另一方面，在 api documentation 中定义的 StatefulSet具有 volumeClaimTemplates，允许每个副本拥有自己生成的 PVC，确保为副本集中的每个 pod 单独提供的 PV。

Now why should I consider Headless Service for StatefulSet apps?

因为易于发现。同样，您不需要知道在 Headless Service 中有多少个副本，检查服务 DNS 您将获得所有副本(注意 - 在那个时刻启动并运行)。您可以手动执行此操作，但在这种情况下，您依赖于不同的副本计数/保持标签机制(例如，副本自行注册到主服务器)。这是一个很好的例子 pod discovery with nslookup这可以阐明为什么 headless 是一个好主意。

Why those(or some other) are important to deploy as StatefulSet

据我了解，您列出的很多 Operator 都是使用 Deployment 本身部署的。但是它们处理 StatefulSets，所以让我们以 ElasticSearch 为例。如果它没有作为 StatefulSet 部署，你最终会得到两个针对相同 PV 的 pod(如果供应商允许的话)，这会严重搞砸事情。使用 StatefulSet，每个 pod 都有自己的持久卷声明(来自模板)，因此将持久卷与同一 StatefulSet 中的其他 ElasticSearch pod 分开。这只是冰山一角，因为 ElasticSearch 的设置/处理更为复杂，而运营商正在帮助解决这一问题。

Why/When should I care about StatefulSet and Headless Serivice?

• 在复制的 pod 需要彼此具有单独的 PV(从 PVC 模板创建并自动配置)的任何情况下，您都应该使用有状态集。

• 在任何情况下，如果您想自动发现该服务下的所有 pod，您都应该使用 Headless Service，而不是获取 ClusterIP 的常规服务。作为上述说明 example这是服务(使用 ClusterIP)和 Headless 服务(不使用 ClusterIP)的 DNS 条目之间的区别:

  • 标准服务 - 您将获得 clusterIP 值:

    kubectl exec zookeeper-0 -- nslookup zookeeper
    Server:        10.0.0.10
    Address:    10.0.0.10#53
    
    Name:    zookeeper.default.svc.cluster.local
    Address: 10.0.0.213
    

  • Headless 服务 - 您将获得每个 Pod 的 IP:

    kubectl exec zookeeper-0 -- nslookup zookeeper
    Server:        10.0.0.10
    Address:    10.0.0.10#53
    
    Name:    zookeeper.default.svc.cluster.local
    Address: 172.17.0.6
    Name:    zookeeper.default.svc.cluster.local
    Address: 172.17.0.7
    Name:    zookeeper.default.svc.cluster.local
    Address: 172.17.0.8