时间戳

首页 > 解决方案 > Kubernetes 为所有 Pod 提供服务，另一个只为领导者提供服务

kubernetes - Kubernetes 为所有 Pod 提供服务，另一个只为领导者提供服务

问题描述

在 Kubernetes 中，是否可以为单个部署提供 2 个服务，一个是“标准”服务，在所有准备好的 pod 前面代理，另一个服务只发送选定的领导者？如果有怎么办？我正在使用client-go进行领导者选举。这些是第 4 层服务。

我知道服务可以使用标签作为选择器，但 client-go 使用注释来标记领导者。使用没有选择器的服务并在领导者回调中创建/删除端点似乎是 hacky/buggy。谢谢你。

标签： kubernetesclient-goleader-election

解决方案

在 Kubernetes 中，是否可以为单个部署提供 2 个服务，一个是“标准”服务并在所有准备好的 pod 前面代理，另一个服务仅发送选定领导者的流量？

是的，但它似乎有点hacky。服务的工作方式是这样的：

服务 -> 服务标签选择端点 -> 端点 -> 端点标签选择 Pod -> Pods (PodIP)

  1. 因此，您可以拥有指向 Deployment 或 StatefulSet 上的所有 pod 的常规“服务”，它会自动配置所有端点。

  2. 您还可以单独手动创建另一组“无头服务” + “端点” ，使它们的标签相互匹配，然后让该端点与您选择的 pod 的标签手动匹配。

现在关于client-go/leaderelection。似乎它为领导者使用Endpoint或ConfigMap锁（该示例显示了ConfigMap锁）。但是，看起来你想使用端点锁。所以这个包不适用于服务或标签，看起来它只适用于端点资源。所以本质上，如果你有 3 个节点并且想要找到领导者，你将不得不使用 3 个手动创建的端点资源。领导者将始终具有注释。

现在你如何将它与上面的 2) 联系起来？当您的客户选举或选择领导者时，您还必须更改端点标签，以便它们与您手动创建的无头服务相匹配。（也可以在您的代码中完成）

您也可以选择只使用上面的端点 2)（无无头服务），并让 client-go/leaderelection 直接与端点对话。

另一种选择是利用StatefulSets及其所需的无头服务。因此，该服务将解析为基于仲裁的集群中所有副本的 IP 地址。领导者选举将取决于客户端包（client-go 似乎不支持这一点），这对于大多数基于仲裁的应用程序（K8s、Zookeeper、Kafka、Etcd 等）来说都是如此；客户是找到领导者的人。

✌️

推荐阅读