工具全景——2026 年你需要认识的 AI 编程工具

2026 年你需要认识的 AI 编程工具

上一节聊了 Vibe Coding 是什么,这一节带大家认识一下当前主流的 AI 编程工具都有哪些、各自的定位是什么。

先说清楚:这里列的不是市面上所有工具,新工具隔几个月就冒一个,穷举没有意义。我们挑的是几类有代表性的,覆盖不同的使用场景和工作方式。

看完这节,你会对这个生态有个清晰的认知框架——以后遇到没见过的工具,自己也能判断它属于哪类、适合什么场景,不需要再来问"这个工具怎么样"。

至于最终用哪个,完全可以根据自己的习惯和需求自由选择,没有标准答案。

三类工具,三种思路

目前 AI 编程工具大致可以分三类,思路上有根本差异:

  • AI IDE 类:把编辑器本身重做,AI 功能深度内嵌进去,和代码编辑是一体的
  • IDE 插件类:在你现有的编辑器(IntelliJ、VS Code)上装一个插件,不换编辑器,只是增强
  • 终端 Agent 类:完全在命令行里工作,没有图形界面,AI 直接读文件、写文件、跑命令

这三类的核心差异不是能力强弱,而是工作方式不同。理解了这个,后面看具体工具就不容易混乱。

AI IDE 类:编辑器即 AI

Cursor:AI IDE 的标杆

基于 VS Code 魔改,目前 AI IDE 里最火的一个。

Agent 模式:你描述一个功能需求,它会自己规划任务、读相关文件、写代码、修 Bug,整个流程几乎不需要手动干预。这是和普通代码补全工具最大的区别。

Rules 系统:可以把项目的技术栈规范、代码风格写进 .cursor/rules/,AI 每次生成代码都会遵循这套规范,输出风格和项目保持一致。

这个模块里 Cursor 会是主角,后面几节会深度讲。

Windsurf:Cursor 的直接对手

原 Codeium 出品,2025 年经历了一轮收购风波(曾传出被 OpenAI 和 Google 接洽),最终以独立品牌继续运营。

主打"Cascade"流式编辑模式,思路和 Cursor 的 Agent 类似,界面比较干净。竞争压力下功能迭代明显加快,是 Cursor 目前最直接的竞争对手。

Trae:国内开发者的友好选择

字节跳动出品,国内用户友好,中文交互体验好,对国内开发者来说网络访问也更顺畅。2025 年持续迭代,免费策略比较激进。

IDE 插件类:在熟悉的环境里增强

GitHub Copilot:企业级首选

微软 + GitHub 出品,支持 IntelliJ、VS Code,是企业里用得最广的 AI 编程工具。

补全质量稳定:这几年积累了大量 Java 代码数据,补全体验扎实。最近加入的 Agent 功能(Copilot Workspace)也在持续增强。

IntelliJ 用户、企业团队环境里,Copilot 是首先会遇到的选项。

JetBrains AI Assistant:深度集成

JetBrains 官方出品,深度集成在 IntelliJ IDEA 里,支持代码补全、重构建议、测试生成、提交信息自动生成等功能。

对 Java 开发者来说,和 IDE 原生功能的结合是最流畅的——不用切换工具,直接在熟悉的环境里用。

2026 年已支持接入多个主流模型,是企业 Java 团队里越来越多被采用的选项。

Tabnine:私有化部署

老牌 AI 补全工具,特点是支持私有化部署——对数据合规要求高的企业(金融、医疗)来说,能在内网部署是很重要的能力。

终端 Agent 类:命令行里的 AI 工程师

Claude Code:大规模重构专家

Anthropic 出品,纯命令行 Agent,没有图形界面。

定位和 Cursor 不同——它更擅长大规模、跨文件的任务。比如"把整个项目的 DAO 层从 MyBatis 迁移到 JPA"这种需要同时修改几十个文件的工作,Claude Code 处理起来很顺手。

它会自己读现有代码结构、写文件、执行 mvn compile 验证、发现报错自己修——整个过程全自动。

这个模块里有专门一节讲 Claude Code,大家到时候跟着操作一遍就有感觉了。

Aider:开源可控

开源命令行 Agent,最大特点是可以接任意 LLM(OpenAI、Claude、本地模型都行)。对想自己控制底层模型、或者需要离线使用的场景比较有用。

OpenAI Codex CLI:沙箱安全

OpenAI 2025 年推出的终端编程 Agent,是 Claude Code 的直接对标。底层默认跑 o4-mini,需要更强推理能力时可以切 o3。

沙箱执行模式:它有三档安全级别:

  • suggest 模式:只给建议不动手
  • auto-edit:可以改文件但执行命令要你确认
  • full-auto:完全自主跑在沙箱里

codex "把这个模块的测试覆盖率跑到 80% 以上" 扔进去,它自己分析代码、生成测试、执行验证、报告结果,全程不用盯着——你可以放心让它跑 mvn testdocker build,出了问题沙箱隔离,不会影响宿主机。

和 Claude Code 怎么选? 两个都值得试一下。社区反馈 Claude Code 在复杂多步推理上略强,Codex CLI 在安全控制粒度上更细腻。大多数时候用哪个主要看你手头哪家的 API 账号更顺手。

一张全景图

类别 工具 特点 适用场景
AI IDE Cursor Agent 模式 + Rules 系统 从零开始的项目,需要深度 AI 辅助
AI IDE Windsurf Cascade 流式编辑 Cursor 的替代选择
AI IDE Trae 中文友好 + 免费策略激进 国内开发者
IDE 插件 GitHub Copilot 企业级 + 稳定补全 企业团队,IntelliJ 用户
IDE 插件 JetBrains AI 深度集成 IntelliJ Java 企业开发
IDE 插件 Tabnine 私有化部署 数据合规要求高的企业
终端 Agent Claude Code 大规模跨文件任务 重构、迁移、批量修改
终端 Agent Aider 开源可控 需要自定义底层模型
终端 Agent Codex CLI 沙箱安全 自动化测试、安全要求高

这个模块会重点讲哪些

这个模块的重点是 CursorClaude Code,原因很简单:这两个代表了两种不同的 AI 编程范式,学会这两个,其他工具上手都很快。

Copilot 的基本用法大家可以类比 Cursor,核心逻辑是一样的,只是嵌在 IntelliJ 里体验会不同。

其他工具如果大家感兴趣,可以根据这节的介绍自行探索,原理都相通。

写在最后:工具是手段,不是目的

最后想提醒一点:工具是手段,不是目的。

Vibe Coding 的核心是"用自然语言描述需求,让 AI 实现",而不是"必须用哪个工具"。

Cursor 好用,但如果你已经是 10 年 IntelliJ 老用户,强行切到 Cursor 反而降低效率——这种情况下,Copilot + JetBrains AI 可能更适合你。

Claude Code 强大,但如果你更习惯图形界面,强行用命令行只会增加认知负担。

选择工具的原则

  1. 熟悉度优先:在熟悉的工具上加 AI 功能,比重新学一个工具成本低
  2. 场景匹配:大规模重构用 Claude Code,日常开发用 Cursor 之类的产品。

本文是 Vibe Coding 系列的第二篇。关注这个系列,一起探索 AI 时代的编程新范式。

Views: 68

代码都不用看了?Vibe Coding 正在重塑编程的未来

代码都不用看了?Vibe Coding 正在重塑编程的未来

2025年,一种名为"Vibe Coding"的编程方式正在颠覆整个开发社区。前 OpenAI 联合创始人 Andrej Karpathy 的一条推文,让"跟着感觉走"成了年度热词。但这真的意味着程序员可以"不看代码"了吗?

当代码遇上直觉:Vibe Coding 的诞生

2025年2月,前 OpenAI 联合创始人、特斯拉 AI 前负责人 Andrej Karpathy 发了一条推文:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I'm doing this all with voice now... I just tell Cursor what I want and it does it... It's not really coding—I barely read the code at all."

翻译过来:有一种新的编程方式叫 Vibe Coding。你完全顺着感觉走,拥抱指数级增长,甚至忘记代码的存在。我现在全用语音,只需要告诉 Cursor 我想要什么,它就帮我做到。这真的不是在写代码——我几乎不看代码。

这条推文像一颗石子投入平静的湖面,激起了2025年IT圈最大的涟漪。Collins词典甚至将其列为年度词汇候选之一。

从建筑工人到建筑师:编程角色的根本转变

核心变化只有一个:你不再写代码,你负责"说清楚你要什么"。

想象一下这个场景:

传统开发:你是一名建筑工人,每天搬砖、砌墙、安装水电管线。你熟悉每一块砖的重量,知道水泥和沙子的最佳配比,你的手上布满老茧,那是劳动的勋章。

Vibe Coding:你成为了一名建筑师。你不再亲手搬砖,而是站在图纸前,决定"这面墙要不要"、"这个房间做什么用"、"采光从哪里来"。你依然需要懂建筑逻辑,但你的价值从"执行"变成了"决策"。

这不是降级,而是升级——从决定"怎么做"跃升为决定"做什么"

Vibe Coding 的四大核心特征

Vibe Coding 不是魔法,它有明确的特征:

1. 自然语言驱动

  • 过去:if (user.isLoggedIn() && user.hasPermission("admin")) { ... }
  • 现在:"检查用户是否登录且有管理员权限"

你用中文或英文描述需求,AI 将你的描述翻译成代码。这不是偷懒,而是效率的革命。

2. 迭代优先

不追求第一次就完美。快速出原型,快速测试,快速调整。传统开发可能花3天写完一个功能,Vibe Coding 用3小时出第一版,然后通过5轮快速迭代达到同等质量。

3. 验证而非审查

关键转变:不逐行读代码,而是通过运行和测试来验证结果。你不需要知道AI用了什么设计模式,你只需要知道:功能是否正常?性能是否达标?安全是否可控?

4. AI 是执行层

你从程序员变成了架构师 + 产品经理。你决定"做什么"(what),AI 负责"怎么实现"(how)。这不是让你变得不重要,而是让你变得更重要——因为你要做的决策更关键。

数据不会撒谎:2026 年的现实

让我们看几组数据,感受这个趋势的猛烈程度:

数据 来源 意味着什么
YC Winter 2025 批次中,25% 的团队 95% 代码由 AI 生成 Y Combinator 官方报告 创业公司已经在用AI狂奔
超过 70% 的开发者已在日常工作中使用 AI 辅助编程 GitHub Octoverse 2025 这不是未来,是现在
Google 25% 的新代码由 AI 生成,并由工程师审查合并 Google 财报电话会议 巨头公司已经规模化应用
45% 的 AI 生成代码含安全漏洞 SAST 分析报告 效率提升了,但风险也来了

最后一条数据要特别注意:效率提升的同时,安全风险也在上升。这恰恰说明了为什么"懂技术"在 Vibe Coding 时代反而更重要。

Vibe Coding ≠ 代替程序员

很多人问:Vibe Coding 是不是就是用 AI 代替程序员?

不是的。

关键转变在于:技术理解力 >>> 代码手写能力

就像建筑师不需要亲自切菜,但他一眼就能看出食材新不新鲜、火候对不对。Vibe Coding 的正确姿势是:让 AI 生成,但你要能看出哪里不对

Java 开发者的隐藏优势

这里有个反直觉的真相:Java 开发者在 Vibe Coding 时代有独特优势

很多人觉得 Python 才是 AI 时代的王,Java 太重了。但事实恰恰相反。

优势一:生态成熟 = AI 的超级饲料

GPT、Claude 这些模型见过的 Java 代码数量是天文数字。Spring Boot、MyBatis、JPA、Hibernate、Maven、Gradle、Spring Cloud……这些框架的代码遍布 GitHub 的每一个角落。

AI 生成 Java 代码的质量,实际上相当高。为什么?因为它"吃"过的 Java 代码太多了。

优势二:强类型红线 = 自带 Code Review

Java 的强类型系统 + IDE 的即时红线提示,让 AI 生成的错误代码立刻暴露。

// AI 生成的错误代码
String userId = user.getId(); // 如果 getId() 返回 Long,IDE 瞬间标红!

在 Python 或 JavaScript 里,这种 Bug 可能要到运行时才发现。但在 Java 里,AI 的低级错误无处遁形。

优势三:企业主场 = 提效刚需

Java 在金融、电商、物流这些企业核心系统里份额极高。这些系统复杂度高、改动频繁、质量要求严——恰恰是 Vibe Coding 提效的最佳战场。

而这些系统的开发者,就是你。

优势四:架构思维 = 精准控局

Vibe Coding 对"我要什么架构"的表达依赖很高。Java 开发者大多有丰富的分层架构、设计模式经验,你在描述需求时天然更精准:

"用策略模式重构这个支付逻辑,支持微信、支付宝、银联三种渠道,每个渠道独立配置超时和重试策略。"

这种描述,AI 听得懂,也能执行好。而缺乏架构经验的人,可能只会说:"帮我写个支付功能",结果得到一堆面条代码。

"我几乎不看代码"的真相

Karpathy 说"我几乎不看代码",这句话需要加个注脚:

他是前 OpenAI 联合创始人,他"不看"并不代表他"不懂"。他是因为懂得太深,所以能快速判断 AI 输出的质量。

这就像米其林大厨不需要亲自切菜,但他一眼就能看出食材新不新鲜、火候对不对。

Vibe Coding 的正确姿势是:让 AI 生成,但你要能看出哪里不对。

这要求你有扎实的技术基础:

  • Java Core:理解 JVM、集合框架、并发编程
  • 算法导论:知道什么问题用什么算法解决
  • 计算机网络:理解 HTTP、TCP/IP、分布式通信
  • 数据库原理:懂索引、事务、隔离级别
  • 安全知识:知道 SQL 注入、XSS、CSRF 是什么

技术底子在,Vibe Coding 才能用好。 不然,你只是在盲目信任 AI 的输出,这是在踩坑。

写在最后:这只是开始

Vibe Coding 不是终点,而是新的起点。它让程序员从"搬砖工"变成了"建筑师",从"执行者"变成了"决策者"。

核心目标:日常开发效率提升 3-5 倍!

但这个转变需要准备:

  1. 扎实的技术底子:能看出AI代码的问题
  2. 清晰的思维表达:能准确描述"我要什么"
  3. 架构设计能力:知道"好的架构"长什么样
  4. 验证测试思维:通过测试而非审查来保证质量

接下来的系列文章中,我们将深入探讨:

  • Vibe Coding 的工具生态(Cursor、Claude Code、GitHub Copilot 等)
  • 如何用自然语言精准描述需求
  • AI 生成代码的安全审查实践
  • Java 项目中的 Vibe Coding 实战案例

准备好了吗?让我们开始这场编程范式的革命。


本文是 Vibe Coding 系列的第一篇。关注这个系列,一起探索 AI 时代的编程新范式。

Views: 35

K8s 学习:常用命令 100 条(五)- 安全加固

K8s 学习:常用命令 100 条(五)- 安全加固

安全

系列文章: K8s 命令实战指南
适用人群: 安全工程师、运维工程师、DevOps 工程师
阅读时间: 18 分钟


前言

安全是 Kubernetes 集群的重中之重。本文介绍如何使用 kubectl 命令进行安全管理、权限控制和安全加固。


一、RBAC 权限管理

1.1 角色(Role)管理

# 查看所有 Role
kubectl get roles --all-namespaces

# 查看指定命名空间的 Role
kubectl get roles -n <namespace>

# 查看 Role 详情
kubectl describe role <role-name> -n <namespace>

# 创建 Role(YAML)
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
EOF

# 创建 Role(命令行)
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n default

# 删除 Role
kubectl delete role <role-name> -n <namespace>

# 编辑 Role
kubectl edit role <role-name> -n <namespace>

# 查看 Role 的规则
kubectl get role <role-name> -n <namespace> -o yaml

使用场景:

  • 命名空间级别权限控制
  • 最小权限原则
  • 职责分离
  • 多租户环境

1.2 集群角色(ClusterRole)管理

# 查看所有 ClusterRole
kubectl get clusterroles

# 查看 ClusterRole 详情
kubectl describe clusterrole <clusterrole-name>

# 创建 ClusterRole(YAML)
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
EOF

# 创建 ClusterRole(命令行)
kubectl create clusterrole node-reader --verb=get,list,watch --resource=nodes

# 删除 ClusterRole
kubectl delete clusterrole <clusterrole-name>

# 编辑 ClusterRole
kubectl edit clusterrole <clusterrole-name>

# 查看系统内置 ClusterRole
kubectl get clusterroles | grep system

# 查看聚合 ClusterRole
kubectl get clusterrole <clusterrole-name> -o jsonpath='{.aggregationRule}'

使用场景:

  • 集群级别权限控制
  • 节点资源访问
  • 集群资源管理
  • 跨命名空间权限

1.3 角色绑定(RoleBinding)管理

# 查看所有 RoleBinding
kubectl get rolebindings --all-namespaces

# 查看指定命名空间的 RoleBinding
kubectl get rolebindings -n <namespace>

# 查看 RoleBinding 详情
kubectl describe rolebinding <rolebinding-name> -n <namespace>

# 创建 RoleBinding(YAML)
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
EOF

# 创建 RoleBinding(命令行)
kubectl create rolebinding read-pods --role=pod-reader --user=jane -n default

# 创建 RoleBinding(ServiceAccount)
kubectl create rolebinding read-pods --role=pod-reader --serviceaccount=default:mysa -n default

# 删除 RoleBinding
kubectl delete rolebinding <rolebinding-name> -n <namespace>

# 编辑 RoleBinding
kubectl edit rolebinding <rolebinding-name> -n <namespace>

使用场景:

  • 用户权限绑定
  • 服务账号授权
  • 角色分配
  • 权限管理

1.4 集群角色绑定(ClusterRoleBinding)管理

# 查看所有 ClusterRoleBinding
kubectl get clusterrolebindings

# 查看 ClusterRoleBinding 详情
kubectl describe clusterrolebinding <clusterrolebinding-name>

# 创建 ClusterRoleBinding(YAML)
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io
EOF

# 创建 ClusterRoleBinding(命令行)
kubectl create clusterrolebinding read-nodes --clusterrole=node-reader --user=jane

# 创建 ClusterRoleBinding(ServiceAccount)
kubectl create clusterrolebinding read-nodes --clusterrole=node-reader --serviceaccount=default:mysa

# 删除 ClusterRoleBinding
kubectl delete clusterrolebinding <clusterrolebinding-name>

# 编辑 ClusterRoleBinding
kubectl edit clusterrolebinding <clusterrolebinding-name>

# 查看管理员权限绑定
kubectl get clusterrolebinding cluster-admin -o yaml

使用场景:

  • 集群管理员授权
  • 集群级别权限绑定
  • 服务账号集群权限
  • 超级管理员配置

1.5 权限检查

# 检查用户是否有权限执行操作
kubectl auth can-i create deployments --as=jane
kubectl auth can-i delete pods --as=jane -n default

# 检查 ServiceAccount 权限
kubectl auth can-i list pods --as=system:serviceaccount:default:mysa

# 检查特定资源的权限
kubectl auth can-i get pods --resource-name=my-pod -n default

# 列出用户的所有权限
kubectl auth can-i --list --as=jane

# 检查用户在命名空间的权限
kubectl auth can-i --list --as=jane -n default

# 检查是否有特定角色的权限
kubectl auth can-i --list --as=jane | grep pod-reader

# 查看角色的权限范围
kubectl auth can-i --list --as=system:anonymous

使用场景:

  • 权限验证
  • 访问控制测试
  • 安全审计
  • 权限排查

二、服务账号管理

2.1 服务账号操作

# 查看所有 ServiceAccount
kubectl get serviceaccounts --all-namespaces

# 查看指定命名空间的 ServiceAccount
kubectl get serviceaccounts -n <namespace>

# 查看 ServiceAccount 详情
kubectl describe serviceaccount <sa-name> -n <namespace>

# 创建 ServiceAccount(YAML)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default
EOF

# 创建 ServiceAccount(命令行)
kubectl create serviceaccount my-service-account -n default

# 删除 ServiceAccount
kubectl delete serviceaccount <sa-name> -n <namespace>

# 编辑 ServiceAccount
kubectl edit serviceaccount <sa-name> -n <namespace>

# 查看 ServiceAccount 的 Secret
kubectl get serviceaccount <sa-name> -n <namespace> -o jsonpath='{.secrets}'

# 查看 ServiceAccount 的 Token
kubectl get secret <secret-name> -n <namespace> -o jsonpath='{.data.token}' | base64 --decode

使用场景:

  • Pod 身份认证
  • API 访问认证
  • 服务间认证
  • CI/CD 认证

2.2 服务账号权限绑定

# 为 ServiceAccount 授予 Role
kubectl create rolebinding my-sa-binding --role=pod-reader --serviceaccount=default:my-service-account -n default

# 为 ServiceAccount 授予 ClusterRole
kubectl create clusterrolebinding my-sa-cluster-binding --clusterrole=node-reader --serviceaccount=default:my-service-account

# 在 Pod 中使用 ServiceAccount
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-service-account
  containers:
  - name: my-container
    image: nginx
EOF

# 查看 Pod 使用的 ServiceAccount
kubectl get pod <pod-name> -o jsonpath='{.spec.serviceAccountName}'

# 查看 ServiceAccount 的镜像拉取密钥
kubectl get serviceaccount <sa-name> -n <namespace> -o jsonpath='{.imagePullSecrets}'

使用场景:

  • Pod 权限控制
  • 最小权限原则
  • 服务账号隔离
  • 安全最佳实践

三、网络策略(Network Policy)

3.1 网络策略管理

# 查看所有 NetworkPolicy
kubectl get networkpolicies --all-namespaces

# 查看指定命名空间的 NetworkPolicy
kubectl get networkpolicies -n <namespace>

# 查看 NetworkPolicy 详情
kubectl describe networkpolicy <policy-name> -n <namespace>

# 创建 NetworkPolicy(YAML)
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

# 创建允许特定流量的 NetworkPolicy
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: allowed
    ports:
    - protocol: TCP
      port: 80
EOF

# 删除 NetworkPolicy
kubectl delete networkpolicy <policy-name> -n <namespace>

# 编辑 NetworkPolicy
kubectl edit networkpolicy <policy-name> -n <namespace>

使用场景:

  • 网络隔离
  • 访问控制
  • 多租户隔离
  • 安全加固

3.2 常用网络策略示例

# 拒绝所有入站流量
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
EOF

# 拒绝所有出站流量
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
EOF

# 允许特定命名空间的流量
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production
EOF

# 允许 DNS 查询
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
spec:
  podSelector: {}
  egress:
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
EOF

使用场景:

  • 默认拒绝策略
  • 精细化访问控制
  • 命名空间隔离
  • 服务隔离

四、Pod 安全策略

4.1 Pod Security Standards(PSS)

# 查看命名空间的 Pod Security 标签
kubectl get namespace <namespace> -o jsonpath='{.metadata.labels}'

# 设置命名空间的 Pod Security 标准
kubectl label namespace <namespace> pod-security.kubernetes.io/enforce=restricted
kubectl label namespace <namespace> pod-security.kubernetes.io/audit=restricted
kubectl label namespace <namespace> pod-security.kubernetes.io/warn=restricted

# 查看三种安全级别
# privileged - 不限制(默认)
# baseline - 基础限制
# restricted - 严格限制

# 移除 Pod Security 标签
kubectl label namespace <namespace> pod-security.kubernetes.io/enforce-

# 验证 Pod Security 配置
kubectl get namespace <namespace> -o yaml | grep pod-security

使用场景:

  • Pod 安全加固
  • 特权控制
  • 容器安全
  • 合规要求

4.2 安全上下文(Security Context)

# 创建安全上下文的 Pod
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: security-context-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: my-container
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
EOF

# 查看 Pod 的安全上下文
kubectl get pod <pod-name> -o jsonpath='{.spec.securityContext}'

# 查看容器的安全上下文
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].securityContext}'

# 查看容器的 capabilities
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].securityContext.capabilities}'

# 验证 Pod 是否以非 root 运行
kubectl exec <pod-name> -- id
kubectl exec <pod-name> -- ps aux | grep nginx

使用场景:

  • 非 root 用户运行
  • 只读文件系统
  • 能力控制(Capabilities)
  • 特权控制

五、镜像安全

5.1 镜像签名验证

# 查看镜像签名(需要 cosign)
cosign verify <image-name>:<tag>

# 签名镜像
cosign sign -key cosign.key <image-name>:<tag>

# 验证镜像签名
cosign verify -key cosign.pub <image-name>:<tag>

# 查看镜像摘要
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].image}'

# 使用镜像摘要(推荐)
kubectl set image deployment/<deployment-name> <container-name>=<image-name>@sha256:<digest>

# 查看镜像拉取策略
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].imagePullPolicy}'

# 设置镜像拉取策略为 Always
kubectl patch deployment <deployment-name> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container-name>","imagePullPolicy":"Always"}]}}}}'

使用场景:

  • 镜像完整性验证
  • 防止镜像篡改
  • 安全镜像拉取
  • 镜像来源验证

5.2 镜像漏洞扫描

# 使用 Trivy 扫描镜像
trivy image <image-name>:<tag>

# 使用 Clair 扫描镜像
clair-scanner <image-name>:<tag>

# 使用 Anchore 扫描镜像
anchore-cli image add <image-name>:<tag>
anchore-cli image vuln <image-name>:<tag> all

# 扫描 Pod 中的所有镜像
kubectl get pods -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | sort | uniq | xargs -I {} trivy image {}

# 导出漏洞报告
trivy image --output report.json <image-name>:<tag>

# 只显示高危和严重漏洞
trivy image --severity HIGH,CRITICAL <image-name>:<tag>

使用场景:

  • 漏洞检测
  • 安全审计
  • 镜像评估
  • 合规检查

5.3 镜像拉取密钥管理

# 创建 Docker Registry Secret
kubectl create secret docker-registry my-registry-key \
  --docker-server=<registry-server> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email>

# 查看 Secret
kubectl get secret my-registry-key -o yaml

# 在 Pod 中使用镜像拉取密钥
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: private-pod
spec:
  imagePullSecrets:
  - name: my-registry-key
  containers:
  - name: my-container
    image: <private-registry>/<image>:<tag>
EOF

# 为 ServiceAccount 添加镜像拉取密钥
kubectl patch serviceaccount default -p '{"imagePullSecrets":[{"name":"my-registry-key"}]}'

# 查看 ServiceAccount 的镜像拉取密钥
kubectl get serviceaccount default -o jsonpath='{.imagePullSecrets}'

使用场景:

  • 私有镜像仓库认证
  • 安全镜像拉取
  • 凭证管理
  • 自动化部署

六、证书管理

6.1 证书查看

# 查看证书有效期(kubeadm)
kubeadm certs check-expiration

# 查看 API Server 证书
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout

# 查看 kubelet 证书
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout

# 查看 etcd 证书
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -text -noout

# 查看证书过期时间
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

# 查看证书主体
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -subject

# 查看证书颁发者
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -issuer

# 查看 CA 证书
openssl x509 -in /etc/kubernetes/pki/ca.crt -text -noout

使用场景:

  • 证书有效期检查
  • 证书内容查看
  • 证书验证
  • 证书更新

6.2 证书更新

# 更新所有证书(kubeadm)
kubeadm certs renew all

# 更新特定证书
kubeadm certs renew apiserver
kubeadm certs renew apiserver-kubelet-client
kubeadm certs renew front-proxy-client
kubeadm certs renew etcd-server
kubeadm certs renew etcd-peer
kubeadm certs renew etcd-healthcheck-client

# 更新 kubeconfig
kubeadm init phase kubeconfig all

# 重启服务使证书生效
kubectl rollout restart deployment -n kube-system
systemctl restart kubelet
systemctl restart docker

# 验证证书更新
kubeadm certs check-expiration

使用场景:

  • 证书过期更新
  • 定期证书轮换
  • 安全加固
  • 合规要求

6.3 证书轮换

# 启用 kubelet 证书轮换
cat <<EOF | kubectl apply -f -
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
rotateCertificates: true
EOF

# 查看 kubelet 证书轮换状态
kubectl get csr

# 手动批准 CSR
kubectl certificate approve <csr-name>

# 拒绝 CSR
kubectl certificate deny <csr-name>

# 查看待处理的 CSR
kubectl get csr | grep Pending

# 自动批准 CSR(需要配置 ClusterRole)
kubectl create clusterrolebinding csr-approver --clusterrole=system:certificates.k8s.io:certificatesigningrequests:nodeclient --user=kubelet-bootstrap

使用场景:

  • 自动证书轮换
  • 节点证书管理
  • 证书审批
  • 安全自动化

七、审计日志

7.1 审计日志配置

# 查看审计日志配置
cat /etc/kubernetes/audit/audit.yaml

# 查看审计日志文件
tail -f /var/log/kubernetes/audit.log

# 查看审计日志大小
ls -lh /var/log/kubernetes/audit.log

# 查看审计策略
cat /etc/kubernetes/audit/audit.yaml | grep -A 10 "rules:"

# 修改审计策略
vi /etc/kubernetes/audit/audit.yaml

# 重启 API Server 使配置生效
kubectl rollout restart deployment -n kube-system kube-apiserver

使用场景:

  • 安全审计
  • 操作追踪
  • 合规检查
  • 事件溯源

7.2 审计日志查询

# 查看最近的审计日志
tail -n 100 /var/log/kubernetes/audit.log | jq .

# 筛选特定用户的操作
cat /var/log/kubernetes/audit.log | jq 'select(.user.username=="admin")'

# 筛选特定资源的操作
cat /var/log/kubernetes/audit.log | jq 'select(.objectRef.resource=="pods")'

# 筛选特定操作类型
cat /var/log/kubernetes/audit.log | jq 'select(.verb=="delete")'
cat /var/log/kubernetes/audit.log | jq 'select(.verb=="create")'

# 筛选失败的操作
cat /var/log/kubernetes/audit.log | jq 'select(.responseStatus.code>=400)'

# 统计操作次数
cat /var/log/kubernetes/audit.log | jq -r '.verb' | sort | uniq -c

# 统计用户操作次数
cat /var/log/kubernetes/audit.log | jq -r '.user.username' | sort | uniq -c

# 导出审计日志
cat /var/log/kubernetes/audit.log | jq . > audit-export.json

使用场景:

  • 操作审计
  • 用户行为分析
  • 安全事件调查
  • 合规报告

八、安全加固最佳实践

8.1 集群安全检查

# 使用 kube-bench 检查集群安全
kube-bench run --targets master
kube-bench run --targets node

# 使用 kube-hunter 检查集群漏洞
kube-hunter --remote

# 检查匿名访问
kubectl get clusterrolebinding cluster-admin -o yaml | grep system:anonymous

# 检查默认 ServiceAccount 权限
kubectl get clusterrolebinding | grep default

# 检查未加密的 Secret
kubectl get secrets --all-namespaces -o jsonpath='{.items[?(@.type=="Opaque")].metadata.name}'

# 检查特权 Pod
kubectl get pods --all-namespaces -o jsonpath='{.items[?(@.spec.containers[*].securityContext.privileged==true)].metadata.name}'

# 检查 hostPath 挂载
kubectl get pods --all-namespaces -o jsonpath='{.items[?(@.spec.volumes[*].hostPath)].metadata.name}'

使用场景:

  • 安全基线检查
  • 漏洞扫描
  • 安全评估
  • 合规检查

8.2 安全加固措施

# 禁用匿名访问
kubectl delete clusterrolebinding cluster-anonymous

# 限制默认 ServiceAccount 权限
kubectl patch clusterrolebinding default -p '{"subjects":null}'

# 启用 Pod Security Standards
kubectl label namespace default pod-security.kubernetes.io/enforce=restricted

# 启用网络策略
kubectl apply -f deny-all-network-policy.yaml

# 启用审计日志
kubectl apply -f audit-policy.yaml

# 定期轮换证书
kubeadm certs renew all

# 更新 kubeconfig
kubeadm init phase kubeconfig all

# 重启服务
systemctl restart kubelet
systemctl restart docker

使用场景:

  • 集群加固
  • 安全基线
  • 合规要求
  • 安全最佳实践

九、总结

9.1 安全体系

认证(Authentication)
    ↓
授权(RBAC)
    ↓
准入控制(Admission Control)
    ↓
网络策略(Network Policy)
    ↓
Pod 安全(Security Context)
    ↓
审计日志(Audit Log)

9.2 安全检查清单

  • 禁用匿名访问
  • 配置 RBAC 最小权限
  • 启用 Network Policy
  • 启用 Pod Security Standards
  • 配置 Security Context
  • 镜像签名验证
  • 镜像漏洞扫描
  • 定期证书轮换
  • 启用审计日志
  • 定期安全扫描

9.3 常用安全命令速查

场景 命令
权限检查 kubectl auth can-i create pods
查看角色 kubectl get roles --all-namespaces
查看绑定 kubectl get rolebindings
网络策略 kubectl get networkpolicies
证书检查 kubeadm certs check-expiration
证书更新 kubeadm certs renew all
审计日志 cat /var/log/kubernetes/audit.log
安全扫描 kube-bench run

参考资料


作者: PaPaBot
发布时间: 2026-03-07
标签: #Kubernetes #K8s #DevOps #安全 #RBAC


本文属于《K8s 命令实战指南》系列文章第五篇(完结篇)

Views: 27

K8s 学习:常用命令 100 条(四)- 监控与日志

K8s 学习:常用命令 100 条(四)- 监控与日志

监控

系列文章: K8s 命令实战指南
适用人群: SRE 工程师、运维工程师、DevOps 工程师
阅读时间: 18 分钟


前言

监控和日志是保障 Kubernetes 集群稳定运行的关键。本文介绍如何使用 kubectl 命令进行监控、日志收集和分析。


一、资源监控

1.1 节点资源监控

# 查看节点资源使用
kubectl top node

# 查看节点资源使用(JSON 格式)
kubectl top node -o json

# 查看节点详细信息
kubectl describe node <node-name>

# 查看节点资源分配
kubectl describe node <node-name> | grep -A 10 "Allocated resources"

# 查看节点条件
kubectl get nodes -o custom-columns='NAME:metadata.name,STATUS:status.conditions[?(@.type=="Ready")].status,CPU:status.capacity.cpu,MEMORY:status.capacity.memory'

# 查看节点容量
kubectl get node <node-name> -o jsonpath='{.status.capacity}'

# 查看节点可分配资源
kubectl get node <node-name> -o jsonpath='{.status.allocatable}'

# 持续监控节点资源
watch kubectl top node

使用场景:

  • 监控节点资源使用
  • 容量规划
  • 节点负载分析
  • 资源瓶颈识别

1.2 Pod 资源监控

# 查看 Pod 资源使用
kubectl top pod

# 查看指定命名空间的 Pod 资源
kubectl top pod -n <namespace>

# 查看所有命名空间的 Pod 资源
kubectl top pod --all-namespaces

# 按 CPU 使用排序
kubectl top pod --sort-by=cpu

# 按内存使用排序
kubectl top pod --sort-by=memory

# 查看 Pod 的容器资源使用
kubectl top pod <pod-name> --containers

# 查看资源请求和限制
kubectl get pod <pod-name> -o custom-columns='NAME:metadata.name,CPU_REQ:spec.containers[*].resources.requests.cpu,CPU_LIM:spec.containers[*].resources.limits.cpu,MEM_REQ:spec.containers[*].resources.requests.memory,MEM_LIM:spec.containers[*].resources.limits.memory'

# 持续监控 Pod 资源
watch kubectl top pod -l app=<app-name>

使用场景:

  • 监控应用资源使用
  • 性能分析
  • 资源优化
  • 容量规划

1.3 容器资源监控

# 查看容器资源使用
kubectl top pod <pod-name> --containers

# 查看所有容器资源
kubectl top pod --all-namespaces --containers

# 查看容器资源使用(排序)
kubectl top pod --all-namespaces --containers --sort-by=cpu

# 查看容器资源限制
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources}'

# 查看容器资源使用率
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources.requests}' | jq

使用场景:

  • 容器级别监控
  • 精细化资源管理
  • 容器性能分析
  • 多容器 Pod 监控

二、事件监控

2.1 集群事件

# 查看所有事件
kubectl get events

# 查看指定命名空间的事件
kubectl get events -n <namespace>

# 查看事件(排序)
kubectl get events --sort-by=.metadata.creationTimestamp

# 查看事件(监视模式)
kubectl get events --watch

# 查看事件(宽输出)
kubectl get events -o wide

# 查看事件(JSON 格式)
kubectl get events -o json

# 查看事件(YAML 格式)
kubectl get events -o yaml

# 按类型筛选事件
kubectl get events --field-selector type=Warning
kubectl get events --field-selector type=Normal

# 按原因筛选事件
kubectl get events --field-selector reason=FailedScheduling
kubectl get events --field-selector reason=OOMKilled
kubectl get events --field-selector reason=Pulling

# 按资源类型筛选
kubectl get events --field-selector involvedObject.kind=Pod
kubectl get events --field-selector involvedObject.kind=Node
kubectl get events --field-selector involvedObject.kind=Service

使用场景:

  • 集群异常监控
  • 调度问题排查
  • 资源冲突识别
  • 事件历史查询

2.2 资源事件

# 查看 Pod 事件
kubectl describe pod <pod-name> | grep -A 20 Events

# 查看 Deployment 事件
kubectl describe deployment <deployment-name> | grep -A 20 Events

# 查看 Service 事件
kubectl describe service <service-name> | grep -A 20 Events

# 查看 Node 事件
kubectl describe node <node-name> | grep -A 20 Events

# 查看特定资源的事件
kubectl get events --field-selector involvedObject.name=<resource-name>

# 查看特定 UID 的事件
kubectl get events --field-selector involvedObject.uid=<uid>

使用场景:

  • 资源故障排查
  • 事件追踪
  • 问题定位
  • 状态变更监控

三、日志收集

3.1 Pod 日志

# 查看 Pod 日志
kubectl logs <pod-name>

# 查看 Pod 日志(指定容器)
kubectl logs <pod-name> -c <container-name>

# 查看 Pod 日志(实时跟踪)
kubectl logs -f <pod-name>

# 查看 Pod 日志(最近 N 行)
kubectl logs --tail=100 <pod-name>

# 查看 Pod 日志(指定时间范围)
kubectl logs --since=1h <pod-name>
kubectl logs --since-time=2024-01-01T00:00:00Z <pod-name>

# 查看 Pod 日志(保存到文件)
kubectl logs <pod-name> > pod.log

# 查看前一个容器的日志(容器重启后)
kubectl logs <pod-name> --previous

# 查看所有容器的日志
kubectl logs <pod-name> --all-containers

# 查看多个 Pod 的日志(需要安装 stern)
stern <pod-name-pattern>

# 查看 Pod 日志(带时间戳)
kubectl logs <pod-name> --timestamps

# 查看 Pod 日志(限制字节数)
kubectl logs <pod-name> --limit-bytes=10000

使用场景:

  • 应用日志查看
  • 故障排查
  • 性能分析
  • 安全审计

3.2 系统日志

# 查看 kubelet 日志(SSH 到节点)
journalctl -u kubelet -f

# 查看容器运行时日志(SSH 到节点)
journalctl -u docker -f
journalctl -u containerd -f

# 查看系统日志(SSH 到节点)
tail -f /var/log/syslog
tail -f /var/log/messages

# 查看 kube-apiserver 日志
kubectl logs -n kube-system kube-apiserver-<node-name>

# 查看 kube-controller-manager 日志
kubectl logs -n kube-system kube-controller-manager-<node-name>

# 查看 kube-scheduler 日志
kubectl logs -n kube-system kube-scheduler-<node-name>

# 查看 etcd 日志
kubectl logs -n kube-system etcd-<node-name>

# 查看 kube-proxy 日志
kubectl logs -n kube-system kube-proxy-<node-name>

# 查看 CoreDNS 日志
kubectl logs -n kube-system -l k8s-app=kube-dns

使用场景:

  • 系统组件故障排查
  • 集群级别问题诊断
  • 安全审计
  • 性能分析

3.3 审计日志

# 查看审计日志配置
cat /etc/kubernetes/audit/audit.yaml

# 查看审计日志文件
tail -f /var/log/kubernetes/audit.log

# 解析审计日志(JSON 格式)
cat /var/log/kubernetes/audit.log | jq .

# 筛选特定用户的操作
cat /var/log/kubernetes/audit.log | jq 'select(.user.username=="admin")'

# 筛选特定资源的操作
cat /var/log/kubernetes/audit.log | jq 'select(.objectRef.resource=="pods")'

# 筛选特定操作
cat /var/log/kubernetes/audit.log | jq 'select(.verb=="delete")'

# 筛选失败的操作
cat /var/log/kubernetes/audit.log | jq 'select(.responseStatus.code>=400)'

使用场景:

  • 安全审计
  • 操作追踪
  • 合规检查
  • 事件溯源

四、Prometheus 监控集成

4.1 部署 Prometheus

# 使用 Helm 部署 Prometheus
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/prometheus

# 查看 Prometheus Pod
kubectl get pods -n default -l app=prometheus

# 查看 Prometheus Service
kubectl get svc -n default -l app=prometheus

# 端口转发访问 Prometheus
kubectl port-forward svc/prometheus-server 9090:80

# 查看 Prometheus 配置
kubectl get configmap prometheus-server -o yaml

# 查看 Prometheus 规则
kubectl get configmap prometheus-server -o jsonpath='{.data.prometheus\.yml}'

使用场景:

  • 监控系统部署
  • 指标收集
  • 告警配置
  • 性能监控

4.2 查询 Prometheus 指标

# 访问 Prometheus API
kubectl port-forward svc/prometheus-server 9090:80

# 查询 CPU 使用率
curl 'http://localhost:9090/api/v1/query?query=rate(container_cpu_usage_seconds_total[5m])'

# 查询内存使用率
curl 'http://localhost:9090/api/v1/query?query=container_memory_usage_bytes'

# 查询网络流量
curl 'http://localhost:9090/api/v1/query?query=rate(container_network_receive_bytes_total[5m])'

# 查询 Pod 重启次数
curl 'http://localhost:9090/api/v1/query?query=increase(kube_pod_container_status_restarts_total[1h])'

# 查询节点资源
curl 'http://localhost:9090/api/v1/query?query=kube_node_status_capacity'

# 查询 PVC 使用量
curl 'http://localhost:9090/api/v1/query?query=kubelet_volume_stats_used_bytes'

使用场景:

  • 指标查询
  • 性能分析
  • 容量规划
  • 自动化监控

五、Grafana 可视化

5.1 部署 Grafana

# 使用 Helm 部署 Grafana
helm repo add grafana https://grafana.github.io/helm-charts
helm install grafana grafana/grafana

# 查看 Grafana Pod
kubectl get pods -l app.kubernetes.io/name=grafana

# 查看 Grafana Service
kubectl get svc -l app.kubernetes.io/name=grafana

# 获取 Grafana 密码
kubectl get secret grafana -o jsonpath="{.data.admin-password}" | base64 --decode

# 端口转发访问 Grafana
kubectl port-forward svc/grafana 3000:80

# 导入 Kubernetes Dashboard
# Dashboard ID: 315 (Kubernetes cluster monitoring)
# Dashboard ID: 6417 (Kubernetes cluster)
# Dashboard ID: 8588 (Kubernetes cluster)

使用场景:

  • 监控可视化
  • 仪表板管理
  • 数据展示
  • 团队协作

5.2 配置数据源

# 配置 Prometheus 数据源
kubectl create configmap grafana-datasources --from-file=datasources.yaml

# datasources.yaml 内容
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-datasources
data:
  datasources.yaml: |
    apiVersion: 1
    datasources:
      - name: Prometheus
        type: prometheus
        url: http://prometheus-server
        access: proxy
        isDefault: true
EOF

# 重启 Grafana
kubectl rollout restart deployment/grafana

使用场景:

  • 数据源配置
  • 多数据源管理
  • 认证配置
  • 权限管理

六、日志收集(EFK)

6.1 部署 EFK

# 部署 Elasticsearch
kubectl apply -f https://download.elastic.co/downloads/eck/2.0.0/crds.yaml
kubectl apply -f https://download.elastic.co/downloads/eck/2.0.0/operator.yaml

# 部署 Elasticsearch 集群
cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 8.0.0
  nodeSets:
  - name: default
    count: 1
    config:
      node.store.allow_mmap: false
EOF

# 部署 Kibana
cat <<EOF | kubectl apply -f -
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 8.0.0
  count: 1
  elasticsearchRef:
    name: quickstart
EOF

# 部署 Fluentd(DaemonSet)
kubectl apply -f fluentd-daemonset.yaml

# 查看 EFK 组件
kubectl get elasticsearch,kibana,pods -l common.k8s.elastic.co/type=elasticsearch

使用场景:

  • 集中式日志收集
  • 日志搜索
  • 日志分析
  • 日志可视化

6.2 查询日志

# 访问 Kibana
kubectl port-forward svc/quickstart-kb-http 5601

# 获取 Kibana 密码
kubectl get secret quickstart-es-elastic-user -o jsonpath='{.data.elastic}' | base64 --decode

# 使用 Elasticsearch API 查询日志
curl -u "elastic:<password>" "http://localhost:9200/_search?q=error&pretty"

# 查询特定索引的日志
curl -u "elastic:<password>" "http://localhost:9200/logstash-*/_search?pretty"

# 查询特定时间范围的日志
curl -u "elastic:<password>" -X GET "http://localhost:9200/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-1h"
      }
    }
  }
}'

# 统计错误数量
curl -u "elastic:<password>" -X GET "http://localhost:9200/_count?q=level:error"

使用场景:

  • 日志查询
  • 日志分析
  • 错误追踪
  • 审计查询

七、告警配置

7.1 Prometheus 告警规则

# 创建告警规则 ConfigMap
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-alerts
data:
  alerts.rules: |
    groups:
    - name: kubernetes-alerts
      rules:
      - alert: PodCrashLooping
        expr: rate(kube_pod_container_status_restarts_total[15m]) * 60 * 15 > 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Pod {{ $labels.pod }} is crash looping"
          description: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is restarting {{ $value }} times per 15 minutes"

      - alert: NodeNotReady
        expr: kube_node_status_condition{condition="Ready",status="true"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Node {{ $labels.node }} is not ready"
          description: "Node {{ $labels.node }} has been unready for more than 1 minute"

      - alert: HighCPUUsage
        expr: rate(container_cpu_usage_seconds_total[5m]) > 0.8
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU usage"
          description: "Container {{ $labels.container }} in pod {{ $labels.pod }} is using high CPU"

      - alert: HighMemoryUsage
        expr: container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.9
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High memory usage"
          description: "Container {{ $labels.container }} is using >90% of memory limit"
EOF

# 查看告警规则
kubectl get configmap prometheus-alerts -o yaml

# 查看告警状态
kubectl port-forward svc/prometheus-server 9090:80
curl http://localhost:9090/api/v1/alerts

使用场景:

  • 异常告警
  • 性能告警
  • 资源告警
  • 自定义告警

7.2 Alertmanager 配置

# 创建 Alertmanager 配置
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
type: Opaque
stringData:
  alertmanager.yaml: |
    global:
      resolve_timeout: 5m
      smtp_smarthost: 'smtp.example.com:587'
      smtp_from: 'alertmanager@example.com'
      smtp_auth_username: 'alertmanager@example.com'
      smtp_auth_password: 'password'

    route:
      group_by: ['alertname']
      group_wait: 10s
      group_interval: 10s
      repeat_interval: 1h
      receiver: 'email'

    receivers:
    - name: 'email'
      email_configs:
      - to: 'team@example.com'
        send_resolved: true
EOF

# 部署 Alertmanager
kubectl apply -f alertmanager-deployment.yaml

# 查看 Alertmanager
kubectl get pods -l app=alertmanager

# 访问 Alertmanager UI
kubectl port-forward svc/alertmanager 9093:9093

使用场景:

  • 告警通知
  • 告警路由
  • 告警静默
  • 告警聚合

八、性能分析

8.1 性能基线

# 收集性能基线数据
kubectl top nodes > baseline-nodes.txt
kubectl top pods --all-namespaces > baseline-pods.txt

# 比较性能数据
diff baseline-nodes.txt current-nodes.txt

# 监控性能趋势
watch -n 5 'kubectl top nodes && echo "---" && kubectl top pods --all-namespaces | head -20'

# 导出性能数据(CSV 格式)
kubectl top nodes --no-headers | awk '{print $1","$2","$3}' > nodes-perf.csv
kubectl top pods --all-namespaces --no-headers | awk '{print $1","$2","$3","$4}' > pods-perf.csv

# 分析性能瓶颈
kubectl top pods --all-namespaces --sort-by=cpu | head -10
kubectl top pods --all-namespaces --sort-by=memory | head -10

使用场景:

  • 性能基线建立
  • 性能对比
  • 趋势分析
  • 瓶颈识别

8.2 资源优化

# 查看资源使用情况
kubectl top pod <pod-name> --containers

# 查看资源请求和限制
kubectl describe pod <pod-name> | grep -A 5 "Limits:\|Requests:"

# 调整资源请求和限制
kubectl set resources deployment/<deployment-name> --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

# 查看资源配额
kubectl get resourcequota -n <namespace>

# 查看限制范围
kubectl get limitrange -n <namespace>

# 查看资源使用率
kubectl top pod <pod-name> --containers | awk '{if(NR>1) print $1, $2, $3, $4}'

使用场景:

  • 资源优化
  • 成本控制
  • 性能调优
  • 容量规划

九、总结

9.1 监控体系

指标收集(Prometheus)
    ↓
数据存储(Prometheus)
    ↓
可视化展示(Grafana)
    ↓
告警通知(Alertmanager)

9.2 日志体系

日志收集(Fluentd)
    ↓
日志存储(Elasticsearch)
    ↓
日志搜索(Elasticsearch)
    ↓
可视化展示(Kibana)

9.3 常用监控命令速查

场景 命令
节点资源 kubectl top node
Pod 资源 kubectl top pod
容器日志 kubectl logs <pod-name>
系统日志 journalctl -u kubelet -f
集群事件 kubectl get events
审计日志 cat /var/log/kubernetes/audit.log
性能分析 kubectl top pod --sort-by=cpu

参考资料


作者: PaPaBot
发布时间: 2026-03-07
标签: #Kubernetes #K8s #DevOps #监控 #日志


本文属于《K8s 命令实战指南》系列文章第四篇

Views: 43

OpenClaw 企业微信智能机器人接入完全指南

OpenClaw 企业微信智能机器人接入完全指南

发布时间: 2026-03-09
标签: OpenClaw, 企业微信, AI机器人, 自动化
分类: 教程


前言

OpenClaw 支持接入企业微信智能机器人,打造专属的智能办公助手。本文将详细介绍如何通过长连接方式将 OpenClaw 接入企业微信。

官方文档: OpenClaw接入企业微信智能机器人


一、前期准备

在开始之前,请确认已完成以下准备工作:

准备项 说明
✅ 企业微信客户端 安装最新版本
✅ OpenClaw 部署 本地或云服务器部署完成
✅ 管理员权限 企业微信管理后台访问权限

二、创建企业微信智能机器人

2.1 进入机器人创建页面

  1. 打开企业微信客户端
  2. 进入工作台
  3. 点击智能机器人
  4. 选择创建机器人
  5. 选择 API模式

2.2 选择长连接方式

重要:选择长连接方式创建,而不是 Webhook 方式。

长连接方式的优势

  • ✅ 支持主动向用户发送消息
  • ✅ 实时双向通信
  • ✅ 无需公网服务器

2.3 获取 Bot ID 和 Secret

创建成功后,系统会生成:

  • Bot ID: 机器人的唯一标识
  • Secret: 用于鉴权的密钥

⚠️ 重要:请妥善保管 Secret,不要泄露!


三、关联机器人与 OpenClaw

根据你的部署方式,选择对应的配置方法:

方式一:腾讯云 Lighthouse 部署(推荐)

如果你使用腾讯云轻量应用服务器 Lighthouse 部署 OpenClaw:

  1. 进入轻量云控制台
  2. 选中已部署 OpenClaw 的服务器实例
  3. 进入"应用管理"页面
  4. 选择企微机器人(长连接)通道
  5. 输入 Bot IDSecret
  6. 点击"添加并应用"
  7. 重启 OpenClaw

方式二:本地终端部署(本文重点)

如果你在本地或自建服务器部署 OpenClaw:

3.1 安装企微插件

openclaw plugins install @wecom/wecom-openclaw-plugin

安装成功后会看到成功提示。

3.2 重启 OpenClaw

openclaw gateway start

3.3 添加企业微信 Channel

openclaw channels add

按照提示操作:

  1. Select channel: 选择 企业微信
  2. 输入 Bot ID: 粘贴之前获取的 Bot ID
  3. 输入 Secret: 粘贴之前获取的 Secret
  4. 选择 finish: 完成基础配置
  5. 选择配对方式: 选择 Pairing

3.4 完成配对流程

关键步骤

  1. 在企业微信机器人创建页面,点击保存并创建
  2. 在企业微信中找到刚创建的机器人,发送任意消息
  3. 机器人会回复一个配置密钥(类似验证码)
  4. 复制密钥的最后一行
  5. 在终端中粘贴此密钥,完成配对

配对成功后,即可在企业微信中正常对话!


四、验证接入

4.1 检查 Channel 状态

openclaw status --deep

期望输出:

│ 企业微信     │ ON      │ OK     │ configured │

4.2 发送测试消息

在企业微信中找到机器人,发送:

你好

如果收到回复,说明接入成功!


五、高级配置

5.1 配置访问策略

私聊开放模式(测试推荐):

openclaw config set channels.wecom.dmPolicy open
openclaw config set channels.wecom.allowFrom '["*"]'

私聊白名单模式(生产推荐):

openclaw config set channels.wecom.dmPolicy allowlist
openclaw config set channels.wecom.allowFrom '["user@company.com"]'

群组白名单模式

openclaw config set channels.wecom.groupPolicy allowlist
openclaw config set channels.wecom.groupAllowFrom '["群组ID"]'

5.2 使用企业微信 API

如需调用企业微信应用 API:

  1. 在管理后台 → 我的企业,获取企业ID (corpid)
  2. 在应用管理 → 自建应用,获取应用Secret
  3. 发送 corpid 和 Secret 给机器人
  4. 机器人会获取 access token
  5. 使用 access token 调用企微 API

示例场景

  • 调用文档 API
  • 管理企业通讯录
  • 发送应用消息

5.3 智能表格 Webhook

企业微信智能表格支持通过 Webhook 接收外部数据:

  1. 在智能表格中开启"接收外部数据"
  2. 获取唯一的 Webhook 地址
  3. 通过 HTTP POST 请求新增或更新记录

适用场景

  • 自动化数据采集
  • 第三方系统集成
  • 定时任务同步

六、故障排查

6.1 插件加载失败

问题Cannot find module 'axios'

解决

cd ~/.openclaw/extensions/wecom-openclaw-plugin
npm install axios
openclaw gateway restart

6.2 配对失败

问题:输入密钥后无法配对

排查步骤

  1. 确认 Bot ID 和 Secret 正确
  2. 确认网络连接正常
  3. 重新创建机器人,获取新的密钥
  4. 检查 OpenClaw 日志:openclaw logs | grep wecom

6.3 消息无响应

问题:发送消息后无回复

可能原因

  • Channel 未启用
  • dmPolicy 配置错误
  • 配对未完成

解决

# 检查 Channel 状态
openclaw status --deep

# 查看日志
openclaw logs | grep wecom

# 确认配置
openclaw config get channels.wecom.dmPolicy

七、最佳实践

7.1 安全配置

生产环境推荐

{
  "channels.wecom.dmPolicy": "allowlist",
  "channels.wecom.allowFrom": ["allowed-user@company.com"],
  "channels.wecom.groupPolicy": "allowlist",
  "channels.wecom.groupAllowFrom": ["allowed-group-id"]
}

7.2 性能优化

  • 使用白名单模式减少不必要的消息处理
  • 定期清理日志:openclaw logs --clear
  • 监控系统资源:openclaw status

7.3 人设定制

OpenClaw 支持根据场景自动切换人设:

场景 身份 风格
私聊 小弟/搭档 呆萌犹豫、有温度
学生群 智能助教 友好专业、循循善诱
同事群 技术秘书 高效专业、不卑不亢
公众场合 AI助手 礼貌克制、有边界

编辑 SOUL.md 文件可自定义人设。


八、总结

OpenClaw 企业微信接入的核心流程:

创建机器人(长连接) → 获取Bot ID和Secret → 安装插件 → 配置Channel → 完成配对 → 开始对话

核心步骤

  1. ✅ 在企业微信客户端创建智能机器人(长连接方式)
  2. ✅ 获取 Bot ID 和 Secret
  3. ✅ 安装企微插件:openclaw plugins install @wecom/wecom-openclaw-plugin
  4. ✅ 添加 Channel:openclaw channels add
  5. ✅ 完成配对流程(发送消息获取密钥)
  6. ✅ 测试验证

优势

  • 🚀 快速部署(15分钟完成)
  • 🔒 安全可控(白名单机制)
  • 🎭 场景自适应(自动切换人设)
  • 🔒 隐私保护(敏感信息不泄露)
  • 📡 长连接支持(主动推送消息)

限制

  • 不能获取历史消息
  • 不能获取企业通讯录(需要额外权限)
  • 图片推送功能受限

参考资料


相关文章推荐

  • OpenClaw 快速入门指南
  • 企业微信智能机器人开发实战
  • AI 助手人设设计最佳实践
  • 使用 OpenClaw 接入智能表格

Views: 65