Kubernetes入门系列之如何使用ReplicationController、ReplicaSet、Deployment管理Pod

Pod直译是豆荚，我们可以把容器想像成豆荚里的豆子，把一个或多个关系紧密的豆子包在一起就是豆荚（一个Pod）。在k8s中我们不会直接操作容器，而是把容器包装成Pod，而对于Pod，我们该如何管理？先看下面这个场景：

1. 应用场景
假设有一个Pod正在提供线上服务，我们想想如何应对以下几个场景：

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

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

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

因此，我们需要一种方式，来自动管理Pod的伸缩。本文将介绍如何利用ReplicationController、Replica Set、Deploymen来管理Pod，分为以下三部分：

使用ReplicationController来部署、升级Pod
Replica Set—下一代的ReplicationController
Deployment — 更加方便的管理Pod和Replica Set

2. 使用ReplicationController（RC）部署，升级Pod
RC保证在同一时间能够运行指定数量的Pod副本，保证Pod总是可用。如果实际Pod数量比指定的多就结束掉多余的，如果实际数量比指定的少就启动缺少的。当Pod失败、被删除或被终结时，RC会自动创建新的Pod来保证副本数量，所以即使只有一个Pod，也应该使用RC来进行管理。我们先看以下这个rc.yaml文件

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend
  labels:
    name: frontend
spec:
  replicas: 3
  selector:
    name: frontend
  template:
    metadata:
     labels:
       name: frontend
    spec:
     containers:
     - name: frontend
       image: kubeguide/guestbook-php-frontend:latest
       env :
       - name : GET_HOSTS_FROM
         value : env
       ports:
       - containerPort: 80

yaml字段的含义：
spec.replicas：副本数量3
spec.selector：RC通过spec.selector来筛选要控制的Pod
spec.template：这里写Pod的定义（但不需要apiVersion和kind）
spec.template.metadata.labels：Pod的label，可以看到这个label与spec.selector相同

这个文件的意思：
定义一个RC对象，它的名字是frontend（metadata.name:frontend），保证有3个Pod运行（spec.replicas:3），Pod的镜像是kubeguide/guestbook-php-frontend:latest（spec.template.spec.containers.image:kubeguide/guestbook-php-frontend:latest）

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

接着我们来看RC的常用操作命令：

通过kubectl创建RC

kubectl create -f rc.yaml

查看RC具体信息

kubectl describe rc frontend

通过RC修改Pod副本数量（需要修改yaml文件的spec.replicas字段到目标值，然后替换旧的yaml文件）

kubectl replace -f rc.yaml

或

kubect edit replicationcontroller frontend

对RC使用滚动升级，来发布新功能或修复BUG

kubectl rolling-update frontend --image=kubeguide/guestbook-php-frontend:latest

当Pod中只有一个容器时，通过–image参数指定新的Tag完成滚动升级，但如果有多个容器或其他字段修改时，需要指定yaml文件

kubectl rolling-update frontend -f FILE.yaml

如果在升级过程中出现问题（如发现配置错误、长时间无响应），可以使用CTRL+C退出，再进行回滚

kubectl rolling-update frontend --image=kubeguide/guestbook-php-frontend:latest --rollback

但如果升级完成后出现问题（比如新版本程序出core），此命令就无能为力了。我们需要使用同样方法，利用原来的镜像，“升级”为旧版本。

3. Deployment—更加方便的管理Pod和Replica Set
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。

使用子命令create，创建Deployment

kubectl create -f deployment.yaml --record

注意–record参数，使用此参数将记录后续创建对象的操作，方便管理与问题追溯

使用子命令edit，编辑spec.replicas/spec.template.spec.container.image字段，完成deployment的扩缩容与滚动升级（这要比子命令rolling-update速度快很多）

kubectl edit deployment hello-deployment

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

kubectl rollout history deployment hello-deployment

上面提到RC在rolling-update升级成功后不能直接回滚，而使用Deployment却可以回滚到上一版本，但要加上–revision参数，指定版本号

kubectl rollout history deployment hello-deployment --revision=2

使用rollout undo回滚到上一版本

kubectl rollout undo deployment hello-deployment 

使用–to-revision可以回滚到指定版本

kubectl rollout undo deployment hello-deployment --to-revision=2

原文地址：https://blog.csdn.net/yjk13703623757/article/details/53746273

转载请注明：西数超哥博客www.ysidc.top» Kubernetes入门系列之如何使用ReplicationController、ReplicaSet、Deployment管理Pod

https://www.ysidc.top 西数超哥博客,数据库,西数超哥,虚拟主机,域名注册,域名,云服务器,云主机,云建站,ysidc.top