【kubernetes】关于云原生之k8s集群中pod的容器资源限制和三种探针

news2024/11/18 17:37:21

目录

一、关于pod容器的资源限制

1.1资源限制的单位

CPU 资源单位

内存 资源单位 

二、关于QOS服务质量（pod的调度和驱逐有限制）

2.1QoS服务质量分类

guaranteed验证

burstable验证

besteffort验证

2.2驱逐顺序

三、关于pod容器的三种探针

3.1健康检查：又称为探针（Probe） 

3.2三种健康检查的方式

3.3实操验证

实操一：通过存活探针验证三大健康检查的方式

存活探针——exec健康检查方式

 存活探针——tcpsocket健康检查方式

​编辑 存活探针之httpget健康检查方式

实操二：验证启动探针、 就绪探针、存活探针的顺序

实操三：验证就绪探针

​编辑 实操四、验证启动和退出动作

四、总结：

三种探针

关于探针的3种探测方式

探针参数：

一、关于pod容器的资源限制

当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

当为 Pod 中的容器指定了 request 资源限制时，代表容器运行所需的最小资源量，调度器就使用该信息来决定将 Pod 调度到哪个节点上（也就是预选策略是根据requests设置的资源进行淘汰不符合要求的node节点）。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。

如果 Pod 运行所在的节点具有足够的可用资源：容器可以使用超出所设置的 request 资源量，容器不可以使用超出所设置的 limit 资源量。

如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。

总结：requests表示创建pod时预留的资源，limits表示pod能够使用资源的最大值。requests值可以被超，limits值不能超过，如果是内存使用超过limits会触发oom然后杀掉进程，如果是cpu超过limits会压缩cpu的使用率。

官网示例：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
Pod 和 容器 的资源请求和限制

spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu			//定义 cpu 的资源上限 
spec.containers[].resources.limits.memory		//定义内存的资源上限

spec.containers[].resources.limits.hugepages-<size> 
spec.containers[].resources.requests.hugepages-<size>

1.1资源限制的单位

CPU 资源单位

CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）。
Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。
Kubernetes 不允许设置精度小于 1m 的 CPU 资源。  

内存 资源单位 

内存的 request 和 limit 以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示， 或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。
如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB

PS：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 MB、GB为单位的，1GB 就是1,000,000,000Byte，而操作系统是以2进制为处理单位的，因此检查硬盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际结果要比标出的少一些。

总结：

cpu的单位可以是核个数如1.25，0.5等，可以是毫核如500m，1250m

memory的单位可以是128M或128Mi （分别是1000k=1M或1024Ki=1Mi）

二、关于QOS服务质量（pod的调度和驱逐有限制）

2.1QoS服务质量分类

  • Guaranteed：Pod 中的每个容器，包含初始化容器，必须指定内存、CPU 的 requests 和 limits，并且 requests 和 limits 要相等
  • Burstable：Pod 中至少一个容器具有内存 或 CPU requests
  • BestEffort：Pod 中的所有容器都没有指定内存 或 CPU 的 requests和 limits

guaranteed验证

只有一个容器，而且容器的req与limit设置值一致

只有1个容器，而且只设置容器的limit设置值

 有2个容器，而且容器的req与limit设置值一致

 

burstable验证

只有1个容器，而且只设置容器的requests设置值

 

 

 

besteffort验证

2.2驱逐顺序

优先级：Guaranteed > Burstable > BestEffort

  • Guaranteed (QoS) 的 Pod，其优先级最高，在其资源使用量不超过其 limits 的情况下，可以确保不被杀死
  • 在系统内存资源紧张，且集群中没有 QoS 为 Best-Effort 级别的其它 Pod 时，一旦 Burstable (QoS) 的Pod 使用的资源量超过了其 requests，这些 Pod 就容易被杀死
  • BestEffort (QoS) 的 Pod，其优先级最低，当系统内存资源紧张时，这些 Pod 底层容器中的进程是最先会被杀死的

验证内存超过limit限制  会触发oomkil杀掉容器

apiVersion: v1
kind: Pod
metadata:
  labels:
    myapp: nginx
  name: pod-demo7
spec:
  containers:
  - image: nginx:1.20
    imagePullPolicy: IfNotPresent
    name: pod-c1
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: "0.5"
        memory: "128Mi"
      limits:
        cpu: "0.5"
        memory: "128Mi"
  - image: mysql
    imagePullPolicy: IfNotPresent
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "123123"
    name: mydb
    resources:
      requests:
        cpu: "0.5"
        memory: "128Mi"
      limits:
        cpu: "0.5"
        memory: "128Mi"
  restartPolicy: Always

 

 

kubectl describe -n <命名空间> pods <资源名称>       
//查看Pod中的每个容器的资源限制的配置


kubectl describe node <node节点名称>                 
//查看node节点的资源总量、每个Pod的资源限制和节点的资源限制总量及比例

 

三、关于pod容器的三种探针

3.1健康检查：又称为探针（Probe） 

探针是由kubelet对容器执行的定期诊断。

探针的三种规则：
●livenessProbe ：判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。

●readinessProbe ：判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service endpoints 中剔除删除该Pod的IP地址。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。

●startupProbe（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。
#注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。

3.2三种健康检查的方式

●exec ：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。

●tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。

●httpGet ：对指定的端口和uri路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

每次探测都将获得以下三种结果之一：
●成功（Success）：表示容器通过了检测。
●失败（Failure）：表示容器未通过检测。
●未知（Unknown）：表示检测没有正常进行。

3.3实操验证

实操一：通过存活探针验证三大健康检查的方式

存活探针——exec健康检查方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: demo1
  name: demo1
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
#args的作用相当于docker-compose文件中的CMD字段，可以设置容器启动命令
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 10
#设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 2         #表示探测周期为2秒

 存活探针——tcpsocket健康检查方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: demo1
  name: demo1
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    ports:
    - containerPort: 80
      name: http
#设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    livenessProbe:
      tcpSocket:
        port: http             #表示探测端口为pod的80端口  这里引用暴露端口的名称来代替80端口 
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 2         #表示探测周期为2秒

 错误验证

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: demo1
  name: demo1
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    ports:
    - containerPort: 80
      name: http
#设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    livenessProbe:
      tcpSocket:
        port: 8080             #该8080端口并未开放，模拟检查失败查看
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针

 存活探针之httpget健康检查方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: demo1
  name: demo1
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    ports:
    - containerPort: 80
      name: http
#设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    livenessProbe:
      httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
        port: http
        path: /index.html      #做http健康检查的页面
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 2         #表示探测周期为2秒

 

实操二：验证启动探针、 就绪探针、存活探针的顺序

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: demo1
  name: demo1
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    ports:
    - containerPort: 80
      name: http
#设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    livenessProbe:
      httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
        port: http
        path: /index.html      #做http健康检查的页面
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 8         #表示探测周期为8秒
#设置就绪探针，探测pod是否处于就绪状态，如果说探测失败则为未就绪状态，service会将其从关联的pod中删除，请求也不转发给该pod
    readinessProbe:
      httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
        port: http
        path: /index.html      #做http健康检查的页面
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 10        #表示探测周期为10秒
#启动探针，为了探测容器应用是否处于运行状态，只有启动探针探测成功以后，就绪探针和存活探针才有效
    startupProbe:
      httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
        port: http
        path: /index1.html      #做http健康检查的页面
      failureThreshold: 3      #表示连续探测失败3次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 15        #表示探测周期为15秒

可验证 就绪探针与存活探针  是在启动探针探测成功以后才会生效

实操三：验证就绪探针

vim readiness-myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp1
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp3
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  type: ClusterIP
  ports:
  - name: http
    port: 80
    targetPort: 80

 

现在恢复index页面

 实操四、验证启动和退出动作

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: soscscs/myapp:v1
    lifecycle:   #此为关键字段
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]      
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  initContainers:
  - name: init-myservice
    image: soscscs/myapp:v1
    command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  volumes:
  - name: message-log
    hostPath:
      path: /data/volumes/nginx/log/
      type: DirectoryOrCreate

Pod容器的启动动作和退出动作：lifecycle.postStart|preStop（lifecycle与image字段同一层级）
lifecycle.postStart      设置Pod容器启动时额外执行的操作，此操作不会作为容器pid=1的主进程
lifecycle.preStop        设置Pod容器被kubelet杀掉退出时执行的操作

 kubelet杀掉有两种：要么kubelet delete 杀掉或者探针 探测失败

四、总结：

三种探针

  • 存活探针（livenessProbe）：探测Pod容器是否在正常运行。如果探测失败则kubelet杀掉容器，并根据容器重启策略决定是否重启容器
  • 就绪探针（readinessProbe）：探测Pod是否进入就绪状态(ready状态栏是否100%比例)，并做好接收service转发来的请求准备。

如果探测失败则Pod变成未就绪状态(0/1 1/2)，service就会删除相关联的Pod端点，并不再转发请求给处于未就绪状态的Pod

  • 启动探针（startupProbe）：探测Pod容器内的应用进程是否启动成功。在启动探针探测成功之前，存活探针和就绪探针都会处于暂停状态，直到启动探针探测成功为止

如果探测失败则kubelet杀掉容器，并根据容器重启策略决定是否重启容器

关于探针的3种探测方式

  • exec：在容器里执行linux命令，如果命令返回码为0则认为探测成功，如果命令返回码为非0值则认为探测失败
  • httpGet：向PodIP和指定的端口及URL路径发送HTTP GET请求，如果HTTP响应状态码为2XX 3XX则认为探测成功，如果HTTP响应状态码为4XX 5XX则认为探测失败
  • tcpSocket：向PodIP和指定的端口发送TCP连接请求（三次握手），如果端口正确且TCP连接成功则认为探测成功，如果TCP连接失败则认为探测失败

探针参数：

  • initialDelaySeconds：指定容器启动后延迟探测的时间（单位为秒）
  • periodSeconds：指定每次探测的间隔时间
  • failureThreshold：指定判定探测失败的连续失败次数
  • timeoutSeconds：指定探测超时等待的时间


Pod容器的启动动作和退出动作：lifecycle.postStart|preStop（lifecycle与image字段同一层级）
lifecycle.postStart      设置Pod容器启动时额外执行的操作，此操作不会作为容器pid=1的主进程
lifecycle.preStop        设置Pod容器被kubelet杀掉退出时执行的操作
 

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

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

相关文章

【数据结构与算法】回溯法解题20240301

【数据结构与算法】回溯法解题20240301

这里写目录标题 一、78. 子集1、nums [1,2,3]为例把求子集抽象为树型结构2、回溯三部曲 二、90. 子集 II1、本题搜索的过程抽象成树形结构如下&#xff1a; 三、39. 组合总和1、回溯三部曲2、剪枝优化 四、LCR 082. 组合总和 II1、思路2、树形结构如图所示&#xff1a;3、回溯…
阅读更多...
命令行启动mongodb服务器的问题及解决方案 -- Unrecognized option: storage.journal

命令行启动mongodb服务器的问题及解决方案 -- Unrecognized option: storage.journal

目录 mongodb命令行启动问题 -- Unrecognized option: storage.journal问题日志&#xff1a;问题截图&#xff1a;问题来源&#xff1a;错误原因&#xff1a;解决方式&#xff1a; mongodb命令行启动问题 – Unrecognized option: storage.journal 同样是格式出问题的问题分析和…
阅读更多...
视频在线压缩

视频在线压缩

video2edit 一款免费的在线视频编辑软件&#xff0c;可以进行视频合并、视频剪辑、视频压缩以及转换视频格式等。 链接地址&#xff1a;在线视频编辑器和转换器 - 编辑&#xff0c;转换和压缩视频文件 打开视频压缩页面&#xff0c;上传想要压缩视频&#xff0c;支持MP4&…
阅读更多...
SpringCloud搭建微服务之Consul服务注册与发现

SpringCloud搭建微服务之Consul服务注册与发现

1. Consul介绍 Consul是由HashiCorp公司使用Go语言开发的一款开源工具&#xff0c;主要用于实现分布式系统的服务发现和服务配置&#xff0c;其内置了服务注册与发现框架、分布式一致性协议实现、健康检查、Key-Value存储、多数据中心方案。Consul具有高可移植性&#xff0c;支…
阅读更多...
LTE 网络与互联网的连接

LTE 网络与互联网的连接

LTE 网络与互联网的连接 当用户设备 UE&#xff08;如手机&#xff09;开机后&#xff0c;就登记到 LTE 网络&#xff0c;以便使用网络资源传送 IP 数据业务。 LTE 网络内的数据路径由两大部分组成&#xff1a; -空口无线链路&#xff08;UE→eNB&#xff09;。 -核心网中的隧…
阅读更多...
【菜鸟入门！】Matlab零基础快速入门教程

【菜鸟入门！】Matlab零基础快速入门教程

数学建模竞赛中&#xff0c;编程软件是必不可缺少的&#xff0c;比如大家都熟知的MATLAB多数同学们都会经常用到&#xff0c;今天给大家介绍一些MATLAB的基本元素&#xff0c;希望帮助大家更好的掌握编写基本的函数&#xff01; 变量和数组 MATLAB 程序的基本数据单元是数组。一…
阅读更多...
Opencv实战(5)平滑处理与常见函数

Opencv实战(5)平滑处理与常见函数

平滑处理 Opencv实战&#xff1a; Opencv(1)读取与图像操作 Opencv(2)绘图与图像操作 Opencv(3)详解霍夫变换 Opencv(4)详解轮廓 文章目录 平滑处理1.均值滤波2.方框滤波3.高斯滤波4.中值滤波5.双边滤波 常见函数(1).createTrackbar()(2).SetMouseCallback() 图像的平滑处理是…
阅读更多...
Intel 芯片 Mac 如何重新安装系统

Intel 芯片 Mac 如何重新安装系统

使用可引导安装器重新安装&#xff08;可用于安装非最新的 Mac OS&#xff0c;系统降级&#xff0c;需要清除所有数据&#xff0c;过程确保连接上网络&#xff0c;虽然这种方式不会下载 Mac OS&#xff0c;但是需要下载固件等信息&#xff09; 插入制作好的可引导安装器&#x…
阅读更多...
使用docker方式测试部署django项目(客户催)

使用docker方式测试部署django项目(客户催)

需求 1&#xff1a;已有django项目–weidanyewu 2&#xff1a;希望在服务器上测试部署–客户催 3&#xff1a;没完善django的启动 4&#xff1a;使用临时数据库进行演示 5&#xff1a;使用python3.10版本镜像 6&#xff1a;展示端口80 7&#xff1a;后台执行django程序 8&#…
阅读更多...
信号系统之滤波器比较

信号系统之滤波器比较

比较 1&#xff1a;模拟与数字滤波器 大多数数字信号源自模拟电子设备。**如果需要对信号进行滤波&#xff0c;是在数字化之前使用模拟滤波器&#xff0c;还是在数字化后使用数字滤波器更好&#xff1f;**将通过两个对比来回答问题。 目标是提供 1 kHz的低通滤波器。模拟端是…
阅读更多...
2023全球软件开发大会-上海站：探索技术前沿，共筑未来软件生态(附大会核心PPT下载)

2023全球软件开发大会-上海站：探索技术前沿，共筑未来软件生态(附大会核心PPT下载)

随着信息技术的迅猛发展&#xff0c;全球软件开发大会&#xff08;QCon&#xff09;已成为软件行业最具影响力的年度盛会之一。2023年&#xff0c;QCon再次来到上海&#xff0c;汇聚了众多业界精英、技术领袖和开发者&#xff0c;共同探讨软件开发的最新趋势和实践。 一、大会…
阅读更多...
网络安全攻防演练：企业蓝队建设指南

网络安全攻防演练：企业蓝队建设指南

第一章 概述 背景 网络实战攻防演习是当前国家、重要机关、企业组织用来检验网络安全防御能力的重要手段之一，是对当下关键信息系统基础设施网络安全保护工作的重要组成部分。网络攻防实战演习通常是以实际运行的信息系统为攻击目标，通过在一定规则限定下的实战攻防对抗，最…
阅读更多...
Django学习笔记-查询及修改MySQL数据库表的所有信息

Django学习笔记-查询及修改MySQL数据库表的所有信息

1.在index中添加一个按钮,用于查询数据 2.urls配置find 3.views定义find,获取PopulationModel模型所有数据渲染到show.html页面上 4.创建show.html,遍历modellist的数据渲染到表格中显示 5.点击查询后页面显示如下 6.添加修改按钮,点击按钮,执行update,urls配置update …
阅读更多...
R语言数学建模（二）—— tidymodels

R语言数学建模（二）—— tidymodels

R语言数学建模&#xff08;二&#xff09;—— tidymodels 文章目录 R语言数学建模&#xff08;二&#xff09;—— tidymodels前言一、示例数据集二、拆分数据集2.1 拆分数据集的常用方法2.2 验证集2.3 多层次数据2.4 其他需考虑问题 三、parsnip用于拟合模型3.1 创建模型3.2 …
阅读更多...
面向对象编程入门：掌握C++类的基础（2/3）：深入理解C++中的类成员函数

面向对象编程入门：掌握C++类的基础（2/3）：深入理解C++中的类成员函数

在C编程中&#xff0c;类是构建程序的基石&#xff0c;而理解类的默认成员函数对于高效使用C至关重要。本文将深入探讨这六个默认成员函数及其他相关概念&#xff0c;提供给读者一个全面的视角。 类的6个默认成员函数&#xff1a; 如果一个类中什么成员都没有&#xff0c;简称为…
阅读更多...
PVE开启IPV6

PVE开启IPV6

echo "net.ipv6.conf.all.accept_ra2net.ipv6.conf.default.accept_ra2net.ipv6.conf.vmbr0.accept_ra2net.ipv6.conf.all.autoconf2net.ipv6.conf.default.autoconf2net.ipv6.conf.vmbr0.autoconf2" > /etc/sysctl.conf然后执行 sysctl -p最后再查询IP地址即可看…
阅读更多...
【Redis】Redis 实现分布式Session

【Redis】Redis 实现分布式Session

Cookie 保存在客户端浏览器中&#xff0c;而 Session 保存在服务器上。客户端浏览器访问服务器的时候&#xff0c;服务器把客户端信息以某种形式记录在服务器上&#xff0c;这就是 Session。客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。 在实际工作…
阅读更多...
免费百度快速收录软件

免费百度快速收录软件

在网站SEO的过程中&#xff0c;不断更新网站内容是提升排名和吸引流量的关键之一。而对于大多数网站管理员来说&#xff0c;频繁手动更新文章并进行SEO优化可能会是一项繁琐且耗时的任务。针对这一问题&#xff0c;百度自动更新文章SEO工具应运而生&#xff0c;它能够帮助网站管…
阅读更多...
pwa应用打开自动跳转到某个网页网址，并且全屏不显示网址url，就像这个网页也具备了pwa功能

pwa应用打开自动跳转到某个网页网址，并且全屏不显示网址url，就像这个网页也具备了pwa功能

问题描述 如果是只要在同一个域名下配置了pwa功能&#xff0c;那么当从桌面上打开这个pwa软件时&#xff0c;就会像真正的app运行一样&#xff0c;全屏显示&#xff0c;并且不显示网址的&#xff0c;但是如果要动态配置打开pwa时动态加载不同的网址&#xff0c;使用 window.lo…
阅读更多...
专利：基于2D工业相机的工件目标检测及三维姿态

专利：基于2D工业相机的工件目标检测及三维姿态

本发明公开了一种基于2D工业相机的工件目标检测及三维姿态判定方法&#xff0c;首先根据待生产或是待加工工件目标搭建其三维几何模型&#xff0c;并标记该几何模型制定特征点&#xff0c;然后对通过两个2D工业相机分别获得的现场工件目标图像进行目标检测及特征识别&#xff0…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023