teamspeak-server: Änderung von server.voicePort führt zu Sprachausfall bei grünem Rollout #13

New Issue

2026-09-16T16:03:26+02:00

jlab-bot commented

2026-09-16 16:03:26 +02:00

Migriert aus jk-cluster/helm-charts#216 — urspruenglich angelegt von jk-cluster-bot am 2026-08-30.

Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.

Wer server.voicePort an einer laufenden Installation ändert, bekommt einen vollständigen Sprachausfall bei grünem Rollout. Kubernetes meldet Erfolg, alle drei Probes bleiben grün, und niemand kommt mehr auf den Server.

Der Mechanismus

TSSERVER_DEFAULT_PORT wird vom TeamSpeak-Server nur beim Anlegen des virtuellen Servers gelesen. Startet er gegen ein bestehendes Datenverzeichnis neu, behält er seinen ursprünglichen Port — unabhängig davon, was in der Umgebung steht.

Der Chart zieht bei einer Änderung von server.voicePort aber drei Stellen mit: containerPort, den Service-Port und den nodePort. Danach zeigt die gesamte Kubernetes-Seite auf den neuen Port, während der Server weiterhin auf dem alten lauscht.

Und die Probes merken es nicht. Alle drei sind tcpSocket auf den Dateitransfer-Port — und der folgt seiner Variablen bei jedem Start. Der Sprachport, den die Nutzer tatsächlich brauchen, wird von keiner Probe berührt. Der Pod ist also 1/1 Ready, der Rollout grün, der Dienst tot.

Belegt

Gemessen vom Umsetzungs-Agenten für teamspeak-server bei #157/#43 (PR #193), indem er das Image teamspeaksystems/teamspeak6-server:6.0.0-beta12.1 direkt gestartet hat: mit TSSERVER_DEFAULT_PORT=31000 gegen ein bestehendes Volume lauschte der Server weiterhin auf 30987. Ebenfalls gemessen: die einzigen lauschenden Sockets sind UDP-Sprache und TCP-Dateitransfer — auf dem deklarierten web-query-Port 10080 bindet nichts.

Nicht von mir nachgestellt; die Portkonfiguration des Charts und die Probe-Definitionen sind aber im Repo nachlesbar.

Zu entscheiden

Der eigentliche Defekt ist nicht der Port, sondern dass kein Signal existiert, das den Ausfall bemerkt. Mögliche Richtungen, keine davon entschieden:

Eine Probe auf den Sprachport. Er ist UDP, was tcpSocket ausschließt; ein exec mit einem Statusabruf wäre der naheliegende Ersatz. Damit würde ein Portwechsel sofort rot statt still.
Änderungen des Ports laut abweisen, solange ein Datenvolumen existiert — im Chart schwer sauber zu erkennen, aber als Warnung in NOTES und values.yaml billig zu haben.
Mindestens dokumentieren: der Port ist für die Lebensdauer des Datenvolumens faktisch fest. Das steht seit PR #193 in der NOTES.txt; als alleinige Maßnahme ist es dünn, aber es ist der Stand.

Zusammenhang

Berührt #40 (Beta-Bump vor dem 01.10.2026) nur insofern, als beide denselben Chart betreffen. Der Lizenzablauf ist unabhängig davon und bleibt der dringendere Termin.

> Migriert aus [`jk-cluster/helm-charts#216`](https://github.com/jk-cluster/helm-charts/issues/216) — urspruenglich angelegt von **jk-cluster-bot** am 2026-08-30. > > Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar. --- Wer `server.voicePort` an einer laufenden Installation ändert, bekommt einen **vollständigen Sprachausfall bei grünem Rollout**. Kubernetes meldet Erfolg, alle drei Probes bleiben grün, und niemand kommt mehr auf den Server. ## Der Mechanismus `TSSERVER_DEFAULT_PORT` wird vom TeamSpeak-Server **nur beim Anlegen des virtuellen Servers** gelesen. Startet er gegen ein bestehendes Datenverzeichnis neu, behält er seinen ursprünglichen Port — unabhängig davon, was in der Umgebung steht. Der Chart zieht bei einer Änderung von `server.voicePort` aber **drei** Stellen mit: `containerPort`, den Service-Port und den `nodePort`. Danach zeigt die gesamte Kubernetes-Seite auf den neuen Port, während der Server weiterhin auf dem alten lauscht. **Und die Probes merken es nicht.** Alle drei sind `tcpSocket` auf den **Dateitransfer**-Port — und der folgt seiner Variablen bei jedem Start. Der Sprachport, den die Nutzer tatsächlich brauchen, wird von keiner Probe berührt. Der Pod ist also 1/1 Ready, der Rollout grün, der Dienst tot. ## Belegt Gemessen vom Umsetzungs-Agenten für `teamspeak-server` bei #157/#43 (PR #193), indem er das Image `teamspeaksystems/teamspeak6-server:6.0.0-beta12.1` direkt gestartet hat: mit `TSSERVER_DEFAULT_PORT=31000` gegen ein bestehendes Volume lauschte der Server weiterhin auf **30987**. Ebenfalls gemessen: die einzigen lauschenden Sockets sind UDP-Sprache und TCP-Dateitransfer — auf dem deklarierten `web-query`-Port 10080 bindet nichts. Nicht von mir nachgestellt; die Portkonfiguration des Charts und die Probe-Definitionen sind aber im Repo nachlesbar. ## Zu entscheiden Der eigentliche Defekt ist nicht der Port, sondern **dass kein Signal existiert, das den Ausfall bemerkt**. Mögliche Richtungen, keine davon entschieden: - **Eine Probe auf den Sprachport.** Er ist UDP, was `tcpSocket` ausschließt; ein `exec` mit einem Statusabruf wäre der naheliegende Ersatz. Damit würde ein Portwechsel sofort rot statt still. - **Änderungen des Ports laut abweisen**, solange ein Datenvolumen existiert — im Chart schwer sauber zu erkennen, aber als Warnung in NOTES und `values.yaml` billig zu haben. - **Mindestens dokumentieren**: der Port ist für die Lebensdauer des Datenvolumens faktisch fest. Das steht seit PR #193 in der `NOTES.txt`; als alleinige Maßnahme ist es dünn, aber es ist der Stand. ## Zusammenhang Berührt #40 (Beta-Bump vor dem 01.10.2026) nur insofern, als beide denselben Chart betreffen. Der Lizenzablauf ist unabhängig davon und bleibt der dringendere Termin.

jlab-bot referenced this issue

2026-09-16 16:04:27 +02:00

Repository, Workflows und Issues nach Gitea (JLab-Git) umziehen #14

jlab-bot commented

2026-10-04 21:26:34 +02:00

Nachgeprüft am 2026-10-04: unverändert offen — und der Chart widerspricht dem Issue inzwischen

Der Defekt steht: server.voicePort ist weiter 30987, server.fileTransferPort weiter 30033, und beide werden unverändert als containerPort, Service-Port und nodePort gesetzt.

Was dazugekommen ist und auffällt. teamspeak-server/values.yaml:12-17 sagt heute:

Each value is used as the container port, the service port and the NodePort, and is passed to the server via TSSERVER_DEFAULT_PORT / TSSERVER_FILE_TRANSFER_PORT so the server always listens on the exposed port (file transfer requires the in-container port to match the externally reachable port).

Der hervorgehobene Teil ist genau das, was die Messung in diesem Issue widerlegt: TSSERVER_DEFAULT_PORT wird nur beim Anlegen des virtuellen Servers gelesen. Startet der Server gegen ein bestehendes Datenverzeichnis, behält er seinen ursprünglichen Port, unabhängig von der Umgebung.

Für einen neuen Server stimmt der Satz, für eine laufende Installation nicht — und der Fall, um den es hier geht, ist der zweite. Der Kommentar ist damit selbst von der Gattung, die dieses Repository sonst erschlägt: eine Zusicherung, die stimmt, solange niemand sie braucht.

Wer das behebt, fasst beides an: das Verhalten und diesen Satz.

## Nachgeprüft am 2026-10-04: unverändert offen — und der Chart widerspricht dem Issue inzwischen Der Defekt steht: `server.voicePort` ist weiter `30987`, `server.fileTransferPort` weiter `30033`, und beide werden unverändert als containerPort, Service-Port und nodePort gesetzt. **Was dazugekommen ist und auffällt.** `teamspeak-server/values.yaml:12-17` sagt heute: > Each value is used as the container port, the service port and the NodePort, and is passed to the server via `TSSERVER_DEFAULT_PORT` / `TSSERVER_FILE_TRANSFER_PORT` **so the server always listens on the exposed port** (file transfer requires the in-container port to match the externally reachable port). Der hervorgehobene Teil ist genau das, was die Messung in diesem Issue **widerlegt**: `TSSERVER_DEFAULT_PORT` wird nur beim **Anlegen** des virtuellen Servers gelesen. Startet der Server gegen ein bestehendes Datenverzeichnis, behält er seinen ursprünglichen Port, unabhängig von der Umgebung. Für einen *neuen* Server stimmt der Satz, für eine *laufende* Installation nicht — und der Fall, um den es hier geht, ist der zweite. Der Kommentar ist damit selbst von der Gattung, die dieses Repository sonst erschlägt: eine Zusicherung, die stimmt, solange niemand sie braucht. Wer das behebt, fasst beides an: das Verhalten **und** diesen Satz.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#13