小暖男石头哥|「Kubernetes1」 前世今生:k8s 是如何火起来的

云计算相关概念【小暖男石头哥|「Kubernetes1」 前世今生:k8s 是如何火起来的】或许你已经听过或简单了解过 Kubernetes , 它是一款由 Google 开源的容器编排管理工具 , 而我们想要深入地掌握 Kubernetes 框架 , 就不得不先了解 Kubernetes 的前世今生 , 而这一切都要从“云计算”的兴起开始讲起 。 说来也巧 , “云计算”这个概念也是由 Google 提出的 , 可见这家公司对计算机技术发展的贡献有多大 。 自云计算 2006 年被提出后 , 已经逐渐成为信息技术产业发展的战略重点 , 你可能也会切身感受到变化 。 我们平时在讨论技术的时候 , 经常会被问到诸如“你们公司的业务是否要考虑上云”的问题 , 而国内相关的云计算大会近几年也如雨后春笋般地召开 , 可见其有多么火热 。
而云计算之所以可以这么快地发展起来 , 主要原因还是可以为企业带来便利 , 同时又能降低成本 , 国内的各大传统型企业的基础设施纷纷向云计算转型 , 从阿里云、腾讯云每年的发展规模我们就可以看出来云计算市场对人才的需求有多大 。
我们可以将经典的云计算架构分为三大服务层:也就是 IaaS(Infrastructure as a Service , 基础设施即服务)、PaaS(Platform as a Service , 平台即服务)和 SaaS(Software as a Service , 软件即服务) 。
IaaS 层通过虚拟化技术提供计算、存储、网络等基础资源 , 可以在上面部署各种 OS 以及应用程序 。 开发者可以通过云厂商提供的 API 控制整个基础架构 , 无须对其进行物理上的维护和管理 。 这样解释起来可能会有点抽象 , 我们可以想象自己要去一个地方旅行 , 那么首先就需要解决住的问题 , 而 IaaS 服务就相当于直接在当地购买了一套商品房 , 像搭建系统、维护运行环境这种“装修”的事情就必须由我们自己来 , 但优点是“装修风格”可以自己定 。
PaaS 层提供软件部署平台(runtime) , 抽象掉了硬件和操作系统 , 可以无缝地扩展(scaling) 。 开发者只需要关注自己的业务逻辑 , 不需要关注底层 。 PaaS 是我们到了一个陌生的城市 , 可以选择住民宿或青旅 , 这样就不需要考虑装修和买家具的事情了 , 系统和环境都是现成的 , 我们只需要安置自己的行李箱就可以了 。
SaaS 层直接为开发者提供软件服务 , 将软件的开发、管理、部署等全部都交给第三方 , 用户不需要再关心技术问题 , 可以拿来即用 。 SaaS相当于直接住酒店 , 一切需求都由供应商搞定了 , 我们还可以选择自己喜欢的房间风格和户型 , 连行李箱都不用带 。
Kubernetes 成为事实标准我们了解了云计算的概念 , 既然上云可以给我们带来这么多的便利 , 那么我们该如何让系统上云呢?以前主流的做法就是申请或创建一批云服务比如亚马逊的 AWS EC2、阿里云 ECS 或者 OpenStack 的虚拟机 , 然后通过 Ansible、Puppet 这类部署工具在机器上部署应用 。 但随着应用的规模变得越来越庞大 , 逻辑也越来越复杂 , 迭代更新也越来越频繁 , 这时我们就逐渐发现了一些问题 , 比如:有时候用户只是希望运行一些简单的程序而已 , 比如跑一个小进程 , 为了不相互影响 , 就要建立虚拟机 , 这显然会浪费不少资源;比如如果想要迁移整个自己的服务程序 , 就要迁移整个虚拟机;比如在进行业务部署发布的过程中 , 服务之间的各种依赖 。
Docker 的横空出世 , 一下子解放了生产力 。 开发者可以根据自己的喜好选择合适的编程语言和框架 , 然后通过微服务的方式组合起来 。 有了容器 , 开发人员就只需要考虑如何恰当地扩展、部署 , 以及管理他们新开发的应用程序 。 但如果我们大规模地使用容器 , 就不得不考虑容器调度、部署、跨多节点访问、自动伸缩等问题 。
Kubernetes 的目标就是消除编排物理或者虚拟计算、网络和存储等基础设施负担 , 让应用运营商和开发工作者可以专注在以容器为核心的应用上面 , 同时可以优化集群的资源利用率 。 Kubernetes 这个词由 Joe Beda , Brendan Burns和 Craig McLuckie 所创建 , 源于希腊语的“舵手”或者“领航员” , 简称“K8s” , 用 8 代替 8 个字符“ubernete”而成的缩写 。 Kubernetes 并不会跟任何平台绑定 , 它可以跑在任何环境里 。 通过 minikube 这类工具 , 就可以在你的笔记本上快速搭建一套 Kubernetes 集群出来 。 Kubernetes 使用了声明式API , 你可以直接通过 YAML 或者 JSON 进行声明 , 然后通过 PATCH 的方式就可以完成对 API 对象的多次修改 , 而无须关心原始 YAML 或 JSON 文件的内容 。


推荐阅读