云计算的拐点已至进入成熟期，云原生成为驱动业务发展的动力引擎，作为新型基础设施，不仅是企业数字化转型的最佳技术路径，同时也成为兴领域人工智能、大数据、边缘计算、5G 等底层平台基础设施。随着云原生技术的成熟和市场需求的升级，云计算的发展已步入新的阶段。
云原生 2.0，将充分地释放了云计算的红利，未来将有更多的业务应用生于云，长于云；为了最大程度发挥云原生的优势，支持好各种复杂个性化场景，云原生技术在不断完善演进，从中心到边缘；理念也在不断总结升华，从微服务到 Mesh，再到无服务，业驱云长，云随业动。
1.1. 云原生时代
Kubernetes 开启了整个云原生的时代，以两年为一个大的阶段，可以分为五个阶段，分别是孵化期、高速发展期、野蛮生长期、普及推广期、业务重构期。 随着物联网、人工智能等技术的不断发展，尤其是产业互联网发展落地，云原生作为新一代基础设施，从互联网大厂走向企业，走向产业；云原生 2.0，企业云化从“On Cloud”走向“In Cloud“，生于云、长于云且立而不破；企业新生能力基于云原生构建，使其生于云；应用、数据和 AI 的全生命周期云上完成，使其长于云；企业原来的业务核心系统开始基于云原生的技术理念解构及重构，实现借助技术的敏捷实现业务敏捷的数字化转型。
未来云原生必将更全面的服务于产业与实业，分布式云+ 云原生，将成为云基础设施新范式，赋能新云原生企业敏捷创新，推动云原生生态有序繁荣，让云无处不在，让智能无所不及。
1.2. Kubernetes 架构及扩展性
Kubernetes 主要由以下几个核心组件组成：
(1) etcd 保存整个集群的状态；
(2) apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
(3) controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
(4) scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
(5) kubelet 负责维护容器的生命周期，负责 Volume（CSI）和网络（CNI）的管理；同时也负责管控 Device Plugins，主要是 GPU，FPGA 及网络设备。
(6) container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
(7) kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；
早期在 Kubernetes 在高速发展期，为了快速适配各个各样的场景，将 Kubernetes 打造成一个可扩展的平台，大致可以分为基础设施（Infrastructure）及应用管理（Application Management）扩展两个方面；
一）基础设施（Infrastructure）扩展：
(1) 通过 OCI 与 CRI 标准容器镜像（image spec）及容器运行时（runtime spec）。
(2) 通过 CNI 与 CSI 标准化网络及存储，开放网络及存储扩展能力。
(3) 通过 Device Plugins 备插件框架，将系统硬件资源引入到 Kubernetes 体系。
二）应用管理（Application Management）扩展：
(1) 通过 CRD 扩展 Kubernetes 用户自定义资源。
(2) 通过 Operators 实现 Kubernetes 应用生命周期管理。
Kubernetes 可扩展性架构及 CNCF 开放式生态发展方向，在高速发展期，野蛮生长期乃至普及推广期，开放式平台及生态都是非常正确明智的选择 ； 但是进入业务重构期，面向业务需要提供整体性一体化的平台， 而不是一个碎片化的功能部件，不是所有公司都具备组装及调优能力，这时候平台的价值就会被重复的组装及调优将价值拉低；平台需要从散装转化成一体化，开箱即用的品牌机，要么就直接选择企业级容器平台或公有云容器产品，比如 Openshift 及阿里云 ACK；要么通过生态治理，逐步收紧平台扩展能力，增加组件的成熟度监管，分久必合合久必分，在分与合中保障平台及生态的良性发展。
1.3. Kubernetes 走向碎片化
CNCF 开放式生态，是导致整个生态体系碎片化的根源；从 2015 年 CNCF 只有 Kubernetes 一个项目，到如今高达 80 多个官方项目，其中毕业项目 15 个，孵化项目 21 个，沙盒 46 个项目；包含底层众多的容器运行时、容器存储、容器网络以及硬件加速器项目，还有以应用为中心的北向数据库、中间件等项目。
通过 CNCF 官方认证的 Kubernetes 的云服务或者发行版也多达 130 款，通过 CNCF 官方认证服务商和培训合作伙伴超过 250 家。在中国 CNCF 的会员数量超过 60 家成员单位。
如此庞大的软件生态体系，集结了开源，云厂商，软件服务商及设备厂商等多个利益方；整个生态大跃进式发展，无论是公有云厂家还是企业，都是忙于通过积木式能力组装容器平台，乐此不疲。还有公有云厂商，疲于跟进与整合容器技术，但只能提供毫无壁垒，毫无优势的工具平台，无法形成真正产品及竞争力；还有从容器，微服务到无服务技术，平台能力几乎应有尽有，貌似全部就绪，好像就只差最理想的应用迁入即可；但是在实际的使用及推广过程，与喧嚣的社区相比，云原生的价值被疲于应对平台各种诡异问题，兼容新老业务的痛苦过程中消耗殆尽，一片哀嚎。
1.3.1. 容器运行时的碎片化
容器运行时（Container Runtime Interface，简称 CRI）是 Kubernetes v1.5 引入的容器运行时接口，它将 Kubelet 与容器运行时解耦，将原来完全面向 Pod 级别的内部接口拆分成面向 Sandbox 和 Container 的 gRPC 接口，并将镜像管理和容器管理分离到不同的服务。在 v1.6 时已经有了很多外部容器运行时，如 frakti 和 cri-o 等。v1.7 中又新增了 cri-containerd 支持用 containerd 来管理容器。
Kubelet 衔接运行时的方式及调用链路如下：
(1) docker： dockershim => dockerd =>containerd => runc
(2) containerd： containerd=>shim v2=> runc
(3) cri-o： cri-o => runc
(4) frakti： frakti=> runv
(5) pouch： pouchContainer =>containerd =>runc
containerd 与 cri-o： 两者都是调用 runc，containerd 是内置 runc 代码，通过函数直接调用；cri-o 是通过 linux 命令方式调用 runc 二进制文件，在性能上 containerd 更具优势，但是 cri-o 集成方式更为合理优雅，比较推荐 cri-o。
runc 与 runv： runc 创建的容器进程，直接运行在宿主机内核上，而 runv 是运行在由 Hypervisor 虚拟出来的虚拟机上，占用的资源更多启动速度慢，而且 runv 容器在调用底层硬件时，中间多了一层虚拟硬件层，计算效率上不如 runc 容器。
总的来说，生产环境的运行时选择主要取决于运行效率，端到端的全流程运行效率，因此建议结合自身业务需求，使用场景以及团队技术储备等选择合适的容器运行时。对性能要求大于安全隔离要求时，推荐使用 cri-o + runc；对安全隔离要求大于性能要求时，在隔离性要求较高的业务场景下，推荐使用 frakti + runv。
1.3.2. 容器网络的碎片化
容器网络属于 Kubernetes 容器平台核心组件，技术复杂度高，对业务影响大。Kubernetes 网络依赖底层的技术大致可以分为三大类：
（一）Overlay 模式是在二层或三层网络之上再构建起来一个独立的网络，这个网络通常会有自己独立的 IP 地址空间、交换或者路由的实现。VXLAN 协议是目前最流行的 Overlay 网络隧道协议之一，显著优势就是灵活，对底层网络没有侵入性。
（二）路由模式放弃了跨主机容器在 L2 的连通性，而专注于通过路由协议提供容器在 L3 的通信方案；路由模式更易于集成到现在的数据中心的基础设施之上，便捷地连接容器和主机，并在报文过滤和隔离方面有着更好的扩展能力及更精细的控制模型。
（三）Underlay 模式是借助驱动程序将宿主机的底层网络接口直接暴露给容器使用的一种网络构建技术，较为常见的解决方案有 MAC VLAN、IP VLAN 和直接路由等。
同时容器网络技术也在持续演进发展，社区开源的网络组件众多，每个组件都有各自的优点及适应的场景，难以形成统一的标准组件，以下是比较常用 Flannel、Calico、Cilium、OVN 网络插件简单介绍：
（一）Flannel： Flannel 是最流行的 Kubernetes 容器网络插件，提供多种网络模式实现，覆盖多种场景，支持 3 种网络模式：
1．UDP 模式使用设备 flannel.0 进行封包解包，不是内核原生支持，上下文切换较大，性能非常差；
2．VXLAN 模式使用 flannel.1 进行封包解包，内核原生支持，性能较强，性能损失可以控制在 20%~30%左右；
3．HOST-GW 模式直接宿主机当作子网的下一跳地址，性能最强，性能损失大约在 10%左右。
（二）Calico： Calico 是一套开源的网络和网络安全方案，用于容器、虚拟机、宿主机之前的网络连接，支持 3 种网络模式：
1．全互联模式(node-to-node mesh) 基于 BGP 协议，每一个 BGP Speaker 都需要和其他 BGP Speaker 建立 BGP 连接，这样 BGP 连接总数就是 N^2，如果数量过大会消耗大量连接。
2．路由反射模式 Router Reflection（RR） 基于 BGP 协议，指定一个或多个 BGP Speaker 为 RouterReflection，它与网络中其他 Speaker 建立连接，每个 Speaker 只要与 Router Reflection 建立 BGP 就可以获得全网的路由信息。
3．IPIP 模式把 IP 层封装到 IP 层的一个 tunnel，常规的网桥是 mac 层的，而 ipip 则是通过两端的路由做一个 tunnel，从而将两个本来不通的网络通过点对点连接起来。
（三）Cilium： Cilium 是一个基于 eBPF 和 XDP 的高性能容器网络方案,是 Kubernetes 第一个基于 BPF 的 CNI，支持 L3/L4/L7 安全策略，支持三层平面网络(如 Overlay，VXLAN 和 Geneve 等)，提供基于 BPF 的负载均衡，提供便利的监控和排错能力，为大规模集群环境而设计。Cilium 的卖点并不是 eBPF，相对于固化的 iptables 或 ipvs 而言，Cillium 真正的卖点是 eBPF 提供的无限可编程能力。
（四）OVN : ovn-kubernetes 提供了一个 OVS/OVN 网络插件，支持 underlay 和 overlay 两种模式。underlay 是容器运行在虚拟机中，而 ovs 则运行在虚拟机所在的物理机上，OVN 将容器网络和虚拟机网络连接在一起；overlay 是 OVN 通过 logical overlay network 连接所有节点的容器，此时 ovs 可以直接运行在物理机或虚拟机上。
总的来说，Overlay 模式对底层网络要求低、落地容易、IP 地址占用少等特点，但是对性能损失比较大。路由模式更易于集成到现在的数据中心的基础设施之上，便捷地连接容器和主机，并在报文过滤和隔离方面有着更好的扩展能力及更精细的控制模型；Underlay 模式对底层网络要求较高，但是如果底层已经有一个完整的虚拟化 IaaS 层，尤其是公有云场景，将云原生能力直接融入到现有的云体系，通过 Underlay 模式实现高性能，灵活可定义的容器网络才是最佳选择。
1.3.3. 容器存储的碎片化
市面上的存储产品种类繁多，主要分为四大类，分别是分布式文件存储，分布式块存储，Local-Disk 和传统 NAS。
（一）分布式块存储： 包括开源社区的 Ceph，Sheepdog，商业产品中 EMC 的 Scale IO，Vmware 的 vSAN 等，分布式块存储不适合容器场景，关键问题是缺失 RWX 的特性。
（二）分布式文件存储： 包括开源社区的 Glusterfs，Cephfs，Lustre，Moosefs，Lizardfs，商业产品中 EMC 的 isilon，IBM 的 GPFS 等。分布式文件存储适合容器场景，但是性能问题比较突出。
（三）Local-Disk： 有明显的缺点，尤其是针对数据库，大数据类的应用。节点故障后，数据的恢复时间长，对业务影响范围广。
（四）传统 NAS： 也是一种文件存储，但是协议网关（机头）是性能瓶颈，传统 NAS 已经跟不上时代发展的潮流。
Kubernetes v1.9 引入的容器存储接口 CSI，并于 v1.13 版本正式 GA。CSI 的引入极大的增强了容器存储生态体系，标准化容器平台与外部存储系统的集成。有状态应用不需要了解底层存储系统的任何信息，只需将数据写入文件系统或块设备的容器存储卷，由容器平台透明地处理存储相关的编排与调度工作。
基于 CSI 实现的持久化 Volume 的创建和挂载流程如下：
1、用户提交 PVC，Kubernetes 平台自动创建出 PV
2、Kubernetes 平台将 PV 和 PVC 进行绑定
3、部署 Pod 并使用已创建的 PVC，Kubernetes 将 Pod 调度到某宿主机
4、Kubernetes 将 PVC 对应的 Volume 进行 Attach 到对应宿主机
5、宿主机上的 kubelet 完成 Volume 的 Mount 操作
总的来说，容器存储方案的选择，需要基于实际的业务需求出发，深刻理解容器平台未来承载的业务类型， 如果基于云平台构建云原生平台，尽量与 IaaS 底层保持一致，同时需要考虑团队的技术实力，开源产品对技术能力要求比较高，选择开源产品，最好有相应的技术人员储备。如果技术储备不足，最好是选择商用产品，虽然成本高点但经过了众多企业的技术验证。
1.3.4. 应用管理的碎片化
一、资源对象及 CRD，Kubernetes 平台开放基础
Kubernetes 标准的资源对象超过一百多个，自下而上可以分为四层：资源层， 实现网络、存储及基础平台等资源对象；调度层， 实现各种调度控制器及调度等资源对象；隔离与服务访问层， 实现资源限制与隔离、配置、身份、路由规则等资源对象；应用层， 实现应用逻辑、服务定义、生命周期控制等资源对象；云原生平台类产品主要是在调度层扩展，通过自定义 CRD 及控制器，实现 Kubernetes 的能力扩展，比如边缘容器，istio 等。
CRD 功能是在 Kubernetes v1.7 版本引入的，通过 CRD 可以快速自定义 Kubernetes 资源对象。CRD 可以是命名空间的，也可以是集群范围的，由 CRD 的作用域(scpoe)字段中所指定的，与 Kubernetes 内置对象一样，删除名称空间将删除该名称空间中的所有自定义对象。基于 Kubernetes 内置对象与 CRD 就可以创建出千变万化的组合；另外同一个资源对象又有多种实现方式，比如 Ingress 就有 10 多种实现，PV 就更不用说，部分互不相干扩展能力存在相互冲突及版本不兼容，一个生产运行的 Kubernetes 容器集群，尤其是启动了 Istio，Knative 能力，CRD 的数量是远远超过 Kubernetes 内置对象，对于开发者与平台管理挑战巨大。
二、从 Helm 到 Operator，实现应用全生命周期管理
云原生应用日趋复杂，仅仅通过 Kubernetes 对象及 Yaml 很难清晰的描述一个复杂的应用程序，所以诞生 Helm 与 Operator。Helm 主要实现是云原生应用打包和版本管理等。Operator 本质是一种调节器模式（Reconciler Pattern）的应用，主要实现云原生应用管理，尤其是有状态应用管理，协调应用的实际状态达到预期状态。
Helm ： 开发非常容易，可以使用 git 仓库管理，运维效率相对不高，用户使用简单，开源生态丰富。
Operator： 开发入门较难，OperatorHub 搭建困难，运维效率更高，用户使用简单，开源生态丰富
建议当前考虑使用 Operator 作为容器应用首选，社区有大量基于 operator 开源实现支持各种中间件和应用。同时也存在比较严重的碎片化问题，在 Helm hub 上 Kafka 的 chart 多达十几个，如果包含 Kafka 配置管理就更多很难选择。Operator Hub 稍微好点，Kafka 有三个 Operator 供选择。
三、OAM 与 KubeVela，走向标准与治理
OAM： Kubernetes 的核心 API 资源比如 Service、Deployment 等，只是云原生应用部分描述，所以衍生出 Helm 及 Operator 以应用为中心，描述一个可部署的应用，但是缺乏标准及规范，复用性差冲突难以排查处理，需要一个专注于应用管理的、标准的、高度一致的模型标准与规范，所以就有衍生出了开放应用模型 Open Application Model （OAM）， 基于 OAM 实现应用描述与基础设施部署，管理应用解耦，通过应用组件（Components），应用部署配置文件（Application Configuration），应用运维特征（Traits）实现平台无关、高可扩展的应用描述能力。
KubeVela： 是基于 OAM 标准实现的，面向平台构建者的、简单易用，高度可扩展的开源云原生平台构建引擎。目标是让任何平台团队都能够以 Kubernetes 原生的方式，快速、高效的打造出适合不同业务场景的、能够直面用户的云原生平台出来。比如构建应用 PaaS、数据库 PaaS、AI PaaS 或者持续交付系统等。KubeVela 开发入门简单，环境搭建困难，混合云场景优势明显，运维效率高，但是处于生态发展初期。
总的来说，Kubernetes 原生的应用原生比较标准，但是一些偏平台的产品及应用就相当杂乱，大部分都只是借助 Kubernetes 屏蔽了底层技术设施差异，对于上层的应用来说没有什么变化。这些应用大部分是传统云时代 PaaS 平台范畴的产品及应用，还有少部分基于云原生技术及理念的新产品，企业及研发团队需要根据自己的需求，通过这些产品及应用拼装成一个面向应用全生命周期的平台，依然有大量的重复建设工作。
1.4. 总结
对 Kubernetes 平台及 CNCF 社区来说， Kubernetes 作为云原生的核心平台，CNCF 作为一个生态运营管理组织，要足够开放，满足上下游个性化集成的需求，确保整个生态繁荣及良性竞争，实现技术与平台快速演进，持续保持行业领先；同时也要去拥抱企业及开发者的真正需求，解决当前企业及研发团队平台杂乱，投入成本过大，无流程难以管控的难题，真正助力企业实现业务价值。
对企业及用户说，“境”优先，“器”其次，在云原生时代，面对复杂的平台，繁荣且碎片化的生态，不要过度追求“神兵利器”，至少先掌握一种工具，能搞定问题的就是好工具。