eBPF & Isovalent: Infrastructure Evolution Briefing

💡 一分钟了解核心价值

💡 Core Value in 1 Minute

本方案带来的商业价值概括如下：

The business value is summarized as:

💰 降低硬件成本 Reduce TCO

通过移除过时的网络组件，CPU 利用率降低 30%-40%，用更少的服务器跑更多的业务。

Remove legacy components, drop CPU usage by 30%-40%. Run more apps on fewer servers.

🛡️ 业务连续性 Business Continuity

无需重启系统即可修补漏洞（虚拟补丁）。生产线不停机，业务不中断。

Patch without rebooting (Virtual Patching). Zero downtime for production lines.

👁️ 故障定责清晰 Clear Accountability

不再在"网络问题"还是"应用问题"之间推诿。可视化大屏一眼看清故障点，大幅缩短修复时间。

No more finger-pointing between "Network" vs "App". Visualize faults instantly.

1. 核心战略价值与责任交付

1. Core Strategic Value & Delivery

我们不仅仅是引入一项新技术，而是为您现有的基础设施注入以下五大战略优势：

We are injecting five strategic advantages into your existing infrastructure:

✅ 保障业务高可用性与稳定性 (High Availability) Ensure High Availability & Stability

免重启安全加固：利用 Tetragon 的动态策略，可即时防御漏洞，无需等待停机维护窗口，最大化业务在线时间。

No-Reboot Hardening: Use Tetragon dynamic policies to mitigate vulnerabilities instantly without maintenance windows, maximizing uptime.

✅ 提升基础设施安全水位 (Security Posture) Elevate Security Posture

内核级同步阻断：区别于传统日志告警，Tetragon 在攻击造成实际损害前（如文件读写）就进行拦截，从根本上防范数据泄露、系统篡改和容器逃逸。

Kernel-Level Blocking: Unlike traditional logging, Tetragon blocks attacks before damage occurs (e.g., file access), preventing leakage.

✅ 确保业务应用性能 (Application Performance) Ensure Application Performance

极致性能： Cilium 移除 kube-proxy 提供接近物理机的网络性能；Tetragon 的安全监控开销小于 1%，保障核心业务应用不受影响。

Ultimate Performance: Cilium removes kube-proxy for near-metal speed; Tetragon overhead is < 1%.

✅ 提升运维与故障排查效率 (Ops Efficiency) Boost Ops Efficiency

全局可视化： Hubble 提供实时的服务依赖和流量拓扑，将复杂的云原生网络环境“透明化”，帮助团队快速定位问题根源（是网络？DNS？还是应用？）。

Global Visibility: Hubble provides real-time topology, making complex networks "transparent" to quickly pinpoint root causes.

✅ 缩短安全事件响应时间 (Reduce MTTR) Reduce Security MTTR

自动化安全闭环：结合 Splunk 与 AI，实现从检测、分析到响应的分钟级自动化，大幅提升安全团队的响应效率。

Automated Loop: Combine with Splunk & AI to automate detection-to-response in minutes.

2. eBPF：Linux 内核的数字化转型

2. eBPF: Digital Transformation of the Linux Kernel

为什么现在谈 eBPF？ 过去，Linux 内核像是一个功能固定的硬件；现在，eBPF 把它变成了软件定义的平台。Google, Meta, Netflix 都在用它重构基础设施。

Why eBPF Now? In the past, the Linux Kernel was like fixed hardware; now, eBPF turns it into a software-defined platform. Google, Meta, Netflix are all rebuilding infrastructure with it.

eBPF（extended Berkeley Packet Filter）起源于1992年的BPF（Berkeley Packet Filter），最初只是一个简单的数据包过滤工具，用于网络分析工具如tcpdump。它允许用户在内核中运行小型程序来过滤网络流量，而无需将所有数据复制到用户空间，从而提高效率。2014年，eBPF扩展了BPF的能力，从单纯的网络过滤扩展到通用内核编程。它引入了JIT（Just-In-Time）编译、Verifier（验证器）和Maps（数据结构），允许安全地在内核中运行自定义代码，而不修改内核源码。

根据Linux Foundation的《eBPF状态报告》（2025版），eBPF已被超过80%的云原生企业采用，在制造业中，它帮助优化VMware虚拟机和SUSE容器平台的资源交付。

传统IT环境（如Linux/Windows VM）面临老旧内核、安全补丁重启问题；eBPF提供无中断升级，完美契合生产线连续性需求。

eBPF (extended Berkeley Packet Filter) originated from the 1992 BPF (Berkeley Packet Filter), initially just a simple packet filtering tool for network analysis tools like tcpdump. It allowed users to run small programs in the kernel to filter network traffic without copying all data to user space, improving efficiency. In 2014, eBPF extended BPF's capabilities from pure network filtering to general kernel programming. It introduced JIT (Just-In-Time) compilation, Verifier, and Maps (data structures), allowing custom code to run safely in the kernel without modifying the source code.

According to the Linux Foundation's "State of eBPF Report" (2025 Edition), eBPF has been adopted by over 80% of cloud-native enterprises. In manufacturing, it helps optimize resource delivery for VMware VMs and SUSE container platforms.

Traditional IT environments (like Linux/Windows VMs) face issues with legacy kernels and security patch reboots; eBPF provides non-disruptive upgrades, perfectly fitting production line continuity requirements.

传统架构 vs eBPF 架构

Traditional vs eBPF Architecture

核心差异： 传统方式依赖 iptables 逐条匹配规则，就像要在几千页的纸质名册里一个个找人，随着规则增加，速度越来越慢。eBPF 使用 Hash Map 进行数据查找，就像使用电子搜索引擎，无论数据有多少，查找速度永远是瞬间完成。

Core Difference: Traditional methods check rules one by one, like searching a paper phonebook. eBPF uses Hash Maps, like a digital search engine—lookup speed is instant regardless of scale.

通俗理解：什么是 eBPF？

Concept: What is eBPF?

无需停车的引擎升级

Engine Upgrade while Driving

传统的内核修改像是在做复杂的开胸手术，风险极高且需要停机。eBPF 就像给正在高速公路上行驶的汽车升级引擎，安全、即时、无感。

Traditional kernel changes are like risky open-heart surgery requiring downtime. eBPF is like upgrading a car's engine while driving on the highway—safe, instant, and seamless.

系统的 X 光机

X-Ray for the System

eBPF 可以在系统关键节点安插“智能探头”。它能看到每一个数据包、每一个文件读写，让黑客行为无处遁形，且不影响系统运行。

eBPF places "smart probes" at key system points. It sees every packet and file access, leaving no place for hackers to hide, without slowing down the system.

安全的沙箱运行

Safe Sandbox Execution

eBPF 代码在内核中运行前必须通过严格的“安检”（Verifier）。任何可能导致死循环或系统崩溃的代码都会被拒绝执行。

eBPF code must pass a strict "security check" (Verifier) before running. Any code that could crash the system or loop forever is rejected instantly.

深度解析：eBPF 运行流程

Deep Dive: How eBPF Works

为什么它既强大又安全？因为每一段代码在运行前都要经过严格的“安检”。

Why is it both powerful and safe? Because every piece of code undergoes a strict "security check" before running.

1

编写程序

Write Program

开发者使用 C 或 Rust 编写 eBPF 程序，定义需要监控的系统事件。

Developers write eBPF programs in C or Rust, defining which system events to monitor.

➜

2

验证器 (Verifier)

The Verifier

最关键的一步。内核检查代码是否安全：没有死循环、不访问非法内存。

Critical Step. The kernel checks if code is safe: no infinite loops, no illegal memory access.

➜

3

JIT 编译

JIT Compile

即时编译器将字节码转换为机器码，确保运行速度接近原生内核代码。

JIT converts bytecode to machine code, ensuring execution speed matches native kernel code.

➜

4

挂载与执行

Attach & Run

程序挂载到 Hook 点（如网卡、系统调用）。事件触发时，代码毫秒级响应。

Program attaches to Hooks (NIC, Syscalls). When events occur, code executes in milliseconds.

为什么这很重要？三大应用支柱

Why it matters? The Three Pillars

下一代安全

Next-Gen Security

场景： 容器逃逸检测、DDoS 防御。
在攻击造成破坏之前，在内核层直接拦截。这比传统的杀毒软件更快、更隐蔽。

Use Case: Container escape detection, DDoS mitigation.
Intercept attacks at kernel level. Faster and stealthier than traditional antivirus.

深度可观测性

Deep Observability

场景： 绘制服务依赖图、分析 MySQL 慢查询。
无需修改应用代码，eBPF 就能告诉你任何进程消耗了多少资源。

Use Case: Service dependency mapping, MySQL slow query analysis.
No code changes needed to see exactly what resources any process is consuming.

云原生网络

Cloud Native Networking

场景： Kubernetes Service Load Balancing。
绕过复杂的 iptables 规则，以极高的效率处理云环境中的海量微服务流量。

Use Case: Kubernetes Service Load Balancing.
Bypasses complex iptables, handling massive microservice traffic with extreme efficiency.

3. Isovalent 工具集详解：架构升级

3. Isovalent Toolkit Deep Dive: Architecture Upgrade

3.1 Cilium 下一代网络高速公路 3.1 Cilium: Next-Gen Networking Highway

📉 背景：没有 Cilium 的世界 (Before)

📉 Context: The World Before Cilium

通俗理解： 想象一个繁忙的邮局（Linux 内核），它的工作是分发信件（数据包）。在传统的 Kubernetes 网络中（使用 iptables），每当你要增加一个新的服务地址，就相当于给邮局的工作人员发了一本厚厚的新操作手册。每来一封信，工作人员都必须从第一页翻到最后一页去比对规则，才能决定信往哪里送。

Layman's Terms: Imagine a busy post office (Linux Kernel) whose job is to distribute letters (packets). In traditional Kubernetes networking (using iptables), every time you add a new service, it's like handing the postal workers a massive new rulebook. For every single letter that arrives, the worker has to read the rulebook from page 1 to the end to decide where to deliver it.

痛点 1 (慢)： 当规则有几万条时，翻书（规则匹配）的速度会变得极慢。
痛点 2 (乱)： 工作人员只认识信封上的地址（IP），根本不知道这封信是谁寄的（哪个 Pod），也不知道里面装的是什么（HTTP 请求内容）。

Pain Point 1 (Slow): When there are thousands of rules, reading the book (rule matching) becomes incredibly slow.
Pain Point 2 (Blind): The worker only sees the address on the envelope (IP). They have no idea who sent it (which Pod) or what's inside (HTTP content).

🚀 解决方案：Cilium 是什么？(What)

🚀 The Solution: What is Cilium?

费曼式定义： Cilium 就像是给这个老旧的邮局（Linux 内核）装上了一个拥有人工智能的自动分拣系统。

Feynman Definition: Cilium is like installing an AI-powered automated sorting system into that old post office.

它不再翻那本厚厚的规则书，而是直接在信件进入邮局大门的那一刻（网卡处），瞬间用扫描仪识别出这封信要去哪，并且通过一条专用高速传送带（eBPF）直接送到目的地。

Instead of reading the massive rulebook, it instantly scans the letter the moment it enters the door (Network Interface), and shoots it down a dedicated high-speed chute (eBPF) directly to the recipient.

⚡ 深度解析：原理与性能 (How & Why)

⚡ Deep Dive: How & Why

How: 它是如何工作的？
想象一个“大脑”和一个“执行者”的配合：

How: How does it work?
Think of it as a "Brain" and an "Executor":

大脑 (Cilium Agent): 住在用户空间（User Space）。它负责听 Kubernetes 的指挥（比如“这个 Pod 可以访问那个 Pod”），然后把这些指令翻译成“字节码”。
执行者 (eBPF Programs): 住在内核空间（Kernel Space）。大脑把翻译好的字节码注入到内核里。这些微小的程序挂载在关键位置（如网卡入口）。一旦数据包到达，它们立刻执行逻辑，甚至不需要叫醒操作系统的主进程。

The Brain (Cilium Agent): Lives in User Space. It listens to Kubernetes instructions and translates them into "bytecode".
The Executor (eBPF Programs): Lives in Kernel Space. The Brain injects this bytecode into the kernel. These tiny programs sit at key checkpoints. When a packet arrives, they act instantly.

Why: 为什么性能大幅提升？三个“作弊码”：

Why: Why the massive performance boost? Three "cheat codes":

算法降维打击 (O(N) vs O(1)): 传统 iptables 是链表，规则越多越慢（线性增长）。Cilium 使用 eBPF Hash Map（哈希表），就像字典索引一样。无论你有 10 条规则还是 10,000 条规则，查找速度都是一样快的。
拒绝中间商 (Bypass TCP/IP): 如果两个 Pod 在同一台机器上，Cilium 可以直接把数据从一个 Socket 搬到另一个 Socket，完全跳过厚重的 TCP/IP 协议栈处理。
减少来回跑腿 (No Context Switching): 处理逻辑直接在内核完成，不需要把数据包在“内核态”和“用户态”之间来回拷贝，省去了巨大的系统开销。

Algorithm Superiority (O(N) vs O(1)): Traditional iptables is a list; more rules = slower. Cilium uses eBPF Hash Maps, like a dictionary index. Looking up a rule takes the same amount of time regardless of scale.
Cut out the Middleman (Bypass TCP/IP): If two Pods are on the same machine, Cilium can move data directly from one Socket to another, bypassing the heavy TCP/IP stack.
Stop Running Back and Forth (No Context Switching): Processing happens in the kernel. No need to copy data back and forth between "Kernel Space" and "User Space".

💎 价值：有了之后有什么不同？(Value)

💎 Value: What changes with Cilium?

维度 Dimension	以前 (Before) Before	现在 (With Cilium) With Cilium
连接性能 Connectivity	依赖 iptables，扩容难，延迟高 Relied on iptables luck, hard to scale	极致性能 eBPF 高速公路，延迟极低 High Performance eBPF Fast Path
可见性 Visibility	两眼一抹黑，只能看到 IP:Port Blind spots (IP:Port only)	L7 可观测能看到 HTTP 路径和 API 调用 L7 Observability See API calls
安全性 Security	基于 IP (脆弱，IP 经常变) IP-based firewalls (Fragile)	身份感知基于 Identity 的零信任 Identity Aware Zero Trust

3.2 Tetragon 内置的安全卫士 3.2 Tetragon: Built-in Security Guard

🏢 业务视角：从“摄像头”到“免疫系统”

🏢 Business Perspective: From CCTV to Immune System

传统安全：摄像头

Traditional: CCTV Camera

以前的安全工具（如日志分析）就像是摄像头。它能录下小偷行窃的过程，但当你发现录像时，小偷早就跑了，财产也损失了。这是“异步检测”。

Legacy tools are like CCTV cameras. They record the crime, but alerts arrive after damage is done. This is "Asynchronous Detection".

Sidecar 模式：安检门

Sidecar: Checkpoint

Sidecar 代理就像在每个房间门口设安检。虽然能阻拦，但每个人进出都要排队，导致大楼（服务器）拥堵，性能下降，且容易被绕过。

Sidecar proxies are like airport security at every door. They block threats but create massive queues (latency) and slow down performance.

Tetragon：智能免疫

Tetragon: Immune System

Tetragon 就像人体免疫细胞，直接驻扎在血液（内核）中。只要识别到病毒（恶意进程），无需等待大脑指令，直接吞噬（Kill）病毒。这是“同步阻断”。

Tetragon acts like white blood cells in the kernel. Upon detecting malware, it instantly neutralizes it without waiting for instructions. This is "Synchronous Enforcement".

⚙️ 技术视角：内核深处的防御架构

⚙️ Technical Perspective: Deep Kernel Defense

内核级可观测性

Kernel-Level Observability

利用 eBPF (Extended Berkeley Packet Filter)，Tetragon 能够在不修改内核源码、不加载内核模块的情况下，安全地动态追踪内核函数（kprobes, tracepoints）。

Using eBPF, Tetragon safely and dynamically traces kernel functions (kprobes, tracepoints) without modifying kernel source code or loading risky kernel modules.

零开销数据上下文

Zero-Overhead Context

传统 eBPF 工具只输出 PID/IP。Tetragon 维护了一个内核内的状态表，能够即时将底层的系统调用映射到 Kubernetes 的 Pod, Namespace, Service 等高层元数据。

Standard eBPF tools only see PIDs/IPs. Tetragon maintains in-kernel state tables to instantly map low-level syscalls to Kubernetes metadata like Pods, Namespaces, and Services.

In-Kernel Enforcement

Tetragon 的独特之处在于它不仅仅是“观察者”。它使用 bpf_send_signal 辅助函数，在恶意 syscall 完成之前，直接在内核态终止进程，杜绝了 TOCTOU 攻击。

Tetragon isn't just an observer. It uses the `bpf_send_signal` helper to kill processes directly from kernel space *before* the malicious syscall completes, eliminating TOCTOU attacks.

🔍 工作原理可视化：拦截文件篡改

🔍 Architecture Visualization: Blocking File Tampering

🚀 为什么 eBPF 更快？(上下文切换的代价)

🚀 Why is eBPF Faster? (Context Switching Cost)

传统工具（如 ptrace 或用户态代理）需要在用户空间和内核空间之间反复复制数据。这就像每次寄信都要亲自跑去邮局。

Traditional tools (like ptrace) copy data between User Space and Kernel Space repeatedly. Like driving to the post office for every letter.

Tetragon 运行在内核中，数据处理就像在自家客厅完成，无需出门。这使得性能损耗从典型的 15%-20% 降低到了 < 1%。

Tetragon runs in the kernel. Processing happens "at home". This drops overhead from 15-20% to < 1%.

🛡️ 三大核心防御场景

🛡️ Three Core Defense Scenarios

1. 敏感文件防篡改

1. File Integrity Monitoring

威胁： 攻击者修改 /etc/passwd。
对策： 监控 write 系统调用，触发即 Kill。

Threat: Modifying /etc/passwd.
Action: Monitor write syscall, Kill on trigger.

2. 反弹 Shell 阻断

2. Reverse Shell Blocking

威胁： 启动连接到 C2 服务器的 Shell。
对策： 监控 connect，禁止非预期连接。

Threat: Shell connecting to C2 server.
Action: Monitor connect, block unexpected socket.

3. 容器逃逸防御

3. Container Escape Prev.

威胁： 特权容器挂载宿主机文件系统。
对策： 强制执行 Namespace 隔离。

Threat: Privileged container mounting host FS.
Action: Enforce Namespace isolation.

📝 策略即代码 (Policy as Code)

📝 Policy as Code

Tetragon 使用 Kubernetes CRD 管理安全策略，清晰易读。

Tetragon uses Kubernetes CRD for security policies, simple and readable.

# 示例 1：禁止任何非 Root 用户读取 /etc/shadow
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "deny-shadow-read"
spec:
  kprobes:
  - call: "sys_openat"
    args:
    - index: 1
      operator: "Equal"
      values: ["/etc/shadow"]
    selectors:
    - matchActions:
      - action: "Sigkill" # 立即终止进程

# 示例 2：Log4Shell 虚拟补丁 (禁止 Java 进程启动 Shell)
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "log4shell-virtual-patch"
spec:
  kprobes:
  - call: "sys_execve"
    selectors:
    - matchBinaries:
      - operator: "In"
        values: ["/usr/bin/java"]
      matchArgs:
      - index: 0
        operator: "Prefix"
        values: ["/bin/sh", "/bin/bash"]
      matchActions:
      - action: "Sigkill"

💻 实时攻防演练：体验“秒杀”黑客

💻 Live Attack Simulation

点击下方按钮，模拟黑客攻击行为。观察 Tetragon 如何在毫秒级内响应。

Click below to simulate a hacker attack. Watch Tetragon respond in milliseconds.

ssh root@production-db-01

Last login: Today from 192.168.1.5

root@prod-db:~#

技术深度解析：它是如何做到零开销阻断的？

Technical Deep Dive: How is Zero-Overhead Blocking Achieved?

1. 同步阻断 (Synchronous Enforcement) 1. Synchronous Enforcement

不同于传统的“检测-告警-响应”异步模式，Tetragon 挂载在内核关键函数（如 sys_write）上。当恶意行为发生时，它在内核态直接发送 SIGKILL 信号终止进程。这意味着攻击者还没来得及写入文件，进程就已经被杀死了。

Unlike the traditional "Detect-Alert-Respond" asynchronous mode, Tetragon attaches to critical kernel functions (like sys_write). When malicious behavior occurs, it sends a SIGKILL signal directly in kernel space to terminate the process. This means the process is killed before the attacker can even write the file.

2. O(1) 性能复杂度 (O(1) Complexity) 2. O(1) Complexity

Tetragon的过滤逻辑依赖 eBPF Map（哈希表）进行数据存储和查找。无论安全策略有多少条（是 10 条还是 10,000 条），规则匹配的时间复杂度始终是 O(1)。这保证了即使在高负载的生产环境中，开启安全阻断功能也不会拖慢业务系统的运行速度。

Tetragon's filtering logic relies on eBPF Maps (hash tables) for data storage and lookup. Regardless of how many security policies there are (10 or 10,000), the rule matching time complexity remains O(1). This ensures that enabling security blocking does not slow down business systems even in high-load production environments.

3.3 Hubble 网络的“透视眼” 3.3 Hubble: Network "X-Ray"

📡 为什么我们需要 Hubble？(空中交通管制)

📡 Why Hubble? (Air Traffic Control)

想象一下，你是一个繁忙机场的空中交通管制员。在没有雷达（Hubble）之前，你只能通过无线电询问飞行员（应用程序）他们在哪里。如果无线电静默，你就是瞎子。

Imagine being an Air Traffic Controller. Without radar (Hubble), you rely on pilots to radio their positions. If radio silence hits, you fly blind.

❌ 没有 Hubble (盲区)

❌ Before Hubble (Blind Spot)

黑盒：服务 A 连不上服务 B，是网络问题？DNS？还是应用崩溃？谁也不知道。Black Box: Service A fails. Is it network? DNS? App? No clue.
性能杀手：为了调试，必须注入 Sidecar，消耗资源。Performance Tax: Debugging requires heavy Sidecars.
安全盲区：无法精确知道非法的外部连接。Security Gap: Can't track illicit external connections.

✅ 拥有 Hubble (上帝视角)

✅ With Hubble (God View)

自动拓扑：自动绘制服务依赖关系图。Auto Topology: Generates service maps instantly.
零侵入：无需修改代码，无需重启 Pod。Zero Instr: No code changes, no restarts.
深度取证：精确到 HTTP, DNS, Kafka 的 7 层可见性。L7 Forensics: HTTP, DNS, Kafka visibility.

⚡ 核心原理：eBPF 的魔法 (The How)

⚡ The Core Principle: eBPF Magic

Hubble 利用 Cilium 在 Linux 内核中运行 eBPF 程序，实现“一次写入，处处可见”。它直接在网络数据包经过内核时进行“抄送”和分析，由于运行在内核态，避免了昂贵的上下文切换，几乎零开销。

Hubble uses eBPF to achieve "Observe Once, See Everywhere". It analyzes packets as they traverse the kernel. Running in kernel space avoids expensive context switching, resulting in near-zero overhead.

架构三剑客：

Architecture Trio:

Hubble Server： 运行在每个 K8s 节点上，搜集本地流量日志。
Hubble Relay： 聚合器，连接所有 Server，提供全集群视角。
Hubble UI / CLI： 可视化界面，展示服务地图和流量详情。

Hubble Server: Runs on every node, collects local flow logs.
Hubble Relay: Aggregator, provides cluster-wide view.
Hubble UI / CLI: Visualizes service maps and flow details.

💎 核心价值与场景 (The Value)

💎 Core Value & Scenarios

L3/L4

基础网络流可视
(IP & Port)

Network Flow
(IP & Port)

L7

应用层可视
(HTTP, DNS, Kafka)

App Layer
(HTTP, DNS)

Policy

网络策略
审计与判决

Network Policy
Audit & Verdicts

具体场景举例：

Use Cases:

排错 (Troubleshooting)： 当用户抱怨“服务变慢”，Hubble 立即显示是 TCP 超时、DNS 失败还是 HTTP 500。
安全合规 (Security)： 发现 Pod 试图连接未知外部 IP（挖矿？）。Hubble 标记所有被策略拒绝的流量 (Policy Drops)。
架构梳理： 自动生成服务拓扑图，帮助新员工快速理解微服务架构。

Troubleshooting: Instantly reveal if slowness is TCP timeout, DNS failure, or HTTP 500.
Security: Detect pods connecting to unknown IPs. Flag all Policy Drops.
Architecture: Auto-generate topology maps for instant understanding.

4. 技术代差对比：Isovalent eBPF vs 传统方案

4. Technology Generation Gap: Isovalent eBPF vs Legacy

为什么选择 eBPF 路线？以下是架构层面的根本性差异：

特性 (Feature)	Isovalent / eBPF (现代方案)	Legacy / 传统方案 (旧方案)
安全防御机制 Security	同步阻断 (Synchronous Enforcement) 在恶意行为发生前，直接在内核空间杀死进程，消除延迟。	异步检测 (Asynchronous Detection) 如日志分析或传统安全工具，像摄像头一样只能记录下犯罪过程，但发现时损害已造成。
部署与系统影响 Deployment	近零影响 (开销 < 1%) 无需修改内核源码或加载内核模块，动态加载，安全稳定。	高性能损耗 / 风险 Sidecar 代理会导致大量排队（延迟）；内核模块存在风险，往往需要停机重启。
安全事件上下文 Context	内核级可观测性能够将低层的系统调用即时映射到高层的 Kubernetes 元数据 (Pod, Namespace)。	信息盲区 / 易被篡改传统 eBPF 工具可能只看到 PID/IP。Auditd 日志易被高级黑客删除，导致“瞎子”状态。
网络性能 (K8s) Network Performance	取代 kube-proxy 通过 eBPF 数据平面提供增强的 Service 支持、更低的延迟，并保留外部客户端源 IP。	性能瓶颈依赖传统 kube-proxy 和 iptables，规则多了会卡顿，存在同步开销。

5. 生态闭环：现有投资价值最大化

5. Ecosystem: Maximizing Existing Investments

我们不是推翻您现有的体系，而是无缝融入 Cisco ACI 和 Splunk：

Splunk 集成价值：上下文即王道

Tetragon 发送到 Splunk 的不是杂乱的日志，而是包含完整故事线的数据。您不仅知道“谁”做了坏事，还能知道“是谁启动了它”，攻击路径一目了然。

Splunk receives full story-lines, not noisy logs. See the entire attack path instantly.

6. 为什么制造业需要 Isovalent 企业版？

6. Why Manufacturing Needs Enterprise Edition?

需求 (Requirement)	Isovalent 企业版	开源社区版
老旧系统支持 RHEL 7, CentOS 7	全面支持提供旧版内核兼容构建，保护既有资产。	有限支持通常依赖较新内核 (5.4+)。
安全合规 FIPS, SOC2	FIPS 认证镜像开箱即用合规报表。	需自行配置无官方认证。
技术支持 SLA	24/7/365 专家支持含热修复补丁 (Hotfixes)。	社区支持无 SLA 保障。

7. FAQ (常见问题)

7. FAQ

Q: 使用这套方案，我需要修改现有的应用程序代码吗？

Q: Do I need to change my app code?

完全不需要。 eBPF 在内核层工作，对上层应用是完全透明的。无论您运行的是 Java, Python 还是旧的遗留系统，都能直接享受安全和网络加速，无需重新开发。

Q: 我们的服务器有一些是老旧的 Linux 版本，能支持吗？

Q: We have old Linux servers, is it supported?

是的，Isovalent 企业版支持。 即使内核较旧（如 RHEL 7），企业版也提供了兼容支持，确保您无需立即升级操作系统也能使用 eBPF 能力。

Q: 这会增加我的运维复杂度吗？

Q: Will this increase complexity?

反而会降低。 以前您需要维护防火墙规则、Sidecar 代理、日志收集器等一堆组件。现在 Cilium 一套方案解决了网络、安全和监控，排查问题变得像看地图一样简单。

📖 附录：通俗概念辞典

📖 Appendix: Glossary for Business Leaders

Kernel (系统内核) Kernel

操作系统的“大脑”和“心脏”。它控制着所有硬件和软件的交互。Isovalent 的工具就是在这个核心区域工作的，所以效率极高。

The "brain" of the OS. Controls all hardware/software interaction. Our tools work here, hence the high efficiency.

Sidecar (边车模式) Sidecar

传统技术需要在每个应用旁边挂一个“小助手”来处理网络（就像三轮摩托车的边车）。这会消耗大量内存。我们通过 eBPF 去掉了这个“边车”，让车跑得更快、更省油。

Traditional tech attaches a "helper" to every app (like a motorcycle sidecar), eating RAM. We remove this "sidecar" using eBPF, saving resources.

Zero Trust (零信任) Zero Trust

默认不信任任何人。以前是“进了大门就是自己人”，现在是“即使在家里，进卧室也要刷卡”。Tetragon 提供了这种级别的内部安全管控。

Trust no one by default. Even inside the network perimeter, every action is verified. Tetragon provides this granular internal security.