我们在Google云平台（托管Kubernetes，GKE）上运行我们的堆栈，并在K8s之外运行Consul集群（常规GCE实例）。
在K8中运行的几个服务使用Consul，主要用于它的CP K / V存储和高级锁定，而不是到目前为止服务发现。
我们最近在K8s中使用 Consul服务发现遇到了一些问题。现在，我们的应用直接与Consul服务器通信，以注册和取消注册他们提供的服务。
这不是推荐的最佳做法，通常Consul客户（即使用Consul的应用）应该与本地 Consul代理商交谈。在我们的设置中，没有当地的Consul代理商。
我的问题：我们应该在每个广告连播中将本地 Consul代理作为 sidekick 容器运行吗？
恕我直言，这将是对资源的巨大浪费，但它会更好地与领事最佳实践相匹配。我尝试在Google上搜索，但所有关于Consul和Kubernetes的帖子都谈到在K8s中运行Consul，这不是我想要做的。
答案 0 :(得分：0)
我不明白来自K8s内部的Consul服务发现是什么意思，但我们也有Consul发现的基于VM的环境可用的服务，几个pod应该访问。
如果你的意思是从K8s pod访问Consul提供的服务，我们通过让我们的内部Kubernetes DNS将consul区域转发给Consul服务器来实现它。因此，我们不会将Consul代理作为每个pod的搭档。
答案 1 :(得分：0)
正如官方Consul Helm图表和文档所建议的那样，标准方法是运行Consul客户端的DaemonSet，然后使用connect-side-car注入器，只需提供pod规范的注释，即可将sidecar注入到您的节点中。这应该处理所有样板，并且符合最佳做法。