Claude AI Rules
# 生产环境运维 — Claude 工作规范 |
# 生产环境运维 — Claude 工作规范 |
HCL AppScan(原名IBM Security AppScan)是原 IBM 的 Rational 软件部门的一组网络安全测试和监控工具,2019 年被 HCL 技术公司收购。AppScan 旨在在开发过程中对 Web 应用程序的安全漏洞进行测试。
OCP (Open Claude Proxy) 的开源项目,核心功能是: 将你的 Claude Pro/Max 订阅转换为一个标准的 OpenAI 兼容 API,从而让你在不需要支付额外 API 费用的情况下,在各种 IDE 和 AI 工具中使用 Claude 模型 。
它利用 已有的 Claude 订阅(Pro 或 Max),通过代理转换为 OpenAI 格式的接口,实现 0 额外 API 成本 。
多端共享 :支持 LAN(局域网)共享,一个订阅可以供全家人、多台设备或多个 IDE 同时使用。
广泛兼容性 :支持任何可以配置 OPENAI_BASE_URL 的工具,如 Cline、Cursor、Aider、Continue.dev 等。
局域网多用户管理 (v3.7.0+) : 支持创建多个 API Key,每个用户拥有独立的令牌和使用量统计,支持一键撤销。
一键配置工具 (ocp-connect) :客户端只需一条命令即可自动检测并配置所有主流 IDE。
请求配额控制 (v3.8.0+) :支持按 Key 设置日/周/月请求限制(例如限制小孩每天 20 次)。
SSE 心跳检测 (v3.12.0+) :针对长时间推理任务发送心跳包,防止 IDE 因超时而断开连接。
高度对齐 (Alignment) :项目严格遵循 cli.js (Claude Code 的核心)的行为,确保稳定性并防止接口漂移。
服务端要求
操作系统 :macOS 或 Linux(不支持 Windows,因为涉及系统服务管理)。
运行环境 :Node.js 22.5+,git。
核心依赖 :必须安装并登录 Claude CLI。
安装 Claude 并登录
npm install -g @anthropic-ai/claude-code |
安装 OCP
git clone https://github.com/dtzp555-max/ocp.git |
单机模式(默认)启动 Proxy ,此模式只能在本地使用 OCP,API URL 为 http://127.0.0.1:3456/v1
node setup.mjs |
局域网模式 (LAN Mode) 。地址监听在 0.0.0.0:3456 ,允许其他设备通过网络访问
export OCP_ADMIN_KEY=$(openssl rand -base64 32) # 设置管理员 Key,建议写入 ~/.zshrc 或 ~/.bashrc |
查看 Proxy 状态(usage + health)
$ ocp status |
以下状态表示 Claude Cli 登录成功,可以看到 当前 Plan、Session utilizaiont/Percent、limit 等信息
$ ocp status |
查看 OCP 使用量信息
$ ocp usage |
浏览器访问 http://<IP>:3456/dashboard 可视化监控请求历史和计划用量。

添加子密钥(子用户)
$ ./ocp keys add external-system |
查看子密钥状态
ocp usage --by-key |
AI Agent 与浏览器的深度集成方案全景,以下为目前的四种主流方案
┌──────────────────────────────────────────────────────────────────────┐ |
Claude Code 通过 Claude in Chrome 浏览器扩展集成,从 CLI 或 VS Code 扩展获得浏览器自动化能力。可以测试 Web 应用、用控制台日志调试、自动化表单填写,以及从网页提取数据。Claude 为浏览器任务打开新标签页并共享浏览器登录状态,可以访问所有你已登录的网站。浏览器操作在可见的 Chrome 窗口中实时运行。
┌────────────────────────────────────────────────────────────────────┐ |
Claude for Chrome 完整安装流程
Claude for Chrome 包含了以下权限模式:
┌─────────────────────────────────────────────────────────────────┐ |
Claude 产品矩阵全景
| 产品形态 | 适用场景 | 适合你的工作 |
|---|---|---|
| Claude.ai (Web/App) | 通用对话、方案设计、知识问答 | 架构设计讨论、概念学习、文档撰写 |
| Claude Code (CLI) | 终端内代理式编程 | 核心推荐:代码编写、调试、远程运维 |
| Claude API | 集成到自有系统/脚本 | 自动化运维、自定义 Bot、CI/CD 集成 |
| Claude in Chrome | 浏览器自动化代理 | AWS Console 操作、Web 控制台批量操作 |
| Desktop App + MCP | 桌面端 + 工具扩展 | 本地文件操作、多工具协同 |
Claude Code 与 IDE 集成的完整图谱
┌─────────────────────────────────────────────────────────────────────┐ |
官方支持的 IDE 一览
官方插件主要支持两大阵营: VS Code 扩展 (最完善,同样适用于 Cursor IDE,需要 VS Code 1.98.0+)和 JetBrains 插件 (IntelliJ IDEA、PyCharm、WebStorm、GoLand 等)。
| 编辑器/IDE | 集成方式 | 推荐度 | 适合人群 |
|---|---|---|---|
| VS Code | 官方扩展(最完善) | ⭐⭐⭐⭐⭐ | DevOps 工程师首选 |
| Cursor | 官方扩展(同 VS Code) | ⭐⭐⭐⭐⭐ | 喜欢 AI 原生体验 |
| JetBrains 系列 | 官方插件 | ⭐⭐⭐⭐ | Python/Java 开发者 |
| Neovim / Vim | 内嵌终端运行 CLI | ⭐⭐⭐ | 服务器/极客工作流 |
| Sublime / Emacs | 内嵌终端运行 CLI | ⭐⭐⭐ | 老牌编辑器用户 |
┌────────────────────────────────────────────────────────────────────┐ |
使用 Claude 高效编码的 10 条铁律
| # | 铁律 | 说明 |
|---|---|---|
| 1 | 先 Plan 后 Code | 让 Claude 先输出实施计划再写代码 |
| 2 | 善用 @ 引用 | 精确传递上下文,避免泛泛而谈 |
| 3 | 多用选区上下文 | 选中代码再唤起 Claude,无需复述 |
| 4 | 写好 CLAUDE.md | 项目”入职文档”是最重要的投资 |
| 5 | 小步快跑 | 一次只让 Claude 改一件事,及时 Review |
| 6 | 保持 git 干净 | 每次 AI 改动前 commit,方便回滚 |
| 7 | 诊断信息驱动 | 让 lint/test 错误驱动 Claude 修复 |
| 8 | 善用 Checkpoint | 改坏了用 IDE 的 checkpoint 回滚 | |
| 9 | /clear 重置上下文 | 长对话变慢就清空重开 |
| 10 | 关键命令进 deny | 危险命令必须在 settings 中禁止 |
# 前提:Node.js 18+ (建议用 nvm 管理) |
首次运行会通过浏览器 OAuth 完成 API 鉴权,无需手动配置 API Key
强制建议在每个项目根目录创建一个 CLAUDE.md 文件,作为给 Claude 的 上下文(Context)说明书 ,用于介绍项目背景、技术栈、代码规范等。
your-project/ |
CLAUDE.md 示例:
# 项目说明:生产环境 EKS 集群运维 |
.claude/settings.json 内容示例:
{ |
一定要注意:
settings.json是”软约束”,不是”硬隔离”。settings.json的permissions是”权限提示层”,它能拦截 Claude 主动发起的危险命令, 但无法防御 命令变形绕过(rm 写成 /bin/rm、用变量拼接)、通过脚本间接执行(写个 .sh 再跑)、通过已 allow 的工具造成的间接破坏
在生产环境中的服务器上使用 Claude,既要能让 Claude 充分发挥其能力,又要对其做出合理的限制,防止误操作或者权限溢出而对生产环境造成事故。
参考文件结构如下
~/projects/prod-ops/ # 本地项目目录(VS Code 打开这里) |
这是第一道防线,也是最容易被忽视的一道。它的作用是从源头降低 Claude 尝试危险操作的概率。
参考 claude_rules.md 文件获取详细的行为规范和使用指南。
这是第二道防线,提交到 git 仓库,团队共享。
{ |
defaultMode: "default" : 未匹配任何规则的操作 → 询问用户deny : 硬拦截所有破坏性命令。deny 优先级最高,任何层级都无法覆盖ask : 半危险操作(写文件、curl、git push)→ 弹窗确认allow : 所有只读、诊断类命令 → 自动执行. 充分发挥能力的关键,让 Claude 流畅排查disableBypassPermissionsMode: "disable" : 禁止 --dangerously-skip-permissions ,禁止跳过所有权限检查的 bypass 模式CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC : 关闭非必要网络流量, 生产环境降噪规则支持精确匹配、前缀通配符(prefix:)和模式通配符()。ToolName 是首字母大写的工具名(如 Bash、Write、Read),括号内是可选的内容模式。
Bash(rm:*) → 拦截所有以 rm 开头的命令 |
个人临时覆盖(不提交 git)。临时需要某个权限时,在这里加,不污染团队共享的 settings.json 。记得加进 .gitignore
{ |
注意: settings.json 的 deny 有个致命弱点: 命令变形可以绕过 ,比如:
# settings.json deny 了 "Bash(rm:*)",但这些可能绕过: |
Hooks 让你能在 Claude 执行工具前后触发自己的 shell 脚本,实现更深的自动化和护栏。这是 真正能防住命令变形 的一层。
#!/usr/bin/env bash |
添加可执行权限
chmod +x ~/projects/prod-ops/.claude/hooks/pretooluse-guard.sh |
在前面的 settings.json 里追加 hooks 配置块
{ |
Hook 的价值 :
settings.json 的 deny 是字面匹配, hook 是语义/正则匹配ArgoCD 是目前 Kubernetes 生态中最流行的 GitOps 持续交付(CD)工具。它的核心理念是将 Git 仓库视为集群状态的“唯一真理来源”。
ArgoCD 的核心工作原理 :
声明式管理 :你不在集群里手动运行 kubectl ,而是将所有的资源清单(YAML、Helm、Kustomize)存放在 Git 中管理。
同步与漂移检测 :ArgoCD 会持续监控 Git 仓库和 EKS 集群。如果两者状态不一致(即发生“漂移”),它会报警或自动将集群恢复到 Git 定义的状态。
ArgoCD Application 删除时的 Propagation Policy
在 Argo CD 中,当你删除一个 Application 时,Propagation Policy(传播策略) 决定了该应用下属的 Kubernetes 资源(如 Deployment, Service, ConfigMap 等) 应该如何处理。本质上是调用了 Kubernetes API 的删除机制,Argo CD 利用 K8s 的 Finalizer 机制来实现这一逻辑
| 策略名称 | 行为描述 | 结果 |
|---|---|---|
| Foreground Cascade(前台级联) | 最常用。先删除子资源,最后删除 Application 本身。 | 集群资源被彻底清理,最安全。 |
| Background Cascade(后台级联) | 立即删除 Application,子资源在后台由 K8s 垃圾回收机制静默删除。 | 最终结果同上,但 Application 对象消失得更快。 |
| Orphan (Non-cascading ,孤儿模式) | 只删壳,不删内容。只删除 Application 对象,保留集群里的实际资源。 | 资源继续运行,不再受 Argo CD 管控。 这通常用于 迁移场景 :你只想让 Argo CD 不再管这个应用,但不想让业务停掉。 |
# kubectl create namespace argocd |
--server-side 选项用于解决可能的报错: The CustomResourceDefinition "applicationsets.argoproj.io" is invalid: metadata.annotations: Too long: may not be more than 262144 bytes等待 ArgoCD 相关 Pod 运行正常
# kubectl get pods -n argocd |
创建 Ingress 对外开放 ArgoCD UI,本示例中 IngressClass 为 AWS alb
apiVersion: networking.k8s.io/v1 |
创建并检查 Ingress
# kubectl apply -f argocd_ingress.yml |
ArgoCD Pod 强制开启了 TLS (HTTPS),而 ALB 却在使用 HTTP 进行健康检查。会因为健康检查失败无法访问

在集群中的 Pod 中尝试请求 argocd-server Pod 的地址,可以看到默认返回了重定向到 HTTPS 的响应,ALB 会因为证书问题对 Pod 健康检查失败
# curl -Iv 172.31.68.215:8080 |
可以配置 ArgoCD 接受 HTTP 协议请求。 修改 ArgoCD Server 启动参数 ,执行命令 kubectl edit deployment argocd-server -n argocd 编辑 argocd-server 的 Deployment,在启动命令( command )中添加 --insecure 参数。
containers: |
修改后等待 Pod 自动重启
$ kubectl get pods -A |
再次观察 ALB 的 Target 健康检查状态
ArgeCD 可以正常访问后,执行以下命令获取初始 admin 账户的密码
kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d |
Project 可以实现资源或者 APP 的逻辑隔离,可以通过 Project 限制 APP 对以下资源的使用:
in-cluster 的 dev-* 命名空间。Argo CD 有两个核心组件控制权限:
argocd-server(认证)
argocd-rbac-cm(授权)
Argo CD 支持三种用户方式
本地用户(不推荐生产)
SSO(推荐生产) ,支持:
GitHub
GitLab
Azure AD
OIDC
LDAP
Okta
Keycloak
Kubernetes RBAC 模式(高级) 。可以让 ServiceAccount 调用 Argo API。
在 ArgoCD 的实践中, Root App(根应用) 模式通常被称为 App of Apps(应用集应用) 模式。它是管理大规模 Kubernetes 集群和多租户环境的核心架构方案。
简单来说,与其在 ArgoCD 界面上手动一个个创建应用,不如创建一个 Root App(父应用) ,由它来自动管理和同步所有的 Application(子应用) 。
在 Kubernetes 中,ArgoCD 的一切配置都是资源(CRD)。一个 Application 资源的 YAML 定义了:
Source: 代码仓库地址、路径、分支。
Destination: 目标集群和命名空间。
Root App 的逻辑是:建立一个特殊的 Root Application ,它的 Source 指向一个存放了多个子应用(Application) YAML 文件的 Git 目录。当 Root App 同步时,它会在集群中生成这些子应用资源,随后 ArgoCD 监听到这些新生成的子应用,进而去同步具体的业务代码。
为什么需要 Root App?
声明式管理 (GitOps) :所有的应用配置都在 Git 中。如果你想增加一个微服务,只需在 Git 里加一个 Application YAML 文件,Root App 会自动感知并创建。
灾备恢复 :如果 ArgoCD 挂了或需要迁移,你只需要手动部署这一个 Root App,它会像树根一样带出整棵应用的“树”。
应用权限控制 :管理员只需要把控 Root App 的权限,普通开发人员在指定目录下提交代码即可。
推荐 Git 仓库结构如下:
. |
Root App 的 YAML 定义如下:
apiVersion: argoproj.io/v1alpha1 |
手动部署 Root App
kubectl apply -f argocd/bootstrap/root-app.yaml |
ArgoCD 会创建 Root App 资源,随后会根据 YAML 定义自动创建所有的子应用资源。
子应用资源只需在 argocd/apps/infrastructure 目录下创建即可。例如创建 cert-manager 应用:
apiVersion: argoproj.io/v1alpha1 |
将代码提交到 Git 仓库后,ArgoCD 会自动感知 spec.source.path (本示例为 argocd/apps/ )下的(递归)目录并创建相应的应用,比如 cert-manager 。在成熟的生产环境下,基本不会手动点击 “Create App”,而是通过维护一个 Git 仓库,利用 Root App 模式实现“配置即代码”的全自动化运维。
ArgoCD 的
spec.source.path只能配置一个目录路径; recurse 只能向下递归该目录, 不能跨目录 (例如同时扫argocd/infrastructure和argocd/projects)
Terraform 和 ArgoCD 自动化部署 EKS 集群以及常用应用的 Github 仓库 ,包括以下内容:
Terraform 配置 EKS Auto Mode 集群
ArgoCD 部署到 EKS 集群
ArgoCD Root App 配置
常用应用的 YAML 定义
KVM(Kernel-based Virtual Machine) 是 Linux 内核的一个模块,它将 Linux 内核转变为一个 Type-1(裸机级) 虚拟机管理程序(Hypervisor/VMM) 。
KVM 本身并不模拟硬件,它只负责处理器虚拟化和内存虚拟化。它需要配合 QEMU 来模拟 I/O 设备(如磁盘、网卡、显卡)。
内核态 (KVM Module) : 负责将 CPU 切换到 客户模式(Guest Mode) ,处理高权限指令。
用户态 (QEMU) : 负责模拟硬件设备,并提供用户操作接口。
管理层 (Libvirt) : 一个标准的 API 库,我们常用的 virsh 命令、 virt-manager 界面都是通过 Libvirt 来调用 QEMU/KVM 的。
核心技术特性
CPU 虚拟化 (Intel VT-x / AMD-V) 。KVM 利用硬件辅助虚拟化技术。它将 CPU 分为四种模式,使得虚拟机(Guest)可以直接在物理 CPU 上执行绝大多数指令,只有在执行敏感指令时才由内核接管,性能损耗极低。
内存管理 (EPT/NPT) 。通过 扩展页表 (EPT) 技术,KVM 实现了物理内存与虚拟机内存的直接映射。
存储与网络 (VirtIO) 。传统的模拟设备(如模拟一张经典的百兆网卡)效率极低。KVM 引入了 VirtIO 准虚拟化驱动。VM 意识到自己处于虚拟化环境,通过“共享内存”的方式与宿主机通信。实现磁盘 IO 和网络吞吐量几乎接近物理机性能。
KVM 家族工具链
qemu-kvm : 核心包,提供底层仿真。
libvirt-daemon : 守护进程,负责管理 VM 的生命周期。
virsh : 命令行工具(运维最常用)。
virt-install : 用于创建虚拟机的命令行脚本工具。
环境信息
- 最好不要和 Docker、K8s 等虚拟化工具同时安装。可能会因为内核参数(如
net.bridge.bridge-nf-call-iptables)冲突导致 VM 无法获得 DHCP 地址。
首先需要确认你的物理机 CPU 是否支持虚拟化技术(VT-x 或 AMD-V)
# egrep -c '(vmx|svm)' /proc/cpuinfo |
如果输出大于 0,说明支持虚拟化
安装 KVM 及相关工具 。参考以下命令安装 Linux 原生的虚拟化栈
sudo apt update |
Talos Linux OS Github 下载地址 ,从中下载 Talos Linux AMD64 版本的 RAW 镜像并提取 raw 文件
wget https://github.com/siderolabs/talos/releases/download/v1.14.0-alpha.0/metal-amd64.raw.zst |
使用解压后的 metal-amd64.raw 文件创建虚拟机
创建 Talos 虚拟机 。可以使用 virt-install 命令行快速创建多个 VM。 创建控制平面 (Control Plane) 虚拟机
cp metal-amd64.raw /var/lib/libvirt/images/talos-control-plane-01.raw |
--name talos-control-plane-01 : 虚拟机唯一名称为 talos-control-plane-01--ram 4096 : 内存大小为 4096MB--vcpus 4 : 虚拟 CPU 数量为 4 个--disk path=/var/lib/libvirt/images/talos-control-plane-01.qcow2,size=20 : path 虚拟磁盘文件存放路径, size 虚拟磁盘文件大小为 20GB--os-variant ubuntu22.04 : --os-variant 用于指定操作系统类型,这里指定为 Ubuntu 22.04。虽然安装的是 Talos,但指定 ubuntu22.04 会让 KVM 自动应用适合该内核版本的硬件加速参数(如 VirtIO 队列优化)--network network=default,model=virtio : 将 VM 挂载到宿主机的 default 网桥上。这是 Libvirt 默认网桥,是 KVM 安装后自动生成的 NAT 网桥。虚拟机可以访问外网,宿主机可以访问虚拟机,但外部机房的其他服务器无法直接访问该虚拟机。--graphics none : 不显示图形界面,禁用图形输出--console pty,target_type=serial : 串口控制台,将虚拟机的控制台重定向到当前的 shell 终端。运行命令后,你可以直接在当前的终端窗口看到 Talos 的启动日志。--cdrom /opt/Talos/metal-amd64.iso : 安装镜像,Talos 首次启动需要通过 ISO 引导来进入安装模式。--boot hd : 设置启动优先级。先尝试从硬盘 (hd) 启动,如果硬盘没系统(如首次启动),则从 光盘 (cdrom) 启动。执行 VM 安装命令后,你的终端会变为 VM 的输出界面。你会看到 Talos 启动并显示以下信息:
Starting install... |
到这一步说明虚拟机已经成功创建并运行了。由于你看到了 Escape character is ^] (Ctrl + ]) 且屏幕停止滚动,这意味着你已经成功进入了虚拟机的串口终端 (Serial Console)。
Talos 启动非常快,大约 10-20 秒。如果 1 分钟后还没输出,说明内核可能还在尝试初始化硬件。
如果你想回到宿主机命令行,执行后续的 talosctl 命令,你需要先 Ctrl + ] (先按住 Ctrl 不放,再按右中括号)退出虚拟机的串口终端。
如果 VM 安装异常,可以查询 libvirtd 服务日志
# journalctl -u libvirtd -n 50 --no-pager |
# virsh list --all |
virsh net-dhcp-leases default |
virsh destroy talos-control-plane-01 |
# virsh console 1 |
# virsh net-list |
virsh net-dhcp-leases default |
sudo dnf install -y yum-utils |
- 安装完成后,
terraform命令即可使用。
$ terraform version |
在 Terraform 节点服务器上安装 AWS CLI 并配置 AWS 凭证。
$ aws sts get-caller-identity |
AWS EKS 集群 Terraform 项目结构
$ tree |
在 variables.tf 文件中定义变量,用于在 Terraform 中使用动态值。
模块(module)的名称必须是一个固定的字符串(静态标识符),绝对不能包含变量插值
${...}。
|
在 providers.tf 文件中定义 AWS 提供商,指定 AWS 区域。
provider "aws" { |
在 versions.tf 文件中定义 AWS 提供商的版本。
|
在 vpc.tf 文件中定义 VPC 模块,用于创建 AWS VPC。
module "eks-6992-hk-uat-vpc" { |
在 eks.tf 文件中定义 EKS 模块,用于创建 AWS EKS 集群。
以下配置为 EKS Auto Mode 配置,建议使用。EKS Auto Mode 是 AWS 提供的“完全代管”体验,它将 Karpenter、EBS 驱动、CNI 等全部内置并由 AWS 直接管理。
EKS Auto Mode 无法直接通过 API 从“普通模式”无缝切换到“Auto Mode”,需要在创建集群指定“Auto Mode”。所以,建议在创建集群时指定“Auto Mode”,而不是在后续通过 API 切换。
module "eks-6992-hk-uat" { |
在 aws-alb.tf 文件中定义 AWS ALB Controller 模块,用于创建 AWS ALB Controller。
module "alb_controller_irsa_role" { |
在 efs.tf 文件中定义 EFS 模块,用于创建 AWS EFS 文件系统。
resource "aws_efs_file_system" "eks_efs" { |
执行以下命令初始化 Terraform 项目
$ terraform init |
使用命令 terraform plan 查看 Terraform 计划,可以检查是否有报错,并确认是否符合预期。
$ terraform plan |
Centos 7 默认的内核版本 3.10 在运行 kubernetes 时存在不稳定性,建议升级内核版本到新版本
Centos 7 默认的内核版本 3.10 使用的 cgroup 版本为 v1,Kubernetes 的部分功能必须使用
cgroup v2来进行增强的资源管理和隔离 [13]使用以下命令检查系统使用的
cgroup版本
stat -fc %T /sys/fs/cgroup/如果输出是
cgroup2fs, 表示使用 cgroup v2如果输出是
tmpfs, 表示使用 cgroup v1
User Namespaces功能需要 Linux 6.3 以上版本,tmpfs才能支持idmap挂载。并且其他功能(如 ServiceAccount 的挂载)也需要此功能的支持 [14]Kubernetes v1.32 需要 Linux Kernel >= 4.19, 建议 5.8+ 以更好的支持 cgroups v2
Rocky Linux 8 或者 Centos 8 默认使用
cgroup v1,需要升级到cgroup v2,执行命令grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1"后重启即可升级到cgroup v2。 使用以下命令检查:
# stat -fc %T /sys/fs/cgroup/
cgroup2fs若 CRI 使用 Containerd,需要 配置启用 CRI 以及配置其使用
cgroup v2版本。
kubernetes 目前未实现对 SELinux 的支持,因此必须要关闭 SELinux
sudo setenforce 0 |
配置集群所有节点的防火墙,确保所有集群节点之间具有完全的网络连接。
FORWARD 链的流量*filter |
Pixie 是一款专为 Kubernetes 设计的 开源全栈可观测性工具 。它最大的特色是利用 eBPF(extended Berkeley Packet Filter)技术,在不修改业务代码、不重启 Pod、不注入 Sidecar 的情况下,自动采集集群内的所有监控数据。Pixie 被称为 K8s 的分布式调试器
Pixie 的核心优势
无侵入性 (Auto-telemetry) : 部署后,自动获取 HTTP/gRPC 请求、SQL 查询、系统调用和火焰图。
边缘计算架构 : 数据存储在集群节点的内存中,查询时才进行分布式计算。这意味着:
极速 : 查询结果近乎实时。
省钱 : 不会有海量日志传输到云端产生的高额带宽和存储费。
动态可编程 : 使用 PxL(基于 Python 的查询语言)编写脚本,可以像写脚本一样实时分析系统性能。
Pixie 核心组件
Vizier : 运行在 K8s 集群中的控制器,负责管理各个节点的边缘收集器。
PEM (Pixie Edge Module) : 以 DaemonSet 形式运行在每个节点,利用 eBPF 采集数据并存储在本地内存。
Cloud Add-on : 提供用户界面 (UI) 和 API 访问。
快速安装
Pixie 的安装非常简单,通常通过 CLI 完成。
确保 Linux 内核版本在 4.16+(推荐 5.10+,2026 年的主流系统如 Ubuntu 22.04+、AlmaLinux 9 等都完美支持)。如果在过旧的内核上强行运行 eBPF 程序,极少数情况下可能导致内核态的不稳定。
下载 Pixie CLI
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)" |
脚本会从 Pixie 的官方 GitHub Release 页面或 CDN 下载最新版本的 px 命令行工具,并将其安装到
/usr/local/bin目录。px是你后续与 Kubernetes 集群交互的唯一入口,所有的部署(deploy)、查询(collect)和脚本运行都通过它完成。。
它会检查你本地的~/.kube/config文件,确保你当前有权限连接到一个 Kubernetes 集群。
当你执行完这个脚本后,Pixie 还没有安装到你的 Kubernetes 集群里。它只是在你的跳板机或开发机上装好了“遥控器”。要真正让 Pixie 开始监控集群,你通常需要继续执行px deploy命令。
部署到 K8s 集群。这将自动安装 Vizier 和 PEM 到集群中
px deploy |
这个命令会将 Vizier 和 PEM 部署到你的 Kubernetes 集群中。
安装完成之后使用
gitlab-ctl reconfigure启动服务
访问页面,默认使用root登录
每次重新更改配置,都需要使用reconfigure重新启动
参考配置如下:
services: |
Kasm Workspaces 是在浏览器里运行完整应用/桌面/浏览器的 云工作空间平台
你会看到:
Kasm 的核心能力
services: |
启动后,首先使用 https://<IP>:3000 进行初始化,初始化时需要设置管理员账号密码信息。初始化成功后,通过 https://<IP>:443 连接 Workspaces。
Kasm 强依赖 Docker,目前还无法在 Kubernetes 环境中部署。
在初始化页面(Install Wizard https://<IP>:3000 )中,确保 Kasm 的所有组件都处于 healthy 状态,表示 Kasm 已能正常提供服务
默认大多数的 Workspace 容器启动时都是没有中文输入的。如果要提供中文输入,可以使用系统提供的 IME Input Mode 。它可以将本地电脑的输入映射到 Kasm Workspaces 中。只需在对应的 Workspace 中开启 IME 配置即可。
使用管理员登录 Kasm。定位到 Workspaces ,编辑对应的 Workspace(如 Kali Linux),找到 Docker Run Configuration Override (JSON)

填入以下内容(如果有其他内容,插入以下内容),开启 IME
{ |

销毁之前的 Workspace Session,运行新的 Workspace Session,打开左侧的配置菜单,找到 Advanced Settings ,将 IME Input Mode 配置为 On

即可在 Workspace 中使用中文
在 Kasm 中,实现 Workspace 用户数据(如 Chrome 书签、桌面配置、文档等)持久化的标准方案是使用 Persistent Profiles(持久化配置层) 。
核心原理
Kasm 会将容器内的用户目录(通常是 /home/kasm )映射到宿主机的特定路径(即 docker-compose.yaml 中定义的 /profiles 目录)。当用户结束会话时,Kasm 会将该目录打包;下次启动时,再自动解压回容器。
开启 Persistent Profiles
docker-compose.yaml 中,已经配置了持久化卷 /opt/kasm-workspaces/profiles:/profiles ,这表示所有持久化数据将保存在宿主机的 /opt/kasm-workspaces/profiles 目录下。[email protected] (管理员账户)登录。local-storageCustom 。/profiles{ |
local-storage 并添加
/profiles/{user_id} ,启用 Enforce Workspace Persistent Profile

Kasm 会自动将
{user_id}替换为登录用户的 ID(例如 admin )。这样即便有多个用户,他们的数据也会分开放,互不干扰。
/opt/kasm-workspaces/profiles/ 中是否有文件存在。配置了 Persistent Profile 后,在 Kasm Workspaces 中启动 Session 也会显示已经启用了 Persistent Profile
用户登录 Kasm 后,可以导航到 Profiles 进行自定义配置:

以下示例在 1 Mster + 2 Worker 的 Kubernetes 集群上快速部署使用 MinIO 存储
mode: distributed |
新增以下 Ingress 配置用于提供 Console 访问
apiVersion: networking.k8s.io/v1 |
执行以下命令部署 MinIO
helm upgrade minio minio/minio -n minio -f values.yaml |
部署成功后通过 minio.example.click 登录 Console,管理员用户密码为 values.yaml 中配置的账户密码。
在 NFS Server 上执行以下命令:
sudo apt update |
sudo mkdir -p /data/nfs/nacos |
调整权限,生产环境建议更精细的权限控制
sudo chown nobody:nogroup /data/nfs/nacos |
sudo nano /etc/exports |
启动服务:
sudo exportfs -a |
为了让 K8S 节点能挂载 NFS,所有 Worker 节点都必须安装客户端工具:
sudo apt install nfs-common -y |
手动创建 PV 非常麻烦,在 K8S 中我们通常使用 nfs-subdir-external-provisioner 来实现自动创建 PV。
这是目前最简单、最标准的方式,添加仓库
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/ |
安装 nfs-provisioner 作为 存储 Provisioner
helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \ |
kubectl get sc 验证 StorageClass
现在可以在 Nacos 的部署配置中使用这个 nfs-storage 的 StorageClass 了。参考以下资源清单部署单节点的 Nacos 完整服务,包括 Nginx Ingress 以及鉴权
apiVersion: v1 |
部署完成后通过 nacos.example.click 登录后台,初始默认密码为 nacos/nacos
要使用 Mysql 存储数据,只需修改资源清单为以下内容即可:
apiVersion: v1 |
创建配置文件 config.json
{ |
"id": "c4187394-5865-446d-9d8d-3f6c179416b0(UID 替换为实际值)" 可以自行生成
"dest": "www.microsoft.com:443" 伪装的网站地址
"privateKey": "mD0OUR8tFvOypHQre6yGgsZs2w-JecH4zkXB9_TY-k8(私钥)" 私钥,公司钥对可以使用如下命令生成
# docker run --rm teddysun/xray xray x25519 |
PrivateKey 对应私钥( privateKey )Password 对应公钥( Public Key ),要发送给客户端使用docker-compose.yaml 配置如下:
services: |
正常启动后,在客户端如下配置:
类型: VLESS
地址(Address): <SERVER IP>
端口(Port): 443 # 对应配置文件中的 inbounds.port
UUID: <UID> # 对应配置文件中的 inbounds.settings.clients.id
流(Flow): xtls-rprx-vision # 对应配置文件中的 inbounds.settings.clients.flow
传输协议(Transport protocol(network)): TCP # 对应配置文件中的 inbounds.streamSettings.network
TLS/安全: Reality # 对应配置文件中的 inbounds.streamSettings.security
加密(Encryption): none # 对应配置文件中的 inbounds.settings.decryption
SNI: www.microsoft.com # 对应配置文件中的 inbounds.streamSettings.realitySettings.dest
短 ID(Short ID): a1b2c3d4 # 对应配置文件中的 inbounds.streamSettings.realitySettings.shortIds
公钥(Public key、密码、Password): <公钥> # docker run --rm teddysun/xray xray x25519 命令生成的 Password
为了方便客户端导入,可以为配置生成以下链接,其中包含了客户端链接所需的参数:
vless://<UID>@<SERVER IP>:<Port>?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=<Public Key or Password>&sid=a1b2c3d4#Shanghai_MS_Reality |
大多数客户端都支持从粘贴板复制以上内容自动导入配置。
Windows 下载 v2rayN ,将其解压后,运行程序 v2rayN.exe 即可打开程序。复制配置链接( vless://<UID>@<SERVER IP>:<Port>?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=<Public Key or Password>&sid=a1b2c3d4#Shanghai_MS_Reality ),在 v2rayN 主界面点击 Configuration -> Import Share Links from clipboard 即可自动导入配置

默认情况下, v2rayN 会测试到 google.com 的连接来验证服务端是否正常,国内服务器此测试必定失败,因此可以修改此测试目标。参考以下步骤:
google.com ,将其改为国内服务器可以访问的地址如 https://www.baidu.com
要验证 xray server 工作正常,可以在 v2rayN 客户端进行 延迟检测(Test real delay) 。右键要检测的 xray server 选择 Test real delay

如果能够获取到延迟数据,说明 xray 工作正常,如果未获取到延迟数据,可以登陆服务器,通过命令 docker logs 检查服务端日志
Prometnehs 告警规则如下:
- alert: HostTCPRetransmitsHigh |
Prometheus 监控数据显示: retrans=21736/5m
检查系统上的 网络内核协议栈状态 ,使用工具 nstat ,它能显示网络栈的统计信息,还能通过差值计数快速定位当前发生的异常。默认显示自系统启动以来的所有统计项。
# nstat |
使用 bpftrace 跟踪重传发生的端口统计数据
# bpftrace -e ' |
使用 bpftrace 实时跟踪指定端口的重传数据
# bpftrace -e ' |
BPF(Berkeley Packet Filter) 是由 Berkeley 学院于 1992 年开发的一款,主要用于提高抓包工具的性能。并于 2014 年被重写进 Linux 内核中,可以用于 内核观测、网络诊断、性能观测、安全、Kubernetes 网络治理等方面 。 [1]
BPF 是一种灵活且高效的技术实现,主要由 指令集(Instruction Set) 、 存储对象(Storage Objects maps) 和 帮助函数(Helper Functions) 构成。因为其 虚拟指令集规范(Virtual Instruction Set Specification) ,可以认为 BPF 是一个虚拟机,BPF 运行于 内核模式(Kernel Mode) 。BPF 基于事件(Events)运行: Socket Events 、 Tracepoints 、 USDT Probes、kprobes、uprobes、perf_events.
eBPF 允许 :
在运行中的内核里插入自己的逻辑
比如:
而且:
无需修改内核源码,只在内核事件点插入逻辑,无需重启系统,是 Linux 内核的动态扩展机制
这是 eBPF 最核心的价值。
eBPF 本质 运行在 Linux 内核中的事件驱动程序 。关键点:
eBPF = Hook + Event + Action
eBPF 的执行流程分六步
编写 eBPF 程序 。例如 把程序挂到 tcp_connect 函数上
SEC("kprobe/tcp_connect") |
编译为 BPF Bytecode(eBPF 虚拟机字节码) 。eBPF 运行的不是机器码,而是 BPF 字节码
clang -> BPF bytecode |
加载到内核 。用户态程序通过 bpf() 系统调用,把字节码加载进内核。
Verifier 验证程序安全 ,这是 eBPF 最重要的机制,用户把程序加载到内核,是极其危险的,它会检查
Attach:把程序挂到事件点 。程序通过 verifier 后,要挂到某个 Hook 点 (Event),比如
kprobe:tcp_connect ,每次调用 tcp_connect ,就执行 eBPF 程序tracepoint:sys_enter_execve,每次进程执行时触发XDP ,挂到网卡驱动层本质是: Attach = 指定“什么时候执行 eBPF” 。这是 eBPF 的事件驱动核心。
事件发生时,程序运行
Map 是内核(Kernel)与用户态(User Space)之间的通信机制 。eBPF 程序运行在内核,但它不能直接:
所以必须通过 BPF Map 与用户态交换数据。其本质是内核中的 Key-Value 存储。eBPF 程序更新 Map,用户态读取 Map。 Map 是用户态和内核态共享数据桥梁
Hook 点是在内核执行路径中插入的一个触发点或者说在内核某个位置插入 eBPF 程序 。正常内核流程:
事件发生 -> 内核函数执行 |
加上 eBPF 后:
事件发生 -> Hook 点 -> eBPF 程序执行 -> 原逻辑继续 |
不同 Hook 点,看到的数据不同,性能不同,用途不同
open() 、 execve() 等函数,适合 进程行为观测所以: Hook 点 = eBPF 能看到什么、能做什么
tcp_connect 。因为挂在函数入口,所以常用于:tcp_connect(sock, addr) 拿到: socket 信息、目标地址kprobe 用于跟踪内核函数行为 。优点是非常灵活,能挂任意内核函数;缺点是依赖内核函数名,不稳定(不同内核版本可能变),内核升级可能导致 kprobe 失效
bpftrace 是一个基于 BPF 的追踪工具(Trace Tools),提供了高级别的编程能力,同时包含了命令行和脚本使用方式
bpftrace 命令详细帮助文档请查看 man bpftrace,下表列出常用选项和参数
| 选项 | 说明 | 示例 |
|---|---|---|
-l [SEARCH] |
列出匹配的事件(Event/Probe),没有 SEARCH 表达式则列出所有的 Event。SEARCH 支持通配符 |
|
-e 'program' |
跟踪脚本 |
筛选指定的事件
# bpftrace -l "tracepoint:*exec*" |
执行以下命令,可以追踪系统中新启动的进程及其参数
# bpftrace -e 'tracepoint:syscalls:sys_enter_execve { join(args->argv); }' |
Systems Performance: Enterprise and the Cloud v2
服务器配置如下(32CPU 32G RAM, 无 GPU):
# lscpu | grep NUMA |
模型推荐清单 (纯 CPU 环境)
| 模型名称 | 推荐版本 | 理由 | 内存占用 | 速度预期 |
|---|---|---|---|---|
| DeepSeek-V3 / R1 (Distill) | deepseek-r1:7b 或 14b | 目前最强的推理模型,逻辑能力极佳。 | ~5GB / 9GB, | 极快 / 流畅 |
| Llama 3.1 | llama3.1:8b | 综合素质平衡,适合通用的英文/开发任务。 | ~5.5GB | 极快 |
| Qwen 2.5 (通义千问) | qwen2.5:7b 或 14b | 中文语境支持最好,适合文档处理、后端开发辅助。 | ~5GB / 9GB | 极快 / 流畅 |
| Command R | command-r:35b | 内存极限挑战。适合需要长上下文(RAG)的任务。 | ~20GB | 较慢 |
安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh |
查看 Ollama Service 状态
# systemctl status ollama --no-pager |
运行推荐模型 (以 DeepSeek R1 7B 为例)
ollama run deepseek-r1:7b |
(Optional)部署 Open WebUI(原 Ollama WebUI) ,它支持 Docker 部署
services: |
# rules |
ansible-core 版本及 Python 版本支持对应关系
| ansible-core Version | Control Node Python | Target Python / PowerShell |
|---|---|---|
| 2.16 | Python 3.10 - 3.12 | Python 2.7 Python 3.6 - 3.12 Powershell 3 - 5.1 |
为了环境部署方便灵活,可以选择使用 python:3.12.3 的 Docker 镜像,以其为基础环境安装 ansible-core 2.16 或者直接使用 ansible 镜像启动。
# docker run --rm -it python:3.12.3 bash |
在服务器本地环境部署,如果想要灵活管理配置,也可以使用 pip3 命令安装 ansible
$ pip3 install ansible |
如此安装的 ansible 默认不加载任何配置文件,此时只需在 ~/.ansible/ 下手动创建 ansible.cfg 即可
[defaults] |
切换到 ~/.ansible/ 目录,再次查看 Ansible 加载的配置,其已经加载了 ~/.ansible/ansible.cfg
$ ansible --version |
Ansible 主配置文件为 /etc/ansible/ansible.cfg,其中的配置都可以被 ansible-playbook 或者命令行参数覆盖。
ansible 默认会读取环境变量
ANSIBLE_CONFIG指定的配置文件,当前路径下的ansible.cfg,以及用户家目录下的.ansible.cfg,以及/etc/ansible/ansible.cfg作为配置文件,已第一个找到的为准
常用配置说明
| 配置项 | 说明 | 示例 |
|---|---|---|
inventory |
指定 inventory (主机列表)文件的路径,默认为 /etc/ansible/hosts |
|
remote_user |
(未指定用户时)连接远程主机时使用的用户 | |
remote_port |
连接远程主机时使用的(默认)端口 | |
host_key_checking |
默认启用。检查主机密钥可以防止服务器欺骗和中间人攻击。 如果主机重新安装并且在 know_hosts 中拥有不同的密钥,ansible 会提示确认密钥。如果要禁用此行为,可以配置为 False |
|
ask_pass |
默认为 False。当设置为 True 时,ansible 要求输入远端服务器的密码,即使配置了免密登录 | |
log_path |
日志文件,默认 /var/log/ansible.log |
|
pattern |
当没有给出 pattern 时的默认 pattern,默认值是 * 即所有主机 |
配置示例
[defaults] |
默认的 inventory 配置文件路径为 /etc/ansible/hosts,主要用来配置 Managed Hosts 列表 [3]
在命令行中,可以使用选项 -i <path> 指定不同的 inventory 或者可以在 ansible 配置文件 ansible.cfg 中使用指令 inventory 指定 inventory 文件位置。
命令行中可以使用
-i <path1> -i <path2> ...指定多个inventory
inventory 文件支持多种格式,最常见的是 INI 和 YAML 格式。
all : 包含所有主机ungrouped : 包含所有不在其他组(all 除外)中的所有主机。任何一个主机都会至少在 2 个组中,要么 在
all和某个组中,要么 在all和ungrouped组。
parent/child 组,child 组被包含在 parent 组中。:children 后缀配置 parentchildren: 配置 parent
- 任何在
child组中的主机自动成为parent组中的一员- 一个组可以包括多个
parent和child组,但是不能形成循环关系- 一个主机可以在多个组中,但是在运行时,只能有一个实例存在,Ansible 会自动将属于多个组的主机合并。
[webservers] |
# ... |
范围格式 的第一项和最后一项也包括在内。即匹配
www01和www50
在主机数量较多,或者组织结构较复杂的情况下,使用单个 Inventory 配置文件会导致主机管理较为复杂。将单个 Inventory 配置文件按照项目或者组织或其他规则进行分割会显著降低维护复杂度。
Inventory 多配置文件支持,可以使用以下方法之一
-i <path1> -i <path2> ... 指定多个 inventory/etc/ansible/inventory/),在命令行中使用选项 -i /etc/ansible/inventory/ 或者在 Ansible 配置文件(ansible.cfg)中使用指令 inventory 配置目录。注意事项: Ansible 使用字典顺序加载配置文件,如果在不同的配置文件中配置了
parent groups和child groups,那么定义child groups的配置要先用定义parent groups的文件加载,否则 Ansible 加载配置会报错:Unable to parse /path/to/source_of_parent_groups as an inventory source[4]
group_vars 和 host_vars 目录分别存储组变量和主机变量 [7]注意事项: 组变量和主机变量必须使用 YAML 格式,合法的文件扩展名包括:
.yaml、yml、.json或者无文件扩展名
主机列表中的主机可以单独出现,也可以位于某个或者多个 组([] 开头的行)中
ansible-demo1.local |
连接主机使用的常用配置说明 [6]
| 配置项 | 说明 | 示例 |
|---|---|---|
ansible_host |
远程主机地址 | |
ansible_port |
远程主机端口 | |
ansible_user |
连接远程主机的 ssh 用户 Ansible 默认使用 control node 上执行 ansible 的用户名来连接远程主机 [9] |
|
ansible_password |
连接远程主机的 ssh 用户密码,建议使用 key 连接 | |
ansible_ssh_private_key_file |
连接远程主机的 ssh 私钥文件路径 | |
ansible_become ansible_sudo ansible_su |
用户权限提升 | |
ansible_become_method |
用户权限提升(escalation)的方式 | |
ansible_become_user ansible_sudo_user ansible_su_user |
用户权限提升(escalation)后的用户 | |
ansible_become_password ansible_sudo_password ansible_su_password |
sudo 密码(这种方式并不安全,强烈建议使用 --ask-sudo-pass) |
|
ansible_become_exeansible_sudo_exe ansible_su_exe |
设置用户权限提升(escalation)后的可执行文件 | |
ansible_connection |
与主机的连接类型.比如:local, ssh 或者 paramikoAnsible 1.2 以前默认使用 paramiko。1.2 以后默认使用 smart,smart 方式会根据是否支持 ControlPersist, 来判断 ssh 方式是否可行. |
|
ansible_shell_type |
目标系统的 shell 类型.默认情况下,命令的执行使用 sh 语法,可设置为 csh 或 fish. |
|
ansible_python_interpreter |
目标主机的 python 路径 系统中有多个 Python, 或者命令路径不是 /usr/bin/python |