|
|
|
|
移动端

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

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

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

有奖调研 | 1TB硬盘等你拿 AI+区块链的发展趋势及应用调研


【51CTO.com快译】Kubernetes开源容器编排引擎不是一个管理平台,也不应该被误认为是一个管理平台。编排的要点在于,可靠地让自动化系统能够便于大规模部署和管理应用程序,不需要在每个步骤都有人干预。如果你使用的面向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】

【编辑推荐】

  1. 看来Kubernetes将一统天下?Docker也无法幸免
  2. Docker也开始原生支援Kubernetes
  3. 去哪儿网基于Kubernetes/Ceph的GPU云平台实践
  4. AWS发布两个新的容器功能-AWS云上托管的 Kubernetes弹性容器服务(EKS)和AWS Fargate
  5. 为什么容器将统治云端:Kubernetes的崛起
【责任编辑:未丽燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

非常网管——网络应用

在网络应用越来越复杂的今天,传统的网络应用已经不能满足企业和用户的需要,这就对网络管理员、信息管理部门提出了更高的要求。本书介绍了...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊