一个轻量级单二进制 Kubernetes 流量分析器，通过 AF_PACKET 捕获 Pod 间流量并映射为 Pod 身份，实现无需 eBPF 或服务网格的东西向流量可观测性。
# k8s-flow-lite
`k8s-flow-lite` 是一个运行于用户空间的流量分析器，它作为节点本地的 DaemonSet 运行，直接通过宿主机的 `AF_PACKET` socket 捕获流量，利用 Kubernetes API 将每一条流与其**源 pod 和目标 pod** 关联起来，并导出干净的逐流指标供 Prometheus 使用。它的诞生是为了应对那些你需要*立即获得东西向流量可观测性*，却又没有或不想使用服务网格、内核 eBPF pipeline 或厂商 agent 的时刻。
## 目录
- [问题陈述](#-problem-statement)
- [架构设计](#-architectural-design)
- [指标输出](#-metrics-output)
- [安装说明](#-installation)
- [用法与 CLI 标志](#-usage--cli-flags)
- [Kubernetes DaemonSet 部署](#-kubernetes-daemonset-deployment)
- [与 Project Calico 网络策略集成](#-integrating-with-project-calico-network-policies)
- [安全考量](#-security-considerations-cks-perspective)
- [我为何开发此项目及所学到的经验](#-why-i-built-this--what-i-learned)
- [路线图](#-roadmap)
- [许可证](#-license)
## 🎯 问题陈述
当 SRE 在凌晨 3 点收到告警，被告知“服务 A 无法连接到服务 B”时，问题几乎总是相同的：**这两个 pod 之间到底有没有流量在流动？如果没有，是谁丢弃了它？**
业界对这个问题默认的解决方案出奇地笨重：
| 方案 | 代价 |
| :--- | :--- |
| **服务网格 (Istio/Linkerd)** | 每个工作负载都需要一个 sidecar（或 ambient ztunnel），mTLS 证书轮换，需要 7x24 小时运行的控制平面，并且每个 pod 要消耗 50–150MB 内存。对于流量管理和零信任来说价值巨大——但如果你只需要知道“数据包到达了吗？”，这完全是杀鸡用牛刀。 |
| **eBPF 可观测性套件 (Hubble/Cilium, Pixie 等)** | 严重依赖内核版本、`BTF`/`CO-RE` 的可用性，并且需要一个特权 agent 将程序加载到内核中。出色的工具——但它们假设你能够在*每一个*节点上满足内核要求，包括那些你无法控制的古老托管型/边缘节点。 |
| **逐个 pod 执行 `kubectl exec` + `tcpdump`** | 手动、非持久化、无法与 pod 身份关联，并且要求容器内有一个 shell，而现在的容器越来越多地采用 `distroless` 且根本没有 shell。 |
| **完整的 APM agent** | 特定语言的插桩、许可费用，以及你需要自行维护的数据 pipeline。 |
`k8s-flow-lite` 正是为了填补所有这些方案之下的空白而生：
- **无需 eBPF，无需折腾内核。** 捕获使用可移植的 `AF_PACKET` 接口（通过 `gopacket`），几乎适用于现代集群运行的任何 Linux 内核。不需要 `BTF`，不需要 CO-RE，不需要审计 `bpf()` 系统调用。
- **无 sidecar，无网格控制平面。** 每个节点一个 DaemonSet pod。不会向你的工作负载中注入任何东西。移除它只需 `kubectl delete -f`。
- **Pod 身份，而不仅仅是 IP。** 原始的数据包工具只能给出 `10.0.3.14 → 10.0.7.9`。此工具通过 API server 将两端解析为 `namespace/pod` 和 `workload`，因此输出的语言正是你的值班团队实际思考时所用的语言。
- **极小、静态、可审计的爆炸半径。** 单个 Go 二进制文件，打包在 `scratch`/`distroless` 镜像中。你可以在一个下午阅读完整个捕获路径，并精确推断出它需要哪些能力（仅需 `CAP_NET_RAW` + `CAP_NET_ADMIN`，仅此而已）。
**核心理念：**对于*流级别的故障排除和 DevSecOps 审计*，你不需要将代码加载到内核中，也不需要用代理封装每个工作负载。你只需要看到流，将其归因于 pod，并导出数据。这就是该项目所做的全部——并且它力求做到尽善尽美。
## 🏗️ 架构设计
`k8s-flow-lite` 作为一个具有特权但范围严格的 DaemonSet 运行。每个实例只关注**其自身节点**上的流量，这使得设计在结构上保持水平可扩展——不存在会成为瓶颈的聚合层。
```
┌──────────────────────────────── Node ─────────────────────────────────┐
│ │
│ Host network namespace │
│ ┌──────────────┐ AF_PACKET (RX ring) ┌──────────────────────┐ │
│ │ eth0 / cali* │ ──────────────────────▶ │ Capture Engine │ │
│ │ (host + veth │ BPF prefilter │ (gopacket / pcap) │ │
│ │ endpoints) │ └──────────┬───────────┘ │
│ └──────────────┘ │ raw packets │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ Decode + Flow Assembler │ │
│ │ 5-tuple → flow key │ │
│ │ bounded LRU flow table │ │
│ └──────────┬───────────────┘ │
│ │ flow key (src/dst IP)│
│ ▼ │
│ ┌──────────────────────┐ watch Pods/Endpoints ┌──────────────────┐ │
│ │ Kubernetes API │ ◀────────────────────── │ IP → Pod Mapper │ │
│ │ (node-scoped watch) │ informer cache │ (local cache) │ │
│ └──────────────────────┘ └──────────┬───────┘ │
│ │ enriched │
│ ▼ │
│ ┌──────────────────────┐│
│ │ Metrics Exporter ││
│ │ /metrics (Prom) ││
│ │ + optional JSON log ││
│ └──────────┬───────────┘│
└──────────────────────────────────────────────────────────────┼──────────┘
▼
Prometheus / Grafana
Loki / SIEM (audit)
```
### 组件
1. **捕获引擎** — 在配置的接口上打开 `AF_PACKET` socket。一个内核级别的 **BPF 预过滤器**（传统的 cBPF，*不是* eBPF——与 `tcpdump` 使用的表达式语言相同）被下推，以便内核在流量进入用户空间之前就丢弃掉不感兴趣的流量。这是最重要的性能杠杆：你在环形缓冲区上进行过滤，而不是在 Go 中。
2. **流组装器** — 解析 L3/L4 头部，并将数据包折叠成一个标准的五元组流键 `(proto, src_ip, src_port, dst_ip, dst_port)`。流状态保存在一个**有界 LRU 表**中，该表对基数有硬性上限限制（`--max-flows`），因此扫描或 SYN 洪泛永远不会导致 agent OOM。空闲的流会被定时驱逐。
3. **IP → Pod 映射器** — 一个 Kubernetes **informer** 维护着一个节点范围、内存中的 `PodIP → {namespace, pod, workload, labels}` 索引。在本地缓存中进行 O(1) 复杂度的查找；agent 永远不会在热路径上请求 API server。监听尽可能过滤到本地节点，以保持缓存小并将 API 负载降至最低。
4. **指标导出器** — 丰富后的流被聚合到 Prometheus 计数器/仪表盘中，并通过 `/metrics` 提供服务。或者，每流记录可以作为结构化 JSON 输出到 stdout，以便发送到 Loki / SIEM，用于 **DevSecOps 审计跟踪**（谁在何时通过哪个端口与谁通信）。
### 设计原则
- **节点本地，无共享。** 没有领导者选举，没有跨节点协调，没有需要扩展或保护的中心化采集器。扩展集群就等于免费扩展了工具。
- **一切皆有界。** 每个缓冲区、队列和表都有明确的上限。可观测性工具绝对不能成为导致其正在观测的节点宕机的罪魁祸首。
- **故障开放，降级明显。** 如果 API 监听断开，捕获将继续运行，流将回退到原始 IP 标签；这种降级会作为指标呈现出来，永远不会是悄无声息的数据缺口。
## 📈 指标输出
所有指标均以 Prometheus 文本格式在 `:9099/metrics`（可配置）处公开。
| 指标 | 类型 | 标签 | 含义 |
| :--- | :--- | :--- | :--- |
| `flowlite_flows_total` | counter | `src_ns, src_pod, dst_ns, dst_pod, proto, dst_port, verdict` | 观测到的流，归因于 pod 身份 |
| `flowlite_bytes_total` | counter | `src_ns, src_pod, dst_ns, dst_pod, direction` | 每个流方向的字节数 |
| `flowlite_active_flows` | gauge | `node` | 流表中的当前条目数 |
| `flowlite_flow_table_evictions_total` | counter | `reason` | LRU / 空闲驱逐（容量压力信号） |
| `flowlite_unmapped_flows_total` | counter | `reason` | 无法解析为 pod 的流（缓存未命中 / 外部 IP） |
| `flowlite_capture_drops_total` | counter | `iface` | 被内核环形缓冲区丢弃的数据包（背压信号） |
| `flowlite_api_watch_state` | gauge | `resource` | 1 = 健康的 informer，0 = 断开连接 |
## 📦 安装说明
### 从源码构建
```
git clone https://github.com/panduraju50/k8s-flow-lite.git
cd k8s-flow-lite
make build # produces ./bin/k8s-flow-lite (static, CGO-free where possible)
```
### 容器镜像
```
make image IMG=ghcr.io/panduraju50/k8s-flow-lite:v0.1.0
make push IMG=ghcr.io/panduraju50/k8s-flow-lite:v0.1.0
```
## 🖥️ 用法与 CLI 标志
```
k8s-flow-lite [flags]
```
| 标志 | 默认值 | 描述 |
| :--- | :--- | :--- |
| `--interface`, `-i` | `any` | 捕获接口。`any` 会跨所有节点接口捕获；显式设置（例如 `cali+`）以限定在 Calico veths 范围内。 |
| `--bpf-filter` | `""` | 下推到内核环形缓冲区的传统 BPF 表达式（例如 `"tcp and not port 22"`）。你抵御性能开销的第一道防线。 |
| `--metrics-addr` | `:9099` | Prometheus `/metrics` endpoint 的监听地址。 |
| `--max-flows` | `65536` | LRU 流表的硬性上限。限制内存；超出限制会触发驱逐，并在指标中进行计数。 |
| `--flow-idle-timeout` | `120s` | 流在经历多长空闲时间后被驱逐并最终确定。 |
| `--sample-rate` | `1` | 1 = 捕获每一个数据包；`N` = 针对非常高吞吐量的节点实行的 1:N 抽样。 |
| `--snaplen` | `256` | 每个数据包捕获的字节数。默认仅限头部——我们永远不需要 payload 来进行流映射。 |
| `--enrich` | `true` | 启用 Kubernetes API pod 信息扩展。设置为 `false` 可作为纯粹的原始流导出器运行。 |
| `--node-name` | `$NODE_NAME` | 将 pod 监听限定到的节点范围（通常通过 downward API 注入）。 |
| `--json-log` | `false` | 向 stdout 输出每个流的结构化 JSON，以便 SIEM/审计摄取。 |
| `--log-level` | `info` | `debug`, `info`, `warn`, `error`。 |
| `--version` | — | 打印版本并退出。 |
### 示例
```
# 故障排查：监视发往特定服务端口的 TCP 流，仅捕获 header
k8s-flow-lite -i any --bpf-filter "tcp and port 8080" --snaplen 128
# 审计模式：向 SIEM 的 stdout 输出带有完整 pod 归属的 flow log，1:4 采样
k8s-flow-lite --json-log --sample-rate 4 --bpf-filter "not port 22"
# 仅将捕获范围限定于 Calico workload interfaces
k8s-flow-lite -i "cali+" --bpf-filter "tcp or udp"
```
## ☸️ Kubernetes DaemonSet 部署
该 agent 运行在 `hostNetwork` 上（以查看真实的节点流量），并具有**最小且显式的能力集**——没有一刀切的 `privileged: true`。
```
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: k8s-flow-lite
namespace: observability
labels:
app.kubernetes.io/name: k8s-flow-lite
spec:
selector:
matchLabels:
app.kubernetes.io/name: k8s-flow-lite
updateStrategy:
type: RollingUpdate
template:
metadata:
labels:
app.kubernetes.io/name: k8s-flow-lite
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9099"
spec:
serviceAccountName: k8s-flow-lite
hostNetwork: true # see the node's real traffic
dnsPolicy: ClusterFirstWithHostNet
priorityClassName: system-node-critical
tolerations:
- operator: Exists # observe every node, including tainted/control-plane
containers:
- name: k8s-flow-lite
image: ghcr.io/panduraju50/k8s-flow-lite:v0.1.0
args:
- "--interface=any"
- "--bpf-filter=tcp or udp"
- "--max-flows=131072"
- "--metrics-addr=:9099"
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
ports:
- name: metrics
containerPort: 9099
protocol: TCP
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: false # AF_PACKET needs the caps below
capabilities:
drop: ["ALL"]
add: ["NET_RAW", "NET_ADMIN"] # packet capture only — nothing else
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 300m
memory: 256Mi
livenessProbe:
httpGet:
path: /healthz
port: 9099
initialDelaySeconds: 5
periodSeconds: 15
terminationGracePeriodSeconds: 10
```
### RBAC (最小权限)
该 agent 只需要**读取** pod 和 endpoint——绝不进行写入：
```
apiVersion: v1
kind: ServiceAccount
metadata:
name: k8s-flow-lite
namespace: observability
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: k8s-flow-lite-reader
rules:
- apiGroups: [""]
resources: ["pods", "endpoints", "services"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: k8s-flow-lite-reader
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k8s-flow-lite-reader
subjects:
- kind: ServiceAccount
name: k8s-flow-lite
namespace: observability
```
### 使用 Terraform 部署
对于将集群插件作为代码进行管理的团队，现成的模块位于
[`deploy/terraform`](./deploy/terraform) 中。它提供了 DaemonSet、
只读 RBAC 以及 ServiceAccount，其最小权限姿态与
上面的清单完全相同——能力限制为 `NET_RAW`/`NET_ADMIN`，只读
根文件系统，以及仅限 `list/watch` 的集群访问权限。
```
cd deploy/terraform
cp example.tfvars terraform.tfvars # edit interface, BPF filter, resources
terraform init
terraform apply -var-file=terraform.tfvars
```
```
# 或者从您的平台 stack 中将其作为 module 消费：
module "k8s_flow_lite" {
source = "github.com/panduraju50/k8s-flow-lite//deploy/terraform"
namespace = "observability"
create_namespace = true
capture_interface = "cali+" # scope to Calico veths
bpf_filter = "tcp or udp"
json_log = true # ship per-flow JSON to the SIEM
}
```
请参阅该模块的 [README](./deploy/terraform/README.md) 获取完整的输入/输出
参考。这使 `k8s-flow-lite` 在 GitOps / Terragrunt
工作流中保持一等公民的地位，而不是一次性的 `kubectl apply`。
## 🛡️ 与 Project Calico 网络策略集成
这就是 `k8s-flow-lite` 为 DevSecOps 团队体现其价值的地方。Calico 在节点上执行 `GlobalNetworkPolicy` / `NetworkPolicy`，但是你*编写*的策略与*实际流动*的流量是两码事。`k8s-flow-lite` 为你提供了闭合这一回路的经验视角。
### 1. 基于观察到的现实而非臆测来制定策略
在集群范围内以 `--json-log` 模式运行 agent 一个基线窗口期。由于每个流都归因于 `src` 和 `dst` pod 的身份，你可以推导出**确切正在使用哪些 pod 到 pod 的路径**，并基于这一基本事实生成最小权限的 Calico 策略——而不是发布一个过于宽泛的 `allow` 并祈祷不出问题。
```
# 提取 'payments' namespace 在一个时间窗口内的真实依赖图
kubectl logs -n observability -l app.kubernetes.io/name=k8s-flow-lite \
| jq -r 'select(.dst_ns=="payments") | "\(.src_ns)/\(.src_workload) -> \(.dst_workload):\(.dst_port)"' \
| sort -u
```
那个去重后的列表就是你的白名单。将其转换为策略：
```
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: payments-api-allow
namespace: payments
spec:
selector: app == 'payments-api'
types: [Ingress]
ingress:
- action: Allow
protocol: TCP
source:
selector: app == 'checkout' # observed by k8s-flow-lite as a real caller
destination:
ports: [8080]
```
### 2. 验证执行——捕捉 Calico 正在（或没有）进行的丢弃
在应用了 `default-deny` 姿态后，关键的运维问题是：“*我是不是刚刚把什么东西搞坏了？*”因为 agent 独立于 CNI 的决定在网络上查看流量，所以出现在捕获中但从未完成握手的流是**策略丢弃**的强烈信号。
将其与 Calico 自身的拒绝数据包可见性配对进行交叉检查：
```
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: default-deny-with-logging
spec:
selector: all()
types: [Ingress, Egress]
ingress:
- action: Log # Calico logs denied packets
- action: Deny
egress:
- action: Log
- action: Deny
```
现在你有了两个独立的见证者：**Calico 的 `Log` action** 告诉你策略引擎*决定丢弃*什么，而**`k8s-flow-lite` 的 `flowlite_flows_total` 与已完成流差值对比**告诉你*应用程序正试图做什么*。它们之间的差距就是你配置策略——在几分钟内就能显现出来，而不是在客户升级投诉之后。
### 3. 持续审计 / 漂移检测
## 🔒 安全考量 (CKS 视角)
此工具会捕获流量，因此它掌握着真正的权力，必须谨慎对待：
- **能力，而非 `privileged`。** 它仅请求 `CAP_NET_RAW` 和 `CAP_NET_ADMIN`。它显式地首先 `drop: ["ALL"]`，且绝不请求 `SYS_ADMIN`、主机路径或 Docker socket。使用 `capsh`/Falco 对其进行审计，你不会发现任何多余的东西。
- **头部，而非 payload。** 默认的 `--snaplen 256` 仅捕获 L3/L4 头部。它是一个*流*分析器，而不是窃听器——它不需要、不请求，也不存储应用 payload 或 TLS 明文。保持这种方式以避开数据隐私范围 (PCI-DSS/FISC)。
- **只读 RBAC。** ServiceAccount 可以 `list/watch` pod；它不能改变集群状态。攻破该 agent 只能获得可见性，而不是控制权。
- **在 `securityContext` 中设置只读根文件系统 + 禁止权限提升**，因此容器表面在 runtime 时是不可变的。
- **最小暴露指标。** `/metrics` endpoint 携带拓扑元数据（namespace、工作负载名称）。使用 Calico 策略将其范围限制在你的监控 namespace 中——不要全集群暴露。
## 💡 我为何开发此项目及所学到的经验
### 痛点
我经历过太多值班轮换，死盯着我*相当确信*是正确的 `NetworkPolicy`，却无法回答最简单的问题——*数据包到底到达了吗？*——除非要么 `exec` 进入一个没有 shell 的 distroless 容器，要么建立起一个我根本不想去运维的服务网格。我接触过的每一个工具，要么沉重到难以证明其合理性，要么做出了我无法在跨区域舰队的每个节点上保证的假设（内核版本、sidecar 注入、控制平面）。`k8s-flow-lite` 就是我希望在凌晨 3 点拥有的工具。
### 权衡 1 — 优于 eBPF 的 `AF_PACKET`（可移植性胜过原始效率）
对于内核级别的可观测性，eBPF 是“正确”的现代答案，我想明确指出，*当你能保证底层基础时*，它是一项卓越的技术。我刻意选择了较旧的 `AF_PACKET` 路径，并且我是睁大眼睛做出这个选择的：
- **原因：** 在真实的舰队中，你会接手你无法控制的节点——运行在较旧内核上的托管节点组、边缘节点、没有 `BTF` 的设备镜像。`AF_PACKET` 几乎可以在任何运行 Linux 的地方工作。eBPF CO-RE 做不到。对于 SRE 工具而言，“无条件地在舰队中的每个节点上运行”胜过“在碰巧能加载它的节点上效率提高 20%”。
- **我接受的代价：** 将数据包复制到用户空间比在内核中使用 eBPF 过滤开销更大。**教训是，cBPF 预过滤器就是一切。** 我的第一个天真版本捕获了所有内容并在 Go 中进行过滤——在负载下 CPU 占用非常尴尬。将传统的 BPF 表达式下推到环形缓冲区，让内核*在复制之前*丢弃不感兴趣的帧，将 CPU 开销降低了一个数量级。内核永远比我的 Go 代码快；我们要做的就是尽早给它过滤器。
### 权衡 2 — 对抗性流量下的内存管理
一个导致其正在监视的节点 OOM 的可观测性 agent 比根本没有 agent 还要糟糕——它将*可见性*事故变成了*可用性*事故。这促成了最艰难的两个教训：
- **永远限制流表。** 流表是明显的无限增长隐患：端口扫描或 SYN 洪泛会产生近乎无限的大量唯一五元组。我将其限制为固定大小的 **LRU 并带有空闲驱逐**（`--max-flows`），并且——至关重要的是——将驱逐率作为指标导出。现在容量压力是一个*你可以报警的 SLI*，而不是凌晨 4 点的悄无声息的 OOM。
- **通过池化对抗分配器压力。** 在 Go 中，高频捕获循环是 GC 的雷区——在线速下每个数据包产生一个新的解码结构会产生令人无法忍受的垃圾。通过 `sync.Pool` 重用解码缓冲区，并解码到预分配的层结构中（`gopacket` `DecodingLayerParser` 模式），抹平了 GC 锯齿。**结论：在高数据包速率下，瓶颈不是你的逻辑，而是你的逻辑产生的垃圾。** 稳态内存必须是*平坦的*，因为 DaemonSet 中的缓慢泄漏意味着在*每个节点上同时*发生泄漏——具有单一根本原因的舰队范围故障。
### 权衡 3 — 并发：一个 pipeline，而不是 mutex 的混战
捕获路径是一个经典的生产者/消费者问题，而我的第一直觉——mutex 后面的一个大型共享 map——是错误的。
- **结构：** 捕获 goroutine → 缓冲 channel → 解码/丰富 worker → 聚合。各个阶段之间的**有界 channel**是背压机制：如果信息丰富化跟不上，缓冲区就会被填满，而我做出了明确的、*可观察*的选择，即丢弃并计数，而不是阻塞捕获 goroutine（这无论如何都会导致内核环形缓冲区丢弃）。**丢弃你可以衡量的数据是可以接受的；阻塞 pipeline 并丢弃你无法衡量的数据则是不行的。**
- **API 缓存是解锁关键。** Pod 信息丰富化不能在热路径上触碰 API server——在线速下你会对自己的控制平面发起 DoS 攻击。client-go **informer** 维护着一个本地、最终一致的 `PodIP → 身份` 索引，因此信息丰富化是一个轻量级锁的本地 map 查找。这反映了*每一个*行为良好的 controller 的工作方式，而将“监听并缓存，绝不热路径轮询”的模式内化，是从该项目中获得的最具可转移性的经验之一。
- **正确性：** 在 CI 中启用 `-race`，并确立一条严格的规则：捕获 goroutine 不拥有任何共享的可变状态——它只负责*发送*。锁越少，凌晨 3 点出现的死锁之谜就越少。
### 这如何映射到 7x24 小时 HA SRE
上面的一切实际上是维持跨区域平台正常运转的同一种直觉：
- **有限的资源 = 可预测的爆炸半径。** DaemonSet 会触及每个节点；一个内存 bug 会立刻发布到你整个舰队。每个缓冲区上的硬上限，与在生产服务上设置资源限制和熔断器是同样的纪律。
- **观测观测者。** 捕获丢弃、流表驱逐和 API 监听健康度是一等指标，*因为静默失败的可观测性工具是一种累赘。* SRE 工具必须对自身的降级保持诚实——这就像我们要对插桩工具进行插桩一样。
- **故障开放，降级明显。** 如果 API 监听断开，捕获将继续运行，并且流将回退到原始 IP 标签，同时降级会作为指标导出。在事件发生期间，部分数据总比没有数据好——优雅降级是全部的工作。
- **构造上的最小权限。** `CAP_NET_RAW`/`CAP_NET_ADMIN` 和只读 RBAC，仅此而已。在符合 PCI-DSS / FISC 的平台上，“为什么这个 pod 拥有那个能力？”是你必须能够用一句话回答的问题——在这里你可以。
**接下来我会做什么：** 一个在 runtime 时选择的可选 eBPF 捕获后端（结合两者的优点——在内核支持的地方使用 CO-RE，在其他所有地方回退到 `AF_PACKET`），以及 conntrack 集成，以明确区分*策略*丢弃和普通的连接拆除。
## 🗺️ 路线图
- [ ] 带有自动 `AF_PACKET` 回退机制的可选 eBPF 捕获后端
- [ ] Conntrack 关联，以明确识别 Calico/`iptables` 策略丢弃
- [ ] Grafana dashboard + 预构建的 Prometheus 告警规则
- [ ] OpenTelemetry 流日志导出器
- [ ] 包含 BPF 过滤器、采样和能力配置值的 Helm chart
- [ ] IPv6 流支持
## 📄 许可证
Apache License 2.0 — 见 [`LICENSE`](./LICENSE)。
## 👤 作者
**Panduranga Rajau M (Pandu)** — 高级站点可靠性工程师 · CKS / CKA / CKAD · 日本东京
使用 Go & Rust 构建代码优先的基础设施工具，用于零信任、高可用的 Kubernetes 平台。
[GitHub · @panduraju50](https://github.com/panduraju50) · [LinkedIn · pandurangaraju](https://www.linkedin.com/in/pandurangaraju/)