freesailarr: im Gateway-Modus fehlt die Umleitung fuer den fehlenden Schraegstrich hinter /qbittorrent #118
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#118
Reference in new issue
Block a user
In
freesailarr3.2.0+up1.0.0 fehlt im Gateway-Modus die Regel, die den fehlenden Schrägstrich hinter/qbittorrentergänzt. Im Ingress-Modus leistet das einconfiguration-snippet; in der gerendertenHTTPRoutehat es keine Entsprechung.Gefunden am 12.10.2026 beim Umschwenken von
freesailarr.jk-dev.deauf die Gateway API (jlab-cluster/cluster-config#19). Der Host ist deshalb nicht migriert worden.Was gerendert wird
Das Praefix-Abschneiden ist damit sauber gelöst — und der Kommentar in den Werten beschreibt genau das zu Recht als besser als vorher, weil der Filter je Regel gilt und das zweite Ingress-Objekt entfällt.
Was fehlt
Eine Anfrage auf
/qbittorrentohne abschließenden Schrägstrich:PathPrefix /qbittorrent/umgeschrieben, qBittorrent liefert seine Anmeldeseite/qbittorrent— es gibt keine Umleitungcss/login.css→/css/login.css/-Regel und landet bei SeerrDas ist genau das Fehlerbild, das die Werte-Datei im
ingress-Block beschreibt — nur dass es dort durch das Snippet verhindert wird:Im Gateway-Modus gibt es dafür keinen Ersatz, und die Werte erwähnen die Lücke nicht. Der
ingress-Block warnt ausdrücklich, dass Annotationen im Gateway-Modus wegfallen — aber bei dieser einen ist der Wegfall nicht neutral, sondern eine Verhaltensänderung.Die Entsprechung gibt es, sie wird nur nicht gerendert
Ein
RequestRedirect-Filter an einer Regel mit Exact-Pfad leistet dasselbe und gewinnt nach den Vorrangregeln gegen beidePathPrefix-Regeln:Dasselbe gilt für jede andere App, die über
<app>.ingress.hostauf einen Unterpfad gelegt wird und keinen Basispfad kennt — die Regel ist nicht qBittorrent-spezifisch, sondern gehört zu „App ohne Basispfad auf einem Unterpfad".Zu prüfen wäre dabei, ob
301oder308richtig ist:308erhält die Methode. Für einen Aufruf der Oberfläche ist das gleichgültig, für eine API unter demselben Präfix nicht.Warum nicht im Cluster umgangen
Eine handgeschriebene
HTTPRoutemit dieser einen Regel neben dem Chart wäre möglich (der Namensraum steht in der Allowlist des Listeners, ein Geschwister-Bundle wäre frei). Dagegen spricht, dass der Chart im Ingress-Modus die Sache selbst löst: Die Asymmetrie gehört in den Chart, nicht in das Cluster-Repository — sonst steht dort ein Objekt, das beim nächsten Chart-Upgrade wieder weg muss.Nebenbefund zum Vergleich
proxy-body-sizefällt im Gateway-Modus ebenfalls weg, und das ist bei diesem Chart laut Werte-Datei für qBittorrents Torrent-Datei-Hochladungen der Kandidat. Das ist aber eine andere Art Lücke — eine Grenze, die verschwindet, nicht ein Verhalten, das kippt. Die Werte benennen sie ausdrücklich; die Schrägstrich-Regel nicht.Nachgeprüft, genehmigter Plan — und eine Korrektur an der Einordnung
Der Befund ist echt und reproduzierbar beschrieben. Eine tragende Annahme hält aber nicht, und sie ändert den Auftrag, deshalb zuerst die Korrektur.
Korrektur: der Ingress-Modus löst es nicht, es gibt dort kein Snippet
Ein solches Snippet existiert in diesem Chart nicht. Ein repo-weites
git grepüberorigin/mainnachconfiguration-snippet,return 30[18]und$uri =findet genau einen Treffer im ganzen Repository, und das ist ein auskommentiertes Beispiel inbentopdf/values.yaml:223. Wederfreesailarr/templates/freesailarr.ingress.yamlnochfreesailarr/values.yamlenthalten etwas davon. Die im Issue zitierte Zeilesteht nirgends im Chart.
Folglich leitet auch der Ingress-Modus nicht um, und zwar Schritt für Schritt aus demselben Grund:
{{ printf "%s(/|$)(.*)" $sharedQbt.path }}, also/qbittorrent(/|$)(.*), mitrewrite-target: /$2./qbittorrentgreift der$-Zweig der Alternation.$1und$2sind leer./. qBittorrent liefert seine Anmeldeseite mit 200 — es sieht/und hat keinen Grund umzuleiten./qbittorrent.css/login.csslöst gegen die Wurzel auf, trifft den/-Pfad des Hauptobjekts und landet bei Seerr.Das ist dasselbe Fehlerbild, dieselben fünf Schritte, derselbe falsche Zielort. Die Lücke ist also kein Verhaltenswechsel des Gateway-Modus, sondern ein Vorbestand in beiden Modi, den die Migration zum ersten Mal sichtbar gemacht hat.
Zwei Folgen, und die zweite ist der Grund, warum der Umfang wächst:
ingress.enabledist der Hauptschalter und steht auftrue. Der Chart würde eine bekannte stille Falle weiter ausliefern, und zwar in genau dem Modus, den heute alle Releases fahren.Davon unberührt: der Nebenbefund zu
proxy-body-sizeist richtig eingeordnet. Eine verschwindende Grenze ist eine andere Gattung als ein kippendes Verhalten, und sie ist in den Werten benannt.Was am Issue bestätigt ist, gegen die Spezifikation geprüft
Geprüft gegen
kubernetes-sigs/gateway-apiv1.6.3,apis/v1/httproute_types.go.Die Vorrangregel trägt. Die Rangfolge lautet dort wörtlich
* "Exact" path match.vor* "Prefix" path match with largest number of characters., und sie gilt unabhängig von der Listenposition — die Position entscheidet erst, wenn alle vorherigen Kriterien gleichstehen („If ties still exist within an HTTPRoute, matching precedence MUST be granted to the FIRST matching rule (in list order)"). Die vorgeschlageneExact-Regel gewinnt damit gegenPathPrefix /qbittorrentund gegenPathPrefix /, ohne dass die Reihenfolge im Template eine Zusage wäre, auf die sich jemand verlassen muss.Die 301/308-Frage ist entscheidbar, und nicht nach Geschmack: es wird 301. Die Spezifikation sagt
Support: statusCode 301 and 302 are Core; all others are Extended, und 308 trägt ein eigenes MerkmalHTTPRoute308RedirectStatusCode. Entscheidend ist, dass ein nicht unterstützter Wert nicht weich fällt:Verworfen wird damit die ganze Route, nicht die eine Regel — auf einer Implementierung ohne 308 wäre also auch das Routing der vier Nachbar-Apps weg. Gegen Entscheidung 1 von #114 (implementierungs-neutral, keine Bindung an eine Implementierung) ist das ausgeschlossen. Der Methodenerhalt, den 308 bietet, wird nicht gebraucht: die umgeleitete Anfrage ist der Aufruf der Oberfläche, und qBittorrents API liegt nicht auf dem präfixlosen Pfad, sondern unter
/qbittorrent/api/..., das von derPathPrefix-Regel bedient wird und dieExact-Regel nie trifft.Nebenbei, weil es leicht übersehen wird:
statusCodehat die Vorgabe 302 und muss ausdrücklich gesetzt werden.Der Umfang ist genau qBittorrent. Die Regel gehört, wie das Issue richtig sagt, zur Gattung „App ohne Basispfad auf einem Unterpfad" — diese Gattung hat in diesem Chart aber nur ein Mitglied.
seerrist vom Chart auf/festgenagelt und wird dort ausdrücklich verweigert,bazarrhat eine Base-URL-Einstellung und erwartet das Präfix. Die Regel wird deshalb an qBittorrent gebunden und nicht spekulativ verallgemeinert; dass sie eine Gattung bedient, gehört in den Kommentar, nicht in eine Schleife über Apps, die es nicht gibt.Plan
1. Gateway-Modus — die fehlende Regel. Eine zusätzliche Regel in der geteilten Route:
Der Pfad kommt aus
qbittorrent.ingress.path, nicht als Literal. Die Core/Extended-Begründung für 301 steht als Kommentar daneben, samt der Folge, die sie trägt (verworfen würde die ganze Route). Gilt auch im Fallqbittorrent.ingress.host, wo qBittorrent auf einem eigenen Host unter/liegt — dort ist weder Rewrite noch Umleitung nötig, und die Regel darf dann nicht rendern.2. Ingress-Modus — dieselbe Umleitung, ohne Snippet. Ein drittes Objekt mit
pathType: Exactauf/qbittorrentundnginx.ingress.kubernetes.io/permanent-redirect.Ausdrücklich kein
configuration-snippet:allow-snippet-annotationsist in ingress-nginx seit 1.9 standardmäßigfalse, ein Snippet bliebe dort also wirkungslos, und zwar still — womit die Behebung genau die Eigenschaft des Fehlers teilen würde, den sie behebt.Das setzt voraus, dass nginx'
location =(auspathType: Exact) Vorrang vor der Regex-Location des bestehenden qBittorrent-Objekts hat. Diese Annahme ist zu messen, nicht zu glauben. Hält sie nicht, wird die Falle stattdessen invalues.yamldokumentiert (Aufruf mit abschließendem Schrägstrich) und der Ingress-Zweig bleibt unverändert — halb behoben ist hier schlechter als offen benannt, weil ein drittes Objekt, das nichts tut, die nächste Diagnose kostet.3. Render-Zusicherung in
ci/run-httproute-match-test.sh. Rendert ein Chart eine Regel mitURLRewrite/ReplacePrefixMatchauf einem Präfix ungleich/, muss zum selben Präfix eineExact-Regel mitRequestRedirectexistieren. Das ist der Teil, der verhindert, dass die Lücke beim nächsten Chart mit Präfix-Rewrite wieder entsteht —bulwarkist in Gruppe 3 der zweiterewrite-target-Chart und läuft damit gegen dieselbe Prüfung.4. Wiki. Die
freesailarr-Seite, undLessons-Learned, weil die Lehre allgemein ist: ein Präfix-Rewrite ohne begleitende Umleitung erzeugt ein Fehlerbild, das wie ein Anwendungsfehler aussieht und auf den Nachbardienst zeigt. Dass der Fehler in beiden Modi steckte und erst bei der Migration auffiel, gehört dazu — die Ursache ist nicht die Gateway-API, sondern dass ein Rewrite ohne Umleitung unvollständig ist.5. Version: Major,
4.0.0+up1.0.0. Eine neue 301 ist nach den Konventionen dieses Repositories eine Laufzeit-Verhaltensänderung. Kein bestehendes funktionierendes Setup bricht, aber die Konvention knüpft an „runtime behaviour changed", nicht an „bricht jemandem etwas". Entsprechend wird hier kein leererhelm template-Diff gegenorigin/mainbehauptet: der Diff ist der Zweck der Änderung, und der PR zeigt ihn.Entschieden
Punkt 2 geht über die Frage des Issues hinaus, das nur den Gateway-Modus betrifft. Beides — der erweiterte Umfang und die Major-Veröffentlichung — ist vom Maintainer genehmigt, mit der Begründung aus der Korrektur oben: der Standardmodus darf die Falle nicht behalten.
Richtigstellung meiner „Korrektur" — der Issue-Rumpf hatte recht
Mein Kommentar davor behauptet, der Ingress-Modus leite nicht um und die Lücke sei ein Vorbestand in beiden Modi ohne Verhaltensänderung. Das ist falsch. Gemessen am laufenden System:
Der Ingress-Modus leitet heute um. Die im Issue-Rumpf beschriebene Verhaltensänderung bei der Migration ist echt.
Wo das Snippet herkommt
Beide Live-Ingress-Objekte im Namensraum
jellyfintragen die Annotation:Sie steht auf beiden Objekten — die Signatur des chart-globalen
ingress.annotations-Merges. Sie kommt also aus den Werten, die der Betreiber setzt, und die liegen injk-cluster-config(objectset.rio.cattle.io/id = default-jk-cluster-config-fleet-cd-jellyfin-freesailarr-c-2c5a3, Fleet-verwaltet). Und sie wirkt:kube-system/rke2-ingress-nginx-controllerhatallow-snippet-annotations: "true"beiannotations-risk-level: "Critical".Mein zweites Argument war damit ebenfalls falsch: dass ein Snippet wegen
allow-snippet-annotations: falseseit ingress-nginx 1.9 still wirkungslos bliebe, gilt für die Upstream-Vorgabe, nicht für diesen Cluster.Was an meinem Befund richtig war, und was daran der Fehler war
Richtig und verstärkt: der Chart hat dieses Snippet nie geliefert. Ein
git grepüberorigin/mainfindet es nicht, undgit log --all -Süber die ganze Historie vonfreesailarr/findet null Commits — es war nie drin.freesailarr/values.yamlbeschreibt das Fehlerbild auch an keiner Stelle.Der Fehler war der Schluss daraus: Ich habe den Chart durchsucht und daraus auf das Verhalten des Clusters geschlossen. Das Grep war korrekt, die Folgerung nicht. Was der Chart tut und was das laufende System tut, sind zwei Messungen; die zweite habe ich nicht gemacht, bevor ich die erste als Verhaltensaussage hingeschrieben habe.
Der Autor des Issue-Rumpfs hat das Verhalten richtig beschrieben und nur den Ort des Snippets verwechselt — Werte des Cluster-Repositories, nicht Chart. Die Zeile, die er zitiert, existiert wörtlich, inklusive des
$is_args$args, das im Zitat fehlte.Das vollständige Bild
Der Chart hat die Umleitung nie geleistet. Das laufende Release hat die Lücke mit einer von Hand gesetzten Annotation hoher Risikostufe in einem anderen Repository geschlossen. Dadurch sah der Chart korrekt aus und das System funktionierte — und die Gateway-Migration, die
ingress.annotationsfallen lässt, schien etwas zu brechen, das der Chart nie bereitgestellt hatte. Es ist beides: ein echter Regress bei der Migration und eine latente Chart-Lücke für jedes Release ohne dieses Snippet.Was sich am Plan ändert
Punkt 2 (Ingress-Modus mitbeheben) fällt — aber nicht wegen dieser Richtigstellung, sondern weil seine technische Voraussetzung widerlegt ist. Der vorab festgelegte Rückfall greift, und das aus einem härteren Grund als ich zugelassen hatte.
Gemessen an der Quelle des eingesetzten Controllers (
rancher/nginx-ingress-controller:v1.14.5-hardened2, upstreamcontroller-v1.14.5):template.go:531kehrt imenforceRegex-Zweig zurück, bevor Zeile 534 dieExact-Prüfung erreicht, undnginx.tmpl:987berechnet$enforceRegexeinmal jeserverüber alle Locations des Hostnamens. qBittorrents eigenes Objekt trägtrewrite-target, also istenforceRegexfür den ganzenserverwahr. Ein drittes Objekt mitpathType: Exactwürde deshalb alslocation ~* "^/qbittorrent"rendern — als Regex, nie alslocation =. Es verliert den Exact-Vorrang vollständig, ist am Ende nicht verankert und matcht damit alles unter dem Präfix; sortiert es vor das bestehende, legt es die ganze App in eine 301-Schleife. Also nicht „ein Objekt, das nichts tut", sondern eines, das schaden kann.Der Ingress-Zweig bleibt daher unverändert, und die Falle wird in
values.yamldokumentiert: samt dem Mittel (configuration-snippetüberingress.annotations), dessen Preis (wirkt nur auf einem Cluster, derallow-snippet-annotationseinschaltet und Risikostufe „Critical" in Kauf nimmt) und der Begründung, warum einExact-Objekt kein Ersatz ist.Version: Minor
3.3.0+up1.0.0statt Major4.0.0. Mit unverändertem Ingress-Zweig undhttpRoute.enabledstandardmäßigfalseändert sich der Render keines bestehenden Releases um ein Byte, und kein Wert wird verpflichtend — additiv mit unveränderten Vorgaben. Das Major war mit einer Laufzeitänderung im Standardmodus begründet, die nun nicht stattfindet.Das Snippet in
jk-cluster-configwird dadurch nicht redundant. Punkt 1 wirkt nur im Gateway-Modus, und dieser Host läuft im Ingress-Modus — dort ist das Snippet weiter das Einzige, was die Umleitung leistet. Es wird wirkungslos, wenn der Host migriert, weil danningress.annotationsohnehin wegfallen. Es ist also nichts abzuräumen, und dieser PR fasst das zweite Repository nicht an.Zusätzlich dokumentiert, weil die Spezifikation schweigt:
HTTPRequestRedirectFilterhat in Gateway API v1.6.3 genau die FelderScheme,Hostname,Path,Port,StatusCode— „query" kommt im ganzen Struct nicht vor, undReplaceFullPathersetzt ausdrücklich den Pfad. Ob der Query-String bei der Umleitung erhalten bleibt, ist damit implementierungsabhängig und vom Chart nicht zusagbar — eine benannte Asymmetrie zum Snippet, das ihn mit$is_args$argsausdrücklich erhält. Praktisch trifft es kaum: dieExact-Regel feuert nur auf dem präfixlosen Einstiegspfad, qBittorrents API liegt unter/qbittorrent/api/...und wird von derPathPrefix-Regel bedient.Unverändert gültig bleiben die beiden gegen die Spezifikation geprüften Punkte des vorigen Kommentars:
ExactschlägtPathPrefixunabhängig von der Listenposition, und es wird 301, weil 308 Extended ist und ein nicht unterstützter Statuscode die ganze Route aufAccepted: Falsesetzt.Implemented in #119 (CI green: all eight checks, including the required
validate-chartscontext and the install-test with the real tunnel).Your description of the behaviour is correct, including the cause — the bare prefix is stripped to
/, qBittorrent answers 200, and the page’s relative links are then resolved against the host root, which is seerr. The only detail that moved on investigation is where the existing redirect lives: it is not in this chart and never was (the pickaxe searches forconfiguration-snippetandreturn 301overfreesailarr/return zero commits, andvalues.yamldid not mention the trap at all). It is an operator-suppliednginx.ingress.kubernetes.io/configuration-snippeton the live Ingress objects, managed by Fleet fromjk-cluster-config. That is why the chart looked correct and the running system worked at the same time.What landed:
HTTPRoutegains a second rule for qBittorrent:Exactmatch onqbittorrent.ingress.path,RequestRedirectwithReplaceFullPathto the slashed form,statusCode: 301.Exactoutranks every prefix match in Gateway-API precedence, so it wins over qBittorrent’s ownPathPrefixrule and over seerr’s/wherever it sits. 301 and not 308 because only 301/302 are Core — an Extended value an implementation declines setsAccepted: Falseon the whole route and would take the four neighbouring apps down with it.statusCodeis written out because it defaults to 302.allow-snippet-annotations=true(off by default since ingress-nginx 1.9, and switching it on means accepting annotation risk levelCritical). Sovalues.yamlnow documents the trap, the working snippet, that price, and why a third object withpathType: Exactis not a substitute —buildLocation()in ingress-nginxcontroller-v1.14.5returns a regex location in itsenforceRegexbranch before reaching thePathTypeExactbranch, andenforceRegexis computed once per nginxserverover every location of the hostname, one of which carriesrewrite-target.freesailarr.jk-dev.destill runs in Ingress mode — it was deliberately not migrated — so that snippet remains the only thing performing the redirect there. Nothing in this change makes it redundant, there is no follow-up to remove it, andjk-cluster-configwas not touched.ci/run-httproute-match-test.shnow requires, perHTTPRoute, that a rule stripping a prefix withReplacePrefixMatchis accompanied by a rule matching that pathExactly with aRequestRedirectfilter. 37 assertions over 15 charts, up from 36; both fail paths exercised.bulwarkmeets the same check when group 3 of #114 lands.3.2.0+up1.0.0→3.3.0+up1.0.0(minor: thehelm templatediff againstorigin/mainis empty for both Ingress shapes, so no existing release’s render changes).freesailarr,CI-CDandLessons-Learned.What is not proven, stated plainly: no Gateway controller runs in CI and no
HTTPRouteever reachesAccepted: True, so "it redirects" is not demonstrable here. What is demonstrable is a schema-valid object against the real Gateway-API CRDs plus the render assertions. The query-string behaviour is a further open point —HTTPRequestRedirectFilterhas no field for it, where the nginx snippet carries it over with$is_args$args; it costs nothing on the UI entry path, which takes no query parameters.Behoben in 3.3.0+up1.0.0 (veröffentlicht 12.10.2026, 22:27). Gerendert gegengeprüft gegen die CRD-Schemata des Clusters, mit den Werten von
freesailarr.jk-dev.de:Die Regel ist da, als
Exact-Pfad mit ausgeschriebenemstatusCode, undbackendRefsfehlt bei ihr richtigerweise. Ausgerollt wird es mitjlab-cluster/cluster-config#400;freesailarr.jk-dev.dewar der Host, der diesen Befund ausgelöst hat.Die offene Frage aus dem Ticketkopf ist beantwortet, und besser als ich sie gestellt hatte
Ich hatte 301 gegen 308 mit der Methodenerhaltung begründet und das für das entscheidende Kriterium gehalten. Der Kommentar an der Regel führt ein Argument, das schwerer wiegt und das ich nicht auf dem Schirm hatte:
301 und 302 sind in der Gateway API CORE, alles andere — 308 eingeschlossen — ist EXTENDED. Eine Implementierung, die den gegebenen Wert nicht unterstützt, muss
Accepted=Falsemitreason: UnsupportedValuesetzen — nicht an der Regel, sondern an der ganzen Route. Auf einem geteilten Host trägt eine Route alle sechs Apps, ein abgelehntes 308 nähme also prowlarr, radarr, sonarr, bazarr und seerr mit qBittorrent mit. Und zwar an einem Objekt, das schema-valide ist, in einem Statusfeld, das keine CI ausliest.Das deckt sich mit Entscheidung 1 aus #114 — nur die Teilmenge rendern, die auf nginx-gateway-fabric, Cilium, Envoy Gateway und Istio gleich aussieht. Die Methodenerhaltung ist dagegen gar nicht betroffen: Die Regel trifft genau den präfixlosen Einstieg in die WebUI, den ein Browser mit GET erreicht; qBittorrents API liegt unter
<path>/api/..., also beschrägstrichtet, länger und von derPathPrefix-Regel bedient, die diese Regel nie sieht.Eine Beobachtung zur Reihenfolge, falls sie jemand später „korrigiert"
Der Kommentar sagt, Position trage keine Bedeutung, und das ist richtig:
Exactschlägt jedes Präfix, unter Präfixen gewinnt das längste, und die Listenreihenfolge wird erst herangezogen, wenn alles davor gleich ist. Regel 1 gewinnt also gegen Regel 0 und gegen Regel 6, egal wo sie steht.Der Zusatz im Chart, das sei „ALSO the order nginx would need … a coincidence of this chart's history", ist der Teil, der das vor einer späteren Umsortierung schützt — ohne ihn würde die absteigende Sortierung früher oder später als Korrektheitsbedingung gelesen.
Was aus diesem Fall als Verfahren bleibt
Der Mangel war nicht im Betrieb zu finden, sondern nur im Rendering: qBittorrent antwortet mit 200, und erst die relativen Verweise der Seite landen bei einer anderen Anwendung. Für die restlichen Charts in #114 heißt das — die gerenderte Route ansehen, nicht nur prüfen, dass eine entsteht. Dass ein Chart „Gateway-fähig" ist, sagt nichts darüber, ob er jede Verhaltensweise mitgenommen hat, die seine Ingress-Fassung hatte.
Aus meiner Sicht kann das Issue zu. Danke für die schnelle Fassung.
Nachtrag: die offene Query-String-Frage ist gemessen — er bleibt erhalten
Dieses Issue und PR #119 ließen eine Frage ausdrücklich offen: ob die Gateway-API-Umleitung den Query-String erhält.
HTTPRequestRedirectFilterhat in v1.6.3 die FelderScheme,Hostname,Path,PortundStatusCode— kein Query-Feld —, undReplaceFullPathist dokumentiert als Ersatz des Pfades. Die Spezifikation sagt also nichts, und der Chart durfte nichts zusagen.Seit
freesailarr.jk-dev.deim Gateway-Modus läuft (13.10.2026), ist es messbar:Der Query-String bleibt erhalten. Die Asymmetrie zum
$is_args$argsdes Betreiber-Snippets, die dieses Issue als Rest benannt hat, ist in der Praxis keine.Zwei Einschränkungen, damit der Befund nicht mehr trägt, als er kann:
values.yamlund im Wiki richtig: nicht zusagbar. Sie bekommt einen gemessenen Datenpunkt, keine Zusage.httproutesundgatewayclassessind für die lesende Identität RBAC-gesperrt.Nebenbei bestätigt dieselbe Messung, dass die Umleitung dieses Charts jetzt wirklich aus der Regel aus #119 kommt und nicht mehr aus dem Snippet: Es gibt keine
freesailarr-Ingress-Objekte mehr, das Snippet hat also keinen Träger, und die Antwortsignatur hat gewechselt (vorher nginx:content-type: text/html, 162 Bytes, HSTS — jetzt 17 Bytes, keines davon).Das Snippet in
jk-cluster-configist damit wirkungslos und kann entfernt werden. Solange der Host im Ingress-Modus lief, wäre das falsch gewesen — es war dort das Einzige, was die Umleitung leistete.