Kubernetes interview question · Most asked
Ingress or Gateway API: how do you expose HTTP services, and what has changed recently?
Summary
An Ingress defines HTTP routing rules (hosts, paths, TLS) implemented by an ingress controller. The Gateway API is its successor: role-oriented resources (GatewayClass, Gateway, HTTPRoute, GRPCRoute) with richer, portable features such as header matching, traffic splitting and cross-namespace delegation, without controller-specific annotations.
Longer Answer
Ingress remains supported but frozen; most advanced behaviour lived in vendor annotations, which made configurations non-portable. Gateway API splits responsibilities: platform teams own Gateways (listeners, certificates), application teams own Routes. Implementations include Envoy Gateway, Istio, Cilium, NGINX Gateway Fabric, and cloud load-balancer controllers.
The community ingress-nginx controller, once the most common choice, has been retired by the Kubernetes project, so new clusters generally adopt a Gateway API implementation or a maintained vendor controller, and existing ingress-nginx users plan a migration.
Key Points
- Ingress: host/path rules via a controller.
- Gateway API: role-based, portable, richer.
- Annotations made Ingress non-portable.
- Plan migrations off retired ingress-nginx.
More most-asked Kubernetes questions
- Describe the Kubernetes architecture: what runs on the control plane and what runs on the nodes?
- How does the scheduler place pods? Explain resource requests, node affinity, taints and tolerations.
- Deployment, StatefulSet, DaemonSet, Job and CronJob: when do you use each?
- How do rolling updates work in a Deployment, and how do you roll back?
- Explain the Service types: ClusterIP, NodePort, LoadBalancer, ExternalName and headless.
- What happens, step by step, when you run kubectl apply for a Deployment?
- ConfigMaps and Secrets: how do they differ, and how should secrets really be handled?
- What is the difference between resource requests and limits, and what are the QoS classes?