​当下企业越来越多的采用云原生来开发和拓展应用程序，因此在处理日益增长的复杂性以及支持在多云环境下部署工作负载时，容器和Kubernetes 就变得至关重要。

但一项针对DevOps专业人士的调查发现，94%的人在过去一年里至少经历过一次Kubernetes安全事件，59%的人认为安全问题是他们在使用Kubernetes以及容器时最大的担忧。虽然越来越多的DevOps团队转向Kubernetes，以满足企业扩展需求，但像安全和数据保护这样的基本原则绝不能被忽视。

部署Kubernetes

开发人员被要求在更多的动态环境中建立更大、更加可扩展的应用程序。因此，对于运营或基础设施团队来说，跟上不断变化的软件开发实践似乎已经成了一项全职工作。Kubernetes只是最新的（也可以说是更复杂的）挑战，但开发人员的目标没有变：我们如何才能减少风险，最大限度地降低成本，并提供一个更好的整体业务成果？

开发团队是 "开拓者"，他们探索新的领域并建立起全新的东西。另一方面，运营和基础设施团队是 "定居者"，在第二波浪潮中来巩固新的开发，并确保它能长期生存。这正是Kubernetes的情况。当Kubernetes处于虚拟化或适用阶段时，通常是由运营团队主导，因为关乎真正的业务成果的责任落在他们身上。

但想让这些团队理解Kubernetes和容器的错综复杂是一个很高的要求。即使是新技术，也需要遵守基本原则，即安全、备份和恢复都是需要的。但独特的技术要求也会带来挑战。

Kubernetes的安全性和零信任

作为一个云原生程序，Kubernetes的许多安全挑战来自云架构的分散性。不同的工作负载可以在几个不同的地方运行，包括多个云以及外部和内部的服务器。这不仅大大增加了可能发生攻击和错误的 "威胁范围"，而且还增加了可视化方面的挑战，即监控容器和检测问题都变的更困难。

虽然Kubernetes的设计是安全的，它只对可以验证和授权的请求做出响应，但它也为开发者提供了定制的配置选项，这意味着它的安全程度只相当于开发者配置的RBAC（基于角色的访问控制）策略。Kubernetes还使用了所谓的 "扁平网络"，使容器组（或Pod）默认与其他容器进行通信。这引起了安全问题，因为理论上，攻击者如果破坏了一个Pod，就可以访问同一集群中的其他资源。

尽管有一定的复杂性，但减轻这种风险的解决方案是非常简单直观的，即零信任。由于有如此大的攻击面、开放的网络设计和跨越不同环境的工作负载，因此在使用Kubernetes进行构建时，零信任架构极为重要，即从不信任和永远验证。

零信任架构的原则是将安全的焦点从应用程序的外围移开，同时将这些原则贯穿始终。所有的内部请求一律视为可疑的，自上至下都需要身份验证。这种策略通过假设网络上一直存在威胁来帮助降低风险，因此围绕每个用户、设备和连接持续保持严格的安全程序。对于Kubernetes的流动和分散的架构来说，这是必须的。

备份和恢复

为Kubernetes应用程序减轻风险所需的另一个基本原则是备份和恢复。这是一个众所周知的概念，但在备份Kubernetes和容器时，有很多特殊的考量。这些对数据备份的不同要求是因为Kubernetes与其他架构有根本的不同，例如，它没有映射到服务器或虚拟机上的应用。

Kubernetes备份系统也需要以应用为中心，而不是以基础设施为重点。这是出于DevOps理论基础和 "左移 "原则，即开发人员对基础设施和部署有更多的控制。Kubernetes备份的其他特殊需求包括应用程序的规模、保护差距和生态系统的整合。

在恢复Kubernetes环境时，需要一个详细的执行计划，确定集群的依赖性，更新应用程序以反映新的存储组件，并将计划转化为相关的Kubernetes应用程序编程接口（API）。虽然备份确实需要更多定制的Kubernetes原生解决方案，但这种恢复过程对企业的长期健康发展仍然至关重要。在今天，高效恢复和灾难恢复是必不可少的，据估计，每分钟的中断成本为1,459欧元。

此外，备份在测试和开发目的以及实现应用程序移动性方面具有巨大价值。应用程序的移动性是指将应用程序迁移到不同环境的能力——跨企业内部、云、集群以及Kubernetes分布。随着IT环境变得越来越复杂，企业需要应对新的业务需求，采用新的技术平台或优化成本，这一点也越来越重要。

迎接改变

尽管Kubernetes带来了新的技术挑战，但终究万变不离其宗。运营和基础设施团队已经习惯于将新的工具纳入不断扩展的技术栈，通过现代数据保护降低风险等核心原则仍在发挥作用。

一旦这些能力建立起来，运营团队就可以看得更远，并通过测试和优化等手段来挖掘利用其数据的价值。利用支持应用程序移动性的强大备份，团队还可以通过确保服务能够更容易地驾驭下一波变化，来为应用程序的未来做好准备。虽然Kubernetes是目前正在改变开发环境的工具，但它肯定不会是最后一个。

（本文由Veeam 全球高级技术专家 Michael Cade撰写）​