Mastering Kubernetes Service Exposure: From Services to Ingress Gateways

Introduction

This article is based on a talk from the Volcano Engine developer community meetup and introduces how applications running on Kubernetes can be exposed and managed through services and gateways.

Why Use a Gateway?

When a simple monolithic shopping app grows into multiple micro‑services, a load balancer like Nginx can expose the services, but additional concerns such as authentication, security, and traffic control become burdensome if implemented in each micro‑service. An API Gateway centralizes these cross‑cutting concerns.

Kubernetes Service Model

Kubernetes provides a Service API that uses kube‑proxy on each node to watch Service and Endpoint resources and create forwarding rules via iptables or IPVS. The three main Service types are:

ClusterIP : internal access within the cluster.

NodePort : exposes a port on each node to reach the service.

LoadBalancer : builds on NodePort and requires an external load‑balancer provider.

Ingress

Ingress is an additional API that provides HTTP/HTTPS entry points to services. An Ingress Controller watches Ingress resources and generates the underlying proxy configuration (e.g., Nginx). Community implementations include Nginx‑ingress, Kong, Envoy‑based controllers such as Contour, and others.

Community Gateway Analysis

Popular open‑source gateways include Nginx‑based Kong, Envoy‑based Contour, Ambassador, Gloo, HAProxy, as well as service‑mesh gateways like Istio and Traefik. Surveys show Nginx remains dominant, but Envoy is gaining traction due to its performance.

Gateway Management Practice

In our PaaS platform we manage gateways via custom CRDs:

Gateway CRD : defines the load‑balancer type and selects an Ingress Controller.

TrafficRoute CRD : manages Ingress resources, routing rules, and plugins.

Supporting operators include:

LoadBalancer Operator : creates cloud or on‑premise load balancers.

Proxy Operator : maintains the lifecycle of the chosen Ingress Controller.

Route Controller : translates TrafficRoute into concrete Ingress configurations.

Non‑Cloud Scenario

When no external load balancer exists, we deploy an internal LB using IPVS, Keepalived, or MetalLB, and expose the Ingress Controller via a LoadBalancer Service.

Cloud Scenario

In cloud environments the cloud provider creates a LoadBalancer Service automatically; the main challenge is managing the Ingress Controller lifecycle.

Gateway API

The emerging Gateway API extends Ingress functionality, introducing resources such as GatewayClass, Gateway, and *Route (HTTPRoute, TCPRoute, etc.). It separates roles into Infrastructure Provider, Cluster Operator, and Application Developer, enabling more expressive configuration and lifecycle management.

Conclusion

Kubernetes offers multiple ways to expose services, with Ingress being the most flexible. Nginx remains the dominant controller, but Envoy‑based solutions are gaining popularity. The new Gateway API promises a more powerful and extensible model, though adoption is still early.