默认拒绝会挡住入口
给业务命名空间加默认拒绝策略后，不仅东西向流量被拦，从入口控制器到后端的请求也会被拦住。典型表现是入口返回服务不可用，而应用日志里一条请求记录都没有。放行入口控制器是收缩网络范围后必须同步完成的一步。
基本信息
| 所属接口组 | networking.k8s.io/v1 |
|---|---|
| 关键前提 | 网络插件必须支持策略执行 |
| 放行对象 | 入口控制器所在命名空间 |
| 依赖标签 | 命名空间的名称标签通常由系统自动维护 |
| 验证方法 | 从入口发起请求并确认后端日志出现记录 |
典型使用场景
- 业务命名空间启用默认拒绝后补齐入口放行规则
- 入口控制器与业务不在同一命名空间，需要跨命名空间放行
- 新增第二个入口控制器后同步新增放行来源
- 排查入口返回不可用：先确认是不是策略挡住了回源流量
- 收紧策略时复核入口相关放行是否仍然完整
放行入口控制器
放行入口控制器
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-controller
namespace: prod
spec:
podSelector:
matchLabels:
app: web # 只作用于目标业务
policyTypes: ["Ingress"]
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ingress-nginx # 按命名空间标签放行
ports:
- protocol: TCP
port: 8080 # 后端容器实际监听端口验证放行结果
验证放行结果
kubectl get networkpolicy -n prod # 现有策略
kubectl describe networkpolicy allow-ingress-controller -n prod
curl -s -o /dev/null -w '%{http_code}\n' http://app.example.com/health # 从入口验证
kubectl logs -n prod deploy/web --tail=20 # 后端是否出现请求记录现象与成因
| 现象 | 可能原因 | 确认方式 |
|---|---|---|
| 入口返回不可用 | 回源流量被策略拦截 | 后端日志无请求记录 |
| 部分版本正常部分异常 | 放行规则未覆盖新端口 | 核对策略中的端口号 |
| 放行后仍不通 | 插件不执行策略或标签不匹配 | 做拒绝场景对照验证 |
| 入口更换后失效 | 放行来源仍是旧命名空间 | 更新命名空间标签选择条件 |
按命名空间标签放行比按固定地址稳：入口控制器的副本地址会随重建与扩缩容变化，而命名空间名称标签由系统维护，引用更可靠。
不要用节点网段的方式放行入口：控制器回源使用的是它自己那组 Pod 地址，与节点网段往往不匹配，规则看起来合理却完全不生效。