标签:就是 none pod net workload 简单的 ges 控制 依赖
明明ReplicaSet已经可以控制pod的数量了,为什么还需要Deployment?
简单的说,Deployment控制ReplicaSet的多个版本,ReplicaSet控制Pod个数
Deploymen实际上一个两层控制器,遵循一种滚动更新的方式来实升级现有的容器,这个能力的实现,依赖的就是ReplicaSet这个对象
当我们修改了Deployment对象后,Deployment控制器会使用修改后的模板,创建一个新的ReplicaSet对象,这时候有两个RelicaSet对象,
Deployment通过控制ReplicaSet对象的pod数量来达到滚动升级的效果
例如A和B,如果最终设置的pod数都是3,通过A-1,B+1这样的方式,直到A的pod数量变为0,最终 达到了滚动升级的目的。
同时,因为存在多个ReplicaSet,让回滚成为了可能
示例yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
template字段,指定了创建pod的模板
replicas指定了pod的节点数量
还有一个 type: RollingUpdate,指定了滚动升级的策略
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
查看deployments
kubectl get deployments demo2 -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
demo2 2/3 3 2 24d demo2 harbor.eoffcn.com/dev/demo2 workload.user.cattle.io/workloadselector=deployment-web-demo2
UP-TO-DATE:当前处于最新版本的 Pod 的个数,所谓最新版本指的是 Pod 的 Spec 部分与 Deployment 里 Pod 模板里定义的完全一致
AVAILABLE:当前已经可用的 Pod 的个数,即:既是 Running 状态,又是最新版本,并且已经处于 Ready(健康检查正确)状态的 Pod 的个数
READY:前处于 Running 状态的 Pod 的个数/用户期望的 Pod 副本个数
查看历史版本
kubectl rollout history deployment ${name}
deployment.extensions/demo2
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
4 <none>
查看指定版本
kubectl rollout history deployment ${name} --revision=${version}
回滚到上一版本
kubectl rollout undo deployment ${name}
回滚到指定版本
kubectl rollout undo deployment ${name} --to-revision=${version}
标签:就是 none pod net workload 简单的 ges 控制 依赖
原文地址:https://www.cnblogs.com/chenqionghe/p/11602950.html