8e743f6e69
- ArgoCD via Helm com recursos mínimos (~1Gi) - GitLab Runner com executor Kubernetes - Exemplo node-bugado com Dockerfile e .gitlab-ci.yml - Manifests K8s para repositório GitOps - README.md da aula-03 (liveness + readiness probes)
142 lines
4.2 KiB
Markdown
142 lines
4.2 KiB
Markdown
# Aula 03 - Alta Disponibilidade com Replicas e Readiness Probe
|
|
|
|
Evolução da aula-02 adicionando múltiplas réplicas e readiness probe para zero-downtime.
|
|
|
|
## Conceitos
|
|
|
|
### Liveness vs Readiness Probe
|
|
|
|
| Probe | Função | Quando Falha |
|
|
|-------|--------|--------------|
|
|
| **Liveness** | "O container está vivo?" | Reinicia o container |
|
|
| **Readiness** | "O container está pronto para receber tráfego?" | Remove do Service (sem reiniciar) |
|
|
|
|
### Por que 5 Réplicas?
|
|
|
|
```
|
|
Cenário: MAX_REQUESTS=3, 5 réplicas
|
|
|
|
Tempo 0s: [Pod1: OK] [Pod2: OK] [Pod3: OK] [Pod4: OK] [Pod5: OK]
|
|
↑ Service distribui tráfego entre todos
|
|
|
|
Tempo 5s: [Pod1: HANG] [Pod2: OK] [Pod3: OK] [Pod4: OK] [Pod5: OK]
|
|
↑ readinessProbe falha → removido do Service
|
|
↑ livenessProbe falha → reiniciando...
|
|
|
|
Tempo 7s: [Pod1: RESTART] [Pod2: OK] [Pod3: OK] [Pod4: OK] [Pod5: OK]
|
|
↑ Pod1 reiniciou, readiness OK → volta ao Service
|
|
|
|
Resultado: Usuário NUNCA vê erro 503
|
|
```
|
|
|
|
## Arquitetura
|
|
|
|
```
|
|
LoadBalancer (:3000)
|
|
│
|
|
┌──────────────┼──────────────┐
|
|
│ │ │
|
|
▼ ▼ ▼
|
|
┌─────────┐ ┌─────────┐ ┌─────────┐
|
|
│ Pod 1 │ │ Pod 2 │ │ Pod 3 │ ... (5 réplicas)
|
|
│ :3000 │ │ :3000 │ │ :3000 │
|
|
└────┬────┘ └────┬────┘ └────┬────┘
|
|
│ │ │
|
|
readinessProbe readinessProbe readinessProbe
|
|
livenessProbe livenessProbe livenessProbe
|
|
```
|
|
|
|
## Execução
|
|
|
|
```bash
|
|
cd aula-03
|
|
|
|
# Aplicar recursos
|
|
kubectl apply -f configmap.yaml
|
|
kubectl apply -f deployment.yaml
|
|
kubectl apply -f service.yaml
|
|
|
|
# Verificar pods
|
|
kubectl get pods -w
|
|
|
|
# Acessar a aplicação
|
|
# Docker Desktop: http://localhost:3000
|
|
# Minikube: minikube service node-bugado --url
|
|
```
|
|
|
|
## Configuração das Probes
|
|
|
|
```yaml
|
|
# Readiness - remove do Service rapidamente
|
|
readinessProbe:
|
|
httpGet:
|
|
path: /health
|
|
port: 3000
|
|
periodSeconds: 1 # Verifica a cada 1 segundo
|
|
failureThreshold: 1 # 1 falha = remove do Service
|
|
|
|
# Liveness - reinicia o container
|
|
livenessProbe:
|
|
httpGet:
|
|
path: /health
|
|
port: 3000
|
|
initialDelaySeconds: 2 # Espera app iniciar
|
|
periodSeconds: 1 # Verifica a cada 1 segundo
|
|
failureThreshold: 2 # 2 falhas = reinicia
|
|
```
|
|
|
|
## Teste de Resiliência
|
|
|
|
```bash
|
|
# Terminal 1: Monitorar pods
|
|
kubectl get pods -w
|
|
|
|
# Terminal 2: Fazer requisições contínuas
|
|
while true; do curl -s http://localhost:3000 && echo; sleep 0.5; done
|
|
|
|
# Observar:
|
|
# 1. Pods recebem requisições e eventualmente "travam"
|
|
# 2. readinessProbe remove pod do Service (sem interromper requests)
|
|
# 3. livenessProbe reinicia o pod
|
|
# 4. Pod volta ao Service quando ready
|
|
# 5. Usuário NÃO vê erros durante todo o processo
|
|
```
|
|
|
|
## Diferença da Aula 02
|
|
|
|
| Aspecto | Aula 02 | Aula 03 |
|
|
|---------|---------|---------|
|
|
| Réplicas | 1 | 5 |
|
|
| Probes | Liveness apenas | Liveness + Readiness |
|
|
| Downtime | Sim (durante restart) | Não (outras réplicas atendem) |
|
|
| Service | NodePort | LoadBalancer |
|
|
|
|
## Fluxo de Eventos
|
|
|
|
1. **Pod recebe requisições** → contador incrementa
|
|
2. **MAX_REQUESTS atingido** → app para de responder
|
|
3. **readinessProbe falha (1s)** → pod removido do Service
|
|
4. **Tráfego redirecionado** → outros pods atendem
|
|
5. **livenessProbe falha (2s)** → Kubernetes reinicia container
|
|
6. **Pod reinicia** → contador zerado, app responde
|
|
7. **readinessProbe OK** → pod volta ao Service
|
|
|
|
## Lições
|
|
|
|
1. **Réplicas = Resiliência**: Múltiplas cópias garantem disponibilidade
|
|
2. **Readiness ≠ Liveness**: Propósitos diferentes, ambos importantes
|
|
3. **Graceful Degradation**: Sistema continua funcionando com capacidade reduzida
|
|
4. **Self-Healing**: Kubernetes detecta e corrige problemas automaticamente
|
|
|
|
## Cleanup
|
|
|
|
```bash
|
|
./cleanup.sh
|
|
# ou
|
|
kubectl delete -f .
|
|
```
|
|
|
|
## Próxima Aula
|
|
|
|
**Aula 04**: NGINX Ingress com Keep Request (Lua) para zero-downtime ainda mais robusto, segurando requisições durante a janela de restart.
|