ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

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

2026/9/14 20:29:44 拓冰建站 浏览量
在 minikube 上快速上手 Cilium：安装部署与 Star Wars 网络策略实战 在 minikube 上快速上手 Cilium安装部署与 Star Wars 网络策略实战【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本文以 Cilium 仓库中 examples/minikube 目录为核心完整演示如何在本地 minikube 集群中安装 CiliumeBPF-based Networking, Security, and Observability 项目并借助仓库自带的 Star Wars 示例应用与三份 CiliumNetworkPolicy 策略文件从零体验从 L3/L4 网络层到 L7 HTTP 层的安全策略配置与验证流程。读完本文你将掌握minikube start --cnicilium的快速装机路径、基于身份标签的访问控制策略编写方法以及用kubectl与cilium-dbg验证策略生效的完整调试手段。一、为什么选择 minikube 体验 CiliumCilium 是一个基于 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 --cnicilium该命令会直接拉起一个为安装 Cilium 准备好的单节点 minikube 集群——--cnicilium让 minikube 跳过默认 kube-proxy 类网络插件把 CNI 插件的安装职责交给 Cilium 自身完成。2.3 两个需要注意的坑官方文档对 minikube 方式给出了两条重要提示版本问题minikube start --cnicilium安装的可能不是最新版本的 Cilium。若需要固定/升级到特定版本建议改用 Cilium CLIcilium install或 Helm 方式在集群内单独部署Virtualbox provider 的 DNS 问题如果使用 Virtualbox 作为 minikube 的驱动可能需要追加--host-dns-resolverfalse参数否则 Cilium 安装完成后集群内 DNS 解析可能无法正常工作$ minikube start --cnicilium --drivervirtualbox --host-dns-resolverfalse2.4 确认 Cilium 就绪集群启动后检查 Cilium 组件是否正常运行$ kubectl -n kube-system get pods -l k8s-appcilium 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两个阵营包含三个微服务服务/Pod标签角色deathstarorgempire, classdeathstar在 80 端口提供 HTTP 着陆服务暴露为 Kubernetes Service负载均衡到两个副本tiefighterorgempire, classtiefighter帝国飞船着陆请求客户端xwingorgalliance, classxwing同盟飞船着陆请求客户端应被策略拒绝这套拓扑存在的意义正是用于测试不同安全策略对deathstar着陆服务的访问控制效果。3.2 清单文件结构解析示例清单位于 examples/minikube/http-sw-app.yaml包含三个 Kubernetes 资源Service/deathstarClusterIP类型暴露 80 端口通过selectororgempire, classdeathstar关联后端 PodDeployment/deathstarreplicas: 2镜像为quay.io/cilium/starwars固定 digestv2.3提供实际 HTTP 业务逻辑两个裸 Podtiefighter与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:classdeathstar 10.0.0.147 ready k8s:io.cilium.k8s.policy.clusterdefault k8s:io.cilium.k8s.policy.serviceaccountdefault k8s:io.kubernetes.pod.namespacedefault k8s:orgempire ... 3184 Disabled Disabled 22654 k8s:classxwing 10.0.0.30 ready k8s:io.cilium.k8s.policy.clusterdefault k8s:io.cilium.k8s.policy.serviceaccountdefault k8s:io.kubernetes.pod.namespacedefault k8s:orgalliance注意其中的IDENTITY列Cilium 用标签而非 IP 标识身份两个deathstar副本共享身份16530xwing则因orgalliance拥有独立的身份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选中所有帝国 Podingress: [{}]是一个空规则它匹配一切来源但其内部没有声明任何可放行的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语义拆解字段值作用endpointSelectororgempire, classdeathstar策略作用于deathstar端点ingress.fromEndpointsorgempire仅放行带orgempire标签的来源身份toPortsTCP 80仅放行目标端口 80这条策略只过滤网络层L3IP与传输层L4TCP因此被称为 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再次发起着陆请求tiefighterorgempire成功xwingorgalliance被丢弃、连接挂起直至超时$ 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:classdeathstar ... ready 2843 Enabled Disabled 16530 k8s:classdeathstar ... 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.httpapiVersion: 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声明仅允许来源为orgempire的身份对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 configured7.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-landingGeneration 为 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:classtiefighter ... k8s:orgempire]) from 2756 ([... k8s:classdeathstar ...]), identity 8876-43854, verdict Forwarded POST http://deathstar/v1/request-landing 200 - Request http from 0 ([k8s:classtiefighter ... k8s:orgempire]) to 2756 ([... k8s:classdeathstar ...]), identity 8876-43854, verdict Denied PUT http://deathstar/v1/request-landing 403输出清晰地展示了POST /v1/request-landing被Forwarded200PUT请求被Denied403——策略判决结果与身份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 等其他环境下的安装差异。九、小结通过本文我们完成了从零到一的完整闭环用minikube start --cnicilium一条命令获得可用的 Cilium 环境部署 http-sw-app.yaml 中三个标签化的微服务依次用 sw_deny_policy.yaml默认拒绝、sw_l3_l4_policy.yaml身份 端口白名单、sw_l3_l4_l7_policy.yamlHTTP 方法/路径白名单验证了从网络层到应用层的策略递进掌握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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考