[我在Kafka中使用Kubernetes的大多数示例都是将其部署为headless service，但我还无法获得为什么它应该无头而不是Cluster IP的答案？在我看来，IP提供了负载平衡，在这种情况下，我们确保开箱即用的是，不仅broker之一总是总是加载其资源，就像我无头的Kafka客户端看到的那样，无论是Sarma还是Java客户端尝试总是从DNS lookup中选择第一个IP并连接到它，如果大约有100多个客户端尝试这样做并打开与第一个IP的连接，这不会成为瓶颈吗？或Kafka已经处理了这个内置函数，而我仍在尝试了解它是如何发生的。
[当服务的各个实例（为无状态应用程序服务的Pod的副本）之间没有区别时，您可以在ClusterIP服务下公开它们，因为可以连接到任何副本以服务当前请求。有状态服务（例如Kafka，数据库等）不是这种情况。每个实例负责自己的数据。每个实例可能拥有不同的分区/主题等。服务的实例不是精确的“副本”。在Kubernetes上运行此类有状态服务的解决方案通常使用无头服务和/或状态集，以便该服务的每个实例都有唯一的标识。这种有状态的应用程序具有自己的群集技术，该技术依赖于群集中具有唯一标识的每个实例。
现在，您知道为什么有状态应用程序需要稳定的身份，以及无头服务的有状态集如何提供稳定的身份，您可以检查您的Kafka发行版可能如何使用它们在kubernetes上运行Kafka。
This blog post explains how strimzi does it:
对于StatefulSets – Strimzi用来运行Kafka经纪人–您可以使用Kubernetes无头服务为每个Pod提供一个稳定的DNS名称。 Strimzi使用这些DNS名称作为广告卡夫卡经纪人的地址。因此，使用Strimzi：
初始连接是通过常规Kubernetes服务完成的，获取元数据。
后续连接使用DNS打开另一个无头的Kubernetes服务为豆荚指定的名称。