快速实现python脚本监控k8s-pod状态

近日见闻

Django 5.0 正式发布，作为运维开发，欢呼雀跃不为过！可喜可贺！--Django

12月6日，谷歌宣布推出其认为规模最大、功能最强大的人工智能模型 Gemini。赶紧去围观体验下，用过记得回来交流下！--google

Linus Torvalds 近日出席了 Linux 基金会的日本开源峰会，Linus 表示，自己的火爆脾气已经有所收敛。在吸取了一些教训之后，他已经不会再 “对一些公司竖中指” 了。--oschina

监控pod状态使用场景

设想一下这个场景，如果你想要快速实现监控k8s集群中pod状态，如果有非running的pod，直接发送钉钉、或者企微告警完成。如何最小成本实现？肯定不是搭建一套专业的监控系统。那么下面就用python脚本分分钟完成这个功能。

有哪些方式？

1.使用kubectl实现pod状态过滤

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状态告警

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不在“Running”状态，send_alert_to_wechat 函数就会被调用。

这个函数构造一个告警信息，然后通过 requests.post 发送给企业微信的webhook URL，这样就能在企业微信那边收到消息了。

区别有那些？

用脚本搞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 更新了，你的脚本可能就得重写。

所以呢：

如果你搞的系统得深度跟Kubernetes API勾兑，或者有一堆复杂的操作要处理，用Python客户端那套可能更合适。

如果你就想赶紧出个自动化脚本，不想折腾，那直接用 kubectl 搞定算了。

选哪个，看你的需求：得考虑安全、自动化的复杂程度、维护容易不，还有你们团队用啥顺手。