Deterministische Verbindung zur cloudinternen IP des K8S-Dienstes oder des ihm zugrunde liegenden Endpunkts?

Question

Ich habe einen Kubernetes-Cluster (1.3.2) im GKE und ich möchte VMs und Dienste von meinem Google-Projekt verbinden, das das gleiche Netzwerk wie der Cluster hat.

Gibt es eine Möglichkeit für eine VM, die intern im Subnetz, aber nicht intern im Cluster selbst ist, sich mit dem Dienst zu verbinden, ohne die externe IP zu treffen?

Ich weiß, es gibt eine Menge Dinge, die Sie tun können, um eindeutig die IP und den Port von Diensten zu bestimmen, wie die ENVs und DNS ... aber das ClusterIP ist außerhalb des Clusters (offensichtlich) nicht erreichbar.

Gibt es etwas, das mir fehlt? Eine wichtige Komponente dazu ist, dass dies ein Dienst "öffentlich" für das Projekt sein soll, so dass ich nicht weiß, welche VMs im Projekt eine Verbindung mit dem Dienst herstellen wollen (diese könnte loadBalancerSourceRanges ausschließen). Ich verstehe den Endpunkt, den die Dienste tatsächlich umschlingen, ist die interne IP, die ich treffen kann, aber der einzige gute Weg, um zu dieser IP zu kommen, ist die Kube API oder kubectl, die beide keine idealen Möglichkeiten sind, meinen Dienst zu treffen.

Answer 1

Schauen Sie sich meine ausführlichere Antwort here an, aber die gängigste Lösung ist das Erstellen von Bastionswegen in Ihrem GCP-Projekt.

In der einfachsten Form können Sie eine einzelne GCE-Route erstellen, um den gesamten Verkehr mit dest_ip im Service-IP-Bereich Ihres Clusters auf einen Ihrer GKE-Knoten zu leiten. Wenn Sie durch diesen SPOF erschreckt werden, können Sie mehrere Routen erstellen, die auf verschiedene Knoten zeigen, und der Verkehr wird zwischen ihnen round-root. Wenn dieser Verwaltungsaufwand nicht gewünscht ist, können Sie einen einfachen Controller in Ihren GKE-Cluster schreiben, um den Nodes-API-Endpunkt zu überwachen, und sicherstellen, dass Sie über eine Bastionsroute mit mindestens N verfügen Knoten zu einer bestimmten Zeit.

GCP internal load balancing wurde gerade als Alpha veröffentlicht, so dass in Zukunft kube-proxy auf GCP implementiert werden könnte, was die Notwendigkeit von Bastionswegen für interne Dienste überflüssig machen würde.