0
votes

2 ports pour 1 Ingres / services / statefulsets / pods

Condition : J'ai deux conteneurs docker où les deux exposent à des ports différents. (Par exemple, les ports 9001 et 9002)

À partir de l'exigence, j'essaie de concevoir les objets kubernetes et leurs relations mais je ne sais pas si A ou B est correct.

A) 1 Ingres se connecte à 1 service. Et 1 service se connecte à 1 statefulset avec 1 pod de 2 conteneurs

B) 2 Ingres se connectent à 2 services. Et 2 services se connectent à 2 statefulset avec 2 pod. Chaque pod a 1 conteneur.

Je souhaite poser les questions suivantes:

  1. 1 Ingres, 1 service, 1 statefulset ou 1 pod peuvent-ils desservir 2 ports? Si peut alors probablement A est correct, sinon B est correct.
  2. En se basant également sur ma question, quelqu'un peut-il me dire si ma compréhension de Kubernetes est correcte ou incorrecte?

2 commentaires

1 dosette peut servir 2 contenants avec 2 dosettes différentes. Pouvez-vous préciser votre besoin final? L'entrée est un moyen d'accès depuis l'extérieur du cluster, en avez-vous besoin?


Je construis un conteneur ethereum et je connecte le conteneur Java au conteneur ethereum. Si vous ne connaissez pas ethereum, traitez-le simplement comme Mysql. Supposons que Java se connecte à mysql, je dois déclencher localhost: 8080 pour appeler l'API Java Et je dois déclencher localhost: 3306 pour communiquer avec la base de données.


3 Réponses :


1
votes

Vous pouvez exécuter deux conteneurs sur le même pod, Le Java peut fonctionner sur le port 8080 Et l'Eheterum peut fonctionner sur le port 3306.

Ensuite, vous pouvez utiliser localhost: 8080 à partir du conteneur pour atteindre le Java, et le java peut atteindre l'étherum sur localhost: 3306.

Si aucun accès depuis l'extérieur du cluster n'est requis, l'entrée n'est pas requise.

J'espère qu'il répond à votre question.


0 commentaires

1
votes

D'après ce que j'ai compris, vous n'avez besoin que d'une application avec état, l'autre peut être sans état et conserver les données dans la première application. Si vous suivez le paradigme des microsservices, vous devez séparer vos applications en services sans état et avec état.
Il est également important de noter qu'à moins que deux conteneurs ne soient étroitement couplés, ils ne devraient pas être sur le même pod. Les séparations permettent une évolutivité plus flexible, car vous n'avez pas besoin d'avoir le même nombre de répliques des deux conteneurs.
En conclusion, je ferais ce qui suit:

  • Créez un déploiement contenant uniquement l'image de votre application sans état.
  • Créez un StatefulSet pour l'application avec état.
  • Créez deux services, un pour chaque application.
  • Créez une entrée pour votre application sans état.

L'entrée permettra le routage de la demande provenant de l'extérieur du cluster vers le service de votre application. Même si votre application statefull ne communique pas avec le monde externe, la création d'un service pour lui permettra une communication plus facile entre les applications à l'intérieur du cluster (vous pouvez utiliser une adresse IP fixe ou même DNS )


0 commentaires

1
votes

1 entrée peut servir n nombre de services et achemine les connexions externes vers les services en fonction de l'hôte et du chemin hôte.

1 service peut desservir plusieurs ports et attribue différents mappages de ports de nœuds à chaque port.

1 pod peut également servir plusieurs ports et cela dépend du port que vous exposez dans votre manifeste.

Les Statefulsets ressemblent plus à des pods manifestes, c'est juste qu'ils fournissent une fonctionnalité complémentaire de persistance des volumes.


0 commentaires