Ho cercato di trovare un modo per definire un servizio in uno spazio dei nomi che si collega a un pod in esecuzione in un altro spazio dei nomi. So che i contenitori in un pod in esecuzione namespaceApossono accedere serviceXdefiniti in namespaceBreferenziandolo nel cluster DNS come serviceX.namespaceB.svc.cluster.local, ma preferirei che il codice all'interno del contenitore non avesse bisogno di conoscere la posizione di serviceX. Cioè, voglio che il codice cerchi serviceXe poi sia in grado di accedervi.
La documentazione di Kubernetes suggerisce che ciò è possibile. Dice che uno dei motivi per cui definiresti un servizio senza un selettore è che vuoi puntare il tuo servizio a un servizio in un altro Namespace o su un altro cluster .
Questo mi suggerisce che dovrei:
- Definisci un
serviceXservizio innamespaceA, senza un selettore (poiché il POD che voglio selezionare non è innamespaceA). - Definisci un servizio (che ho anche chiamato
serviceX)namespaceBe poi - Definire un oggetto endpoint
namespaceAa puntoserviceXanamespaceB.
È questo terzo passaggio che non sono stato in grado di compiere.
Innanzitutto, ho provato a definire l'oggetto Endpoint in questo modo:
kind: Endpoints
apiVersion: v1
metadata:
name: serviceX
namespace: namespaceA
subsets:
- addresses:
- targetRef:
kind: Service
namespace: namespaceB
name: serviceX
apiVersion: v1
ports:
- name: http
port: 3000
Sembrava l'approccio logico, e ovviamente a cosa servivatargetRef . Tuttavia, questo ha portato a un errore che diceva che il ipcampo addressesnell'array era obbligatorio. Quindi, il mio tentativo successivo è stato quello di assegnare un indirizzo ClusterIP fisso a serviceXin namespaceBe inserirlo nel campo IP (si noti che service_cluster_ip_rangeè configurato come 192.168.0.0/16, ed è 192.168.1.1stato assegnato come ClusterIP per serviceXin namespaceB; serviceXin è namespaceAstato assegnato automaticamente un ClusterIP diverso sulla 192.168.0.0/16sottorete) :
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: 3000
È stato accettato, ma gli accessi a serviceXin namespaceAnon sono stati inoltrati al Pod in namespaceB: sono scaduti. Guardando la configurazione di iptables, sembra che avrebbe dovuto eseguire due volte il pre-routing NAT per ottenere ciò.
L'unica cosa che ho trovato che ha funzionato - ma non è una soluzione soddisfacente - è di ricercare l'indirizzo IP effettivo del Pod fornire serviceXin namespaceBe mettere quell'indirizzo nell'oggetto Endpoint in namespaceA. Ciò non è soddisfacente, ovviamente, perché l'indirizzo IP del Pod potrebbe cambiare nel tempo. Questo è il problema che gli IP del servizio sono lì per risolvere.
Quindi, c'è un modo per soddisfare quella che sembra essere la promessa della documentazione che posso indirizzare un servizio in uno spazio dei nomi a un servizio in esecuzione in uno spazio dei nomi diverso?
Un commentatore ha chiesto perché vorresti farlo: ecco un caso d'uso che ha senso per me, almeno:
Supponiamo di avere un sistema multi-tenant, che include anche una funzione di accesso ai dati comune che può essere condivisa tra i tenant. Ora immagina che esistano versioni diverse di questa funzione di accesso ai dati con API comuni, ma caratteristiche di prestazioni diverse. Alcuni inquilini hanno accesso a uno di essi, altri hanno accesso a un altro.
I pod di ogni tenant vengono eseguiti nei propri spazi dei nomi, ma ognuno deve accedere a uno di questi servizi di accesso ai dati comuni, che sarà necessariamente in un altro spazio dei nomi (poiché è accessibile da più tenant). Tuttavia, non si vorrebbe che l'inquilino debba modificare il proprio codice se l'abbonamento cambia per accedere al servizio con prestazioni più elevate.
Una potenziale soluzione (la più pulita a cui riesco a pensare, se solo funzionasse) è includere una definizione del servizio nello spazio dei nomi di ogni tenant per il servizio di accesso ai dati, con ciascuno configurato per l'endpoint appropriato. Questa definizione di servizio sarebbe configurata in modo da puntare al servizio di accesso ai dati appropriato che ogni tenant è autorizzato a utilizzare.