Add cluster monitoring to the monitoring stack

[sidharthanup]

The monitoring stack in GCS currently only gives us metrics obtained from the gluster-exporter. It should also pick up node level metrics and cluster level metrics that can be obtained from node-exporter and kube-state-metrics exporter respectively. Also it should report metrics on the prometheus operator also as the operator by default exposes metrics that can be scraped by the deployed prometheus server.

[sidharthanup]

In the PR, I have removed the monitoring namespace and relocated the monitoring objects in the gcs namespace itself. Is a separate namespace for monitoring necessary? Functionality wise there is no issues in having it in gcs namespace only. Architecturally is there any advantage in having a separate monitoring namespace where the monitoring stack resides?
@JohnStrunk @Madhu-1 Your thoughts?
Will revert back to previous model if it is an issue.

[JohnStrunk]

If the components are "things we would deploy as a part of gcs" (i.e., they would be deployed if and only if GCS is deployed), they should be in the gcs namespace.

If there are components that we are deploying because we need to make use of them, but any reasonable cluster would be providing that for us, it should probably go elsewhere. (example: etcd-operator would be provided by OLM... we should move it).

My rationale here is that a namespace is the way of grouping things, and it has a security boundary. When deployed in production, the RBAC rules will limit us to our own namespace (unless we have a really good reason). Also, cleaning up our components is just: kubectl delete ns/gcs

[sidharthanup]

Ack. The prometheus operator would be provided by OLM as well(For now I'm putting it in the gcs namespace) . The rest of the components can be in the same namespace itself.