CKA — Ingress Resources

5 minute read

CKA Exam Domain

Services & Networking — 20%

Ingress resources are a core topic in the CKA exam. You’ll be asked to create Ingress rules that route traffic based on paths and hostnames. Know the YAML structure cold — there’s no time to look it up.

What Is an Ingress?

An Ingress is a Kubernetes resource that manages external HTTP and HTTPS access to Services inside your cluster. Think of it as a Layer 7 load balancer defined in YAML.

Without Ingress, you’d need a separate LoadBalancer Service for every application — expensive and messy. Ingress consolidates routing rules into a single entry point:

Client → Ingress Controller (single LB) → Ingress Rules → Services → Pods

Key characteristics:

  • Operates at Layer 7 (HTTP/HTTPS) — can route based on URL paths and hostnames
  • Requires an Ingress Controller to actually implement the rules (covered in the next lesson)
  • Supports TLS termination for HTTPS
  • Defined using the networking.k8s.io/v1 API

Ingress Spec

Here’s a complete, annotated Ingress resource with path-based routing to two backend Services:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx          # Which Ingress Controller handles this
  rules:
  - host: app.example.com          # Optional — match this hostname
    http:
      paths:
      - path: /api                 # Match requests to /api
        pathType: Prefix
        backend:
          service:
            name: api-svc          # Route to this Service
            port:
              number: 80
      - path: /                    # Match everything else
        pathType: Prefix
        backend:
          service:
            name: frontend-svc
            port:
              number: 80

Key fields to remember:

  • spec.ingressClassName — selects the Ingress Controller
  • spec.rules[].host — hostname to match (optional)
  • spec.rules[].http.paths[] — list of path rules
  • backend.service.name and backend.service.port.number — target Service

Path-Based Routing

Path-based routing sends traffic to different Services based on the URL path. This is the most common Ingress pattern.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-routing
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-svc
            port:
              number: 80

pathType Explained

The pathType field controls how the path is matched:

pathType Behavior Example: /api matches
Prefix Matches the URL path prefix split by / /api, /api/, /api/v1/users
Exact Matches the URL path exactly /api only (not /api/ or /api/v1)
ImplementationSpecific Matching depends on the IngressClass Varies by controller

Exam tip: Use Prefix unless the question specifically asks for exact matching. It’s the most common and flexible option.

Ordering matters

When multiple paths match, the longest matching path takes precedence. If two paths have the same length, Exact beats Prefix.

Host-Based Routing

Host-based routing sends traffic to different Services based on the Host header (i.e., the domain name).

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-routing
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-svc
            port:
              number: 80
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 8080

In this example:

  • Requests to app.example.com → app-svc
  • Requests to api.example.com → api-svc

You can combine host-based and path-based routing in a single Ingress resource.

Default Backend

When no rule matches an incoming request, the Ingress Controller sends traffic to the default backend. You can configure this explicitly:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: with-default-backend
spec:
  ingressClassName: nginx
  defaultBackend:
    service:
      name: fallback-svc
      port:
        number: 80
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

If no defaultBackend is specified, the Ingress Controller typically returns a 404 for unmatched requests.

IngressClass

An IngressClass tells Kubernetes which Ingress Controller should handle a given Ingress resource. This is important when you have multiple controllers installed.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-nginx

Reference it in your Ingress:

spec:
  ingressClassName: nginx

If an IngressClass is annotated as the default, any Ingress without an explicit ingressClassName will use it automatically.

kubectl Commands

These commands are essential for working with Ingress resources:

# List all Ingress resources
kubectl get ingress

# Get detailed info about a specific Ingress
kubectl describe ingress my-ingress

# List available IngressClasses
kubectl get ingressclass

# Create an Ingress from a YAML file
kubectl apply -f ingress.yaml

# Delete an Ingress
kubectl delete ingress my-ingress

Pro tip: Use kubectl describe ingress to check the Rules section and Backends — it shows whether your Services are correctly resolved and have active endpoints.

Practice Questions

Test your understanding. Try answering before revealing the solution.

Q1. Create an Ingress named shop-ingress in namespace default that routes /products to Service product-svc on port 80 and /cart to Service cart-svc on port 8080. Use pathType Prefix and IngressClass nginx.

Show Answer 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /products
        pathType: Prefix
        backend:
          service:
            name: product-svc
            port:
              number: 80
      - path: /cart
        pathType: Prefix
        backend:
          service:
            name: cart-svc
            port:
              number: 8080

Q2. What is the difference between pathType: Prefix and pathType: Exact?

Show Answer
  • Prefix matches the URL path prefix split by /. For example, /api matches /api, /api/, and /api/v1/users.
  • Exact matches the URL path exactly. /api only matches /api — not /api/ or /api/v1.

Use Prefix for most use cases. Use Exact when you need strict path matching.

Q3. Create a host-based Ingress that routes blog.example.com to blog-svc:80 and shop.example.com to shop-svc:8080.

Show Answer 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-host-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: blog.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: blog-svc
            port:
              number: 80
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: shop-svc
            port:
              number: 8080

Q4. What happens if you create an Ingress resource but no Ingress Controller is installed?

Show Answer

Nothing. The Ingress resource will be created and stored in etcd, but no routing will happen. The Ingress resource is just configuration — the Ingress Controller is the component that reads the rules and configures the actual load balancer. Without a controller, Ingress does nothing.

Q5. How do you set a default backend for unmatched requests?

Show Answer

Add the defaultBackend field under spec:

spec:
  defaultBackend:
    service:
      name: fallback-svc
      port:
        number: 80

Requests that don’t match any rule will be sent to fallback-svc. If no defaultBackend is configured, the controller typically returns a 404.

Updated:

You may also enjoy