本文主要是介绍Kubernetes：从萌芽到巨大生态系统的成长之路，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Docker在集群中工作面临着诸多问题，如下：
1.跨主机通信问题？
2.多容器跨主机部署？
3.容器发布,升级，回滚？
4.容器挂掉后，如何自动拉起服务？
5.当现有容器资源不足时，是否可以自动扩容？
6.能够实现容器的健康检查，若不健康是否能自动恢复？
7.如何将容器调度到集群特定节点？
8.将容器从一个节点驱逐，下线节点如何操作?
9.集群如何扩容?
10.集群如何监控？
11.集群日志如何收集？
...
早期容器容器编排工具：docker inc swarm，Apache mesos marathon，Google Kubernetes（简称K8S），帮助Docker逐一化解。
Docker：从概念到主流的容器化技术变革
-
Docker IT 界的福音：
Docker是一种流行的容器化技术，它的原型可以追溯到2008年，在那时，Linux容器还是一个比较新颖的概念。
2010年，dotCloud公司在旧金山成立了一家做Paas平台的公司。
直到2013年3月，dotCloud将docker正式以开源的软件等形式在pycon网站首次发布。docker开源后很受欢迎，dotCloud将公司更名为"Docker Inc"，将重心放在Docker的研发中。
2014年8月，docker宣布把paas的业务dotCloud出售给德国柏林PAAS提供商cloudControl，自此dotCloud和Docker分道扬镳啦。
-
容器编排工具kubernetes诞生
Google公司在看到Docker的流行趋势，在2014年3月Google公司开始研发容器化编排系统Kubernetes （简称k8s）。它将Google内部的大规模集群管理经验和技术优势与开发者社区分享。这一平台秉承了Google商业化编排系统"Omega"（第一代）和"Borg"（第二代）的精髓，经过了长达15年的在Google内部的实际测试，每周数十亿容器得以在其中运行。
k8s在2014年6月6日首次发布。
-
Docker lnc 推出容器编排三剑客
Swarm:
早在2014年底，Docker公司就设计了容器集群的方案组合（也称之为docker编排工具三剑客）：
Machine:
可快速创建Docker运行环境。 Swarm: 是Docker社区原生提供的容器集群管理工具。
Compose:
自定义文件格式以运行多容器应用程序的工具。
当然此时的Swarm局限性较大，比如：
(1)没有副本和负载均衡的概念，这导致服务无法高可用；
(2)当然也更不存在什么服务网络管理和跨节点数据存储这些东西； (
3)没有服务模型：集群中服务间关系和启动顺序编排也很复杂，于是就有了下面的SwarmKit的诞生；
SwarmKit:
在2016年2月，Docker公司开始了一个名叫SwarmKit的项目。而恰在Docker 1.12 RC之前的一段时间，Docker发布了Swarmkit，这是一个独立的、开源的容器编排项目。
SwarmKit不同于一开始的经典Swarm，它从一开始就重新设计了一套独立的API和模型体系，并且采用独立的客户端命令行工具"swarmctl"。
和上面的经典Swarm模型相比，它加入了如下特性：
(1)重新设计的一套独立的API和模型体系;
(2)使用了自己的CLI(swarmd命令负责管理，swarmctl命令用于控制);
(3)节点管理、服务模型更加自然，提供编排和调度服务;
(4)将过去Swarm依赖的外部集群一致性存储组件Etcd的核心部分内置化;
(5)然而此时的SwarmKit并没有提供诸如服务发现、负载均衡和路由等功能。
尽管如此，SwarmKit其实已经是我们今天广泛使用的Docker Swarm集群技术的基石。
Swarm Mode:
Swarm Mode则更进一步，它在Docker 1.12版本开始为大家所周知，一个docker swarm命令红遍大江南北，这个所谓的Swarm Mode其实就是我们今天所广泛使用的Docker Swarm集群技术。
然而Swarm Mode并不是一个全新的东西，也并不是一个全新的模式，而是站在SwarmKit的巨人肩膀上发展起来的，是Docker中的一组与集群相关功能的统称而已。
Docker将SwarmKit的核心模块内嵌于Docker的后台服务之中，通过不同的命令允许使用者同时以"本节点"和"本集群"这两种视角来操作整个集群，增加了集群的管理、节点的管理、服务的管理和编排等等一系列高级特性。
因此总结一下Swarm Mode就是：
(1)基于Swarmkit编写;
(2)支持服务模型以及服务发现、路由和负载均衡等新功能;
(3)使用Docker原生态的CLI命令;
(4)集成到了Docker engine中(强大的docker swarm命令);
-
CoreOS rkt 轻量级容器
CoreOS是在2013年创建，主要完成基础设施服务，有自己的操作系统(CoreOS)，早期也是docker拥护者。
随着docker在容器行业变得逐渐强大，docker也越来越臃肿(比如说将swarm代码封装在docker engine)。
rkt诞生于2014年11月末，rkt专门用于容器管理，并不支持集群编排功能。
在k8s和docker swarm大战时，CoreOS公司的rkt站队k8s，k8s拥抱这个项目。
-
对决巅峰：Docker Swarm与Kubernetes的容器编排之战
rkt站队k8s，在2017年底，市场占有率k8s占有大份额。
CoreOS公司(开源了RKT的母公司)被收购:
2018年1月31日由Redhat公司宣布收购CoreOS且已签署最终协议，收购价格为2.5亿美元。
2018年4月16日是发布的最新rkt容器工具，目前该项目已经停止维护，因此生产环境中不推荐大家使用该容器技术。推荐使用主流的容器工具，如Docker，Pouch，podman。
Docker公司被收购:
2019年11月左右，Mirantis收购Docker，但收购金额两家公司貌似很保密，至今未公开发布官方说明。
Mirantis表示，今后的重点是Kubernetes。他还承诺将对Swarm的支持再延长至少两年。
CNI，OCI，CRI技术词汇
-
CNI（Container Networker Interface）
CNI全称为"Container Networker Interface"。主要是用于容器跨主机互联提供基础网络服务。
k8s本身并不提供容器跨主机互联，而是声明了CNI规范，凡事遵循了CNI规范都可以被k8s集群用作网络基础组件。
目前市面上比较流行且符合CNI标准的代表有: Flannel，Calico。
推荐阅读:
https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/addons
-
OCI（Open Container Initative）
业内最早的容器运行时环境(Runtime)是LXC，起初Docker就是利用LXC做容器管理引擎，但是在创建容器用户空间时不在用LXC的模板现场安装生成容器，而是先通过一种镜像技术，把一个操作系统用户空间所要用到的所有组件事先准备编排好打包成一个文件，这个文件Docker称之为镜像文件。
但后来觉得隔离性差，后来采用libcontainer组件，不过此时Docker已被CNCF挟持了，当然容器的话语权依旧归Docker公司，这并不是说CNCF组织没有能力定制Docker的标准，只不过他们真那样做就太欺负Docker公司了。
后来Docker又转型到runC，所以说到目前为止，runC是Docker的独生子。
随着LXC，LXD，Docker，Rkt等容器运行时环境各有不同，这时候容器运行时的确是有点多了，开放容器倡议(Open Container Initiative，简称"OCI")由多家公司共同成立的项目，并由linux基金会进行管理。
OCI（全称为"Open Container Initative"）是建立围绕容器格式和运行时的开放式行业标准的明确目的的开放式的治理结构。OCI由Docker和其他容器行业的领导者于2015年6月建立，但在2015年12月18日才在GitHub上发布的"v0.1.1"。
所谓container runtime，主要负责的是容器的生命周期的管理。OCI目前包含两个规范：运行时规范(runtime-spec)和映像规范(image-spec)。
(1)OCI的runtime spec标准中对于容器的状态描述，创建，删除，查看等操作进行了定义，以及容器运行时如何运行指定文件系统上的包;
(2)OCI的image-spec标准在定义了如何创建一个OCI运行时可运行的文件系统上的包; Docker公司将容器镜像格式和runtime(也就是runc)都捐献给了Open Container Initiative组织。runc是对于OCI标准的一个参考实现，是一个可以用于创建和运行容器的CLI(command-line interface)工具。
runc直接与容器所依赖的cgroup/linux kernel等进行交互，负责为容器配置cgroup/namespace等启动容器所需的环境，创建启动容器的相关进程。
为了兼容OCI标准，docker也做了架构调整。2016年12月14日，Docker公司宣布将将容器运行时相关的程序从docker daemon剥离出来，形成了containerd。而早在同年的3月份，Docker 1.11的Docker Engine里就包含了containerd。
Containerd向docker提供运行容器的API，二者通过grpc进行交互。containerd最后会通过runc来实际运行容器。其架构如下图所示。
-
CRI（全称为"Container Runtime Interface")
kubernetes在初期版本里，就对多个容器引擎做了兼容，因此可以使用docker、rkt对容器进行管理。以docker为例，kubelet中会启动一个docker manager，通过直接调用docker的api进行容器的创建等操作。
在kubernetes中，pod是由一组进行了资源限制的，在隔离环境中的容器组成。而这个隔离环境，称之为PodSandbox。
据说是Google(对K8S源码贡献第一)和RedHat(对K8S源码贡献第二)这两家公司有意将Docker边缘化，因此大力扶持由CoreOS公司2014年开源的轻量级rkt容器工具引擎。
在Kubernetes早期版本，主要是支持docker和rkt两种容器引擎，这需要Kubernetes官方做大量的工作来兼容这两种容器，而兼容会带来很多维护性工作。
于是在OCI提出一年后，大概在2016年12月19日，即在k8s 1.5版本之后，kubernetes推出了自己的运行时接口Container Runtime Interface(下面简称"CRI")。
凡是支持CRI皆可作为K8S的底层运行时，CRI接口的推出，隔离了各个容器引擎之间的差异，而通过统一的接口与各个容器引擎之间进行互动。
与OCI不同，CRI与kubernetes的概念更加贴合，并紧密绑定。CRI不仅定义了容器的生命周期的管理，还引入了k8s中pod的概念，并定义了管理pod的生命周期。
但Docker本身并未实现CRI，因此使用临时解决方案: 其中kubelet是通过CRI接口，调用docker-shim，并进一步调用docker api实现的。但这增大了K8S官方的工作负担，于是在2020年12月宣布将来会弃用docker-shim。
如上文所述，docker独立出来了containerd。kubernetes也顺应潮流，孵化了cri-containerd项目，用以将containerd接入到cri的标准中。
为了进一步与oci进行兼容，kubernetes还孵化了cri-o，成为了架设在cri和oci之间的一座桥梁。通过这种方式，可以方便更多符合oci标准的容器运行时，接入kubernetes进行集成使用。
可以预见到，通过cri-o，kubernetes在使用的兼容性和广泛性上将会得到进一步加强。
大概在2017年左右，Docker将自身的容器运行时(即"containerd")捐给了CNCF组织(该组织维护的是Kubernetes开源产品)。同年，Docker的网络组建(libnetwork)增加了CNI的支持，同时实现基于IPVS的SERVICE负载均衡。
来自谷歌、Docker、IBM、中兴通讯和ZJU的工程师们致力于为containerd实现CRI。该项目名为cri containerd，其特性在2017年9月25日发布了完整的v1.0.0-alpha.0版本。
在2018年5月24日，Kubernetes GA版本正式集成了cri containerd架构。使用cri containerd，用户可以运行Kubernetes集群，使用containerd作为底层运行时，而无需安装Docker。
2019年8月16日，CNCF组织正式将rkt归档，结束了rkt容器的在Kubernetes的生命周期，在此之前，2018年4月16日是发布的最新rkt容器工具。
这篇关于Kubernetes：从萌芽到巨大生态系统的成长之路的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
