Ingress

​

Scenario: Why Ingress?

• Your storefront is built into a Docker image and deployed as a Deployment.
• MySQL runs as a Pod and is exposed internally via a ClusterIP Service (mysql-service) so your app can access the database.
• The storefront app is exposed using a NodePort Service (wear-service) which assigns a high port (e.g., 30080) on every node.

• http://<node-ip>:30080

• Friendly hostnames (DNS pointing to an external IP rather than node IPs).
• Standard ports (80/443), not high NodePort numbers.
• Path- or host-based routing for multiple applications (e.g., /watch or watch.myonlinestore.com).
• Centralized TLS termination and certificate management.

• Route traffic by hostnames and URL paths (e.g., /apparel → apparel service, /video → video service).
• Terminate TLS and centralize certificate handling.
• Avoid provisioning a cloud load balancer for every Service.

​

How Ingress works — components and flow

1. Deploy an Ingress controller (a Deployment/DaemonSet running NGINX, Traefik, Contour, HAProxy, etc.).
2. Create Ingress resources (Kubernetes objects) describing host/path → Service mappings and TLS configuration.
3. The controller watches the API for Ingress objects and updates its proxy configuration accordingly (routing, load balancing, TLS termination, rewrites, etc.).
4. Expose the controller externally (Service type LoadBalancer or NodePort). That external exposure is typically a one-time setup; adding routes or certificates is handled by updating Ingress resources.

​

Ingress controller typical components

• Deployment (or DaemonSet) running controller pods.
• Service exposing the controller (NodePort or LoadBalancer) to receive external traffic.
• Optional ConfigMap for controller-specific settings.
• ServiceAccount + RBAC so the controller can watch Ingress, Services, Endpoints, Secrets, Pods, etc.

​

Simplified example: NGINX Ingress controller manifest

# nginx-ingress-controller Deployment (simplified)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
spec:
  replicas: 1
  selector:
    matchLabels:
      name: nginx-ingress
  template:
    metadata:
      labels:
        name: nginx-ingress
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
      - name: nginx-ingress-controller
        image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.21.0
        args:
          - /nginx-ingress-controller
          - --configmap=$(POD_NAMESPACE)/nginx-configuration
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
        ports:
          - name: http
            containerPort: 80
          - name: https
            containerPort: 443

---
# Minimal ConfigMap for NGINX configuration (can be empty initially)
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configuration

---
# Service exposing the Ingress controller externally (NodePort in this example)
apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress
spec:
  type: NodePort
  selector:
    name: nginx-ingress
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP

---
# ServiceAccount for the Ingress controller (RBAC roles/rolebindings not shown here)
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount

​

Ingress resources: rules and examples

1. Default backend — route all traffic to a single Service.
2. Path-based routing — same host, route different URL paths to different Services.
3. Host-based routing — route by host header (subdomains) to different Services.

​

Example 1 — Default backend

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wear
spec:
  defaultBackend:
    service:
      name: wear-service
      port:
        number: 80

kubectl create -f ingress-wear.yaml
kubectl get ingress
# Example output:
# NAME           CLASS   HOSTS   ADDRESS   PORTS   AGE
# ingress-wear           *       <none>    80     2s

​

Example 2 — Path-based routing

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wear-watch
spec:
  rules:
  - http:
      paths:
      - path: /wear
        pathType: Prefix
        backend:
          service:
            name: wear-service
            port:
              number: 80
      - path: /watch
        pathType: Prefix
        backend:
          service:
            name: watch-service
            port:
              number: 80

kubectl describe ingress ingress-wear-watch
# Example excerpt:
# Name:             ingress-wear-watch
# Namespace:        default
# Address:
# Default backend:  <default>
# Rules:
#   Host  Path    Backends
#   ----  ----    --------
#   *     /wear   wear-service:80
#         /watch  watch-service:80
# Annotations:
# Events:
#   Normal  CREATE  14s   nginx-ingress-controller   Ingress default/ingress-wear-watch created

​

Example 3 — Host-based routing

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wear-watch
spec:
  rules:
  - host: wear.my-online-store.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wear-service
            port:
              number: 80
  - host: watch.my-online-store.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: watch-service
            port:
              number: 80

​

Comparison: routing approaches

​

TLS / HTTPS with Ingress

• Ingress supports TLS termination. Create a Kubernetes Secret of type kubernetes.io/tls containing your certificate and private key, then reference that secret in the Ingress tls section.
• TLS can be applied per-host (recommended) or globally, depending on the controller’s capability.
• Use certificate automation tools like cert-manager to obtain and renew certificates from Let’s Encrypt automatically.

tls:
- hosts:
  - wear.my-online-store.com
  secretName: wear-tls-secret

​

Best practices and notes

• Deploy a single Ingress controller (or a controller per team/namespace if needed) and expose it externally once (LoadBalancer or NodePort). Then manage routing via Ingress resources.
• Keep certificate secrets secure (RBAC and namespace scoping).
• Use pathType Prefix or Exact depending on desired behavior. Check controller docs for regex or advanced matching options.
• Test Ingress behavior with kubectl describe ingress and controller logs when troubleshooting.

​

Summary

• Ingress is the Kubernetes-native way to provide HTTP/HTTPS routing and TLS termination at Layer 7.
• You must deploy an Ingress controller (NGINX, Traefik, cloud controller, etc.) to implement Ingress resources.
• Choose default, path-based, or host-based routing based on your application topology.
• Expose the controller externally once, then add routes and TLS via Kubernetes manifests.

​

Practice labs

• Lab type 1: Ingress controller, Ingress resources, and apps are pre-deployed. Explore the cluster, inspect resources, and answer scenario-driven questions.
• Lab type 2: Deploy an Ingress controller and create Ingress resources from scratch; configure TLS and test routing.

​

Links and references

• Kubernetes Ingress documentation: https://kubernetes.io/docs/concepts/services-networking/ingress/
• cert-manager: https://cert-manager.io/
• Let’s Encrypt: https://letsencrypt.org/
• NGINX Ingress controller: https://kubernetes.github.io/ingress-nginx/
• Istio (service mesh): https://istio.io/