A set of extensible configs for running Prometheus on Kubernetes.
Usage:
-
Make sure you have Tanka and jsonnet-bundler installed:
-
In your config repo, init Tanka with
k8s-alpha
and point it at your Kubernetes cluster:
# set up Tanka project, we will install k8s ourselves
tk init --k8s=false
# pull k8s-alpha for Kubernetes 1.18
jb install github.com/jsonnet-libs/k8s-alpha/1.18
# init k.libsonnet
cat <<EOF > lib/k.libsonnet
(import "github.com/jsonnet-libs/k8s-alpha/1.18/main.libsonnet")
+ (import "github.com/jsonnet-libs/k8s-alpha/1.18/extensions/kausal-shim.libsonnet")
EOF
# point at cluster
export CONTEXT=$(kubectl config current-context)
tk env set environments/default --server-from-context=$CONTEXT
- Vendor this package using jsonnet-bundler:
jb install github.com/grafana/jsonnet-libs/prometheus-ksonnet
- Assuming you want to run in the default namespace ('environment' in Tanka parlance), add the following to the file
environments/default/main.jsonnet
:
cat <<EOF > environments/default/main.jsonnet
local prometheus = import "prometheus-ksonnet/prometheus-ksonnet.libsonnet";
prometheus {
_config+:: {
cluster_name: "cluster1",
namespace: "default",
},
}
EOF
- Apply your config:
tk apply environments/default
If you made your Kubernetes cluster with Kops, add the Kops mixin to your config to scrape the Kubernetes system components:
local prometheus = import "prometheus-ksonnet/prometheus-ksonnet.libsonnet";
local kops = import "prometheus-ksonnet/lib/prometheus-config-kops.libsonnet";
prometheus + kops {
_config+:: {
namespace: "default",
insecureSkipVerify: true,
},
}
The choice of Tanka for configuring these jobs was intentional; it allows users to easily override setting in these configurations to suit their needs, without having to fork or modify this library. For instance, to override the resource requests and limits for the Prometheus container, you would:
local prometheus = import "prometheus-ksonnet/prometheus-ksonnet.libsonnet";
prometheus {
prometheus_container+::
$.util.resourcesRequests("1", "2Gi") +
$.util.resourcesLimits("2", "4Gi"),
}
We sometimes specify config options in a _config
dict; there are two situations
under which we do this:
- When you must provide a value for the parameter (such as
namesapce
). - When the parameter get referenced in multiple places, and overriding it using
the technique above would be cumbersome and error prone (such as with
cluster_dns_suffix
).
We use these two guidelines for when to put parameters in _config
as otherwise
the config field would just become the same as the jobs it declares - and lets
not forget, this whole thing is config - so its completely acceptable to override
pretty much any of it.