Menu
Use when working with load balancer configuration, upstream health checks, or traffic distribution
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use before any DevOps build, change, or new feature — refine requirements through dialogue before touching infrastructure or code
Use when working with Docker — building images, writing Dockerfiles, debugging container issues
Use to execute a written implementation plan via subagents with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when working with Kubernetes or Helm — authoring, reviewing, hardening, or debugging manifests, Deployments, Services, Ingress, RBAC, NetworkPolicy, or cluster operations
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
| name | load-balancing |
| description | Use when working with load balancer configuration, upstream health checks, or traffic distribution |
tooling/network/. Scaffold or modify load balancer configs.| Algorithm | When to use |
|---|---|
| Round robin | Stateless services, equal capacity upstreams |
| Least connections | Long-lived connections, variable request duration |
| IP hash | Session affinity needed (sticky sessions) |
| Weighted | Upstreams with different capacities |
upstream myapp {
least_conn;
server 10.0.0.1:3000 weight=3;
server 10.0.0.2:3000 weight=1;
server 10.0.0.3:3000 backup; # only used if others fail
keepalive 32; # reuse upstream connections
}
server {
location / {
proxy_pass http://myapp;
proxy_next_upstream error timeout http_502 http_503;
proxy_connect_timeout 5s;
proxy_read_timeout 60s;
}
}
Passive (Nginx default): marks upstream as failed after N consecutive errors.
upstream myapp {
server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
}
Active (Nginx Plus / OpenResty): proactively polls upstream health endpoint.
Kubernetes readinessProbe:
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3
# Check Nginx upstream status (if status module enabled)
curl http://localhost/nginx_status
# Watch access logs to verify distribution
tail -f /var/log/nginx/access.log | awk '{print $7}'
# Test upstream directly
curl -v http://10.0.0.1:3000/health
curl -v http://10.0.0.2:3000/health
| Symptom | Cause | Fix |
|---|---|---|
| All traffic to one upstream | Sticky sessions / IP hash | Check algorithm config |
| Upstream marked down incorrectly | Health check too aggressive | Increase fail_timeout, check health endpoint |
| 502 during deploy | Old connections to stopped pod | Use proxy_next_upstream to retry |
| Uneven distribution | Weight mismatch or keepalive skewing | Review weights and keepalive settings |