- Prometheus should run as close to its scrape targets as possible for reliability and performance.
- You can reuse existing Kubernetes infrastructure instead of managing a separate VM or external host.

- Application monitoring — web apps, services, databases, custom application metrics.
- Cluster monitoring — API server, scheduler, kubelets, node OS metrics, and Kubernetes object state.
- API Server, kube-scheduler, CoreDNS, and other control-plane components.
- kubelet (exposes cAdvisor-style container metrics).
kube-state-metrics(converts Kubernetes API objects into Prometheus metrics).- Node Exporter on each node to collect OS-level metrics (CPU, memory, disk, network).

- Kubernetes does not expose higher-level cluster objects (Deployments, ReplicaSets, Services, etc.) as Prometheus metrics by default.
kube-state-metricswatches the Kubernetes API and exposes metrics derived from those objects for Prometheus to scrape. It runs as a normal Pod in the cluster and is the standard way to gather cluster state.
- For OS-level metrics, run a Node Exporter on each host. In Kubernetes, the recommended pattern is to deploy Node Exporter as a DaemonSet so a pod runs on every node (including new nodes as they join).

- Prometheus integrates with Kubernetes Service Discovery: it queries the Kubernetes API to discover scrape targets (control-plane endpoints, kubelet/node-exporters,
kube-state-metrics, application Services, etc.). This removes the need for manually maintaining endpoint lists.

- You can deploy Prometheus manually by creating Deployments, StatefulSets, Services, ConfigMaps, and Secrets, but this approach is verbose, repetitive, and error-prone for production-grade setups.

- Helm is the de facto package manager for Kubernetes that packages manifests, templates, and configuration into charts.
- The Prometheus Community chart
kube-prometheus-stackpackages a complete, production-ready Prometheus stack tuned for Kubernetes.

- The chart deploys a complete monitoring stack for Kubernetes: Prometheus Server, Alertmanager, Pushgateway, Grafana (optional), and the Prometheus Operator that manages lifecycle and configuration.

- The operator handles lifecycle tasks: installation, configuration, upgrades, rolling restarts on config changes, and resource ownership.
- Using the operator replaces the need to manage multiple low-level objects by offering higher-level CRs such as
Prometheus,ServiceMonitor,PodMonitor,PrometheusRule, andAlertmanager.

- Instead of creating StatefulSets or Deployments directly, you declare a
Prometheuscustom resource that the operator translates into the required Kubernetes primitives.
ServiceMonitor and PodMonitor
- Use
ServiceMonitorandPodMonitorobjects to declare scrape targets in a Kubernetes-native way. This avoids editing Prometheus config directly and integrates cleanly with Kubernetes RBAC and namespaces.
Using the kube-prometheus-stack chart plus the Prometheus Operator provides a Kubernetes-native, declarative approach to deploy and manage Prometheus, Alertmanager, and related resources with far less manual YAML and maintenance overhead.
- Prometheus Operator — https://github.com/prometheus-operator/prometheus-operator
- kube-prometheus-stack chart — https://github.com/prometheus-community/helm-charts
- Kubernetes documentation — https://kubernetes.io/docs/
- kube-state-metrics — https://github.com/kubernetes/kube-state-metrics
- Helm documentation — https://helm.sh/docs/