In this question, I managed to set-up REST communication between two microservices using a user-defined bridge network in docker-compose
Now, I'm trying to do the same when hosting my microservices on AWS.
I could really use some pointers as to how to achieve this, because I'm terribly lost.
I've tried following numerous tutorials, both written and on pluralsight, but none seem to be close enough to my use case.
My project architecture is as follows:
https://i.stack.imgur.com/vc6TX.png
And my project infrastructure should probably look like this:
https://i.stack.imgur.com/X73HA.png
Thanks
You can use internal Loadbalancer for each service and create DNS records us it for app communication Also ECS and a service discovery feature that is useful in this scenario.
Related
Hello intelligent stackoverflow people,
i am trying to deploy my microservice backend developed with nestjs on Kubernetes.
But i don´t know how to do it or even find a tutorial that shows me how to.
I found an article talking about a similar case using Kafka as the event-streaming-service.
https://limascloud.com/2022/03/22/nestjs-on-kubernetes-kubernetes-for-developers/
Instead of Kafka i used the native event based communication provided by the framework described in the docs. It is some basic topic based publish-subscribe mechanism.
Does that prohibit the use of Kubernetes. Do i need to use some kind of external communication software?
I am really confused at the moment and dont know if we/i made an error since the start.
I am the author of the post you mentioned. You should be able to use the event-streaming-service, but it's a different scenario than the one I represent in the post.
In the post, the pods are connecting to a Kafka service that is running outside of the Kubernetes network, but in your scenario, the pods need to be able to connect to one another inside the Kubernetes network.
If you are planning to use two separate services, I would recommend using an external broker. If you plan to use the default mechanism, make sure to set the host and port configuration for one of the pods. Lets say api is just going to produce, so set its configuration to the pod name and port of the worker. Let me know if it works. I would start trying to make it work on your local env before going to Kubernetes.
I'm new to Kubernetes and trying to point all requests to the domain to another local service.
Both applications are running in the same cluster under a different namespace
Example domains
a.domain.com hosting first app
b.domain.com hosting the second app
When I do a curl request from the first app to the second app (b.domain.com). it travels through the internet to the second app.
Usually what I could do is in /etc/hosts point b.domain.com to localhost.
What do we do in this case in Kubernetes?
I was looking into Network Policies but I'm not sure if it correct approach.
Also As I understood we could just call service name.namespace:port from the first app. But I would like to keep the full URL.
Let me know if you need more details to help me solve this.
The way to do it is by using the Kubernetes Gateway API. Now, it is true that you can deploy your own implementation since this is an Open Source project, but there are a lot of solutions already using it and it would be much easier to learn how to implement those instead.
For what you want, Istio would fit your needs. If your cluster is hosted in a Cloud environment, you can take a look at Anthos, which is the managed version of Istio.
Finally, take a look at the blog Welcome to the service mesh era, since the traffic management between services is one of the elements of the service mesh paradigm, among others like monitoring, logging, etc.
I am wondering how to deploy multiple applications such as springboot app, nodejs app etc.on a single kubernetes cluster that has a single istio load balancer.
Is it pssible?
I am a beginner in devops so need some guidance on this.
Thank you for suggestions.
Yes, it's possible. Moreover this is the exact purpose of the LoadBalancer - to be a single point of entrance for multiple applications.
If you deploy an example application, you will create three versions of reviews application (reviews-v1, reviews-v2, reviews-v3 - as far as K8s and Istio are concerned, those are three different apps). With the use of Virtual Services and Destination rules, Istio manages traffic between those three applications.
Since you are a beginner, I would strongly recommend thorough read of Istio documentation, especially Tasks and Examples
Context
I am deploying a set of services that are containerised using Docker into AWS. No matter which deployment solution is chosen (e.g. raw EC2/ECS/Elastic Beanstalk/Fargate) we will face the issue of "service discovery".
To name just a few of the options for service discovery that I've considered:
AWS Route 53 Service Registry
Kubernetes
Hashicorp Consul
Spring Cloud Netflix Eureka
Specifics Of My Stack
I am developing Java Spring Boot applications using Spring Cloud with the target deployment environment being AWS.
Given that my stack is Spring based, spring cloud eureka made sense to me while developing locally. It was easy to set up a single node, integrates well with the stack and ecosystem of choice and required very little set up.
Locally, we are using docker compose (not swarm) to deploy services - one of the containers deployed is a single node Eureka service discovery server.
However, when we progress outside of local development and into staging or production environment we are considering options like Kubernetes.
My Own Assessment Of Pros/Cons
AWS Route 53 Service Registry
Requires us to couple code specifically to AWS services. Not a problem per se, we are quite tied in anyway on other parts of the stack (SNS/SQS).
Makes running the stack locally slightly more difficult as it relies on Route 53, I suppose we could open up a certain hosted zone for local development.
AWS native, no managing service registries or extra "moving parts".
Spring Cloud Eureka
Downside is that thus requires us to deploy and manage a high availability service registry cluster and requires more resources. Another "moving part" to manage.
Advantages are that it fits into our stack well (spring ecosystem, spring boot, spring cloud, feign and zuul work well with this). Also can be run locally trivially.
I presume we need to configure the networks and registry zone to ensure that that clients publish their host address rather and docker container internal IP address. e.g. if service A is on host A and wants to talk to service B on host B, service B needs to advertise its EC2 address rather than some internal docker IP.
Questions
If we use Kubernetes for orchestration, are there any disadvantages to using something like Spring Cloud Eureka over the built in service discovery options described here https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
Given Kube provides this, it seems suboptimal to then use eureka deployed using kube to perform discovery. I presume kube can make some optimisations that impact avaialbility and stability that might nit be possible using eureka. e.g kube would know when deploying a new service - eureka will have to rely on heartbeats/health checks and depending on how that is configured (e.g. frequency) this could result in stale records whereas i presume kube might not suffer from this for planned service shutdown/restarts. I guess it still does for unplanned failures such as a host failure or network partition.
Does anyone have any advice on this, do people use services like Kubernetes but use other mechanisms for service discovery rather than those provided by kube. Is there a good reason to do one or the other?
Possible Challenges I Anticipate
We could replace eureka, but relying on Kube to perform discovery will mean that we need to run kube locally to deploy whereas currently we have a simple tiny docker-compose file. Also, I'll have to look at how easy it'll be to ensure that ribbon, zuul and feign play nicely with this.
Currently we have ribbon configured with a eureka client so that service A can server to service B just as "service-b" for example and have ribbon resolve a healthy host via a eureka client. I guess we can configure ribbon to not use eureka and use an external Kube service name which will be resolved by Kube DNS at runtime...
Final Note
Thanks in advance for any contribution or advice. I know this might elicit a primarily opinion focused response. But I am hoping someone can provide objective guidance on when one solution might be preferable to another.
Service discovery is something you get out-of-the-box with Kubernetes. So having another external service in your platform will be another application to maintain, deploy and can be a point of failure. So I would stick with the the service discovery provided by Kubernetes.
We're migrating to Kubernetes and many of our services are using Hystrix which expose a stream of server sent event data consumed by Turbine and visualized by a Hystrix Dashboard. I'd like to implement a service discovery plugin to Turbine which auto discovers our Hystix streams running on Kubernetes.
Would it be a good idea to use labels for this? I.e. define a label that includes the path to the hystrix stream for each pod using Hystrix?
If labels are not a good idea, what would be?
I had the same problem and I created a little project to address it.
essentially I implemented a hystric instance discovery class to work with kubernetes services.
You can find my project here.
This projects is in its infancy so bugs are likely. Feedback it welcome.
Thanks
Raffaele
How about making Hystrix a Kubernetes service?Kubernetes has two suggested ways to discover services: https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/services.md#discovering-services