但一项针对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撰写）
