部署容器时要考虑的6个关键因素
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支持,它必须要有。考虑可支持性DD这适用于面向硬件的容器主机和面向软件的容器映像。
选择容器映像和容器主机时,这个“购买标准”常被遗忘。但记住,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。然后你要回到第一个模式来更改代码、实现不同版本的库,并将其放回到开发人员的手中,这可能代价高昂。