摘要：是运行服务的基础，那我们如何来管理呢，下面我们就来聊一聊。所以即使只有一个也应该使用来进行管理。现在回到最开始的问题，如何通过修改副本数量。
这是在微信群分享的文章，也贴在这里。
在本次分享开始前，让我们先回想下Pod。Pod直译是豆荚，可以把容器想像成豆荚里的豆子，把一个或多个关系紧密的豆子包在一起就是豆荚（一个Pod）。在k8s中我们不会直接操作容器，而是把容器包装成Pod再进行管理（关于Pod，大家可以参考第十期的分享“谈谈Pod在微服务中的运用”）。Pod是运行服务的基础，那我们如何来管理Pod呢，下面我们就来聊一聊。分为这三个部分：
使用Replication Controller 来部署、升级Pod
Replica Set – 下一代Replication Controller
Deployment – 更加方便的管理Pod和Replica Set
先举个例子,假设我们有一个Pod在提供线上服务，现在有如下几个场景，大家想想如何应对：
节日活动，网站访问量突增
遭到攻击，网站访问量突增
运行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
对照两张截图，我们能够看出升级步骤如下：
创建一个使用新版本Pod的RC，hello-rc-4f7ed44b6db1e20aa1bc681c81d63caf
依次增加新RC的副本数量、减少旧RC的副本数量
当升级成功后，删除旧RC
重命名新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。
那么它们优势在哪里，我们来看一看：
RC只支持基于等式的selector（env=dev或environment!=qa）但Replica Set还支持新的基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)），这对复杂的运维管理带来很大方便
使用Deployment升级Pod只需要定义Pod的最终状态，k8s会为你执行必要的操作，虽然能够使用命令kubectl rolling-update完成升级，但它是在客户端与服务端多次交互控制RC完成的，所以REST API中并没有rolling-update的接口，这为定制自己的管理系统带来了一些麻烦。
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版本所以不建议在生产环境使用，不过相信不久的将来我们就能使用上。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/33023.html
摘要：本文整理自时速云线上微信群分享第十二期在本次分享开始前，让我们先回想下。但目前时速云平台还不支持这种。问时速云是怎么保持的高可用的答高可用目前是官方推荐的多方式，以及我们自己的监管方式。 本文整理自【时速云线上微信群分享】第十二期 在本次分享开始前，让我们先回想下Pod。Pod直译是豆荚，可以把容器想像成豆荚里的豆子，把一个或多个关系紧密的豆子包在一起就是豆荚（一个Pod）。在k8s中...
摘要：又因为是谷歌出品的，依赖了很多谷歌自己的镜像，所以对于国内的同学环境搭建的难度又增加了一层。 带着问题学 Kubernetes 架构 摘要：本文属于原创，欢迎转载，转载请保留出处：https://github.com/jasonGeng88/blog 打开这篇文章的同学，想必对 docker 都不会陌生。docker 是一种虚拟容器技术，它上手比较简单，只需在宿主机上起一个 docke...
摘要：又因为是谷歌出品的，依赖了很多谷歌自己的镜像，所以对于国内的同学环境搭建的难度又增加了一层。 带着问题学 Kubernetes 架构 摘要：本文属于原创，欢迎转载，转载请保留出处：https://github.com/jasonGeng88/blog 打开这篇文章的同学，想必对 docker 都不会陌生。docker 是一种虚拟容器技术，它上手比较简单，只需在宿主机上起一个 docke...
摘要：本期主题有状态集群服务部署与管理嘉宾介绍张寿红，从事软件研发工作十余年，目前从事基于和的企业级容器云平台研发工作，主要包括容器服务存储服务和镜像服务等。为此开发了一套以为核心的全新特性，方便了有状态集群服务在上的部署和管理。 极牛技术分享活动 极牛技术实践分享系列活动是极牛联合顶级VC、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。 每期不同的技术主题，和行业专家深度探讨，...
摘要：简称，是在年发布的一个开源项目。网络要能够通信，必须部署网络，是其中一个可选方案。最常使用，可以管理多个副本，并确保按照期望的状态运行，底层调用。用于每个最多只运行一个副本的场景。 Kubernetes 简称 k8s，是 google 在 2014 年发布的一个开源项目。 Kubernetes 解决了哪些问题？ 真实的生产环境应用会包含多个容器，而这些容器还很可能会跨越多个服务器主机部...
摘要：有状态集群服务，与普通有状态服务相比，它多了集群管理的需求。为此开发了一套以为核心的全新特性，方便了有状态集群服务在上的部署和管理。 2016年12月2日，时速云架构师张寿红应邀参加ArchSummit2016全球架构师峰会，并在微服务与容器实践专场做了《Kubernetes有状态集群服务部署与管理》的干货分享。 showImg(https://segmentfault.com/img...
阅读 779·2021-11-22 12:09
阅读 3576·2021-09-27 13:36
阅读 1253·2021-08-20 09:37
阅读 3662·2019-12-27 12:22
阅读 2159·2019-08-30 15:55
阅读 2195·2019-08-30 13:16
阅读 2891·2019-08-27 14:19
阅读 2680·2019-08-26 17:06
