IT生产环境中容器编排系统的五个最佳做法

如果您还没有关注容器编排技术，那您需要抓紧了，因为它们和容器技术一样重要。这些产品能够让您进行容器启停调度，并且通过管理容器集群来提升容器使用率。

虽然容器自身是一个非常棒的、分布式且可移植的架构，但是容器编排引擎的重要性在于它能够满足企业需求，因为它解决了容器伸缩问题（至少也解决了一部分）。

因此，当IT运维管理人员和产品开发人员将基于容器的应用程序部署到生存环境时，他们应该考虑的最佳做法是什么？虽然虚拟化技术具有一些现存的运维模式，但IT运维人员很快会发现容器并不是虚拟机。所以事实上并没有太多现存的IT运维方式可供参考。

考虑到这一点，是时候为IT生产环境的容器编排定义一些核心的最佳做法。以下从大多重要步骤中总结了5点。

当处于staging阶段时，它们应该运行在编排系统中，例如Kubernetes，因为这是生产环境配置的准确副本。一旦被证明是稳定的，那么容器可以从staging阶段部署到生产环境。如果新部署出现问题，他们需要随时回滚。在许多情况下，回滚是一个自动过程。

鉴于生产和开发现在已经通过DevOps做法相互联系，自动报告生产环境容器中发现的问题非常重要。

开发人员需要通过连续报告的问题来了解发生了什么问题，并且需要对持续测试、集成和部署的修补程序反馈的问题做出反应，以便在短时间内解决问题。

• 随时间收集详细数据的能力，并使用该数据来发现可能表明容器正在走向失败的趋势。这些工具从容器编排系统中提取数据，例如内存使用情况、处理器、网络、I/O等，并确定了表明系统健康的相关性，包括可能需要注意的系统各个方面。

  
  

• 监测系统具备根据它的发现采取自动行动的能力。例如，如果控制台上出现网络错误，那么关闭疑似这些错误源的集线器能够避免网络完全中断。并且，它允许您通过既定规则在监控软件中设置策略。

有些管理容器编排生产环境的工作人员，对于数据的位置或者数据应该如何备份、保存以及恢复不是很了解。然而无论是否在公有云上，这些需求都必须被处理。

容器，包括编排系统中运行的容器，可以在运行应用程序的容器内存储数据，或者也可以通过基于容器的外部数据库进行存储，但通常不是。无论数据存在哪里，都必须将其复制到次级和独立存储系统，并对其进行保护。

虽然很多人相信公有云已经建立了灾难恢复机制，但在大多数情况下，您可能需要恢复一些意外删除或损坏的数据。虽然公共云确实具有某些故障恢复功能，但您也需要确保这些更细粒度的数据恢复操作已经具备且可用。而且它们不是自动的 您需要设置好它们并进行测试。

此外，许多备份和恢复机制只是对部分用户可用的用户驱动进程。如果你只将控制权限赋予一小部分运维管理人员，你很快会发现开发人员和其他终端用户比想象中更需要进行数据恢复。安全机制和控制管理机制允许那些没有OP权限的工作人员根据企业的政策和规定恢复他们想要恢复的数据。

本文所列所有最佳做法中最重要的是生产能力规划。同样地，本地和基于公共云的系统都需要考虑。

这种做法理论上很简单，但实际上很难实现。对于容器编排系统所需的基础设施而言，您需要了解当前的容量需求。这包括服务器、存储、网络、数据库等。此外，您需要规划短期、中期和长期的需求。

关键在于您需要了解容器、容器编排系统以及任何其他支持系统（例如数据库）之间的相互关系及其对容量的影响。例如，假设您有五个容器编排系统实例，包括2个staging环境和3个生产环境，那么您需要20个特定方式配置的服务器。

这些服务器可以在公共云中进行配置，也可以使用传统方法在物理机上进行配置。当然，这些服务器也有一定需求，包括存储、网络、安全、监控、电源等。您还需要对这些容量进行建模。

公共云用户可以根据他们的需要调整容器容量。然而，这并不能解决所有问题，例如在预算和了解需要使用哪些云服务器等方面。更重要的是，您需要考虑将容器编排系统作为云服务进行提供，因此您对他们的管理可能要少于云服务提供商。

容器时代IT产品取得成功是基于开放思维和尝试新流程与技术的能力。尽管试错方式可能会吓倒IT生产环境中的许多人，但实际情况是您没有选择。

当然，IT生产环境流程不能被夸大，通常每五到十年其流程和工具就会有所变化。IT世界的变化是常事，容器和容器编排的兴起要求您再次进行改变。

负责容器编排生产环境的人员需要明白他们正在打开一扇新的大门，当然他们仍可以依靠以前的方式来学习如何操作这些系统。但考虑到DevOps的兴起以及开发与运维的逻辑耦合，这是您学习新方式并走向正确方向的好时机。