mirror of https://git.rancher.io/charts
6.3 KiB
6.3 KiB
Changelog
All notable changes from the upstream Prometheus Operator chart will be added to this file.
[Package Version 00] - 2020-07-19
Added
- Added Prometheus Adapter as a dependency to the upstream Prometheus Operator chart to allow users to expose custom metrics from the default Prometheus instance deployed by this chart
- Remove
prometheus-operator/cleanup-crds.yaml
andprometheus-operator/crds.yaml
from the Prometheus Operator upstream chart in favor of just using the CRD directory to install the CRDs. - Added support for
rkeControllerManager
,rkeScheduler
,rkeProxy
, andrkeEtcd
PushProx exporters for monitoring k8s components within RKE clusters - Added support for
k3sControllerManager
,k3sScheduler
, andk3sProxy
PushProx exporters for monitoring k8s components within k3s clusters - Added support for
kubeAdmControllerManager
,kubeAdmScheduler
,kubeAdmProxy
, andkubeAdmEtcd
PushProx exporters for monitoring k8s components within kubeAdm clusters - Exposed
prometheus.prometheusSpec.ignoreNamespaceSelectors
on values.yaml and set it totrue
by default. This value instructs the default Prometheus server deployed with this chart to ignore thenamespaceSelector
field within any created ServiceMonitor or PodMonitor CRs that it selects. This prevents ServiceMonitors and PodMonitors from configuring the Prometheus scrape configuration to monitor resources outside the namespace that they are deployed in; if a user needs to have one ServiceMonitor / PodMonitor monitor resources within several namespaces, they will need to either disable this default option or create one ServiceMonitor / PodMonitor CR per namespace that they would like to monitor. Relevant fields were also updated in the default README.md - Added
grafana.sidecar.dashboards.searchNamespace
to values.yaml with a default value ofgrafana-dashboards
. The namespace provided should contain all ConfigMaps with the labelgrafana_dashboard
and will be searched by the Grafana Dashboards sidecar for updates. The namespace specified is also created along with this deployment. All default dashboard ConfigMaps have been relocated from the deployment namespace to the namespace specified - Added
grafana.sidecar.datasources.searchNamespace
to values.yaml with a default value ofgrafana-datasources
. The namespace provided should contain all ConfigMaps with the labelgrafana_datasource
and will be searched by the Grafana Datasources sidecar for updates. The namespace specified is also created along with this deployment. All default datasource ConfigMaps have been relocated from the deployment namespace to the namespace specified - Added
monitoring-admin
,monitoring-edit
, andmonitoring-view
defaultClusterRoles
to allow admins to assign roles to users to interact with Prometheus Operator CRs. These can be enabled by setting.Values.global.rbac.userRoles.create
(default:true
). In a typical RBAC setup, you might want to assign specific usersmonitoring-edit
ormonitoring-view
within a specific namespace to allow them to set upServiceMonitors
/PodMonitors
that only monitor resources within that namespace. If.Values.global.rbac.userRoles.aggregateRolesForRBAC
is enabled, these ClusterRoles will aggregate into the respective default ClusterRoles provided by Kubernetes - Added
grafana-config-edit
andgrafana-config-view
defaultClusterRoles
to allow admins to assign roles to users to interact with Secrets or ConfigMaps utilized by Grafana. These can be enabled by setting.Values.global.rbac.userRoles.create
(default:true
). In a typical RBAC setup, you might want to assign the following users with these permissions:- User who needs to be able to persist custom Grafana dashboards from the Grafana UI but does not need to be able to interact with Prometheus CRs:
grafana-config-edit
within the.Values.grafana.sidecar.dashboards.searchNamespace
(defaultgrafana-dashboards
) namespace - User who needs to be able to persist new Grafana datasources but does not need to be able to interact with Prometheus CRs:
.Values.grafana.sidecar.datasources.searchNamespace
(defaultgrafana-datasources
) namespace
- User who needs to be able to persist custom Grafana dashboards from the Grafana UI but does not need to be able to interact with Prometheus CRs:
- Added default resource limits for
Prometheus Operator
,Prometheus
,AlertManager
,Grafana
,kube-state-metrics
,node-exporter
Modified
- Updated the chart name from
prometheus-operator
torancher-monitoring
and added theio.rancher.certified: rancher
annotation toChart.yaml
- Modified the default
node-exporter
port from9100
to9796
- Modified the default
nameOverride
torancher-monitoring
. This change is necessary as the Prometheus Adapter's default URL (http://{{ .Values.nameOverride }}-prometheus.{{ .Values.namespaceOverride }}.svc
) is based off of the value used here; if modified, the default Adapter URL must also be modified - Modified the default
namespaceOverride
tocattle-monitoring-system
. This change is necessary as the Prometheus Adapter's default URL (http://{{ .Values.nameOverride }}-prometheus.{{ .Values.namespaceOverride }}.svc
) is based off of the value used here; if modified, the default Adapter URL must also be modified - Configured some default values for
grafana.service
values and exposed them in the default README.md - The default namespaces the following ServiceMonitors were changed from the deployment namespace to allow them to continue to monitor metrics when
prometheus.prometheusSpec.ignoreNamespaceSelectors
is enabled:core-dns
:kube-system
api-server
:default
kube-controller-manager
:kube-system
kubelet
:{{ .Values.kubelet.namespace }}
- Disabled the following deployments by default (can be enabled if required):
AlertManager
kube-controller-manager
metrics exporterkube-etcd
metrics exporterkube-scheduler
metrics exporterkube-proxy
metrics exporter
- Updated default Grafana
deploymentStrategy
toRecreate
to prevent deployments from being stuck on upgrade if a PV is attached to Grafana - Modified the default
<serviceMonitor|podMonitor|rule>SelectorNilUsesHelmValues
to default tofalse
. As a result, we look for all CRs with any labels in all namespaces by default rather than just the ones tagged with the labelrelease: rancher-monitoring
.