网络策略（NetworkPolicy）
NetworkPolicy（网络策略）是集群内部（东西向）流量的访问控制：指定一批 Pod（容器组），然后声明它们允许哪些入站（Ingress）与出站（Egress）流量。策略采用白名单模型——命中策略的 Pod 在某方向上的流量默认全部拒绝，只有规则中显式放行的才允许，从而在微服务之间做隔离。
入站 Ingress（别人 / 外部访问我） → 出站 Egress（我去访问别人）
来源：Pod / 名称空间 / 网段 目标：Pod / 名称空间 / 网段Kuboard 中位置：服务与网络 → 网络策略（资源 networking.k8s.io/v1，名称空间级）。
生效前提：依赖 CNI 网络插件
NetworkPolicy 不是 apiserver / kubelet 强制的机制，必须由集群的 CNI 网络插件（Container Network Interface）实现，例如 Calico、Cilium、Antrea、Weave Net、kube-router 等。
先确认插件支持再创建
默认的 flannel 及其他部分简化插件不实现 NetworkPolicy。若集群不支持，创建策略不会报错，但流量行为完全无变化。排查"策略不生效"时，先确认这一点。
理解两个默认状态，是看懂策略效果的前提：
| 状态 | 流量行为 |
|---|---|
| 某 Pod 未被任何策略命中 | 不做任何隔离，与任意对象互通（默认放行） |
| 某 Pod 被策略命中其入站/出站方向 | 该方向立即进入默认拒绝：只放行规则中显式允许的流量 |
入口位置
进入目标集群 → 名称空间后，点击左侧 服务与网络 → 网络策略。
列表页为 Kuboard 通用资源列表：顶部可切换集群 / 名称空间（或树形导航）、按名称搜索、勾选后批量删除；行内提供 编辑 / YAML / 删除，点击名称进入详情页。
创建网络策略
- 进入 网络策略 列表页，点击右上角 创建；
- 基本信息：填写名称（必填，名称空间内唯一）、标签、注解；
- 容器组选择器：定义这条策略作用于哪些 Pod；
- 入方向规则 / 出方向规则：按需求添加规则（可只写一个方向）；
- 点击 保存，在 预览 YAML 中确认后提交，跳转到详情页。
第一步：容器组选择器（策略管哪些 Pod）
选择器用标签匹配 Pod，只会命中本名称空间内的容器组，其它名称空间不受影响。
| 配置项 | 说明 |
|---|---|
| matchLabels | key=value 精确匹配，多行之间是"与"（AND）。照抄工作负载（如 Deployment）模板里的标签即可命中对应 Pod |
| matchExpressions | 表达式匹配，操作符 In / NotIn / Exists / DoesNotExist，适合排除或集合匹配 |
- 什么都不填：匹配本名称空间内的所有容器组（界面显示"未定义容器组选择器"字样，但语义为选中全部）；
- 填写后：只匹配标签符合的容器组。
标签从哪来
在 Deployment 等创建向导中，Kuboard 默认为 Pod 写入 app=<名称> 标签。创建策略时把同样的标签填进选择器，即可锁定这组 Pod。
第二步：填写规则（入方向 / 出方向）
两个标签页结构一致：点击 添加规则，得到一张"规则卡片"——左侧是源 / 目标（from：入站规则里的"来源"；to：出站规则里的"去向"），右侧是端口。
点击左侧 添加网段 或 添加选择器 可添加多个来源/目标；点击右侧 添加端口 添加端口条目。
- 多条规则之间是"或"（OR），规则内多个来源/目标之间也是"或"——满足任意一条即可放行；
- 某方向不添加任何规则时，策略只"隔离"（默认拒绝）而不放行任何流量。
源 / 目标：网段（IP Block）
点击 添加网段：
| 字段 | 说明 |
|---|---|
| 有效网段 | CIDR 网段，如 192.168.1.0/24、2001:db9::/64，必填 |
| 排除网段 | 在有效网段内再排除若干子网，如填 192.168.1.0/24、排除 192.168.1.64/26 |
源 / 目标：选择器（名称空间 + 容器组）
点击 添加选择器，出现一张选择器卡片，内含两个可勾选项：
| 勾选项 | 不勾选 | 勾选后 |
|---|---|---|
| 名称空间选择器 | 仅限本名称空间（界面提示"仅限于名称空间 xxx"） | 可用标签跨名称空间匹配；不填条件 = 所有名称空间 |
| 容器组选择器 | 该维度不限 | 可用标签匹配容器组；不填条件 = 所有容器组 |
- 卡片内两个选择器同时生效时是"与"（AND）：来源 = 满足名称空间选择器 且 满足容器组选择器的 Pod；
- 界面校验：两个选择器不能同时为空；
- 多个选择器卡片之间仍是"或"（OR）。
跨名称空间放行的常见诉求
"允许 payments 名称空间的 Pod 访问我"：勾选名称空间选择器，填 name=payments（Kuboard 为名称空间默认打 name=<名称> 标签），容器组选择器留空即可。
端口
| 字段 | 说明 |
|---|---|
| 协议 | TCP / UDP / SCTP |
| 端口 | 1 - 65535 |
| 端口范围（endPort） | 与端口号构成区间，如 8000 - 9000；Kubernetes 1.25 及以上版本显示，更早版本的集群界面自动隐藏 |
- 不填任何端口 = 匹配所有端口（界面提示"匹配所有端口"）；
- 填了一个或多个端口后为"仅匹配如下端口"，条目之间是"或"。
第三步：规则方向与默认拒绝（重点）
界面不单独设置 policyTypes（Ingress / Egress），由你填写了哪类规则决定：
- 只填了入方向规则 → 策略只管控入站；
- 只填了出方向规则 → 策略只管控出站；
- 两个都填 → 双向管控。
填写规则即开启该方向的"默认拒绝"
只要策略命中了某个 Pod，被填写的方向就进入默认拒绝状态——即使你只写了一条放行规则，其余未放行的流量也会被拒绝。典型事故：只配置了入站规则觉得大功告成，Pod 的出站（如访问数据库、解析 DNS）却全被切断。出站方向也要按需补充 egress 规则。
反过来，若某方向不打算隔离，对该方向不添加任何规则即可（保持该方向默认放行）。
编辑与删除
- 编辑：列表行内 编辑，复用创建表单，可随时修改选择器、规则、网段与端口；
- 删除：行内删除或勾选后批量删除，需输入对象名称确认。
- 删除后，该策略的隔离立即解除，相关 Pod 恢复为"未被策略命中"的默认放行状态。
修改策略即时生效
NetworkPolicy 由 CNI 控制器实时下发，保存/删除后无需重启任何对象，通常秒级生效。
详情页与查看"被哪些 Pod 影响"
详情页顶部为元数据信息卡与事件面板，下方三个只读标签页：容器组选择器、入方向规则、出方向规则（展示规则、网段、端口与"或"关系）。
界面不提供"受影响容器组清单"，核对方式是"选择器 → Pod 标签"对照：
- 打开策略的 容器组选择器 标签页，记下 matchLabels / matchExpressions；
- 到 容器组（Pod） 列表页，用同一组标签筛选；
- 命中的容器组即策略的作用对象——策略只影响它们，不命中的容器组不受影响。
选择器没命中 = 策略形同虚设
标签拼错、大小写不符、表达式写反都会导致选择器不命中任何 Pod，策略自然不产生任何隔离效果。创建后先在容器组列表核对一遍命中情况。
排障与验证：策略是否真的生效
验证路径（端到端）
# 1. 集群是否支持（有 ControllerRevision/CRD 或文档依据；不支持的插件需先更换）
kubectl get networkpolicy -A
# 2. 选择器是否命中：列出目标容器组标签，与策略 podSelector 对照
kubectl -n <ns> get pod -L app,tier
# 3. 查看策略当前定义（规则 / 端口 / policyTypes）
kubectl -n <ns> get networkpolicy <名称> -o yaml再通过一次真实访问验证放行与拒绝：
构造测试 Pod
# test-src.yaml：源容器组（带标签 src=probe）
apiVersion: v1
kind: Pod
metadata:
name: probe-src
namespace: <ns>
labels: { app: probe, src: "true" }
spec:
containers:
- name: nc
image: busybox
command: ["sh", "-c", "sleep 3600"]kubectl -n <ns> apply -f test-src.yaml
# 在源容器组内探测目标容器组的端口（能通 = 已放行；超时 = 被策略拒绝）
kubectl -n <ns> exec probe-src -- sh -c "echo | nc -w 2 <目标PodIP> <端口> && echo OK || echo BLOCKED"常见问题对照
| 现象 | 常见原因 |
|---|---|
| 创建策略后流量毫无变化 | CNI 插件不支持 NetworkPolicy；选择器未命中任何 Pod |
| 策略一创建，前后端互通突然全断 | 默认拒绝模型生效——规则只放行"显式允许"，其余全拒（重点检查被漏掉的 egress） |
| Pod 无法解析域名 | egress 规则未放行 kube-system 名称空间、UDP 53 端口（kube-dns / CoreDNS） |
| 放行某网段仍不通 | 端口没放行（空白端口=全放行，但填了端口则只放行这些）；协议填错（TCP 写成 UDP）；网段 CIDR 写错 |
| 跨名称空间访问仍被拒 | 名称空间选择器未勾选（默认仅限本名称空间）、或未匹配目标名称空间的标签 |
| 只想放行一条规则却"全通" | 规则内来源/端口留空 = 匹配任意，请补上具体来源与端口 |
命令行速查
kubectl -n <ns> get networkpolicy
kubectl -n <ns> describe networkpolicy <名称> # 结构与规则一目了然
kubectl -n <ns> get pod -o wide --show-labels # 对照 Pod IP 与标签策略对象本身通常不产生事件，异常更多体现在与其相关的 CNI 数据面（如 Calico 的 Felix 日志）；Kuboard 详情页的事件面板可查看对象创建/更新等资源侧事件。
相关页面
- 服务与 Ingress：四层 Service 与七层 Ingress，与 NetworkPolicy 互补（对外暴露 vs 内部隔离）
- 网关（Gateway API）：新一代流量路由 API
- 名称空间：跨名称空间策略的名称空间标签来源
- Deployment、容器组：策略选择器的标签来源，以及核对受影响的 Pod