惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Jina AI
Jina AI
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
B
Blog
T
The Blog of Author Tim Ferriss
量子位
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - Franky
小众软件
小众软件
Recent Announcements
Recent Announcements
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
I
InfoQ
美团技术团队
G
Google Developers Blog
Engineering at Meta
Engineering at Meta
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
V
Visual Studio Blog
云风的 BLOG
云风的 BLOG
博客园 - 【当耐特】
IT之家
IT之家
Microsoft Security Blog
Microsoft Security Blog
博客园 - 聂微东
Last Week in AI
Last Week in AI
H
Hackread – Cybersecurity News, Data Breaches, AI and More
H
Help Net Security

郑文峰的博客

使用dify对接飞书多维表格 使用n8n对接飞书多维表格 服务启动时出现 OOM 一次服务升级时pg表DDL执行超时失败 Go语言高效IO缓冲技术详解 Go语言延迟初始化(Lazy Initialization)最佳实践 Go语言字符串拼接性能对比与优化指南 Go语言结构体内存对齐完全指南 Go语言空结构体:零内存消耗的高效编程 Go语言堆栈分配与逃逸分析深度解析 Go语言原子操作完全指南 Go语言内存预分配完全指南 Go语言不可变数据共享:无锁并发编程实践 Go语言零拷贝技术完全指南 Go语言遍历性能深度解析:从原理到优化实践 Go语言Interface Boxing原理与性能优化指南 Go协程池深度解析:原理、实现与最佳实践 使用etcd分布式锁导致的协程泄露与死锁问题 基于pre-commit的Python代码规范落地实践 初识 MCP Server pulsar阻塞导致logstash无法接入日志 django-prometheus使用及源码分析 kube-proxy源码分析 kubernetes service如何通过iptables转发 tcp缓存引起的日志丢失 django-apschedule定时任务异常停止 理解calico容器网络通信方案原理 理解flannel的三种容器网络方案原理 理解Linux IPIP隧道 理解VXLAN网络
k8s之Deployment
zhengwenfeng · 2022-08-30 · via 郑文峰的博客

# 简介

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

1
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

1
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

1
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

1
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

1
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

1
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

1
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

1
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

1
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

1
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

1
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

1
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