Brandwatch如何管理多云生产环境Kubernetes集群

Brandwatch 的工程团队介绍了他们在跨 EKS、GKE 和自管理集群管理多集群 Kubernetes 方面的经验。Brandwatch 在 6 个独立的Kubernetes集群，其中运行着约 150 项生产服务，这些集群运行在AWS EKS、GKE和伦敦自主管理的数据中心里。2016 年初，他们开始在 GKE 上运行这些服务，并且发现这对他们的许多服务都非常适合。他们使用 ConcourseCI 和一些定制工具进行自动化部署，并使用 nginx ingress 控制器对 HTTP 请求/响应进行更多控制。

为了解更多信息，InfoQ 联系了 Brandwatch 应用基础设施工程总监Andy Hume。

虽然 GKE 和 EKS 解决了管理 Kubernetes 控制平面的难题，但 Brandwatch 仍需管理和升级其自主管理的 Kubernetes 集群。Hume 谈到了他们使用的工具：

我们在自己的数据中心里使用Rancher管理Kubernetes集群。在2015/2016年，使用Kubernetes之前，我们已经有了运营Rancher 1的经验，因此，当Rancher 2迁移到Kubernetes时，对于我们最初的实现来说，这似乎是一个明智的起点。然而，当我们计划如何在现有的裸金属基础设施上扩展Kubernetes时，我们可能会寻找复杂性更低的解决方案，并为集成现有网络设计提供更大的灵活性。

Brandwatch 团队广泛使用了 K8S。Hume 解释说，他们并没有在团队中强推任何特定的工具：

我们的开发团队在开发人员工作流方法方面非常的多样化，并且应用程序平台没有针对本地开发强推任何特定的工具或工作流。团队使用了一系列工具来简化开发，包括Skaffold、Telepresence、Docker Compose。

然而，他们的 CI/CD 工作流是标准化的，并且“所有团队都将容器镜像和元数据发布到一个用于管理部署和变更控制的中央系统”，Hume 如是说。

CI/CD在ConcourseCI上进行管理，而它本身就运行在 Kubernetes 上，他们使用一些自定义工具实现了部署的自动化。该团队围绕 kubectl 编写了一个声明性封装器（可作为 YAML 编辑），用于捕获服务元数据。Helm用于模板（但不用于生产部署），与Kustomize一起管理所有集群级服务。该团队将所有 Kubernetes 清单文件保存在一个与应用程序源代码分离的存储库中，这“简化了滚动推出变更的机制”。要回滚到应用程序的旧版本，团队只需部署一个旧版本的清单。Hume 解释说：

当团队部署源代码的新版本（镜像）时，他们通过更新Git中Kubernetes清单中的镜像引用来实现。这是自动的，让部署过程尽可能简单，但这也意味着应用程序源代码和Kubernetes清单之间实际上没有单独的映射。Git中的清单是唯一的真相来源，因此，恢复到旧版本也会回滚镜像标签/版本。

Kubernetes 集群需要 Ingress 来接受来自互联网的流量——管理 Kubernetes 的云供应商将其负载均衡器合并为 Ingress 实现的一部分。这里，你也可以使用自己的负载均衡器，或者自己管理Kubernetes 集群。Brandwatch 工程团队在所有集群（包括 EKS 和 GKE 上的集群）上运行nginx-ingress-controller，绕过了托管的负载均衡器。这使他们可以操作 HTTP 响应报头，添加特定于安全性的报头并删除内部报头。此外，Hume 还说：

最好不要依赖于应用程序本身添加这些报头，而要在一个中心位置进行，以便我们的安全团队在需要时可以进行审计或调整。我们还发现了云HTTP LB的一些其他约束。例如，GCP LB限制传入请求HTTP头的大小，对于我们希望迁移到Kubernetes的一些旧应用程序，这会导致问题。

Brandwatch 在每个集群上都运行Prometheus，使用Prometheus operator进行监控和报警。按照 Hume 的说法，发出告警的主要目标是“关注我们面向客户的应用程序的可用性和正确性，通常，由一个开发团队负责使用 prometheus/alertmanager 栈在我们的每个集群中创建和响应这些告警”。除此之外，Kubernetes 工作负载的总体健康状况也会被监控，作为整个集群健康状况的指示器。Hume 补充道：

一般来说，我们发现GKE和EKS的管理节点是有弹性的，并且在发生故障时很容易管理。如果特定节点上的工作负载出现故障，采取的措施是立即终止该节点，并让集群自动扩展启动一个新节点。我们确实在节点级进行了监控，但是我们不会主动触发任何节点级度量的告警。

尽管 Brandwatch 会在需要时使用 Cluster Autoscaler 来启动节点，但这通常太慢了。他们是使用应用程序逻辑来处理这一问题，在节点（和 pod）启动时进行排队或重试，对于已知的工作负载峰值，他们还会按预期进行扩展。

原文链接：

Managing Multi-Cloud Production Kubernetes Clusters at Brandwatch