自动化管理大规模生产级Kubernetes的七个方法

Kubernetes开源容器编排引擎不是一个管理平台，也不应该被误认为是一个管理平台。编排的要点在于，可靠地让自动化系统能够便于大规模部署和管理应用程序，不需要在每个步骤都有人干预。如果你使用的面向Kubernetes的工具不支持自动化，那么你没有真正利用编排的好处。

作者：布加迪编译来源：51CTO.com|2018-01-30 13:45: 收藏

分享

【新品产上线啦】51CTO播客，随时随地，碎片化学习

【51CTO.com快译】Kubernetes开源容器编排引擎不是一个管理平台，也不应该被误认为是一个管理平台。编排的要点在于，可靠地让自动化系统能够便于大规模部署和管理应用程序，不需要在每个步骤都有人干预。如果你使用的面向Kubernetes的工具不支持自动化，那么你没有真正利用编排的好处。

为此，这七个方法可以让你自动管理生产环境的Kubernetes集群。

1.日志

任何Kubernetes生产环境都将高度依赖日志。在Kenzan，我们通常会努力将平台日志与应用程序日志分开来。这可以通过全然不同的工具和应用程序来做到，甚至通过日志本身里面的过滤和标记来做到。与任何分布式系统一样，日志为准确跟踪特定的调用提供了重要的证据，即使它们针对不同的微服务，那样就能查明根本原因。

2.自我修复

我们认为，要是没有自我修复功能，你的系统几乎不可能获得很长的正常运行时间，尤其是在分布式环境中。Kubernetes可以定期监测pod和容器的健康状况，立即采取措施解决遇到的问题。Kubernetes可直接识别的两种对象类型是pod状态(podstatus)和容器状态(containerstatus)。

容器探针(livenessProbe和readinessProbe)让你可以定义希望Kubernetes如何监测容器是否处于活动状态且准备就绪。readiness probe(就绪探针)尤其有用，因为如果探针失效，它实际上会让pod处于运行状态，但并不传送任何流量。

不过要注意，虽然每半小时重启之类的自我修复功能很有用，但也可能会掩盖应用程序的问题。你需要足够强大，能够发现出现的任何问题的监测和日志功能。

3.弹性测试

弹性测试应该是你平台的一部分，这取决于你应用程序的要求(比如99.999%的正常运行时间)。应用程序任何级别的失效都应该可以恢复，那样没人会遇到任何停机时间。根据我们的经验，如果开发团队事先知道他们的开发工作会接受广泛的弹性测试，才有可能开发出可靠的应用程序。

虽然你可以通过最简单的手动方法进行一种弹性测试，比如手动关闭数据库或随机终结pod，但我们的经验证明，这些方法在实现自动化后有效得多。虽然Netflix的Chaos Monkey是一种在亚马逊网络服务中运行的非常强大的、极其有用的弹性测试工具，但它不是为Kubernetes构建的。幸好，Kubernetes领域出现了新兴的弹性测试框架，其中两个框架是fabric8 Chaos Monkey(fabric8集成开发环境的一部分)和kube-monkey。

4.例行审计

无论你落实了多少制衡措施，你的Kubernetes生产环境都将得益于例行维护和审计。例行审计将涵盖平常监测涵盖不了的方面。传统上，审计是作为手动过程进行的，而这个领域的自动化工具在迅速而显著地改进。

5.自动扩展

对于Kubernetes来说，扩展通常意味着两者之一：

扩展pod
扩展集群内的节点

扩展pod绝对是最常见的扩展形式。这将添加更多的服务实例，让它们准备开始接受流量。通常，pod级别的扩展使用Heapster度量标准来执行，确定是否需要创建新实例。我们通常实际上将最小pod数量设置得很低，让Kubernetes Horizontal Pod Autoscaler正确设置最小副本数量。我们的确始终将最小值设置成大于每个群集一个副本，以免出现单点故障情况。

扩展节点属于比较少见的情形，但对于高度弹性的应用程序来说是一种非常有用的扩展机制。节点扩展需要底层IaaS(AWS和GCP等)来扩展，并注册到Kubernetes集群。这个过程可以采用手动操作，不过我们不建议这么做。通常我们使用可以自动扩展单个节点的工具。节点级别的自动扩展器将执行两个主要操作，第一个是需要时添加更多节点，第二个是删除未充分利用的节点。

6.资源配额

资源配额让你可以限制Kubernetes平台里面的命名空间，确保一个应用程序不会占用所有资源，不会影响其他应用程序。设置资源配额可能有点困难。根据我们的经验，按预期负载来划分命名空间，并使用一个比率来计算集群的百分比是最稳妥的方法。运行Heapster就可以使用kubectl top {node | pod}命令，该命令显示当前节点或pod的资源使用情况，这有时还有助于配额。之后，使用监视和审计来确定你的分区是否正确。

7.容器资源约束

搞清楚单个容器或pod需要多少资源可以说已成了一门艺术。过去，开发团队估计的资源比实际需要的资源多得多。我们试图执行某种级别的负载测试，观察故障切换是如何进行的，然后适当地分配资源。Netflix称这个方法为“挤压测试”(squeeze testing)。

原文标题：7 WAYS TO AUTOMATE KUBERNETES AT SCALE IN PRODUCTION，作者：Craig Martin

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】

【编辑推荐】

【责任编辑：未丽燕 TEL：（010）68476606】