【云原生】什么是云原生？如何学习云原生？一篇文章带你了解云原生

云原生，相信这个名词大家并不陌生；云原生在近期可谓是爆火，伴随云计算的滚滚浪潮，云原生(CloudNative)的概念应运而生，云原生很火，火得一塌糊涂。可是现在很多人还是不知道什么是云原生，所以今天我们就来聊一聊近期很火的这个名词：云原生吧 。

大家平时经常提到云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商，不过我对于读不懂的文章，一律归因于写文章的人太蠢，当然这不一定是事实，但这样的思考方式能让我避免陷入自我怀疑的负面情绪。

其实，云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。作为云计算领域的一个新兴概念，云原生现在频繁出现在我们的视野中。很多互联网大咖把它奉为至宝，走到哪说到哪，所以我们就先来看一下云原生的起源吧。

云原生的起源

云原生的概念最早开始于2010年，在当时 Paul Fremantle 的一篇博客中被提及，他主要将其描述为一种和云一样的系统行为的应用的编写，比如分布式的、松散的、自服务的、持续部署与测试的。当时提出云原生是为了能构建一种符合云计算特性的标准来指导云计算应用的编写。

后来到2013年 Matt Stine在推特上迅速推广云原生概念，并在2015年《迁移到云原生架构》一书中定义了符合云原生架构的特征：12因素、微服务、自服务、基于API协作、扛脆弱性。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时这时云原生也被12要素变成了一个抽象的概念。

那么接下来我们就来介绍一下CNCF。

CNCF，全称为Cloud Native Computing Foundation，中文译为“云原生计算基金会”。

这个基金会成立于2015年12月11日，属于Linux基金会旗下。

CNCF致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。

所以说，CNCF是云原生领域影响力最大最有话语权的组织。

 

说起CNCF的故事，还要从Cgroups（control groups，控制组群）开始说起。

十六年前，也就是2004年，谷歌开始使用容器技术。到了2006年，谷歌发布了Cgroups，最初叫Process Container（进程容器）。

Process Container的目的非常直白，它希望能够像虚拟化技术那样，给进程提供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力。

带着这样的设计思路，Process Container发布后第二年就进入了Linux内核主干。

因为在Linux内核中，容器（container）这个名词有许多不同的意义，为避免混乱，就更名为Control Groups，也就是Cgroups。

2013年，Docker项目正式发布，2014年，K8s项目也正式发布。

K8s项目的初衷，就是提供一种方式去帮助大家方便、快速、优雅地管理容器。（K8s是云原生的基石，后面会细讲。）

在Google和Redhat发布了K8s之后，这个项目的发展速度非常之快。

2015年，由Google、Redhat以及微软等大型云计算厂商以及一些开源公司共同牵头成立了CNCF云原生基金会。

CNCF成立之初，就有22个创始会员，而且K8s也成为了CNCF托管的第一个开源项目。

 CNCF基金最初对云原生定义是也是深窄的，当时把云原生定位为容器化封装+自动化管理+面向微服务：

The CNCF defines “cloud-native” a little more narrowly, 
to mean using open source software stack to be containerized,
where each part of the app is packaged in its own container,
dynamically orchestrated so each part is actively scheduled 
and managed to optimize resource utilization, 
and microservices-oriented to increase the overall agility 
and maintainability of applications.

这主要因为CNCF基金会在当时的核心拳头软件就是 k8s，因此在概念定义上主要是围绕着容器编排建立起来的生态。其实这也是为什么我们可以看到 CNCF 定义云原生的时候有时感觉就是再说容器生态。

2017年，Matt Stine 在接受 InfoQ 采访时，对云 Cloud Native Architecture 的定义做了小幅调整，具体有以下六个特质：

模块化（Modularity）
可观测性（Observability）
可部署性（Deployability）
可测试性（Testability）
可处理性（Disposability）
可替代性（Replaceability）

 

2019年, VMware Tanzu收购了 Pivotal，其官网给出了云原生最新定义，以及云原生的架构原则：

云原生是一种利用云计算交付模型的优势来构建和运行应用程序的方法论。
当企业使用云原生架构开发和运维应用程序时，它们能更快速地响应客户需求将新想法推向市场。

虽然公共云影响了几乎所有行业对于基础设施的思维模式，但类似云的交付并不仅限于公共环境。
云原生的开发同时适合公共云和私有云，你只需要关心应用程序是如何创建和部署，无需理会在哪部署。

更重要的是能够为开发人员提供按需访问计算能力以及现代数据和应用程序服务。
云原生开发融合了 DevOps、连续交付、微服务和容器。

云原生架构原则：DevOps、Microservices、Containers、Security

2021年，已经有几百家企业和机构加入 CNCF 参与云原生的建设，其中不乏亚马逊、微软、思科、华为、阿里云等大型科技公司。截止到目前（2021年10月），CNCF 已毕业的项目有16个，孵化中的项目有23个。

所以，云原生的发展是与CNCF密切相关不可分离的。

云原生与云计算

 

提及云原生我们就不可能离开云计算。

从云原生的定位可以看到，云原生包含大量新的PaaS层技术和新的开发理念，是释放云计算价值的最短路径，也推动着云计算的再升级。

整个云原生技术栈都是基于开源、开放的技术标准。CNCF也在致力于云原生技术的标准化，为云原生技术和产品的用户提供使用云服务的标准界面，同时避免了厂商锁定。

• 云计算传统的三层架构，即：基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS），它们重塑了 IT 基础设施的形态，节约 IT 成本、提升业务敏捷性。后来再扩展至 “无服务器计算架构”（Serverless，指用户无须购买或关注基础设施，即可运行应用程序，按需付费，弹性扩容，也是 PaaS 演进的一种 “极端” 形态）；
• 而基于云计算的云原生，则重塑了应用程序，摈弃传统的软件架构，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点重新设计，从而建设全新的云化的应用，即云原生应用。

所以，云原生是云计算的升级也是云计算的趋势。

简而言之，云原生不仅是对使用云的应用架构的再升级，也是对云平台的技术和云服务的再升级。从构建现代化应用的角度，我们可以发现，云原生对应用的重构体现在应用开发的整个生命周期中。

云原生的发展趋势

而云计算经过十几年的发展，从一开始讨论什么是云计算，到争论云计算是否是旧瓶装新酒，再到讨论如何建设云基础能力，到如何建设云平台上的应用，随着业界对云计算技术的不断探索，我们对云计算的理解和期望在日益提升。当前，大部分的企业已经确实体会到了云计算带来的竞争优势，并已经建成企业内部的私有云基础能力，或是将数据中心迁移到公有云上。应用如何使用好云计算基础设施，使云计算发挥最大能力，是目前云计算技术中最重要的议题。

运维继续下沉，服务网格将成为主流，Serverless逐步推广

云计算的一个发展方向就是运维下沉，将和业务无关的管理功能和运维工作尽量下沉到基础设施中，应用可以聚焦在业务能力的开发和运营。这个趋势演化的过程，影响了云计算的发展方向。从一开始的虚拟化，到IaaS，到PaaS都是将应用系统的部分运维职责交给平台运维的过程。

软硬结合，解决虚拟化性能问题的利器

随着云计算的发展，虚拟化技术越来越多的被使用，从计算虚拟化到存储虚拟化到网络虚拟化。虚拟化技术带来了很多的好处，虚拟化是基础设施服务化的基础，通过虚拟化，可以实现基础设施即代码，大大提升了资源的可管理性和自动化程度。但是虚拟化带来了另外一个问题，就是性能的损耗和软件进程之间的相互影响问题。

对于性能损耗，会导致需要的资源比实际业务耗费的资源更多，提升了服务器资源的成本；进程之间的相互影响则会导致云平台的整体性能问题，网络虚拟化和存储虚拟化都需要通过软件进程的方式，来处理网络流量和IO。为了实现分布式高可用和减少数据包转发，基础的SDN，SDS的进程通常是和应用进程部署在同一套集群上。这就导致了有可能部分的SDN和SDS的管理进程所在服务由于各种原因，CPU或是内存占用过大，导致无法及时处理网络和IO请求，导致云平台整体性能下降。

容器虚拟机进一步融合

容器和虚拟机的优势和劣势，从容器技术诞生的那天起就一直在争论。容器轻量化，良好的封装能力和部署简便的特点，特别是在Kubernetes出现后，大有取代虚拟机的气势。但是在处理重应用（如关系型数据库，大数据等）的这点上，容器技术显得有些力不从心。另外容器技术在资源隔离和安全性上，还达不到虚拟机的水准，所以在很多场景，仍然是虚拟机的用武之地。

在这种情况下，如何实现容器技术和虚拟化技术的融合，发挥两者的长处，成为云计算的一个发展课题。目前的技术主要有三种，一种是容器虚拟机的混布；一种是轻量级虚拟机；最后是安全容器。

所以，云原生技术是目前技术阶段，企业IT系统的最优模式的集合。企业通过遵循云原生的技术和设计模式，可以充分发挥云计算平台的优势的同时，可以最大限度的减少对开发效率的影响，实现稳定而高效的系统。技术是不断发展的，云原生技术也是一个不断更新迭代的过程，相应的开发习惯和方法也会跟着改变。

云原生的代表技术

• 容器

一般我们说的“容器”（LinuxContainer，LXC），都是“Linux容器”（当然微软也在搞容器，但还没linux那么成熟）。

开源解决方案供应商红帽官网给出的容器定义：

Linux® 容器是与系统其他部分隔离开的一系列进程。

运行这些进程所需的所有文件都由另一个镜像提供，这意味着从开发到测试再到生产的整个过程中，Linux 容器都具有可移植性和一致性。

因而，相对于依赖重复传统测试环境的开发渠道，容器的运行速度要快得多。容器比较普遍也易于使用，因此也成了 IT 安全方面的重要组成部分。

容器提供进程级的隔离，可以将操作系统管理的资源划分到相互隔离的组中，在相互隔离的组之间解决资源使用存在冲突的问题。

比如应用程序（Application）APP 1 ，只能在centos 操作系统上运行；APP2只能在ubuntu操作系统上运行。而同一个操作系统同时运行APP1和APP2就产生冲突。容器技术则恰恰可以解决这类问题。目前主流的容器技术有Docker、LXD以及RKT等。

• Docker

说到容器，就不得不说Docker。

2010年，几个大胡子的年轻人在美国旧金山成立了一家名叫“dotCloud”的公司。这家公司主要提供基于PaaS的云计算技术服务。具体来说，是和LXC有关的容器技术。

LXC，就是Linux容器虚拟技术（Linux container）

后来，dotCloud公司将自己的容器技术进行了简化和标准化，并命名为——Docker。

Docker项目发布时，无非也是LXC的一个使用者。它创建和使用应用容器的逻辑跟Warden等竞争对手没有本质不同。

不过，我们现在也知道，真正让PaaS项目无所适从的，是Docker项目最厉害的杀手锏：容器镜像。

Docker项目通过容器镜像，直接将一个应用运行所需的完整环境，即：整个操作系统的文件系统也打包了进去。

这种思路，可算是解决了困扰PaaS用户已久的一致性问题，制作一个“一次发布、随处运行”的Docker镜像的意义，一下子就比制作一个连开发和测试环境都无法统一的Buildpack高明了太多。

Docker项目大大降低了容器技术的使用门槛。轻量级，可移植，虚拟化，语言无关，写了程序扔上去做成镜像可以随处部署和运行，开发、测试和生产环境彻底统一了，还能进行资源管控和虚拟化。

Docker作为一种开源应用容器引擎，是为开发人员和系统管理员设计的用于构建、发布和运行分布式应用的平台，典型的Docker平台Kubernetes、Openshift V3、Flynn、Deis等。

Docker允许开发人员将各种应用以及依赖包打包到一个可移植的Docker容器中，以Docker容器为资源分割和调度的基本单位，封装整个软件运行时的环境，然后发布到Linux机器上。

按照Docker的设计方案，应用软件的交付过程如同海上运输，操作系统OS如同一个货轮，每一个在OS基础上的软件都如同一个集装箱。

用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员（开发人员或系统管理员）定制。

如此一来，交付一个应用软件产品，就相当于交付一系列标准化组件的集合。

• Kubernetes

有了容器，就需要编排管理容器的生命周期。这里就要提到kubernetes。

Kubernetes，这个单词来自于希腊语，含义是舵手或领航员。K8s是它的缩写，用“8”字替代了“ubernete”这8个字符。

K8s并不是一件全新的发明。它是谷歌根据其内部使用的 Borg 改造成的一个通用容器编排调度器，于2014年6月开源。

同年7月，微软、Red Hat、IBM、Docker等公司，相继加入K8s。

2015年，谷歌将其捐赠给Linux基金会下属的云原生计算基金会（CNCF），K8s也成为CNCF第一个项目。

云可以为我们提供稳定而唾手可得的基础设施，但是业务上云成了一个难题，K8s 的出现与其说是从最初的容器编排解决方案开始，倒不如说是为了解决应用上云（即云原生应用）这个难题。

CNCF中托管的一系列项目，即致力于云原生应用整个生命周期的管理，从部署平台、日志收集、Service Mesh（服务网格）、服务发现、分布式追踪、监控以及安全等各个领域通过开源软件为我们提供一整套解决方案。

Kubernetes作为云应用的部署标准，直接面向业务应用，大大提高了云应用的可移植性，解决云厂商锁定的问题，让云应用可以在夸云之间无缝迁移，甚至用来管理混合云，成为企业 IT 云平台的新标准。

• 微服务

微服务需要从两个方面去理解：什么是"微"、什么是"服务"。

微，狭义来讲就是体积小。

著名的 "2 pizza 团队" 很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来只需要2个披萨就够了）。

而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

传统的单体架构，是以整个系统为单位进行部署。而微服务，则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。

对于单体应用，如果发现某一业务的请求量非常大，那么是无法单独扩展该业务的，只能拷贝整个单体应用，再部署一套环境，来实现集群。

正因为单体应用的缺陷，才有了微服务。

微服务和单体应用的区别，可以用Martin Fowler的这张图来解释：

图中左边是单体架构的集群，右边是微服务集群。

什么意思呢？比如根据每个服务的吞吐量不同，支付服务需要部署20台机器，用户服务需要部署30台机器，而商品服务只需要部署10台机器。这种灵活部署只有微服务架构才能实现。

而近几年流行的Docker，为微服务架构提供了有效的容器。

• 服务网格

服务网格( Service Mesh )，是指用以处理服务与服务之间通信的基础设施层。

其最早由Buoyant公司（开发Service Mesh项目Linkerd的公司）提出，并在内部使用。该公司2016年9月29日第一次公开使用这个术语。

Service Mesh一般用于微服务应用的可配置基础架构层( configurable infrastructure layer )。Istio( 由Google、IBM、Lyft公司在背后进行支持 ) 是目前最广为人知的一款服务网格架构。

Kubernetes是目前Istio唯一支持的容器组织框架。

为什么Service Mesh这么受欢迎？

对许多公司来说，Docker和Kubernetes这样的工具已经 "解决了部署问题"，或者说几乎解决了。但他们还没有解决运行时的问题，这就是服务网格的由来。

什么是解决了部署问题？

使用 Docker 和 Kubernetes 等功能可显著减轻部署的增量操作负担。使用这些工具，部署100个应用或服务不再是部署单个应用的100倍。

这是向前迈出的一大步。对许多公司来说，这导致采用微服务的成本大幅降低。这不仅是因为Docker和Kubernetes所提供了强大的抽象，而且还因为它们使整个组织的打包和部署模式过程标准化了。

Service Mesh的出现，弥补了Kubernetes在微服务的连接、管理和监控方面的短板，为Kubernetes提供更好的应用和服务管理。

因此，Service Mesh的代表Istio一经推出，就被认为是可以和Kubernetes形成双剑合璧效果的微服务管理的利器，受到了业界的推崇。

• 不可变基础设施

在传统的可变服务器基础架构中，服务器会不断更新和修改。

使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器，手动升级或降级软件包，逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。

换句话说，这些服务器是可变的。它们可以在创建后进行更改。

可变基础设施通常会导致以下问题：

在灾难发生的时候，难以重新构建服务。持续过多的手工操作，缺乏记录，会导致很难由标准初始化后的服务器来重新构建起等效的服务。

在服务运行过程中，持续的修改服务器，就犹如程序中的可变变量的值发生变化而引入的状态不一致的并发风险。这些对于服务器的修改，同样会引入中间状态，从而导致不可预知的问题。

不可变基础架构是另一种基础架构范例，其中服务器在部署后永远不会被修改。

程序设计中不可变变量（ImmutableVariable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不在进行更改。

不可变基础架构的好处，包括基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。

它可以缓解或完全防止可变基础架构中常见的问题，例如配置漂移和雪花服务器。但是，有效地使用它通常包括全面的部署自动化，云计算环境中的快速服务器配置，以及处理状态或短暂数据（如日志）的解决方案。

• 声明式API

声明式（Declarative）的编程方式一直都会被工程师们拿来与命令式（Imperative）进行对比。

我们最常接触的其实是命令式编程，它要求我们描述为了达到某一个效果或者目标所需要完成的指令，常见的编程语言 Go、Ruby、C++ 其实都为开发者了命令式的编程方法，

声明式和命令式是两种截然不同的编程方式:

在命令式 API 中，我们可以直接发出服务器要执行的命令，例如： “运行容器”、“停止容器”等；

在声明式 API 中，我们声明系统要执行的操作，系统将不断向该状态驱动。

通俗的说，命令式编程是第一人称，我要做什么，我要怎么做。

操作系统最喜欢这种编程范式了，操作系统几乎不用“思考”, 只要一对一的将代码翻译成指令就可以了。

而声明式编程则类似于“第二人称”， 也就是你要做什么。

有点“”产品经理”和“开发”之间的关系，“产品经理”只负责提需求，而“开发”怎么实现的，他并不关心。

让我们来总结一下上面提到的技术和工具：

k8s是整个云原生的基石，云原生的整个生态体系都是依靠k8s建立起来的。

容器（Container）是k8s的底层引擎。

Docker是应用最广的容器工具。

微服务是docker的好搭档。

服务网格是微服务的辅助，建立在k8s上的针对请求的扩展功能。

不可变基础设施是现代运维的基石。

声明式API是k8s的编码方式。

如何学习云原生

在学习云原生技术之前，首先需要了解以下几点：

• 初学者在学习时，看再多云原生的历史沿革、优势好处以及涉及到哪些技术方向，听再多大佬的“夸夸其谈”，都不如自己动手实践，从部署上线几个应用开始；
• 云原生是一个技术的“时代”，不是某一个的职业或技术产品，而不同的职业方向与目的，学习的内容也会有很大差异；而其中Docker和Kubernetes是云原生的两个核心基础产品，值得所有方向的技术人员、工程师及早开始学习；
• 网络上很多云原生课程虽然都是大厂宝贵的经验，但是大多数内容都是写给运维工程师和架构师看的，不太适合新手学习，需先掌握基础后再来进阶；

动手实战时，建议在本地安装部署好 Docker 环境、Kubernetes 集群以及使用云服务商提供的线上托管 Kubernetes（如腾讯云容器服务TKE、弹性容器服务 EKS）搭配来学习，这才贴近企业实际生产时的真实环境。

尽管也有一些不错的线上实验室，如 Katacoda、play-with-k8s，这些更加建议大家把这些网站涉及的案例给“移植”到自己的学习环境中。

可以先从 Docker 开始学起，Docker 是一个非常容易呈现效果和结果的工具，在粗略了解了容器、镜像和镜像仓库的情况下，只需要几行命令就能启动一些“看得见”的应用程序。Docker的核心思想就是如何将应用整合到容器中，并且能在容器中实际运行。这个整合并运行的过程就是“容器化”。容器化主要分为以下几个步骤：

• 编写应用的代码，应用要能在本地环境正常运行；
• 创建一个 Dockerfile ，Dockerfile 要包含当前应用的描述、依赖以及该如何运行这个应用；比如基础的base环境，系统组件的安装(如apk add, apt install等)、应用代码的拷贝、业务系统依赖的安装（php composer, npm install 等）、分层、stage构建等；
• 对Dockerfile执行docker build命令将项目源代码打包成镜像；
• 将镜像分发到容器镜像服务，如 hub.docker.com 或使用腾讯云镜像服务等；

云原生中最为重要的产品就是 Kubernetes ，简称 K8s，因此我们学习的核心也是K8s。如果说传统云计算时期的操作系统是 Linux，那云原生时代的操作系统就是 K8s 。

Kubernetes入门动手实践基本遵循以下流程，Kubernetes官方技术文档的【教程】(https://kubernetes.io/zh/docs...)部分就有这些基础步骤的讲解：

• 创建本地集群和托管集群
• 使用 kubectl 来创建Depoyment部署应用
• 学会查看 pod 和工作节点
• 使用 Service 公开地暴露你的应用
• 使用 Kubectl 实现应用的扩缩容
• 使用 kubectl 执行滚动更新
• 使用 ConfigMaps、Secrets 实现外部化应用配置
• 了解有状态应用程序和无状态应用程序
• 了解如何限制容器对资源的访问和系统的调用

尽管 Docker 和 Kubernetes 官方技术文档是一个不错的入门教程，但是仍然存在很多新手不可避免的一些“坑”，让原本简单且有意思的动手变得艰难，有的人甚至连安装配置环境就阻力重重。

学习路线

这里不会详细到具体的linux或者计算机网络的底层知识，如果发现在学习其中有对应的疑惑的时候找对应的书籍或资料学习即可。接下来会介绍一下云原生的学习路线和一些推荐学习资源，每个人的学习方式不同，这里的学习路线只是一个个人学习思路参考，希望可以帮助到大家。

1. kubernetes
   云原生中最重要的就是Kubernetes，简称k8s。所以我们的学习核心就是k8s，根据k8s辐射到云原生学习的其他领域，k8s可以说是云原生时代的操作系统，内部的设计是非常的复杂，每一个设计都有他运用的领域，我们可以先尝试去理解里面的一些基本概念，比如Node，Pod，Service等资源对象，慢慢的去了解k8s的网络原理，存储原理，核心组件的运行机制，k8s的拓展等等深入的知识。

推荐一些学习k8s资源：

• 可以在线学习k8s的网站：https://www.katacoda.com/courses/kubernetes
  • k8s的新华字典：Kubernetes权威指南
  • 七牛云团队的k8s书籍：Kubernetes in Action
  • CNCF 官方大使张磊的教学：https://time.geekbang.org/column/intro/100015201

2. 容器运行时
由于所有的项目都是跑在容器里面，所以我们在学习k8s的pod的时候我们就知道我们需要学习一下容器的运行时，比如大名鼎鼎的docker，containerd等。这时候我们就开始设计到landscape的这一块内容了

推荐docker的学习资料：

• Docker技术入门与实战，学习下一些docker的操作命令，知道如何去操作镜像，打包镜像等即可

3. 容器仓库
在我们学习docker的时候，知道了如何打包镜像后，这时候我们可能会有我们自己的一些项目镜像，但是我们又不想上传到dockerHub等公开仓库，我们可能会思考可不可以像gitlab一样搭建属于我们自己的镜像仓库呢？那么这时候我们就来到了landscape的这一块区域，我们可以学习着去搭建一个Harbor去存储我们的私有镜像。

4. 服务发现
学习完容器相关的东西，我们回到我们的k8s，我们发现k8s的数据都存储在etcd中，甚至还能自己服务注册与服务发现，我们想了解一下服务注册，服务发现，配置中心，注册中心等相关的内容，于是我们就来到了landscape的这一块内容：

这里强烈推荐一波etcd，用过都说好，etcd的学习书籍：

• 云原生分布式存储基石：etcd深入解析

5. 代理/网关
继续学习我们的k8s，当我们学习Service的时候，对ingress比较感兴趣，想深入了解一下网络代理，ingress网关或者api网关的时候，我们就可以根据landscape的这一部分内容进行深入的研究，比如envoy，apisix，traefik，mosn等项目。

6. 分布式存储
在学习k8s的时候，碰到一些有状态应用，我们需要保存下一些数据信息，这时候我们可能用到一些分布式存储，这时候我们可以从landscape这一块中找寻我们需要的：

7. 可观测性
在我们的项目都在k8s运行起来后，我们可能需要对项目的一些可观测性有需求，比如ELK日志，Promerheus监控，Skywalking，zipkin链路追踪等，我们同样可以开始学习landscape的这一块的内容：

分享资料：

• 深入浅出Prometheus：原理、应用、源码与拓展详解

8. 服务网格
k8s的功能已经非常强大了，但是他主要是提供服务编排等能力，在服务治理相关能力上却显得不足了，所以我们可以学习服务网格相关的服务治理能力。

istio作为后 Kubernetes 时代的微服务治理框架，是非常值得我们去学习与关注的。

• 深入浅出Istio：Service Mesh快速入门与实践（版本可能老了，可以了解）
• 宋净超大神：https://www.servicemesher.com/istio-handbook/
• 赵化冰大神：https://zhaohuabing.com/istio-practice/

尾言

云原生涉及的内容非常多，上文只是一个抛砖引玉，给各位想学习云原生领域知识的小伙伴一个导火线，实际云原生内容不止上文所列出的内容，可能学到头秃都学不完，大家可以围绕k8s找到自己感兴趣的方向去学习，祝大家在云原生领域都有所成就！