有状态集和无头服务如何工作 - K8s

Question

我明白了

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

来自 K8s 文档 -> 有时您不需要或不需要负载平衡和单个服务 高原油在这种情况下，您可以通过指定来创建"无外设"服务 "无"表示群集 IP (.spec.clusterIP)。

我对"有状态与无状态"应用程序/组件的看法

1. UI属于无状态应用程序/组件，因为它不维护任何数据。但它来自数据库和显示器

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

我的问题。

1. Persistence storage in Apps- 为什么我应该考虑将后退(例如)部署为StatefulSet？我可以在Deployement中定义PVs和PVC，以将数据存储在PV中。即使 Pod 重新启动，它也会得到 PV，因此不会丢失数据。

2. Network- Redis(例如)应该部署为StatefulSet，这样即使在重新启动 pod 后，我们每次都可以获得唯一的"网络 ID"/名称。例如;Redis-0，Redis-1在StatefulSet，我可以Redis-0定义为主人，所以主人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 Serivice？

Answer 1

在尝试回答您的一些问题之前，我必须添加免责声明：有不同的方法可以剥猫皮。由于我们在这里讨论的是有状态集，请注意并非所有方法都最适合所有有状态应用程序。如果您需要具有单个 PV 的单个数据库 pod，您可以使用一种方法，如果您的 api pod 需要一些共享和一些分离的 PV，那么另一种，依此类推。

应用中的持久性存储 - 为什么应考虑将后gress(例如)部署为 StatefulSet？我可以在部署中定义 PV 和 PVC，以将数据存储在 PV 中。

如果所有 Pod 都在所有副本中使用相同的持久卷声明(并且配置程序允许这样做)，则此情况成立。如果尝试根据部署增加副本数，则所有 Pod 都将使用相同的 PVC。另一方面，API 文档中定义的 StatefulSetvolumeClaimTemplates允许每个副本都有自己生成的 PVC，从而保护副本集中每个 Pod 的单独预配的 PV。

现在，为什么我应该考虑为有状态集应用提供无外设服务？

因为易于发现。同样，您不需要知道无头服务中有多少副本，检查服务 DNS，您将获得所有副本(警告 - 当时已启动并运行)。您可以手动执行此操作，但在这种情况下，您依赖于对副本进行计数/保留选项卡的不同机制(例如，副本是自行注册到主副本的)。这是使用 nslookup 发现 pod 的一个很好的例子，它可以阐明为什么无头是一个好主意。

为什么这些(或其他一些)对于部署为 StatefulSet 很重要

据我了解，您列出的许多操作员都是使用部署本身部署的。不过，它们处理 StatefulSets，所以让我们以 ElasticSearch 为例。如果它没有部署为 StatefulSet，您最终会得到两个针对同一 PV 的 Pod(如果配置器允许的话)，这会严重搞砸事情。使用 StatefulSet，每个 Pod 都会获得自己的持久卷声明(从模板)，从而将持久卷与同一 StatefulSet 中的其他 ElasticSearch Pod 分开。这只是冰山一角，因为 ElasticSearch 在设置/处理方面更加复杂，操作员正在提供帮助。

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

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

• 无头服务，您应该在想要自动发现服务下的所有 Pod 的情况下使用，而不是在获得 ClusterIP 的常规服务中使用。从上面提到的示例中可以看出，服务(使用 ClusterIP)和无头服务(不使用 ClusterIP)的 DNS 条目之间的差异：

  • 标准服务 - 您将获得群集 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: 10.0.0.213
    

  • 无头服务 - 您将获得每个 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