statefulset和headless service是如何工作的-K8s
How does statefulset and headless service works-K8s
我明白
StatefulSet - manages/maintains 稳定的主机名、网络 ID 和持久存储。 HeadlessService - 您需要为有状态应用程序定义无头服务的稳定网络 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).
我对"Statefull vs Stateless"的看法Apps/components
UI 属于无状态 application/component 因为它不维护任何数据。但它从数据库中获取并显示
DB,Cache(Redis)是Statefullapplication/components,因为要维护数据
我的问题。
Persistence storage in Apps - 为什么我应该考虑将 postgress（例如）部署为 StatefulSet？我可以在 Deployement 中定义 PVs 和 PVC 来将数据存储在 PV 中。即使pods重启，也会获取PV，不会丢失数据。
Network - Redis（例如）应该部署为 StatefulSet，这样即使在 [=] 重启后我们每次都能获得唯一的 "Network ID"/Name 101=]。例如; Redis-0、Redis-1在StatefulSet里，我可以把Redis-0定义为master，所以mastername永远不会变。现在为什么我应该考虑 Headless Service 用于 StatefulSet 个应用程序？我可以直接access/connect PODs 本身，对吗？ Headless Service有什么用？
我听说 Operators，这是管理 StatefulSet 应用程序的最佳方式。我在下面找到了一些例子。为什么这些（或其他一些）部署为 StatefulSet 很重要。例如，Prometheus 或 ElasticSearch；我可以定义PVs和PVC来存储数据而不丢失。
Why/When 我应该关心 StatefulSet 和 Headless Serivice 吗？
在尝试回答您的一些问题之前，我必须添加免责声明：给猫剥皮的方法有很多种。由于我们在这里讨论 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.
如果您的所有 pods 都在所有副本中使用相同的持久卷声明（并且供应商允许这样做），则这适用。如果您尝试根据 Deployment 增加副本数量，您的 pods 将使用完全相同的 PVC。另一方面，api documentation 中定义的 StatefulSet volumeClaimTemplates 允许每个副本拥有自己生成的 PVC，确保为副本集中的每个 pod 单独提供 PV。
Now why should I consider Headless Service for StatefulSet apps?
因为易于发现。同样，您不需要知道在 Headless Service 中有多少个副本，检查服务 DNS 您将获得所有副本（警告 - 那些已经启动并且在那一刻 运行）。您可以手动执行此操作，但在这种情况下，您依赖于副本上 counting/keeping 选项卡的不同机制（例如，副本自行注册到主服务器）。这是 pod discovery with nslookup 的一个很好的例子，它可以阐明为什么无头是一个好主意。
Why those(or some other) are important to deploy as StatefulSet
据我了解，您列出的很多 Operator 都是使用 Deployment 本身部署的。但是它们处理 StatefulSets，所以让我们以 ElasticSearch 为例。如果它没有作为 StatefulSet 部署，你最终会得到两个 pods 目标相同的 PV（如果供应商允许的话），这会严重搞砸事情。使用 StatefulSet，每个 pod 都有自己的持久卷声明（来自模板），因此将持久卷与同一 StatefulSet 中的其他 ElasticSearch pods 分开。这只是冰山一角，因为 ElasticSearch 对于 setup/handling 来说更为复杂，而运营商正在帮助解决这个问题。
Why/When should I care about StatefulSet and Headless Serivice?
在复制 pods 需要彼此独立的 PV（从 PVC 模板创建，并自动配置）的任何情况下，您都应该使用有状态集。
Headless Service 您应该在任何情况下使用，如果您想自动发现该服务下的所有 pods，而不是获取 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
无头服务 - 您将获得每个 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
我明白
StatefulSet- manages/maintains 稳定的主机名、网络 ID 和持久存储。HeadlessService- 您需要为有状态应用程序定义无头服务的稳定网络 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).
我对"Statefull vs Stateless"的看法Apps/components
UI属于无状态 application/component 因为它不维护任何数据。但它从数据库中获取并显示DB,Cache(Redis)是Statefullapplication/components,因为要维护数据
我的问题。
Persistence storage in Apps- 为什么我应该考虑将 postgress（例如）部署为StatefulSet？我可以在Deployement中定义PVs 和PVC来将数据存储在 PV 中。即使pods重启，也会获取PV，不会丢失数据。Network- Redis（例如）应该部署为StatefulSet，这样即使在 [=] 重启后我们每次都能获得唯一的 "Network ID"/Name 101=]。例如;Redis-0、Redis-1在StatefulSet里，我可以把Redis-0定义为master，所以mastername永远不会变。现在为什么我应该考虑Headless Service用于StatefulSet个应用程序？我可以直接access/connect PODs 本身，对吗？Headless Service有什么用？我听说
Operators，这是管理StatefulSet应用程序的最佳方式。我在下面找到了一些例子。为什么这些（或其他一些）部署为StatefulSet很重要。例如，Prometheus或ElasticSearch；我可以定义PVs和PVC来存储数据而不丢失。
Why/When 我应该关心 StatefulSet 和 Headless Serivice 吗？
在尝试回答您的一些问题之前，我必须添加免责声明：给猫剥皮的方法有很多种。由于我们在这里讨论 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.
如果您的所有 pods 都在所有副本中使用相同的持久卷声明（并且供应商允许这样做），则这适用。如果您尝试根据 Deployment 增加副本数量，您的 pods 将使用完全相同的 PVC。另一方面，api documentation 中定义的 StatefulSet volumeClaimTemplates 允许每个副本拥有自己生成的 PVC，确保为副本集中的每个 pod 单独提供 PV。
Now why should I consider Headless Service for StatefulSet apps?
因为易于发现。同样，您不需要知道在 Headless Service 中有多少个副本，检查服务 DNS 您将获得所有副本（警告 - 那些已经启动并且在那一刻 运行）。您可以手动执行此操作，但在这种情况下，您依赖于副本上 counting/keeping 选项卡的不同机制（例如，副本自行注册到主服务器）。这是 pod discovery with nslookup 的一个很好的例子，它可以阐明为什么无头是一个好主意。
Why those(or some other) are important to deploy as StatefulSet
据我了解，您列出的很多 Operator 都是使用 Deployment 本身部署的。但是它们处理 StatefulSets，所以让我们以 ElasticSearch 为例。如果它没有作为 StatefulSet 部署，你最终会得到两个 pods 目标相同的 PV（如果供应商允许的话），这会严重搞砸事情。使用 StatefulSet，每个 pod 都有自己的持久卷声明（来自模板），因此将持久卷与同一 StatefulSet 中的其他 ElasticSearch pods 分开。这只是冰山一角，因为 ElasticSearch 对于 setup/handling 来说更为复杂，而运营商正在帮助解决这个问题。
Why/When should I care about StatefulSet and Headless Serivice?
在复制 pods 需要彼此独立的 PV（从 PVC 模板创建，并自动配置）的任何情况下，您都应该使用有状态集。
Headless Service 您应该在任何情况下使用，如果您想自动发现该服务下的所有 pods，而不是获取 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无头服务 - 您将获得每个 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