Comparing Kubernetes Gateway and Ingress APIs
A couple of months ago, the new Kubernetes Gateway API graduated to beta, which probably means you have several questions, like:
- Why do you need another API to handle external traffic when you have the stable Kubernetes Ingress API and dozens of implementations?
- What problems of the Ingress API does the new Gateway API solve?
- Does this mean the end of the Ingress API?
I will try to answer these questions in this article by getting hands-on with these APIs and looking at how they have evolved.
The Kubernetes Ingress API was created to standardize exposing services in Kubernetes to external traffic. The Ingress API overcame the limitations of the default service types, NodePort and LoadBalancer, by introducing features like routing and SSL termination.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-routes
spec:
ingressClassName: apisix
rules:
– host: local.navendu.me
http:
paths:
– backend:
service:
name: bare-minimum-api-v1
port:
number: 8080
path: /v1
pathType: Prefix
– backend:
service:
name: bare-minimum-api-v2
port:
number: 8081
path: /v2
pathType: Prefix