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

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/DUOdOzOEJ04pplFH6IvK
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券