A SaaS company is decomposing a monolith into 30 Kubernetes-native microservices with spiky traffic, wants Kubernetes APIs and serverless nodes, and requires namespace isolation plus autoscaling without managing EC2. Which container orchestration design for microservices best balances control and operations?
Select an answer to reveal the explanation.
Short Explanation
You love Kubernetes but not patching nodes at midnight. Fargate profiles give you serverless pods with familiar kubectl control. It's like renting furnished apartments instead of maintaining houses.
Full Explanation
The correct choice preserves Kubernetes APIs, manifests and namespace isolation while offloading node provisioning to EKS with Fargate profiles that schedule pods serverlessly and are selected per namespace, with pod-level autoscaling through the Horizontal Pod Autoscaler (Fargate has no nodes for Cluster Autoscaler to manage), paired with ALB Ingress for L7 routing, which meets spiky scale and no-EC2 facts. ECS with Fargate also removes servers and autoscales but abandons Kubernetes APIs and tooling, so it satisfies serverless but misses the Kubernetes-native requirement. EKS with managed EC2 node groups and Karpenter optimizes bin-packing and startup but reintroduces AMI, patching and capacity operations, violating the no-EC2-management constraint. ECS with EC2 launch cannot run native Kubernetes objects like Deployments backed by kubelet and API server, so that hybrid misstates service capabilities and fails both control and operations goals. For the exam, choose EKS plus Fargate when Kubernetes compatibility and serverless nodes are both explicit, choose ECS plus Fargate for simplicity without Kubernetes, and in practice validate Fargate CPU memory combinations, profile selectors and Ingress health checks.