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

近日见闻

1. Django 5.0 正式发布，作为运维开发，欢呼雀跃不为过！可喜可贺！--Django
2. 12月6日，谷歌宣布推出其认为规模最大、功能最强大的人工智能模型 Gemini。赶紧去围观体验下，用过记得回来交流下！--google
3. 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

这段代码核心逻辑就是：

1. 敲命令查Pods:
   • kubectl get pods --all-namespaces -o json 这一行，就像你平时敲命令查Pod状态一样，但是输出格式是json，方便代码处理。
   • subprocess.Popen 这个玩意，就是在代码里敲命令行，然后拿结果。
2. 解读结果:
   • 拿到结果后，先看有没有错误信息。有的话，直接打印出来。
   • 没错误的话，就读取那一堆json里的信息，一个个Pod查。
3. 找出问题Pod:
   • 查的时候，主要看Pod的状态。如果不是在“跑步”（Running）也没“成功完成”（Succeeded），那就得仔细看看了。
   • 然后检查那些状态细节，比如conditions（Pod运行状况的一些标志）和containerStatuses（容器的状态）。
4. 报告给企业微信:
   • 发现问题了，就用 send_alert_to_wechat 这个函数，按照企业微信要的格式，组装一条消息出来。
   • 然后通过网上发个HTTP的POST请求，把这消息扔给那个webhook_url，企业微信那边就能收到了。
5. 只报一次:
   • 遇到问题，报告一次就行，不用一个问题报好几遍。

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状态不对头。

核心逻辑就这么几步：

1. 连上你的Kubernetes集群:
   • 用 config.load_kube_config() 这行代码，就跟你平时在本地用kubectl搞事情一样，假设你的电脑已经有权限连Kubernetes集群了。
2. 检查Pod状态:
   • v1.list_pod_for_all_namespaces(watch=False) 这行代码就是在说，嘿Kubernetes API，把所有namespace命名空间（就是Kubernetes里面隔离资源的区）的Pod信息给我看看。
   • 然后这个代码遍历所有Pod，用 pod.status.phase 去看它的状态是不是“Running”。
3. 发现问题就报告:
   • 一旦发现哪个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 搞定算了。

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