02 如何让你的集群更加整洁一点

# 问题背景

首先，你有没有遇到过这样的情况

apiVersion: v1

kind: ConfigMap

metadata:

  name: test-cm

  namespace: default

  labels:

    test-label: test

  managedFields:

  - manager: kubectl

    operation: Apply

    apiVersion: v1

    time: "2010-10-10T0:00:00Z"

    fieldsType: FieldsV1

    fieldsV1:

      f:metadata:

        f:labels:

          f:test-label: {}

      f:data:

        f:key: {}

data:

  key: some value

这特么的一堆括号是什么东西？？？？？？

有什么用？？？？？？？？

其实是记录的迭代的信息。要说有啥用，其实真的没有啥用

# 结论

以 kubectl get no 场景为例，当集群节点非常多的时候，集群 pod 非常多的时候，建议优化关闭不需要的字段。

ServerSideApply=false

kubectl get 资源的执行过程，是以 500 个对象为一个分页，从 apiserver 到 etcd 进行一致性读操作，将全部分页读到本地 并显示；过程中，会 get 每个资源对象的 yaml。通过 kubectl get <资源> -v 9 可以看到详细执行过程。所以减少单个资源 对象的 yaml size，可以缩短 kubectl get 的执行时间。

# 优缺点

关闭 ServerSideApply featureGate (https://kubernetes.io/zh-cn/docs/reference/using-api/server-side-apply/ )，关闭 managedFields 更新。需要修改 apiserver 参数，期间 apiserver 会滚动更新，对生产业务无影响。

优点:

关闭之后，该字段不会更新，从而控制该字段导致的持续增长。针对新开集群操作后，可以避免后续 get 资源的时 候产生较大的数据量，造成 kubectl 缓慢。随开随用。

缺点:

在后续部署的时候，yaml 中无法携带 managedFields 字段，否则会 apply 失败。

关闭了之后你会发现：

apiVersion: v1

kind: ConfigMap

metadata:

  name: test-cm

  namespace: default

  labels:

    test-label: test

data:

  key: some value

哇擦，好整洁，但是只对新增的资源生效哦，不会对已有的资源有改变。