Files
baim0-learn/k8sFunny/02 如何让你集群更整洁.md
T

100 lines
2.1 KiB
Markdown
Raw Normal View History

2023-09-16 20:09:12 +08:00
---
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
```
哇擦,好整洁,但是只对新增的资源生效哦,不会对已有的资源有改变。