livenessProbe不像预期的那样工作

Question

在我的部署中，定义了以下livenessProbe：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-deployment
  labels:
    name: backend-deployment
    app: fc-test
spec:
  replicas: 1
  selector:
    matchLabels:
      name: fc-backend-pod
      app: fc-test
  template:
    metadata:
      name: fc-backend-pod
      labels:
        name: fc-backend-pod
        app: fc-test
    spec:
      containers:
      - name: fc-backend
        image: localhost:5000/backend:1.3
        ports:
        - containerPort: 4042
        env:
        - name: NODE_ENV
          value: "int"
        livenessProbe:
          exec:
            command:
            - RESULT=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | wc | awk '{print $3}');
            - if [[ $RESULT -lt 150 ]]; then exit 1; else exit 0; fi
          initialDelaySeconds: 20
          failureThreshold: 8
          periodSeconds: 10

由于API连接有时会出现一些问题，所以我决定设置一个操作检查是否从API获取整个请求的数据集。如果是这样的话，整组的大小大约是400 KB。如果不返回，则只返回一条短消息，响应的大小小于120 B。这时，来自探测的第二个命令进入:它检查RESULT环境变量是否低:如果是，则意味着响应没有包含所有想要的数据，并使用错误代码退出。

这两个命令都是通过从正在运行的容器内部调用来进行测试的，因此这两种情况都包括在内：( a)正确的数据获取--退出0，以及( b)只是一个获取的错误消息--退出1。

在没有探针的情况下运行的应用程序已经正常工作了至少3-4小时，然后连接问题出现了，它们最终是可以自我解决的，但是应用程序有点窒息，这是非常不可取的。

在执行探测之后，第一个不稳定问题在部署几分钟后开始发生。每隔几分钟，豆荚就会重新启动，重新启动计数也会以一种正常的方式增加。

我发现的描述部署的内容：

Pod Template:
  Labels:  app=fc-test
           name=fc-backend-pod
  Containers:
   nsc-backend:
    Image:      localhost:5000/backend:1.3
    Port:       4042/TCP
    Host Port:  0/TCP
    Liveness:   exec [RESULT=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | wc | awk '{print $3}'); if [[ $RESULT -lt 150 ]]; then exit 1; else exit 0; fi] delay=20s timeout=1s period=10s #success=1 #failure=8

这看起来是合理的，但是当使用exec命令进入正在运行的容器时，我发现echo $RESULT没有提供任何输出(只是一个空行)。

这是否意味着只成功地处理了探测器的第一次调用，而接下来的所有调用都没有成功处理？如何处理探测配置以使其按预期工作？

Answer 1

测试了这个问题的两个解决方案:第一个是稍微改变一下方法(谢谢@moonkotte关于日志记录的提示:它给了我在应用程序目录中保存一些证据的想法)。我没有使用环境变量，而是决定将curl的S输出转储到一个文件中。然后，我开始寻找一条特定的消息，当远程端点发生问题时(在本例中是Response is empty)。如果消息存在，grep会发现这一点，但与正常模式不同的是，由于存在-v参数(倒置)，它返回退出代码1。如果没有找到指定的消息，那么端点和退出代码0似乎都没有问题，导致吊舱继续正常工作。

整个命令如下所示：

livenessProbe:
  exec:
    command:
    - sh
    - -c
    - >-
        curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes |
        head -c 30 > /app/output.log &&
        grep -v 'Response is empty' /app/output.log

第二个解决方案是将curl命令放入bash脚本，并将其与整个映像一起传送。脚本本身看起来像：

#!/bin/bash
msg=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | head -c 30)
if [[ $msg == *"Response is empty"* ]]; then
        exit 1
else
        exit 0
fi

通过命令调用脚本：

livenessProbe:
  exec:
    command:
    - sh
    - ./liveness_check.sh

结果是一样的。第二种方法可以在更复杂的逻辑情况下使用，也可以作为解决办法。