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

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

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

[[218766]]

为此,这七个方法可以让你自动管理生产环境的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】

责任编辑:未丽燕 来源: 51CTO.com
相关推荐

2022-06-09 13:45:18

vivoK8S集群Kubernetes

2023-01-09 15:20:16

2022-06-10 07:25:41

测试自动化趋势

2024-03-08 13:13:05

人工智能自动化

2022-05-13 09:16:49

Python代码

2021-07-26 05:33:59

自动化领导CIO

2022-06-09 10:57:29

人工智能自动化招聘

2021-07-23 11:08:12

自动化

2023-12-21 18:01:58

Docker容器部署

2021-02-02 10:24:57

CIO数据管理IT

2023-11-01 18:01:02

改进WakaTime编程

2022-03-25 08:00:00

Kubernetes备份集群

2022-04-02 10:42:04

数据管理数据管理现代化CIO

2016-01-29 20:23:23

华为

2022-09-14 12:26:13

质量管理企业关系管理

2015-12-30 14:50:45

Kubernetes容器技术Docker

2020-12-09 13:18:32

数字化转型敏捷性IT

2020-02-17 08:00:02

云计算云开发Kubernetes

2022-07-29 11:03:03

Kubernetes应用安全

2018-12-06 10:17:10

点赞
收藏

51CTO技术栈公众号