Kubernetes是什么？
古早的部署时代呢，大家都在物理服务器上跑应用，谁也分不清究竟哪个程序占了多少资源，那可真是闹心啊！比如你在同一个物理服务器上给好几个程序开了工，那么其中一个程序可能就漫无目的地占满了整个服务器的资源，就像嚣张跋扈的土豪，让其他的程序都喘不过气来。这时候要是有办法把这些程序分开在不同的物理服务器上跑那该多好，可惜的是这样做也不能解决资源利用不够充分和维护这么多物理服务器的成本高昂这两个大难题。
虚拟化这个东西，就是咱们为了解决这些麻烦事儿弄出来的。他能让你在同一个物理服务器的CPU上开启好几台“小屋子”（VM，虚拟机），有点像开了一家宾馆包揽了住客的房间，却只用一套被子铺床。这样就能让应用程序彼此分开，而且还颇有人情味儿，因为他们之间看不见摸不着，谁也别想偷窥到谁的小秘密。虚拟化技术利用起物理服务器的资源来得心应手，还能让我们随着业务的扩展说加就加，说升级就升级，硬件成本蹭蹭往下掉，真是个好事儿。每个VM就像是一台微型的PC，在虚拟化的外衣下运转着所有部件，甚至还带了自己的操作系统来撑腰呢。
到了现在的容器部署时代，这个玩法跟虚拟机其实差不多，只是流程简化了点儿，有点儿像咱们做菜的时候用碗装菜，然后再找个篮子装碗，省事儿又能省碗。容器也有自己的文件系统、CPU、内存、进程空间啥的，跟VM也没有什么两样。但它跟硬件关系不太紧密，所以无论是放到云里还是放在操作系统上，都能稳妥地搞定。 容器还因为有很多优点变得越来越火爆。比如说呢，创建和部署应用程序就像是炒盘家常菜一样简单迅速；还有持续开发、集成和部署，这可是开发和运维之间的一份大哥大，支持可靠且频繁的容器镜像构建和部署。最有意思的是，关注开发与运维的分离，在构建/发布时创建应用程序容器镜像，这样就能让应用程序和基础架构相互远离，各自安好。再加上可观察性，不仅能展示操作系统级别的信息和指标，还能看到应用程序的运行状况和其他指标信号呢。还有跨开发、测试和生产的环境一致性，不管是在便携式计算机上还是在云中，都是同样地运行。跨云和操作系统发行版本的可移植性，可以在Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine以及其他各种场合里自由行动。最后，以应用程序为中心的管理，提升了抽象层次，从在虚拟硬件上运行OS变成了使用逻辑资源在OS上运行应用程序，这个关注点的切换真是让人眼前一亮哦。松散耦合、分布式、弹性、解放的微服务，把应用程序分解成若干个独立的部分，自由布署和管理——不再是在一台大机器上硬挺硬抗。资源隔离，预知应用程序的性能波动。资源利用，效率高，密度大，真是绝佳的捆绑和运行应用程序的方式。 在生产力整顿上，咱们得烙下这个印象：管理好运转应用程序的容器，保证没日没夜的工作，不要有机器停摆的现象。
为什么需要 Kubernetes，它能做什么？
服务发现和负载均衡搞得那叫一个溜啊！Kubernetes这货能用DNS名儿或者自家IP公开那些破烂儿容器，要是一不小心进来了大量流量，它立马就能委曲求全地把这些破烂儿分摊处理，稳定住整个部署。自动部署？那对Kubernetes来说就像是家常便饭：理解你的部署状态，然后按照你设定的速度慢慢把实际状况改造成你想要的那个理想形态。比如你要让它给你的部署整点新玩意儿容器，就得删掉现在用的这些老工具人，把他们的家产都贡献出来供养新人。各种操作孔武有力！不过别忘了定时给它们喂点吃的哦~
风驰电掣般的装箱计算要是没了Kubernetes可真是没法活下去。咱们可以尽情地去规划每一个容器需要多少CPU、还有多少内存（RAM）。只要容器报上了它们到货所需的这些屁事儿，Kubernetes就能自作主张，把资源管理得井井有条。即使出现了瑕疵，比如说某个家伙遇到点小问题，Kubernetes也能大刀阔斧地把它们干翻，换个新的，凡是没通过用户设定的健康检查又不肯改邪归正的，直接拉出去毙了，决不能留情。
Kubernetes在保护我们安全方面可是出了名的。比如说密钥、配置什么的，Kubernetes都给你管着，你不用再担心在重新部署应用程序的时候还得大费周章地重新创建容器镜像，或是在配置文件里泄露密码什么的。你只需动动手指头部署、更新你的密钥，应用程序就跟着你的指令起舞；至于那些不听话的，就让它们孤死路口好了。容量可以随意调节?那就让Kubernetes给咱们弄明白吧，你只需要告诉它你心目中的容器应该长什么样、需要用哪些资源，剩下的事情都由它搞定。无论是增加还是减少实例数量，它都会在最短时间内达到你的需求。
说到存储编排，瞧瞧Kubernetes，这货就能帮咱们轻松挂上各种款式的存储系统，不管是本地仓库，还是被世人所尊崇的公共云供应商们。如此强大的功能，你值得拥有！相信有了Kubernetes这货的辅助，你的业务一定会如虎添翼，登峰造极！
Kubernetes 版本进化
• 2014 年 6 月份：大家所熟知的那个谷歌，大声向全世界宣告，有个叫kubernetes的东西要开源啦！大家还记得吗？ • 同年 7 月份：眼见着这事儿火了起来，Microsoft、Red Hat、IBM、Docker、CoreOS、Mesosphere和Saltstack等巨头都纷纷投入到了kubernets之中来，热闹非凡。 • 再到 8 月份，咱们回到 2014 年 8 月份，这个时候有个老大哥——Mesosphere出来发声，他们说也要把 kubernetes纳入自己的阵营，然后用它来调度、部署和管理那些Docker的容器集群。真可谓是一石二鸟啊！ • 又过了一个半月，也就是当年的 8 月底，VMware也站出来表明态度，宣布要加入kubernets的大家庭。真是好事连连，热闹非凡！ • 当然，还有 11 月份，那件大事可不能忘记，HP同样加入了kubernets的团队。这样一来，筹码越来越重，众人纷纷效仿。 • 11 月份也是值得纪念的月份，Google的容器引擎Alpha版本上线，并且宣布在GCE（Google Compute Engine）中支持容器与服务，用的还是熟悉的那套，那个叫做kubernetes的架构哦。这可是不得了的消息呢！ • 再接下来，时光机器来到 2015 年 1 月份，当时Google与Mirantis及其他伙伴联手，将kubernetes引入OpenStack之中，让开发人员可以直接在openstack上安装和运行kubernetes应用。真是不得了啊！ • 同一年的 4 月份，Google和CoreOs一拍即合，共同发布了Tectonic，将熟知的kubernetes和CoreOS软件栈整合在了一起。这可是商业版啊！ • 到了 5 月份，Intel也加入了我们的家庭，表示会大力推动Tectonic软件栈的开发进程，助力我们成长壮大。真是太好了！ • 紧接着，又是一个重大事件发生在2015年6月份，Google的容器引擎正式步入beta版本。beta版本预示着什么呢?温室里的花朵即将走向成熟。 • 到了7月份，Google终于正式加入了OpenStack基金会，Kubernetes的产品经理毫不讳言地坦白，他将要把他所掌握的关于容器计算的专业知识注入到OpenStack这个大家庭当中去。你们猜对了，那就是kuberntes！ • 而就在同一天，我们亲爱的Kuberentes v1.0正式面世啦！之后每三个月更新一次，现在我们已经来到1.22版本咯！
Kubernetes 概念
控制平面组件（Control Plane Components）
• apiserver：得大头角色者，作为咱们kubernetes系统的大柜台，啥功能都不少，包括但不限于核心对象的增删改查这些家常便饭，都是以RESTFul 接口这种通俗易懂的方式提供给外部顾客和内部老铁们调用。老哥稳妥画风，他手底下维护的那些玩意儿都会稳稳当当地存进立即性（Durable）、容错性（Fault-Tolerant）的etcd大神家里吃住。
• scheduler：这个家伙就是负责集群那点破事儿的资源大管家，一有新宝宝 ——即新建的 pod，就负责给他分派一片天地（好比为新生儿找个爸似的）——即分配机器。这小子割据一方，分化成一个独立的部件，毫无疑问，以后换台车跑路都行，多敞亮！
• controller-manager：老大的跟班，手里需要处理各种琐碎的事务，现在嘛，有两种主流玩法：
• endpoint-controller：兢兢业业打工仔，至少半年一次死磕，把service 和 pod勾搭在一块儿（关联信息会由 endpoint 当事人来照料），确保 service 到 pod 的中间人永远是帅气的最新款。
• replication-controller ： 如同上班打卡一样定点儿去节点，盯紧 replicationController 和 pod 的关系，务必让 replicationController 规定的复制数量赶得上实际运行平淡无奇的 pod 的产量！Node 组件
• kubelet：接锅客服，搞定 docker 容器的一切事宜，比如说开机/关机这类小事儿，以及监控运行活蹦乱跳的状态什么的。这个货儿会定期从 etcd 大神那里获取分配到家门口的 pod，然后再根据 这位来访的 pod 的情报启动或者关闭相应的容器。而且啊，它还能飘洋过海接收到 apiserver 的 HTTP 请求，汇报 那个征战四方的 pod 正在战火纷飞中演绎着自己的故事。
• proxy：这个技术含量高些，起到为pod 提供代言人的作用。它老大是 etcd，时不时扒拉扒拉所有的 service，然后根据服务信息建立代理。真可谓独孤求败，当某位客户的 pod 需要拜访他人时，拜访请求自然会通过在本机安营扎寨的 proxy 做转发送的。
• Container Runtime – Docker enginee 插件（Addons）
• CoreDNS: Kube-DNS, CoreDNS
• Network Plugin : Flannel/calico
• Web 界面（仪表盘）: Dashboard 这哥们儿就是个全能选手，既能帮忙搞定 Kubernetes 集群的大活儿，又能用言语表达清楚，简单明了，让用户轻松管理集群中操劳奔波的应用程序以至整个丛林本身，实在是让人爱不释手的监测工具。
• 容器资源监控：Heapster, Metrics-server
Kubernetes 中 3 个重要概念
• the Pod：哦，这个东西可谓是 Kubernetes 的底子啊！无论您要搞什么东东，它都能摆平！Pod简直就是一个大牛级别的容器，说实话，它代表着某种应用的一个实例。例如，咱们假设有个火爆的 web 站点，那就得靠前端、后端以及数据库这几个江湖好汉一起使劲儿，它们各显神通，在自己的小天地里大展拳脚。所以呢，Pod 嘛，咱们就可以利用起来，让这三位英雄都住进 Pod 的大家庭中去啦。
• the Service：瞧吧，Kubernetes 的神器来了！这个东西可比 Pod 厉害多了，它是真实应用服务的精致模版，背后隐藏着无数栩栩如生的容器。这些容器犹如众士兵守护着强大的司令官—Service，它们通过 Proxy 的 port 和服务 selector 明察秋毫，一旦有敌军出现，就立即向后传达远处传来的战斗信号，决定到底应该让哪位大侠过来支援。这样一来，无论敌人多么凶猛，Service总是能够以其单一的访问接口来应对，外界也无需知晓内部的运作机制，真正实现了后端的隐形守护神，对后期的扩张和维护可真是益处多多啊！
• the ReplicationController：哼，这个就是 Pod 的老铁，专门用来处理 Pod 的大小调整问题，稳重得很。做一般大型游戏时，为了多获得点加分或是想提高游戏的生存率，大部分玩家都会考虑多生孩子，但这个孩子多了也得精打细算，不能浪费。ReplicationController就能帮您解决这类问题，您只需告诉它某场游戏需要多少份资源，然后 Kubernetes 就会像部队一样，按照您说的数量来为每份资源创建一个 Pod，确保腹中的孩子们数量不会超过您的期望（比如突然哪个孩子夭折了，立马就会被替代）。
