In Amazon EKS, how do you ensure high availability of components, and what happens if a component crashes?

High availability in EKS is achieved through a combination of cluster architecture, node management, and application design. First, run worker nodes across multiple Availability Zones (AZs) using managed node groups or self‑managed nodes with an Auto Scaling Group (ASG) that spans AZs. This ensures that if an AZ fails, the cluster still has healthy nodes. Second, use Kubernetes ReplicaSets and Deployments to maintain the desired number of pod replicas; if a pod crashes, the kube‑controller automatically schedules a replacement on a healthy node. Third, enable pod anti‑affinity rules to spread critical pods across AZs. For control plane, EKS automatically runs the API server and etcd across three AZs, so the control plane remains available even if one AZ is down. If a component crashes, Kubernetes’ self‑healing mechanisms detect the failure via liveness/readiness probes and restart the pod or reschedule it. For node failures, the ASG replaces the instance, and the kubelet on the new node registers it with the cluster. Monitoring and alerting (Prometheus, CloudWatch) should be in place to detect and respond to failures quickly.