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