Add mdox link checking and formatting

Signed-off-by: Saswata Mukherjee <[email protected]>

Author: saswatamcode

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/[email protected]`
 
 In order to update the kube-prometheus dependency, simply use the jsonnet-bundler update functionality:
+
 ```shell
 $ jb update
 ```
@@ -280,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:
 
@@ -288,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.
@@ -297,30 +302,35 @@ 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
 $ 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
 
@@ -342,6 +352,7 @@ 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:
+
 ```
       grafana+:: {
         config: { // http://docs.grafana.org/installation/configuration/
@@ -588,7 +599,7 @@ 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.
 
 ```jsonnet mdox-exec="cat examples/all-namespaces.jsonnet"
 local kp = (import 'kube-prometheus/main.libsonnet') +
@@ -749,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',
@@ -759,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
 
@@ -775,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
 

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,19 +53,19 @@ 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
 
 ### 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.

code-of-conduct.md

@@ -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

developer-workspace/README.md

@@ -20,7 +20,7 @@ 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
 
@@ -31,4 +31,3 @@ You can use the same workflow as mentioned in the [Codespaces](#codespaces) sect
 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`
 
 ![image](https://user-images.githubusercontent.com/24193764/135534546-4f6bf0e5-57cd-4e35-ad80-88bd47d64276.png)
-

docs/EKS-cni-support.md

@@ -4,7 +4,7 @@ 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 : 
+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') + {

docs/GKE-cadvisor-support.md

@@ -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') +

docs/blackbox-exporter.md

@@ -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) }
 ```