2020云原生7大趋势预测

Kubernetes 的大规模使用是否会带来企业运维人员的失业?实际上，随着越来越多的企业 IT 架构，从 on Kubernetes 到 in Kubernetes，大量的 CRD、自定义 Controller 和服务网格的引入，给 Kubernetes 的稳定性和性能优化带来大量的挑战。Kubernetes 的掌握深度逐渐成为企业运维团队技术能力的重要评估标尺，而企业运维人员的技能也会从自动化向数据化和智能化发展。

预测在 2020 年，围绕着 Kubernetes 的 AIOps 会逐渐涌出，来进一步完善 Kubernetes 的成本优化、故障检测和集群优化。

而 Kubernetes 等云原生技术也会让 AIOps 不再雾里看花：

1)得益于 Kubernetes 的良好设计，包括声明式API、不可变架构、优雅的扩展机制，可以促进应用发布和运维的操作归一化(Normalization);

2)结合 GItOps、Tekton、SecOps 等自动化流程的落地，应用的生命周期更加标准化(Standardization);

3)随着 OpenTelemetry、CloudEvents 等项目的推进，应用可观测性领域在日志、监控、Tracing、事件等领域进一步标准化和融合，使得多指标、根因分析的数据集更加丰富，从而提高 AIOPS 的 AI 层面的准确率和覆盖率。

新内核、新硬件助力容器优化 OS 的演进。

容器技术经过了多年的发展，从早期的 Docker、rkt、CRI-O 等，到 containerd、Kata Container、gVisor，已经成为 Kubernetes 运行的重要基石。然而无论是 runc 场景的进一步隔离，还是安全容器场景的进一步性能优化，还需要持续的打磨和增强。

随着新内核技术包括 CGroup V2、namespace、virtiofs 等的逐步成熟，可以进一步增强容器运行时的能力。另一方面，一些新硬件包括 NPU、MoC、NUMA 等的引入，也给容器和 K8s 调度带来了更多的优化空间和场景。得益于这些能力的加成，为容器场景量身定制的容器优化 OS 成为可能，并会快速发展。

容器网络和 Mesh 网络将进一步融合。

Service Mesh 经过多年的市场培育，2020 年将会成为 Service Mesh 技术的普及年。而 Service Mesh 的性能优化也会成为重头戏，一些下沉方案也在选择基于 CNI(容器网络接口)和内核技术进一步优化网络转发性能。

而容器网络自身也在逐渐演进，从面向 ip 到面向 Identity，从单容器网络平面到多网络平面，并进一步优化网络转发性能和零可信安全。在 2020 年，我们相信容器网络和 Mesh 网络将进一步融合，在 Network ServiceMesh、NFV等场景进一步集成。

4、边缘计算

随着 5G 和万物互联时代的到来，联网智能终端设备数量将急剧增加，传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求，将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控，将是云计算的重要发展趋势。

IDC 预计，到 2020 年全球将有超过 500 亿的终端与设备联网，超过 40% 的数据要在网络边缘侧进行分析、处理与存储，这对边缘计算提供了充分的场景和想象空间。

站在新的一个十年，2020 年边缘计算领域将有如下变化：

以 Kubernetes 为基础的云原生技术，经过近几年的高速发展，适用范围、落地场景、技术成熟度等均有了长足发展，其核心价值之一是通过统一的标准实现在任何基础设施上提供和云上一致的功能和体验。将云原生技术和边缘计算相结合，可以快速实现『云-边-端』一体化的应用分发，解决在海量边、端设备上统一完成大规模应用交付、运维、管控的诉求;

在安全方面，云原生技术可以提供容器等更加安全的工作负载运行环境，以及流量控制、网络策略等能力，能够有效提升边缘服务和边缘数据的安全性;

在边缘网络环境下，基于云原生技术的边缘容器能力，能保证弱网、断网的自治性，提供有效的自恢复能力，同时对复杂的网络接入环境有良好的兼容性;

依托云原生领域强大的社区和厂商支持，云原生技术对异构资源的适用性逐步提升，在物联网领域，云原生技术已经能够很好的支持多种 CPU 架构和通信协议，并实现较低的资源占用。

目前已经有不少厂商在进行云原生边缘计算的尝试，并有了部分成功案例，相信在 2020 年随着 5G 的快速铺开，云原生边缘计算的发展将大大提速。

5、容器实例与容器引擎

在 2019 年的最后一个月 AWS 终于发布了 Fargate for EKS 产品，这也宣告了云上 Kubernetes 使用 Serverless 容器实例作为底层运行时资源的产品形态得到了业界更广泛的认可。通过容器实例作为底层运行实体可以让用户专注于构建自身的业务和服务，无需再配置和管理服务器，摆脱基础设施运维的复杂性。同时通过真正的按需付费和实时扩容来降低用户的使用成本。

无论是亚马逊的 Fargate，微软的 ACI 还是阿里云的 ECI，各产品当前在对接 Kubernetes 的具体架构上仍然有分歧，以 Fargate 为代表采用的是透传 Node 信息的方式来提供对 Kubernetes 功能的完整支持;以 ACI/ECI 为代表则采用 virtual kubelet 方式对接 Kubernetes 对容器实例进行管理。

但无论采用何种对接方式，容器实例产品的核心依然需要构建在弹性、成本和 Kubernetes 兼容性上。通过弹性实现用户服务的按需实时扩容，用户无需选择实例和集群容量，不需要为额外的服务器预置而付费;通过实时扩容实现真正的按使用资源付费，降低用户的使用成本;Kubernetes 已经成为容器编排领域的事实标准，对 Kubernetes 功能的兼容性决定着容器实例的适用范围。

站在新的一个十年，相信在 2020 年容器实例产品会在这三个方面继续改进和完善，持续提升弹性能力，降低用户的使用成本，并不断完善与 Kubernetes 的集成。同时也会有更多的云原生应用迁移到 Kubernetes+ 容器实例上，享受云原生的技术红利。

从上述各厂商的同类产品中我们也可以看到此类产品在设计上的共同之处：

一个实例对应一个 Pod

对接 Kubernetes

安全容器作为底层容器引擎

这其中使用安全容器作为底层容器引擎是各家都很重视的底层基础能力。在 2019 年安全容器技术的隔离性越来越被看重，作为一个隔离层，不仅提升云原生平台的安全性，也对可运维性、服务质量和用户数据保护有显著效果。不过，回归初心，用户选择云原生的本质是容器带来的敏捷性，他们可以快速地调度并启动容器，并且可以灵活地使用资源，这方面安全技术尚不能达到传统容器的水平。

不论是 Kata Containers 还是 gVisor，开源安全容器引擎在 2019 年都取得了很多进展，Kata Containers 明确提出了“做面向云原生的虚拟化”作为 2020 年的目标：

在沙箱间共享资源，同时保持沙箱边界仍然清晰。

即时、动态地按需为沙箱提供资源，而不是像分区那样进行固定的资源分配。

主机的用户态工具、VMM、乃至应用的内核联合起来，彼此协同为沙箱中的应用提供服务。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!