管理Pod(rc,rs,deployment)

1.概述

  可以把容器想像成豆荚里的豆子,把一个或多个关系紧密的豆子包在一起就是豆荚(一个Pod)。在k8s中我们不会直接操作容器,而是把容器包装成Pod再进行管理.

2.管理Pod

a. 使用Replication Controller 来部署、升级Pod
b. Replica Set – 下一代Replication Controller
c. Deployment – 更加方便的管理Pod和Replica Set

  例子1: 提出疑惑

先举个例子,假设我们有一个Pod在提供线上服务,现在有如下几个场景,大家想想如何应对:

1.节日活动,网站访问量突增
2.遭到攻击,网站访问量突增
3.运行Pod的节点发生故障


第1种情况,活动前预先多启动几个Pod,活动结束后再结束掉多余的,虽然要启动和结束的Pod有点多,但也能有条不紊按计划进行
第2种情况,正在睡觉突然手机响了说网站反应特慢卡得要死,赶紧爬起来边扩容边查找攻击模式、封IP等等……
第3种情况,正在休假突然手机又响了说网站上不去,赶紧打开电脑查看原因,启动新的Pod

  解决办法:引入rc

Pod需要手动管理,好累……能否在Pod发生问题时自动恢复呢,我们先来看下Replication Controller(以下简称RC)

先说RC是什么。RC保证在同一时间能够运行指定数量的Pod副本,保证Pod总是可用。如果实际Pod数量比指定的多就结束掉多余的,如果实际数量比指定的少就启动缺少的。
当Pod失败、被删除或被终结时RC会自动创建新的Pod来保证副本数量。所以即使只有一个Pod也应该使用RC来进行管理。

  管理Pod(rc,rs,deployment)

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


管理Pod(rc,rs,deployment)

 

  解决办法:引入rs,官方推荐使用RS代替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。


管理Pod(rc,rs,deployment)

上一篇:制作MySQL RPM安装包Spec


下一篇:2、词法分析--4、字面值--3、格式化字符串