|
|
# 12 | 牛刀小试：我的第一个容器化应用
|
|
|
|
|
|
你好，我是张磊。今天我和你分享的主题是：牛刀小试之我的第一个容器化应用。
|
|
|
|
|
|
在上一篇文章《从0到1：搭建一个完整的Kubernetes集群》中，我和你一起部署了一套完整的Kubernetes集群。这个集群虽然离生产环境的要求还有一定差距（比如，没有一键高可用部署），但也可以当作是一个准生产级别的Kubernetes集群了。
|
|
|
|
|
|
而在这篇文章中，我们就来扮演一个应用开发者的角色，使用这个Kubernetes集群发布第一个容器化应用。
|
|
|
|
|
|
在开始实践之前，我先给你讲解一下Kubernetes里面与开发者关系最密切的几个概念。
|
|
|
|
|
|
作为一个应用开发者，你首先要做的，是制作容器的镜像。这一部分内容，我已经在容器基础部分[《白话容器基础（三）：深入理解容器镜像》](https://time.geekbang.org/column/article/17921)重点讲解过了。
|
|
|
|
|
|
而有了容器镜像之后，你需要按照Kubernetes项目的规范和要求，将你的镜像组织为它能够“认识”的方式，然后提交上去。
|
|
|
|
|
|
那么，什么才是Kubernetes项目能“认识”的方式呢？
|
|
|
|
|
|
这就是使用Kubernetes的必备技能：编写配置文件。
|
|
|
|
|
|
> 备注：这些配置文件可以是YAML或者JSON格式的。为方便阅读与理解，在后面的讲解中，我会统一使用YAML文件来指代它们。
|
|
|
|
|
|
Kubernetes跟Docker等很多项目最大的不同，就在于它不推荐你使用命令行的方式直接运行容器（虽然Kubernetes项目也支持这种方式，比如：kubectl run），而是希望你用YAML文件的方式，即：把容器的定义、参数、配置，统统记录在一个YAML文件中，然后用这样一句指令把它运行起来：
|
|
|
|
|
|
```
|
|
|
$ kubectl create -f 我的配置文件
|
|
|
|
|
|
```
|
|
|
|
|
|
这么做最直接的好处是，你会有一个文件能记录下Kubernetes到底“run”了什么。比如下面这个例子：
|
|
|
|
|
|
```
|
|
|
apiVersion: apps/v1
|
|
|
kind: Deployment
|
|
|
metadata:
|
|
|
name: nginx-deployment
|
|
|
spec:
|
|
|
selector:
|
|
|
matchLabels:
|
|
|
app: nginx
|
|
|
replicas: 2
|
|
|
template:
|
|
|
metadata:
|
|
|
labels:
|
|
|
app: nginx
|
|
|
spec:
|
|
|
containers:
|
|
|
- name: nginx
|
|
|
image: nginx:1.7.9
|
|
|
ports:
|
|
|
- containerPort: 80
|
|
|
|
|
|
```
|
|
|
|
|
|
像这样的一个YAML文件，对应到Kubernetes中，就是一个API Object（API对象）。当你为这个对象的各个字段填好值并提交给Kubernetes之后，Kubernetes就会负责创建出这些对象所定义的容器或者其他类型的API资源。
|
|
|
|
|
|
可以看到，这个YAML文件中的Kind字段，指定了这个API对象的类型（Type），是一个Deployment。
|
|
|
|
|
|
所谓Deployment，是一个定义多副本应用（即多个副本Pod）的对象，我在前面的文章中（也是第9篇文章《从容器到容器云：谈谈Kubernetes的本质》）曾经简单提到过它的用法。此外，Deployment还负责在Pod定义发生变化时，对每个副本进行滚动更新（Rolling Update）。
|
|
|
|
|
|
在上面这个YAML文件中，我给它定义的Pod副本个数(spec.replicas)是：2。
|
|
|
|
|
|
而这些Pod具体的又长什么样子呢？
|
|
|
|
|
|
为此，我定义了一个Pod模版（spec.template），这个模版描述了我想要创建的Pod的细节。在上面的例子里，这个Pod里只有一个容器，这个容器的镜像（spec.containers.image）是nginx:1.7.9，这个容器监听端口（containerPort）是80。
|
|
|
|
|
|
关于Pod的设计和用法我已经在第9篇文章[《从容器到容器云：谈谈Kubernetes的本质》](https://time.geekbang.org/column/article/23132)中简单的介绍过。而在这里，你需要记住这样一句话：
|
|
|
|
|
|
> Pod就是Kubernetes世界里的“应用”；而一个应用，可以由多个容器组成。
|
|
|
|
|
|
需要注意的是，像这样使用一种API对象（Deployment）管理另一种API对象（Pod）的方法，在Kubernetes中，叫作“控制器”模式（controller pattern）。在我们的例子中，Deployment扮演的正是Pod的控制器的角色。关于Pod和控制器模式的更多细节，我会在后续编排部分做进一步讲解。
|
|
|
|
|
|
你可能还注意到，这样的每一个API对象都有一个叫作Metadata的字段，这个字段就是API对象的“标识”，即元数据，它也是我们从Kubernetes里找到这个对象的主要依据。这其中最主要使用到的字段是Labels。
|
|
|
|
|
|
顾名思义，Labels就是一组key-value格式的标签。而像Deployment这样的控制器对象，就可以通过这个Labels字段从Kubernetes中过滤出它所关心的被控制对象。
|
|
|
|
|
|
比如，在上面这个YAML文件中，Deployment会把所有正在运行的、携带“app: nginx”标签的Pod识别为被管理的对象，并确保这些Pod的总数严格等于两个。
|
|
|
|
|
|
而这个过滤规则的定义，是在Deployment的“spec.selector.matchLabels”字段。我们一般称之为：Label Selector。
|
|
|
|
|
|
另外，在Metadata中，还有一个与Labels格式、层级完全相同的字段叫Annotations，它专门用来携带key-value格式的内部信息。所谓内部信息，指的是对这些信息感兴趣的，是Kubernetes组件本身，而不是用户。所以大多数Annotations，都是在Kubernetes运行过程中，被自动加在这个API对象上。
|
|
|
|
|
|
一个Kubernetes的API对象的定义，大多可以分为Metadata和Spec两个部分。前者存放的是这个对象的元数据，对所有API对象来说，这一部分的字段和格式基本上是一样的；而后者存放的，则是属于这个对象独有的定义，用来描述它所要表达的功能。
|
|
|
|
|
|
在了解了上述Kubernetes配置文件的基本知识之后，我们现在就可以把这个YAML文件“运行”起来。正如前所述，你可以使用kubectl create指令完成这个操作：
|
|
|
|
|
|
```
|
|
|
$ kubectl create -f nginx-deployment.yaml
|
|
|
|
|
|
```
|
|
|
|
|
|
然后，通过kubectl get命令检查这个YAML运行起来的状态是不是与我们预期的一致：
|
|
|
|
|
|
```
|
|
|
$ kubectl get pods -l app=nginx
|
|
|
NAME READY STATUS RESTARTS AGE
|
|
|
nginx-deployment-67594d6bf6-9gdvr 1/1 Running 0 10m
|
|
|
nginx-deployment-67594d6bf6-v6j7w 1/1 Running 0 10m
|
|
|
|
|
|
```
|
|
|
|
|
|
kubectl get指令的作用，就是从Kubernetes里面获取（GET）指定的API对象。可以看到，在这里我还加上了一个-l参数，即获取所有匹配app: nginx标签的Pod。需要注意的是，**在命令行中，所有key-value格式的参数，都使用“=”而非“:”表示。**
|
|
|
|
|
|
从这条指令返回的结果中，我们可以看到现在有两个Pod处于Running状态，也就意味着我们这个Deployment所管理的Pod都处于预期的状态。
|
|
|
|
|
|
此外， 你还可以使用kubectl describe命令，查看一个API对象的细节，比如：
|
|
|
|
|
|
```
|
|
|
$ kubectl describe pod nginx-deployment-67594d6bf6-9gdvr
|
|
|
Name: nginx-deployment-67594d6bf6-9gdvr
|
|
|
Namespace: default
|
|
|
Priority: 0
|
|
|
PriorityClassName: <none>
|
|
|
Node: node-1/10.168.0.3
|
|
|
Start Time: Thu, 16 Aug 2018 08:48:42 +0000
|
|
|
Labels: app=nginx
|
|
|
pod-template-hash=2315082692
|
|
|
Annotations: <none>
|
|
|
Status: Running
|
|
|
IP: 10.32.0.23
|
|
|
Controlled By: ReplicaSet/nginx-deployment-67594d6bf6
|
|
|
...
|
|
|
Events:
|
|
|
|
|
|
Type Reason Age From Message
|
|
|
|
|
|
---- ------ ---- ---- -------
|
|
|
|
|
|
Normal Scheduled 1m default-scheduler Successfully assigned default/nginx-deployment-67594d6bf6-9gdvr to node-1
|
|
|
Normal Pulling 25s kubelet, node-1 pulling image "nginx:1.7.9"
|
|
|
Normal Pulled 17s kubelet, node-1 Successfully pulled image "nginx:1.7.9"
|
|
|
Normal Created 17s kubelet, node-1 Created container
|
|
|
Normal Started 17s kubelet, node-1 Started container
|
|
|
|
|
|
```
|
|
|
|
|
|
在kubectl describe命令返回的结果中，你可以清楚地看到这个Pod的详细信息，比如它的IP地址等等。其中，有一个部分值得你特别关注，它就是**Events（事件）。**
|
|
|
|
|
|
在Kubernetes执行的过程中，对API对象的所有重要操作，都会被记录在这个对象的Events里，并且显示在kubectl describe指令返回的结果中。
|
|
|
|
|
|
比如，对于这个Pod，我们可以看到它被创建之后，被调度器调度（Successfully assigned）到了node-1，拉取了指定的镜像（pulling image），然后启动了Pod里定义的容器（Started container）。
|
|
|
|
|
|
所以，这个部分正是我们将来进行Debug的重要依据。**如果有异常发生，你一定要第一时间查看这些Events**，往往可以看到非常详细的错误信息。
|
|
|
|
|
|
接下来，如果我们要对这个Nginx服务进行升级，把它的镜像版本从1.7.9升级为1.8，要怎么做呢？
|
|
|
|
|
|
很简单，我们只要修改这个YAML文件即可。
|
|
|
|
|
|
```
|
|
|
...
|
|
|
spec:
|
|
|
containers:
|
|
|
- name: nginx
|
|
|
image: nginx:1.8 #这里被从1.7.9修改为1.8
|
|
|
ports:
|
|
|
- containerPort: 80
|
|
|
|
|
|
```
|
|
|
|
|
|
可是，这个修改目前只发生在本地，如何让这个更新在Kubernetes里也生效呢？
|
|
|
|
|
|
我们可以使用kubectl replace指令来完成这个更新：
|
|
|
|
|
|
```
|
|
|
$ kubectl replace -f nginx-deployment.yaml
|
|
|
|
|
|
```
|
|
|
|
|
|
不过，在本专栏里，我推荐你使用kubectl apply命令，来统一进行Kubernetes对象的创建和更新操作，具体做法如下所示：
|
|
|
|
|
|
```
|
|
|
$ kubectl apply -f nginx-deployment.yaml
|
|
|
|
|
|
# 修改nginx-deployment.yaml的内容
|
|
|
|
|
|
$ kubectl apply -f nginx-deployment.yaml
|
|
|
|
|
|
```
|
|
|
|
|
|
这样的操作方法，是Kubernetes“声明式API”所推荐的使用方法。也就是说，作为用户，你不必关心当前的操作是创建，还是更新，你执行的命令始终是kubectl apply，而Kubernetes则会根据YAML文件的内容变化，自动进行具体的处理。
|
|
|
|
|
|
而这个流程的好处是，它有助于帮助开发和运维人员，围绕着可以版本化管理的YAML文件，而不是“行踪不定”的命令行进行协作，从而大大降低开发人员和运维人员之间的沟通成本。
|
|
|
|
|
|
举个例子，一位开发人员开发好一个应用，制作好了容器镜像。那么他就可以在应用的发布目录里附带上一个Deployment的YAML文件。
|
|
|
|
|
|
而运维人员，拿到这个应用的发布目录后，就可以直接用这个YAML文件执行kubectl apply操作把它运行起来。
|
|
|
|
|
|
这时候，如果开发人员修改了应用，生成了新的发布内容，那么这个YAML文件，也就需要被修改，并且成为这次变更的一部分。
|
|
|
|
|
|
而接下来，运维人员可以使用git diff命令查看到这个YAML文件本身的变化，然后继续用kubectl apply命令更新这个应用。
|
|
|
|
|
|
所以说，如果通过容器镜像，我们能够保证应用本身在开发与部署环境里的一致性的话，那么现在，Kubernetes项目通过这些YAML文件，就保证了应用的“部署参数”在开发与部署环境中的一致性。
|
|
|
|
|
|
**而当应用本身发生变化时，开发人员和运维人员可以依靠容器镜像来进行同步；当应用部署参数发生变化时，这些YAML文件就是他们相互沟通和信任的媒介。**
|
|
|
|
|
|
以上，就是Kubernetes发布应用的最基本操作了。
|
|
|
|
|
|
接下来，我们再在这个Deployment中尝试声明一个Volume。
|
|
|
|
|
|
在Kubernetes中，Volume是属于Pod对象的一部分。所以，我们就需要修改这个YAML文件里的template.spec字段，如下所示：
|
|
|
|
|
|
```
|
|
|
apiVersion: apps/v1
|
|
|
kind: Deployment
|
|
|
metadata:
|
|
|
name: nginx-deployment
|
|
|
spec:
|
|
|
selector:
|
|
|
matchLabels:
|
|
|
app: nginx
|
|
|
replicas: 2
|
|
|
template:
|
|
|
metadata:
|
|
|
labels:
|
|
|
app: nginx
|
|
|
spec:
|
|
|
containers:
|
|
|
- name: nginx
|
|
|
image: nginx:1.8
|
|
|
ports:
|
|
|
- containerPort: 80
|
|
|
volumeMounts:
|
|
|
- mountPath: "/usr/share/nginx/html"
|
|
|
name: nginx-vol
|
|
|
volumes:
|
|
|
- name: nginx-vol
|
|
|
emptyDir: {}
|
|
|
|
|
|
```
|
|
|
|
|
|
可以看到，我们在Deployment的Pod模板部分添加了一个volumes字段，定义了这个Pod声明的所有Volume。它的名字叫作nginx-vol，类型是emptyDir。
|
|
|
|
|
|
那什么是emptyDir类型呢？
|
|
|
|
|
|
它其实就等同于我们之前讲过的Docker的隐式Volume参数，即：不显式声明宿主机目录的Volume。所以，Kubernetes也会在宿主机上创建一个临时目录，这个目录将来就会被绑定挂载到容器所声明的Volume目录上。
|
|
|
|
|
|
> 备注：不难看到，Kubernetes的emptyDir类型，只是把Kubernetes创建的临时目录作为Volume的宿主机目录，交给了Docker。这么做的原因，是Kubernetes不想依赖Docker自己创建的那个\_data目录。
|
|
|
|
|
|
而Pod中的容器，使用的是volumeMounts字段来声明自己要挂载哪个Volume，并通过mountPath字段来定义容器内的Volume目录，比如：/usr/share/nginx/html。
|
|
|
|
|
|
当然，Kubernetes也提供了显式的Volume定义，它叫作hostPath。比如下面的这个YAML文件：
|
|
|
|
|
|
```
|
|
|
...
|
|
|
volumes:
|
|
|
- name: nginx-vol
|
|
|
hostPath:
|
|
|
path: " /var/data"
|
|
|
|
|
|
```
|
|
|
|
|
|
这样，容器Volume挂载的宿主机目录，就变成了/var/data。
|
|
|
|
|
|
在上述修改完成后，我们还是使用kubectl apply指令，更新这个Deployment:
|
|
|
|
|
|
```
|
|
|
$ kubectl apply -f nginx-deployment.yaml
|
|
|
|
|
|
```
|
|
|
|
|
|
接下来，你可以通过kubectl get指令，查看两个Pod被逐一更新的过程：
|
|
|
|
|
|
```
|
|
|
$ kubectl get pods
|
|
|
NAME READY STATUS RESTARTS AGE
|
|
|
nginx-deployment-5c678cfb6d-v5dlh 0/1 ContainerCreating 0 4s
|
|
|
nginx-deployment-67594d6bf6-9gdvr 1/1 Running 0 10m
|
|
|
nginx-deployment-67594d6bf6-v6j7w 1/1 Running 0 10m
|
|
|
$ kubectl get pods
|
|
|
NAME READY STATUS RESTARTS AGE
|
|
|
nginx-deployment-5c678cfb6d-lg9lw 1/1 Running 0 8s
|
|
|
nginx-deployment-5c678cfb6d-v5dlh 1/1 Running 0 19s
|
|
|
|
|
|
```
|
|
|
|
|
|
从返回结果中，我们可以看到，新旧两个Pod，被交替创建、删除，最后剩下的就是新版本的Pod。这个滚动更新的过程，我也会在后续进行详细的讲解。
|
|
|
|
|
|
然后，你可以使用kubectl describe查看一下最新的Pod，就会发现Volume的信息已经出现在了Container描述部分：
|
|
|
|
|
|
```
|
|
|
...
|
|
|
Containers:
|
|
|
nginx:
|
|
|
Container ID: docker://07b4f89248791c2aa47787e3da3cc94b48576cd173018356a6ec8db2b6041343
|
|
|
Image: nginx:1.8
|
|
|
...
|
|
|
Environment: <none>
|
|
|
Mounts:
|
|
|
/usr/share/nginx/html from nginx-vol (rw)
|
|
|
...
|
|
|
Volumes:
|
|
|
nginx-vol:
|
|
|
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
|
|
|
|
|
|
```
|
|
|
|
|
|
> 备注：作为一个完整的容器化平台项目，Kubernetes为我们提供的Volume类型远远不止这些，在容器存储章节里，我将会为你详细介绍这部分内容。
|
|
|
|
|
|
最后，你还可以使用kubectl exec指令，进入到这个Pod当中（即容器的Namespace中）查看这个Volume目录：
|
|
|
|
|
|
```
|
|
|
$ kubectl exec -it nginx-deployment-5c678cfb6d-lg9lw -- /bin/bash
|
|
|
# ls /usr/share/nginx/html
|
|
|
|
|
|
```
|
|
|
|
|
|
此外，你想要从Kubernetes集群中删除这个Nginx Deployment的话，直接执行：
|
|
|
|
|
|
```
|
|
|
$ kubectl delete -f nginx-deployment.yaml
|
|
|
|
|
|
```
|
|
|
|
|
|
就可以了。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
在今天的分享中，我通过一个小案例，和你近距离体验了Kubernetes的使用方法。
|
|
|
|
|
|
可以看到，Kubernetes推荐的使用方式，是用一个YAML文件来描述你所要部署的API对象。然后，统一使用kubectl apply命令完成对这个对象的创建和更新操作。
|
|
|
|
|
|
而Kubernetes里“最小”的API对象是Pod。Pod可以等价为一个应用，所以，Pod可以由多个紧密协作的容器组成。
|
|
|
|
|
|
在Kubernetes中，我们经常会看到它通过一种API对象来管理另一种API对象，比如Deployment和Pod之间的关系；而由于Pod是“最小”的对象，所以它往往都是被其他对象控制的。这种组合方式，正是Kubernetes进行容器编排的重要模式。
|
|
|
|
|
|
而像这样的Kubernetes API对象，往往由Metadata和Spec两部分组成，其中Metadata里的Labels字段是Kubernetes过滤对象的主要手段。
|
|
|
|
|
|
在这些字段里面，容器想要使用的数据卷，也就是Volume，正是Pod的Spec字段的一部分。而Pod里的每个容器，则需要显式的声明自己要挂载哪个Volume。
|
|
|
|
|
|
上面这些基于YAML文件的容器管理方式，跟Docker、Mesos的使用习惯都是不一样的，而从docker run这样的命令行操作，向kubectl apply YAML文件这样的声明式API的转变，是每一个容器技术学习者，必须要跨过的第一道门槛。
|
|
|
|
|
|
所以，如果你想要快速熟悉Kubernetes，请按照下面的流程进行练习：
|
|
|
|
|
|
* 首先，在本地通过Docker测试代码，制作镜像；
|
|
|
* 然后，选择合适的Kubernetes API对象，编写对应YAML文件（比如，Pod，Deployment）；
|
|
|
* 最后，在Kubernetes上部署这个YAML文件。
|
|
|
|
|
|
更重要的是，在部署到Kubernetes之后，接下来的所有操作，要么通过kubectl来执行，要么通过修改YAML文件来实现，**就尽量不要再碰Docker的命令行了**。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
在实际使用Kubernetes的过程中，相比于编写一个单独的Pod的YAML文件，我一定会推荐你使用一个replicas=1的Deployment。请问，这两者有什么区别呢？
|
|
|
|
|
|
感谢你的收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。
|
|
|
|