Ich habe versucht, einen Weg zu finden, um einen Dienst in einem Namespace zu definieren, der mit einem Pod verknüpft ist, der in einem anderen Namespace ausgeführt wird. Ich weiß, dass Container in einem Pod, in dem ausgeführt wird, namespaceAauf serviceXdefinierten Zugriff zugreifen können , namespaceBindem sie im Cluster-DNS als referenziert werden serviceX.namespaceB.svc.cluster.local, aber ich möchte lieber nicht, dass der Code im Container über den Speicherort von informiert wird serviceX. Das heißt, ich möchte, dass der Code nur nachschlägt serviceXund dann darauf zugreifen kann.
Die Kubernetes-Dokumentation legt nahe, dass dies möglich ist. Einer der Gründe, warum Sie einen Dienst ohne Selektor definieren würden, besteht darin, dass Sie Ihren Dienst auf einen Dienst in einem anderen Namespace oder in einem anderen Cluster verweisen möchten .
Das legt mir nahe, dass ich:
- Definieren Sie einen
serviceXDienst innamespaceAohne Selektor (da der POD, den ich auswählen möchte, nicht in istnamespaceA). - Definieren Sie einen Dienst (den ich auch angerufen habe
serviceX) innamespaceBund dann - Definieren Sie ein Endpunktobjekt
namespaceA, auf dasserviceXin gezeigt werden sollnamespaceB.
Es ist dieser dritte Schritt, den ich nicht ausführen konnte.
Zuerst habe ich versucht, das Endpunktobjekt folgendermaßen zu definieren:
kind: Endpoints
apiVersion: v1
metadata:
name: serviceX
namespace: namespaceA
subsets:
- addresses:
- targetRef:
kind: Service
namespace: namespaceB
name: serviceX
apiVersion: v1
ports:
- name: http
port: 3000Das schien der logische Ansatz zu sein und offensichtlich, wofür das targetRefwar. Dies führte jedoch zu einem Fehler, der besagte, dass das ipFeld im addressesArray obligatorisch war. Also, mein nächster Versuch war eine feste ClusterIP Adresse zuweisen serviceXin namespaceBund umsetzen , die in dem IP - Feld (beachten Sie, dass das service_cluster_ip_rangeso konfiguriert ist 192.168.0.0/16, und 192.168.1.1wurde als ClusterIP für zugewiesen serviceXin namespaceB, serviceXin namespaceAwurde automatisch einen anderen ClusterIP auf dem zugewiesenen 192.168.0.0/16Subnetz) ::
kind: Endpoints
apiVersion: v1
metadata:
name: serviceX
namespace: namespaceA
subsets:
- addresses:
- ip: 192.168.1.1
targetRef:
kind: Service
namespace: namespaceB
name: serviceX
apiVersion: v1
ports:
- name: http
port: 3000Das wurde akzeptiert, aber die Zugriffe auf serviceXin namespaceAwurden nicht an den Pod in weitergeleitet namespaceB- sie haben eine Zeitüberschreitung. Wenn man sich das iptables-Setup ansieht, sieht es so aus, als hätte es zweimal NAT-Pre-Routing durchführen müssen, um dies zu erreichen.
Das einzige , was ich gefunden haben , das funktionierte - aber keine befriedigende Lösung - ist die tatsächliche IP - Adresse der Pod Bereitstellung Nachschlag serviceXin namespaceBund diese Adresse in dem Endpoints Objekt setzen namespaceA. Das ist natürlich nicht zufriedenstellend, da sich die Pod-IP-Adresse im Laufe der Zeit ändern kann. Das ist das Problem, das Service-IPs lösen müssen.
Gibt es also eine Möglichkeit, das Versprechen der Dokumentation zu erfüllen, dass ich einen Dienst in einem Namespace auf einen Dienst verweisen kann , der in einem anderen Namespace ausgeführt wird?
Ein Kommentator fragte, warum Sie dies tun möchten - hier ist ein Anwendungsfall, der zumindest für mich sinnvoll ist:
Angenommen, Sie haben ein System mit mehreren Mandanten, das auch eine gemeinsame Datenzugriffsfunktion enthält, die von Mandanten gemeinsam genutzt werden kann. Stellen Sie sich nun vor, dass es verschiedene Varianten dieser Datenzugriffsfunktion mit gemeinsamen APIs gibt, aber unterschiedliche Leistungsmerkmale. Einige Mieter erhalten Zugang zu einem von ihnen, andere Mieter haben Zugang zu einem anderen.
Die Pods jedes Mandanten werden in seinen eigenen Namespaces ausgeführt, aber jeder muss auf einen dieser allgemeinen Datenzugriffsdienste zugreifen, die sich notwendigerweise in einem anderen Namespace befinden (da mehrere Mandanten darauf zugreifen). Sie möchten jedoch nicht, dass der Mandant seinen Code ändern muss, wenn sich sein Abonnement ändert, um auf den leistungsstärkeren Dienst zuzugreifen.
Eine mögliche Lösung (die sauberste, die ich mir vorstellen kann, wenn sie nur funktioniert) besteht darin, eine Dienstdefinition in den Namespace jedes Mandanten für den Datenzugriffsdienst aufzunehmen, wobei jede für den entsprechenden Endpunkt konfiguriert ist. Diese Dienstdefinition würde so konfiguriert, dass sie auf den richtigen Datenzugriffsdienst verweist, zu dessen Nutzung jeder Mandant berechtigt ist.