【51CTO.com快译】容器功用弱小，易于提供运用顺序或效劳。虽然容器的目的是为了增加可变要素，从而简化和提高效率，但有许多复杂要素要思索。在企业界，思索这六个要素很重要：

1. 功用

开发人员通常不从功用的角度思索潜在成绩，但就由于你运用Web阅读器拜访运用顺序并不意味着它可处置少量并发事务。真正测试后，你才知道其处置才能。

Kubernetes可扩展规模，但也会占用少量资源。容器可协助处置架构成绩，并确保一切必需的依赖项都到位，但它在推出后并不自动确保功用。

底层言语运转时环境、Web效劳器和openssl等库的质量都会对功用产生影响。确保你的Linux发行版有一批积极自动的功用工程师停止回归测试，更重要的是优化整个架构的功用。

2. 兼容性

在Linux界，不同的顺序在内核上运转。大少数顺序运用与内核对接的API：syscall层。假设你坚持运用Linux中的syscall层，向前兼容性就很重要。

Linux之父Linus Torvalds有条严厉的规则：内核不应破坏向后兼容性。容器一直向前兼容，由于syscall层尽量不破坏该功用。

在旧的内核上运转新的容器映像会发作什么?或许你从syscall层进入到ioctl、/dev、/proc之类的API会发作什么?

兼容性存在时间和空间方面的限制，良好的设计和测试有所协助。面向容器映像和主机的Linux发行版要深化思索这些成绩，否则用户会堕入蹩脚形状。在内核层、编译器层(gcc)和库层(glibc)以及syscall接口之外的API都是如此。

另一个成绩是，假设只运用与C库有关的syscall函数，你能够没成绩。但运用顺序更有能够调入一款不是运用顺序一部分的辅佐软件，比如缺点排查或监控组件，它们运用ioctl /proc或/dev之类的其他内核API，这能够会招致成绩。

假设晋级容器主机，它能够再无法运转容器。在虚拟机范围，你通常不必担忧(但是就算运用虚拟化，一些架构或芯片组能够会招致成绩)，但在物理效劳器范围，一些架构或芯片组能够招致成绩。

3. 与现有基础设备整合

受支持的软硬件生态系统对应于底层的Linux发行版。假设你需求ARM支持，它必需要有。思索可支持性――这适用于面向硬件的容器主机和面向软件的容器映像。

选择容器映像和容器主机时，这个“购置标准”常被遗忘。但记住，Linux发行版的生态系统(硬件和软件)是可供容器主机(硬件)和容器映像(软件)运用的生态系统。假设你的Linux发行版支持某个特定的硬件或云提供商，那么你的容器主机就可以顺畅运转。

假设你的运用顺序是为特定的Linux发行版设计和构建的，将那些运用顺序放入基于该Linux发行版的容器映像中会容易得多。

4. 安全

一旦容器映像部署到消费环境，它将使你的运用顺序及其一切依赖项暴露在风险重重的互联网面前。这包括拒绝效劳攻击、数据泄露、特洛伊木马图片和黑客攻击。为容器环境选择容器映像和容器主机时要思索一切这些方面。

能够你不是从Red Hat容器目录下载该容器映像，而是选择从某个可疑网站下载。这是个坏主意。假设不从已知好的容器入手，有人会注入恶意代码，而你浑然不知。

从安全角度来看，了解组件的质量至关重要;一直运用信得过的来源。记住：容器在你下载那天能够是好的，但几年后能够变坏了。

5. 大小

容器执行少量构建操作，每当重建容器都会重新编译运用顺序。

如今，开发人员担任映像中的一切。一年后，假设某个库中的代码破坏向后兼容性，容器出缺点，谁来修复?他要有开发人员的技艺，而不只是执行“yum update”之类的操作。能够需求重新编译运用顺序。

另一种办法是构建基本映像，它有顺序包，比如用openssl静态编译的Web效劳器软件，功用成绩可经过yum update来修复以获取新的顺序包。这比更改代码容易得多，不过最终映像更庞大。

一旦添加软件，基本映像的大小有关紧要，如今它是400 Mb或500 Mb。

正在开发两种主要的容器化运用顺序。一种是基于Linux基本映像构建的，另一种是从头末尾构建的。

在这两种运用顺序中，用户常常对容器映像的大小敏感，由于它会影响将容器映像提取到容器主机所需的时间。假设从头末尾构建，并部署静态编译的二进制文件，选择小巧的基本映像或从头末尾构建很重要。

为用于企业外部的软件构建整个生态系统时，思索整条供应链的大小(一切RPM顺序包及依赖项)更重要，由于基础层常常可以共享缓和存。减小攻击面的关键是增加库和言语运转时环境的重复正本，从而减小在整个环境中的占用空间。

6. 支持

支持主要有两种：生命周期支持和白手套支持。

生命周期决议了支持时间以及为容器映像中的任何特定顺序(RPM或Debs)发布哪些补丁。

白手套支持让你可以提交工单、取得热修补顺序以及主张下游更改。

两者都十分重要，详细取决于你支持容器化运用顺序的时间。

生命周期支持的上下文很重要，由于运用顺序的运转时间比你所想的要长。能够三五年，或许更久。运用顺序/系统有众多实例，运转了多年。你要思索支持该基本映像多长时间来运转yum update。然后你要回到第一个形式来更改代码、完成不同版本的库，并将其放回到开发人员的手中，这能够代价昂扬。

问问本人：我的容器映像能否有更新?要是出了成绩，可以打电话给某人，取得修复顺序吗?假设我有共同的成绩，可以要求开发补丁吗?可以提交工单、要求补丁与仅仅运转yum update是不一样的支持级别。

原文标题：6 critical factors to consider when deploying containers，作者：Scott Matteson

【51CTO译稿，协作站点转载请注明原文译者和出处为51CTO.com】

【编辑引荐】

4个需求避免的常见Kubernetes监控圈套

消费环境 VS 开发环境，关于Kubernetes的四大看法误区

谷歌是如何增强Kubernetes容器安全的?

如何优化消费环境下的Kubernetes资源分配

调教Kubernetes部署的19款工具

(责任编辑：admin)