Kubernetes and DLNA
These are some notes taken while deploying a Digital Living Network Alliance (DLNA) to Kubernetes. DLNA is derived from Universal Plug and Play (UPnP) specifically for media interoperability. DLNA services are advertised and discovered via Simple Service Discovery Protocol (SSDP).
Take the follow DLNA interaction:
Let’s have a look at a captured interaction with
sudo tshark -i eno1 -f "udp port 1900" Capturing on 'eno1' ... 12 10.641536725 192.168.0.85 → 188.8.131.52 SSDP 169 M-SEARCH * HTTP/1.1 13 10.643129842 192.168.0.211 → 192.168.0.85 SSDP 404 HTTP/1.1 200 OK
We can see the SSDP port in our DLNA Deployment Kubernetes manifest.
ports: - containerPort: 1900 hostPort: 1900 protocol: UDP
If we run
-T pdml to examine the contents of the interaction the server - we will see an advertised http endpoint.
You also discover the advertised endpoints with
nmap sU -p 1900 --script=upnp-info 192.168.0.0/24 Starting Nmap 7.80 ( https://nmap.org ) at 2021-06-03 13:11 UTC Nmap scan report for mymodem.modem (192.168.0.1) Host is up (0.0045s latency). PORT STATE SERVICE 1900/udp open upnp | upnp-info: | 192.168.0.1 | Server: Homeware UPnP/1.1 |_ Location: http://192.168.0.1:5000/rootDesc.xml MAC Address: D4:35:1D:14:F3:FE (Technicolor)
The endpoint enables programmatic interaction between client and server. This coincides with another port exposed in our manifest.
ports: - containerPort: 8200 hostPort: 8200 protocol: TCP
Enabling the SSDP interaction on Kubernetes required the DLNA server pod to be run with
Otherwise, you can expect the following issues.
- Pod network SSDP advertisement traffic may not reach the host network. This often enforced via node IP tables.
- Host network SSDP discovery traffic may not reach the pod network. This may be Container Network Interface (CNI) dependent.
- The advertise internal pod IP endpoint address may not reachable from the host network.
To avoid node port conflicts the deployment spec will needs to use a
replicas: 1 strategy: type: Recreate