假设我们有一个应用程序，它需要一段时间来初始化并准备好接收流量。我们可以使用就绪探针来确保容器已准备好接收流量后才将其暴露给外部服务。

(资料图)

我们首先创建一个Deployment对象来运行应用程序。Deployment对象将自动创建一个副本集（ReplicaSet），并在其中运行指定数量的Pod。我们将使用nginx镜像作为应用程序的示例。

apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx-deploymentspec:  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的状态：

kubectl get deployment nginx-deployment

输出应该类似于：

NAME               READY   UP-TO-DATE   AVAILABLE   AGEnginx-deployment   3/3     3            3           10s

上面的输出显示了Deployment中有3个Pod副本，所有的副本都已准备好，可以接收流量。

接下来，我们可以创建一个Service对象来暴露Deployment中的Pod给外部服务。Service对象将使用负载均衡器将流量分配给Deployment中的Pod。

apiVersion: v1kind: Servicemetadata:  name: nginx-servicespec:  selector:    app: nginx  ports:  - protocol: TCP    port: 80    targetPort: 80  type: LoadBalancer

在上面的示例中，我们创建了一个名为nginx-service的Service对象，它将负责将流量分配给Deployment中的Pod。我们将type属性设置为LoadBalancer，这将自动为Service对象创建一个外部负载均衡器。

我们可以通过kubectl命令检查Service对象的状态：

kubectl get service nginx-service

输出应该类似于：

NAME           TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGEnginx-service  LoadBalancer   10.0.111.157  203.0.113.10  80:30549/TCP   10s

上面的输出显示了Service对象的一些基本信息，包括CLUSTER-IP、EXTERNAL-IP和端口信息。

现在，我们可以使用EXTERNAL-IP和端口信息来访问我们的应用程序。但在我们开始访问应用程序之前，我们需要确保它已准备好接收流量。我们可以使用kubectl describe命令来检查Pod的状态：

kubectl describe pod 

输出应该类似于：

Name:           nginx-deployment-7d6ff77df6-f7m6kNamespace:      defaultPriority:       0Node:           minikube/192.168.99.107Start Time:     Mon, 31 May 2021 16:10:53 +0300Labels:         app=nginx                pod-template-hash=7d6ff77df6Annotations:    Status:         RunningIP:             172.17.0.4IPs:            Controlled By:  ReplicaSet/nginx-deployment-7d6ff77df6Containers:  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:        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:           DownwardAPI:             trueQoS Class:                   BestEffortNode-Selectors:              Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300sEvents:  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探针。下面是一个包含就绪探针的更新后的Pod定义：

apiVersion: v1kind: Podmetadata:  name: nginx  labels:    app: nginxspec:  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集群：

kubectl apply -f pod.yaml

如果我们再次运行kubectl describe pod命令，我们应该看到容器的Readiness状态已更改为True：

Name:           nginxNamespace:      defaultPriority:       0Node:           minikube/192.168.99.107Start Time:     Mon, 31 May 2021 16:10:53 +0300Labels:         app=nginxAnnotations:    Status:         RunningIP:             172.17.0.4IPs:            Controlled By:  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:        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:    falseQoS Class:       BestEffortNode-Selectors:  Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300sEvents:          

现在我们可以确认容器已经准备好接收流量，Readiness探针定期调用/healthz端点以确保容器仍然是就绪的。