背景：只要创建的pod的标签与service的pod选择器相匹配，它就成为服务的一部分，并且请求开始被重定向到pod。但是，如果这个pod没有准备好，如何处理服务请求呢？

5.5. 1 介绍就绪探针

就绪探针(readiness probe)会被定期调用，并确定特定的 pod 是否应该接收客户端请求。当容器的就绪探针返回成功时，表示容器己准备好接收请求。

就绪探针的类型

类似存活探针，有3种类型

• Exec 探针：执行一个命令。
• HTTP GET 探针：发送HTTP GET请求。
• TCP Socket 探针：建立TCP连接。

了解就绪探针的操作

启动容器时，可以为 Kubernetes 配置一个等待时间，经过等待时间后才可以执行第一次就绪检查。之后，它会周期性地调用探针，并根据就绪探针的结果采取行动。如果某个 pod 报告它尚未准备就绪，则会从服务中删除该 pod 。如果它再次准备就绪，则重新添加 pod。
就绪探针确保只有准备好处理请求的pod才可以接收请求。

了解就绪探针的重要性

就绪探针确保客户端只与正常的pod交互，并且永远不会知道系统存在问题。

5.5.2 向pod添加就绪探针

环境准备

cd /root/k8s
kubectl delete all --all
kubectl create -f kubia-rc.yaml
kubectl create -f kubia-svc-loadbalancer.yaml

向 pod template 添加就绪探针

如下图所示修改示例代码 kubia-rc.yaml文件，位置sepc.template.spec.containers下的第一个容器。
kubectl edit rc kubia
注意：在插入字段时可能有tab，而违反缩进。可以在vim中用\t查找tab或替换。

就绪探针将定期在容器内执行ls /var/ready命令。如果文件存在，则ls 命 令返回退出码 0, 否则返回非零的退出码。如果文件存在，则就绪探针将成功，否 则，它会失败。

要使探针生效，修改pod模板后要删除rc的pod，让它重新创建
kubectl delete po --all

观察并修改 pod 就绪状态

查看pod发现还未就绪

#在一个容器中创建/var/ready文件，使其就绪探针返回成功


#为什么该pod还未就绪？使用kubectl describe查看pod详细信息。输出包含以下内容：

Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3

大约等待10秒（period=10）发现pod已经准备就绪。
#其IP应该列为了service的endpoint，确认如下
kubectl get ep kubia-loadbalancer

命中只有一个就绪pod的service

你会发现每次请求service都只命中刚才就绪的pod：

5.5.3 了解就绪探针的实际作用

在实际应用中， 应用程序是否可以接收客户端请求， 决定了就绪探针应该返回成功或失败。

提示：如果想要从某个服务中手动添加或删除 pod, 请将 enabled=true 作为标签添加到 pod, 以及服务的标签选择器中。 当想要从服务中移除 pod 时，删除标签。

务必定义就绪探针

如果没有将就绪探针添加到 pod 中，它们几乎会立即成为服务端点。 如果应用程序需要很长时间才能开始监听传入连接，则在服务启动但尚未准备好接收传入连接时，客户端请求将被转发到该 pod。 因此， 客户端会看到 “连接被拒绝 ” 类型的错误。

提示：应该始终定义一个就绪探针，即使它只是向基本 URL 发送 HTTP 请求一样简单。

不要将关闭 pod 的逻辑纳入就绪探针中

只要删除（关闭）pod，Kubernetes就会从所有服务中移除该pod。所以不需要让就绪探针返回失败从而确保从服务中删除该pod。