Kubernetes(k8s)健康性检查:livenessprobe探测和readinessprobe探测
一.系统环境
本文主要基于Kubernetes1.21.9和Linux操作系统CentOS7.4。
| 服务器版本 | docker软件版本 | Kubernetes(k8s)集群版本 | CPU架构 |
|---|---|---|---|
| CentOS Linux release 7.4.1708 (Core) | Docker version 20.10.12 | v1.21.9 | x86_64 |
Kubernetes集群架构:k8scloude1作为master节点,k8scloude2,k8scloude3作为worker节点
| 服务器 | 操作系统版本 | CPU架构 | 进程 | 功能描述 |
|---|---|---|---|---|
| k8scloude1/192.168.110.130 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker,kube-apiserver,etcd,kube-scheduler,kube-controller-manager,kubelet,kube-proxy,coredns,calico | k8s master节点 |
| k8scloude2/192.168.110.129 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker,kubelet,kube-proxy,calico | k8s worker节点 |
| k8scloude3/192.168.110.128 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker,kubelet,kube-proxy,calico | k8s worker节点 |
二.前言
在Kubernetes中,保证应用的高可用性和稳定性非常重要。为此,Kubernetes提供了一些机制来监视容器的状态,并自动重启或删除不健康的容器。其中之一就是livenessprobe探测和readinessprobe探测。
本文将介绍Kubernetes中的livenessprobe探测和readinessprobe探测,并提供示例来演示如何使用它们。
使用livenessprobe探测和readinessprobe探测的前提是已经有一套可以正常运行的Kubernetes集群,关于Kubernetes(k8s)集群的安装部署,可以查看博客《Centos7 安装部署Kubernetes(k8s)集群》https://www.cnblogs.com/renshengdezheli/p/16686769.html。
三.Kubernetes健康性检查简介
Kubernetes支持三种健康检查,它们分别是:livenessprobe, readinessprobe 和 startupprobe。这些探针可以周期性地检查容器内的服务是否处于健康状态。
- livenessprobe:用于检查容器是否正在运行。如果容器内的服务不再响应,则Kubernetes会将其标记为Unhealthy状态并尝试重启该容器。通过重启来解决问题(重启指的是删除pod,然后创建一个相同的pod),方法有:command,httpGet,tcpSocket。
- readinessprobe:用于检查容器是否已准备好接收流量。当容器未准备好时,Kubernetes会将其标记为Not Ready状态,并将其从Service endpoints中删除。不重启,把用户发送过来的请求不在转发到此pod(需要用到service),方法有:command,httpGet,tcpSocket 。
- startupprobe:用于检查容器是否已经启动并准备好接收请求。与readinessprobe类似,但只在容器启动时运行一次。
在本文中,我们将重点介绍livenessprobe探测和readinessprobe探测。
四.创建没有探测机制的pod
创建存放yaml文件的目录和namespace
[root@k8scloude1 ~]# mkdir probe
[root@k8scloude1 ~]# kubectl create ns probe
namespace/probe created
[root@k8scloude1 ~]# kubens probe
Context "kubernetes-admin@kubernetes" modified.
Active namespace is "probe".
现在还没有pod
[root@k8scloude1 ~]# cd probe/
[root@k8scloude1 probe]# pwd
/root/probe
[root@k8scloude1 probe]# kubectl get pod
No resources found in probe namespace.
先创建一个普通的pod,创建了一个名为liveness-exec的Pod,使用busybox镜像来创建一个容器。该容器会执行args参数中的命令:touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 6000。
[root@k8scloude1 probe]# vim pod.yaml
[root@k8scloude1 probe]# cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
#terminationGracePeriodSeconds属性,将其设置为0,意味着容器在接收到终止信号时将立即关闭,而不会等待一段时间来完成未完成的工作。
terminationGracePeriodSeconds: 0
containers:
- name: liveness
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 6000
#先创建一个普通的pod
[root@k8scloude1 probe]# kubectl apply -f pod.yaml
pod/liveness-exec created
查看pod
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-exec 1/1 Running 0 6s 10.244.112.176 k8scloude2 <none> <none>
查看pod里的/tmp文件
[root@k8scloude1 probe]# kubectl exec -it liveness-exec -- ls /tmp
pod运行30秒之后,/tmp/healthy文件被删除,pod还会继续运行6000秒,/tmp/healthy文件存在就判定pod正常,/tmp/healthy文件不存在就判定pod异常,但是目前没有探测机制,所以pod还是正在运行状态。
[root@k8scloude1 probe]# kubectl exec -it liveness-exec -- ls /tmp
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-exec 1/1 Running 0 3m29s 10.244.112.176 k8scloude2 <none> <none>
删除pod,添加探测机制
[root@k8scloude1 probe]# kubectl delete -f pod.yaml
pod "liveness-exec" deleted
[root@k8scloude1 probe]# kubectl get pod -o wide
No resources found in probe namespace.
五.添加livenessprobe探测
5.1 使用command的方式进行livenessprobe探测
创建具有livenessprobe探测的pod
创建了一个名为liveness-exec的Pod,使用busybox镜像来创建一个容器。该容器会执行args参数中的命令:touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600。
Pod还定义了一个名为livenessProbe的属性来定义liveness探针。该探针使用exec检查/tmp/healthy文件是否存在。如果该文件存在,则Kubernetes认为容器处于健康状态;否则,Kubernetes将尝试重启该容器。
liveness探测将在容器启动后5秒钟开始,并每隔5秒钟运行一次。
[root@k8scloude1 probe]# vim podprobe.yaml
#现在加入健康检查:command的方式
[root@k8scloude1 probe]# cat podprobe.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
terminationGracePeriodSeconds: 0
containers:
- name: liveness
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
#容器启动的5秒内不监测
initialDelaySeconds: 5
#每5秒检测一次
periodSeconds: 5
[root@k8scloude1 probe]# kubectl apply -f podprobe.yaml
pod/liveness-exec created
观察pod里的/tmp文件和pod状态
[root@k8scloude1 probe]# kubectl exec -it liveness-exec -- ls /tmp
healthy
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-exec 1/1 Running 0 18s 10.244.112.177 k8scloude2 <none> <none>
[root@k8scloude1 probe]# kubectl exec -it liveness-exec -- ls /tmp
healthy
[root@k8scloude1 probe]# kubectl exec -it liveness-exec -- ls /tmp
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-exec 1/1 Running 0 36s 10.244.112.177 k8scloude2 <none> <none>
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-exec 1/1 Running 0 43s 10.244.112.177 k8scloude2 <none> <none>
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-exec 1/1 Running 1 50s 10.244.112.177 k8scloude2 <none> <none>
加了探测机制之后,当/tmp/healthy不存在,则会进行livenessProbe重启pod,如果不加宽限期terminationGracePeriodSeconds: 0,一般75秒的时候会重启一次
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-exec 1/1 Running 3 2m58s 10.244.112.177 k8scloude2 <none> <none>
删除pod
[root@k8scloude1 probe]# kubectl delete -f podprobe.yaml
pod "liveness-exec" deleted
[root@k8scloude1 probe]# kubectl get pod -o wide
No resources found in probe namespace.
5.2 使用httpGet的方式进行livenessprobe探测
创建了一个名为liveness-httpget的Pod,使用nginx镜像来创建一个容器。该容器设置了一个HTTP GET请求的liveness探针,检查是否能够成功访问Nginx的默认主页/index.html。如果标准无法满足,则Kubernetes将认为容器不健康,并尝试重启该容器。
liveness探测将在容器启动后10秒钟开始,并每隔10秒钟运行一次。failureThreshold属性表示最大连续失败次数为3次,successThreshold属性表示必须至少1次成功才能将容器视为“健康”。timeoutSeconds属性表示探测请求的超时时间为10秒。
[root@k8scloude1 probe]# vim podprobehttpget.yaml
#httpGet的方式
[root@k8scloude1 probe]# cat podprobehttpget.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-httpget
spec:
terminationGracePeriodSeconds: 0
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
httpGet:
path: /index.html
port: 80
scheme: HTTP
#容器启动的10秒内不监测
initialDelaySeconds: 10
#每10秒检测一次
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
[root@k8scloude1 probe]# kubectl apply -f podprobehttpget.yaml
pod/liveness-httpget created
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-httpget 1/1 Running 0 6s 10.244.112.178 k8scloude2 <none> <none>
查看/usr/share/nginx/html/index.html文件
[root@k8scloude1 probe]# kubectl exec -it liveness-httpget -- ls /usr/share/nginx/html/index.html
/usr/share/nginx/html/index.html
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-httpget 1/1 Running 0 2m3s 10.244.112.178 k8scloude2 <none> <none>
删除/usr/share/nginx/html/index.html文件
[root@k8scloude1 probe]# kubectl exec -it liveness-httpget -- rm /usr/share/nginx/html/index.html
[root@k8scloude1 probe]# kubectl exec -it liveness-httpget -- ls /usr/share/nginx/html/index.html
ls: cannot access '/usr/share/nginx/html/index.html': No such file or directory
command terminated with exit code 2
观察pod状态和/usr/share/nginx/html/index.html文件,通过端口80探测文件/usr/share/nginx/html/index.html,探测不到说明文件有问题,则进行livenessProbe重启pod。
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-httpget 1/1 Running 1 2m43s 10.244.112.178 k8scloude2 <none> <none>
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-httpget 1/1 Running 1 2m46s 10.244.112.178 k8scloude2 <none> <none>
[root@k8scloude1 probe]# kubectl exec -it liveness-httpget -- ls /usr/share/nginx/html/index.html
/usr/share/nginx/html/index.html
#通过端口80探测文件/usr/share/nginx/html/index.html,探测不到说明文件有问题,则进行livenessProbe重启pod
[root@k8scloude1 probe]# kubectl exec -it liveness-httpget -- ls /usr/share/nginx/html/index.html
/usr/share/nginx/html/index.html
删除pod
[root@k8scloude1 probe]# kubectl delete -f podprobehttpget.yaml
pod "liveness-httpget" deleted
[root@k8scloude1 probe]# kubectl get pod -o wide
No resources found in probe namespace.
5.3 使用tcpSocket的方式进行livenessprobe探测
创建了一个名为liveness-tcpsocket的Pod,使用nginx镜像来创建一个容器。该容器设置了一个TCP Socket连接的liveness探针,检查是否能够成功连接到指定的端口8080。如果无法连接,则Kubernetes将认为容器不健康,并尝试重启该容器。
liveness探测将在容器启动后10秒钟开始,并每隔10秒钟运行一次。failureThreshold属性表示最大连续失败次数为3次,successThreshold属性表示必须至少1次成功才能将容器视为“健康”。timeoutSeconds属性表示探测请求的超时时间为10秒。
[root@k8scloude1 probe]# vim podprobetcpsocket.yaml
#tcpSocket的方式:
[root@k8scloude1 probe]# cat podprobetcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-tcpsocket
spec:
terminationGracePeriodSeconds: 0
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
tcpSocket:
port: 8080
#容器启动的10秒内不监测
initialDelaySeconds: 10
#每10秒检测一次
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
[root@k8scloude1 probe]# kubectl apply -f podprobetcpsocket.yaml
pod/liveness-tcpsocket created
观察pod状态,因为nginx运行的是80端口,但是我们探测的是8080端口,所以肯定探测失败,livenessProbe就会重启pod
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-tcpsocket 1/1 Running 0 10s 10.244.112.179 k8scloude2 <none> <none>
[root@k8scloude1 probe]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
liveness-tcpsocket 1/1 Running 1 55s 10.244.112.179 k8scloude2 <none> <none>
删除pod
[root@k8scloude1 probe]# kubectl delete -f podprobetcpsocket.yaml
pod "liveness-tcpsocket" deleted
下面添加readinessprobe探测
六.readinessprobe探测
因为readiness probe的探测机制是不重启的,只是把用户发送过来的请求不再转发到此pod上,为了模拟此情景,创建三个pod,svc把用户请求转发到这三个pod上。
小技巧TIPS:要想看文字有没有对齐,可以使用 :set cuc ,取消使用 :set nocuc
创建pod,readinessProbe探测 /tmp/healthy文件,如果 /tmp/healthy文件存在则正常,不存在则异常。lifecycle postStart表示容器启动之后创建/tmp/healthy文件。
[root@k8scloude1 probe]# vim podreadinessprobecommand.yaml
[root@k8scloude1 probe]# cat podreadinessprobecommand.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: readiness
name: readiness-exec
spec:
terminationGracePeriodSeconds: 0
containers:
- name: readiness
image: nginx
imagePullPolicy: IfNotPresent
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
#容器启动的5秒内不监测
initialDelaySeconds: 5
#每5秒检测一次
periodSeconds: 5
lifecycle:
postStart:
exec:
command: ["/bin/sh","-c","touch /tmp/healthy"]
创建三个名字不同的pod
[root@k8scloude1 probe]# kubectl apply -f podreadinessprobecommand.yaml
pod/readiness-exec created
[root@k8scloude1 probe]# sed 's/readiness-exec/readiness-exec2/' podreadinessprobecommand.yaml | kubectl apply -f -
pod/readiness-exec2 created
[root@k8scloude1 probe]# sed 's/readiness-exec/readiness-exec3/' podreadinessprobecommand.yaml | kubectl apply -f -
pod/readiness-exec3 created
查看pod的标签
[root@k8scloude1 probe]# kubectl get pod -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
readiness-exec 1/1 Running 0 23s 10.244.112.182 k8scloude2 <none> <none> test=readiness
readiness-exec2 1/1 Running 0 15s 10.244.251.236 k8scloude3 <none> <none> test=readiness
readiness-exec3 0/1 Running 0 9s 10.244.112.183 k8scloude2 <none> <none> test=readiness
三个pod的标签是一样的
[root@k8scloude1 probe]# kubectl get pod -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
readiness-exec 1/1 Running 0 26s 10.244.112.182 k8scloude2 <none> <none> test=readiness
readiness-exec2 1/1 Running 0 18s 10.244.251.236 k8scloude3 <none> <none> test=readiness
readiness-exec3 1/1 Running 0 12s 10.244.112.183 k8scloude2 <none> <none> test=readiness
为了标识3个pod的不同,修改nginx的index文件
[root@k8scloude1 probe]# kubectl exec -it readiness-exec -- sh -c "echo 111 > /usr/share/nginx/html/index.html"
[root@k8scloude1 probe]# kubectl exec -it readiness-exec2 -- sh -c "echo 222 > /usr/share/nginx/html/index.html"
[root@k8scloude1 probe]# kubectl exec -it readiness-exec3 -- sh -c "echo 333 > /usr/share/nginx/html/index.html"
创建一个service服务,把用户请求转发到这三个pod上
[root@k8scloude1 probe]# kubectl expose --name=svc1 pod readiness-exec --port=80
service/svc1 exposed
test=readiness这个标签有3个pod
[root@k8scloude1 probe]# kubectl get svc -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
svc1 ClusterIP 10.101.38.121 <none> 80/TCP 23s test=readiness
[root@k8scloude1 probe]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
readiness-exec 1/1 Running 0 7m14s test=readiness
readiness-exec2 1/1 Running 0 7m6s test=readiness
readiness-exec3 1/1 Running 0 7m test=readiness
访问service 服务 ,发现用户请求都分别转发到三个pod
[root@k8scloude1 probe]# while true ; do curl -s 10.101.38.121 ; sleep 1 ; done
333
111
333
222
111
......
删除pod readiness-exec2的探测文件
[root@k8scloude1 probe]# kubectl exec -it readiness-exec2 -- rm /tmp/healthy
因为/tmp/healthy探测不成功,readiness-exec2的READY状态变为了0/1,但是STATUS还为Running状态,还可以进入到readiness-exec2 pod里。由于readinessprobe只是不把用户请求转发到异常pod,所以异常pod不会被删除。
[root@k8scloude1 probe]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
readiness-exec 1/1 Running 0 10m test=readiness
readiness-exec2 0/1 Running 0 10m test=readiness
readiness-exec3 1/1 Running 0 10m test=readiness
[root@k8scloude1 probe]# kubectl exec -it readiness-exec2 -- bash
root@readiness-exec2:/# exit
exit
kubectl get ev (查看事件),可以看到“88s Warning Unhealthy pod/readiness-exec2 Readiness probe failed: cat: /tmp/healthy: No such file or directory”警告
[root@k8scloude1 probe]# kubectl get ev
LAST SEEN TYPE REASON OBJECT MESSAGE
......
32m Normal Pulled pod/readiness-exec2 Container image "nginx" already present on machine
32m Normal Created pod/readiness-exec2 Created container readiness
32m Normal Started pod/readiness-exec2 Started container readiness
15m Normal Killing pod/readiness-exec2 Stopping container readiness
13m Normal Scheduled pod/readiness-exec2 Successfully assigned probe/readiness-exec2 to k8scloude3
13m Normal Pulled pod/readiness-exec2 Container image "nginx" already present on machine
13m Normal Created pod/readiness-exec2 Created container readiness
13m Normal Started pod/readiness-exec2 Started container readiness
88s Warning Unhealthy pod/readiness-exec2 Readiness probe failed: cat: /tmp/healthy: No such file or directory
32m Normal Scheduled pod/readiness-exec3 Successfully assigned probe/readiness-exec3 to k8scloude3
32m Normal Pulled pod/readiness-exec3 Container image "nginx" already present on machine
32m Normal Created pod/readiness-exec3 Created container readiness
32m Normal Started pod/readiness-exec3 Started container readiness
15m Normal Killing pod/readiness-exec3 Stopping container readiness
13m Normal Scheduled pod/readiness-exec3 Successfully assigned probe/readiness-exec3 to k8scloude2
13m Normal Pulled pod/readiness-exec3 Container image "nginx" already present on machine
13m Normal Created pod/readiness-exec3 Created container readiness
13m Normal Started pod/readiness-exec3 Started container readiness
再次访问service服务,发现用户请求只转发到了111和333,说明readiness probe探测生效。
[root@k8scloude1 probe]# while true ; do curl -s 10.101.38.121 ; sleep 1 ; done
111
333
333
333
111
......
七.总结
通过本文,您应该已经了解到如何使用livenessprobe探测和readinessprobe探测来监视Kubernetes中容器的健康状态。通过定期检查服务状态、命令退出码、HTTP响应和内存使用情况,您可以自动重启不健康的容器,并提高应用的可用性和稳定性。
Kubernetes(k8s)健康性检查:livenessprobe探测和readinessprobe探测的更多相关文章
- LVS实现健康性检查功能
LVS高可用性 Director不可用,整个系统将不可用:SPoF Single Point of Failure 解决方案:高可用 keepalived heartbeat/corosync 某RS ...
- Kubernetes(K8S) kubesphere 安装
安装KubeSphere最好的方法就是参考官方文档,而且官方文档是中文的. 官网地址:https://kubesphere.com.cn/ https://github.com/kubesphere/ ...
- Kubernetes 健康检查的两种机制:Liveness 探测和 Readiness 探测
Kubernetes 健康检查的两种机制:Liveness 探测和 Readiness 探测,并实践了健康检查在 Scale Up 和 Rolling Update 场景中的应用.kubelet使用启 ...
- aspnetcore.webapi实战k8s健康探测机制 - kubernetes
1.浅析k8s两种健康检查机制 Liveness k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈.比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可 ...
- aspnetcore.webapi实践k8s健康探测机制 - kubernetes
1.浅析k8s两种健康检查机制 Liveness k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈.比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可 ...
- Docker系列(五):.Net Core实现k8s健康探测机制
k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈.比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可能是资源死锁,此时 httpd 进程并没有异常退出 ...
- k8s健康检查(七)--技术流ken
默认的健康检查 强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness ...
- Kubernetes Pod 健康检查
参考文档: https://jimmysong.io/kubernetes-handbook/guide/configure-liveness-readiness-probes.html 一.Pod的 ...
- Kubernetes 健康状态检查(九)
强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness 探测机制设置更精 ...
- linux运维、架构之路-K8s健康检查Health Check
一.Health Check介绍 强大的自愈能力是k8s容器编排引擎一个重要特性,自愈能力的默认实现方式为自动重启发生故障的容器,另外还可以利用Liveness和Readiness探测 ...
随机推荐
- 剑指offer 第 17 天
第 17 天 排序(中等) 剑指 Offer 40. 最小的k个数 输入整数数组 arr ,找出其中最小的 k 个数.例如,输入4.5.1.6.2.7.3.8这8个数字,则最小的4个数字是1.2.3. ...
- 在ArcGIS Pro中对Revit的bim数据进行地理配准(平移、旋转等)
在ArcGIS Pro中,打开Revit的rvt格式数据,默认是没有坐标系,且位置会放置在原点位置(0,0),在实际使用过程中,需要对rvt数据进行地理配准,包括平移.旋转等操作将bim数据放置在正确 ...
- Kubeadm安装k8s集群升级100年证书时报错:Unable to connect to the server: EOF:求解决方法.
报错信息: 使用命令时: Kubelet服务报错: 报错情况,在更新完k8s100年证书的时候,到最后重新启动kubelet服务的时候,服务是可以重新启动的,但是kubectl的命令是无法使用的,会等 ...
- Flask框架cbv的写法、请求与响应、请求扩展、session源码分析、闪现
本篇文章将会详细讲在flask框架如何写cbv.请求与响应.请求扩展.session源码分析.闪现等知识点. 目录 一.flask写CBV 二.请求与响应 三.session 四.闪现flash 五. ...
- 如何通过Java代码将添加页码到PDF文档?
页码可以清楚了解总页数.定位页数快速寻找自己所要的文段.打印时不会分不清头中尾.很多人在使用办公软件的时候就会选择PDF进行文档的保存,因为PDF在保存之后不会出现乱码甚至是格式改变的情况.在PDF中 ...
- python入门教程之十二Open及file操作
读和写文件 open() 将会返回一个 file 对象,基本语法格式如下: open(filename, mode) filename:包含了你要访问的文件名称的字符串值. mode:决定了打开文件的 ...
- odbe简介
Odbc简介 今天工作中遇到一个问题,缺少某个数据库驱动程序,百度半天才发现原来室odbc原因,所以,就捎带学习了一下odbc, ODBC数据源中文名称:开放数据库互联英文名称:Open Databa ...
- [数据库]MYSQL之InnoDB存储引擎 VS MYISAM存储引擎
InnoDB VS MYISAM 参考文献 innoDB与MyISAM的区别 - Zhihu
- Burp Suite最新版本专业版激活2022.12.1附原文件
Burp Suite 攻击web 应用程序的集成平台 Burp Suite 是用于攻击web 应用程序的集成平台,包含了许多工具.Burp Suite为这些工具设计了许多接口,以加快攻击应用程序的过程 ...
- python语法的入门
1.变量 1.1: 底层原理:现在内存空间申请一块地址来储存变量值, 然后把申请的内存地址跟变量名绑定在一起 之后只需通过访问变量名就可以获取变量值 1.2:一个变量名只能指向一个内存地址,但是一个内 ...