k8s pod生命周期、初始化容器、鉤子函數、容器探測、重啟策略

pod結構

在這里插入圖片描述

Pause容器

Pause容器是每個Pod都會有的一個根容器，它的作用有兩個

  • 可以以它為根據，評估整個pod的健康狀態
  • 可以在根容器上設置IP地址，其他容器都以此IP（Pod IP），以實現Pod內部的網絡通信，
    這里是Pod內部的通訊，Pod之間的通訊采用虛擬二層網絡技術來實現，我們當前環境用的是Flannel

pod配置

apiVersion: v1 #必選，版本號，例如v1
king: Pod         #必選，資源類型，例如Pod
metadata:name: string  #必選，pod名稱namespace: string #pod所屬的命名空間，默認為"default"labels:- name: string
spec:  #必選，pod中容器的詳細定義containers:  #必選，pod中容器列表- name: string   #必選，容器名稱image: string  #必選，容器鏡像名稱imagePullPolicy: [Always|Never|IfNotPresent] #獲取鏡像的策略command: [string]  #容器的啟動命令列表，如不指定，使用打包時使用的啟動命令args: [string]  #容器的啟動命令參數列表workingDir: string  #容器的工作目錄volumeMounts: #掛載到容器內部的存儲卷配置- name: string  #引用pod定義的共享數據卷的名稱，需用volumes[]部分定義的卷名mountPath: string  #存儲卷在容器內mount的絕對路徑，應少于512字符readOnly: boolean  #是否為只讀模式ports:  3需要暴露的端口庫號列表- name: string  #端口的名稱containerPort: int  #容器需要監聽的端口號hostPort: int  #容器所在主機需要監聽的端口號，默認與Container相同protocol: string  #端口協議，支持TCP和UDP，默認TCP    env:  #容器運行前需要設置的環境變量列表    - name: string  #環境變量名稱      value: string  #環境變量的值    resources:  #資源限制和請求的設置      limits: #資源限制的設置......

pod的資源配置非常繁多，因此要一個一個記住是不現實的

所以k8s提供了能夠查看每種資源的配置項的命令

kubectl explain 資源類型      #查看某種資源可以配置的一級屬性
kubectl explain 資源類型.屬性   #查看屬性的子屬性

查看pod資源的metadata的子屬性

kubectl explain pod.metadata

在k8s中所有資源的一級屬性都是一樣的，主要包含5部分：

  • apiVersion 版本，由k8s內部定義，版本號可以用 kubectl api-versions查詢到
  • kind 類型，由k8s內部定義，可以用 kubectl api-resources查詢到
  • metadata 元數據，主要是資源標識和說明，常用的有name，namespace，labels等
  • spec 描述，這是配置中最重要的一部分，里面是對各種資源配置的詳細描述
  • status 狀態信息，里面的內容不需要定義，由k8s自動生成

在上面的屬性中，spect是接下來研究的重點，繼續看下它的常見子屬性：

  • containers <[]Object> 容器列表，用于定義容器的詳細信息
  • nodeName 根據nodename的值將pod調度到指定的Node節點上
  • nodeSelector <map[]> 根據NodeSelector中定義的信息選擇將該Pod調度到包含這些label的node上
  • hostNetwork 是否使用主機網絡模式，默認為false，如果設置為true，表示使用宿主機網絡
  • volumes <[]Object> 存儲卷，用于定義Pod上面掛載的存儲信息
  • restartPolicy 重啟策略，表示Pod在遇到故障的時候的處理策略;

pod生命周期

pod對象從創建到終止的這段時間范圍被稱為生命周期，它主要包含以下幾個過程：

  1. pod創建過程
  2. 運行初始化容器（init container）過程
  3. 運行主容器（main container）
    • 容器啟動后鉤子（post start）、容器終止前鉤子（pre stop）
    • 容器的存活性探測（liveness probe）、就緒性探測（readiness probe）
  4. pod終止過程
    在這里插入圖片描述

生命周期中出現的5種狀態

狀態值狀態名稱描述
  1. Pending|掛起|apiServer已經創建了pod資源對象，但它尚未被調度完成或者仍處于下載鏡像的過程中；
  2. Running|運行中|pod已經被調度至某節點，并且所有容器都已經被kubelet創建完成；
  3. Succeeded|成功|pod中的所有容器都已經成功終止并且不會被重啟
  4. Failed|失敗|所有容器都已終止，但至少有一個容器終止失敗，即容器返回了非0值的退出狀態；
  5. Unknown|未知|apiServer無法正常獲取到pod對象的狀態信息，通常由網絡通訊失敗所導致；

pod創建過程

  1. 用戶通過kubectl或其他api客戶端提交需要創建的pod信息給apiServer
  2. apiServer開始生成pod對象的信息，并將信息存入etcd，然后返回確認信息至客戶端
  3. apiServer開始反映etcd中的pod對象的變化，其它組件使用watch機制來跟蹤檢查apiServer上的變動
  4. scheduler發現有新的pod對象要創建，開始為Pod分配主機并將結果信息更新至apiServer
  5. node節點上的kubelet發現有pod調度過來，嘗試調用docker啟動容器，并將結果回送至apiServer
  6. apiServer將接收到的pod狀態信息存入etcd中

pod終止過程

  1. 用戶向apiServer發送刪除pod對象的命令
  2. apiServcer中的pod對象信息會隨著時間的推移而更新，在寬限期內（默認30s），pod被視為dead（死亡）
  3. 將pod標記為terminating（正在刪除中）狀態
  4. kubelet在監控到pod對象轉為terminating（正在刪除中）狀態的同時啟動pod關閉過程
  5. 端點控制器監控到pod對象的關閉行為時將其從所有匹配到此端點的service資源的端點列表中移除
  6. 如果當前pod對象定義了preStop鉤子處理器，則在其標記為terminating（正在刪除中）后即會以同步的方式啟動執行
  7. pod對象中的容器進程收到停止信號
  8. 寬限期結束后，若pod中還存在仍在運行的進程，那么pod對象會收到立即終止的信號
  9. kubelet請求apiServer將此pod資源的寬限期設置為0從而完成刪除操作，此時pod對于用戶已不可見

初始化容器

Pod能夠具有多個容器，應用運行在容器里面，但是它也可能有一個或多個先于應用容器啟動的 Init容器
Init 容器與普通的容器非常像，除了如下兩點：

  1. Init 容器總是運行到成功完成為止
  2. 每個 Init 容器都必須在下一個 Init 容器啟動之前成功完成

如果 Pod 的 Init 容器失敗， Kubernetes 會不斷地重啟該 Pod ，直到 Init 容器成功為止。然而，如果 Pod 對應的 restartPolicy（重啟策略） 為 Never，它不會重新啟動。

init容器能夠做什么呢？

  1. Init 容器可以包含一些安裝過程中應用容器中不存在的實用工具或個性化代碼。
  2. Init 容器可以安全地運行這些工具，避免這些工具導致應用鏡像的安全性降低。
  3. 應用鏡像的創建者和部署者可以各自獨立工作，而沒有必要聯合構建一個單獨的應用鏡像。
  4. Init 容器能以不同于Pod內應用容器的文件系統視圖運行。因此，Init容器 可具有訪問 Secrets 的權限，而應用容器不能夠訪問。
  5. 由于 Init 容器必須在應用容器啟動之前運行完成，因此 Init 容器提供了一種機制來阻塞或延遲應用容器的啟動，直到滿足了一組先決條件。一旦前 置條件滿足，Pod內的所有的應用容器會并行啟動。

初始化容器配置

在spec下添加initContainers子項即可

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPinitContainers:- name: init-mysqlimage: busybox:1.3.0command: ["/bin/sh","-c","while true;do echo hello;sleep 1;done"]

鉤子函數

類似spring的AOP功能，在主容器啟動后和容器終止前執行一些自定義的邏輯；

  • postStart：容器創建之后執行，如果postStart鉤子函數失敗了會重啟容器；
  • preStop：容器終止之前執行，執行完成之后容器將成功終止，在其完成之前會阻塞刪除容器的操作

鉤子函數支持以下三種方式定義動作

第一種：exec命令

在容器內執行一次命令，這種方式使用比較頻繁，一般都是使用這種方式作為鉤子函數；

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器啟動后鉤子exec:command: ["/bin/bash","-c","echo postStart > /root/post.txt"]preStop:  # 主容器終止前鉤子exec:command: ["/bin/bash","-c","echo postStart > /root/post.txt"]

也可以這樣

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器啟動后鉤子exec:command: - cat- post.txtpreStop:  # 主容器終止前鉤子exec:command: - cat- post.txt

第二種：tcpSocket

以下列子是在主容器啟動后嘗試去連接8080端口，在主容器終止前去連接8081端口

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器啟動后鉤子tcpSocket: port: 8080preStop:  # 主容器終止前鉤子tcpSocket: port: 8081

第三種：httpGet

以下列子是在主容器啟動后會去訪問鏈接http://192.168.1.101:8080/login，在主容器終止前去訪問鏈接http://192.168.1.101:8080/logout;

spec: containers: - image: nginx:1.17.1name: nginx-containerports: - name: "port-name"containerPort: 8080protocol: TCPlifecycle:postStart:  # 主容器啟動后鉤子httpGet: path: /login             # Url地址port: 8080          # 端口host: 192.168.1.101 # 主機地址schema: HTTP # 支持的協議，http或httpspreStop:  # 主容器終止前鉤子httpGet: path: /logout            # Url地址port: 8080          # 端口host: 192.168.1.101 # 主機地址schema: HTTP # 支持的協議，http或https

容器探測

容器探測用于檢測容器中的應用實例是否正常工作，是保障業務可用性的一種傳統機制，如果經過探測，實例的狀態不符合預期，那么kubernetes就會把該問題實例“摘除”，不承擔業務流量，k8s提供了兩種探針來實現容器探測

  • liveness probes ： 存活性探針，用于檢測應用實例當前是否處于正常運行狀態，如果不是，k8s會重啟容器
  • readiness probes ： 就緒性探針，用于檢測應用實例當前是否可以接收請求，如果不能，k8s不會轉發流量

liveness probes決定是否重啟容器，readiness probes覺得是否將請求轉發給容器

存活性探針和就緒性探針都支持三種探測方式，其實就是使用了鉤子函數,

第一種 exec

在容器內執行一次命令，如果命令執行的退出碼為0，則認為程序正常， 否則不正常；
仔細看看，跟上面的鉤子函數差不多，鉤子函數用的是lifecycle，而探針用的是livenessProbe或者readinessProbe

# 存活性探針
.....
spec:containers:- image: nginx:1.17.1name: nginx-containerlivenessProbe:   # 存活性探針initialDelaySeconds: 5 # 容器啟動后等待多少秒執行第一次探測timeoutSeconds: 10     # 探測超時時間，默認1秒，默認1秒failureThreshold: 10   # 連續探測失敗多少次才被認定為失敗，默認是3，最小值是1successThreshold: 1    # 連續探測成功多少次才被認定為成功，默認是1exec:command: - cat- post.txt
......# 就緒性探針
.....
spec:containers:- image: nginx:1.17.1name: nginx-containerreadinessProbe:   # 就緒性探針initialDelaySeconds: 5 # 容器啟動后等待多少秒執行第一次探測timeoutSeconds: 10     # 探測超時時間，默認1秒，默認1秒failureThreshold: 10   # 連續探測失敗多少次才被認定為失敗，默認是3，最小值是1successThreshold: 1    # 連續探測成功多少次才被認定為成功，默認是1exec:command: - cat- post.txt
......

第二種 tcpSocket

將會嘗試訪問容器的端口，如果能建立連接，則認為程序正常，否則不正常
仔細看看，跟上面的鉤子函數差不多，鉤子函數用的是lifecycle，而探針用的是livenessProbe或者readinessProbe

# 存活性探針
......
spec:containers:- image: nginx:1.17.1name: nginx-containerlivenessProbe:   # 存活性探針initialDelaySeconds: 5 # 容器啟動后等待多少秒執行第一次探測timeoutSeconds: 10     # 探測超時時間，默認1秒，默認1秒failureThreshold: 10   # 連續探測失敗多少次才被認定為失敗，默認是3，最小值是1successThreshold: 1    # 連續探測成功多少次才被認定為成功，默認是1tcpSocket: port: 8080
......# 就緒性探針
......
spec:containers:- image: nginx:1.17.1name: nginx-containerreadinessProbe:  # 就緒性探針initialDelaySeconds: 5 # 容器啟動后等待多少秒執行第一次探測timeoutSeconds: 10     # 探測超時時間，默認1秒，默認1秒failureThreshold: 10   # 連續探測失敗多少次才被認定為失敗，默認是3，最小值是1successThreshold: 1    # 連續探測成功多少次才被認定為成功，默認是1tcpSocket: port: 8080
......

第三種 httpGet

調用容器內web應用的url，如果返回的狀態碼在200 ~ 399之間，則認為程序正常，否則不正常
仔細看看，跟上面的鉤子函數差不多，鉤子函數用的是lifecycle，而探針用的是livenessProbe或者readinessProbe

# 存活性探針
......
spec:containers:- image: nginx:1.17.1name: nginx-container # 存活性探針livenessProbe:  initialDelaySeconds: 5 # 容器啟動后等待多少秒執行第一次探測timeoutSeconds: 10     # 探測超時時間，默認1秒，默認1秒failureThreshold: 10   # 連續探測失敗多少次才被認定為失敗，默認是3，最小值是1successThreshold: 1    # 連續探測成功多少次才被認定為成功，默認是1httpGet: path: /login             # Url地址port: 8080          # 端口host: 192.168.1.101 # 主機地址schema: HTTP # 支持的協議，http或https
......# 就緒性探針
......
spec:containers:- image: nginx:1.17.1name: nginx-containerreadinessProbe:   # 就緒性探針initialDelaySeconds: 5 # 容器啟動后等待多少秒執行第一次探測timeoutSeconds: 10     # 探測超時時間，默認1秒，默認1秒failureThreshold: 10   # 連續探測失敗多少次才被認定為失敗，默認是3，最小值是1successThreshold: 1    # 連續探測成功多少次才被認定為成功，默認是1httpGet: path: /login             # Url地址port: 8080          # 端口host: 192.168.1.101 # 主機地址schema: HTTP # 支持的協議，http或https
......

重啟策略

存活性探針對容器進行探測時，如果出現了問題，k8s就會對容器所在的pod進行重啟，這是由pod的重啟策略決定的，pod的重啟策略由三種

  • Always：（默認值）總是重啟容器
  • OnFailure： 容器終止運行且退出碼不為0時重啟
  • Never ： 不論狀態如何，都不重啟

配置重啟策略

spec:restartPolicy: Always

重啟等待時間

重啟策略適用pod中的所有容器，如果是第一次重啟，在需要重啟時將會立即重啟，如果不是第一次重啟，那么將會延長一段時間后重啟，這是防止服務器資源都用來重啟所做的一些優化，

  1. 第一次重啟，立即重啟
  2. 第二次重啟，延長10s重啟
  3. 第三次重啟，延長20s重啟，
  4. 第四次重啟，延長40s重啟
  5. 第五次重啟，延長80s重啟
  6. 第六次重啟，延長160s重啟
  7. 第七次或七次以上重啟，都延長300s重啟

pod調度

什么是調度

默認情況下，一個pod在哪個node節點上運行，是通過scheduler組件采用相應的算法計算出來的，這個過程是不受人工控制的；

調度規則

但是在實際使用中，我們想控制某些pod定向到達某個節點上，應該怎么做呢？其實k8s提供了四類調度規則

調度方式描述
自動調度通過scheduler組件采用相應的算法計算得出運行在哪個節點上
定向調度運行到指定的node節點上，通過NodeName、NodeSelector實現
親和性調度跟誰關系好就調度到哪個節點上
1、nodeAffinity ：節點親和性，調度到關系好的節點上
2、podAffinity：pod親和性，調度到關系好的pod所在的節點上
3、PodAntAffinity：pod反清河行，調度到關系差的那個pod所在的節點上
污點（容忍）調度污點是站在node的角度上的，比如果nodeA有一個污點，大家都別來，此時nodeA會拒絕master調度過來的pod

定向調度

指的是利用在pod上聲明nodeName或nodeSelector的方式將pod調度到指定的pod節點上，因為這種定向調度是強制性的，所以如果node節點不存在的話，也會向上面進行調度，只不過pod會運行失敗；

定向調度-> nodeName

nodeName 是將pod強制調度到指定名稱的node節點上，這種方式跳過了scheduler的調度邏輯，直接將pod調度到指定名稱的節點上，配置文件內容如下

apiVersion: v1  # 版本號
kind: Pod  # 資源類型
metadata: name: pod-namenamespace: dev
spec: containers: - image: nginx:1.17.1name: nginx-containernodeName: node1  # 調度到node1節點上
定向調度 -> NodeSelector

NodeSelector是將pod調度到添加了指定label標簽的node節點上，它是通過k8s的label-selector機制實現的，也就是說，在創建pod之前，會由scheduler用matchNodeSelecto調度策略進行label標簽的匹配，找出目標node，然后在將pod調度到目標node；

要實驗NodeSelector，首先得給node節點加上label標簽

kubectl label nodes node1 nodetag=node1

配置文件內容如下

apiVersion: v1  # 版本號
kind: Pod  # 資源類型
metadata: name: pod-namenamespace: dev
spec: containers: - image: nginx:1.17.1name: nginx-containernodeSelector: nodetag: node1  # 調度到具有nodetag=node1標簽的節點上

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/diannao/93790.shtml
繁體地址，請注明出處：http://hk.pswp.cn/diannao/93790.shtml
英文地址，請注明出處：http://en.pswp.cn/diannao/93790.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

Redis：緩存雪崩、穿透、擊穿的技術解析和實戰方案

Redis：緩存雪崩、穿透、擊穿的技術解析和實戰方案

&#x1f6a8; 1、簡述 隨著系統規模擴大&#xff0c;Redis 緩存被廣泛用于數據預熱、熱點數據防護和高并發系統優化。然而在高并發環境中&#xff0c;緩存雪崩、穿透、擊穿等問題若處理不當&#xff0c;可能導致系統雪崩式崩潰。 本文從原理、原因出發&#xff0c;結合實際項目…
閱讀更多...
前端-html+CSS基礎到高級(二)html基礎

前端-html+CSS基礎到高級(二)html基礎

一、 為什么需要Web標準 瀏覽器差異問題&#xff1a;五大主流瀏覽器&#xff08;IE、Chrome、Firefox、Safari等&#xff09;使用不同渲染引擎&#xff0c;導致相同代碼解析效果存在差異。為什么需要Web標準&#xff1f;不同瀏覽器的渲染引擎不同&#xff0c;對于相同代碼解析的…
閱讀更多...
前端-移動Web-day2

前端-移動Web-day2

目錄 1、空間-平移 2、視距 3、空間旋轉-Z軸 4、空間旋轉-X軸 5、空間旋轉-Y軸 6、立體呈現 7、案例-3D導航 8、空間-縮放 9、動畫-體驗 10、動畫-實現步驟 11、animation復合屬性 12、animation拆分寫法 13、案例-走馬燈 14、精靈動畫 15、多組動畫 16、案例-…
閱讀更多...
力扣1116題：用C++實現多線程交替輸出零、偶數、奇數

力扣1116題：用C++實現多線程交替輸出零、偶數、奇數

一、題目解讀 力扣1116題要求設計一個類&#xff0c;實現三個線程交替輸出數字&#xff1a;一個線程輸出連續的0&#xff0c;一個線程輸出連續的偶數&#xff0c;另一個線程輸出連續的奇數。輸入參數n為總輸出次數&#xff08;每個線程各輸出n次&#xff09;&#xff0c;輸出需…
閱讀更多...
C語言（07）——原碼 補碼 反碼 （超絕詳細解釋）

C語言（07）——原碼 補碼 反碼 （超絕詳細解釋）

本文的內容通下面這篇文章有著緊密的聯系&#xff0c;讀者可以選擇性閱讀 C語言————二、八、十、十六進制的相互轉換-CSDN博客 相關的C語言練習題和思維鍛煉可以參考以下文章 C語言————練習題冊&#xff08;答案版&#xff09;-CSDN博客 C語言————斐波那契數列…
閱讀更多...
磁盤壞道檢測工具在美國服務器硬件維護中的使用規范

磁盤壞道檢測工具在美國服務器硬件維護中的使用規范

磁盤壞道檢測工具在美國服務器硬件維護中的使用規范在服務器硬件維護領域&#xff0c;磁盤壞道檢測工具是保障數據安全的第一道防線。本文將系統介紹美國數據中心環境下專業級磁盤診斷方案的實施標準&#xff0c;重點解析SMART檢測、壞道修復算法與自動化運維流程的整合方法&am…
閱讀更多...
【n8n】如何跟著AI學習n8n【03】：HTTPRequest節點、Webhook節點、SMTP節點、mysql節點

【n8n】如何跟著AI學習n8n【03】：HTTPRequest節點、Webhook節點、SMTP節點、mysql節點

前言 n8n的系統性學習&#xff0c;對各知識點地毯式學習&#x1f50d;~ 前面課程 定制n8n的AI老師&#xff0c;有AI老師制定學習大綱&#xff0c;參考之前的文檔&#xff08;本系列n8n學習大綱&#xff0c;也在這里&#xff09;&#xff1a; 【n8n】如何跟著AI學習n8n_01&a…
閱讀更多...
Vue 的雙向數據綁定原理

Vue 的雙向數據綁定原理

Vue 的雙向數據綁定是通過 數據劫持 發布-訂閱模式 實現的&#xff0c;具體分為以下三個關鍵機制&#xff1a;1. 數據劫持&#xff08;響應式系統&#xff09; Vue 使用 Object.defineProperty&#xff08;Vue 2&#xff09;或 Proxy&#xff08;Vue 3&#xff09;監聽數據變化…
閱讀更多...
【基于C# + HALCON的工業視覺系統開發實戰】三十五、金屬表面劃傷檢測：強反光場景解決方案

【基于C# + HALCON的工業視覺系統開發實戰】三十五、金屬表面劃傷檢測：強反光場景解決方案

摘要：針對金屬表面強反光導致劃傷檢測準確率低的行業痛點，本文提出基于光度立體法的工業視覺檢測方案。系統采用“硬件抗反光+算法重建”雙策略，硬件上通過可編程分區環形光源、偏振鏡頭與高動態相機構建成像系統；算法上利用四方向光源序列圖像重建表面法向量與高度場，實現…
閱讀更多...
為什么bert是雙向transformer

為什么bert是雙向transformer

BERT 是雙向 Transformer&#xff0c;這是它的一個核心創新點。下面我從 技術原理、與傳統 Transformer 的區別、以及雙向性的實際意義 來詳細解釋為什么 BERT 被稱為“雙向 Transformer”。一、什么是 BERT 的“雙向”&#xff1f;在 BERT 的論文中&#xff0c;雙向的原文是 &…
閱讀更多...
vue中使用Canvas繪制波形圖和頻譜圖（支持.pcm）

vue中使用Canvas繪制波形圖和頻譜圖（支持.pcm）

實現方式一&#xff1a; vue中使用wavesurfer.js繪制波形圖和頻譜圖 安裝colorMap&#xff1a; npm install --save colormap1、單個頻譜圖 效果&#xff1a; 源碼&#xff1a; <template><div class"spectrogram-container"><canvas ref"ca…
閱讀更多...
【Python系列】Flask 應用中的主動垃圾回收

【Python系列】Flask 應用中的主動垃圾回收

博客目錄一、Python 內存管理基礎二、Flask 中手動觸發 GC 的基本方法三、高級 GC 策略實現1. 使用裝飾器進行請求級別的 GC2. 定期 GC 的實現四、Flask 特有的 GC 集成方式1. 使用 teardown_request 鉤子2. 結合應用上下文管理五、智能 GC 策略六、注意事項與最佳實踐七、替代…
閱讀更多...
Linux和shell

Linux和shell

最快入門的方式是使用蘋果系統。此外&#xff0c;累計補充學習&#xff1a;一、目錄結構/bin&#xff0c;二進制文件 /boot&#xff0c;啟動文件 /dev&#xff0c;設備文件 /home&#xff0c;主目錄&#xff0c;一般外接包、安裝包放在這里 /lib&#xff0c;庫文件 /opt&#x…
閱讀更多...
告別內存泄漏：你的Rust語言30天征服計劃

告別內存泄漏：你的Rust語言30天征服計劃

歡迎踏上Rust學習之旅&#xff01;第一周&#xff1a;奠定基礎 (Week 1: Laying the Foundation)第1天&#xff1a;環境搭建與 “Hello, World!”核心概念: 安裝Rust工具鏈 (rustup)&#xff0c;它包含了編譯器rustc和包管理器Cargo。Cargo是你的好朋友&#xff0c;用于創建項目…
閱讀更多...
亂刪文件，電腦不能開機，怎么辦

亂刪文件，電腦不能開機，怎么辦

相信不少朋友在清理電腦、釋放空間時&#xff0c;都做過一件“后悔一整年”的事——亂刪系統文件。本來只是想讓電腦快點、干凈點&#xff0c;結果第二天一開機&#xff1a;黑屏了、藍屏了、無限重啟了&#xff0c;甚至連桌面都見不到了&#xff01;很多用戶在刪文件時&#xf…
閱讀更多...
ICODE SLIX2有密鑰保護的物流跟蹤、圖書館管理ISO15693標簽讀寫Delphi源碼

ICODE SLIX2有密鑰保護的物流跟蹤、圖書館管理ISO15693標簽讀寫Delphi源碼

本示例使用設備&#xff1a;https://item.taobao.com/item.htm?spma21dvs.23580594.0.0.6781645eXF3tm5&ftt&id959258149468 一、密鑰認證 procedure TForm1.Button21Click(Sender: TObject); varctrlword:byte;passwordid:byte; //密鑰類型status:byte; //存…
閱讀更多...
核環境特種機器人設備的抗輻照芯片選型方案

核環境特種機器人設備的抗輻照芯片選型方案

摘要&#xff1a;核能作為國家能源安全的重要組成部分&#xff0c;對工業自動化設備的穩定性和可靠性提出了極高的要求。機器人設備在涉核環境下的日常巡檢、設備維護、應急響應等任務中發揮著不可替代的作用。然而&#xff0c;涉核環境&#xff0c;尤其是高能粒子的輻照效應&a…
閱讀更多...
Linux權限系統完全指南：從本質到安全實踐

Linux權限系統完全指南：從本質到安全實踐

一、權限的本質&#xff1a;Linux安全的核心邏輯在Linux的多用戶環境中&#xff0c;權限系統通過三個關鍵維度實現資源隔離&#xff1a;用戶標識 (UID)&#xff1a;系統通過數字ID識別用戶&#xff0c;root用戶的UID固定為0組標識 (GID)&#xff1a;用戶組機制實現批量權限管理…
閱讀更多...
養老院跌倒漏報率↓78%！陌訊多模態算法在智慧照護中的邊緣計算優化

養老院跌倒漏報率↓78%！陌訊多模態算法在智慧照護中的邊緣計算優化

?摘要??&#xff1a; 針對養老場景中復雜光照與遮擋導致的跌倒漏報問題&#xff0c;陌訊視覺算法通過多模態融合與邊緣計算優化&#xff0c;實測顯示在RK3588 NPU硬件上實現??mAP0.5達89.3%??&#xff0c;較基線模型提升28.5%&#xff0c;功耗降低至7.2W。本文解析其動態…
閱讀更多...
【通識】計算機網絡

【通識】計算機網絡

1. 基礎概述11 2.
閱讀更多...
最新文章

Copyright @ 2022~2023