StatefulSet

StatefulSet

关注
发信
关注(28)粉丝(399)

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

我明白

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



    • 我对“有状态 vs 无状态”应用程序/组件的看法
  • UI 属于无状态应用程序/组件，因为它不维护任何数据。但它从数据库获取并显示
  • DB , Cache (Redis) 是有状态的应用程序/组件，因为它必须维护数据

    • 我的问题。
  • Persistence storage in Apps - 为什么我应该考虑将 postgress(例如)部署为 StatefulSet ？我可以在 PV 中定义 PVC s 和 Deployement 来存储 PV 中的数据。即使 pods 重启，它也会获得 PV，因此不会丢失数据。
  • Network - Redis(例如)应该部署为 StatefulSet ，这样即使在 pod 重新启动后，我们也可以每次都获得唯一的“网络 ID”/名称。例如; Redis-0 , Redis-1 都在 StatefulSet 中，我可以将 Redis-0 定义为 master，所以 master name 永远不会改变。现在为什么我应该考虑 Headless Service 用于 StatefulSet 应用程序？我可以直接访问/连接 POD 本身，对吗？ Headless Service 有什么用？
  • 我听说过 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 ？

    最佳答案

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



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



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



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


  • 有状态集，您应该在复制的 pod 需要彼此具有单独 PV(从 PVC 模板创建并自动配置)的任何情况下使用。
  • Headless Service 在您想要自动发现服务下的所有 pod 的任何情况下都应该使用，而不是在常规服务中获得 ClusterIP。作为上面提到的 example 的一个说明，这里是 Service(带 ClusterIP)和 Headless Service(不带 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

    • 10-07 14:55
    Powered by LMLPHP ©2024 StatefulSet 0.039228