Docker+k8s容器云建设中常见难点分析.docx

《Docker+k8s容器云建设中常见难点分析.docx》由会员分享，可在线阅读，更多相关《Docker+k8s容器云建设中常见难点分析.docx（11页珍藏版）》请在三一办公上搜索。

1、随着云计算、DeVOPS和微服务应用架构的发展，容器云成为IT的主要基础设施平台之一。以DOCker为代表的容器技术，是目前有效的应用交付模式之一;以Kubernetes为代表的容器编排技术，是目前流行的应用部署方案。云平台的基础设施、DeVc)PS的工程体系和微服务应用架构是IT技术转型的底座。而容器云又是这个底座下的一块基石。下面几个问题是在DOCker+K8S容器云建设过程中，最常被问起和需要解决的难点问题。1、企业是应该选择原生的DOCker还是定制化的DOCker,比如胖容器/富容器？【问题描述】Docker是当前企业在进行容器化时首选的容器技术，但是原生的DOCker在实际使用的过

2、程中，特别是在传统虚机运维到容器化运维的过渡中，会碰到以下类似问题：1、如何SSh登录到容器，像登录虚机那样，可以通过SSh进行管理2、对于普通用户来说，如何从容器中拷贝文件到外部3、虚机中一般会配置定时任务，在容器中如何实现4、虚机中一般会安装各种agent,容器中怎么去安装若企业直接采用原生的Docker,那么以上问题是比较棘手的。因此企业在容器技术选型上，是否应该为了最大程度兼容虚机运维模式，对DoCker进行定制化改造，满足实际需求呢？是使用原生还是定制就要看企业实力了。一一般的企业不会去动原生的东西，不愿意将人力花在这个方面。很多企业是通过应用的改造来适配容器化的方案，包括运维上的问

3、题。4个问题：1dockerexec可以进入容器，如果是k8s或者ocp,还有有相应的叩i2、方便拷贝的方式第一个容器中应用产生的文件目录挂载到本地；第二个使用相应的命令如dockercp；也许你说的不仅限一些简单场景，其实都是有方法的，不仅以上两种3、容器中也是可以使用Crontab定时任务操作的4、agent的功能要先说清楚，如果上k8s或者OCp,一个POd可以完成你要说的内容。如果仅仅是用docker,根据功能需要应该也是有方法的。1dockerexec可以满足要求2、最直接就是挂在本地磁盘存储到容器上3、可以考虑一下，定时调度起一个DOCker执行任务4、主要是这些Agent是用来干

4、什么的？DOCker实例本来就是作为一种一次性的，不可变的运行实例，传统虚拟机的那个操作Agent,不符合容器的设计理定制化最大的问题在于，目前技术升级比较快，一旦定制，就锁定在几个版本了，后续升级维护工作量会很大。2、容器云平台选型及如何制定相关的标准和规范探讨？【问题描述】在引入容器平台时，需先了解当前主流的容器平台技术和成熟产品，然后制定相关的标准和规范。具体如下：1、想了解当前主流容器平台如何选型？2、除了资金成本，容器平台后期的使用和运维需要如何考虑，目前公司自己对容器平台的开发能力不在，运维人员需要具体具备哪些能力，运维与开发如何协作，投入运维人员的规模如何估算？3、容器平台早期实

5、施的过程中需要做哪些规划，避免哪些坑？1现在的容器平台，基本都是基于KUberneteS做的产品化，最基本的功能上没有太大的差别，主要是看一些附加的能力，如云管工具，对IaaS的支持还有安全，对开发人员的友好性这些方面。选型是还要考虑厂商的支持能力，还有就是厂商在开源社区的影响力等。具体的功能性能对比没有做过，每个厂商都会提供，综合对比一下。2、不考虑自己开发和增量开发，后期的运维主要就是容器平台的日常运维（监控，告警处理和问题定位等），还有容器平台属于更新比较快的产品，平台升级和补丁也会比普通应用多。运维人员对LinUX的基础，自动化脚本能力要求比较高。3、这边真没有什么规则，如果说有，就是

6、尽量各层解耦，选择主流的技术路线。选型还要看企业实际情况、实际需求而来，既然容器的引擎是docker,集群编排靠k8s,其实不同服务商大家优缺点可能不太一样。但核心就是容器及k8s,其他的外围生态、服务质量，产品公司服务的可持续性，服务商自身技术等都决定最后的选择。建议可以多找几家了解一下他们产品，最好能够逐一进行PoC需要关注的点：第一就是规划，你的容器是直接部署在baremetal上还是虚拟机上，因为虚拟化软件本身就有10%-20%对于硬件的消耗，因为容器本身消耗理论值在5%以内。第二就是你对于容器网络的选择，网络将是你在使用容器时候的一个很大的一个坑。比如Vxlan等技术由于对于数据包的

7、反复封装会导致网络性能下降，kube-proxy默认使用的iptables在条目过多的情况下性能也是衰减的，当然要结合你的部署架构。第三就是你的存储，是通过传统FC-SAN,还是通过NFS、还是对象存储等等方式，如果是网络存储这将影响你的数据读取速度。第四就是你的微服务的设计和拆分。第五就是你的CI/CD的设计。第五就看你们在建设的时候的需求了，如果你需要对象存储，你可能还需要选择ceph,如果你选择ABteSt、蓝绿部署、或是灰度发布那么就考验发布方案和编排能力了。会不会写dockerfile、会不会写ClePIoyment.yaml,jenkinsfile,这些可能需要和开发团队、IT领导

8、，服务商一起去探讨，如果需要引入代码审核，安全扫描等。事前的规划很重要：关键是上容器有没有最好相应的准备,业务类型是什么，稳态还是敏态，是否频繁变化；有没有做好做的技术储备和技术积累，不光是人;有没有做好团队重塑的准备。产品能力不是唯一的维度：容器云的上线，跟微服务有千丝万缕的联系，不是简单产品的堆砌，更是需要大量服务的结合。最重要的是要结合自身的实际情况，谨慎一点没大错！3、KUbeneteS在金融多安全域的环境中，架构规划问题？【问题描述】金融行业网络架构中存在多安全域的设计，kubenetes在多安全域网络隔离的情况下，每个安全域都部署一套k8s集群吗？生产环境k8s集群中calico有

9、哪些网络控制策略最佳实践？理论上来说各个安全域的网络时隔离的，如果部署一套k8s集群，所有的node节点和master节点是联通的，node直接默认也是联通的。可以每个安全域部署一套k8s集群，使用同一的容器管理平台，这是k8s多集群管理。CaIiCO是k8s其中一个网络插件，其他还有flannel、OVS等不同的网络插件,生产使用哪一种网络插件需根据自身业务需求选择。其实不需要这么复杂，比如分了互联网区、中间业务区、核心业务区，k8s集群有6个node节点，可以两个放互联网、两个放中间业务，两个放核心业务,比如master节点都在OA区，只要将master跟着6个node网络上能通即可，不需

10、要node间都能互相访问，一个集群也是可以的。calico是可以解决集群内外访问的问题，但是随着需要访问集群的外部节点的增加，那运维成本就很高了。可以使用ingress类似的解决方案。4、容器云平台建设难点之网络如何选择？如果选SDN网络，那么SDN网络实现方案又应该如何选择？【问题描述】容器网络如何选择？容器云平台的网络一直是一个技术难题，是采用SDN网络还是桥接到Underlay网络；如果使用SDN网络，那么多的SDN网络实现方案，如何选择？优先考虑公司整个网络扁平化，互联互通，这样对应用改造成本要小很多，即基于公司原来的网络打通来进行。如果容器的应用是一个相对独立的服务，可以考虑Over

11、layo规模不大的情况下一些开源网络组件可以考虑采用。calico、bgp、ingress、nginx等都是可以的1、calico将集群内与集群外网络打通，但是随着集群外访问集群内的节点越来越多，运维难度会加大2、bgp需配置内部路由协议，性能上有损耗3、ingress、nginx道理类似，将需要被外部访问的应用使用这两个组件外部负载进到集群内部4、hostnetwork方式5、nodeport方式如何选择要根据自身IT架构及监管要求定了关于SDN还是UndeHay,如果你是自建的，一定不会选用SDN,成本啊，兄弟们！Cisco去年要给我们搭建个ACI,一个交换机就是1万多，如果是银行钱多没有

12、关系，中小企业资金紧张加上疫情，哪会选择。VMware的NST-G我们也用过，有bug,这个PKS每个月都会有一次“月经”，每次网络存储全堵死，IO基本龟速，厂商派人解决了大半年，连交换机都换了都没有解决，结果赔了3台服务器，帮我们全换成普通的VCentoSDN听上去美好，现实很骨感，当然如果你有钱并愿意试错，又追求新技术，当然也是没问题的。比如阿里云、腾讯云这些公有云，基本必然是SDN,人家有钱有人，来填坑。所以，一般公司Underlay就可以了，加上Kubernetes自己的calico,fannel,或cattle,一般都没问题，就是网络上没有硬隔离，没有客户化的东东，但我们可以用公有云

13、的啊，自己去建，多费钱。1 .既然是说容器云平台建设，肯定已经有了网络基础设施，那不考虑数据中心级别的SDN方案。只考虑在已有的网络建设成果上建设。2 .不用迷信商业方案，无论是开源还是商业方案，大家都得遵守k8s的Cni接口。不建议在容器网络方案中寄托太多的功能，如网络限速、安群策略等等。3 .考虑目前主机层面大都可以保障二层是通的。最简单方案方案可以选flannelo目前flannel发展到现在，己经支持vxlan模式下启用DR网络了，通俗讲，就是同一子网下，走hostgw,宿主机充当软路由，性能接近裸网，垮子网的情况走VXlan。即兼顾了性能，又考虑了可扩展性。另外flannel目前也重

14、点优化了大规模容器云的路由表或arp占用过多问题，做到了：每扩展一个主机只增加一个路由项、一个fdb项、一个arp项。4.如果考虑容器网络隔离和安全策略的话（其实没必要，网络隔离，可以从项目级别来设置调度策略做到物理隔离），可以考虑Canal网络方案，他是CaIiCo和flannel的结合体。关于容器网络的建设思路：容器网络发展到现在，已经是双雄会的格局。双雄会其实指的就是Docker的CNM和GOogIe、CoreOSKUbereneteS主导的CNI。首先明确一点，CNM和CNl并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用FIannel也好、用Cali

15、CO也好，他们并不关心，CNM和CNl关心的是网络管理的问题。网络需求调研发现，业务部门主要关注以下几点：1、容器网络与物理网络打通；2、速度越快越好；3、改动越少越好；4、尽可能少的风险点。容器的网络方案大体可分为协议栈层级、穿越形态、隔离方式这三种形式协议栈层级：二层比较好理解,在以前传统的机房或虚拟化场景中比较常见，就是基于桥接的ARP+MAC学习，它最大的缺陷是广播。因为二层的广播，会限制节点的量级；三层（纯路由转发），协议栈三层一般基于BGP,自主学习整个机房的路由状态。它最大的优点是它的IP穿透性，也就是说只要是基于这个IP的网络，那此网络就可以去穿越。显而易见，它的规模是非常有优

16、势，且具有良好的量级扩展性。但在实际部署过程中，因为企业的网络大多受控。比如，有的企业网络的BGP是基于安全考虑不给开发者用或者说企业网络本身不是BGP,那这种情况下你就受限了；协议栈二层加三层，它的优点是能够解决纯二层的规模性扩展问题，又能解决纯三层的各种限制问题，特别是在云化VPC场景下，可以利用VPC的跨节点三层转发能力。穿越形态：这个与实际部署环境十分相关。穿越形态分为两种：Underlay、OverlayoUnderlay：在一个较好的可控的网络场景下，我们一般利用Underlayo可以这样通俗的理解，无论下面是裸机还是虚拟机，只要整个网络可控，容器的网络便可直接穿过去，这就是Und

17、erlayoOverlay：Overlay在云化场景比较常见。OVerlay下面是受控的VPC网络，当出现不属于VPC管辖范围中的IP或者MAC,VPC将不允许此IP/MAC穿越。出现这种情况时，我们可利用OVerIay方式来做。Overlay网络使物理网络虚拟化、资源池化，是实现云网融合的关键。把Overlay网络和SDN技术结合使用，把SDN控制器作为OVerIay网络控制平面的控制器，这种方式更容易使网络与计算组件整合，是网络向云平台服务转变的理想选择。隔离方式：隔离方式通常分为VLAN和VXLAN两种。VLAN：VLAN机房中使用偏多，但实际上存在一个问题。就是它总的租户数量受限。众所

18、周知，VLAN具有数量限制。VXLAN：VXLAN是现今较为主流的一种隔离方式。因为它的规模性较好较大，且它基于IP穿越方式较好。容器网络选择我个人觉得不是重点，其实不管哪种网络，都应该对终端用户透明，所以不应该纠结于网络模型。需要考虑的重点可能是安全性，稳定性，易用性等，我们使用CaliCo网络，发现也是很多问题，在考虑替换。开源产品总是需要很多额外的工作，测试验证，逐步优化，不实际使用，很难说哪种更合适，在使用过程中可能会逐步清晰自己的需求。容器安全，容器网络安全可能是重点，特别上生产业务，服务数量达到一定量后，会有很多想不到的问题，当然，不实际做过，也很难选择，所以可以尝试先用起来，经常

19、使用会逐步清晰明白自己要什么。5、容器东西向网络安全是怎么考虑的？东西向流量的控制，是服务网格的控制范畴，istio可以实现，但目前istio不完善，所有很不好用。建议使用kongtraefik为代表的apigateway,其中Kong基于nginx,可以在容器中部署到每个Pod中去，控制pod和POd之间的流量。东西向流量指同一宿主机上与其他容器相互访问，同一主机上pod默认是互通的。我认为可以从上层逻辑控制上减少安全隐患，即根据业务划分不同的逻辑集群，尽量让有血缘关系的业务放在同一逻辑集群。6、容器云平台的整体规划：包括计算资源、存储、网络的选型？【问题描述】我想了解一下容器云平台的一个整

20、体规划，包括计算资源、存储、网络的选型，我们打算将微服务迁移到容器云平台。个人意见：1、首先确定目标，建设容器云平台的目标，规划哪些业务上容器，大概的资源需求是多少，集群规模多大等等；2、容器平台选型，基本是k8s,这个应该没问题；3、计算资源：基本是采用裸机还是虚拟机作为计算资源，两种方案各有优劣,如果已有IaaS平台，可以采用虚拟机，如果没有IaaS平台，也可以直接使用裸机；4、网络资源：需要考虑业务上容器是否需要对业务进行改造，另外就是将来业务向容器平台迁移过程，比如一个微服务业务，迁移至容器平台时，先迁移部分微服务，还是整体迁移？迁移部分微服务后，已上容器微服务和未上微服务网络网络通信

21、等等；5、存储资源：考虑业务上容器是有状态业务还是无状态业务，已经业务对性能的影响，选择合适的存储资源；综上，还需要考虑运维团队的运维能力、以及和开发对接等等。7、使用容器云平台，如何提升系统开发和测试的能力？【问题描述】目前公司选择springcloud微服务体系，在开发测试过程中，如何使用容器云平台提升系统开发测试能力？能够提升哪些能力？有没有较好的实践路径和应注意的关键点？比如是否在开发测试云上先搭建通用的服务（注册中心等，是否开发测试云通用一套服务？）,maven私仓管理、基础镜像管理等等？对于测试，可以使用容器平台的持续交付的能力，缩短测试版本周期和环境准备的时间；使用平台灵活的路由

22、功能，进行多版本兼容性测试。较好的实践路径和应注意的关键点：1 .通用的服务建议统一建设成平台服务，但是不建议测试开发使用同一个运行实例。2 .建立私有的镜像仓库，制定基础镜像白名单。3 .做好镜像的版本管理，利用容器和git的tag,做到实例和镜像，镜像和源码的对应。8、银行重要的业务场景如何用k8s做滚动更新？这个问题细说的话就多了，需要看业务场景。强一致性交易类业务，像消费之类的需要应用本身来保证，事务失败要能回滚。那版本升级回滚就要有优雅停机的动作，一些渠道类交易，只是做中间转接，一般是可以直接做升级回滚的。升级回滚的操作，主要是通过替换应用依赖的镜像版本。k8s的升级回滚是利用新版本

23、镜像或者旧版本镜像拉起一个新pod,下线一个旧pod依次完成此操作的，保证业务正常运行。平台方面：结合K8s的流量分发，实现金丝雀发布机制，通过精细的流量控制，来实现业务的滚动更新。应用方面：应用需要有合理的设计，在规划时就需要有相关的设计,对应用有合理的低耦合的切分，尽量减少发布应用的涉及面,这其中最重要的如何实现问题的回退，特别是影响到账务数据的，采用数据染色或是零时表的方式，尽量做到应用可回溯。这个问题可以结合着蚂蚁作大规模发布的时候所关注的变更管理来回答。原生deployment做灰度或者金丝雀发布时，默认情况下在Pod变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程

24、管控。因此，我们在PaaS产品层面做了定制，在Kubernetes层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。在实际的生产环境中，围绕容器大规模变更会配合业务监控及更多维度的观察，确保每一步都是符合预期、验证通过的。这样在应用实例层面的精细化管控,为运维提供了能够及时刹车回滚的机会，是线上应用发布的一个重要的保险绳。简单来说，在蚂蚁内部所有的变更要满足”可灰度、可监控、可应急J当基础设施全面转向云原生，就开始基于Kubernetes作了非常多扩展和补充。对于金融业务场景，从实际产品层，

25、需要做到：1 .感知底层拓扑2 .分组/beta/分批发布3 .优雅摘流附参考资料：容器的崛起对于K8s启用docker,作为普通开发者的体感是，k8s不就是docker的集群操作吗？k8s弃用docker就像鱼反对水一样不可思议，那么这两个技术究竟是什么关系，Kubernetes是如何一步步与Docker解耦的，请看下文。模块导学：从微服务到云原生什么是不可变基础设施向应用代码隐藏分布式架构复杂度、让分布式架构得以成为一种能够普遍推广的普适架构风格的必要前提。云原生的定义官方定义太抽象了，我就不复制粘贴了，我选择从我们都比较熟悉的，至少是能看得见、摸得着的容器化技术开始讲起。虚拟化的目标与类

26、型容器是云计算、微服务等诸多软件业界核心技术的共同基石。容器的首要目标是让软件分发部署的过程，从传统的发布安装包、靠人工部署，转变为直接发布已经部署好的、包含整套运行环境的虚拟化镜像。操作系统层虚拟化操作系统层虚拟化也就是容器化，仅仅是虚拟化的一个子集，它只能提供操作系统内核以上的部分ABI兼容性与完整的环境兼容性。引言作I整个模块的开篇，我们这节课的学习目的是要明确软件运行的“兼容性”指的是什么，以及要能理解我们经常能听到的“虚拟化概念指的是什么。只有理清了这些概念、统一了语境，在后续的课程学习中，我们关于容器、编排、云原生等的讨论，才不会产生太多的歧义。DoCker与K8s的相爱相杀云原生

27、进化历程接下来的两节课，我会以容器化技术的发展为线索，带你从隔离与封装两个角度，去学习和了解容器技术。今天，我们就先来学习下Linux系统中隔离技术前提准备，以此为下节课理解“以容器封装应用的思想打好前置基础。封装系统：LXC当文件系统、访问、资源都可以被隔离后，容器就已经具备它降生所需要的全部前置支撑条件了，并且Linux的开发者们也已经明确地看到了这一点。2008年LinuxKernel2.6.24内核在刚刚开始提供Cgroups的同一时间，就马上发布了名为LinUX容器(LinuXContainers,LXC)的系统级虚拟化功能。如此一来，LXC就带着令人瞩目的光环登场，它的出现促使“容

28、器”从一个阳春白雪的、只流传于开发人员口中的技术词汇,逐渐向整个软件业的公共概念、共同语言发展，就如同今天的“服务器”“客户端”和“互联网”一样。1.XC眼中的容器的定义与OPenVZ和Linux-VServer并没有什么差别，它们都是一种封装系统的轻量级虚拟机，而Docker眼中的容器的定义则是一种封装应用的技术手段。这两种封装理念在技术层面并没有什么本质区别，但在应用效果上差异可就相当大了。封装应用：Docker在2013年宣布开源的Docker,毫无疑问是容器发展历史上里程碑式的发明，然而Docker的成功似乎没有太多技术驱动的成分。至少对于开源早期的Docker而言，确实没有什么能构成

29、壁垒的技术。事实上，它的容器化能力直接来源于LXC,它的镜像分层组合的文件系统直接来源于AUFS,在Docker开源后不久，就有人仅用了一百多行的Shell脚本，便实现了Docker的核心功能（名为BoCker,提供了dockerbulid/pull/images/ps/run/exec/logs/commit/rm/rmi等功能）。为什么要用Docker而不是LXC?（WhywouldIuseDockeroverplainLXC?）跨机器的绿色部署以应用为中心的封装自动构建：Docker提供了开发人员从在容器中构建产品的全部支持，开发人员无需关注目标机器的具体配置，就可以使用任意的构建工具链

30、，在容器中自动构建出最终产品。多版本支持：Docker支持像Git一样管理容器的连续版本，进行检查版本间差异、提交或者回滚等操作。从历史记录中，你可以查看到该容器是如何一步一步构建成的，并且只增量上传或下载新版本中变更的部分。组件重用：Docker允许将任何现有容器作为基础镜像来使用，以此构建出更加专业的镜像。共享：DOCker拥有公共的镜像仓库，成千上万的Docker用户在上面上传了自己的镜像，同时也使用他人上传的镜像。工具生态：Docker开放了一套可自动化和自行扩展的接口，在此之上用户可以实现很多工具来扩展其功能，比如容器编排、管理界面、持续集成，等等。其实，促使Docker一问世就惊艳

31、世间的，并不是什么黑科技式的秘密武器,而是它符合历史潮流的创意与设计理念，还有充分开放的生态运营。由此可见，在正确的时候，正确的人手上有一个优秀的点子，确实有机会引爆一个时代。=和ChatgPt套壳一样，巨大的需求，最低的门槛，资源丰富的公共仓库=2014年,Docker开源了自己用Golang开发的IibCOntainer,这是一个越过LXC直接操作namespaces和Cgroups的核心模块，有了IibCOntainer以后，Docker就能直接与系统内核打交道，不必依赖LXC来提供容器化隔离能力了。（runC的前身，后期会讲到这个）（docker开始构建自己的技术壁垒）到了2015年，

32、在Docker的主导和倡议下，多家公司联合制定了“开放容器交互标准”（OpenContainerlnitiative,OCl）,这是一个关于容器格式和运行时的规范文件，其中包含了运行时标准（runtime-spec）、容器镜像标准（image-spec）和镜像分发标准（distribution-spec,分发标准还未正式发布）。运行时标准定义了应该如何运行一个容器、如何管理容器的状态和生命周期、如何使用操作系统的底层特性（namespaces、CgrOUp、pivot_root等）；容器镜像标准规定了容器镜像的格式、配置、元数据的格式，你可以理解为对镜像的静态描述；镜像分发标准则规定了镜像推送

33、和拉取的网络交互过程。由此，为了符合OCl标准，Docker推动自身的架构继续向前演进。首先，它是将Iibeontainer独立出来，封装重构成runC项目，并捐献给了Linux基金会管理。runC是OClRuntime的首个参考实现，它提出了“让标准容器无所不在(MakeStandardContainersAvailableEverywhere)的口号。而为了能够兼容所有符合标准的OClRUntime实现，Docker进一步重构了DockerDaemon子系统，把其中与运行时交互的部分抽象为了Containerd项目。这是一个负责管理容器执行、分发、监控、网络、构建、日志等功能的核心模块，其

34、内部会为每个容器运行时创建一个Containerd-Shim适配进程，默认与runC搭配工作，但也可以切换到其他OClRUntime实现上(然而实际并没做至J,最后Containerd仍是紧密绑定于runC)o后来到了2016年，Docker把Containerd捐献给了CNCF管理。可以说，runC与Containerd两个项目的捐赠托管，既带有Docker对开源信念的追求，也带有Docker在众多云计算大厂夹击下自救的无奈，这两个项目也将会成为未来DOCker消亡和存续的伏笔(到这节课的末尾你就能理解这句矛盾的话了)。Docker2封装集群：KUbemeteS如果说以Docker为代表的容

35、器引擎，是把软件的发布流程从分发二进制安装包，转变为了直接分发虚拟化后的整个运行环境，让应用得以实现跨机器的绿色部署；那以Kubernetes为代表的容器编排框架，就是把大型软件系统运行所依赖的集群环境也进行了虚拟化，让集群得以实现跨数据中心的绿色部署，并能够根据实际情况自动扩缩。尽管早在2013年，PivotaK持有着SpringFramework和CloudFoundry的公司)就提出了“云原生”的概念，但是要实现服务化、具备韧性(Resilience)、弹性(Elasticity)、可观测性(ObSerVabiIity)的软件系统依旧十分困难，在当时基本只能依靠架构师和程序员高超的个人能

36、力，云计算本身还帮不上什么忙。而在云的时代，不能充分利用云的强大能力，这让云计算厂商无比遗憾，也无比焦虑。所以可以说，直到Kubemetes横空出世，大家才终于等到了破局的希望，认准了这就是云原生时代的操作系统,是让复杂软件在云计算下获得韧性、弹性、可观测性的最佳路径，也是为厂商们推动云计算时代加速到来的关键引擎之一。Docker靠的是优秀的理念，它是以一个“好点子”引爆了一个时代。我相信就算没有Docker,也会有Cocker或者Eocker的出现，但由成立仅三年的DotCIoud公司(三年后又倒闭)做成了这样的产品，确实有一定的偶然性。而Kubernetes的成功，不仅有Google深厚的

37、技术功底作支撑、有领先时代的设计理念，更加关键的是Kubernetes的出现，符合所有云计算大厂的切身利益，有着业界巨头不遗余力地广泛支持，所以它的成功便是一种必然。KubernetesMaster3Kubernetes与Docker两者的关系十分微妙，因此我们把握住两者关系的变化过程，是理解Kubernetes架构演变与CRkOCI规范的良好线索。Kubernetes是如何一步步与Docker解耦的？在一般使用者的体感中，k8s,就是作为管理和编排众多docker容器的工具，后来听说k8s要弃用docker,感觉就像鱼反对水一样不可思议，但是k8s随着版本更迭慢慢解耦docker,可以看做是

38、云原生发展的历史，对理解现在k8s架构有重大意义。于我而言，在这里多费笔墨的原因是，这个过程和企业级架构中用于替换或者升级某一个应用或者组件也如出一辙，在替换过程中的抽象和重构，亦是大型应用的常态。在Kubernetes开源的早期，它是完全依赖且绑定Docker的，并没有过多地考虑日后有使用其他容器引擎的可能性。直到Kubernetes1.5之前,Kubernetes管理容器的方式都是通过内部的DockerManager,向DockerEngine以HTTP方式发送指令，通过Docker来操作镜像的增删改查的，如上图最右边线路的箭头所示（图中的kubelet是集群节点中的代理程序，负责与管理集

39、群的Master通信，其他节点的含义在下面介绍时都会有解释）。现在，我们可以把这个阶段的Kubernetes与容器引擎的调用关系捋直，并结合前面提到的DoCker捐献Containerd与runC后重构的调用，一起来梳理下这个完整的调用链条：KubernetesMasterkubeletDockerManagerDockerEnginecontainerdrunC然后到了2016年，Kubemetes1.5版本开始引入“容器运行时接口”（ContainerRuntimeInterface,CRI）,这是一个定义容器运行时应该如何接入到kubelet的规范标准，从此Kubernetes内部的Do

40、ckerManager,就被更为通用的KubeGenericRuntimeManager所替代了（实际上在1.6.6之前都仍然可以看到DockerManager）,kubelet与KubeGenericRuntimeManager之间通过gRPC协议通信。不过，由于CRI是在Docker之后才发布的规范，Docker是肯定不支持CRI的，所以Kubernetes又提供了DockerShim服务作为Docker与CRI的适配层，由它与DoCkerEngine以HTTP形式通信，从而实现了原来DockerManager的全部功能。此时，Docker对Kubernetes来说就只是一项默认依赖，而非

41、之前的不可或缺了，现在它们的调用链为：KubernetesMasterkubeletKubeGenericRuntimeManagerDockerShimDockerEnginecontainerdrunC接着再到2017年，由Google.RedHatInteKSUSEIBM联合发起的CRl-O（ContainerRuntimeInterfaceOrchestrator）项目发布了首个正式版本。一方面，我们从名字上就可以看出来，它肯定是完全遵循CRl规范来实现的；另一方面，它可以支持所有符合Oel运行时标准的容器引擎，默认仍然是与runC搭配工作的，如果要换成ClearCOntainers、

42、KataCOntainerS等其他OCI运行时，也完全没有问题。（前面提过的运行时交互的部分抽象为了containerd项目，负责管理容器执行、分发、监控、网络、构建、日志等功能的核心模块，其内部会为每个容器运行时创建一个containerd-shim适配进程）不过到这里，开源版的Kubernetes虽然完全支持用户去自由选择（根据用户宿主机的环境选择）是使用CRI-Ocri-containerd,还是DockerShim来作为CRl实现，但在RedHat自己扩展定制的Kubemetes企业版，即OpenShift4中，调用链已经没有了DockerEngine的身影：KubernetesMas

43、terkubeletKubeGenericRuntimeManagerCRI-0runC当然，因为此时Docker在容器引擎中的市场份额仍然占有绝对优势，对于普通用户来说，如果没有明确的收益，也并没有什么动力要把Docker换成别的引擎。所以CRI-O即使摆出了直接挖掉Docker根基的凶悍姿势，实际上也并没有给Docker带来太多即时可见的影响。不过，我们能够想像此时DoCker心中肯定充斥了难以言喻的危机感。时间继续来到了2018年，由Docker捐献给CNCF的containerd,在CNCF的精心孵化下发布了1.1版，1.1版与1.0版的最大区别是此时它已经完美地支持了CRI标准，这意

44、味着原本用作CRl适配器的cri-containerd从此不再被需要。此时，我们再观察Kubernetes到容器运行时的调用链，就会发现调用步骤会比通过DockerShimDockerEngine与containerd交互的步骤要减少两步，这又意味着用户只要愿意抛弃掉DOCker情怀的话，在容器编排上就可以至少省略一次HTTP调用，获得性能上的收益。而且根据Kubernetes官方给出的测试数据，这些免费的收益还相当地可观。如此，Kubernetes从1.10版本宣布开始支持containerd1.1,在调用链中就已经能够完全抹去DockerEngine的存在了：KubernetesMaste

45、rkubeletKubeGenericRuntimeManagercontainerdrunC而到了今天，要使用哪一种容器运行时，就取决于你安装Kubernetes时宿主机上的容器运行时环境，但对于云计算厂商来说，比如国内的阿里云ACK、腾讯云TKE等直接提供的Kubernetes容器环境，采用的容器运行时普遍都已经是containerd了，毕竟运行性能对它们来说就是核心生产力和竞争力。画时间线图描述，结合调用图就清楚了。小结学完这节课，我们可以试着来做一个判断：在未来，随着Kubernetes的持续发展壮大，DockerEngine经历从不可或缺、默认依赖、可选择、直到淘汰，会是大概率的事件。从表面上看，这件事情是Google.RedHat等云计算大厂联手所为，可实际淘汰它的还是技术发展的潮流趋势。这就如同Docker诞生时依赖LXC到最后用Iibcontainer取代掉LXC一样。同时，我们也该看到事情的另一面：现在连LXC都还没有挂掉，反倒还发展出了更加专注于跟OPenVZ等系统级虚拟化竞争的LXD,就可以相信Docker本身也是很难彻底消亡的，已经养成习惯的CLI界面，已经形成成熟生态的镜像仓库等，都应该会长期存在，只是在容器编排领域，未来的Docker很可能只会以runC和Containerd的形式存续下去，毕竟它们最初都源于Docker的血脉。