大家好！在Kubernetes环境中，面对服务之间错综复杂的通信，大家是否都有过头疼的经历呢？🧐 比如“这个Pod需要和那个Pod通信…”，或者“咦？这个Pod绝对不能对外访问！”这样的烦恼。
今天，我们将深入探讨Cilium网络策略的核心原理，它是解决这些复杂网络流量的能手。它就像交通警察一样，决定哪些流量可以通过(Go🚦)，哪些流量需要阻止(Stop🛑)，是一套既简单又强大的规则。
只要您读完这篇文章，您也能成为Cilium网络策略专家！
🤔 Cilium策略，核心到底是什么？
开门见山地说，贯穿Cilium网络策略的三个最核心要素就是“谁（Source）”、“给谁（Destination）”、“做什么（Action）”。
只要记住这三点，您就已经理解了Cilium策略的一半！
- Source (谁发送？ 📤)
- 指发起流量的主体。在“A向B发送数据”中，它就是“A”。
- 在Cilium中，您可以明确指定源为具有特定标签的Pod组（如app=frontend）、特定的IP范围（CIDR）或其他实体。
- Destination (发送给谁？ 📥)
- 指接收流量的目标。在上述示例中，它就是“B”。
- 通常指策略所应用的端点（Pod）本身，更进一步，您还可以指定特定的端口号，进行精细控制，例如“只允许进入80端口的流量！”。
- Action (将如何处理？ ✅)
- 决定当从源到目标的流量与规则匹配时，应采取何种措施。
- Cilium最重要的理念是“Default Deny（默认拒绝）”。这意味着，如果没有设置任何策略，所有Pod之间的通信都将被阻止。因此，我们创建的策略是一种“允许（Allow）”特定流量的“白名单”方式。这个“允许”就是Action。
🗺️ 从全局理解：默认拒绝与允许策略
了解单个要素固然重要，但理解整体流程才能真正体会到Cilium的强大之处。
我们来假设一个场景：您的集群中有一个frontend Pod和一个backend Pod。frontend需要接收用户请求并向backend发送API请求。
- 策略应用前 (Default Deny) 🚫
- 在应用了Cilium的环境中，frontend和backend默认无法相互通信。可以想象成所有路径都被堵塞了。即使frontend调用backend，也不会有响应。
- 策略应用后 (Allow Rule) ✅
- 我们现在需要创建一个策略，允许frontend与backend的8080端口进行通信。
- Source: 带有app=frontend标签的Pod
- Destination: 带有app=backend标签的Pod，端口为8080
- Action: 允许此通信。
一旦应用此策略，两个之前被阻止的Pod之间就会打开一个安全的通信通道。✨
💻 通过代码亲自验证：允许Frontend调用Backend
百闻不如一见！我们将通过实际的CiliumNetworkPolicy YAML文件来了解如何实现上述场景。此策略应用于backend Pod，允许来自frontend的入站流量。
# CiliumNetworkPolicy 定义 (API 版本和类型)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
# 策略将应用的命名空间
namespace: my-app
# 策略的名称
name: backend-allow-from-frontend
spec:
# --- 目标 (Destination) ---
# 选择此策略将应用于哪些Pod。
# 所有带有'app=backend'标签的Pod都是目标。
endpointSelector:
matchLabels:
app: backend
# --- 动作 (允许) + 源/目标端口 ---
# 'ingress' 指的是入站流量的规则。
ingress:
- fromEndpoints:
# --- 源 (Source) ---
# 允许来自带有'app=frontend'标签的Pod的流量。
- matchLabels:
app: frontend
toPorts:
# --- 目标端口 (Destination Port) ---
# 此规则仅适用于进入8080/TCP端口的流量。
- ports:
- port: "8080"
protocol: TCPYAML文件解析：
- endpointSelector: 定义此策略的Destination（目标）是谁（app=backend Pod）。
- ingress: 明确表示这是针对入站流量的规则。
- fromEndpoints: 定义流量的Source（源）是谁（app=frontend Pod）。
- toPorts: 通过指定Destination的特定端口，使规则更加精细。
- 将此YAML文件本身应用到集群的行为，即表示Action（允许）。
🧐 等等，为什么这不是正确答案？
有些概念看起来相似，但偏离了核心。理解为什么它们不是基本结构，可以使概念更清晰。
- ❌ Pod, Service, Namespace
- 原因: 它们是Kubernetes的“对象”或“资源”。Cilium策略利用这些对象来“指定”源或目标，但它们不是策略规则本身的基本结构（谁、给谁、如何）。换句话说，它们只是食材，而不是食谱的基本步骤。
- ❌ Ingress, Egress, Protocol
- 原因: Ingress（入站）和Egress（出站）表示流量的“方向”。Protocol（TCP/UDP）是通信“协议”。这些是构成策略的非常重要的“属性”，但它们不是定义“源 → 目标”这一更大流程的结构性组成部分。方向和属性是在“谁给谁”的关系确定之后具体化的细节。
总结
现在您是否看到了Cilium网络策略的核心？看似复杂的YAML文件，最终也只是回答一个简单的问题：“哪个源（Source），可以与哪个目标（Destination）通信，并采取什么动作（Action）？”
只要牢记这三个核心原则，您就能成为一名出色的安全架构师，保护您的Kubernetes集群免受任何威胁。🚀
发表回复