【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.rhkb.cn/news/91665.html

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

相关文章

前后端分离------后端创建笔记（05）用户列表查询接口(上)

前后端分离------后端创建笔记（05）用户列表查询接口(上)

本文章转载于【SpringBootVue】全网最简单但实用的前后端分离项目实战笔记 - 前端_大菜007的博客-CSDN博客 仅用于学习和讨论&#xff0c;如有侵权请联系 源码&#xff1a;https://gitee.com/green_vegetables/x-admin-project.git 素材&#xff1a;https://pan.baidu.com/s/…
阅读更多...
css3 瀑布流布局遇见截断下一列展示后半截现象

css3 瀑布流布局遇见截断下一列展示后半截现象

css3 瀑布流布局遇见截断下一列展示后半截现象 注&#xff1a;css3实现瀑布流布局简直不要太香&#xff5e;&#xff5e;&#xff5e;&#xff5e;&#xff5e; 场景-在uniapp项目中 当瀑布流布局column-grap:10px 相邻两列之间的间隙为10px&#xff0c;column-count:2,2列展…
阅读更多...
数据结构入门指南：二叉树

数据结构入门指南：二叉树

目录 文章目录 前言 1. 树的概念及结构 1.1 树的概念 1.2 树的基础概念 1.3 树的表示 1.4 树的应用 2. 二叉树 2.1 二叉树的概念 2.2 二叉树的遍历 前言 在计算机科学中&#xff0c;数据结构是解决问题的关键。而二叉树作为最基本、最常用的数据结构之一&#xff0c;不仅在算法…
阅读更多...
LC-相交链表（解法2）

LC-相交链表（解法2）

LC-相交链表&#xff08;解法2&#xff09; 链接&#xff1a;https://leetcode.cn/problems/intersection-of-two-linked-lists/description/ 描述&#xff1a;给你两个单链表的头节点 headA 和 headB &#xff0c;请你找出并返回两个单链表相交的起始节点。如果两个链表不存在…
阅读更多...
ABAP Der Open SQL command is too big.

ABAP Der Open SQL command is too big.

ABAP Der Open SQL command is too big. DBSQL_STMNT_TOO_LARGE CX_SY_OPEN_SQL_DB 应该是选择条件中 维护的条件值条数太多了
阅读更多...
CSS：background 复合属性详解（用法 + 例子 + 效果）

CSS：background 复合属性详解（用法 + 例子 + 效果）

目录 background 复合属性background-color 背景颜色&#xff08;纯&#xff09;background-image 背景图片 或者 渐变颜色background-repeat 背景是否重复background-size 设置图片大小background-position 设置背景图片显示位置background-attachment 设置背景图片是否随页面…
阅读更多...
Windows下升级jdk1.8小版本

Windows下升级jdk1.8小版本

1.首先下载要升级jdk最新版本&#xff0c;下载地址&#xff1a;Java Downloads | Oracle 中国 2.下载完毕之后&#xff0c;直接双击下载完毕后的文件&#xff0c;进行安装。 3.安装完毕后&#xff0c;调整环境变量至新安装的jdk位置 4.此时&#xff0c;idea启动项目有可能会出…
阅读更多...
如何给 Keycloak 用户加上“部门”、“电话”等自定义属性

如何给 Keycloak 用户加上“部门”、“电话”等自定义属性

Keycloak 是一款开源的用户认证和授权软件。在默认安装情况下&#xff0c;它只给新创建的用户提供了 email 属性&#xff0c;但是在许多应用场景中&#xff0c;客户都会要求给新创建的用户增加诸如“部门”、“电话”等自定义属性。 本文会介绍如何给 keycloak 中新创建的用户…
阅读更多...
新疆大学841软件工程考研

新疆大学841软件工程考研

1&#xff0e;软件生产的发展经历了三个阶段&#xff0c;分别是____、程序系统时代和软件工程时代时代。 2&#xff0e;可行性研究从以下三个方面研究每种解决方法的可行性&#xff1a;经济可行性、社会可行性和_____。 3&#xff0e;HIPO图的H图用于描述软件的层次关系&…
阅读更多...
网神 SecGate 3600 防火墙任意文件上传漏洞复现

网神 SecGate 3600 防火墙任意文件上传漏洞复现

0x01 产品简介 网神SecGate3600下一代极速防火墙&#xff08;NSG系列&#xff09;是基于完全自主研发、经受市场检验的成熟稳定网神第三代SecOS操作系统 并且在专业防火墙、VPN、IPS的多年产品经验积累基础上精心研发的高性能下一代防火墙 专门为运营商、政府、军队、教育、大型…
阅读更多...
Ansible 进阶

Ansible 进阶

Ansible 进阶 ⤴️Ansible 入门看这篇文章⤵️Ansible 实战看这篇文章 一.Ansible 中的 Playbook 1.1 Playbook 介绍 如下图&#xff0c;ansible 在整个管理过程中使用 playbook 的大体流程。 Playbook 中包含多个 role&#xff0c;每个 role 对应于在远程主机完成某个比较复…
阅读更多...
Springboot 实践（3）配置DataSource及创建数据库

Springboot 实践（3）配置DataSource及创建数据库

前文讲述了利用MyEclipse2019开发工具&#xff0c;创建maven工程、加载springboot、swagger-ui功能。本文讲述创建数据库&#xff0c;为项目配置数据源&#xff0c;实现数据的增删改查服务&#xff0c;并通过swagger-ui界面举例调试服务控制器 创建数据库 项目使用MySQL 8.0.…
阅读更多...
R语言初学者书籍推荐

R语言初学者书籍推荐

Home | Bookdown 这个网站上有很多R语言的书籍&#xff0c;并且一直在更新&#xff0c;阅读起来没有难度。 今天搜索材料的时候&#xff0c;检索到下面这本书&#xff1a; 有输入&#xff0c;才会有输出。
阅读更多...
多线程并发服务器

多线程并发服务器

代码&#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> //…
阅读更多...
【数仓建设系列之一】什么是数据仓库？

【数仓建设系列之一】什么是数据仓库？

一、什么是数据仓库&#xff1f; 数据仓库(Data Warehouse&#xff0c;简称DW)简单来讲&#xff0c;它是一个存储和管理大量结构化和非结构化数据的存储集合&#xff0c;它以主题为向导&#xff0c;通过整合来自不同数据源下的数据(比如各业务数据&#xff0c;日志文件数据等)…
阅读更多...
中科亿海微浮点数转换定点数

中科亿海微浮点数转换定点数

引言 浮点数转换定点数是一种常见的数值转换技术&#xff0c;用于将浮点数表示转换为定点数表示。浮点数表示采用指数和尾数的形式&#xff0c;可以表示较大范围的数值&#xff0c;但存在精度有限的问题。而定点数表示则采用固定小数点位置的形式&#xff0c;具有固定的精度和范…
阅读更多...
Arraylist集合

Arraylist集合

保存数据会经常使用到数组&#xff0c;但数组存在以下几个缺陷: 长度固定&#xff1b;保存的必须为同一类型的元素&#xff0c;&#xff08;基本数据类型&#xff0c;或引用数据类型&#xff09;&#xff1b;使用数组进行增加元素的步骤比较麻烦&#xff1b; 这个时候就需要用一…
阅读更多...
人大进仓数据库ksql命令基础

人大进仓数据库ksql命令基础

测试环境信息： 系统为银河麒麟V10 数据库为Kingbase ES V8 数据库安装目录为/opt/Kingbase/ES/V8 ksql命令位于/opt/Kingbase/ES/V8/Server/bin下 使用--help获取帮助 续上图 1.查看数据库列表 ./ksql -U system -l 2.查看数据库版本 ./ksql -V 3.连接指定的数据库tes…
阅读更多...
单芯片3路CC管理的VR转接器解决方案

单芯片3路CC管理的VR转接器解决方案

VR眼镜即VR头显&#xff0c;也称虚拟现实头戴式显示设备&#xff0c;随着元宇宙概念的传播&#xff0c;VR眼镜的热度一直只增不减&#xff0c;但是头戴设备的续航一直被人诟病&#xff0c;如果增大电池就会让头显变得笨重影响体验&#xff0c;所以目前最佳的解决方案还是使用VR…
阅读更多...
Idea的基本使用带案例---详细易懂

Idea的基本使用带案例---详细易懂

一.idea是什么 有专业人士说&#xff0c;idea是天生适合做微软&#xff0c;当时我还想肯定是夸大其词了&#xff0c;但当你用起来的时候确实很爽&#xff0c;&#x1f60a;&#x1f60a; ntelliJ IDEA是一种集成开发环境&#xff08;IDE&#xff09;&#xff0c;由JetBrains开发…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023

友情链接： 我的编程经验分享 一条长河网 尧图网站开发