Why Kubernetes ，我所理解的docker与k8s

---

去年换工做后，开始真正在生产环境中接触容器与Kubernetes。边恶补相关知识的同时，也想把学到的内容和本身的理解整理出来。学习的途径包括k8s官方文档、书籍、极客时间专栏及网上各类博文。所涉及一些摘抄或描述，大多用本身的理解来组织语言，也就不一一注明出处了。

---

Kubernetes(简称K8S)与容器技术，能够说是近几年最火热的技术之一。提起K8S，你们都知道是google开源的容器编排工具。今天想先谈谈，我理解的容器、K8S是什么，以及为何它们能火起来。

Why Docker

既然说K8S是一个容器编排的工具，那么要搞清楚K8S是什么，首先得搞清楚，容器是什么，以及为何要用容器技术。

形象的来讲，一个linux容器，实际就是一个进程，仍是个被系统欺骗的进程。为何这么说呢？一个运行在容器里的进程，主要有如下特色：

• 它被宿主机操做系统隔离了，它看不到宿主机上的其余进程，觉得本身就是pid为1的进程
• 它被宿主机操做系统限制了硬件资源，它能使用的cpu、内存等硬件资源只是宿主机的一部分
• 在被宿主机操做系统限制了存储空间，让这个进程认为宿主机的某个目录就是系统根目录

这几个欺骗进程的技术，就是是容器技术的三板斧，用于资源隔离的namespace，用于资源限制的cgroup,以及用于假装进程根目录的rootfs。这三种技术，都是是早已存在于linux中的，只是docker公司比较创新的把这三种技术整合在一块儿，而且，提出了容器镜像及镜像仓库等概念，把这个进程及相关的依赖环境都一块儿打包成可分发及重复使用的镜像文件，方便容器能在不一样机器之间移植。这样，在任何地方，只要能运行docker，就能把容器镜像跑成一个包含这应用进程及相关依赖环境的容器实例。

这里用利用K8S官方文档的图，简单说下生产中的场景，看看容器技术能解决什么问题。

左图是传统的物理机部署应用方式的方式，能够看到除了一个应用的运行，除了程序自己，离不开应用配置、库、等等依赖环境。一般状况下，一个应用的上线，要经历开发环境、pre环境、beta环境、灰度测试、生产环境等等不一样的基础环境。开发的同窗在开发环境跑通了代码，到其余环境运行时，因为各环境依赖、配置、安全需求不一样，可能会出现各类问题。运维的同窗忙着在不一样的环境中统一依赖。不一样应用各类语言，各类应用的特殊依赖需求，也形成了CI/CD逻辑复杂，难以统一。

右图是用了容器技术以后的场景。一个容器镜像的实质就是程序进程加全部运行时环境及配置、依赖的集合。只要各个环境的底层能兼容docker，就能实现全部环境部署的一致性。开发同窗不用关心生产环境和开发环境的差别可能会致使应用运行问题，运维同窗部署一个应用，只要确保容器镜像能正常运行就好。CI/CD的自动化也相对容易实现不少。从而极大增长开发效率、应用迭代效率及节省了运维工做量。

说到这里，不得不说下容器与传统意义的虚拟机间的对比。其实两者均可以理解为虚拟化，它们最本质的区别是，容器是操做系统层级的虚拟化，而虚拟机是硬件层级的虚拟化。参看下图。

因为虚拟机多了一层Guest OS，须要宿主机额外的性能开销进行硬件虚拟化，同时由于是完整的操做系统，虚拟机镜像通常动辄大几G，很难在各环境间快速传播，hypervisor层相对Docker Engine也比较重。再看docker容器，实质就是宿主机上跑的一个进程，只不过经过docker与其余进程隔离开来。简单的说，敏捷和高效，是容器相比虚拟机最大的优点，固然也有劣势，因为容器只是操做系统级别的隔离，不一样容器间隔离的不够完全。

Why Kubernetes

简单说完了docker的理解，那么Kubernetes又是什么，它解决了哪些问题呢，为啥如今提容器技术必提k8s呢。这里再谈谈我理解的Why K8S。

回到实际的场景来，假如你已经开始用docker镜像来打包应用，能够方便的进行分发和部署，不用去考虑不一样环境的差别。可是不是还感受还少了点什么？

由于正常的实际业务系统，不是应用能部署，能运行起来就完事了，还要考虑应用容器的访问、水平伸缩、监控、安全、备份、容灾等等因素。而对于一个完整的业务系统来讲，也不是单个应用就能搞定的，还要考虑的是各应用间的关系，及应用运行的形态。好比一个web业务，可能须要web服务器、缓存系统、数据库等多个应用。容器化部署后，它们可能部署在不一样宿主机的不一样容器中，相互间的访问要怎么实现，这就涉及到容器间访问关系的处理。再好比，有个优化缓存的应用也跑在容器里，只须要按期运行容器实例执行优化任务，执行完毕就终止容器，这就须要处理不一样容器应用的运行形态问题。相似上述这些对容器应用及容器间关系进行管理，就是所谓的容器编排及调度。而Kubernetes，就是目前的容器编排的平台的事实标准了。

那么，具体来讲，K8S到底能作哪些事呢。

在官方文档中，对K8S功能的描述以下

Kubernetes 知足了生产中运行应用程序的许多常见的需求，例如：
Pod提供了一种复合的应用容器模型,
挂载外部存储,
Secret管理,
应用健康检查,
副本应用实例,
横向自动扩缩容,
服务发现,
负载均衡,
滚动更新,
资源监测,
日志采集和存储,
支持自检和调试,
认证和鉴权.

从这些功能介绍能够看出，K8S已很相似一个云平台了，能够彻底能知足生产级别的容器应用管理需求。下面是一张最简单的K8S系统示意图：

K8S集群由一个主节点（master节点）及多个工做节点（node节点）构成，开发者提交应用容器镜像，并将镜像运行的数量、方法等经过描述文件提交给K8S master节点，K8S master节点或根据集群总体状况，将应用按照需求部署在工做节点中。对于开发者来讲，利用K8S能够方便的部署程序，不用关心基础设施，而对于运维人员来讲，工做重心从维护具体应用，转变为维护K8S集群。并且，不论是开发者仍是运维人员，都不用关心应用具体部署在哪一个节点，K8S会自动判断搞定一切。相比于传统的应用部署方式，有没有以为K8S很棒棒？

在容器编排这个概念出现的时候，Kubernetes并非惟一的一个容器编排工具，主流的工具还有Docker公司原生的swarm和Apache基金会的mesos，为何K8S能笑到最后，成为容器编排的事实标准呢？我理解K8S对比它们有两个最大不一样点：（这里不对swarm和mesos作详细介绍了，实际也确实没怎么玩过）

1. K8S对容器又作了一层抽象，也就是POD。
   不一样于与其余两个工具，K8S管理的原子对象，其实并非容器，而是POD。按照官方文档的定义，一个POD，是由一个或多个共享存储及网络的容器，以及描述怎么运行这些容器的集合，因此，POD实际是一个抽象的概念。k8s对容器的全部操做，好比动态伸缩、监控等，实际上都是对pod的管理。那这层抽象的好处是什么呢？
   上面有提到过，容器实质就是被特殊处理的进程。想像一个web业务，web应用进程输出的日志须要被大数据agent进程处理。这个业务若是想容器化，一般有两个作法。一是分别起来两个容器，挂载宿主机同一个目录来存放日志。另外一种是起一个操做系统级别的容器或supervisord容器做为enterpoint，来管理web服务和agent进程。前一种方式，这个两个容器就被框在这台宿主机上了，要实现业务实例横向扩缩容，要考虑两个容器的运行状况和存储挂载，逻辑比较复杂。后一种方式，你要为每一个容器再额外开一个supervisord进程，更重要的是，因为entrypoint是supervisord进程，web应用和大数据agent对docker来讲，都是不可见的。即便nginx出错频繁重启，只要supervisord还活着，Docker就认为这个容器是正常的。

   咱们再来看看，使用了pod这个概念之后，有什么变化。一个pod里面同时起了web服务进程和大数据agent两个容器实例，首先，pod里的容器实例是共享存储和网络namespace的，也就是说，这两进程的存储数据是直接共享的，不须要额外的挂载动做。其次，这个pod是做为一个总体被k8s管理着的，k8s会监控pod里每一个容器的状态，并根据策略在有问题时进行自动干预。从这个意义上说，pod才更相似传统的虚拟机。

2. 声明式API
   第二点也是比较重要的方面，是K8S的声明式api(貌似swarm的新版也支持了，一样没玩过就不细说了)。什么是声明式API呢，能够参考上面系统图中的描述文件。好比要我须要集群中跑10个web服务容器，传统的命令式API是一步步调用命令构建出容器。而使用声明式api，只要告诉K8S我要10个web容器，K8S就会自动将web集群实例数维持在10个，而且，在某个pod出问题退出时，K8S会自动从新拉起新pod，使集群始终保持10个pod实例在跑。这就使得管理集群变得很简单，只要经过配置文件描述出但愿的集群状态，而不用去关注中间的实现过程。

最后，总结一下：
Why Dokcer： 用容器技术跑应用，相比原来的物理机及虚拟机更高效、轻量、省资源，同时大大方便了不一样环境下的应用部署及分发。
Why Kubernetes：生产集群光跑容器还不够，还要对容器应用做为一个业务系统集群进行编排及管理，而K8S的一些优点使得它成为目前容器集群编排管理工具的事实标准。

最后的最后再多提一点，实际上，容器技术不止Docker公司一家在作，Kubernetes也不是只能管理Docker容器。只是，不管从市场份额、应用性仍是开发社区的热度来讲，它们都是目前容器技术最主流的解决方案，就生产环境来讲，目前基本没有必要去考虑其余的容器技术了。