livenessProbe ไม่ทำงานตามที่คาดไว้

ในการปรับใช้ของฉันต่อไปนี้ ความสด ถูกกำหนด:

apiVersion: แอป/v1
ประเภท: การปรับใช้
ข้อมูลเมตา:
  ชื่อ: การปรับใช้แบ็กเอนด์
  ป้ายกำกับ:
    ชื่อ: การปรับใช้แบ็กเอนด์
    แอพ: fc-test
ข้อมูลจำเพาะ:
  แบบจำลอง: 1
  ตัวเลือก:
    ป้ายกำกับการแข่งขัน:
      ชื่อ: fc-backend-pod
      แอพ: fc-test
  แม่แบบ:
    ข้อมูลเมตา:
      ชื่อ: fc-backend-pod
      ป้ายกำกับ:
        ชื่อ: fc-backend-pod
        แอพ: fc-test
    ข้อมูลจำเพาะ:
      ตู้คอนเทนเนอร์:
      - ชื่อ: fc-แบ็กเอนด์
        รูปภาพ: localhost:5000/แบ็กเอนด์:1.3
        พอร์ต:
        - พอร์ตคอนเทนเนอร์: 4042
        สภาพแวดล้อม:
        - ชื่อ: NODE_ENV
          ค่า: "int"
        livenessProbe:
          ผู้บริหาร:
            สั่งการ:
            - RESULT=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | wc | awk '{print $3}');
            - ถ้า [[ $RESULT -lt 150 ]]; แล้วออก 1; อื่นออก 0; ไฟ
          initialDelaySeconds: 20
          เกณฑ์ความล้มเหลว: 8
          periodSeconds: 10

เนื่องจากบางครั้งมีปัญหาเกี่ยวกับการเชื่อมต่อ API ฉันจึงตัดสินใจตั้งค่าการดำเนินการตรวจสอบว่าข้อมูลที่ร้องขอทั้งชุดได้รับการดึงจาก API หรือไม่ หากเป็นเช่นนั้น ทั้งชุดจะมีขนาดประมาณ 400 KB หากไม่เป็นเช่นนั้น ระบบจะส่งกลับเฉพาะข้อความสั้นๆ และขนาดของการตอบกลับจะต่ำกว่า 120 B และนี่คือเมื่อคำสั่งที่สองจากโพรบเข้ามา: จะตรวจสอบว่า ผลลัพธ์ ตัวแปรสภาพแวดล้อมต่ำ: ถ้าเป็นเช่นนั้น แสดงว่าการตอบสนองไม่มีข้อมูลที่ต้องการทั้งหมดและออกด้วยรหัสข้อผิดพลาด

คำสั่งทั้งสองได้รับการทดสอบโดยการโทรจากภายในคอนเทนเนอร์ที่กำลังรัน ดังนั้นจึงครอบคลุมทั้งสองกรณี: a) ดึงข้อมูลมาถูกต้อง - ออก 0 และ b) ดึงเฉพาะข้อความแสดงข้อผิดพลาด - ออก 1

แอปพลิเคชันที่ทำงานโดยไม่มีโพรบนั้นทำงานอย่างถูกต้องเป็นเวลาอย่างน้อย 3-4 ชั่วโมง จากนั้นปัญหาเกี่ยวกับการเชื่อมต่อก็ปรากฏขึ้นและพวกเขาสามารถแก้ไขได้เองในท้ายที่สุด แต่ทำให้แอปติดขัดเล็กน้อย ซึ่งเป็นสิ่งที่ค่อนข้างไม่พึงปรารถนา

หลังจากใช้งานโพรบแล้ว ปัญหาความไม่เสถียรอย่างแรกเริ่มเกิดขึ้นหลังจากการปรับใช้ไม่กี่นาที พ็อดถูกรีสตาร์ททุกๆ สองสามนาที และจำนวนการรีสตาร์ทเพิ่มขึ้นในลักษณะปกติ

สิ่งที่ฉันพบอธิบายการปรับใช้:

เทมเพลตพ็อด:
  ป้ายกำกับ: app=fc-test
           name=fc-แบ็กเอนด์-พ็อด
  ตู้คอนเทนเนอร์:
   nsc-แบ็กเอนด์:
    รูปภาพ: localhost:5000/แบ็กเอนด์:1.3
    พอร์ต: 4042/TCP
    พอร์ตโฮสต์: 0/TCP
    ความมีชีวิตชีวา: exec [RESULT=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | wc | awk '{print $3}'); ถ้า [[ $RESULT -lt 150 ]]; แล้วออก 1; อื่นออก 0; fi] ล่าช้า = หมดเวลา 20 วินาที = 1 วินาที ระยะเวลา = 10 วินาที # สำเร็จ = 1 # ล้มเหลว = 8

มันดูสมเหตุสมผล แต่เมื่อเข้าสู่คอนเทนเนอร์ที่รันด้วย ผู้บริหาร คำสั่ง ฉันพบว่า สะท้อน $RESULT ไม่มีเอาต์พุต (เพียงบรรทัดว่าง)

หมายความว่าเฉพาะการเรียกโพรบครั้งแรกเท่านั้นที่ได้รับการประมวลผลสำเร็จและการโทรที่ตามมาทั้งหมดไม่สำเร็จใช่หรือไม่ จะเข้าใกล้การกำหนดค่าโพรบเพื่อให้ทำงานตามที่ตั้งใจไว้ได้อย่างไร?

ทดสอบวิธีแก้ปัญหาสองวิธี: วิธีแรกเปลี่ยนวิธีการเล็กน้อย (ขอบคุณ @moonkotte สำหรับคำแนะนำเกี่ยวกับการบันทึก: มันทำให้ฉันมีความคิดที่จะบันทึกหลักฐานบางอย่างในไดเรกทอรีแอป) แทนที่จะใช้ตัวแปรสภาพแวดล้อม ฉันตัดสินใจทิ้งไฟล์ ขดของเอาต์พุตไปยังไฟล์. จากนั้นฉันก็เริ่มมองหาข้อความเฉพาะที่คาดว่าจะถูกส่งกลับเมื่อมีสิ่งผิดปกติเกิดขึ้นกับปลายทางระยะไกล (คำตอบว่างเปล่า ในกรณีนี้). หากมีข้อความอยู่ เกรป พบว่า แต่ไม่เหมือนกับโหมดปกติ ส่งคืนรหัสทางออก 1 เนื่องจากการมีอยู่ของ -v อาร์กิวเมนต์ (ผกผัน) หากไม่พบข้อความที่ระบุ แสดงว่าทุกอย่างปกติดีเมื่อปลายทางและรหัสออก 0 ถูกส่งกลับ ทำให้พ็อดทำงานต่อไปได้ตามปกติ

คำสั่งทั้งหมดมีลักษณะดังนี้:

livenessProbe:
  ผู้บริหาร:
    สั่งการ:
    - ช
    - -ค
    ->-
        curl -X รับ $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes |
        หัว -c 30 > /app/output.log &&
        grep -v 'การตอบกลับว่างเปล่า' /app/output.log

วิธีที่สองคือการใส่ ขด คำสั่งลงในสคริปต์ทุบตีและจัดส่งพร้อมกับภาพทั้งหมด สคริปต์นั้นดูเหมือนว่า:

#!/bin/bash
msg=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | head -c 30)
ถ้า [[ $msg == *"การตอบกลับว่างเปล่า"* ]]; แล้ว
        ทางออก 1
อื่น
        ทางออก 0
ไฟ

สคริปต์ถูกเรียกใช้โดยคำสั่ง:

livenessProbe:
  ผู้บริหาร:
    สั่งการ:
    - ช
    - ./liveness_check.sh

ผลลัพธ์เหมือนกัน แนวทางที่ 2 สามารถใช้ในกรณีของตรรกะที่ซับซ้อนมากขึ้นหรือเป็นวิธีแก้ปัญหา