first add

k8szatan/02 如何让你集群更整洁.md

@@ -0,0 +1,100 @@
+---
+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
+```
+
+哇擦，好整洁，但是只对新增的资源生效哦，不会对已有的资源有改变。