1. 前言为什么服务发现和网络策略是K8s运维的两道必答题无论你是刚把第一个Pod跑起来还是已经在生产环境里折腾了大半年Kubernetes的服务发现和网络策略一定都绕不开。简单说服务发现解决的是“流量到底该打到哪个Pod上”的问题而网络策略解决的是“哪些流量允许通过”的问题。这两个点看似基础但真的到了排障和优化阶段很多人都会栽跟头。我见过太多兄弟Deployment写得很溜Pod也跑得欢但一说到Service的类型怎么选、kube-proxy的iptables和ipvs模式有什么差别、NetworkPolicy该怎么设计才能不误伤业务流量就开始含糊了。这篇内容我打算用一套完整的实操来把这些事情讲透先从一个最常用的nginx部署入手把Service的服务发现机制逐步拆开再把NetworkPolicy的规则设计、命名空间隔离、以及常见的坑逐个讲明白。中间会穿插我自己踩过的坑和复盘包括为什么DNS解析偶尔会延迟、为什么NodePort端口被人乱改之后流量就断了、为什么默认拒绝规则一开整个集群都“瘫痪”之类的问题。这些内容适合正在维护K8s集群的运维和开发同学也适合那些刚接触K8s、想系统理解网络模型的人。只要你手头有一套能跑的K8s环境跟着实操走一遍收获会非常直接。2. 整体设计与思路拆解先把服务发现和网络策略的底层逻辑搞清楚2.1 服务发现到底在解决什么问题K8s里的Pod是“朝生暮死”的Deployment滚动更新、故障重启、扩缩容都会让Pod的IP不断变化。如果我们的业务代码直接写死Pod IP去访问某个服务那这个服务一重启调用方就得跟着改配置这在动态环境里根本没法玩。服务的出现就是为了给一组Pod提供一个稳定的“入口”这个入口的IPClusterIP和域名不会因为Pod的重启而变化。从使用者的视角来看服务发现最直观的体现就是DNS。K8s集群里通常跑着一个CoreDNS它会动态监听Service和Pod的变化自动生成对应的DNS记录。你在任何Pod里直接ping一个Service的域名比如nginx-svc.default.svc.cluster.local就能拿到对应的ClusterIP。这个过程完全自动化不需要人为干预这就是K8s服务发现最基础、也最核心的体验。但这里有个容易被忽略的点Service只是一个“虚拟”的概念它本身不处理流量真正的流量转发是由每个节点上的kube-proxy完成的。kube-proxy负责把发往ClusterIP的流量按照某种负载均衡策略转发到后端的Pod上。理解了这个链路你就能明白为什么排查“为什么Service访问不通”的时候要先去看Pod是否存在、再看Endpoints是否正常、最后再查kube-proxy的转发规则。2.2 为什么网络策略需要单独设计服务发现解决的是“找得到”的问题网络策略解决的是“能不能访问”的问题。默认情况下K8s集群里的网络是“全开放”的任意一个Pod都可以直接访问任意一个其他Pod哪怕它们在不同的命名空间里。这个特性在开发环境很舒服但在生产环境就是灾难尤其是涉及多租户、或者有合规审计要求的时候。NetworkPolicy正是用来做精细化流量管控的。它的设计逻辑和传统防火墙的ACL很相似通过选择器匹配一组Pod然后定义允许哪些来源Ingress访问允许访问哪些目的地Egress。需要注意的是NetworkPolicy的规则是“白名单机制”一旦对某个Pod应用了NetworkPolicy那么没有被明确允许的流量都会默认被拒绝。这个特性如果没搞清楚很容易把业务流量全部切断。命名空间的隔离也是网络策略设计中的一个关键考量。虽然可以使用Namespace级别的选择器来限定规则的作用范围但NetworkPolicy本身并不能单独实现命名空间之间的完整隔离——这需要结合具体的CNI插件来实现比如Calico就支持Namespace的默认拒绝策略但这已经是CNI层面的能力了和NetworkPolicy的语义有所区别。在纯K8s环境下我们一般通过在每个需要保护的命名空间中配置NetworkPolicy规则来模拟“默认拒绝、按需放行”的效果。我自己的习惯是新业务上线前先画一张流量拓扑图把服务之间的访问关系列清楚然后针对每个服务写NetworkPolicy而不是等业务跑起来之后再去补规则。因为在流量已经跑起来的情况下再收紧网络策略很容易出现“漏放行”导致的故障而且当时很难立刻定位问题。2.3 方案选型从“能不能跑”到“跑得好”搞清楚了服务发现和网络策略要解决的问题接下来就是方案选型。在服务发现层面最核心的选择是kube-proxy的工作模式是iptables还是IPVS。iptables模式最大的特点是简单、稳定所有Linux发行版默认支持但缺点是规则多了之后性能会下降具体能扛多少节点和Service取决于节点的规格和内核参数并没有一个绝对的标准。IPVS模式则是在内核层面实现了高效的负载均衡支持更多的调度算法规则数量大的时候性能更稳定但需要确认内核模块ip_vs是否存在而且某些旧版本的内核可能有兼容性问题。从生产环境的选择来看我目前更倾向于IPVS模式尤其是在Service数量超过几百个、或者有大量并发连接的情况下。但如果你是刚入门或者只是在测试环境里跑一跑iptables模式完全够用不用为了“先进”而盲目切换。在网络策略层面关键选择是CNI插件。Flannel默认不支持NetworkPolicyCanalCalico Flannel的组合和Calico可以。如果你的集群已经装了Flannel又想用NetworkPolicy那就需要评估是切换CNI还是引入额外的组件。这里给个建议如果集群规模不大规模在几十个节点以内可以平滑切换依赖Calico VXLAN模式如果集群已经跑了很久而且网络架构比较复杂那最好先在测试环境完整验证一遍再动手。我自己就在生产环境遇到过切换CNI时所有节点的网络中断的情况所以大家在做这类操作时务必先准备好回滚方案并且选择业务低峰期进行。3. 核心细节解析与实操要点从部署nginx开始一步步拆解3.1 部署一个nginx应用先让Pod跑起来我们先把最基础的nginx部署起来。这一步虽然简单但后面很多操作都要依赖它所以别跳过。创建一个deployment.yaml文件内容如下apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80这里注意一点spec.selector.matchLabels必须和spec.template.metadata.labels保持一致否则Deployment创建时会直接报错。这是K8s的“强制一致性”校验很多新手在这个地方翻过车。执行命令kubectl apply -f deployment.yaml kubectl get pods -o wide正常情况下你会看到三个nginx Pod各自分配了不同的Pod IP。我这边测试环境的输出类似NAME READY STATUS RESTARTS AGE IP NODE nginx-deployment-7c8c9b5d9c-abc12 1/1 Running 0 2m 10.244.1.5 node01 nginx-deployment-7c8c9b5d9c-def34 1/1 Running 0 2m 10.244.1.6 node01 nginx-deployment-7c8c9b5d9c-ghi56 1/1 Running 0 2m 10.244.2.7 node02如果你现在直接去访问这三个Pod IP是能拿到nginx默认欢迎页的。但这个IP不稳定——假设某个Pod发生OOM重启它的IP就可能变掉。所以我们需要用Service把它们“绑定”在一个稳定入口后面。3.2 创建Service观察服务发现的完整链路创建一个Service类型选择ClusterIP默认就是这种类型apiVersion: v1 kind: Service metadata: name: nginx-svc namespace: default spec: selector: app: nginx ports: - port: 80 targetPort: 80应用之后检查服务的状态kubectl get svc nginx-svc kubectl get endpoints nginx-svc你会看到Service分配了一个ClusterIP而Endpoints列表里恰好是我们那三个nginx Pod的IP。这就是服务发现的第一个关键机制——Endpoints控制器它会持续监听符合selector条件的Pod变化并实时更新Endpoints列表。你可以做个实验手动把Deployment的副本数缩到1再去看Endpoints会发现另外两个IP自动消失了。接下来验证DNS解析。起一个临时的测试Podkubectl run test-pod --imagebusybox --rm -it -- sh在容器里执行nslookup nginx-svc.default.svc.cluster.local正常会返回ClusterIP类似10.96.100.100。这条DNS记录由CoreDNS维护它其实就是一个部署在kube-system命名空间里的Deployment只不过它以DNS服务的形式对外提供解析能力。如果发现解析不到优先排查CoreDNS的Pod状态以及kube-dns这个Service是否存在。关于域名格式多说一句完整的域名是服务名.命名空间.svc.cluster.local。同一个Namespace里的Pod访问服务时直接写服务名nginx-svc就行跨Namespace访问时要写成nginx-svc.其它命名空间.svc.cluster.local这一点在调试时特别容易踩坑。3.3 kube-proxy的iptables和IPVS选哪个更靠谱Service创建好之后实际转发规则是靠kube-proxy写到节点上的。iptables模式下你可以在节点上查看规则iptables -t nat -L -n | grep nginx-svc输出会让你看到一个“链”里面有一串规则大多是概率权重规则用于把流量随机转发到后端PodIP。这个模式的最大问题是当Service数量很大时iptables的规则数量会爆炸式增长因为每条规则都要一条条匹配规则一多转发性能就会下降。再看IPVS模式ipvsadm -L -n | grep nginx-svcIPVS的输出则清晰得多每个Service会对应一条虚拟服务器记录下面挂着三个真实的PodIP作为后端。IPVS本身工作在内核态使用哈希表做查找性能稳定得多还支持rr、wrr、lc等负载均衡算法可控性更强。那么怎么切换呢Kubeadm部署的集群修改kube-proxy的ConfigMap即可关键参数是mode: ipvs。严格来说可以通过kubectl edit -n kube-system configmap kube-proxy修改mode字段然后在每个节点重启kube-proxy的Pod让配置生效。不过这种做法在有些版本里会被kube-proxy的DaemonSet重新覆盖所以更稳妥的方式是在部署集群时直接在kube-proxy的配置文件中写明mode: ipvs。如果是在已有集群上切换建议先在一台节点上手动测试确认IPVS模块正常再全量操作。检查节点是否支持IPVSlsmod | grep ip_vs如果没有模块需要手动加载modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh另外还要装好ipvsadm工具用来观察转发规则。3.4 服务发现的隐藏坑headless service与DNS缓存再说一个容易被忽略的场景有状态应用比如数据库集群客户端需要直接连接到具体的Pod而不是随机负载均衡。这时候就需要Headless Service。它的特征是clusterIP: None创建之后不会分配ClusterIP但DNS记录会直接返回后端每个Pod的IP地址。对于这类服务通过DNS查询可以得到全部Pod的IP列表进而由客户端自己决定与哪个节点建立连接。Headless Service在服务发现层面很有用但它打破了“Service稳定入口”的直觉。如果你在Headless Service上用普通方式去“访问服务名”会发现自己会随机连到某个Pod IP上这不是故障而是它的设计如此。另外在排查DNS相关的问题时还需要注意缓存。CoreDNS本身启动了缓存插件默认的缓存时间由DNS记录本身的TTL决定而有些业务容器内的DNS解析库比如glibc或者某些Java应用也会做自己的缓存。这就导致了一个常见但难排查的现象Service的端点发生了变化但业务访问的还是一台已经下线的Pod。如果遇到这种问题最快的排查方法是直接在受影响的容器内手动nslookup确认解析结果并结合业务日志判断是容器内缓存、还是服务端解析异常。3.5 网络策略的“默认拒绝”风险与测试方法网络策略有一个极其容易踩雷的设计对一个应用了策略的Pod来说只要规则没有显式允许某类流量这类流量就会被拒绝。这意味着如果你给一个nginx应用加上了一条只允许来自前端Pod访问的Ingress规则那么你直接去访问这个nginx Pod的IP就会不通——即使是用kubectl exec进入集群里的另一个Pod去访问也会被拒绝。因此我的建议是在正式上线网络策略之前一定先创建验证用的临时Pod分别模拟“应当允许”和“应当拒绝”的场景逐个验证规则是否符合预期然后再把策略应用到生产环境。这种从“先验证再上线”的流程能帮你避免大多数由于策略误配引起的故障。下面这条规则是给带app: nginx标签的Pod设置Ingress白名单只允许同样带app: frontend标签的Pod访问80端口apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-nginx namespace: default spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 80保存为network-policy.yaml执行kubectl apply -f network-policy.yaml验证方法kubectl run frontend-pod --imagebusybox --rm -it -- sh # 在容器内 wget -O- http://nginx-svc.default.svc.cluster.local如果规则生效这个请求是通的。再起一个不带任何标签的Pod执行同样的wget请求大概率会超时。如果你发现“不带标签竟然也通了”那就要检查CNI插件是否真的实现了NetworkPolicy的规则——在纯Flannel环境下NetworkPolicy并不会生效这算是一个冷知识。4. 实操过程与核心环节实现一步步把策略体系搭起来4.1 环境准备与合理的命名空间规划在动手之前先准备好实验环境。我个人建议使用一套至少3个节点的K8s集群1个Master 2个WorkerCNI插件选择Calico。版本不需要太激进选择一个稳定版本即可这样可以避免很多底层网络的不确定性。环境就绪后下一步是设计命名空间。不要所有服务都堆在default命名空间里这是生产环境的大忌。我一般会按照“业务线”划分命名空间比如frontend、backend、database、monitoring。这样隔离的好处是策略可以按命名空间维度去设计而不用在几百个标签里慢慢挑Pod。kubectl create namespace frontend kubectl create namespace backend kubectl create namespace database4.2 部署前端nginx并配置策略实现“谁可以访问我”在frontend命名空间里部署一个nginx服务作为整个实验的“靶子”同时还原搜索记录中“kubernetes部署nginx”这个热搜词的真实场景apiVersion: apps/v1 kind: Deployment metadata: name: nginx-frontend namespace: frontend spec: replicas: 2 selector: matchLabels: app: nginx-frontend template: metadata: labels: app: nginx-frontend spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80然后创建对应的ServiceapiVersion: v1 kind: Service metadata: name: nginx-frontend namespace: frontend spec: selector: app: nginx-frontend ports: - port: 80 targetPort: 80等Pod和Service就绪后用kubectl get svc -n frontend确认ClusterIP。接下来开始上策略。我们的目标是只允许来自backend命名空间的Pod访问这个nginx服务其余一律拒绝。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend-only namespace: frontend spec: podSelector: matchLabels: app: nginx-frontend ingress: - from: - namespaceSelector: matchLabels: name: backend ports: - protocol: TCP port: 80这里有个细节需要留意namespaceSelector匹配的是命名空间的标签而不是命名空间的名称。所以在backend命名空间创建时需要手动给它打上标签kubectl label namespace backend namebackend验证一下在backend命名空间起一个busybox Pod访问nginx-frontend.frontend.svc.cluster.local应该通然后到frontend命名空间再起一个busybox做同样的访问应该不通。4.3 默认拒绝策略保护数据库这类敏感服务对于数据库这类敏感服务光靠“只允许白名单来源”还不够因为万一漏了一条放行规则数据库就暴露在所有命名空间里了。更稳妥的做法是先用一条“空规则”把所有入站流量全部拒绝然后再追加白名单规则。这里要说明的是数据库的拒绝策略需要按业务实际情况设计如果应用Pod分散在不同命名空间往往无法简单地用一个namespaceSelector搞定。更常见的做法是给应用Pod打上统一的标签比如tier: application然后用podSelector精确匹配如果还需要允许运维跳板机访问数据库的调试端口如3306可以把运维节点所在的命名空间也作为白名单来源加进去。我在写数据库策略时一般先和开发确认访问来源再列成清单每一条都对应一条规则避免“图省事放整个网段”的做法。空策略如下apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-ingress namespace: database spec: podSelector: {} policyTypes: - Ingress这条规则匹配database命名空间里的全部Pod。Ingress列表为空等价于所有入站流量都被禁止。这有点像安全组里的“拒绝全入”。然后在它之上再创建一个允许规则apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-app-to-database namespace: database spec: podSelector: matchLabels: app: mysql ingress: - from: - podSelector: matchLabels: tier: application ports: - protocol: TCP port: 3306这段规则的含义是只有带tier: application标签的Pod才能访问带app: mysql标签的Pod的3306端口其余流量仍然保持默认拒绝。这样即使前端Pod被攻破也无法横向接触到数据库为纵深防御提供了基本前提。4.4 Egress流量让Pod只能访问指定外部地址很多团队只关注入站策略忽视了出站策略。一旦业务容器被攻破攻击者可以把它当成跳板向集群外发起任意方向的请求。如果你没有出站限制那就等于给攻击者留了一扇没锁的后门。所以建议核心业务都配上Egress规则。比如只允许Pod访问特定的DNS服务器和特定网段其余出站流量全部丢弃。下面是一条允许访问CoreDNS以及某个内部网段的Egress策略apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: restrict-egress namespace: backend spec: podSelector: matchLabels: app: backend-app policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: kube-system ports: - protocol: UDP port: 53 - to: - namespaceSelector: matchLabels: name: kube-system ports: - protocol: TCP port: 53 - to: - ipBlock: cidr: 10.88.0.0/16第二条规则用于访问内部网段你可以依据业务需要做调整。注意如果没有在Egress中放行DNS流量那么业务Pod连域名解析都会被拒绝这是一个非常容易遗漏的细节。4.5 策略验证不要凭感觉用探针说话策略写完之后凭“肉眼检查”是不够的必须实际验证。推荐方案是启动一个预置好的busyboxPod进入后逐个访问目标地址记录通断结果。有条件的话也可以使用curl工具或专用探针容器。下面是我常用的验证脚本kubectl run probe-allow -n backend --imagebusybox --rm -it -- sh # 容器内执行 wget -T 3 -O- http://nginx-frontend.frontend.svc.cluster.local如果有“允许但不通”的情况优先检查Service是否正常Endpoints是否指向正确Pod。NetworkPolicy的selector是否正确匹配了目标Pod。CNI插件是否实现了NetworkPolicy。是否有其它更高优先级或叠加的NetworkPolicy做了限制。网络策略的匹配逻辑是“多条规则取并集”即只要有一条策略允许那么对应的流量就是放行的。你在设计规则时要特别留意策略之间的叠加关系避免出现“看起来是拒绝了实际被另一条规则放行”的情况。5. 常见问题与排查技巧实录现场推进时的“避坑”笔记5.1 问题一CoreDNS解析偶尔失败但过一会自己恢复现象业务容器访问服务名偶尔报connection refused或server misbehaving过几分钟自动恢复。排查发现CoreDNS的Pod有重启记录通常是内存压力导致Pod被杀或者DNS解析超时。建议给CoreDNS设置足够的资源限制避免被节点驱逐同时保证CoreDNS至少有2个副本并配置反亲和或拓扑分布约束避免所有副本落在同一个节点上。另外检查集群的kube-dnsService是否能被正常访问可以使用kubectl get svc -n kube-system kube-dns进行确认。5.2 问题二创建了Service但Endpoints一直为空现象kubectl get endpoints nginx-svc输出结果中ENDPOINTS一列为空。排查顺序先看Pod是否存在、状态是否为Running再确认Pod的标签和Service的selector完全一致接着确认Pod的containerPort和Service的targetPort是否能对得上。如果这三处都没问题就检查是不是ResourceQuota或者网络策略干扰了Pod的创建导致它一直起不来。5.3 问题三IPVS模式切换后Service随机访问不通现象从iptables切到IPVS后某些Service出现间歇性不通。排查思路先确认节点上IPVS模块加载是否完整。没有加载ip_vs_rr之类的调度模块IPVS就找不到对应的调度算法可能会回退到错误状态。其次检查有没有漏掉安装ipvsadm导致你根本看不到规则。另外如果集群里同时存在一些老的iptables规则残留例如之前手动加过NAT规则也可能干扰流量转发。处理办法是切换模式后按节点逐个清空并重建kube-proxy规则再验证流量。5.4 问题四标签选择器写错NetworkPolicy没生效这个问题的隐蔽性很强。比如你把NetworkPolicy写在database命名空间但podSelector写的标签却来自frontend命名空间那么策略虽然创建成功但实际上没有匹配到任何需要保护的Pod。而且更气人的是你可能对这个错误毫无察觉因为K8s不会在创建NetworkPolicy时给你任何警告。所以写策略前记得先确认目标Pod的标签直接kubectl get pods -n database --show-labels5.5 问题五网络策略导致健康检查失败这是我在生产环境踩过最痛的一次给某个应用加了“默认拒绝入站”策略ClusterIP服务里的健康检查探针kubelet发起的liveness探针也被拦了结果Pod不断被杀重启整条业务链跟着雪崩。注意kubelet的探测请求来源在某些CNI实现下可能无法被常规的podSelector规则正确匹配因为kubelet不在Pod网络中因此你在设计策略时要么放行来自节点网段的流量要么对健康检查所在的端口设置宽松规则的通道。具体实现取决于CNI的行为但务必在测试环境模拟一下健康检查场景确认加了策略后Pod不会被误杀。6. 最佳实践与性能优化建议6.1 服务发现层面的优化如果你的集群Service数量很多或者节点上的Pod经常频繁扩缩容那么IPVS是比iptables更合适的选择。但是IPVS也并非没有开销它需要维护虚拟服务器和真实服务器之间的映射关系规则数量极大时对内存和CPU也有消耗。建议定期用ipvsadm -L -n检查规则条数出现不正常的条目增多时及时清理。DNS层面CoreDNS的副本数不要低于2并且要监控它的延迟和错误率。业务侧如果对DNS请求量很敏感可以考虑在CoreDNS配置缓存参数或是在不影响正确性的前提下让业务代码复用长连接降低DNS QPS。6.2 网络策略层面的运维习惯把NetworkPolicy当代码来管理而不是靠“手打kubectl”维生。所有策略文件都放到Git仓库里变更走评审。这样每次改动都有迹可循出问题可以快速git diff定位。在CI/CD流水线里加上策略校验的环节用kubectl diff检查变更范围避免不小心影响到别的应用。给每个命名空间都设计“默认拒绝所有入口流量”的策略除非业务明确不需要。在K8s集群内实现“零信任”的流量安全模型这是一个非常值得投入的习惯。6.3 监控与告警提前发现问题而不是事后救火网络策略的故障影响范围通常很广而且排查难度大。建议把网络策略的监控纳入现有Prometheus体系。比较实用的做法在集群内运行一个探针组件定时从多个命名空间发起“期望可通”和“期望不可通”的探测并把结果暴露成Metrics由Prometheus采集后在告警规则里对“期望通但实际不通”以及“期望不通但实际通了”这两种情况都进行告警。前者说明策略误伤了业务后者说明策略限制被绕过两种情况都需要及时介入。这里说一下我在实操中的体会网络策略的监控告警重要性不亚于节点的CPU和内存。原因很简单节点的资源指标异常往往会在几分钟内被容量监控捕获但网络策略的误配经常要在业务方反馈“服务时好时坏”之后才能被发现有时候甚至隔了几天才被注意到那时候定位问题的成本已经很高了。所以哪怕初期只做一个最简单的连通性探测也建议优先安排上。6.4 性能测试验证策略没拖慢业务最后再聊聊性能这也是我常被问到的问题“加了NetworkPolicy之后流量性能会不会变差”答案取决于CNI的实现方式。Calico在Linux内核的iptables或eBPF数据路径上实现策略如果开启eBPF模式性能损失很小如果使用老旧的iptables实现在长连接场景下的损耗相对有限但在高并发短连接场景下会有明显增加。建议做法是在上线前做一次A/B性能对比测试打一些真实流量观察加了NetworkPolicy前后的延迟和吞吐变化再决定是否需要对数据路径进行优化。7. 写在最后的经验之谈做K8s网络优化这件事说白了就是不断在“可用性”和“安全性”之间找平衡。服务发现解决的是“找得到”网络策略解决的是“进得来、出得去”两者配合好了业务才能跑得又稳又安全。我在实际作业中最深的体会是不要追求一次把所有策略配齐而是先用最简单的默认拒绝策略保护核心敏感服务再逐步补齐业务所需的放行规则。这个节奏能让风险可控也能避免“一把梭”之后产生的雪崩式故障。最后再分享一个亲测有效的技巧每一条NetworkPolicy都加上明确的前缀比如allow-和deny-并且把对应的业务线名称写进去。管理大量的策略之后你会感谢这个看似微小的命名习惯。在做策略review的时候看着命名就能大概知道策略意图排查效率在那时就会完全不同。希望这篇内容能帮到你如果你在实操中也踩了别的坑欢迎和大家交流讨论。