Ζωντάνια/Δείγματα ετοιμότητας

2) Αρχές σχεδιασμού

1. Ξεχωριστή σημασιολογία.

Ετοιμότητα: εξωτερική ικανότητα παροχής υπηρεσιών (λαμβάνει υπόψη τις κρίσιμες εξαρτήσεις).
Ζωντάνια: Η ανιχνευσιμότητα της «ανίατης» κατάστασης της διαδικασίας.
2. Αποτυχία-γρήγορη, αλλά όχι ψεύτικη-γρήγορη. Προσαρμογή του χρονοδιαγράμματος/κατωφλίου «κατώφλι» ώστε οι σύντομες εκρήξεις να μην οδηγήσουν σε περιττές επανεκκινήσεις.
3. Δεν υπάρχουν βαριές λειτουργίες σε δείγματα. Ο έλεγχος θα πρέπει να είναι γρήγορος (≤100 - 200 ms) και χωρίς ανεπιθύμητες ενέργειες.
4. Χαριτωμένη υποβάθμιση. Σε περίπτωση μερικής μη διαθεσιμότητας εξαρτήσεων - Ετοιμότητα = OK, εάν υπάρχει ασφαλής θύλακας (μνήμη/τραχύτητα).
5. Προσδιορισμός I/O. Οι καταστάσεις εξαρτώνται μόνο από την τρέχουσα κατάσταση και όχι από «τυχαίες» εξωτερικές δοκιμές.

3) Σημασιολογία των τελικών σημείων της HEALTH

3. 1 προσέγγιση HTTP (συνιστάται)

"GET/healthz/livenes → 200 εάν η διαδικασία είναι" ζωντανή "(περιστρέφεται ο βρόχος, η GC δεν έχει κολλήσει, ο φύλακας" καρδιά "χτυπάει).
«GET/healthz/ετοιμότητα» → 200 εάν το παράδειγμα είναι έτοιμο για κυκλοφορία κρίσιμης κλάσης. Έλεγχοι: κοινοπραξία σύνδεσης, τοπικές αποθήκες επαφής, διαθεσιμότητα πυρήνα επιχειρηματικής λογικής.
«GET/healthz/startup» → 200 μετά την αρχικοποίηση (μεταναστεύσεις/μοντέλα προθέρμανσης/φόρτωσης).

• Δεν μπορείτε να μεταβείτε σε εξωτερικές βάσεις δεδομένων/API ως προς τη ζωντάνια - αυτό θα οδηγήσει σε «αυτοκτονίες» κατά τη διάρκεια συμβάντων εξάρτησης.
• Σε ετοιμότητα, μπορείτε να ελέγξετε κρίσιμες εξαρτήσεις, αλλά με χρονοδιαγράμματα και υποβάθμιση: αν υπάρχει έγκυρη οπίσθια όψη, μην την κατεβάσετε.

3. Έλεγχος υγείας 2 gRPC

Χρήση του προτύπου 'grpc'. υγεία. v1. Health/Check 'with service-scoped states (' SERVING ',' NOT _ SERVING '). Για Kubernetes - grpc καθετήρες (ή http proxy).

3. 3 Εσωτερικές ενεργοποιήσεις

Watchdog «μαλακό» stop: με SIGTERM set Readiness = FAIL → περιμένετε για 'termendingGraceReturnSeconds' → τέλος, δουλεύοντας ουρές.

4) Χρονοδιαγράμματα και κατώτατα όρια (ρύθμιση)

• 'initial Seconds', 'desmedSecondsSeconds', 'timeoutSeconds', 'successthore', 'successform', ' Secondary'.

• ετοιμότητα: "περίοδος = 5s, timeout = 0. 2–0. 5s, αστοχία = 2 "
• ζωντανότητα: "περίοδος = 10s, timeout = 0. 2–0. 5s, αστοχία = 3 "

• startup: 'περίοδος = 5s, αποτυχία = 60' (έως ~ 5 λεπτά)
• ετοιμότητα/επιβίωση που ενεργοποιείται μετά την επιτυχία εκκίνησης

• η ετοιμότητα αντικατοπτρίζει την ετοιμότητα για επεξεργασία (σύνδεση με μεσίτη, εάν υπάρχει υποβάθμιση DLQ),
• ζωντάνια - εσωτερικός καρδιακός παλμός.

Backoff σε αστοχίες: στην εφαρμογή, χρησιμοποιήστε το εκθετικό backoff για να επανασυνδεθείτε σε εξαρτήσεις, διαφορετικά η ετοιμότητα θα «πριονίσει».

5) Διαμορφώσεις (θραύσματα)

5. 1 Kubernetes, ανιχνευτές HTTP

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 Kubernetes, δείγμα gRPC

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 Χαριτωμένο κλείσιμο

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

Το '/healthz/drain 'στο εσωτερικό της υπηρεσίας μεταφράζει την ετοιμότητα = FAIL (stop-accepting), δίνει χρόνο για την ολοκλήρωση των ενεργών αιτημάτων.

6) Εξαρτήσεις και υποβάθμιση

Κρίσιμη (δεν μπορεί να εξυπηρετηθεί χωρίς αυτές): βάση δεδομένων εξουσιοδότησης για «/σύνδεση », πύλη πληρωμής για «/πληρωμή». Μπορεί να ελεγχθεί σε ετοιμότητα με χρονική καθυστέρηση ≤80% των δειγμάτων 'timeoutSeconds'.
Μη κρίσιμη: ανάλυση, email, στρώμα κρυφής μνήμης εάν υπάρχει φορτίο. Μην τα συμπεριλάβετε σε ετοιμότητα. χρησιµοποιήστε ένα φιαλίδιο.
Σημαίες χαρακτηριστικών: Εάν υποβαθμιστεί μερικώς, απενεργοποιούνται τα εξαρτώμενα χαρακτηριστικά διατηρώντας παράλληλα την ετοιμότητα = OK.

7) Ουρές αναμονής και χειριστές υποβάθρου

• Ετοιμότητα = Εντάξει εάν εγκατασταθεί συνδρομή/σύνδεση με τον μεσίτη και υπάρχει ένας πόρος προς επεξεργασία.
• Όταν DLQ/lag υπερχείλιση → ετοιμότητα μπορεί να παραμείνει εντάξει (αν δεχτούμε και προσθέσουμε), αλλά SLI «φρεσκάδα/καθυστέρηση» φωτίζει - συναγερμός σύμφωνα με τα δεδομένα.
• Ζωντανότητα: έλεγχος του κύκλου της σφυγμομέτρησης/καρδιακός παλμός, θανατηφόρος.

Ταυτότητα: Επιταχύνει την ανάκαμψη από την επανεκκίνηση της ζωντανότητας.

8) Sidecar/πλέγμα/είσοδος

• Ενεργοποίηση της «πύλης ανάγνωσης» (K8s) ώστε να λαμβάνεται υπόψη η κατάσταση του πλευρικού οδοστρώματος,
• Εξασφαλίζεται ότι τα δείγματα δεν εμπίπτουν στα εμπόδια mTLS (ή προσθέτουν εξαιρέσεις).
• Είσοδος/Απεσταλμένος/Nginx: Prox '/healthz/' τοπικά, μην «αναδεικνύετε» εσωτερικά τμήματα.

9) Ασφάλεια και ιδιωτικότητα

Τα τελικά σημεία υγείας δεν πρέπει να αποκαλύπτουν ρυθμίσεις, εκδόσεις βιβλιοθήκης, συμβολοσειρές σφάλματος - μόνο «OK/FAIL» + κωδικός ελάχιστης αιτίας.
Περιορισμός της εξωτερικής πρόσβασης (NetworkPolicy/ACL). Για το κοινό - ας ζήσουμε απλά χωρίς λεπτομέρειες.
Καταγραφές υγειονομικών ελέγχων - σε επίπεδο DEBUG, με στραγγαλισμό.

10) Παρατηρησιμότητα και SLO

Μετρήσεις εξαγωγής: 'health _ readiness {status}', 'health _ liveness {status}', χρόνος επεξεργασίας δειγμάτων.
Συσχετίστε σημαίες ετοιμότητας με SLO διαθεσιμότητας (πτώση από τα τελικά σημεία → 5xx/επαναφορά σύνδεσης).

• «Συχνές επαναλήψεις ανά ζώο> Ν/ώρα» - σύμπτωμα αδιεξόδου/διαρροών.
• «Ετοιμότητα πτερύγων> X/15 min» - σύμπτωμα εθισμού/προβλημάτων δικτύου.
• Συσχέτιση με την ανάπτυξη ("υπηρεσία. έκδοση ").

11) Δοκιμές

Μονάδα/Σύμβαση: Τελικά σημεία/healthz/" επιστρέφουν σωστές καταστάσεις όταν κάθε εξάρτηση είναι απενεργοποιημένη.
Χάος: απενεργοποίηση βάσης δεδομένων/κρύπτη/μεσίτης: Η ετοιμότητα πρέπει να πέσει ή να ενεργοποιήσει την οπίσθια όψη αυστηρά σύμφωνα με το μοντέλο. Ζωντανότητα - δεν ενεργοποιεί εάν η διαδικασία είναι «ζωντανή».
Φορτίο/εμποτισμός: Υπό φορτίο, τα τελικά σημεία υγείας πρέπει να παραμένουν γρήγορα (μην πιέζετε το περιεχόμενο).
Κανάριος: Ελέγξτε τη σταθερότητα ετοιμότητας πριν από την αύξηση της κυκλοφορίας.

12) Συχνά λάθη και τρόπος αποφυγής τους

Βάσεις δεδομένων ελέγχου της ανθεκτικότητας/εξωτερικές API. Το αποτέλεσμα είναι ατελείωτες επαναλήψεις για περιστατικά. Η λύση: περιορισμός της ζωντάνιας στη «διεργασία ζωής».
Αυστηροί έλεγχοι σε δείγματα. Οδηγεί σε ψευδείς αποτυχίες. Λύση: ελαφροί έλεγχοι + ατομικές οθόνες υποβάθρου-υγείας.
Δεν υπάρχει Startup Probe. Οι αργές εκκινήσεις «σκοτώνονται» από τη ζωντάνια. Διάλυμα: προσθήκη εκκίνησης με ένα ευρύ παράθυρο.
Όχι χαριτωμένο κλείσιμο. Σπάνιες 5xx σε depla. Διάλυμα: preStop + ανισορροπία.
Καταιγίδες πτερύγων. Υπερβολικά επιθετικά κατώτατα όρια. Λύση: αύξηση του ' κατωφλίου', αύξηση του 'timeoutSeconds', προσθήκη αντιγράφου ασφαλείας.
Τα ίδια τελικά σημεία για τα πάντα. Ανάμειξη σημασιολογίας. Λύση: ατομική «ζωντάνια/ετοιμότητα/εκκίνηση».

13) Μίνι πρότυπα εφαρμογής

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) Κατάλογοι ελέγχου

Πριν από την πώληση

• Η ζωντάνια/ετοιμότητα/τα τελικά σημεία εκκίνησης χωρίζονται, η σημασιολογία τους περιγράφεται.
• Η βιωσιμότητα δεν αγγίζει εξωτερικές εξαρτήσεις. Δοκιμές ετοιμότητας που είναι κρίσιμες μόνο με χρονοδιαγράμματα και ωοθυλάκια.
• Ρυθμισμένη 'initialDemand/period/timeout/ Κατώφλι' για το προφίλ υπηρεσίας.
• χαριτωμένο κλείσιμο ενεργοποιημένο: 'preStop' + ανισορροπία.
• Συνδέονται μετρήσεις υγείας/κούτσουρα. προειδοποιήσεις για επανεκκίνηση/πτερύγιο.
• Αποτυχία εξάρτησης και δοκιμές αργής εκκίνησης πέρασαν.

Πράξη

• Εβδομαδιαία έκθεση για επανεκκίνηση και σημαίες ετοιμότητας.
• Κατώφλια ρύθμισης μετά από συμβάντα. σύνδεση με τις ελευθερώσεις.
• Τακτικές δοκιμές χάους για την απενεργοποίηση εξαρτήσεων.
• Σημασία της σημασιολογίας όταν αλλάζει η κρισιμότητα της εξάρτησης.

15) ΣΥΧΝΈΣ ΕΡΩΤΉΣΕΙΣ

Ε: Είναι δυνατόν να κλείσουν τα πάντα με μία ανάλυση

A: Ανεπιθύμητες ενέργειες. Ξεχωριστή «εκκίνηση», «ετοιμότητα», «ζωντάνια» - αυτό μειώνει τα ψευδή θετικά και επιταχύνει την RCA.

Ε: Ελέγχω την κρύπτη σε ετοιμότητα

Α: Αν υπάρχει μια σωστή (αν και πιο αργή) λειτουργία χωρίς μια κρύπτη, μην μειώσετε την ετοιμότητα, απλά ενεργοποιήστε την υποβάθμιση.

Ε: Τι να κάνετε με τις συχνές επαναλήψεις για τη ζωντάνια

Α: Πρώτα να αποκλείσει μια δεξαμενή/διαρροή. στη συνέχεια να χαλαρώσει τα κατώτατα όρια και να προσθέσει ένα φύλακα στην εφαρμογή.

Ε: Πώς είμαστε υπεύθυνοι για την πολυκατοικία

A: Η ετοιμότητα θα πρέπει να αντικατοπτρίζει την ικανότητα εξυπηρέτησης οποιασδήποτε κίνησης ενοικίασης. Για ιδιωτικά προβλήματα ενός συγκεκριμένου ενοικιαστή - δεν αλλάζουν την ετοιμότητα, αλλά σηματοδοτούν με ξεχωριστές SLI/προειδοποιήσεις.

• «Παρατηρησιμότητα: κούτσουρα, μετρήσεις, ίχνη»
• «Κατανεμημένα ίχνη»
• «SLO/SLA and Metrics»
• «Εγγυήσεις παράδοσης Webhook»
• «Κρυπτογράφηση διαμετακόμισης»
• «Μυστική διαχείριση»