Brandwatch 的工程团队介绍了他们在跨 EKS、GKE 和自管理集群管理多集群 Kubernetes 方面的经验。Brandwatch 在 6 个独立的Kubernetes集群，其中运行着约 150 项生产服务，这些集群运行在、和伦敦自主管理的数据中心里。2016 年初，他们开始在 GKE 上运行这些服务，并且发现这对他们的许多服务都非常适合。他们使用 ConcourseCI 和一些定制工具进行自动化部署，并使用 nginx ingress 控制器对 HTTP 请求/响应进行更多控制。
为了解更多信息，InfoQ 联系了 Brandwatch 应用基础设施工程总监。
虽然 GKE 和 EKS 解决了管理 Kubernetes 控制平面的难题，但 Brandwatch 仍需管理和升级其自主管理的 Kubernetes 集群。Hume 谈到了他们使用的工具：
Brandwatch 团队广泛使用了 K8S。Hume 解释说，他们并没有在团队中强推任何特定的工具：
然而，他们的 CI/CD 工作流是标准化的，并且“所有团队都将容器镜像和元数据发布到一个用于管理部署和变更控制的中央系统”，Hume 如是说。
CI/CD在ConcourseCI上进行管理，而它本身就运行在 Kubernetes 上，他们使用一些自定义工具实现了部署的自动化。该团队围绕 kubectl 编写了一个声明性封装器（可作为 YAML 编辑），用于捕获服务元数据。用于模板（但不用于生产部署），与一起管理所有集群级服务。该团队将所有 Kubernetes 清单文件保存在一个与应用程序源代码分离的存储库中，这“简化了滚动推出变更的机制”。要回滚到应用程序的旧版本，团队只需部署一个旧版本的清单。Hume 解释说：
Kubernetes 集群需要 Ingress 来接受来自互联网的流量——管理 Kubernetes 的云供应商将其负载均衡器合并为 Ingress 实现的一部分。这里，你也可以使用自己的负载均衡器，或者自己管理Kubernetes 集群。Brandwatch 工程团队在所有集群（包括 EKS 和 GKE 上的集群）上运行nginx-ingress-controller，绕过了托管的负载均衡器。这使他们可以操作 HTTP 响应报头，添加特定于安全性的报头并删除内部报头。此外，Hume 还说：
Brandwatch 在每个集群上都运行Prometheus，使用Prometheus operator进行监控和报警。按照 Hume 的说法，发出告警的主要目标是“关注我们面向客户的应用程序的可用性和正确性，通常，由一个开发团队负责使用 prometheus/alertmanager 栈在我们的每个集群中创建和响应这些告警”。除此之外，Kubernetes 工作负载的总体健康状况也会被监控，作为整个集群健康状况的指示器。Hume 补充道：
尽管 Brandwatch 会在需要时使用 Cluster Autoscaler 来启动节点，但这通常太慢了。他们是使用应用程序逻辑来处理这一问题，在节点（和 pod）启动时进行排队或重试，对于已知的工作负载峰值，他们还会按预期进行扩展。
原文链接：
Managing Multi-Cloud Production Kubernetes Clusters at Brandwatch
