大规模 Kubernetes 集群在Datadog上应用的艰辛之路

大规模 Kubernetes 集群在Datadog上应用的艰辛之路

来自 Datadog 的 Laurent Bernaille 在柏林举行的 Velocity 会议上讨论了运维大型自管理 Kubernetes 集群所面临的挑战。Bernaille专注于如何配置弹性和可扩展的控制平面，为何和如何频繁地循环更新证书以及在Kubernetes中使用网络插件进行有效通信的需求。

传统的架构方法是将所有Kubernetes主组件都包含在一台服务器中，并至少具有三台服务器以实现高可用性。但是，这些组件具有不同的职责，因此可以或不需要以相同的方式进行扩展。例如，调度器（scheduler）和控制器（controller）是无状态的组件，这使得它们很易于扩展。但是，etcd 是有状态的，需要数据的冗余备份。同时，像调度器这样的组件会与一个选举机制协作，确保只有一个实例是处于激活状态的。Bernaille 认为扩展调度器并没有什么意义。

因此，Datadog决定在具有不同资源的不同服务器中拆分Kubernetes组件，并配置自定义扩展策略。对于API服务器之类的组件，他们在其前面放置了一个负载均衡器，以正确分配请求。对于etcd服务器，他们也将其拆分以专用于一个etcd集群仅处理Kubernetes事件。

Bernaille表示，Kubernetes使用加密和x509证书在其所有组件之间进行通信。因此，为避免证书出现问题（例如到期），Datadog决定每天轮换证书。但是，轮流更新证书是一项很具挑战性的任务，因为 Kubernetes 需要在不同的组件和服务器上安装和使用不同的证书。同时，Datadog 意识到在每次轮流更新之后，他们必须要重新启动像 API 服务器这样的组件。因此，Datadog 决定将每天的证书轮流更新自动化并把该任务交给 HaschiCorp Vault 来实现。

但是，由于kubelet按需生成证书的方式，Datadog决定在kubelet的每日轮换中添加例外规则。尽管面临挑战和复杂性，Bernaille建议经常轮换证书。这不是一件容易的事，但是用户将来可以在证书过期时避免出现问题，更糟糕的是在日志中可能并没有证书过期的明显标志。

Bernaille还提到Datadog面临网络挑战，因为它们需要大量服务器来运行其平台。Bernaille 花了一些时间阐述 Kubernetes 节点会有一个 IP 地址的范围，它们被用来给 pod 分配 IP 地址。因此，对于小型集群来说，使用静态路由实现 pod 之间的通信能够运行地非常好。但是，对于中等规模的集群来说，一种有效的方式就是使用网络覆盖（networking overlays），在这种方式中，节点通过隧道进行通信。在Datadog，有效的方式是在整个网络中，为pod 分配一个可路由的IP。通过这种方式，到pod 的通信是直接连接的，不再需要像kube-proxy 这样的中介。 GCP 以 IP 别名的方式支持该模型， AWS 也以弹性网络接口（elastic network interface，ENI）的形式提供了支持，对于企业的内建集群，用户可以使用像 Calico 这样的工具。

最后，Bernaille 谈到了跨不同集群的交流。默认情况下，在 Kubernetes 中，当一个外部请求到达集群时，Kubernetes 会通过 kube-proxy 来路由流量。但是，如果请求到达了一个不正确的节点，目标 pod 并没有运行，那么 kube-proxy 必须将请求重定向到正确的节点。另一种解决方案是创建一个外部流量策略或者使用ingress 控制器，但是该方案并不适用于大规模集群。因此，Datadog 借助 AWS 中的 ALB ingress 控制器针对 HTTP 通信实现了原生路由。

Bernaille 最后说，他们在 DNS、有状态应用和应用部署方面还面临着其他的挑战，但是他没有足够的时间来深入讨论这些话题。不过，他推荐观看 Jerome Petazzoni 关于 Kubernetes 内部核心的演讲以及更早的关于 Datadog 使用 Kubernetes 艰辛之路的演讲。