Cilium 的 CiliumEndpoint CRD从 Kubernetes API 洞察每个 Pod 的网络身份与安全策略【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/ciliumCiliumEndpointCEP是 Cilium 在 Kubernetes 集群中为每一个被其管理的 Pod 自动创建的 Custom ResourceCRD对象它以 Kubernetes 原生 API 的形式暴露 Pod 的网络状态快照包括 IP 地址、安全身份Security Identity以及生效中的网络策略。阅读本文后你将掌握如何通过kubectl快速检索集群内任意 Pod 的网络细节、理解 CiliumEndpoint 的字段结构与源码定义并了解其在大规模集群中的扩展形态 CiliumEndpointSlice。CiliumEndpoint 是什么Pod 网络状态的「Kubernetes 原生投影」当 Cilium 作为 Kubernetes 集群的 CNI 插件运行时它不会把端点Endpoint信息只保存在 agent 本地的内存或 kvstore 中而是将每个被其管理的 Pod 映射为一个 Kind 为CiliumEndpoint的自定义资源。每个 Pod 恰好对应一个 CiliumEndpoint且两者同名、同命名空间见 Documentation/network/kubernetes/ciliumendpoint.rst。这种「一 Pod 一 CRD」的设计带来两个直接收益统一的数据视图CiliumEndpoint 的内容与在任意节点上执行cilium-dbg endpoint get输出的.status字段完全一致但后者只能看到该节点上的端点而 CiliumEndpoint 可以通过 Kubernetes API 查看集群中所有 Pod的网络状态。标准化的查询入口任何拥有 Kubernetes RBAC 权限的组件、CI 流水线或运维脚本都可以用kubectl、client-go 或任意 Kubernetes 客户端访问这些信息而无需 SSH 到节点执行特权命令。从源码结构看这一映射关系在 Cilium 的 API 模型中是一等公民CRD 的类型定义位于 pkg/k8s/apis/cilium.io/v2/types.go其CiliumEndpoint结构体仅包含metav1.TypeMeta、metav1.ObjectMeta与一个可选的Status EndpointStatus字段——也就是说CiliumEndpoint 没有 spec它纯粹是一个状态投影资源只负责把 cilium-agent 对端点的观测结果身份、地址、策略等同步到集群 API 中。上手使用用 kubectl 检索集群中的所有端点CiliumEndpoint 的 CRD 全名为ciliumendpoints.cilium.io在实际命令行中你几乎总是使用它的短名cep同时注册的短名还有ciliumep见 types.go 中shortName{cep,ciliumep}的 kubebuilder 注解。最常用的操作是跨命名空间列出全部端点$ kubectl get ciliumendpoints --all-namespaces NAMESPACE NAME AGE default app1-55d7944bdd-l7c8j 1h default app1-55d7944bdd-sn9xj 1h default app2 1h default app3 1h kube-system cilium-health-minikube 1h kube-system microscope 1hkubectl get cep -A可以达到同样的效果。默认表格输出只显示命名空间、名称和年龄但如果想看到每个端点更有价值的网络信息可以显式指定输出列——CRD 在定义时注册了如下打印列print columns见 types.go 与生成的 ciliumendpoints.yaml列名JSONPath说明Security Identity.status.identity.id端点关联的安全身份数值 IDIngress Enforcement.status.policy.ingress.state入方向策略强制执行状态Egress Enforcement.status.policy.egress.state出方向策略强制执行状态Endpoint State.status.state端点当前生命周期状态IPv4.status.networking.addressing[0].ipv4端点 IPv4 地址IPv6.status.networking.addressing[0].ipv6端点 IPv6 地址因此你可以直接用如下命令看到每个端点的关键网络属性$ kubectl get cep -A -o custom-columnsNAMESPACE:.metadata.namespace,NAME:.metadata.name,IDENTITY:.status.identity.id,IPV4:.status.networking.addressing[0].ipv4,STATE:.status.state如果列表视图满足不了你添加-o json或-o yaml将导出关于每个端点的更多信息包括端点的标签labels、安全身份security identity以及作用于其上的网络策略policy——这正是原文档强调的扩展信息。例如$ kubectl get ciliumendpoint -n default app2 -o json输出中的.status部分与在运行该 Pod 的节点上执行cilium-dbg endpoint get id -o json的.status内容一一对应两者可以互相印证。深入字段结构CiliumEndpoint 的 status 到底记录了哪些状态要真正用好 CiliumEndpoint需要理解EndpointStatus的完整字段模型。该类型定义在 pkg/k8s/apis/cilium.io/v2/types.go各字段含义如下字段JSON 键含义IDidcilium-agent 本地端点 ID数值Controllerscontrollers该端点上失败的 controller 列表如配置下发控制器的故障信息ExternalIdentifiersexternal-identifiers端点外部标识集合包含容器运行时 ID、docker endpoint ID 等对应models.EndpointIdentifiersHealthhealth端点整体与子组件健康状态如可达性models.EndpointHealthIdentityidentity与端点关联的安全身份见下文Loglog最近若干条 warning 与 error 日志条目models.EndpointStatusChangeNetworkingnetworking端点的网络属性IP 地址对与所在节点 IP见下文Encryptionencryption节点/端点的加密配置EncryptionSpecPolicypolicy端点上生效的入向/出向策略见下文Statestate端点生命周期状态NamedPortsnamed-ports端点的命名端口映射models.NamedPortsServiceAccountservice-account与端点关联的 Kubernetes ServiceAccount值得留意的是State字段的取值是受限枚举kubebuilder 校验注解限定为creating、waiting-for-identity、not-ready、waiting-to-regenerate、regenerating、restoring、ready、disconnecting、disconnected、invalid见 types.go。其中ready表示端点数据面就绪regenerating/waiting-to-regenerate表示安全身份或策略变更后数据面正在重建这是排查「Pod 网络为何暂时中断」时最先要看的字段。Networkingtypes.go则记录了两类关键地址信息addressing分配给该端点的 IPv4/IPv6 地址对列表AddressPairListnode端点所在节点的 IPNodeIP该地址必须保证在节点间可达。安全身份与网络策略CiliumEndpoint 的「安全视图」原文档明确指出-o json导出的扩展信息中最有价值的两块就是安全身份和生效中的策略它们分别对应status.identity与status.policy。安全身份EndpointIdentityEndpointIdentitytypes.go由两部分组成id数值形式的安全身份 IDlabels构成该身份的标签列表。Cilium 的身份Identity机制是将一组标签集合通过哈希映射为集群内唯一的安全身份 ID所有数据面策略都以身份而非 IP 为粒度进行匹配。因此从 CiliumEndpoint 里读取status.identity就能立刻知道某个 Pod 属于哪个安全域以及它当前的标签输入是什么。标签到身份的全局协调由CiliumIdentityCRD 承担同样是集群级资源见 types.go 中的CiliumIdentity定义以数值身份为对象名、以security-labels为标签集合的真实来源kubectl get ciliumid -l foobar可以按标签反查身份。网络策略EndpointPolicyEndpointPolicytypes.go将端点策略按方向拆分为ingress与egress两个EndpointPolicyDirection每个方向包含enforcing布尔值表示该方向的策略是否实际强制执行对应cilium-dbg endpoint get输出中的 enforcement 标志allowed允许的对端列表AllowedIdentityList每个条目是一个IdentityTuple由对端身份 ID、身份标签、目标端口和协议构成见 types.godenied显式拒绝的对端列表DenyIdentityListstate该方向的策略状态EndpointPolicyState取值为enforcing、non-enforcing、disabled之一见 types.go。也就是说仅凭一个 CiliumEndpoint 对象你就能回答「这个 Pod 当前允许谁访问、被禁止访问谁、策略是否真的在生效」——这对于核对 CNP/CENP 策略是否符合预期、排查「策略看起来配了但流量没被拦截」等问题是直接证据。同时注意EndpointPolicyState的disabled/non-enforcing与enforcing的区别前者表示该方向未启用策略或处于非强制模式后者表示策略已实际加载并强制执行。特殊端点cilium-health-在上面的列表输出中kube-system命名空间下出现了cilium-health-minikube这样的条目它并不是普通的 Kubernetes Pod。原文档特别提示每个 cilium-agent Pod 都会创建一个代表其自身 inter-agent 健康检查端点的 CiliumEndpoint。这类端点不属于任何 Kubernetes Pod因此没有对应的 Pod 对象固定位于kube-system命名空间命名规则为cilium-health-node-name例如运行在节点minikube上的 agent 就会创建cilium-health-minikube。它用于 Cilium 集群内节点之间的健康探测cilium-health 机制通过查看这类 CEP 的status.health与status.state可以判断节点间的网络连通性与 agent 健康检查端点的状态。规模化演进从 CiliumEndpoint 到 CiliumEndpointSlice当集群规模增大后每个 Pod 对应一个 CEP 意味着大量 CEP 对象要在 cilium-agent 与 API Server 之间持续同步会给 API Server 带来压力。为此 Cilium 提供了CiliumEndpointSliceCES机制由 Cilium Operator 监控 CEP 对象并把它们的精简版本slim 版本批量打包进 CES 对象cilium-agent 改为监听 CES 来学习远端端点信息见 Documentation/network/kubernetes/ciliumendpointslice.rst。CES 是当前仓库中独立于 Kubernetes EndpointSlice 的 Cilium 专属概念前者为 Service 负载均衡跟踪后端而 CEP/CES 服务于网络路由与策略决策二者互不影响。CES 默认关闭需要时可通过 Helm 值ciliumEndpointSlice.enabled或 Operator 的--enable-cilium-endpoint-slice标志开启并用--ces-max-cilium-endpoints-per-ces调节单个 CES 中 CEP 的批量上限。也就是说CiliumEndpoint 是整个体系的基础信息单元CES 只是它在超大规模场景下的传输与存储优化形态——理解 CEP 的字段模型是理解 CES 的前置条件。运维实战CiliumEndpoint 的典型使用场景综合以上内容CiliumEndpoint 在真实运维中至少有三个高价值入口全集群网络清单盘点kubectl get cep -A输出每个 Pod 的 IPv4/IPv6、安全身份与端点状态是「一分钟摸清集群网络现状」的快捷方式尤其适合在故障发生时快速定位异常端点如status.state长期不是ready的 Pod。策略生效验证对某个受网络策略保护的 Pod 执行kubectl get cep pod -n ns -o json检查status.policy.ingress.enforcing与status.policy.ingress.allowed与预期 CNP/CENP 规则交叉比对即可确认策略是否如设计般生效。身份与可达性排障结合status.identity.labels判断安全身份是否符合预期例如是否错误地落入了reserved身份而非工作负载身份结合status.networking.node确认 Pod 所在节点再配合cilium-dbg endpoint get在节点本地做深度排查两者数据同源可互相印证。如果想深入字段级细节建议直接研读仓库中的两个权威定义源pkg/k8s/apis/cilium.io/v2/types.goGo 类型定义与 kubebuilder 注解和 pkg/k8s/apis/cilium.io/client/crds/v2/ciliumendpoints.yaml最终落地的 OpenAPI Schema包含每个字段的校验规则与描述。所有字段是否可写、取值范围如何均以这两份文件为准。小结CiliumEndpoint 是 Cilium 面向 Kubernetes 生态的「状态投影层」它把每个 Pod 的数据面观测结果地址、身份、策略、健康与生命周期状态以标准 CRD 形式暴露给整个集群让网络和安全状态不再局限于 agent 本地。掌握kubectl get cep、-o json的字段解读以及 CEP 与 CES、CiliumIdentity 的关系你就拥有了一套基于 Kubernetes API 的、跨节点统一视角的 Cilium 网络与安全排障工具箱。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考