kubernetes 🚀 - Dienste mit demselben Port, unterschiedlichem Protokoll werden in kubectl falsch angezeigt und haben einen falschen ... | bleepcoder.com (2024)

@thockin Mit dem Validierungscode kann ich keine zwei Ports mit nicht angegebenen Namen erstellen.

The Service "my-service" is invalid: * spec.ports[0].name: Required value* spec.ports[1].name: Required value

Welche Version hat der Benutzer verwendet?

Es sieht so aus, als hätte der Benutzer den Kommentar gelöscht, in dem er dies behauptet hat
wahrscheinlich wurde ihnen klar, dass sie einen Fehler gemacht haben (sorry, dass sie das nicht gesehen haben). Immer noch,
Der Portname scheint der korrektere Zusammenführungsschlüssel zu sein

Am Dienstag, den 27. Dezember 2016 um 16:11 Uhr schrieb Mengqi Yu [emailprotected] :

@thockin https://github.com/thockin Der Validierungscode
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/validation/validation.go#L2481
Ich kann keine zwei Ports mit nicht angegebenen Namen erstellen.

Der Dienst "my-service" ist ungültig:

• spec.ports [0] .name: Erforderlicher Wert
• spec.ports [1] .name: Erforderlicher Wert

Welche Version hat der Benutzer verwendet?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/39188#issuecomment-269401334 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFVgVH8_TwXVE7sudwh4kZl230-wkIPgks5rMalGgaJpZM4LUkwV
.

Trotzdem scheint der Portname der korrektere Zusammenführungsschlüssel zu sein

Zustimmen.
Wenn wir name als mergeKey möchten, sollten wir einen Validierungscode hinzufügen, um sicherzustellen, dass die Namen eindeutig sind. Und wir müssen uns um einen leeren Namen kümmern, wenn es nur einen einzigen Port gibt.

@thockin Dies ist eine bahnbrechende Änderung. Also sollten wir diese Änderung in 1.6 vornehmen, richtig?

cc: @pwittrock

Namen sind einzigartig. Wir können nicht verlangen, dass dieser Name für das nicht leer ist
Single-Port-Fall, und wir fordern es bereits im Multi-Port-Fall. Können ""
ein gültiger Wert für den Fall eines einzelnen Ports sein?

Ich denke, das Ändern des Zusammenführungsschlüssels ist technisch gesehen eine bahnbrechende Änderung, aber es gibt sie
irgendwelche wirklichen Auswirkungen?

Am Dienstag, den 27. Dezember 2016 um 16:40 Uhr schrieb Mengqi Yu [emailprotected] :

Trotzdem scheint der Portname der korrektere Zusammenführungsschlüssel zu sein

Zustimmen.
Wenn wir den Namen als mergeKey verwenden möchten, sollten wir einen Validierungscode hinzufügen
Stellen Sie sicher, dass die Namen eindeutig sind. Und wir müssen uns um einen leeren Namen kümmern
wenn es nur einen einzigen Port gibt.

@thockin https://github.com/thockin Dies ist eine bahnbrechende Änderung. Also wir
sollte diese Änderung in 1.6 vornehmen, oder?

cc: @pwittrock https://github.com/pwittrock

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/39188#issuecomment-269403661 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFVgVFEiLbxVHCgP4QtVUV4t9PML2OC2ks5rMa_7gaJpZM4LUkwV
.

Kann "" ein gültiger Wert für den Fall eines einzelnen Ports sein?

Weiß noch nicht. Ich muss mich darum kümmern.

Ich denke, das Ändern des Zusammenführungsschlüssels ist technisch gesehen eine bahnbrechende Änderung, aber es gibt sie
irgendwelche wirklichen Auswirkungen?

Ja, wie # 36024 ( kubectl ist kaputt, auch bei geringfügigem Versionsversatz)

igitt

Am Dienstag, den 27. Dezember 2016 um 17:00 Uhr schrieb Mengqi Yu [emailprotected] :

Kann "" ein gültiger Wert für den Fall eines einzelnen Ports sein?

Weiß noch nicht. Ich muss mich darum kümmern.

Ich denke, das Ändern des Zusammenführungsschlüssels ist technisch gesehen eine bahnbrechende Änderung, aber es gibt sie
irgendwelche wirklichen Auswirkungen?

Ja, wie # 36024 https://github.com/kubernetes/kubernetes/issues/36024 (
kubectl ist kaputt, auch bei geringfügigem Versionsversatz)

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/39188#issuecomment-269405464 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFVgVI2Vj195GZZg7oyCZwmm4SaqQaOZks5rMbSzgaJpZM4LUkwV
.

Kann "" ein gültiger Wert für den Fall eines einzelnen Ports sein?

Der mergeKey muss in der go-Struktur vorhanden sein, um den Patch zu berechnen. Beim Auslösen einer Objektrunde wird jedoch ein leeres Feld gelöscht, das in diesem Fall name ist. Wenn Sie also einfach mergeKey ändern, wird der No-Name-Single-Port-Fall aufgehoben.

for: "../svc.yaml": map: map[protocol:UDP port:30420 targetPort:0 nodePort:30432] does not contain declared merge key: name

Wir sollten die mergeKey ändern, sonst macht kubectl apply etwas falsch.
zB Erstellen eines Dienstes mit kubectl apply

apiVersion: v1kind: Servicemetadata: name: my-servicespec: type: NodePort ports: - protocol: UDP port: 30420 name: updport nodePort: 30420 - protocol: TCP port: 30420 name: tcpport nodePort: 30420 selector: app: MyApp

Nehmen Sie die Änderung an tcpport und apply

 - protocol: TCP port: 30420 name: tcpport nodePort: 30000 # Change this nodePort

kubectl get den Service zurück

apiVersion: v1kind: Servicemetadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"kind":"Service","apiVersion":"v1","metadata":{"name":"my-service","creationTimestamp":null},"spec":{"ports":[{"name":"updport","protocol":"UDP","port":30420,"targetPort":0,"nodePort":30420},{"name":"tcpport","protocol":"TCP","port":30420,"targetPort":0,"nodePort":30000}],"selector":{"app":"MyApp"},"type":"NodePort"},"status":{"loadBalancer":{}}} name: my-service...spec: clusterIP: 10.0.0.249 ports: - name: updport nodePort: 30000 # Wrong change port: 30420 protocol: UDP targetPort: 30420 - name: tcpport nodePort: 30420 port: 30420 protocol: TCP targetPort: 30420 selector: app: MyApp sessionAffinity: None type: NodePortstatus: loadBalancer: {}

Die Änderung geht an den falschen Ort.

Ich bin damit einverstanden, dass wir es ändern sollten, aber wie können wir das tun, wenn der Name optional ist?
Kann ein leerer Mergekey automatisch zu einer zufälligen Zeichenfolge werden?

Am Mittwoch, den 28. Dezember 2016 um 14:20 Uhr schrieb Mengqi Yu [emailprotected] :

Kann "" ein gültiger Wert für den Fall eines einzelnen Ports sein?

Der mergeKey muss in der go-Struktur vorhanden sein, um den Patch zu berechnen. Aber Objekt
Beim Auslösen einer Runde wird ein leeres Feld gelöscht, das in diesem Fall der Name ist. Damit
Ändern Sie einfach den mergeKey, um den No-Name-Single-Port-Fall zu lösen.

Wir sollten den mergeKey ändern, sonst reicht kubectl apply aus
etwas stimmt nicht.
zB Erstellen eines Dienstes mit kubectl anwenden

apiVersion: v1kind: Servicemetadata:
Name: my-servicespec:
Typ: NodePort
Häfen:
- Protokoll: UDP
Port: 30420
Name: Updport
nodePort: 30420
- Protokoll: TCP
Port: 30420
Name: tcpport
nodePort: 30420
Wähler:
App: MyApp

Nehmen Sie Änderungen an tcpport vor und übernehmen Sie die Änderung

- protocol: TCP port: 30420 name: tcpport nodePort: 30000 # Change this nodePort

kubectl bekommt den Service zurück

apiVersion: v1kind: Servicemetadata:
Anmerkungen:
kubectl.kubernetes.io/last-applied-configuration: | {"kind": "Service", "apiVersion": "v1", "metadata": {"name": "my-service", "createdTimestamp": null}, "spec": {"ports": [{ "name": "updport", "protocol": "UDP", "port": 30420, "targetPort": 0, "nodePort": 30420}, {"name": "tcpport", "protocol": "TCP "," port ": 30420," targetPort ": 0," nodePort ": 30000}]," selector ": {" app ":" MyApp "}," type ":" NodePort "}," status ": { "loadBalancer": {}}} name: my-service ... spec:
clusterIP: 10.0.0.249
Häfen:

• Name: Updport
  nodePort: 30000 # Falsche Änderung
  Port: 30420
  Protokoll: UDP
  targetPort: 30420
• Name: tcpport
  nodePort: 30420
  Port: 30420
  Protokoll: TCP
  targetPort: 30420
  Wähler:
  App: MyApp
  sessionAffinity: Keine
  Typ: NodePortstatus:
  Lastenausgleicher: {}

Die Änderung geht an den falschen Ort.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/39188#issuecomment-269550385 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFVgVB00_aCZ2pF7mjyy3y2f810VjtMaks5rMuDGgaJpZM4LUkwV
.

Kann ein leerer Mergekey automatisch zu einer zufälligen Zeichenfolge werden?

Ja, es ist möglich, aber es wird die Logik kompliziert machen. Da apply die ursprüngliche Konfiguration (in Anmerkungen), die aktuelle Konfiguration (auf dem API-Server) und die geänderte Konfiguration (in der Benutzerdatei) benötigen, um 3-Wege-Diff auszuführen.

Ich bin mir nicht sicher, ob @pwittrock @ bgrant0607 das gefallen wird. Benötigen Sie ihre Kommentare, bevor Sie fortfahren.

"Zufällige" Zeichenfolge - Nr.

In anderen Fällen reicht ein einzelnes Feld als Zusammenführungsschlüssel nicht aus, z. B. Listen mit Objektreferenzen. Ich denke, alle Felder, die in der Konfiguration des Benutzers angegeben sind, als Schlüssel zu behandeln, funktioniert in allen Fällen, an die ich gedacht habe. Ich würde das wahrscheinlich zu einer neuen Patch-Strategie machen. Es wäre wahrscheinlich sogar abwärtskompatibel.

@ bgrant0607 Denken Sie, dass dies nur die primitiven Felder als Teil des eindeutigen / Zusammenführungsschlüssels unterstützen würde? Oder wäre diese Strategie nur für Typen gültig, die nur primitive Felder enthalten?

Basierend auf Ihrer Beschreibung wäre der Zusammenführungsschlüssel für diese Strategie dynamisch und würde vom Client definiert.

Haben wir darüber nachgedacht, Zusammenführungsschlüssel zu unterstützen, bei denen es sich um mehrere Werte handelt, die ansonsten genauso behandelt werden wie Zusammenführungsschlüssel mit einem Wert (in diesem Fall könnte dies der Fall sein?oder)?

Für diesen speziellen Fall ist "" nur im Fall eines einzelnen ein gültiger Name
Eintrag, und das wird durch Validierung erzwungen, also wenn "" erlaubt wäre, würde es
einfach arbeiten?

Am Mittwoch, den 11. Januar 2017 um 19:10 Uhr, Brian Grant [emailprotected]
schrieb:

@pwittrock https://github.com/pwittrock Nein, ich dachte, wir würden alle verwenden
Vom Benutzer als Schlüssel angegebene Felder, einschließlich verschachtelter Karten. Mehrere
Schlüssel würden auch funktionieren und könnten weniger fehleranfällig sein.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/39188#issuecomment-272064310 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFVgVDqLA1mRB-bEcODC1TQDuFNPXi_7ks5rRZmmgaJpZM4LUkwV
.

@thockin Ich habe gestern etwas Ähnliches gedacht. Etwas wie:

Wenn len (Patchliste) == 1 && Zusammenführungsschlüssel im Patchlisteneintrag fehlt && len (Zielliste) == 1 && Zusammenführungsschlüssel im Ziellisteneintrag fehlt
-> Dann nur in Eintrag in der Zielliste zusammenführen

Mein größtes Zögern hier war, dass es der bereits schlecht verstandenen Zusammenführungssemantik etwas Komplexität hinzufügt. Es würde wahrscheinlich einige seltsame Randfälle geben, wie das, was passiert, wenn wir den Zusammenführungsschlüssel zum vorhandenen Eintrag hinzufügen. z.B

Wenn len (Patch-Liste) == 1 && Zusammenführungsschlüssel im Listeneintrag vorhanden ist && len (Zielliste) == 1 && Zusammenführungsschlüssel im Ziellisteneintrag fehlt
-> Führen Sie dann nur den Eintrag in der Zielliste zusammen und legen Sie den Zusammenführungsschlüssel fest

Synchronisieren Sie mit @thockin , um die Mindestanforderungen für die Richtigkeit zu ermitteln. Ich möchte keine Teillösung einführen, da dies zu einem Wartungsaufwand führt. Sobald die Zusammenführungsschlüsselprüfung abgeschlossen ist, können Sie einen Vorschlag unterbreiten.

Ich denke, es ist in Ordnung, wenn wir einen Entwurfsvorschlag schreiben. Ich werde sicherstellen, dass es innerhalb von ~ Wochen angemessen überprüft wird.

Ich denke, der Schmerz, den Sie beim PATCHEN der Ports haben, wird durch den Fehler verursacht, das falsche JSON-Paket auf dem API-Server zu verwenden (# 42488). Es wurde von # 42489 behoben.

Probleme mit Ports:

• [x] # 42488 Problem mit der Nummernkonvertierung, das durch die Verwendung des falschen JSON-Pakets verursacht wurde.
• [] (dieses Problem) mergeKey für Ports (Port #) ist nicht eindeutig. Die Ports werden immer noch falsch PATCHED, wenn der Benutzer etwas wie https://github.com/kubernetes/kubernetes/issues/39188#issue -197312716 tut

Wurde dies behoben? Ich sehe beide Ports auf beschreiben:

› kubectl describe svc nginxName: nginxNamespace: defaultLabels: <none>Annotations: <none>Selector: app=nginxType: NodePortIP: 10.0.0.133Port: udp 30420/UDPNodePort: udp 30420/UDPEndpoints: 172.17.0.4:30420Port: tcp 30420/TCPNodePort: tcp 30420/TCPEndpoints: 172.17.0.4:30420Session Affinity: NoneEvents: <none>

@ Jamiehannaford Noch nicht. describe ist von diesem Problem nicht betroffen.
Vorschlag unter https://github.com/kubernetes/community/pull/476. Bewertung willkommen.

PR für die Unterstützung von Multifields MergeKey in neuen APIs: https://github.com/kubernetes/kubernetes/pull/46161
Vorschlag zur Korrektur vorhandener APIs: https://github.com/kubernetes/community/pull/476
Der zweite hängt vom ersten ab.

Scheint so, als würde dies nicht auf 1.8 landen. Möglicherweise möchten wir den Meilenstein entfernen.

cc @pwittrock @thockin

[MILESTONENOTIFIER] Meilensteinetiketten unvollständig

@mengqiy @thockin

Erforderliche Aktion : Für dieses Problem sind Änderungen an der Bezeichnung erforderlich. Wenn die erforderlichen Änderungen nicht innerhalb eines Tages vorgenommen werden, wird das Problem aus dem Meilenstein von Version 1.8 entfernt.

kind: Muss höchstens eines von ['kind / bug', 'kind / feature', 'kind / cleanup'] angeben.
Priorität: Muss höchstens eines von ['Priorität / kritisch-dringend', 'Priorität / wichtig-bald', 'Priorität / wichtig-langfristig'] angeben.

Probleme sind nach 90 Tagen Inaktivität veraltet.
Markieren Sie das Problem mit /remove-lifecycle stale als frisch.
Veraltete Probleme verrotten nach weiteren 30 Tagen Inaktivität und schließen schließlich.

Verhindern Sie das automatische Schließen von Problemen mit einem /lifecycle frozen -Kommentar.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes / test-infra und / oder @fejta .
/ Lebenszyklus abgestanden

Probleme sind nach 90 Tagen Inaktivität veraltet.
Markieren Sie das Problem mit /remove-lifecycle stale als frisch.
Veraltete Probleme verrotten nach weiteren 30 Tagen Inaktivität und schließen schließlich.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes / test-infra und / oder fejta .
/ Lebenszyklus abgestanden

Probleme sind nach 90 Tagen Inaktivität veraltet.
Markieren Sie das Problem mit /remove-lifecycle stale als frisch.
Veraltete Probleme verrotten nach weiteren 30 Tagen Inaktivität und schließen schließlich.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes / test-infra und / oder fejta .
/ Lebenszyklus abgestanden

Was ist passiert :
Ich glaube, ich habe das reproduziert. Bitte zögern Sie nicht, mich zu informieren, wenn meine Erwartungen falsch sind.
Ich habe eine Bereitstellung mit der folgenden Portdeklaration durchgeführt:

ports: - name: https containerPort: 443 - name: cport10000tcp containerPort: 10000 protocol: TCP - name: cport10000udp containerPort: 10000 protocol: UDP - name: cport10001udp containerPort: 10001 protocol: UDP

Wenn ich den Pod beschreibe, wurde er übersprungen und erwähnt, dass der Port (10000) für UDP geöffnet ist.

Pod Template: Labels: app=svr env=dev Containers: svr: Image: dev-svr:0.92 Ports: 443/TCP, 10000/TCP, 10001/UDP Host Ports: 0/TCP, 0/TCP, 0/UDP

Umwelt :

• Kubernetes-Version (verwenden Sie kubectl version ):
  $ kubectl versionClient Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:36:19Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
• Cloud-Anbieter oder Hardwarekonfiguration:
  Mac
• Betriebssystem (zB: cat /etc/os-release ):
  macOS Version 10.14.6
• Kernel (zB uname -a ):
  $ uname -aDarwin skwok-mbp.local 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64
• Tools installieren:
  Docker Desktop Version 19.03.1
• Netzwerk-Plugin und -Version (falls es sich um einen Netzwerkfehler handelt):
• Andere:

Das macht Spaß!

Ich werde dies für API-Maschinerie anstelle von CLI markieren, weil es nicht so aussieht, als ob dies wirklich nichts ist, was in der CLI behoben wird.

/ remove-sig cli
/ remove-area kubectl
/ sig api-maschinen

Es scheint, dass es einige mögliche Ansätze gibt, die dies angehen könnten (bitte fügen Sie andere hinzu, wenn Sie welche kennen):

1. Ändern Sie den Zusammenführungsschlüssel für Service.Ports (und Container.Ports ) so, dass er Name anstelle von Port ist.

• Dies scheint vom Standpunkt des Codes aus am wenigsten störend zu sein.
• Einige vorhandene Single-Port-Dienste verfügen jedoch über Ports ohne Namen, da der Name nur erforderlich war, wenn Sie mehrere Ports hatten.
• Im Wesentlichen kann der Zusammenführungsschlüssel nicht optional sein. Es wäre schön, einen Namen erforderlich zu machen, aber das scheint die bestehenden Single-Port-Dienste ohne Namen zu beschädigen.
• Möglicherweise könnte der Patch-Code für die

2. Aktualisieren Sie den strategischen Zusammenführungs-Patch, um mehrere Zusammenführungsschlüssel zu ermöglichen (Port, Protokoll statt nur Port).

• Dies scheint den Code zu stören und das Risiko zu erhöhen, aber es umgeht das Problem, dass einige Single-Port-Dienste einen Port ohne Namen haben, da wir damit im Grunde einen zusammengesetzten Zusammenführungsschlüssel für Port und Protokoll definieren könnten
• Ich bin kein großer Fan dieser Idee, weil es eine so große Veränderung ist und nur die Hafensituation wirklich berücksichtigt.

3. Repariere es nicht. Fehler beim Erstellen des Dienstes, wenn Sie versuchen, dieselbe Portnummer mit zwei Protokollen zu verwenden.

• Natürlich möchte jeder, dass dies behoben wird, aber seien wir ehrlich, es wurde seit Jahren nicht mehr behoben, und wenn es auftritt, verursacht es Probleme für Leute, von denen sie nichts erfahren, bis sie später versuchen, ihre Ports zu aktualisieren.
• Wir sollten den Leuten helfen, indem wir ihnen zu dem Zeitpunkt, zu dem der Server (oder Container) erstellt wird, im Voraus mitteilen, dass er nicht unterstützt wird, und den Vorgang fehlschlagen.
• Dies kann jedoch zu Problemen führen, wenn einige Benutzer es ordnungsgemäß verwenden, ihre Ports jedoch nie aktualisiert haben. Ich bin mir nicht sicher, ob dies realistisch ist oder nicht.

So reproduzieren Sie das Problem:

Ich weiß, dass dieser Thread bereits viele Informationen und Beispiele enthält, aber hier ist mein All-in-One-Skript, um das Problem zu reproduzieren:

# Create a service with tcp and udp ports using the same port numberkubectl apply -f - <<EOFapiVersion: v1kind: Servicemetadata: name: foospec: type: NodePort ports: - name: bar protocol: UDP port: 30420 nodePort: 30420 - name: baz protocol: TCP port: 30420 nodePort: 30420EOFkubectl get svc foo# Update the service to use a new port number for both portskubectl apply -f - <<EOFapiVersion: v1kind: Servicemetadata: name: foospec: type: NodePort ports: - name: bar protocol: UDP port: 30421 nodePort: 30421 - name: baz protocol: TCP port: 30421 nodePort: 30421EOFkubectl get svc fooecho "Whoops, I lost one of my ports!"

Ausgabe:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEfoo NodePort 10.109.137.128 <none> 30420:30420/UDP,30420:30420/TCP 0sservice/foo configuredNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEfoo NodePort 10.109.137.128 <none> 30421:30421/UDP 1sWhoops, I lost one of my ports!

Ja, ich denke, das wäre Teil von Option 1.

Es gibt jedoch immer noch Dienste mit einem einzigen Port ohne Namen. Ich bin mir nicht sicher, wie Sie noch zulassen können, dass diese aktualisiert werden.

Ich habe das gleiche Problem beim Erstellen eines ClusterIP-Dienstes mit demselben Port für TCP und UDP ... und beim Lesen dieses Threads klingt es so, als wäre er nach all dieser Zeit nicht behoben. Aber ich bin verwirrt von kube-dns unter dem Namespace des kube-Systems. Es ist auch ein ClusterIP, aber es scheint denselben Port für TCP und UDP zu haben:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkube-dns ClusterIP 10.100.200.2 <none> 53/UDP,53/TCP 60d

Ich habe mir die Service-Definition yaml (https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/deployments/kube-dns.yaml#L15) angesehen und sie ist sehr einfach. Ich habe die gleiche Syntax für meine service.yaml, aber es wird nur TCP angezeigt ... nun, je nachdem, was oben steht. Weiß jemand, was an kube-dns anders ist, was diese Arbeit macht?

Hier gibt es einen Aspekt, der einige Komplikationen verursacht. Die Diskussion konzentrierte sich auf Definitionen, die denselben Port haben, aber je nach Protokoll variieren. Das aktuelle Verhalten akzeptiert jedoch yaml mit Definitionen, die nur nach Namen variieren. Es wird nicht wie erwartet funktionieren, aber das Yaml wird akzeptiert.

Konzeptionell gibt es ein Argument zur Unterstützung mehrerer Namen für einen einzelnen Port: Ports haben Port-Aliase - ich kann Port 25 entweder als SMTP oder als Mail bezeichnen.

Dies scheint in 1.20 behoben zu sein (vielleicht vorher, aber ich habe 20 zur Hand :):

$ k describe svc hostnames...Type: NodePortIP: 10.0.0.201Port: tcp 80/TCPTargetPort: 9376/TCPNodePort: tcp 30013/TCPEndpoints: 10.64.0.83:9376Port: udp 80/UDPTargetPort: 9376/UDPNodePort: udp 30013/UDPEndpoints: 10.64.0.83:9376...

Gibt es noch andere Aspekte, die noch ausstehen?

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen