首页 星云 工具 资源 星选 资讯 热门工具
:

PDF转图片 完全免费 小红书视频下载 无水印 抖音视频下载 无水印 数字星空

k8s-使用Network Policies实现网络隔离

编程知识
2024年08月27日 14:41

一、需求

Kubernetes 的命名空间主要用于组织和隔离资源,但默认情况下,不同命名空间中的 Pod 之间是可以相互通信的。为了实现更严格的网络隔离,同一套k8s需要根据不同的命名空间进行网络环境隔离,例如开发(dev01)测试(test01)环境。Network Policies 是 Kubernetes 提供的一种机制,用于控制 Pod 间的网络流量。你可以为每个命名空间定义 Network Policies 来限制 Pod 之间的通信。

二、相关解释
  • spec.PodSelector

它是pod选择器,基于标签选择与Network Policy处于同一namespace下的pod,如果pod被选中,则对其应用Network Policy中定义的规则。此为可选字段,当没有此字段时,表示选中所有pod。

  • spec.PolicyTypes

Network Policy定义的规则可以分成两种,一种是入pod的Ingress规则,一种是出pod的Egress规则。本字段可以看作是一个开关,如果其中包含Ingress,则Ingress部分定义的规则生效,如果是Egress则Egress部分定义的规则生效,如果都包含则全部生效。当然此字段也可选,如果没有指定的话,则默认Ingress生效,如果Egress部分有定义的话,Egress才生效。怎么理解这句话,下文会提到,没有明确定义Ingress、Egress部分,它也是一种规则,默认规则而非没有规则。

  • spec.ingress与spec.egress

spec.ingressspec.egress 字段分别用于定义允许进入 Pod 的流量规则和允许离开 Pod 的流量规则。下面详细解释这两个字段的结构和包含的子项。

spec.ingress 结构

spec:
  ingress:
  - from:
    - podSelector:
        matchLabels: {} # 选择具有特定标签的 Pod
    - namespaceSelector:
        matchLabels: {} # 选择具有特定标签的命名空间
    - ipBlock:
        cidr: 0.0.0.0/0 # CIDR 地址范围
        except:
        - 10.0.0.0/8 # 排除的 CIDR 地址范围
  - ports:
    - protocol: TCP # 协议类型
      port: 80 # 具体端口
      endPort: 8080 # 如果是端口范围,则需要指定结束端口

spec.egress 结构

spec:
  egress:
  - to:
    - podSelector:
        matchLabels: {} # 选择具有特定标签的 Pod
    - namespaceSelector:
        matchLabels: {} # 选择具有特定标签的命名空间
    - ipBlock:
        cidr: 0.0.0.0/0 # CIDR 地址范围
        except:
        - 10.0.0.0/8 # 排除的 CIDR 地址范围
  - ports:
    - protocol: TCP # 协议类型
      port: 80 # 具体端口
      endPort: 8080 # 如果是端口范围,则需要指定结束端口

示例

假设你有一个 NetworkPolicy,它允许 Pod 接收来自 CIDR 地址范围 192.168.1.0/24 的流量,并允许 Pod 发送流量到 CIDR 地址范围 10.0.0.0/8,同时只允许通过 TCP 协议的端口 80 和 443 进行通信。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-traffic
  namespace: my-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.0/24
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443
  policyTypes:
  - Ingress
  - Egress

注意事项

  • 适用性: 该 NetworkPolicy 适用于 my-namespace 命名空间中的所有 Pod。
  • 流量控制: 控制了 Ingress 和 Egress 流量。
  • CIDR 地址范围: 192.168.1.0/24 和 10.0.0.0/8 通常用于私有网络。
  • 端口控制: 只允许通过 TCP 协议的端口 80 和 443 进行通信。
三、测试规划

1、创建命名空间

2、创建pod和nodeport

3、应用策略之前测试

4、创建网络策略1-pod隔离

5、创建网络策略2-命名空间隔离

6、创建网络策略3-业务命名空间隔离

四、具体实施

1、创建命名空间

创建测试使用的3个命名空间sub1,sub2,sub3。

如果后面的网络策略使用到namespaceSelector,在创建命名空间时需要带label,也可在需要时手动添加label。

kubectl create ns sub1 --labels ns=sub1
kubectl create ns sub2 --labels ns=sub2
kubectl create ns sub3 --labels ns=sub2

  如果使用的是私有仓库,注意ns要创建docker-secret。

kubectl create secret docker-registry my-registry-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD -n namespace

2、创建pod和nodeport

 2.1、sub1创建sub1-pod1和sub1-pod1-nodeport,sub1-pod2;
 2.2、sub2创建sub2-pod1和sub2-pod1-nodeport,sub2-pod2;
 2.3、sub3创建sub3-pod1;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub1-pod1
  namespace: sub1
spec:
  selector:
    matchLabels:
      app: sub1pod1
  replicas: 1
  template:
    metadata:
      labels:
        app: sub1pod1
    spec:
      containers:
      - name: my-test01-01
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret

---

apiVersion: v1
kind: Service
metadata:
  name: sub1-pod1-nodeport
  namespace: sub1
spec:
  type: NodePort
  selector:
    app: sub1pod1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8103
      nodePort: 32700

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub1-pod2
  namespace: sub1
spec:
  selector:
    matchLabels:
      app: sub1pod2
  replicas: 1
  template:
    metadata:
      labels:
        app: sub1pod2
    spec:
      containers:
      - name: my-test01-02
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret
	
---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub2-pod1
  namespace: sub2
spec:
  selector:
    matchLabels:
      app: sub2pod1
  replicas: 1
  template:
    metadata:
      labels:
        app: sub2pod1
    spec:
      containers:
      - name: my-test02-01
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret
---

apiVersion: v1
kind: Service
metadata:
  name: sub2-pod1-nodeport
  namespace: sub2
spec:
  type: NodePort
  selector:
    app: sub2pod1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8103
      nodePort: 32701

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub2-pod2
  namespace: sub2
spec:
  selector:
    matchLabels:
      app: sub2pod2
  replicas: 1
  template:
    metadata:
      labels:
        app: sub2pod2
    spec:
      containers:
      - name: my-test02-02
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub3-pod1
  namespace: sub3
spec:
  selector:
    matchLabels:
      app: sub3pod1
  replicas: 1
  template:
    metadata:
      labels:
        app: sub3pod1
    spec:
      containers:
      - name: my-test03-01
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret  

查看创建的资源

3、应用策略之前测试

在应用网络策略之前测试各pod之间、pod和外网之间是否可以通信。

sub1-pod1 ping sub1-pod2、sub2-pod1、sub3-pod1、qq.com

外部节点ping sub1-pod1-nodeport、sub2-pod1-nodeport

取k8s集群任一节点ip  10.34.106.14

 总结:通过以上测试证明未加网络策略之前pod之间,pod外网之间都是互通的。

4、创建网络策略1-pod隔离 

策略描述:在sub1中创建策略,使sub1中pod之间无法通信且和其他命名空间pod也无法通信,只能进出外网。
测试流程:
  4.1、sub1-pod1、sub1-pod2、sub2-pod1三者之间互ping不通;
  4.2、sub1-pod1、sub1-pod2可以ping通外网(包含域名),外网也能和sub1-pod1-nodeport通信;

本k8s集群pod cidr为:10.243.0.0/16

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pod-policy
  namespace: sub1
spec:
  podSelector: {}
  ingress:
    - from:
      - ipBlock:
          cidr: 0.0.0.0/0
          except:
          - 10.243.0.0/16
  egress:
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0
          except:
          - 10.243.0.0/16
  policyTypes:
  - Egress
  - Ingress

解释:

  1. podSelector{} 表示选择命名空间中的所有 Pod。
  2. ingress: 定义了进入命名空间的流量控制规则。
    • from: 表示允许来自哪些来源的流量。
    • ipBlock: 表示允许来自除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。
  3. egress: 定义了离开命名空间的流量控制规则。
    • to: 表示允许流向哪些目的地的流量。
    • ipBlock: 表示允许流向除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。
  4. policyTypes: 指定 NetworkPolicy 控制的流量类型,这里包括 Ingress 和 Egress

效果:

  • Ingress: 允许所有来源的流量,除了 CIDR 地址范围 10.243.0.0/16
  • Egress: 允许流向所有目的地的流量,除了 CIDR 地址范围 10.243.0.0/16

测试:

创建策略

 sub1-pod1  ping  sub1-pod2和sub2-pod1 (不通)

 sub2-pod1  ping  sub1-pod1和sub1-pod2(不通)

 sub1-pod1  ping  外网ip(通)

 sub1-pod1  ping  域名(不通)-- 因为域名解析服务dns在kube-system空间,而sub1屏蔽了所有空间,下面示例可解决。

外部访问sub1-pod1-nodeport(通)

取k8s集群任一节点ip  10.34.106.14

5、创建网络策略2-命名空间隔离

策略描述:在sub2中创建策略,使sub2中pod之间可以通信但和其他命名空间pod无法通信,也能进出外网。

测试流程:
  5.1、sub2-pod1和sub2-pod2之间互ping可通;
  5.2、sub2-pod1、sub2-pod2和sub3-pod1之间互ping不通;
  5.3、sub2-pod1、sub2-pod2可以ping通外网(包含域名),外网也能和sub2-pod1-nodeport通信;

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sub2
  namespace: sub2
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
    - namespaceSelector:    # 如果不想给命名空间加label,可以换成   - podSelector: {} # 允许来自同一命名空间中的所有 Pod 的流量
        matchLabels:
          ns: sub2
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
    - namespaceSelector:    # 如果不想给命名空间加label,可以换成   - podSelector: {} # 允许来自同一命名空间中的所有 Pod 的流量
        matchLabels:
          ns: sub2
  policyTypes:
  - Egress
  - Ingress

解释

  1. podSelector{} 表示选择命名空间中的所有 Pod。
  2. ingress: 定义了进入命名空间的流量控制规则。
    • from: 表示允许来自哪些来源的流量。
    • ipBlock: 表示允许来自除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。
    • namespaceSelector: 表示允许来自具有标签 ns=sub2 的命名空间中的 Pod 的流量。
    • from字段中的 podSelector: {} 表示允许来自同一命名空间中的所有 Pod 的流量。
  3. egress: 定义了离开命名空间的流量控制规则。
    • to: 表示允许流向哪些目的地的流量。
    • ipBlock: 表示允许流向除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。
    • namespaceSelector: 表示允许流向具有标签 ns=sub2 的命名空间中的 Pod 的流量。
    • to字段中的 podSelector: {} 表示允许流向同一命名空间中的所有 Pod 的流量。
  4. policyTypes: 指定 NetworkPolicy 控制的流量类型,这里包括 Ingress 和 Egress

效果

  • Ingress: 允许所有来源的流量,除了 CIDR 地址范围 10.243.0.0/16 和来自其他命名空间的流量,如果使用namespaceSelector则允许进入命名空间具有标签 ns=sub2中的pod,如果使用podSelector: {}表示允许来自同一命名空间中的所有 Pod 的流量
  • Egress: 允许流向所有目的地的流量,除了 CIDR 地址范围 10.243.0.0/16 和流向其他命名空间的流量,如果使用namespaceSelector则允许流向命名空间具有标签 ns=sub2中的pod,如果使用podSelector: {}表示允许流向同一命名空间中的所有 Pod 的流量

测试

创建策略

sub2-pod1  ping  sub2-pod2(通)

sub2-pod1  ping  sub3-pod1(不通)

sub3-pod1  ping  sub2-pod1、sub2-pod2(不通)

sub2-pod1  ping  外网ip(通)

sub2-pod1  ping  域名(不通)-- 因为域名解析服务dns在kube-system空间,而sub1屏蔽了所有空间,下面示例可解决。

外部 访问sub2-pod1-nodeport(通)

取k8s集群任一节点ip  10.34.106.14

6、创建网络策略3-业务命名空间隔离

实际应用中某些命名空间中的pod可能和其他命名空间中的pod有调用关系,还可能用到一些系统命名空间中的服务(如DNS服务),所以不能将某个命名空间完全和其他所有命名空间隔离,只需要将确定没有业务调用的命名空间隔离。

策略描述:更新第5步sub2中创建的策略,使sub2中的pod除了不能和sub3中的pod通信外,和其他所有地址都可通信。

测试流程:

  6.1、sub2-pod1和sub2-pod2互ping可通;

  6.2、sub2-pod1和kube-system命名空间中的coredns-pod之间互ping可通;

  6.3、sub2-pod1和sub3-pod1互ping不通;

  6.4、sub2-pod1可以ping通外网(域名),外网也能和sub2-pod1-nodeport通信;

由于没有直接阻止具有某个label的命名空间配置,所有只能间接通过放行具有某些labels的命名空间以达到阻止的目的。

label设置比较灵活,可根据实际情况配置,有一下几种方式可供参考:

1、可以将放行的所有命名空间配置一个统一的label,这样只需要在配置中放行具有这个label的命名空间即可;

2、也可给每个命名空间配置一个label,这样需要在配置中放行各个不同label的命名空间;

3、可以将通用的系统命名空间设置一个统一的label,给业务命名空间配置不同的label;

本例采用第2种,给所有需要放行的命名空间配置不同的label;

命名空间加label

kubectl label ns kube-system ns=kube-system
kubectl label ns kuboard ns=kuboard
kubectl label ns kube-public ns=kube-public

网络隔离配置

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ns-policy-2
  namespace: sub2
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
  - from:
    - namespaceSelector:
        matchLabels:
          ns: kube-system
  - from:
    - namespaceSelector:
        matchLabels:
          ns: kuboard
  - from:
    - namespaceSelector:
        matchLabels:
          ns: kube-public
  egress:
  - to:
    - podSelector: {}
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
  - to:
    - namespaceSelector:
        matchLabels:
          ns: kube-system
  - to:
    - namespaceSelector:
        matchLabels:
          ns: kuboard
  - to:
    - namespaceSelector:
        matchLabels:
          ns: kube-public
  policyTypes:
  - Egress
  - Ingress

解释

  • podSelector{} 表示选择命名空间中的所有 Pod。
  • policyTypesIngress 和 Egress 表示同时控制进入和离开命名空间的流量。
  • ingressfrom 字段中的 podSelector: {} 表示允许来自同一命名空间中的所有 Pod 的流量;ipBlock 表示允许来自除了 Kubernetes 内部网络 CIDR 地址范围10.243.0.0/16
    之外的所有 IP 地址的流量。
  • egressto 字段中的 podSelector: {} 表示允许流向同一命名空间中的所有 Pod 的流量;ipBlock 表示允许流向除了 Kubernetes 内部网络 CIDR 地址范围10.243.0.0/16
     之外的所有 IP 地址的流量。
  • from 和 to: 使用 namespaceSelector 允许放行具有标签 ns=kube-system、ns=kuboardns、ns=kube-public的命名空间中的 Pod 的流量,间接阻止了其他命名空间的流量。

测试

创建策略

sub2-pod1  ping  sub2-pod2(通)

sub2-pod1  ping  kube-system命名空间中的coredns-pod(通)

sub2-pod1  ping  sub3-pod1(不通)

sub2-pod1可以ping通外网、域名(通)

外部 访问sub2-pod1-nodeport(通)

取k8s集群任一节点ip  10.34.106.14

 

 

 

 

 

 

 

 

 

 

 

  

 

From:https://www.cnblogs.com/wangjiayu/p/18381458
本文地址: http://shuzixingkong.net/article/1489
0评论
提交 加载更多评论
其他文章 树莓派CM4(四):树莓派镜像替换内核
树莓派镜像替换内核 1. 为什么要替换内核 树莓派官方提供的镜像中,自带的内核版本为6.6.31 然而github上提供的内核源码为6.6.40,有些微差别 此外,后续很有可能进行内核裁剪定制,替换内核是一个无法绕开的工作 2. 获取内核源码 github地址: https://github.com
树莓派CM4(四):树莓派镜像替换内核 树莓派CM4(四):树莓派镜像替换内核 树莓派CM4(四):树莓派镜像替换内核
逻辑回归算法 0基础小白也能懂(附代码)
逻辑回归算法 0基础小白也能懂(附代码) 原文链接 啥是逻辑回归算法 逻辑回归(Logistic Regression)是一种广泛用于分类任务的统计模型,特别适用于二元分类问题。尽管名称中带有“回归”,但逻辑回归主要用于分类。逻辑回归算法包含以下几个关键部分:线性回归与分类,Sigmoid 函数与决
逻辑回归算法 0基础小白也能懂(附代码) 逻辑回归算法 0基础小白也能懂(附代码) 逻辑回归算法 0基础小白也能懂(附代码)
React 高德地图 进京证 (二)
上回书说到,躲开摄像头的基本功能实现了,但有三个核心问题: (1)速度慢 (2)距离远易失败 (3)地图限制 第一个问题:较为简单,把几千个摄像头按行政区划分好带上编号,在路线分段避让时按片儿计算,综合测试速度提升了50%。 //找到每段step途径的 let wayDistrictsCamera
React 高德地图 进京证 (二) React 高德地图 进京证 (二) React 高德地图 进京证 (二)
《数据资产管理核心技术与应用》读书笔记-第四章:数据质量的技术实现(二)
质量数据采集到的是原始的数据,由于数据质量规则众多,所以每一种规则采集到的原始数据可能都不一样,所以还需要对原始的数据做归一化处理,然后才能进行入库存储
《数据资产管理核心技术与应用》读书笔记-第四章:数据质量的技术实现(二) 《数据资产管理核心技术与应用》读书笔记-第四章:数据质量的技术实现(二) 《数据资产管理核心技术与应用》读书笔记-第四章:数据质量的技术实现(二)
OpenVino快速落地部署教程
OpenVino快速落地部署教程 Openvino是由Intel开发的专门用于优化和部署人工智能推理的半开源的工具包,主要用于对深度推理做优化。本教程适用于Yolov5-7.0,直接跑Yolov5为6FPS,使用OpenVino后为30FPS,未来将会出一系列其他模型(Paddle等)的OpenVi
安装nvm,并通过nvm安装nodejs
转载请注明出处: 1.安装nvm 打开终端,然后运行以下命令来下载并安装nvm: curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash 或者使用wget: wget -qO- https://r
安装nvm,并通过nvm安装nodejs 安装nvm,并通过nvm安装nodejs 安装nvm,并通过nvm安装nodejs
压缩流使用
压缩流 场景:需要将一些数据,以及这些数据关联的附件压缩下载,数据导出为一个Excel,附件导出到一个文件夹中 这里使用easyexcel 导出excel 从华为云 obs 下载附件 并交给浏览器 public void downloadAllEliminate(HttpServletRespons
压缩流使用
Modbus ASCII 获取数据
根据银河高低温试验箱协议读取数据 1.协议内容 8.1:通讯协议介绍 8.1.5 通讯设置 本通讯协议使用异步串行通讯方式,1 个起始位、8 个数据位、2 个停止 位、无奇偶校验数据通讯格式,其中数据位8 位,第1 位为最高位(MSB),第8 位为最低位(LSB)。 8.1.6 数据格式 通讯采用直
Modbus ASCII 获取数据 Modbus ASCII 获取数据