我开始在我的服务中引入活动性和就绪性探测器，我不确定我是否成功地让它工作，因为我无法自信地解释kubectl报告的状态。
kubectl describe pod mypod给了我这样的东西：
Name: myapp-5798dd798c-t7dqs
Namespace: dev
Node: docker-for-desktop/192.168.65.3
Start Time: Wed, 24 Oct 2018 13:22:54 +0200
Labels: app=myapp
pod-template-hash=1354883547
Annotations: version: v2
Status: Running
IP: 10.1.0.103
Controlled By: ReplicaSet/myapp-5798dd798c
Containers:
myapp:
Container ID: docker://5d39cb47d2278eccd6d28c1eb35f93112e3ad103485c1c825de634a490d5b736
Image: myapp:latest
Image ID: docker://sha256:61dafd0c208e2519d0165bf663e4b387ce4c2effd9237fb29fb48d316eda07ff
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Wed, 24 Oct 2018 13:23:06 +0200
Ready: True
Restart Count: 0
Liveness: http-get http://:80/healthz/live delay=0s timeout=10s period=60s #success=1 #failure=3
Readiness: http-get http://:80/healthz/ready delay=3s timeout=3s period=5s #success=1 #failure=3
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-gvnc2 (ro)
Conditions:
Type Status
Initialized True
Ready True
PodScheduled True
Volumes:
default-token-gvnc2:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-gvnc2
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 84s default-scheduler Successfully assigned myapp-5798dd798c-t7dqs to docker-for-desktop
Normal SuccessfulMountVolume 84s kubelet, docker-for-desktop MountVolume.SetUp succeeded for volume "default-token-gvnc2"
Normal Pulled 75s kubelet, docker-for-desktop Container image "myapp:latest" already present on machine
Normal Created 74s kubelet, docker-for-desktop Created container
Normal Started 72s kubelet, docker-for-desktop Started container
Warning Unhealthy 65s kubelet, docker-for-desktop Readiness probe failed: Get http://10.1.0.103:80/healthz/ready: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
现在，我注意到container已Status: Ready，但事件列表中的最后一个事件将状态列为Unhealthy，因为准备情况探测失败。(查看应用程序日志，我可以看到从那以后对就绪情况探测的传入请求更多，并且它们都成功了。
我应该如何解释这些信息？Kubernetes 认为我的 Pod 已经准备好了，还是没有准备好？
当容器的所有容器的就绪探测返回成功时，Pod 已准备就绪。在您的情况下，就绪情况探测在第一次尝试中失败，但下一次探测成功，容器进入就绪状态。下面是失败的就绪情况探测示例
下面的准备探测器在最后 11 米探测了 58 次并失败。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 11m default-scheduler Successfully assigned default/upnready to mylabserver.com
Normal Pulling 11m kubelet, mylabserver.com pulling image "luksa/kubia:v3"
Normal Pulled 11m kubelet, mylabserver.com Successfully pulled image "luksa/kubia:v3"
Normal Created 11m kubelet, mylabserver.com Created container
Normal Started 11m kubelet, mylabserver.com Started container
Warning Unhealthy 103s (x58 over 11m) kubelet, mylabserver.com Readiness probe failed: Get http://10.44.0.123:80/: dial tcp 10.44.0.123:80: connect:
此外，容器状态尚未准备就绪，如下所示
kubectl get pods -l run=upnready
NAME READY STATUS RESTARTS AGE
upnready 0/1 Running 0 17m
在您的情况下，就绪探测通过了运行状况检查，并且您的容器处于就绪状态。
您可以有效地利用初始延迟秒，周期秒，超时秒来获得更好的结果。这是一篇文章。
有关就绪探测和活动探测的文章