我们应该在每个Pod中运行一个Consul容器吗?

tex*_*tex 6 service-discovery kubernetes consul

我们在Google云平台(托管的Kubernetes,GKE)上运行我们的堆栈,并在K8s之外运行Consul集群(常规GCE实例).

在K8中运行的几个服务使用Consul,主要用于它的CP K/V存储和高级锁定,而不是到目前为止服务发现.

我们最近遇到了一些使用K8内部Consul服务发现的问题.现在,我们的应用程序直接与Consul服务器通信,以注册和取消注册他们提供的服务.

这不是推荐的最佳实践,通常Consul客户(即使用Consul的应用程序)应该与当地的 Consul代理商交谈.在我们的设置中,没有当地的Consul代理商.

我的问题:我们是否应该将本地 Consul代理作为每个pod中的sidekick容器运行?

恕我直言,这将是对资源的巨大浪费,但它将更好地匹配领事最佳实践.

我尝试在Google上搜索,但所有关于Consul和Kubernetes的帖子都谈到在K8s中运行Consul,这不是我想要做的.

tst*_*rzl 1

正如官方 Consul Helm 图表和文档所表明的,标准方法是运行 Consul 客户端的 DaemonSet,然后使用 connect-side-car 注入器,只需提供 pod 规范的注释即可将 sidecar 注入节点。这应该处理所有样板文件并且符合最佳实践。