kubernetes|云原生| 如何优雅的重启和更新pod---pod生命周期管理实务

news2024/12/26 23:28:38

前言：

kubernetes的管理维护的复杂性体现在了方方面面，例如，ｐｏｄ的管理，服务的管理，用户的管理（ＲＢＡＣ），网络的管理等等，因此，kubernetes安装部署完毕仅仅是万里长征的第一步，后面的运营和维护工作才是更为关键的东西。

那么，ｐｏｄ的生命周期是什么概念呢？这些和重启与更新这样的操作有着怎样的联系呢？进一步的说，什么是优雅，优雅的重启和更新有什么好处？如何做到优雅的重启和更新？

以上问题是本文想要搞清楚的，也应该搞清楚的问题，下面就以上问题做一个尽量详细的解答，如有不对的地方，还请各位轻喷（水或者火）

一，

ｐｏｄ的生命周期

Pod 是 Kubernetes 中最基本的工作单元，代表了一个可执行的应用程序实例。Pod 的生命周期由一系列状态组成，如下所示：

  1. Pending：表示 Pod 已经被创建，但尚未调度到任何节点上。
  2. Running：表示 Pod 已经被成功调度并正在运行。
  3. Succeeded：表示 Pod 所包含的所有容器都已经成功终止，且不会被重启。
  4. Failed：表示 Pod 所包含的至少有一个容器未能成功终止，或者 Pod 本身出现了故障。
  5. Unknown：表示无法确定 Pod 的状态，通常是由于 API 服务器无法与 Pod 进行通信。
  6. tｅｒｒｉｍｅｒ　挂起状态，表示此ｐｏｄ不可用，一般是删除期间的旧ｐｏｄ的状态

当然了，ｐｏｄ的状态还有十来种，例如，ｏｕｔｏｆｃｐｕ　等等这样的，但主要的常用的状态就是上面的这些。

Pod创建：
      1. API Server 在接收到创建pod的请求之后，会根据用户提交的参数值来创建一个运行时的pod对象。
      2. 根据 API Server 请求的上下文的元数据来验证两者的 namespace 是否匹配，如果不匹配则创建失败。
      3. Namespace 匹配成功之后，会向 pod 对象注入一些系统数据，如果 pod 未提供 pod 的名字，则 API Server 会将 pod 的 uid 作为 pod 的名字。
      4. API Server 接下来会检查 pod 对象的必需字段是否为空，如果为空，创建失败。
      5. 上述准备工作完成之后会将在 etcd 中持久化这个对象，将异步调用返回结果封装成 restful.response，完成结果反馈。
      6. API Server 创建过程完成，剩下的由 scheduler 和 kubelet 来完成，此时 pod 处于 pending 状态。
      7. Scheduler选择出最优节点。
      8. Kubelet启动该Pod。
   Pod删除：
      1. 用户发出删除 pod 命令
      2. 将 pod 标记为“Terminating”状态
         监控到 pod 对象为“Terminating”状态的同时启动 pod 关闭过程
         endpoints 控制器监控到 pod 对象关闭，将pod与service匹配的 endpoints 列表中删除
         Pod执行PreStop定义的内容
      3. 宽限期（默认30秒）结束之后，若存在任何一个运行的进程，pod 会收到 SIGKILL 信号
      4. Kubelet 请求 API Server 将此 Pod 资源宽限期设置为0从而完成删除操作

那么，ｐｏｄ的生命周期运行机制是比较复杂的，上面只是粗略的说了一下，底层的东西并无必要在本文详细讲解，而一个ｐｏｄ从创建到彻底的删除或回收我们就可以简单的认为这是一个生命周期，而在此期间ｐｏｄ可能会经历种种状态，并不是简单的说一个ｐｏｄ创建完了就等待删除，这些想法是不正确的。

二，

pod生命周期的管理

由于kubernetes是一个自动化的容器管理平台，因此，我们总是希望pod被部署好后，是处于一个稳定的状态，也就是说除了running状态，其它的状态基本是不可接受的，除了部分的job类型或者init类型的pod，那么，现在的目标就很简单了，如何保持pod的状态总是running

下面以一个实际的例子来说明问题：

kubernetes的版本

[root@node1 ~]# kubectl get no -owide
NAME    STATUS   ROLES                  AGE    VERSION    INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME
node1   Ready    control-plane,master   117d   v1.23.16   192.168.123.11   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8
node2   Ready    control-plane,master   117d   v1.23.16   192.168.123.12   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8
node3   Ready    control-plane,master   117d   v1.23.16   192.168.123.13   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8
node4   Ready    worker                 117d   v1.23.16   192.168.123.14   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8

  创建了一个名为nginx的deployment，然后将它修改为两个副本，随后又修改为三个副本

kubectl create deployment nginx --image=nginx:1.18
kubectl scale deployment nginx  --replicas=2
kubectl scale deployment nginx  --replicas=3

创建一个nodeport类型的service将该后端服务发布出去，经查询，可以看到端口30353是对外端口：

kubectl expose deployment nginx --type=NodePort --port=80 --target-port=80
[root@node1 ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP        117d
nginx        NodePort    10.96.24.248   <none>        80:30353/TCP   36s

此时，可以利用watch命令监听此服务：

watch curl -I http://192.168.123.11:30353/

OK，现在一切都还是正常的，那么，现在我们更新此deployment的镜像为1.20.1，这个时候会出现什么情况呢？

通过kubelet get events命令，可以发现，kubectl set 命令更改镜像不会对服务造成任何的影响，服务没有任何中断：

<invalid>   Normal    SuccessfulCreate         replicaset/nginx-648458674d   Created pod: nginx-648458674d-gldmc
<invalid>   Normal    Scheduled                pod/nginx-648458674d-gldmc    Successfully assigned default/nginx-648458674d-gldmc to node4
<invalid>   Normal    Pulling                  pod/nginx-648458674d-gldmc    Pulling image "nginx:1.20.1"
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Pulled                   pod/nginx-648458674d-gldmc    Successfully pulled image "nginx:1.20.1" in 55.174012251s (55.174015279s including waiting)
<invalid>   Normal    Created                  pod/nginx-648458674d-gldmc    Created container nginx
<invalid>   Normal    Started                  pod/nginx-648458674d-gldmc    Started container nginx
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              Scaled down replica set nginx-6888c79454 to 2
<invalid>   Normal    SuccessfulDelete         replicaset/nginx-6888c79454   Deleted pod: nginx-6888c79454-g24tx
<invalid>   Normal    Killing                  pod/nginx-6888c79454-g24tx    Stopping container nginx
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled up replica set nginx-648458674d to 2
<invalid>   Normal    SuccessfulCreate         replicaset/nginx-648458674d   Created pod: nginx-648458674d-kfgb4
<invalid>   Normal    Scheduled                pod/nginx-648458674d-kfgb4    Successfully assigned default/nginx-648458674d-kfgb4 to node4
<invalid>   Normal    Pulled                   pod/nginx-648458674d-kfgb4    Container image "nginx:1.20.1" already present on machine
<invalid>   Normal    Created                  pod/nginx-648458674d-kfgb4    Created container nginx
<invalid>   Normal    Started                  pod/nginx-648458674d-kfgb4    Started container nginx
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled down replica set nginx-6888c79454 to 1
<invalid>   Normal    SuccessfulDelete         replicaset/nginx-6888c79454   Deleted pod: nginx-6888c79454-dhhts
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled up replica set nginx-648458674d to 3
<invalid>   Normal    Killing                  pod/nginx-6888c79454-dhhts    Stopping container nginx
<invalid>   Normal    SuccessfulCreate         replicaset/nginx-648458674d   Created pod: nginx-648458674d-v4lwp
<invalid>   Normal    Scheduled                pod/nginx-648458674d-v4lwp    Successfully assigned default/nginx-648458674d-v4lwp to node4
<invalid>   Normal    Pulled                   pod/nginx-648458674d-v4lwp    Container image "nginx:1.20.1" already present on machine
<invalid>   Normal    Created                  pod/nginx-648458674d-v4lwp    Created container nginx
<invalid>   Normal    Started                  pod/nginx-648458674d-v4lwp    Started container nginx
<invalid>   Normal    Killing                  pod/nginx-6888c79454-dhhts    Stopping container nginx
<invalid>   Warning   FailedKillPod            pod/nginx-6888c79454-dhhts    error killing pod: failed to "KillContainer" for "nginx" with KillContainerError: "rpc error: code = Unknown desc = Error response from daemon: No such container: 0c27aa115f96cbc5d713a2d508310d20035021046b59878ffc50bb2bd6ee9271"
<invalid>   Normal    SuccessfulDelete         replicaset/nginx-6888c79454   Deleted pod: nginx-6888c79454-gcw24
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled down replica set nginx-6888c79454 to 0
<invalid>   Normal    Killing                  pod/nginx-6888c79454-gcw24    Stopping container nginx
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Scheduled                pod/nginx-6888c79454-tlczp    Successfully assigned default/nginx-6888c79454-tlczp to node4
<invalid>   Normal    SuccessfulCreate         replicaset/nginx-6888c79454   Created pod: nginx-6888c79454-tlczp
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              Scaled up replica set nginx-6888c79454 to 2
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Pulled                   pod/nginx-6888c79454-tlczp    Container image "nginx:1.18" already present on machine
<invalid>   Normal    Created                  pod/nginx-6888c79454-tlczp    Created container nginx
<invalid>   Normal    Started                  pod/nginx-6888c79454-tlczp    Started container nginx
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Scheduled                pod/nginx-6888c79454-6tfk2    Successfully assigned default/nginx-6888c79454-6tfk2 to node4
<invalid>   Normal    SuccessfulCreate         replicaset/nginx-6888c79454   Created pod: nginx-6888c79454-6tfk2
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              Scaled up replica set nginx-6888c79454 to 3
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.
<invalid>   Normal    Pulled                   pod/nginx-6888c79454-6tfk2    Container image "nginx:1.18" already present on machine
<invalid>   Normal    Created                  pod/nginx-6888c79454-6tfk2    Created container nginx
<invalid>   Normal    Started                  pod/nginx-6888c79454-6tfk2    Started container nginx
<invalid>   Normal    Starting                 node/node4                    Starting kubelet.

说明：以上是kubernetes的调度过程，关键的地方如下，表示scale逐步扩张新镜像的pod，缩减旧镜像的pod：

(combined from similar events): Scaled up replica set nginx-648458674d to 2

(combined from similar events): Scaled down replica set nginx-6888c79454 to 1
(combined from similar events): Scaled up replica set nginx-648458674d to 3
(combined from similar events): Scaled down replica set nginx-6888c79454 to 0

pod的最终状态如下：

[root@node1 ~]# kubectl get po -owide
NAME                     READY   STATUS    RESTARTS   AGE         IP             NODE    NOMINATED NODE   READINESS GATES
nginx-648458674d-gldmc   1/1     Running   0          <invalid>   10.244.41.18   node4   <none>           <none>
nginx-648458674d-kfgb4   1/1     Running   0          <invalid>   10.244.41.19   node4   <none>           <none>
nginx-648458674d-v4lwp   1/1     Running   0          <invalid>   10.244.41.20   node4   <none>           <none>

OK，这样的更新我们可以认为是一个平滑的，优雅的更新，而如果是通过部署清单yaml文件先删除deploment，在修改文件后重新创建deployment，这样的方式无疑是简单的，粗暴的，会导致服务中断的，此时我们认为这个更新不是平滑的，粗暴的一种更新方式。

那么，重启的话，只是省略掉修改部署清单yaml 文件这一步，同样的是粗暴的一种方式。

具体的操作也不就演示了，大体上就是kubectl delete -f 文件  然后kubelet apply -f文件  这种形式。

三，

更为精细的pod版本控制 kubectl rollout

以上介绍的两种pod管理方式，可以看出，并不是特别的精准，因为都是命令行的形式，所有更改并没有具体的体现，因此，平常的工作中，还是需要使用部署清单yaml文件的。

那么，kubectl rollout 命令是可以满足优雅重启和更新的，下面接上面的例子说明：

[root@node1 ~]# kubectl get po
NAME                     READY   STATUS    RESTARTS   AGE
nginx-648458674d-gldmc   1/1     Running   0          <invalid>
nginx-648458674d-kfgb4   1/1     Running   0          <invalid>
nginx-648458674d-v4lwp   1/1     Running   0          <invalid>

直接重启deployment控制器：

[root@node1 ~]# kubectl rollout restart deployment nginx
deployment.apps/nginx restarted

 

查看events：

命令：

kubectl get events -w

部分输出： 

<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled up replica set nginx-5fc8f974d9 to 1
<invalid>   Normal    SuccessfulCreate         replicaset/nginx-5fc8f974d9   Created pod: nginx-5fc8f974d9-9gn8z
<invalid>   Normal    Scheduled                pod/nginx-5fc8f974d9-9gn8z    Successfully assigned default/nginx-5fc8f974d9-9gn8z to node4
<invalid>   Normal    Pulled                   pod/nginx-5fc8f974d9-9gn8z    Container image "nginx:1.18" already present on machine
<invalid>   Normal    Created                  pod/nginx-5fc8f974d9-9gn8z    Created container nginx
<invalid>   Normal    Started                  pod/nginx-5fc8f974d9-9gn8z    Started container nginx
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled down replica set nginx-bf95bf86b to 2
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled up replica set nginx-5fc8f974d9 to 2
<invalid>   Normal    SuccessfulDelete         replicaset/nginx-bf95bf86b    Deleted pod: nginx-bf95bf86b-jsssl
<invalid>   Normal    Killing                  pod/nginx-bf95bf86b-jsssl     Stopping container nginx
<invalid>   Normal    SuccessfulCreate         replicaset/nginx-5fc8f974d9   Created pod: nginx-5fc8f974d9-nkcbd
<invalid>   Normal    Scheduled                pod/nginx-5fc8f974d9-nkcbd    Successfully assigned default/nginx-5fc8f974d9-nkcbd to node4
<invalid>   Normal    Pulled                   pod/nginx-5fc8f974d9-nkcbd    Container image "nginx:1.18" already present on machine
<invalid>   Normal    Created                  pod/nginx-5fc8f974d9-nkcbd    Created container nginx
<invalid>   Normal    Started                  pod/nginx-5fc8f974d9-nkcbd    Started container nginx
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled down replica set nginx-bf95bf86b to 1
<invalid>   Normal    SuccessfulDelete         replicaset/nginx-bf95bf86b    Deleted pod: nginx-bf95bf86b-98lpj
<invalid>   Normal    Killing                  pod/nginx-bf95bf86b-98lpj     Stopping container nginx
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled up replica set nginx-5fc8f974d9 to 3
<invalid>   Normal    SuccessfulCreate         replicaset/nginx-5fc8f974d9   Created pod: nginx-5fc8f974d9-xw64m
<invalid>   Normal    Scheduled                pod/nginx-5fc8f974d9-xw64m    Successfully assigned default/nginx-5fc8f974d9-xw64m to node4
<invalid>   Normal    Pulled                   pod/nginx-5fc8f974d9-xw64m    Container image "nginx:1.18" already present on machine
<invalid>   Normal    Created                  pod/nginx-5fc8f974d9-xw64m    Created container nginx
<invalid>   Normal    Started                  pod/nginx-5fc8f974d9-xw64m    Started container nginx
<invalid>   Normal    ScalingReplicaSet        deployment/nginx              (combined from similar events): Scaled down replica set nginx-bf95bf86b to 0
<invalid>   Normal    SuccessfulDelete         replicaset/nginx-bf95bf86b    Deleted pod: nginx-bf95bf86b-nfh5r

更新完毕后，pod的状态：

[root@node1 ~]# kubectl get po
NAME                    READY   STATUS    RESTARTS   AGE
nginx-bf95bf86b-98lpj   1/1     Running   0          <invalid>
nginx-bf95bf86b-jsssl   1/1     Running   0          <invalid>
nginx-bf95bf86b-nfh5r   1/1     Running   0          <invalid>

[root@node1 ~]# kubectl get replicasets.apps 
NAME               DESIRED   CURRENT   READY   AGE
nginx-5fc8f974d9   3         3         3       <invalid>
nginx-648458674d   0         0         0       <invalid>
nginx-6888c79454   0         0         0       <invalid>
nginx-bf95bf86b    0         0         0       <invalid>

此时看rollout的历史，应该是4个，输出可以看到和上面的rc是一一对应的关系：

[root@node1 ~]# kubectl rollout history deployment 
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
4         <none>

查看deployment的历史详情：

kubectl rollout history deployment nginx --revision=1
deployment.apps/nginx with revision #1
Pod Template:
  Labels:	app=nginx
	pod-template-hash=6888c79454
  Containers:
   nginx:
    Image:	nginx:1.18
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>


[root@node1 ~]# kubectl rollout history deployment nginx --revision=2
deployment.apps/nginx with revision #2
Pod Template:
  Labels:	app=nginx
	pod-template-hash=6888c79454
  Containers:
   nginx:
    Image:	nginx:1.18
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>


root@node1 ~]# kubectl rollout history deployment nginx --revision=3
deployment.apps/nginx with revision #3
Pod Template:
  Labels:	app=nginx
	pod-template-hash=bf95bf86b
  Annotations:	kubectl.kubernetes.io/restartedAt: 2023-11-18T17:06:24+08:00
  Containers:
   nginx:
    Image:	nginx:1.18
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>


[root@node1 ~]# kubectl rollout history deployment nginx --revision=4
deployment.apps/nginx with revision #4
Pod Template:
  Labels:	app=nginx
	pod-template-hash=5fc8f974d9
  Annotations:	kubectl.kubernetes.io/restartedAt: 2023-11-18T17:10:02+08:00
  Containers:
   nginx:
    Image:	nginx:1.18
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

升级镜像到1.20.1 ，生成新历史版本5：

[root@node1 ~]# kubectl apply -f nginx.yaml 
deployment.apps/nginx configured
[root@node1 ~]# kubectl rollout history deployment nginx --revision=5
deployment.apps/nginx with revision #5
Pod Template:
  Labels:	app=nginx
	pod-template-hash=6469d4d479
  Annotations:	kubectl.kubernetes.io/restartedAt: 2023-11-18T17:10:02+08:00
  Containers:
   nginx:
    Image:	nginx:1.20.1
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

回滚版本到2：

先查询历史版本

[root@node1 ~]# kubectl get rs -o wide
NAME               DESIRED   CURRENT   READY   AGE         CONTAINERS   IMAGES         SELECTOR
nginx-5fc8f974d9   0         0         0       <invalid>   nginx        nginx:1.18     app=nginx,pod-template-hash=5fc8f974d9
nginx-6469d4d479   3         3         3       <invalid>   nginx        nginx:1.20.1   app=nginx,pod-template-hash=6469d4d479
nginx-648458674d   0         0         0       <invalid>   nginx        nginx:1.20.1   app=nginx,pod-template-hash=648458674d
nginx-6888c79454   0         0         0       <invalid>   nginx        nginx:1.18     app=nginx,pod-template-hash=6888c79454
nginx-bf95bf86b    0         0         0       <invalid>   nginx        nginx:1.18     app=nginx,pod-template-hash=bf95bf86b
[root@node1 ~]# kubectl rollout history deployment nginx 
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
4         <none>
5         <none>


[root@node1 ~]# kubectl rollout history deployment nginx --revision=2
deployment.apps/nginx with revision #2
Pod Template:
  Labels:	app=nginx
	pod-template-hash=6888c79454
  Containers:
   nginx:
    Image:	nginx:1.18
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

回滚：

[root@node1 ~]# kubectl rollout undo deployment nginx --to-revision=2
deployment.apps/nginx rolled back

查看是否正确回滚:

[root@node1 ~]# kubectl get deployments.apps -owide
NAME    READY   UP-TO-DATE   AVAILABLE   AGE    CONTAINERS   IMAGES       SELECTOR
nginx   3/3     3            3           177m   nginx        nginx:1.18   app=nginx

那么，重启pod一般常见的就是删除pod后在重新创建，但，对于多副本的pod来说，会有服务中断的风险，更新一般也是暴力方式删除pod后，修改后在重新启动了，或者副本数先设置为0后，在恢复到原先的设置。

而如果想要服务不中断的，优雅的更新或者重启，首选还得是kubectl rollout 命令啦。

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

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

相关文章

RT-DETR算法优化改进：SCConv，空间和通道重建卷积 | CVPR2023 | 卷积变体大作战

RT-DETR算法优化改进：SCConv，空间和通道重建卷积 | CVPR2023 | 卷积变体大作战

💡💡💡本文改进：SCConv（空间和通道重建卷积），一个即插即用的架构单元，可以直接用来替代各种卷积神经网络中的标准卷积。 1）放入Neck RepC3后面； RT-DETR魔术师专栏介绍： https://blog.csdn.net/m0_63774211/category_12497375.html ✨✨✨魔改创新RT-DETR �…
阅读更多...
98.qt qml-使用曲线图综合示例、支持多种鼠标交互、支持百万数据显示(已适配黑白风格)

98.qt qml-使用曲线图综合示例、支持多种鼠标交互、支持百万数据显示(已适配黑白风格)

在上章我们只是简单实现了曲线图和折线图的显示： 79.qt qml-如何在QML中使用QCustomPlot之曲线/折线示例(已适配黑白风格)_qml 折线图_诺谦的博客-CSDN博客 所以本章实现综合示例、并添加多种功能如下所示： 详细显示：鼠标任意移动显示具体值内容鼠标右击: 弹出菜单栏，支持…
阅读更多...
华夏ERP打包手册

华夏ERP打包手册

Maven安装及环境配置 1.下载 浏览器搜索maven点击apache Maven 2.选择安装目录&#xff0c;注意不能有中文 3.环境变量配置 点击计算机右键属性>高级系统设置>环境变量 新建系统变量 MAVEN_HOME 变量值是安装目录 进入path点击新建点击编辑&#xff0c;写入% MAVEN_H…
阅读更多...
【Unity】单例模式及游戏声音管理类应用

【Unity】单例模式及游戏声音管理类应用

【Unity】单例模式及游戏声音管理类应用 描述 在日常游戏项目开发中&#xff0c;单例模式是一种常用的设计模式&#xff0c;它允许在应用程序的生命周期中只创建一个对象实例&#xff0c;并提供对该实例的全局访问点。通过使用单例模式&#xff0c;可以提高代码的可维护性和可…
阅读更多...
人工智能轨道交通行业周刊-第65期（2023.10.30-11.19）

人工智能轨道交通行业周刊-第65期（2023.10.30-11.19）

本期关键词&#xff1a;高铁自主创新、智慧城轨、调车司机、大模型垂直应用、大模型幻觉 1 整理涉及公众号名单 1.1 行业类 RT轨道交通人民铁道世界轨道交通资讯网铁路信号技术交流北京铁路轨道交通网上榜铁路视点ITS World轨道交通联盟VSTR铁路与城市轨道交通RailMetro轨道…
阅读更多...
PaddlePaddle：开源深度学习平台

PaddlePaddle：开源深度学习平台

深度学习作为人工智能领域的重要分支&#xff0c;正在全球范围内得到广泛应用。而在构建和训练深度学习模型时&#xff0c;选择一个高效、易用且功能强大的开源平台是至关重要的。PaddlePaddle&#xff08;即飞桨&#xff09;作为国内领先的深度学习平台&#xff0c;一直以来都…
阅读更多...
【代码随想录】算法训练计划23

【代码随想录】算法训练计划23

1、669. 修剪二叉搜索树 题目&#xff1a; 给你二叉搜索树的根节点 root &#xff0c;同时给定最小边界low 和最大边界 high。通过修剪二叉搜索树&#xff0c;使得所有节点的值在[low, high]中。修剪树 不应该 改变保留在树中的元素的相对结构 (即&#xff0c;如果没有被移除&…
阅读更多...
在 C# 程序中注入恶意 DLL

在 C# 程序中注入恶意 DLL

为什么 Windbg 附加到 C# 程序后&#xff0c;程序就处于中断状态了&#xff1f;它到底是如何实现的&#xff1f;其实简而言之就是线程的远程注入&#xff0c;这一篇就展开说一下。 实现原理 1. 基本思路 WinDbg 在附加进程的时候&#xff0c;会注入一个线程到 C# 进程 中&…
阅读更多...
设计模式-行为型模式-责任链模式

设计模式-行为型模式-责任链模式

一、什么是责任链模式 责任链模式是一种设计模式。在责任链模式里&#xff0c;很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递&#xff0c;直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求&…
阅读更多...
RobotFramework之如何使用数据驱动（十二）

RobotFramework之如何使用数据驱动（十二）

学习目录 引言 数据驱动是什么&#xff1f; 非驱动方式测试案例 通过添加Template模板的方式&#xff0c;实现数据驱动 将参数放在变量文件中&#xff0c;实现数据驱动 引言 大家平时在写接口或者UI自动化用例的时候&#xff0c;是否遇到这种情况&#xff1a; 写了很多条…
阅读更多...
手搓哈希表、列表、队列，只为了用C语言快速求解华容道游戏，我不是大佬，只是一个游戏算法爱好者

手搓哈希表、列表、队列，只为了用C语言快速求解华容道游戏，我不是大佬，只是一个游戏算法爱好者

背景 多年前曾经写过C语言求解华容道&#xff0c;当时没有用到哈希表&#xff0c;导致整个查重搜索数组过大&#xff0c;每次求解都得花上数分钟的时间&#xff0c;如今时过境迁&#xff0c;对数据结构和算法有了更深的理解&#xff0c;所以得把这一块补上了。(其实就是最近想…
阅读更多...
UE5制作场景时的小技巧和注意事项

UE5制作场景时的小技巧和注意事项

UE5制作场景时的小技巧和注意事项 一、场景相关 1.1灯光 1.1.1构建完光照，发现场景都是黑的 可能是所有灯光是静态灯光，把skylight改为动态，如果改完之后还是黑色的，那就在构建一次，就应该没问题了 1.1.2场景中有多个动态光会造成阴影闪烁 需要将skylight变为固定 1…
阅读更多...
CI/CD - jenkins

CI/CD - jenkins

目录 一、部署 1、简介 2、部署 二、配置 三、实时触发 四、自动化构建docker镜像 五、通过ssh插件交付任务 六、添加jenkins节点 七、RBAC 八、pipeline 九、jenkins结合ansible参数化构建 1、安装ansible 2、新建gitlab项目 3、jenkins新建项目playbook 一、部…
阅读更多...
linux进程之进程的优先级➕环境变量

linux进程之进程的优先级➕环境变量

文章目录 1.优先级的认识1.1优先级的介绍1.2初识优先级1.3ps指令1.4查看/修改进程的优先级1.5对优先级的认识1.6对进程的深一步理解 2.环境变量2.0环境变量相关的命令2.1环境变量的概念2.2常见/查看环境变量2.3环境变量的作用2.4修改环境变量1.将zombie可执行程序放到PATH现有的…
阅读更多...
IOS object-c大屏图表 PNChart 折线图 曲线图

IOS object-c大屏图表 PNChart 折线图 曲线图

折线图是排列在工作表的列或行中的数据可以绘制到折线图中。折线图可以显示随时间&#xff08;根据常用比例设置&#xff09;而变化的连续数据&#xff0c;因此非常适用于显示在相等时间间隔下数据的趋势。在折线图中&#xff0c;类别数据沿水平轴均匀分布&#xff0c;所有值数…
阅读更多...
​软考-高级-系统架构设计师教程（清华第2版）【第19章 大数据架构设计理论与实践 （P691~716）-思维导图】​

​软考-高级-系统架构设计师教程（清华第2版）【第19章 大数据架构设计理论与实践 （P691~716）-思维导图】​

软考-高级-系统架构设计师教程&#xff08;清华第2版&#xff09;【第19章 大数据架构设计理论与实践 &#xff08;P691~716&#xff09;-思维导图】 课本里章节里所有蓝色字体的思维导图
阅读更多...
AI Navigation导航系统_unity基础开发教程

AI Navigation导航系统_unity基础开发教程

AI Navigation导航系统 安装插件烘焙导航系统障碍物创建人物的AI导航动态障碍物 在unity编辑器中&#xff0c;有一个灰常好用的插件&#xff1a;Navigation。有了它1&#xff0c;你就可以实现人物自动走到你鼠标点击的位置&#xff0c;而且还会自动避开障碍物&#xff0c;下面就…
阅读更多...
7、传统CV之高斯滤波

7、传统CV之高斯滤波

这一节在上一节均值滤波的基础上，再进阶一下，了解一下什么是高斯滤波。 首先，如上一节所说，均值滤波是利用一个窗口在图片上滑动，每次都计算窗口内能看到的像素的平均值，然后将平均值作为滤波的输出，从而可以起到平滑图像、去噪点的作用。 有没有发现，此时并没有特别…
阅读更多...
SARAS-Net: Scale and Relation Aware Siamese Network for Change Detection

SARAS-Net: Scale and Relation Aware Siamese Network for Change Detection

SARAS-Net&#xff1a;用于变化检测的尺度和关系感知的孪生网络 AAAI Chao-Peng Chen, Jun-Wei Hsieh, Ping-Yang Chen, Yi-Kuan Hsieh, Bor-Shiun Wang 2023 摘要&#xff1a;变化检测(CD)旨在找出不同时间两幅图像之间的差异&#xff0c;并输出变化图来表示该区域是否发生了…
阅读更多...
C++17中std::variant的使用

C++17中std::variant的使用

可变参数模板类std::variant表示类型安全联合体(type-safe union)。std::variant的实例在任何给定时间要么保存其替代类型之一的值&#xff0c;要么在错误的情况下无值。 与union一样&#xff0c;如果std::variant保存某个对象类型T的值&#xff0c;则T的对象表示形式将直…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023