【云原生布道系列】第一篇：不谋全局不足以谋一域

本文首发在有CNCF、信通院、华为云牵头成立的全球云原生专业交流组织“创原会”的专刊第三期

云原生体系知识地图大纲：

​

锲子

       云原生概念这几年非常火爆，本人因有幸参与公司云原生转型项目调研，开始接触这一庞大技术体系，再通过与同业、各大头部云厂商超过150场的密集研讨交流，方得初窥全貌。同时，也看到业界对云原生体系的解读纷繁庞杂，慎思之下，觉得有必要涤清迷雾，故著此文。

一、云原生定义界定

        云原生（Cloud Native）的概念最早是由Pivotal公司的Matt Stine于2013年提出，到2015年，Matt Stine在《迁移到云原生架构》一书中第一次全面定义了符合云原生架构的几个特征——12因素、微服务、自敏捷架构、基于API协作、扛脆弱性。经过多次发展，当前Pivotal官网对云原生的最新概括为4个要点——DevOps、持续交付、微服务、容器。 

       而另一边，云原生计算基金会（CNCF）也于2015年7月成立，由Google 牵头成立，隶属于 Linux 基金会，目前主流云厂商（包括AWS、微软 Azure 、华为、阿里、IBM、腾讯等）均已加入。CNCF的组织定位在于推广技术、形成社区、开源项目管理与推进生态系统健康发展，故其对云原生的定义主要偏技术范畴，具体为——容器化封装、自动化管理、面向微服务、服务网格(Service Mesh)和声明式API。

       从上述背景可以看到，CNCF将云原生的定义更偏向于界定云原生应用的技术能力特征，而Matt Stine的定义从最初的技术能力特征，逐步扩展到了研发管理。如果站在企业数字化转型的角度来做普适推广，Matt Stine的定义会显得更加立体化又简明易懂，也更符合企业管理者的云原生转型全面价值目标。其对云原生概括为4个要点——DevOps、持续交、微服务、容器，其实笔者更倾向于将DevOps与持续交付合二为一，统称DevOps——毕竟DevOps敏捷交付体系建设本就是为了持续地敏捷交付业务价值。因此本系列中，笔者将云原生体系（而不只是云原生技术体系）的定义依然浓缩为传统三驾马车（DevOps+微服务+容器），这其中既囊括了技术面解决方案思维，也能包含研发管理方面的建设思路，以期能真正成为解锁企业数字化的“他山之石”。

​

云原生三驾马车

二、云计算演进之路

​

 三代云计算演进历程

        众所周知，云计算技术的发展离不开虚拟化技术的高速演进，而虚拟化技术最早可以追溯到1959年克里斯托弗在《大型高速计算机中的时间共享》一文中的阐述。而本文论述的三代云计算技术，特指基于x86的PC计算平台上的演进，也即从1999年VMware公司推出商业版虚拟化软件VMaware Workstation起，不包含之前的大型机虚拟化演进历史。

        第一代云计算技术以VMare的全软虚拟化技术为代表，其最早是为了解决软件程序在不同操作系统及不同厂商兼容型PC机上统一运行的痛点问题，以期屏蔽WinTel时代大量兼容型台式机的硬件差异、OS差异（特别是Windows与Linux两大阵营），为用户提供完整的标准化虚拟X86计算平台，使用户可以无差别运行任何在现有X86物理机上运行过操作系统和软件。在当时的时代背景下，其在资源虚拟化方面的贡献绝对是革命性的，也一举奠定了VMare在虚拟化解决方案的全球领导厂商地位。

        但是VMare基于普适全市场PC机且未借力底层硬件的纯软设计思路，必然需要花费大量架构精力去做各类异构环境的兼容，同时以软件模拟所有硬件资源（特别是对CPU特权指令的捕捉与模拟），必然带来运行性能上的巨大损耗，也即我们常看到的虚拟机上跑程序怎么都感觉比物理机慢。于是，计算虚拟化技术后续又逐步发展出了以Xen为代表的半虚拟化方案、以KVM为代表的硬件辅助虚拟化方案。

       但是不可否认，其代表的第一代云计算技术，为企业IT架构特别是计算资源的自动化管理提供了非常高效的解决方案，极大地提高了计算资源利用率与伸缩弹性、大幅降低了IT运维运营成本，其弹性扩容、资源超卖、故障迁移等云计算典型能力特征，在云计算技术演进到第三代的今天，依然是评估一朵云关键基础技术能力的关键指标。

       如果说第一代云计算技术集中解决了计算资源的虚拟化，那第二代云计算技术的突破就集中体现在“软件可定义”这个关键词上，其中尤为值得关注的便是SDN技术（即软件定义网络）。严格来说，在VMware将计算资源实现虚拟化之后，云平台已经具备一定的软件定义计算的能力了，而SDN的出现则大幅下推了软件可定义的企业IT架构下界——由计算层(主要是OS)下推到了网络层，而且大幅扩展了企业IT架构可虚拟化的范围——从单服务器拓展到了整个数据中心。

       第二代云计算技术伴随着AWS、Azure、阿里云、腾讯云、华为云等公有云厂商的崛起而发扬光大，当前正热火朝天地推动着各行业大中小型企业的IT架构云化演进，“上云”已然成为企业IT架构升级的必然选择。

       然而，IT上云的“前浪”还未上岸，云原生转型的“后浪”又已轰然而至。随着以Docker+K8S为代表的容器技术与云的大规模结合应用，基本可以判断——云计算技术已经发展到第三代了，即云原生时代。

        以往云计算对企业IT架构的支撑仅仅停留在IT资源管理层面，即其只是作为一项IaaS层的资源管理方案来展现价值，虽然贡献巨大但对企业研发架构与组织管理的变革推动依然不够全面彻底。而云原生体系，是基于资源全面虚拟化、应用运行标准化基础上，演进成了一整套成体系解决方案，落地着力点便是容器+微服务+DevOps。

        诚然，这三架马车是需要长于云上的（现阶段也有大量专家脱离云，基于其商业目的或自身技术认知局限，独独侧重容器来谈云原生，这是非常片面而值得商榷的），只有充分结合了云的软硬件一体化协同能力，才能真正使企业技术架构有质变性提升、IT研发效能有肉眼可见的效率提升，如此才能真正发挥云原生1+1+1>3的效果。

​

云原生不能以偏概全

三、基于云计算再来看云原生三驾马车——老树发新芽

       若单论三项技术，其实都不新潮。容器技术看似新鲜，但其实早在2001年，通过 Jacques Gélinas的VServer项目，隔离环境的实施就进入了Linux领域，这便是容器技术的雏形。只不过直到2008年，Docker的崛起才让容器技术广为人知(引自RedHat官网《容器简史》)。

       而微服务技术就更“老”了，从下图来看，软件应用架构从最初的单体式架构，到上个世纪八十年代的MVC架构(1979年，Trygve Reenskaug在一篇论文中首次提出MVC模型)，再到跨进程的RPC架构(Birrell和Nelson在1984 发表于ACM Transactions on Computer Systems 的论文《Implementing remote procedure calls》对 RPC 做了经典的诠释)，再到上个世纪90年代中期出现的SOA（全称Service-Oriented Architecture），再到2014年Martin Fowler与James Lewis共同提出的微服务（Micro-Service），其一路就代表着IT开发技术的发展历程。而就实现本质而言，从RPC架构其实就已经与现在的微服务技术同宗同源了。

​

软件应用架构演进历史

      而DevOps，最早于2009 年6月，在美国圣荷西举办的第二届Velocity大会上，一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，便成为了DevOps 萌发的标志。

       所以若论各单项技术，都是10年前的“老”技术了，但是在云上进行融合后，所产生的“化合反应”才能真正推动企业的数字化转型，云原生也才能真正成为企业数字化转型的核心引擎！

        这三驾马车中“容器”是承上启下的至关重要的一层，往下，容器技术代表着IT基础设施（计算、存储、网络等）在资源虚拟化技术成熟并大规模商用（第二代云计算）之后，在资源标准化道路上的又一关键进步；往上，则标志着业务应用经微服务化大规模解耦、能力细粒度拆分与复用之后，在运行依赖自包含、运维自动化、研发敏捷化方面的可大规模落地的标准化解法的到来。

1、云+容器质变性推进计算环境的运行标准化进程

       当前的第三代云计算技术，首先是基于第二代云厂商的公有云大规模实践发展而来，即便沉淀到私有云领域，基本都是沿用了公有云架构，其在基础资源管理方面的处理思路也充分体现了公有云的需求特点。

       首先便是基础硬件标准化思路的变革——第二代云对于基础硬件的标准化思路与VMare第一代云截然相反，VMare企图以软件全虚拟化技术去全面兼容市面参差不齐的异构PC机，而第二代云则反其道行之，基于公有云资源超大规模带来的话语权，其反向要求入云纳管的硬件设备，特别是计算服务器首先必须是满足云厂商兼容性准入标准的（甚至根据云厂商要求进行定制），由此便可大幅降低云平台硬件兼容适配范围。再基于此来进行针对性调优、持续推动硬件辅助虚拟化技术进一步发展，最终大幅降低虚拟化性能损耗。目前头部厂商均宣称其基于KVM的虚拟机技术，性能损耗均已能降低到5%以内（优秀者可以到3%以内）。

       由此可以预见，全行业级别的云基础硬件规格标准必然在不远的将来出台（当然这也有赖国家主导成立的相关云计算产业协会来牵头），并由此倒推整机硬件厂商进行标准化生产，再上溯倒逼上游零部件厂商标准化生产，最终实现全行业全产业链的深度协同标准化。

       第二点，随着AWS的Nitro硬件卡、阿里神龙卡的出现，结合英特尔的DPDK/SPDK技术，出现了服务器上网络处理指令“绕过”CPU、将流量卸载到PCI扩展卡处理的云网络性能加速方案，即智能网卡方案(Smart NIC)，此方案能大幅提升云网络性能、全云存储性能（知名厂商产品还包括Intel SmartNIC C5020X和N5010、NVIDIA BlueField-3 DPU、Broadcom BCM58800、腾讯云的黑石、华为云的擎天等），应用此类智能网卡的服务器在特定领域（例如高性能计算、云存储、裸机容器）将拥有无可比拟的性能优势。

       基于智能网卡卓越的性能加速优势，随着头部云厂商的市场占比不断攀升，定制版智能网卡、定制版服务器的市场占比也将不断提升，继而可以进一步展望一下，智能网卡会否分担更多特定CPU/GPU的任务（NVIDIA已将智能网卡升级为DPU）？而回到本节中心观点，在通过增加PCI扩展卡方式提升通用云服务器特定领域性能的同时（目前已实现的是网络、存储），进一步增加了云厂商在云服务器领域的标准话语权，从而也更能反向推动传统服务器厂商的标准化生产程度。

       第三点，过往云端计算资源的全局调度、弹性伸缩能力，均是依托虚拟化技术（不论是VMware的软件虚拟化，亦或VT-x/VT-d的通用硬件虚拟化技术）来实现，本质上依然是借力单台云服务器的宿主机操作系统的资源调度能力来实现，而在“云服务器定制化、SDN技术的出现使得云上网络也可软件定义、智能网卡能力不断强化”这三方面因素驱动下，操作系统级调度能力由单机上收至全云调度中心、软硬协同一体化的全云资源调度管理成为了可能，这一点对于传统虚机类应用或许收益不那么明显，但是在容器领域，其影响将是革命性的。

       目前容器场景的运行模式是宿主机+虚拟机+Docker容器的三级运行模式，一般就意味着三层网络传输的转换延时，即便通过专有云SDN能力将Overlay网络与容器网络拉通成一个平面，在金融等时延敏感场景，性能表现依然不够理想。容器技术要达到真正生产级可用，说到底，还是需要将容器网络流量也卸载到硬件、由云调度中心接管容器宿主机资源调度，也即只有真正实现智能网卡加持的裸金属容器方案（即宿主OS上直接运行容器，并实现资源自动弹性伸缩），才能彻底替代物理机部署模式，来满足企业日益高涨的高性能、大并发、低延时、高算力、高容错等互联网场景需求。企业应用云原生转型的第二步“容器化改造”才能无顾虑地全面开展。

       第四点，容器服务长在云上，相比物理机环境或者虚机环境，通过SDN可将容器网络平面与云上(Overlay)网络平面拉平，做统一网络规划设计，也便于容器应用与传统应用的统一网络管理与安全策略控制。当前开源容器网络解决方案如flannel、calico、weave、Canal等，均是基于过往Internet模式下海量分散单机寻址路由的背景设计，方案出发点都在单容器或单宿主机，即仅从容器来设计容器网络，并未站在企业实际落地的角度来设计容器网络。而云上容器服务的网络解决方案，从调研来看，均是直接借力云上SDN能力，将容器网络与Overlay网络拉平，依托VPC、智能网卡等先进云技术来提升容器网络性能、简化网络管理，方案设计出发点便是以全数据中心网络一体化拉通为设计目标，不论方案高度还是可落地性均非开源纯容器网络方案可望其项背。这也是笔者坚持“不能脱离云单以容器来论云原生”的另一核心原因！

2、云+容器+微服务，拔高基础设施上限至PaaS层

      依托云平台的资源软件可定义能力，搭建统一大集群规格的PaaS服务，为传统企业瞬时提供能比肩一线互联网企业的高性能、高可靠的中间件服务与应用开发框架能力，并进一步推动企业内开发框架标准化进程。

       微服务的核心思想便是能力拆分、功能解耦，其与容器是天然一对——服务的并发弹性要求可通过容器的水平伸缩能力来完美匹配、服务的高可靠要求可通过容器的自动恢复机制来实现。同时，基于应用服务的全面容器化，应用开发框架中的大部分非业务相关的框架性能力便能与业务应用逐步解耦，以SideCar方式伴生运行——此举既能实现应用框架独立于业务应用的自主升级，也能使业务开发团队更加聚焦于业务功能开发，同时为跨系统、跨技术栈的真正全链路服务追踪、全局服务治理提供技术落地可能性，这便是ServiceMesh。

       而即便不用容器技术，仅基于云+微服务使用场景，应用依赖的中间件服务（例如常见的Redis、MQ等）也能通过云端标准PaaS服务提供，并支持分租户、实例级隔离使用。此类公共组件，依托云端的规模化集群部署，可轻松提供比肩一线互联厂商的大并发、高性能、自动弹性扩缩容的中间件服务，为业务应用的性能提升、稳定性提升提供统一化、规模化、专业化技术服务保障。

       在云原生时代，PaaS服务也将成为云端基础设施，在短时间内大幅提升企业系统的运行性能、稳定性的同时，也能大幅降低企业中间件建设成本、开发框架的维护成本、架构人员能力要求与精力投入，同时，借助业务上云，也能轻松实现应用开发框架收敛、中间件服务标准化，将其版本迭代管理、能力演进节奏都依托云端实现，其企业架构治理前景也是非常可观的。

3、云+容器+DevOps，依托运行标准化，降低DevOps对接成本，真正使研发全流程自动化成为可能。

        基于云+容器来进行DevOps敏捷化运作，其核心收益点在于——容器依赖自包含特性带来的CD环节（持续发布）的对接改造成本的大幅降低、基础运行环境大幅软件可定义之后系统资源的自动化申请与创建使得研发全流程自动化有了真正落地可能。

        DevOps这个概念并不新鲜，但是在云原生时代以前，除了一线互联网企业，鲜有成功案例，其一大原因在于应用依赖环境的繁杂，特别传统企业，历史遗留系统多、技术栈庞杂、框架版本碎片化严重，若要在CD环境对接改造所有系统的各类运行环境，对接成本高、技术复杂度高、发布后监控反馈环节对接难度大，最终导致改造后系统运行风险反而不可控。故而只能在Java等少数“先进且标准”、对接成本更低的领域试点，全面推广几无可能。

        而容器技术出现后，业务应用统一打包成依赖自包含的容器镜像，对运行环境的依赖程度大幅降低，DevOps的流水线系统只需要对接云上统一的容器发布系统，即可轻松实现各类技术栈应用的自动化发布，再依托云平台全栈的容器运行状态监控机制、ServiceMesh流量劫持等能力，在应用发布后状态监控环节，也有了可低成本实现的标准化解决方案。整体自动化发布方案也更加立体，更具备生产落地可行性。

        第二个原因在于，在传统机房的基础设施运行环境，系统运行资源、网络、安全策略等程序运行相关的配置类资源的下发多为手工操作、流程断节，即便在编码研发环节能做到持续集成、自动化构建，应用包自动化推送与部署，中间环节的应用配置下发或变更依然是手工操作，并不能真正实现全流程自动化，也就依然无法实现快速迭代发布。而在第二代云计算技术之后，有赖云上技术、存储、网络、安全等资源的软件可定义，程序运行所需配置类资源通过调用云端标准接口即可开通或下发，使全流程自动化发布真正成为可能。

        第三点在于，在ServiceMesh出现以前，大部分应用运行保障相关的框架级非功能特性（如弹性、韧性、安全、可观测性、灰度等）均依赖不同技术栈的应用开发框架能力来保证，甚至如在开发框架上述能力缺失的情况下，还需要业务开发团队自建，这就导致了此类特性涉及的运维自动化、运行监控等工具能力也需要重复建设多套，很难做标准统一的同规格高质量建设，因此即便前面CI/CD做到了全流程自动化，自动化发布后也不敢在生产无值守运行。这一点在容器环境，伴随着ServiceMesh技术的出现，才真正有了标准化解法。

四、云原生体系加速业务敏捷迭代

        综上所述，在云原生时代，通过云上环境的软件可定义能力、标准化能力，已经可以使大量研发管理操作、运维监控操作由过去的手工处理变为自动化、标准化的系统动作，从而整体性提升企业IT研发运维自动化水平、质变性跃升软件开发架构能力、指数级提升PaaS服务并发规模与稳定性，最终加快业务研发敏捷迭代速度，是一场彻底的科技引领业务的转型变革。

        随着业务大规模上云，研发组织、团队技能知识结构也需要根据云的特性来做适配性调整（也即认知上云、系统上云、技能上云、组织上云）。

        一方面云上应用开发框架、PaaS服务充分结合了云的特性，其持续迭代、运营运维的能力要求，对平台框架开发人员、业务团队架构师的能力要求变得更高了，以往上述人员只需要精于软件开发框架，而云原生体系下，还需要懂云、懂容器，技术能力需要往全栈方向延展；另一方面，传统IT部门中研发与运维是分离的，部门并行设立、工作独立运作，而上云之后，因敏捷迭代要求，开发与运维的协作需要更加紧密，不论是平台开发框架、PaaS服务、业务系统，均需要以产品化思路来运作，这就要求管理者、架构师、业务人员、开发人员、运维人员、运营人员均需要从过往工具化软件开发思维提升到产品化研发思维中来，并形成配套的产品型研发团队。即便业务部门、研发部门与运维部门依然并行设立，但“管人”与“管事”也要开始做分离，以“事”聚“人”，如此才能适应快速迭代要求，业务才能真正“敏”起来。

​

云技术变革逐层驱动企业研发与管理模式的变革

五、小结 

       也因此，我们可以看到，云原生时代的三驾马车，已经不仅仅是针对云原生应用的技术面的能力表述，还蕴含了依托云的IT研发全生命周期管理含义与研发团队组织思想，因为更立体。云原生体系是企业管理模式向互联网模式进化的核心关键技术与管理思想、组织流程的深度融合，应该也能成为实现国家的互联网+战略的一条重要路径，也必将大幅推动中国乃至世界企业的互联网化进程！

        当然在互联网化过程中，笔者依然建议“以我为主、拿来主义”，而不要直接照搬，毕竟目前来看，互联网的经验，科技是其所长，管理是其所短，传统行业有自身的历史背景与行业特点，取长补短，方能在云原生引擎的核心驱动下，实现敏稳业务的双速迭代。

​

 敏稳业务双速迭代

参考链接：

什么是 Linux 容器？

微服务浅述---架构演进

RPC 发展史

微服务架构诞生的今世前生大揭秘

DevOps的那些事儿——DevOps的前世今生

虚拟机的实现原理

《重识云原生系列》专题索引：

1. 【云原生布道系列】第一篇：不谋全局不足以谋一域
2. 【云原生布道系列】第二篇：云原生时代领域解决方案专家的价值
3. 【云原生布道系列】第三篇：“软”饭“硬”吃的计算

1. 第二章计算第1节——计算虚拟化技术总述
2. 第二章计算第2节——主流虚拟化技术之VMare ESXi
3. 第二章计算第3节——主流虚拟化技术之Xen
4. 第二章计算第4节——主流虚拟化技术之KVM
5. 第二章计算第5节——商用云主机方案
6. 第二章计算第6节——裸金属方案
7. 第三章云存储第1节——分布式云存储总述
8. 第三章云存储第2节——SPDK方案综述
9. 第三章云存储第3节——Ceph统一存储方案
10. 第三章云存储第4节——OpenStack Swift 对象存储方案
11. 第三章云存储第5节——商用分布式云存储方案
12. 第四章云网络第一节——云网络技术发展简述
13. 第四章云网络4.2节——相关基础知识准备
14. 第四章云网络4.3节——重要网络协议
15. 第四章云网络4.3.1节——路由技术简述
16. 第四章云网络4.3.2节——VLAN技术
17. 第四章云网络4.3.3节——RIP协议
18. 第四章云网络4.3.4.1-2节——OSPF协议综述
19. 第四章云网络4.3.4.3节——OSPF协议工作原理
20. 第四章云网络4.3.4.4节——[转载]OSPF域内路由
21. 第四章云网络4.3.4.5节——[转载]OSPF外部路由
22. 第四章云网络4.3.4.6节——[转载]OSPF特殊区域之Stub和Totally Stub区域详解及配置
23. 第四章云网络4.3.4.7节——OSPF特殊区域之NSSA和Totally NSSA详解及配置
24. 第四章云网络4.3.5节——EIGRP协议
25. 第四章云网络4.3.6节——IS-IS协议
26. 第四章云网络4.3.7节——BGP协议
27. 第四章云网络4.3.7.2节——BGP协议概述
28. 第四章云网络4.3.7.3节——BGP协议实现原理
29. 第四章云网络4.3.7.4节——高级特性
30. 第四章云网络4.3.7.5节——实操
31. 第四章云网络4.3.7.6节——MP-BGP协议
32. 第四章云网络4.3.8节——策略路由
33. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
34. 第四章云网络4.3.10节——VXLAN技术
35. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
36. 第四章云网络4.3.10.3节——VXLAN隧道机制
37. 第四章云网络4.3.10.4节——VXLAN报文转发过程
38. 第四章云网络4.3.10.5节——VXlan组网架构
39. 第四章云网络4.3.10.6节——VXLAN应用部署方案
40. 第四章云网络4.4节——Spine-Leaf网络架构
41. 第四章云网络4.5节——大二层网络
42. 第四章云网络4.6节——Underlay 和 Overlay概念
43. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
44. 第四章云网络4.7.2节——virtio网络半虚拟化简介
45. 第四章云网络4.7.3节——Vhost-net方案
46. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
47. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
48. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
49. 第四章云网络4.7.8节——SR-IOV方案
50. 第四章云网络4.7.9节——NFV
51. 第四章云网络4.8.1节——SDN总述
52. 第四章云网络4.8.2.1节——OpenFlow概述
53. 第四章云网络4.8.2.2节——OpenFlow协议详解
54. 第四章云网络4.8.2.3节——OpenFlow运行机制
55. 第四章云网络4.8.3.1节——Open vSwitch简介
56. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
57. 第四章云网络4.8.4节——OpenStack与SDN的集成
58. 第四章云网络4.8.5节——OpenDayLight
59. 第四章云网络4.8.6节——Dragonflow

60.  第四章云网络4.9.1节——网络卸载加速技术综述

61. 第四章云网络4.9.2节——传统网络卸载技术

62. 第四章云网络4.9.3.1节——DPDK技术综述

63. 第四章云网络4.9.3.2节——DPDK原理详解

64. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

65. 第四章云网络4.9.4.2节——智能网卡实现

66. 第六章容器6.1.1节——容器综述

67. 第六章容器6.1.2节——容器安装部署

68. 第六章容器6.1.3节——Docker常用命令

69. 第六章容器6.1.4节——Docker核心技术LXC

70. 第六章容器6.1.5节——Docker核心技术Namespace

71. 第六章容器6.1.6节—— Docker核心技术Chroot

72. 第六章容器6.1.7.1节——Docker核心技术cgroups综述

73. 第六章容器6.1.7.2节——cgroups原理剖析

74. 第六章容器6.1.7.3节——cgroups数据结构剖析

75. 第六章容器6.1.7.4节——cgroups使用

76. 第六章容器6.1.8节——Docker核心技术UnionFS

77. 第六章容器6.1.9节——Docker镜像技术剖析

78. 第六章容器6.1.10节——DockerFile解析

79. 第六章容器6.1.11节——docker-compose容器编排

80. 第六章容器6.1.12节——Docker网络模型设计

81. 第六章容器6.2.1节——Kubernetes概述

82. 第六章容器6.2.2节——K8S架构剖析

83. 第六章容器6.3.1节——K8S核心组件总述

84. 第六章容器6.3.2节——API Server组件

85. 第六章容器6.3.3节——Kube-Scheduler使用篇

86. 第六章容器6.3.4节——etcd组件

87. 第六章容器6.3.5节——Controller Manager概述

88. 第六章容器6.3.6节——kubelet组件

89. 第六章容器6.3.7节——命令行工具kubectl

90. 第六章容器6.3.8节——kube-proxy

91.  第六章容器6.4.1节——K8S资源对象总览

92. 第六章容器6.4.2.1节——pod详解

93. 第六章容器6.4.2.2节——Pod使用(上)

94. 第六章容器6.4.2.3节——Pod使用(下)

95. 第六章容器6.4.3节——ReplicationController

96. 第六章容器6.4.4节——ReplicaSet组件

97. 第六章容器基础6.4.5.1节——Deployment概述

98. 第六章容器基础6.4.5.2节——Deployment配置详细说明

99. 第六章容器基础6.4.5.3节——Deployment实现原理解析

100. 第六章容器基础6.4.6节——Daemonset

101. 第六章容器基础6.4.7节——Job

102. 第六章容器基础6.4.8节——CronJob

103. 第六章容器基础6.4.9.1节——Service综述

104. 第六章容器基础6.4.9.2节——使用 Service 连接到应用

105. 第六章容器基础6.4.9.3节——Service拓扑感知

106. 第六章容器基础6.4.10.1节——StatefulSet概述

107. 第六章容器基础6.4.10.2节——StatefulSet常规操作实操

108. 第六章容器基础6.4.10.3节——StatefulSet实操案例-部署WordPress 和 MySQL

109. 第六章容器基础6.4.10.4节——StatefulSet实操案例-使用 StatefulSet 部署Cassandra

110. 第六章容器基础6.4.10.5节——Statefulset原理剖析

111. 第六章容器基础6.4.11.1节——Ingress综述

《云原生进阶之容器》专题索引：

1. 第一章Docker核心技术1.1节——Docker综述
2. 第一章Docker核心技术1.2节——Linux容器LXC
3. 第一章Docker核心技术1.3节——命名空间Namespace
4. 第一章Docker核心技术1.4节——chroot技术
5. 第一章Docker核心技术1.5.1节——cgroup综述
6. 第一章Docker核心技术1.5.2节——cgroups原理剖析
7. 第一章Docker核心技术1.5.3节——cgroups数据结构剖析
8. 第一章Docker核心技术1.5.4节——cgroups使用
9. 第一章Docker核心技术1.6节——UnionFS
10. 第一章Docker核心技术1.7节——Docker镜像技术剖析
11. 第一章Docker核心技术1.8节——DockerFile解析
12. 第一章Docker核心技术1.9节——docker-compose容器编排
13. 第一章Docker核心技术1.10节——Docker网络模型设计
14. 第二章——Kubernetes概述
15. 第二章Controller Manager原理剖析--2.1节Controller Manager综述
16. 第二章Controller Manager原理2.2节--client-go剖析
17. 第二章Controller Manager原理2.3节--Reflector分析
18. 第二章Controller Manager原理2.4节--Informer机制剖析
19. 第二章Controller Manager原理2.5节--DeltaFIFO剖析
20. 第二章Controller Manager原理2.6节--Informer controller
21. 第二章Controller Manager原理2.7节--Indexer剖析
22. 第二章Controller Manager原理2.8节--Resync机制
23. 第三章List-Watch机制3.1节-- List-Watch机制剖析
24. 第四章Operator原理4.1节--定制资源（Custom Resource）
25. 第四章Operator原理4.2节--CRD
26. 第四章Operator原理4.3节--Operator模式
27. 第四章Operator原理4.4节--Operator深入实践
28. 第五章容器运行时5.1节--容器运行时总述
29. 第五章容器运行时5.2节--容器运行时接口规范CRI
30. 第五章容器运行时5.3.1--runC简介与使用
31. 第五章容器运行时5.3.2--runC原理解读
32. 第五章容器运行时5.4--容器运行时之Firecracker
33. 第五章容器运行时5.5--容器运行时之Kata Container
34. 第五章容器运行时5.6--容器运行时之gVisor
35. 第六章容器网络6.1--Docker网络模型
36. 第六章容器网络6.2--K8S网络模型
37. 第六章容器网络6.3--CNI及各CNI网络解决方案简述
38. 第六章容器网络6.4.1--Flannel组网方案综述
39. 第六章容器网络6.4.2--Flannel的安装与部署
40. 第六章容器网络6.4.3--Flannel网络模式
41. 第六章容器网络6.5.1--Calico网络方案综述
42. 第六章容器网络6.5.2--Calico网络架构详述
43. 第六章容器网络6.5.3--Calico安装与部署
44. 第六章容器网络6.6.1--Cilium网络方案概述
45. 第六章容器网络6.6.2--Cilium部署
46. 第六章容器网络6.7.1--阿里云Terway网络模式综述