Zlatan Eevee

如何自建一个自己的 cursor codebase？

Mon, 29 Dec 2025 08:11:12 +0800

使用过 cursor 做编程的同学，对于 cursor 的 code base功能一定不陌生。通过将代码的函数、类、逻辑块等转换为向量，然后通过向量计算，就可以快速找到代码中的相似代码。

基于此，我们可以在 cursor 里进行智能问答，例如给定一个 log 日志，让 cursor 基于 codebase 进行分析，给出可能的原因。cursor 会查询 codebase 中的代码（基于相似度，而非类似 grep 的精确查询），理解代码，并进行解答。

在做一些 Agent 的时候，我们通常会使用文档来作为知识库，进行专属领域内的知识解答，但是文档总是有穷尽的，不可能覆盖到方方面面。如果我们可以基于代码做知识库解答，把一些客户现场报错的 log 日志输入进去，让 AI 自动分析，给出可能的原因，这就可以大大提升我们的工作效率。

但是 cursor 或者其他的一些 ai IDE，通常都不提供这样的能力，所以我们需要自己来实现。

下面是基于 Agno 做的一个简单的 codebase 实现，注意，没有使用向量库，而是使用文本匹配。

import os
import subprocess
from typing import Optional
from textwrap import dedent

from agno.agent import Agent
from agno.models.google import Gemini
from agno.models.nvidia import Nvidia
from agno.models.openai import OpenAIChat
from agno.models.openai.like import OpenAILike


# ================= 配置部分 =================

# 你的代码仓库路径 (请修改为你本地代码的实际路径)
REPO_PATH = ""

# ================= 自定义工具函数 (Tools) =================

def search_codebase(query: str) -> str:
    """
    在代码仓库中执行全局搜索（类似 grep）。
    当你需要查找某个变量定义、错误提示字符串或函数名在何处出现时使用此工具。

    Args:
        query (str): 要搜索的字符串或正则表达式。

    Returns:
        str: 搜索结果，包含文件名、行号和匹配内容。
    """
    if not os.path.exists(REPO_PATH):
        return f"Error: Repository path '{REPO_PATH}' does not exist."

    print(f"🔍 [Tool] Searching for: '{query}'")
    try:
        # 使用 grep -rn 递归搜索并显示行号
        # -I 忽略二进制文件
        command = ["grep", "-rnI", query, "."]
        result = subprocess.run(
            command,
            cwd=REPO_PATH,  # 在仓库根目录下执行
            capture_output=True,
            text=True
        )

        output = result.stdout
        if not output:
            return "No matches found."

        # 限制输出长度，防止 Token 溢出
        lines = output.split('\n')
        if len(lines) > 50:
            return "\n".join(lines[:50]) + f"\n... (and {len(lines)-50} more lines)"
        return output
    except Exception as e:
        return f"Error executing grep: {str(e)}"

def read_file_segment(filepath: str, line_number: int, context: int = 10) -> str:
    """
    读取指定文件在特定行号附近的代码片段。

    Args:
        filepath (str): 文件路径（相对于仓库根目录）。
        line_number (int): 核心行号。
        context (int): 读取上下多少行作为上下文，默认为 10 行。

    Returns:
        str: 带有行号的代码内容。
    """
    full_path = os.path.join(REPO_PATH, filepath)
    print(f"📖 [Tool] Reading file: {filepath} around line {line_number}")

    if not os.path.exists(full_path):
        # 尝试模糊匹配，因为 grep 有时返回的路径格式可能不同
        return f"Error: File '{filepath}' not found."

    try:
        with open(full_path, 'r', encoding='utf-8') as f:
            lines = f.readlines()

        start_index = max(0, line_number - 1 - context)
        end_index = min(len(lines), line_number + context)

        result_lines = []
        for i in range(start_index, end_index):
            # 标记出报错的那一行，方便 AI 识别
            prefix = ">>> " if (i + 1) == line_number else "    "
            result_lines.append(f"{prefix}{i+1}: {lines[i].rstrip()}")

        return "\n".join(result_lines)
    except Exception as e:
        return f"Error reading file: {str(e)}"

# ================= Agno Agent 定义 =================

def create_code_analysis_agent():
    return Agent(
        #model=Nvidia(id="qwen/qwen3-235b-a22b"),
        model=Gemini(
          id="your gemini model id",
          project_id="your google project id",
        ),
        description="你是一个资深的云原生开发工程师，精通 Golang 和 Kubernetes 控制器模式。",
        instructions=dedent("""\
         你可以完成根据日志进行排障，也可以完成根据用户的问题，对代码进行分析，并输出有效的结论

         # 根据日志排障:
         你的目标是根据用户提供的日志，找出代码中的根本原因。
         **分析流程**：
         1. 提取日志中的`文件名`、`行号`和`错误关键信息`。
         2. 使用 `read_file_segment` 工具查看报错位置的代码。
         3. 仔细阅读代码。如果遇到不明来源的变量（特别是 Secret 名称、常量等），使用 `search_codebase` 全局搜索该变量的定义。
         4. 结合 Kubernetes 知识推理：比如 Secret 缺失意味着什么？它是如何被创建的？
         5. 最终输出清晰的中文报告：包含错误原因、代码证据链和可能的修复建议。

         # 代码分析:
         当用户询问关于“接口”、“API”、“功能模块”或“代码结构”的问题时，请遵循以下分析策略：

         1. **意图识别与策略选择**：
            - 如果用户问的是 **Go 语言层面的 Interface**（如“核心接口有哪些”）：
            - 动作：使用 `search_codebase` 搜索关键字 `type .* interface \{`。
            - 重点：关注 `pkg/` 目录下的核心定义，忽略 `vendor/` 或测试代码。
            - 如果用户问的是 **REST API / HTTP 接口**：
            - 动作：搜索路由定义关键字，如 `path`, `route`, `gin.Default`, `mux.NewRouter`, `RegisterWebHook` 或 `v1.`。
            - 重点：寻找 `cmd/` 入口或 `pkg/apiserver` 中的路由注册代码。

         2. **代码阅读与提取 (Deep Dive)**：
            - 找到相关文件后，使用 `read_file_segment` 读取接口定义及其**上方的注释文档**。
            - **必须**提取每个方法的注释（DocString），这是解释功能的关键依据。

         3. **内容生成要求**：
            - **不要**直接堆砌代码。
            - 请生成一份结构化的 Markdown 报告，格式如下：

            ### [接口/模块名称]
            **文件路径**: `pkg/xxx/xxx.go`
            **核心职责**: (一句话总结这个接口是做什么的)
            **包含方法**:
            - `MethodA()`: (功能描述)
            - `MethodB()`: (功能描述)

         4. **兜底策略**：
            - 如果搜索结果过多（超过 10 个），请先列出核心的 3-5 个接口，并询问用户是否需要展开特定模块。
            - 如果代码中没有注释，请通过方法名（Naming Convention）推断功能，并明确标注“（推断）”。
        """),
        # 将我们定义的 Python 函数直接传给 Agno
        tools=[search_codebase, read_file_segment],
        #debug_mode=True,
        #debug_level=2,
        markdown=True,        # 输出 Markdown 格式
    )

# ================= 主程序运行 =================

if __name__ == "__main__":
    # 1. 实例化 Agent
    agent = create_code_analysis_agent()

    agent.cli_app(
        user="User",
        emoji="✍️ ",
        stream=True,
        markdown=True,
    )

上面的代码，我们定义了两个工具函数，分别是 search_codebase 和 read_file_segment，分别用于在代码仓库中搜索代码和读取代码片段。

并且，Prompt 里面的 instructions 里面，我们定义了两个策略，一个是根据日志进行排障，另一个是根据用户的问题，对代码进行分析，并输出有效的结论。即面向了常见的两个场景，一是问题排查，二是代码走读。

用我开源的小工具topic来做个测试，运行效果如下：

Agno Agent 会主动调用 search_codebase 和 read_file_segment 两个工具，来获取代码信息。

获取代码后，会再提交个大模型进行分析，最终输出结果。

可以看到，对于这种大模型没有信息的代码仓库，也可以通过 codebase 进行分析。

k8s的域名解析总是需要coredns吗？

Wed, 18 Jun 2025 08:11:12 +0800

我们知道k8s的域名解析是通过coredns来完成的，但是，总是需要coredns吗？或者换个问法，所有dns请求都经过coredns吗？

答案：并不是，API Server就不是。

API Server通常是host network方式部署的，其nameserver来源自节点的/etc/resolv.conf，并不是coredns的 .10 地址。那么API Server是怎么解析cluster ip类型的域名呢？

在 Kubernetes 中，kube-apiserver 设计了一个 loopback resolver 是为了支持高可靠性和一致性的内部组件通信，特别是在需要通过自己的 API 与自己通信时。这种设计背后的核心思想包括以下几点：

支持可靠的自引用 kube-apiserver 本身需要处理一些会调用自身 API 的功能（例如 webhook、Admission Controller 或 API Aggregation）。通过 loopback resolver，kube-apiserver 可以在集群网络不可用或存在部分网络分区的情况下依然高效地与自己通信。

问题：如果 kube-apiserver 通过普通的 Service IP 访问自己，可能依赖 DNS 解析、kube-proxy 或网络插件，这些组件可能未完全运行或存在网络延迟/异常。解决：Loopback 直接将请求回路短路到本地，从而绕过外部网络依赖。

提升可靠性和性能 Loopback resolver 不需要经过集群的 Service 解析、负载均衡及 kube-proxy 开销，而是直接在本地完成请求，这大幅降低了延迟并减少了网络层次的开销。
支持集群初始化阶段在 Kubernetes 的启动过程中，kube-apiserver 是服务启动的核心。其他组件（例如 kube-proxy、coredns）可能尚未完全可用，这种情况下，kube-apiserver 不能依赖外部网络资源。通过 loopback resolver，可以确保即使在集群组件未完全就绪时，自身功能仍然可用。
避免复杂的网络配置问题 Loopback resolver 可以避免额外引入不必要的配置复杂性，例如确保 kube-proxy 和网络插件的双向可靠通信。

相关的代码实现可以参见 staging/src/k8s.io/kube-aggregator/pkg/apiserver/resolvers.go：

func (r *loopbackResolver) ResolveEndpoint(namespace, name string, port int32) (*url.URL, error) {
	if namespace == "default" && name == "kubernetes" && port == 443 {
		return r.host, nil
	}
	return r.delegate.ResolveEndpoint(namespace, name, port)
}

降本增效，下掉一台小主机

Fri, 08 Nov 2024 08:11:12 +0800

前情回顾：说说我的homelab homelab v2.0

家里之前是有2台Dell的optiplex小型机，最近盘算了下，其实完全没有用到（optiplex 5080 sff 4c24G + optiplex 7080 sff 12c64G），完全可以下掉一台。

比较理想的是留下来12c64G的这台，但是openwrt虚拟机在4c24G，PCI网卡也在这台机器上。如果要重新搞openwrt、重新配置clash，想想就觉得头大。

前两天有一个空闲的半天，突然想到：其实我不用重新安装openwrt，把4c24G机器上的ssd和4T盘，换到12c64G机器上，不就行了？

事实证明，确实可以，不过会有一些小问题，好在都能解决。

其一是由于4c24G机器安装的比较早，迁移后操作系统不认识新机器的网卡（连网卡都识别不到），因此一直网络不通。解决办法是升级系统，apt update后驱动就安装上去了，重新配置下网桥就OK了。

其二是由于之前闲着没事把2台proxmox组了集群，但是现在只剩下一台了，达不到qurom，集群不可用，连管控页面都进不去。解决办法是强行恢复成单节点模式。

其他就都比较顺利了，新机器资源比较充裕，因此可以把之前的虚拟机都调大规格。

现在是彻底的All In Boom了。只是空出来一台机器，用来做什么好呢？

域名迁移到Cloudflare上了

Thu, 11 Apr 2024 08:11:12 +0800

ieevee.com 这个域名是2017在Godaddy上购买的，当时价格还不贵，2年109.14人民币，但后来价格就越来越高，去年续费的时候已经是170.4HKD一年了。

最近看到有网友将域名迁移到了互联网活菩萨 Cloudflare 上，据说域名是成本价售卖。看了下，狗爹续费差不多要180块钱一年，而Cloudflare只要9.77刀一年，确实便宜了很多。

而且Cloudflare还有很多其他的服务，比如对象存储、Zero Trust、AI workers等等，而狗爹其实只是一家新加坡的小公司，并且狗爹的管理面板一直很迷（但狗爹的广告做的确实很好，经常在英超赛场上看到），迁移势在必行。

迁移过程凭记忆大概是这样的一个步骤：

在GoDaddy发起域名转移到其他域名商，这个时候Godaddy会提供一个验证码
到Cloudflare注册网站，并将域名转入，填写GoDaddy提供的验证码
到GoDaddy确认转出。默认是要等好几天的，可以到GoDaddy上手工转出下，立即就可以生效了。
确认DNS配置是否正常，实测Cloudflare迁移过去的DNS域名有错误，需要手工修正。

注意，Cloudflare默认是开启域名代理的，即解析域名时，是先解析到Cloudflare的代理，然后再由Cloudflare转发给实际的Real Server IP，理论上这样会提高安全性，也能提供global wide的就近访问，但是因为我的域名还有其他的用途，没办法使用代理，所以需要在域名管理里关闭代理。

我的域名还绑定了腾讯企业邮，迁移过程中几乎无任何感知，没有受到影响。

Ref：

將我的網域轉出 GoDaddy

homelab v2.0

Sat, 03 Feb 2024 08:11:12 +0800

前情回顾：说说我的homelab

前几年搬家，有机会重新布线，于是把家里的网络做了更新，有了homelab v2.0。

跟v1版本相比，最大的不同是将网件的WNDR4300改为了Optiplex 5050的一台虚拟机，加了一块网卡直通给虚拟机（软路由），增加一台H3C的wifi6路由器作为AP，同时所有需要有线接入的设备都接到一个H3C的二层交换机上。

配置软路由后，就可以配置Clash服务实现内外网分流了。外网服务器是一台香港的腾讯云轻量，带宽、时延都还不错。

新增加了一台Optiplex 5080，也安装了PVE，总的资源升级到了16C86G。

k8s从1.11版本逐渐升级到了1.23。由于1.24以后只能使用containerd，所以暂时就停留在1.23版本不再升级。

新增了一台PS5，但是发现PS上的游戏不是很对我的口味，这个游戏机基本沦为了netflix播放器，最近网飞在打击各种合租账号，现在也用不了了。这台PS5买的实在是不划算，使用率远不如switch。

新增了2台homepod mini，可以组成一对音箱，方便播放儿歌。

空调也接入了家庭网络，之前配置home-assistant，可以通过siri控制空调的开关，后来可能美的升级了，已经不能用了。

相比v1的homelab，v2增加了异地管理（- -!）。福州放了一个绿联云的NAS，为了方便观看电视，还用N1电视盒子装了armbian操作系统，安装PLEX挂载NAS的samba，这样就可以在电视上用PLEX观看、管理影视了。有的时候NAS可能关闭或者samba挂载掉线之类，需要穿梭过去到N1盒子查下问题，所以将N1挂到了tailscale上，这样我将本地的虚拟机也挂到tailscale上，就可以通过小局域网连接回去了。甚至可以PC加进来以后，从PC上远程查看Plex的内容，不过确实带宽有限，体验一般。

绿联云还出了电视端的App，安装到异地的另外一个电视上，直接通过绿联云观看。但是我买的绿联云型号比较早，App只能直接列表式查看文件，不能像Plex一样管理影视，看起来比较费劲（比如无法记录昨天看到哪里了）。新的型号是有这个功能的。另外还推荐极空间，他们的NAS有比较优秀的极影视。

2台小服务器接了UPS，防止断电，然而搬过来好几年了，从来没用上过，白白占了一大片空间。

服务部署太多，入口难以管理，所以用了一个开源的组件做了个Portal，管理起来方便一些。

一个Projeted Volume挂载service account引发的故障

Wed, 13 Dec 2023 08:11:12 +0800

最近接到一个业务报告的故障，提到argo创建的流水线运行失败，其中Pod去访问kube API Server时，偶发出现401认证不通过的问题。

API Server报错如下：

E1212 18:37:53.063390       1 claims.go:126] unexpected validation error: *errors.errorString
E1212 18:37:53.063583       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, Token could not be validated.]"

从报错上来看，的确没有通过API Server的认证。

func (v *validator) Validate(ctx context.Context, _ string, public *jwt.Claims, privateObj interface{}) (*apiserverserviceaccount.ServiceAccountInfo, error) {
	private, ok := privateObj.(*privateClaims)
	if !ok {
		klog.Errorf("jwt validator expected private claim of type *privateClaims but got: %T", privateObj)
		return nil, errors.New("Token could not be validated.")
	}
	nowTime := now()
	err := public.Validate(jwt.Expected{
		Time: nowTime,
	})
	switch {
	case err == nil:
	case err == jwt.ErrExpired:
		return nil, errors.New("Token has expired.")
	default:
		klog.Errorf("unexpected validation error: %T", err)
		return nil, errors.New("Token could not be validated.")
	}

先不看API Server的报错，看看业务使用的认证方式是什么。

通常业务使用的是service account来访问API Server，这种情况业务代码使用incluster kubeconfig就可以通过API Server的认证了；如果需要相应的权限，则给这个service account授予对应的RBAC权限即可。

这种用法的一个弊端是一旦授予出去了，service account的有效期就是永久的，回收很困难。

projected volumes提供了一种新的service account注入的方法： https://kubernetes.io/docs/concepts/storage/projected-volumes/#serviceaccounttoken

如下是一个示例：

apiVersion: v1
kind: Pod
metadata:
  name: sa-token-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: token-vol
      mountPath: "/service-account"
      readOnly: true
  serviceAccountName: default
  volumes:
  - name: token-vol
    projected:
      sources:
      - serviceAccountToken:
          audience: api
          expirationSeconds: 3600
          path: token

kubelet会为service account临时生成一个token，并将token注入到/service-account，token有效期为3600秒。你可以将token取出来，写到kubectl使用的config中，同样可以访问API Server。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: 「CA」
    server: https://kubernetes-apiserver.kube-system.svc.global.tcs.internal:6443
  name: global
contexts:
- context:
    cluster: global
    user: xxx
  name: xxx@global
current-context: xxx@global
kind: Config
preferences: {}
users:
- name: xxx
  user:
    token: 「token」

回到这个问题，既然怀疑这个token有问题，于是我们将Pod的启动命令改成 sleep infinity，等Pod启动后，将token拿出来放到config中，发现token没有任何问题，而且过期时间也足够。

陷入了沉思。

不过没关系，我们回过来看上面API Server的报错。我们使用的是k8s 1.22版本，只有ErrExpired会打印具体的报错，其他的错误只会傻傻的打印 *errors.errorString 。

func (c Claims) ValidateWithLeeway(e Expected, leeway time.Duration) error {
	if e.Issuer != "" && e.Issuer != c.Issuer {
		return ErrInvalidIssuer
	}

	if e.Subject != "" && e.Subject != c.Subject {
		return ErrInvalidSubject
	}

	if e.ID != "" && e.ID != c.ID {
		return ErrInvalidID
	}

	if len(e.Audience) != 0 {
		for _, v := range e.Audience {
			if !c.Audience.Contains(v) {
				return ErrInvalidAudience
			}
		}
	}

	if !e.Time.IsZero() && e.Time.Add(leeway).Before(c.NotBefore.Time()) {
		return ErrNotValidYet
	}

	if !e.Time.IsZero() && e.Time.Add(-leeway).After(c.Expiry.Time()) {
		return ErrExpired
	}

	return nil
}

从上面的代码来看，返回的错误情况有很多，但是最大的嫌疑，就是 ErrNotValidYet 。于是检查了各个节点的时间，发现果然时钟不同步，有一台服务器的时钟慢了2分钟。

那么是为什么呢？

原因很简单。证书签发后，如果是发给时钟慢的节点，会被API Server认为证书签发在未来的一个时间，所以还没生效，认证失败；为什么取出来token就好了呢？因为这个动作是人来做的，等把token取出来编辑好 kubeconfig，已经过去了2分钟，证书也就生效了。

btw，token是一个jwt，可以到 jwt.io 上检查，可视化做的非常好。

Ref：

Projected Volumes

老古董：Kindle 4 刷多看系统

Sun, 10 Dec 2023 08:11:12 +0800

好多年前买的Kindle 4，以为丢了，找了好久都没找到，这次搬家在一个抽屉最里面发现了，插上电居然还能用。

和现在用的文石leaf相比，kindle4的实体翻页键还是非常带感，厚厚的实体也很有分量，更像一本书。不过Kindle 4的中文支持的很奇怪，有些书的中文显示会很怪，有些又很正常，于是萌生了刷机的想法。

古早时期，Kindle是可以刷多看系统的，当时嗤之以鼻，嫌弃不够清真，现在多看还在，但已经不再提供Kindle系统了，只有多看阅读App了。

网络上去查找Kindle的刷多看说明，基本都会贴一个多看网站的链接，然而这个链接已经失效了。物是人非呀，一晃好多年了。

不过幸好还有互联网博物馆 web.archive.org ，还可以下载到刷机用的文件。你可以到这里看看之前的历史记录，从这里下载刷机包。

我也把多看刷机包上传到天翼云盘上了，可以你也有这样的老古董Kindle，不妨也刷一下。如今多看商城已经不可用了，但是系统还不错，对中文的支持也蛮好的，刷机后还是双系统，默认进多看，可以重启进Kindle原生系统。

https://cloud.189.cn/t/F3iaqyueya2m（访问码：9wwb）

刷机很简单，包里有说明。

如何使用Prometheus+Grafana监控Proxmox

Sat, 10 Sep 2022 08:11:12 +0800

prometheus-pve-exporter
Prometheus
Grafana

家里的软路由是跑在一台Dell的小机器（Optiplex 5050）上，使用Proxmox做的虚拟化，跑的Openwrt。前不久发现家里有时候网络会很卡顿，后来在Proxmox上看监控发现openwrt虚拟机在这个时间段内，CPU跑到了100%，难怪会非常卡。

我还有一台Dell的小机器（Optiplex 5080），也是Proxmox的虚拟化，两台Dell加起来一共有5个虚拟机，是时候上个监控了。

社区对于Proxmox的监控一般有 +Prometheus 和 +influxdb 两种方式，我这里采用的是 +Prometheus。

prometheus-pve-exporter

和Node exporter一样，也需要一个 Proxmox exporter，可以用prometheus-pve-exporter项目。prometheus-pve-exporter调用Proxmox的API采集指标，然后Prometheus再从 prometheus-pve-exporter 抓取metrics数据，最后通过Grafana展示。

prometheus-pve-exporter的配置可以使用配置文件，也可以使用环境变量。我这里传入了 PVE_USER/PVE_PASSWORD/PVE_VERIFY_SSL，用来调用Proxmox API时进行认证。由于是监控请求，因此建议在Proxmox上新建一个只读的用户，不要使用root。Proxmox新建用户很简单，在页面上操作即可，但给用户授权只能通过命令行进行。

如下，给用户 monitor@pve授予PVEAuditor权限。

pveum aclmod / -user monitor@pve -role PVEAuditor

注意，PVE_USER的格式是user@pve或者user@pam，两者的区别是，pve是proxmox的用户，比如我这里是2台Proxmox组成的集群，建立一个pve用户就可以访问2台Proxmox机器；pam是linux的用户，不同的Proxmox机器的用户名密码可能不同（Proxmox实际也是一台Linux机器）。

PVE_VERIFY_SSL需要设置为false，因为是自签的证书。

prometheus-pve-exporter可以直接启动，也可以容器化启动。因为后面要使用Prometheus来监控，所以我将prometheus-pve-exporter部署到了kubernetes上去，并创建了一个svc。Deployment的写法类似于：

docker run --name prometheus-pve-exporter -d -p 127.0.0.1:9221:9221 -v /path/to/pve.yml:/etc/pve.yml prompve/prometheus-pve-exporter

创建的svc：

apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: pve-exporter
  name: pve-exporter
  namespace: default
spec:
  ports:
  - name: pve-exporter-0
    port: 9221
    protocol: TCP
    targetPort: 9221
  selector:
    app: pvc-exporter-5050
  type: LoadBalancer

prometheus-pve-exporter启动后，可以通过http请求metrics：

http://{service loadbalancer ip}:9221/pve?target=1.2.3.4

一个prometheus-pve-exporter可以请求多个Proxmox(target)。

Prometheus

我这里使用的是Prometheus Operator，因此只要配置ServiceMonitor即可。endpoints配置2台Proxmox。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    k8s-app: pve-exporter
  name: pve-exporter
spec:
  endpoints:
  - interval: 30s
    params:
      target:
      - 1.1.1.1
    path: /pve
    port: pve-exporter-0
    scheme: http
  - interval: 30s
    params:
      target:
      - 1.1.1.2
    path: /pve
    port: pve-exporter-0
    scheme: http
  jobLabel: k8s-app
  namespaceSelector:
    matchNames:
    - default
  selector:
    matchLabels:
      k8s-app: pve-exporter

注意namespaceSelector和selector.matchLabels和上面创建的pve-exporter要匹配起来。

ServiceMonitor创建后，Prometheus Operator会自动刷新Prometheus配置，之后在Prometheus上可以查看pve的监控信息（例如pve_up）。

Grafana

Proxmox数据收集到Prometheus后，就可以通过Grafana展示了。这里我使用的是Proxmox via Prometheus by Pietro Saccardi。

至此，就可以比较方便的统一展示所有Proxmox虚拟机的状态了。

智能家居: 如何使用siri控制美的空调

Sat, 16 Jul 2022 08:11:12 +0800

home assistant
HACS
Midea AC LAN
HomeKit Bridge

杭州今年热出了天际，温度稳定达到了40摄氏度以上，家里的3台美的空调也是经常开开关关（开了冷，不开热）。美的空调是可以通过App“美的美居”控制的，不需要遥控器。貌似现在新发货的美的空调已经不带遥控器了。

不过，每次都要经历“找手机-解锁-找到美的美居-打开美的美居-等待启动-选中空调-打开”的一系列操作，很不友好。

能不能用siri来控制呢？“hey siri，打开客厅空调”，这样体验会更好。

这里我使用的是home assistant + Media AC LAN + HASS Bridge + Apple Home + HomePod mini 的方案。

home assistant

home assistant简称hass，一个开源的智能家居设备，能够控制非常多的设备（homepod,plex,kodi,etc），官方宣称支持1900多种设备。我这里用hass的目的是为了控制美的空调。

hass有2种安装方式，一种是使用树莓派，斐讯N1，玩客云等嵌入式设备，安装hass os，另一种是直接安装应用。

我这里是使用docker 安装的，具体可以参考官方这里。

官方给出了docker的安装命令，我这里部署到了家里的k8s上，config使用了一个nfs pvc，并且提供了一个svc供集群外访问。

docker run -d \
  --name homeassistant \
  --privileged \
  --restart=unless-stopped \
  -e TZ=MY_TIME_ZONE \
  -v /PATH_TO_YOUR_CONFIG:/config \
  --network=host \
  ghcr.io/home-assistant/home-assistant:stable

注意2点：

务必使用hostnetwork，实测如果使用overlay网络方案，评估手机的home app无法连接到hass。只是hass网页打开没这个限制。
privileged不是必须的。

Pod起来以后，使用Pod的IP或者使用svc IP打开 http://{ip}:8123，就可以进入hass的页面了。

HACS

接下来我们要安装 HACS。HACS是hass的社区市场，提供一些设备、主题的第三方资源。

如果hass是容器化安装的，HACS的安装可以参考Home Assistant 安装 HACS，安装后左边栏会多一个“HACS”的菜单。简单来说就是：

wget -q -O - https://install.hacs.xyz | bash -

重启hass，然后在hass配置界面添加集成HACS即可。

注意，HACS只是一个“市场”，在HACS上添加的集成，其实是只做了下载，真正的管理还是要到hass的配置-设备与服务界面。

Midea AC LAN

Midea AC LAN可以通过本地局域网控制你的美的空调。

这个插件可以自动配置，其他插件使用起来会繁琐一些。安装很简单，在HACS中搜索’Midea AC LAN’并安装就可以。

安装后，到hass的配置-设备与服务-添加集成，搜索Midea AC LAN，添加新设备，选择auto方式，然后插件会自动发现家里的空调，依次添加即可。

如果家里有多台美的空调，由于自动发现的是一个序列号，需要自己挨个开关下，看看各自对应的是什么，并且重命名为对应的房间，例如我这里的“客厅”。注意一定要重命名，因为后面的siri控制需要使用。

到这里，我们就可以通过hass控制家里的美的空调了。

HomeKit Bridge

在hass配置界面，添加新集成“HomeKit”，注意不要选择”HomeKit控制器”。前者的作用是将hass作为一个设备加入到HomeKit，后者是让hass去控制HomeKit设备。我们这里是为了让siri去控制美的空调，所以需求是前者。少数派的这篇文章说的比较清楚。

安装后，需要进行配置。选择bridge+exclude模式。

接下来选择要排除的实体，我们只是想用siri去控制空调的开关和简单设定，一些舒适模式、ECO模式平时也很少用到，所以在这里要把他们排除，免得HomeKit这里太乱。我这里只保留了各个房间的控制。

完成后，hass会有一个提示，点开是一个二维码，用手机的Apple Home扫码，可以添加这个设备。这里要注意，如果前面Pod使用overlay网络模式，添加会失败。

添加后，在Home就可以看到3个空调了。如果在Home上看到的命名比较乱，可以在设备图标上右键设置，重命名下。

配置好之后，就可以使用siri来控制了。实测可以打开、关闭某个空调，设置空调的模式、温度、风量等等，还是比较方便的。

istio: 如何对istio数据平面进行benchmark

Mon, 27 Jun 2022 08:11:12 +0800

背景介绍
准备
tools install
- fortioclient
- fortioserver
测试
总结
Ref

背景介绍

istio在应用时，会遇到的2个典型质疑是：

istio增加了单独的数据平面，从传输的角度来说增加了2跳，势必会带来latency的增加。那么latency的增加到底是多少呢？
proxy容器需要实现数据面的报文劫持、转发，以及一些策略的实施，其需要的cpu、内存，是多少呢？

要回答这些问题，就要对istio的数据面进行量化。 istio社区提供了一个工具来进行具体的测试：istio tools perf benchmark

为什么不需要对控制面进行量化呢？主要原因是数据面是O(n)的空间复杂度，而控制面几乎是O(1)的空间复杂度。另外一个原因是目前istio的遥测、限流等策略，均为envoy实现，不再交由mixer组件处理，因此集群规模提升后对控制面来说变化不大。

准备

istio tools perf benchmark需要读取Pod的监控信息，因此部署istio时，需要增加Prometheus组件。具体参考Prometheus安装。

tools install

安装参考 readme即可。

注意：

资源需求比较多，要求至少32 cpu、4个node。建议使用完善的生产集群，确保硬件资源充裕。
测试套依赖python3/pip3/pipenv，所以最好是在有网环境进行安装，我这里选择的是本地PC；若离线安装，可能会遇到一些镜像源获取不到的问题。
不要在docker环境中安装，测试套运行过程中会使用docker执行一些命令，如果在docker中安装会执行失败。

安装后，将在namespace twopods-istio中部署2个Deployment：fortioclient/fortioserver。下面简要说明下。

fortioclient

Deployment的编排文件请见deployment fortioclient。Pod的编排文件请见pod fortioclient

来看 Pod fortioclient。其包括4个container和1个init container：

captured：运行nighthawk客户端，客户端发出的报文会被proxy劫持
uncaptured：运行fortio客户端，客户端发出的报文不会被proxy劫持；监听9076端口，用于托管测试生成的json文件
shell：用于执行curl、jq等命令行
istio-proxy：proxy，istio注入的sidecar
init container：istio注入的init container，用于初始化iptables规则进行流量劫持。

注意Deployment 中设置的 excludeInboundPorts/excludeOutboundPorts的端口范围，8076/8077/8078/8081/端口是不走proxy的(具体查看fortioclient iptables规则)，这里代表测试的是原生（非mesh）的性能，用于作为baseline对比；而发往8079/8080端口的报文则会被iptables劫持给proxy。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fortioclient
  namespace: twopods-istio
..
  template:
    metadata:
      annotations:
        linkerd.io/inject: disabled
        sidecar.istio.io/inject: "true"
        sidecar.istio.io/interceptionMode: REDIRECT
        traffic.sidecar.istio.io/excludeInboundPorts: 8076,8077,8078,8081,9999
        traffic.sidecar.istio.io/excludeOutboundPorts: 80,8076,8077,8078,8081
        traffic.sidecar.istio.io/includeOutboundIPRanges: 10.222.0.0/16

fortioserver

Deployment的编排文件请见deployment fortioserver。Pod的编排文件请见pod fortioserver

fortioserver包括4个container和1个init container。

captured：nighthawk-test-server服务端，发给该服务的报文会被proxy劫持。具体来说，监听8079/8080/9080端口，均被劫持。
uncaptured：运行nighthawk-test-server服务端，发给该服务的报文不会被劫持。具体来说，监听8076/8077/8078端口，均不会被劫持。
shell：用于执行curl、jq等命令行
istio-proxy：proxy，istio注入的sidecar
init container：istio注入的init container，用于初始化iptables规则进行流量劫持。

fortioserver的excludeInboundPorts/excludeOutboundPorts的配置与fortioclient是一致的。

测试

运行测试用例

runner/runner.py 用来执行测试用例。具体参数参考run-performance-tests。

如下，将采用fortio作为压力源，并发连接设置为16，基准测试的qps依次设置为100,500,1000,2000,4000，每个基准测试用例持续时间为120s，遥测模式为telemetry-v2，针对如下场景进行测试：

both: 默认值，收发两端均通过sidecar
baseline: 基线，收发两端直连，均不通过sidecar
serversidecar: 只有server端启用sidecar

python runner/runner.py --conn 16 --qps 100,500,1000,2000,4000 --duration 120 --serversidecar --baseline --load_gen_type=fortio --telemetry_mode=v2-nullvm

这样，就可以得到5 * 3 个测试数据，从而比对不同qps下，直连、全mesh、服务端mesh场景下，时延的变化情况。

测试完毕后，在fortioclient pod的shell container中的 /var/lib/fortio/下，会生成15个json文件，数据参考fortio_json_data，该文件描述了本次基准测试的数据，如基准测试起始时间，P50/P90/P99，基准测试报文特征等。

注意，由于每次测试生成的文件都放在 /var/lib/fortio/，多次测试的数据会有干扰，建议测试前先清理下该目录。

收集指标信息

runner/fortio.py 用来收集基准测试数据、监控指标数据。具体参数参考gather-result-metrics

fortio.py依赖 fortioclient uncaptured(9076端口)、Prometheus，需要确保本地能够访问这两个地址。

我这里使用了kubectl port-forward的方式。也可以直接访问url，注意FORTIO_CLIENT_URL、PROMETHEUS_URL设置为正确的值即可。

kubectl -n twopods-istio port-forward svc/fortioclient 9076:9076 &
kubectl -n istio-system port-forward svc/prometheus 9090:9090 &

export PROMETHEUS_URL=http://localhost:9090
export FORTIO_CLIENT_URL=http://localhost:9076

配置好后，执行下面的命令。

python ./runner/fortio.py $FORTIO_CLIENT_URL --prometheus=$PROMETHEUS_URL --csv StartTime,ActualDuration,Labels,NumThreads,ActualQPS,p50,p90,p99,p999,cpu_mili_avg_istio_proxy_fortioclient,cpu_mili_avg_istio_proxy_fortioserver,cpu_mili_avg_istio_proxy_istio-ingressgateway,mem_Mi_avg_istio_proxy_fortioclient,mem_Mi_avg_istio_proxy_fortioserver,mem_Mi_avg_istio_proxy_istio-ingressgateway

fortio.py 会调用kubectl将json文件拷贝到本地的tmp目录，并依次处理目录下的json文件。

注意，由于每次收集指标时，拷贝的文件都放在相同的tmp 目录(macos)，多次测试的数据会有干扰，建议测试前先清理下该目录。

执行后，会生成一个json文件和一个csv文件。csv文件参考tmpld48kepv.csv。

通过简单的数据分析，可以发现，both/serveronly模式下，相对baseline，其P50时延增加了基本不超过5ms，P99不超过8ms。

在一些对时延要求相对宽松的场景下，增加8ms可能不是一个很致命的问题，但在一些严苛的场景（例如结算页），留给业务处理的时间可能就几十ms（包括业务逻辑、访问数据库、访问缓存），proxy增加的延迟还是比较严重的。

可视化

graph_plotter/graph_plotter.py 可以用来对数据进行可视化。具体参数参考usage-and-example-plot。

接上面的示例，我们设置横轴(x_axis)为qps，横轴的点为qps列表(query_list) [100,500,1000,2000,4000] ，纵轴(graph_type)为P90的延迟数据，进行绘图。

python3 ./graph_plotter/graph_plotter.py --graph_type=latency-p90 --x_axis=qps --telemetry_modes=v2-nullvm_serveronly,v2-nullvm_baseline,v2-nullvm_both --query_list=100,500,1000,2000,4000 --query_str=NumThreads==16 --csv_filepath=/var/folders/sf/ndqwtn_105n5c4pfcg9kh1rc19706f/T/tmpld48kepv.csv --graph_title=./graph_plotter/example_plot/plotter_output4.png

绘制图形如下，可以直观的看到both和serveronly模式相对baseline的时延增加情况。

将纵轴改为服务端的cpu使用率 --graph_type=cpu-server，可以查看到随着qps的提高，pod的cpu使用率有着明显的提升。

总结

istio tools perf benchmark 通过比较巧妙Deployment编排，设计了baseline/serveronly/both等测试场景，能够形象的对istio 数据面进行基准测试，并对延迟、cpu使用率、内存使用率进行度量。