【Kubernetes】Kubernetes的Pod進階

Pod進階

  • 一、資源限制和重啟策略
    • 1. 資源限制
    • 2. 資源單位
      • 2.1 CPU 資源單位
      • 2.2 內存 資源單位
    • 3. 重啟策略（restartPolicy）
  • 二、健康檢查的概念
    • 1. 健康檢查
      • 1.1 探針的三種規則
      • 1.2 Probe 支持三種檢查方法
    • 2. 示例
      • 2.1 exec 方式
      • 2.2 httpGet 方式
      • 2.3 tcpSocket 方式
      • 2.4 就緒檢測
      • 2.5 就緒檢測2
      • 2.6 啟動、退出動作
  • 總結
    • 1. Pod 容器的資源限制
    • 2. Pod 容器資源的單位
    • 3. Pod 容器資源查看命令
    • 4. Pod 容器的 3 種探針 （健康檢查）
    • 5. Pod 容器探針的 3 種探測方式

一、資源限制和重啟策略

1. 資源限制

??當定義 Pod 時可以選擇性地為每個容器設定所需要的資源數量。 最常見的可設定資源是 CPU 和內存大小，以及其他類型的資源。

??當為 Pod 中的容器指定了 request 資源時，代表容器運行所需的最小資源量，調度器就使用該信息來決定將 Pod 調度到哪個節點上。當還為容器指定了 limit 資源時，kubelet 就會確保運行的容器不會使用超出所設的 limit 資源量。kubelet 還會為容器預留所設的 request 資源量， 供該容器使用。

??如果 Pod 運行所在的節點具有足夠的可用資源，容器可以使用超出所設置的 request 資源量。不過，容器不可以使用超出所設置的 limit 資源量。

??如果給容器設置了內存的 limit 值，但未設置內存的 request 值，Kubernetes 會自動為其設置與內存 limit 相匹配的 request 值。 類似的，如果給容器設置了 CPU 的 limit 值但未設置 CPU 的 request 值，則 Kubernetes 自動為其設置 CPU 的 request 值 并使之與 CPU 的 limit 值匹配。

官網示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

#Pod 和 容器 的資源請求和限制：
spec.containers[].resources.requests.cpu		#定義創建容器時預分配的CPU資源
spec.containers[].resources.requests.memory		#定義創建容器時預分配的內存資源
spec.containers[].resources.limits.cpu			#定義 cpu 的資源上限 
spec.containers[].resources.limits.memory		#定義內存的資源上限

2. 資源單位

2.1 CPU 資源單位

??CPU 資源的 request 和 limit 以 cpu 為單位。Kubernetes 中的一個 cpu 相當于1個 vCPU（1個超線程）。

??Kubernetes 也支持帶小數 CPU 的請求。spec.containers[].resources.requests.cpu 為 0.5 的容器能夠獲得一個 cpu 的一半 CPU 資源（類似于Cgroup對CPU資源的時間分片）。表達式 0.1 等價于表達式 100m（毫核），表示每 1000 毫秒內容器可以使用的 CPU 時間總量為 0.1*1000 毫秒。Kubernetes 不允許設置精度小于 1m 的 CPU 資源。

2.2 內存 資源單位

??內存的 request 和 limit 以字節為單位。可以以整數表示，或者以10為底數的指數的單位（E、P、T、G、M、K）來表示， 或者以2為底數的指數的單位（Ei、Pi、Ti、Gi、Mi、Ki）來表示。
如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB

apiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: appimage: nginxenv:- name: MYSQL_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"- name: log-aggregatorimage: images.my-company.example/log-aggregator:v6resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"

??此例子中的 Pod 有兩個容器。每個容器的 request 值為 0.25 cpu 和 64MiB 內存，每個容器的 limit 值為 0.5 cpu 和 128MiB 內存。那么可以認為該 Pod 的總的資源 request 為 0.5 cpu 和 128 MiB 內存，總的資源 limit 為 1 cpu 和 256MiB 內存。

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: webimage: nginxenv:- name: WEB_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: "abc123"resources:requests:memory: "512Mi"cpu: "0.5"limits:memory: "1Gi"cpu: "1"kubectl apply -f pod2.yaml
kubectl describe pod frontendkubectl get pods -o wide
NAME       READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
frontend   2/2     Running   5          15m   10.244.2.4   node02   <none>           <none>kubectl describe nodes node02				#由于當前虛擬機有2個CPU，所以Pod的CPU Limits一共占用了50%
Namespace                  Name                           CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE---------                  ----                           ------------  ----------  ---------------  -------------  ---default                    frontend                       500m (25%)    1 (50%)     128Mi (3%)       256Mi (6%)     16mkube-system                kube-flannel-ds-amd64-f4pbp    100m (5%)     100m (5%)   50Mi (1%)        50Mi (1%)      19hkube-system                kube-proxy-pj4wp               0 (0%)        0 (0%)      0 (0%)           0 (0%)         19h
Allocated resources:(Total limits may be over 100 percent, i.e., overcommitted.)Resource           Requests    Limits--------           --------    ------cpu                600m (30%)  1100m (55%)memory             178Mi (4%)  306Mi (7%)ephemeral-storage  0 (0%)      0 (0%)

3. 重啟策略（restartPolicy）

??當 Pod 中的容器退出時通過節點上的 kubelet 重啟容器。適用于 Pod 中的所有容器。

策略含義
Always當容器終止退出后，總是重啟容器，默認策略
OnFailure當容器異常退出（退出狀態碼非0）時，重啟容器；正常退出則不重啟容器
Never當容器終止退出，從不重啟容器。

??注意：K8S 中不支持重啟 Pod 資源，只有刪除重建。

??在用 yaml 方式創建 Deployment 和 StatefulSet 類型時，restartPolicy 只能是 Always，kubectl run 創建 Pod 可以選擇 Always、OnFailure、Never 三種策略。

kubectl edit deployment nginx-deployment
......restartPolicy: Always

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3kubectl apply -f pod3.yaml#查看Pod狀態，等容器啟動后30秒后執行exit退出進程進入error狀態，就會重啟次數加1
kubectl get pods
NAME                              READY   STATUS             RESTARTS   AGE
foo                               1/1     Running            1          50skubectl delete -f pod3.yaml

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3restartPolicy: Never
#注意：跟container同一個級別kubectl apply -f pod3.yaml#容器進入error狀態不會進行重啟
kubectl get pods -w

二、健康檢查的概念

1. 健康檢查

?? 健康檢查又稱為探針（Probe） ，探針是由kubelet對容器執行的定期診斷。

1.1 探針的三種規則

探測規則說明
ivenessProbe判斷容器是否正在運行。如果探測失敗，則kubelet會殺死容器，并且容器將根據 restartPolicy 來設置 Pod 狀態。 如果容器不提供存活探針，則默認狀態為Success。
readinessProbe判斷容器是否準備好接受請求。如果探測失敗，端點控制器將從與 Pod 匹配的所有 service endpoints 中剔除刪除該Pod的IP地址。 初始延遲之前的就緒狀態默認為Failure。如果容器不提供就緒探針，則默認狀態為Success。
startupProbe這個1.17版本增加的）：判斷容器內的應用程序是否已啟動，主要針對于不能確定具體啟動時間的應用。如果配置了 startupProbe 探測，則在 startupProbe 狀態為 Success 之前，其他所有探針都處于無效狀態，直到它成功后其他探針才起作用。 如果 startupProbe 失敗，kubelet 將殺死容器，容器將根據 restartPolicy 來重啟。如果容器沒有配置 startupProbe， 則默認狀態為 Success。

??注：以上規則可以同時定義。在readinessProbe檢測成功之前，Pod的running狀態是不會變成ready狀態的。

1.2 Probe 支持三種檢查方法

檢查方法說明
exec在容器內執行指定命令。如果命令退出時返回碼為0則認為診斷成功。
tcpSocket對指定端口上的容器的IP地址進行TCP檢查（三次握手）。如果端口打開，則診斷被認為是成功的。
httpGet對指定的端口和uri路徑上的容器的IP地址執行HTTPGet請求。如果響應的狀態碼大于等于200且小于400，則診斷被認為是成功的

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

  • 成功（Success）：表示容器通過了檢測。
  • 失敗（Failure）：表示容器未通過檢測。
  • 未知（Unknown）：表示檢測沒有正常進行。

官網示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

2. 示例

2.1 exec 方式

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: k8s.gcr.io/busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60livenessProbe:exec:command:- cat- /tmp/healthyfailureThreshold: 1initialDelaySeconds: 5periodSeconds: 5

#initialDelaySeconds：指定 kubelet 在執行第一次探測前應該等待5秒，即第一次探測是在容器啟動后的第6秒才開始執行。默認是 0 秒，最小值是 0。
#periodSeconds：指定了 kubelet 應該每 5 秒執行一次存活探測。默認是 10 秒。最小值是 1。
#failureThreshold: 當探測失敗時，Kubernetes 將在放棄之前重試的次數。 存活探測情況下的放棄就意味著重新啟動容器。就緒探測情況下的放棄 Pod 會被打上未就緒的標簽。默認值是 3。最小值是 1。
#timeoutSeconds：探測的超時后等待多少秒。默認值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探針會忽略 timeoutSeconds 探針會無限期地 持續運行，甚至可能超過所配置的限期，直到返回結果為止。）

??
可以看到 Pod 中只有一個容器。kubelet 在執行第一次探測前需要等待 5 秒，kubelet 會每 5 秒執行一次存活探測。kubelet 在容器內執行命令 cat /tmp/healthy 來進行探測。如果命令執行成功并且返回值為 0，kubelet 就會認為這個容器是健康存活的。 當到達第 31 秒時，這個命令返回非 0 值，kubelet 會殺死這個容器并重新啟動它。

vim exec.yaml
apiVersion: v1
kind: Pod
metadata:name: liveness-execnamespace: default
spec:containers:- name: liveness-exec-containerimage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]livenessProbe:exec:command: ["test","-e","/tmp/live"]initialDelaySeconds: 1periodSeconds: 3kubectl create -f exec.yamlkubectl describe pods liveness-exec
Events:Type     Reason     Age               From               Message----     ------     ----              ----               -------Normal   Scheduled  51s               default-scheduler  Successfully assigned default/liveness-exec-pod to node02Normal   Pulled     46s               kubelet, node02    Container image "busybox" already present on machineNormal   Created    46s               kubelet, node02    Created container liveness-exec-containerNormal   Started    45s               kubelet, node02    Started container liveness-exec-containerWarning  Unhealthy  8s (x3 over 14s)  kubelet, node02    Liveness probe failed:Normal   Killing    8s                kubelet, node02    Container liveness-exec-container failed liveness probe,will be restartedkubectl get pods -w
NAME                READY   STATUS    RESTARTS   AGE
liveness-exec       1/1     Running   1          85s

2.2 httpGet 方式

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: k8s.gcr.io/livenessargs:- /serverlivenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3

??在這個配置文件中，可以看到 Pod 也只有一個容器。initialDelaySeconds 字段告訴 kubelet 在執行第一次探測前應該等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒執行一次存活探測。kubelet 會向容器內運行的服務（服務會監聽 8080 端口）發送一個 HTTP GET 請求來執行探測。如果服務器上 /healthz 路徑下的處理程序返回成功代碼，則 kubelet 認為容器是健康存活的。如果處理程序返回失敗代碼，則 kubelet 會殺死這個容器并且重新啟動它。

??任何大于或等于 200 并且小于 400 的返回代碼標示成功，其它返回代碼都標示失敗。

vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10kubectl create -f httpget.yamlkubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods
NAME               READY   STATUS    RESTARTS   AGE
liveness-httpget   1/1     Running   1          2m44s

2.3 tcpSocket 方式

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

??這個例子同時使用 readinessProbe 和 livenessProbe 探測。kubelet 會在容器啟動 5 秒后發送第一個 readinessProbe 探測。這會嘗試連接 goproxy 容器的 8080 端口。如果探測成功，kubelet 將繼續每隔 10 秒運行一次檢測。除了 readinessProbe 探測，這個配置包括了一個 livenessProbe 探測。kubelet 會在容器啟動 15 秒后進行第一次 livenessProbe 探測。就像 readinessProbe 探測一樣，會嘗試連接 goproxy 容器的 8080 端口。如果 livenessProbe 探測失敗，這個容器會被重新啟動。

vim tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:name: probe-tcp
spec:containers:- name: nginximage: soscscs/myapp:v1livenessProbe:initialDelaySeconds: 5timeoutSeconds: 1tcpSocket:port: 8080periodSeconds: 10failureThreshold: 2kubectl create -f tcpsocket.yamlkubectl exec -it probe-tcp  -- netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1/nginx: master prokubectl get pods -w
NAME        READY   STATUS    RESTARTS   AGE
probe-tcp   1/1     Running             0          1s
probe-tcp   1/1     Running             1          25s       #第一次是 init(5秒) + period(10秒) * 2
probe-tcp   1/1     Running             2          45s       #第二次是 period(10秒) + period(10秒)  重試了兩次
probe-tcp   1/1     Running             3          65s

2.4 就緒檢測

vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:name: readiness-httpgetnamespace: default
spec:containers:- name: readiness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10kubectl create -f readiness-httpget.yaml#readiness探測失敗，無法進入READY狀態
kubectl get pods 
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   0/1     Running   0          18skubectl exec -it readiness-httpget sh# cd /usr/share/nginx/html/# ls
50x.html    index.html# echo 123 > index1.html # exitkubectl get pods 
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   1/1     Running   0          2m31skubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods -w
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   1/1     Running   0          4m10s
readiness-httpget   0/1     Running   1          4m15s

2.5 就緒檢測2

vim readiness-myapp.yaml
apiVersion: v1
kind: Pod
metadata:name: myapp1labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:name: myapp2labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:name: myapp3labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10 
---
apiVersion: v1
kind: Service
metadata:name: myapp
spec:selector:app: myapptype: ClusterIPports:- name: httpport: 80targetPort: 80kubectl create -f readiness-myapp.yamlkubectl get pods,svc,endpoints -o wide
NAME         READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod/myapp1   1/1     Running   0          3m42s   10.244.2.13   node02   <none>           <none>
pod/myapp2   1/1     Running   0          3m42s   10.244.1.15   node01   <none>           <none>
pod/myapp3   1/1     Running   0          3m42s   10.244.2.14   node02   <none>           <none>NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
......
service/myapp        ClusterIP   10.96.138.13   <none>        80/TCP    3m42s   app=myappNAME                   ENDPOINTS                                      AGE
......
endpoints/myapp        10.244.1.15:80,10.244.2.13:80,10.244.2.14:80   3m42skubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html#readiness探測失敗，Pod 無法進入READY狀態，且端點控制器將從 endpoints 中剔除刪除該 Pod 的 IP 地址
kubectl get pods,svc,endpoints -o wide
NAME         READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod/myapp1   0/1     Running   0          5m17s   10.244.2.13   node02   <none>           <none>
pod/myapp2   1/1     Running   0          5m17s   10.244.1.15   node01   <none>           <none>
pod/myapp3   1/1     Running   0          5m17s   10.244.2.14   node02   <none>           <none>NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
......
service/myapp        ClusterIP   10.96.138.13   <none>        80/TCP    5m17s   app=myappNAME                   ENDPOINTS                       AGE
......
endpoints/myapp        10.244.1.15:80,10.244.2.14:80   5m17s

2.6 啟動、退出動作

vim post.yaml
apiVersion: v1
kind: Pod
metadata:name: lifecycle-demo
spec:containers:- name: lifecycle-demo-containerimage: soscscs/myapp:v1lifecycle:   #此為關鍵字段postStart:exec:command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]      preStop:exec:command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falseinitContainers:- name: init-myserviceimage: soscscs/myapp:v1command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falsevolumes:- name: message-loghostPath:path: /data/volumes/nginx/log/type: DirectoryOrCreatekubectl create -f post.yamlkubectl get pods -o wide
NAME             READY   STATUS    RESTARTS   AGE    IP            NODE     NOMINATED NODE   READINESS GATES
lifecycle-demo   1/1     Running   0          2m8s   10.244.2.28   node02   <none>           <none>kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
Hello initContainers
Hello from the postStart handler#在 node02 節點上查看
[root@node02 ~]# cd /data/volumes/nginx/log/
[root@node02 log]# ls
access.log  error.log  message
[root@node02 log]# cat message 
Hello initContainers
Hello from the postStart handler
#由上可知，init Container先執行，然后當一個主容器啟動后，Kubernetes 將立即發送 postStart 事件。#刪除 pod 后，再在 node02 節點上查看
kubectl delete pod lifecycle-demo[root@node02 log]# cat message 
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，當在容器被終結之前， Kubernetes 將發送一個 preStop 事件。

總結

1. Pod 容器的資源限制

sepc.containers.resources.requests.cpu|memory     設置pod容器創建時需要預留的資源量     容器應用最低配置 <= requests <= limits
sepc.containers.resources.limits.cpu|memory 	  設置pod容器能夠使用的資源量上限，如果容器進程內存使用量超過limits.memory會引發OOM

2. Pod 容器資源的單位

cpu資源量單位	cpu個數 1 2 0.1 .5 .25     豪核 100m 250m 1000m 1500m
內存資源量單位    整數（默認單位為字節）	 2的底數單位（Ki Mi Gi Ti）  10的底數單位（K M G T）

3. Pod 容器資源查看命令

kubectl describe -n 命名空間 pod <pod名稱>

4. Pod 容器的 3 種探針 （健康檢查）

存活探針（livenessProbe)：探測是否正常運行。如果探測失敗則kubelet殺掉容器（(Pod容器會根據重啟策略決定是否重啟)就緒探針(readinessProbe)：探測Pod是否進入就緒狀態(readry狀態欄1/1)，并做好接收servricei請求的準備。如果探測失敗則Peodt會變成未就緒狀態(reacyp狀態欄0/1),service資源會刪除所關聯的端點（endpoints)，并不再轉發請求給就緒探測失敗的Pod啟動探針（startupProbe)：探測容器內的應用是否啟動成功。在啟動探針探測成功之前，存活探針和就緒探針都會暫時處于禁用狀態，直到啟動探針探測成功

5. Pod 容器探針的 3 種探測方式

exec		在commadn字段中指定在容器內執行的Linux命令來進行探測，如果命令返回碼為0則認為探測成功，如果返回碼為非0則認為探測失敗
tcpSocket	向指定的Pod容器端口發送tcp連接請求，如果端口正確且tcp連接成功則認為探測成功，如果tcp連接失敗，則認為探測失敗
httGet		向指定的Pod容器端口和URL路徑發送http get請求，如果http響應狀態碼為2xx或3xx則認為探測成功，如果響應狀態碼為4xx或5xx則認為探測失敗

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

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

相關文章

臨床試驗三原則-對照、重復、隨機

臨床試驗三原則-對照、重復、隨機

臨床試驗必須遵循三個基本原則&#xff1a;對照、重復、隨機。 一、對照原則和對照的設置 核心觀點&#xff1a;有比較才有鑒別。 對照組和試驗組同質可比。 三臂試驗 安慰劑&#xff1a;試驗組&#xff1a;陽性對照組1&#xff1a;n&#xff1a;m&#xff08;n≥m&#xff…
閱讀更多...
FFmpeg常見命令行（五）：FFmpeg濾鏡使用

FFmpeg常見命令行（五）：FFmpeg濾鏡使用

前言 在Android音視頻開發中&#xff0c;網上知識點過于零碎&#xff0c;自學起來難度非常大&#xff0c;不過音視頻大牛Jhuster提出了《Android 音視頻從入門到提高 - 任務列表》&#xff0c;結合我自己的工作學習經歷&#xff0c;我準備寫一個音視頻系列blog。本文是音視頻系…
閱讀更多...
Nginx反向代理服務流式輸出設置

Nginx反向代理服務流式輸出設置

Nginx反向代理服務流式輸出設置 1.問題場景 提問&#xff1a;為什么我部署的服務沒有流式響應 最近在重構原有的GPT項目時&#xff0c;遇到gpt回答速度很慢的現象。在使用流式輸出的接口時&#xff0c;接口響應速度居然還是達到了30s以上。 2.現象分析 分析現象我發現&…
閱讀更多...
Leetcode鏈表篇 Day3

Leetcode鏈表篇 Day3

.24. 兩兩交換鏈表中的節點 - 力扣&#xff08;LeetCode&#xff09; 1.構建虛擬結點 2.兩兩一組&#xff0c;前繼結點一定在兩兩的前面 3.保存結點1和結點3 19. 刪除鏈表的倒數第 N 個結點 - 力扣&#xff08;LeetCode&#xff09; 1.雙指針&#xff1a;快慢指針 兩個指針的差…
閱讀更多...
新能源汽車需要檢測哪些項目

新能源汽車需要檢測哪些項目

截至2022年底&#xff0c;中國新能源車保有量達1310萬輛&#xff0c;其中純電動汽車保有量1045萬輛。為把好新能源汽車安全關&#xff0c;我國新能源汽車除了完善的強制性產品認證型式實驗外&#xff0c;還建立了“車企-地方-國家”逐級上報的三級監管體系實行新能源汽車全生命…
閱讀更多...
2023.8.14論文閱讀

2023.8.14論文閱讀

文章目錄 ESPNet: Efficient Spatial Pyramid of Dilated Convolutions for Semantic Segmentation摘要本文方法實驗結果 DeepFusion: Lidar-Camera Deep Fusion for Multi-Modal 3D Object Detection摘要本文方法實驗結果 ESPNet: Efficient Spatial Pyramid of Dilated Convo…
閱讀更多...
vue 路由地址把#去掉

vue 路由地址把#去掉

在路由對象里邊添加history模式就不顯示# mode:history // 4.通過規則創建對象 const router new VueRouter({routes,// 默認模式為hash 帶# // history 不帶#mode:history })想把端口號8000換成其他的 比如我這樣的3000更換端口號教程
閱讀更多...
Android Framework 動態更新插拔設備節點執行權限

Android Framework 動態更新插拔設備節點執行權限

TF卡設備節點是插上之后動態添加&#xff0c;所以不能通過初始化設備節點權限來解決&#xff0c;需要監聽TF插入事件&#xff0c;在init.rc 監聽插入后動態更新設備節點執行權限 添加插拔TF卡監聽 frameworks/base/services/core/java/com/android/server/StorageManagerServic…
閱讀更多...
IL匯編ldc指令學習

IL匯編ldc指令學習

ldc指令是把值送到棧上&#xff0c; 說明如下&#xff0c; ldc.i4 將所提供的int32類型的值作為int32推送到計算堆棧上&#xff1b; ldc.i4.0 將數值0作為int32推送到計算堆棧上&#xff1b; ... ldc.i4.8 將數值8作為int32推送到計算堆棧上&#xff1b; ldc.i4.m1 將數值-…
閱讀更多...
Stable Diffusion 告別復制關鍵詞，高質量提示詞自動生成插件

Stable Diffusion 告別復制關鍵詞，高質量提示詞自動生成插件

在使用SD時，我們經常會遇到心中無想法，或不知如何描述心中所想的圖像。有時由于提示詞的選擇不當，生成的圖片質量也不盡如人意。為此，我今天為大家推薦一個高質量的提示詞自動生成插件——One Button Prompt。 下面是他生成的一些樣圖。 文章目錄 插件安裝插件說明主菜單工…
閱讀更多...
用python繪制CDF圖

用python繪制CDF圖

一、code import os.pathimport pandas as pd import numpy as np import matplotlib.pyplot as pltcsv_path r"XXX.csv" save_fig_path os.path.join(os.path.split(csv_path)[0], "metrics_cdf.png")# 從CSV讀取數據 data pd.read_csv(csv_path)[XXX…
閱讀更多...
Android 屏幕適配資源xml的配置方法

Android 屏幕適配資源xml的配置方法

在 Android 中進行屏幕適配是確保應用在不同設備上正常顯示的重要步驟之一。資源文件夾的配置是實現屏幕適配的關鍵之一&#xff0c;以下是一些常見的資源文件夾配置方法&#xff0c;以適應不同屏幕尺寸和密度。 不同屏幕尺寸的適配&#xff1a; res/layout&#xff1a;通常存放…
閱讀更多...
使用vscode進行遠程調試

使用vscode進行遠程調試

官方調試手冊&#xff1a;vscode官方調試手冊 1.安裝python擴展 如果是遠程連接的話&#xff0c;一定要在ssh上啟用擴展。不然創建基于python的配置文件時就會提示&#xff0c;無python擴展。 2.新建配置文件&#xff0c;并修改參數 點擊左側第四個按鈕&#xff0c;運行與調試…
閱讀更多...
【C# 基礎精講】異常的類型和處理方法

【C# 基礎精講】異常的類型和處理方法

異常&#xff08;Exception&#xff09;是在程序執行過程中發生的意外或異常情況&#xff0c;例如除零錯誤、空引用訪問、文件不存在等。在C#及其他編程語言中&#xff0c;異常處理是一種重要的機制&#xff0c;用于捕獲和處理程序運行時可能出現的錯誤&#xff0c;以保證程序的…
閱讀更多...
【碎碎念隨筆】1、回顧我的電腦和編程經歷

【碎碎念隨筆】1、回顧我的電腦和編程經歷

?? 閑著無事&#xff0c;講述一下我的計算機和代碼故事 一、初識計算機 &#x1f5a5;? 余家貧&#xff0c;耕植無錢買電腦。大約六年級暑假&#xff0c;我在姐姐哪兒第一次接觸到了計算機&#xff08;姐姐也是買的二手&#xff09;。 &#x1f5a5;? 計算機真有趣&#x…
閱讀更多...
多線程并發服務器

多線程并發服務器

代碼&#xff1a; #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> #include <unistd.h> #define PORT 6666 //1024~49151 #define IP "192.168.122.130" //ifconfig查看本機IP #include <pthread.h> //…
閱讀更多...
深入解析：HTTP和HTTPS的三次握手與四次揮手

深入解析：HTTP和HTTPS的三次握手與四次揮手

推薦閱讀 AI文本 OCR識別最佳實踐 AI Gamma一鍵生成PPT工具直達鏈接 玩轉cloud Studio 在線編碼神器 玩轉 GPU AI繪畫、AI講話、翻譯,GPU點亮AI想象空間 「java、python面試題」來自UC網盤app分享&#xff0c;打開手機app&#xff0c;額外獲得1T空間 https://drive.uc.cn/…
閱讀更多...
探索Python編程的技巧：多線程魔法、網絡舞臺、正則魔法陣與遞歸迷宮

探索Python編程的技巧：多線程魔法、網絡舞臺、正則魔法陣與遞歸迷宮

一 多線程 1.1 進程和線程 進程&#xff1a; 就是一個程序&#xff0c;運行在系統之上&#xff0c;稱這個程序為一個運行進程&#xff0c;并分配進程ID方便系統管理。線程&#xff1a;線程是歸屬于進程的&#xff0c;一個進程可以開啟多個線程&#xff0c;執行不同的工作&…
閱讀更多...
【C++面向對象】--- 繼承 的奧秘（下篇）

【C++面向對象】--- 繼承 的奧秘（下篇）

個人主頁&#xff1a;平行線也會相交&#x1f4aa; 歡迎 點贊&#x1f44d; 收藏? 留言? 加關注&#x1f493;本文由 平行線也會相交 原創 收錄于專欄【C之路】&#x1f48c; 本專欄旨在記錄C的學習路線&#xff0c;望對大家有所幫助&#x1f647;? 希望我們一起努力、成長&…
閱讀更多...
Vim基本使用

Vim基本使用

Vim基本使用 概念模式類型常規模式編輯模式命令模式 概念 vim 是一款功能豐富、高度可定制和高效的文本編輯器&#xff0c;適用于處理各種文本文件和編程任務。熟練使用vim幫助提高編輯效率&#xff0c;并為用戶提供更多的操作選項。 模式類型 常規模式 使用vim打開一個文件…
閱讀更多...
最新文章

Copyright @ 2022~2023