在生产环境中运行容器的“六要、六不要和六管理”

　　单从数据来看，近年来容器和Kubernetes在传统数据中心和云原生应用中得到很好运用，但是当前容器的生态系统并不完善，缺乏足够成熟的操作实践案例。容器集成、网络以及自动化部署仍然是非常棘手的问题。此外，由于云原生应用需要一个高度自动化基础设施环境以及专业的运维技能，导致容器在企业中应用仍然受到一定限制。

　　因此，在具体生产环境中运行容器仍然需要一个长期的学习过程。企业在生产环境中部署容器之前，一定要认真思考以下六个问题：

　　DevOps：是否拥有DevOps团队来做开发运维，能够启用敏捷开发和部署模型?

　　工作负载：是否确定了专人来负责容器化的工作负载?

　　快速集成：是否了解如何集成IT基础架构，以及拥有跨平台的集成能力?

　　付费模型：是否了解使用哪种运行和编排引擎，以及他们的付费模式?

　　培训技能：是否了解应学习哪种新技能以及采用哪种规则能确保容器部署成功?

　　ROI：投资回报率如何?

　　但是，很多企业组织经常会低估在生产环境中运行容器所需的工作量，想要让容器在企业中正常运作，要尽量避免下述六个错误的行为。

　　1.在没有成熟DevOps实践经验的情况下就开始部署容器。

   　2.选择了那些带有专有组件的容器导致被锁定。

　　3.没有在企业组织中实施通用的工具和合规要求。

　　4.没有为开发和运维人员提供前沿的技术培训服务。

　　5.在选择工具的时候没有考虑开发者和运维者的需求。

　　6.选择了依赖性、相关性非常大的复杂工作负载。

　　企业在生产环境部署容器后，就应该格外重视容器本身的安全。例如Docker宿主机安全、Docker镜像安全、运行环境安全、编排安全等问题，这都意味着保护容器安全将是一项持续的挑战。在生产环境中部署容器，需要重点考虑安全合规、持续监控、数据持久性、网络安全问题、全生命周期管理、容器编排等问题。

　　安全不能总是事后诸葛亮。它需要嵌入到DevOps过程中。企业组织需要考虑跨容器全生命周期安全问题，包括应用程序的构建、开发、部署和运行等不同阶段。

　　1.将镜像扫描集成到企业的CI/CD中，及时发现漏洞。在软件开发生命周期的构建和运行阶段对应用程序进行扫描。重点是扫描和验证开源组件、库和框架。

　　2.根据CIS基线检查安全配置。

　　3.建立强制性访问控制，针对SSL密钥或数据库凭据等敏感信息进行加密管理，只在运行时提供。

　　4.通过策略管理避免特权容器，以减少潜在攻击的影响。

　　5.部署提供白名单、行为监控和异常检测的安全产品，以防止恶意活动。

　　开发人员主要关注容器在功能方面的应用，而不会去监控它们的运行情况。传统监控工具主要关注主机级指标，如CPU利用率、内存利用率、I/O、延迟和网络带宽。但这远远不够，还缺少容器或工作负载级别指标数据。

　　1.安全人员要将监控重点放在容器和服务级别上，实现细粒度监控“应用程序”，而不仅仅是物理主机。

　　2.优先考虑提供与容器编排(尤其是Kubernetes)深度集成的工具和供应商。

　　3.使用那些能够提供细粒度日志记录、提供自动服务发现、实时操作建议的工具。

　　随着对有状态工作负载容器使用的增加，客户需要考虑物理主机之外数据的持久性，保护这些数据安全。即便容器不在了，数据必须还在。如果企业对容器的主要使用场景，是转移老旧应用程序或无状态用例，对存储的安全需求不会发生大变化。但是，如果要对应用程序进行重构，或提供一个新的、面向微服务的有状态应用程序，那么安全人员就需要一个存储平台，能够最大限度地提高工作负载的可用性、灵活性和性能。例如，为了更好的支持容器迁移和数据共享，Docker推出了Volume plugin接口机制，让第三方的存储厂商来支持Docker Volume并且在此基础上进行功能拓展。

　　1.选择与微服务体系结构原则一致的存储解决方案，要能满足支持API驱动、具有分布式架构、支持本地和公有云部署的服务。

　　2.避免使用专有插件和接口。相反，优先考虑与Kubernetes紧密集成的供应商，并支持标准接口，如容器存储接口(CSIs)。

　　开发人员最关心就是软件开发的敏捷性和可移植性，希望应用程序能够跨软件开发生命周期进行移植。虽然在传统的企业网络模型中，IT人员为每个项目的开发、测试和生产等创建网络环境，即便如此仍然不一定能够与业务流保持很好一致性。在容器业务环境中，容器网络问题就更加复杂。例如，容器网络跨越多个层，如果直接在主机端口上开放服务虽然可行，但是部署多个应用的时会遇到端口冲突，加大扩展集群和更换主机的难度。

　　因此网络解决方案需要与Kubernetes原语和策略引擎紧密集成。安全和运维人员需要努力实现高度的网络自动化，并为开发人员提供适当的工具和足够的灵活性。

　　1.分析现有的容器即服务(CaaS)或软件定义网络(SDN)解决方案是否支持Kubernetes网络。如果没有，可以选择通过容器网络接口(CNI)来集成应用层网络和策略引擎。

　　2.确保所选择的CaaS、PaaS工具能为主机集群提供负载均衡方面控制，或者选择第三方代理服务器。

　　3.培训网络工程师对Linux网络、自动化网络工具的使用，弥补技能差距。

　　因为容器编排工具管理着承载各类服务的容器集群。无论是 Kubernetes 社区还是第三方安全机构均针对 Kubernetes 中组件和资源的安全进行了相应改善和安全加固，包括计算资源安全、集群安全及相关组件安全等。这块需要重点考虑是隐私管理、授权管理、身份防控制、编排控制面、网络证书等都需要全面考虑。

　　其中，容器部署的关键是提供编排和调度能力。编排层与应用程序进行接口，使容器保持在所需的状态下运行。而容器调度系统按照编排层的要求将容器放在集群中最优的主机上。例如通过Apache Mesos提供调度，Marathon提供编排或使用单个工具Kubernetes或Docker Swarm提供编排和调度。客户在编排引擎之间或跨Kubernetes发行版之间进行决策时，需要重点考虑以下几个方面：

　　容器和DevOps的关系就像是咖啡伴侣。容器能够快速发展，也得益于DevOps实践经验。在传统的开发环境，开发团队编写代码，QA团队测试软件应用程序，并将它们移交给运维团队进行日常管理。为了解决传统开发模式中的问题，很多企业都采用了“DevOps流程+微服务理论+使用容器和容器编排工具”。事实上，DevOps前身就是CI/CD，现在只不过是再加上一些发布、部署等标准和管理就构成了DevOps。

　　在云原生环境中，不仅软件开发和发布速度很快，而且平台本身也需要被当作一个产品来对待，因为它是动态的，并且在功能和规模方面不断发展。平台运营团队的目标是自动化、可伸缩和有弹性的标准化平台。平台运营团队的职责包括CaaS、PaaS产品的部署、操作、定制，标准化中间件的开发、操作，以及IaaS供应的自动化、部署、安全的启用等等。企业组织需要创建一个DevOps团队来运营容器，而不是一个个孤立的IT运营团队。

　　以容器安全为例，企业需要一个可集成至DevOps流程，又不会拖慢软件开发的方案。目前国内外有一些安全厂商已经在这方面做出好成绩，例如青藤容器安全解决方案，就可以提供对容器镜像扫描、入侵检测和合规基线实施情况等产品服务，化解容器所带来的安全挑战。这是一个以应用为中心、轻量级、保障容器静态资源及运行时安全的分布式解决方案，能够针对应用漏洞、不安全配置、入侵攻击、网络行为，并结合安全策略，提供覆盖容器全生命周期的、持续性安全防护。