现在越来越多的企业采用云原生来开发和扩展应用。因此，在应对日益增加的复杂性并支持在多云环境中部署工作负载时，容器和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全球高级技术专家MichaelCade撰写）
