Merge pull request #1453 from saswatamcode/add-mdox
This commit is contained in:
11
.github/workflows/ci.yaml
vendored
11
.github/workflows/ci.yaml
vendored
@@ -22,6 +22,17 @@ jobs:
|
||||
with:
|
||||
go-version: ${{ env.golang-version }}
|
||||
- run: make --always-make generate validate && git diff --exit-code
|
||||
check-docs:
|
||||
runs-on: ubuntu-latest
|
||||
name: Check Documentation formatting and links
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
with:
|
||||
persist-credentials: false
|
||||
- uses: actions/setup-go@v2
|
||||
with:
|
||||
go-version: ${{ env.golang-version }}
|
||||
- run: make check-docs
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
name: Jsonnet linter
|
||||
|
||||
9
.mdox.validate.yaml
Normal file
9
.mdox.validate.yaml
Normal file
@@ -0,0 +1,9 @@
|
||||
version: 1
|
||||
|
||||
validators:
|
||||
# Ignore localhost links.
|
||||
- regex: 'localhost'
|
||||
type: "ignore"
|
||||
# Ignore release links.
|
||||
- regex: 'https:\/\/github\.com\/prometheus-operator\/kube-prometheus\/releases'
|
||||
type: "ignore"
|
||||
24
Makefile
24
Makefile
@@ -2,29 +2,39 @@ SHELL=/bin/bash -o pipefail
|
||||
|
||||
BIN_DIR?=$(shell pwd)/tmp/bin
|
||||
|
||||
EMBEDMD_BIN=$(BIN_DIR)/embedmd
|
||||
MDOX_BIN=$(BIN_DIR)/mdox
|
||||
JB_BIN=$(BIN_DIR)/jb
|
||||
GOJSONTOYAML_BIN=$(BIN_DIR)/gojsontoyaml
|
||||
JSONNET_BIN=$(BIN_DIR)/jsonnet
|
||||
JSONNETLINT_BIN=$(BIN_DIR)/jsonnet-lint
|
||||
JSONNETFMT_BIN=$(BIN_DIR)/jsonnetfmt
|
||||
KUBECONFORM_BIN=$(BIN_DIR)/kubeconform
|
||||
TOOLING=$(EMBEDMD_BIN) $(JB_BIN) $(GOJSONTOYAML_BIN) $(JSONNET_BIN) $(JSONNETLINT_BIN) $(JSONNETFMT_BIN) $(KUBECONFORM_BIN)
|
||||
TOOLING=$(JB_BIN) $(GOJSONTOYAML_BIN) $(JSONNET_BIN) $(JSONNETLINT_BIN) $(JSONNETFMT_BIN) $(KUBECONFORM_BIN) $(MDOX_BIN)
|
||||
|
||||
JSONNETFMT_ARGS=-n 2 --max-blank-lines 2 --string-style s --comment-style s
|
||||
|
||||
all: generate fmt test
|
||||
MDOX_VALIDATE_CONFIG?=.mdox.validate.yaml
|
||||
MD_FILES_TO_FORMAT=$(shell find docs developer-workspace examples experimental jsonnet manifests -name "*.md") $(shell ls *.md)
|
||||
|
||||
all: generate fmt test docs
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
# Remove all files and directories ignored by git.
|
||||
git clean -Xfd .
|
||||
|
||||
.PHONY: generate
|
||||
generate: manifests **.md
|
||||
.PHONY: docs
|
||||
docs: $(MDOX_BIN) $(shell find examples) build.sh example.jsonnet
|
||||
@echo ">> formatting and local/remote links"
|
||||
$(MDOX_BIN) fmt --soft-wraps -l --links.localize.address-regex="https://prometheus-operator.dev/.*" --links.validate.config-file=$(MDOX_VALIDATE_CONFIG) $(MD_FILES_TO_FORMAT)
|
||||
|
||||
**.md: $(EMBEDMD_BIN) $(shell find examples) build.sh example.jsonnet
|
||||
$(EMBEDMD_BIN) -w `find . -name "*.md" | grep -v vendor`
|
||||
.PHONY: check-docs
|
||||
check-docs: $(MDOX_BIN) $(shell find examples) build.sh example.jsonnet
|
||||
@echo ">> checking formatting and local/remote links"
|
||||
$(MDOX_BIN) fmt --soft-wraps --check -l --links.localize.address-regex="https://prometheus-operator.dev/.*" --links.validate.config-file=$(MDOX_VALIDATE_CONFIG) $(MD_FILES_TO_FORMAT)
|
||||
|
||||
.PHONY: generate
|
||||
generate: manifests
|
||||
|
||||
manifests: examples/kustomize.jsonnet $(GOJSONTOYAML_BIN) vendor
|
||||
./build.sh $<
|
||||
|
||||
84
README.md
84
README.md
@@ -80,8 +80,8 @@ You will need a Kubernetes cluster, that's it! By default it is assumed, that th
|
||||
|
||||
This means the kubelet configuration must contain these flags:
|
||||
|
||||
* `--authentication-token-webhook=true` This flag enables, that a `ServiceAccount` token can be used to authenticate against the kubelet(s). This can also be enabled by setting the kubelet configuration value `authentication.webhook.enabled` to `true`.
|
||||
* `--authorization-mode=Webhook` This flag enables, that the kubelet will perform an RBAC request with the API to determine, whether the requesting entity (Prometheus in this case) is allowed to access a resource, in specific for this project the `/metrics` endpoint. This can also be enabled by setting the kubelet configuration value `authorization.mode` to `Webhook`.
|
||||
* `--authentication-token-webhook=true` This flag enables, that a `ServiceAccount` token can be used to authenticate against the kubelet(s). This can also be enabled by setting the kubelet configuration value `authentication.webhook.enabled` to `true`.
|
||||
* `--authorization-mode=Webhook` This flag enables, that the kubelet will perform an RBAC request with the API to determine, whether the requesting entity (Prometheus in this case) is allowed to access a resource, in specific for this project the `/metrics` endpoint. This can also be enabled by setting the kubelet configuration value `authorization.mode` to `Webhook`.
|
||||
|
||||
This stack provides [resource metrics](https://github.com/kubernetes/metrics#resource-metrics-api) by deploying the [Prometheus Adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter/).
|
||||
This adapter is an Extension API Server and Kubernetes needs to be have this feature enabled, otherwise the adapter has no effect, but is still deployed.
|
||||
@@ -116,12 +116,12 @@ The following versions are supported and work as we test against these versions
|
||||
|
||||
## Quickstart
|
||||
|
||||
>Note: For versions before Kubernetes v1.21.z refer to the [Kubernetes compatibility matrix](#kubernetes-compatibility-matrix) in order to choose a compatible branch.
|
||||
> Note: For versions before Kubernetes v1.21.z refer to the [Kubernetes compatibility matrix](#kubernetes-compatibility-matrix) in order to choose a compatible branch.
|
||||
|
||||
This project is intended to be used as a library (i.e. the intent is not for you to create your own modified copy of this repository).
|
||||
|
||||
Though for a quickstart a compiled version of the Kubernetes [manifests](manifests) generated with this library (specifically with `example.jsonnet`) is checked into this repository in order to try the content out quickly. To try out the stack un-customized run:
|
||||
* Create the monitoring stack using the config in the `manifests` directory:
|
||||
* Create the monitoring stack using the config in the `manifests` directory:
|
||||
|
||||
```shell
|
||||
# Create the namespace and CRDs, and then wait for them to be available before creating the remaining resources
|
||||
@@ -135,7 +135,8 @@ Alternatively, the resources in both folders can be applied with a single comman
|
||||
`kubectl create -f manifests/setup -f manifests`, but it may be necessary to run the command multiple times for all components to
|
||||
be created successfullly.
|
||||
|
||||
* And to teardown the stack:
|
||||
* And to teardown the stack:
|
||||
|
||||
```shell
|
||||
kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup
|
||||
```
|
||||
@@ -173,14 +174,15 @@ Then access via [http://localhost:9093](http://localhost:9093)
|
||||
## Customizing Kube-Prometheus
|
||||
|
||||
This section:
|
||||
* describes how to customize the kube-prometheus library via compiling the kube-prometheus manifests yourself (as an alternative to the [Quickstart section](#Quickstart)).
|
||||
* still doesn't require you to make a copy of this entire repository, but rather only a copy of a few select files.
|
||||
* describes how to customize the kube-prometheus library via compiling the kube-prometheus manifests yourself (as an alternative to the [Quickstart section](#quickstart)).
|
||||
* still doesn't require you to make a copy of this entire repository, but rather only a copy of a few select files.
|
||||
|
||||
### Installing
|
||||
|
||||
The content of this project consists of a set of [jsonnet](http://jsonnet.org/) files making up a library to be consumed.
|
||||
|
||||
Install this library in your own project with [jsonnet-bundler](https://github.com/jsonnet-bundler/jsonnet-bundler#install) (the jsonnet package manager):
|
||||
|
||||
```shell
|
||||
$ mkdir my-kube-prometheus; cd my-kube-prometheus
|
||||
$ jb init # Creates the initial/empty `jsonnetfile.json`
|
||||
@@ -196,6 +198,7 @@ $ wget https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/rel
|
||||
> An e.g. of how to install a given version of this library: `jb install github.com/prometheus-operator/kube-prometheus/jsonnet/kube-prometheus@release-0.7`
|
||||
|
||||
In order to update the kube-prometheus dependency, simply use the jsonnet-bundler update functionality:
|
||||
|
||||
```shell
|
||||
$ jb update
|
||||
```
|
||||
@@ -210,8 +213,7 @@ Here's [example.jsonnet](example.jsonnet):
|
||||
|
||||
> Note: some of the following components must be configured beforehand. See [configuration](#configuration) and [customization-examples](#customization-examples).
|
||||
|
||||
[embedmd]:# (example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat example.jsonnet"
|
||||
local kp =
|
||||
(import 'kube-prometheus/main.libsonnet') +
|
||||
// Uncomment the following imports to enable its patches
|
||||
@@ -250,8 +252,7 @@ local kp =
|
||||
|
||||
And here's the [build.sh](build.sh) script (which uses `vendor/` to render all manifests in a json structure of `{filename: manifest-content}`):
|
||||
|
||||
[embedmd]:# (build.sh)
|
||||
```sh
|
||||
```sh mdox-exec="cat build.sh"
|
||||
#!/usr/bin/env bash
|
||||
|
||||
# This script uses arg $1 (name of *.jsonnet file to use) to generate the manifests/*.yaml files.
|
||||
@@ -282,6 +283,7 @@ rm -f kustomization
|
||||
This script runs the jsonnet code, then reads each key of the generated json and uses that as the file name, and writes the value of that key to that file, and converts each json manifest to yaml.
|
||||
|
||||
### Apply the kube-prometheus stack
|
||||
|
||||
The previous steps (compilation) has created a bunch of manifest files in the manifest/ folder.
|
||||
Now simply use `kubectl` to install Prometheus and Grafana as per your configuration:
|
||||
|
||||
@@ -290,6 +292,7 @@ Now simply use `kubectl` to install Prometheus and Grafana as per your configura
|
||||
$ kubectl apply -f manifests/setup
|
||||
$ kubectl apply -f manifests/
|
||||
```
|
||||
|
||||
Alternatively, the resources in both folders can be applied with a single command
|
||||
`kubectl apply -Rf manifests`, but it may be necessary to run the command multiple times for all components to
|
||||
be created successfullly.
|
||||
@@ -299,15 +302,18 @@ Check the monitoring namespace (or the namespace you have specific in `namespace
|
||||
### Containerized Installing and Compiling
|
||||
|
||||
If you don't care to have `jb` nor `jsonnet` nor `gojsontoyaml` installed, then use `quay.io/coreos/jsonnet-ci` container image. Do the following from this `kube-prometheus` directory:
|
||||
|
||||
```shell
|
||||
$ docker run --rm -v $(pwd):$(pwd) --workdir $(pwd) quay.io/coreos/jsonnet-ci jb update
|
||||
$ docker run --rm -v $(pwd):$(pwd) --workdir $(pwd) quay.io/coreos/jsonnet-ci ./build.sh example.jsonnet
|
||||
```
|
||||
|
||||
## Update from upstream project
|
||||
|
||||
You may wish to fetch changes made on this project so they are available to you.
|
||||
|
||||
### Update jb
|
||||
|
||||
`jb` may have been updated so it's a good idea to get the latest version of this binary:
|
||||
|
||||
```shell
|
||||
@@ -315,14 +321,16 @@ $ go get -u github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb
|
||||
```
|
||||
|
||||
### Update kube-prometheus
|
||||
|
||||
The command below will sync with upstream project:
|
||||
|
||||
```shell
|
||||
$ jb update
|
||||
```
|
||||
|
||||
### Compile the manifests and apply
|
||||
Once updated, just follow the instructions under "Compiling" and "Apply the kube-prometheus stack" to apply the changes to your cluster.
|
||||
|
||||
Once updated, just follow the instructions under "Compiling" and "Apply the kube-prometheus stack" to apply the changes to your cluster.
|
||||
|
||||
## Configuration
|
||||
|
||||
@@ -343,7 +351,8 @@ Configuration is mainly done in the `values` map. You can see this being used in
|
||||
},
|
||||
```
|
||||
|
||||
The grafana definition is located in a different project (https://github.com/brancz/kubernetes-grafana), but needed configuration can be customized from the same top level `values` field. For example to allow anonymous access to grafana, add the following `values` section:
|
||||
The grafana definition is located in a different project (https://github.com/brancz/kubernetes-grafana ), but needed configuration can be customized from the same top level `values` field. For example to allow anonymous access to grafana, add the following `values` section:
|
||||
|
||||
```
|
||||
grafana+:: {
|
||||
config: { // http://docs.grafana.org/installation/configuration/
|
||||
@@ -373,8 +382,7 @@ A common example is that not all Kubernetes clusters are created exactly the sam
|
||||
|
||||
These mixins are selectable via the `platform` field of kubePrometheus:
|
||||
|
||||
[embedmd]:# (examples/jsonnet-snippets/platform.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/jsonnet-snippets/platform.jsonnet"
|
||||
(import 'kube-prometheus/main.libsonnet') +
|
||||
{
|
||||
values+:: {
|
||||
@@ -406,8 +414,7 @@ The output of this command can be piped to a shell to be executed by appending `
|
||||
|
||||
Then to generate manifests with `internal-registry.com/organization`, use the `withImageRepository` mixin:
|
||||
|
||||
[embedmd]:# (examples/internal-registry.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/internal-registry.jsonnet"
|
||||
local mixin = import 'kube-prometheus/addons/config-mixins.libsonnet';
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
@@ -430,8 +437,7 @@ local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
|
||||
Another mixin that may be useful for exploring the stack is to expose the UIs of Prometheus, Alertmanager and Grafana on NodePorts:
|
||||
|
||||
[embedmd]:# (examples/jsonnet-snippets/node-ports.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/jsonnet-snippets/node-ports.jsonnet"
|
||||
(import 'kube-prometheus/main.libsonnet') +
|
||||
(import 'kube-prometheus/addons/node-ports.libsonnet')
|
||||
```
|
||||
@@ -440,8 +446,7 @@ Another mixin that may be useful for exploring the stack is to expose the UIs of
|
||||
|
||||
To give another customization example, the name of the `Prometheus` object provided by this library can be overridden:
|
||||
|
||||
[embedmd]:# (examples/prometheus-name-override.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/prometheus-name-override.jsonnet"
|
||||
((import 'kube-prometheus/main.libsonnet') + {
|
||||
prometheus+: {
|
||||
prometheus+: {
|
||||
@@ -457,8 +462,7 @@ To give another customization example, the name of the `Prometheus` object provi
|
||||
|
||||
Standard Kubernetes manifests are all written using [ksonnet-lib](https://github.com/ksonnet/ksonnet-lib/), so they can be modified with the mixins supplied by ksonnet-lib. For example to override the namespace of the node-exporter DaemonSet:
|
||||
|
||||
[embedmd]:# (examples/ksonnet-example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/ksonnet-example.jsonnet"
|
||||
((import 'kube-prometheus/main.libsonnet') + {
|
||||
nodeExporter+: {
|
||||
daemonset+: {
|
||||
@@ -474,8 +478,7 @@ Standard Kubernetes manifests are all written using [ksonnet-lib](https://github
|
||||
|
||||
The Alertmanager configuration is located in the `values.alertmanager.config` configuration field. In order to set a custom Alertmanager configuration simply set this field.
|
||||
|
||||
[embedmd]:# (examples/alertmanager-config.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/alertmanager-config.jsonnet"
|
||||
((import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
alertmanager+: {
|
||||
@@ -502,8 +505,7 @@ The Alertmanager configuration is located in the `values.alertmanager.config` co
|
||||
|
||||
In the above example the configuration has been inlined, but can just as well be an external file imported in jsonnet via the `importstr` function.
|
||||
|
||||
[embedmd]:# (examples/alertmanager-config-external.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/alertmanager-config-external.jsonnet"
|
||||
((import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
alertmanager+: {
|
||||
@@ -517,8 +519,7 @@ In the above example the configuration has been inlined, but can just as well be
|
||||
|
||||
In order to monitor additional namespaces, the Prometheus server requires the appropriate `Role` and `RoleBinding` to be able to discover targets from that namespace. By default the Prometheus server is limited to the three namespaces it requires: default, kube-system and the namespace you configure the stack to run in via `$.values.namespace`. This is specified in `$.values.prometheus.namespaces`, to add new namespaces to monitor, simply append the additional namespaces:
|
||||
|
||||
[embedmd]:# (examples/additional-namespaces.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/additional-namespaces.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+: {
|
||||
@@ -548,8 +549,7 @@ In order to Prometheus be able to discovery and scrape services inside the addit
|
||||
|
||||
You can define ServiceMonitor resources in your `jsonnet` spec. See the snippet bellow:
|
||||
|
||||
[embedmd]:# (examples/additional-namespaces-servicemonitor.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/additional-namespaces-servicemonitor.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+: {
|
||||
@@ -599,10 +599,9 @@ local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
|
||||
### Monitoring all namespaces
|
||||
|
||||
In case you want to monitor all namespaces in a cluster, you can add the following mixin. Also, make sure to empty the namespaces defined in prometheus so that roleBindings are not created against them.
|
||||
In case you want to monitor all namespaces in a cluster, you can add the following mixin. Also, make sure to empty the namespaces defined in prometheus so that roleBindings are not created against them.
|
||||
|
||||
[embedmd]:# (examples/all-namespaces.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/all-namespaces.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
(import 'kube-prometheus/addons/all-namespaces.libsonnet') + {
|
||||
values+:: {
|
||||
@@ -630,7 +629,7 @@ Proceed with [creating ServiceMonitors for the services in the namespaces](#defi
|
||||
|
||||
### Static etcd configuration
|
||||
|
||||
In order to configure a static etcd cluster to scrape there is a simple [kube-prometheus-static-etcd.libsonnet](jsonnet/kube-prometheus/kube-prometheus-static-etcd.libsonnet) mixin prepared - see [etcd.jsonnet](examples/etcd.jsonnet) for an example of how to use that mixin, and [Monitoring external etcd](docs/monitoring-external-etcd.md) for more information.
|
||||
In order to configure a static etcd cluster to scrape there is a simple [static-etcd.libsonnet](jsonnet/kube-prometheus/addons/static-etcd.libsonnet) mixin prepared - see [etcd.jsonnet](examples/etcd.jsonnet) for an example of how to use that mixin, and [Monitoring external etcd](docs/monitoring-external-etcd.md) for more information.
|
||||
|
||||
> Note that monitoring etcd in minikube is currently not possible because of how etcd is setup. (minikube's etcd binds to 127.0.0.1:2379 only, and within host networking namespace.)
|
||||
|
||||
@@ -639,8 +638,7 @@ In order to configure a static etcd cluster to scrape there is a simple [kube-pr
|
||||
To prevent `Prometheus` and `Alertmanager` instances from being deployed onto the same node when
|
||||
possible, one can include the [kube-prometheus-anti-affinity.libsonnet](jsonnet/kube-prometheus/addons/anti-affinity.libsonnet) mixin:
|
||||
|
||||
[embedmd]:# (examples/anti-affinity.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/anti-affinity.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
(import 'kube-prometheus/addons/anti-affinity.libsonnet') + {
|
||||
values+:: {
|
||||
@@ -664,8 +662,7 @@ local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
Sometimes in small clusters, the CPU/memory limits can get high enough for alerts to be fired continuously. To prevent this, one can strip off the predefined limits.
|
||||
To do that, one can import the following mixin
|
||||
|
||||
[embedmd]:# (examples/strip-limits.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/strip-limits.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
(import 'kube-prometheus/addons/strip-limits.libsonnet') + {
|
||||
values+:: {
|
||||
@@ -763,7 +760,7 @@ kube-state-metrics resource allocation is managed by
|
||||
You can control it's parameters by setting variables in the
|
||||
config. They default to:
|
||||
|
||||
``` jsonnet
|
||||
```jsonnet
|
||||
kubeStateMetrics+:: {
|
||||
baseCPU: '100m',
|
||||
cpuPerNode: '2m',
|
||||
@@ -773,11 +770,12 @@ config. They default to:
|
||||
```
|
||||
|
||||
### Error retrieving kube-proxy metrics
|
||||
|
||||
By default, kubeadm will configure kube-proxy to listen on 127.0.0.1 for metrics. Because of this prometheus would not be able to scrape these metrics. This would have to be changed to 0.0.0.0 in one of the following two places:
|
||||
|
||||
1. Before cluster initialization, the config file passed to kubeadm init should have KubeProxyConfiguration manifest with the field metricsBindAddress set to 0.0.0.0:10249
|
||||
2. If the k8s cluster is already up and running, we'll have to modify the configmap kube-proxy in the namespace kube-system and set the metricsBindAddress field. After this kube-proxy daemonset would have to be restarted with
|
||||
`kubectl -n kube-system rollout restart daemonset kube-proxy`
|
||||
`kubectl -n kube-system rollout restart daemonset kube-proxy`
|
||||
|
||||
## Contributing
|
||||
|
||||
@@ -789,8 +787,8 @@ the following process:
|
||||
2. Commit your changes (This is currently necessary due to our vendoring
|
||||
process. This is likely to change in the future).
|
||||
3. Update the pinned kube-prometheus dependency in `jsonnetfile.lock.json`: `jb update`
|
||||
3. Generate dependent `*.yaml` files: `make generate`
|
||||
4. Commit the generated changes.
|
||||
4. Generate dependent `*.yaml` files: `make generate`
|
||||
5. Commit the generated changes.
|
||||
|
||||
## License
|
||||
|
||||
|
||||
20
RELEASE.md
20
RELEASE.md
@@ -4,12 +4,12 @@ Kube-prometheus has a somehow predictable release schedule, releases were
|
||||
historically cut in sync with OpenShift releases as per downstream needs. So
|
||||
far there hasn't been any problem with this schedule since it is also in sync
|
||||
with Kubernetes releases. So for every new Kubernetes release, there is a new
|
||||
release of kube-prometheus, although it tends to happen later.
|
||||
release of kube-prometheus, although it tends to happen later.
|
||||
|
||||
# How to cut a new release
|
||||
|
||||
> This guide is strongly based on the [prometheus-operator release
|
||||
instructions](https://github.com/prometheus-operator/prometheus-operator/blob/master/RELEASE.md).
|
||||
> instructions](https://github.com/prometheus-operator/prometheus-operator/blob/master/RELEASE.md).
|
||||
|
||||
## Branch management and versioning strategy
|
||||
|
||||
@@ -53,9 +53,9 @@ failed or because the main branch was already up-to-date.
|
||||
The main branch of kube-prometheus should support the last 2 versions of
|
||||
Kubernetes. We need to make sure that the CI on the main branch is testing the
|
||||
kube-prometheus configuration against both of these versions by updating the [CI
|
||||
worklow](/.github/workflows/ci.yaml) to include the latest kind version and the
|
||||
worklow](.github/workflows/ci.yaml) to include the latest kind version and the
|
||||
2 latest images versions that are attached to the kind release. Once that is
|
||||
done, the [compatibility matrix](/README.md#kubernetes-compatibility-matrix) in
|
||||
done, the [compatibility matrix](README.md#kubernetes-compatibility-matrix) in
|
||||
the README should also be updated to reflect the CI changes.
|
||||
|
||||
## Create pull request to cut the release
|
||||
@@ -63,9 +63,9 @@ the README should also be updated to reflect the CI changes.
|
||||
### Pin Jsonnet dependencies
|
||||
|
||||
Pin jsonnet dependencies in
|
||||
[jsonnetfile.json](/jsonnet/kube-prometheus/jsonnetfile.json). Each dependency
|
||||
[jsonnetfile.json](jsonnet/kube-prometheus/jsonnetfile.json). Each dependency
|
||||
should be pinned to the latest release branch or if it doesn't have one, pinned
|
||||
to the latest commit.
|
||||
to the latest commit.
|
||||
|
||||
### Start with a fresh environment
|
||||
|
||||
@@ -87,14 +87,14 @@ make generate
|
||||
|
||||
### Update the compatibility matrix
|
||||
|
||||
Update the [compatibility matrix](/README.md#kubernetes-compatibility-matrix) in
|
||||
Update the [compatibility matrix](README.md#kubernetes-compatibility-matrix) in
|
||||
the README, by adding the new release based on the `main` branch compatibility
|
||||
and removing the oldest release branch to only keep the latest 5 branches in the
|
||||
matrix.
|
||||
|
||||
### Update changelog
|
||||
|
||||
Iterate over the PRs that were merged between the latest release of kube-prometheus and the HEAD and add the changelog entries to the [CHANGELOG](/CHANGELOG.md).
|
||||
Iterate over the PRs that were merged between the latest release of kube-prometheus and the HEAD and add the changelog entries to the [CHANGELOG](CHANGELOG.md).
|
||||
|
||||
## Create release branch
|
||||
|
||||
@@ -111,10 +111,10 @@ the main branch to be in sync with the latest changes of its dependencies.
|
||||
|
||||
### Update CI workflow
|
||||
|
||||
Update the [versions workflow](/.github/workflows/versions.yaml) to include the latest release branch and remove the oldest one to reflect the list of supported releases.
|
||||
Update the [versions workflow](.github/workflows/versions.yaml) to include the latest release branch and remove the oldest one to reflect the list of supported releases.
|
||||
|
||||
### Update Kubernetes versions used by kubeconform
|
||||
|
||||
Update the versions of Kubernetes used when validating manifests with
|
||||
kubeconform in the [Makefile](/Makefile) to align with the compatibility
|
||||
kubeconform in the [Makefile](Makefile) to align with the compatibility
|
||||
matrix.
|
||||
|
||||
@@ -33,8 +33,8 @@ This code of conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by contacting a project maintainer listed in
|
||||
https://github.com/prometheus-operator/prometheus-operator/blob/master/MAINTAINERS.md.
|
||||
reported by contacting a project maintainer listed in
|
||||
https://github.com/prometheus-operator/prometheus-operator/blob/master/MAINTAINERS.md.
|
||||
|
||||
This Code of Conduct is adapted from the Contributor Covenant
|
||||
(http://contributor-covenant.org), version 1.2.0, available at
|
||||
|
||||
@@ -20,15 +20,14 @@ After your workspace start, you can deploy a kube-prometheus inside a Kind clust
|
||||
|
||||
If you are reviewing a PR, you'll have a fully-functional kubernetes cluster, generating real monitoring data that can be used to review if the proposed changes works as described.
|
||||
|
||||
If you are working on new features/bug fixes, you can regenerate kube-prometheus's YAML manifests with `make generate` and deploy it again with `make deploy`.
|
||||
If you are working on new features/bug fixes, you can regenerate kube-prometheus's YAML manifests with `make generate` and deploy it again with `make deploy`.
|
||||
|
||||
## Gitpod
|
||||
|
||||
Gitpod is already available to everyone to use for free. It can also run commands that we speficy in the `.gitpod.yml` file located in the root directory of the git repository, so even the cluster creation can be fully automated.
|
||||
|
||||
You can use the same workflow as mentioned in the [Codespaces](#Codespaces) section, however Gitpod doesn't have native support for any kubernetes distribution. The workaround is to create a full QEMU Virtual Machine and deploy [k3s](https://github.com/k3s-io/k3s) inside this VM. Don't worry, this whole process is already fully automated, but due to the workaround the whole workspace may be very slow.
|
||||
You can use the same workflow as mentioned in the [Codespaces](#codespaces) section, however Gitpod doesn't have native support for any kubernetes distribution. The workaround is to create a full QEMU Virtual Machine and deploy [k3s](https://github.com/k3s-io/k3s) inside this VM. Don't worry, this whole process is already fully automated, but due to the workaround the whole workspace may be very slow.
|
||||
|
||||
To open up a workspace with Gitpod, you can install the [Google Chrome extension](https://www.gitpod.io/docs/browser-extension/) to add a new button to Github UI and use it on PRs or from the main page. Or by directly typing in the browser `http://gitpod.io/#https://github.com/prometheus-operator/kube-prometheus/pull/<Pull Request Number>` or just `http://gitpod.io/#https://github.com/prometheus-operator/kube-prometheus`
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@ AWS EKS uses [CNI](https://github.com/aws/amazon-vpc-cni-k8s) networking plugin
|
||||
|
||||
One fatal issue that can occur is that you run out of IP addresses in your eks cluster. (Generally happens due to error configs where pods keep scheduling).
|
||||
|
||||
You can monitor the `awscni` using kube-promethus with :
|
||||
[embedmd]:# (../examples/eks-cni-example.jsonnet)
|
||||
```jsonnet
|
||||
You can monitor the `awscni` using kube-promethus with :
|
||||
|
||||
```jsonnet mdox-exec="cat examples/eks-cni-example.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+: {
|
||||
|
||||
@@ -5,6 +5,7 @@ authentication. Until it does, Prometheus must use HTTP (not HTTPS)
|
||||
for scraping.
|
||||
|
||||
You can configure this behavior through kube-prometheus with:
|
||||
|
||||
```
|
||||
local kp = (import 'kube-prometheus/kube-prometheus.libsonnet') +
|
||||
(import 'kube-prometheus/kube-prometheus-insecure-kubelet.libsonnet') +
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
---
|
||||
title: "Blackbox Exporter"
|
||||
description: "Generated API docs for the Prometheus Operator"
|
||||
lead: "This Document documents the types introduced by the Prometheus Operator to be consumed by users."
|
||||
date: 2021-03-08T08:49:31+00:00
|
||||
lastmod: 2021-03-08T08:49:31+00:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "kube"
|
||||
weight: 630
|
||||
toc: true
|
||||
title: Blackbox Exporter
|
||||
menu:
|
||||
docs:
|
||||
parent: kube
|
||||
lead: This Document documents the types introduced by the Prometheus Operator to be consumed by users.
|
||||
lastmod: "2021-03-08T08:49:31+00:00"
|
||||
images: []
|
||||
draft: false
|
||||
description: Generated API docs for the Prometheus Operator
|
||||
date: "2021-03-08T08:49:31+00:00"
|
||||
---
|
||||
|
||||
# Setting up a blackbox exporter
|
||||
@@ -21,6 +21,7 @@ The `prometheus-operator` defines a `Probe` resource type that can be used to de
|
||||
|
||||
1. Override blackbox-related configuration parameters as needed.
|
||||
2. Add the following to the list of renderers to render the blackbox exporter manifests:
|
||||
|
||||
```
|
||||
{ ['blackbox-exporter-' + name]: kp.blackboxExporter[name] for name in std.objectFields(kp.blackboxExporter) }
|
||||
```
|
||||
|
||||
@@ -4,7 +4,7 @@ For bugs, you can use the GitHub [issue tracker](https://github.com/prometheus-o
|
||||
|
||||
For questions, you can use the GitHub [discussions forum](https://github.com/prometheus-operator/kube-prometheus/discussions).
|
||||
|
||||
Many of the `kube-prometheus` project's contributors and users can also be found on the #prometheus-operator channel of the [Kubernetes Slack][Kubernetes Slack].
|
||||
Many of the `kube-prometheus` project's contributors and users can also be found on the #prometheus-operator channel of the [Kubernetes Slack](https://slack.k8s.io/).
|
||||
|
||||
`kube-prometheus` is the aggregation of many projects that all have different
|
||||
channels to reach out for help and support. This community strives at
|
||||
@@ -18,7 +18,7 @@ if applicable.
|
||||
|
||||
For documentation, check the project's [documentation directory](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation).
|
||||
|
||||
For questions, use the #prometheus-operator channel on the [Kubernetes Slack][Kubernetes Slack].
|
||||
For questions, use the #prometheus-operator channel on the [Kubernetes Slack](https://slack.k8s.io/).
|
||||
|
||||
For bugs, use the GitHub [issue tracker](https://github.com/prometheus-operator/prometheus-operator/issues/new/choose).
|
||||
|
||||
@@ -26,19 +26,19 @@ For bugs, use the GitHub [issue tracker](https://github.com/prometheus-operator/
|
||||
|
||||
For documentation, check the Prometheus [online docs](https://prometheus.io/docs/). There is a
|
||||
[section](https://prometheus.io/docs/introduction/media/) with links to blog
|
||||
posts, recorded talks and presentations. This [repository](https://github.com/roaldnefs/awesome-prometheus)
|
||||
posts, recorded talks and presentations. This [repository](https://github.com/roaldnefs/awesome-prometheus)
|
||||
(not affiliated to the Prometheus project) has also a list of curated resources
|
||||
related to the Prometheus ecosystem.
|
||||
|
||||
For questions, see the Prometheus [community page](https://prometheus.io/community/) for the various channels.
|
||||
|
||||
There is also a #prometheus channel on the [CNCF Slack][CNCF Slack].
|
||||
There is also a #prometheus channel on the [CNCF Slack](https://slack.cncf.io/).
|
||||
|
||||
## kube-state-metrics
|
||||
|
||||
For documentation, see the project's [docs directory](https://github.com/kubernetes/kube-state-metrics/tree/master/docs).
|
||||
|
||||
For questions, use the #kube-state-metrics channel on the [Kubernetes Slack][Kubernetes Slack].
|
||||
For questions, use the #kube-state-metrics channel on the [Kubernetes Slack](https://slack.k8s.io/).
|
||||
|
||||
For bugs, use the GitHub [issue tracker](https://github.com/kubernetes/kube-state-metrics/issues/new/choose).
|
||||
|
||||
@@ -46,7 +46,7 @@ For bugs, use the GitHub [issue tracker](https://github.com/kubernetes/kube-stat
|
||||
|
||||
For documentation, check the [Kubernetes docs](https://kubernetes.io/docs/home/).
|
||||
|
||||
For questions, use the [community forums](https://discuss.kubernetes.io/) and the [Kubernetes Slack][Kubernetes Slack]. Check also the [community page](https://kubernetes.io/community/#discuss).
|
||||
For questions, use the [community forums](https://discuss.kubernetes.io/) and the [Kubernetes Slack](https://slack.k8s.io/). Check also the [community page](https://kubernetes.io/community/#discuss).
|
||||
|
||||
For bugs, use the GitHub [issue tracker](https://github.com/kubernetes/kubernetes/issues/new/choose).
|
||||
|
||||
@@ -54,7 +54,7 @@ For bugs, use the GitHub [issue tracker](https://github.com/kubernetes/kubernete
|
||||
|
||||
For documentation, check the project's [README](https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/README.md).
|
||||
|
||||
For questions, use the #sig-instrumentation channel on the [Kubernetes Slack][Kubernetes Slack].
|
||||
For questions, use the #sig-instrumentation channel on the [Kubernetes Slack](https://slack.k8s.io/).
|
||||
|
||||
For bugs, use the GitHub [issue tracker](https://github.com/DirectXMan12/k8s-prometheus-adapter/issues/new).
|
||||
|
||||
@@ -70,7 +70,7 @@ For bugs, use the GitHub [issue tracker](https://github.com/grafana/grafana/issu
|
||||
|
||||
For documentation, check the project's [README](https://github.com/kubernetes-monitoring/kubernetes-mixin/blob/master/README.md).
|
||||
|
||||
For questions, use #monitoring-mixins channel on the [Kubernetes Slack][Kubernetes Slack].
|
||||
For questions, use #monitoring-mixins channel on the [Kubernetes Slack](https://slack.k8s.io/).
|
||||
|
||||
For bugs, use the GitHub [issue tracker](https://github.com/kubernetes-monitoring/kubernetes-mixin/issues/new).
|
||||
|
||||
@@ -79,6 +79,3 @@ For bugs, use the GitHub [issue tracker](https://github.com/kubernetes-monitorin
|
||||
For documentation, check the [Jsonnet](https://jsonnet.org/) website.
|
||||
|
||||
For questions, use the [mailing list](https://groups.google.com/forum/#!forum/jsonnet).
|
||||
|
||||
[Kubernetes Slack]: https://slack.k8s.io/
|
||||
[CNCF Slack]: https://slack.cncf.io/
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
title: "Deploy to kind"
|
||||
description: "Deploy kube-prometheus to Kubernets kind."
|
||||
lead: "Deploy kube-prometheus to Kubernets kind."
|
||||
date: 2021-03-08T23:04:32+01:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "kube"
|
||||
weight: 500
|
||||
toc: true
|
||||
title: Deploy to kind
|
||||
menu:
|
||||
docs:
|
||||
parent: kube
|
||||
lead: Deploy kube-prometheus to Kubernets kind.
|
||||
images: []
|
||||
draft: false
|
||||
description: Deploy kube-prometheus to Kubernets kind.
|
||||
date: "2021-03-08T23:04:32+01:00"
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
title: "Prometheus Rules and Grafana Dashboards"
|
||||
description: "Create Prometheus Rules and Grafana Dashboards on top of kube-prometheus"
|
||||
lead: "Create Prometheus Rules and Grafana Dashboards on top of kube-prometheus"
|
||||
date: 2021-03-08T23:04:32+01:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "kube"
|
||||
weight: 650
|
||||
toc: true
|
||||
title: Prometheus Rules and Grafana Dashboards
|
||||
menu:
|
||||
docs:
|
||||
parent: kube
|
||||
lead: Create Prometheus Rules and Grafana Dashboards on top of kube-prometheus
|
||||
images: []
|
||||
draft: false
|
||||
description: Create Prometheus Rules and Grafana Dashboards on top of kube-prometheus
|
||||
date: "2021-03-08T23:04:32+01:00"
|
||||
---
|
||||
|
||||
`kube-prometheus` ships with a set of default [Prometheus rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) and [Grafana](http://grafana.com/) dashboards. At some point one might like to extend them, the purpose of this document is to explain how to do this.
|
||||
@@ -20,8 +20,7 @@ For both the Prometheus rules and the Grafana dashboards Kubernetes `ConfigMap`s
|
||||
|
||||
As a basis, all examples in this guide are based on the base example of the kube-prometheus [readme](../README.md):
|
||||
|
||||
[embedmd]:# (../example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat example.jsonnet"
|
||||
local kp =
|
||||
(import 'kube-prometheus/main.libsonnet') +
|
||||
// Uncomment the following imports to enable its patches
|
||||
@@ -68,8 +67,7 @@ The format is exactly the Prometheus format, so there should be no changes neces
|
||||
|
||||
> Note that alerts can just as well be included into this file, using the jsonnet `import` function. In this example it is just inlined in order to demonstrate their use in a single file.
|
||||
|
||||
[embedmd]:# (../examples/prometheus-additional-alert-rule-example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/prometheus-additional-alert-rule-example.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+: {
|
||||
@@ -124,8 +122,7 @@ In order to add a recording rule, simply do the same with the `prometheusRules`
|
||||
|
||||
> Note that rules can just as well be included into this file, using the jsonnet `import` function. In this example it is just inlined in order to demonstrate their use in a single file.
|
||||
|
||||
[embedmd]:# (../examples/prometheus-additional-recording-rule-example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/prometheus-additional-recording-rule-example.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+: {
|
||||
@@ -184,8 +181,7 @@ cat existingrule.yaml | gojsontoyaml -yamltojson > existingrule.json
|
||||
|
||||
Then import it in jsonnet:
|
||||
|
||||
[embedmd]:# (../examples/prometheus-additional-rendered-rule-example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/prometheus-additional-rendered-rule-example.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+: {
|
||||
@@ -217,6 +213,7 @@ local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
{ ['grafana-' + name]: kp.grafana[name] for name in std.objectFields(kp.grafana) } +
|
||||
{ ['example-application-' + name]: kp.exampleApplication[name] for name in std.objectFields(kp.exampleApplication) }
|
||||
```
|
||||
|
||||
### Changing default rules
|
||||
|
||||
Along with adding additional rules, we give the user the option to filter or adjust the existing rules imported by `kube-prometheus/main.libsonnet`. The recording rules can be found in [kube-prometheus/components/mixin/rules](../jsonnet/kube-prometheus/components/mixin/rules) and [kubernetes-mixin/rules](https://github.com/kubernetes-monitoring/kubernetes-mixin/tree/master/rules) while the alerting rules can be found in [kube-prometheus/components/mixin/alerts](../jsonnet/kube-prometheus/components/mixin/alerts) and [kubernetes-mixin/alerts](https://github.com/kubernetes-monitoring/kubernetes-mixin/tree/master/alerts).
|
||||
@@ -224,7 +221,9 @@ Along with adding additional rules, we give the user the option to filter or adj
|
||||
Knowing which rules to change, the user can now use functions from the [Jsonnet standard library](https://jsonnet.org/ref/stdlib.html) to make these changes. Below are examples of both a filter and an adjustment being made to the default rules. These changes can be assigned to a local variable and then added to the `local kp` object as seen in the examples above.
|
||||
|
||||
#### Filter
|
||||
|
||||
Here the alert `KubeStatefulSetReplicasMismatch` is being filtered out of the group `kubernetes-apps`. The default rule can be seen [here](https://github.com/kubernetes-monitoring/kubernetes-mixin/blob/master/alerts/apps_alerts.libsonnet). You first need to find out in which component the rule is defined (here it is kuberentesControlPlane).
|
||||
|
||||
```jsonnet
|
||||
local filter = {
|
||||
kubernetesControlPlane+: {
|
||||
@@ -251,7 +250,9 @@ local filter = {
|
||||
```
|
||||
|
||||
#### Adjustment
|
||||
|
||||
Here the expression for another alert in the same component is updated from its previous value. The default rule can be seen [here](https://github.com/kubernetes-monitoring/kubernetes-mixin/blob/master/alerts/apps_alerts.libsonnet).
|
||||
|
||||
```jsonnet
|
||||
local update = {
|
||||
kubernetesControlPlane+: {
|
||||
@@ -283,6 +284,7 @@ local update = {
|
||||
```
|
||||
|
||||
Using the example from above about adding in pre-rendered rules, the new local variables can be added in as follows:
|
||||
|
||||
```jsonnet
|
||||
local add = {
|
||||
exampleApplication:: {
|
||||
@@ -327,6 +329,7 @@ local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
{ ['kubernetes-' + name]: kp.kubernetesControlPlane[name] for name in std.objectFields(kp.kubernetesControlPlane) } +
|
||||
{ ['exampleApplication-' + name]: kp.exampleApplication[name] for name in std.objectFields(kp.exampleApplication) }
|
||||
```
|
||||
|
||||
## Dashboards
|
||||
|
||||
Dashboards can either be added using jsonnet or simply a pre-rendered json dashboard.
|
||||
@@ -337,8 +340,7 @@ We recommend using the [grafonnet](https://github.com/grafana/grafonnet-lib/) li
|
||||
|
||||
> Note that dashboards can just as well be included into this file, using the jsonnet `import` function. In this example it is just inlined in order to demonstrate their use in a single file.
|
||||
|
||||
[embedmd]:# (../examples/grafana-additional-jsonnet-dashboard-example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/grafana-additional-jsonnet-dashboard-example.jsonnet"
|
||||
local grafana = import 'grafonnet/grafana.libsonnet';
|
||||
local dashboard = grafana.dashboard;
|
||||
local row = grafana.row;
|
||||
@@ -394,8 +396,7 @@ local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
|
||||
As jsonnet is a superset of json, the jsonnet `import` function can be used to include Grafana dashboard json blobs. In this example we are importing a [provided example dashboard](../examples/example-grafana-dashboard.json).
|
||||
|
||||
[embedmd]:# (../examples/grafana-additional-rendered-dashboard-example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/grafana-additional-rendered-dashboard-example.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+:: {
|
||||
@@ -419,8 +420,8 @@ local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
```
|
||||
|
||||
In case you have lots of json dashboard exported out from grafana UI the above approach is going to take lots of time to improve performance we can use `rawDashboards` field and provide it's value as json string by using `importstr`
|
||||
[embedmd]:# (../examples/grafana-additional-rendered-dashboard-example-2.jsonnet)
|
||||
```jsonnet
|
||||
|
||||
```jsonnet mdox-exec="cat examples/grafana-additional-rendered-dashboard-example-2.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
values+:: {
|
||||
common+:: {
|
||||
@@ -523,8 +524,7 @@ values+:: {
|
||||
|
||||
Full example of including etcd mixin using method described above:
|
||||
|
||||
[embedmd]:# (../examples/mixin-inclusion.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/mixin-inclusion.jsonnet"
|
||||
local addMixin = (import 'kube-prometheus/lib/mixin.libsonnet');
|
||||
local etcdMixin = addMixin({
|
||||
name: 'etcd',
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
title: "Expose via Ingress"
|
||||
description: "How to setup a Kubernetes Ingress to expose the Prometheus, Alertmanager and Grafana."
|
||||
lead: "How to setup a Kubernetes Ingress to expose the Prometheus, Alertmanager and Grafana."
|
||||
date: 2021-03-08T23:04:32+01:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "kube"
|
||||
weight: 500
|
||||
toc: true
|
||||
title: Expose via Ingress
|
||||
menu:
|
||||
docs:
|
||||
parent: kube
|
||||
lead: How to setup a Kubernetes Ingress to expose the Prometheus, Alertmanager and Grafana.
|
||||
images: []
|
||||
draft: false
|
||||
description: How to setup a Kubernetes Ingress to expose the Prometheus, Alertmanager and Grafana.
|
||||
date: "2021-03-08T23:04:32+01:00"
|
||||
---
|
||||
|
||||
In order to access the web interfaces via the Internet [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is a popular option. This guide explains, how Kubernetes Ingress can be setup, in order to expose the Prometheus, Alertmanager and Grafana UIs, that are included in the [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) project.
|
||||
@@ -104,7 +104,7 @@ k.core.v1.list.new([
|
||||
|
||||
In order to expose Alertmanager and Grafana, simply create additional fields containing an ingress object, but simply pointing at the `alertmanager` or `grafana` instead of the `prometheus-k8s` Service. Make sure to also use the correct port respectively, for Alertmanager it is also `web`, for Grafana it is `http`. Be sure to also specify the appropriate external URL. Note that the external URL for grafana is set in a different way than the external URL for Prometheus or Alertmanager. See [ingress.jsonnet](../examples/ingress.jsonnet) for how to set the Grafana external URL.
|
||||
|
||||
In order to render the ingress objects similar to the other objects use as demonstrated in the [main readme](../README.md#usage):
|
||||
In order to render the ingress objects similar to the other objects use as demonstrated in the [main readme](../README.md):
|
||||
|
||||
```
|
||||
{ ['00namespace-' + name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } +
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
title: "Deploy to kubeadm"
|
||||
description: "Deploy kube-prometheus to Kubernets kubeadm."
|
||||
lead: "Deploy kube-prometheus to Kubernets kubeadm."
|
||||
date: 2021-03-08T23:04:32+01:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "kube"
|
||||
weight: 500
|
||||
toc: true
|
||||
title: Deploy to kubeadm
|
||||
menu:
|
||||
docs:
|
||||
parent: kube
|
||||
lead: Deploy kube-prometheus to Kubernets kubeadm.
|
||||
images: []
|
||||
draft: false
|
||||
description: Deploy kube-prometheus to Kubernets kubeadm.
|
||||
date: "2021-03-08T23:04:32+01:00"
|
||||
---
|
||||
|
||||
The [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/) tool is linked by Kubernetes as the offical way to deploy and manage self-hosted clusters. kubeadm does a lot of heavy lifting by automatically configuring your Kubernetes cluster with some common options. This guide is intended to show you how to deploy Prometheus, Prometheus Operator and Kube Prometheus to get you started monitoring your cluster that was deployed with kubeadm.
|
||||
@@ -93,7 +93,6 @@ Once you complete this guide you will monitor the following:
|
||||
* kube-scheduler
|
||||
* kube-controller-manager
|
||||
|
||||
|
||||
## Getting Up and Running Fast with Kube-Prometheus
|
||||
|
||||
To help get started more quickly with monitoring Kubernetes clusters, [kube-prometheus](https://github.com/coreos/kube-prometheus) was created. It is a collection of manifests including dashboards and alerting rules that can easily be deployed. It utilizes the Prometheus Operator and all the manifests demonstrated in this guide.
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
|
||||
An example conversion of a legacy custom jsonnet file to release-0.8
|
||||
format can be seen by viewing and comparing this
|
||||
[release-0.3 jsonnet file](./my.release-0.3.jsonnet) (when the github
|
||||
[release-0.3 jsonnet file](my.release-0.3.jsonnet) (when the github
|
||||
repo was under `https://github.com/coreos/kube-prometheus...`)
|
||||
and the corresponding [release-0.8 jsonnet file](./my.release-0.8.jsonnet).
|
||||
and the corresponding [release-0.8 jsonnet file](my.release-0.8.jsonnet).
|
||||
|
||||
These two files have had necessary blank lines added so that they
|
||||
can be compared side-by-side and line-by-line on screen.
|
||||
@@ -16,8 +16,9 @@ release-0.3 and also the major migration after release-0.7 as described in
|
||||
The sample files are intended as an example of format conversion and
|
||||
not necessarily best practice for the files in release-0.3 or release-0.8.
|
||||
|
||||
Below are three sample extracts of the conversion as an indication of the
|
||||
Below are three sample extracts of the conversion as an indication of the
|
||||
changes required.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th> release-0.3 </th>
|
||||
|
||||
@@ -33,14 +33,14 @@ Thanks to our community we identified a lot of short-commings of previous design
|
||||
|
||||
Those concepts were already present in the repository but it wasn't clear which file is holding what. After refactoring we categorized jsonnet code into 3 buckets and put them into separate directories:
|
||||
- `components` - main building blocks for kube-prometheus, written as functions responsible for creating multiple objects representing kubernetes manifests. For example all objects for node_exporter deployment are bundled in `components/node_exporter.libsonnet` library
|
||||
- `addons` - everything that can enhance kube-prometheus deployment. Those are small snippets of code adding a small feature, for example adding anti-affinity to pods via [`addons/anti-affinity.libsonnet`][antiaffinity]. Addons are meant to be used in object-oriented way like `local kp = (import 'kube-prometheus/main.libsonnet') + (import 'kube-prometheus/addons/all-namespaces.libsonnet')`
|
||||
- `addons` - everything that can enhance kube-prometheus deployment. Those are small snippets of code adding a small feature, for example adding anti-affinity to pods via [`addons/anti-affinity.libsonnet`](https://github.com/prometheus-operator/kube-prometheus/blob/main/jsonnet/kube-prometheus/addons/anti-affinity.libsonnet). Addons are meant to be used in object-oriented way like `local kp = (import 'kube-prometheus/main.libsonnet') + (import 'kube-prometheus/addons/all-namespaces.libsonnet')`
|
||||
- `platforms` - currently those are `addons` specialized to allow deploying kube-prometheus project on a specific platform.
|
||||
|
||||
### Component configuration
|
||||
|
||||
Refactoring main components to use functions allowed us to define APIs for said components. Each function has a default set of parameters that can be overridden or that are required to be set by a user. Those default parameters are represented in each component by `defaults` map at the top of each library file, for example in [`node_exporter.libsonnet`][node_exporter_defaults_example].
|
||||
Refactoring main components to use functions allowed us to define APIs for said components. Each function has a default set of parameters that can be overridden or that are required to be set by a user. Those default parameters are represented in each component by `defaults` map at the top of each library file, for example in [`node_exporter.libsonnet`](https://github.com/prometheus-operator/kube-prometheus/blob/1d2a0e275af97948667777739a18b24464480dc8/jsonnet/kube-prometheus/components/node-exporter.libsonnet#L3-L34).
|
||||
|
||||
This API is meant to ease the use of kube-prometheus as parameters can be passed from a JSON file and don't need to be in jsonnet format. However, if you need to modify particular parts of the stack, jsonnet allows you to do this and we are also not restricting such access in any way. An example of such modifications can be seen in any of our `addons`, like the [`addons/anti-affinity.libsonnet`][antiaffinity] one.
|
||||
This API is meant to ease the use of kube-prometheus as parameters can be passed from a JSON file and don't need to be in jsonnet format. However, if you need to modify particular parts of the stack, jsonnet allows you to do this and we are also not restricting such access in any way. An example of such modifications can be seen in any of our `addons`, like the [`addons/anti-affinity.libsonnet`](https://github.com/prometheus-operator/kube-prometheus/blob/main/jsonnet/kube-prometheus/addons/anti-affinity.libsonnet) one.
|
||||
|
||||
### Mixin integration
|
||||
|
||||
@@ -63,25 +63,14 @@ All examples from `examples/` directory were adapted to the new codebase. [Pleas
|
||||
|
||||
## Legacy migration
|
||||
|
||||
An example of conversion of a legacy release-0.3 my.jsonnet file to release-0.8 can be found in [migration-example](./migration-example)
|
||||
An example of conversion of a legacy release-0.3 my.jsonnet file to release-0.8 can be found in [migration-example](migration-example)
|
||||
|
||||
## Advanced usage examples
|
||||
|
||||
For more advanced usage examples you can take a look at those two, open to public, implementations:
|
||||
- [thaum-xyz/ankhmorpork][thaum] - extending kube-prometheus to adapt to a required environment
|
||||
- [openshift/cluster-monitoring-operator][openshift] - using kube-prometheus components as standalone libraries to build a custom solution
|
||||
- [thaum-xyz/ankhmorpork](https://github.com/thaum-xyz/ankhmorpork/blob/master/apps/monitoring/jsonnet) - extending kube-prometheus to adapt to a required environment
|
||||
- [openshift/cluster-monitoring-operator](https://github.com/openshift/cluster-monitoring-operator/pull/1044) - using kube-prometheus components as standalone libraries to build a custom solution
|
||||
|
||||
## Final note
|
||||
|
||||
Refactoring was a huge undertaking and possibly this document didn't describe in enough detail how to help you with migration to the new stack. If that is the case, please reach out to us by using [GitHub discussions][discussions] feature or directly on [#prometheus-operator kubernetes slack channel][slack].
|
||||
|
||||
|
||||
[antiaffinity]: https://github.com/prometheus-operator/kube-prometheus/blob/main/jsonnet/kube-prometheus/addons/anti-affinity.libsonnet
|
||||
|
||||
[node_exporter_defaults_example]: https://github.com/prometheus-operator/kube-prometheus/blob/1d2a0e275af97948667777739a18b24464480dc8/jsonnet/kube-prometheus/components/node-exporter.libsonnet#L3-L34
|
||||
|
||||
[openshift]: https://github.com/openshift/cluster-monitoring-operator/pull/1044
|
||||
[thaum]: https://github.com/thaum-xyz/ankhmorpork/blob/master/apps/monitoring/jsonnet
|
||||
|
||||
[discussions]: https://github.com/prometheus-operator/kube-prometheus/discussions
|
||||
[slack]: http://slack.k8s.io/
|
||||
Refactoring was a huge undertaking and possibly this document didn't describe in enough detail how to help you with migration to the new stack. If that is the case, please reach out to us by using [GitHub discussions](https://github.com/prometheus-operator/kube-prometheus/discussions) feature or directly on [#prometheus-operator kubernetes slack channel](http://slack.k8s.io/).
|
||||
|
||||
@@ -1,23 +1,23 @@
|
||||
---
|
||||
title: "Monitoring external etcd"
|
||||
description: "This guide will help you monitor an external etcd cluster."
|
||||
lead: "This guide will help you monitor an external etcd cluster."
|
||||
date: 2021-03-08T23:04:32+01:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "kube"
|
||||
weight: 640
|
||||
toc: true
|
||||
title: Monitoring external etcd
|
||||
menu:
|
||||
docs:
|
||||
parent: kube
|
||||
lead: This guide will help you monitor an external etcd cluster.
|
||||
images: []
|
||||
draft: false
|
||||
description: This guide will help you monitor an external etcd cluster.
|
||||
date: "2021-03-08T23:04:32+01:00"
|
||||
---
|
||||
|
||||
When the etcd cluster is not hosted inside Kubernetes.
|
||||
This is often the case with Kubernetes setups. This approach has been tested with kube-aws but the same principals apply to other tools.
|
||||
|
||||
Note that [etcd.jsonnet](../examples/etcd.jsonnet) & [kube-prometheus-static-etcd.libsonnet](../jsonnet/kube-prometheus/kube-prometheus-static-etcd.libsonnet) (which are described by a section of the [Readme](../README.md#static-etcd-configuration)) do the following:
|
||||
* Put the three etcd TLS client files (CA & cert & key) into a secret in the namespace, and have Prometheus Operator load the secret.
|
||||
* Create the following (to expose etcd metrics - port 2379): a Service, Endpoint, & ServiceMonitor.
|
||||
Note that [etcd.jsonnet](../examples/etcd.jsonnet) & [static-etcd.libsonnet](../jsonnet/kube-prometheus/addons/static-etcd.libsonnet) (which are described by a section of the [Readme](../README.md#static-etcd-configuration)) do the following:
|
||||
* Put the three etcd TLS client files (CA & cert & key) into a secret in the namespace, and have Prometheus Operator load the secret.
|
||||
* Create the following (to expose etcd metrics - port 2379): a Service, Endpoint, & ServiceMonitor.
|
||||
|
||||
# Step 1: Open the port
|
||||
|
||||
@@ -26,6 +26,7 @@ You now need to allow the nodes Prometheus are running on to talk to the etcd on
|
||||
If using kube-aws, you will need to edit the etcd security group inbound, specifying the security group of your Kubernetes node (worker) as the source.
|
||||
|
||||
## kube-aws and EIP or ENI inconsistency
|
||||
|
||||
With kube-aws, each etcd node has two IP addresses:
|
||||
|
||||
* EC2 instance IP
|
||||
@@ -40,6 +41,7 @@ Another idea woud be to use the DNS entries of etcd, but those are not currently
|
||||
# Step 2: verify
|
||||
|
||||
Go to the Prometheus UI on :9090/config and check that you have an etcd job entry:
|
||||
|
||||
```
|
||||
- job_name: monitoring/etcd-k8s/0
|
||||
scrape_interval: 30s
|
||||
@@ -48,6 +50,5 @@ Go to the Prometheus UI on :9090/config and check that you have an etcd job entr
|
||||
```
|
||||
|
||||
On the :9090/targets page:
|
||||
* You should see "etcd" with the UP state. If not, check the Error column for more information.
|
||||
* If no "etcd" targets are even shown on this page, prometheus isn't attempting to scrape it.
|
||||
|
||||
* You should see "etcd" with the UP state. If not, check the Error column for more information.
|
||||
* If no "etcd" targets are even shown on this page, prometheus isn't attempting to scrape it.
|
||||
|
||||
@@ -1,24 +1,26 @@
|
||||
---
|
||||
title: "Monitoring other Namespaces"
|
||||
description: "This guide will help you monitor applications in other Namespaces."
|
||||
lead: "This guide will help you monitor applications in other Namespaces."
|
||||
date: 2021-03-08T23:04:32+01:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "kube"
|
||||
weight: 640
|
||||
toc: true
|
||||
title: Monitoring other Namespaces
|
||||
menu:
|
||||
docs:
|
||||
parent: kube
|
||||
lead: This guide will help you monitor applications in other Namespaces.
|
||||
images: []
|
||||
draft: false
|
||||
description: This guide will help you monitor applications in other Namespaces.
|
||||
date: "2021-03-08T23:04:32+01:00"
|
||||
---
|
||||
|
||||
This guide will help you monitor applications in other Namespaces. By default the RBAC rules are only enabled for the `Default` and `kube-system` Namespace during Install.
|
||||
|
||||
# Setup
|
||||
|
||||
You have to give the list of the Namespaces that you want to be able to monitor.
|
||||
This is done in the variable `prometheus.roleSpecificNamespaces`. You usually set this in your `.jsonnet` file when building the manifests.
|
||||
|
||||
Example to create the needed `Role` and `RoleBinding` for the Namespace `foo` :
|
||||
Example to create the needed `Role` and `RoleBinding` for the Namespace `foo` :
|
||||
|
||||
```
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') + {
|
||||
_config+:: {
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
# Setup Weave Net monitoring using kube-prometheus
|
||||
|
||||
[Weave Net](https://kubernetes.io/docs/concepts/cluster-administration/networking/#weave-net-from-weaveworks) is a resilient and simple to use CNI provider for Kubernetes. A well monitored and observed CNI provider helps in troubleshooting Kubernetes networking problems. [Weave Net](https://www.weave.works/docs/net/latest/concepts/how-it-works/) emits [prometheus metrics](https://www.weave.works/docs/net/latest/tasks/manage/metrics/) for monitoring Weave Net. There are many ways to install Weave Net in your cluster. One of them is using [kops](https://github.com/kubernetes/kops/blob/master/docs/networking.md).
|
||||
|
||||
Following this document, you can setup Weave Net monitoring for your cluster using kube-prometheus.
|
||||
|
||||
## Contents
|
||||
|
||||
Using kube-prometheus and kubectl you will be able install the following for monitoring Weave Net in your cluster:
|
||||
|
||||
1. [Service for Weave Net](https://gist.github.com/alok87/379c6234b582f555c141f6fddea9fbce) The service which the [service monitor](https://coreos.com/operators/prometheus/docs/latest/user-guides/cluster-monitoring.html) scrapes.
|
||||
@@ -15,8 +17,7 @@ Using kube-prometheus and kubectl you will be able install the following for mon
|
||||
## Instructions
|
||||
- You can monitor Weave Net using an example like below. **Please note that some alert configurations are environment specific and may require modifications of alert thresholds**. For example: The FastDP flows have never gone below 15000 for us. But if this value is say 20000 for you then you can use an example like below to update the alert. The alerts which may require threshold modifications are `WeaveNetFastDPFlowsLow` and `WeaveNetIPAMUnreachable`.
|
||||
|
||||
[embedmd]:# (../examples/weave-net-example.jsonnet)
|
||||
```jsonnet
|
||||
```jsonnet mdox-exec="cat examples/weave-net-example.jsonnet"
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
(import 'kube-prometheus/addons/weave-net/weave-net.libsonnet') + {
|
||||
values+:: {
|
||||
@@ -66,6 +67,7 @@ local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
```
|
||||
|
||||
- After you have the required yamls file please run
|
||||
|
||||
```
|
||||
kubectl create -f prometheus-serviceWeaveNet.yaml
|
||||
kubectl create -f prometheus-serviceMonitorWeaveNet.yaml
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
# Windows
|
||||
|
||||
The [Windows addon](../examples/windows.jsonnet) adds the dashboards and rules from [kubernetes-monitoring/kubernetes-mixin](https://github.com/kubernetes-monitoring/kubernetes-mixin#dashboards-for-windows-nodes).
|
||||
The [Windows addon](../examples/windows.jsonnet) adds the dashboards and rules from [kubernetes-monitoring/kubernetes-mixin](https://github.com/kubernetes-monitoring/kubernetes-mixin#dashboards-for-windows-nodes).
|
||||
|
||||
Currently, Windows does not support running with [windows_exporter](https://github.com/prometheus-community/windows_exporter) in a pod so this add on uses [additional scrape configuration](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/additional-scrape-config.md) to set up a static config to scrape the node ports where windows_exporter is configured.
|
||||
|
||||
|
||||
The addon requires you to specify the node ips and ports where it can find the windows_exporter. See the [full example](../examples/windows.jsonnet) for setup.
|
||||
The addon requires you to specify the node ips and ports where it can find the windows_exporter. See the [full example](../examples/windows.jsonnet) for setup.
|
||||
|
||||
```
|
||||
local kp = (import 'kube-prometheus/main.libsonnet') +
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
# Adding a new platform specific configuration
|
||||
|
||||
Adding a new platform specific configuration requires to update the [README](../../../README.md#cluster-creation-tools) and the [platforms.jsonnet](./platform.jsonnet) file by adding the platform to the list of existing ones. This allow the new platform to be discoverable and easily configurable by the users.
|
||||
Adding a new platform specific configuration requires to update the [README](../../../README.md#cluster-creation-tools) and the [platforms.libsonnet](platforms.libsonnet) file by adding the platform to the list of existing ones. This allow the new platform to be discoverable and easily configurable by the users.
|
||||
|
||||
@@ -4,7 +4,7 @@ go 1.15
|
||||
|
||||
require (
|
||||
github.com/brancz/gojsontoyaml v0.0.0-20200602132005-3697ded27e8c
|
||||
github.com/campoy/embedmd v1.0.0
|
||||
github.com/bwplotka/mdox v0.9.0
|
||||
github.com/google/go-jsonnet v0.17.1-0.20210909114553-2f2f6d664f06 // commit on SEP 9th 2021. Needed by jsonnet linter
|
||||
github.com/jsonnet-bundler/jsonnet-bundler v0.4.0
|
||||
github.com/yannh/kubeconform v0.4.7
|
||||
|
||||
968
scripts/go.sum
968
scripts/go.sum
File diff suppressed because it is too large
Load Diff
@@ -6,10 +6,10 @@ package tools
|
||||
|
||||
import (
|
||||
_ "github.com/brancz/gojsontoyaml"
|
||||
_ "github.com/campoy/embedmd"
|
||||
_ "github.com/bwplotka/mdox"
|
||||
_ "github.com/google/go-jsonnet/cmd/jsonnet"
|
||||
_ "github.com/google/go-jsonnet/cmd/jsonnet-lint"
|
||||
_ "github.com/google/go-jsonnet/cmd/jsonnetfmt"
|
||||
_ "github.com/yannh/kubeconform/cmd/kubeconform"
|
||||
_ "github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb"
|
||||
_ "github.com/yannh/kubeconform/cmd/kubeconform"
|
||||
)
|
||||
|
||||
Reference in New Issue
Block a user