https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/Recent content in Implemented Proposals on Prometheus OperatorHugo -- gohugo.ioen-USTue, 06 Oct 2020 08:49:15 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/prometheus-agent/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/prometheus-agent/Status # Implemented Summary # The Prometheus 2.32.0 release introduces the Prometheus Agent, a mode optimized for remote-write dominant scenarios. This document proposes extending the Prometheus Operator to allow running a Prometheus Agent with different deployment strategies. Background # The Prometheus Operator in its current state does not allow a simple way of deploying the Prometheus agent. A potential workaround has been described in a Github comment, where the agent can be deployed through the existing Prometheus CRD by explicitly setting command-line arguments specific to the agent mode.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/scrape-config/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/scrape-config/Owners: xiu Status: Implemented Related Tickets: #2787 #3447 Other docs: n/a This document aims at creating a lower level ScrapeConfig Custom Resource Definition that defines additional scrape configurations the Kubernetes way. Why # prometheus-operator misses a way to scrape external targets using CRD. Users have either been abusing the Probe CRD (#3447) or additionalScrapeConfig to do so. Multiple use cases have been reported: A user reported in the contributor office hours that their team serves Prometheus as a service to several teams across multiple regions.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/scrapeclasses/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/scrapeclasses/Owners: nicolastakashi eronwright Status: Implemented Related Tickets: https://github.com/prometheus-operator/prometheus-operator/issues/4121 https://github.com/prometheus-operator/prometheus-operator/issues/3922 https://github.com/prometheus-operator/prometheus-operator/issues/5947 https://github.com/prometheus-operator/prometheus-operator/issues/5948 This proposal introduces the concept of scrape classes, enabling users to utilize scrape configuration data provided by the administrator, through scrape objects such as PodMonitor, Probe, ServiceMonitor and ScrapeConfig. Why # Sometimes Prometheus administrators needs to provide default configurations for scrape objects, such as the definition of TLS certificates, when running Prometheus to scrape pods in an Istio mesh with strict mTLS as described in Istio documentation.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/controller-id/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/controller-id/Owners: danielmellado Status: Implemented Related Tickets: #4281 #4498 Other Docs: n/a Introduction # This proposal aims to implement a solution to support multiple cluster-level Prometheus instances running concurrently without conflicting over the same custom resources. This solution isn’t limited to the Prometheus resources as it’ll also be available for AlertManagerand ThanosRuler ones, as well as for any pod-based resource that could be added in the future. This issue can significantly impact use cases where multiple Prometheus operator instances run at the same time in the Kubernetes cluster.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/docs-restructuring/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/docs-restructuring/Owners: AshwinSriram11 Status: Implemented Related Tickets: #3553 #6046 Other docs: N/A This document proposes restructuring the documentation of the Prometheus-Operator website, aiming for better content organization and better experience for new users and old veterans. Why # Restructuring the documentation will help in improving user experience and may save time for a user to search for relevant information effectively. This will encourage a newcomer to get familiar with the project in an efficient manner.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/status-subresource/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/implemented/status-subresource/Owners: simonpasquier Status: Implemented Related Tickets: #3335 Other docs: N/A This proposal describes how we will extend the Prometheus operator workload Custom Resource Definitions (CRDs) with a Status subresource field. Why # Core Kubernetes resources differentiate between the desired state of an object (the spec field) and the current status of the object (the status field) details. Before this proposal, the current status of the objects was never reflected by the Prometheus operator which makes it harder for external actors to know if the underlying resource is available or not.