Le service Kubernetes répond sur un port différent du port attribué

Dec 16 2020

J'ai déployé peu de services et constaté qu'un service se comporte différemment des autres. Je l'ai configuré pour écouter sur le port 8090 (qui correspond à 8443 en interne), mais la demande ne fonctionne que si j'envoie sur le port 8080. Voici mon fichier yaml pour le service (réduit à l'essentiel) et il y a un déploiement qui encapsule le service et conteneur

apiVersion: v1
kind: Service
metadata:
  name: uisvc
  namespace: default
  labels:
    helm.sh/chart: foo-1
    app.kubernetes.io/name: foo
    app.kubernetes.io/instance: rb-foo
spec:
  clusterIP: None
  ports:
    - name: http
      port: 8090
      targetPort: 8080
  selector:
    app.kubernetes.io/component: uisvc

Après avoir installé la barre, lorsque je cours kubectl get svc, j'obtiens le résultat suivant

fooaccess       ClusterIP   None         <none>        8888/TCP   119m
fooset          ClusterIP   None         <none>        8080/TCP   119m
foobus          ClusterIP   None         <none>        6379/TCP   119m
uisvc           ClusterIP   None         <none>        8090/TCP   119m

Cependant, lorsque je ssh dans l'un des autres conteneurs en cours d'exécution et émet une requête curl sur 8090, j'obtiens "Connexion refusée". Si je tourne vers "http: // uisvc: 8080", alors j'obtiens la bonne réponse. Le conteneur exécute une application de démarrage de printemps qui écoute par défaut sur 8080. La seule explication que je pourrais trouver est que le port / targetPort est ignoré dans cette configuration et que d'autres pods atteignent directement le service de printemps à l'intérieur.

Ce comportement est-il correct? Pourquoi n'écoute-t-il pas sur 8090? Comment dois-je le faire fonctionner de cette façon?

Edit: Sortie pour kubectl describe svc uisvc

Name:              uisvc
Namespace:         default
Labels:            app.kubernetes.io/instance=foo-rba
                   app.kubernetes.io/managed-by=Helm
                   app.kubernetes.io/name=rba
                   helm.sh/chart=rba-1
Annotations:       meta.helm.sh/release-name: foo
                   meta.helm.sh/release-namespace: default
Selector:          app.kubernetes.io/component=uisvc
Type:              ClusterIP
IP:                None
Port:              http  8090/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.8:8080
Session Affinity:  None
Events:            <none>

Réponses

1 thomas Dec 16 2020 at 20:39

Il s'agit du comportement attendu depuis que vous avez utilisé headless service.

Les services sans tête sont utilisés pour le mécanisme de découverte de service.Ainsi, au lieu de renvoyer un seul DNS A records, DNS serverils renverront plusieurs A recordspour votre service, chacun pointant vers l'adresse IP d'un pod individuel qui soutient le service. Vous effectuez donc une DNS A recordsrecherche simple et obtenez l'adresse IP de tous les pods qui font partie du service.

Puisque headless servicene crée pas de iptablesrègles mais crée à la dns recordsplace, vous pouvez interagir directement avec votre pod au lieu d'un proxy. Donc, si vous résolvez, <servicename:port>vous obtiendrez <podN_IP:port>et votre connexion ira directement au pod. Tant que tout cela est dans le même espace de noms, vous ne l'avez pas résolu par le nom DNS complet.

Avec plusieurs pods, DNS vous les donnera tous et les placera simplement dans l'ordre aléatoire (ou dans l'ordre RR). L'ordre dépend de l'implémentation et des paramètres du serveur DNS.

Pour plus d'informations, veuillez visiter:

  • Services-netowrking / services-sans-tête
  • Cette pile de questions avec une excellente réponse expliquant le fonctionnement des services sans tête