https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/Recent content in Platform Guide on Prometheus OperatorHugo -- gohugo.ioen-USTue, 06 Oct 2020 08:49:15 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/platform-guide/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/platform-guide/This guide assumes you have a basic understanding of the Prometheus Operator. If you are new to it, please start with the Introduction page before proceeding. This guide will walk you through deploying Prometheus and Alertmanager instances. Deploying Prometheus # To deploy a Prometheus instance, you must create the RBAC rules for the Prometheus service account. First, create a ServiceAccount for Prometheus. apiVersion: v1 kind: ServiceAccount metadata: name: prometheus Next, create a ClusterRole that grants Prometheus the necessary permissions to discover and scrape the targets within the cluster.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/exposing-prometheus-and-alertmanager/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/exposing-prometheus-and-alertmanager/Note: Starting with v0.39.0, Prometheus Operator requires use of Kubernetes v1.16.x and up. Exposing Prometheus and Alertmanager # The Prometheus Operator takes care of operating Prometheus and Alertmanagers clusters. Kubernetes provides several ways to expose these clusters to the outside world. This document outlines best practices and caveats for exposing Prometheus and Alertmanager clusters. NodePort # The easiest way to expose Prometheus or Alertmanager is to use a Service of type NodePort.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/webhook/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/webhook/This guide describes how to deploy and use the Prometheus operator’s admission webhook service. The admission webhook service is able to Validate requests ensuring that PrometheusRule and AlertmanagerConfig objects are semantically valid. Mutate requests enforcing that all annotations of PrometheusRule objects are coerced into string values. Convert AlertmanagerConfig objects between v1alpha1 and v1beta1 versions. This guide assumes that you have already deployed the Prometheus Operator and that admission controllers are enabled on your cluster.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/prometheus-agent/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/prometheus-agent/👉 Prometheus Operator >= v0.64.0 is required. As mentioned in Prometheus’s blog, Prometheus Agent is a deployment model optimized for environments where all collected data is forwarded to a long-term storage solution, e.g. Cortex, Thanos or Prometheus, that do not need storage or rule evaluation. First of all, make sure that the PrometheusAgent CRD is installed in the cluster and that the operator has the proper RBAC permissions to reconcile the PrometheusAgent resources.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/thanos/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/thanos/Thanos is a set of components that can be composed into a highly available, multi Prometheus metric system with potentially unlimited storage capacity, if your Object Storage allows for it. Before continuing with Prometheus Operator Thanos integration, it is recommended to read more about Thanos in the official documentation. What does the Prometheus Operator help with? # Prometheus Operator can manage: the Thanos sidecar component with the Prometheus custom resource definition.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/rbac/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/rbac/Role-based access control (RBAC) for the Prometheus Operator involves two parts, RBAC rules for the Operator itself and RBAC rules for the Prometheus Pods themselves created by the Operator as Prometheus requires access to the Kubernetes API for target and Alertmanager discovery. Prometheus Operator RBAC # In order for the Prometheus Operator to work in an RBAC based authorization environment, a ClusterRole with access to all the resources the Operator requires for the Kubernetes API needs to be created.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/rbac-crd/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/rbac-crd/Aggregated ClusterRoles # It can be useful to aggregate permissions on the Prometheus Operator CustomResourceDefinitions to the default user-facing roles, like view, edit and admin. This can be achieved using aggregated ClusterRoles. This lets admins include rules for custom resources, such as those served by CustomResourceDefinitions or Aggregated API servers, on the default roles. Note: ClusterRole aggregation is available starting Kubernetes 1.9. Example # In order to aggregate read (resp. edit) permissions for the Prometheus Operator CustomResourceDefinitions to the view (resp.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/high-availability/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/high-availability/High availability is not only important for customer facing software, but if the monitoring infrastructure is not highly available, then there is a risk that operations people are not notified for alerts of the customer facing software. Therefore high availability must be just as thought through for the monitoring stack, as for anything else. Prometheus # To run Prometheus in a highly available manner, two (or more) instances need to be running with the same configuration except that they will have one external label with a different value to identify them.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/storage/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/storage/By default, the operator configures Pods to store data on emptyDir volumes which aren’t persisted when the Pods are redeployed. To maintain data across deployments and version upgrades, you can configure persistent storage for Prometheus, Alertmanager and ThanosRuler resources. Kubernetes supports several kinds of storage volumes. The Prometheus Operator works with PersistentVolumeClaims, which support the underlying PersistentVolume to be provisioned when requested. This document assumes a basic understanding of PersistentVolumes, PersistentVolumeClaims, and their provisioning.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/strategic-merge-patch/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/platform/strategic-merge-patch/This document describes how to overwrite the configuration generated by the operator using strategic merge patches. When users need to apply a specific configuration to the containers that is either not exposed in the custom resource definitions or already defined by the operator, strategic merge patch can be used. How does it work? # The Prometheus, Alertmanager, and ThanosRuler CRDs expose a spec.containers field which allows to: Override fields for the containers generated by the operator.