Liveness, readiness, மற்றும் startup probe கள் என்ன, மற்றும் ஒவ்வொன்றையும் எப்போது பயன்படுத்துவீர்கள்?

Question

IT Interview Practice · Accepted Answer

Probe கள் kubelet ஒரு container-இன் health ஐச் சரிபார்த்து முடிவின்படி செயல்பட அனுமதிக்கின்றன. மூன்று உள்ளன: **liveness** (அது உயிருடன் உள்ளதா, அல்லது restart செய்யப்பட வேண்டுமா?), **readiness** (traffic ஐப் பெறத் தயாராக உள்ளதா?), மற்றும் **startup** (அது boot ஆவதை முடித்துவிட்டதா?). ஒவ்வொன்றும் வேறு கேள்விக்குப் பதிலளிக்கிறது.

## மூன்று probe கள் ஒரு பார்வையில்

```text
LIVENESS   → "Is the app stuck/deadlocked?"   FAIL → kubelet RESTARTS the container
READINESS  → "Can it serve traffic right now?" FAIL → Pod removed from Service endpoints
                                                       (NOT restarted)
STARTUP    → "Has the slow boot finished?"     runs FIRST; while it runs, liveness &
                                                readiness are held off
```

## Readiness vs liveness — முக்கிய வேறுபாடு

```text
Readiness controls TRAFFIC:
  → a Pod that fails readiness is pulled OUT of the Service load-balancer,
    but keeps running (e.g. it's warming a cache or a dependency is down)
Liveness controls LIFE:
  → a Pod that fails liveness is KILLED and restarted (it's broken beyond recovery)
Using liveness where you meant readiness causes needless restart loops.
```

## Probe வரையறைகள்

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # gives a slow starter time before others kick in
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = up to 5 min to start
        periodSeconds: 10

readinessProbe:          # gate traffic
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # restart if unhealthy
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe கருவிகள் (mechanisms)

```text
httpGet    → GET a path; 2xx/3xx = pass         (most common for web apps)
tcpSocket  → can we open a TCP connection?       (for non-HTTP services)
exec       → run a command; exit 0 = pass        (custom checks)
grpc       → native gRPC health check
Key knobs: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Startup probe கள் ஏன் இருக்கின்றன

```text
Slow-starting apps (JVM warmup, big migrations) used to force you to set a huge
initialDelaySeconds on liveness — which then made real crashes slow to detect.
The startupProbe fixes this: it protects the slow boot, and ONLY after it passes
do liveness/readiness begin with their normal (tight) timings.
```

```bash
kubectl describe pod app     # see probe failures & restart reasons in events
kubectl get pod app          # READY column reflects readiness; RESTARTS reflects liveness
```

## இது ஏன் முக்கியம்

Health probe கள் தான் Kubernetes self-healing மற்றும் பாதுகாப்பான traffic routing ஐ வழங்கும் விதம், எனவே மூன்று வகைகளையும் ஒவ்வொன்றையும் எப்போது பயன்படுத்துவது என்பதைப் புரிந்துகொள்வது அத்தியாவசியமான reliability அறிவு. முக்கியமான வேறுபாடு — பல engineer களைத் தடுமாற வைப்பது — **readiness** மற்றும் **liveness** இடையே: readiness **traffic** ஐக் கட்டுப்படுத்துகிறது (தோல்வியடையும் ஒரு Pod Service load-balancer-லிருந்து வெளியே இழுக்கப்படுகிறது ஆனால் இயங்கிக்கொண்டே இருக்கிறது, அது warm up ஆகும்போது அல்லது ஒரு dependency தற்காலிகமாக down ஆகும்போது ideal), அதேசமயம் liveness **life** ஐக் கட்டுப்படுத்துகிறது (தோல்வியடையும் ஒரு Pod கொல்லப்பட்டு restart செய்யப்படுகிறது, அது மீட்க முடியாத அளவுக்கு deadlock ஆகும்போது). இரண்டையும் குழப்புவது — readiness என்று பொருள்பட்ட இடத்தில் liveness probe ஐப் பயன்படுத்துவது — தேவையற்ற restart loop களையும் outage களையும் ஏற்படுத்துகிறது, எனவே ஒவ்வொரு probe எந்த கேள்விக்குப் பதிலளிக்கிறது என்பதை அறிவது நேரடியாக நடைமுறைப் பயனுள்ளது. **Startup** probe ஒரு நிஜமான வரலாற்று வலியைத் தீர்க்கிறது: மெதுவாக boot ஆகும் app கள் ஒரு காலத்தில் liveness-இல் மிகப்பெரிய `initialDelaySeconds` ஐ கட்டாயப்படுத்தின (இது நிஜமான crash களைக் கண்டறிவதைத் தாமதப்படுத்தியது), அதேசமயம் ஒரு startup probe boot window ஐப் பாதுகாத்து, startup வெற்றியடைந்தவுடன் மட்டுமே liveness/readiness ஐ இறுக்கமான, சாதாரண timing களுடன் இயங்க அனுமதிக்கிறது. Probe கருவிகளை (`httpGet`, `tcpSocket`, `exec`, `grpc`) மற்றும் tuning knob களை (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, முதலியன) புரிந்துகொள்வது health checking ஐ ஊகத்தால் அல்லாமல் சரியாக configure செய்ய உங்களை அனுமதிக்கிறது. Probe கள் பயனர்கள் ஆரோக்கியமான Pod களை அடைகிறார்களா, உடைந்த Pod கள் தானாக மீள்கின்றனவா என்பதை நேரடியாகத் தீர்மானிப்பதால், அவற்றைச் சரியாகப் பெறுவது Kubernetes-இல் நம்பகமான, production-grade workload களை இயக்குவதற்கு அடிப்படையானது.

மூன்று probe கள் ஒரு பார்வையில்

Readiness vs liveness — முக்கிய வேறுபாடு

Probe வரையறைகள்

Probe கருவிகள் (mechanisms)

Startup probe கள் ஏன் இருக்கின்றன

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்