来自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

创作场景

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