自从上次跟女朋友唠了唠“容器技术”之后，似懂非懂、欲拒还迎的女朋友仿佛并没有get到云原生、容器与Kubernetes之间的“瓜葛”，每天纠缠着、催促着下一轮的“科普”。于是，我又双叒叕妥协了。
那么，这一期，我们主要唠一唠Kubernetes。在这里提醒一下大家，想知道更多关于容器技术的内容，可以看一看《趣说“容器技术”，女朋友让我白话它的精彩故事》。同时，我们也会沿着上一期的脉络往下说。
好了，我们言归正传。
话说，开源之后的Docker容器技术被炒得热火朝天，俨然红得像带货界的领军人物。但是随着用它的企业越来越多，大家发现将Dcoker用于具体业务是存在困难的，尤其是编排、管理、调度等，都非常不容易。这时，人们迫切需要一个Docker管理系统，对容器进行灵活的管理。
细心的企业逐渐发现这也是商机，时间来到2013年，那是一个炎热的夏天，谷歌内部有一群非常有想法的产品经理，脑洞了一个想法，我们何不开发一个开源的容器管理系统?于是开始的谷歌内部进行游说，希望可以得到一定的支持。
按照他们的说法，在预算紧张的早年间，谷歌为了榨取服务器的没一点性能，渐渐开启尝试容器，并且构建了一个名为Borg的集群管理系统。在这套系统下，谷歌的服务器可以运行成千上万个任务，提高了计算效率。
事实上，他们的基于容器的集群管理平台，也是从Borg蜕变来的。
苦心人，天不负，三千越甲可吞吴。终于，他们的游说得到了反馈。于是，谷歌开始做基于容器的集群管理平台——Kubernetes。
2014年6月，Google正式公布并开源Kubernetes。
Emmmm，Kubernetes这个单词来自于希腊语，意思是舵手或领航员。K8S是它的缩写，用“8”字替代了“ubernete”这8个字符。
在宣布开源之后，微软、Red Hat、IBM、Docker、CoreOS、Mesosphere、Saltstack等公司闻风而来，纷纷投入K8s温暖的怀抱。
此后，VMware、HP、Intel等公司，也陆续加入。
2015年7月，Google正式加入OpenStack基金会。与此同时，Kuberentes v1.0正式发布。
目前，kubernetes的版本已经发展到V1.13。
截止目前，K8s的炼金之旅正式完成。
如今，K8s在容器领域、云原生领域初露锋芒，未来亦将潜力无限。
这就是K8s，简而言之，它就是基于容器的集群管理平台。
紧接着，我们来看一下K8s的架构，其实一个K8s系统，通常被成为一个K8s集群(Cluster)。该集群主要包括两个部分：一个Master节点(主节点)、一群Node节点(计算节点)。其中，Master节点负责管理和控制;Node节点是工作负载节点，包含具体的容器。
Master节点
Master节点包括API Server、Scheduler、Controller manager、etcd。
API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。
Scheduler负责对集群内部的资源进行调度，相当于“调度室”。
Controller manager负责管理控制器，相当于“大总管”。
Node节点
Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns(可选)，还有就是Pod。
Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。
Docker，创建容器。
Kubelet，负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等。
Kube-proxy，主要负责为Pod对象提供代理。
Fluentd，主要负责日志收集、存储与查询。
那么，K8s有什么样的优缺点?
我们知道，Kubernetes并不是市场唯一的容器管理平台，但仍然受到极大地欢迎。我们来看一下原因。
- 使用简单。利用Kubernetes，容器化的应用程序可以只编写一次，就能够在所有类型云供应商以及私有云上运行。
- 快速简捷。开发人员可以快速部署应用程序。
- 降低硬件使用量，可以减少40-50%。
- 开源社区大。Google将其发布为开源项目，吸引了1000+的社区贡献者，34000次commit。
与此同时，K8s有着不可规避的缺点。
- 首次部署比较艰难，困难度很高。
- 作为容器的第三方管理系统，容器本身的缺陷影响K8s提供的服务。
- Kubernetes欠缺的领域是调度器。
随着云原生的深入发展，容器技术再次彰显其价值，其中Kubernetes作为容器的编排、管理平台或系统，将会发挥至关重要的作用，前途不可限量。
......
好了，云原生、容器技术、K8s终于和盘托出，我也可以跟女朋友交差了。