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.