Calico NetworkPolicy 不支持基于 MAC 地址的匹配或流控，因其工作在 L3/L4 层，仅支持 IP、端口、协议、标签等条件，而 MAC 属于 L2 层且在 Kubernetes 网络中被剥离或重写。

Calico 的 NetworkPolicy 不支持基于 MAC 地址的匹配或流控。

这是关键前提，必须首先明确：
Kubernetes 原生 NetworkPolicy 和 Calico 扩展的 NetworkPolicy（包括 NetworkPolicy 和 GlobalNetworkPolicy）均工作在 网络层（L3）和传输层（L4），其匹配条件仅限于：

• IP 地址 / CIDR（IPv4/IPv6）
• 端口（numbered、range、named port）
• 协议（TCP/UDP/ICMP/SCTP 等）
• Pod / Namespace / ServiceAccount 标签选择器（label selector）
• HTTP 属性（仅当集成 Istio 且启用 L7 策略时）
• 网络集（NetworkSet）、FQDN（需额外启用 DNS 策略插件）

但 MAC 地址属于数据链路层（L2），在 Kubernetes 网络模型中：

• Pod 流量经 CNI 插件（如 Calico）转发时，宿主机内核通常不保留原始源 MAC（尤其跨节点通信时，ARP 封装、BGP 路由、eBPF 处理等会剥离或重写二层头）；
• NetworkPolicy 规则由 Felix（Calico agent）注入 iptables 或 eBPF 程序实现，这些机制本身不解析或匹配 MAC 字段；
• Kubernetes API 和 Calico CRD（projectcalico.org/v3）的 schema 中无 macAddress、srcMAC、dstMAC 等字段定义。

因此，无法通过任何标准 Calico NetworkPolicy 配置实现“基于容器服务 MAC 地址 + 端口”的复合策略。

---

如果你确实需要 MAC 级别的控制，可考虑以下替代路径（非 NetworkPolicy 范畴）

• 宿主机层面干预（不推荐用于生产）
  在节点上手动配置 ebtables 或 iptables 链（如 FORWARD 或 OUTPUT），匹配物理网卡入向/出向帧的源/目的 MAC。但该方式：

  • 绕过 Kubernetes 控制平面，不可审计、不可版本化、无法与 Pod 生命周期联动；
  • 容器重启、IP 变更、节点漂移后规则失效；
  • 不适用于 Calico 的 IPIP/BGP/eBPF 模式下封装流量（MAC 已被覆盖）。

• 使用 eBPF 自定义程序（高门槛）
  借助 cilium（非 Calico）或自研 eBPF 程序，在 tc 或 xdp 层解析以太网头并做过滤。但：

  • Calico 当前（v3.27+）虽支持 eBPF 数据面，但策略引擎仍不暴露 MAC 匹配能力；
  • 此类开发需深入内核网络栈，维护成本极高，且破坏声明式运维原则。

• 业务层标识替代（推荐实践）
  若目标是“识别并控制某类特定容器实例”，应改用上层可管理的标识：

  • 为该容器 Pod 打唯一 label（如 app=payment-gateway, instance-id=vm-abc123）；
  • 结合端口与协议，在 NetworkPolicy 中精确放行/拒绝：

    apiVersion: projectcalico.org/v3
    kind: NetworkPolicy
    metadata:
      name: restrict-payment-port
      namespace: prod
    spec:
      podSelector:
        matchLabels:
          app: payment-gateway
      ingress:
      - action: Allow
        protocol: TCP
        source:
          namespaceSelector:
            matchLabels:
              team: finance
        destination:
          ports:
          - number: 8080
      - action: Deny  # 显式拒绝其他来源
        protocol: TCP
        destination:
          ports:
          - number: 8080

• 结合网络可观测性工具定位异常 MAC（排查用途）
  使用 calicoctl ipam show + kubectl get pods -o wide 关联 IP-MAC（仅限本地 ARP 表），再配合 tcpdump 或 calico-felix 日志分析异常流量源——但这属于事后诊断，不能用于实时流控。

---

小结

• Calico NetworkPolicy 天然不支持 MAC 地址匹配，这不是配置问题，而是设计边界；
• 所有“MAC + 端口”类需求，本质应归因于标识粒度不足，正确解法是用标签、ServiceAccount、命名空间或 Istio Sidecar 注入的 mTLS 身份替代硬件地址；
• 若强制要求 L2 控制，说明架构可能偏离云原生网络模型，建议重新评估网络分层职责（例如是否应在 SDN 交换机或物理防火墙侧统一管控）。

不复杂但容易忽略：网络策略的生命力，来自它与 Kubernetes 对象模型的一致性；越试图突破这个边界，运维负担就越重。