我们最近在Kubernetes上构建了一个分布式cron作业调度系统，Kubernetes是一个令人兴奋的容器编排新平台。Kubernetes现在非常流行，并且做出了很多令人兴奋的承诺：最令人兴奋的是工程师不需要知道或关心他们的应用程序运行在什么机器上。分布式系统确实很难，管理分布式系统上的服务是操作团队面临的最困难的问题之一。在生产中开发新软件并学习如何可靠地操作它是我们非常重视的事情。作为一个例子，说明为什么学习操作Kubernetes很重要（为什么很难！），这是一个奇妙的死亡后，一个小时的故障造成的库伯内特斯。在这篇文章中，我们将解释为什么我们选择在Kubernetes之上构建。我们将研究如何将Kubernetes集成到我们现有的基础设施中，我们对Kubernetes集群的可靠性建立信心的方法，以及我们在Kubernetes之上构建的抽象。库伯内特斯是什么？Kubernetes是一个用于调度程序在集群中运行的分布式系统。您可以告诉Kubernetes运行一个程序的五个副本，它会在您的worker节点上动态地调度它们。容器被自动调度以提高利用率和节省资金，强大的部署原语允许您逐步推出新代码，安全上下文和网络策略允许您以安全的方式运行多租户工作负载。Kubernetes内置了很多不同种类的调度功能。它可以调度长时间运行的HTTP服务、在集群中每台机器上运行的守护进程、每小时运行一次的cron作业，等等。库伯内特斯还有很多。如果你想知道更多，Kelsey Hightower已经做了很多精彩的演讲：Kubernetes for sysadmins和healthz：停止逆向工程应用程序和从内部开始监控是两个不错的起点。还有一个伟大的，支持的社区在懈怠。为什么是库伯内特斯？每个基础设施项目（希望如此！）从业务需求开始，我们的目标是提高现有分布式cron作业系统的可靠性和安全性。我们的要求是：我们需要能够在一个相对较小的团队中构建和运营它（只有2个人在项目中全职工作）我们需要在大约20台机器上可靠地安排大约500个不同的cron作业。以下是我们决定在Kubernetes基础上构建的几个原因：我们希望在现有的开源项目的基础上进行构建。Kubernetes包括一个分布式cron作业调度器，因此我们不必自己编写。Kubernetes是一个非常活跃的项目，经常接受捐款。Kubernetes是用Go写的，很容易学。几乎所有的Kubernetes错误修复都是由我们团队中没有经验的Go程序员完成的。如果我们能够成功地操作Kubernetes，我们将来可以在Kubernetes之上构建（例如，我们目前正在开发一个基于Kubernetes的系统来训练机器学习模型）我们之前一直在使用Chronos作为cron作业调度系统，但它不再满足我们的可靠性要求，而且大部分都没有维护（过去9个月有1次提交，最后一次合并拉取请求是在2016年3月），因为Chronos没有被维护，我们决定不值得继续投资改善我们现有的集群。如果你在考虑Kubernetes，请记住：不要仅仅因为其他公司正在使用Kubernetes而使用它。建立一个可靠的集群需要大量的时间，而且使用它的商业案例并不总是显而易见的。把你的时间花在明智的方式上。可靠是什么意思？说到操作服务，可靠这个词本身就没有意义。要谈论可靠性，首先需要建立一个SLO（服务级别目标）。我们有三个主要目标：99.99%的cron作业应该得到调度，并在计划运行时间的20分钟内开始运行。20分钟是一个相当大的窗口，但我们采访了我们的内部客户，他们都没有要求更高的精度。在未完成作业的情况下终止作业（应为99.99%）。我们迁移到Kubernetes不会导致任何客户面临的事件。这意味着：KubernetesAPI中的短时间停机是可以接受的（如果停机10分钟，只要我们能在5分钟内恢复就可以了）调度错误（cron作业运行被完全丢弃而根本无法运行）是不可接受的。我们非常认真地对待调度错误的报告。我们需要小心pod收回和安全终止实例，这样作业就不会太频繁地被终止。我们需要一个好的移民计划。建立Kubernetes集群我们建立第一个Kubernetes集群的基本方法是从头构建集群，而不是使用kubeadm或kops之类的工具（使用Kubernetes的硬方法作为参考）。我们用Puppet配置配置，Puppet是我们常用的配置管理工具。从头开始构建非常棒，原因有两个：我们能够将Kubernetes深入地集成到我们的架构中，并且我们对它的内部结构有了深入的理解。从头开始构建让我们将Kubernetes集成到我们现有的基础设施中。我们希望与我们现有的系统无缝集成，用于日志记录、证书管理、机密、网络安全、监控、AWS实例管理、部署、数据库代理、内部DNS服务器、配置管理等等。整合所有这些系统有时需要一点创造力，但总的来说，要比强迫kubeadm/kops做我们想要的要容易得多。我们已经信任并知道如何操作所有这些现有的系统，所以我们希望在我们新的Kubernetes集群中继续使用它们。例如，安全证书管理是一个非常困难的问题，我们已经有了一种方法来颁发和管理证书。我们能够通过适当的集成避免为Kubernetes创建一个新的CA。我们不得不确切地了解我们设置的参数是如何影响我们的Kubernetes设置的。例如，在配置用于身份验证的证书/ca时，使用了十几个参数。当遇到身份验证问题时，理解所有这些参数可以使调试设置变得更容易。建立对库伯内特斯的信心在我们的Kubernetes工作开始时，团队中没有人以前使用过Kubernetes（除了在某些情况下用于玩具项目）。如何从"我们都没有使用过Kubernetes"到"我们有信心在生产中运行Kubernetes"？策略0：与其他公司对话我们向其他公司的一些人询问了他们在库伯内茨的经历。他们都以不同的方式或在不同的环境中使用Kubernetes（在裸机上运行HTTP服务，在googlekubernetes引擎上，等等）。尤其是在谈到像Kubernetes这样的大型复杂系统时，重要的是要批判性地思考自己的用例，做自己的实验，对自己的环境建立信心，并做出自己的决定。例如，你不应该在阅读这篇博文后得出这样的结论："好吧，Stripe成功地使用了Kubernetes，所以它对我们也有用！"以下是我们在与运营Kubernetes集群的几家公司交谈后了解到的：优先考虑etcd集群的可靠性（etcd是存储Kubernetes集群所有状态的地方）一些Kubernetes特性比其他特性更稳定，所以要小心alpha特性。有些公司只在稳定了不止一个版本之后才使用稳定的特性（例如，如果某个特性在1.8版本中变得稳定，那么他们会等到1.9或1.10之后再使用它）考虑使用像GKE/AKS/EKS这样的托管Kubernetes系统。从头开始建立一个高可用性Kubernetes系统是一项巨大的工作。AWS在这个项目中没有托管的Kubernetes服务，所以这不是我们的选择。小心重叠网络/软件定义的网络带来的额外网络延迟。当然，与其他公司的谈话并没有给我们一个明确的答案，关于库伯内特斯是否会为我们工作，但它确实给了我们一些问题要问，一些事情需要谨慎。策略一：读代码我们计划非常依赖Kubernetes的一个组件，cronjob控制器。这个组件当时在阿尔法，这让我们有点担心。我们已经在一个测试集群中进行了测试，但是我们如何判断它在生产中是否适用呢？谢天谢地，cron作业控制器的所有核心功能都只是400行Go。快速阅读源代码可以看出：cron作业控制器是一个无状态服务（就像其他Kubernetes组件一样，除了etcd）。每隔10秒，这个控制器调用syncAll函数：go等等，直到(吉咪。西考尔，10*时间。秒，停止）syncAll函数从kubernetesapi获取所有cron作业，遍历该列表，确定下一次运行哪些作业，然后启动这些作业。核心逻辑似乎相对容易理解。更重要的是，我们觉得如果这个控制器中有一个bug，它可能是我们可以自己修复的。策略2：进行负载测试在我们开始认真构建集群之前，我们做了一些负载测试。我们并不担心Kubernetes集群可以处理多少节点（我们计划部署大约20个节点），但我们确实希望确保Kubernetes能够处理尽可能多的cron作业（大约每分钟50个）。我们在一个3节点集群中运行了一个测试，在这个集群中我们创建了1000个cron作业，每个作业每分钟运行一次。每个作业都只需运行bash-c"echo hello world"。我们选择简单作业是因为我们想测试集群的调度和编排能力，而不是集群的总计算能力