1.3 CNCF与云原生平台
CNCF（Cloud-Native Compute Foundation，云原生计算基金会）由Google等大公司牵头于2015年正式成立，目前有100多家企业成员，其目的是在容器、微服务及DevOps领域里，通过一系列的规范和标准帮助企业和组织，在现代的云化环境中构建架构一致的应用。
CNCF的Landscape定义了关于Provisioning、Runtime、容器编排、PaaS平台、微服务治理等多个容器和微服务相关子领域的开源组件和技术标准。
1.3.1 CNCF社区
CNCF Landscape定义了各领域中优秀的云原生组件。Landscape的发展速度很快，近几年不断地纳入新的应用和组件，外表纷繁复杂。CNCF中定义的逻辑是很清晰的，关键的组件也很有限。在图1-4中，1～9是CNCF Landscape中的关键部分。
1）第一部分是内存数据库和关系数据库部分。核心和常用的组件有：关系型数据库MySQL和PostgreSQL、内存数据库Redis、分布式事务组件Seata、文件存储数据库MongoDB。这是第一部分的几个核心组件，其他组件并不是没有用，只是这几个组件占据了云原生社区，特别是国内云原生社区的大部分关注。再就是云原生主推的数据库Vitness发展速度也很快，它是基于MySQL的主从复制数据库。
2）第二部分的重点是Spark、Flink这两个流式数据分析技术，以及Kafka和RabbitMQ这两个消息中间件。
•图1-4 CNCF全景图
3）第三部分的重点是Helm。这是一个将批量的Kubernetes pod资源声明文件合并成一个整体，形成一个包括多个应用组件的完整应用定义包，并支持部署运行的一套组件。
4）第四部分的重点是GitLab。这是一个开源的代码仓库实现，并支持流水线。另外Jenkins是传统主流的流水线调度引擎。
5）第五部分的重点是Kubernetes。
6）第六部分的重点是Istio。Istio是主流的Service Mesh框架。
7）第七部分是容器领域的三大标准，分别是计算部分的CRI标准，存储部分的CSI标准，网络部分的CNI标准。CRI标准的权威实现是Containerd，在2020年年底，Kubernetes原生不支持Docker容器引擎，原因是Docker底层不是CRI标准（但是Docker有dockersim，通过dockersim实现了CRI-O标准的接口转换）。CSI标准的主流实现是Ceph，这是最为主流的分布式存储技术。CNI作为网络标准，有多个主流的网络实现，包括Calico、OVS、Flannel等。
8）第八部分是边缘云、部署服务、容器安全和密钥管理相关的云原生组件。这里面最为常用的是Harbor，是一个分布式镜像仓库组件。
9）第九部分是监控和日志部分，最为主流的监控组件就是Prometheus，日志组件最为主流的是ELK日志套件。
上面简单介绍了一下CNCF社区的全局概貌。云原生社区集合了几乎所有主流云服务供应商和所有跟云相关的技术，同时涉及了很多的商业竞争，把云原生社区完整地了解透彻需要大量的学习和研究，需要投入大量的时间和精力。不过好在云原生有它主流的一些技术体系和技术组件，把握了主流的这部分内容，相当于80%的云原生内容都已经掌握了。
为了能够充分地理解和掌握云原生下的安全体系，在后面的章节中，会有一些案例和实际操作。本章的介绍比较简短，不可能让大家通过这么一点信息建立起对云原生技术的支撑，但是读者可以通过一定的学习迅速掌握前述9点当中的重要组件，从而能够在云原生技术大浪中畅游而不会感到不适。这些基础的组件和技术包括Kubernetes、ELK、Helm、Redis、RabbitMQ、Jenkins、GitLab、Harbor、Ceph、MySQL，以及容器领域三大接口标准CRI、CSI、CNI。
1.3.2 云服务商与云原生
随着云原生技术的推广普及，国内外主流云服务提供商都投入了大量的精力在云原生的推广上。在云服务提供商的服务目录里，普遍都有较为完善的云原生支持。
国内厂商比如阿里云、华为云等在容器相关产品、微服务产品，以及云原生中间件及数据库产品、DevOps产品等方面都有对应的服务能力，详见表1-2。
表1-2 国内主流云服务商与云原生
Google在2019年发布的Anthos融合了GKE、私有化Kubernetes服务、Kubernetes集群纳管能力、容器应用部署能力和应用配置管理能力，是一个完整的云原生混合云平台。
从表面上看，在云原生技术领域，从基础容器技术到Kubernetes平台，到中间件直至DevOps工具链，基本上都是以国外的技术为主，鲜有由国内发起的原创技术。实际上，国内的云原生技术发展也有很多优秀的产品，除了一些表现抢眼的中间件和微服务框架之外，由阿里云联合微软提出的OAM（Open Application Model）更是其中的翘楚。
OAM将应用软件运行的基础设施、应用的配置和运维策略以及应用本身的定义综合起来，形成了一整套围绕应用的完整定义规范。这套定义规范支持异构平台、容器运行时、调度系统、云供应商、硬件配置等信息。基于这套规范定义的应用Yaml配置，能够自底向上从资源层到应用层直至应用运维策略，在云原生平台上把应用完整地建立起来。目前OAM也处在迅速的进步当中，未来会有更进一步的发展。
1.3.3 利用开源技术搭建云原生平台
云原生社区秉承开放原则，集合了大部分云计算行业的主流公司和大量的开源社区力量。在这些力量下，围绕容器和Kubernetes的技术体系迅速地迭代，利用开源技术搭建一套完整的云原生平台是可行的。
此外，云原生技术本身就代表着统一，使用开源技术搭建的私有化云原生平台以及在上面开发的云原生应用，理论上可以轻松地迁移到任何其他云原生平台上，而不需要做调整适配。
采用主流开源技术搭建云原生平台，并运行一个简单的云原生应用，其最终形态大体上如图1-5所示。
•图1-5 利用开源技术搭建云原生平台
搭建上面的云原生平台在硬件资源上需要三台服务器，这三台服务器至少需要4核CPU、8GB内存，并且通过千兆网卡连接。搭建步骤如下。
1）使用Kubernetes安全工具，按照Kubernetes集群推荐使用Kubeadm（https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/）。
2）在部署好的Kubernetes集群中安装Helm，通过Helm来安装后续的其他服务。
3）通过Helm来安装部署分布式存储GlusterFS、Redis服务、MySQL服务、GitLab或Jenkins。
4）创建代码库，配置Jenkins流水线。
5）通过流水线将代码打包构建成容器镜像，并存放到镜像仓库中。
6）通过容器镜像来启动微服务。微服务使用ETCD作为注册中心，同样也使用ETCD作为配置中心。
7）Kubernetes集群中运行的微服务对外通过集群Ingress提供服务，外部请求通过Ingress访问运行在集群中的微服务。