J'utilise kubernetes et je voudrais configurer des workers, l'un de mes docker héberge une API utilisant flask, j'ai un algorithme dans un autre docker (même pod, je ne sais pas si je dois le laisser dans le same) et d'autres scripts qui sont également dans des dockers séparés. Je veux lier tous ces éléments, lorsque je reçois une demande sur l'API, appelle les autres dockers en fonction de la demande et obtiens le retour.
Je ne sais pas comment faire cela avec plusieurs dockers et donc kubernetes.
J'utilise la bibliothèque RQ pour python à paralléliser jusqu'à présent, mais c'était sur Heroku sans kubernetes (je migre vers azure pour le moment) et je ne sais pas comment elle la gère.
Merci.
3 Réponses :
suivez la référence ci-dessous et configurez le cluster kubernetes à l'aide de kubeadm.
https://kubernetes.io/docs/setup/independent/ create-cluster-kubeadm /
en utilisant la commande 'kubeadm join', vous devriez pouvoir ajouter des nœuds de travail au maître. le lien ci-dessus contient des étapes pour rejoindre le collaborateur en tant que maître
Puis-je simplement utiliser une instance minimale de flask avec un port différent, je pourrais simplement appeler un autre docker en utilisant localhost et le port correspondant. est-ce une mauvaise façon?
que se passe-t-il si le conteneur docker tombe en panne. vous avez besoin d'un orchstrateur tel que kubernetes ou docker swarm pour gérer le cycle de vie. interrogez régulièrement la santé du conteneur s'il ne répond pas, l'orchestrateur redémarrera le conteneur / pod
Si vous utilisez Azure, vous pouvez essayer d'explorer AKS. Cela fonctionne hors de la boîte. Il vous suffit de configurer kubectl et vous serez prêt à partir.
En ce qui concerne le déploiement de plusieurs microservices (API), vous pouvez déployer chaque microservice en tant que déploiement k8s distinct à l'aide de kubectl et les exposer à l'aide d'un service. De cette façon, ils peuvent communiquer entre eux en utilisant des points de terminaison exposés (API) ou une file d'attente de messages.
Voici un guide rapide sur lequel vous pouvez obtenir de l'aide: https://dzone.com/articles/quick-guide-to-microservices-with-kubernetes-sprin
Puis-je simplement utiliser une instance minimale de flask avec un port différent, je pourrais simplement appeler un autre docker en utilisant localhost et le port correspondant. est-ce une mauvaise façon?
En règle générale, vous ne devez utiliser qu'un seul conteneur par pod. Plusieurs conteneurs par pod sont possibles mais sont généralement utilisés pour les side-cars, pas pour les API supplémentaires.
Vous exposez vos services à l'aide des services kubernetes, pas besoin de tout exécuter sur un port différent si vous ne le souhaitez pas.
Une configuration minimale pour les appels typicall webapi ressemblerait à ceci (si vous exposez votre service API en tant que LoadBalancer public, vous n'avez pas nécessairement besoin d'Ingress)
Client -> (Ingress) -> Service API -> Pod (s) de déploiement d'API -> services internes -> pods de déploiement.
Vous pouvez accéder à vos services internes depuis votre cluster en utilisant http (s): // servicename [: custom-port]
D'un autre côté, si vous utilisez simplement flask pour transférer les appels d'API vers d'autres services, vous voudrez peut-être le remplacer par un contrôleur d'entrée qui effectue tout le routage à votre place.
C'est intéressant, je vais vérifier ça. Pour: Vous pouvez accéder à vos services internes à partir de votre cluster en utilisant http (s): // nom_service [: port personnalisé] Je suis désolé mais je ne suis pas sûr de comprendre. pourriez-vous expliquer plus s'il vous plaît?
Kubernetes utilise un service DNS interne. Chaque définition de service comprend un nom. Pour communiquer avec d'autres services de votre cluster à partir d'un conteneur, vous pouvez utiliser ces noms DNS comme n'importe quel autre nom de domaine. Donc, si vous voulez accéder à "internal-service-1" sur le port 80 et récupérer "/ api / values", il vous suffit de faire une requête HTTP à internal-service-1 / api / values depuis votre pod de passerelle API.
Si par «workers» vous entendez des pods qui n'exposent pas de service http mais s'exécutent simplement en arrière-plan en travaillant sur une file d'attente (puisque vous mentionnez RQ), l'architecture est presque la même à l'exception de ne pas communiquer directement via HTTP à l'intérieur de votre cluster mais en passant des messages dans une file d'attente. En fonction de votre cas d'utilisation, vous pouvez utiliser Redis pour cela, mais il existe également d'autres options gérées sur Azure comme Event Hub et Service Bus.
Mais ils doivent être dans le même pod non? pour le travailleur d'arrière-plan Et pour RQ par exemple, je dois importer le conn d'un autre fichier qui se trouve dans le même menu fixe. Puis-je le faire entre deux dockers?
au lieu de partager la configuration, dupliquez-la ou, mieux encore, utilisez des variables d'environnement et / ou des secrets pour les données de configuration. voici une procédure pas à pas pour votre cas d'utilisation: louistiao.me/posts/...