~/ nmadiraju.com
school Amazon EKS · Learning path

EKS Concepts

Every concept starts with the problem it exists to solve. For each one: how to explain it in one breath, what it's most often confused with, and where to go deeper.

New to Kubernetes? Show only Essentials, read top to bottom, and follow the “read after” hints.

Essentials
The minimum to be useful on a cluster.
Solid
What a working EKS engineer is expected to know.
Deep
Specialist topics, for when the basics are solid.
Show
Concept In one breath Often confused with Learn & practice
Foundations 6 concepts
Control plane vs data plane
Essentials EKS

Splits who runs the cluster's brain from who runs your workloads.

The control plane (API server, etcd, scheduler, controllers) stores what you asked for and works to make it real; on EKS, AWS runs it across multiple Availability Zones. The data plane is the nodes where your pods run, and those are yours to size and pay for.
vs Master nodes

On EKS there are no master nodes in your account. The control plane is AWS-managed and never shows up in your EC2 list or kubectl get nodes.

Pods
Essentials Kubernetes

The smallest thing Kubernetes runs: one or more containers that share an IP and storage.

A pod wraps one or more containers that share one IP address and their volumes, and are always scheduled together onto one node. Pods are disposable: when one dies it is replaced, not repaired, usually with a new IP.
vs Containers

A container is one running image. A pod is the unit Kubernetes schedules, and it can hold several containers that share one IP.

Deployments and ReplicaSets
Essentials Kubernetes

Keeps the right number of identical pods running, and rolls out new versions safely.

read after: Pods

A Deployment declares how many copies of a pod template you want and manages ReplicaSets that create and replace pods to match. Changing the template starts a rolling update, and you can roll back to the previous ReplicaSet.
vs StatefulSets

A Deployment's pods are interchangeable. A StatefulSet's pods each keep a stable name and their own volume.

Namespaces, labels and selectors
Essentials Kubernetes

Groups and finds objects: namespaces divide a cluster, labels tag objects, selectors pick them.

read after: Pods

A namespace is a scope for names, quotas and access rules inside one cluster. Labels are key-value tags and selectors are queries on them; that's how a Service finds its pods.
vs Security boundaries

A namespace scopes names and RBAC, but on its own it doesn't block network traffic between namespaces. That takes Network Policies.

Services and kube-proxy
Essentials Kubernetes

Gives a changing set of pods one stable name and IP.

read after: Namespaces, labels and selectors

A Service selects pods by label and gets a stable virtual IP (the ClusterIP) and a DNS name. kube-proxy programs rules on every node that rewrite traffic for that IP to a ready pod.
vs Ingress

A Service gives pods one stable address at layer 4. An Ingress adds HTTP routing by host and path in front of many Services.

CoreDNS
Solid Kubernetes

Turns Service names into IPs inside the cluster.

read after: Services and kube-proxy

CoreDNS runs as pods in kube-system and answers queries like shop.default.svc.cluster.local with the Service's ClusterIP. Names outside the cluster are forwarded upstream; on EKS, to the VPC's DNS resolver.
vs kube-proxy

CoreDNS turns a name into the Service's IP. kube-proxy turns that Service IP into a pod's IP.

Workloads 5 concepts
Liveness, readiness and startup probes
Essentials Kubernetes

Tells Kubernetes when a container is alive, and when it's ready for traffic.

read after: Pods

A failing liveness probe makes the kubelet restart the container; a failing readiness probe removes the pod from its Services' endpoints without restarting it. A startup probe holds off the other two until a slow app has started.
vs Liveness vs readiness

Liveness failure restarts the container; readiness failure only stops traffic to it. Checking a slow dependency in a liveness probe causes restart loops.

Requests, limits and QoS
Essentials Kubernetes

Reserves resources for scheduling, and caps what a container may use.

read after: Pods

The scheduler places pods by their requests; limits are enforced while running: over the CPU limit the container is throttled, over the memory limit it is OOM-killed. Together they set the pod's QoS class, a good hint at which pods go first when a node runs short of memory.
vs Requests vs limits

A request is a reservation used for placement; a limit is a hard cap. A container can use more than its request, up to its limit.

StatefulSets
Solid Kubernetes

Runs pods that need a stable identity and their own storage, like databases.

read after: Deployments and ReplicaSets

A StatefulSet gives each pod a stable ordinal name (db-0, db-1) and, through volume claim templates, its own persistent volume that stays with that name when the pod is rescheduled. By default, pods are created and scaled in order.
vs Deployments

A Deployment's pods are interchangeable, and any volume claim they use is the same one for all. A StatefulSet's pods each get their own name and their own volume.

DaemonSets
Solid Kubernetes

Runs one copy of a pod on every node, or every matching node.

read after: Deployments and ReplicaSets

A DaemonSet keeps one copy of a pod on each eligible node, adding it when a node joins and removing it when the node leaves. It's how node agents run: log shippers, and on EKS the VPC CNI (aws-node) and kube-proxy.
vs Deployments

A Deployment runs a set number of replicas wherever they fit. A DaemonSet ties the count to nodes: one per node.

Jobs and CronJobs
Solid Kubernetes

Runs work to completion, once or on a schedule, instead of forever.

read after: Pods

A Job runs pods until a set number finish successfully, retrying failures up to a backoff limit. A CronJob creates a Job on a cron schedule.
vs Deployments

A Deployment restarts pods that exit, to keep them running. A Job is done once its pods succeed.

Networking 10 concepts
VPC CNI
Essentials EKS

Gives every pod a real VPC IP address.

read after: Pods

The Amazon VPC CNI attaches network interfaces to each node and gives pods secondary IPs from the node's subnet, so pod IPs are ordinary VPC addresses. The trade-off: pods per node and free subnet IPs become limits you have to plan for.
vs Overlay networks

Overlay plugins give pods addresses from a separate range and wrap their traffic in tunnels. The VPC CNI uses real VPC addresses, with no encapsulation.

NodePort and LoadBalancer Services
Essentials Kubernetes

Lets traffic from outside the cluster reach a Service.

read after: Services and kube-proxy

A NodePort Service opens the same port (30000–32767 by default) on every node and forwards it to the Service's pods. type: LoadBalancer builds on that by asking AWS for a load balancer: with the AWS Load Balancer Controller or Auto Mode it's an NLB (internal unless you ask for internet-facing), and without either, a Classic Load Balancer.
vs Ingress

A LoadBalancer Service gets its own load balancer, one per Service, at layer 4. An Ingress shares one HTTP load balancer across many Services.

Ingress and the AWS Load Balancer Controller
Essentials EKS

One load balancer for many apps, routed by path.

read after: NodePort and LoadBalancer Services

An Ingress is a set of HTTP routing rules (host and path to a Service) stored in the API, and it does nothing until a controller reads it. On EKS, the AWS Load Balancer Controller turns it into one ALB.
vs Gateway API

Gateway API is the newer, more expressive successor. It splits the entry point (Gateway) from the routes (HTTPRoute), so platform and app teams own different parts.

Network Policies
Solid Kubernetes

Controls which pods may talk to which.

read after: Namespaces, labels and selectors

By default every pod can reach every other pod. A NetworkPolicy selects pods and lists the traffic allowed in or out, and once a pod is selected, everything else in that direction is denied; on EKS, the VPC CNI enforces it once you turn on its network policy support.
vs Security groups for pods

Network Policies filter pod-to-pod traffic by labels inside the cluster. Security groups for pods apply AWS security groups to a pod, mostly to control access to AWS resources like RDS.

Gateway API
Deep Kubernetes

A richer, role-based replacement for Ingress.

read after: Ingress and the AWS Load Balancer Controller

Gateway API splits ingress into a GatewayClass, a Gateway and route objects like HTTPRoute, so the platform team owns the entry point and app teams own their routes. Header matching, traffic splitting and cross-namespace routing are part of the spec, not vendor annotations.
vs Ingress

Ingress is one object, with most features in vendor-specific annotations. Gateway API is several typed objects with those features built in.

Amazon VPC Lattice
Deep EKS

Connects services across clusters, VPCs and accounts without managing networking between them.

read after: Gateway API

VPC Lattice is an AWS-managed application network: services join a service network and are reached by name, with IAM auth policies deciding who may call them. On EKS, the AWS Gateway API Controller links each Gateway to the service network of the same name and turns each HTTPRoute into a Lattice service, so routes can span clusters.
vs Service mesh

A mesh runs a proxy beside every Pod to route traffic. VPC Lattice is a managed AWS service outside the cluster that routes across VPCs and accounts. You need at most a signing sidecar when you use IAM auth.

Security groups for pods
Deep EKS

Applies AWS security groups to individual pods, not the whole node.

read after: VPC CNI

With the VPC CNI's pod ENI mode, selected pods get their own branch network interface with their own security groups, chosen by a SecurityGroupPolicy. That lets, for example, only the payments pods reach the payments database.
vs Network Policies

Security groups for pods are AWS-level rules on a pod's network interface. Network Policies are Kubernetes rules between pods, based on labels.

Private clusters and endpoint access
Solid EKS

Keeps the cluster's API and nodes off the public internet.

read after: VPC CNI

The cluster endpoint can be public, private or both; with private-only access, kubectl and nodes reach the API from inside the VPC or a connected network. Nodes in subnets with no internet route need VPC endpoints, for ECR, S3, EC2 and other AWS APIs, to pull images and call AWS.
vs Private subnets

Putting nodes in private subnets doesn't make the API private. Endpoint access is a separate cluster setting.

Prefix delegation and custom networking
Deep EKS

Fixes running out of pod IPs, per node or in the subnet.

read after: VPC CNI

By default a node can run only as many pods as it has secondary IPs on its network interfaces. Prefix delegation hands out /28 blocks instead of single IPs to raise that, and custom networking puts pods in separate subnets, often from a secondary CIDR, so they stop draining the node subnets.
vs The max-pods setting

max-pods only caps how many pods the kubelet accepts. Raising it without more IPs just creates pods that can't get an address.

Service mesh
Deep Kubernetes

Adds encryption, retries and traffic control between services, without changing app code.

read after: Services and kube-proxy

A mesh such as Istio adds proxies to the traffic path between services (a sidecar beside each pod, or shared proxies in ambient mode) plus a control plane that configures them. That adds mutual TLS, service identity, retries and fine-grained traffic shifting between services.
vs Ingress

Ingress handles traffic coming into the cluster. A mesh handles traffic between services inside it.

Compute and scheduling 13 concepts
Managed node groups
Essentials EKS

EC2 worker nodes whose launch, update and drain AWS automates for you.

read after: Control plane vs data plane

A managed node group is an EKS-managed Auto Scaling group of EC2 instances running an EKS-optimized image. AWS creates the nodes and, when you start an update, cordons and drains them for you.
vs Karpenter

A node group holds instance types you chose and needs Cluster Autoscaler to resize it. Karpenter picks instance types per pending pod and launches them itself.

EKS Hybrid Nodes
Deep EKS

Runs on-premises or edge machines as nodes of an EKS cluster.

read after: Managed node groups

EKS Hybrid Nodes lets servers in your own data centre join an EKS cluster whose control plane AWS runs in a Region. They connect over a private link such as Direct Connect or VPN, sign in with AWS IAM through SSM or IAM Roles Anywhere, and need their own CNI, such as Cilium (the one AWS supports), because the VPC CNI doesn't run there.
vs EKS Anywhere

EKS Anywhere runs the whole cluster, control plane included, on your own infrastructure. Hybrid Nodes keep the control plane in AWS and add your machines as nodes.

Taints, tolerations and affinity
Solid Kubernetes

Controls which pods may land on which nodes.

read after: Managed node groups

A taint on a node repels pods unless they carry a matching toleration. Node affinity attracts pods to nodes with certain labels, and pod anti-affinity spreads pods away from each other.
vs Taints vs affinity

A toleration only allows a pod onto a tainted node; it doesn't send it there. Affinity is what attracts it, so dedicated nodes usually need both.

GPU nodes and model serving
Deep Kubernetes

Runs ML inference and training on GPU nodes.

read after: Taints, tolerations and affinity

GPU nodes advertise their GPUs to Kubernetes through a device plugin, and pods ask for them in resource limits, for example nvidia.com/gpu: 1. A serving engine such as vLLM loads a model onto the GPU and exposes an inference API, which you scale on serving signals such as queue depth rather than CPU.
vs CPU requests

By default a pod asks for whole GPUs, and they aren't shared like CPU, so packing, cost and slow starts from large images and models need planning.

Horizontal Pod Autoscaler
Solid Kubernetes

Adds or removes pod replicas as load changes.

read after: Requests, limits and QoS

The Horizontal Pod Autoscaler compares a metric, such as CPU usage as a share of requests, against a target and changes a Deployment's replica count to match. It needs metrics-server (or another metrics source), and CPU-percentage targets need requests set.
vs Karpenter and Cluster Autoscaler

HPA adds pods. Karpenter or Cluster Autoscaler add nodes when those pods don't fit.

KEDA
Solid Kubernetes

Scales pods on events, like queue length, including down to zero.

read after: Horizontal Pod Autoscaler

KEDA watches event sources such as an SQS queue or Kafka consumer lag and drives a Horizontal Pod Autoscaler from them. It can also scale a workload to zero when there's no work and back up when work arrives.
vs Horizontal Pod Autoscaler

HPA on its own usually scales on metrics like CPU, and a CPU-based HPA never goes below one replica. KEDA feeds an HPA event metrics and scales to and from zero itself.

Cluster Autoscaler
Solid Kubernetes

Adds nodes when pods can't be scheduled, by resizing node groups.

read after: Managed node groups

Cluster Autoscaler watches for pods that can't be scheduled and raises the desired size of a node group that could fit them, and removes underused nodes. It works through node groups, so it can only add instance types you defined up front.
vs Karpenter

Cluster Autoscaler resizes Auto Scaling groups you defined. Karpenter chooses instance types per workload and launches them directly.

Karpenter
Solid EKS

Launches the right nodes when pods can't be scheduled, and removes idle ones.

read after: Cluster Autoscaler

Karpenter watches pending pods, picks instance types that fit them within a NodePool's constraints, and launches EC2 instances directly, without node groups. It also consolidates: replacing or removing nodes when the pods would fit on fewer or cheaper ones.
vs Cluster Autoscaler

Cluster Autoscaler resizes node groups you defined. Karpenter picks the instance type per pending pod and launches it itself.

Karpenter NodePools and disruption
Deep EKS

Controls which nodes Karpenter may launch, and when it may replace or remove them.

read after: Karpenter

A NodePool sets the rules for the nodes Karpenter launches, such as instance families, capacity types, zones, taints and limits, and several NodePools can be weighted. Its consolidation policy and disruption budgets decide when Karpenter may replace drifted or underused nodes; expireAfter replaces nodes past a set age, whatever the budgets say.
vs PodDisruptionBudgets

A PodDisruptionBudget limits how many of an app's pods may be evicted at once. A NodePool disruption budget limits how many of that NodePool's nodes Karpenter may disrupt at once.

Spot and Graviton
Solid EKS

Cuts compute cost with spare-capacity and Arm-based instances.

read after: Karpenter

Spot instances are spare EC2 capacity at a steep discount that AWS can take back with a two-minute warning, so they suit workloads that tolerate interruption. Graviton instances are Arm (arm64), so your images must be built for Arm, usually as multi-architecture images.
vs Savings Plans

Savings Plans lower On-Demand rates in exchange for a 1- or 3-year $/hour commitment, and they don't apply to Spot. Spot needs no commitment and is cheaper, but it can be reclaimed.

Fargate and EKS Auto Mode
Solid EKS

Run pods without managing nodes yourself.

read after: Managed node groups

Fargate runs each pod on its own AWS-managed node, so there are no nodes for you to manage, with limits such as no DaemonSets. EKS Auto Mode keeps real EC2 nodes but has AWS manage them, including scaling, patching and core add-ons.
vs Each other

Fargate gives each pod its own node that AWS fully manages. Auto Mode runs normal EC2 nodes for many pods, so DaemonSets still work, but you can't log in to or customize the nodes.

PodDisruptionBudgets
Solid Kubernetes

Stops planned maintenance from taking down too many replicas at once.

read after: Deployments and ReplicaSets

A PodDisruptionBudget sets minAvailable or maxUnavailable for the pods it selects. Node drains, upgrades and Karpenter consolidation go through the eviction API, which respects it; a node crashing does not.
vs Replicas

Replicas say how many pods should run. A PodDisruptionBudget says how many may be taken down on purpose at the same time.

Evictions and node pressure
Deep Kubernetes

What the kubelet does when a node runs short of memory or disk.

read after: Requests, limits and QoS

When a node crosses an eviction threshold for memory, disk or inodes, the kubelet evicts pods to reclaim it, starting with pods using more than they requested, lowest priority first. These evictions don't respect PodDisruptionBudgets.
vs OOM kills

An OOM kill is the kernel killing one container that went over its memory limit. An eviction is the kubelet removing whole pods to protect the node.

Identity and security 6 concepts
RBAC
Essentials Kubernetes

Controls what each user and service account may do in the Kubernetes API.

read after: Namespaces, labels and selectors

A Role (in one namespace) or ClusterRole (cluster-wide) lists allowed actions on resources, and a RoleBinding or ClusterRoleBinding grants it to users, groups or service accounts. Anything not granted is denied.
vs IAM

On EKS, IAM proves who you are to the cluster. RBAC decides what you're allowed to do inside it.

Access entries
Solid EKS

Decides which IAM users and roles can use the cluster.

read after: RBAC

An access entry links an IAM principal to Kubernetes permissions, either through an EKS access policy or through Kubernetes groups that RBAC binds. It's managed through the EKS API and replaces editing the aws-auth ConfigMap.
vs Pod Identity

Access entries control who can call the cluster's API. Pod Identity controls what a pod can do in AWS.

Pod Identity vs IRSA
Solid EKS

Lets a pod call AWS APIs with its own IAM role, not the node's.

read after: Access entries

Both give a pod's service account temporary credentials for a chosen IAM role. IRSA works through the cluster's OIDC provider and a role trust policy that names each cluster; EKS Pod Identity uses an on-node agent and an association, so one role works across clusters without trust-policy edits.
vs The node's IAM role

Without either, pods can fall back to the node's instance role, so every pod on that node shares the same AWS permissions.

Pod Security Admission
Deep Kubernetes

Blocks risky pod settings, like privileged containers, per namespace.

read after: RBAC

Pod Security Admission is built into the API server and enforces the Pod Security Standards (privileged, baseline, restricted) chosen by namespace labels. Each namespace can enforce, audit or just warn.
vs Policy as code

Pod Security Admission enforces three fixed profiles. Kyverno or Gatekeeper let you write any rule, like "images only from our registry".

Runtime and image security (GuardDuty, Inspector)
Solid EKS

Finds vulnerable images and suspicious behaviour in running clusters.

read after: Pod Security Admission

Amazon Inspector scans container images in ECR for known vulnerabilities, and image signing proves an image came from your pipeline. Amazon GuardDuty reads EKS audit logs and, with runtime monitoring, watches node and container activity to flag threats such as crypto mining or stolen credentials.
vs Policy as code

Admission policies block bad objects before they're stored. Inspector and GuardDuty find problems in images and in workloads that are already running.

Policy as code (Kyverno, Gatekeeper)
Deep Kubernetes

Enforces your own rules on every object the cluster accepts.

read after: Pod Security Admission

Kyverno and OPA Gatekeeper run as admission webhooks that check objects against rules you write, such as required labels or allowed image registries, and can also change them. Most teams start in audit mode and switch to enforce once violations are fixed.
vs Pod Security Admission

Pod Security Admission is built in and fixed to three profiles. Policy engines are add-ons that enforce whatever rules you write.

Config and storage 4 concepts
ConfigMaps and Secrets
Essentials Kubernetes

Keeps configuration and credentials out of container images.

read after: Pods

ConfigMaps and Secrets hold key-value data that pods read as environment variables or mounted files. A Secret's values are only base64-encoded, so who can read them is controlled by RBAC and encryption at rest, not by the encoding.
vs Encryption

base64 is encoding anyone can reverse, not encryption. Protection comes from RBAC and encrypting Secrets at rest.

Secrets from AWS (External Secrets, Secrets Store CSI)
Deep EKS

Keeps secrets in AWS Secrets Manager, not in Git or hand-made Kubernetes Secrets.

read after: ConfigMaps and Secrets

External Secrets Operator syncs values from Secrets Manager or Parameter Store into Kubernetes Secrets; the Secrets Store CSI driver mounts them into pods as files. Either way, nobody commits secrets to Git, and rotation happens in one place.
vs Kubernetes Secrets

A Kubernetes Secret lives in the cluster. These tools keep AWS as the source of truth: External Secrets copies values into Secrets, and the CSI driver mounts them as files.

Persistent volumes and the EBS CSI driver
Solid EKS

Gives a pod storage that outlives the pod.

read after: Pods

A PersistentVolumeClaim asks for storage from a StorageClass, and the EBS CSI driver creates an EBS volume and attaches it to the pod's node. An EBS volume lives in one Availability Zone, so a pod using it can only run on nodes in that zone.
vs EFS

EBS is block storage attached to one node at a time, in one zone. EFS is a shared file system many pods can mount across zones.

EFS and shared storage
Solid EKS

Gives many pods the same files, across Availability Zones.

read after: Persistent volumes and the EBS CSI driver

The EFS CSI driver mounts an Amazon EFS file system into pods, usually with an access point per claim, so pods on different nodes and zones can read and write the same files (ReadWriteMany). EFS Standard costs more per GB than EBS gp3, and EFS suits shared files more than databases.
vs EBS

A gp3 EBS volume attaches to one node at a time, in one zone. EFS is a network file system that pods on many nodes, in every zone with a mount target, can mount at once.

Delivery and operations 10 concepts
Helm
Solid Kubernetes

Packages many Kubernetes manifests into one versioned, configurable install.

read after: Deployments and ReplicaSets

A Helm chart is a set of templated manifests plus default values. helm install renders them with your values and records the result as a release you can upgrade or roll back.
vs Kustomize

Helm fills templates with variables. Kustomize patches plain YAML with overlays, with no templating.

Kustomize
Solid Kubernetes

Adjusts plain YAML for each environment without templates.

read after: Helm

Kustomize starts from a base of ordinary manifests and applies overlays, patches and generators per environment, such as a different replica count or image tag for prod. It's built into kubectl as kubectl apply -k, and Argo CD and Flux can apply it directly.
vs Helm

Helm fills templates with values and tracks releases. Kustomize patches real YAML and keeps no release history.

Argo CD and GitOps
Solid Kubernetes

Makes Git the source of truth, and keeps the cluster matching it.

read after: Helm

Argo CD runs in the cluster, compares what's in Git with what's running, and syncs the difference, automatically or when someone triggers a sync. Changes go through pull requests, and manual edits show up as OutOfSync drift.
vs Push-based CI/CD

A CI pipeline pushes changes into the cluster and needs cluster credentials. GitOps pulls from Git from inside the cluster, so CI never needs cluster access.

Progressive delivery
Deep Kubernetes

Releases a new version to a small share of traffic first, and rolls back on bad metrics.

read after: Argo CD and GitOps

A tool such as Argo Rollouts or Flagger shifts traffic to a new version in steps, for example 10%, then 50%, then 100%, and checks metrics like error rate as it goes. If a check fails, it shifts traffic back automatically.
vs Rolling updates

A Deployment's rolling update replaces pods as they become ready, not by share of traffic or by business metrics, and it doesn't roll back on its own.

ACK, kro and EKS Capabilities
Deep EKS

Manages AWS resources from Kubernetes, next to the apps that use them.

read after: Argo CD and GitOps

AWS Controllers for Kubernetes (ACK) let you declare AWS resources such as S3 buckets or RDS databases as Kubernetes objects, and kro bundles several resources into one reusable API. EKS Capabilities run Argo CD, ACK and kro for you as AWS-managed features.
vs Terraform

Terraform changes things when you run it. ACK controllers keep reconciling like any Kubernetes controller, so AWS resources fit the same GitOps flow as your apps.

EKS add-ons
Solid EKS

AWS-managed installs and upgrades for core cluster software.

read after: Control plane vs data plane

An EKS add-on is software AWS packages, versions and tests against your cluster version, such as the VPC CNI, CoreDNS, kube-proxy and the EBS CSI driver. You choose the version and can override its settings.
vs Helm charts

A chart you install yourself is yours to version and upgrade. An EKS add-on's versions are tested by AWS against your cluster version.

Observability (Container Insights, Prometheus)
Solid Kubernetes

Shows what the cluster and its apps are doing: metrics, logs and traces.

read after: DaemonSets

Metrics usually come from Prometheus (or Amazon Managed Service for Prometheus) scraping pods and nodes, and logs are shipped from each node by a DaemonSet such as Fluent Bit; CloudWatch Container Insights bundles both for EKS. Control-plane logs are separate and have to be turned on in EKS.
vs metrics-server

metrics-server only keeps current CPU and memory, for autoscaling and kubectl top. It isn't a monitoring system and keeps no history.

Cost visibility and allocation
Solid EKS

Shows what each team, namespace and workload costs in a shared cluster.

read after: Observability (Container Insights, Prometheus)

A shared cluster bills as EC2, storage and data transfer, not per app. Split cost allocation data for EKS in AWS Cost and Usage Reports, or a tool such as Kubecost, divides the node (EC2) costs by pod requests and usage, so you can see cost per namespace or label and find idle capacity.
vs Cost Explorer alone

Cost Explorer shows what you spent on EC2 instances. Allocation splits that spend across the pods and teams that used it.

Failure testing (AWS FIS)
Deep EKS

Proves the cluster and apps survive failures before a real one happens.

read after: PodDisruptionBudgets

AWS Fault Injection Service runs controlled experiments such as terminating nodes, deleting pods or disrupting an Availability Zone, with stop conditions tied to CloudWatch alarms. You watch whether replicas, PodDisruptionBudgets, topology spread and autoscaling keep the app up.
vs Load testing

Load testing checks behaviour under more traffic. Failure testing checks behaviour when parts of the system break.

scheduleWalkthrough coming
Cluster upgrades
Deep EKS

Moves a cluster to a newer Kubernetes version.

read after: EKS add-ons

On EKS you upgrade the control plane one minor version at a time, then bring add-ons and nodes up to match, after checking for removed APIs. Each version has a standard support window; after that comes paid extended support, and when that ends AWS upgrades the cluster for you.
vs Node upgrades

Upgrading the control plane doesn't upgrade nodes. Nodes may lag the control plane within the supported version skew, but never run ahead of it.