K8s Pod 进阶

news2024/10/6 8:33:37

目录

资源限制

Pod 和容器的资源请求和限制

CPU 资源单位

内存资源单位 

示例1

示例2

重启策略（restartPolicy）

示例

健康检查

探针的三种规则

Probe支持三种检查方法

示例1：exec方式

示例2：httpGet方式

示例3：tcpSocket方式

示例4：就绪检测

示例5：就绪检测2

启动、退出动作

总结

Pod容器的资源限制

CPU资源量单位

QOS服务质量

Pod容器的3种探针（健康检查）

探针的3种探测方式

探针参数

Pod容器的启动动作和退出动作

资源限制

  • 当定义 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 值匹配。

Pod 和容器的资源请求和限制

spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu			//定义 cpu 的资源上限 
spec.containers[].resources.limits.memory		//定义内存的资源上限

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 资源。 

内存资源单位 

  • 内存的 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

示例1

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      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 内存。

示例2

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:
      requests:
        memory: "512Mi"
        cpu: "0.5"
      limits:
        memory: "1Gi"
        cpu: "1"

kubectl apply -f pod2.yaml
kubectl describe pod frontend

kubectl get pods -o wide

重启策略（restartPolicy）

  • 当 Pod 中的容器退出时通过节点上的 kubelet 重启容器。适用于 Pod 中的所有容器。

1、Always：当容器终止退出后，总是重启容器，默认策略

2、OnFailure：当容器异常退出（退出状态码非0）时，重启容器；正常退出则不重启容器

3、Never：当容器终止退出，从不重启容器

注意：K8S 中不支持重启 Pod 资源，只有删除重建

  • 在用 yaml 方式创建 Deployment 和 StatefulSet 类型时，restartPolicy 只能是 Always，kubectl run 创建 Pod 可以选择 Always,OnFailure,Never 三种策略

示例

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3


kubectl apply -f pod3.yaml

//查看Pod状态，等容器启动后30秒后执行exit退出进程进入error状态，就会重启次数加1
kubectl get pods

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3
  restartPolicy: Never
#注意：跟container同一个级别

kubectl apply -f pod3.yaml

//容器进入error状态不会进行重启
kubectl get pods -w

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3
  restartPolicy: Never
#注意：跟container同一个级别

kubectl apply -f pod3.yaml

//容器进入error状态不会进行重启
kubectl get pods -w

健康检查

  • 探针是由kubelet对容器执行的定期诊断。

探针的三种规则

  • livenessProbe ：判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。
  • readinessProbe ：判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service endpoints 中剔除删除该Pod的IP地址。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
  • startupProbe（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。

Probe支持三种检查方法

  • exec ：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
  • tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
  • httpGet ：对指定的端口和uri路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

每次探测都将获得以下三种结果之一

  • 成功（Success）：表示容器通过了检测。
  • 失败（Failure）：表示容器未通过检测。
  • 未知（Unknown）：表示检测没有正常进行。

示例1：exec方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 1
      initialDelaySeconds: 5
      periodSeconds: 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-exec
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
	  
kubectl create -f exec.yaml

kubectl describe pods liveness-exec

kubectl get pods -w

示例2：httpGet方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 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-httpget
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
	  
kubectl create -f httpget.yaml

kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html

kubectl get pods

示例3：tcpSocket方式

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 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: nginx
    image: soscscs/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 10
      failureThreshold: 2

kubectl create -f tcpsocket.yaml

kubectl exec -it probe-tcp  -- netstat -natp
kubectl get pods -w

示例4：就绪检测

vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

kubectl create -f readiness-httpget.yaml

//readiness探测失败，无法进入READY状态
kubectl get pods

kubectl exec -it readiness-httpget sh
kubectl get pods 
kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html
kubectl get pods -w

示例5：就绪检测2

vim readiness-myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp1
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp3
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  type: ClusterIP
  ports:
  - name: http
    port: 80
    targetPort: 80

kubectl create -f readiness-myapp.yaml
kubectl get pods,svc,endpoints -o wide
kubectl 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

启动、退出动作

vim post.yaml
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: soscscs/myapp:v1
    lifecycle:   #此为关键字段
      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-log
      mountPath: /var/log/nginx/
      readOnly: false
  initContainers:
  - name: init-myservice
    image: soscscs/myapp:v1
    command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  volumes:
  - name: message-log
    hostPath:
      path: /data/volumes/nginx/log/
      type: DirectoryOrCreate

kubectl create -f post.yaml
kubectl get pods -o wide
kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
/在 node01 节点上查看
[root@node01 ~]# cd /data/volumes/nginx/log/
[root@node01 log]# ls
access.log  error.log  message
[root@node01 log]# cat message 
Hello initContainers
Hello from the postStart handler
#由上可知，init Container先执行，然后当一个主容器启动后，Kubernetes 将立即发送 postStart 事件。

//删除 pod 后，再在 node02 节点上查看
kubectl delete pod lifecycle-demo

[root@node01 log]# cat message 
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，当在容器被终结之前， Kubernetes 将发送一个 preStop 事件。

总结

Pod容器的资源限制

resources.requests|limits（resources与image字段同一层级）
resources.requests.cpu|memory|hugepages-<size>|ephemeral-storage|nvidia.com/gpu(需要第三方插件支持)    设置Pod容器创建时需要预留的资源量
resources.limits.cpu|memory|hugepages-<size>|ephemeral-storage|nvidia.com/gpu(需要第三方插件支持)      设置Pod容器能够使用的资源量上限

如果Pod容器的进程使用的内存资源量超过limits.memory设置的值则会引发内存不足OOM错误

CPU资源量单位

CPU资源量单位：cpu个数 1  2  0.5  1.25         毫核  1000m   2000m   500m   1250m
memory|hugepages-<size>|ephemeral-storage资源量单位：纯整数（默认单位为字节）   2为底数的单位（Ki  Mi  Gi  Ti）   10为底数的单位（K  M  G  T）

QOS服务质量

  • 确定Pod的调度和驱逐优先级

Guaranteed：Pod 中的每个容器，包含初始化容器，必须指定内存、CPU 的 requests 和 limits，并且 requests 和 limits 要相等
Burstable：Pod 中至少一个容器具有内存 或 CPU requests
BestEffort：Pod 中的所有容器都没有指定内存 或 CPU 的 requests和 limits

优先级：Guaranteed > Burstable > BestEffort
Guaranteed (QoS) 的 Pod，其优先级最高，在其资源使用量不超过其 limits 的情况下，可以确保不被杀死
在系统内存资源紧张，且集群中没有 QoS 为 Best-Effort 级别的其它 Pod 时，一旦 Burstable (QoS) 的Pod 使用的资源量超过了其 requests，这些 Pod 就容易被杀死
BestEffort (QoS) 的 Pod，其优先级最低，当系统内存资源紧张时，这些 Pod 底层容器中的进程是最先会被杀死的

kubectl describe -n <命名空间> pods <资源名称>       查看Pod中的每个容器的资源限制的配置
kubectl describe node <node节点名称>                 查看node节点的资源总量、每个Pod的资源限制和节点的资源限制总量及比例

Pod容器的3种探针（健康检查）

  • 存活探针（livenessProbe）：探测Pod容器是否在正常运行。如果探测失败则kubelet杀掉容器，并根据容器重启策略决定是否重启容器
  • 就绪探针（readinessProbe）：探测Pod是否进入就绪状态(ready状态栏是否100%比例)，并做好接收service转发来的请求准备。 如果探测失败则Pod变成未就绪状态(0/1 1/2)，service就会删除相关联的Pod端点，并不再转发请求给处于未就绪状态的Pod
  • 启动探针（startupProbe）：探测Pod容器内的应用进程是否启动成功。在启动探针探测成功之前，存活探针和就绪探针都会处于暂停状态，直到启动探针探测成功为止， 如果探测失败则kubelet杀掉容器，并根据容器重启策略决定是否重启容器

探针的3种探测方式

  • exec：在容器里执行linux命令，如果命令返回码为0则认为探测成功，如果命令返回码为非0值则认为探测失败
  • httpGet：向PodIP和指定的端口及URL路径发送HTTP GET请求，如果HTTP响应状态码为2XX 3XX则认为探测成功，如果HTTP响应状态码为4XX 5XX则认为探测失败
  • tcpSocket：向PodIP和指定的端口发送TCP连接请求（三次握手），如果端口正确且TCP连接成功则认为探测成功，如果TCP连接失败则认为探测失败

探针参数

initialDelaySeconds：指定容器启动后延迟探测的时间（单位为秒）
periodSeconds：指定每次探测的间隔时间
failureThreshold：指定判定探测失败的连续失败次数
timeoutSeconds：指定探测超时等待的时间

Pod容器的启动动作和退出动作

Pod容器的启动动作和退出动作：lifecycle.postStart|preStop（lifecycle与image字段同一层级）
lifecycle.postStart      设置Pod容器启动时额外执行的操作，此操作不会作为容器pid=1的主进程
lifecycle.preStop        设置Pod容器被kubelet杀掉退出时执行的操作

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1494883.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

C++--调整数组顺序使奇数位于偶数前面

C++--调整数组顺序使奇数位于偶数前面

题目&#xff1a; 输入一个整数数组&#xff0c;实现一个函数来调整该数组中数字的顺序&#xff0c;使得所有的奇数位于数组的前半部分&#xff0c;所有的偶数位于数组的后半部分&#xff0c;并保证奇数和奇数&#xff0c;偶数和偶数之间的相对位置不变。 方法一&#xff1a; …
阅读更多...
第三届国际亲子游泳学术峰会，麒小佑为亲游行业提供健康解决方案

第三届国际亲子游泳学术峰会，麒小佑为亲游行业提供健康解决方案

第三届国际亲子游泳学术峰会大合影 2024年2月26—28日&#xff0c;第三届国际亲子游泳学术峰会在中国青岛成功召开。 第三届国际亲子游泳学术峰会是中国婴幼游泳行业最高标准的学术性会议&#xff0c;由亲游圈主办&#xff0c;旨在为本行业搭建一个高端圈层&#xff0c;帮助机…
阅读更多...
保留数据的重装系统教程！（win10系统）

保留数据的重装系统教程！（win10系统）

上车警告&#xff01;&#xff01;&#xff01; 本教程无需思考&#xff0c;跟着操作一步一步来就能完成系统的重装。原理是将C盘系统重装&#xff0c;其他盘符数据保存。适用于系统盘重装数据或更改系统版本。 重要提示&#xff01;&#xff01;&#xff01; C盘有重要学习资…
阅读更多...
18个惊艳的可视化大屏（第18辑）：数字资产场景

18个惊艳的可视化大屏（第18辑）：数字资产场景

hello&#xff0c;我是贝格前端工场&#xff0c;本次分享可视化大屏在数字资产领域的应用&#xff0c;喜欢文章的别忘点赞关注&#xff0c;文章底部也有其他行业的案例&#xff0c;有需求您说话&#xff08;可私信&#xff09;。 数字资产可视化大屏可以应用于各种场景&#x…
阅读更多...
从零学习Linux操作系统 第三十一部分 ansible常用模块介绍

从零学习Linux操作系统 第三十一部分 ansible常用模块介绍

一、ansible运行模块的两种方式 Ad-Hoc方式 ##利用ansible命令直接完成管理&#xff0c;主要用于临时命令使用场景 playbook方式 ##ansible脚本&#xff0c;主要用于大型项目场景&#xff0c;需要前期的规划&#xff0c;相当于shell当中的脚本 二、如何查看模块帮助 ansible…
阅读更多...
重磅：2024广州国际酒店工程照明展览会

重磅：2024广州国际酒店工程照明展览会

2024广州国际酒店工程照明展览会 Guangzhou international hotel engineering lighting exhibition 2024 时间&#xff1a;2024年12月19-21日 地点&#xff1a;广州.中国进出口商品交易会展馆 承办单位&#xff1a;广州佛兴英耀展览服务有限公司 上海昶文展览服务有限公司…
阅读更多...
基于springboot的蜗牛兼职网的设计与实现论文

基于springboot的蜗牛兼职网的设计与实现论文

摘 要 随着科学技术的飞速发展&#xff0c;社会的方方面面、各行各业都在努力与现代的先进技术接轨&#xff0c;通过科技手段来提高自身的优势&#xff0c;蜗牛兼职网当然也不能排除在外。蜗牛兼职网是以实际运用为开发背景&#xff0c;运用软件工程原理和开发方法&#xff0c…
阅读更多...
FISCO BCOS区块链平台上的智能合约压力测试指南

FISCO BCOS区块链平台上的智能合约压力测试指南

引言 在当今的分布式系统中&#xff0c;区块链技术因其去中心化、安全性和透明性而备受关注。随着区块链应用的不断扩展&#xff0c;对其性能和稳定性的要求也越来越高。因此&#xff0c;对区块链网络进行压力测试显得尤为重要。 目录 引言 1. 配置FISCO BCOS节点 2. 安装和…
阅读更多...
strongswan编译报错：NID_sm2p256v1未定义

strongswan编译报错：NID_sm2p256v1未定义

strongswan编译报错&#xff1a;NID_sm2p256v1未定义 现象&#xff1a; 原因&#xff1a; 我用的是openssl.-1.1.1d&#xff0c;发现NID_sm2p256v1曲线改为了NID_sm2&#xff08;gmssl用的是NID_sm2p256v1&#xff09;。对比了一下参数&#xff0c;是相同的。个人猜测是国际只…
阅读更多...
C语言初学10：共同体

C语言初学10：共同体

一、共同体作用 提供一种在相同内存位置存储不同数据类型的有效方式 二、共同体定义 union [union tag] //tag是可选参数 {member definition;member definition;...member definition; } [one or more union variables]; // 共同体变量是可选的 三、共同体占用空间大小 #…
阅读更多...
Docker安装MySQL镜像实战分享

Docker安装MySQL镜像实战分享

今天我们对Docker安装MySQL镜像进行实战分享&#xff0c;以更深入的了解容器的使用场景。我们在云付服务器Ubuntu环境上已经安装好了Docker&#xff0c;接下来我们开始安装mysql5.7版本&#xff0c;安装mysql有两种思路&#xff0c;直接拉取mysql镜像和自己做mysql镜像&#xf…
阅读更多...
【leetcode C++】电话号码的字母组合

【leetcode C++】电话号码的字母组合

17. 电话号码的字母组合 题目 给定一个仅包含数字 2-9 的字符串&#xff0c;返回所有它能表示的字母组合。答案可以按 任意顺序 返回。 给出数字到字母的映射如下&#xff08;与电话按键相同&#xff09;。注意 1 不对应任何字母。 题目链接 . - 力扣&#xff08;LeetCode&…
阅读更多...
Linux学习-函数指针和指针函数

Linux学习-函数指针和指针函数

目录 字符串是char *型&#xff0c;代表的是字符串的第一个元素的地址 指针函数&#xff1a; 函数指针&#xff1a; 字符串是char *型&#xff0c;代表的是字符串的第一个元素的地址 指针函数&#xff1a; int *Fun(int a, int b); 是函数&#xff0c;函数的返回值类型是…
阅读更多...
PaddleSeg分割框架解读[01] readme解读

PaddleSeg分割框架解读[01] readme解读

简介 PaddleSeg是基于飞桨PaddlePaddle的端到端图像分割套件，内置45+模型算法及140+预训练模型，支持配置化驱动和API调用开发方式，打通数据标注、模型开发、训练、压缩、部署的全流程，提供语义分割、交互式分割、Matting、全景分割四大分割能力，助力算法在医疗、工业、遥…
阅读更多...
docker容器内修改容器时间

docker容器内修改容器时间

因为开发需要&#xff0c;需要临时修改容器内时间测试&#xff0c;且不影响宿主机的原始时间。调研了下相关方法&#xff0c;现做记录如下. LIBFAKETIME ​ libfaketime 可以安装在linux和macOS系统。它使用操作系统的预加载library机制&#xff0c;因此对于静态链接或setuid程…
阅读更多...
前端面试拼图-原理源码

前端面试拼图-原理源码

摘要&#xff1a;最近&#xff0c;看了下慕课2周刷完n道面试题&#xff0c;记录下... 1. JS内存泄漏如何检测&#xff1f;场景有哪些? 1.1 垃圾回收 GC 垃圾回收是一种自动管理内存的机制&#xff0c;它负责在运行时跟踪内存的分配和使用情况&#xff0c;并在不再需要的对象…
阅读更多...
本机虚拟机centos7设置固定ip

本机虚拟机centos7设置固定ip

一、配置虚拟机网络 1、点击编辑 2、点击更改设置 记住子网地址&#xff1a;192.168.121.0 点击确定 二、配置虚拟机网络配置文件 首先进去root中&#xff0c;然后进入vim编辑器中 (1)su - root (2) vim /etc/sysconfig/network-scripts/ifcfg-ens33 在VIM编辑器中修改并添加…
阅读更多...
云计算的部署方式(公有云、私有云、混合云、社区云)

云计算的部署方式(公有云、私有云、混合云、社区云)

云计算的部署方式(公有云、私有云、混合云、社区云) 目录 零、00时光宝盒 一、云计算的部署方式 1.1、公有云&#xff08;Public Cloud&#xff09; 1.2、私有云&#xff08;Private Cloud&#xff09;　 1.3、混合云&#xff08;Hybrid Cloud&#xff09; 1.4、社区云&am…
阅读更多...
解决DBeaver执行脚本报错No active connection

解决DBeaver执行脚本报错No active connection

解决DBeaver执行脚本报错No active connection 1、报错问腿 2、问题解决 2.1、右键点击该数据库&#xff0c;选择SQL编辑器&#xff0c;选择新建SQL编辑器&#xff0c;然后将sql语句复制过去。 或者左击选中数据库后直接使用快捷键 Ctrl] 2.2、在Project-General中找到Scr…
阅读更多...
Linux-网络-011

Linux-网络-011

1网络协议模型 1.1【OSI】协议模型 1.1.1应用层 实际发送的数据应用层:HTTP 超文本传输协议HTTPS FTP 文件传输协议TFTP 简单文本传输协议SMTP 邮件传输协议MQTT TELNET ..1.1.2表示层 发送的数据是否加密1.1.3会话层 是否建立会话连接1.1.4传输层 数据…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023