释放双眼，带上耳机，听听看~！
目录
-
Kubernetes之（九）Pod控制器，ReplicaSet，Deployment，DaemonSet
-
ReplicaSet
- Deployment控制器
-
创建Deployment
* Deployment更新
* Deployment扩容
* 金丝雀发布
* Deployment回滚- DaemonSet
-
定义
* DaemonSet演示 redis-filebeat
* DaemonSet的滚动更新
Kubernetes之（九）Pod控制器，ReplicaSet，Deployment，DaemonSet
Kubernetes中内建了很多controller（控制器），这些相当于⼀个状态机，⽤来控制Pod的具体状态和⾏为。
Pod控制器有多种类型：
**ReplicaSet：**它的核心作用是代用户创建指定数量的Pod副本，并确定Pod副本一直处于满足用户期望数量的状态，多退少补，同时支持扩缩容机制。主要有三个组件：
- 用户期望的Pod副本数量；
- 标签选择器，选择属于自己管理和控制的Pod；
- 当前Pod数量不满足用户期望数量时，根据资源模板进行新建。
**Deployment：**工作在ReplicaSet之上，用于管理无状态应用，除了ReplicaSet的机制，还增加了滚动更新和回滚功能，提供声明式配置。
**DaemonSet：**用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务。要求：服务是无状态的；服务必须是守护进程
Job：：只要完成就立即退出，不需要重启或重建。
**Cronjob：**周期性任务控制，不需要持续后台运行。
**StatefulSet：**管理有状态应用，如mysql，redis等。
ReplicaSet
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。
虽然ReplicaSet可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update但Deployment支持）。
举例
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
36
37
38
39
40
41
42
43
44
45
46
47
48
2
3[root@master manifests]# vim rs-demo.yaml
4apiVersion: apps/v1 #群组/版本
5kind: ReplicaSet #类型 注意大小写
6metadata: #元数据
7 name: myapp
8 namespace: default
9spec:
10 replicas: 2 #定义ReplicaSet副本数量
11 selector: #定义选择器
12 matchLabels: #匹配 ，创建的模板的标签需要包含此处的标签，不然无法被创建
13 app: myapp
14 release: canary
15 template: #定义模板
16 metadata: #模板元数据
17 name: myapp-pod #此处名称定义没有用，被控制器创建的pod都会以控制器的名称后加随机字符串来命名
18 labels: #此处要包含replicaset处定义的标签选择器
19 app: myapp
20 release: canary
21 spec:
22 containers: #定义模板的容器
23 - name: myapp-container
24 image: ikubernetes/myapp:v1
25 ports: #端口
26 - name: http
27 containerPort: 80
28
29#运行后验证
30[root@master manifests]# kubectl create -f rs-demo.yaml
31replicaset.apps/myapp created
32[root@master manifests]# kubectl get rs #replicaset 简写rs
33NAME DESIRED CURRENT READY AGE
34client-f5cdb799f 1 1 1 3d19h
35myapp 2 2 2 10s
36nginx-deploy-84cbfc56b6 1 1 1 3d23h
37#查看pod
38[root@master manifests]# kubectl get pods
39NAME READY STATUS RESTARTS AGE
40client-f5cdb799f-pklmc 1/1 Running 0 3d19h
41myapp-fxmjz 1/1 Running 0 59s
42myapp-hxvnz 1/1 Running 0 59s
43nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 3d22h
44pod-demo 2/2 Running 7 2d22h
45poststart-pod 1/1 Running 1 2d16h
46readiness-httpget-pod 1/1 Running 0 2d16h
47#可以使用kubectl describe pods <POD_NAME>来查看详细信息
48
修改Pod的副本数量：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2 replicas: 5
3[root@master manifests]# kubectl get pods
4NAME READY STATUS RESTARTS AGE
5client-f5cdb799f-pklmc 1/1 Running 0 3d19h
6myapp-64qnb 1/1 Running 0 9s
7myapp-fxmjz 1/1 Running 0 3m53s
8myapp-hdv9c 1/1 Running 0 9s
9myapp-hxvnz 1/1 Running 0 3m53s
10myapp-mwb27 1/1 Running 0 9s
11nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 3d23h
12pod-demo 2/2 Running 7 2d22h
13poststart-pod 1/1 Running 1 2d16h
14readiness-httpget-pod
15
修改Pod的镜像版本：
2
3
2 - image: ikubernetes/myapp:v2
3
此时查看原来存在的pod副本还是v1版本，只有重建后的pod才会是V2版本。
kubectl delete -f *** && kube create -f &&
Deployment控制器
Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。
只需要在 Deployment 中描述想要的目标状态，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
典型的用例如下：
- 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态。
- 通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中.
- 如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision.
- 扩容Deployment以满足更高的负载。
- 暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。
- 根据Deployment 的状态判断上线是否hang住了。
清除旧的不必要的 ReplicaSet。
官方定义
查看deployment.spec定义所需字段：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2KIND: Deployment
3VERSION: extensions/v1beta1 #现在最新式apps/v1
4
5 minReadySeconds <integer>
6
7 paused <boolean> #暂停
8
9 progressDeadlineSeconds <integer>
10
11 replicas <integer> #replicas
12
13 revisionHistoryLimit <integer> #保存历史版本数量，用于回滚，默认10
14
15 rollbackTo <Object> #回滚
16
17 selector <Object> #选择器，和replicaset的一样
18
19 strategy <Object> #更新策略 rollingUpdate滚动更新和Recreate重建更新，如果使用rollingUpdate，内部还可以定义更新粒度
20 maxSurge #更新时最多可超出副本数 可以是数量和百分比
21 maxUnavailable #最大不可用 可以是数量和百分比，和上面的maxSurge不能同为0
22
23 template <Object> -required- #模板，和replicaset的一样
24
创建Deployment
举例
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
2apiVersion: apps/v1
3kind: Deployment
4metadata:
5 name: myapp-deploy
6 namespace: default
7spec:
8 replicas: 2
9 selector:
10 matchLabels:
11 app: myapp
12 release: canary
13 template:
14 metadata:
15 labels:
16 app: myapp
17 release: canary
18 spec:
19 containers:
20 - name: myapp
21 image: ikubernetes/myapp:v1
22 imagePullPolicy: IfNotPresent
23 ports:
24 - name: http
25 containerPort: 80
26[root@master manifests]# kubectl apply -f deploy-damo.yaml
27deployment.apps/myapp-deploy created
28
Deployment更新
apply表示声明式创建，也可以用来更新
查看创建结果
2
3
4
5
6
7
8
9
10
11
12
13
14
2NAME READY UP-TO-DATE AVAILABLE AGE
3myapp-deploy 2/2 2 2 2m31s
4[root@master manifests]# kubectl get rs
5NAME DESIRED CURRENT READY AGE
6myapp-deploy-65df64765c 2 2 2 3m22s
7[root@master manifests]# kubectl get pods
8NAME READY STATUS RESTARTS AGE
9myapp-deploy-65df64765c-95dwm 1/1 Running 0 3m24s
10myapp-deploy-65df64765c-btbhg 1/1 Running 0 3m24s
11pod-demo 2/2 Running 8 2d22h
12poststart-pod 1/1 Running 2 2d17h
13readiness-httpget-pod 1/1 Running 0 2d17h
14
Deployment扩容
直接编辑deploy-damo.yaml，副本数修改为4，然后使用kubectl apply -f 更新 也可以使用-w 监控实时更新
2
3
4
5
2 replicas: 4
3[root@master manifests]# kubectl apply -f deploy-damo.yaml
4deployment.apps/myapp-deploy configured
5
再次查看
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2NAME DESIRED CURRENT READY AGE
3replicaset.extensions/myapp-deploy-65df64765c 4 4 4 6m53s
4
5NAME READY UP-TO-DATE AVAILABLE AGE
6deployment.extensions/myapp-deploy 4/4 4 4 6m53s
7
8NAME READY STATUS RESTARTS AGE
9pod/myapp-deploy-65df64765c-8q8bq 1/1 Running 0 31s
10pod/myapp-deploy-65df64765c-95dwm 1/1 Running 0 6m53s
11pod/myapp-deploy-65df64765c-btbhg 1/1 Running 0 6m53s
12pod/myapp-deploy-65df64765c-x742g 1/1 Running 0 31s
13pod/pod-demo 2/2 Running 8 2d22h
14pod/poststart-pod 1/1 Running 2 2d17h
15pod/readiness-httpget-pod 1/1 Running 0 2d17h
16
每次使用apply改变的信息都会被保存在annotations里面。
2
3
4
5
6
7
8
2Annotations: deployment.kubernetes.io/revision: 1
3 kubectl.kubernetes.io/last-applied-configuration:
4 {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"myapp-deploy","namespace":"default"},"spec":{"replicas":4...
5
6StrategyType: RollingUpdate #默认滚动策略
7RollingUpdateStrategy: 25% max unavailable, 25% max surge #更新策略25% 低于1补为1，
8
如果只是更新模板的image 可以使用kubectl set image命令
2
2
如果修改其他配置，例如修改副本数量，滚动更新策略等，可以使用kubectl patch 打补丁后面使用对象的jason格式内容
2
3
4
2
3[root@master ~]# kubectl patch deployment myapp-deploy -p '{"spec":{"strategy":{"rollingupdate":{"maxsurge“:1,"maxUnavailable":0}}}}'
4
金丝雀发布
Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布（Canary Release），如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2[root@master manifests]# kubectl set image deployment myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployment myapp-deploy
3deployment.extensions/myapp-deploy image updated
4deployment.extensions/myapp-deploy paused
5
6#查看
7[root@master ~]# kubectl get pod -w
8NAME READY STATUS RESTARTS AGE
9myapp-deploy-65df64765c-48bjw 1/1 Running 0 8m2s
10myapp-deploy-65df64765c-5qd4x 1/1 Running 0 18s
11myapp-deploy-65df64765c-w4htd 1/1 Running 0 8m2s
12pod-demo 2/2 Running 8 2d23h
13poststart-pod 1/1 Running 3 2d17h
14readiness-httpget-pod 1/1 Running 0 2d18h
15myapp-deploy-548f47d899-cbhsf 0/1 Pending 0 0s
16myapp-deploy-548f47d899-cbhsf 0/1 Pending 0 0s
17myapp-deploy-548f47d899-cbhsf 0/1 ContainerCreating 0 0s
18myapp-deploy-548f47d899-cbhsf 1/1 Running 0 1s
19
此时只有一个pod版本更新为V3版本
2
3
4
5
6
7
8
9
10
2NAME READY STATUS RESTARTS AGE
3myapp-deploy-548f47d899-cbhsf 1/1 Running 0 49s
4myapp-deploy-65df64765c-48bjw 1/1 Running 0 9m2s
5myapp-deploy-65df64765c-5qd4x 1/1 Running 0 78s
6myapp-deploy-65df64765c-w4htd 1/1 Running 0 9m2s
7pod-demo 2/2 Running 8 2d23h
8poststart-pod 1/1 Running 3 2d17h
9readiness-httpget-pod 1/1 Running 0 2d18h
10
确保更新的pod没问题了，继续更新
2
3
4
5
6
7
8
9
10
11
12
2deployment.extensions/myapp-deploy resumed
3
4[root@master ~]# kubectl get pods
5NAME READY STATUS RESTARTS AGE
6myapp-deploy-548f47d899-5rdgh 1/1 Running 0 59s
7myapp-deploy-548f47d899-cbhsf 1/1 Running 0 2m54s
8myapp-deploy-548f47d899-prvpl 1/1 Running 0 57s
9pod-demo 2/2 Running 8 2d23h
10poststart-pod 1/1 Running 3 2d17h
11readiness-httpget-pod 1/1 Running 0 2d18h
12
也可以使用kubectl rollout status <TYPE> <TYPE_NAME>监控
2
3
2deployment "myapp-deploy" successfully rolled out
3
Deployment回滚
默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便可以随时回退（您可以修改revision history limit来更改保存的revision数）。
注意： 只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如.spec.template）被更改，例如更新template 中的 label 和容器镜像时，就会创建出一个新的 revision。
其他的更新，比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 revision 时，只有 Deployment 中的 Pod template 部分才会回退。
2
3
4
5
6
2deployment.extensions/myapp-deploy
3REVISION CHANGE-CAUSE
49 <none>
510 <none>
6
这里在创建deployment时没有增加–record参数，所以并不能看到revision的变化。在创建 Deployment 的时候使用了–record参数可以记录命令，就可以方便的查看每次 revision 的变化。
查看单个revision的详细信息：
2
2
回滚历史版本,默认是上一个版本
2
3
2deployment.extensions/myapp-deploy rolled back
3
使用 –to-revision参数指定某个历史版本：
2
3
2deployment.extensions/myapp-deploy skipped rollback (current template already matches revision 11)
3
DaemonSet
定义
DaemonSet确保全部（或者一些）Node上运行一个Pod的副本。当有Node加入集群时也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
DaemonSet 的一些典型用法：
- 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
- 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
- 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。
一个简单的用法是，在所有的 Node 上都存在一个 DaemonSet，将被作为每种类型的 daemon 使用。 一个稍微复杂的用法可能是，对单独的每种类型的 daemon 使用多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同的内存、CPU要求。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2KIND: DaemonSet
3
4 minReadySeconds <integer>
5
6 revisionHistoryLimit <integer>
7
8 selector <Object>
9
10 template <Object> -required-
11
12 templateGeneration <integer>
13
14 updateStrategy <Object>
15
DaemonSet演示 redis-filebeat
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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
2apiVersion: apps/v1
3kind: Deployment
4metadata:
5 name: redis
6 namespace": default
7spec:
8 replicas: 1
9 selector:
10 matchLabels:
11 app: redis
12 role: logstore
13 template:
14 metadata:
15 labels:
16 app: redis
17 role: logstore
18 spec:
19 containers:
20 - name: redis
21 image: redis:4.0-alpine
22 ports:
23 - name: redis
24 containerPort: 6379
25---
26apiVersion: apps/v1
27kind: DaemonSet
28metadata:
29 name: filebeat-ds
30 namespace: default
31spec:
32 selector:
33 matchLabels:
34 app: filebeat
35 release: stable
36 template:
37 metadata:
38 labels:
39 app: filebeat
40 release: stable
41 spec:
42 containers:
43 - name: filebeat
44 image: ikubernetes/filebeat:5.6.5-alpine
45 env:
46 - name: REDIS_HOST
47 value: redis.default.svc.cluster.local
48 - name: REDIS_LOG_LEVEL
49 value: info
50
创建并暴漏端口
2
3
4
5
6
7
8
9
10
11
12
13
14
2deployment.apps/redis created
3daemonset.apps/filebeat-ds created
4
5[root@master manifests]# kubectl expose deploy redis --port=6379
6service/redis exposed
7
8[root@master manifests]# kubectl get svc
9NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
10kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d19h
11myapp NodePort 10.104.138.182 <none> 80:30298/TCP 3d21h
12nginx ClusterIP 10.98.2.12 <none> 80/TCP 4d
13redis ClusterIP 10.97.149.76 <none> 6379/TCP 15s
14
测试redis是否收到日志
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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
2NAME READY STATUS RESTARTS AGE
3filebeat-ds-28kmv 1/1 Running 0 48s
4filebeat-ds-wmlzj 1/1 Running 0 48s
5myapp-deploy-65df64765c-9g9bv 1/1 Running 0 29m
6myapp-deploy-65df64765c-ll8bk 1/1 Running 0 29m
7myapp-deploy-65df64765c-xd2kn 1/1 Running 0 29m
8pod-demo 2/2 Running 9 3d
9poststart-pod 1/1 Running 3 2d18h
10readiness-httpget-pod 1/1 Running 0 2d18h
11redis-76c85b5744-7zt7l 1/1 Running 0 48s
12
13#进入redis
14[root@master manifests]# kubectl exec -it redis-76c85b5744-7zt7l -- /bin/sh
15/data # netstat -lnt
16Active Internet connections (only servers)
17Proto Recv-Q Send-Q Local Address Foreign Address State
18tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN
19tcp 0 0 :::6379 :::* LISTEN
20
21
22/data # nslookup redis.default.svc.cluster.local
23nslookup: can't resolve '(null)': Name does not resolve
24
25Name: redis.default.svc.cluster.local
26Address 1: 10.97.149.76 redis.default.svc.cluster.local
27 #由于redis在filebeat后面才启动，日志可能已经发走了，所以查看key为空
28/data # redis-cli -h redis.default.svc.cluster.local
29redis.default.svc.cluster.local:6379> keys *
30(empty list or set)
31#进入filebeat容器
32[root@master manifests]# kubectl get pods
33NAME READY STATUS RESTARTS AGE
34filebeat-ds-28kmv 1/1 Running 0 4m48s
35filebeat-ds-wmlzj 1/1 Running 0 4m48s
36myapp-deploy-65df64765c-9g9bv 1/1 Running 0 33m
37myapp-deploy-65df64765c-ll8bk 1/1 Running 0 33m
38myapp-deploy-65df64765c-xd2kn 1/1 Running 0 33m
39pod-demo 2/2 Running 9 3d
40poststart-pod 1/1 Running 3 2d18h
41readiness-httpget-pod 1/1 Running 0 2d18h
42redis-76c85b5744-7zt7l 1/1 Running 0 4m48s
43[root@master manifests]# kubectl exec -it filebeat-ds-28kmv -- /bin/sh
44#查看filebeat配置文件
45filebeat.registry_file: /var/log/containers/filebeat_registry
46filebeat.idle_timeout: 5s
47filebeat.spool_size: 2048
48
49logging.level: info
50
51filebeat.prospectors:
52- input_type: log
53 paths:
54 - "/var/log/containers/*.log"
55 - "/var/log/docker/containers/*.log"
56 - "/var/log/startupscript.log"
57 - "/var/log/kubelet.log"
58 - "/var/log/kube-proxy.log"
59 - "/var/log/kube-apiserver.log"
60 - "/var/log/kube-controller-manager.log"
61 - "/var/log/kube-scheduler.log"
62 - "/var/log/rescheduler.log"
63 - "/var/log/glbc.log"
64 - "/var/log/cluster-autoscaler.log"
65 symlinks: true
66 json.message_key: log
67 json.keys_under_root: true
68 json.add_error_key: true
69 multiline.pattern: '^\s'
70 multiline.match: after
71 document_type: kube-logs
72 tail_files: true
73 fields_under_root: true
74
75output.redis:
76 hosts: ${REDIS_HOST:?No Redis host configured. Use env var REDIS_HOST to set host.}
77 key: "filebeat"
78
79
DaemonSet的滚动更新
DaemonSet有两种更新策略类型：
2
3
4
5
6
7
8
9
10
2KIND: DaemonSet
3VERSION: extensions/v1beta1
4
5FIELD: type <string>
6
7DESCRIPTION:
8 Type of daemon set update. Can be "RollingUpdate" or "OnDelete". Default is
9 OnDelete.
10
- OnDelete:向后兼容性的默认更新策略。使用 OnDelete更新策略，在更新DaemonSet模板后，只有在手动删除旧的DaemonSet pod时才会创建新的DaemonSet pod。这与Kubernetes 1.5或更早版本中DaemonSet的行为相同
- RollingUpdate：使用RollingUpdate更新策略，在更新DaemonSet模板后，旧的DaemonSet pod将被终止，并且将以受控方式自动创建新的DaemonSet pod。
要启用DaemonSet的滚动更新功能，必须将其设置 .spec.updateStrategy.type为RollingUpdate。
查看当前的更新策略：
2
3
2RollingUpdate
3
更新DaemonSet模板
对RollingUpdateDaemonSet的任何更新都.spec.template将触发滚动更新。这可以通过几个不同的kubectl命令来完成。
- 声明式命令方式： 修改配置文件后使用kubectl apply更新
2）补丁式命令方式：kubectl edit ds/filebeat-ds
kubectl patch ds/filebeat-ds -p=<strategic-merge-patch>
仅仅更新容器镜像还可以使用以下命令：
kubectl set image ds/<daemonset-name> <container-name>=<container-new-image>
对filebeat-ds的镜像进行版本更新
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
2daemonset.extensions/filebeat-ds image updated
3[root@master manifests]# kubectl get pods -w
4NAME READY STATUS RESTARTS AGE
5filebeat-ds-28kmv 1/1 Running 0 21m
6filebeat-ds-wmlzj 0/1 Terminating 0 21m
7myapp-deploy-65df64765c-9g9bv 1/1 Running 0 50m
8myapp-deploy-65df64765c-ll8bk 1/1 Running 0 50m
9myapp-deploy-65df64765c-xd2kn 1/1 Running 0 50m
10pod-demo 2/2 Running 10 3d
11poststart-pod 1/1 Running 4 2d18h
12readiness-httpget-pod 1/1 Running 0 2d19h
13redis-76c85b5744-7zt7l 1/1 Running 0 21m
14filebeat-ds-wmlzj 0/1 Terminating 0 21m
15filebeat-ds-wmlzj 0/1 Terminating 0 21m
16filebeat-ds-j69gd 0/1 Pending 0 0s
17filebeat-ds-j69gd 0/1 Pending 0 0s
18filebeat-ds-j69gd 0/1 ContainerCreating 0 0s
19filebeat-ds-j69gd 1/1 Running 0 14s
20filebeat-ds-28kmv 1/1 Terminating 0 21m
21filebeat-ds-28kmv 0/1 Terminating 0 21m
22filebeat-ds-28kmv 0/1 Terminating 0 21m
23filebeat-ds-28kmv 0/1 Terminating 0 21m
24filebeat-ds-p5r4n 0/1 Pending 0 0s
25filebeat-ds-p5r4n 0/1 Pending 0 0s
26filebeat-ds-p5r4n 0/1 ContainerCreating 0 0s
27filebeat-ds-p5r4n 1/1 Running 0 13s
28
从上面的滚动更新，可以看到在更新过程中，是先终止旧的pod，再创建一个新的pod，逐步进行替换的，这就是DaemonSet的滚动更新策略。
