Kubernetes Deployment + Service + Ingress Reference

TL;DR

• Bottom line: A Deployment manages Pod replicas with rolling updates, a Service provides stable networking to those Pods, and an Ingress routes external HTTP/HTTPS traffic to Services -- these three resources form the standard pattern for exposing applications on Kubernetes.
• Key tool/command: kubectl apply -f deployment.yaml -f service.yaml -f ingress.yaml
• Watch out for: Creating an Ingress without an Ingress controller deployed -- the resource will exist but do nothing.
• Works with: Kubernetes 1.19+ (apps/v1 Deployment, networking.k8s.io/v1 Ingress). Ingress API is frozen; Gateway API is the recommended successor for new projects.

Constraints

• An Ingress controller MUST be deployed in the cluster for Ingress resources to have any effect -- creating an Ingress alone does nothing
• Always use apps/v1 for Deployments and networking.k8s.io/v1 for Ingress -- older beta APIs are removed in k8s 1.22+
• spec.selector in Deployment is immutable after creation -- you cannot change it without deleting and recreating the Deployment
• Never use the :latest image tag in production -- pin to specific versions for reproducibility and rollback
• Resource requests and limits MUST be set on production Pods -- omitting them risks OOMKills and noisy-neighbor issues
• The Ingress API is frozen -- no new features will be added; use Gateway API for new greenfield projects

Quick Reference

Resource Type Overview

Service Type Comparison

Ingress Path Types

Decision Tree

START: How should external traffic reach your application?
│
├── Internal microservice only (no external traffic)?
│   ├── YES → Use Service type: ClusterIP (default)
│   └── NO  ↓
│
├── Need to expose a single TCP/UDP service (not HTTP)?
│   ├── YES → Cloud cluster? → LoadBalancer. On-prem? → NodePort
│   └── NO  ↓
│
├── Need HTTP/HTTPS routing with host/path rules?
│   ├── YES → New project? → Gateway API. Existing? → Ingress
│   └── NO  ↓
│
├── Need TLS termination?
│   ├── YES → Add tls section + cert-manager annotation
│   └── NO  → Ingress with HTTP-only rules
│
└── Which Ingress controller?
    ├── General purpose → NGINX Ingress Controller
    ├── Auto-discovery, Let's Encrypt → Traefik
    ├── High performance → HAProxy
    └── Cloud native → AWS ALB / GCE Ingress

Step-by-Step Guide

1. Create a Deployment

A Deployment declares the desired state for your application Pods, including the container image, replicas, and update strategy. [src1]

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.2.3
        ports:
        - containerPort: 8080
        resources:
          requests: { cpu: 100m, memory: 128Mi }
          limits: { cpu: 500m, memory: 256Mi }
        readinessProbe:
          httpGet: { path: /healthz, port: 8080 }
          initialDelaySeconds: 5
          periodSeconds: 10

Verify: kubectl apply -f deployment.yaml && kubectl rollout status deployment/myapp → deployment "myapp" successfully rolled out

2. Create a Service

A Service provides a stable ClusterIP and DNS name for the set of Pods matched by the selector. [src2]

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - name: http
    port: 80
    targetPort: 8080

Verify: kubectl get svc myapp → Shows ClusterIP assigned. kubectl get endpoints myapp → Shows Pod IPs.

3. Create an Ingress

An Ingress defines HTTP routing rules that map external hostnames and paths to backend Services. Requires an Ingress controller. [src3]

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
  - hosts: [myapp.example.com]
    secretName: myapp-tls
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port: { number: 80 }

Verify: kubectl get ingress myapp → Shows ADDRESS and HOST.

4. Configure cert-manager for automatic TLS

cert-manager watches for Ingress resources with the appropriate annotation and automatically provisions TLS certificates. [src5]

# cluster-issuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v2.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          ingressClassName: nginx

Verify: kubectl get certificate -A → Ready: True.

5. Perform a rolling update

Update the container image to trigger a zero-downtime rolling update. [src1]

kubectl set image deployment/myapp myapp=myapp:1.3.0
kubectl rollout status deployment/myapp
# Roll back if needed:
kubectl rollout undo deployment/myapp

Verify: kubectl rollout history deployment/myapp → Shows revision history.

Code Examples

YAML: Complete Deployment + ClusterIP Service + Ingress

# Input:  Container image myapp:1.2.3 on port 8080
# Output: App accessible at https://myapp.example.com
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels: { app: myapp }
spec:
  replicas: 3
  selector: { matchLabels: { app: myapp } }
  template:
    metadata: { labels: { app: myapp } }
    spec:
      containers:
      - name: myapp
        image: myapp:1.2.3
        ports: [{ containerPort: 8080 }]
        resources:
          requests: { cpu: 100m, memory: 128Mi }
          limits: { cpu: 500m, memory: 256Mi }
        readinessProbe:
          httpGet: { path: /healthz, port: 8080 }

YAML: NodePort Service (on-prem / no cloud LB)

apiVersion: v1
kind: Service
metadata:
  name: myapp-nodeport
spec:
  type: NodePort
  selector: { app: myapp }
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080

YAML: LoadBalancer Service (cloud environments)

apiVersion: v1
kind: Service
metadata:
  name: myapp-lb
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector: { app: myapp }
  ports:
  - name: https
    port: 443
    targetPort: 8080

YAML: Multi-service Ingress with path-based routing

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-service
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: { name: frontend, port: { number: 80 } }
      - path: /api(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service: { name: api, port: { number: 80 } }

Anti-Patterns

Wrong: Missing resource requests and limits

# BAD -- no resource requests/limits; Pod can OOMKill others
spec:
  containers:
  - name: myapp
    image: myapp:1.2.3
    # No resources block -- BestEffort QoS

Correct: Always set resource requests and limits

# GOOD -- explicit resource boundaries
spec:
  containers:
  - name: myapp
    image: myapp:1.2.3
    resources:
      requests: { cpu: 100m, memory: 128Mi }
      limits: { cpu: 500m, memory: 256Mi }

Wrong: Using :latest image tag

# BAD -- :latest is mutable; rollback impossible
spec:
  containers:
  - name: myapp
    image: myapp:latest

Correct: Pin image to specific version

# GOOD -- immutable version tag; rollback works
spec:
  containers:
  - name: myapp
    image: myapp:1.2.3

Wrong: No readiness probe with rolling update

# BAD -- traffic sent to Pods before they're ready
spec:
  containers:
  - name: myapp
    image: myapp:1.2.3
    # No readinessProbe

Correct: Configure readiness probe

# GOOD -- Pod receives traffic only after probe succeeds
spec:
  containers:
  - name: myapp
    image: myapp:1.2.3
    readinessProbe:
      httpGet: { path: /healthz, port: 8080 }
      initialDelaySeconds: 5
      periodSeconds: 10

Wrong: Selector mismatch between Deployment and Service

# BAD -- "my-app" != "myapp"; no traffic reaches Pods
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

Correct: Ensure labels match exactly

# GOOD -- selector matches Pod template labels
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

Wrong: Ingress without ingressClassName

# BAD -- wrong or no controller may handle it
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: { name: myapp, port: { number: 80 } }

Correct: Always specify ingressClassName

# GOOD -- explicit controller selection
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
spec:
  ingressClassName: nginx
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: { name: myapp, port: { number: 80 } }

Common Pitfalls

• Selector mismatch: Pod labels, Service selector, and Ingress backend must all align. Fix: kubectl get endpoints myapp to verify Pod IPs are listed. [src2]
• Ingress without controller: Ingress resource sits idle with no ADDRESS. Fix: Install a controller first; check with kubectl get ingressclass. [src3]
• TLS secret not found: Secret must be in same namespace as Ingress. Fix: Verify ClusterIssuer is configured; check kubectl describe certificate. [src5]
• NodePort range conflict: Must be 30000-32767. Fix: Omit nodePort for auto-assign or check existing with kubectl get svc --all-namespaces. [src2]
• Rolling update deadlock: maxSurge=0 + maxUnavailable=0 is invalid. Fix: Set maxSurge >= 1 when maxUnavailable is 0. [src1]
• Image pull errors: Wrong image name/tag or missing imagePullSecrets. Fix: kubectl describe pod <name> for exact error. [src4]
• OOMKilled from low limits: Container exceeds memory limit. Fix: kubectl top pod to check usage, set limits 20-50% above peak. [src4]
• Ingress path ordering: More specific paths must come first. Fix: Order /api/v1 before /api before /. [src3]

Diagnostic Commands

# Check Deployment rollout status
kubectl rollout status deployment/myapp

# View rollout history
kubectl rollout history deployment/myapp

# Check Service endpoints (empty = selector mismatch)
kubectl get endpoints myapp

# Verify Ingress has ADDRESS (empty = no controller)
kubectl get ingress myapp

# Debug Pod issues
kubectl describe pod -l app=myapp
kubectl logs -l app=myapp --tail=50

# Check installed Ingress controllers
kubectl get ingressclass

# Test connectivity from inside cluster
kubectl run curl --image=curlimages/curl --rm -it -- curl http://myapp.default.svc.cluster.local

# View resource usage (requires metrics-server)
kubectl top pods -l app=myapp

# Check events for failures
kubectl get events --sort-by=.metadata.creationTimestamp

Version History & Compatibility

When to Use / When Not to Use

Important Caveats

• The Ingress API is frozen and will receive no new features -- plan migration to Gateway API for new projects
• Community Ingress NGINX controller is retiring March 2026 -- migrate to NGINX Inc's controller, Traefik, or Gateway API
• Each LoadBalancer Service provisions a separate cloud LB ($15-25/month) -- use Ingress to consolidate
• maxSurge and maxUnavailable cannot both be 0 -- Kubernetes rejects the configuration
• Ingress TLS terminates at the controller -- traffic to Pods is HTTP by default; use service mesh for end-to-end encryption
• Deployment spec.selector.matchLabels is immutable -- changing requires delete and recreate