运维大规模K8S集群注意事项

序言

闲来无事,一片混沌,想不清思不断,改变好像来自于各个方面,有的时候是内部的冲突,有的时候是外部的竞争,然而,大部分情况下,一旦错过,就已经没得选了。

尴尬的处境,需要有强大的抗压能力,可能是环境带来的,可能是别人带来的,而大部分情况下,都是自己带来的。

运维大规模K8S集群的注意事项

1 pod无法启动

有几个组件的pod,有的是deployment,有的是cronjob,运行了380多天了,突然有一天,这个pod就启动不起来了,一直在crash中,无法启动,第一反应是干啥,对,你想对了,删除这个pod重启一下,发现依旧无法启动。

重启在关键时刻居然失效了,那么就只能看一下日志了。

nginx 复制代码
kubectl logs -n sre podname
#日志显示内容
argument list too long

好熟悉的报错信息,似曾相识,好像在进行删除大量文件的时候,也见过这个报错。最后一通搜索发现了是pod里面默认注入了的环境变量太多,从而导致pod无法启动。

javascript 复制代码
#在pod的spec里面配置
enableServiceLinks: false

在k8s的默认配置中,会将svc的相关信息注入到pod中,而在pod进行启动init进程的时候,环境变量会作为参数传递进入,从而导致pod无法启动。

在容器启动的时候,第一个进程就是init进程,可能是我们自己的业务进程,那么当进程进行fork后,就是exec啥的装载用户进程,而这个参数的长度是2M,一旦超过,那么这个容器就永远启动不起来了。

检查了一下同命名空间的pod数量,大概3000个样子,而每个都有3个svc,从而导致进入一个pod之后,就有好几万个关于svc的环境变量。。。有的时候,默认配置并不一定是好的,而且社区好像也不愿意进行修改默认值,因为违反了他们原则。

这个就让我想起来当初我做helm chart的时候,进入pod,在无意中看了一眼环境变量,然后发现有很多的环境变量,感觉很烦,然后就加入了这个配置,想来还是好的,要不然大规模的生产环境pod都要全部升级一遍,那工作量,想想就够了。。。别说去真的升级了。

cs 复制代码
#env参数就是环境变量的大小,在内核中编译的,无法修改
int execve(const char *pathname, char *const argv[],
 char *const envp[]);

当你的容器有好几个sidecar容器的时候,你需要去查看对应容器的日志,默认的容器可能还没启动。。。例如你还有个init容器。

无论是deployment,statfullset还是cronjob,在默认情况下,都会注入这个环境变量。所以,如果你不想莫名其妙的出问题,禁止这个吧,因为大部分情况下,这个环境变量毫无用处。

2 pod label不要随便打

当你使用helm chart来进行资源管理的时候,千万要记住,pod的label不要随便打,当你需要对一个pod打label的时候,最好好是永远不变的一个label,这样的是可以设置的。

但是如果你打了一个在pod的生命周期中会不断变化的label,那么就在label的值发生变化的时候,就需要修改,然后你就会发现一个非常悲催的事,这个pod label是无法修改的。

cs 复制代码
#helm upgrade的时候报错信息
Field is immutable

在进行设计产品的时候,每一个操作,都要考虑生命周期管理,其中修改是最常见一种操作,而helm说,pod label不支持修改,你只能重建,对于那种很轻松重建的还好,但是如果是那种比较重要的,只能一直upgrade的应用来说,这日子没法过了,再也不能好好的滚动更新了。。。服务中断了解一下。

你猜我为什么知道这个大坑呢,因为我就是设计那个BUG的人。。。急匆匆上线,急匆匆扩大规模,到了一定的时间段,卧槽。。。前任挖坑,后人乘凉

其实有的时候,也是一个权衡,没事干的时候,打什么label呢,还要各种修改chart的template,纠结的不行,其实打label的原因有没有可能是为了适配监控,然后你会发现如果一开始不做艰难的抉择,到后面也会很痛苦,因为面临着重建而带来的服务中断的风险,但是。。。如果你架构上面做了双k8s的架构那还有挽救的可能,否则,你将毫无办法。

风言风语

有的时候,你不踩一些坑,你根本记不住那些需要避开的地方,可能看过,也可能没注意过,反正是踩中了,经历过才懂,否则都是懵懂。

坑多了,其实压力也蛮大的,因为毕竟自己设计的自己运维,而且是大规模的集群,升级起来何其痛苦,要通知各种人,各种防御手段,一想到这,我就准备把同事嘎了,怎么他们就没阻止我。

那么问题来了,如果你知道一个风险,但是你什么都做不了,那么你还会一如既往的去努力付出吗?如果不知道这个风险,依旧懵懵懂懂的,那么一旦风险来临,你又将如何面对,你喜欢哪种?是知道还是不知道。。。知道的人可能更加痛苦一点吧,因为做不了任何改变。。。首先是失望,当你发现不能改变的时候,慢慢就演变成了绝望?还是能及时的调整心态,然后。。。享受当下?

你以为知道,只是你以为知道,其实你不知道还有很多很多,你知道的只是别人让你知道的,就像你以为是你选择了玩游戏,其实可能是游戏的设计者让你按时的去玩游戏,就像是你以为你刷视频是休息一下,其实可能是视频的设计者引诱你去刷,只是一个时间黑洞而已,所有的广告都在强化你的认识,你以为是你选的,可能并不是。。。

树立一个所谓的价值观和愿景,其实有没有可能是他们自己也不知道怎么玩了,树立一个虚拟的目标,来让无欲无求的自己能涌起一股激情。。。本质上其实也是毫无意义。

信息围城。。。想清楚自己想做啥,想清楚那就去追求自己想做的,毕竟时光不等人。世界尽头的咖啡,苦而涩,味甘甜。

相关推荐
dessler38 分钟前
Docker-run命令详细讲解
linux·运维·后端·docker
群联云防护小杜1 小时前
如何给负载均衡平台做好安全防御
运维·服务器·网络·网络协议·安全·负载均衡
PyAIGCMaster1 小时前
ubuntu装P104驱动
linux·运维·ubuntu
奈何不吃鱼1 小时前
【Linux】ubuntu依赖安装的各种问题汇总
linux·运维·服务器
aherhuo1 小时前
kubevirt网络
linux·云原生·容器·kubernetes
zzzhpzhpzzz1 小时前
Ubuntu如何查看硬件型号
linux·运维·ubuntu
蜜獾云1 小时前
linux firewalld 命令详解
linux·运维·服务器·网络·windows·网络安全·firewalld
陌北v12 小时前
Docker Compose 配置指南
运维·docker·容器·docker-compose
只会copy的搬运工2 小时前
Jenkins 持续集成部署——Jenkins实战与运维(1)
运维·ci/cd·jenkins
catoop2 小时前
K8s 无头服务(Headless Service)
云原生·容器·kubernetes