k8s之Deployment
# 简介
Deployment是k8s用来管理部署无状态Pod的控制器。
适用场景
无状态应用,所有的pod无依赖关系,无指定节点运行、无特殊处理的方式部署
# 使用yaml描述Deployment
使用下面的yaml文件用来创建nginx的Deployment对象
replicas是用来定义创建pod的数量。template中的是所管理的Pod模板,Deployment就是根据该字段来创建pod资源对象。selector是用来筛选需要管理的pod对象,template下的labels的值需要与selector的值需要保持一致,这样Deployment才能找到需要控制的Pod。
更多的字段说明可以看官网 (opens new window)
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: ngx-dep
name: ngx-dep
spec:
replicas: 2
selector:
matchLabels:
app: ngx-dep
template:
metadata:
labels:
app: ngx-dep
spec:
containers:
- image: nginx:alpine
name: nginx
ports:
- containerPort: 80
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 查看Deployment
我们有了yaml来描述deployment之后,就可以使用kubectl apply
来创建Deployment对象。
[root@k8s-worker1 zwf]# kubectl apply -f deployments.yaml -n zwf
deployment.apps/ngx-dep created
2
我也也可以使用kubectl get
来查看我们创建的deplotment对象的信息
[root@k8s-worker1 zwf]# kubectl get deployment -n zwf
NAME READY UP-TO-DATE AVAILABLE AGE
ngx-dep 2/2 2 2 19m
2
3
信息:
- READY,就绪个数/期望个数
- UP-TO-DATE,当前处于最新版本的pod数
- AVAILABLE,当前可用的Pod数,也就是已经经过ready之后的Pod
- age,存活时间
我们将其中一个pod删除了,会发现不就后pod还会自动创建,因为k8s会根据yaml中replicas的值,让deployment的实际状态不断的向期望状态逼近,最终达到一个应用"永不宕机"
[root@k8s-worker1 zwf]# kubectl delete pods ngx-dep-69b9455bcf-cfwgd -n zwf
pod "ngx-dep-69b9455bcf-cfwgd" deleted
[root@k8s-worker1 zwf]# kubectl get pods -n zwf
NAME READY STATUS RESTARTS AGE
ngx-dep-69b9455bcf-ddjml 1/1 Running 0 13m
ngx-dep-69b9455bcf-fn6gw 1/1 Running 0 5s
2
3
4
5
6
7
# ReplicaSet
Deployment并不是直接管理Pod,而是通过ReplicaSet对象间接管理的,也就是说真正管理pod的其实是replicaSet对象.
我们使用kubectl get rs可以查看到ReplicaSet对象,该对象是在创建Deployment时创建的,查看一下ReplicaSet对象的信息,其中的DESIRED和CURRENT对应在和Deployment的READY,READY和Deployment中的是一样的。
[root@k8s-worker1 zwf]# kubectl get rs -n zwf
NAME DESIRED CURRENT READY AGE
ngx-dep-69b9455bcf 2 2 2 43s
2
3
通过kubectl describe查看deploment的详情,可以看到NewReplicaSet的值指向的是ReplicaSet对象,并间接管理Pod。
[root@k8s-worker1 zwf]# kubectl describe deploy ngx-dep -n zwf
Name: ngx-dep
Namespace: zwf
CreationTimestamp: Tue, 30 Aug 2022 11:27:14 +0800
Labels: app=ngx-dep
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=ngx-dep
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=ngx-dep
Containers:
nginx:
Image: mirrors.sangfor.com/nginx:alpine
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Progressing True NewReplicaSetAvailable
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: ngx-dep-69b9455bcf (2/2 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 13m deployment-controller Scaled up replica set ngx-dep-69b9455bcf to 2
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 水平扩缩容
水平扩缩容是可以动态的改变Pod的数量,在高峰期可以扩大应用的数量提高并发,在低峰期缩减Pod减少资源的使用。
我们使用kubectl scale
动态改变Deployment的副本数,查看Deployment对象可以看到READY从2/4到4/4,并且AVALIABLE的值也是逐渐的从2到4
[root@k8s-worker1 zwf]# kubectl scale deploy ngx-dep -n zwf --replicas=4
[root@k8s-worker1 zwf]# kubectl get deployment -n zwf
NAME READY UP-TO-DATE AVAILABLE AGE
ngx-dep 2/4 4 2 18m
[root@k8s-worker1 zwf]# kubectl get deployment -n zwf
NAME READY UP-TO-DATE AVAILABLE AGE
ngx-dep 3/4 4 3 18m
[root@k8s-worker1 zwf]# kubectl get deployment -n zwf
NAME READY UP-TO-DATE AVAILABLE AGE
ngx-dep 4/4 4 4 18m
2
3
4
5
6
7
8
9
10
11
12
13
我们再看看ReplicaSet对象,可以看到当前正在运行Pod数量也发生了改变。因为水平扩缩容的实质是deplotment去修改ReplicaSet的Pod副本的数量。
[root@k8s-worker1 zwf]# kubectl get replicaset -n zwf
NAME DESIRED CURRENT READY AGE
ngx-dep-69b9455bcf 4 4 4 50m
2
3
# 滚动更新
在更新的过程,是逐渐将旧的ReplicaSet所管理的Pod删除,新的ReplicaSet管理的Pod新增这么一个过程。
我们修改Deployment的yaml文件,将containers的name修改为nginx2
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: ngx-dep
name: ngx-dep
spec:
replicas: 2
selector:
matchLabels:
app: ngx-dep
template:
metadata:
labels:
app: ngx-dep
spec:
containers:
- image: nginx:alpine
name: nginx2 # 修改
ports:
- containerPort: 80
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
再使用kubectl apply
执行,更新Deployment,可以看到,UP-TO-DATE是逐渐的从1到2,旧的pod会逐渐的更新成最新的pod.
[root@k8s-worker1 zwf]# kubectl apply -f deployments.yaml -n zwf
deployment.apps/ngx-dep configured
[root@k8s-worker1 zwf]# kubectl get deploy -n zwf
NAME READY UP-TO-DATE AVAILABLE AGE
ngx-dep 2/2 1 2 55m
[root@k8s-worker1 zwf]# kubectl get deploy -n zwf
NAME READY UP-TO-DATE AVAILABLE AGE
ngx-dep 2/2 2 2 55m
2
3
4
5
6
7
8
9
10
我们再看下ReplicaSet对象,可以看到有两个对象。这是因为我们更新了Deployment中的pod template模板,也就是会更新pod,我们知道Deployment是通过ReplicaSet来管理对象的,所以会创建一个新版本的ReplicaSet对象用来创建新版本的Pod并逐渐增加,然后逐渐将旧版本的ReplicaSet对象管理的pod删除直至为0。
[root@k8s-worker1 zwf]# kubectl get rs -n zwf
NAME DESIRED CURRENT READY AGE
ngx-dep-54d65f4d8c 2 2 2 2m54s
ngx-dep-69b9455bcf 0 0 0 58m
2
3
4
我们再看Deployment的详情,Events字段是代表着Deployment中发生的事件,可以看到ngx-dep-69b9455bcf
所管理的pod逐渐减少,而ngx-dep-69b9455bcf
在逐渐增加pod的数量。这也就解释了上面为什么有两个ReplicaSet对象,因为一个是新对象,一个是旧对象,在更新Deployment时,都会保留下来。
[root@k8s-worker1 zwf]# kubectl describe deploy ngx-dep -n zwf
Name: ngx-dep
Namespace: zwf
CreationTimestamp: Tue, 30 Aug 2022 11:27:14 +0800
Labels: app=ngx-dep
Annotations: deployment.kubernetes.io/revision: 2
Selector: app=ngx-dep
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=ngx-dep
Containers:
nginx2:
Image: mirrors.sangfor.com/nginx:alpine
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: ngx-dep-54d65f4d8c (2/2 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 5m deployment-controller Scaled up replica set ngx-dep-54d65f4d8c to 1
Normal ScalingReplicaSet 4m58s deployment-controller Scaled down replica set ngx-dep-69b9455bcf to 1
Normal ScalingReplicaSet 4m58s deployment-controller Scaled up replica set ngx-dep-54d65f4d8c to 2
Normal ScalingReplicaSet 4m54s deployment-controller Scaled down replica set ngx-dep-69b9455bcf to 0
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35