Kubernetes - Es kann keine Verbindung mit einer Service-IP aus dem Service-Pod hergestellt werden

Ich versuche, 3 Instanzen von Kafka zu erstellen und stelle ein lokales Kubernetes-Setup bereit. Da jede Instanz eine bestimmte Konfiguration benötigt, erstelle ich jeweils ein RC und einen Service - und warte gespannt auf ​​# 18016 ;)

Ich habe jedoch Probleme, weil Kafka keine Netzwerkverbindung zu sich selbst herstellen kann, wenn es die Service-IP verwendet (ein Kafka-Broker versucht dies, wenn er Replikationsnachrichten mit anderen Brokern austauscht). Nehmen wir zum Beispiel an, ich habe zwei Arbeiter-Hosts (172.17.8.201 und 172.17.8.202) und meine Pods sind wie folgt geplant:

• Host 1 (172.17.8.201)

  • kafka1 pod (10.2.16.1)

• Host 2 (172.17.8.202)

  • kafka2 pod (10.2.68.1)
  • kafka3 pod (10.2.68.2)

Sagen wir zusätzlich, dass ich die folgenden Service-IPs habe:

• kafka1 Cluster IP: 11.1.2.96
• kafka2 Cluster IP: 11.1.2.120
• kafka3 Cluster IP: 11.1.2.123

Das Problem tritt auf, wenn der kafka1 pod (Container) versucht, eine Nachricht (an sich selbst) mit der kafka1 Cluster-IP (11.1.2.96) zu senden. Aus irgendeinem Grund kann die Verbindung nicht hergestellt werden und die Nachricht wird nicht gesendet.

Noch ein paar Informationen: Wenn ich mich manuell mit dem kafka1 pod verbinde, kann ich mit den jeweiligen Cluster-IPs (11.1.2.120 / 11.1.2.123) korrekt zu kafka2 und kafka3 pods telnet. Wenn ich mich im kafka2 -Pod befinde, verbinde ich mich mit den beiden kafka1 und kafka3 -Pods unter Verwendung von 11.1.2.96 und 11.1.2.123. Schließlich kann ich eine Verbindung zu allen Pods (von allen Pods) herstellen, wenn ich die Pod-IPs verwende.

Es ist wichtig zu betonen, dass ich den Kafka-Brokern nicht empfehlen sollte, die Pod-IPs anstelle der Cluster-IPs für die Replikation zu verwenden. Wie es gerade ist, verwendet Kafka für die Replikation, welche IP-Adresse Sie auch konfigurieren, um "beworben" zu werden - das ist die IP, die Ihr Client verwendet, um sich mit den Brokern zu verbinden. Selbst wenn ich könnte, glaube ich, dass dieses Problem auch mit anderer Software auftreten kann.

Dieses Problem scheint nur mit der Kombination zu passieren, die ich verwende, weil die exakt gleichen Dateien in GCE korrekt funktionieren. Im Moment renne ich:

• Kubernetes 1.1.2
• coreos 928.0.0
• Netzwerkeinrichtung mit Flanell
• alles auf vagrant + VirtualBpx

Nach einigem Debuggen bin ich mir nicht sicher, ob das Problem in den iptables-Regeln, in kube-proxy oder in flanel liegt.

PS: Ich habe diese Frage ursprünglich als Problem auf ihren GitHub gestellt, aber ich wurde hierher umgeleitet vom Kubernetes-Team. Ich habe den Text ein wenig umgeschrieben, weil es sich anhört als wäre es eine "Supportanfrage", aber eigentlich glaube ich, dass es eine Art Bug ist. Wie auch immer, entschuldige das Kubernetes Team!

Bearbeiten: Dieses Problem wurde als Fehler Ссылка