云原生技术的前世今生
前言
之前看到过一句话，大概意思是：学技术如果只去专研技术本身，那么你学到的技术就是“冷冰冰”的，而如果在了解技术背后的背景和有趣的发展历程后再去学习，这样你学习的技术才会“有血有肉”，更加有趣。
我特别赞同也觉得很有道理，所以第一期就想写一写docker、k8s、Google、CNCF等有关云原生组织、技术的发展历程以及彼此之间的“恩怨纠葛”，希望学习云原生技术的伙伴能“知其然并知其所以然”！
说起“云原生技术”，大家可能有点懵，只闻其声，不明其意。但是云原生背后典型的几个公司或者技术产品的名称可能大家经常听到：比如容器技术的代表公司docker；容器编排技术开源产品kubernetes（因为K和S之间有8个字母简称K8S）；微服务治理框架Service Mesh；比如CoreOS；更有非常有名的Google、IBM、redhat(已经被IBM收购)、阿里云、vmware；开源技术基金会，linux基金会以及云原生基金会（CNCF）；对了，还有一个老家伙，早期开源paas平台 Cloud Foundry。
今天要讲的主角有Google、docker、K8S；配角是CoreOS。（如有雷同，纯属巧合）
Docker“横空出世”
-
2010年几个大胡子年轻人在旧金山成立了一家叫做 PaaS
平台的公司，起名为dotCloud，虽然dotCloud期间获得过一些融资，但随着大厂商（微软、谷歌、亚马逊等）杀入PaaS平台，dotCloud举步维艰。 -
2013年的IT技术，AWS和openstack如日中天，当时是IAAS的天下，云里雾里的云计算最终都落地成了虚拟机以及公有云的资源账单！
-
2013年开源的paas项目Cloud
Foundry却属于云计算中的一股清流，在经历了艰难的paas概念普及阶段后，吸引了大批国内外厂商参与paas开源平台的建设。而2013年之前“Docker”这个词还只是dotCloud这个公司内部的一个容器项目的名称，dotCloud这个公司的创业者们也是Paas热潮中的一份子，但是dotCloud微不足道，小的可怜，他主打的产品和Cloud Foundry社区脱节，长期无人问津，眼看着就要被PAAS潮流无情的抛弃！ -
2013年dotCloud公司决定开源自己的容器项目“Docker”，显然这在当时没人Care，因为“容器”不是新鲜玩意，大家都知道他是基于linux的内核技术（namespace和cgroupe）实现，这和Cloud Foundry底层技术大部分都一样。但是恰恰是那一小部分的不一样（docker的镜像打包技术）造就了Docker的雄起。
-
2013年，Docker项目开源后短短几个月内迅速崛起，红遍大江南北，以秋风扫落叶之势迅速干掉其他paas社区，他们甚至都没资格成为Docker的竞争对手就已经出局，Docker雄心勃勃大有统一容器江湖之势。
-
Docker崛起的时候CoreOS也是其中的一员，在容器生态圈中CoreOS的标签就是：专为容器设计的操作系统。作为互补，CoreOS+Docker曾经也是容器部署的明星套餐。CoreOS为Docker的推广和源码社区都做出了巨大的贡献。
-
2014年随着Docker通过开发或者收购，逐步完善容器云平台的各个组件，准备打造Docker自己的生态圈以后，CoreOS发现docker想抛弃自己，docker的一系列布局与自己有直接竞争关系，因此CoreOS也愤怒的发布了另一个开源容器引擎Rocket简称rkt作为两家的分手宣言，至此两家分道扬镳！
“江湖大佬”出山
Google公司秘而不宣的使用容器已经有十几年了，本想关键时候做杀手锏，没想到docker居然搞出了docker容器还开源了，且发展势头极其迅猛。Google坐不住了，担心自己的江湖地位受到挑战。于是财大气粗的Google就大力扶持docker的“反对派”阵营-CoreOS，kubernetes一经推出就原生支持rkt容器引擎，并且在2015年4月Google还给CoreOS投资了1200万美刀，而CoreOS也发布了Tectonic，成为首个支持企业版本kubernetes的公司。从此容器生态江湖分为两大阵营Google和Docker。
“容器编排”战争打响
2014年，当Google发现CoreOS在容器生态领域实在不是Docker的竞争对手之后，决定换道超车，于当年宣布推出kubernetes容器集群编排工具，并在2014年6月7日将初始版本代码提交到Github上完全开源，当年7 月 10 日微软、RedHat、IBM、Docker 加入Kubernetes 开源社区。
2014年的Docker公司雄心勃勃，于2014年底在DockerCon上发布了自己研发的“Docker原生”容器集群管理项目DockerSwarm，并想与kubernetes一较高下。Mesosphere公司的Mesos + Marathon（马拉松）的项目更是早期容器编排解决方案的领头羊，像是有3亿用户的Twitter以及苹果语音助手Siri就是使用mesos作为后端集群管理工具。
但由于kubernetes基于Google内部使用的容器集群管理系统Borg+Omega，在谷歌已经平稳运行了15年，Google将他们自己超大范围的技术经验带到了容器编排中，该填的坑早已经被谷歌的技术大神们填了，因此推出后不到三年横扫docker swarm和mesos marathon容器编排工具。
2017年10月17日，随着docker宣布支持kubernetes开始，其实容器编排的战争就已经结束了，整个行业已经聚焦到K8S家门前！截止2017年6月，据CNCF统计：K8S占据着77%的市场份额；docker swarm则只有21%，远远落后；第三名Mesos则是13%。
聊一下CNCF（云原生基金会）
2015年7月，由Google牵头并联合linux基金会以及一大票牛掰的技术公司（IBM、microsoft、redhat等等）成立了CNCF（Cloud Native Computing Foundation），紧接着就把kubernetes1.0版本的源代码捐献给CNCF。
这给大家传递的信息就是K8S是大家的，因此K8S一出世就让大家趋之若鹜，而借着CNCF，谷歌纠集了除了docker以外容器领域的几乎全部力量，此时docker如果不加入CNCF就会被CNCF抛弃掉。
后来CNCF就提出，如果容器要快速发展就必须要标准化，不能受控于一家公司，由谁来制作容器的一系列标准化？为了给docker机会，就让docker去制定标准化（OCI），毕竟在容器领域Docker的技术还是领先的，因此docker的容器运行时（runtime）从一开始的LXC进化到libcontainer，再到最后的runC，完全符合OCI标准！
结束语
本期就先唠到这儿，接下来我将从linux的namespace、Cgroup、chroot开始，逐渐完成对容器（docker）及容器编排技术（K8S）的梳理。这其实既是帮助自己做知识体系整理，也是跟大家交流探讨的共同进步。
特别希望大家在了解云原生背后的这些故事后，能够和我一起继续深入学习探索云原生相关的技术，并持续关注云原生类解决方案的落地实践。