Kubernetes如何使用ReplicationController、Replica Set、Deployment管理Pod
https://blog.csdn.net/yjk13703623757/article/details/53746273https://www.cnblogs.com/ilinuxer/p/6637214.html(部署)使用kubernetes的deployment进行RollingUpdaterolling update，可以使得服务近乎无缝地平滑升级，即在不停止对外服务的前提下...
https://blog.csdn.net/yjk13703623757/article/details/53746273
https://www.cnblogs.com/ilinuxer/p/6637214.html
(部署)使用kubernetes的deployment进行RollingUpdate
rolling update，可以使得服务近乎无缝地平滑升级，即在不停止对外服务的前提下完成应用的更新。
replication controller与deployment的区别
replication controller
Replication Controller为Kubernetes的一个核心内容，应用托管到Kubernetes之后，需要保证应用能够持续的运行，Replication Controller就是这个保证的key，主要的功能如下：
-
确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod，Replication Controller会创建新的，反之则会删除掉多余的以保证Pod数量不变。
-
确保pod健康：当pod不健康，运行出错或者无法提供服务时，Replication Controller也会杀死不健康的pod，重新创建新的。
-
弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况，做到自动伸缩。
-
滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。
Deployment
Deployment同样为Kubernetes的一个核心内容，主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：
-
Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。
-
事件和状态查看：可以查看Deployment的升级详细进度和状态。
-
回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
-
版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。
-
暂停和启动：对于每一次升级，都能够随时暂停和启动。
-
多种升级方案：Recreate：删除所有已存在的pod,重新创建新的; RollingUpdate：滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。
deployment的常用命令
查看部署状态
kubectl rollout status deployment/review-demo --namespace=scm
kubectl describe deployment/review-demo --namespace=scm或者这种写法
kubectl rollout status deployments review-demo --namespace=scm
kubectl describe deployments review-demo --namespace=scm升级
kubectl set image deployment/review-demo review-demo=library/review-demo:0.0.1 --namespace=scm或者
kubectl edit deployment/review-demo --namespace=scm编辑.spec.template.spec.containers[0].image的值
终止升级
kubectl rollout pause deployment/review-demo --namespace=scm继续升级
kubectl rollout resume deployment/review-demo --namespace=scm回滚
kubectl rollout undo deployment/review-demo --namespace=scm查看deployments版本
kubectl rollout history deployments --namespace=scm回滚到指定版本
kubectl rollout undo deployment/review-demo --to-revision=2 --namespace=scm升级历史
kubectl describe deployment/review-demo --namespace=scm
Name: review-demo
Namespace: scm
CreationTimestamp: Tue, 31 Jan 2017 16:42:01 +0800
Labels: app=review-demo
Selector: app=review-demo
Replicas: 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: review-demo-2741031620 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 1
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 2
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 2
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 1
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 3
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 0deployment文件
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: review-demo
namespace: scm
labels:
app: review-demo
spec:
replicas: 3
# minReadySeconds: 60 #滚动升级时60s后认为该pod就绪
strategy:
rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间
maxSurge: 1 #滚动升级时会先启动1个pod
maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
template:
metadata:
labels:
app: review-demo
spec:
terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号，可以用来正确、优雅地关闭应用,默认为30秒
containers:
- name: review-demo
image: library/review-demo:0.0.1-SNAPSHOT
imagePullPolicy: IfNotPresent
livenessProbe: #kubernetes认为该pod是存活的,不存活则需要重启
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 60 ## equals to the maximum startup time of the application + couple of seconds
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe: #kubernetes认为该pod是启动成功的
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 30 ## equals to minimum startup time of the application
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
resources:
# keep request = limit to keep this container in guaranteed class
requests:
cpu: 50m
memory: 200Mi
limits:
cpu: 500m
memory: 500Mi
env:
- name: PROFILE
value: "test"
ports:
- name: http
containerPort: 8080几个重要参数说明
maxSurge与maxUnavailable
maxSurge: 1 表示滚动升级时会先启动1个pod
maxUnavailable: 1 表示滚动升级时允许的最大Unavailable的pod个数
由于replicas为3,则整个升级,pod个数在2-4个之间
terminationGracePeriodSeconds
k8s将会给应用发送SIGTERM信号，可以用来正确、优雅地关闭应用,默认为30秒。
如果需要更优雅地关闭，则可以使用k8s提供的pre-stop lifecycle hook 的配置声明，将会在发送SIGTERM之前执行。
livenessProbe与readinessProbe
livenessProbe是kubernetes认为该pod是存活的，不存在则需要kill掉，然后再新启动一个，以达到replicas指定的个数。
readinessProbe是kubernetes认为该pod是启动成功的，这里根据每个应用的特性，自己去判断，可以执行command，也可以进行httpGet。比如对于使用java web服务的应用来说，并不是简单地说tomcat启动成功就可以对外提供服务的，还需要等待spring容器初始化，数据库连接连接上等等。对于spring boot应用，默认的actuator带有/health接口，可以用来进行启动成功的判断。
其中readinessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最少时间，livenessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最大时间+若干秒。
这几个参数配置好了之后，基本就可以实现近乎无缝地平滑升级了。对于使用服务发现的应用来说，readinessProbe可以去执行命令，去查看是否在服务发现里头应该注册成功了，才算成功。
doc
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
1
查看RC具体信息
# kubectl describe rc frontend
1
通过RC修改Pod副本数量（需要修改yaml文件的spec.replicas字段到目标值，然后替换旧的yaml文件）
# kubectl replace -f rc.yaml
或
# kubect edit replicationcontroller frontend
1
2
3
4
5
对RC使用滚动升级，来发布新功能或修复BUG
# kubectl rolling-update frontend --image=kubeguide/guestbook-php-frontend:latest
1
当Pod中只有一个容器时，通过–image参数指定新的Tag完成滚动升级，但如果有多个容器或其他字段修改时，需要指定yaml文件
# kubectl rolling-update frontend -f FILE.yaml
1
如果在升级过程中出现问题（如发现配置错误、长时间无响应），可以使用CTRL+C退出，再进行回滚
# kubectl rolling-update frontend --image=kubeguide/guestbook-php-frontend:latest --rollback
1
但如果升级完成后出现问题（比如新版本程序出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
1
注意–record参数，使用此参数将记录后续创建对象的操作，方便管理与问题追溯
使用子命令edit，编辑spec.replicas/spec.template.spec.container.image字段，完成deployment的扩缩容与滚动升级（这要比子命令rolling-update速度快很多）
# kubectl edit deployment hello-deployment
1
使用rollout history命令，查看Deployment的历史信息
# kubectl rollout history deployment hello-deployment
1
上面提到RC在rolling-update升级成功后不能直接回滚，而使用Deployment却可以回滚到上一版本，但要加上–revision参数，指定版本号
# kubectl rollout history deployment hello-deployment --revision=2
1
使用rollout undo回滚到上一版本
# kubectl rollout undo deployment hello-deployment
1
使用–to-revision可以回滚到指定版本
# kubectl rollout undo deployment hello-deployment --to-revision=2
1
4. 总结
通过对比，我们发现新的Replica Set、Deployment，比RC要强大易用很多。
开源、云原生的融合云平台
更多推荐
1
0- 0
已为社区贡献6条内容
所有评论(0)