近日见闻
- Django 5.0 正式发布,作为运维开发,欢呼雀跃不为过!可喜可贺!--Django
- 12月6日,谷歌宣布推出其认为规模最大、功能最强大的人工智能模型 Gemini。赶紧去围观体验下,用过记得回来交流下!--google
- Linus Torvalds 近日出席了 Linux 基金会的日本开源峰会,Linus 表示,自己的火爆脾气已经有所收敛。在吸取了一些教训之后,他已经不会再 “对一些公司竖中指” 了。--oschina
监控pod状态使用场景
设想一下这个场景,如果你想要快速实现监控k8s集群中pod状态,如果有非running的pod,直接发送钉钉、或者企微告警完成。如何最小成本实现?肯定不是搭建一套专业的监控系统。那么下面就用python脚本分分钟完成这个功能。
有哪些方式?
1.使用kubectl实现pod状态过滤
代码语言:javascript复制def check_pods_status():
"""
使用kubectl命令检查所有Pods的状态,如果不是在正常状态列表,则发送告警,并且记录状态
"""
cmd = "kubectl get pods --all-namespaces -o json"
result = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
stdout, stderr = result.communicate()
if stderr:
print("执行kubectl命令时出错: {error}".format(error=stderr.strip()))
return
这段代码核心逻辑就是:
- 敲命令查Pods:
kubectl get pods --all-namespaces -o json
这一行,就像你平时敲命令查Pod状态一样,但是输出格式是json,方便代码处理。subprocess.Popen
这个玩意,就是在代码里敲命令行,然后拿结果。
- 解读结果:
- 拿到结果后,先看有没有错误信息。有的话,直接打印出来。
- 没错误的话,就读取那一堆json里的信息,一个个Pod查。
- 找出问题Pod:
- 查的时候,主要看Pod的状态。如果不是在“跑步”(Running)也没“成功完成”(Succeeded),那就得仔细看看了。
- 然后检查那些状态细节,比如conditions(Pod运行状况的一些标志)和containerStatuses(容器的状态)。
- 报告给企业微信:
- 发现问题了,就用
send_alert_to_wechat
这个函数,按照企业微信要的格式,组装一条消息出来。 - 然后通过网上发个HTTP的POST请求,把这消息扔给那个webhook_url,企业微信那边就能收到了。
- 发现问题了,就用
- 只报一次:
- 遇到问题,报告一次就行,不用一个问题报好几遍。
2.调用集群api实现pod状态告警
代码语言:javascript复制def check_pods_status():
"""
检查所有Pods的状态,如果不是Running,则发送告警
"""
try:
pods = v1.list_pod_for_all_namespaces(watch=False)
for pod in pods.items:
if pod.status.phase != "Running":
# 发送告警
send_alert_to_wechat(pod.metadata.labels.get('app'), pod.metadata.namespace, pod.metadata.name, pod.status.phase)
except ApiException as e:
print(f"Exception when calling CoreV1Api->list_pod_for_all_namespaces: {e}")
这段代码的主要作用就是定期检查你Kubernetes集群里面的Pod是不是都活蹦乱跳的,即状态是不是“Running”。如果不是,就往企业微信群里扔个告警,让人知道有Pod状态不对头。
核心逻辑就这么几步:
- 连上你的Kubernetes集群:
- 用
config.load_kube_config()
这行代码,就跟你平时在本地用kubectl搞事情一样,假设你的电脑已经有权限连Kubernetes集群了。
- 用
- 检查Pod状态:
v1.list_pod_for_all_namespaces(watch=False)
这行代码就是在说,嘿Kubernetes API,把所有namespace命名空间(就是Kubernetes里面隔离资源的区)的Pod信息给我看看。- 然后这个代码遍历所有Pod,用
pod.status.phase
去看它的状态是不是“Running”。
- 发现问题就报告:
- 一旦发现哪个Pod不在“Running”状态,
send_alert_to_wechat
函数就会被调用。 - 这个函数构造一个告警信息,然后通过
requests.post
发送给企业微信的webhook URL,这样就能在企业微信那边收到消息了。
- 一旦发现哪个Pod不在“Running”状态,
区别有那些?
用脚本搞Kubernetes自动化,区别应该有这些:
1. 直接用Python搞定一切:
玩这招,就是在你的代码里直接跟Kubernetes耍,用Python写个脚本啥的,不用搞那个 kubectl
。
- 优点:
- 整合溜: 可以把操作Kubernetes的动作搞进Python程序里。
- 活儿多,灵活: 复杂点儿的东西,直接用代码写,不用等
kubectl
搞定。 - 好改: 告警逻辑要调整?直接改代码就行,简单粗暴。
- 速度快: 和API对话可能比等
kubectl
的结果要快。
- 缺点:
- 学着费劲: 要学点儿Python和Kubernetes的骚操作,初学者可能头大。
- 依赖多: 得装Python和一堆库,搞不好还得更新维护。
2. 继续用 kubectl
命令行:
这招就是继续用传统的 kubectl
,写个shell脚本或者在Python里调用它,然后处理它吐出来的信息。
- 优点:
- 上手快: 对于那些天天用
kubectl
的老鸟来说,这种方式简单明了。 - 轻松: 没啥额外的负担,只要一个
kubectl
工具就行。 - 兼容好:
kubectl
一般会跟着集群升级,不用操心兼容问题。
- 上手快: 对于那些天天用
- 缺点:
- 效率低: 比起直接跟API说话,系统调用(就是运行
kubectl
)慢点儿。 - 解析麻烦: 得从
kubectl
的结果里摘信息,容易让脚本变复杂,也难改。 - 移植性差: 如果
kubectl
更新了,你的脚本可能就得重写。
- 效率低: 比起直接跟API说话,系统调用(就是运行
所以呢:
- 如果你搞的系统得深度跟Kubernetes API勾兑,或者有一堆复杂的操作要处理,用Python客户端那套可能更合适。
- 如果你就想赶紧出个自动化脚本,不想折腾,那直接用
kubectl
搞定算了。
选哪个,看你的需求:得考虑安全、自动化的复杂程度、维护容易不,还有你们团队用啥顺手。