Datadog 使用大规模 Kubernetes 集群的艰辛之路

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

传统的架构方式会将所有的 Kubernetes master 组件都放到同一台服务器上，并且至少有三台这样服务器来保持高可用性。但是，这些组件有不同的职责，不能或者不需要以相同的方式进行扩展。举例来说，调度器（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艰辛之路的演讲。

原文链接：

Kubernetes the Very Hard Way With Large Clusters at Datadog