本文讲的是IT生产环境中容器编排系统的五个最佳做法【编者的话】本文主要讲述了生产环境中使用容器编排系统需要注意的5个最佳做法。
【深入浅出学习 etcd】etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。
如果您的企业IT运维组织结构已转移到Docker等容器技术，您可能会在IT生产环境中接触到容器编排系统。 这些系统 包括Apache Mesos、 Google Kubernetes 、Docker Swarm以及其他一些小众编排系统。
如果您还没有关注容器编排技术，那您需要抓紧了，因为它们和 容器技术 一样重要。这些产品能够让您进行容器启停调度，并且通过管理 容器集群 来提升容器使用率。
虽然容器自身是一个非常棒的、分布式且可移植的架构，但是容器编排引擎的重要性在于它能够满足企业需求，因为它解决了容器伸缩问题（至少也解决了一部分）。
IT生产环境的一个普遍问题在于它的任务是在真实环境中运行的，并且需要保证其正常运行，至少在一段时间内需要保证99.99%的时间都正常运行。考虑到市场上多数容器技术都较新，对于容器生产环境的要求就更多了。
因此，当IT运维管理人员和产品开发人员将基于容器的应用程序部署到生存环境时，他们应该考虑的最佳做法是什么？虽然虚拟化技术具有一些现存的运维模式，但IT运维人员很快会发现容器并不是虚拟机。所以事实上并没有太多现存的IT运维方式可供参考。
考虑到这一点，是时候为IT生产环境的容器编排定义一些核心的最佳做法。以下从大多重要步骤中总结了5点。
当处于staging阶段时，它们应该运行在编排系统中，例如Kubernetes，因为这是生产环境配置的准确副本。一旦被证明是稳定的，那么容器可以从staging阶段部署到生产环境。如果新部署出现问题，他们需要随时回滚。在许多情况下，回滚是一个自动过程。
鉴于生产和开发现在已经通过DevOps做法相互联系，自动报告生产环境容器中发现的问题非常重要。
开发人员需要通过连续报告的问题来了解发生了什么问题，并且需要对持续测试、集成和部署的修补程序反馈的问题做出反应，以便在短时间内解决问题。
容器，包括编排系统中运行的容器，可以在运行应用程序的容器内存储数据，或者也可以通过基于容器的外部数据库进行存储，但通常不是。无论数据存在哪里，都必须将其复制到次级和独立存储系统，并对其进行保护。
虽然很多人相信公有云已经建立了灾难恢复机制，但在大多数情况下，您可能需要恢复一些意外删除或损坏的数据。虽然公共云确实具有某些故障恢复功能，但您也需要确保这些更细粒度的数据恢复操作已经具备且可用。而且它们不是自动的 您需要设置好它们并进行测试。
此外，许多备份和恢复机制只是对部分用户可用的用户驱动进程。如果你只将控制权限赋予一小部分运维管理人员，你很快会发现开发人员和其他终端用户比想象中更需要进行数据恢复。安全机制和控制管理机制允许那些没有OP权限的工作人员根据企业的政策和规定恢复他们想要恢复的数据。
这种做法理论上很简单，但实际上很难实现。对于容器编排系统所需的基础设施而言，您需要了解当前的容量需求。这包括服务器、存储、网络、数据库等。此外，您需要规划短期、中期和长期的需求。
关键在于您需要了解容器、容器编排系统以及任何其他支持系统（例如数据库）之间的相互关系及其对容量的影响。例如，假设您有五个容器编排系统实例，包括2个staging环境和3个生产环境，那么您需要20个特定方式配置的服务器。
这些服务器可以在公共云中进行配置，也可以使用传统方法在物理机上进行配置。当然，这些服务器也有一定需求，包括存储、网络、安全、监控、电源等。您还需要对这些容量进行建模。
您需要了解目前生产环境中容器的使用情况，以及未来五年的增长情况。 通过生产环境中容器使用情况的增长预测，您应该可以算出其他基础设施的影响，以及了解其容量问题。这种方式需要被建模，从而增长不会超出预期。
公共云用户可以根据他们的需要调整容器容量。然而，这并不能解决所有问题，例如在预算和了解需要使用哪些云服务器等方面。更重要的是，您需要考虑将容器编排系统作为云服务进行提供，因此您对他们的管理可能要少于云服务提供商。
当然，IT生产环境流程不能被夸大，通常每五到十年其流程和工具就会有所变化。IT世界的变化是常事，容器和容器编排的兴起要求您再次进行改变。
负责容器编排生产环境的人员需要明白他们正在打开一扇新的大门，当然他们仍可以依靠以前的方式来学习如何操作这些系统。但考虑到DevOps的兴起以及开发与运维的逻辑耦合，这是您学习新方式并走向正确方向的好时机。
【深入浅出学习 etcd】etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。
如果您的企业IT运维组织结构已转移到Docker等容器技术，您可能会在IT生产环境中接触到容器编排系统。 这些系统 包括Apache Mesos、 Google Kubernetes 、Docker Swarm以及其他一些小众编排系统。
如果您还没有关注容器编排技术，那您需要抓紧了，因为它们和 容器技术 一样重要。这些产品能够让您进行容器启停调度，并且通过管理 容器集群 来提升容器使用率。
虽然容器自身是一个非常棒的、分布式且可移植的架构，但是容器编排引擎的重要性在于它能够满足企业需求，因为它解决了容器伸缩问题（至少也解决了一部分）。
IT生产环境的一个普遍问题在于它的任务是在真实环境中运行的，并且需要保证其正常运行，至少在一段时间内需要保证99.99%的时间都正常运行。考虑到市场上多数容器技术都较新，对于容器生产环境的要求就更多了。
因此，当IT运维管理人员和产品开发人员将基于容器的应用程序部署到生存环境时，他们应该考虑的最佳做法是什么？虽然虚拟化技术具有一些现存的运维模式，但IT运维人员很快会发现容器并不是虚拟机。所以事实上并没有太多现存的IT运维方式可供参考。
考虑到这一点，是时候为IT生产环境的容器编排定义一些核心的最佳做法。以下从大多重要步骤中总结了5点。
1. 建立生产分界线
虽然这是一种常见的传统做法，但涉及容器的人往往不了解从开发到生产的途径。在进行容器编排时，需要有一个staging平台，通常是在DevOps进程和工具链的末尾。容器需要进行测试、集成、验证，并准备好进行staging。当处于staging阶段时，它们应该运行在编排系统中，例如Kubernetes，因为这是生产环境配置的准确副本。一旦被证明是稳定的，那么容器可以从staging阶段部署到生产环境。如果新部署出现问题，他们需要随时回滚。在许多情况下，回滚是一个自动过程。
2. 自动报告在容器编排生产环境中发现的问题
所有事情都可能会出错，特别是当您考虑容器如何在编排系统中运行时。鉴于生产和开发现在已经通过DevOps做法相互联系，自动报告生产环境容器中发现的问题非常重要。
开发人员需要通过连续报告的问题来了解发生了什么问题，并且需要对持续测试、集成和部署的修补程序反馈的问题做出反应，以便在短时间内解决问题。
3. 监控，监控，监控
运行容器编排系统（无论是在云端还是在本地）的好处是它提供了可以监控容器运行状况的监控和管理工具。这些监控系统具有几个核心功能和优点，包括：- 随时间收集详细数据的能力，并使用该数据来发现可能表明容器正在走向失败的趋势。这些工具从容器编排系统中提取数据，例如内存使用情况、处理器、网络、I/O等，并确定了表明系统健康的相关性，包括可能需要注意的系统各个方面。
- 监测系统具备根据它的发现采取自动行动的能力。例如，如果控制台上出现网络错误，那么关闭疑似这些错误源的集线器能够避免网络完全中断。并且，它允许您通过既定规则在监控软件中设置策略。
4. 自动备份数据，包括灾难恢复和业务连续性
有些管理容器编排生产环境的工作人员，对于数据的位置或者数据应该如何备份、保存以及恢复不是很了解。然而无论是否在公有云上，这些需求都必须被处理。容器，包括编排系统中运行的容器，可以在运行应用程序的容器内存储数据，或者也可以通过基于容器的外部数据库进行存储，但通常不是。无论数据存在哪里，都必须将其复制到次级和独立存储系统，并对其进行保护。
虽然很多人相信公有云已经建立了灾难恢复机制，但在大多数情况下，您可能需要恢复一些意外删除或损坏的数据。虽然公共云确实具有某些故障恢复功能，但您也需要确保这些更细粒度的数据恢复操作已经具备且可用。而且它们不是自动的 您需要设置好它们并进行测试。
此外，许多备份和恢复机制只是对部分用户可用的用户驱动进程。如果你只将控制权限赋予一小部分运维管理人员，你很快会发现开发人员和其他终端用户比想象中更需要进行数据恢复。安全机制和控制管理机制允许那些没有OP权限的工作人员根据企业的政策和规定恢复他们想要恢复的数据。
5. 规划生产能力
本文所列所有最佳做法中最重要的是生产能力规划。同样地，本地和基于公共云的系统都需要考虑。这种做法理论上很简单，但实际上很难实现。对于容器编排系统所需的基础设施而言，您需要了解当前的容量需求。这包括服务器、存储、网络、数据库等。此外，您需要规划短期、中期和长期的需求。
关键在于您需要了解容器、容器编排系统以及任何其他支持系统（例如数据库）之间的相互关系及其对容量的影响。例如，假设您有五个容器编排系统实例，包括2个staging环境和3个生产环境，那么您需要20个特定方式配置的服务器。
这些服务器可以在公共云中进行配置，也可以使用传统方法在物理机上进行配置。当然，这些服务器也有一定需求，包括存储、网络、安全、监控、电源等。您还需要对这些容量进行建模。
您需要了解目前生产环境中容器的使用情况，以及未来五年的增长情况。 通过生产环境中容器使用情况的增长预测，您应该可以算出其他基础设施的影响，以及了解其容量问题。这种方式需要被建模，从而增长不会超出预期。
公共云用户可以根据他们的需要调整容器容量。然而，这并不能解决所有问题，例如在预算和了解需要使用哪些云服务器等方面。更重要的是，您需要考虑将容器编排系统作为云服务进行提供，因此您对他们的管理可能要少于云服务提供商。
试错时间
容器时代IT产品取得成功是基于开放思维和尝试新流程与技术的能力。尽管试错方式可能会吓倒IT生产环境中的许多人，但实际情况是您没有选择。当然，IT生产环境流程不能被夸大，通常每五到十年其流程和工具就会有所变化。IT世界的变化是常事，容器和容器编排的兴起要求您再次进行改变。
负责容器编排生产环境的人员需要明白他们正在打开一扇新的大门，当然他们仍可以依靠以前的方式来学习如何操作这些系统。但考虑到DevOps的兴起以及开发与运维的逻辑耦合，这是您学习新方式并走向正确方向的好时机。
原文链接：5 best practices for container orchestration in IT production（翻译：肖远昊）
原文发布时间为：2017-05-22
本文作者：肖远昊
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：IT生产环境中容器编排系统的五个最佳做法
