Kubernetes Deployment, Service and Ingress: How the Production Request Path Actually Works

The request path

A Kubernetes application is easier to operate when the team understands what every object does.

Typical request:

Internet
  |
DNS
  |
Load Balancer
  |
Ingress Controller
  |
Ingress rule
  |
Service
  |
Pod
  |
NestJS/Spring application

Deployment

Deployment manages desired replica sets.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: booking-service
spec:
  replicas: 4
  selector:
    matchLabels:
      app: booking-service
  template:
    metadata:
      labels:
        app: booking-service
    spec:
      containers:
        - name: booking
          image: registry/booking:2026.09.01
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: "1"
              memory: 768Mi
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080

Service

Pods are replaceable.

Service provides stable virtual identity:

apiVersion: v1
kind: Service
metadata:
  name: booking-service
spec:
  selector:
    app: booking-service
  ports:
    - port: 80
      targetPort: 8080

Internal caller:

http://booking-service

does not know pod IPs.

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: booking
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "5"
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /booking
            pathType: Prefix
            backend:
              service:
                name: booking-service
                port:
                  number: 80

Ingress is routing configuration.

The ingress controller is the actual running component implementing it.

TLS

I terminate TLS at load balancer/ingress according to platform design and automate certificate rotation.

Internal encryption requirements may require TLS deeper in the path.

Service types

ClusterIP: internal stable endpoint.

LoadBalancer: cloud load balancer.

NodePort: usually an implementation building block, not my preferred public API exposure.

Why readiness matters

Service endpoints should include only ready pods.

If readiness is wrong:

new pod starts
Service sends traffic
application still loading configuration
requests fail

Why selectors matter

If labels/selector do not match, Service has zero endpoints.

Debug:

kubectl get service booking-service
kubectl get endpoints booking-service
kubectl get pods -l app=booking-service

Request tracing

I propagate:

X-Request-ID / traceparent

through ingress -> service -> downstream.

That is much more useful than treating Kubernetes network hops as invisible.

Production checklist

• Deployment labels match Service selector.
• Readiness removes unhealthy pods.
• Resource requests defined.
• Multiple replicas.
• Ingress timeout aligned with API SLA.
• TLS managed automatically.
• Public/internal routes separated.
• Correlation propagated.
• NetworkPolicy where required.
• Endpoint count monitored.

FAQ

Service vs Ingress?

Service routes to pods inside the cluster. Ingress provides HTTP routing from an ingress controller toward Services.

Does Ingress replace API Gateway?

Not necessarily. Ingress handles network/application routing; API gateways often add consumer auth, quotas, API products and policy.

Why not call Pod IP directly?

Pod IPs are ephemeral and bypass Service discovery/load balancing.

Related architecture guides

• Amazon EKS

• Kubernetes Production Readiness

  Architect's final take

  Deployment, Service and Ingress are simple objects individually. Production reliability comes from understanding how they interact during startup, failure, scaling and rollout.