关键词:管理Replicaset
关键概念
属于Replicaset
的升级版,是建立在rs之上的一个控制器,可以管理多个rs,每次更新镜像版本,都会生成一个新的rs,把旧的rs替换掉,多个rs同时存在,但是只有一个rs运行。
解释
rs v1控制三个pod,删除一个pod,在rs v2上重新建立一个,依次类推,直到全部都是由rs v2控制,如果rs v2有问题,还可以回滚,Deployment是建构在rs之上的,多个rs组成一个Deployment,但是只有一个rs处于活跃状态。
Deployment可以使用声明式定义,直接在命令行通过纯命令的方式完成对应资源版本的内容的修改,也就是通过打补丁的方式进行修改;Deployment能提供滚动式自定义自控制的更新;对Deployment来讲,我们在实现更新时还可以实现控制更新节奏和更新逻辑。
核心功能
1、创建ReplicaSet和Pod
2、滚动升级(不停止旧服务的状态下升级)和回滚应用(将应用回滚到之前的版本)
3、平滑地扩容和缩容
4、暂停和继续Deployment
资源清单解释
# kubectl explain deployment.spec
minReadySeconds <integer> #在等待设置的时间后才进行升级。如果没有设置该值,会假设该容器启动起来后就提供服务了
paused <boolean> #暂停,当我们更新的时候创建pod先暂停,不是立即更新
progressDeadlineSeconds <integer> #升级中由于各种原因升级卡住,个时候就需要有个deadline
replicas <integer> #副本数
revisionHistoryLimit <integer> #保留的历史版本,默认是10
selector <Object> -required- #标签选择器,选择它关联的pod
strategy <Object> #更新策略
template <Object> -required #定义的pod模板
# kubectl explain deploy.spec.strategy
rollingUpdate <Object> #
type <string> #支持两种更新,Recreate和RollingUpdate(默认)
#Recreate是重建式更新,删除一个更新一个
#RollingUpdate滚动更新,定义滚动更新方式,即pod能多几个或少几个
# kubectl explain deploy.spec.strategy.rollingUpdate
maxSurge <string> #我们更新的过程当中最多允许超出的指定的目标副本数有几个;它有两种取值方式,第一种直接给定数量,第二种根据百分比,百分比表示原本是5个,最多可以超出20%,那就允许多一个,最多可以超过40%,那就允许多两个
maxUnavailable <string> #最多允许几个不可用。假设有5个副本,最多一个不可用,就表示最少有4个可用
# kubectl explain deploy.spec.template
metadata <Object>
spec <Object>
# kubectl explain deploy.spec.template.spec
同Pod相关属性配置
# 示例【1】
vim doploy-test-myapp.yaml
kubectl apply -f doploy-test-myapp.yaml
kubectl get deploy
kubectl get rs
kubectl get pods
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 2
selector:
matchLabels:
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp
image: algebra/docker-demo:1.1-SNAPSHOT
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
字段详述
apiVersion: apps/v1 #deployment对应的api版本
kind: Deployment #创建的资源是deployment
metadata:
name: myapp-v1 #deployment的名字
spec:
replicas: 2 #deployment管理的pod副本数
selector: #标签选择器
matchLabels: #matchLabels下定义的标签需要跟template.metadata.labels定义的标签一致
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec: #定义容器的属性
containers:
- name: myapp
image: janakiramm/myapp:v1 #容器使用的镜像
imagePullPolicy: IfNotPresent #镜像拉取策略
ports:
- containerPort: 80 #容器里的应用的端口【一定要看清自己应用的端口】
扩缩容
与Replicaset一样,也是两种方式控制
# 方式一:修改本地资源文件[修改replicas字段]
vim deploy-test-myapp.yaml
kubectl apply -f deploy-test-myapp.yaml[fileName]
# 方式二:直接编辑资源文件[修改replicas字段]
kubectl edit deploy myapp[deployName]
## 动态监测
kubectl get pods -l app=myapp -w
滚动升级&回滚
# 修改本地资源文件[修改image字段,修改为升级的镜像版本]
vim deploy-test-myapp.yaml
kubectl apply -f deploy-test-myapp.yaml[fileName]
# 查看副本控制器[发现有两个rs,其中一个是历史rs]
kubectl get rs
NAME DESIRED CURRENT READY AGE
myapp-79bfbcbb99 2 2 2 4m55s
myapp-9db9684c6 0 0 0 171m
# 查看myapp这个控制器的历史版本
kubectl rollout history deployment myapp
# 回滚到指定版本
kubectl rollout undo deployment myapp --to-revision=1
自定义滚动策略
maxSurge和maxUnavailable用来控制滚动更新的更新策略
取值范围
【数值】
- maxUnavailable: [0, 副本数]
- maxSurge: [0, 副本数]
注意:两者不能同时为0。
【比例】 - maxUnavailable: [0%, 100%] 向下取整,比如10个副本,5%的话==0.5个,但计算按照0个;
- maxSurge: [0%, 100%] 向上取整,比如10个副本,5%的话==0.5个,但计算按照1个;
注意:两者不能同时为0。
【建议配置】
- maxUnavailable == 0
- maxSurge == 1
这是我们生产环境提供给用户的默认配置。即“一上一下,先上后下”最平滑原则:
1个新版本pod ready(结合readiness)后,才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳,但也有缺点,就是“太慢”了。
总结:
maxUnavailable:和期望的副本数比,不可用副本数最大比例(或最大值),这个值越小,越能保证服务稳定,更新越平滑;
maxSurge:和期望的副本数比,超过期望副本数最大比例(或最大值),这个值调的越大,副本更新速度越快。
资源配额
# 资源配额要设置在容器属性上
containers:
- name: myapp
image: algebra/docker-demo:1.2-SNAPSHOT
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
resources:
limits: #资源限制,最多可用的cpu和内存
cpu: 200m
memory: 256M
requests: #最少需要多少资源才可以运行Pod
cpu: 200m
memory: 256M