k8s之Deployment

简介

Deployment是k8s用来管理部署无状态Pod的控制器。

适用场景

无状态应用，所有的pod无依赖关系，无指定节点运行、无特殊处理的方式部署

使用yaml描述Deployment

使用下面的yaml文件用来创建nginx的Deployment对象

replicas是用来定义创建pod的数量。template中的是所管理的Pod模板，Deployment就是根据该字段来创建pod资源对象。selector是用来筛选需要管理的pod对象，template下的labels的值需要与selector的值需要保持一致，这样Deployment才能找到需要控制的Pod。

更多的字段说明可以看官网

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

查看Deployment

我们有了yaml来描述deployment之后，就可以使用kubectl apply来创建Deployment对象。

[root@k8s-worker1 zwf]# kubectl apply -f deployments.yaml  -n zwf
deployment.apps/ngx-dep created

我也也可以使用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

信息：

• 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

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

通过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:  
    Mounts:       
  Volumes:        
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  
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

水平扩缩容

水平扩缩容是可以动态的改变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

我们再看看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

滚动更新

在更新的过程，是逐渐将旧的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

再使用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

我们再看下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

我们再看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:  
    Mounts:       
  Volumes:        
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  
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

欢迎关注，互相学习，共同进步~

我的个人博客

我的微信公众号：编程黑洞