k8s如何管理Pod

本文整理自【时速云线上微信群分享】第十二期

在本次分享开始前，让咱们先回想下Pod。Pod直译是豆荚，能够把容器想像成豆荚里的豆子，把一个或多个关系紧密的豆子包在一块儿就是豆荚（一个Pod）。在k8s中咱们不会直接操做容器，而是把容器包装成Pod再进行管理（关于Pod，你们能够参考第二期的分享“谈谈Pod在微服务中的运用”）。Pod是运行服务的基础，那咱们如何来管理Pod呢，下面咱们就来聊一聊。分为这三个部分：

1. 使用Replication Controller 来部署、升级Pod

2. Replica Set – 下一代Replication Controller

3. Deployment – 更加方便的管理Pod和Replica Set

先举个例子

假设咱们有一个Pod在提供线上服务，如今有以下几个场景，你们想一想如何应对：

1. 节日活动，网站访问量突增

2. 遭到攻击，网站访问量突增

3. 运行Pod的节点发生故障

第1种状况， 活动前预先多启动几个Pod，活动结束后再结束掉多余的，虽然要启动和结束的Pod有点多，但也能有条不紊按计划进行

第2种状况， 正在睡觉忽然手机响了说网站反应特慢卡得要死，赶忙爬起来边扩容边查找攻击模式、封IP等等……

第3种状况， 正在休假忽然手机又响了说网站上不去，赶忙打开电脑查看缘由，启动
新的Pod

Pod须要手动管理，好累……

可否在Pod发生问题时自动恢复呢，咱们先来看下Replication Controller（如下简称RC）

先说RC 是什么。RC保证在同一时间可以运行指定数量的Pod副本，保证Pod老是可用。若是实际Pod数量比指定的多就结束掉多余的，若是实际数量比指定的少就启动缺乏的。当Pod失败、被删除或被终结时RC会自动建立新的Pod来保证副本数量。

因此即便只有一个Pod也应该使用RC来进行管理。

接下来咱们看下如何建立RC，看这个定义文件rc.yaml

这个文件定义了RC的属性，咱们先关注以下字段：

spec.replicas：副本数量3

spec.selector：RC经过spec.selector来筛选要控制的Pod

spec.template：这里写Pod的定义（但不须要apiVersion和kind）

spec.template.metadata.labels：Pod的label，能够看到这个label与spec.selector相同

这个文件的意思是定义了一个RC对象，它的名字是hello-rc（metadata.name:hello-rc），保证有3个Pod运行（spec.replicas:3），Pod的镜像是index.tenxcloud.com/tailnode/hello:v1.0（spec.template.spec.containers.image: index.tenxcloud.com/tailnode/hello:v1.0）

关键在于spec.selector与spec.template.metadata.labels，这两个字段必须相同，不然下一步建立RC会失败。（也能够不写spec.selector，这样默认与spec.template.metadata.labels相同）

如今经过kubectl来建立RC：

查看结果能够看到当前RC的状态：指定了须要3个Pod、当前实际有3个Pod、3个Pod都在运行中（图片较大只截取部分）：

若是使用的镜像较大查看状态多是Waiting，这是由于正在下载镜像，等待一段时间就好。

上面说过RC会自动管理Pod保证指定数量副本运行，咱们来实验一下，看下图：

1.查看当前Pod，（注意NAME和AGE列）

2.删除hello-rc-5crgq

3.再次查看Pod，发现新的Pod启动了（注意NAME和AGE列）

到这里咱们对RC有了基本的认识，并进行了简单的使用。

如今回到最开始的问题，如何经过RC修改Pod副本数量。其实很是简单，只须要修改yaml文件spec.replicas字段成想要的值，而后执行kubectl replace命令（或者使用kubect edit replicationcontroller hello-rc直接修改）.

执行结果看下图：

当咱们有新功能发布或修复BUG时使用滚动升级是不错的选择，可使用工具kubectl rolling-update完成这个任务。对照下图咱们来看下是如何进行的

使用命令kubectl rolling-update hello-rc –image=index.tenxcloud.com/tailnode/hello:v2.0

在另外一个窗口查看RC

对照两张截图，咱们可以看出升级步骤以下：

1.建立一个使用新版本Pod的RC，hello-rc-4f7ed44b6db1e20aa1bc681c81d63caf

2.依次增长新RC的副本数量、减小旧RC的副本数量

3.当升级成功后，删除旧RC

4.重命名新RC为hello-rc

当Pod中只有一个容器时经过–image参数指定新的Tag，若是有多个容器或其余字段的修改时，须要使用kubectl rolling-update NAME -f FILE指定文件

若是在升级过程当中出现问题（好比长时间无响应），能够CTRL+C结束再使用kubectl rolling-update hello-rc –rollback进行回滚，但若是升级完成后出现问题（好比新版本程序出core），此命令无能为力，须要使用一样方法“升级”为旧版本

在时速云平台咱们可以很是方便的使用弹性伸缩功能来调整Pod副本数量，仍是举例说明：

启动一个可以输出Pod主机名和版本号的服务，看下图当前只有一个Pod副本运行

点击弹性伸缩，修改数量为3，同时使用下面的命令测试，从输出结果能够看出提供服务的Pod数量变成了3个：

下面再来测试下灰度升级功能，修改目标版本为v2.0（以前是v1.0，为了便于查看效果新建有2个Pod的服务），而后查看Pod变化

第一个新Pod hello-v2.0-ywcc2已经启动

第二个新Pod hello-v2.0-whtvh正在启动

最后一个旧Pod hello-41ee8正在中止

升级完成，只有两个新Pod提供服务

同时使用命令查看服务的响应以下：

k8s是一个高速发展的项目，在新的版本中官方推荐使用Replica Set和Deployment来代替RC。

那么它们优点在哪里，咱们来看一看：

1. RC只支持基于等式的selector（env=dev或environment!=qa）但Replica Set还支持新的基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)），这对复杂的运维管理带来很大方便

2. 使用Deployment升级Pod只须要定义Pod的最终状态，k8s会为你执行必要的操做，虽然可以使用命令kubectl rolling-update完成升级，但它是在客户端与服务端屡次交互控制RC完成的，因此REST API中并无rolling-update的接口，这为定制本身的管理系统带来了一些麻烦。

3. Deployment拥有更加灵活强大的升级、回滚功能

Replica Set目前与RC的区别只是支持的selector不一样，后续确定会加入更多功能。Deployment使用了Replica Set，是更高一层的概念。除非须要自定义升级功能或根本不须要升级Pod，因此推荐使用Deployment而不直接使用Replica Set。

下面咱们继续来看Deployment的定义文件，与RC的定义文件基本相同（注意apiVersion仍是beta版），因此再也不详细解释各字段意思

与建立RC相同，使用命令kubectl create -f deployment.yaml –record建立Deployment，注意–record参数，使用此参数将记录后续对建立的对象的操做，方便管理与问题追溯

使用kubectl edit deployment hello-deployment修改spec.replicas/spec.template.spec.container.image字段来完成扩容缩容与滚动升级（比kubectl rolling-update速度快不少）

修改image字段为新版本镜像后查看Pod，在STATUS列看到正在执行升级的Pod：

使用kubectl rollout history命令查看Deployment的历史信息

上面提到过kubectl rolling-update升级成功后不能直接回滚，不是很方便，那使用Deployment能够吗，答案是确定的。

首先在上面的命令加上–revision参数，查看改动详细信息以下：

而后使用kubctl rollout undo deployment hello-deployment回滚至前一版本（使用–to-revision参数指定版本）便可。

命令kubectl describe deployment hello-deployment查看详细信息，在Message一列看到回滚以下，详细的信息记录对于问题发生后的缘由查找有很大帮助：

经过对比RC、Replica Set与Deployment，能够看出新的Replica Set与Deployment比RC要强大易用不少，但由于如今仍是beta版本因此不建议在生产环境使用，不过相信不久的未来咱们就能使用上。

Q&A

1. 问：灰度发布， 能够指定新旧版共存么， 怎么整？
   答：能够像上面说的那样，使用命令行工具建立新旧两个RC，而后分别指定须要的Pod数量。但目前时速云平台还不支持这种。

2. 问：时速云是怎么保持k8s master的高可用的？
   答：高可用目前是官方推荐的多master standby方式，以及咱们本身的agent监管方式。

3. 问：Pod 之间通讯是否是也是用的flannel？
   答：pod和pod之间，能够采用官方推荐的各类网络解决方案，目前咱们主要关注 flannel(vxlan）和 Calico

4. 问：flannel以及calico，大家选其一仍是两个方案都在用？有测试报告吗？
   答：两个方案都在用，测试报告之前分享过几种方案的网络性能比较，这里有一个Calico的，能够参考：https://www.projectcalico.org/ ... ance/

5. 问：Replica Set 这个有demo的例子么？
   答：由于通常Replica Set不会直接使用，而是经过Deployment来控制它，因此本次没有写出Replica Set的demo

6. 问：Deployment如今是没有rest api修改Pod数量么？
   答：有的，PUT /apis/extensions/v1beta1/namespaces/{namespace}/deployments/{name}

7. 问：因为k8s严重依赖etcd中的数据，一旦etcd的数据紊乱，可能形成业务故障。这个问题在大量业务接入的时候可能有概率出现，时速云有解决方案吗？
   答：这个问题，目前尚未碰到，不过咱们会将服务信息同时存放到另外的存储中，也会对etcd进行备份，这样在出现故障时也能够很容易恢复或者迁移整个集群。

8. 问：时速云用的是原生k8s吗，都作了哪些优化？
   答：优化是有一些的，包括部署方式、网络、存储、以及一些用户体验上的优化为主，以便充分发挥 k8s 的一些优点。

9. 问：Docker 1.12版本开始集成了Swarm到Docker Engine中，Swarm功能也变得愈来愈强大，那么时速云怎么看这个问题？之后考不考虑用高版本Docker，用k8s管理集成Swarm的Docker，会不会性能浪费？
   答：咱们目前主要关注swarm，swarmkit这些docker原生的工具，会去了解他们的主要特性，能够看到swarmkit正在向 k8s 方向迈进。

10. 问：再问个问题，有状态服务的pod，挂载个数据卷（好比rbd）。用rc或者deployment管理的pod重启或者升级之后，数据卷从新挂载到新的pod上会有什么问题么？
    答：没有遇到过问题，理论上也不该该会有问题的。

11. 问：能不能介绍一下怎么作用户隔离的，公有云的话，安全对你们很重要
    答：能够参考 Calico 的网络隔离和 k8s 的服务、api访问控制，以及一些用户角色上的设计，k8s在安全上仍是考虑了很多东西的。

12. 问：容器飘移和虚拟机飘移同样吗？
    答：仍是不太同样的，虚拟机能够支持热迁移，目前容器还不行。

如何参与线上分享？

添加微信号：时速云小助手(tenxcloud6)，咱们便可拉您进群