随着组织越来越多地采用云原生方法来开发和扩展应用程序，容器和Kubernetes在管理日益增长的复杂性和使工作负载能够在多云环境中部署方面发挥着关键作用。
但最近一项针对DevOps专业人员的调查发现，94%的人在过去一年中至少经历过一次Kubernetes安全事件，59%的人认为在使用Kubernets和容器时，安全是他们最大的担忧。尽管越来越多的DevOps团队转向Kubernetes以满足其组织的可扩展性需求，但安全和数据保护等基本原则不容忽视。
部署Kubernetes
开发人员被要求在更动态的环境中构建更大、更可扩展的应用程序。因此，对于运维或基础设施团队来说，这似乎是一项全职工作，以跟上不断变化的软件开发实践。Kubernetes只是最新的（可以说是更复杂的）挑战，但目标不变：如何降低风险、最小化成本并提供整体更好的业务成果？
开发团队是“先驱”——他们探索新的领域，在以前不存在的地方构建一些东西。另一方面，运维和基础设施团队是“定居者”，他们是第二波来巩固新的开发项目并确保其长期生存的。Kubernetes就是这样。当Kubernetes处于虚拟化或采用阶段时，通常由运维团队负责——真正的业务成果由他们承担。
但期望这些团队了解Kubernetes和容器的复杂性是一个很大的要求。即使有了新技术，也需要遵守基本原则。安全、备份和恢复仍然需要，但独特的技术要求可能会带来挑战。
Kubernetes中的安全性和零信任
作为一个云原生程序，Kubernetes面临的许多安全挑战来自于云架构的分散性。不同的工作负载可以跨多个不同的位置运行，包括多个云以及非本地和本地服务器。这不仅大大增加了可能发生攻击或错误的“威胁范围”，而且还可能意味着可见性挑战，使容器监控和检测变得更加困难。
虽然Kubernetes被设计为安全的，只响应它可以认证和授权的请求，但它也为开发人员提供了定制的配置选项，这意味着它仅与开发人员配置的基于角色的访问控制（RBAC）策略一样安全。Kubernetes还使用所谓的“扁平网络”，默认情况下，它允许容器组（或pod）与其他容器通信。这引发了安全问题，因为理论上，破坏pod的攻击者可以访问同一集群中的其他资源。
减轻这种风险的解决方案相当简单：零信任策略。面对如此大的攻击面、相当开放的网络设计以及跨不同环境的工作负载，零信任架构（从不信任并始终验证）在构建Kubernetes时至关重要。
零信任架构的原则是在应用这些原则的同时，将安全焦点从应用程序的外围移开。所有内部请求都被认为是可疑的，并且需要自上而下进行身份验证。该策略通过假设网络上随时存在威胁来帮助降低风险，因此在每个用户、设备和连接周围都会不断维护严格的安全程序。对于Kubernetes的流动和去中心化架构，这是必须的。
备份和恢复
备份和恢复是一个众所周知的概念，但在备份Kubernetes和容器时有一些独特的考虑因素，因为Kubernete与其他架构有根本不同。例如，它没有将应用程序映射到服务器或虚拟机。
Kubernetes备份系统还需要以应用程序为中心，而不是以基础设施为中心。这是由于DevOps的哲学和“左移”原则，这本质上意味着开发人员对基础设施和部署有更多的控制权。Kubernetes备份的其他独特要求是应用程序的规模、保护差距和生态系统集成。
在恢复Kubernetes环境时，需要一个详细的执行计划，以识别集群依赖关系，更新应用程序以反映新的存储组件，并将计划转换为相关的Kubernetes API。虽然备份确实需要更定制的Kubernetes原生解决方案，但此类恢复过程对业务的长期健康仍然至关重要。在今天的环境中，高效的恢复和灾难恢复是不可或缺的，停机成本估计为每分钟1459欧元（约1440.51美元）。
然而，除此之外，备份在测试和开发目的以及实现应用程序移动性方面具有巨大的价值。应用程序移动性是指跨内部部署、云、集群或Kubernetes分布将应用程序迁移到不同环境的能力。随着IT环境变得更加复杂，企业需要响应新的业务需求、采用新的技术平台或优化成本，这一点变得越来越重要。
做好准备
尽管Kubernetes面临着新的技术挑战，但最终情况变化越多，它们就越保持不变。运维和基础设施团队习惯于在不断扩展的技术堆栈中加入新工具，而通过现代数据保护降低风险等核心原则仍然符合他们的目的。
一旦建立了这些能力，运维团队就可以开始深入研究，并通过测试和优化等活动探索利用数据的价值。通过支持应用程序移动性的健壮备份，团队还可以通过确保服务能够更轻松地应对下一波变化，在未来经得起考验的应用程序方面走得更远。虽然Kubernetes是当前改变开发环境的工具，但它肯定不会是最后一个。
原文链接：
https://thenewstack.io/what-do-cloud-native-and-kubernetes-even-mean/
