当前位置: 首页 > java >正文

k8s-NetworkPolicy

在 Kubernetes 中,NetworkPolicy 是一种资源对象,用于定义 Pod 之间的网络通信策略。它允许你控制哪些 Pod 可以相互通信,以及如何通信。通过使用 NetworkPolicy,可以实现更细粒度的网络访问控制,增强集群的安全性。
1.NetworkPolicy 的作用
NetworkPolicy 主要用于以下场景:
限制 Pod 之间的通信:指定哪些 Pod 可以相互通信,哪些不能通信。
控制入站和出站流量:定义哪些流量可以进入 Pod,哪些流量可以从 Pod 发出。
基于标签的策略:通过 Pod 的标签选择器来定义策略,使得策略的管理更加灵活。

2.NetworkPolicy 的工作原理
NetworkPolicy 本身并不直接实现网络策略,而是依赖于支持网络策略的网络插件(如 Calico、Cilium、Weave 等)。这些插件会根据 NetworkPolicy 的定义,动态地配置网络规则,从而实现流量的控制。

3.NetworkPolicy 的基本配置
NetworkPolicy 的配置文件是一个 YAML 文件,定义了策略的规则。以下是一个简单的例子:

apiVersion: networking.k8s.io/v1   # 指定API版本
kind: NetworkPolicy				   # 指定资源类型为 NetworkPolicy。
metadata:						   # 定义了策略的名称和命名空间。name: allow-specific-podsnamespace: default
spec:podSelector:    # 定义了哪些 Pod 受此策略影响。在这个例子中,所有带有 role: frontend 标签的 Pod 会受到此策略的限制。matchLabels:role: frontendpolicyTypes:  # 定义了策略的类型,可以是 Ingress(入站流量)、Egress(出站流量)或两者。- Ingress- Egressingress:   # 定义了允许进入 Pod 的流量规则。在这个例子中,只有带有 role: backend 标签的 Pod 可以向带有 role: frontend 标签的 Pod 发送流量。- from:- podSelector:matchLabels:role: backendegress: # 定义了允许从 Pod 发出的流量规则。在这个例子中,带有 role: frontend 标签的 Pod 只能向带有 role: backend 标签的 Pod 发送流量。- to:- podSelector:matchLabels:role: backend

4.NetworkPolicy 的主要字段
podSelector:选择受此策略影响的 Pod。如果没有指定,则默认选择命名空间中的所有 Pod。
policyTypes:定义策略的类型,可以是 Ingress、Egress 或两者。
ingress:定义入站流量的规则。
from:定义允许流量的来源。
podSelector:基于 Pod 的标签选择器。
namespaceSelector:基于命名空间的标签选择器。
ipBlock:基于 IP 范围。
egress:定义出站流量的规则。
to:定义允许流量的目的地。
podSelector:基于 Pod 的标签选择器。
namespaceSelector:基于命名空间的标签选择器。
ipBlock:基于 IP 范围。
ports:定义允许的端口和协议。如果没有指定,则默认允许所有端口。

5.示例 限制 Pod 之间的通信

假设我们有两个服务:
frontend:运行前端应用,带有标签 role: frontend。
backend:运行后端应用,带有标签 role: backend。

我们希望:
frontend 只能从 backend 接收流量。
frontend 只能向 backend 发送流量。

创建 Pod

apiVersion: v1
kind: Pod
metadata:name: frontendlabels:role: frontend
spec:containers:- name: frontendimage: my-frontend-image
---
apiVersion: v1
kind: Pod
metadata:name: backendlabels:role: backend
spec:containers:- name: backendimage: my-backend-image

创建 NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-specific-podsnamespace: default
spec:podSelector:matchLabels:role: frontendpolicyTypes:- Ingress- Egressingress:- from:- podSelector:matchLabels:role: backendegress:- to:- podSelector:matchLabels:role: backend

6.注意事项
默认策略:如果没有定义任何 NetworkPolicy,则默认允许所有 Pod 之间的通信。
网络插件支持:NetworkPolicy 的实现依赖于网络插件。确保你的 Kubernetes 集群使用了支持 NetworkPolicy 的网络插件(如 Calico、Cilium 等)。
命名空间隔离:NetworkPolicy 仅在定义它的命名空间内生效。如果需要跨命名空间的策略,需要使用 namespaceSelector。

7.示例:限制外部流量
假设我们希望限制外部流量只能访问特定的 Pod,可以使用以下 NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-external-trafficnamespace: default
spec:podSelector:matchLabels:role: frontendpolicyTypes:- Ingressingress:- from:- ipBlock:cidr: 192.168.0.0/16

在这个例子中,只有来自 192.168.0.0/16 网段的外部流量可以访问带有 role: frontend 标签的 Pod。

8.示例:限制特定端口
假设我们希望限制 Pod 只能通过特定端口通信,可以使用以下 NetworkPolicy:

apiVersion: networking.k8s.io/v1  # 指定了 Kubernetes API 的版本
kind: NetworkPolicy			# :指定了资源类型
metadata:name: allow-specific-ports	# 定义了这个网络策略的名称namespace: default		# 定义了这个网络策略所在的命名空间
spec:podSelector:	# 定义了哪些 Pod 受此策略影响matchLabels:role: frontendpolicyTypes:	# :定义了策略的类型- Ingress- Egressingress:	# 定义了入站流量的规则。- from:	# 定义了允许流量的来源。- podSelector:	# 指定了流量来源的 Pod。这里通过 matchLabels 指定了带有 role: backend 标签的 Pod。matchLabels:role: backendports:	# 定义了允许的端口和协议。- protocol: TCP	# 指定了协议类型,这里是 TCP。port: 80	# 指定了端口号,这里是 80。# 解释:这个规则表示:只有带有 role: backend 标签的 Pod 可以通过 TCP 端口 80 向带有 role: frontend 标签的 Pod 发送流量。egress: # 定义了出站流量的规则。- to:	# 定义了允许流量的目的地。- podSelector:	# 指定了流量目的地的 Pod。这里通过 matchLabels 指定了带有 role: backend 标签的 Pod。matchLabels:role: backendports: # 定义了允许的端口和协议。- protocol: TCP # 指定了协议类型,这里是 TCP。port: 80 # 指定了端口号,这里是 80。
# 这个规则表示:带有 role: frontend 标签的 Pod 只能通过 TCP 端口 80 向带有 role: backend 标签的 Pod 发送流量。

在这个例子中,带有 role: frontend 标签的 Pod 只能通过 TCP 端口 80 与带有 role: backend 标签的 Pod 通信。

总结
NetworkPolicy 是 Kubernetes 中用于控制 Pod 之间网络通信的强大工具。通过合理配置 NetworkPolicy,可以实现细粒度的网络访问控制,增强集群的安全性。

http://www.xdnf.cn/news/7846.html

相关文章:

  • Android Handler/Looper线程管理实战攻略:从零到企业级开发
  • Android车载应用开发:Kotlin与Automotive OS深度实践
  • 【VLNs篇】02:NavGPT-在视觉与语言导航中使用大型语言模型进行显式推理
  • 初识GPU加速:如何利用GPU提升AI训练效率
  • 数据直观分析与可视化
  • 如何应对kaggle离线安装环境?
  • 工具环境与系统部署
  • SQL 多表关联与分组聚合:解密答题正确率分析
  • 项目交付标准不明确,如何确保验收顺利
  • HarmonyOS NEXT应用开发实战:玩鸿蒙App客户端开发
  • 网站制作公司哪家强?(2025最新版)
  • Go语言中new与make的深度解析
  • EasyRTC嵌入式音视频通信SDK一对一音视频通信,打造远程办公/医疗/教育等场景解决方案
  • 关于sql 查询性能优化的小经验
  • 【Vue3】一文学会动态路由和编程式路由的使用
  • 前端excel表格解析为json,并模仿excel显示
  • Flink 核心概念解析:流数据、并行处理与状态
  • Flink-Yarn运行模式
  • Java异常处理全解析:从基础到自定义
  • COMPUTEX 2025 | 广和通率先发布基于MediaTek T930 平台的5G模组FG390
  • 集星云推“碰一碰源码”开发思路解析
  • 【神经网络与深度学习】流模型的通俗易懂的原理
  • 鸿蒙开发——8.wrapBuilder 封装全局@Builder的高阶用法
  • 离线服务器Python环境配置指南
  • LangChain入门
  • 专业 YouTube SEO 方案:打造高排名视频的关键步骤
  • 【容易坑】mybatis中使用if标签比较两个字符串是否相等
  • SpringBoot微服务编写Dockerfile流程及问题汇总
  • Burp Suite返回中文乱码?
  • 使用 Spring AI Alibaba 集成阿里云百炼大模型应用