Kubernetes Networking - Learning Module

Loading content...

0/273

Ingress Controllers: L7 Traffic Management

Beyond Services: The Need for L7 Routing

In the previous page, we explored Kubernetes Services—the L4 (transport layer) abstraction for routing TCP/UDP traffic to Pods. Services work remarkably well for internal communication and simple external exposure. But they have a significant limitation: Services are blind to HTTP semantics.

Consider these common requirements:

Route api.example.com/users to the User Service and api.example.com/orders to the Order Service
Terminate TLS/SSL at the edge and handle certificates
Redirect HTTP to HTTPS automatically
Apply rate limiting to specific API endpoints
Enable WebSocket connections with proper upgrade handling

Services cannot do any of this. They operate at Layer 4—they see IP addresses and ports, not HTTP paths, headers, or hostnames. This is where Ingress enters the picture.

What You Will Learn

By the end of this page, you will understand Ingress resources, Ingress Controllers, and how they enable sophisticated L7 traffic management. You'll learn to configure path-based and host-based routing, TLS termination, and choose between popular Ingress Controller implementations.

Understanding Ingress

Ingress is a Kubernetes API resource that defines HTTP/HTTPS routing rules for external traffic. Unlike Services, which are implemented natively by kube-proxy, Ingress requires a separate component called an Ingress Controller to function.

The Ingress Architecture

External Traffic
      │
      ▼
┌─────────────────┐
│  Load Balancer  │   ← Cloud LB or bare metal LB
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│    Ingress      │   ← Ingress Controller Pod(s)
│   Controller    │      (NGINX, Traefik, etc.)
└────────┬────────┘
         │ Routes based on
         │ host/path rules
    ┌────┴────┐
    ▼         ▼
┌───────┐ ┌───────┐
│ Svc A │ │ Svc B │   ← ClusterIP Services
└───┬───┘ └───┬───┘
    │         │
    ▼         ▼
  Pods       Pods

Key Components:

Ingress Resource: A YAML definition of routing rules (the "what")
Ingress Controller: A reverse proxy/load balancer that reads Ingress resources and implements them (the "how")
Backend Services: ClusterIP Services that the Ingress routes traffic to

Critical: Ingress Doesn't Work Alone

Creating an Ingress resource without an Ingress Controller does nothing. The Ingress API object is just data—the Controller is what reads it and configures the actual proxy. Every cluster needs at least one Ingress Controller deployed.

Why Ingress Over Multiple LoadBalancers?

You could expose each service with its own LoadBalancer Service. But consider the costs:

Approach	10 Services	Monthly Cost (AWS)	TLS Certificates
10 LoadBalancer Services	10 LBs	~$180/month	10 separate certs
1 Ingress + 1 LoadBalancer	1 LB	~$18/month	1 wildcard or multi-SAN cert

Ingress consolidates external access into a single entry point, dramatically reducing cost and operational complexity.

Ingress Resource Deep Dive

An Ingress resource defines how external HTTP(S) traffic should be routed to Services. Let's explore the full capabilities:

ingress-complete-example.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  namespace: production
  annotations:
    # Controller-specific annotations (NGINX example)
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    
    # CORS configuration
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "https://app.example.com"
    
    # Rate limiting
    nginx.ingress.kubernetes.io/limit-rps: "100"
    nginx.ingress.kubernetes.io/limit-connections: "50"
spec:
  # Specify which controller should handle this Ingress
  ingressClassName: nginx
  
  # TLS configuration
  tls:
  - hosts:
    - api.example.com
    - app.example.com
    secretName: example-com-tls    # Secret with TLS cert + key
  - hosts:
    - admin.example.com
    secretName: admin-tls
  
  # Default backend for unmatched requests
  defaultBackend:
    service:
      name: default-backend
      port:
        number: 80
  
  # Routing rules
  rules:
  # Host-based routing: api.example.com
  - host: api.example.com
    http:
      paths:
      # Path-based routing within the host
      - path: /users
        pathType: Prefix          # Match /users, /users/123, /users/123/profile
        backend:
          service:
            name: user-service
            port:
              number: 80
      - path: /orders
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 80
      - path: /
        pathType: Prefix         # Catch-all for api.example.com
        backend:
          service:
            name: api-gateway
            port:
              number: 80
  
  # Another host: app.example.com
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-frontend
            port:
              number: 80
  
  # Wildcard host: *.staging.example.com
  - host: "*.staging.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: staging-router
            port:
              number: 80

Path Types Explained

Kubernetes supports three pathType values, and understanding them is crucial for correct routing:

pathType	Behavior	Example Path: `/api`
Exact	Must match exactly	Only `/api`, not `/api/` or `/api/v1`
Prefix	Matches path prefix by segment	`/api`, `/api/`, `/api/v1`, `/api/users`
ImplementationSpecific	Controller decides	Varies by controller

Important: Prefix matching is segment-based. Path /api will match /api/v1 but NOT /apikey (different segment).

Path Matching Examples
Rule Path	pathType	/api	/api/	/api/v1	/apikey
/api	Exact	✅ Match	❌ No	❌ No	❌ No
/api	Prefix	✅ Match	✅ Match	✅ Match	❌ No
/api/	Prefix	❌ No	✅ Match	✅ Match	❌ No
/	Prefix	✅ Match	✅ Match	✅ Match	✅ Match

TLS Termination and Certificate Management

Ingress Controllers handle TLS termination at the edge, decrypting HTTPS traffic before forwarding plain HTTP to backend Services. This centralizes certificate management and offloads encryption from application Pods.

Setting Up TLS

tls-setup.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# Step 1: Create TLS Secret with certificate and private key
apiVersion: v1
kind: Secret
metadata:
  name: example-com-tls
  namespace: production
type: kubernetes.io/tls
data:
  # Base64-encoded certificate chain (PEM format)
  tls.crt: LS0tLS1CRUdJTi...  # base64 -w 0 cert.pem
  # Base64-encoded private key (PEM format)
  tls.key: LS0tLS1CRUdJTi...  # base64 -w 0 key.pem
 
---
# Or create imperatively:
# kubectl create secret tls example-com-tls \
#   --cert=cert.pem \
#   --key=key.pem \
#   -n production
 
---
# Step 2: Reference in Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
  namespace: production
  annotations:
    # Force HTTPS redirect
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    # HSTS header
    nginx.ingress.kubernetes.io/hsts: "true"
    nginx.ingress.kubernetes.io/hsts-max-age: "31536000"
    nginx.ingress.kubernetes.io/hsts-include-subdomains: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - api.example.com
    - www.example.com
    secretName: example-com-tls  # Must be in same namespace
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Automated Certificates with cert-manager

cert-manager is the de facto standard for automated certificate management in Kubernetes. It integrates with Let's Encrypt and other CAs to automatically provision and renew certificates.

cert-manager-setup.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
# Step 1: Install cert-manager (Helm)
# helm repo add jetstack https://charts.jetstack.io
# helm install cert-manager jetstack/cert-manager \
#   --namespace cert-manager \
#   --create-namespace \
#   --set installCRDs=true
 
---
# Step 2: Create ClusterIssuer for Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: platform-team@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    # HTTP-01 challenge solver (requires Ingress)
    - http01:
        ingress:
          class: nginx
    # OR DNS-01 challenge (for wildcards, requires DNS provider)
    # - dns01:
    #     cloudDNS:
    #       project: my-gcp-project
    #       serviceAccountSecretRef:
    #         name: clouddns-dns01-solver-svc-acct
    #         key: key.json
 
---
# Step 3: Annotate Ingress for automatic certificate
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auto-tls-ingress
  namespace: production
  annotations:
    # Tell cert-manager to issue certificate
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - api.example.com
    secretName: api-example-com-tls  # cert-manager creates this automatically!
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
 
# cert-manager will:
# 1. Detect the annotation and tls.hosts
# 2. Create a Certificate resource
# 3. Solve the ACME challenge (HTTP-01 or DNS-01)
# 4. Store the issued cert in the Secret
# 5. Renew automatically before expiry

cert-manager Best Practices

• Use ClusterIssuer for shared issuers across namespaces; use Issuer for namespace-scoped. • Start with Let's Encrypt staging for testing to avoid rate limits. • For wildcard certificates, DNS-01 challenge is required. • Set up monitoring for certificate expiration (cert-manager exports Prometheus metrics).

Popular Ingress Controllers Compared

Kubernetes doesn't ship with a default Ingress Controller—you must choose and deploy one. The ecosystem offers numerous options, each with different strengths. Here's an in-depth comparison of the most popular choices:

Ingress Controller Comparison
Controller	Base Technology	Best For	Key Features
NGINX Ingress	NGINX	General purpose, high performance	Lua scripting, canary deployments, rate limiting, WAF
Traefik	Go (native)	Dynamic environments, GitOps	Auto-discovery, Let's Encrypt, middlewares, observability
HAProxy Ingress	HAProxy	High-performance L4/L7	Connection queuing, advanced LB algorithms
Kong Ingress	Kong (NGINX)	API Gateway features	Plugins (auth, rate limiting), developer portal
Istio Gateway	Envoy	Service mesh environments	mTLS, traffic management, observability
AWS ALB	AWS ALB	AWS-native deployments	Native ALB features, WAF, Cognito auth
GKE Ingress	Google Cloud LB	GKE clusters	Global LB, Cloud CDN, Cloud Armor
Contour	Envoy	Multi-team clusters	HTTPProxy CRD, delegation, rate limiting

NGINX Ingress Controller (Most Common)

The NGINX Ingress Controller is the most widely deployed option. It comes in two variants:

kubernetes/ingress-nginx (Community) - Kubernetes project maintained
nginxinc/kubernetes-ingress (NGINX Inc) - Commercial, with NGINX Plus support

nginx-ingress-install.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Install NGINX Ingress Controller (Helm method - recommended)
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
 
# Basic installation
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace
 
# Production installation with recommended settings
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=3 \
  --set controller.nodeSelector."node.kubernetes.io/purpose"=ingress \
  --set controller.resources.requests.memory=256Mi \
  --set controller.resources.requests.cpu=100m \
  --set controller.autoscaling.enabled=true \
  --set controller.autoscaling.minReplicas=3 \
  --set controller.autoscaling.maxReplicas=10 \
  --set controller.service.externalTrafficPolicy=Local \
  --set controller.metrics.enabled=true \
  --set controller.metrics.serviceMonitor.enabled=true
 
# Verify installation
kubectl get pods -n ingress-nginx
kubectl get svc -n ingress-nginx
 
# Check the external IP/hostname
kubectl get svc ingress-nginx-controller -n ingress-nginx -o jsonpath='{.status.loadBalancer.ingress[0]}'

Traefik (Cloud-Native Alternative)

Traefik is designed for dynamic environments with automatic service discovery. It's particularly popular in Docker and smaller Kubernetes deployments.

traefik-install.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Install Traefik via Helm
helm repo add traefik https://helm.traefik.io/traefik
helm repo update
 
helm install traefik traefik/traefik \
  --namespace traefik \
  --create-namespace \
  --set deployment.replicas=3 \
  --set ingressRoute.dashboard.enabled=true \
  --set providers.kubernetesIngress.enabled=true \
  --set providers.kubernetesCRD.enabled=true \
  --set metrics.prometheus.enabled=true
 
# Traefik uses its own CRD (IngressRoute) for advanced features
# but also supports standard Kubernetes Ingress

traefik-ingressroute.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# Traefik's native CRD offers more features than standard Ingress
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-ingressroute
  namespace: production
spec:
  entryPoints:
  - websecure    # HTTPS entrypoint
  routes:
  - match: Host(`api.example.com`) && PathPrefix(`/v1`)
    kind: Rule
    services:
    - name: api-v1
      port: 80
      weight: 100
    middlewares:
    - name: rate-limit
    - name: api-auth
  - match: Host(`api.example.com`) && PathPrefix(`/v2`)
    kind: Rule
    services:
    - name: api-v2
      port: 80
  tls:
    secretName: api-example-com-tls
 
---
# Middleware for rate limiting
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: rate-limit
  namespace: production
spec:
  rateLimit:
    average: 100
    burst: 200
    period: 1s

Advanced Ingress Patterns

Production Ingress configurations often require advanced patterns beyond basic routing. Here are the most commonly used patterns:

1. Canary Deployments

Gradually shift traffic to a new version to validate before full rollout:

canary-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
# Primary (stable) Ingress - receives most traffic
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress-stable
  annotations:
    nginx.ingress.kubernetes.io/canary: "false"
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service-stable
            port:
              number: 80
 
---
# Canary Ingress - receives percentage of traffic
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    # Weight-based: 10% of traffic to canary
    nginx.ingress.kubernetes.io/canary-weight: "10"
    
    # OR Header-based: route specific users to canary
    # nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    # nginx.ingress.kubernetes.io/canary-by-header-value: "true"
    
    # OR Cookie-based: route users with specific cookie
    # nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service-canary
            port:
              number: 80

2. Blue-Green Deployments

Switch between two complete environments:

blue-green-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# Single Ingress pointing to the active environment
# Switch by updating the backend service name
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service-blue   # Switch to api-service-green
            port:
              number: 80
 
---
# Blue environment service
apiVersion: v1
kind: Service
metadata:
  name: api-service-blue
spec:
  selector:
    app: api
    version: blue
  ports:
  - port: 80
    targetPort: 8080
 
---
# Green environment service
apiVersion: v1
kind: Service
metadata:
  name: api-service-green
spec:
  selector:
    app: api
    version: green
  ports:
  - port: 80
    targetPort: 8080

3. Path Rewriting

Rewrite request paths before forwarding to backends:

path-rewrite-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    # Rewrite /api/users/(.*)  →  /$1  (strip /api/users prefix)
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    # Use regex in path matching
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      # /api/users/profile → backend receives /profile
      - path: /api/users(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: user-service
            port:
              number: 80
      # /api/orders/123 → backend receives /123
      - path: /api/orders(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: order-service
            port:
              number: 80

4. Authentication and Authorization

Integrate external authentication services:

auth-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: protected-ingress
  annotations:
    # External auth service
    nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/verify"
    nginx.ingress.kubernetes.io/auth-signin: "https://auth.example.com/login?rd=$scheme://$host$request_uri"
    nginx.ingress.kubernetes.io/auth-response-headers: "X-User-Id,X-User-Email,X-User-Roles"
    
    # Basic auth (alternative - simpler)
    # nginx.ingress.kubernetes.io/auth-type: basic
    # nginx.ingress.kubernetes.io/auth-secret: basic-auth-secret
    # nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
spec:
  ingressClassName: nginx
  rules:
  - host: admin.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: admin-dashboard
            port:
              number: 80
 
---
# Basic auth secret (for basic-auth approach)
# Create: htpasswd -c auth admin
# kubectl create secret generic basic-auth-secret --from-file=auth

Running Multiple Ingress Controllers

Large organizations often run multiple Ingress Controllers for different purposes:

Public vs Private: One for internet traffic, one for internal traffic
Team Isolation: Different teams manage their own controllers
Feature Requirements: Some apps need features only available in specific controllers

The ingressClassName field directs each Ingress to the correct controller.

multiple-controllers.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
# IngressClass for public traffic (NGINX)
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx-public
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"  # Default for unspecified
spec:
  controller: k8s.io/ingress-nginx
  parameters:
    apiGroup: k8s.nginx.org
    kind: IngressNginxConfig
    name: nginx-public-config
 
---
# IngressClass for internal traffic (separate NGINX deployment)
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx-internal
spec:
  controller: k8s.io/ingress-nginx-internal  # Different controller name
 
---
# Public-facing API
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: public-api
spec:
  ingressClassName: nginx-public  # Routed by public controller
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: public-api
            port:
              number: 80
 
---
# Internal admin dashboard
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: internal-admin
spec:
  ingressClassName: nginx-internal  # Routed by internal controller
  rules:
  - host: admin.internal.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: admin-dashboard
            port:
              number: 80

IngressClass vs Annotations

Before Kubernetes 1.18, controller selection was done via the kubernetes.io/ingress.class annotation. The ingressClassName field is the modern, standardized approach. Most controllers support both for backward compatibility.

Monitoring Ingress Controllers

Ingress Controllers are critical infrastructure—if they fail, external traffic stops. Comprehensive monitoring is essential.

nginx-monitoring.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# Enable metrics in NGINX Ingress (Helm values)
controller:
  metrics:
    enabled: true
    port: 10254
    service:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "10254"
    serviceMonitor:
      enabled: true
      namespace: monitoring
      additionalLabels:
        release: prometheus
 
---
# ServiceMonitor for Prometheus Operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: nginx-ingress
  namespace: monitoring
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/component: controller
  namespaceSelector:
    matchNames:
    - ingress-nginx
  endpoints:
  - port: metrics
    interval: 30s

Key Metrics to Monitor

Metric	Description	Alert Threshold
`nginx_ingress_controller_requests`	Total requests by status code	High 5xx rate
`nginx_ingress_controller_request_duration_seconds`	Request latency histogram	p99 > 1s
`nginx_ingress_controller_nginx_process_connections`	Active connections	Near max connections
`nginx_ingress_controller_ssl_certificate_expiry_seconds`	Cert expiry	< 7 days
`nginx_ingress_controller_config_reload_success`	Config reload status	Any failure

Essential Alerts

•High Error Rate: Alert if 5xx responses exceed 1% of traffic
•Latency Degradation: Alert if p99 latency exceeds SLA threshold
•Certificate Expiry: Alert 30, 14, and 7 days before expiration
•Config Reload Failures: Alert immediately on any reload failure
•Controller Pod Restarts: Alert if pods restart frequently
•Connection Saturation: Alert if active connections approach limit

Troubleshooting Ingress Issues

Ingress adds a layer of abstraction that can make troubleshooting complex. Here's a systematic debugging approach:

troubleshoot-ingress.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Step 1: Check Ingress Controller is running
kubectl get pods -n ingress-nginx
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx -f
 
# Step 2: Verify Ingress resource is created correctly
kubectl get ingress my-ingress -o yaml
kubectl describe ingress my-ingress
 
# Step 3: Check IngressClass assignment
kubectl get ingressclass
kubectl describe ingressclass nginx
 
# Step 4: Verify backend Service and Endpoints
kubectl get svc my-backend-service
kubectl get endpoints my-backend-service  # Should show Pod IPs
 
# Step 5: Check controller configuration (NGINX specific)
# Enter the controller pod and check generated config
kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- \
  cat /etc/nginx/nginx.conf | grep -A 20 "server_name my-host"
 
# Step 6: Test from inside cluster
kubectl run -it --rm debug --image=curlimages/curl -- \
  curl -H "Host: api.example.com" http://ingress-nginx-controller.ingress-nginx/path
 
# Step 7: Check TLS certificates
kubectl get secret my-tls-secret -o yaml
# Decode and verify: echo "<base64>" | base64 -d | openssl x509 -text
 
# Step 8: View controller logs for specific host
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx | \
  grep "api.example.com"
 
# Step 9: Check for configuration errors
kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- \
  nginx -t  # Test NGINX config syntax

Common Ingress Issues and Solutions
Symptom	Likely Cause	Solution
404 Not Found	Path doesn't match any rule	Check pathType and path values; verify host header
503 Service Unavailable	No healthy backends	Check Endpoints; verify readinessProbe
SSL Error	Certificate mismatch or missing	Verify TLS secret exists; check cert hostnames
Ingress not working at all	Controller not watching namespace	Check controller logs; verify IngressClass
Redirect loop	SSL redirect + backend also redirecting	Disable annotation or fix backend
Slow responses	Backend slow or controller overloaded	Check backend latency; scale controller
WebSocket fails	Timeouts too short	Increase proxy-read-timeout annotation

Summary: Ingress Controllers

We've covered Ingress Controllers comprehensively. Let's consolidate the key takeaways:

Key Takeaways

•Ingress provides L7 routing that Services (L4) cannot—host-based, path-based, and TLS termination.
•Ingress resources are declarative rules; Ingress Controllers are the implementations that enforce them.
•TLS termination centralizes certificate management and is easily automated with cert-manager.
•NGINX Ingress Controller is the most common choice, but evaluate Traefik, Kong, or cloud-native options based on your needs.
•Canary and blue-green deployments are natively supported through Ingress annotations.
•Multiple controllers can coexist using IngressClass to direct traffic appropriately.
•Monitoring is critical—track latency, error rates, and certificate expiration.

What's Next:

Ingress controls traffic at the edge, but what about internal traffic between Pods? In the next page, we'll explore Network Policies—Kubernetes' built-in firewall for controlling Pod-to-Pod communication and implementing zero-trust networking.

Page Complete

You now understand Ingress Controllers—how they provide L7 traffic management, TLS termination, and advanced routing capabilities. You can configure Ingress resources, choose appropriate controllers, and troubleshoot common issues. Next, we'll secure internal traffic with Network Policies.