Service explained in plain language
Amazon EKS provides a managed Kubernetes control plane, while workloads also depend on functioning compute and networking. A node marked NotReady cannot be treated as equivalent to a healthy capacity unit. The first business question is whether applications still have enough usable replicas, not merely whether a cluster page opens.
Setup prerequisites and starting sequence
- Define cluster access, supported version, compute model and network requirements for the chosen architecture. Separate platform administration from application deployment privileges.
- Create a documented node or compute baseline with the required identity and connectivity. Review address capacity and workload resource expectations.
- Configure node events, application monitoring and an agreed recovery procedure. Validate a small test workload before admitting critical applications to the cluster.
Start in non-production with the approved account/subscription, region and owner. Follow the linked service instructions for exact console/API options; provisioned resources may incur charges.
Example operational issue
After a node-group change, replacement nodes do not become usable. Existing application replicas continue serving for a while, masking the loss of replacement capacity. Waiting until the last healthy replica fails would turn a capacity incident into a complete application outage.
This is an illustrative operational example. Capture the exact error and time before making changes.
Troubleshooting: evidence before changes
| Observation | First check | Why it matters |
|---|---|---|
| New nodes do not join successfully | Compare node-group events, identity and required connectivity with the supported baseline | Creation of compute does not prove it joined the intended cluster. |
| A previously working node is NotReady | Inspect node conditions, resource pressure and relevant runtime events | Disk, networking or runtime symptoms need different corrective actions. |
| Only selected workloads fail | Compare scheduling, requests and pod events with node health | An application configuration error can exist while the platform is otherwise functioning. |
Begin with status and scoped diagnostics. Sanitize shared evidence and escalate any check beyond your approved access.
Corrective action and change boundary
Use node and cluster evidence to select a supported correction. Respect workload disruption and capacity requirements before replacing or draining compute. Avoid deleting multiple nodes simultaneously as a diagnostic shortcut. Preserve the previous node-group or deployment configuration and obtain approval for changes that reduce serving capacity.
Verification: what proves recovery
Confirm usable node capacity, successful scheduling and application readiness. Run the representative user transaction and check the expected distribution of replicas. Observe replacement behavior through the acceptance period, including any recurring node condition rather than closing on a brief Ready state.
Monitoring, SLI, SLO and SLA
Track usable capacity, unscheduled work and application success separately. A platform SLO might define time to restore required spare capacity, while the product SLO measures user transactions. Clearly document which objective is affected when service remains up but redundancy is reduced.
SLI means the measured result; SLO means an agreed internal target. SLA means a contractual commitment with its own scope and remedy. The training targets here are examples, not vendor commitments; verify current service terms before promising an SLA.
An illustrative platform target is restoring the agreed spare serving capacity within 30 minutes after a supported node failure is acknowledged.
SOP and escalation handover
The platform incident owner coordinates node recovery; application owners approve disruption-sensitive operations. Keep cluster context, node-group change, resource conditions and recovery evidence together. Escalate insufficient healthy capacity early instead of waiting for a customer-visible outage.
SOP means standard operating procedure. Retain owner, evidence, approved change, reversal conditions and acceptance. Escalate with sanitized errors and resource identifiers.
Beginner glossary
Control plane: cluster management services. Node: compute running workloads. Replica: another instance of an application component.
Clouvenix can help scope setup, management and operational support around a documented environment and agreed acceptance criteria.
Technical reference
Official AWS service guidance. Validate resource-specific prerequisites and supported behavior against the deployed version. This walkthrough defines an investigation and operating contract; it does not authorize changes to someone else's environment.