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
clipboard.png

这个文件定义了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:
clipboard.png

查看结果可以看到当前RC的状态:指定了需要3个Pod、当前实际有3个Pod、3个Pod都在运行中(图片较大只截取部分):
clipboard.png

如果使用的镜像较大查看状态可能是Waiting,这是因为正在下载镜像,等待一段时间就好。
clipboard.png

上面说过RC会自动管理Pod保证指定数量副本运行,我们来实验一下,看下图:
clipboard.png
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直接修改)
执行结果看下图:
clipboard.png

当我们有新功能发布或修复BUG时使用滚动升级是不错的选择,可以使用工具kubectl rolling-update完成这个任务。对照下图我们来看下是如何进行的
使用命令kubectl rolling-update hello-rc –image=index.tenxcloud.com/tailnode/hello:v2.0
clipboard.png
在另一个窗口查看RC
clipboard.png

对照两张截图,我们能够看出升级步骤如下:

  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副本运行
clipboard.png
点击弹性伸缩,修改数量为3,同时使用下面的命令测试,从输出结果可以看出提供服务的Pod数量变成了3个:
clipboard.png

下面再来测试下灰度升级功能,修改目标版本为v2.0(之前是v1.0,为了便于查看效果新建有2个Pod的服务),然后查看Pod变化
第一个新Pod hello-v2.0-ywcc2已经启动
clipboard.png
第二个新Pod hello-v2.0-whtvh正在启动
clipboard.png
最后一个旧Pod hello-41ee8正在停止
clipboard.png
升级完成,只有两个新Pod提供服务
图片描述
同时使用命令查看服务的响应如下:
clipboard.png

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版),所以不再详细解释各字段意思
clipboard.png
与创建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:
clipboard.png

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

上面提到过kubectl rolling-update升级成功后不能直接回滚,不是很方便,那使用Deployment可以吗,答案是肯定的。
首先在上面的命令加上–revision参数,查看改动详细信息如下:
clipboard.png
然后使用kubctl rollout undo deployment hello-deployment回滚至前一版本(使用--to-revision参数指定版本)即可。

命令kubectl describe deployment hello-deployment查看详细信息,在Message一列看到回滚如下,详细的信息记录对于问题发生后的原因查找有很大帮助:
clipboard.png

通过对比RC、Replica Set与Deployment,可以看出新的Replica Set与Deployment比RC要强大易用很多,但因为现在还是beta版本所以不建议在生产环境使用,不过相信不久的将来我们就能使用上。


1.2k 声望
33 粉丝
0 条评论
推荐阅读
Google API 设计指南-词汇表
翻译自 API Design Guide - Glossary 网络 API(Networked APIs) 通过计算机网络中运行的应用程序接口。它们使用包括 HTTP 在内的网络协议进行通信,并且生产和消费 API 的往往是不同的组织。 Google API Google...

tailnode1阅读 2.2k

Helm3-安装RabbitMQ
最近在使用k8s搭建微服务时,发现需要手动修改yaml文件里面的pod name、pod image、svc name、ingress tls等等,非常麻烦,但是有了helm之后情况就不一样了,helm是k8s的包管理器,类似ubuntu的apt-get,centos的...

Awbeci阅读 9.6k

Kubernetes Gateway API 深入解读和落地指南
Kubernetes Gateway API 是 Kubernetes 1.18 版本引入的一种新的 API 规范,是 Kubernetes 官方正在开发的新的 API,Ingress 是 Kubernetes 已有的 API。Gateway API 会成为 Ingress 的下一代替代方案。Gateway A...

Rainbond2阅读 456

Jvm调优与微服务资源分配
在没有接触微服务之前,我们的java程序一般都部署在WebLogic、Tomcat这类应用服务器上,这些应用服务器本身也是基于Jvm虚拟机的。一般我们统一对应用服务器做Jvm参数调优(分配多大内存,线程池限制等),而不用...

KerryWu阅读 6.1k

K8S-使用Helm安装RabbitMQ和Redis的总结
记得去年2021上半年的时候自学了k8s并且使用helm安装了rabbitmq和redis,可以在开发、测试和生产环境上用起来,但是下半年之后就没有用,再拾起来的时候发现好多知识点都忘了,这篇文章就是总结使用helm安装rabbm...

Awbeci1阅读 1.9k

Kubernetes v1.27 新特性一览
Kubernetes v1.27 是 2023 年的第一个大版本更新,包含了近 60 项主要的更新。 而 1.26 只有 37 项,所以这个版本可以说是一个变化非常显著的版本了。

张晋涛1阅读 1.1k

封面图
实战:用“廉价”的NFS作为K8S后端存储
大家都知道,NFS是一种基于网络的文件系统协议,允许在不同的机器之间共享文件系统资源。在K8S中,可以使用NFS作为后端存储,以提供持久化存储和共享存储卷。但是否适合在生产环境使用NFS作为后端存储,这取决于...

不背锅运维2阅读 770

1.2k 声望
33 粉丝
宣传栏