kubernetes就绪探针使用(kubernetes event)

南窗分类：IT技术人气：102 回帖：0 发布于1年前收藏

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

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

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的状态：

kubectl get deployment nginx-deployment

输出应该类似于：

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

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

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

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对象的状态：

kubectl get service nginx-service

输出应该类似于：

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的状态：

kubectl describe pod <pod-name>

输出应该类似于：

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定义：

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集群：

kubectl apply -f pod.yaml

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

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端点以确保容器仍然是就绪的。

标签：kubernetes,

讨论这个帖子（0）垃圾回帖将一律封号处理……

技术交流QQ群