重溫k8s基礎概念知識系列二(Pod)

文章目錄

      • 1、Pod概念
      • 2、K8s 中的 Pod 的兩種用法
      • 3、定義Pod
      • 4、Pod的創建資源
      • 5、Pod 模板
      • 6、容器探針
      • 7、總結干貨
      • 8、 K8s Pod 經典面試題速查表

Pod是Kubernetes中最小的單元:

在這里插入圖片描述

1、Pod概念

Pod 是可以在 Kubernetes中創建和管理的、最小的可部署的計算單元。它由一組、一個或多個容器組成,每個Pod還包含了一個Pause容器,Pause容器是Pod的父容器,主要負責僵尸進程的回收管理,通過Pause容器可以使同一個Pod里面的多個容器共享存儲、網絡、PID、IPC等。

Pod(就像在鯨魚莢或者豌豆莢中)是一組(一個或多個) 容器; 這些容器共享存儲、網絡、以及怎樣運行這些容器的規約。 Pod中的內容總是并置(colocated)的并且一同調度,在共享的上下文中運行。 Pod所建模的是特定于應用的“邏輯主機”,其中包含一個或多個應用容器, 這些容器相對緊密地耦合在一起。在非云環境中,在相同的物理機或虛擬機上運行的應用類似于在同一邏輯主機上運行的云應用。

除了應用容器,Pod 還可以包含在 Pod 啟動期間運行的 Init 容器。 你也可以注入臨時性容器來調試正在運行的 Pod。

Pod 的共享上下文包括一組 Linux 名字空間、控制組(CGroup)和可能一些其他的隔離方面, 即用來隔離容器的技術。 在 Pod 的上下文中,每個獨立的應用可能會進一步實施隔離。

2、K8s 中的 Pod 的兩種用法

Pod 類似于共享名字空間并共享文件系統卷的一組容器。

Kubernetes 集群中的 Pod 主要有兩種用法:

  • 運行單個容器的 Pod。"每個 Pod 一個容器"模型是最常見的 Kubernetes 用例; 在這種情況下,可以將 Pod 看作單個容器的包裝器,并且 Kubernetes 直接管理 Pod,而不是容器。

  • 運行多個協同工作的容器的 Pod。 Pod 可以封裝由緊密耦合且需要共享資源的多個并置容器組成的應用。 這些位于同一位置的容器構成一個內聚單元。

將多個并置、同管的容器組織到一個 Pod 中是一種相對高級的使用場景。 只有在一些場景中,容器之間緊密關聯時你才應該使用這種模式。

3、定義Pod

定義一個Pod:

下面是一個 Pod 示例,它由一個運行鏡像 nginx:1.14.2 的容器組成。

apiVersion: v1
kind: Pod
metadata:name: nginx
spec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

要創建上面顯示的 Pod,請運行以下命令:

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
apiVersion: v1 # 必選,API的版本號
kind: Pod       # 必選,類型Pod
metadata:       # 必選,元數據name: nginx   # 必選,符合RFC 1035規范的Pod名稱namespace: default # 可選,Pod所在的命名空間,不指定默認為default,可以使用-n 指定namespace labels:       # 可選,標簽選擇器,一般用于過濾和區分Podapp: nginxrole: frontend # 可以寫多個annotations:  # 可選,注釋列表,可以寫多個app: nginx
spec:   # 必選,用于定義容器的詳細信息initContainers: # 初始化容器,在容器啟動之前執行的一些初始化操作- command:- sh- -c- echo "I am InitContainer for init some configuration"image: busyboximagePullPolicy: IfNotPresentname: init-containercontainers:   # 必選,容器列表- name: nginx # 必選,符合RFC 1035規范的容器名稱image: nginx:latest    # 必選,容器所用的鏡像的地址imagePullPolicy: Always     # 可選,鏡像拉取策略command: # 可選,容器啟動執行的命令- nginx - -g- "daemon off;"workingDir: /usr/share/nginx/html       # 可選,容器的工作目錄volumeMounts:   # 可選,存儲卷配置,可以配置多個- name: webroot # 存儲卷名稱mountPath: /usr/share/nginx/html # 掛載目錄readOnly: true        # 只讀ports:  # 可選,容器需要暴露的端口號列表- name: http    # 端口名稱containerPort: 80     # 端口號protocol: TCP # 端口協議,默認TCPenv:    # 可選,環境變量配置列表- name: TZ      # 變量名value: Asia/Shanghai # 變量的值- name: LANGvalue: en_US.utf8resources:      # 可選,資源限制和資源請求限制limits:       # 最大限制設置cpu: 1000mmemory: 1024Mirequests:     # 啟動所需的資源cpu: 100mmemory: 512Mi
#    startupProbe: # 可選,檢測容器內進程是否完成啟動。注意三種檢查方式同時只能使用一種。
#      httpGet:      # httpGet檢測方式,生產環境建議使用httpGet實現接口級健康檢查,健康檢查由應用程序提供。
#            path: /api/successStart # 檢查路徑
#            port: 80readinessProbe: # 可選,健康檢查。注意三種檢查方式同時只能使用一種。httpGet:      # httpGet檢測方式,生產環境建議使用httpGet實現接口級健康檢查,健康檢查由應用程序提供。path: / # 檢查路徑port: 80        # 監控端口livenessProbe:  # 可選,健康檢查#exec:        # 執行容器命令檢測方式#command: #- cat#- /health#httpGet:       # httpGet檢測方式#   path: /_health # 檢查路徑#   port: 8080#   httpHeaders: # 檢查的請求頭#   - name: end-user#     value: Jason tcpSocket:    # 端口檢測方式port: 80initialDelaySeconds: 60       # 初始化時間timeoutSeconds: 2     # 超時時間periodSeconds: 5      # 檢測間隔successThreshold: 1 # 檢查成功為2次表示就緒failureThreshold: 2 # 檢測失敗1次表示未就緒lifecycle:postStart: # 容器創建完成后執行的指令, 可以是exec httpGet TCPSocketexec:command:- sh- -c- 'mkdir /data/ 'preStop:httpGet:      path: /port: 80#  exec:#    command:#    - sh#    - -c#    - sleep 9restartPolicy: Always   # 可選,默認為Always#nodeSelector: # 可選,指定Node節點#      region: subnet7imagePullSecrets:     # 可選,拉取鏡像使用的secret,可以配置多個- name: default-dockercfg-86258hostNetwork: false    # 可選,是否為主機模式,如是,會占用主機端口volumes:      # 共享存儲卷列表- name: webroot # 名稱,與上述對應emptyDir: {}    # 掛載目錄#hostPath:              # 掛載本機目錄#  path: /etc/hosts
apiVersion: v1 # 必選,API的版本號
kind: Pod       # 必選,類型Pod
metadata:       # 必選,元數據name: nginx   # 必選,符合RFC 1035規范的Pod名稱# namespace: default # 可選,Pod所在的命名空間,不指定默認為default,可以使用-n 指定namespace labels:       # 可選,標簽選擇器,一般用于過濾和區分Podapp: nginxrole: frontend # 可以寫多個annotations:  # 可選,注釋列表,可以寫多個app: nginx
spec:   # 必選,用于定義容器的詳細信息
#  initContainers: # 初始化容器,在容器啟動之前執行的一些初始化操作
#  - command:
#    - sh
#    - -c
#    - echo "I am InitContainer for init some configuration"
#    image: busybox
#    imagePullPolicy: IfNotPresent
#    name: init-containercontainers:   # 必選,容器列表- name: nginx # 必選,符合RFC 1035規范的容器名稱image: nginx:1.15.2    # 必選,容器所用的鏡像的地址imagePullPolicy: IfNotPresent     # 可選,鏡像拉取策略, IfNotPresent: 如果宿主機有這個鏡像,那就不需要拉取了. Always: 總是拉取, Never: 不管是否存儲都不拉去command: # 可選,容器啟動執行的命令 ENTRYPOINT, arg --> cmd- nginx - -g- "daemon off;"workingDir: /usr/share/nginx/html       # 可選,容器的工作目錄
#    volumeMounts:   # 可選,存儲卷配置,可以配置多個
#    - name: webroot # 存儲卷名稱
#      mountPath: /usr/share/nginx/html # 掛載目錄
#      readOnly: true        # 只讀ports:  # 可選,容器需要暴露的端口號列表- name: http    # 端口名稱containerPort: 80     # 端口號protocol: TCP # 端口協議,默認TCPenv:    # 可選,環境變量配置列表- name: TZ      # 變量名value: Asia/Shanghai # 變量的值- name: LANGvalue: en_US.utf8
#    resources:      # 可選,資源限制和資源請求限制
#      limits:       # 最大限制設置
#        cpu: 1000m
#        memory: 1024Mi
#      requests:     # 啟動所需的資源
#        cpu: 100m
#        memory: 512Mi
#    startupProbe: # 可選,檢測容器內進程是否完成啟動。注意三種檢查方式同時只能使用一種。
#      httpGet:      # httpGet檢測方式,生產環境建議使用httpGet實現接口級健康檢查,健康檢查由應用程序提供。
#            path: /api/successStart # 檢查路徑
#            port: 80
#    readinessProbe: # 可選,健康檢查。注意三種檢查方式同時只能使用一種。
#      httpGet:      # httpGet檢測方式,生產環境建議使用httpGet實現接口級健康檢查,健康檢查由應用程序提供。
#            path: / # 檢查路徑
#            port: 80        # 監控端口
#    livenessProbe:  # 可選,健康檢查#exec:        # 執行容器命令檢測方式#command: #- cat#- /health#httpGet:       # httpGet檢測方式#   path: /_health # 檢查路徑#   port: 8080#   httpHeaders: # 檢查的請求頭#   - name: end-user#     value: Jason 
#      tcpSocket:    # 端口檢測方式
#            port: 80
#      initialDelaySeconds: 60       # 初始化時間
#      timeoutSeconds: 2     # 超時時間
#      periodSeconds: 5      # 檢測間隔
#      successThreshold: 1 # 檢查成功為2次表示就緒
#      failureThreshold: 2 # 檢測失敗1次表示未就緒
#    lifecycle:
#      postStart: # 容器創建完成后執行的指令, 可以是exec httpGet TCPSocket
#        exec:
#          command:
#          - sh
#          - -c
#          - 'mkdir /data/ '
#      preStop:
#        httpGet:      
#              path: /
#              port: 80#  exec:#    command:#    - sh#    - -c#    - sleep 9restartPolicy: Always   # 可選,默認為Always,容器故障或者沒有啟動成功,那就自動該容器,Onfailure: 容器以不為0的狀態終止,自動重啟該容器, Never:無論何種狀態,都不會重啟#nodeSelector: # 可選,指定Node節點#      region: subnet7
#  imagePullSecrets:     # 可選,拉取鏡像使用的secret,可以配置多個
#  - name: default-dockercfg-86258
#  hostNetwork: false    # 可選,是否為主機模式,如是,會占用主機端口
#  volumes:      # 共享存儲卷列表
#  - name: webroot # 名稱,與上述對應
#    emptyDir: {}    # 掛載目錄
#        #hostPath:              # 掛載本機目錄
#        #  path: /etc/hosts

4、Pod的創建資源

Pod 通常不是直接創建的,而是使用工作負載資源創建的。
用于管理 Pod 的工作負載資源:

  • Deployment
  • StatefulSet
  • DaemonSet

通常你不需要直接創建 Pod,甚至單實例 Pod。相反,你會使用諸如 Deployment 或 Job 這類工作負載資源來創建 Pod。 如果 Pod 需要跟蹤狀態,可以考慮 StatefulSet 資源。

每個 Pod 都旨在運行給定應用程序的單個實例。如果希望橫向擴展應用程序 (例如,運行多個實例以提供更多的資源),則應該使用多個 Pod,每個實例使用一個 Pod。 在 Kubernetes 中,這通常被稱為副本(Replication)。 通常使用一種工作負載資源及其控制器來創建和管理一組 Pod 副本。

Pod 天生地為其成員容器提供了兩種共享資源:網絡和存儲。

說明:
重啟 Pod 中的容器不應與重啟 Pod 混淆。 Pod 不是進程,而是容器運行的環境。 在被刪除之前,Pod 會一直存在。

5、Pod 模板

工作負載資源的控制器通常使用 Pod 模板(Pod Template) 來替你創建 Pod 并管理它們。

Pod 模板是包含在工作負載對象中的規范,用來創建 Pod。這類負載資源包括 Deployment、 Job 和 DaemonSet 等。

工作負載的控制器會使用負載對象中的 PodTemplate 來生成實際的 Pod。 PodTemplate 是你用來運行應用時指定的負載資源的目標狀態的一部分。

創建 Pod 時,你可以在 Pod 模板中包含 Pod 中運行的容器的環境變量。

6、容器探針

probe 是由 kubelet 對容器執行的定期診斷。 要執行診斷,kubelet 既可以在容器內執行代碼,也可以發出一個網絡請求。

檢查機制
使用探針來檢查容器有四種不同的方法。 每個探針都必須準確定義為這四種機制中的一種:

  • exec
    在容器內執行指定命令。如果命令退出時返回碼為 0 則認為診斷成功。
  • grpc
    使用 gRPC 執行一個遠程過程調用。 目標應該實現 gRPC 健康檢查。 如果響應的狀態是 “SERVING”,則認為診斷成功。
  • httpGet
    對容器的 IP 地址上指定端口和路徑執行 HTTP GET 請求。如果響應的狀態碼大于等于 200 且小于 400,則診斷被認為是成功的。
  • tcpSocket
    對容器的 IP 地址上的指定端口執行 TCP 檢查。如果端口打開,則診斷被認為是成功的。 如果遠程系統(容器)在打開連接后立即將其關閉,這算作是健康的。
    注意:
    和其他機制不同,exec 探針的實現涉及每次執行時創建/復制多個進程。 因此,在集群中具有較高 pod 密度、較低的 initialDelaySeconds 和 periodSeconds 時長的時候, 配置任何使用 exec 機制的探針可能會增加節點的 CPU 負載。 這種場景下,請考慮使用其他探針機制以避免額外的開銷。

探測結果
每次探測都將獲得以下三種結果之一:

  • Success(成功)
    容器通過了診斷。
  • Failure(失敗)
    容器未通過診斷。
  • Unknown(未知)
    診斷失敗,因此不會采取任何行動。

探測類型
針對運行中的容器,kubelet 可以選擇是否執行以下三種探針,以及如何針對探測結果作出反應:

  • livenessProbe
    指示容器是否正在運行。如果存活態探測失敗,則 kubelet 會殺死容器, 并且容器將根據其重啟策略決定未來。如果容器不提供存活探針, 則默認狀態為 Success。
  • readinessProbe
    指示容器是否準備好為請求提供服務。如果就緒態探測失敗, EndpointSlice 控制器將從與該 Pod 匹配的所有 Service 的 EndpointSlice 中刪除該 Pod 的 IP 地址。 初始延遲之前的就緒態的狀態值默認為 Failure。 如果容器不提供就緒態探針,則默認狀態為 Success。
  • startupProbe
    指示容器中的應用是否已經啟動。如果提供了啟動探針,則所有其他探針都會被 禁用,直到此探針成功為止。如果啟動探測失敗,kubelet 將殺死容器, 而容器依其重啟策略進行重啟。 如果容器沒有提供啟動探測,則默認狀態為 Success。
    如欲了解如何設置存活態、就緒態和啟動探針的進一步細節, 可以參閱配置存活態、就緒態和啟動探針。

何時該使用存活態探針?
如果容器中的進程能夠在遇到問題或不健康的情況下自行崩潰,則不一定需要存活態探針; kubelet 將根據 Pod 的 restartPolicy 自動執行修復操作。

如果你希望容器在探測失敗時被殺死并重新啟動,那么請指定一個存活態探針, 并指定 restartPolicy 為 “Always” 或 “OnFailure”。

何時該使用就緒態探針?
如果要僅在探測成功時才開始向 Pod 發送請求流量,請指定就緒態探針。 在這種情況下,就緒態探針可能與存活態探針相同,但是規約中的就緒態探針的存在意味著 Pod 將在啟動階段不接收任何數據,并且只有在探針探測成功后才開始接收數據。

如果你希望容器能夠自行進入維護狀態,也可以指定一個就緒態探針, 檢查某個特定于就緒態的因此不同于存活態探測的端點。

如果你的應用程序對后端服務有嚴格的依賴性,你可以同時實現存活態和就緒態探針。 當應用程序本身是健康的,存活態探針檢測通過后,就緒態探針會額外檢查每個所需的后端服務是否可用。 這可以幫助你避免將流量導向只能返回錯誤信息的 Pod。

如果你的容器需要在啟動期間加載大型數據、配置文件或執行遷移, 你可以使用啟動探針。 然而,如果你想區分已經失敗的應用和仍在處理其啟動數據的應用,你可能更傾向于使用就緒探針。

說明:
請注意,如果你只是想在 Pod 被刪除時能夠排空請求,則不一定需要使用就緒態探針; 當 Pod 被刪除時,EndpointSlice 中對應的端點會更新其狀況: 該端點的 ready 狀況將被設置為 false,因此負載均衡器不會再將該 Pod 用于常規流量。 關于 kubelet 如何處理 Pod 刪除的更多信息,請參見 Pod 終止。

何時該使用啟動探針?
對于所包含的容器需要較長時間才能啟動就緒的 Pod 而言,啟動探針是有用的。 你不再需要配置一個較長的存活態探測時間間隔,只需要設置另一個獨立的配置選定, 對啟動期間的容器執行探測,從而允許使用遠遠超出存活態時間間隔所允許的時長。

如果你的容器啟動時間通常超出

initialDelaySeconds+failureThreshold×periodSeconds 總值,你應該設置一個啟動探測,對存活態探針所使用的同一端點執行檢查。 periodSeconds 的默認值是 10 秒。你應該將其 failureThreshold 設置得足夠高, 以便容器有充足的時間完成啟動,并且避免更改存活態探針所使用的默認值。 這一設置有助于減少死鎖狀況的發生。

7、總結干貨

Pod 是 Kubernetes 的最小執行單元,是“一組共享網絡和存儲的容器”,通常通過控制器來管理

序號內容
1Pod 內部可以包含一個或多個容器(常見情況是 1 個容器)。
1Pod 里的容器 共享網絡和存儲卷。
2同一網絡命名空間:Pod 內的容器共享 IP、Port。
3共享存儲卷:多個容器能訪問相同的持久存儲。
4緊密耦合:Pod 內容器一般完成一個整體任務。
5單容器 Pod:最常見,一個容器一個 Pod。
6調度器:將 Pod 分配到合適的節點。
7控制器:保證 Pod 的副本數和狀態(如 Deployment、DaemonSet)。
8親和/反親和:Pod 可以指定與節點或其他 Pod 的調度關系。
9Pod 的 IP 不穩定(Pod 刪除重建后會變)

Pod 的狀態描述

狀態描述
Pending:Pod 已提交,等待調度。
Running:Pod 已調度到節點上,至少一個容器運行中。
Succeeded:所有容器成功退出(狀態碼 0)。
Failed:至少一個容器異常退出。
CrashLoopBackOff:容器不斷重啟,說明有錯誤。

Pod 相關命令速查

# 查看 Pod
kubectl get pods -o wide# 查看 Pod 詳細信息
kubectl describe pod <pod-name># 查看 Pod 日志
kubectl logs -f <pod-name> [-c 容器名]# 進入 Pod 容器
kubectl exec -it <pod-name> -c <容器名> -- /bin/bash

8、 K8s Pod 經典面試題速查表

1?? 基礎概念類
Q1: 為什么 Kubernetes 引入 Pod,而不是直接用容器?

👉 因為有些場景需要多個容器緊密協作(例如主應用 + 日志收集 + 代理),Pod 提供:

共享網絡命名空間(一個 IP,多個容器);

共享存儲卷;

作為 調度和伸縮的最小單位。

Q2: Pod 和容器的區別是什么?

👉 容器是應用的運行實例;

Pod 是 Kubernetes 調度的基本單位,可以包含一個或多個容器;

Pod 提供共享網絡和存儲,是容器的邏輯集合。

Q3: Pod 的類型有哪些?

👉單容器 Pod(最常見);

多容器 Pod(Sidecar、Ambassador、Adapter 模式);

靜態 Pod(由 kubelet 直接管理,不受 API Server 控制)。

2?? 生命周期與狀態類
Q4: Pod 有哪些狀態?

👉 Pending → Running → Succeeded/Failed → CrashLoopBackOff(異常重啟)。

Q5: 什么是 Init 容器,有什么作用?

👉 Init 容器在主容器啟動前運行,用于:

執行初始化任務(配置下載、檢查依賴服務);

保證主容器在準備好環境后再啟動。

Q6: Pod CrashLoopBackOff 怎么排查?

👉 常見原因:

應用啟動失敗(配置錯誤、缺少依賴)。

存儲掛載失敗。

探針檢查失敗(liveness/readiness probe)。 👉 排查命令:

kubectl describe pod <pod-name>
kubectl logs <pod-name> -c <container>

3?? 調度與控制類
Q7: Pod 如何被調度到節點?

👉 調度器會根據:

資源請求/限制(CPU、內存);

節點選擇器(nodeSelector, nodeAffinity);

Pod 親和性/反親和性;

Taints & Tolerations(污點與容忍)。

Q8: Pod 與 Deployment/ReplicaSet 的關系?

👉Pod:最小運行單位;

ReplicaSet:保證 Pod 的副本數;

Deployment:聲明式管理 ReplicaSet,支持滾動更新、回滾。

4?? 網絡與存儲類
Q9: Pod 如何通信?

👉同一 Pod 內:容器共享 localhost;

同一 Node 內不同 Pod:通過 Pod IP 通信;

跨 Node Pod:依賴 CNI 插件(Flannel, Calico, Cilium);

外部訪問 Pod:通過 Service(ClusterIP、NodePort、LoadBalancer)。

Q🔟: Pod 為什么需要 Service?

👉 Pod 的 IP 不是固定的,重啟后會變化。 Service 提供一個 穩定的虛擬 IP(ClusterIP),解決 Pod
動態變化帶來的訪問問題。

5?? 高級與實戰類
Q11: Pod 重啟策略有哪些?

👉 在 Pod Spec 中 restartPolicy:

Always(默認,適用于長期運行的服務);

OnFailure(任務型,失敗才重啟);

Never(一次性任務)。

Q12: 怎么排查 Pod 處于 Pending 狀態?

👉 常見原因:

沒有可用的 Node(資源不足);

PVC 未綁定(存儲不足);

Node 上的 Taint 無法被容忍。

👉 排查命令:

kubectl describe pod <pod-name>
kubectl get events --sort-by=.metadata.creationTimestamp

Q13: 靜態 Pod 和普通 Pod 的區別?

👉靜態 Pod:由 kubelet 直接管理,通常用于運行核心組件(kube-apiserver 等),存放在
/etc/kubernetes/manifests。

普通 Pod:由 API Server 管理,通過 etcd 存儲。

在這里插入圖片描述


“人的一生會經歷很多痛苦,但回頭想想,都是傳奇”。


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

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

相關文章

設計模式之靜態代理

一些個人理解 顧名思義&#xff0c;就是代理一個對象。 那么&#xff0c;既然要代理一個東西&#xff0c;就要傳入它吧? 【1】所以將代理對象當作屬性【【2】往往通過構造方法傳入被代理的目標對象】。 既然要代理&#xff0c;那必然要和代理對象擁有相同的功能吧? 所以實現了…

牛津大學xDeepMind 自然語言處理(1)

牛津大學xDeepMind 自然語言處理 Natural Language Processing 詞向量與詞匯語義學 Word Vectors and Lexical Semantics 詞語表示的基本問題與分布語義思想 傳統詞語表示&#xff08;如獨熱向量&#xff09;存在稀疏、正交、語義弱的問題&#xff0c;無法表達語義相似性。分布…

StarRocks數據庫集群的完整部署流程

目錄 依賴環境 下載安裝包 部署FE 部署BE 搭建集群 停止集群 依賴環境 詳見&#xff1a;StarRocks 部署&#xff1a;依賴環境-CSDN博客 下載安裝包 在官方網站下載安裝包&#xff1a;StarRocks 部署FE 創建元數據目錄。 mkdir -p <meta_dir> 修改 FE 配置文件 f…

簡單的 VSCode 設置

以下是我使用的vscode設置。雖然有些主觀&#xff0c;但很實用。1 主題。我放棄了那些炫酷的主題。我選擇了Tokyo Night (Storm)。理由是&#xff1a;它平靜、賞心悅目&#xff0c;并且與代碼形成了美麗的對比&#xff0c;卻又不顯得刺眼。2. 字體。我切換到了 JetBrains Mono …

Rust 條件語句

Rust 條件語句 在編程語言中&#xff0c;條件語句是程序流程控制的重要組成部分。Rust 作為一種系統編程語言&#xff0c;其條件語句的設計簡潔而強大。本文將詳細介紹 Rust 中的條件語句&#xff0c;包括其語法、用法以及一些高級特性。 1. 基本條件語句 Rust 中的基本條件語句…

【Java EE進階 --- SpringBoot】初識Spring(創建SpringBoot項目)

樂觀學習&#xff0c;樂觀生活&#xff0c;才能不斷前進啊&#xff01;&#xff01;&#xff01; 我的主頁&#xff1a;optimistic_chen 我的專欄&#xff1a;c語言 &#xff0c;Java, Java EE初階&#xff0c; Java數據結構 歡迎大家訪問~ 創作不易&#xff0c;大佬們點贊鼓勵…

腦潛在進展:基于潛擴散模型的三維腦磁共振成像個體時空疾病進展研究|文獻速遞-深度學習人工智能醫療圖像

Title題目Brain Latent Progression: Individual-based spatiotemporal diseaseprogression on 3D Brain MRIs via latent diffusion腦潛在進展&#xff1a;基于潛擴散模型的三維腦磁共振成像個體時空疾病進展研究01文獻速遞介紹神經退行性疾病是現代醫療保健領域最緊迫的挑戰之…

專題:2025AI技術應用與發展報告|附600+份報告PDF、數據儀表盤匯總下載

原文鏈接&#xff1a;https://tecdat.cn/?p43632 當企業管理者看著后臺65%的任務被AI自動分配&#xff0c;卻仍在為下周的營銷方案熬夜改稿時&#xff0c;一個現實的矛盾浮出水面&#xff1a;AI到底能幫企業做什么&#xff1f; 2025年&#xff0c;算法研發投入占企業AI預算的…

【筆記】擴散模型(一一):Stable Diffusion XL 理論與實現

論文鏈接&#xff1a;SDXL: Improving Latent Diffusion Models for High-Resolution Image Synthesis 官方實現&#xff1a;Stability-AI/generative-models 非官方實現&#xff1a;huggingface/diffusers Stable Diffusion XL (SDXL) 是 Stablility AI 對 Stable Diffusion 進…

學習安卓APP開發,10年磨一劍,b4a/Android Studio

學習安卓APP開發 記得上次學APP都是在2016年前了&#xff0c;一晃就過去了10年。 當時用ANDROID studio打開一個空項目和編繹分別用了300秒&#xff0c;一下就用了10分鐘。 后來買了一臺一萬多的電腦&#xff0c;CPU換成了I5 8600K 4.2GHZ*6核&#xff0c;再加上M2固態硬盤。 編…

調試技巧(vs2022 C語言)

調試之前首先要保證我們的腦袋是清晰的&#xff0c;我們調試的過程主要是看代碼有沒有按照我們的想法去運行調試最常使用的幾個快捷鍵F5啟動調試&#xff0c;經常用來直接跳到下一個斷點處&#xff08;F5通常和F9配合使用&#xff0c;打了斷點按F5程序可以直接運行到斷點處&…

MySQL深度理解-Innodb底層原理

1.MySQL的內部組件結構大體來說&#xff0c;MySQL可以分為Server層和存儲引擎層兩部分。2.Server層Server層主要包括連接器、查詢緩存、分析器、優化器和執行器等&#xff0c;涵蓋MySQL的大多數核心服務功能&#xff0c;以及所有的內置函數&#xff08;如日期、時間、數據和加密…

QFtp在切換目錄、上傳文件、下載文件、刪除文件等一系列操作時,如何按照預期操作指令順序執行

FTP服務初始化時&#xff0c;考慮到重連、以及commandFinished信號信號執行完成置m_bCmdFinished 為true; void ICore::connectFtpServer() {if(g_pFile nullptr){g_pFile new QFile;}if(g_pFtp){g_pFtp->state();g_pFtp->abort();g_pFtp->deleteLater();g_pFtp n…

JavaSE高級-02

文章目錄1. 多線程1.1 創建線程的三種方式多線程的創建方式一&#xff1a;繼承Thread類多線程的創建方式二&#xff1a;實現Runnable接口多線程的創建方式三&#xff1a;實現Callable接口三種線程的創建方式對比Thread的常用方法1.2 線程安全線程同步方式一&#xff1a;同步代碼…

從舒適度提升到能耗降低再到安全保障,樓宇自控作用關鍵

在現代建筑的發展歷程中&#xff0c;樓宇自動化控制系統&#xff08;BAS&#xff09;已從單純的設備管理工具演變為集舒適度優化、能耗控制與安全保障于一體的核心技術。隨著物聯網和人工智能的深度應用&#xff0c;樓宇自控系統正以數據為紐帶&#xff0c;重構人與建筑的關系。…

圖像分類精度評價的方法——誤差矩陣、總體精度、用戶精度、生產者精度、Kappa 系數

本文詳細介紹 “圖像分類精度評價的方法”。 圖像分類后&#xff0c;需要評估分類結果的準確性&#xff0c;以判斷分類器的性能和結果的可靠性。 常涉及到下面幾個概念&#xff08;指標&#xff09; 誤差矩陣、總體精度、用戶精度、生產者精度和 Kappa 系數。1. 誤差矩陣&#…

【科普向-第一篇】數字鑰匙生態全景:手機廠商、車廠與協議之爭

目錄 一、協議標準之爭&#xff1a;誰制定規則&#xff0c;誰掌控入口 1.1 ICCE&#xff1a;中國車企主導的自主防線 1.2 ICCOA&#xff1a;手機廠商的生態突圍 1.3 CCC&#xff1a;國際巨頭的高端壁壘 1.4 協議對比 二、底層技術路線&#xff1a;成本與安全的博弈 2.1B…

dockerfile及docker常用操作

1: docker 編寫 Dockerfile 是用于構建 Docker 鏡像的文本文件&#xff0c;包含一系列指令和參數&#xff0c;用于定義鏡像的構建過程 以下是關鍵要點&#xff1a; 一、基本結構 ?FROM?&#xff1a;必須作為第一條指令&#xff0c;指定基礎鏡像&#xff08;如 FROM python:3.…

[vibe coding-lovable]lovable是不是ai界的復制忍者卡卡西?

在火影忍者的世界里&#xff0c;卡卡西也被稱為復制忍者&#xff0c;因為大部分忍術都可以被其Copy! 截圖提示:實現這個效果 -> 發給Lovalbe -> 生成的的效果如下&#xff0c;雖然不是1比1還原&#xff0c;但是這個效果也很驚艷。 這個交互設計&#xff0c;這個UI效果&am…

技術賦能安全:智慧工地構建城市建設新防線

城市建設的熱潮中&#xff0c;工地安全始終是關乎生命與發展的核心議題。江西新余火災等事故的沉痛教訓&#xff0c;暴露了傳統工地監管的諸多短板——流動焊機“行蹤難覓”&#xff0c;無證動火作業屢禁不止&#xff0c;每一次監管缺位都可能引發災難性后果。如今&#xff0c;…