Here’s a comprehensive, practical, and easy-to-follow tutorial on all main types of Kubernetes Ingress rules—with detailed explanations, diagrams, and YAML examples for each. This guide is aimed at both beginners and advanced users and covers every core ingress rule type you’ll encounter, including real-world use cases.

🚀 Kubernetes Ingress Rules: Complete Guide with Examples

Table of Contents

1. What is Kubernetes Ingress?
2. Types of Ingress Rules
   • Host-based Routing
   • Path-based Routing
   • Combined Host & Path Routing
   • Default Backend (Catch-all)
   • TLS/SSL Rules
   • Advanced (Rewrite/Redirect, Auth, Rate Limiting)
3. Examples and Use Cases
4. Visual Summary
5. FAQ & Tips

1. What is Kubernetes Ingress?

• Ingress is a Kubernetes resource that manages external access to your cluster services, typically HTTP/HTTPS.
• With Ingress, you can expose multiple apps under different domains/paths using a single load balancer or IP.
• An Ingress Controller (like NGINX, AWS ALB, Traefik, etc.) implements the routing specified in your Ingress resource.

2. Types of Ingress Rules

A. Host-based Routing (Name-based Routing)

What it is:
Route traffic to different services based on the requested domain name (host).

Use Case:
You have multiple apps, each with its own subdomain or domain (e.g., app1.example.com, app2.example.com).

Example YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-based-ingress
spec:
  rules:
    - host: app1.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app1
                port:
                  number: 80
    - host: app2.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app2
                port:
                  number: 80

Diagram:

(app1.example.com) --> [Ingress] --> [app1 Service]
(app2.example.com) --> [Ingress] --> [app2 Service]
Code language: CSS (css)

B. Path-based Routing (URL Path Routing)

What it is:
Route traffic to different services based on the URL path.

Use Case:
Expose multiple apps under different paths of the same domain (e.g., /api, /shop).

Example YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-based-ingress
spec:
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /shop
            pathType: Prefix
            backend:
              service:
                name: shop-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Diagram:

(www.example.com/api)  --> [Ingress] --> [api-service]
(www.example.com/shop) --> [Ingress] --> [shop-service]
(www.example.com/)     --> [Ingress] --> [web-service]

C. Combined Host and Path-based Routing

What it is:
Use both host and path to route traffic for fine-grained control.

Use Case:
Same domain serves different apps under different paths, and you have more than one domain.

Example YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: combined-ingress
spec:
  rules:
    - host: admin.example.com
      http:
        paths:
          - path: /dashboard
            pathType: Prefix
            backend:
              service:
                name: admin-dashboard
                port:
                  number: 80
    - host: shop.example.com
      http:
        paths:
          - path: /cart
            pathType: Prefix
            backend:
              service:
                name: cart-service
                port:
                  number: 80

Diagram:

(admin.example.com/dashboard) --> [Ingress] --> [admin-dashboard]
(shop.example.com/cart)       --> [Ingress] --> [cart-service]

D. Default Backend (Catch-all Rule)

What it is:
A default backend serves any request that doesn’t match the host/path rules above (often a 404 or static site).

Use Case:
Handle “not found” errors or serve a default landing page.

How to set:

• For NGINX, add a path: / rule without host or at the bottom.
• For AWS ALB Ingress, define a backend with path / and no host, or use a dedicated default backend controller.

Example YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: default-backend-ingress
spec:
  defaultBackend:
    service:
      name: default-backend
      port:
        number: 80
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80
Code language: PHP (php)

Diagram:

(Any unmatched domain/path) --> [Ingress] --> [default-backend]
Code language: JavaScript (javascript)

Note: The exact method depends on your Ingress controller version.

E. TLS/SSL Rules

What it is:
Specify which hosts should use HTTPS and which certificate to use for encryption.

Use Case:
Serve your app securely over HTTPS.

NGINX Example:

spec:
  tls:
    - hosts:
        - www.example.com
      secretName: my-tls-secret
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

• my-tls-secret is a Kubernetes TLS secret with your certificate and private key.

AWS ALB Example:

metadata:
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:REGION:ACCOUNT:certificate/XXXX

• The annotation links your ACM certificate to the ALB for HTTPS.

Diagram:

(Browser --HTTPS--> ALB) --HTTP--> [Service]
Code language: CSS (css)

F. Advanced Rules

1. Rewrite/Redirect Rules

• Modify the URL path before passing to backend, or redirect to another location.
• Often set using annotations (varies by controller).

2. Authentication Rules

• Protect paths with Basic Auth, OAuth2, or custom headers.
• Usually via annotations or external Auth service.

3. Rate Limiting / WAF

• Control request rates or apply security policies.
• Usually via annotations/integration with external tools.

3. Examples and Use Cases Table

4. Visual Summary

        +-------------------------+
        |  Ingress Controller     |
        +-------------------------+
         |           |           |
     Host1      Host2+Path     Default
      |             |             |
  [ServiceA]   [ServiceB]    [Default Svc]
Code language: PHP (php)

5. FAQ & Tips

Q: Can I use all rule types in one Ingress?
A: Yes! You can combine host, path, TLS, and advanced rules as needed.

Q: What about gRPC?
A: Use the right annotation (e.g., alb.ingress.kubernetes.io/backend-protocol-version: GRPC for AWS) and make sure your ingress controller supports gRPC routing.

Q: What happens if rules overlap?
A: The most specific rule (exact match > prefix match > default) wins.

Q: Can I redirect HTTP to HTTPS?
A: Yes, with annotations or controller config. For ALB, use alb.ingress.kubernetes.io/ssl-redirect: '443'.

6. Full Example: Real-World Multi-rule Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: complex-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-northeast-1:123456789012:certificate/abcd1234
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/backend-protocol-version: GRPC
spec:
  tls:
    - hosts:
        - www.example.com
      secretName: my-tls-secret         # For NGINX/Traefik; ignored by ALB
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /shop
            pathType: Prefix
            backend:
              service:
                name: shop-service
                port:
                  number: 80
    - host: admin.example.com
      http:
        paths:
          - path: /dashboard
            pathType: Prefix
            backend:
              service:
                name: admin-dashboard
                port:
                  number: 80
    # Default backend or more hosts/paths as needed

Conclusion

• Host-based: Route by domain.
• Path-based: Route by URL path.
• Combined: Mix host/path for precise routing.
• Default backend: Catch all requests not matched.
• TLS: Secure HTTPS by mapping domain(s) to certificate(s).
• Advanced: Use controller features for rewrites, redirects, auth, WAF, etc.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.