【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.mzph.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