Cross-Namespace Ingress Configuration in Kubernetes: Core Principles and Practical Implementation

Core Concepts of Kubernetes Ingress Architecture

Within the Kubernetes ecosystem, Ingress serves as a critical component for managing cluster entry traffic, following a clear principle of separation of concerns. Understanding this architecture is essential for resolving cross-namespace configuration challenges. The Ingress system comprises two main components: the Ingress controller and Ingress rules.

Relationship Between Ingress Controller and Ingress Rules

The Ingress controller, typically deployed as a DaemonSet or Deployment, monitors changes to Ingress resources across the cluster and configures underlying proxy servers (such as NGINX) based on these rules. Controllers can be deployed in any namespace, with common practice placing them in dedicated namespaces like ingress-nginx or kube-system. Controllers possess cluster-wide visibility, enabling them to discover Ingress resources in all namespaces.

Conversely, Ingress rules must reside in the same namespace as the backend services they reference. This is an inherent constraint of Kubernetes' networking model: when an Ingress controller parses an Ingress resource, it searches for the specified Service within the current namespace. If the Service exists in a different namespace, the controller cannot establish proper endpoint mappings, resulting in "service was not found" errors.

Problem Diagnosis: Root Cause of Cross-Namespace Configuration Failure

Based on the provided configuration example, the issue stems from the Ingress resource app-ingress being deployed in the ingress-nginx namespace while referencing Service api-sand located in the resources namespace. When the Ingress controller attempts to parse this rule, it searches for the api-sand service only within the ingress-nginx namespace, naturally failing to locate corresponding endpoints.

The error message error obtaining service endpoints: error getting service resources/api-sand from the cache: service resources/api-sand was not found clearly indicates this namespace mismatch. Deploying the service to the same namespace resolves the issue, validating the necessity of namespace alignment.

Solution One: Standard Namespace Alignment Method

The most straightforward and recommended approach is to keep Ingress rules in the same namespace as their backend services. For the example scenario, move app-ingress.yaml to the resources namespace:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: resources
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
      - api-sand.fake.com
  rules:
  - host: api-sand.fake.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-sand
            port:
              number: 80

This configuration ensures the Ingress controller correctly discovers the api-sand service and its associated Pod endpoints within the resources namespace. The controller deployment can remain in the ingress-nginx namespace, as it retains the ability to read Ingress resources across namespaces.

Solution Two: Cross-Namespace Approach Using ExternalName Services

When architectural requirements demand strict separation between Ingress configuration and application deployment, indirect referencing via ExternalName services provides an alternative. This method creates an ExternalName service in the Ingress rule's namespace that points to the actual service:

# Create ExternalName service in ingress-nginx namespace
apiVersion: v1
kind: Service
metadata:
  name: api-sand-proxy
  namespace: ingress-nginx
spec:
  type: ExternalName
  externalName: api-sand.resources.svc.cluster.local
  ports:
  - port: 80
    targetPort: 80

Subsequently modify the Ingress rule to reference this proxy service instead of the original:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: ingress-nginx
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: api-sand.fake.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-sand-proxy
            port:
              number: 80

An ExternalName service essentially functions as a DNS CNAME record, resolving api-sand-proxy.ingress-nginx.svc.cluster.local to api-sand.resources.svc.cluster.local. When traffic reaches the Ingress controller, it routes correctly through this proxy service to the actual service in the target namespace.

Configuration Practices and Considerations

When deploying in Azure Kubernetes Service environments, ensure proper configuration of LoadBalancer services. The example's ingress-nginx service uses type: LoadBalancer and externalTrafficPolicy: Local, which helps preserve client source IP addresses and optimize traffic routing.

Key configuration parameters include:

• Health check configuration: Ensure appropriate livenessProbe and readinessProbe settings, such as path: /healthz with suitable timeouts
• Resource limits: Set reasonable CPU and memory limits for controller containers to prevent resource contention
• Annotation usage: Correctly configure kubernetes.io/ingress.class to specify controller type

Architectural Decision Recommendations

When selecting a cross-namespace Ingress configuration approach, consider these factors:

1. Maintenance complexity: The standard method is simpler and more intuitive, while the ExternalName approach adds an indirection layer
2. Network performance: ExternalName introduces additional DNS resolution, potentially adding slight latency
3. Security boundaries: Namespaces provide natural isolation; cross-namespace access requires consideration of RBAC policies
4. Team collaboration: In multi-team environments, namespace alignment may better align with separation of responsibilities

For most production scenarios, the standard namespace alignment method is recommended, unless specific architectural requirements demand strict separation between Ingress configuration and application deployment. Regardless of the chosen approach, establish clear documentation and automated deployment processes to ensure configuration consistency and maintainability.