Conversation
baumeister25
left a comment
baumeister25
left a comment
There was a problem hiding this comment.
My first impression is very good. I think it could be here and there more crisp on the details such as What exacly are you solving, what are the requirements and basic. Bullet point lists could make this more clear sometimes
I've stopped at reading the yaml files and will continue there later
| //Abstract | ||
| == Core elements of the problem and its solution | ||
|
|
||
| Standardization of communication in a kubernetes cluster between different microservices. Subsequent monitoring with Prometheus and Grafana. |
There was a problem hiding this comment.
I would leave out this sentences. and instead take the block from below (l. 27ff)
|
|
||
| We used the following tools to solve the problem: | ||
|
|
||
| * Rancher (Docker) |
There was a problem hiding this comment.
I would leave out Rancher I guess.
Maybe it could be a sidenote somewhere that rancher was used for local testing
| Our solution is tailored for when istio is running on the existing cluster and monitoring of the various microservices is attempted. | ||
| We are in an environment of docker, kubernetes, microservices and istio. The idea here is that a cluster consists of microservices and runs with docker over kubernetes. Now, we want to maintain the communication between the individual microservices uniformly by default. In addition, we would like to find a way how we can monitor our cluster with the individual microservices and accordingly make some analyses via prometheus or grafana. Now we present a solution following for how we have implemented this scenario. Our final project was a cluster with three different namespaces: Istio, Application and Monitoring. On the Istio namespace the normal istio system is running and the solution was tested with the default demo https://istio.io/latest/docs/setup/additional-setup/config-profiles/[profile]. The application namespace runs all microservices and the monitoring namespace is where we want to do the monitoring. |
There was a problem hiding this comment.
In generall I like this as an abstract.
But I would tailor this solution only on one key aspect.
This abstract explains 2 topics (communication management and monitoring). That's kind of unexpected, because the title is all about monitoring.
There was a problem hiding this comment.
Even though, communication management comes for free, this would be a separate solution snippet.
Maybe you could think of parts in the docu that are valid for both?!
| Assumed is a kubernernetes cluster with istio installed and running microservices. We will continuously show how you can monitor your cluster with the microservices using prometheus/grafana and how you can split the tasks into different namespaces. | ||
| The prerequisite is that there is a Kubernetes cluster with microservices and istio is already running on it. In case istio isn't installed already check https://istio.io/latest/docs/setup/getting-started/#download[here]. Adapt the walkthrough of deploying the sample application to deploy your own application and you will need a gateway that exposes your application to incoming traffic. If your existing application doesn't satisfy this requirement you can setup an istio ingress-gateway by following this https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/[link] and adapt the configuration to your needs. We offer a basic xref:Files/ingressgateway.yaml[ingressgateway.yaml] for this step but the configuration varies drastically depending on your specific application. Configuring an istio-ingressgateway or any other gateway is most likely mandatory but out of scope for this solution. Therefor we only covered the bare minimum. |
There was a problem hiding this comment.
For me this part seems a bit chaotic.
I would make it very clear with own subchapters inside introduction.
Prerequisites and requirements (maybe even split those two if it makes sense)
A bullet point list of prerequisites (kubernetes running with istio. Link to installation,
Microservices seems to have some Requirements
Goals
What are the goals of this solution?
Monitoring of what exaclty?
|
|
||
| //Context and Scope | ||
| == Context and Scope | ||
| Since this solution is tailored towards an existing application you may have gateways (like Kubernetes Virtual Service) configured that expose your application to outside traffic already. With Istio you can define traffic routes and destination rules inside your cluster. Monitoring with Istio will help you to analyze the performance of your cluster regardless of your gateway cofiguration. Just note that configuring an ingress-gateway will enable other benefits that are likely going to influence the monitoring of your application. |
There was a problem hiding this comment.
Would be more the goals in my eyes
|
|
||
| //Solution Strategy | ||
| == Solution Strategy | ||
| The setup of the namespace *istio-system* is indirectly already done, because istio is already installed on our system and therefore the namespace is created automatically. The next namespace where we don't have to care much is the *application* namespace, there we only have to add all our microservices which run in our cluster. |
| kubectl label namespace monitoring istio-injection=enabled | ||
| ``` | ||
| The namespace with the *monitoring* will be a bit more complex, because we have to adjust the config files of Prometheus and Grafana. We have oriented ourselves as it can be seen in this https://istiobyexample.dev/prometheus/[example] + | ||
| *(1) Grafana Monitoring Namespace* - Part 1 |
There was a problem hiding this comment.
Maybe you could document some of the yamls to explain what they're used for
2 participants
What we will add more: