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

Question

我明白

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

FROM K8s Docs->有时您不需要或不需要负载平衡和单个服务IP。在这种情况下，可以通过为群集IP（.spec.clusterIP）指定“无”来创建“无头”服务。

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

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

2. DB，Cache（Redis的）是有状态应用/组件，因为它具有保持数据的

我的问题。

1. Persistence storage in Apps-为什么要考虑将postgress（例如）部署为StatefulSet？我可以定义PVS和PVC在Deployement将数据存储在PV。即使Pod重新启动，它也会获得PV，因此不会丢失数据。

2. Network-Redis（例如）应该以部署StatefulSet，这样即使在重启Pod之后，我们也可以每次都获得唯一的“网络ID” /名称。例如; Redis-0，Redis-1是StatefulSet的，我可以定义Redis-0为主，所以主name永远不会改变。现在为什么要考虑Headless Service使用StatefulSet应用程序？我可以直接访问/连接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

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

Apps中的持久性存储-为什么我应该考虑将Postgress（例如）部署为StatefulSet？我可以在“部署”中定义PV和PVC，以将数据存储在PV中。

如果您的所有Pod在所有副本中都使用相同的持久卷声明（并且预配器允许），则适用。如果您尝试根据“部署”增加副本数，则所有吊舱将使用完全相同的PVC。在另一方面，StatefulSet中定义的API文档已经volumeClaimTemplates允许每个副本具有自己生成的PVC，分别固定配置的PV在副本集合中的每个吊舱。

现在，为什么我应该考虑为StatefulSet应用提供无头服务？

因为容易发现。同样，您无需知道Headless Service中有多少个副本，只需检查服务DNS，即可获取所有副本（caveat-当时已启动并正在运行）。您可以手动执行此操作，但是在这种情况下，您依赖于对副本上的选项卡进行计数/保留选项卡的不同机制（例如，副本是自行注册到主数据库的）。这是使用nslookup进行Pod发现的一个很好的例子，可以阐明为什么无头可能是个好主意。

为什么这些（或其他一些）作为StatefulSet部署很重要

据我了解，您列出的操作员非常多是使用“部署”本身进行部署的。它们虽然处理StatefulSets，所以让我们考虑以ElasticSearch为例。如果未将其部署为StatefulSet，则最终将有两个针对同一PV的Pod（如果预配器允许），这将使事情严重混乱。使用StatefulSet，每个Pod都有其自己的持久卷声明（从模板），因此持久化卷与同一StatefulSet中的其他ElasticSearch Pod分开。这只是冰山一角，因为ElasticSearch的设置/处理更为复杂，而运营商正在为此提供帮助。

为什么/何时应该关心StatefulSet和无头服务？

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

• 在任何情况下，如果您想自动发现该服务下的所有Pod，都应该使用无头服务，而常规服务则是使用ClusterIP。作为上述示例的说明，此处是服务（带有ClusterIP）和无头服务（没有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
    

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