大佬教程收集整理的这篇文章主要介绍了Kubernetes Pod Probes 探针解析，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
Pod的探针主要用于决定Pod的生命周期，就是判断一个Pod什么时候算是启动成功，什么时候可以接收流量，什么时候需要重启，这三种功能就对应了三种探针类型。@H_801_3@
| Value | Description |
|---|---|
| Pending | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiTing to be scheduled as well as the time spent downloading container images over the network. |
| Running | The Pod has been bound to a node, and all of the containers have been created. at least one container is still running, or is in the process of starTing or restarTing. |
| Succeeded | All containers in the Pod have terminated in success, and will not be restarted. |
| Failed | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system. |
| Unknown | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicaTing with the node where the Pod should be running. |
WaiTing 不处于Running和Terminated状态的容器就是该状态。 Running 运行没有错误的状态，如果有PostStart，表示该PostStart已经执行并且成功结束。 Terminated 正常或者出现错误的结束。PreStop已经在该状态之前执行完。@H_801_3@
spec.restartPolicy有3中配置，Always, OnFailure, 和 Never. 默认值是 Always. 容器重启以指数级间隔增长(10s, 20s, 40s...),最大间隔不超过5分钟。一旦一个容器在没有任何问题的情况下执行了10分钟，kubelet将重置该容器的重启回退计时器。@H_801_3@
FEATURE STATE: Kubernetes v1.14 [stable] 你可以自己添加一些Pod条件控制容器的状态，readinessGates里面添加的条件，你必须将这些条件添加到status中，否则该条件的状态是false.@H_801_3@
kind: Pod
...
spec:
readinessGates:
- conditionType: "www.example.com/feature-1"
status:
conditions:
- type: Ready # a built in PodCondition
status: "false"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
- type: "www.example.com/feature-1" # an extra PodCondition
status: "false"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
containerStatuses:
- containerID: docker://abcd...
ready: true
...
在容器里执行一条指定的命令，状态码为0是成功。@H_801_3@
针对Pod在指定端口上的IP地址执行TCP检查。如果端口打开，则认为诊断成功。@H_801_3@
执行一个http GET请求，200<= 返回码 <400 时诊断成功。@H_801_3@
每种探针有以下三种结果。 success: The container passed the diagnostic. Failure: The container failed the diagnostic. Unknown: The diagnostic failed, so no action should be taken.@H_801_3@
FEATURE STATE: Kubernetes v1.0 [stable] 指示容器存活。如果探针失败，则按照restartPolicy指定的策略进行重启容器。如果没有提供该探针配置，默认为success。@H_801_3@
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 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
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
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
FEATURE STATE: Kubernetes v1.0 [stable] 指示容器已经准备好接收请求。如果探针失败，则将该Pod的IP从所有关联该Pod的endpoints中移除。如果配置了该探针，则在初始执行之前默认为Failure。如果没有配置该探针，默认为success。@H_801_3@
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
FEATURE STATE: Kubernetes v1.20 [stable] 指示容器已经启动成功。在该探针成功之前，其它所有探针都不会执行。如果该探针失败，kubelet将会删除该容器并根据策略重启。如果没有提供该探针，默认为success。@H_801_3@
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
initialDelaySeconds: number of seconds after the container has started before liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0. periodSeconds: How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. timeoutSeconds: number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. successThreshold: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup Probes. Minimum value is 1. failureThreshold: When a probe fails, Kubernetes will try failureThreshold times before giving up. Giving up in case of liveness probe means restarTing the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1.@H_801_3@
Note: Before Kubernetes 1.20, the field timeoutSeconds was not respected for exec probes: probes conTinued running indefinitely, even past their configured deadline, until a result was returned.@H_801_3@
This defect was corrected in Kubernetes v1.20. You may have been relying on the previous behavior, even without realizing it, as the default timeout is 1 second. As a cluster administrator, you can disable the feature gate ExecProbeTimeout (set it to falsE) on each kubelet to restore the behavior from older versions, then remove that override once all the exec probes in the cluster have a timeoutSeconds value set. If you have pods that are impacted from the default 1 second timeout, you should update their probe timeout so that you're ready for the eventual removal of that feature gate.@H_801_3@
With the fix of the defect, for exec probes, on Kubernetes 1.20+ with the dockershim container runtime, the process inside the container may keep running even after probe returned failure because of the timeout.@H_801_3@
Caution: Incorrect implementation of readiness probes may result in an ever growing number of processes in the container, and resource starvation if this is left unchecked.@H_801_3@
host: Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead. scheR_264_11845@e: scheR_264_11845@e to use for connecTing to the host (http or httpS). Defaults to http. path: Path to access on the http server. Defaults to /. httpHeaders: Custom headers to set in the request. http allows repeated headers. port: Name or number of the port to access on the container. number must be in the range 1 to 65535.@H_801_3@
For an http probe, the kubelet sends an http request to the specified path and port to perform the check. The kubelet sends the probe to the pod's IP address, unless the address is overridden by the optional host field in httpGet. If scheR_264_11845@e field is set to httpS, the kubelet sends an httpS request skipping the certificate verification. In most scenarios, you do not want to set the host field. Here's one scenario where you would set it. Suppose the container listens on 127.0.0.1 and the Pod's hostNetwork field is true. Then host, under httpGet, should be set to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common case, you should not use host, but rather set the Host header in httpHeaders.@H_801_3@
For an http probe, the kubelet sends two request headers in addition to the mandatory Host header: User-Agent, and Accept. The default values for these headers are kube-probe/1.21 (where 1.21 is the version of the kubelet ), and / respectively.@H_801_3@
You can override the default headers by defining .httpHeaders for the probe; for example@H_801_3@
livenessProbe:
httpGet:
httpHeaders:
- name: Accept
value: application/json
startupProbe:
httpGet:
httpHeaders:
- name: User-Agent
value: MyUserAgent
You can also remove these two headers by defining them with an empty value.@H_801_3@
livenessProbe:
httpGet:
httpHeaders:
- name: Accept
value: ""
startupProbe:
httpGet:
httpHeaders:
- name: User-Agent
value: ""
For a TCP probe, the kubelet makes the probe connection at the node, not in the pod, which means that you can not use a service name in the host parameter since the kubelet is unable to resolve it.@H_801_3@
FEATURE STATE: Kubernetes v1.21 [alpha] Prior to release 1.21, the pod-level terminationGracePeriodSeconds was used for terminaTing a container that failed its liveness or startup probe. This coupling was unintended and may have resulted in failed containers taking an unusually long time to restart when a pod-level terminationGracePeriodSeconds was set.@H_801_3@
In 1.21, when the feature flag ProbeTerminationGracePeriod is enabled, users can specify a probe-level terminationGracePeriodSeconds as part of the probe specification. When the feature flag is enabled, and both a pod- and probe-level terminationGracePeriodSeconds are set, the kubelet will use the probe-level value.@H_801_3@
For example,@H_801_3@
spec:
terminationGracePeriodSeconds: 3600 # pod-level
containers:
- name: test
image: ...
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 60
# Override pod-level terminationGracePeriodSeconds #
terminationGracePeriodSeconds: 60
Probe-level terminationGracePeriodSeconds cAnnot be set for readiness probes. It will be rejected by the API server.@H_801_3@
Controller会清理状态为Succeeded or Failed的Pod，见kube-controller的配置参数terminated-pod-gc-threshold。@H_801_3@
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/ https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/@H_801_3@
以上是大佬教程为你收集整理的Kubernetes Pod Probes 探针解析全部内容，希望文章能够帮你解决Kubernetes Pod Probes 探针解析所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。