结论先行：容器环境里做东西向访问控制，卡住的环节常常不在策略本身，而在下面那层网络：容器网络默认是通的、地址随 Pod 创建销毁而变、不同网络插件的行为也不一样。可行的做法有三个动作——把管控锚点从地址换成业务身份，把执行放在 Pod 这一层，并让策略跟着编排平台一起走，而不是靠人定期补。
先看清原来的做法为什么失效
过去的内网管控建立在三个假设上：地址稳定、位置固定、边界清晰。容器把这三条同时改了。
- 地址不再是稳定的标识。Pod 重建、扩缩容、滚动发布都会带来新地址，按地址写成的白名单很快指向了不存在的对象。
- 流量不再经过固定的边界点位。同一个网段里跑着大量工作负载，域与域之间那道线，在容器里不容易对应到某台具体设备。
- 同一套环境里跑着不同的东西。物理机、虚拟机、容器往往并存，各用一套管控手段，最后没人说得清整体处于什么状态。
默认全通意味着什么
很多团队刚看清容器网络的访问关系时都会有点意外：新起的服务默认能访问同集群内的其他服务。这不是配置失误，而是默认行为。它的代价是：任何一个 Pod 出问题，它能够到的地方都比预想的多。
更麻烦的是，这些通路不体现在任何一张策略表里。过去的做法是「画区域、配策略、逐条放行」；而在默认全通的容器环境里，通路本来就都在，要做的是反过来——把该保留的留下，把其余的关掉。
把锚点从地址换成身份
既然地址会变，管控的锚点就不该是地址。可行的替代是用业务标签定义资产身份，策略绑在标签上：位置、环境、应用描述它属于哪个工作组，角色描述它在业务里的分层，比如接入层、应用层、数据层。
这样做之后有两个直接变化：地址变化不会让策略失效；新资产上线时，只要标签被正确打上，它就自动落进对应的策略范围。反过来说，这也给标签体系提出了要求——标签的来源必须可靠，靠人工维护的表撑不住长期运行。
执行端放在哪里
容器环境里的执行方式与物理机不同。常见做法是以守护进程的形式部署在集群的每个节点上，随集群一起创建，不需要改动容器网络架构，也不必逐台安装。这样做的直接好处是：策略能落到 Pod 这一层，而不是只到节点这一层。
这一层还有两个需要提前确认的点。一是集群所用的网络插件是否在适配范围内——不同插件对流量的处理方式不同，适配情况要在选型阶段确认，而不是上线之后才发现。二是执行组件自身的资源占用与升级方式，它跟着集群走，就要按集群的节奏做版本管理。
容器场景最容易漏掉的三件事
- 业务下线之后的清理。服务下线、地址回收时，指向它的策略也应当同步清掉。这一步最容易被跳过，结果是长期堆积一批指向已消失对象的规则，既占资源，也干扰后续判断。
- 扩缩容时的策略跟随。弹性是容器的常态，策略要能跟着实例增减自动调整，而不是每次变化都人工介入一遍。
- 上线前的试运行。容器业务迭代快，把策略直接切到阻断状态的风险比传统环境更高。常见的稳妥做法是先把策略下发但不阻断，只记录命中的情况，观察一段时间并与业务侧核对之后再正式生效。
边界与前提
三点需要说明。其一，是否需要在容器里做这一层控制，取决于业务重要程度与合规要求，不是所有集群都需要同等强度；如果只有少量内部服务、访问关系很简单，收敛暴露面未必划算。其二，不同容器平台与网络插件的适配程度不同，方案落地前需要先在测试环境确认，不能直接在生产上试。其三，标签体系的准确性是整套机制的前提，标签错了，策略会跟着错。深圳市奇摩计算机有限公司在为企业做东西向访问关系梳理时，通常先从标签与资产身份对齐开始，再谈策略与执行方式，避免出现「策略配得很细、对象本身就是错的」这种情况。
需要评估你的容器环境访问关系与落地方式，欢迎 预约咨询。