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

news2024/9/20 18:42:58

一、需求

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.ingress 和 spec.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。

  • policyTypes: Ingress 和 Egress 表示同时控制进入和离开命名空间的流量。

  • ingress: from 字段中的 podSelector: {} 表示允许来自同一命名空间中的所有 Pod 的流量；ipBlock 表示允许来自除了 Kubernetes 内部网络 CIDR 地址范围10.243.0.0/16

  • 之外的所有 IP 地址的流量。

  • egress: to 字段中的 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

文章转载自：技术人的菜园子

原文链接：https://www.cnblogs.com/wangjiayu/p/18381458

体验地址：引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2087177.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Plik文件上传系统本地docker部署与远程访问传输文件详细操作流程

Plik文件上传系统本地docker部署与远程访问传输文件详细操作流程

文章目录 前言1. Docker部署Plik2. 本地访问Plik3. Linux安装Cpolar4. 配置Plik公网地址5. 远程访问Plik6. 固定Plik公网地址7. 固定地址访问Plik 前言 本文介绍如何使用Linux docker方式快速安装Plik并且结合Cpolar内网穿透工具实现远程访问，实现随时随地在任意设…
阅读更多...
blender4.2中安装插件的方式

blender4.2中安装插件的方式

1，安装好blender之后，打开软件，找到 编辑，---> 偏好设置， 插件---> 从磁盘安装...., 找到插件.zip格式的文件， 选择 .zip格式的文件后，点击“从磁盘安装”按钮，即可
阅读更多...
【linux003】目录操作命令篇 - cd 命令

【linux003】目录操作命令篇 - cd 命令

文章目录 1、基本用法2、常见选项3、举例4、注意事项 cd 命令在 Linux 中用于更改当前工作目录。它是“change directory”的缩写。 cd 命令本身比较简单，不具有复杂的选项和参数，但它提供了一些有用的功能。 1、基本用法 cd [目录]2、常见选项 ~&…
阅读更多...
示波器常识概述及简介

示波器常识概述及简介

1、示波器分类 DSO：数字存储示波器； MSO：混合信号示波器，将传统的 DSO 测量模拟与逻辑分析测量相结合。 2、示波器探头提供高阻抗输入的原因 示波器探头在测试点提供相对较高的输入阻抗端子功能（高电阻，低…
阅读更多...
Html 添加音效音乐音频播放和震动效果

Html 添加音效音乐音频播放和震动效果

文章目录 需求分析1.我们需要将用到的音频文件导入到我们的网页中2.赋给图片点击的方法3.编写play()方法4. wav 格式转 MP35. 添加震动效果需求 给页面添加背景音乐和震动效果 分析 点击指定点播放音乐，再次点击则停止音乐. 1.我们需要将用到的音频文件导入到我们的网页…
阅读更多...
数据库：头歌实验一关系数据库标准语言SQL

数据库：头歌实验一关系数据库标准语言SQL

一、创建数据库 本关任务： 建立数据库 任务要求： 建立demo数据库 并显示所有数据库 #代码开始 CREATE DATABASE demo; show databases;#代码结束 二、创建表 本关任务： 建立数据表 任务要求 设有一个demo数据库，包括S,P,…
阅读更多...
Android 动态性能框架 (ADPF)

Android 动态性能框架 (ADPF)

Performance Hint API | Android game development | Android Developers (google.cn) ADPF 是一组 API，可让游戏和性能密集型应用更为直接地与 Android 设备的电源和散热系统进行互动。借助这些 API，您可以监控 Android 系统上的动态行为&#xff…
阅读更多...
给Ubuntu添加硬盘之后，该如何使用

给Ubuntu添加硬盘之后，该如何使用

当你给Ubuntu系统添加了新的硬盘后，你需要按照以下步骤来识别、分区、格式化和挂载新硬盘： 1. 检查新硬盘是否被系统识别 首先确认新硬盘已经被系统识别： lsblk 2. 分区新硬盘 如果硬盘没有分区或者需要重新分区，可以使用fdis…
阅读更多...
Open3D mesh 获取网格属性

Open3D mesh 获取网格属性

目录 一、概述 二、网格属性 三、实现代码 四、实现效果 4.1原始mesh 4.2数据显示 Open3D点云算法汇总及实战案例汇总的目录地址： Open3D点云算法与点云深度学习案例汇总（长期更新）-CSDN博客 一、概述 在 Open3D 中，网格模…
阅读更多...
kubectl陈述式资源管理方式、声明式资源管理

kubectl陈述式资源管理方式、声明式资源管理

一、命令行: kubectl命令行工具 优点: 90%以上的场景都可以满足 对资源的增，删，查比较方便，对改不是很友好 缺点:命令比较冗长，复杂难记 声明方式：k8s当中的yaml文件实现资源管理----声明式 GUI:图形化工具的管理…
阅读更多...
谷歌又出三款Gemini模型

谷歌又出三款Gemini模型

每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领…
阅读更多...
uniapp、微信小程序车牌的录入的解决方案

uniapp、微信小程序车牌的录入的解决方案

结合uv-ui进行编写&#xff0c;键盘使用uv-ui的组件&#xff0c;其他由我们自己编写。 <template><div class"addCarContent"><div class"boxContent"><div class"carCodeInput" click"getIndex"><div:cl…
阅读更多...
中间件实时监控，运维难题一站解决

中间件实时监控，运维难题一站解决

中间件是介于操作系统和在其上运行的应用程序之间的软件&#xff0c;实现了分布式应用程序的通信和数据管理&#xff0c;用于协调不同的系统和组件之间的通信&#xff0c;是连接应用与底层资源之间的桥梁。因此&#xff0c;中间件的稳定与高可用对于整个业务系统的可靠性和性能…
阅读更多...
算法题：单词接龙

算法题：单词接龙

单词接龙 字典 wordList 中从单词 beginWord 到 endWord 的 转换序列 是一个按下述规格形成的序列 beginWord -> s1 -> s2 -> … -> sk&#xff1a; 每一对相邻的单词只差一个字母。 对于 1 < i < k 时&#xff0c;每个 si 都在 wordList 中。注意&#xf…
阅读更多...
倒计时1天！每日一题，零基础入门FPGA

倒计时1天！每日一题，零基础入门FPGA

近年来&#xff0c;FPGA工程师凭借着远高于传统软件开发工程师的薪酬&#xff0c;吸引了越来越多的人转行。 然而&#xff0c;入门FPGA并非易事。你需要有清晰的学习路线&#xff0c;包括它的基本组成&#xff08;如可编程逻辑块CLB、输入输出块IOB、内部连线资源等&#xff0…
阅读更多...
【单片机开发】单片机的烧录方式详解（ICP、IAP、ISP）

【单片机开发】单片机的烧录方式详解（ICP、IAP、ISP）

【前言】 在单片机开发过程中&#xff0c;程序的烧录是一个至关重要的环节。随着技术的不断演进&#xff0c;单片机烧录方式也日益多样化。本文将重点讲解单片机中三种常见的烧录方式&#xff1a;ICP&#xff08;In-Circuit Programming&#xff09;、ISP&#xff08;In-Syste…
阅读更多...
html+css+js网页设计 婚庆类型模版 12个页面

html+css+js网页设计 婚庆类型模版 12个页面

htmlcssjs网页设计 婚庆类型模版 12个页面 网页作品代码简单&#xff0c;可使用任意HTML编辑软件&#xff08;如&#xff1a;Dreamweaver、HBuilder、Vscode 、Sublime 、Webstorm、Text 、Notepad 等任意html编辑软件进行运行及修改编辑等操作&#xff09;。 获取源码 1&am…
阅读更多...
【排序算法】快速排序升级版--三路快排详解 + 实现（c语言）

【排序算法】快速排序升级版--三路快排详解 + 实现（c语言）

&#x1f31f;&#x1f31f;作者主页&#xff1a;ephemerals__ &#x1f31f;&#x1f31f;所属专栏&#xff1a;算法 目录​​​​​​​ 前言 一、三路快排的整体思路 二、三路快排的具体实现 1.测试数据、交换函数和三数取中法 2.三路快排函数 三、程序全部代码 总…
阅读更多...
vue手机端 搜索框调起带搜索键盘，点击确认自动关闭

vue手机端 搜索框调起带搜索键盘，点击确认自动关闭

效果如下图 步骤&#xff1a; 1.html,所需配置参数都在下图 <el-form :inline"true" :mode"serchFormf" class"searchForm" action"javascript:return true;"><el-form-item label"" ><el-inputsize"…
阅读更多...
Oracle DG备库应用延迟问题分析处理

Oracle DG备库应用延迟问题分析处理

1.情况说明 分享一个之前的案例&#xff0c;客户备库出现间歇性的日志应用延迟&#xff0c;延迟最高时刻需经过约50分钟左右才能将日志追平。 2.详细记录 2.1、问题发现 数据库的DG1备库出现间歇性的日志应用延迟&#xff0c;具体表现为备库apply lag延迟过高。影响到数据库的…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023