随着容器的增加,容器错误也随之增加。
随着组织为提高软件开发效率和基础架构数字化,容器正变得越来越流行。根据最近的451 Research报告,大约一半的企业现在正在使用容器或计划在未来两年内使用容器。
这个数字可能会持续增长。为什么这样呢?不管什么样的运行环境,容器都可以打包并隔离应用程序所需的基础架构。这增加了应用程序在公共云,混合云和本地基础架构之间的可移植性,降低了成本并促进了DevOps敏捷文化。
开源的软件Kubernetes的出现使容器化应用程序的部署,编排和管理变得自动化,并且是迄今为止最受欢迎的编排工具。它帮助组织可以大规模使用容器。
那么会出什么问题呢?有很多,以下是最常见的容器错误。
对容器或容器中应用程序的错误配置
从传统的工作负载转移到容器时,会发生很多变化:IP地址,权限等。应用程序维护人员必须知道所有这些更改。否则,可能会发生配置错误,从而导致意外结果,例如应用程序故障,性能下降,安全隐患等。
为了解决配置错误,应用程序维护人员应熟悉容器编排平台,并采取必要的措施为迁移准备应用程序。
缺乏容器的容量管理和规划,导致资源过量使用
尽管容器通常比传统的虚拟机消耗更少的资源,但这并不意味着用户可以在一台物理服务器上创建数千个容器。实施容器策略时,应始终考虑容器的资源管理和容量监控。否则,可用的物理资源很快就会被过度使用。
幸运的是,领先的容器编排平台(例如Kubernetes)提供了资源管理功能,例如,可以指定每个容器使用多少CPU和RAM。另外,各种开源工具也提供有容量监控。
缺乏后期容器操作的考虑
很多用户,由于缺乏对后期容器操作–例如:打补丁,升级,扩容和基础架构即服务(IaaS)集成的考虑而造成服务故障。
在使用容器之前,必须三思而后行,因为每台计算机都是具有自己的类库和二进制文件集的操作系统。随着时间的流逝,它们可能容易受到安全漏洞和容器错误的影响。
容器仅提供有限的隔离,例如容器间是共享内核,这意味着当你使用一个容器时,则很可能存在其他容器威胁底层主机。
有多种方法可以解决这个问题:自动化的CI / CD,可方便应用程序自动构建,测试和重新部署。此外,容器运行时(例如开源Kata)可以通过使用基础硬件的功能(即CPU虚拟化指令)为容器提供更多隔离。有些第三方产品,不仅可以在部署期间而且在开发阶段,都可以帮助进行安全扫描。
尝试将不适合容器或微服务体系结构的工作负载移植到容器
将应用迁移到容器越来越普遍,但有时组织却完全忽略了其现有工作负载尚未准备好迁移的事实。例如,尝试将单片应用程序放入容器中通常不会很好。所以,迁移到容器应该是组织的战略决策,并涵盖基础架构和应用程序。在迁移到容器之前,应基于微服务体系结构重新设计现有的工作负载。
而且,某些应用程序根本不适合容器或微服务体系结构。此类应用程序,通常需要某些硬件扩展(例如虚拟化)或在本地有存储数据的有状态服务。
低估了容器不兼容的可能性
尽管容器具有可移植性,但在某些情况下,容器与企业使用的基础操作系统或平台(PaaS)之间可能存在不兼容性。一个示例是:容器中的应用程序可能调用或依赖底层主机OS或PaaS尚不可用的内核功能。
同样,某些供应商拥有专用的CLI工具,例如Kubernetes提供的API。这就使得将工作负载从一个PaaS迁移到另一PaaS变得很困难。如果一个PaaS解决方案只能在单个云中使用,那么这也会使多云设置更加困难。
我们建议遵循十二要素应用程序的原理,该方法是构建现代软件即服务应用程序的方法。围绕这些架构,设计了诸如Kubernetes之类的平台,因此建议您充分了解这些知识。
容器是应用程序开发的未来。所以,避免常见的容器错误很重要。
译文链接: https://containerjournal.com/topics/container-management/5-common-container-mistakes-to-avoid/
登录后评论
立即登录 注册