Kubernetes Ingress Configuration for Multiple Namespaces

Introduction
Step-by-Step Guide
Code Example
Additional Notes
Summary
Conclusion
References

Introduction

In Kubernetes, Ingress Controllers play a crucial role in routing external traffic to services within your cluster. While they can reside in any namespace, a common practice is to place them in a dedicated namespace for better organization. This article will demonstrate how to route traffic to services residing in different namespaces using a single Ingress resource.

Step-by-Step Guide

While an Ingress Controller can reside in any namespace, it's typically placed in a separate one from your applications, like ingress or kube-system. This separation enhances organization.

Let's say you want to route traffic to services in different namespaces using a single Ingress resource. You can achieve this by referencing the services directly in your Ingress definition.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /service1
        pathType: Prefix
        backend:
          service:
            name: service1
            namespace: namespace1
            port:
              number: 80
      - path: /service2
        pathType: Prefix
        backend:
          service:
            name: service2
            namespace: namespace2
            port:
              number: 80

In this example, requests to example.com/service1 are routed to service1 in namespace1, while requests to example.com/service2 go to service2 in namespace2.

This approach allows you to manage traffic for services in different namespaces from a central Ingress resource.

Code Example

This code deploys two simple web servers, one running Apache (httpd) and the other Nginx, each in a separate Kubernetes namespace. It then creates an Ingress resource that routes traffic to the appropriate service based on the URL path. Accessing http://example.com/service1 will reach the Apache server in namespace1, while http://example.com/service2 will reach the Nginx server in namespace2. This demonstrates how Ingress can manage traffic for services across different namespaces.

This code example demonstrates the article's concept by deploying two simple services, each in a different namespace, and then routing traffic to them using a single Ingress resource.

Prerequisites:

A Kubernetes cluster up and running.
Kubectl configured to interact with your cluster.

Steps:

Create the Namespaces:

kubectl create namespace namespace1
kubectl create namespace namespace2

Deploy the Services:

namespace1/service1.yaml:

apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: namespace1
spec:
  selector:
    app: service1
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: namespace1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: httpd
        ports:
        - containerPort: 8080

namespace2/service2.yaml:

apiVersion: v1
kind: Service
metadata:
  name: service2
  namespace: namespace2
spec:
  selector:
    app: service2
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service2
  namespace: namespace2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service2
  template:
    metadata:
      labels:
        app: service2
    spec:
      containers:
      - name: service2
        image: nginx
        ports:
        - containerPort: 8080

Deploy both services:

kubectl apply -f namespace1/service1.yaml
kubectl apply -f namespace2/service2.yaml

Create the Ingress Resource:

ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /service1
        pathType: Prefix
        backend:
          service:
            name: service1
            namespace: namespace1
            port:
              number: 80
      - path: /service2
        pathType: Prefix
        backend:
          service:
            name: service2
            namespace: namespace2
            port:
              number: 80

Deploy the Ingress:

kubectl apply -f ingress.yaml

Access the Services:

Note: You might need to configure your DNS or use /etc/hosts to map example.com to your Ingress controller's IP address.
- Accessing http://example.com/service1 should route you to service1 in namespace1.
- Accessing http://example.com/service2 should route you to service2 in namespace2.

This example demonstrates how a single Ingress resource can manage traffic for services residing in different namespaces, providing a centralized approach to traffic management in your Kubernetes cluster.

Additional Notes

Benefits of Namespace Separation for Ingress Controllers:

Organization: Keeps Ingress resources separate from application resources, improving readability and maintainability of configurations.
Security: Limits the blast radius of potential issues with the Ingress Controller. If it were to malfunction in the same namespace as your applications, it could potentially impact them.
Resource Isolation: Allows for better resource management and allocation, as the Ingress Controller's resource consumption won't directly compete with your applications.

Important Considerations:

DNS Configuration: Ensure your DNS server is properly configured to resolve the hostname (example.com in the example) to the IP address of your Ingress Controller.
Ingress Controller Type: The specific configuration and capabilities of Ingress resources can vary slightly depending on the Ingress Controller you are using (e.g., Nginx Ingress, Traefik, etc.). Refer to your Ingress Controller's documentation for specific details.
TLS/SSL Termination: For production environments, always configure TLS/SSL termination on your Ingress Controller to secure traffic between clients and your services.

Alternative Approaches:

Ingress Controller per Namespace: For larger deployments or when stricter isolation is required, you can deploy a dedicated Ingress Controller in each namespace. This provides maximum isolation but increases management overhead.
Service Mesh: Service meshes like Istio and Linkerd offer more advanced traffic management features, including cross-namespace routing, that can be an alternative to using Ingress for complex scenarios.

Troubleshooting:

Verify Service Selectors: Double-check that the selector labels in your Service definitions match the labels in your Deployment Pod templates.
Check Ingress Controller Logs: Examine the logs of your Ingress Controller for any errors or warnings that might indicate configuration issues.
Describe Resources: Use kubectl describe ingress, kubectl describe service, and kubectl describe deployment to get detailed information about your resources and their current status.

Summary

This article explains how Kubernetes Ingress resources can route traffic to services residing in different namespaces.

Key takeaways:

Ingress Controller Namespace: While Ingress Controllers can be placed in any namespace, it's recommended to use a dedicated namespace like ingress or kube-system for better organization.
Cross-Namespace Routing: A single Ingress resource can route traffic to services in different namespaces.
Service Referencing: The Ingress definition directly references the target service's name, namespace, and port.
Example: The provided YAML code demonstrates routing traffic for example.com/service1 to service1 in namespace1 and example.com/service2 to service2 in namespace2.
Centralized Traffic Management: This approach enables managing traffic for services across multiple namespaces using a single Ingress resource.

Conclusion

By leveraging Ingress resources and understanding cross-namespace communication, you can effectively manage external access to your services, ensuring a robust and scalable architecture for your applications. Remember to consider security best practices, such as TLS/SSL termination, and explore alternative approaches like service meshes for more complex traffic management needs. Properly configuring Ingress is fundamental to building well-structured and manageable Kubernetes deployments.

References

2 ways to route Ingress traffic across namespaces - Kubernetes ... | The tech industry is full of workarounds, and you probably rely on one or more. There is no problem with that per se, but it...
Using Single Load Balancer across multiple namespaces in ... | How to use single load balancer across all namespaces in kubernetes
Ingress to services in different namespaces : r/kubernetes | Posted by u/win2nat - 3 votes and 2 comments
Cross namespaces IngressRoutes and Services - Traefik v2 - Traefik ... | I face a security issue with Traefik 2.2.8. From an IngressRoute in one namespace, I can access a service in another namespace. All details are written in issue #7151. Is this a real issue and the bot did not classify it correctly? Or did I make a mistake in my configuration, as suggested by the bot? Thanks.
Cross-namespace configuration | NGINX Ingress Controller | This topic explains how to spread Ingress configuration across different namespaces in F5 NGINX Ingress Controller.
Ingress | Kubernetes | Make your HTTP (or HTTPS) network service available using a protocol-aware configuration mechanism, that understands web concepts like URIs, hostnames, paths, and more. The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API.
How to use the same wildcard TLS certificate in multiple ... | I have one wildcard TLS certificate, and in order to use it in different namespaces, I have created multiple Secrets containing the same TLS certificate. I have multiple IngressRoutes in different namespaces for hosts such as traefik.mydomain.com, linkerd.mydomain.com. I am being flooded by following warnings: Skipping addition of certificate for domain(s) "*.mydomain.com,mydomain.com", to EntryPoint default, as it already exists for this Entrypoint." First of all, creating multiple Secrets ...
How to manage incoming traffic for multiple instances of the same ... | How can I use an Ingress Controller in K8S to manage traffic for multiple instances of the same application with isolated namespaces and unique subdomains for each instance? I need each instance to have two services (backend and frontend) accessible via their respective subdomains. However, the Ingress Controller cannot access other namespaces, creating an issue in managing traffic. I’ve considered placing the Ingress Controller in the kube-system namespace, but I’m not sure if this is a good pr...
Unable to get multiple traefik running in the same Kubernetes ... | Hi, I'm trying to get multiple traefik in different namespaces on Kubernetes, but it seems that allowCrossNamespace=false to isolate them does not work. Is there any recipe that can help us on setting up multiple traefik on the same cluster and completely isolated from each other ? The issue we're having is the different treafik talking to services in other namespaces. Thanks