Claude Code——终端里的全能编程 Agent

引言:AI 编程工具的新纪元

2026年,AI 编程工具已经从"代码补全"进化到"真正的编程伙伴"。在众多工具中,Claude Code 以其独特的"终端 Agent"定位脱颖而出。它不是简单的代码补全工具,而是一个能够理解你的代码库、自主执行任务、验证编译结果的全能工程师。

核心差异

  • Cursor:"你告诉 AI 改什么,AI 帮你改"(辅助驾驶)
  • Claude Code:"你告诉 AI 你想要什么结果,AI 自己去读文件、写代码、跑命令、提交 Git"(自动驾驶)

这种差异让 Claude Code 更接近一个真实的软件工程师——它能独立完成从需求理解到代码验证的完整流程。


一、Claude Code 是什么?

Claude Code 是 Anthropic 推出的终端 AI 编程工具,具有以下特点:

1.1 核心能力

能力 说明
代码理解 自动读取项目结构、分析依赖关系、理解代码上下文
代码生成 根据需求生成符合项目规范的代码(遵循 CLAUDE.md)
命令执行 自动运行 npm、git、maven 等命令
自我验证 编译失败会自动修复,直到代码能运行
Git 集成 自动提交代码、创建分支、处理冲突

1.2 技术架构

Claude Code 架构
├── 核心引擎:Claude 3.7 Sonnet
├── 工具集成
│   ├── 文件系统(读/写)
│   ├── Shell 命令执行
│   ├── Git 操作
│   └── 编译器/测试框架
├── 上下文管理
│   ├── 项目结构分析
│   ├── 依赖关系图
│   └── 代码语义理解
└── 权限系统
    ├── 沙箱模式(默认)
    └── 全权模式(--dangerously-skip-permissions)

1.3 与传统工具的对比

特性 Claude Code Cursor GitHub Copilot
操作方式 终端对话 + 自主执行 IDE 内嵌,手动确认 IDE 内嵌,代码补全
自主程度 ⭐⭐⭐⭐⭐ 高 ⭐⭐⭐ 中 ⭐⭐ 低
适用场景 批量修改、完整功能、重构 边写边改、逐行补全 代码补全、简单建议
IDE 依赖 ❌ 无(任何编辑器) ✅ 必须用 Cursor ✅ 需要插件
自我验证 ✅ 自动编译测试 ❌ 需手动验证 ❌ 无

二、安装与认证

2.1 安装要求

  • Node.js: 21+ (推荐 22+)
  • 操作系统: macOS / Linux / Windows
  • 网络: 需要访问 Anthropic API

2.2 安装方式

方式一:官方脚本(推荐)

# macOS / Linux
curl -fsSL https://claude.ai/install.sh | bash

# Windows(PowerShell)
irm https://claude.ai/install.ps1 | iex

方式二:包管理器

# Homebrew(macOS / Linux)
brew install --cask claude-code

# WinGet(Windows)
winget install Anthropic.ClaudeCode

方式三:NPM(已废弃)

# 不推荐,官方已标记为 deprecated
npm install -g @anthropic-ai/claude-code

2.3 认证流程

首次运行 claude 会自动引导认证:

  1. 选择认证方式

    • Anthropic 账号登录
    • API Key 认证
  2. 设置预算上限(重要!):

    # 建议设置每日预算
    claude config set max-daily-cost 10  # 美元
  3. 验证安装

    claude --version
    claude /help

2.4 价格说明

  • 计费方式: 按 Token 计费(使用 Claude 3.7 Sonnet)
  • 成本估算:
    • 日常编码任务:$2-5/天(比 Copilot 订阅便宜)
    • 复杂重构任务:$10-20/次(注意预算上限)
  • 省钱技巧:
    • 使用 /clear 清除上下文
    • 使用 /compact 压缩对话历史
    • 避免长会话(每个独立任务重新开始)

三、三种核心用法

3.1 交互式对话模式(最常用)

在项目目录下启动:

cd my-project
claude

进入交互式会话后,可以直接用自然语言对话:

你: 实现一个用户签到功能,包括 API、数据库表、前端组件

Claude: 好的,我来实现签到功能。首先让我分析一下项目结构...

[Claude 自动执行]
⏺ Search(pattern: "src/**/*.ts")
⏺ Read(src/models/User.ts)
⏺ Read(src/api/auth.ts)
⏺ Create(src/models/CheckIn.ts)
⏺ Create(src/api/checkin.ts)
⏺ Update(src/database/schema.sql)
⏺ Bash(npm run build)
⏺ Bash(npm test)

✅ 签到功能已完成,包括:
- 数据库表:checkins(id, user_id, check_in_time, points)
- API:POST /api/checkin
- 前端组件:CheckInButton.tsx
- 测试覆盖率:85%

关键差异:Claude Code 会真的去读你的文件、修改代码、跑命令,而不是把代码粘贴给你让你自己改。

3.2 单次任务模式(非交互)

适合写脚本或 CI/CD 集成:

# 单次执行任务
claude "重构 UserService,使用依赖注入"

# 在 CI 中使用
claude --non-interactive "检查代码风格并修复所有 lint 错误"

应用场景

  • 自动化代码审查
  • 批量重构
  • CI/CD 流程中的代码生成
  • 定时任务(如每日代码优化)

3.3 全权委托模式(高级)

⚠️ 警告:此模式不会询问确认,直接执行所有操作!

claude --dangerously-skip-permissions

使用建议

  • 适用场景:新功能开发、原型验证
  • 禁止场景:生产环境、重要数据、核心模块

建议

在新功能开发时用这个,别在生产代码上不经确认直接跑。这个模式就是字面意思的"全权委托",很爽,也要负责任地用。


四、实战:从零实现一个功能

4.1 场景描述

让 Claude Code 从零实现一个「用户签到」功能,包括:

  • 数据库表设计
  • 后端 API
  • 前端组件
  • 单元测试

4.2 执行流程

启动 Claude Code,描述需求:

你: 实现用户签到功能,要求:
1. 每天只能签到一次
2. 连续签到有额外积分奖励
3. 提供 API 和前端组件
4. 需要单元测试

Claude Code 的处理流程(你会在终端里实时看到):

⏺ 分析项目结构...
⏺ Search(pattern: "src/**/*.ts")
⏺ Read(src/models/User.ts)
⏺ Read(src/api/auth.ts)
⏺ Read(src/database/schema.sql)

⏺ 设计数据库表...
⏺ Create(src/models/CheckIn.ts)
  - id: UUID
  - user_id: UUID
  - check_in_time: TIMESTAMP
  - points: INTEGER
  - streak_days: INTEGER

⏺ 实现 API...
⏺ Create(src/api/checkin.ts)
  - POST /api/checkin
  - GET /api/checkin/status
  - GET /api/checkin/history

⏺ 创建前端组件...
⏺ Create(src/components/CheckInButton.tsx)
⏺ Create(src/components/CheckInHistory.tsx)

⏺ 编写测试...
⏺ Create(tests/checkin.test.ts)

⏺ 验证实现...
⏺ Bash(npm run build)
  ✅ Build successful

⏺ Bash(npm test)
  ✅ Tests passed (12/12)

✅ 签到功能已完成!

整个过程 1-2 分钟,它会自己读项目结构、对齐包名、编译验证。通常在它跑的时候喝杯水。

4.3 自动纠错循环

如果编译失败,它会自己修:

⏺ Bash(npm run build)
  ❌ Error: Cannot find module '@/models/User'

⏺ 修复导入路径...
⏺ Update(src/api/checkin.ts)
  - import { User } from '@/models/User'
  + import { User } from '../models/User'

⏺ Bash(npm run build)
  ✅ Build successful

这就是和 Cursor 的本质区别:Cursor 给你改完代码,跑不跑得通你自己去 IDE 里看;Claude Code 改完会自己验证,不行自己继续修。


五、核心杀手锏:无限自我纠错循环

5.1 工作流程图

用户描述需求
    ↓
Claude Code 分析项目
    ↓
读取相关文件
    ↓
生成/修改代码
    ↓
编译验证 ──→ 失败 ──→ 自动修复 ──→ 重新编译
    ↓ 成功
返回结果给用户

5.2 实际案例

场景:重构一个模块,涉及 20 个文件的包名修改

Cursor 方式

  1. 你告诉 AI 改哪些文件
  2. AI 逐个修改
  3. 你手动去 IDE 里跑编译
  4. 发现错误,再告诉 AI 改
  5. 循环直到成功

Claude Code 方式

  1. 你说"重构这个模块的包名"
  2. Claude Code 自动:
    • 分析所有依赖文件
    • 批量修改 20 个文件
    • 运行编译
    • 发现错误自动修复
    • 循环直到编译成功
  3. 你喝茶等待 2 分钟,任务完成

5.3 纠错策略

Claude Code 的纠错策略包括:

  1. 导入路径修复:自动对齐项目包结构
  2. 类型错误修复:根据 TypeScript 错误自动调整类型
  3. 依赖安装:缺少包会自动 npm install
  4. 测试修复:测试失败会自动修改代码
  5. Lint 修复:自动运行 eslint --fix

六、常用斜杠命令

6.1 生存指南

命令 作用 使用频率
/help 查看所有可用命令 偶尔
/clear 清除当前对话上下文,开始新任务 ⭐⭐⭐⭐⭐ 极高
/compact 压缩对话历史(减少 Token 消耗) ⭐⭐⭐⭐ 高
/cost 查看当前会话消耗了多少 Token 和费用 ⭐⭐⭐ 中
/bug 报告 Claude Code 的 Bug 偶尔
/exitCtrl+C 退出 每次结束

6.2 最爱的命令:/clear

为什么最常用?

你: 实现功能 A
Claude: [完成功能 A]

你: /clear  ← 清除上下文

你: 实现功能 B
Claude: [完成功能 B,不会受功能 A 的干扰]

好处

  1. 防止干扰:旧上下文不会影响新任务
  2. 节省 Token:减少不必要的上下文传递
  3. 提高准确性:AI 不会被旧任务误导

最佳实践:每完成一个独立任务就 /clear 一次。

6.3 /compact 的妙用

长会话时,对话历史会越来越长,消耗大量 Token。/compact 会智能压缩:

原对话(5000 tokens):
你: 修改文件 A
Claude: [修改 A]
你: 修改文件 B
Claude: [修改 B]
...(50 轮对话)

压缩后(500 tokens):
已完成的任务:
- 修改了文件 A、B、C...
- 当前状态:项目可编译
- 下一步:等待用户指令

七、CLAUDE.md——给 Claude Code 的项目规范

7.1 什么是 CLAUDE.md?

和 Cursor 的 .cursorrules 一样,Claude Code 支持在项目根目录放一个 CLAUDE.md 文件,每次启动都会自动读取这份规范。

作用

  • 定义项目技术栈
  • 规定代码风格
  • 约定命名规范
  • 禁止某些操作

7.2 完整示例

# CLAUDE.md

## 项目信息
- Java 21 + Spring Boot 3.5.11 + Spring AI 1.1.2
- 包名:com.jichi.agent
- 构建工具:Maven

## 代码规范
- 使用 @Slf4j 打日志,不用 System.out.println
- DTO 用 Java Record
- 构造器注入,不用 @Autowired 字段注入
- 异常用 ResponseStatusException,统一在 @RestControllerAdvice 处理
- 每个类头部必须有 package 声明和完整 import

## Spring AI 规范
- ChatModel 注入用 @Qualifier("dashScopeChatModel")
- 不用 ChatClient.Builder,直接注入 ChatModel 再 build
- SearchRequest 用 builder 模式:SearchRequest.builder().query(q).topK(5).build()

## 禁止事项
- 不要生成任何测试类(我们有独立的测试模块)
- 不要修改 pom.xml 里已有的依赖版本
- 代码注释用中文

## 数据库规范
- 表名用下划线命名:user_checkins
- 主键用 UUID
- 必须有 created_at 和 updated_at 字段
- 软删除用 deleted_at 字段

## API 规范
- RESTful 风格
- 统一返回格式:Response<T>
- 错误码遵循 HTTP 标准

7.3 CLAUDE.md 的好处

  1. 代码风格统一:生成的代码像你自己人写的
  2. 减少沟通成本:不用每次都重复说明规范
  3. 项目活文档:新人加入可以读这个文件快速了解规范
  4. 提高效率:AI 第一次就生成符合规范的代码

7.4 最佳实践

写得越具体,代码越符合你的项目风格

❌ 不好的例子:
## 代码规范
- 写好代码

✅ 好的例子:
## 代码规范
- 使用 @Slf4j 打日志,不用 System.out.println
- DTO 用 Java Record
- 构造器注入,不用 @Autowired 字段注入

八、Claude Code vs Cursor——怎么选?

8.1 核心差异对比

维度 Claude Code Cursor
操作方式 终端对话 + 自主执行 IDE 内嵌,需要手动确认改动
适用场景 批量修改、完整功能实现、重构 边写边改、逐行补全、精细调整
IDE 依赖 无,任何编辑器都能配合 必须用 Cursor IDE
自主程度 高,能自己跑命令、验证编译 中,改完代码需要你自己跑
上手难度 低,终端直接用 低,GUI 操作
价格 按 Token 计费 订阅制($20/月)

8.2 使用场景建议

选择 Claude Code 的场景

  • ✅ 批量修改 20+ 文件
  • ✅ 从零实现完整功能
  • ✅ 重构整个模块
  • ✅ CI/CD 集成
  • ✅ 不想绑定特定 IDE

选择 Cursor 的场景

  • ✅ 日常开发中的逐步实现
  • ✅ 逐行代码补全
  • ✅ 精细调整代码
  • ✅ 需要实时预览
  • ✅ 习惯 GUI 操作

8.3

实际工作流

两个工具我都在用,效率是真的高:

  • Cursor 负责:日常开发中的逐步实现、边写边改、逐行补全
  • Claude Code 负责:"大块头"任务——重构模块、批量修改、从需求生成完整功能

两个一起用,互补性强。

8.4 决策树

你的任务是什么?
├─ 批量修改 10+ 文件 → Claude Code
├─ 从零实现新功能 → Claude Code
├─ 重构模块 → Claude Code
├─ CI/CD 自动化 → Claude Code
├─ 逐行补全代码 → Cursor
├─ 精细调整逻辑 → Cursor
└─ 实时预览效果 → Cursor

九、生态工具介绍

9.1 ccswitch

简介:ccswitch 是 Claude Code 的模型切换工具,支持在不同 Claude 模型之间动态切换。

GitHubhttps://github.com/sst/ccswitch

功能

  • 动态切换 Claude 模型(Sonnet / Opus / Haiku)
  • 根据任务复杂度自动选择模型
  • 成本优化(简单任务用 Haiku,复杂任务用 Opus)

使用方法

# 安装
npm install -g ccswitch

# 配置
ccswitch config set default-model claude-3-5-sonnet

# 使用
ccswitch "实现用户登录功能"

应用场景

  • 简单任务(如格式化代码)→ 自动切换到 Haiku(便宜)
  • 复杂任务(如架构设计)→ 自动切换到 Opus(强大)
  • 日常编码 → 默认 Sonnet(平衡)

9.2 cloudcli

简介:cloudcli 是 Claude Code 的云服务集成工具,支持将 Claude Code 部署到云端。

功能

  • 云端运行 Claude Code(无需本地安装)
  • 团队共享配置
  • 云端会话管理
  • API 接口(集成到其他工具)

使用方法

# 安装
npm install -g @cloudcli/cli

# 登录
cloudcli login

# 创建云端会话
cloudcli session create --project my-project

# 执行任务
cloudcli run "重构 UserService"

应用场景

  • 团队协作:共享 Claude Code 配置
  • CI/CD:在云端自动运行
  • 远程开发:无需本地资源

9.3 其他生态工具

9.3.1 claude-code-plugins

官方插件仓库https://github.com/anthropics/claude-code/tree/main/plugins

常用插件

  • plugin-git-enhanced:增强 Git 操作
  • plugin-docker:Docker 集成
  • plugin-testing:测试框架集成
  • plugin-docs:自动生成文档

使用方法

# 安装插件
claude plugin install git-enhanced

# 使用插件
claude --plugin git-enhanced "创建发布分支"

9.3.2 claude-code-monitor

功能:监控 Claude Code 的使用情况和成本

# 安装
npm install -g claude-code-monitor

# 启动监控
claude-code-monitor

# 查看统计
claude-code-monitor stats

输出示例

今日统计(2026-03-29):
- 任务数:15
- Token 消耗:125,432
- 成本:$3.21
- 最常用命令:/clear (12次)

9.3.3 MCP (Model Context Protocol) 集成

简介:Anthropic 推出的模型上下文协议,让 Claude Code 能访问外部工具和数据源

支持的工具

  • 数据库(PostgreSQL、MySQL)
  • API 服务
  • 文件系统
  • 云服务(AWS、GCP、Azure)

示例

# 配置 MCP 服务器
claude mcp add postgresql --connection-string "postgresql://..."

# 使用
claude "查询最近一周的用户数据"

十、最佳实践

10.1 任务描述技巧

好的描述

✅ 实现用户签到功能,要求:
1. 每天只能签到一次
2. 连续签到有额外积分奖励(7天+10分,30天+50分)
3. 提供 REST API:POST /api/checkin
4. 需要单元测试,覆盖率 > 80%
5. 使用现有的 User 模型

不好的描述

❌ 做个签到功能

差异

  • ✅ 明确需求、边界、技术细节
  • ❌ 太模糊,AI 会瞎猜

10.2 成本控制

技巧 1:使用 /clear

# 每完成一个任务就清除上下文
你: 实现功能 A
Claude: [完成]
你: /clear  ← 节省后续任务的 Token
你: 实现功能 B

技巧 2:使用 /compact

# 长会话时压缩历史
你: /compact
Claude: 对话历史已压缩(5000 tokens → 500 tokens)

技巧 3:设置预算上限

# 设置每日预算
claude config set max-daily-cost 10  # 美元

# 设置单次任务预算
claude config set max-task-cost 2  # 美元

10.3 安全建议

⚠️ 重要警告

  1. 不要在生产环境使用 --dangerously-skip-permissions
  2. 不要让 AI 访问敏感数据(密钥、密码、token)
  3. 定期检查 AI 生成的代码(可能有安全漏洞)
  4. 使用版本控制(Git),方便回滚

推荐流程

1. Claude Code 生成代码
2. 人工审查代码
3. 运行测试
4. 提交到 Git
5. 代码审查(Pull Request)
6. 合并到主分支

10.4 团队协作

共享 CLAUDE.md

# 团队共享项目规范
git add CLAUDE.md
git commit -m "添加 Claude Code 规范"
git push

统一配置

# 团队成员使用相同配置
claude config set default-model claude-3-5-sonnet
claude config set max-daily-cost 10

十一、常见问题

Q1: Claude Code 会取代程序员吗?

A: 不会。Claude Code 是工具,不是替代品。它擅长:

  • ✅ 重复性工作
  • ✅ 批量修改
  • ✅ 代码生成

但不擅长:

  • ❌ 架构设计
  • ❌ 业务理解
  • ❌ 创新思维

结论:它会让程序员更高效,但不会取代程序员。

Q2: 成本会不会很高?

A: 看使用方式。

  • 日常使用:$2-5/天(比 Copilot 便宜)
  • 复杂任务:$10-20/次(注意预算)
  • 省钱技巧:使用 /clear/compact、设置预算上限

Q3: Cursor 和 Claude 比,选哪个?

A: 工具定位不同:

工具 定位 价格
Cursor IDE + AI $20/月
Claude Code 终端 Agent 按量计费

Q4: 支持哪些编程语言?

A: 理论上支持所有语言,但擅长:

  • ✅ JavaScript/TypeScript
  • ✅ Python
  • ✅ Java
  • ✅ Go
  • ✅ Rust

对冷门语言支持较弱。

Q5: 数据安全吗?

A: Anthropic 的数据政策:

  • ✅ 对话数据加密存储
  • ✅ 不会用你的代码训练模型
  • ✅ 有限保留期(90天)
  • ✅ 符合 GDPR、SOC 2

但建议:

  • ❌ 不要让 AI 访问敏感数据
  • ✅ 使用本地模型(如 Ollama)处理敏感项目

十二、总结

12.1 Claude Code 的核心价值

  1. 真正的自动化:不是补全代码,而是完成整个任务
  2. 自我纠错:编译失败会自动修复
  3. 不绑定 IDE:任何编辑器都能用
  4. 项目规范:通过 CLAUDE.md 让 AI 遵循你的风格

12.2 适用人群

  • ✅ 专业开发者(提高效率)
  • ✅ 团队协作(共享规范)
  • ✅ CI/CD 自动化
  • ❌ 初学者(建议先用 Copilot 学习)

12.3 未来展望

Claude Code 代表了 AI 编程工具的新方向:从"辅助工具"到"真正的合作伙伴"。随着技术进步,我们可以期待:

  • 更强的理解能力:理解复杂业务逻辑
  • 更好的自主性:独立完成更复杂的任务
  • 更低的成本:模型优化降低使用成本
  • 更广的生态:更多插件和集成

附录:快速开始清单

安装(5分钟)

# 1. 安装
curl -fsSL https://claude.ai/install.sh | bash

# 2. 认证
claude

# 3. 设置预算
claude config set max-daily-cost 10

第一个任务(2分钟)

cd my-project
claude

你: 实现一个工具函数:格式化日期为 YYYY-MM-DD

Claude: [自动完成]

学习资源


结语

Claude Code 不是代码补全工具,而是一个真正帮你干活的工程师。它不会取代程序员,但会让程序员的工作效率提升 10 倍。

建议

先从简单任务开始,熟悉它的能力边界,再逐步应用到复杂场景。记住,工具再强,也需要人来驾驭。

Views: 137

工具全景——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: 51

代码都不用看了?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: 30

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: 20

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: 38