企业官网建设流程全解析

在 minikube 上快速上手 Cilium：安装部署与 Star Wars 网络策略实战

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium

本文以 Cilium 仓库中 examples/minikube 目录为核心，完整演示如何在本地 minikube 集群中安装 Cilium（eBPF-based Networking, Security, and Observability 项目），并借助仓库自带的 Star Wars 示例应用与三份 CiliumNetworkPolicy 策略文件，从零体验从 L3/L4 网络层到 L7 HTTP 层的安全策略配置与验证流程。读完本文，你将掌握minikube start --cni=cilium的快速装机路径、基于身份（标签）的访问控制策略编写方法，以及用kubectl与cilium-dbg验证策略生效的完整调试手段。

一、为什么选择 minikube 体验 Cilium

Cilium 是一个基于 eBPF 的云原生网络、安全与可观测性项目，其核心能力包括：

• 身份感知的网络策略：策略匹配 Pod 标签（Identity）而非 IP 地址，规避了传统网络策略在动态调度场景下的脆弱性；
• L7 应用层策略：可对 HTTP/gRPC/Kafka 等七层协议做细粒度访问控制，实现微服务"最小权限"隔离；
• 可观测性：通过 Hubble 与cilium-dbg monitor实时观察流量走向与策略判决结果。

minikube 是本地搭建单节点 Kubernetes 集群的最轻量方案，配合 Cilium 仓库中现成的示例清单文件，可以在几分钟内构建一个可用于学习和验证的最小环境。仓库根目录下的 Documentation/gettingstarted/k8s-install-default.rst 将 minikube 列为快速安装的推荐方式之一，examples/minikube 则提供了配套的演示资源。

二、创建带 Cilium 的 minikube 集群

2.1 前置条件

• 安装 minikube≥ v1.28.0（按 minikube 官方文档安装即可）；
• 本机已安装kubectl并可用；
• 具备拉取镜像的网络条件（集群创建过程需要下载 Cilium 相关镜像）。

2.2 一条命令启动集群

Cilium 官方快速安装文档（Documentation/gettingstarted/k8s-install-default.rst 的 minikube 选项卡）给出的命令极其简洁：

$ minikube start --cni=cilium

该命令会直接拉起一个为安装 Cilium 准备好的单节点 minikube 集群——--cni=cilium让 minikube 跳过默认 kube-proxy 类网络插件，把 CNI 插件的安装职责交给 Cilium 自身完成。

2.3 两个需要注意的坑

官方文档对 minikube 方式给出了两条重要提示：

1. 版本问题：minikube start --cni=cilium安装的可能不是最新版本的 Cilium。若需要固定/升级到特定版本，建议改用 Cilium CLI（cilium install）或 Helm 方式在集群内单独部署；
2. Virtualbox provider 的 DNS 问题：如果使用 Virtualbox 作为 minikube 的驱动，可能需要追加--host-dns-resolver=false参数，否则 Cilium 安装完成后集群内 DNS 解析可能无法正常工作：

$ minikube start --cni=cilium --driver=virtualbox --host-dns-resolver=false

2.4 确认 Cilium 就绪

集群启动后，检查 Cilium 组件是否正常运行：

$ kubectl -n kube-system get pods -l k8s-app=cilium NAME READY STATUS RESTARTS AGE cilium-5ngzd 1/1 Running 0 3m19s

待 Cilium agent Pod 处于Running且集群内kube-dns正常工作后，即可部署演示应用。

三、部署 Star Wars 演示应用

3.1 应用拓扑与角色设计

Documentation/security/gsg_sw_demo.rst 说明了这套示例的业务语义：它模拟《星球大战》中的帝国（empire）与同盟（alliance）两个阵营，包含三个微服务：

这套拓扑存在的意义正是用于测试不同安全策略对deathstar着陆服务的访问控制效果。

3.2 清单文件结构解析

示例清单位于 examples/minikube/http-sw-app.yaml，包含三个 Kubernetes 资源：

• Service/deathstar：ClusterIP类型，暴露 80 端口，通过selector（org=empire, class=deathstar）关联后端 Pod；
• Deployment/deathstar：replicas: 2，镜像为quay.io/cilium/starwars（固定 digest，v2.3），提供实际 HTTP 业务逻辑；
• 两个裸 Pod：tiefighter与xwing，均使用quay.io/cilium/json-mock:v1.4.1镜像，仅作为策略测试的流量发起方。

3.3 部署并确认状态

$ kubectl create -f examples/minikube/http-sw-app.yaml service/deathstar created deployment.apps/deathstar created pod/tiefighter created pod/xwing created

等待 Pod 全部进入Running：

$ kubectl get pods,svc NAME READY STATUS RESTARTS AGE pod/deathstar-6fb5694d48-5hmds 1/1 Running 0 107s pod/deathstar-6fb5694d48-fhf65 1/1 Running 0 107s pod/tiefighter 1/1 Running 0 107s pod/xwing 1/1 Running 0 107s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/deathstar ClusterIP 10.96.110.8 <none> 80/TCP 107s service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 3m53s

四、无策略时的默认访问行为

在尚未导入任何网络策略之前，Cilium 对所有 Pod 均不启用策略强制（ingress/egress 均为 Disabled）。可以通过cilium-dbg endpoint list查看每个 Pod（在 Cilium 中称为 endpoint）对应的身份与策略状态：

$ kubectl -n kube-system exec cilium-5ngzd -- cilium-dbg endpoint list ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS ENFORCEMENT ENFORCEMENT 232 Disabled Disabled 16530 k8s:class=deathstar 10.0.0.147 ready k8s:io.cilium.k8s.policy.cluster=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default k8s:org=empire ... 3184 Disabled Disabled 22654 k8s:class=xwing 10.0.0.30 ready k8s:io.cilium.k8s.policy.cluster=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default k8s:org=alliance

注意其中的IDENTITY列：Cilium 用标签而非 IP 标识身份，两个deathstar副本共享身份16530，xwing则因org=alliance拥有独立的身份22654。

由于没有规则，此时帝国与同盟的飞船都能成功请求着陆：

$ kubectl exec xwing -- curl -s -XPOST deathstar/v1/request-landing Ship landed $ kubectl exec tiefighter -- curl -s -XPOST deathstar/v1/request-landing Ship landed

五、先收紧：默认拒绝（Default-Deny）策略

在生产实践中最常见的安全基线是"默认拒绝，按需放行"。仓库在 examples/minikube/sw_deny_policy.yaml 中给出了针对整个帝国阵营的默认拒绝策略：

apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "empire-default-deny" spec: description: "Default-deny ingress policy for the empire" endpointSelector: matchLabels: org: empire ingress: - {}

关键点：

• endpointSelector.matchLabels: org: empire选中所有帝国 Pod；
• ingress: [{}]是一个空规则：它匹配一切来源，但其内部没有声明任何可放行的fromEndpoints/toPorts，效果是对所有帝国 Pod 的入站流量实施默认拒绝。

$ kubectl create -f examples/minikube/sw_deny_policy.yaml ciliumnetworkpolicy.cilium.io/empire-default-deny created

说明：在实际的 Demo 流程中，也可以跳过此步、直接用后面的白名单策略替代——因为 Cilium 的策略语义是"只放行显式允许的流量"，一旦有策略选中某 endpoint，未匹配到的流量即被丢弃。此文件用于单独演示默认拒绝基线的写法。

六、L3/L4 网络策略：按身份限制访问

6.1 策略文件详解

examples/minikube/sw_l3_l4_policy.yaml 定义了一条名为rule1的 L3/L4 白名单策略：

apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "rule1" spec: description: "L3-L4 policy to restrict deathstar access to empire ships only" endpointSelector: matchLabels: org: empire class: deathstar ingress: - fromEndpoints: - matchLabels: org: empire toPorts: - ports: - port: "80" protocol: TCP

语义拆解：

这条策略只过滤网络层（L3，IP）与传输层（L4，TCP），因此被称为 L3/L4 网络策略。正如 Documentation/gettingstarted/demo.rst 所强调的：Cilium 执行有状态的连接跟踪，策略允许前端访问后端时，同一 TCP/UDP 连接内后端返回的应答包会自动放行，无需额外配置。

6.2 应用策略并验证

$ kubectl create -f examples/minikube/sw_l3_l4_policy.yaml ciliumnetworkpolicy.cilium.io/rule1 created

再次发起着陆请求：tiefighter（org=empire）成功，xwing（org=alliance）被丢弃、连接挂起直至超时：

$ kubectl exec tiefighter -- curl -s -XPOST deathstar/v1/request-landing Ship landed $ kubectl exec xwing -- curl -s -XPOST deathstar/v1/request-landing # 请求挂起，按 Control-C 中断或等待超时

6.3 验证策略已生效

通过cilium-dbg endpoint list可观察到两个deathstarendpoint 的ingress 策略强制已变为Enabled：

$ kubectl -n kube-system exec cilium-1c2cz -- cilium-dbg endpoint list 232 Enabled Disabled 16530 k8s:class=deathstar ... ready 2843 Enabled Disabled 16530 k8s:class=deathstar ... ready

用kubectl也能查看策略对象：

$ kubectl get cnp NAME AGE rule1 2m $ kubectl describe cnp rule1 Name: rule1 Namespace: default API Version: cilium.io/v2 Description: L3-L4 policy to restrict deathstar access to empire ships only Kind: CiliumNetworkPolicy Spec: Endpoint Selector: Match Labels: Class: deathstar Org: empire Ingress: From Endpoints: Match Labels: Org: empire To Ports: Ports: Port: 80 Protocol: TCP

七、L7 策略：HTTP 层的细粒度访问控制

7.1 问题场景

L3/L4 策略解决了"谁能连"的问题，但无法区分"连上之后能调哪些 API"。Demo 中deathstar暴露了一个本不该被普通飞船调用的维护接口：

$ kubectl exec tiefighter -- curl -s -XPUT deathstar/v1/exhaust-port Panic: deathstar exploded

要落实微服务间的最小权限隔离，就需要 L7（应用层）策略。Cilium 支持在 L3/L4 规则之上叠加 HTTP 规则，精确限制允许的方法与路径。

7.2 L7 策略文件详解

examples/minikube/sw_l3_l4_l7_policy.yaml 在 L3/L4 规则基础上增加了rules.http：

apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "rule1" spec: description: "L7 policy to restrict access to specific HTTP call" endpointSelector: matchLabels: org: empire class: deathstar ingress: - fromEndpoints: - matchLabels: org: empire toPorts: - ports: - port: "80" protocol: TCP rules: http: - method: "POST" path: "/v1/request-landing"

新增的rules.http声明：仅允许来源为org=empire的身份，对deathstar的 TCP 80 端口发起POST /v1/request-landing请求；其余一切 HTTP 方法/路径（包括PUT /v1/exhaust-port）均被拒绝。

更新（替换）已有规则：

$ kubectl apply -f examples/minikube/sw_l3_l4_l7_policy.yaml ciliumnetworkpolicy.cilium.io/rule1 configured

7.3 验证 L7 策略

允许的请求照常通过，越权的PUT被显式拒绝：

$ kubectl exec tiefighter -- curl -s -XPOST deathstar/v1/request-landing Ship landed $ kubectl exec tiefighter -- curl -s -XPUT deathstar/v1/exhaust-port Access denied

非帝国来源依然被 L3 层丢弃、连接超时：

$ kubectl exec xwing -- curl -s -XPOST deathstar/v1/request-landing # 请求挂起

7.4 路径匹配与正则

注意：path默认是精确匹配。若想放行某一前缀下的所有路径，需要使用正则表达式，例如：

path: "/v1/.*"

7.5 从策略对象与实时监控中观察 L7 规则

通过kubectl describe ciliumnetworkpolicies可看到rule1已携带 HTTP 规则（Method: POST, Path: /v1/request-landing，Generation 为 2，表明已被更新过）。

通过cilium-dbg policy get可查看 Cilium 内部基于身份的完整策略模型——注意标签被规范化为any:class、any:org等带身份域的键：

$ kubectl -n kube-system exec cilium-qh5l2 -- cilium-dbg policy get [ { "endpointSelector": { "matchLabels": { "any:class": "deathstar", "any:org": "empire", "k8s:io.kubernetes.pod.namespace": "default" } }, "ingress": [ { "fromEndpoints": [...], "toPorts": [ { "ports": [ { "port": "80", "protocol": "TCP" } ], "rules": { "http": [ { "path": "/v1/request-landing", "method": "POST" } ] } } ] } ], "revision": 11 } ]

实时观察 L7 流量判决结果，使用cilium-dbg monitor过滤 L7 事件：

$ kubectl exec -it -n kube-system cilium-kzgdx -- cilium-dbg monitor -v --type l7 <- Response http to 0 ([k8s:class=tiefighter ... k8s:org=empire]) from 2756 ([... k8s:class=deathstar ...]), identity 8876->43854, verdict Forwarded POST http://deathstar/v1/request-landing => 200 <- Request http from 0 ([k8s:class=tiefighter ... k8s:org=empire]) to 2756 ([... k8s:class=deathstar ...]), identity 8876->43854, verdict Denied PUT http://deathstar/v1/request-landing => 403

输出清晰地展示了：POST /v1/request-landing被Forwarded（200），PUT请求被Denied（403）——策略判决结果与身份（identity）一一对应，这就是 eBPF 数据路径上基于身份的 L7 强制效果。

八、清理环境

实验结束后，删除应用与策略：

$ kubectl delete -f examples/minikube/http-sw-app.yaml $ kubectl delete cnp rule1

如需进一步深入，可继续阅读 Documentation/gettingstarted/demo.rst 与 Documentation/security/gsg_sw_demo.rst，或结合 Documentation/gettingstarted/k8s-install-default.rst 了解 GKE/AKS/EKS/kind 等其他环境下的安装差异。

九、小结

通过本文，我们完成了从零到一的完整闭环：

1. 用minikube start --cni=cilium一条命令获得可用的 Cilium 环境；
2. 部署 http-sw-app.yaml 中三个标签化的微服务；
3. 依次用 sw_deny_policy.yaml（默认拒绝）、sw_l3_l4_policy.yaml（身份 + 端口白名单）、sw_l3_l4_l7_policy.yaml（HTTP 方法/路径白名单）验证了从网络层到应用层的策略递进；
4. 掌握kubectl get/describe cnp、cilium-dbg endpoint list、cilium-dbg policy get、cilium-dbg monitor --type l7四条核心验证链路。

这套"标签定义身份 → 白名单策略 → L7 精确放行"的实践路径，正是 Cilium 在真实 Kubernetes 集群中落地零信任与最小权限网络隔离的缩影。

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium