Kubernetes-旅程的开始

Follow the notes upon the journey, At first sight make one's destiny. Once the voyage comes to an end, Return lies within hasty keys.

在一番铺垫之后，让我们步入正题，今天正式来play with kubernetes。

搭建一个集群

万事开头难，我们还需要现有一个kubernetes集群来开始我们的旅程。

作为一个分布式系统项目，kubernetes的部署一直是一直拦路虎，在最初用户需要编译一堆二进制文件，还要为这些二进制编写配置文件、准备证书等等等等步骤，对于新手来说，大概这就是：kubernetes从还没入门到放弃。

如果你熟悉Linux而且有运维经验的话，那么你可以按照Kubernetes官方推荐，用kops等来安装集群。如果是一个新手，你那在本地装一个minikube入门玩也是不错的选择，但是今天我要介绍一个更简单的方式。

不想看英语？不想安装太复杂？那么试一下Rancher吧。利用Rancher你可以简单几步就搭建起一个单节点集群来使用，或者你想试试多节点集群也很简单，多复制粘贴几句Docker命令而已。Rancher也是我们那之前说的在Kubernetes生态繁荣下诞生的创业公司的典型，当然Rancher还可以做更多事情，但是我们目前只是需要一个新手友好的环境而已，剩下的就留给你们自己去探索吧。

Rancher中文文档链接：

https://www.rancher.cn/docs/rancher/v2.x/cn/overview/

小试牛刀

当你按照Rancher官方文档搭建好一个集群环境之后，你一定磨刀霍霍了，下面我们以开发者的身份使用kubernetes来发布一个容器化应用，来小试牛刀。

我们之前已经讲过容器镜像相关知识，如何把这个镜像组织为kubernetes认识的方式提交上去呢？

我们要和Kubernetes打交道，便要根据kubernetes的要求和规范，来用它的语言来和它打交道，这个方式就是：YAML配置文件。

这也是kubernetes和Docker等项目最大的不同，kubernetes不鼓励你用命令行的方式直接运行镜像（虽然它本身也支持这种方式，像：kubectl run），kubernetes鼓励你用YAML的方式把这个容器的定义、参数、配置等等全都写在一个YAML文件里，然后再用命令将它运行起来：

这么做的好处显而易见，我们把编排的内容都记录在了文件里，记录下了我们run了个什么东西，我们拿来看一个例子：

我们来看看这个文件都记录了什么，我们可以看到这个YAML中的kind字段是Deployment，Deployment也就是一个多副本应用对象（即多个Pod），我们可以使用它来进行滚动更新。在这个YAML里，我们定义的Pod副本数是2个，我们之前已经提到了Pod是kubernetes编排的最小单位，那么这个Pod是怎么定义的呢？

像这样的一个 YAML 文件，对应到 Kubernetes 中，就是一个 API Object（API 对象）。当你为这个对象的各个字段填好值并提交给 Kubernetes 之后，Kubernetes 就会负责创建出这些对象所定义的容器或者其他类型的 API 资源。

在上面这个例子里，Deployment是一个API对象，而Pod也是一个API对象，而Deployment对象管理着Pod对象，在 Kubernetes 中，这叫作“控制器”模式（controller pattern）。在这个例子里，Deployment 扮演的正是 Pod 的控制器的角色。

这样我们就能够将上面的YAML分为两部分来看，一部分是控制器的定义，在这个例子里即Deployment的定义：

剩下的则是Pod对象的定义了。

我们那可以看到我们定义了API的metadata参数，这一组参数定义了这个对象的标识，这也是我们在kubernetes里找到这个对象的依据。这其中最主要使用到的字段是 Labels。顾名思义，Labels 就是一组 key-value 格式的标签。而像 Deployment 这样的控制器对象，就可以通过这个 Labels 字段从 Kubernetes 中过滤出它所关心的被控制对象。比如，在上面这个 YAML 文件中，Deployment 会把所有正在运行的、携带“app: nginx”标签的 Pod 识别为被管理的对象，并确保这些 Pod 的总数严格等于两个。

一个 Kubernetes 的 API 对象的定义，大多可以分为 Metadata 和 Spec 两个部分。前者存放的是这个对象的元数据，对所有 API 对象来说，这一部分的字段和格式基本上是一样的；而后者存放的，则是属于这个对象独有的定义，用来描述它所要表达的功能。

下面我们可以将这个对象运行起来看看：

然后我们通过kubectl get命令来查看这个Deployment的运行状态是不是符合预期：

我们可以看到现在有两个Pod正在运行，符合我们的预期。

kubectl get 指令的作用，就是从 Kubernetes 里面获取（GET）指定的 API 对象。可以看到，在这里我还加上了一个 -l 参数，即获取所有匹配 app: nginx 标签的 Pod。

如果我们想看看这个对象的细节，那么使用kubectl describe吧：

在返回的结果中我们可以看到这个Pod的详细信息，我特意列出了最后的Events，Events将是我们Debug的重要依据，它列出了Kubernetes执行过程里对API对象操作的信息，比如上面从开始创建容器到拉取镜像到将这个容器分配到某个节点的信息都被记录了下来。

下面我们来将这个Deployment进行一下滚动升级，我们现在被告知要把Nginx的版本改到1.8，我们要怎么操作呢？

我们上面的YAML文件记录了所有API对象定义，那么我们修改这个文件就好了。

我们将这个镜像版本改掉：

然后执行：

用kubectl apply的好处就是你不用关心是创建还是更新，kubernetes会根据文件的内容自动处理。它有助于帮助开发和运维人员，围绕着可以版本化管理的 YAML 文件，而不是“行踪不定”的命令行进行协作，从而大大降低开发人员和运维人员之间的沟通成本。

以上就是发布一个应用的简单案例了，本次分享让你近距离体验了kubernetes的使用操作，这个过程即是：

首先，在本地通过 Docker 测试代码，制作镜像；

然后，选择合适的 Kubernetes API 对象，编写对应 YAML 文件（比如，Pod，Deployment）；

最后，在 Kubernetes 上部署这个 YAML 文件。

而后面的分享里，我将会详细讲解kubernetes 的API对象们。

欢迎关注~~