个人观点：非常不喜欢这种被限制的方式， 就算是 aop ， 那么也要精简，而不是做全。
让 gin 、echo 、iris 能够接入就行，或者参考 kratos 做成插件形式。

static pod 是不受 kubernetes 调度的， 属于 Kubelet 直接管理。 只有少数情况下需要用， 这个是和节点绑定的
1.只有要在宿主机运行的 daemon
2. 需要和节点绑定的 Pod
直接和 kubernetes 节点相关的修改和组件 需要, 其他情况下用这个基本要被开除。

xsession 错误大多数并不是很重要， 基本上它是一个相当低级的 X11 的错误日志，xwindows Linux 远程桌面的东西。
定期删除

k8s 是包含服务注册、降级、也是很多服务配置中心以及元数据存储的地方
滴滴技术在文章里写原地大版本升级，艺高人胆大，链接在下
https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw

K8s 跨版本升级是很危险的， 除非集群里 没有任何第三方的 Operator 完全是自研的 而且充分考虑到兼容度， 代码全部改过了，你无法保证各种依赖的兼容性。
一般都是升级到高一个版本，中间版本慢慢过渡，1.12 到 1.20 属于艺高人胆大。

滴滴技术自己写的 k8s 升级
https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw

像大厂商都会自建 IDC, 不然投资人为什么愿意在当年投资那么多钱给它， 你只有花得多，才会有更多的投资。

k8s 跨版本升级是有很多坑的， 像滴滴 K8s 版本这么久还没升级估计就是在做很多测试。 结果版本还升级错了。

@pandaPapa 如果是集群所有的 master 高可用节点都挂了, 想调度都调度不了。这种错误真的是极其少见。

基础设施才会导致这种大规模问题，否则软件版本回滚还是很快的。难道降本增效到了深水区了。

已经在一些网站上公布了，是因为 K8s 版本升级升错了，造成基础设施问题。
https://www.oschina.net/news/268635

telepresence 或者 kt-connect 都可以将集群内的请求流量劫持到本机进行处理
https://github.com/telepresenceio/telepresence
https://github.com/alibaba/kt-connect

我有时候看这个 low level learning 的油管博主，他有一些粗浅的入门介绍。
https://www.youtube.com/@LowLevelLearning/search?query=arm

@baobao1270
赞同你写的，这上面很多人都在凭空想象，不去多看看基本密码学和网络安全协议设计的书 或 RFC 标准。