kubernetes: service situé dans un autre espace de noms

Question

J'ai essayé de trouver un moyen de définir un service dans un espace de noms que les liens vers une Gousse d'exécution dans un autre espace de noms. Je sais que les contenants dans un Pod en "namespaceA" peuvent accéder à "serviceX" au sens de "namespaceB" par référence dans le cluster du serveur DNS comme "serviceX.namespaceB.svc.cluster.locaux", mais je préfère ne pas avoir le code à l'intérieur du conteneur besoin de savoir à propos de l'emplacement de "serviceX". C'est, je veux le code pour juste recherche "serviceX" et ensuite être en mesure d'y accéder.

Le Kubernetes la documentation suggère que cela est possible. Il est dit que l'une des raisons que vous pourriez définir un service, sans un sélecteur est que "Vous voulez signaler votre service pour un service dans un autre espace de Noms ou sur un autre cluster."

Qui me fait penser que je devrais:

1. Définir un "serviceX" service "namespaceA", sans un sélecteur (depuis le POD, je veux sélectionner n'est pas dans "namespaceA").
2. Définir un service (dont j'ai aussi appelé "serviceX") dans "namespaceB", puis
3. Définir les terminaux objet dans le "namespaceA", pour faire "serviceX" dans "namespaceB".

C'est dans cette troisième étape que je n'ai pas été capable d'accomplir.

Tout d'abord, j'ai essayé de définir les paramètres de l'objet de cette façon:

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

Cela semblait la logique de l'approche, et "de toute évidence" que le "targetRef" a été pour. Mais, cela a conduit à une erreur disant que la "propriété intellectuelle" dans le champ "adresse" tableau était obligatoire. Donc, mon prochain essai a été d'attribuer un fixe ClusterIP adresse à "serviceX" dans "namespaceB", et placez-la dans le domaine de la propriété intellectuelle (à noter que la service_cluster_ip_range est configuré comme 192.168.0.0/16, et 192.168.1.1 a été affecté en tant que ClusterIP pour "serviceX" dans "namespaceB"; "serviceX" dans "namespaceA" a été affecté automatiquement sur un autre ClusterIP sur le 192.168.0.0/16 sous-réseau):

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

Qui a été accepté, mais accède à "serviceX" dans "namespaceA" n'a pas envoyés à la Gousse de "namespaceB" - ils dépassé. En regardant la configuration iptables, il ressemble comme il aurait dû le faire NAT pré-acheminement deux fois pour le faire.

La seule chose que j'ai trouver qui a travaillé mais n'est pas une solution satisfaisante - est à la recherche de l'adresse IP réelle de la Gousse de fournir "serviceX" dans "namespaceB" et de mettre cette adresse dans les paramètres de l'objet dans le "namespaceA". Ce n'est pas satisfaisante, bien sûr, parce que le Pod adresse IP peut changer au fil du temps. C'est le problème de service IPs sont là pour les résoudre.

Alors, est-il un moyen de répondre à ce qui semble être la promesse de la documentation que je peux point de service dans un espace de noms pour un service qui s'exécute dans un espace de noms?

Un intervenant a demandé pourquoi vous voulez pour ce faire, voici un cas d'utilisation qui fait sens pour moi, au moins:

Disons que vous avez un multi-locataire système, qui comprend également un commun d'accès aux données de fonction qui peuvent être partagées entre les locataires. Maintenant, imaginez qu'il y a différentes saveurs de ces données-accès à la fonction commune de l'Api, mais les différentes caractéristiques de performance. Certains locataires l'accès à l'un d'entre eux, les autres locataires ont accès à une autre.

Chaque locataire gousses d'exécuter dans leurs propres espaces de noms, mais chacun a besoin d'accéder à l'un de ces courants d'accès aux données des services, qui sera forcément dans un autre espace de noms (car il est accessible par plusieurs locataires). Mais, vous ne voulez pas le locataire d'avoir à changer leur code si leurs changements d'abonnement pour accéder à la plus performante de service.

Une solution possible (le plus propre, je peux le penser, si seulement il a travaillé) est à inclure une définition de service dans chacun des locataires de l'espace de noms pour les données de service d'accès, chacun configuré pour le point de terminaison. Cette définition de service doit être configuré pour pointer vers le bon de données du service d'accès à chaque locataire est en droit d'utiliser.

Answer 1

Je suis tombé sur le même problème et trouvé une belle solution qui ne nécessite pas de configuration ip statique:

Vous pouvez accéder à un service via c'est le nom DNS (comme mentionné par vous): servicename.espace de noms.svc.cluster.local

Vous pouvez utiliser le nom DNS de référence dans un autre espace de noms par l'intermédiaire d'un service local:

kind: Service
apiVersion: v1
metadata:
  name: service-y
  namespace: namespace-a
spec:
  type: ExternalName
  externalName: service-x.namespace-b.svc.cluster.local
  ports:
  - port: 80

Answer 2

Vous pouvez l'obtenir par le déploiement de quelque chose sur une couche supérieure que des espaces de Services, comme le service de loadbalancer https://github.com/kubernetes/contrib/tree/master/service-loadbalancer. Si vous souhaitez restreindre à un seul espace de noms, utilisez "--namespace=ns" argument (la valeur par défaut pour tous les espaces de noms: https://github.com/kubernetes/contrib/blob/master/service-loadbalancer/service_loadbalancer.go#L715). Cela fonctionne bien pour le L7, mais est un peu bordélique pour L4.