Container Monitoring in Kubernetes

The current monitoring capabilities that can be deployed with magnum span through different components. These are:

  • metrics-server: is responsible for the API metrics.k8s.io requests. This includes the most basic functionality when using simple HPA metrics or when using the kubectl top command.

  • prometheus: is a full fledged service that allows the user to access advanced metrics capabilities. These metrics are collected with a resolution of 30 seconds and include resources such as CPU, Memory, Disk and Network IO as well as R/W rates. These metrics of fine granularity are available on your cluster for up to a period of 14 days (default).

  • prometheus-adapter: is an extra component that integrates with the prometheus service and allows a user to create more sophisticated HPA rules. The service integrates fully with the metrics.k8s.io API but at this time only custom.metrics.k8s.io is being actively used.

The installation of these services is controlled with the following labels:

metrics_server_enabled

metrics_server_enabled is used to enable disable the installation of the metrics server. To use this service tiller_enabled must be true when using helm_client_tag<v3.0.0. Train default: true Stein default: true

monitoring_enabled

Enable installation of cluster monitoring solution provided by the stable/prometheus-operator helm chart. To use this service tiller_enabled must be true when using helm_client_tag<v3.0.0. Default: false

prometheus_adapter_enabled

Enable installation of cluster custom metrics provided by the stable/prometheus-adapter helm chart. This service depends on monitoring_enabled. Default: true

To control deployed versions, extra labels are available:

metrics_server_chart_tag

Add metrics_server_chart_tag to select the version of the stable/metrics-server chart to install. Ussuri default: v2.8.8 Yoga default: v3.7.0

prometheus_operator_chart_tag

Add prometheus_operator_chart_tag to select version of the stable/prometheus-operator chart to install. When installing the chart, helm will use the default values of the tag defined and overwrite them based on the prometheus-operator-config ConfigMap currently defined. You must certify that the versions are compatible.

prometheus_adapter_chart_tag

The stable/prometheus-adapter helm chart version to use. Train-default: 1.4.0

Full fledged cluster monitoring

The prometheus installation provided with the monitoring_enabled label is in fact a multi component service. This installation is managed with the prometheus-operator helm chart and the constituent components are:

  • prometheus (data collection, storage and search)

    • node-exporter (data source for the kubelet/node)

    • kube-state-metrics (data source for the running kubernetes objects {deployments, pods, nodes, etc})

  • alertmanager (alarm aggregation, processing and dispatch)

  • grafana (metrics visualization)

These components are installed in a generic way that makes it easy to have a cluster wide monitoring infrastructure running with no effort.

Warning

The existent monitoring infra does not take into account the existence of nodegroups. If you plan to use nodegroups in your cluster you can take into account the maximum number of total nodes and use max_node_count to correctly setup the prometheus server.

Note

Before creating your cluster take into account the scale of the cluster. This is important as the Prometheus server pod might not fit your nodes. This is particularly important if you are using Cluster Autoscaling as the Prometheus server will schedule resources needed to meet the maximum number of nodes that your cluster can scale up to defined by label (if existent) max_node_count.

The Prometheus server will consume the following resources:

RAM:: 256 (base) + Nodes * 40 [MB]
CPU:: 128 (base) + Nodes * 7 [mCPU]
Disk:: 15 GB for 2 weeks (depends on usage)

Tuning parameters

The existent setup configurations allows you to tune the metric infrastructure to your requisites. Below is a list of labels that can be used for specific cases:

grafana_admin_passwd

This label lets users create their own admin user password for the Grafana interface. It expects a string value. Default: admin

monitoring_retention_days

This label lets users specify the maximum retention time for data collected in the prometheus server in days. Default: 14

monitoring_interval_seconds

This label lets users specify the time between metric samples in seconds. Default: 30

monitoring_retention_size

This label lets users specify the maximum size (in gigibytes) for data stored by the prometheus server. This label must be used together with monitoring_storage_class_name. Default: 14

monitoring_storage_class_name

The kubernetes storage class name to use for the prometheus pvc. Using this label will activate the usage of a pvc instead of local disk space. When using monitoring_storage_class_name 2 pvcs will be created. One for the prometheus server which size is set by monitoring_retention_size and one for grafana which is fixed at 1Gi. Default: “”

monitoring_ingress_enabled

This label set’s up all the underlying services to be accessible in a ‘route by path’ way. This means that the services will be exposed as:

my.domain.com/alertmanager
my.domain.com/prometheus
my.domain.com/grafana

This label must be used together with cluster_root_domain_name. Default: false

cluster_root_domain_name

The root domain name to use for the cluster automatically set up applications. Default: “localhost”

cluster_basic_auth_secret

The kubernetes secret to use for the proxy basic auth username and password for the unprotected services {alertmanager,prometheus}. Basic auth is only set up if this file is specified. The secret must be in the same namespace as the used proxy (kube-system). Default: “”

To create this secret you can do:
$ htpasswd -c auth foo
$ kubectl create secret generic basic-auth --from-file=auth
prometheus_adapter_configmap

The name of the prometheus-adapter rules ConfigMap to use. Using this label will overwrite the default rules. Default: “”