假设我们有一个应用程序，它需要一段时间来初始化并准备好接收流量。我们可以使用就绪探针来确保容器已准备好接收流量后才将其暴露给外部服务。
我们首先创建一个Deployment对象来运行应用程序。Deployment对象将自动创建一个副本集（ReplicaSet），并在其中运行指定数量的Pod。我们将使用nginx镜像作为应用程序的示例。
代码语言：javascript复制apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /
port: 80在上面的示例中，我们创建了一个名为nginx-deployment的Deployment对象，并指定了需要运行3个Pod副本。每个Pod都运行一个名为nginx-container的容器，该容器使用nginx镜像，并在80端口上监听流量。我们还将就绪探针配置为使用httpGet方法，向容器的/路径发送HTTP GET请求来检查容器是否已准备好接收流量。
我们可以通过kubectl命令检查Deployment的状态：
代码语言：javascript复制kubectl get deployment nginx-deployment输出应该类似于：
代码语言：javascript复制NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 10s上面的输出显示了Deployment中有3个Pod副本，所有的副本都已准备好，可以接收流量。
接下来，我们可以创建一个Service对象来暴露Deployment中的Pod给外部服务。Service对象将使用负载均衡器将流量分配给Deployment中的Pod。
代码语言：javascript复制apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer在上面的示例中，我们创建了一个名为nginx-service的Service对象，它将负责将流量分配给Deployment中的Pod。我们将type属性设置为LoadBalancer，这将自动为Service对象创建一个外部负载均衡器。
我们可以通过kubectl命令检查Service对象的状态：
代码语言：javascript复制kubectl get service nginx-service输出应该类似于：
代码语言：javascript复制NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service LoadBalancer 10.0.111.157 203.0.113.10 80:30549/TCP 10s上面的输出显示了Service对象的一些基本信息，包括CLUSTER-IP、EXTERNAL-IP和端口信息。
现在，我们可以使用EXTERNAL-IP和端口信息来访问我们的应用程序。但在我们开始访问应用程序之前，我们需要确保它已准备好接收流量。我们可以使用kubectl describe命令来检查Pod的状态：
代码语言：javascript复制kubectl describe pod <pod-name>输出应该类似于：
代码语言：javascript复制Name: nginx-deployment-7d6ff77df6-f7m6k
Namespace: default
Priority: 0
Node: minikube/192.168.99.107
Start Time: Mon, 31 May 2021 16:10:53 0300
Labels: app=nginx
pod-template-hash=7d6ff77df6
Annotations: <none>
Status: Running
IP: 172.17.0.4
IPs: <none>
Controlled By: ReplicaSet/nginx-deployment-7d6ff77df6
Containers:
nginx-container:
Container ID: docker://3d7df1c0d93fc7e97467a35c2e82d26134b6bfbca6f9cb6d82e57e65dcb61990
Image: nginx
Image ID: docker-pullable://nginx@sha256:95202e0d007bbd2edcad2b8eae1d2e6966efadfca6b7c6f9e57d71d06ef42b6f
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Mon, 31 May 2021 16:11:05 0300
Ready: False
Restart Count: 0
Readiness: http-get http://:80/ delay=0s timeout=1s period=10s #success=1 #failure=3
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vh2lm (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
kube-api-access-vh2lm:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 47s default-scheduler Successfully assigned default/nginx-deployment-7d6ff77df6-f7m6k to minikube
Normal Pulled 45s kubelet Container image "nginx" already present on machine
Normal Created 45s kubelet Created container nginx-container
Normal Started 45s kubelet Started container nginx-container输出显示了Pod中的nginx容器的状态。我们可以看到，容器的Readiness状态为False，这意味着它还没有准备好接收流量。我们还可以看到，容器的Readiness状态为False，这意味着它还没有准备好接收流量。我们还可以看到Readiness探针的详细信息，它会定期调用容器的/healthz端点以检查容器是否已准备好接收流量。
在这种情况下，我们的Readiness探针定义了一个HTTP GET请求，它将在容器的80端口上调用/healthz端点。如果该请求成功，则容器被认为是“就绪”的。
现在我们需要添加一个就绪探针来确保容器已准备好接收流量。在Kubernetes中，我们可以使用以下方式定义就绪探针：
- HTTP GET探针：向容器发送一个HTTP GET请求，以检查容器是否已准备好接收流量。
- TCP Socket探针：尝试连接到容器的指定端口，以检查容器是否已准备好接收流量。
- Exec探针：在容器中执行指定的命令，并检查命令的退出状态以确定容器是否已准备好接收流量。
在本例中，我们将使用HTTP GET探针。下面是一个包含就绪探针的更新后的Pod定义：
代码语言：javascript复制apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10在这个更新的Pod定义中，我们添加了一个名为readinessProbe的字段，并在其中定义了HTTP GET探针。探针将在容器的80端口上调用/healthz端点，并在初始延迟5秒后每10秒执行一次。
现在，我们使用kubectl apply命令将更新的Pod定义应用于Kubernetes集群：
代码语言：javascript复制kubectl apply -f pod.yaml如果我们再次运行kubectl describe pod命令，我们应该看到容器的Readiness状态已更改为True：
代码语言：javascript复制Name: nginx
Namespace: default
Priority: 0
Node: minikube/192.168.99.107
Start Time: Mon, 31 May 2021 16:10:53 0300
Labels: app=nginx
Annotations: <none>
Status: Running
IP: 172.17.0.4
IPs: <none>
Controlled By: <none>
Containers:
nginx:
Container ID: docker://d96f8e1536c5feca2d79bfb13aebc5e47e5a6c5dd5d5b68a904a8110e32fbaec
Image: nginx
Image ID: docker-pullable://nginx@sha256:95202e0d007bbd2edcad2b8eae1d2e6966efadfca6bf772bd0eeb695c2d17c5b
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Mon, 31 May 2021 16:11:04 0300
Ready: True
Restart Count: 0
Readiness: http-get http://:80/healthz delay=5s timeout=1s period=10s #success=1 #failure=3
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-x4rrz (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-x4rrz:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-x4rrz
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events: <none>现在我们可以确认容器已经准备好接收流量，Readiness探针定期调用/healthz端点以确保容器仍然是就绪的。
