pod 升级方式:
1、删掉旧pod,在部署新pod.
2、创建新pod,通过修改service选择器后删除旧pod
3、滚动式升级 rolling-update
4、使用deployment声明方式升级
前两者不在详述,都需要中断业务。
kubectl 滚动式升级:
实验:
定义kubia-v1 YAML 文件创建POD 和service
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia-v1
spec:
replicas: 3
template:
metadata:
name: kubia
lebels:
app: kubia
spec:
containers:
- images: luksa/kubia:v1
name: nodejs
---
apiVersion: v1
kind: service
metadata:
name: kubia-v1
spec:
type: LoadBalancer
selector:
app: kubia
ports:
- port: 80
targetPort: 8080
使用 kubia-v2替换kubia-v1
kubectl rolling-update kubia-v1 kubia-v2 --image=luksa/kubia:v2 #执行替换命令.一个新的rc会被创建,初始副本为0。
kubectl describe rc kubia-v2 #查看kubia-v2的RC
随着kubectl继续滚动升级,开始看到越来越多的请求被切换到v2 pod,v1的pod 不断的被删除。
rolling-update的方式升级需要执行 kubectl 命令,如果在升级过程中失去网络连接升级进程会将中断。 rolling-update是一种淘汰的升级方式。
deployment 声明式升级
deployment用于部署应用程序并已声明的方式升级应用、而不是通过RC,RS进行部署。
使用deployment时,实际上pod是由deployment的replicaset创建和管理的,不是由deployment直接创建和管理。
deployment也是由标签选择器、期望副本数和pod模本组成,此外还包含一个字段指定一个部署策略,该策略定义在修改deployment资源时应该如何执行更新。
创建一个deployment yaml 文件
apiVersion: apps/v1beta1 #deployment属于apps api组,版本为v1beta1
kind: Deployment #kind 名称为Deployment
metadata:
name: kubia #deployment名称中不在需要版本号
spec:
replicas: 3
template:
metadata:
name: kubia
labels:
app: kubia
spec:
contaoners:
- image: luksa/kubia:v1
name: nodejs
kubectl create -f kubia-deployment.yaml --record #创建deployment, --record 参数会记录历史版本号。
可以同过kubectl get deployment 和 kubectl describe deployment 查看详细信息。
kubectl rollout status deployment kubia #查看 kubia的部署状态。
deployment 升级策略:
1、滚动式升级(rollingupdate)
2、recreate (逐渐删除旧pod,逐渐创建新pod)
要触发升级,只需要修改deployment的yaml 文件即可。
kubectl set image deployment kubia nodejs=lunksa/kubia:v2 #这条命名会将模板里的镜像修改为lunksa/kubia:v2 (新版本)修改完成后会开始滚动升级。
修改deployment或者其他资源的不同方式:
方法 | 作用 |
Kubectl edit | 使用默认编辑器打开资源配置,修改保存并退出编辑器 例: kubectl edit deployment kubia |
Kubectl patch | 修改单个资源属性 例:kubectl patch deployment kubia -p ‘{“spec”:{template”:{“spec”:{“containers”:[{“name”: “nodejs”,”image”:”luksa/kubia:v2}]}}} |
Kubectl apply | 通过一个完整的yaml或json 文件,应用其中新的值来修改对象,如果yaml或json中指定的对象不存在,则会被创建。该文件需要包含资源的完整定义,(不能像 kubectl patch 那样只创建想要更新的字段) 例:kubectl apply -f kubia-deployment-v2.yaml |
Kubectl replace | 将原有对象替换为YAML、JSON文件中定义的新对象,与apply命令相反,运行这个命令要求对象必须存在,否则报错。 Kubectl replace -f kubia-deployment-v2.yaml |
Kubectl setimage | 修改Pod、RS、RC、 Deployment 、DemonSet 、Job内的镜像 例:kubectl set image deploymen kubia nodejs=luksa/kubia:v2 |
回滚升级:
Kubectl rollout undo deployment kubia #回滚到上一个版本
Kubectl rollout history deployment kubia # 查看kubia 历史版本
Kubectl rollout undo deployment kubia —to-revision=1 #回滚到指定版本
暂停滚动升级:
如果想让新版和旧版pod混合运行、看看新版pod运行是否正常则在执行升级几秒后在执行暂停升级命令。
kubectl rollout pause deployment kubia
恢复滚动升级:
确认了刚才新版没有问题,可以继续升级替换所以旧版本pod,可以执行恢复升级命令。
kubectl rollout resume deployment kubia
取消出错滚动升级 :
kubectl describe deploy kubia # 查看deployment的详细情况。
如果出现ProgressDeadlineExceeded记录,则表示完成滚动升级时间太久。
可通过设定Deployment spec 中使用 progressDeadlineSeconds来指定时间。
因为错误滚动升级不能在继续,所以执行下面命令取消升级。
kubectl rollout undo deployment kubia