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

前言：

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=nginxpod-template-hash=6888c79454Containers:nginx:Image:	nginx:1.18Port:	<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=nginxpod-template-hash=6888c79454Containers:nginx:Image:	nginx:1.18Port:	<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=nginxpod-template-hash=bf95bf86bAnnotations:	kubectl.kubernetes.io/restartedAt: 2023-11-18T17:06:24+08:00Containers:nginx:Image:	nginx:1.18Port:	<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=nginxpod-template-hash=5fc8f974d9Annotations:	kubectl.kubernetes.io/restartedAt: 2023-11-18T17:10:02+08:00Containers:nginx:Image:	nginx:1.18Port:	<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=nginxpod-template-hash=6469d4d479Annotations:	kubectl.kubernetes.io/restartedAt: 2023-11-18T17:10:02+08:00Containers:nginx:Image:	nginx:1.20.1Port:	<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=nginxpod-template-hash=6888c79454Containers:nginx:Image:	nginx:1.18Port:	<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.mzph.cn/news/147989.shtml

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

相关文章

通付盾Web3专题 | KYT/AML：Web3合规展业的必要条件

通付盾Web3专题 | KYT/AML：Web3合规展业的必要条件

与传统证券一样&#xff0c;基于区块链技术发展出来的虚拟资产交易所经历了快速发展而缺乏有效监管的行业早期。除了科技光环加持的各种区块链项目方、造富神话之外&#xff0c;交易所遭到黑客攻击、内部偷窃作恶、甚至经营主体异常而致使投资人血本无归的案例亦令人触目惊心。…
阅读更多...
802.11-2020协议学习__专题__TxTime-Calculation__HR/DSSS

802.11-2020协议学习__专题__TxTime-Calculation__HR/DSSS

802.11-2020协议学习__专题__TxTime-Calculation__HR/DSSS 16.2.2 PPDU format16.2.2.1 General16.2.2.2 Long PPDU format16.2.2.3 Short PPDU format 16.3.4 HR/DSSS TXTIME calculation PREV&#xff1a; TBD NEXT&#xff1a; TBD 16.2.2 PPDU format 16.2.2.1 General 定…
阅读更多...
ubuntu 20.04安装 Anaconda教程

ubuntu 20.04安装 Anaconda教程

在安装Anaconda之前需要先安装ros(防止跟conda冲突&#xff0c;先装ros)。提前安装好cuda 和cudnn。 本博客参考&#xff1a;ubuntu20.04配置ros noetic和cuda&#xff0c;cudnn&#xff0c;anaconda&#xff0c;pytorch深度学习的环境 安装完conda后&#xff0c;输入: pyth…
阅读更多...
Mysql -常见函数

Mysql -常见函数

目录 字符串函数 数值函数 日期函数 流程函数 字符串函数 -- 拼接 SELECT CONCAT(Hello, World); -- 小写 SELECT LOWER(Hello); -- 大写 SELECT UPPER(Hello); -- 左填充 SELECT LPAD(01, 5, -); -- 右填充 SELECT RPAD(01, 5, -); -- 去除空格 SELECT TRIM( Hello World )…
阅读更多...
Flume学习笔记（2）—— Flume进阶

Flume学习笔记（2）—— Flume进阶

Flume进阶 Flume 事务 事务处理流程如下&#xff1a; Put doPut&#xff1a;将批数据先写入临时缓冲区putListdoCommit&#xff1a;检查channel内存队列是否足够合并。doRollback&#xff1a;channel内存队列空间不足&#xff0c;回滚数据 Take doTake&#xff1a;将数据取…
阅读更多...
数学建模 | 灰色预测原理及python实现

数学建模 | 灰色预测原理及python实现

目录 一、灰色预测的原理 二、灰色预测的应用及python实现 一、灰色预测的原理 灰色预测是以灰色模型为基础&#xff0c;灰色模型GM(n,h)是微分方程模型&#xff0c;可用于描述对象做长期、连续、动态的反应。其中&#xff0c;n代表微分方程式的阶数&#xff0c;h代表微分方…
阅读更多...
Spring Framework IOC依赖查找 - 按名称查找解析

Spring Framework IOC依赖查找 - 按名称查找解析

IoC按名称查找共分为三类&#xff1a; 按名称按类型按集合 按名称查找 在Spring Framework中&#xff0c;实时加载和延迟加载是指在容器启动时是否立即实例化bean的不同策略。下面我们将分别介绍这两种加载方式及其应用场景。 tips: 当涉及到懒加载和延时加载时&#xff0…
阅读更多...
windows排除故障工具pathping、MTR、sysinternals

windows排除故障工具pathping、MTR、sysinternals

pathping 基本上可以认为它是ping和tracert的功能合体。 pathping首先对目标执行tracert&#xff0c;然后使用ICMP对每一跳进行100次ping操作。 如图&#xff0c;是一个对8.8.8.8进行pathing操作。 MTR MTR是另一个多工具合体工具。 winmtr是mtr的windows版本。 这个工具…
阅读更多...
vscode设置latex

vscode设置latex

vscode配置latex 1.安装vscode,并添加环境变量路径 2.安装latex,bin文件夹添加到环境变量路径 3.vscode安装插件 4.vscode->文件->首选项->显示配置内容->setting.json文件&#xff0c;查看其位置目录&#xff0c;通过我的电脑找到此文件&#xff08;不要使用v…
阅读更多...
OpenCV快速入门：图像形态学操作

OpenCV快速入门：图像形态学操作

文章目录 前言一、图像形态学基础1.1 背景介绍1.2 像素距离1.2.1 什么是像素距离&#xff1f;1.2.2 常见的像素距离度量方法1.2.3 计算像素距离的代码实现 1.3 图像连通性1.3.1 什么是图像连通性&#xff1f;1.3.2 连通类型1.3.3 连通组件标记1.3.4 连通性在图像处理中的应用 1…
阅读更多...
在 el-table 中嵌入 el-checkbox el-input el-upload 多组件，实现复杂业务场景

在 el-table 中嵌入 el-checkbox el-input el-upload 多组件，实现复杂业务场景

由于业务场景的复杂性&#xff0c;需实现&#xff1a;在 el-table 表格中 嵌入 el-checkbox 多选框 及 el-input 输入框 及 el-upload 上传组件 &#xff0c;先附上实现效果图。 从图片可以看出其实就是一个规格可以带有多个属性的规格表&#xff0c;实现此效果需涉及到的知识点…
阅读更多...
【机器学习基础】对数几率回归（logistic回归）

【机器学习基础】对数几率回归（logistic回归）

&#x1f680;个人主页&#xff1a;为梦而生~ 关注我一起学习吧&#xff01; &#x1f4a1;专栏&#xff1a;机器学习 欢迎订阅&#xff01;后面的内容会越来越有意思~ &#x1f4a1;往期推荐&#xff1a; 【机器学习基础】机器学习入门&#xff08;1&#xff09; 【机器学习基…
阅读更多...
ADS村田电感.mod（spice netlist文件）和.s2p模型导入与区别

ADS村田电感.mod（spice netlist文件）和.s2p模型导入与区别

ADS村田电感.mod&#xff08;spice netlist文件&#xff09;和.s2p模型导入与区别 简介环境过程s2pspice netlist&#xff08;.mod文件&#xff09;导入和结果对比 简介 记录了ADS村田电感.mod&#xff08;spice netlist文件&#xff09;和.s2p模型导入与区别 环境 ADS2020 …
阅读更多...
什么是UV贴图？

什么是UV贴图？

UV 是与几何图形的顶点信息相对应的二维纹理坐标。UV 至关重要&#xff0c;因为它们提供了表面网格与图像纹理如何应用于该表面之间的联系。它们基本上是控制纹理上哪些像素对应于 3D 网格上的哪个顶点的标记点。它们在雕刻中也很重要。 为什么UV映射很重要&#xff1f; 默认情…
阅读更多...
opencv(2): 视频采集和录制

opencv(2): 视频采集和录制

视频采集 相关API VideoCapture()cap.read()&#xff1a; 返回两个值&#xff0c;第一个参数&#xff0c;如果读到frame&#xff0c;返回 True. 第二个参数为相应的图像帧。cap.release() VideoCapture cv2.VideoCapture(0) 0 表示自动检测&#xff0c;如果在笔记本上运行&…
阅读更多...
助力水泥基建裂痕自动化巡检，基于yolov5融合ASPP开发构建多尺度融合目标检测识别系统

助力水泥基建裂痕自动化巡检，基于yolov5融合ASPP开发构建多尺度融合目标检测识别系统

道路场景下的自动化智能巡检、洞体场景下的壁体类建筑缺陷自动检测识别等等已经在现实生活中不断地落地应用了&#xff0c;在我们之前的很多博文中也已经有过很多相关的实践项目经历了&#xff0c;本文的核心目的是想要融合多尺度感受野技术到yolov5模型中以期在较低参数量的情…
阅读更多...
计算属性与watch的区别,fetch与axios在vue中的异步请求,单文本组件使用,使用vite创建vue项目,组件的使用方法

计算属性与watch的区别,fetch与axios在vue中的异步请求,单文本组件使用,使用vite创建vue项目,组件的使用方法

7.计算属性 7-1计算属性-有缓存 模板中的表达式虽然很方便,但是只能做简单的逻辑操作,如果在模版中写太多的js逻辑,会使得模板过于臃肿,不利于维护,因此我们推荐使用计算属性来解决复杂的逻辑 <!DOCTYPE html> <html lang"en"> <head><meta …
阅读更多...
Go vs Rust：文件上传性能比较

Go vs Rust：文件上传性能比较

在本文中&#xff0c;主要测试并比较了Go—Gin和Rust—Actix之间的多部分文件上传性能。 设置 所有测试都在配备16G内存的 MacBook Pro M1 上执行。 软件版本为&#xff1a; Go v1.20.5Rust v1.70.0 测试工具是一个基于 libcurl 并使用标准线程的自定义工具&#xff0c;能…
阅读更多...
【性能】如何计算 Web 页面的 FP 指标

【性能】如何计算 Web 页面的 FP 指标

什么是 FP 指标 FP (First Paint) 为首次渲染的时间点&#xff0c;在性能统计指标中&#xff0c;从用户开始访问 Web 页面的时间点到 FP 的时间点这段时间可以被视为 白屏时间&#xff0c;也就是说在用户访问 Web 网页的过程中&#xff0c;FP 时间点之前&#xff0c;用户看到的…
阅读更多...
KeyarchOS的CentOS迁移实践：使用操作系统迁移工具X2Keyarch V2.0

KeyarchOS的CentOS迁移实践：使用操作系统迁移工具X2Keyarch V2.0

KeyarchOS的CentOS迁移实践&#xff1a;使用操作系统迁移工具X2Keyarch V2.0 作者&#xff1a; 猫头虎博主 文章目录 KeyarchOS的CentOS迁移实践&#xff1a;使用操作系统迁移工具X2Keyarch V2.0&#x1f405;摘要引言1. 迁移前的精心准备1.1 系统环境介绍1.2 深度数据验证1.2.…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023