---
title: 02 如何让你的集群更加整洁一点
date: 2023-04-20 22:23:07
tags:
- kubernetes杂谈
categories:
- kubernetes杂谈
---

## 问题背景

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

```bash
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非常多的时候，建议优化关闭不需要的字段。

```bash
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失败。





关闭了之后你会发现：

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
  namespace: default
  labels:
    test-label: test
data:
  key: some value
```

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