5b627f9e73
The 180s post-uncordon health check in `update-node.sh` step 7 was single-shot. Any transient yellow signal (Init:*, Running-but-not-Ready, deployment below replicas during reschedule) at the exact moment of the check would FATAL the whole cycle and require operator wake + manual `--start-from <next-node>`. During DEV-593 this fired three times in one cycle (opencloud init, harbor jobservice reinit) for conditions that cleared within seconds. Wrap the health check in a bounded retry loop: - First check at `POST_UNCORDON_WAIT_SECONDS` (default 180s, unchanged). - Up to `HEALTH_MAX_RETRIES` (default 10) more attempts at `HEALTH_RETRY_INTERVAL_SECONDS` (default 30s) = +5 min max. - Short-circuit halt immediately on persistent pod errors (CrashLoopBackOff, ImagePullBackOff, ErrImagePull, CreateContainerConfigError, InvalidImageName) — these don't recover on their own and shouldn't burn the retry budget. - Each retry calls `cluster-health.sh` with `RETRY_ON_TRANSIENT=0` so the outer loop controls cadence (no double 30s sleeps per attempt). No k3s or manifest changes. Preflight path is untouched. Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|---|---|---|
| .. | ||
| k3s-upgrade | ||
| networking | ||
| scripts | ||
| ADD_WORKER_NODE.md | ||
| CLUSTER_ACCESS.md | ||
| CP1_UPDATE_PROCEDURE.md | ||
| CP_UPDATE_PROCEDURE.md | ||
| K3S_OPERATIONS.md | ||
| OS_UPDATE_PROCEDURE.md | ||
| OS_UPDATE_ROUTINE.md | ||
| README.md | ||
Infrastructure
This directory contains cluster-wide infrastructure configurations that support all applications.
Operational procedures (agent-facing)
- OS_UPDATE_PROCEDURE.md — weekly rolling Ubuntu OS update for all cluster nodes (drain → apt → reboot → verify → uncordon → cluster health → next). Never touches k3s config.
- OS_UPDATE_ROUTINE.md — the Paperclip routine that fires the above weekly.
- K3S_OPERATIONS.md — k3s version upgrades (separate concern from OS updates).
- ADD_WORKER_NODE.md — adding a worker node.
- CLUSTER_ACCESS.md — SSH / kubectl access.
Structure
networking/
Network-level configurations including:
- Network Architecture - Comprehensive network architecture documentation
- DNS Requirements - DNS records and configuration guide
- Ingress controller configurations (Traefik)
- Network policies
- Load balancer configurations (k3s ServiceLB)
- Certificate management (cert-manager, TLS)
- Certificate reloading (Stakater Reloader)
monitoring/
Observability infrastructure:
- Prometheus operator and configurations
- Grafana dashboards and datasources
- Logging stack (Loki, Promtail, etc.)
- Alert rules and notification channels
- Service monitors and pod monitors
Purpose
Infrastructure configurations in this directory are shared across all applications. Changes here can affect the entire cluster, so:
- Test thoroughly before applying
- Document all changes
- Consider the impact on existing deployments
- Coordinate with other team members
Adding Infrastructure Components
When adding new infrastructure components:
- Create appropriate subdirectories if needed
- Include clear documentation
- Define dependencies and prerequisites
- Provide rollback procedures
- Update this README with the new component