科学家观察到三种新粒子 更好地理解夸克如何“成群结队”形成复合粒子
2022-07-08 17:18:43
假设我们有一个应用程序，它需要一段时间来初始化并准备好接收流量。我们可以使用就绪探针来确保容器已准备好接收流量后才将其暴露给外部服务。
(资料图)
我们首先创建一个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探针：向容器发送一个HTTP GET请求，以检查容器是否已准备好接收流量。TCP Socket探针：尝试连接到容器的指定端口，以检查容器是否已准备好接收流量。Exec探针：在容器中执行指定的命令，并检查命令的退出状态以确定容器是否已准备好接收流量。在本例中，我们将使用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端点以确保容器仍然是就绪的。