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

目录

一、关于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杀掉退出时执行的操作
 

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

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

mobile app 安全扫描工具MobSF了解下

mobile app 安全扫描工具MobSF了解下

可以干啥&#xff1a; static 静态分析 dynamic 动态分析 可以用来渗透了 如何docker安装 docker image 下载地址https://hub.docker.com/r/opensecurity/mobile-security-framework-mobsf/ setup 两行即可 1 docker pull opensecurity/mobile-security-framework-mobsf…
阅读更多...
Python：练习：编写一个程序，录入一个美元数量（int），然后显示出增加%5税率后的相应金额。

Python：练习：编写一个程序，录入一个美元数量（int），然后显示出增加%5税率后的相应金额。

案例&#xff1a; 编写一个程序&#xff0c;录入一个美元数量&#xff08;int&#xff09;&#xff0c;然后显示出增加%5税率后的相应金额。格式如下所示&#xff1a; Enter an amount:100 With tax added:$105.0 思考&#xff1a; 1、录入一个美元数量&#xff0c;录入&am…
阅读更多...
[Flutter]TextButton自定义样式

[Flutter]TextButton自定义样式

在Flutter中&#xff0c;TextButton是一个简单的文本按钮&#xff0c;它遵循当前的Theme。如果你想要修改TextButton的样式&#xff0c;可以通过设置其style属性来实现&#xff0c;该属性接收一个ButtonStyle对象。 给TextButton和里面Text添加背景后&#xff0c;效果如下。可…
阅读更多...
【软件测试】接口调不通排查分析+常遇面试题总结

【软件测试】接口调不通排查分析+常遇面试题总结

目录&#xff1a;导读 前言一、Python编程入门到精通二、接口自动化项目实战三、Web自动化项目实战四、App自动化项目实战五、一线大厂简历六、测试开发DevOps体系七、常用自动化测试工具八、JMeter性能测试九、总结&#xff08;尾部小惊喜&#xff09; 前言 1、接口调不通&am…
阅读更多...
【MySQL】MySQL数据管理——DDL数据操作语言(数据表)

【MySQL】MySQL数据管理——DDL数据操作语言(数据表)

目录 创建数据表语法列类型字段属性SQL示例创建学生表 查看表和查看表的定义表类型设置表的类型 面试题&#xff1a;MyISAM和InnoDB的区别设置表的字符集删除表语法示例 修改表修改表名语法示例 添加字段语法示例 修改字段语法示例 删除字段语法示例 数据完整性实体完整性域完整…
阅读更多...
petalinux烧写image.ub报错

petalinux烧写image.ub报错

xinlinx SDK烧写petalinux生成的BOOT.BIN和image.ub时&#xff0c;BOOT.BIN烧写正常&#xff0c;image.ub烧写报错如下 Erase Operation failed. INFO: [Xicom 50-44] Elapsed time 0 sec.ERROR: Flash Operation Failed串口助手操作擦除flash如图&#xff1a; 解决方法&am…
阅读更多...
JVM内存分配与垃圾收集流程

JVM内存分配与垃圾收集流程

3.8　实战&#xff1a;内存分配与回收策略 3.8.1　对象优先在Eden分配 大多数情况下&#xff0c;对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时&#xff0c;虚拟机将发起一次Minor GC。 3.8.2　大对象直接进入老年代 HotSpot虚拟机提供了-XX&#xff1a;Prete…
阅读更多...
西软云XMS futurehotel/operate XXE漏洞复现

西软云XMS futurehotel/operate XXE漏洞复现

0x01 产品简介 西软云XMS是基于云平台数据中心开发的支持多酒店、多语言、多平台的酒店管理系统。致力于以新一代云架构为国内四，五星级中高端酒店提供灵活、高度整合酒店业务，助力酒店智能转型升级。 0x02 漏洞复现 西软云XMS /XopServerRS/rest/futurehotel/operate接口…
阅读更多...
Spring事务模板及afterCommit存在的坑

Spring事务模板及afterCommit存在的坑

大家好&#xff0c;我是墨哥&#xff08;隐墨星辰&#xff09;。今天的内容来源于两个线上问题&#xff0c;主要和大家聊聊为什么支付系统中基本只使用事务模板方法&#xff0c;而不使用声明式事务Transaction注解&#xff0c;以及使用afterCommit()出现连接未按预期释放导致的…
阅读更多...
Smuggler：一款功能强大的HTTP请求走私和去同步安全测试工具

Smuggler：一款功能强大的HTTP请求走私和去同步安全测试工具

关于Smuggler Smuggler是一款功能强大的HTTP请求走私和去同步安全测试工具&#xff0c;该工具基于纯Python 3开发&#xff0c;可以帮助广大研究人员针对应用程序的HTTP协议执行安全分析和测试。 工具安装 由于该工具基于Python 3开发&#xff0c;因此我们首先需要在本地设备上…
阅读更多...
【学习记录】HC32F460USB——U盘IAP升级app

【学习记录】HC32F460USB——U盘IAP升级app

从头开始&#xff0c;万物从解压开始 直奔猪蹄&#xff0c;找到usb下的工程文件 开始移植 主要移植IAP的boot和fatfs的文件系统&#xff0c;fatfs官网去下载ff15.0版本&#xff0c;目前用这个 放到项目里 添加到工程文件中 改引脚&#xff0c;给USB放电 编译&#xff0c;可以…
阅读更多...
GCC如何产生core dump

GCC如何产生core dump

先决条件 1.安装apport&#xff08;automatically generate crash reports for debugging&#xff09; 2.修改/etc/security/limits.conf文件&#xff0c;使允许core dump&#xff0c;或者用ulimit -c unlimited设置core dump文件的大小为unlimited&#xff08;临时方案&#x…
阅读更多...
生成voc格式数据集

生成voc格式数据集

数据集存放格式&#xff1a;&#xff08;Annotations文件夹放标注的xml文件&#xff0c;JPEGImages文件夹放标注的图片&#xff09; 运行代码&#xff1a; import os import random import xml.etree.ElementTree as ETimport numpy as npdef get_classes(classes_path):with …
阅读更多...
Java中的时间API：Date、Calendar到Java.time的演变

Java中的时间API：Date、Calendar到Java.time的演变

引言 在软件开发中&#xff0c;处理时间和日期是一项基本且不可或缺的任务。无论是日志记录、用户信息管理还是复杂的定时任务&#xff0c;准确地处理时间都显得至关重要。然而&#xff0c;时间的处理并不像它看起来那么简单&#xff0c;尤其是当我们考虑到时区、夏令时等因素…
阅读更多...
计算机组成原理-第一/二章 概述和数据的表示和运算【期末复习|考研复习】

计算机组成原理-第一/二章 概述和数据的表示和运算【期末复习|考研复习】

文章目录 前言第一章 计算机组成原理 概述及各种码1.1 计算机硬件的基本组成1.1.1 存储器1.1.2 运算器1.1.3 控制器 1.2 计算机的工作过程1.3 计算机的性能指标1.4 各个字长区别与联系 第二章 数据的表示与运算2.1 ASCII码2.2 各种码2.3 浮点数 总结 前言 给大家整理了一下计算…
阅读更多...
域控操作七：让某人不执行某策略/单独放行某人

域控操作七：让某人不执行某策略/单独放行某人

比如我设置的是禁用移动热点&#xff0c;我在这里对某人拒绝&#xff0c;那他就能用移动热点
阅读更多...
Qt6内嵌CEF

Qt6内嵌CEF

一、下载CEF CEF下载地址&#xff1a;https://cef-builds.spotifycdn.com/index.html 或https://bitbucket.org/chromiumembedded/cef/src/master/ 选择对应系统的版本&#xff08;本教程选择的是116.0.19&#xff09; CMake下载地址&#xff1a;https://cmake.org/download…
阅读更多...
大数据界面：客户又又又要求科技感了，如何破？

大数据界面：客户又又又要求科技感了，如何破？

如果你问客户想要什么风格&#xff0c;大部分脱口而出科技感&#xff0c;不仅要求静态页&#xff0c;而且还要求动态效果&#xff0c;炫酷动画&#xff0c;贝格前端工场结合多个项目经历&#xff0c;帮助友友们梳理如何让界面科技动感。 一、没有科技感背后的潜台词 客户说大数…
阅读更多...
SI523 替代CLRC522/RC523，软硬件开发资料

SI523 替代CLRC522/RC523，软硬件开发资料

​si523是一个 13.56MHz 的非接触式读写器芯片&#xff0c;支持 ISO/IEC 14443 A/B/MIFARE协议。内部集成低功耗自动寻卡与定时唤醒功能&#xff0c;可编程寻卡时间间隔&#xff0c;寻卡过程无需 MCU 操作&#xff0c;寻卡成功中断唤醒或定时唤醒 MCU 以实现低功耗。 产品特性…
阅读更多...
笑营宝高校选修课报名考勤系统源码开发方案

笑营宝高校选修课报名考勤系统源码开发方案

一、项目背景与目标 &#xff08;一&#xff09;项目背景 随着高等教育的普及和教学模式的不断创新&#xff0c;高校选修课程体系日趋复杂多变。学生对课程选择的自由度提高&#xff0c;使得传统的选课和考勤管理方式变得繁琐且效率低下。目前&#xff0c;许多高校仍然采用纸…
阅读更多...
最新文章

Copyright @ 2022~2023