Le service Kubernetes répond sur un port différent du port attribué
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
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 server
ils renverront plusieurs A records
pour votre service, chacun pointant vers l'adresse IP d'un pod individuel qui soutient le service. Vous effectuez donc une DNS A records
recherche simple et obtenez l'adresse IP de tous les pods qui font partie du service.
Puisque headless service
ne crée pas de iptables
règles mais crée à la dns records
place, 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