Practical tools for system, network, security, and operations administrators.

CLD-C0588 · Managed Kubernetes Guides

EKS Administration Guide

Plan one EKS lab cluster, with a small node pool, and leave the autoscaler and ingress for later.

Updated 25 October 2026 · Pillar guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

One cluster name in EKS

EKS is a managed cluster in an account you administer. The account and region are the AWS lab from the provider guide. The generators can draft a node pool, an autoscaler, and an ingress. This window drafts the cluster identity and, at most, the node pool. The other two files wait.

kubectl's context must be this cluster before any apply. A context you did not write down is the wrong cluster until proven otherwise. The Kubernetes guide owns the namespace habit. This page owns the product's cluster boundary.

The API endpoint's audience is a decision you write: private, or public with a named admin network. Public to the world is not the decision you keep. A kubeconfig in git or in the ticket is a secret you rotate. prompt-for-this is not a kubeconfig.

The application identity is not a cluster administrator, and the pipeline identity is not a cluster administrator. Autoscaling and ingress are capacity and traffic decisions. They are not how you check that the API answers.

A name, a version, a node pool you can explain

Write the cluster name, the region, the version, and the account. Draft a node pool only if the version is written. The size is a lab size. One pool is enough. A second pool for a second architecture waits.

The node role can join the cluster and pull images. It is not an account administrator. Write that split in the note before you draft the pool.

Read the API with a get, when the lab window opens, and paste the context line into the ticket. If the name differs, stop. Do not install an ingress to debug the context.

The autoscaler draft and the ingress draft stay in the ticket as later work, unapplied. An ingress that requests a public address is a network change. The network guide has to agree before that file is applied.

# EKS note. One cluster you administer.
# Context first. Apply second.
# Node pool is optional and small. Autoscaler and ingress wait.
# No cluster-admin for the app or the pipeline.
# prompt-for-this is not a kubeconfig.
# A public ingress is a separate decision.

A change you can finish

The later change is the cluster or the one node pool, not the autoscaler and not the ingress.

Rollback of a lab pool is removing that pool. You do not delete a shared cluster to undo a draft. You do not scale a production pool to zero as a test.

  1. Write the account, region, name, and version.
  2. Confirm you administer that account.
  3. Draft at most one lab node pool.
  4. Keep autoscaler and ingress unapplied.
  5. Write the context name you expect.
  6. Refuse cluster-admin for the app and the pipeline.
  7. Hand the first kubectl get to a window where the context is checked.

Mistakes that outlive the command

EKS fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Decisions to write down before the window

One decision for EKS: The cluster name and region are written. The version is written. The account is yours. At most one node pool is in this draft. The pool size is a lab size. Autoscaler is not applied. Ingress is not applied. The context will be checked before any write. No kubeconfig is in git. The app and the pipeline are not cluster administrators. The API audience is private or a named admin network. And a second person can say which cluster this is.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for EKS. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.

One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.

A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.

Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.

Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next account waits until someone else can repeat the proof from the notes. EKS is done for this window when the proof is written, not when a CLI printed a success line.

This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.

EKS checks before a manifest is applied

Confirm this before you call the change done: The name, region, and version are in the ticket. The account matches the provider note. Only one pool is drafted, or none yet. Autoscaler and ingress are unapplied. No kubeconfig is in the note. cluster-admin is not the app identity. The context check is the next command. The node role is not an account administrator. The hostname in the prompt matches the hostname in the ticket for EKS. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for EKS happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.