k8s-pod 控制器

k8s-pod 控制器

当 Pod 被创建出来，Pod 会被调度到集群中的节点上运行，Pod 会在该节点上一直保持运行状态，直到进程终止、Pod 对象被删除、Pod 因节点资源不足而被驱逐或者节点失效为止。Pod 并不会自愈，当节点失效，或者调度 Pod 的这一操作失败了，Pod 就该被删除。如此，单单用 Pod 来部署应用，是不稳定不安全的。

Kubernetes 使用更高级的资源对象 *“控制器”* 来实现对Pod的管理。控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。 例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。

无状态服务与有状态服务

pod 控制器针对不同类型服务，有着更细致的划分。在k8s 中，会根据容器是需要在运行过程中存储数据到宿主机上将服务分为 无状态 和有状态两种

针对于这两种状态服务以及监控服务，k8s分别推出了不同的控制器来实现管理

无状态服务pod 控制器

ReplicationController(RC)

Replication Controller 简称 RC，RC 是 Kubernetes 系统中的核心概念之一，简单来说，RC 可以保证在任意时间运行 Pod 的副本数量，能够保证 Pod 总是可用的。如果实际 Pod 数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当 Pod 失败、被删除或者挂掉后，RC 都会去自动创建新的 Pod 来保证副本数量，所以即使只有一个 Pod，我们也应该使用 RC 来管理我们的 Pod。可以说，通过 ReplicationController，Kubernetes 实现了 Pod 的高可用性。

v1.11+ 已经弃用，了解即可

ReplicaSet(RS)

Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector, 对pod。功能强大了点

Label 和 Selector

label （标签）是附加到 Kubernetes 对象（比如 Pods）上的键值对，用于区分对象（比如Pod、Service）。 label 旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 label 可以用于组织和选择对象的子集。label 可以在创建时附加到对象，随后可以随时添加和修改。可以像 namespace 一样，使用 label 来获取某类对象，但 label 可以与 selector 一起配合使用，用表达式对条件加以限制，实现更精确、更灵活的资源查找。

label 与 selector 配合，可以实现对象的“关联”，“Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod，可以给 Pod 设置 label，然后给“控制器”设置对应的 selector，这就实现了对象的关联。

1. label 使用

1. 配置文件中
		在各类资源的 metadata.labels  或者 sepc.metadata.labels中进行配置
		apiVersion: v1
    kind: Pod
    metadata:
      name: nginx-demo
      labels:   # 设置标签
        type: app   # 标签 k,v
        test: 1.0.0  # label 的值需要使用字符串，如果是数字，需要加 '' 框起来
2. 通过临时创建修改
		kubectl label po <资源名称> app=hello
3. 修改label
		kubectl label po <资源名称> app=hello2 --overwrite
4. 查看label 信息
		kubectl get po  --show-labels
5. 根具label 值查找pod
		kubectl get po -A -l app=hello
		kubectl get po -A -l 'kind=nginx-demo, test=1.0.0'  # 可以多条件查询 in 查询 != 
		# 匹配单个值，查找 app=hello 的 pod
    kubectl get po -A -l app=hello

    # 匹配多个值
    kubectl get po -A -l 'k8s-app in (metrics-server, kubernetes-dashboard)'
    或 

    # 查找 version!=1 and app=nginx 的 pod 信息
    kubectl get po -l version!=1,app=nginx

    # 不等值 + 语句
    kubectl get po -A -l version!=1,'app in (busybox, nginx)'
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

2. selector 使用

   在各对象的配置 spec.selector 或其他可以写 selector 的属性中编写

   selector 在 deployment 和 service 中配置有点去呗

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: web-app-deployment  
spec:  
  replicas: 3  
  selector:  
    matchLabels:  
      app: web-app  
  template:  
    metadata:  
      labels:  
        app: web-app  
        env: production  
    spec:  
      containers:  
      - name: web-app  
        image: my-web-app-image  
        ports:  
        - containerPort: 8080
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: v1  
kind: Service  
metadata:  
  name: web-app-service  
spec:  
  selector:  
    app: web-app    # service 中配置 selector 不需要使用matchLabels 
  ports:  
  - protocol: TCP  
    port: 80  
    targetPort: 8080
1
2
3
4
5
6
7
8
9
10
11

至于 为啥 deployment 中的 selector 比 service 中多了一层的原因如下

Deployment中的selector字段是用来指定如何识别Pod的，以确保Deployment控制器能够正确地管理这些Pod。selector字段内通常包含matchLabels或matchExpressions，它们定义了用来选择Pod的标签条件。

当使用matchLabels时，你需要提供一个或多个键值对，这些键值对必须与Pod模板中的标签完全匹配，这样Deployment才能正确地识别和管理这些Pod。通过定义这些匹配条件，Deployment控制器能够确保它所管理的Pod集合始终符合期望的状态。

为什么selector的使用需要加上matchLabels（或matchExpressions）呢？这主要有以下几个原因：

1. 精确识别：通过matchLabels，你可以精确地指定要由Deployment管理的Pod的标签。这有助于避免管理错误的Pod或遗漏应该管理的Pod。
2. 标签选择器灵活性：除了简单的键值对匹配外，你还可以使用matchExpressions来执行更复杂的标签选择逻辑，如“存在某个标签”或“标签的值在某个集合中”等。
3. 状态一致性：当Deployment的期望状态与实际状态不一致时（例如，Pod数量不足或配置不匹配），控制器会使用selector来识别需要创建、更新或删除的Pod，以确保集群中的Pod集合始终符合Deployment的期望状态。
4. 避免冲突：在Kubernetes集群中，可能同时存在多个Deployment和其他资源对象，它们可能都试图管理相同或不同的Pod。通过使用特定的selector，每个Deployment都可以明确指定它应该管理哪些Pod，从而避免潜在的冲突。

综上所述，selector中的matchLabels（或matchExpressions）是确保Deployment能够正确、有效地识别和管理其目标Pod集合的关键组成部分。

Service中不需要matchLabels是因为它的职责是提供网络访问入口和流量路由，而不是直接管理Pod的生命周期。标签选择器用于在Service中识别需要暴露的Pod集合，而Pod的管理则由其他资源对象（如Deployment）通过matchLabels等方式来负责。

Deployment

Deployment 在 RS 的基础上，又包了一层，实现了更多的功能

创建

yaml文件

apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
  labels: # 标签
    app: nginx-deploy # 具体的 key: value 配置形式
  name: nginx-deploy # deployment 的名字
  namespace: default # 所在的命名空间
spec:
  replicas: 1 # 期望副本数
  revisionHistoryLimit: 10 # 进行滚动更新后，保留的历史版本数
  selector: # 选择器，用于找到匹配的 RS
    matchLabels: # 按照标签匹配
      app: nginx-deploy # 匹配的标签key/value
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时，更新的个数最多可以超过期望副本数的个数/比例
      maxUnavailable: 25% # 进行滚动更新时，最大不可用比例更新比例，表示在所有副本数中，最多可以有多少个不更新成功
    type: RollingUpdate # 更新类型，采用滚动更新
  template: # pod 模板
    metadata: # pod 的元信息
      labels: # pod 的标签
        app: nginx-deploy
    spec: # pod 期望信息
      containers: # pod 的容器
      - image: nginx:1.7.9 # 镜像
        imagePullPolicy: IfNotPresent # 拉取策略
        name: nginx # 容器名称
      restartPolicy: Always # 重启策略
      terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间
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

1. 通过命令创建一个 deployment
kubectl create deploy nginx-deploy --image=nginx:1.7.9

2. 通过 yaml 文件创建
kubectl create -f xxx.yaml --record
--record 会在 annotation 中记录当前命令创建或升级了资源，后续可以查看做过哪些变动操作。

#查看部署信息
kubectl get deployments

#查看 rs
kubectl get rs

#查看 pod 以及展示标签，可以看到是关联的那个 rs
kubectl get pods --show-labels

# 快速获取一个yaml 文件方案
1. 通过命令创建一个 deploy
2. kubectl get deploy <deploy_name> -o yaml  # 去除不需要的，改一改就可以用了
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

滚动更新

只有修改了 deployment 配置文件中的 template 中的属性后，才会触发更新操作

#修改 nginx 版本号
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

#或者通过 kubectl edit deployment/nginx-deployment 进行修改

#查看滚动更新的过程
kubectl rollout status deploy <deployment_name>

#查看部署描述，最后展示发生的事件列表也可以看到滚动更新过程
kubectl describe deploy <deployment_name>
'''
通过 kubectl get deployments 获取部署信息，UP-TO-DATE 表示已经有多少副本达到了配置中要求的数目
通过 kubectl get rs 可以看到增加了一个新的 rs
通过 kubectl get pods 可以看到所有 pod 关联的 rs 变成了新的
'''
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

注：假设当前有 5 个 nginx:1.7.9 版本，你想将版本更新为 1.9.1，当更新成功第三个以后，你马上又将期望更新的版本改为 1.9.2，那么此时会立马删除之前的三个，并且立马开启更新 1.9.2 的任务

回滚版本

有时候你可能想回退一个Deployment，例如，当Deployment不稳定时，比如一直crash looping。

默认情况下，kubernetes会在系统中保存前两次的Deployment的rollout历史记录，以便你可以随时会退（你可以修改revision history limit来更改保存的revision数）。

#更新 deployment 时参数不小心写错，如 nginx:1.9.1 写成了 nginx:1.91
kubectl set image deployment/nginx-deploy nginx=nginx:1.91

#监控滚动升级状态，由于镜像名称错误，下载镜像失败，因此更新过程会卡住
kubectl rollout status deployments nginx-deploy

#结束监听后，获取 rs 信息，我们可以看到新增的 rs 副本数是 2 个
kubectl get rs

#通过 kubectl get pods 获取 pods 信息，我们可以看到关联到新的 rs 的 pod，状态处于 ImagePullBackOff 状态

#为了修复这个问题，我们需要找到需要回退的 revision 进行回退
#通过命令可以获取 revison 的列表
kubectl rollout history deployment/nginx-deploy

#通过可以查看详细信息
kubectl rollout history deployment/nginx-deploy --revision=2 

#确认要回退的版本后，可以回退到上一个版本
kubectl rollout undo deployment/nginx-deploy 

#也可以回退到指定的 revision
kubectl rollout undo deployment/nginx-deploy --to-revision=2

再次通过 kubectl get deployment 和 kubectl describe deployment 可以看到，我们的版本已经回退到对应的 revison 上了

可以通过设置 .spec.revisonHistoryLimit 来指定 deployment 保留多少 revison，如果设置为 0，则不允许 deployment 回退了。
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

扩容/缩容

通过 kube scale 命令可以进行自动扩容/缩容，以及通过 kube edit 编辑 replcas 也可以实现扩容/缩容

扩容与缩容只是直接创建副本数，没有更新 pod template 因此不会创建新的 rs

kubectl scale --replicas=3 deploy nginx-deploy
1

暂停和恢复

由于每次对 pod template 中的信息发生修改后，都会触发更新 deployment 操作，那么此时如果频繁修改信息，就会产生多次更新，而实际上只需要执行最后一次更新即可，当出现此类情况时我们就可以暂停 deployment 的 rollout

 # 实现暂停，直到你下次恢复后才会继续进行滚动更新
 kubectl rollout pause deployment <name> 
 
 # 恢复更新
 kubectl rollout deploy <name>
1
2
3
4
5

StatefulSet

用于有状态服务

StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster.local

• serviceName 为 Headless Service 的名字
• 0…N-1 为 Pod 所在的序号，从 0 开始到 N-1
• statefulSetName 为 StatefulSet 的名字
• namespace 为服务所在的 namespace，Headless Servic 和 StatefulSet 必须在相同的 namespace
• .cluster.local 为 Cluster Domain

特点：

1. Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现
2. 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现
3. 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0到 N-1，在下一个Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现
4. 有序收缩，有序删除（即从 N-1 到 0）

注意事项：

kubernetes v1.5 版本以上才支持

所有pod 的vloume 必须使用PersistentVolume 或者是管理员提前建好

为了保证数据安全, 删除 StatefulSet时不会删除Volume

StatefulSet 需要一个 Headless Service 来定义DNS domain，需要在 StatefulSet之前创建好

创建

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---     # 先创建上面的service
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web  # statefulset 对象name
spec:
  serviceName: "nginx"  # 使用 name 为nginx 的service 来管理 dns
  replicas: 2
  selector:
    matchLabels:  # 匹配对应的标签
    	app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:   # 对外暴露的端口
        - containerPort: 80  # 具体端口号
          name: web     # 端口配置的name
          
        volumeMounts:   # 加载数据卷   使用pvc 需要提取创建 pv 
        - name: www			# 数据卷的name
          mountPath: /usr/share/nginx/html  # 挂载容器内的目录
  volumeClaimTemplates:  # 数据卷模板
  - metadata:   # 数据卷描述
      name: www  # 数据卷name
      annotations:  # 数据卷的注解
        volume.alpha.kubernetes.io/storage-class: anything  # s
    spec:   # 数据卷的规约
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi  # 需要的存储资源
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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

# 查看 service 和 statefulset => sts
kubectl get service nginx
kubectl get statefulset web

# 查看 PVC 信息
kubectl get pvc

# 查看创建的 pod，这些 pod 是有序的
kubectl get pods -l app=nginx

# 查看这些 pod 的 dns
# 运行一个 pod，基础镜像为 busybox 工具包，利用里面的 nslookup 可以看到 dns 信息
kubectl run -i --tty --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh
nslookup web-0.nginx
1
2
3
4
5
6
7
8
9
10
11
12
13
14

扩容/缩容

$ kubectl scale sts web --replicas=5

# 缩容
$ kubectl patch statefulset web -p '{"spec":{"replicas":3}}'
1
2
3
4

更新

statefulset 有两种更新方式 RollingUpdate 和 OnDelete，默认采用RollingUpdate 方式

# 镜像更新（1.23版本还不支持直接更新 image，需要 patch 来间接实现） 也就是直接改sts yaml文件
kubectl patch sts web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:1.9.1"}]'
1
2

RollingUpdate->金丝雀发布

statefulset 管理的pod 命令和deployment 不同, deploy 后缀是uuid，statefulset 管理的pod 后缀从0 开始递增，也是基于这个特性，可以通过设置 partition 的值来实现灰度发布

  updateStrategy:
    rollingUpdate:
      partition: 0  # 这里设置值越高, 自动更新的容器越少，设置为0,有修改就全部更新
    type: RollingUpdate
1
2
3
4

OnDelete

  updateStrategy:
    type: OnDelete  # 设置为OnDelete后，有更新后，先删除原有容器，才会更新新的容器
1
2

删除

# 删除 StatefulSet 和 Headless Service
# 级联删除：删除 statefulset 时会同时删除 pods
kubectl delete statefulset web
# 非级联删除：删除 statefulset 时不会删除 pods，删除 sts 后，pods 就没人管了，此时再删除 pod 不会重建的
kubectl deelte sts web --cascade=false
# 删除 service
kubectl delete service nginx
1
2
3
4
5
6
7

DaemonSet

DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

• 日志收集，比如 fluentd，logstash 等
• 系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
• 系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd  
spec:
  template:
    metadata:
      labels:
        app: logging  
        id: fluentd
      name: fluentd   
    spec:
      containers:
      - name: fluentd-es
        image: agilestacks/fluentd-elasticsearch:v1.3.0
        env:
         - name: FLUENTD_ARGS
           value: -qq
        volumeMounts:
         - name: containers
           mountPath: /var/lib/docker/containers
         - name: varlog
           mountPath: /varlog
      volumes:
         - hostPath:
             path: /var/lib/docker/containers
           name: containers
         - hostPath:
             path: /var/log
           name: varlog
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

其他命令和上面sts deploy 差不多

节点选择器

DaemonSet 会忽略 Node 的 unschedulable 状态，有两种方式来指定 Pod 只运行在指定的 Node 节点上：

• nodeSelector：只调度到匹配指定 label 的 Node 上
• nodeAffinity：功能更丰富的 Node 选择器，比如支持集合操作
• podAffinity：调度到满足条件的 Pod 所在的 Node 上

nodeSelector

#先为 Node 打上标签
# kubectl label nodes k8s-node1 svc_type=microsvc
# 配置后，可以通过给node 添加标签来自动添加删除 daemonset 服务
#然后再 daemonset 配置中设置 nodeSelector
spec:
  template:
    spec:
      nodeSelector:
        svc_type: microsvc
1
2
3
4
5
6
7
8
9

nodeAffinity

nodeAffinity 目前支持两种：requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution，分别代表必须满足条件和优选条件。

比如下面的例子代表调度到包含标签 wolfcode.cn/framework-name 并且值为 spring 或 springboot 的 Node 上，并且优选还带有标签 another-node-label-key=another-node-label-value 的Node。
1
2
3

podAffinity

podAffinity 基于 Pod 的标签来选择 Node，仅调度到满足条件Pod 所在的 Node 上，支持 podAffinity 和 podAntiAffinity。这个功能比较绕，以下面的例子为例：
如果一个 “Node 所在空间中包含至少一个带有 auth=oauth2 标签且运行中的 Pod”，那么可以调度到该 Node
不调度到 “包含至少一个带有 auth=jwt 标签且运行中 Pod”的 Node 上

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:  # 将相关pod放在一起
      requiredDuringSchedulingIgnoredDuringExecution:  # 硬限制条件，必须满足才能调度到对应pod
      - labelSelector:
          matchExpressions:
          - key: auth
            operator: In
            values:
            - oauth2
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:  # 将相关标签的pod 分散开
      preferredDuringSchedulingIgnoredDuringExecution: # 软限制权限, 没有满足的条件，就当这个配置不存在
      - weight: 100
        podAffinityTerm:  # 定义具体反亲和性条件
          labelSelector:
            matchExpressions:
            - key: auth
              operator: In
              values:
              - jwt
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: pauseyyf/pause
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

滚动更新

ds 的默认滚动更新策略时RollingUpdate ，但是生产环境中不建议使用 RollingUpdate，建议使用 OnDelete 模式，这样避免频繁更新 ds

 # 默认配置
 updateStrategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate
    
 # 建议配置
  updateStrategy:
    type: OnDelete
1
2
3
4
5
6
7
8
9
10

HAP

Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。

• 控制管理器每隔30s（可以通过–horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况
• 支持三种metrics类型
  • 预定义metrics（比如Pod的CPU）以利用率的方式计算
  • 自定义的Pod metrics，以原始值（raw value）的方式计算
  • 自定义的object metrics
• 支持两种metrics查询方式：Heapster和自定义的REST API
• 支持多metrics

通常用于 Deployment/StatefulSet，不适用于无法扩/缩容的对象，如 DaemonSet

开启指标服务

kubectl top pod 相关命令需要metrics-server 服务来支撑

# 下载 metrics-server 组件配置文件
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml

# 修改镜像地址为国内的地址
sed -i 's/egistry.k8s.io\/metrics-server/registry.cn-hangzhou.aliyuncs.com\/google_containers/g' metrics-server-components.yaml

# 修改容器的 tls 配置，不验证 tls，在 containers 的 args 参数中增加 --kubelet-insecure-tls 参数

# 安装组件
kubectl apply -f metrics-server-components.yaml

# 查看 pod 状态
kubectl get pods --all-namespaces | grep metrics

1
2
3
4
5
6
7
8
9
10
11
12
13
14

测试方案

实现 cpu 或内存的监控，首先有个前提条件是该对象必须配置了 resources.requests.cpu 或 resources.requests.memory 才可以，可以配置当 cpu/memory 达到上述配置的百分比后进行扩容或缩容

创建一个 HPA：
1. 先准备一个好一个有做资源限制的 deployment
2. 执行命令 kubectl autoscale deploy nginx-deploy --cpu-percent=20 --min=2 --max=5
3. 通过 kubectl get hpa 可以ku获取 HPA 信息

测试：找到对应服务的 service，编写循环测试脚本提升内存与 cpu 负载
while true; do wget -q -O- http://<ip:port> > /dev/null ; done

可以通过多台机器执行上述命令，增加负载，当超过负载后可以查看 pods 的扩容情况 kubectl get pods

查看 pods 资源使用情况
kubectl top pods

扩容测试完成后，再关闭循环执行的指令，让 cpu 占用率降下来，然后过 5 分钟后查看自动缩容情况
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16