VDR In kubernetes cluster

  • Hallo,


    ich hätt da mal ein kleines Problem:


    Bin gerade dabei mein seit jahren zuverlässig laufenden VDR (bisher x64 kvm mit OctopusNet SATIP) mal komplett mit "neumodischen Zeugs" zu machen. Ist eher ein Spiel-/Lernprojekt denn wirklich notwendig.


    Was ich bisher gemacht habe: -

    - Kubernetes Cluster auf 3 Raspi-4 (8GB) Nodes mit Ubuntu 20.04 als Host OS und microk8s (mit Kubernetes 1.19) aufgesetzt. Funktioniert soweit schon mal ganz gut für andere Dinge. Ich verwende "metallb" um die Services "nach aussen" also in mein lokales Netz zu mappen.

    - Eigenes Docker Image für vdr erzeugt (custom build aus den Repositories für vdr und den paar wenigen Plugins die ich brauche - satip, streamdev-server, epgsearch, vdrmanager, live, vnsiserver, svdrposd, dummydevice). Alles wird auf dem Raspie compiliert. Ist allerdings noch Work in Progress, weil das erzeugte Image noch etwas kleiner werden soll. Base OS im Docker-Image ist auch wieder Ubuntu 20.04.

    - helm chart geschrieben, welches das Deployment in den Kubernetes Cluster macht (hier werden das /video Verzeichnis und das config Directory für den VDR via NFS gemountet damit die Daten persistent sind.)


    Wenn alles läuft sehe ich:



    Code ist bisher noch nicht veröffentlicht, weil das ja alles noch sehr roh mit vielen lokalen Eiegenheiten durchsetzt ist.


    2. Probleme die ich bisher noch nicht lösen konnte:


    1. Wenn ich den vdr im Container als root user starte und dann mit "-u vdr" den User vdr als echten Benutzer verwenden will, dann bekomme ich beim Start:


    Code
    1. vdr: cap_set_proc failed: Operation not permitted
    2. vdr: OS does not support cap_sys_time


    Geht also erst mal nicht. Wenn ich den vdr direkt unter dem User "vdr" starte (also: "su -c /opt/vdr/bin/vdr vdr") startet der vdr.

    Allerdings bekomme ich dann Fehlermeldungen im log:

    Code
    1. 2020-09-22T11:53:39.836187+02:00 vdr-5c8477d77f-xlm44 vdr: [57] SATIP poller thread started (pid=54, tid=57, prio=high)
    2. 2020-09-22T11:53:39.838676+02:00 vdr-5c8477d77f-xlm44 vdr: [57] ERROR (thread.c,258): Permission denied


    Ist das kritisch? Und ist ggf. mein 2. Problem eine Folge davon? Was würde man erwarten das alles nicht geht wenn man den vdr Prozess direkt als nicht privilegierten Benutzer startet?


    2. SATIP funktioniert nur sporadisch und meldet Fehler:


    Damit ich das satip plugin überhaupt - zumindest rudimentär - zum laufen bekommen habe, habe ich folgendes gemacht:

    Code
    1. [satip]
    2. -d3
    3. -s 192.168.62.32|DVBS2-4|OctopusNet|
    4. -p 31900-31907

    D.h. der SATIP Server ist ausserhalb des Netzes des Clusters in meinem lokalen Netz! Und dann in der Service Definition für Kubernetes:

    Code
    1. ports:
    2. - port: 31900
    3. targetPort: 31900
    4. nodePort: 31900
    5. protocol: UDP
    6. name: rtp-0
    7. (wiederholt für ports 31901-31907 ...)

    Und das dann korrespondierend im deployment.


    D.h. der Nodeport ist der gleiche wie der Containerport. Damit werden also die UDP Ports jeweils 1:1 gemapped und sind aus meinem Netz erreichbar unter der Adresse 192.168.63.1

    Code
    1. kubectl get svc
    2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
    3. vdr-tcp LoadBalancer 10.152.183.29 192.168.63.1 6419:31991/TCP,6420:31230/TCP,2004:30022/TCP,3000:30623/TCP,8008:30008/TCP,34890:31354/TCP 9m29s
    4. vdr-udp LoadBalancer 10.152.183.16 192.168.63.1 31900:31900/UDP,31901:31901/UDP,31902:31902/UDP,31903:31903/UDP,31904:31904/UDP,31905:31905/UDP,31906:31906/UDP,31907:31907/UDP 9m29


    Wenn ich alles neu starte, dann bekomme ich auch EPG daten (z.b. ersichtlich über das Live frontend welches über http://192.168.62.1:8008 zugänglich ist, (Mein lokales netz mit dem SATIP server (ist 192.168.62.0/23 und das Netz mit calico im cluster für die services ist dann 10.152.183.0/24). kube-proxy sollte das dann mappen.


    Sollte so ein Setup denn überhaupt funktionieren? Sprich vdr mit satip Plugin im Cluster mit IPs des Clusters und dann der SATIP-Server ausserhalb des Clusters in einem anderen Subnetz. Kube-proxy macht ja da sowas wie NAT wenn ich das richtig verstehe. Hat jemand so ein Setup bereits am laufen?


    Gruß Michael

  • 1. vdr: cap_set_proc failed: Operation not permitted
    2. vdr: OS does not support cap_sys_time

    Kommen die Meldungen wirklich in der Reihenfolge ? Das würde ich nicht verstehen.


    2. ist keine Fehlermeldung, sondern nur ein Hinweis, dass in deiner Umgebung nicht mal root die Systemzeit setzen darf. Das ist innerhalb eines Container normal. Da ich vdr auch im Container (lxc) laufen lasse und das auch nur mit root ging, habe ich mal eingebaut, dass das abgefangen wird.

    Siehe hier.


    Mit "sudo vdr -u vdr" startet der vdr als root und droppt dann auf vdr, will aber die Rechte cap_sys_nice, cap_sys_time und cap_net_raw (siehe vdr.c ab Zeile 127) behalten. In deiner Umgebung geht das Behalten von cap_sys_nice oder cap_net_raw zusätzlich schief.

  • Mal ein kleines Update:


    Also der VDR an sich läuft inzwischen prima im Kubernetes Cluster auf den Raspies. Das beschrieben Problem mit den capabilities habe ich durch "rauspatchen" für mich hier umgangen (gelöst würde ich nicht schreiben wollen).


    Also einfach so:


    Die einzige Baustelle mit der ich noch kämpfe ist SATIP. Ich benutze einen Octopus 4-Kanal SATIP Receiver mit aktueller Firmware (1.16). Wenn ich den direkt im SATIP Plugin konfiguriere (-s 192.168.62.32|DVBS2-4|OctopusNet|) bekomme ich zwar zumeist ein SIgnal, aber nicht immer und häufig "tuning timed out" Meldungen) Spätestens nach einem Tag ist das aber für alle Tuner tot. Nur noch Fehlermeldungen. Das erholt sich auch nicht von selbst und ich muß alles mögliche machen (den Octopus, und VDR neu Starten und machmal sogar anschliessend im VDR Satip Plugin den Transport auf TCP und dann wieder auf UDP zurück stellen) um wieder ein Signal zu bekommen. So ist das Ganze unbenutzbar.


    Nun habe ich Rahmen des debuggings (sprich: "ziellosem rumprobieren" ;-) ) mal ein minisatip "dazwischen" gehängt. Also der minisatip hat als Quellen die 4 Tuner des Octopus (wird also mit "minisatip -s 192.168.62.32 -s 192.168.62.32 -s 192.168.62.32 -s 192.168.62.32" gestartet.). Dabei läuft der minisatip auf einem System (Fedora 33) ausserhalb des Kubernetes clusters. Nun konfiguriere ich das SATIP Plugin im vdr mit "-s 192.168.62.10|DVBS2-4|minisatip|" Zu meiner großen Überraschung läuft das Ganze damit fast stabil (im Bereich "gut benutzbar"). Auch wenn es mal "Tuner timeouts" gibt "erholt" sich das dann wieder von selbst.


    Nun bin ich natürlich am grübeln warum die für mich fragiler aussehende Konfiguration (Traffic vom Octopus zum minisatip und dann von dort zum vdr) stabiler läuft wie der direkte weg. Irgenwelche Ideen dazu?


    Gruß Michael

  • Hallo,

    nochmals ein Update: Inzwischen habe ich auch das SATIP Plugin mit direkter Kommunikationm zum Octopus wieder am laufen. Der relevante Unterschied war hier ein Downgrade der Firmware Version 1.16 auf 1.15. Gibt es hier auch Erfahrungen mit Problemen bei der 1.16 Firmware version?


    DIe letzten offenen Themen sind nun nur noch dass ich relativ oft folgende Meldungen sehe:


    2020-12-04T09:29:29.692031+01:00 vdr-6d7d678f9-qtq5p vdr: [482] retrying


    D.h. der Channelwitch (für's EPG scanning - was anderes ist in dieser Zeit nicht passiert) scheint nicht auf Anhieb zu klappen und mehere Anläufe zu brauchen. Ideen dazu?


    Und dann sehe ich noch (zwar selten aber immerhin)
    2020-12-04T09:37:40.486680+01:00 vdr-6d7d678f9-qtq5p vdr: [485] SATIP: Detected 4 RTP packet errors [device 2]


    Netzwerk ist schon überprüft (unterschiedliche Switche und Kabel machten keinen Unterschied).


    Wenn ich das nun noch geläst bekomme, räume ich mal auf und mache das ganze öffentlich zugänglich.


    Gruß

    Michael