“每个微效劳都需求与管理运用顺序共享其形状。这可以决议微效劳的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如，一旦微效劳不报告或许正在被超载，就可以用一个新效劳交流或许被复制。”

4.制定一套最低限制的运营才能

一个容器管理平台不会为你做一切的任务。Retriever Communications首席技术官Nic Grange 说，除了像Kubernetes这样的编排系统之外，还需求确保每个容器化的微效劳都遵照“最低限制的运营才能”，以便在这样的环境下运转良好。他提供了以下这些功用的关键示例列表：

编排系统需求可以拜访每个微效劳上的API，确定它能否预备好接纳流量，以及能否安康。需哀告知微效劳何时正常封锁的办法。需求微效劳地下目的和日志记载。在大少数状况下，微效劳需求可以水平扩展，并且在某些状况下具有集群看法。

Grange也为开发人员分享了一些好音讯：特定言语的微效劳模板库(如go-kit for Go)和dropwizard for Java，可以节省少量的开发这些最低功用的前期任务。

Grange说：“这些让开发人员更容易做正确的事情，取得许多开箱即用的功用，而不必编写更多的代码。

5.实施继续集成和继续交付

Sungard Availability Services CTO& 初级架构师 Kevin McGrath 表示，继续集成和继续交付实际关于基于容器的微效劳的长期管理是一个庞大的益处，尤其是作为支撑企业编排工具的基础。

McGrath说：“假设没有CI / CD，微效劳的维护将会由于手动流程而变得不堪重负，无法按预期停止扩展，并且最终将比基础设备和人力资源中的全体运用成本更高。”

随着时间的推移，CI / CD将协助团队释放编排或管理工具的潜力，尤其是在管理如何在主机池中分配CPU，内存和存储时。

McGrath解释说：“一旦CI / CD成为产品生命周期一个自然的组成部分，管理系统就十分好，它们处置各种基础架构需求，并将其作为工程师的逻辑配置参数。“关于运维来说，要片面了解主机，容器和效劳的资源消耗状况，以便更好地了解需求更多资源的位置。当效劳不再与特定的基础设备绑定，而是与基础设备需求相联络时，这一点十分重要。”

6.不断重新审视并重新投资业务

容器和微效劳不是与日俱增的技术。DigitalOcean公司的工程经理 Mac Browning 建议说，为了正确运用他们，需求不断在如何运转基于容器的微效劳上停止投资。这个建议适用于企业的人员、流程和工具。编排平台是一个好的末尾。

Browning说：“假设完全投资并运用像Kubernetes这样的编排平台，那就意味着要花时间和资源来跟上项目和更新，并在本人的部署中表现这些变化。“由于企业微效劳如今集中运转，这项投资将对一切要运转的效劳产生积极影响，而不是一个或两个特定的单一效劳。”

【编辑引荐】

态牛-Tech Neo 11月刊：容器平台管理实际

2017，容器圈繁华的一年

容器堆栈须知的八个要素

梁胜关于容器的年终总结，没再提Docker

4大维度3大预测，基于容器生态扩张的DevSecOps为啥引关注？

(责任编辑：admin)