pod结构

在这里插入图片描述

Pause容器

Pause容器是每个Pod都会有的一个根容器，它的作用有两个

  • 可以以它为根据，评估整个pod的健康状态
  • 可以在根容器上设置IP地址，其他容器都以此IP（Pod IP），以实现Pod内部的网络通信，
    这里是Pod内部的通讯，Pod之间的通讯采用虚拟二层网络技术来实现，我们当前环境用的是Flannel

pod配置

apiVersion: v1 #必选，版本号，例如v1
king: Pod         #必选，资源类型，例如Pod
metadata:name: string  #必选，pod名称namespace: string #pod所属的命名空间，默认为"default"labels:- name: string
spec:  #必选，pod中容器的详细定义containers:  #必选，pod中容器列表- name: string   #必选，容器名称image: string  #必选，容器镜像名称imagePullPolicy: [Always|Never|IfNotPresent] #获取镜像的策略command: [string]  #容器的启动命令列表，如不指定，使用打包时使用的启动命令args: [string]  #容器的启动命令参数列表workingDir: string  #容器的工作目录volumeMounts: #挂载到容器内部的存储卷配置- name: string  #引用pod定义的共享数据卷的名称，需用volumes[]部分定义的卷名mountPath: string  #存储卷在容器内mount的绝对路径，应少于512字符readOnly: boolean  #是否为只读模式ports:  3需要暴露的端口库号列表- name: string  #端口的名称containerPort: int  #容器需要监听的端口号hostPort: int  #容器所在主机需要监听的端口号，默认与Container相同protocol: string  #端口协议，支持TCP和UDP，默认TCP    env:  #容器运行前需要设置的环境变量列表    - name: string  #环境变量名称      value: string  #环境变量的值    resources:  #资源限制和请求的设置      limits: #资源限制的设置......

pod的资源配置非常繁多，因此要一个一个记住是不现实的

所以k8s提供了能够查看每种资源的配置项的命令

kubectl explain 资源类型      #查看某种资源可以配置的一级属性
kubectl explain 资源类型.属性   #查看属性的子属性

查看pod资源的metadata的子属性

kubectl explain pod.metadata

在k8s中所有资源的一级属性都是一样的，主要包含5部分：

  • apiVersion 版本，由k8s内部定义，版本号可以用 kubectl api-versions查询到
  • kind 类型，由k8s内部定义，可以用 kubectl api-resources查询到
  • metadata 元数据，主要是资源标识和说明，常用的有name，namespace，labels等
  • spec 描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
  • status 状态信息，里面的内容不需要定义，由k8s自动生成

在上面的属性中，spect是接下来研究的重点，继续看下它的常见子属性：

  • containers <[]Object> 容器列表，用于定义容器的详细信息
  • nodeName 根据nodename的值将pod调度到指定的Node节点上
  • nodeSelector <map[]> 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的node上
  • hostNetwork 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
  • volumes <[]Object> 存储卷，用于定义Pod上面挂载的存储信息
  • restartPolicy 重启策略，表示Pod在遇到故障的时候的处理策略;

pod生命周期

pod对象从创建到终止的这段时间范围被称为生命周期，它主要包含以下几个过程：

  1. pod创建过程
  2. 运行初始化容器（init container）过程
  3. 运行主容器（main container）
    • 容器启动后钩子（post start）、容器终止前钩子（pre stop）
    • 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）
  4. pod终止过程
    在这里插入图片描述

生命周期中出现的5种状态

状态值状态名称描述
  1. Pending|挂起|apiServer已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中；
  2. Running|运行中|pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成；
  3. Succeeded|成功|pod中的所有容器都已经成功终止并且不会被重启
  4. Failed|失败|所有容器都已终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态；
  5. Unknown|未知|apiServer无法正常获取到pod对象的状态信息，通常由网络通讯失败所导致；

pod创建过程

  1. 用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer
  2. apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
  3. apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动
  4. scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer
  5. node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer
  6. apiServer将接收到的pod状态信息存入etcd中

pod终止过程

  1. 用户向apiServer发送删除pod对象的命令
  2. apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead（死亡）
  3. 将pod标记为terminating（正在删除中）状态
  4. kubelet在监控到pod对象转为terminating（正在删除中）状态的同时启动pod关闭过程
  5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
  6. 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating（正在删除中）后即会以同步的方式启动执行
  7. pod对象中的容器进程收到停止信号
  8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
  9. kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见

初始化容器

Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init容器
Init 容器与普通的容器非常像，除了如下两点：

  1. Init 容器总是运行到成功完成为止
  2. 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

如果 Pod 的 Init 容器失败， Kubernetes 会不断地重启该 Pod ，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy（重启策略） 为 Never，它不会重新启动。

init容器能够做什么呢？

  1. Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
  2. Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
  3. 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
  4. Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器 可具有访问 Secrets 的权限，而应用容器不能够访问。
  5. 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前 置条件满足，Pod内的所有的应用容器会并行启动。

初始化容器配置

在spec下添加initContainers子项即可

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPinitContainers:- name: init-mysqlimage: busybox:1.3.0command: ["/bin/sh","-c","while true;do echo hello;sleep 1;done"]

钩子函数

类似spring的AOP功能，在主容器启动后和容器终止前执行一些自定义的逻辑；

  • postStart：容器创建之后执行，如果postStart钩子函数失败了会重启容器；
  • preStop：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作

钩子函数支持以下三种方式定义动作

第一种：exec命令

在容器内执行一次命令，这种方式使用比较频繁，一般都是使用这种方式作为钩子函数；

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器启动后钩子exec:command: ["/bin/bash","-c","echo postStart > /root/post.txt"]preStop:  # 主容器终止前钩子exec:command: ["/bin/bash","-c","echo postStart > /root/post.txt"]

也可以这样

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器启动后钩子exec:command: - cat- post.txtpreStop:  # 主容器终止前钩子exec:command: - cat- post.txt

第二种：tcpSocket

以下列子是在主容器启动后尝试去连接8080端口，在主容器终止前去连接8081端口

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器启动后钩子tcpSocket: port: 8080preStop:  # 主容器终止前钩子tcpSocket: port: 8081

第三种：httpGet

以下列子是在主容器启动后会去访问链接http://192.168.1.101:8080/login，在主容器终止前去访问链接http://192.168.1.101:8080/logout;

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器启动后钩子httpGet: path: /login             # Url地址port: 8080          # 端口host: 192.168.1.101 # 主机地址schema: HTTP # 支持的协议，http或httpspreStop:  # 主容器终止前钩子httpGet: path: /logout            # Url地址port: 8080          # 端口host: 192.168.1.101 # 主机地址schema: HTTP # 支持的协议，http或https

容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制，如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例“摘除”，不承担业务流量，k8s提供了两种探针来实现容器探测

  • liveness probes ： 存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器
  • readiness probes ： 就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量

liveness probes决定是否重启容器，readiness probes觉得是否将请求转发给容器

存活性探针和就绪性探针都支持三种探测方式，其实就是使用了钩子函数,

第一种 exec

在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常， 否则不正常；
仔细看看，跟上面的钩子函数差不多，钩子函数用的是lifecycle，而探针用的是livenessProbe或者readinessProbe

# 存活性探针
.....
spec:containers:- image: nginx:1.17.1name: nginx-containerlivenessProbe:   # 存活性探针initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测timeoutSeconds: 10     # 探测超时时间，默认1秒，默认1秒failureThreshold: 10   # 连续探测失败多少次才被认定为失败，默认是3，最小值是1successThreshold: 1    # 连续探测成功多少次才被认定为成功，默认是1exec:command: - cat- post.txt
......# 就绪性探针
.....
spec:containers:- image: nginx:1.17.1name: nginx-containerreadinessProbe:   # 就绪性探针initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测timeoutSeconds: 10     # 探测超时时间，默认1秒，默认1秒failureThreshold: 10   # 连续探测失败多少次才被认定为失败，默认是3，最小值是1successThreshold: 1    # 连续探测成功多少次才被认定为成功，默认是1exec:command: - cat- post.txt
......

第二种 tcpSocket

将会尝试访问容器的端口，如果能建立连接，则认为程序正常，否则不正常
仔细看看，跟上面的钩子函数差不多，钩子函数用的是lifecycle，而探针用的是livenessProbe或者readinessProbe

# 存活性探针
......
spec:containers:- image: nginx:1.17.1name: nginx-containerlivenessProbe:   # 存活性探针initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测timeoutSeconds: 10     # 探测超时时间，默认1秒，默认1秒failureThreshold: 10   # 连续探测失败多少次才被认定为失败，默认是3，最小值是1successThreshold: 1    # 连续探测成功多少次才被认定为成功，默认是1tcpSocket: port: 8080
......# 就绪性探针
......
spec:containers:- image: nginx:1.17.1name: nginx-containerreadinessProbe:  # 就绪性探针initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测timeoutSeconds: 10     # 探测超时时间，默认1秒，默认1秒failureThreshold: 10   # 连续探测失败多少次才被认定为失败，默认是3，最小值是1successThreshold: 1    # 连续探测成功多少次才被认定为成功，默认是1tcpSocket: port: 8080
......

第三种 httpGet

调用容器内web应用的url，如果返回的状态码在200 ~ 399之间，则认为程序正常，否则不正常
仔细看看，跟上面的钩子函数差不多，钩子函数用的是lifecycle，而探针用的是livenessProbe或者readinessProbe

# 存活性探针
......
spec:containers:- image: nginx:1.17.1name: nginx-container # 存活性探针livenessProbe:  initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测timeoutSeconds: 10     # 探测超时时间，默认1秒，默认1秒failureThreshold: 10   # 连续探测失败多少次才被认定为失败，默认是3，最小值是1successThreshold: 1    # 连续探测成功多少次才被认定为成功，默认是1httpGet: path: /login             # Url地址port: 8080          # 端口host: 192.168.1.101 # 主机地址schema: HTTP # 支持的协议，http或https
......# 就绪性探针
......
spec:containers:- image: nginx:1.17.1name: nginx-containerreadinessProbe:   # 就绪性探针initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测timeoutSeconds: 10     # 探测超时时间，默认1秒，默认1秒failureThreshold: 10   # 连续探测失败多少次才被认定为失败，默认是3，最小值是1successThreshold: 1    # 连续探测成功多少次才被认定为成功，默认是1httpGet: path: /login             # Url地址port: 8080          # 端口host: 192.168.1.101 # 主机地址schema: HTTP # 支持的协议，http或https
......

重启策略

存活性探针对容器进行探测时，如果出现了问题，k8s就会对容器所在的pod进行重启，这是由pod的重启策略决定的，pod的重启策略由三种

  • Always：（默认值）总是重启容器
  • OnFailure： 容器终止运行且退出码不为0时重启
  • Never ： 不论状态如何，都不重启

配置重启策略

spec:restartPolicy: Always

重启等待时间

重启策略适用pod中的所有容器，如果是第一次重启，在需要重启时将会立即重启，如果不是第一次重启，那么将会延长一段时间后重启，这是防止服务器资源都用来重启所做的一些优化，

  1. 第一次重启，立即重启
  2. 第二次重启，延长10s重启
  3. 第三次重启，延长20s重启，
  4. 第四次重启，延长40s重启
  5. 第五次重启，延长80s重启
  6. 第六次重启，延长160s重启
  7. 第七次或七次以上重启，都延长300s重启

pod调度

什么是调度

默认情况下，一个pod在哪个node节点上运行，是通过scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的；

调度规则

但是在实际使用中，我们想控制某些pod定向到达某个节点上，应该怎么做呢？其实k8s提供了四类调度规则

调度方式描述
自动调度通过scheduler组件采用相应的算法计算得出运行在哪个节点上
定向调度运行到指定的node节点上，通过NodeName、NodeSelector实现
亲和性调度跟谁关系好就调度到哪个节点上
1、nodeAffinity ：节点亲和性，调度到关系好的节点上
2、podAffinity：pod亲和性，调度到关系好的pod所在的节点上
3、PodAntAffinity：pod反清河行，调度到关系差的那个pod所在的节点上
污点（容忍）调度污点是站在node的角度上的，比如果nodeA有一个污点，大家都别来，此时nodeA会拒绝master调度过来的pod

定向调度

指的是利用在pod上声明nodeName或nodeSelector的方式将pod调度到指定的pod节点上，因为这种定向调度是强制性的，所以如果node节点不存在的话，也会向上面进行调度，只不过pod会运行失败；

定向调度-> nodeName

nodeName 是将pod强制调度到指定名称的node节点上，这种方式跳过了scheduler的调度逻辑，直接将pod调度到指定名称的节点上，配置文件内容如下

apiVersion: v1  # 版本号
kind: Pod  # 资源类型
metadata: name: pod-namenamespace: dev
spec: containers: - image: nginx:1.17.1name: nginx-containernodeName: node1  # 调度到node1节点上
定向调度 -> NodeSelector

NodeSelector是将pod调度到添加了指定label标签的node节点上，它是通过k8s的label-selector机制实现的，也就是说，在创建pod之前，会由scheduler用matchNodeSelecto调度策略进行label标签的匹配，找出目标node，然后在将pod调度到目标node；

要实验NodeSelector，首先得给node节点加上label标签

kubectl label nodes node1 nodetag=node1

配置文件内容如下

apiVersion: v1  # 版本号
kind: Pod  # 资源类型
metadata: name: pod-namenamespace: dev
spec: containers: - image: nginx:1.17.1name: nginx-containernodeSelector: nodetag: node1  # 调度到具有nodetag=node1标签的节点上

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

如若内容造成侵权/违法违规/事实不符，请联系英文站点网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Redis：缓存雪崩、穿透、击穿的技术解析和实战方案

Redis：缓存雪崩、穿透、击穿的技术解析和实战方案

&#x1f6a8; 1、简述 随着系统规模扩大&#xff0c;Redis 缓存被广泛用于数据预热、热点数据防护和高并发系统优化。然而在高并发环境中&#xff0c;缓存雪崩、穿透、击穿等问题若处理不当&#xff0c;可能导致系统雪崩式崩溃。 本文从原理、原因出发&#xff0c;结合实际项目…
阅读更多...
前端-html+CSS基础到高级(二)html基础

前端-html+CSS基础到高级(二)html基础

一、 为什么需要Web标准 浏览器差异问题&#xff1a;五大主流浏览器&#xff08;IE、Chrome、Firefox、Safari等&#xff09;使用不同渲染引擎&#xff0c;导致相同代码解析效果存在差异。为什么需要Web标准&#xff1f;不同浏览器的渲染引擎不同&#xff0c;对于相同代码解析的…
阅读更多...
前端-移动Web-day2

前端-移动Web-day2

目录 1、空间-平移 2、视距 3、空间旋转-Z轴 4、空间旋转-X轴 5、空间旋转-Y轴 6、立体呈现 7、案例-3D导航 8、空间-缩放 9、动画-体验 10、动画-实现步骤 11、animation复合属性 12、animation拆分写法 13、案例-走马灯 14、精灵动画 15、多组动画 16、案例-…
阅读更多...
力扣1116题：用C++实现多线程交替输出零、偶数、奇数

力扣1116题：用C++实现多线程交替输出零、偶数、奇数

一、题目解读 力扣1116题要求设计一个类&#xff0c;实现三个线程交替输出数字&#xff1a;一个线程输出连续的0&#xff0c;一个线程输出连续的偶数&#xff0c;另一个线程输出连续的奇数。输入参数n为总输出次数&#xff08;每个线程各输出n次&#xff09;&#xff0c;输出需…
阅读更多...
C语言（07）——原码 补码 反码 （超绝详细解释）

C语言（07）——原码 补码 反码 （超绝详细解释）

本文的内容通下面这篇文章有着紧密的联系&#xff0c;读者可以选择性阅读 C语言————二、八、十、十六进制的相互转换-CSDN博客 相关的C语言练习题和思维锻炼可以参考以下文章 C语言————练习题册&#xff08;答案版&#xff09;-CSDN博客 C语言————斐波那契数列…
阅读更多...
磁盘坏道检测工具在美国服务器硬件维护中的使用规范

磁盘坏道检测工具在美国服务器硬件维护中的使用规范

磁盘坏道检测工具在美国服务器硬件维护中的使用规范在服务器硬件维护领域&#xff0c;磁盘坏道检测工具是保障数据安全的第一道防线。本文将系统介绍美国数据中心环境下专业级磁盘诊断方案的实施标准&#xff0c;重点解析SMART检测、坏道修复算法与自动化运维流程的整合方法&am…
阅读更多...
【n8n】如何跟着AI学习n8n【03】：HTTPRequest节点、Webhook节点、SMTP节点、mysql节点

【n8n】如何跟着AI学习n8n【03】：HTTPRequest节点、Webhook节点、SMTP节点、mysql节点

前言 n8n的系统性学习&#xff0c;对各知识点地毯式学习&#x1f50d;~ 前面课程 定制n8n的AI老师&#xff0c;有AI老师制定学习大纲&#xff0c;参考之前的文档&#xff08;本系列n8n学习大纲&#xff0c;也在这里&#xff09;&#xff1a; 【n8n】如何跟着AI学习n8n_01&a…
阅读更多...
Vue 的双向数据绑定原理

Vue 的双向数据绑定原理

Vue 的双向数据绑定是通过 数据劫持 发布-订阅模式 实现的&#xff0c;具体分为以下三个关键机制&#xff1a;1. 数据劫持&#xff08;响应式系统&#xff09; Vue 使用 Object.defineProperty&#xff08;Vue 2&#xff09;或 Proxy&#xff08;Vue 3&#xff09;监听数据变化…
阅读更多...
【基于C# + HALCON的工业视觉系统开发实战】三十五、金属表面划伤检测：强反光场景解决方案

【基于C# + HALCON的工业视觉系统开发实战】三十五、金属表面划伤检测：强反光场景解决方案

摘要：针对金属表面强反光导致划伤检测准确率低的行业痛点，本文提出基于光度立体法的工业视觉检测方案。系统采用“硬件抗反光+算法重建”双策略，硬件上通过可编程分区环形光源、偏振镜头与高动态相机构建成像系统；算法上利用四方向光源序列图像重建表面法向量与高度场，实现…
阅读更多...
为什么bert是双向transformer

为什么bert是双向transformer

BERT 是双向 Transformer&#xff0c;这是它的一个核心创新点。下面我从 技术原理、与传统 Transformer 的区别、以及双向性的实际意义 来详细解释为什么 BERT 被称为“双向 Transformer”。一、什么是 BERT 的“双向”&#xff1f;在 BERT 的论文中&#xff0c;双向的原文是 &…
阅读更多...
vue中使用Canvas绘制波形图和频谱图（支持.pcm）

vue中使用Canvas绘制波形图和频谱图（支持.pcm）

实现方式一&#xff1a; vue中使用wavesurfer.js绘制波形图和频谱图 安装colorMap&#xff1a; npm install --save colormap1、单个频谱图 效果&#xff1a; 源码&#xff1a; <template><div class"spectrogram-container"><canvas ref"ca…
阅读更多...
【Python系列】Flask 应用中的主动垃圾回收

【Python系列】Flask 应用中的主动垃圾回收

博客目录一、Python 内存管理基础二、Flask 中手动触发 GC 的基本方法三、高级 GC 策略实现1. 使用装饰器进行请求级别的 GC2. 定期 GC 的实现四、Flask 特有的 GC 集成方式1. 使用 teardown_request 钩子2. 结合应用上下文管理五、智能 GC 策略六、注意事项与最佳实践七、替代…
阅读更多...
Linux和shell

Linux和shell

最快入门的方式是使用苹果系统。此外&#xff0c;累计补充学习&#xff1a;一、目录结构/bin&#xff0c;二进制文件 /boot&#xff0c;启动文件 /dev&#xff0c;设备文件 /home&#xff0c;主目录&#xff0c;一般外接包、安装包放在这里 /lib&#xff0c;库文件 /opt&#x…
阅读更多...
告别内存泄漏：你的Rust语言30天征服计划

告别内存泄漏：你的Rust语言30天征服计划

欢迎踏上Rust学习之旅&#xff01;第一周&#xff1a;奠定基础 (Week 1: Laying the Foundation)第1天&#xff1a;环境搭建与 “Hello, World!”核心概念: 安装Rust工具链 (rustup)&#xff0c;它包含了编译器rustc和包管理器Cargo。Cargo是你的好朋友&#xff0c;用于创建项目…
阅读更多...
乱删文件，电脑不能开机，怎么办

乱删文件，电脑不能开机，怎么办

相信不少朋友在清理电脑、释放空间时&#xff0c;都做过一件“后悔一整年”的事——乱删系统文件。本来只是想让电脑快点、干净点&#xff0c;结果第二天一开机&#xff1a;黑屏了、蓝屏了、无限重启了&#xff0c;甚至连桌面都见不到了&#xff01;很多用户在删文件时&#xf…
阅读更多...
ICODE SLIX2有密钥保护的物流跟踪、图书馆管理ISO15693标签读写Delphi源码

ICODE SLIX2有密钥保护的物流跟踪、图书馆管理ISO15693标签读写Delphi源码

本示例使用设备&#xff1a;https://item.taobao.com/item.htm?spma21dvs.23580594.0.0.6781645eXF3tm5&ftt&id959258149468 一、密钥认证 procedure TForm1.Button21Click(Sender: TObject); varctrlword:byte;passwordid:byte; //密钥类型status:byte; //存…
阅读更多...
核环境特种机器人设备的抗辐照芯片选型方案

核环境特种机器人设备的抗辐照芯片选型方案

摘要&#xff1a;核能作为国家能源安全的重要组成部分&#xff0c;对工业自动化设备的稳定性和可靠性提出了极高的要求。机器人设备在涉核环境下的日常巡检、设备维护、应急响应等任务中发挥着不可替代的作用。然而&#xff0c;涉核环境&#xff0c;尤其是高能粒子的辐照效应&a…
阅读更多...
Linux权限系统完全指南：从本质到安全实践

Linux权限系统完全指南：从本质到安全实践

一、权限的本质&#xff1a;Linux安全的核心逻辑在Linux的多用户环境中&#xff0c;权限系统通过三个关键维度实现资源隔离&#xff1a;用户标识 (UID)&#xff1a;系统通过数字ID识别用户&#xff0c;root用户的UID固定为0组标识 (GID)&#xff1a;用户组机制实现批量权限管理…
阅读更多...
养老院跌倒漏报率↓78%！陌讯多模态算法在智慧照护中的边缘计算优化

养老院跌倒漏报率↓78%！陌讯多模态算法在智慧照护中的边缘计算优化

​摘要​​&#xff1a; 针对养老场景中复杂光照与遮挡导致的跌倒漏报问题&#xff0c;陌讯视觉算法通过多模态融合与边缘计算优化&#xff0c;实测显示在RK3588 NPU硬件上实现​​mAP0.5达89.3%​​&#xff0c;较基线模型提升28.5%&#xff0c;功耗降低至7.2W。本文解析其动态…
阅读更多...
【通识】计算机网络

【通识】计算机网络

1. 基础概述11 2.
阅读更多...
最新文章

Copyright @ 2022~2023