Communicating between namespaces - Mon, Dec 7, 2020

How to communicate from one namespace to another in kubernetes

Communicating between namespaces in Kubernetes

Recently while setting up a ci pipeline using Tekton for a Kafka streaming application I came across the issue hwo to communicate between two namespaces in kubernetes which I describe in this post.

The service in the target namespace

The service to access in the target namespace was the bootstrap brokers for a demo cluster my-cluster which was deployed in the namespace kafka:

$ kubectl get service -n kafka my-cluster-kafka-bootstrap -o yaml
apiVersion: v1
kind: Service
metadata:
  name: my-cluster-kafka-bootstrap
  namespace: kafka
  ownerReferences:
  uid: 7628383a-d59b-45fa-9fb4-9fd0340dec06
spec:
  clusterIP: 10.96.63.139
  ports:
  - name: tcp-replication
    port: 9091
    protocol: TCP
    targetPort: 9091
  - name: tcp-clients
    port: 9092
    protocol: TCP
    targetPort: 9092
  - name: tcp-clientstls
    port: 9093
    protocol: TCP
    targetPort: 9093
  selector:
    strimzi.io/cluster: my-cluster
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka
  sessionAffinity: None
  type: ClusterIP

The service in the source namespace

The source of the communication was the namespace ci in which the Tekton pipeline for provisioning the cluster wit the appropriate topology is defined. The pipeline is described in detail here .
For accessing a different namespace, a service without a selector and of type ExternalName with the dns name of the target service needs to be defined as described here . Traffic will be routed to its single endpoint. The manifest for the service in the namespace ci looks like this:

1  kind: Service
2  apiVersion: v1
3  metadata:
4    name: kafka-bootstrap
5    namespace: ci
6  spec:
7    type: ExternalName
8    externalName: my-cluster-kafka-bootstrap.kafka.svc.cluster.local
9    ports:
10    - port: 9092

Note the fqdn in line 8 which points to the service my-cluster-kafka-bootstrap in the namepsace kafka. Now any Pod from namespace ci can access the bootsrap broker using the dns name kafka-bootstrap.

Testing

In order to test teh connectivity I ran a Pod instance of the image network-multitool which contains useful networking tools like nmap :

$ kubectl run --rm network-multitool -n ci --image=praqma/network-multitool
$ kubectl exec -ti -n ci network-multitool -- bash

# nmap kafka-bootstrap -p 9092 -Pn -v
Starting Nmap 7.80 ( https://nmap.org ) at 2020-12-07 07:19 UTC
Initiating Parallel DNS resolution of 1 host. at 07:19
Completed Parallel DNS resolution of 1 host. at 07:19, 0.00s elapsed
Initiating SYN Stealth Scan at 07:19
Scanning kafka-bootstrap (10.96.63.139) [1 port]
Discovered open port 9092/tcp on 10.96.63.139
Completed SYN Stealth Scan at 07:19, 0.02s elapsed (1 total ports)
Nmap scan report for kafka-bootstrap (10.96.63.139)
Host is up (0.000057s latency).
rDNS record for 10.96.63.139: my-cluster-kafka-bootstrap.kafka.svc.cluster.local

PORT     STATE SERVICE
9092/tcp open  XmlIpcRegSvc

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
           Raw packets sent: 1 (44B) | Rcvd: 1 (44B)

Note the line 9092/tcp open XmlIpcRegSvc which indicates that the port is open.

Conclusion

Services with no selector of type External can be used to communicate with services in different namespaces. They can also be used to communicate with services outside of the cluster (e.g. a database) that reside on premise for example.

Back to Home