LEo的网络日志

警告优化建议

Fri, 22 May 2026 00:12:05 +0000

警告优化建议。

警告分级

核心功能的流量波动是 P0，非核心功能流量波动是 P1，单机故障或者磁盘上涨是 P2。P0 报警一般都有电话通知，P1 是短信通知，如果 P1 长时间不处理，会上升为 P0。

警告合并

把相同或相似的报警信息进行合并，以减少重复报警，我们可以在报警平台里面采取一些报警抑制，比如同一个服务在 1 分钟内，同时有可用性、延迟、CPU 等多个报警，就可以合并成一条；也可以采用 top-n 报警优化，只展示最严重的前 n 个报警，帮助团队集中注意力处理最关键的问题。

不断优化阈值

合理设置报警阈值，可以避免因小幅度波动而频繁触发报警。

优化警告规则

定期审查和优化报警规则，确保它们仍然符合当前的业务需求和系统状态。

有效的报警响应流程

我们应该建立有效的报警响应流程，确保团队能够及时、有效地处理报警。比如设置上升机制，Oncall 同学没有接手，上升到 leader，如果再没人接手就继续上升，一直上升到部门负责人。

etcd raft学习

Mon, 18 May 2026 00:12:05 +0000

raft通过leader选举和日志复制来保证一致性。选举靠随机超时和多数投票，保证一任一个leader，日志复制要求过半节点确认才提交，保证数据不丢。

leader选举

必须有一个所有节点都承认的leader，节点有3种状态，leader、follower和candidate，leader定期给所有follower发送心跳。如果讴歌follower在一段时间内没有收到心跳，就回把自己变成candidate，宣布竞选leader，然后向所有节点请求投票，每个节点只能投一票，当candidate拿到超过半数的票，就成功当选新的leader，然后继续给所有节点发送心跳。

每个任期内，只会有一个leader被选择出来，因为每个节点只能投票一次，并且先到先得，遵循多数原则。不会出现2个节点都获得多数票情况，避免出现多个leader的现象。新leader一定会拥有之前所有leader的日志，因为在选举leader时，拥有旧日志的节点没有资格当选。

日志复制

所有的写操作都是由leader处理，然后再复制给其他节点。当有写操作时，leader将将这个操作写入自己的日志，但是该日志没有提交，然后leader给所有节点发送这个写操作的日志，当过半节点确认已经写入这个日志以后，leader就将这个日志提交，然后告诉所有节点，之前的写操作日志可以提交了。然后leader才确认本次写事件成功，并反馈客户端。整个过程和选举leader类似，确保多数节点已经接收到本次写操作，才算真正完成。日志是批量，并行的发送到其他节点，减少网络延迟，提高写入效率。

读操作

相比较写操作，读操作为了确保读到最新的数据，leader会先广播一次心跳，确认自己是leader，然后直接读取相应数据，无需将读操作写成日志，保证一致性并提升读取效率。

claude code subagent学习

Sat, 16 May 2026 00:00:00 +0000

什么是 subagent？

subagent是主 agent 可以调用的独立 ai 实例。与 skill 不同，subagent 拥有独立的对话上下文、独立的工具访问权限，甚至可以运行在不同的隔离环境中。subagent 就像是主 agent 的”助手”或”专家顾问”，可以独立处理复杂任务并返回结果。

何时使用 subagent

适用场景

隔离上下文需求
- 需要独立对话历史
- 不想污染主对话的上下文
- 并行处理多个独立任务
工具隔离
- 需要不同的工具权限
- 需要在隔离环境中执行操作
复杂任务分解
- 主任务可以分解为多个独立的子任务
- 需要不同专业领域的专家协作
上下文窗口管理
- 主对话上下文接近窗口上限
- 需要保存子任务的完整历史

不适用场景

简单、快速的任务（直接用工具或 skill 更高效）
需要与主对话紧密协作的任务
对执行速度要求极高的场景

如何创建好的 subagent

1. 清晰的任务描述

subagent 需要一个明确且独立的任务描述。这个描述应该包含：

# 伪代码示例
agent_description = """
分析这个代码库中的性能瓶颈。具体任务：
1. 扫描所有 python 文件
2. 识别常见的性能反模式
3. 提供优化建议
4. 生成报告
"""

关键原则：

任务边界清晰
输入输出明确
避免需要与主 agent 频繁通信

2. 合适的 agent 类型选择

根据任务性质选择正确的 agent 类型：

# 探索代码库结构
Agent(
    subagent_type="Explore",
    prompt="找出所有 API 端点",
    description="探索 API 端点"
)

# 架构设计
Agent(
    subagent_type="Plan",
    prompt="设计一个新的认证系统",
    description="设计认证系统架构"
)

3. 预期结果处理

subagent 完成后，主 agent 需要正确处理结果：

# 获取结果并整合
result = Agent(
    prompt="分析 X 模块的依赖关系"
)
# 将结果简洁地报告给用户
# 不要直接堆砌子 agent 的完整输出

4. 并行执行

对于独立的任务，可以并行启动多个 subagent：

# 并行探索多个区域
Agent(
    prompt="分析前端代码",
    description="分析前端",
    run_in_background=True
)
Agent(
    prompt="分析后端代码",
    description="分析后端",
    run_in_background=True
)

subagent 的最佳实践

1. 避免过度使用

subagent 的调用有开销（启动时间、上下文传递）。只有当其带来的价值超过这个开销时才使用。

2. 保持任务独立性

subagent 应该能够独立完成任务，不应该频繁需要与主 agent 交互。

3. 提供足够的上下文

虽然 subagent 有独立上下文，但启动时应该提供足够的初始信息，避免它需要反复询问。

4. 使用适当的超时

为长时间运行的 subagent 设置合理的超时时间。

skill vs subagent 核心对比

架构层面的区别

特性	skill	subagent
执行模式	在主对话上下文中执行	独立上下文执行
工具访问	继承主 agent 的权限	可以有独立权限
状态持久性	短暂，执行完即结束	持续，有独立记忆
触发机制	基于用户输入自动触发	由主 agent 显式调用
并行能力	单一执行	可并行多个实例
上下文隔离	无	完全隔离

claude code skill学习

Sat, 16 May 2026 00:00:00 +0000

什么是 skill

claude code 中的 skill 是一种可复用、可调用的程序化任务处理器。当用户输入特定命令或满足触发条件时，skill 会被自动加载并执行预定义的任务。skill 就像是给 claude 配备的”专业技能包”，让它能够以一致、可靠的方式处理特定类型的工作，可以理解成是ai工具的sop。主要针对以下痛点：

高效的提示词封装，节约token，保证执行的一致性和高效性
通过skill，不污染对话上下文，确保ai能准确记住记忆和上下文
将领域知识固化，分享给团队

设计一个优秀 skill 的核心原则

1. 明确的触发条件

好的 skill 首先要有清晰的触发机制。触发条件应该既足够精确，避免误触发，又足够宽泛，覆盖目标场景。

# 示例：描述字段定义触发条件
description: |
  Use this skill when the user asks for code review, wants feedback on changes,
  or mentions reviewing a pull request.

最佳实践：

使用具体的动作动词（”review”, “refactor”, “test”）
包含同义词和变体
避免过于宽泛的描述（如”help with code”）

2. 专注单一职责

每个 skill 应该只解决一个明确的问题。当一个 skill 试图做太多事情时，它会变得复杂、难以维护，且触发准确性下降。

好的 skill	不好的 skill
`/pr-review` - 专注于 PR 代码审查	`/code-helper` - 试图处理所有代码相关任务
`/deps-check` - 检查依赖安全性	`/project-tools` - 包含多个不相关的工具集合

3. 提供明确的输出格式

用户需要知道 skill 的执行结果是什么样的。定义清晰的输出格式可以让结果更易于消费和后续处理。

## 输出格式

skill 应该按照以下结构返回结果：

### 发现的问题
- [ ] 问题1: 问题描述
- [ ] 问题2: 问题描述

### 建议
1. 建议1
2. 建议2

4. 可测试性

优秀的 skill 应该易于测试。这意味着：

输入输出明确
不依赖难以模拟的外部状态
可以提供测试用例

skill 的结构组成

frontmatter

---
name: my-skill
description: 简短描述 Skill 的用途
type: # 可以是自定义类型
---

描述字段

最重要的部分，决定了 skill 何时被触发：

# description 撰写指南

**以动作开头**：使用 "Use this skill when..." 或类似模式
**列举关键触发词**：列出会触发此 skill 的常见短语
**说明边界**：明确哪些情况不应该触发此 skill

执行逻辑

skill 的核心执行逻辑应该：

首先验证是否真正应该被触发
按照预定步骤执行任务
返回结构化结果
处理错误情况

常见的 skill 类型

1. 审查型 skill

用于审查和提供反馈：

代码审查（/pr-review）
安全审查（/security-review）
文档审查

2. 任务型 skill

用于执行特定任务：

初始化项目（/init）
配置管理（/update-config）
依赖分析

3. 分析型 skill

用于代码或项目分析：

复杂度分析
性能分析
测试覆盖率分析

4. 转换型 skill

用于转换或生成内容：

代码迁移
文档生成
格式转换

编写 skill 的最佳实践

1. 使用示例和模板

在 skill 中包含清晰的示例，帮助用户理解如何使用：

## 示例

### 用户输入
"review my recent changes"

### skill 行为
1. 检查 git diff
2. 分析代码质量
3. 提供改进建议

2. 错误处理

预见可能出现的错误并提供友好的处理：

### 错误场景

- 未找到文件：提示用户检查路径
- 权限不足：说明需要的权限级别
- 依赖缺失：提供安装指南

3. 保持简洁

skill 不应该有太多样板代码。只包含必要的逻辑，让主 model 处理自然语言理解。

4. 版本控制

对 skill 进行版本管理：

记录变更历史
使用语义化版本
提供升级指南

skill 的调试技巧

1. 验证触发条件

通过测试不同的用户输入来验证 skill 是否在正确的时候被触发。

2. 检查输出格式

确保输出格式符合预期，特别是当输出会被其他工具或流程消费时。

3. 性能分析

监控 skill 的执行时间，避免长时间运行的 skill 影响用户体验。

4. 日志记录

适当添加日志记录，帮助调试问题。

总结

编写优秀的 skill 需要：

清晰的触发机制 - 确保 skill 在正确的时候被调用
单一职责 - 每个 skill 专注解决一个问题
明确的输出 - 提供结构化、可预期的结果
良好的文档 - 包含示例、错误处理和使用说明

claude code 的 skill 机制，实质上是一套基于 prompt 的动态知识注入架构。它将开发者的经验、规范和流程，从一次次手动输入的“消耗品”，变为可复用、可共享、自动触发的“资产”，从根本上解决了 ai 编程助手的遗忘、不一致和难以协作三大核心痛点。

prometheus查询优化

Fri, 15 May 2026 00:12:05 +0000

recording rules

通过 recording rules 预计算常用查询或聚合表达式，可以将复杂的实时计算转移到后台提前完成，大幅减少查询时遍历的时间序列数量。这不仅能降低 prometheus 的查询负载，还能让 grafana 仪表盘响应更快。合理设置规则也能为后续的降采样和长期存储打下基础。

优化metric

设计指标时尽量避免使用动态或高基数的标签，比如用用户 id、url 路径全文等作为标签值，很容易造成时间序列数量失控。一方面会拖慢查询速度，另一方面会急剧增加内存与磁盘开销。可以把高基数信息转移到日志、trace 等系统，保持指标标签集合小而稳定。

relabeling机制

利用 prometheus 的 relabel 机制，在抓取阶段主动丢弃那些高基数且对查询没有帮助的标签。例如去掉临时 id 或不必要的实例信息，从源头控制时间序列的膨胀。这比事后清理更有效，也更节约资源。

采样和限流

只采集真正重要的指标数据，从采集端就做好过滤与限制。对历史数据可以采用更稀疏的采样粒度：比如超过 7 天的数据按每 10 分钟一个点聚合，超过 30 天的数据按每小时一个点聚合。在保留基本趋势的同时，大幅降低长期数据查询需要扫描的样本数。

缓存机制

分层利用不同存储介质来提升查询效率：最近 1 小时的热数据直接从内存返回，24 小时内的温数据由本地磁盘承担，更久远的历史数据则归档到对象存储。

数据压缩

通过合理调整 prometheus 的压缩策略，或利用其自带的块压缩机制，可以有效节省磁盘空间。当引入对象存储作为长期保留方案时，还可以叠加通用压缩算法进一步降低存储成本，但需要权衡压缩率对查询解压性能的影响，避免拖慢历史数据加载速度。

技术决策随笔

Thu, 14 May 2026 00:12:05 +0000

之前有人问起，如果现在重新设计过去做过的 GPU 调度系统，我会怎么做。当时的回答是：肯定不会从0开始再开发一个调度系统了，时间成本和维护成本都不划算。更好的做法是直接在社区里找一个能满足大致需求的方案，说不定连二次开发都不需要。于是就想随便写点东西，权当总结与思考吧。

功能

选择的技术框架是否满足核心需求，是否支持二次开发和未来扩展。以前选型往往只盯着当前的功能列表，后来才意识到，扩展性决定了系统能走多远。好的框架不会把你框死，而是在你需要自定义策略时，留有合理的切入点和插件机制。

性能

性能是否能支撑当下的规模，有什么性能瓶颈。除了吞吐和延迟这些直观指标，还要关注高负载下系统自身的资源消耗。如果框架本身比较重，可能业务还没到瓶颈，维护这套系统本身就变成了一个大问题。

成本

搭建这套系统的成本如何，学习曲线和开发时间都需要考虑，后期的维护成本同样不能忽略。引入一个新框架看似省事，但如果团队要花大量时间排查问题、阅读源码来填坑，隐性成本其实非常高。

社区和生态

社区活跃度如何，文档是否完善，生态的工具链是否齐全。遇到问题时，是否有足够多的参考案例和解答渠道，这直接影响到解决问题的效率。成熟的生态往往能大幅降低集成成本和踩坑概率。

团队能力

当前团队有多少人熟悉这个技术栈，多久能在团队里推广开，学习成本是否够低。技术决策不能脱离团队的实际状况，再好的工具如果没人会用、没人愿意维护，最后也只能闲置。

k8s network policy tips

Thu, 14 May 2026 00:12:05 +0000

Network Policy 是 Kubernetes 中实现网络隔离和安全控制的核心机制。本文通过大量实例，帮助你快速掌握 Network Policy 的使用。

什么是 Network Policy？

简单理解：Network Policy 就像是 Pod 之间的”防火墙规则”，控制哪些流量可以进入（Ingress）或离开（Egress）一个 Pod。

类比：

传统网络：防火墙规则（iptables）
云安全组：AWS Security Group、Azure NSG
Kubernetes：Network Policy

为什么需要 Network Policy？

默认情况（没有 Network Policy）

┌─────────┐      ┌─────────┐      ┌─────────┐
│ Frontend│─────▶│ Backend │─────▶│Database │
│  Pod    │      │  Pod    │      │  Pod    │
└─────────┘      └─────────┘      └─────────┘
     │                                   ▲
     │                                   │
     └───────────────────────────────────┘
              可以直接访问！（不安全）

问题：

❌ 任何 Pod 都可以访问数据库
❌ 没有网络隔离
❌ 安全风险高

有了 Network Policy

┌─────────┐      ┌─────────┐      ┌─────────┐
│ Frontend│─────▶│ Backend │─────▶│Database │
│  Pod    │  ✅  │  Pod    │  ✅  │  Pod    │
└─────────┘      └─────────┘      └─────────┘
     │                                   ▲
     │            ❌ 拒绝                │
     └───────────────────────────────────┘

优势：

✅ 最小权限原则
✅ 网络分段
✅ 合规要求（PCI-DSS、HIPAA 等）

核心概念

1. Ingress vs Egress

┌──────────────────────────────────────┐
│              Pod                     │
│                                      │
│  ┌────────────────────────────────┐ │
│  │                                │ │
│  │         Application            │ │
│  │                                │ │
│  └────────────────────────────────┘ │
│         ▲                  │         │
│         │ Ingress          │ Egress  │
│         │ (进入Pod)        │ (离开Pod)│
└─────────┼──────────────────┼─────────┘
          │                  │
     其他Pod访问         Pod访问外部

Ingress（入站）：其他 Pod/Service → 这个 Pod
Egress（出站）：这个 Pod → 其他 Pod/Service/外部

2. Label Selector

Network Policy 使用 Label 选择 Pod：

# Pod 定义
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: backend      # ← 这个 label
    tier: api
spec:
  containers:
  - name: app
    image: myapp

---
# Network Policy 通过 label 选择 Pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend    # ← 匹配上面的 label

3. 默认行为

重要：

如果一个 Pod 没有任何 Network Policy → 允许所有流量（默认开放）
如果一个 Pod 有至少一个 Network Policy → 拒绝所有流量，只允许策略中明确允许的

常见场景和配置

场景 1：拒绝所有流量（Default Deny）

需求：默认拒绝所有进入 Pod 的流量，作为安全基线。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}    # 空选择器 = 选择该 namespace 下的所有 Pod
  policyTypes:
  - Ingress
  # 注意：这里没有 ingress 规则，意味着拒绝所有

效果：

✅ production namespace 下所有 Pod 拒绝入站流量
⚠️ 需要配合其他策略显式允许需要的流量

同时拒绝出站：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  # 既拒绝入站，也拒绝出站

场景 2：允许特定 Pod 访问（最常用）

需求：只允许 Frontend Pod 访问 Backend Pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
  namespace: production
spec:
  # 1. 选择要保护的 Pod（Backend）
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
  - Ingress

  ingress:
  # 2. 允许来自 Frontend 的流量
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

可视化：

┌─────────────┐         ┌─────────────┐
│  Frontend   │   ✅    │   Backend   │
│ app:frontend│────────▶│ app:backend │
└─────────────┘         │   port:8080 │
                        └─────────────┘
                              ▲
┌─────────────┐               │
│   Other     │      ❌       │
│   Pods      │───────────────┘
└─────────────┘

场景 3：跨 Namespace 访问

需求：允许 monitoring namespace 的 Prometheus 访问 production namespace 的应用。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
  - Ingress

  ingress:
  - from:
    # 跨 namespace 访问需要 namespaceSelector
    - namespaceSelector:
        matchLabels:
          name: monitoring    # ← Namespace 需要有这个 label
      podSelector:
        matchLabels:
          app: prometheus
    ports:
    - protocol: TCP
      port: 9090    # metrics 端口

前置条件：给 namespace 打 label

kubectl label namespace monitoring name=monitoring

可视化：

┌──────────────────────────────────┐
│  monitoring namespace            │
│  (name=monitoring)               │
│                                  │
│  ┌─────────────┐                │
│  │ Prometheus  │                │
│  │app:prometheus                │
│  └──────┬──────┘                │
└─────────┼───────────────────────┘
          │ ✅ 允许访问 :9090
          ▼
┌──────────────────────────────────┐
│  production namespace            │
│                                  │
│  ┌─────────────┐                │
│  │  Backend    │                │
│  │ app:backend │                │
│  └─────────────┘                │
└──────────────────────────────────┘

场景 4：允许访问外部服务（Egress）

需求：允许 Pod 访问外部 API（如 api.example.com）和 DNS。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-external-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
  - Egress

  egress:
  # 1. 允许访问外部 API (通过 CIDR)
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0    # 所有外部 IP
        except:
        - 10.0.0.0/8       # 排除内网
        - 172.16.0.0/12
        - 192.168.0.0/16
    ports:
    - protocol: TCP
      port: 443    # HTTPS

  # 2. 允许访问 DNS (必须！)
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

重要：

⚠️ 如果配置了 Egress 策略，必须显式允许 DNS，否则域名解析会失败！
0.0.0.0/0 表示所有 IP，但可以用 except 排除内网

场景 5：同 Namespace 内部互通

需求：同一个 namespace 下的所有 Pod 可以互相访问。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  podSelector: {}    # 所有 Pod

  policyTypes:
  - Ingress

  ingress:
  - from:
    - podSelector: {}    # 来自同 namespace 的所有 Pod

场景 6：允许特定 IP 地址访问

需求：允许特定 IP 段（如办公网）访问应用。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-office-ip
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
  - Ingress

  ingress:
  - from:
    - ipBlock:
        cidr: 203.0.113.0/24    # 办公网 IP 段
    ports:
    - protocol: TCP
      port: 8080

使用场景：

限制管理界面只能从办公网访问
限制数据库只能从特定 IP 访问

场景 7：多条件组合（AND 逻辑）

需求：必须同时满足”来自 frontend Pod” 且 “在 production namespace”。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-strict-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
  - Ingress

  ingress:
  - from:
    # 注意：这是一个 from 项，包含两个 selector
    # 表示 AND 关系：必须同时满足
    - namespaceSelector:
        matchLabels:
          name: production
      podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

AND vs OR 的区别：

# AND：同一个 from 项中的多个 selector
ingress:
- from:
  - namespaceSelector: {...}    # 必须同时满足
    podSelector: {...}          # ← 注意没有 "-"

# OR：多个 from 项
ingress:
- from:
  - namespaceSelector: {...}    # 满足这个
  - podSelector: {...}          # 或满足这个 ← 注意有 "-"

场景 8：三层架构完整示例

架构：Frontend → Backend → Database

# 1. Database：只允许 Backend 访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database

  policyTypes:
  - Ingress

  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432    # PostgreSQL

---
# 2. Backend：允许 Frontend 访问，允许出站到 Database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
  - Ingress
  - Egress

  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

  egress:
  # 允许访问 Database
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

  # 允许 DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

---
# 3. Frontend：允许外部访问，允许出站到 Backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: frontend

  policyTypes:
  - Ingress
  - Egress

  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0    # 允许外部访问
    ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

  egress:
  # 允许访问 Backend
  - to:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 8080

  # 允许 DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

流量示意：

Internet
   │
   │ ✅ :80/:443
   ▼
┌─────────────┐
│  Frontend   │
│ app:frontend│
└──────┬──────┘
       │ ✅ :8080
       ▼
┌─────────────┐
│  Backend    │
│ app:backend │
└──────┬──────┘
       │ ✅ :5432
       ▼
┌─────────────┐
│  Database   │
│ app:database│
└─────────────┘

❌ Frontend 无法直接访问 Database
❌ 外部无法直接访问 Backend/Database

高级用法

1. 端口范围

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-port-range
spec:
  podSelector:
    matchLabels:
      app: myapp

  ingress:
  - from:
    - podSelector: {}
    ports:
    - protocol: TCP
      port: 8080
      endPort: 8090    # 允许 8080-8090 端口范围

2. 命名端口（Named Port）

# Pod 定义中使用命名端口
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: backend
spec:
  containers:
  - name: app
    ports:
    - name: http    # ← 命名端口
      containerPort: 8080

---
# Network Policy 引用命名端口
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend

  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: http    # ← 引用命名端口（推荐）

优势：

更改端口号时，不需要修改 Network Policy
更易读

3. 多个 Network Policy 叠加（OR 关系）

重要：多个 Network Policy 作用于同一个 Pod 时，是 OR 关系（取并集）。

# Policy 1：允许 Frontend 访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

---
# Policy 2：允许 Monitoring 访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: prometheus

效果：Backend 同时接受来自 Frontend 或 Prometheus 的流量。

实战技巧

1. 调试 Network Policy

问题：配置了 Network Policy 后，连接失败。

排查步骤：

# 1. 检查 Network Policy 是否生效
kubectl get networkpolicy -n production
kubectl describe networkpolicy backend-policy -n production

# 2. 检查 Pod 的 label 是否匹配
kubectl get pods -n production --show-labels

# 3. 检查 CNI 是否支持 Network Policy
# Calico、Cilium、Weave 支持
# Flannel 默认**不支持**（需要 Calico + Flannel）

# 4. 测试连通性
kubectl run test-pod --image=nicolaka/netshoot -it --rm -- /bin/bash
# 在 Pod 内
curl http://backend-service:8080    # 测试能否访问

# 5. 查看 iptables 规则（高级）
# 进入节点
iptables-save | grep <pod-ip>

常见错误：

错误	原因	解决方法
忘记允许 DNS	Egress 策略没有允许 DNS	显式允许 `kube-dns`
Label 不匹配	Pod label 和 Policy selector 不一致	检查 label
Namespace label 缺失	跨 namespace 访问时，namespace 没打 label	`kubectl label ns`
CNI 不支持	使用了不支持 Network Policy 的 CNI（如 Flannel）	更换 CNI 或添加 Calico

2. 渐进式实施策略

推荐流程：

第 1 步：审计模式（不阻断，只记录）
  ├─ 部署 Network Policy
  ├─ 观察日志，确认不会误伤
  └─ 调整策略

第 2 步：宽松策略
  ├─ 允许同 namespace 互通
  ├─ 允许必要的跨 namespace 访问
  └─ 测试验证

第 3 步：收紧策略
  ├─ 实施最小权限原则
  ├─ 只允许必要的流量
  └─ 持续监控

示例：先部署宽松策略，再逐步收紧

# 阶段 1：允许所有同 namespace 流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace-phase1
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

# 几天后，确认没问题
# 阶段 2：收紧为特定 Pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy-phase2
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend    # 只允许 frontend

3. 监控 Network Policy

推荐工具：

Cilium Hubble：可视化网络流量和策略
Calico Enterprise：Network Policy 审计
Open Policy Agent (OPA)：策略即代码，验证 Network Policy 合规性

手动检查：

# 列出所有 Network Policy
kubectl get netpol -A

# 检查哪些 Pod 受到保护
kubectl get pods -n production -o json | \
  jq '.items[] | select(.metadata.labels.app=="backend") | .metadata.name'

# 检查 Network Policy 覆盖率
# 找出没有 Network Policy 保护的 Pod
kubectl get pods -n production -o json | \
  jq -r '.items[] | select(.metadata.labels | length == 0) | .metadata.name'

最佳实践

✅ DO

Default Deny First ```yaml
先部署 default deny，再逐个允许

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes:
- Ingress
- Egress ```

为所有 Pod 打 Label

# 便于 Network Policy 选择
metadata:
  labels:
    app: backend
    tier: api
    version: v1

使用命名端口
- 更易维护，端口变更不需要改 Policy
允许 DNS ```yaml
Egress 策略中必须允许 DNS

egress:
- to:
  - namespaceSelector: matchLabels: name: kube-system ports:
  - protocol: UDP port: 53 ```

给 Namespace 打 Label

kubectl label namespace production name=production
kubectl label namespace monitoring name=monitoring

文档化策略

# 使用 annotations 说明策略用途
metadata:
  name: backend-policy
  annotations:
    description: "Only allow frontend pods to access backend"
    owner: "platform-team"
    reviewed: "2026-05-14"

❌ DON’T

不要忘记 DNS
- Egress 策略必须允许 DNS，否则域名解析失败
不要使用过宽的 CIDR ```yaml
❌ 不好：允许所有
- ipBlock: cidr: 0.0.0.0/0
✅ 好：明确 IP 范围
- ipBlock: cidr: 203.0.113.0/24 ```
不要只依赖 Network Policy
- 结合 RBAC、Pod Security、Service Mesh 等多层防御
不要忘记测试
- 部署前在测试环境验证
- 使用渐进式策略

完整示例：微服务应用

场景：电商应用，包含 Web、API、Database、Redis、Elasticsearch。

# Namespace 和 Label
apiVersion: v1
kind: Namespace
metadata:
  name: ecommerce
  labels:
    name: ecommerce

---
# 1. Default Deny All
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: ecommerce
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

---
# 2. Web Frontend Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-policy
  namespace: ecommerce
spec:
  podSelector:
    matchLabels:
      app: web

  policyTypes:
  - Ingress
  - Egress

  ingress:
  # 允许来自 Ingress Controller
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
    ports:
    - protocol: TCP
      port: 80

  egress:
  # 允许访问 API
  - to:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 8080

  # DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

---
# 3. API Backend Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
  namespace: ecommerce
spec:
  podSelector:
    matchLabels:
      app: api

  policyTypes:
  - Ingress
  - Egress

  ingress:
  # 允许来自 Web
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8080

  # 允许来自 Prometheus
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
      podSelector:
        matchLabels:
          app: prometheus
    ports:
    - protocol: TCP
      port: 9090

  egress:
  # 允许访问 Database
  - to:
    - podSelector:
        matchLabels:
          app: postgres
    ports:
    - protocol: TCP
      port: 5432

  # 允许访问 Redis
  - to:
    - podSelector:
        matchLabels:
          app: redis
    ports:
    - protocol: TCP
      port: 6379

  # 允许访问 Elasticsearch
  - to:
    - podSelector:
        matchLabels:
          app: elasticsearch
    ports:
    - protocol: TCP
      port: 9200

  # DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

  # 允许访问外部 API (支付网关等)
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16
    ports:
    - protocol: TCP
      port: 443

---
# 4. Database Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-policy
  namespace: ecommerce
spec:
  podSelector:
    matchLabels:
      app: postgres

  policyTypes:
  - Ingress

  ingress:
  # 只允许 API 访问
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 5432

---
# 5. Redis Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: redis-policy
  namespace: ecommerce
spec:
  podSelector:
    matchLabels:
      app: redis

  policyTypes:
  - Ingress

  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 6379

---
# 6. Elasticsearch Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: elasticsearch-policy
  namespace: ecommerce
spec:
  podSelector:
    matchLabels:
      app: elasticsearch

  policyTypes:
  - Ingress
  - Egress

  ingress:
  # 允许 API 访问
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 9200

  # 允许 Elasticsearch 集群内部通信
  - from:
    - podSelector:
        matchLabels:
          app: elasticsearch
    ports:
    - protocol: TCP
      port: 9300    # Transport port

  egress:
  # 允许集群内部通信
  - to:
    - podSelector:
        matchLabels:
          app: elasticsearch
    ports:
    - protocol: TCP
      port: 9300

  # DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

架构图：

Internet
   │
   ▼
[Ingress Controller]
   │
   │ ✅ :80
   ▼
┌──────┐
│ Web  │
└───┬──┘
    │ ✅ :8080
    ▼
┌──────┐     ✅ :5432      ┌──────────┐
│ API  │─────────────────▶│ Postgres │
└───┬──┘                   └──────────┘
    │
    ├──✅ :6379──────────▶┌───────┐
    │                     │ Redis │
    │                     └───────┘
    │
    └──✅ :9200──────────▶┌──────────────┐
                          │Elasticsearch │
                          └──────────────┘

✅ Prometheus (monitoring ns) → API :9090
✅ API → External Payment API :443
❌ Web 不能直接访问 Database
❌ 外部不能直接访问 API/Database

总结

关键要点

默认拒绝（Default Deny）：先部署 deny-all，再逐个允许
最小权限：只允许必要的流量
Label 驱动：合理使用 Label 和 Selector
不要忘记 DNS：Egress 策略必须允许 DNS
渐进式实施：先宽松，再收紧
测试验证：部署前充分测试

快速参考

# 模板：基础 Network Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: <policy-name>
  namespace: <namespace>
spec:
  # 1. 选择要保护的 Pod
  podSelector:
    matchLabels:
      app: <app-name>

  # 2. 指定策略类型
  policyTypes:
  - Ingress    # 控制入站
  - Egress     # 控制出站

  # 3. Ingress 规则
  ingress:
  - from:
    # 同 namespace 的特定 Pod
    - podSelector:
        matchLabels:
          app: <source-app>

    # 跨 namespace
    - namespaceSelector:
        matchLabels:
          name: <namespace-name>
      podSelector:
        matchLabels:
          app: <source-app>

    # 特定 IP
    - ipBlock:
        cidr: <ip-range>

    ports:
    - protocol: TCP
      port: <port-number>

  # 4. Egress 规则
  egress:
  # 允许访问特定服务
  - to:
    - podSelector:
        matchLabels:
          app: <target-app>
    ports:
    - protocol: TCP
      port: <port-number>

  # 必须：允许 DNS
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

智算平台随笔

Wed, 13 May 2026 00:12:05 +0000

最近有聊到智算平台，想着借此机会，结合自己知道的一点点，随便写写，不懂的地方就先略过，权当复习总结。

分层设计

应用层：训练作业、推理作业、智能体、其他作业等
平台层k8s：
- volcano+kueue: 作业调度+队列管理
- 多集群管理: karmada
- 训练作业管理：openfuyao
- 监控管理：prometheus+grafana+alertmanager+slack
- 日志管理：loki
- gitops: flux cd / argocd
基础设施层
- 计算：CPU、GPU、NPU等
- 网络
- 存储
  - 缓存：热数据，训练数据等
  - 磁盘：温数据，作业检查点，模型数据等
  - 对象存储：冷数据，归档数据、历史数据等

容量规划

节点数：考虑冗余节点
GPU卡数：单个作业最大需要多少卡
CPU核数
内存
存储
网络带宽
功耗和散热

存储

热数据层：实时训练数据，保留时间短，比如1周删除或者迁移到温数据层
温数据层：分布式文件系统如ceph，保存活跃的训练数据、作业检查点、日志、监控数据等，保留时间长一些比如3个月删除或者迁移到冷数据层
冷数据层：对象存储如minio，历史数据、模型归档、日志归档等，保留时间比如6个月后删除

作业检查点

通过使用增量检查点减少存储空间，第一次保存完整的检查点，户名值保存增量
最多保存3个检查点，通过异步方式保存，不影响当前作业
设置适合时间保存一次检查点
检查点恢复机制
检查点清理

调度系统volcano

配置抢占队列，供紧急作业运行
配置可被抢占队列，供一般作业运行
拓扑感知，优先同一个机架、同交换机、通一个节点调度，提升GPU之间通信效率
gang scheduling
独占式调度
共享式调度
队列支持优先级
弹性调度，最少需要多少卡，最多需要多少卡
bin packing减少资源碎片
fifo
自定义调度插件
- 缓存节点信息

监控系统

业务指标：成功作业数、失败作业数、队列排队时间、作业训练速度、作业运行时间
系统指标：GPU利用率、显存利用率、内存、CPU、存储、网络
硬件指标：GPU温度、功耗、网卡丢包、硬件错误等
dashboard展示
保存短期指标数据到内存和缓存，提升查询效率，如1小时数据从内存查询，24小时数据从硬盘查，历史数据从对象存储查
数据压缩和降采样节约存储空间，比如超过7天数据10分钟采样，超过30天数据1小时采样
自身监控
高可用：部署分布在不同节点或者不同区域

告警

GPU利用率低
GPU温度高
作业排队时间过长
失败作业数多
支持检查点作业没有检查点
GPU错误：自动重置？

aiops

alert触发脚本自动resolve issue
agent诊断
持续学习和改进
基于作业队列自动扩缩容

k8s多租户学习

Sun, 10 May 2026 00:12:05 +0000

namespace级别隔离

为每个租户创建独立namespace，并创建相应的resourcequota和limitrange限制资源使用。

权限隔离

通过rbac创建租户管理员角色和一般用户。

网络隔离

通过networkpolicy实现网络隔离，如默认拒绝跨ns的流量，但是允许访问dns服务。

节点隔离

给节点设置相应的污点，让租户允许部署需添加容忍。

vcluster

为每个租户创建vcluster，提供独立的control plane。

独立的cluster

每个用户创建独立的无力集群，实现硬隔离。

docker部署llm

Sat, 18 Apr 2026 00:12:05 +0000

docker image准备

docker pull swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/vllm/vllm-openai:latest
docker tag swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/vllm/vllm-openai:latest vllm-openai:latest

启动llm

docker run --rm -d --gpus all `
    --shm-size=30g `
    -p 8000:8000 `
    --ipc=host `
    -v D:/ai-learning/model/DeepSeek-R1-Distill-Qwen-1.5B:/models/DeepSeek-R1-Distill-Qwen-1.5B `
    vllm-openai:latest `
    --model /models/DeepSeek-R1-Distill-Qwen-1.5B `
    --gpu-memory-utilization 0.9 `
    --swap-space 20 `
    --max-model-len 8192 `
    --dtype half `
    --max-num-seqs 10

验证

$ curl http://192.168.0.122:8000/v1/chat/completions -H "Content-Type: application/json" -d "{\"model\":\"/models/DeepSeek-R1-DistillQwen-1.5B\",\"messages\":[{\"role\":\"user\",\"content\":\"你好，请介绍一下自己\"}],\"max_tokens\":100}"
{
  "id": "chat-d8e563fc13094ce195f9b661a376a33e",
  "object": "chat.completion",
  "created": 1776502168,
  "model": "/models/DeepSeek-R1-Distill-Qwen-1.5B",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "<think>\n\n</think>\n\n你好！我是DeepSeek-R1，一个由深度求索公司开发的智能助手，我会尽我所能为您提供帮助。请问有什么可以为您服务的？",
        "tool_calls": [

        ]
      },
      "logprobs": null,
      "finish_reason": "stop",
      "stop_reason": null
    }
  ],
  "usage": {
    "prompt_tokens": 7,
    "total_tokens": 45,
    "completion_tokens": 38
  },
  "prompt_logprobs": null
}

总结

gpu驱动版本需要更新，否则vllm不支持
参数需要调整，否则gpu oom
大模型通过国内镜像下载
vllm通过国内镜像下载