livenessProbe nu funcționează așa cum era de așteptat

În cadrul implementării mele, următoarele livenessProbe este definit:

apiVersion: apps/v1
fel: Desfăşurare
metadate:
  nume: backend-deployment
  etichete:
    nume: backend-deployment
    aplicație: fc-test
specificație:
  replici: 1
  selector:
    matchLabels:
      nume: fc-backend-pod
      aplicație: fc-test
  șablon:
    metadate:
      nume: fc-backend-pod
      etichete:
        nume: fc-backend-pod
        aplicație: fc-test
    specificație:
      containere:
      - nume: fc-backend
        imagine: localhost:5000/backend:1.3
        porturi:
        - containerPort: 4042
        env:
        - nume: NODE_ENV
          valoare: "int"
        livenessProbe:
          executiv:
            comanda:
            - RESULT=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | wc | awk '{print $3}');
            - dacă [[ $REZULTAT -lt 150 ]]; apoi ieșirea 1; altfel ieșire 0; fi
          initialDelaySeconds: 20
          Pragul de eșec: 8
          perioadaSecunde: 10

Deoarece uneori există unele probleme cu conexiunea API, am decis să configurez o acțiune pentru a verifica dacă întregul set de date solicitate este preluat din API. Dacă se întâmplă, întregul set are o dimensiune de aproximativ 400 KB. În caz contrar, este returnat doar un mesaj scurt, iar dimensiunea răspunsului este mai mică de 120 B. Și aici intră a doua comandă de la sondă: verifică dacă REZULTAT variabila de mediu este scăzută: dacă este, înseamnă că răspunsul nu a conținut toate datele dorite și iese cu un cod de eroare.

Ambele comenzi au fost testate prin apelare din interiorul containerului care rulează, astfel încât ambele cazuri sunt acoperite: a) date corecte preluate - ieșirea 0 și b) doar un mesaj de eroare preluat - ieșirea 1.

Aplicația care rulează fără sondă a funcționat corect de cel puțin 3-4 ore, apoi au apărut problemele de conectare și s-au rezolvat de la sine până la urmă, dar a sufocat puțin aplicația, ceea ce era destul de nedorit.

După implementarea sondei, primele probleme de instabilitate au început să apară la câteva minute după implementare. La fiecare două minute, podurile au fost repornite și numărul de reporniri a crescut în mod regulat.

Ce am găsit descriind implementarea:

Șablon de pod:
  Etichete: app=fc-test
           nume=fc-backend-pod
  Containere:
   nsc-backend:
    Imagine: localhost:5000/backend:1.3
    Port: 4042/TCP
    Port gazdă: 0/TCP
    Liveness: exec [RESULT=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | wc | awk '{print $3}'); dacă [[ $REZULTAT -lt 150 ]]; apoi ieșirea 1; altfel ieșire 0; fi] delay=20s timeout=1s period=10s #success=1 #failure=8

Pare rezonabil, dar când intri în containerul de rulare cu exec comanda, am aflat asta echo $REZULTAT nu dă nicio ieșire (doar o linie goală).

Înseamnă că doar primul apel al sondei a fost cumva procesat cu succes și toate cele care au urmat nu? Cum să abordați configurația sondei pentru a o face să funcționeze conform intenției?

Am testat două soluții ale problemei: prima a schimbat puțin abordarea (mulțumesc, @moonkotte pentru indiciu despre logare: mi-a dat idee să salvez niște dovezi în directorul aplicației). În loc să folosesc o variabilă de mediu, am decis să dump răsuciieșirea lui într-un fișier. Apoi am început să caut un mesaj specific care se așteaptă să fie trimis înapoi când se întâmplă ceva greșit cu punctul final la distanță (Răspunsul este gol în acest caz). Dacă mesajul este prezent, grep află asta, dar spre deosebire de modul normal, returnează codul de ieșire 1 din cauza prezenței lui -v argument (inversare). Dacă mesajul specificat nu este găsit, totul pare să fie în regulă cu punctul final și codul de ieșire 0 este returnat, determinând podul să continue să funcționeze normal.

Întreaga comandă arată astfel:

livenessProbe:
  executiv:
    comanda:
    - SH
    - -c
    ->-
        curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes |
        head -c 30 > /app/output.log &&
        grep -v „Răspunsul este gol” /app/output.log

A doua soluție este punerea răsuci comandă într-un script bash și trimite-o împreună cu întreaga imagine. Scriptul în sine arată astfel:

#!/bin/bash
msg=$(curl -X GET $BACKEND_SERVICE_HOST:$BACKEND_SERVICE_PORT/api/v2/makes | head -c 30)
if [[ $msg == *"Răspunsul este gol"* ]]; atunci
        iesirea 1
altfel
        iesirea 0
fi

Scriptul este invocat prin comandă:

livenessProbe:
  executiv:
    comanda:
    - SH
    - ./liveness_check.sh

Rezultatele sunt aceleași. A doua abordare poate fi folosită în cazul unei logici mai complexe sau ca o soluție.