所以我要在OpenShift中设置一个NATS集群。通过让每个NATS服务器实例将其Pod IP广播到集群，我可以轻松地使事情工作。我在工作中与之交谈的人强烈建议不要使用Pod IP，并建议使用Pod名称。在电子邮件中，他说了有关是否重新启动Pod的信息。但是就像我尝试删除Pod一样，新的Pod IP位于NATS的连接URL列表中，并且工作正常。我知道Kubernetes拥有DNS，您可以使用无头服务，但对我来说似乎有点不稳定。 Pod IP有效。
答案 0 :(得分：2)
我相信“工作中的家伙”在一定程度上有道理，但是很难说这是在什么程度上进行货物培训，什么才是知识的一半。关键是：吊舱IP不稳定，也就是说，每次吊舱重新启动（在同一节点或其他地方，都没关系）时，它将从分配的吊舱CIDR范围中获取新IP。
现在，服务通过引入虚拟IP（VIP）来提供稳定性：这充当坐在Pod前面的群集内部微型负载平衡器，是的，在通常情况下，建议的与Pod通话的方式是通过服务。否则，您需要跟踪带外的Pod IP，而不是Bueno。
底线：如果NATS帮您管理，跟踪并映射Pod IP，则可以使用它，不会造成任何伤害。
答案 1 :(得分：1)
尽管Michael的回答大部分都是正确的，但重要的是要了解不能100％保证服务IP（即ClusterIP）服务不会更改其IP。在特定情况下（重新创建/删除）服务会导致服务IP更改。
也就是说，对于具有自己的自动发现和/或群集方式的服务而言，情况有所不同。通常，仅提供一次定期服务是不够的或不够的。他们需要连接到种子或发现所有节点等。您可能在这里使用的一种方法是无头服务，这些服务以给定名称返回所有直接Pod IP的完整列表。
请注意，使用headles服务也有其微小的怪癖，即。并非所有软件在初次启动后都会随着时间的推移重新解析DNS，因此最终可能会导致缓存的端点随着时间的推移而变得过时。
您可能还想利用StatefulSets功能为每个Pod（即mypod-1，mypod-2等）保留确定性名称（即网络身份），再结合无头服务，将为每个Pod提供静态信息使用的名称。
我确实认为仅使用Pod IP可能会在一个或多个边缘情况下导致某些问题，因此您至少应将上述解决方案之一用于集群发现/注册。对于在集群中注册Pod的过程中和之后的实际通信，实际上最好使用Pod IP。