In Kubernetes, Services provide a stable network endpoint for accessing Pods. While Services within the same namespace can be accessed using their name, accessing a Service in another namespace requires a specific approach. This article explains how to access a Service located in a different namespace, focusing on the use of fully qualified domain names (FQDNs) and best practices.
TL;DR
To access a Service in another namespace in Kubernetes:
- Use the Service’s fully qualified domain name (FQDN):
<service-name>.<namespace>.svc.cluster.local - Alternatively, access the Service using its ClusterIP obtained via:
kubectl get service <service-name> -n <namespace>
Use tools like ExternalName or NetworkPolicy for advanced configurations.
Understanding Kubernetes Namespaces and Service DNS
Namespaces in Kubernetes are virtual clusters that provide isolation for resources such as Pods and Services. Each namespace maintains its own unique set of names, allowing multiple resources with the same name to exist in different namespaces.
Kubernetes uses DNS to provide Service discovery. By default, Services are resolvable within their namespace. To access a Service in another namespace, a fully qualified domain name (FQDN) or the Service’s ClusterIP can be used.
Accessing a Service Using Fully Qualified Domain Names (FQDN)
Kubernetes automatically configures DNS records for Services, enabling them to be accessed by their FQDN.
FQDN Format:
<service-name>.<namespace>.svc.cluster.local <service-name>: Name of the Service.<namespace>: Namespace where the Service is located.svc.cluster.local: Default DNS suffix for the cluster.
Example
Consider a Service named example-service in the namespace dev. To access this Service from another namespace, use its FQDN:
example-service.dev.svc.cluster.local A Pod in a different namespace can resolve the Service using:
curl http://example-service.dev.svc.cluster.local Accessing a Service Using the ClusterIP
Every Kubernetes Service has a ClusterIP, a virtual IP accessible only within the cluster. To access a Service via its ClusterIP:
kubectl get service example-service -n dev Output:
NAME TYPE CLUSTER-IP PORT(S)
example-service ClusterIP 10.96.0.1 80/TCP Use the ClusterIP to access the Service:
curl http://10.96.0.1Note: Using ClusterIP is practical for testing or when DNS resolution is not available.
Cross-Namespace Access Configuration
Option 1: Using a NetworkPolicy
To allow cross-namespace communication, a NetworkPolicy may need to be configured, depending on the cluster’s networking setup.
Example:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-access
namespace: dev
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
name: testThis policy allows Pods in the test namespace to access any Pod in the dev namespace.
Option 2: Exporting the Service Using ExternalName
The ExternalName type allows a Service in one namespace to act as an alias for a Service in another namespace.
Example:
apiVersion: v1
kind: Service
metadata:
name: example-service-alias
namespace: test
spec:
type: ExternalName
externalName: example-service.dev.svc.cluster.localPods in the test namespace can now access the example-service in the dev namespace using the alias:
curl http://example-service-aliasBest Practices for Cross-Namespace Service Access
- Use FQDNs for Clarity: FQDNs ensure unambiguous Service resolution across namespaces.
- Limit Access with NetworkPolicies: Restrict cross-namespace access to necessary workloads for security.
- Leverage ExternalName for Simplification: Use
ExternalNameto provide a simple alias for Services accessed frequently across namespaces. - Verify Access Permissions: Ensure role-based access control (RBAC) policies allow the required actions.
Summary
Accessing a Service in another namespace in Kubernetes can be achieved using FQDNs, ClusterIP, or the ExternalName Service type. By leveraging Kubernetes DNS and network policies, administrators can facilitate cross-namespace communication securely and effectively. Understanding these techniques ensures reliable Service discovery and access across namespaces.
References
- Kubernetes Official Documentation: Service
- Kubernetes Official Documentation: DNS for Services and Pods
- Kubernetes Official Documentation: NetworkPolicy
