谈谈Kubernetes的内核

• 1-容器的结构

  • （1）一组联合挂载在/var/lib/docker/aufs/mnt上的rootfs,这一部分我们称为“容器镜像（Container Image）”,是容器的静态视图。
  • （2）一个由NameSpace+Crgoups 构成的隔离环境，这一部分我们称为“容器运行时”（Container Runtime），是容器的动态视图。

​ 容器就从一个开发者手里的小工具，一跃成为了云计算领域的绝对主角，而能够定义容器组织和管理规范“容器编排”技术，则当仁不让地坐上容器技术领域的“头把交椅”。

• 2-Kubernetes 和Swarm的对比

  • Docker Swarm和Kubernetes

    Docker Swarm 是 Docker 公司的容器编排系统，使用的是标准 Docker API 接口，容器使用命令和 docker 命令是一套，简单方便。Docker Swarm 基本架构是也是简单直接，每个主机运行一个 Docker Swarm 代理，一个主机运行一个 Docker Swarm 管理者，这个管理者负责指挥和调度这些主机上的容器，Docker Swarm 以高可用性模式运行，Docker Swarm 中的一个节点充当其他节点的管理器，包括调度程序和服务发现组件的容器。

    Docker Swarm 的优点和缺点都是使用标准的 Docker 接口，因为使用简单，容易集成到现有系统，所以在支持复杂的调度系统时候就会比较困难了，特别是在定制的接口中实现的调度。这也许就是成也在 Docker，败也在 Docker 的原因所在。

    Kubernetes 作为一个容器集群管理系统，用于管理云平台中多个主机上的容器应用，Kubernetes 的目标是让部署容器化的应用变得简单且高效，所以 Kubernetes 提供了应用部署，规划，更新，维护的一整套完整的机制。

    Kubernetes 没有固定要求容器的格式，但是 Kubernetes 使用它自己的 API 和命令行接口来进行容器编排。除了 Docker 容器之外，Kubernetes 还支持其他多种容器，如 rkt、CoreOS 等。Kubernetes 是自成体系的管理工具，可以实现容器调度，资源管理，服务发现，健康检查，自动伸缩，更新升级等，也可以在应用模版配置中指定副本数量，服务要求（IO 优先；性能优先等），资源使用区间，标签（Labels等）来匹配特定要求达到预期状态等，这些特征便足以征服开发者，再加上 Kubernetes 有一个非常活跃的社区。它为用户提供了更多的选择以方便用户扩展编排容器来满足他们的需求。但是由于 Kubernetes 使用了自己的 API 接口，所以命令系统是另外一套系统，这也是 kubernetes 门槛比较高的原因所在。

    大部分的应用程序我们在部署的时候都会适当的添加监控，对于运行载体容器则更应该如此。kubernetes 提供了 liveness probes 来检查我们的应用程序，它是由节点上的 kubelet 定期执行的。

    • 实际上，过去很多的集群管理项目（比如 Yarn、Mesos，以及 Swarm）所擅长的，都是 把一个容器，按照某种规则，放置在某个最佳节点上运行起来。这种功能，我们称为“调 度”。 而 Kubernetes 项目所擅长的，是按照用户的意愿和整个系统的规则，完全自动化地处理 好容器之间的各种关系。这种功能，就是我们经常听到的一个概念：编排。 所以说，Kubernetes 项目的本质，是为用户提供一个具有普遍意义的容器编排工具。

• 3-Kubernetes 的历史

  • Kubernetes 项目的理论 基础则要比工程实践走得靠前得多，这当然要归功于 Google 公司在 2015 年 4 月发布的 Borg 论文了。 Borg 系统，一直以来都被誉为 Google 公司内部最强大的“秘密武器”。
  • Borg 可以说是 Google 最不可能开源的一个项目。而幸运地是，得 益于 Docker 项目和容器技术的风靡，它却终于得以以另一种方式与开源社区见面，这个方 式就是 Kubernetes 项目。 所以，相比于“小打小闹”的 Docker 公司、“旧瓶装新酒”的 Mesos 社区， Kubernetes 项目从一开始就比较幸运地站上了一个他人难以企及的高度：在它的成长阶 防止断更 请务必加 首发微信：1716143665 段，这个项目每一个核心特性的提出，几乎都脱胎于 Borg/Omega 系统的设计与经验。更 重要的是，这些特性在开源社区落地的过程中，又在整个社区的合力之下得到了极大的改 进，修复了很多当年遗留在 Borg 体系中的缺陷和问题。

• 4-Kubernetes的架构

  • 

  • 我们可以看到，Kubernetes 项目的架构，跟它的原型项目 Borg 非常类似，都由 Master 和 Node 两种节点组成，而这两种角色分别对应着控制节点和计算节点。 其中，控制节点，即 Master 节点，由三个紧密协作的独立组件组合而成，它们分别是负责 API 服务的 kube-apiserver、负责调度的 kube-scheduler，以及负责容器编排的 kube-controller-manager。整个集群的持久化数据，则由 kube-apiserver 处理后保存在 Etcd 中。 而计算节点上最核心的部分，则是一个叫作 kubelet 的组件。

• 5-Kubernetes 项目要着重解决的问题？

  • 运行在大规模集群中的各种任务之间，实际上存在着各种各样关系，这些关系的处理，才是作业编排和管理系统最困难的地方。
    实际上存在着各种各样关系，这些关系的处理，才是作业编排和管理系统最困难的地方。
  • Kubernetes项目最主要的设计思想是，从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。