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,这不是我想要做的.
正如官方 Consul Helm 图表和文档所表明的,标准方法是运行 Consul 客户端的 DaemonSet,然后使用 connect-side-car 注入器,只需提供 pod 规范的注释即可将 sidecar 注入节点。这应该处理所有样板文件并且符合最佳实践。
| 归档时间: |
|
| 查看次数: |
2715 次 |
| 最近记录: |