云原生技术之kubernetes学习笔记(1)

云原生技术之kubernetes学习笔记(1)

今天我们看看kubernetes技术的介绍，最近在极客时间上看张磊老师的深入kubernetes技术，讲的非常好，有兴趣的同学可以去收听一下，对于理解kubernetes技术非常有帮助，这里我会按照自己的进度，分享一下学习的笔记。

今天站的角度比较高，概念性质的东西会多一点。

01 kubernetes是什么？

曾经我认为这个问题很好回答，直到不断的去理解kubernetes，不断的深入之后，我发现这个问题很难回答的全面。

要想搞明白这个问题，首先你得知道容器是什么？在前面的文章中，我们说过，容器是一个特殊的进程，实际上是由Namespace、Cgroup、以及rootfs三种技术构建出来的一种特殊的进程的隔离环境。 这个隔离环境最主要的目的，是要运行我们自己的应用程序。

对于云厂商来说，如果能够将用户提交上来的docker镜像运行在自己平台的容器环境中，并很好的管理起来，那么这个云平台就有了商业价值。事实上，也确实是这么实现的。

然而，想要得到用户的认可，绝不仅仅是支持一个容器、一个用户的docker镜像，更多的是支持无数开发者，庞大的容器集群，才能让你的平台得到云原生整个生态的认可。基于这个现实情况，不难发现，谁能够更好的组织、调度、编排、规范化管理容器集群，谁就能够得到容器领域的青睐。

这里面，我标红了2个词语，分别是调度和编排，对这两个词语，有必要解释一下：

调度：把一个容器，按照某种规则，放置在某个最佳节点上运行起来

编排：按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系

在这样的背景下面，docker公司原生的Compose+Swarm组合、以及google公司的kubernetes项目应运而生。为什么kubernetes最终胜出？我们慢慢来看。

Kubernetes项目的理论基础要比工程实践走得更靠前，kubernetes项目起源于Borg，一个Google公司基础设施的核心系统，相比于其他的容器编排项目，它体现出了一系列的"先进性"和"完备性"，而这些特性，成为了kubernetes项目赖以生存的核心价值。

kubernetes的问世，解决了容器的编排、调度和集群管理中的瓶颈，它解决了用户一个痛点问题：我有一个应用程序的容器镜像，请帮我在一个集群上将这个应用程序运行起来。然而，这并不足以让它替代Compose+Swarm的架构，因为docker公司原生的Compose+Swarm架构也能够解决容器的运行和基本的运维管理功能。

kubernetes更有价值的地方在于，它从一开始，就不是围绕docker这个特定的容器去设计的，它将docker仅仅看成是底层的一个容器实现，它着重解决的问题是：运行在大规模的任务之间，实际上存在着各种各样的关系，这些关系的处理，才是任务编排和系统管理最困难的地方。

这些任务之间的关系有很多类型，例如，一个web应用和MySQL数据库之间的关系、一个负载proxy和后端服务之间的关系等等。

传统的虚拟机处理这种类型的任务，通常情况是将它们部署在一起，因为各个任务之间会有tcp或者http的请求发生。但是容器技术出现之后，各个任务都可以通过镜像的方式，封装在不同的容器中，它们之间不相互干涉，拥有各自的资源配置，也可以被集群调度在不同的机器上。如下：

02 kubernetes和Compost+Swarm之间的区别

这种任务之间的关系处理，也是kubernetes项目区别于Compost+Swarm架构最明显的地方。

以web应用和MySQL这两个服务为例，在Compost+Swarm架构中，会为这两个服务中间定义一个"link"，Docker项目会负责维护这个"link"。Docker会在这个web应用的容器中，将DB容器的IP、port以环境变量的方法给注入进去，供应用进程使用，当DB容器的连接信息发生变化的时候，更新环境变量。

Compost+Swarm这种设计模式，可以比较好的支持web应用和MySQL的服务之间联系，但是未来可能出现更多类型的任务之间的联系，这种简单的处理依赖关系的能力，一定会遇到瓶颈。

Kubernetes 项目最主要的设计思想是：从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。

例如，Kubernetes为容器之间的相互调用进行了分类，来区分哪些交互式频繁的tcp交互，哪些交互仅仅是磁盘文件的交互等等。对于这些需要交互的任务，常规的做法是各种任务部署在同一台机器上，通过Localhost进行通信，而Kubernetes引入Service的概念，让两个本来互相依赖的服务，甚至可以部署在不同的机器上。每一个Service的背后，都是若干个Pod，Service的作用就是为Pod提供固定的代理入口，而Pod的分布，完全是随机的。

这样，对于 Web 应用的 Pod 来说，它需要关心的就是数据库 Pod 的 Service 信息。不难想象，Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自动更新、维护，则是 Kubernetes 项目的职责。

03 一点总结

今天我们从容器这个最基础的概念出发，提出了k8s产生的背景，又通过web应用和MySQL服务之间的“紧密协作”关系，扩展到了 Pod，有了 Pod 之后，我们希望能一次启动多个应用的实例，这样就需要Deployment 这个 Pod 的多实例管理器(后面会讲到)；而有了这样一组相同的 Pod 后，我们又需要通过一个固定的 IP 地址和端口以负载均衡的方式访问它，于是就有了 Service，如果web应用访问MySQL需要账号密码，我们又会引出Secret......最终，你会看到下面的一张图：

具体的内容，我们后续慢慢分析。。。

说这么多，主要是为了表达Kubernetes 项目并没有像其他项目那样，为每一个管理功能创建一个指令，然后在项目中实现其中的逻辑。 相比之下，在 Kubernetes 项目中，我们所推崇的使用方法是： 1、首先，通过一个“编排对象”，比如 Pod、Job、CronJob 等，来描述你试图管理的应用； 2、然后，再为它定义一些“服务对象”，比如 Service、Secret、Horizontal Pod Autoscaler（自 动水平扩展器）等。这些对象，会负责具体的平台级功能。 这种使用方法，就是所谓的“声明式 API”。这种 API 对应的“编排对象”和“服务对象”，都是Kubernetes 项目中的 API 对象（API Object）。

这就是 Kubernetes 最核心的设计理念。

今天的内容就先到这里了。