关于容器、微服务、Docker的十大问题

容器的运行无法简单参考虚拟机的实践经验。例如，几乎任何工作负载都可以立即虚拟化，但是有些工作负载适合容器化部署，有的则不适合。

本文回答企业在使用容器时最常见的10个问题，帮助大家更好地理解容器部署、工作负载容器化等问题。

1. 最适合容器的使用场景是什么?

在生产环境中，最适合容器化部署的理想应用类型应该是微服务。微服务是一个聚焦的任务，它只代表整个应用程序中很小部分。因为微服务专注于单个任务，所以它可以独立于应用程序的其它部分进行伸缩扩展。此外，由于微服务是高内聚和松散耦合的，因此可以彼此独立部署和发布。

此外，使用容器基础设施构建微服务可以更快、更好地实现其优势。只要面向外部的API不破坏应用兼容性，软件开发人员就可以快速迭代并改进整个微服务，且不会影响其它开发人员的微服务。但是，大多数传统的企业应用程序并不符合微服务体系结构，所以也不是所有企业都适合使用微服务。

2. 容器部署时需要考虑的关键因素都有哪些?

(1)UI界面管理和API

管理用户界面UI，包括那些基于API的图形化UI(即外部系统直接使用API访问系统)。

(2)镜像仓库

公共镜像仓库，例如Docker Hub提供公共管理的容器镜像仓库。许多容器管理系统都提供私有镜像仓库，企业组织可以在其中管理自己的镜像。

(3)编排和调度

编排层能够使容器以所需的状态运行，并提供滚动更新和回滚的功能。当然，Kubernetes已经成为容器编排的实际标准。

(4)容器运行时

容器运行时，可以让集群节点在镜像仓库中获取容器镜像，还可生成正确的文件结构在主机上运行容器，也可与网络和存储插件交互，也能创建、启停容器。

(5)安全管控

通过安全组件执行安全策略，包括秘钥管理、安全扫描、图像签名、网络隔离和加密、以及基于角色的访问控制(RBAC)等。

(6)持续监控

监控程序能够提供集群节点、容器和微服务级别的可视化能力。

(7)DevOps工作流

DevOps对于容器部署并不重要，但是它们通常一起使用，例如，DevOps工具、CI/CD管道工具和容器镜像生成器等工具需要协同工作。

3. 是否可以在Windows、VMware环境运行容器?

Windows容器生态系统还不够成熟，无法广泛应用于生产环境中。Windows容器缺乏容器编排工具的支持。例如，最新的Kubernetes软件版本只提供了对Windows容器的beta支持。此外，容器支持的Windows应用程序非常少。Windows服务器对身份验证、安全和网络的支持也非常有限的。现有的几个组件要么处于“beta”版本，要么处于“预览”版本。当然，尽管有这些限制，针对特定场景也是可以使用Windows容器，例如内部开发等场景，通过容器可以获得敏捷性、可移植性和成本优势。

VMware的vSphere可将Docker引擎与vSphere集成，为容器在轻量级VM中运行提供了途径。此外VMware还提供了用于安全存储镜像的容器管理门户和私有仓库。

4. 应该选择CaaS、Kubernetes还是BYO容器管理解决方案

市场上有多种产品允许企业大规模部署容器。这些产品为应用程序开发人员提供的抽象程度不同。最抽象的产品是容器即服务产品(CaaS)，这类产品以前大多是PaaS产品，比如Cloud Foundry和OpenShift。这些CaaS产品从开发人员那里抽象出基础设施的细节，并以结构化方式提供应用程序工具。而BYO容器管理方案，则提供了最少的抽象和最大的灵活性，但是增加了复杂性。

• BYO：尽量避免使用BYO，除非在极少数情况下。因为很少有组织有能力实现它。对于想要BYO的组织，可以选择集成一些快速移动的开源产品。
• Kubernetes：至少在概念上了解基础设施并且能够动手实践，那么选择一个相对灵活K8S发行版是一个可行方案。有些CaaS产品提供了一些开发人员工具的选项，同时也为开发人员提供了更直接地使用容器编排、调度组件的选项。
• PaaS：如果刚刚进入微服务开发，那么就使用PaaS提供的服务。

5. 容器技术会比虚拟机技术(VM)更不安全吗?

容器技术本身并非不安全。事实上，以防止由于其它容器的破坏而遭受攻击, 容器中每个应用程序和用户是相互隔离的。所以确保共享主机OS内核的完整性是至关重要的，并确保在主机上容器的相互隔离。此外，需要监控和保护容器间通信，而传统的安全工具在这方面大多是无效的。

采用容器技术时候，建议考虑以下3点：

• 使用一个经过加固的操作系统，通常是一个“瘦客户机操作系统”，它可以限制攻击面，并通过一个严格的和自动化的补丁管理系统对其进行补充。
• 在容器的构建和运行阶段采取控制手段，例如在软件开发生命周期过程中对软件进行扫描，及早发现漏洞。
• 通过使用细粒度容器安全工具主动检测和监控异常行为，例如青藤蜂巢等容器安全产品可以提供容器和服务器级别的安全可视化图，并有助于防止恶意应用程序流量。

6. 容器是否可以处理敏感数据和应用程序?

通过聚焦于容器安全的方法进行容器部署，同时结合现有加密等安全工具，那么容器就可用于处理敏感数据和应用程序。此外，还可以使用一些容器安全厂商的方案确保容器的安全，例如青藤云安全的容器解决方案等。当然，要使此方法成功，安全团队必须尽早参与为敏感数据部署容器的过程。

7. 容器是否适合COTS应用?

现在越来越多的软件供应商将容器化部署作为产品一个选项。有的供应商采用敏捷开发模式满足容器化部署方式，将其纳入他们编写、测试和交付软件的一部分。这些应用都被重构为天然适配容器的微服务。但也有供应商，是因为害怕不提供容器化部署功能将失去市场，故而勉强提供容器部署，这种情况下COTS多数不适合容器，因为这些应用程序本质上可能仍然是整体的，或者应用程序没有独立可扩展属性。此外，如果企业本身没有现有的容器基础设施来管理，那么COTS应用程序的容器部署可能不适合企业。

在绝大多数情况下，应该避免在没有供应商明确支持的情况下封装COTS应用程序，避免出差错。

8. Foundry、OpenShift等产品和容器之间有什么关系

Cloud Foundry是一个应用程序PaaS平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题。因此，也是一个相对固定的容器框架。之所以这样描述，是因为它是预先配置的，以便于安装和维护。

OpenShift是红帽的云开发平台即服务(PaaS)，能使开发人员创建、测试和运行他们的应用程序，并且可以把它们部署到云中。OpenShift广泛支持多种编程语言和框架，如Java、Ruby和PHP等。另外它还提供了多种集成开发工具如Eclipse integration，JBoss Developer Studio和 Jenkins等。

企业在评估面向容器场景的PaaS产品时，重需要重点注意其提供服务范围，区分它们自身是否支持容器场景，还是需要自定义配置或者需要通过第三方组件服务才能支持容器场景。

9. 是否应该重构应用程序，以更好地支持容器?

在生产中，如果通过部署容器来支持微服务的弹性工作负载时，容器将会带来最大的帮助。因此是否要重构应用程序以支持容器化部署，这取决于企业组织是否计划在开发测试、生产等阶段中使用容器。

另外，企业在决定重构应用程序以更好支持容器，应该首先重构无状态部分应用程序，例如web应用程序前端部分，将其重构为微服务，以便能够支持使用容器。此外，企业可以通过微服务体系结构来构建新的应用程序，避免以后重构。

10. 在公有云中部署容器服务效果如何?

云IaaS服务提供商提供完全托管服务，而不需要处理虚拟机或底层基础设施，这种趋势现在也被应用到容器中，例如，AWS Fargate提供了抽象底层基础设施的托管容器服务，以便开发人员关注需要执行的任务，而不是Kubernetes集群中的实例数量。