k8s-资源限制-探针检查

news2024/11/26 2:56:39

文章目录

  • 一、资源限制
    • 1、资源限制的使用
    • 2、reuqest资源（请求）和limit资源（约束）
    • 3、Pod和容器的资源请求和限制
    • 4、官方文档示例
    • 5、资源限制实操
      • 5.1 编写yaml资源配置清单
      • 5.2 释放内存（node节点，以node01为例）
      • 5.3 创建资源
      • 5.4 跟踪查看pod状态
      • 5.5 查看容器日志
      • 5.6 删除pod
      • 5.7 修改yaml配置资源清单，提高mysql资源限制
      • 5.8 再次创建资源
      • 5.9 跟踪查看pod状态
      • 5.10 查看pod详细信息
      • 5.11 查看node资源使用
  • 二、健康检查
    • 1、健康检查的定义
    • 2、探针的三种规则
      • 2.1 livenessProbe存活探针
      • 2.2 readinessProbe就绪探针
      • 2.3 startupProbe启动探针（1.17版本新增）
      • 2.4 同时定义
    • 3、Probe支持的三种检测方法
      • 3.1 exec
      • 3.2 tcpSocket
      • 3.3 httpGet
    • 4、探测结果
    • 5、exec方式
    • 6、httpGet方式
    • 7、tcpSocket方式
  • 三、总结
    • 1、探针
    • 2、检查方式
    • 3、常用的探针可选参数
    • 4、重启策略

一、资源限制

1、资源限制的使用

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

2、reuqest资源（请求）和limit资源（约束）

  1. 当为Pod中的容器指定了request资源时，调度器就使用该信息来决定将Pod调度到哪个节点上。当还为容器指定了limit资源时，kubelet就会确保运行的容器不会使用超出所设的limit资源量。kubelet还会为容器预留所设的request资源量，供该容器使用。
  2. 如果Pod所在的节点具有足够的可用资源，容器可以使用超过所设置的request资源量。不过，容器不可以使用超出所设置的limit资源量。
  3. 如果给容器设置了内存的limit值，但未设置内存的request值，Kubernetes会自动为其设置与内存limit相匹配的request值。类似的，如果给容器设置了CPU的limit值但未设置CPU的request值，则Kubernetes自动为其设置CPU的request值，并使之与CPU的limit值匹配。

3、Pod和容器的资源请求和限制

定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.cpu
定义创建容器时预分配的内存资源
spec.containers[].resources.requests.memory
定义创建容器时预分配的巨页资源
spec.containers[].resources.requests.hugepages-<size>
定义cpu的资源上限
spec.containers[].resources.limits.cpu
定义内存的资源上限
spec.containers[].resources.limits.memory
定义巨页的资源上限
spec.containers[].resources.limits.hugepages-<size>

4、官方文档示例

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

此例子中Pod有两个Container。每个Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， 每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。

5、资源限制实操

5.1 编写yaml资源配置清单

[root@master ~]# mkdir /opt/test
[root@master ~]# cd !$
cd /opt/test
[root@master test]# vim test1.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: test1
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

5.2 释放内存（node节点，以node01为例）

由于mysql对于内存的使用要求比较高，因此需要先检查内存的可用空间是否能够满足mysql的正常运行，若剩余内存不够，可对其进行释放操作。

查看内存

free -mH

[root@node01 ~]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           1.9G        1.0G         86M         26M        870M        663M
Swap:            0B          0B          0B

内存总量为1.9G，实际使用1G，因此可有内存应该为0.9G左右。
但是由于有870M的内存被用于缓存，导致了free仅为86M。
86M剩余可用内存显然是不够用的，因此需要释放缓存。

手动释放缓存

echo [1\2\3] > /proc/sys/vm/drop_caches

[root@node01 ~]# cat /proc/sys/vm/drop_caches
0
[root@node01 ~]# echo 3 > /proc/sys/vm/drop_caches
[root@node01 ~]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           1.9G        968M        770M         26M        245M        754M
Swap:            0B          0B          0B

0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理
1：释放页缓存
2：释放dentries和inodes
3：释放所有缓存

注意：

如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。
一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。

5.3 创建资源

kubectl apply -f tets1.yaml

[root@master test]# kubectl apply -f test1.yaml 
pod/test1 created

5.4 跟踪查看pod状态

kubectl get pod -o wide -w

[root@master test]# kubectl get pod -o wide -w
NAME    READY   STATUS              RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
test1   0/2     ContainerCreating   0          4s    <none>   node01   <none>           <none>
test1   2/2     Running             0          18s   10.244.1.55   node01   <none>           <none>
test1   1/2     OOMKilled           0          21s   10.244.1.55   node01   <none>           <none>
test1   2/2     Running             1          37s   10.244.1.55   node01   <none>           <none>
test1   1/2     OOMKilled           1          40s   10.244.1.55   node01   <none>           <none>
......

OOM（OverOfMemory）表示服务的运行超过了我们所设定的约束值。

Ready:2/2，status:Running说明该pod已成功创建并运行，但运行过程中发生OOM问题被kubelet杀死并重新拉起新的pod。

5.5 查看容器日志

kubectl logs test1 -c web

[root@master test]# kubectl logs test1 -c web
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2021/11/06 08:31:23 [notice] 1#1: using the "epoll" event method
2021/11/06 08:31:23 [notice] 1#1: nginx/1.21.3
2021/11/06 08:31:23 [notice] 1#1: built by gcc 8.3.0 (Debian 8.3.0-6) 
2021/11/06 08:31:23 [notice] 1#1: OS: Linux 3.10.0-693.el7.x86_64
2021/11/06 08:31:23 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2021/11/06 08:31:23 [notice] 1#1: start worker processes
2021/11/06 08:31:23 [notice] 1#1: start worker process 31
2021/11/06 08:31:23 [notice] 1#1: start worker process 32

nginx启动正常，接下来查看mysql日志

kubectl logs test1 -c mysql

[root@master test]# kubectl logs test1 -c db2021-11-06 08:38:44+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.27-1debian10 started.2021-11-06 08:38:44+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'2021-11-06 08:38:44+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.27-1debian10 started.2021-11-06 08:38:44+00:00 [Note] [Entrypoint]: Initializing database files2021-11-06T08:38:44.274783Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.27) initializing of server in progress as process 412021-11-06T08:38:44.279965Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.2021-11-06T08:38:44.711420Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.2021-11-06T08:38:45.777355Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1 is enabled for channel mysql_main2021-11-06T08:38:45.777389Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1.1 is enabled for channel mysql_main2021-11-06T08:38:45.898121Z 6 [Warning] [MY-010453] [Server] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option./usr/local/bin/docker-entrypoint.sh: line 191:    41 Killed                  "$@" --initialize-insecure --default-time-zone=SYSTEM

锁定问题容器为mysql

5.6 删除pod

kubectl delete -f test1

[root@master test]# kubectl delete -f test1.yaml

5.7 修改yaml配置资源清单，提高mysql资源限制

[root@master test]# vim test1.yaml  
 
apiVersion: v1
kind: Pod
metadata:  
  name: test1
spec:  
  containers:  
  - name: web    
    image: nginx    
    env:    
    - name: WEB_ROOT_PASSWORD      
      value: "password"    
    resources:      
    requests:         
      memory: "64Mi"        
      cpu: "250m"      
    limits:        
      memory: "128Mi"        
      cpu: "500m"  
  - name: db    
    image: mysql    
    env:    
    - name: MYSQL_ROOT_PASSWORD      
      value: "password"    
    resources:      
    requests:        
      memory: "512Mi"        
      cpu: "0.5"      
    limits:        
      memory: "1024Mi"        
      cpu: "1"

5.8 再次创建资源

kubectl apply -f test1.yaml

[root@master test]# kubectl apply -f test1.yaml pod/test1 created

5.9 跟踪查看pod状态

kubectl get pod -o wide -w

[root@master test]# kubectl get pod -o wide -w

5.10 查看pod详细信息

kubectl describe pod test1

[root@master test]# kubectl describe pod test1

5.11 查看node资源使用

[root@master test]# kubectl describe node node01

node01的配置为2C2G。
CPU Requests分析：
nginx的requests为250m，mysql的requests为500m，因此node01的CPU Requests为750m，在node01的两个核中使用占比为37%。
CPU Limits分析：
nginx到的limit为500m，mysql的limit为1，因此node01到的CPU Limits为1500m，在node01的两个核中使用占比为75%。
Memory Requests分析：
nginx的requests为64Mi，mysql的requests为512Mi，因此node01的内存Requests为576Mi，在node01的2G内存中使用占比为30%。
Memory Limits分析：
nginx的limits为128Mi，mysql的limit为1Gi，因此node01的1152Mi，在node01的2G内存中使用占比为61%。

二、健康检查

1、健康检查的定义

img

健康检查又称为探针（Probe），是由kubelet对容器执行的定期诊断。

2、探针的三种规则

2.1 livenessProbe存活探针

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

2.2 readinessProbe就绪探针

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

2.3 startupProbe启动探针（1.17版本新增）

判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果匹配了startupProbe探测，则在startupProbe状态为Success之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果startupProbe失败，kubelet将杀死容器，容器将根据restartPolicy来重启。如果容器没有配置startupProbe，则默认状态为Success。

2.4 同时定义

以上三种规则可同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。

3、Probe支持的三种检测方法

3.1 exec

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

3.2 tcpSocket

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

3.3 httpGet

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

4、探测结果

每次探测都将获得以下三种结果之一：
● 成功：容器通过了诊断
● 失败：容器未通过诊断
● 未知：诊断失败，因此不会采取任何行动

5、exec方式

vim exec.yaml
 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness				#为了健康检查定义的标签
  name: liveness-exec
spec:						#定义了Pod中containers的属性
  containers:
  - name: liveness
    image: busybox
    args:						#传入的命令
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5			#表示pod中容器启动成功后，多少秒后进行健康检查 
      periodSeconds: 5				#在首次健康检查后，下一次健康检查的间隔时间 5s

在配置文件中，可以看到Pod具有单个Container。该perioSeconds字段指定kubelet应该每5秒执行一次活动性探测。该initiaDelaySeconds字段告诉kubelet在执行第一个探测之前应该等待5秒。为了执行探测，kubelet cat /tmp/healthy在容器中执行命令。如果命令成功执行，则返回0，并且kubelet认为Container仍然重要。如果命令返回非0值，则kubelet将杀死Container并重启它。

  1. 在这个配置文件中，可以看到Pod只有一个容器。
  2. 容器中的command字段表示创建一个/tmp/live文件后休眠30秒，休眠结束后删除该文件，并休眠10分钟。
  3. 仅使用livenessProbe存活探针，并使用exec检查方式，对/tmp/live文件进行存活检测。
  4. initialDelaySeconds字段表示kubelet在执行第一次探测前应该等待5秒。
  5. periodSeconds字段表示kubelet每隔5秒执行一次存活探测。

在这里插入图片描述

6、httpGet方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

在这里插入图片描述

7、tcpSocket方式

定义TCP活动度探针

第三种类型的活动性探针使用TCP套接字，使用此配置，kubelet将尝试在指定端口上打开容器的套接字。如果可以建立连接，则认为该让其运行状况良好，如果不能，则认为该容器是故障容器。

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

在这里插入图片描述

如图所示，TCP检查的配置与HTTP检查非常相似，此示例同时使用就绪和活跃度探针，容器启动5秒后，kubelet将发送第一个就绪探测器。这些尝试连接到goproxy端口8080上的容器。如果探测成功，则容器将标记为就绪，kubelet将继续每10秒运行一次检查。

除了就绪探针之外，此配置还包括活动探针。容器启动后15秒钟，kubelet将运行第一个活动谈着，就像就绪探针一样，这些尝试goproxy在端口8080上连接到容器。如果活动探针失败，则容器将重新启动。

三、总结

1、探针

探针分为3种

  1. livenessProbe（存活探针）∶判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略是否重启容器
  2. readinessProbe（就绪探针）∶判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器
  3. startupProbe∶判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

2、检查方式

检查方式分为3种

  1. exec∶使用 command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功
  2. httpget∶通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功
  3. tcpsocket∶通过tcp连接pod（IP）和指定端口，如果端口无误且tcp连接成功，则认为探测成功

3、常用的探针可选参数

常用的探针可选参数有4个

  1. initialDelaySeconds∶ 容器启动多少秒后开始执行探测
  2. periodSeconds∶探测的周期频率，每多少秒执行一次探测
  3. failureThreshold∶探测失败后，允许再试几次
  4. timeoutSeconds ∶ 探测等待超时的时间

4、重启策略

Pod在遇到故障之后“重启”的动作Pod在遇到故障之后“重启”的动作

Always：当容器终止退出后，总是“重启”容器，默认策略

OnFailure：当容器异常退出（退出状态码非0）时，重启容器

Never：当容器终止退出，从不“重启”容器。

（注意：k8s中不支持重启Pod资源，只有删除重建，重建）

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

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

相关文章

计算机网络题库---错题本

计算机网络题库---错题本

&#xff08;一&#xff09;老生常谈 第一章&#xff1a; 1.什么是计算机网络&#xff1f;其主要功能是什么&#xff1f; 解答&#xff1a; 利用通信设备和线路&#xff0c;将分布在地理位置不同的、功能独立的多个计算机系统连接起来&#xff0c;以功能完善的网络软件实现网…
阅读更多...
ChatGPT 开发人员教程 - 38种提高工作效率10倍的方法

ChatGPT 开发人员教程 - 38种提高工作效率10倍的方法

未来的时代&#xff0c;又将是一个“洋枪洋炮”对“大刀长矛”的时代。在过去的十年里&#xff0c;传统行业在和经过IT改造的行业竞争时&#xff0c;无一例外地败北。08年金融危机前&#xff0c;全世界市值前十的公司&#xff0c;只有微软一家是IT企业。仅仅过去了十年&#xf…
阅读更多...
文献阅读：Training language models to follow instructions with human feedback

文献阅读：Training language models to follow instructions with human feedback

文献阅读&#xff1a;Training language models to follow instructions with human feedback 1. 文献工作简介2. 模型优化设计3. 实验结果4. 总结 & 思考 文献链接&#xff1a;https://arxiv.org/abs/2203.02155 1. 文献工作简介 这篇文章是OpenAI在上年提出的一篇对于…
阅读更多...
Go项目（商品微服务-1）

Go项目（商品微服务-1）

文章目录简介建表protohandler商品小结简介 商品微服务主要在于表的设计&#xff0c;建哪些表&#xff1f;表之间的关系是怎样的&#xff1f; 主要代码就是 CURD表和字段的设计是一个比较有挑战性的工作&#xff0c;比较难说清楚&#xff0c;也需要经验的积累&#xff0c;这里…
阅读更多...
【Linux】工具（2）——vim

【Linux】工具（2）——vim

本期博客我们进入到Linux环境下vim工具的学习&#xff1a;一、vim是什么&#x1f4cc;Vim是一个超级超级强大的文本编辑器。Vim及前身VI&#xff0c;历史悠久&#xff08;可能比多数读者的年龄更大&#xff09;&#xff0c;经历了几十年的考验和发展。Vim全称叫Vi IMproved. 而…
阅读更多...
Linux安装云原生网关Kong/KongA

Linux安装云原生网关Kong/KongA

目录1 概述2 创建服务器3 安装postgres4 安装kong5 安装node6 安装KONGA1 概述 Kong Kong是一款基于OpenResty&#xff08;NginxLua模块&#xff09;编写的高可用、易扩展的开源API网关&#xff0c;专为云原生和云混合架构而建&#xff0c;并针对微服务和分布式架构进行了特别…
阅读更多...
蓝桥杯算法模板

蓝桥杯算法模板

模拟散列表拉链法import java.io.*; import java.util.*; public class a1 {static int n;static int N100003;static int[] hnew int[N];static int[] enew int[N];static int[] nenew int[N]; static int idx; static void insert(int x){int k(x%NN)%N;e[idx]x;ne[idx]h[k];…
阅读更多...
终端软件架构说

终端软件架构说

目录 零&#xff1a;前言 一&#xff0c;基于服务的架构 二&#xff0c;基于多进程多线程的架构 三&#xff0c;以数据为中心的架构 四&#xff0c;类Android的分层架构设计 五&#xff0c;总结 零&#xff1a;前言 谈到架构&#xff0c;可能大家的第一感觉是信息系统的…
阅读更多...
2023年三月份图形化三级打卡试题

2023年三月份图形化三级打卡试题

活动时间 从2023年3月1日至3月21日&#xff0c;每天一道编程题。 本次打卡的规则如下&#xff1a; 小朋友每天利用10~15分钟做一道编程题&#xff0c;遇到问题就来群内讨论&#xff0c;我来给大家答疑。 小朋友做完题目后&#xff0c;截图到朋友圈打卡并把打卡的截图发到活动群…
阅读更多...
Vue 3第三章：模板语法及指令介绍

Vue 3第三章：模板语法及指令介绍

文章目录1. 插值表达式1.1. 声明变量可直接在模板中使用&#xff0c;采用{{变量名称}}的方式1.2. 模板语法支持三元表达式1.3. 模板语法支持运算1.4. 模板语法支持方法调用2. 指令2.1. v-bind&#xff1a;用于绑定属性或动态绑定对象的值到元素上。2.2. v-if、v-else-if、v-els…
阅读更多...
C#学习记录——接口的实现

C#学习记录——接口的实现

一小部分知识精英依旧直面核心困难&#xff0c;努力地进行深度钻研&#xff0c;生产内容&#xff1b;而大多数信息受众始终在享受轻度学习&#xff0c;消费内容。如果我们真的希望在时代潮流中占据一席之地&#xff0c;那就应该尽早抛弃轻松学习的幻想&#xff0c;锤炼深度学习…
阅读更多...
Burp Suite 常用模块简介

Burp Suite 常用模块简介

Burp Suite 常用模块分为 目标站点(target)模块 代理(proxy)模块 攻击(Intruder)模块 重放(Repeater) 模块 Target模块是对站点资源的收集&#xff0c;与站点各资源包发出和相应包的记录 Proxy模块是核心模块&#xff0c;可以拦截数据包发送往浏览器&#xff0c;进行修改后再…
阅读更多...
网络协议分析（2）判断两个ip数据包是不是同一个数据包分片

网络协议分析（2）判断两个ip数据包是不是同一个数据包分片

一个节点收到两个IP包的首部如下&#xff1a;&#xff08;1&#xff09;45 00 05 dc 18 56 20 00 40 01 bb 12 c0 a8 00 01 c0 a8 00 67&#xff08;2&#xff09;45 00 00 15 18 56 00 b9 49 01 e0 20 c0 a8 00 01 c0 a8 00 67分析并判断这两个IP包是不是同一个数据报的分片&a…
阅读更多...
Android JetPack之启动优化StartUp初始化组件的详解和使用

Android JetPack之启动优化StartUp初始化组件的详解和使用

一、背景 先看一下Android系统架构图 在Android设备中&#xff0c;设备先通电&#xff08;PowerManager&#xff09;&#xff0c;然后加载内核层&#xff0c;内核走完&#xff0c;开始检查硬件&#xff0c;以及为硬件提供的公开接口&#xff0c;然后进入到库的加载。库挂载后开…
阅读更多...
Winform控件开发（16）——Timer（史上最全）

Winform控件开发（16）——Timer（史上最全）

前言： Timer控件的作用是按用户定义的时间间隔引发事件的计时器，说的直白点就是，他就像一个定时炸弹一样到了一定时间就爆炸一次，区别在于定时炸弹炸完了就不会再次爆炸了，但是Timer这个计时器到了下一个固定时间还会触发一次，上面那张图片就是一个典型的计时器，该定时器…
阅读更多...
【Java】Spring Boot 配置文件

【Java】Spring Boot 配置文件

文章目录SpringBoot 配置文件1. 配置文件的作用2. 配置文件的格式3. properties配置文件说明3.1 properties基本语法3.2 读取配置文件3.3 properties缺点分析4. yml配置文件说明4.1 yml基本语法4.2 yml使用进阶4.2.1 yml配置不同的数据类型及null4.2.1 yml配置的读取4.2.2 配置…
阅读更多...
Python蓝桥杯训练：基本数据结构 [哈希表]

Python蓝桥杯训练：基本数据结构 [哈希表]

Python蓝桥杯训练&#xff1a;基本数据结构 [哈希表] 文章目录Python蓝桥杯训练&#xff1a;基本数据结构 [哈希表]一、哈希表理论基础知识1、开放寻址法2、链式法二、有关哈希表的一些常见操作三、力扣上面一些有关哈希表的题目练习1、[有效的字母异位词](https://leetcode.cn…
阅读更多...
0101基础概念-图-数据结构和算法(Java)

0101基础概念-图-数据结构和算法(Java)

文章目录1 图1.1 定义1.2 4种图模型2 无向图2.1 定义2.2 术语后记1 图 1.1 定义 图是一种非线性的数据结构&#xff0c;表示多对多的关系。 图&#xff08;Graph&#xff09;是由顶点的有穷非空集合和顶点之间边的集合组成&#xff0c;通常表示为&#xff1a;G(V, E)&#xf…
阅读更多...
ecology9-谷歌浏览器下-pdf.js在渲染时部分发票丢失文字 问题定位及解决

ecology9-谷歌浏览器下-pdf.js在渲染时部分发票丢失文字 问题定位及解决

问题 问题描述 &#xff1a; 在谷歌浏览器下&#xff0c;pdf.js在渲染时部分发票丢失文字&#xff1b;360浏览器兼容模式不存在此问题 排查思路&#xff1a;1、对比谷歌浏览器的css样式和360浏览器兼容模式下的样式&#xff0c;没有发现关键差别 2、✔使用Fiddler修改网页js D…
阅读更多...
什么是线程死锁？如何解决死锁问题

什么是线程死锁？如何解决死锁问题

死锁&#xff0c;一组互相竞争的资源的线程之间相互等待&#xff0c;导致永久阻塞的现象。 如下图所示&#xff1a; 与死锁对应的&#xff0c;还有活锁&#xff0c;是指线程没有出现阻塞&#xff0c;但是无限循环。 有一个经典的银行转账例子如下&#xff1a; 我们有个账户类…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023