kubernetes通过kube-prometheus安装高可用的监控告警

kube-prometheus介绍

kube-prometheus是coreos专门为kubernetes封装的一套高可用的监控预警，方便用户直接安装使用。

声明，所有操作都是基于实验性的，随时可能发生重大变化。

该项目包含 Grafana 和 Prometheus规则 以及文档和脚本，使用 Prometheus Operator 创建Prometheus提供端到端的Kubernetes集群监控。

kube-prometheus包含的组件：

• Prometheus Operator
• 高可用的 Prometheus
• 高可用的 Alertmanager
• Prometheus node-exporter
• Prometheus Adapter for Kubernetes Metrics APIs
• kube-state-metrics
• Grafana

kube-prometheus是用于kubernetes集群监控的，所以它预先配置了从所有Kubernetes组件中收集指标。除此之外，它还提供了一组默认的仪表板和警报规则。许多有用的仪表板和警报都来自于kubernetes-mixin项目，与此项目类似，它也提供了jsonnet，供用户根据自己的需求定制。

前提条件

你需要一个 Kubernetes 集群，就这样! 默认情况下，假设kubelet使用token认证和授权，否则的话Prometheus需要一个客户端证—书，要让它可以完全访问kubelet，而不仅仅是指标。token认证和授权允许更细粒度和更简单的访问控制。

这意味着kubelet配置必须包含这些标志。

• --authentication-token-webhook=true 这个标志使ServiceAccounttoken可以用来对kubelet进行身份验证。也可以通过将 kubelet 配置值 authentication.webhook.enabled 设置为 true 来启用。

• --authorization-mode=Webhook 这个标志可以使kubelet使用API执行RBAC请求，以确定请求实体（本例中的Prometheus）是否允许访问一个资源，具体到本项目的/metrics端点。这也可以通过设置kubelet配置值authorization.mode为Webhook来启用。

可以通过部署Prometheus Adapter来提供资源指标。

这个适配器是一个扩展API服务器，Kubernetes需要启用这个功能，否则适配器没有效果（但仍然部署）。

minikube

可以使用 minikube 安装，运行以下命令:

$ minikube delete && minikube start --kubernetes-version=v1.18.1 --memory=6g --bootstrapper=kubeadm --extra-config=kubelet.authentication-token-webhook=true --extra-config=kubelet.authorization-mode=Webhook --extra-config=scheduler.address=0.0.0.0 --extra-config=controller-manager.address=0.0.0.0

kube-prometheus包括了一个资源度量API服务器，所以不需要使用度量服务器插件。确保metrics-server附加组件在minikube上被禁用。

$ minikube addons disable metrics-server

兼容性

以下是支持的版本，我们在各自的分支中对这些版本进行了测试。但请注意，其他版本可能也是ok的!

kube-prometheus stack	Kubernetes 1.14	Kubernetes 1.15	Kubernetes 1.16	Kubernetes 1.17	Kubernetes 1.18	Kubernetes 1.19	Kubernetes 1.20
release-0.3	✔	✔	✔	✔	✗	✗	✗
release-0.4	✗	✗	✔ (v1.16.5+)	✔	✗	✗	✗
release-0.5	✗	✗	✗	✗	✔	✗	✗
release-0.6	✗	✗	✗	✗	✔	✔	✗
release-0.7	✗	✗	✗	✗	✗	✔	✔
HEAD	✗	✗	✗	✗	✗	✔	✔

注意：由于Kubernetes v1.16.1中的两个bug，在Kubernetes v1.16.5之前，kube-prometheus releas-0.4分支只支持v1.16.5及以上版本。为了解决Kubernetes v1.16.2到v1.16.4的第二个问题，可以手动编辑kube-system命名空间中的extension-apiserver-apiserver-authentication-reader角色，将list和watch权限加进去。

快速启动

注意：对于Kubernetes v1.18.z之前的版本，请参考Kubernetes兼容性，选择兼容的分支。

使用manifests目录下的配置创建监控:

# Create the namespace and CRDs, and then wait for them to be availble before creating the remaining resources
kubectl create -f manifests/setup
until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done
kubectl create -f manifests/

我们先创建命名空间和CustomResourceDefinitions，以避免在部署监控组件时出现竞赛情况。

另外，也可以用一条命令来应用这两个文件夹中的资源。
kubectl create -f manifests/setup -f manifests，但可能需要多次运行该命令才能成功创建所有组件。

卸载（And to teardown the stack:）

kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup

访问dashboards

Prometheus、Grafana 和 Alertmanager 仪表盘可以通过以下命令运行快速启动后，使用 kubectl port-forward 快速访问。需要Kubernetes 1.10或更高版本。

Prometheus

$ kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

访问地址： http://localhost:9090

Grafana

$ kubectl --namespace monitoring port-forward svc/grafana 3000

访问地址： http://localhost:3000

grafana 默认密码是admin:admin。

Alert Manager

$ kubectl --namespace monitoring port-forward svc/alertmanager-main 9093

访问地址： http://localhost:9093

自定义 Kube-Prometheus

本节：

• 讲解如何通过编译kube-prometheus库来重新定制kube-prometheus库。

• 不需要你复制整个项目，只需要复制几个选择的文件即可。

安装

这个项目的内容由一组jsonnet文件组成。

用 jsonnet-bundler在你的项目中安装这个库。

$ mkdir my-kube-prometheus; cd my-kube-prometheus
$ jb init  # Creates the initial/empty `jsonnetfile.json`
# Install the kube-prometheus dependency
$ jb install github.com/coreos/kube-prometheus/jsonnet/kube-prometheus@release-0.4 # Creates `vendor/` & `jsonnetfile.lock.json`, and fills in `jsonnetfile.json`

可以用 go get github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb安装jb

安装指定版本: jb install github.com/coreos/kube-prometheus/jsonnet/kube-prometheus@release-0.4

为了更新kube-prometheus依赖关系，只需使用jsonnet-bundler更新功能即可：

$ jb update

编译

如：如何编译成manifests: ./build.sh example.jsonnet

在编译之前，用go get github.com/brancz/gojsontoyaml安装gojsontoyaml工具。

注意：必须事先配置以下一些组件。请参见configuration 和customization-examples。

local kp =
  (import 'kube-prometheus/kube-prometheus.libsonnet') +
  // Uncomment the following imports to enable its patches
  // (import 'kube-prometheus/kube-prometheus-anti-affinity.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-managed-cluster.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-node-ports.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-static-etcd.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-thanos-sidecar.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-custom-metrics.libsonnet') +
  {
    _config+:: {
      namespace: 'monitoring',
    },
  };

{ ['setup/0namespace-' + name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } +
{
  ['setup/prometheus-operator-' + name]: kp.prometheusOperator[name]
  for name in std.filter((function(name) name != 'serviceMonitor'), std.objectFields(kp.prometheusOperator))
} +
// serviceMonitor is separated so that it can be created after the CRDs are ready
{ 'prometheus-operator-serviceMonitor': kp.prometheusOperator.serviceMonitor } +
{ ['node-exporter-' + name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } +
{ ['kube-state-metrics-' + name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } +
{ ['alertmanager-' + name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } +
{ ['prometheus-' + name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } +
{ ['prometheus-adapter-' + name]: kp.prometheusAdapter[name] for name in std.objectFields(kp.prometheusAdapter) } +
{ ['grafana-' + name]: kp.grafana[name] for name in std.objectFields(kp.grafana) }

下面是build.sh 脚本（它使用 vendor/ 将所有的 manifests 呈现在一个 {filename: manifest-content} 的 json 结构中）。

#!/usr/bin/env bash

# This script uses arg $1 (name of *.jsonnet file to use) to generate the manifests/*.yaml files.

set -e
set -x
# only exit with zero if all commands of the pipeline exit successfully
set -o pipefail

# Make sure to use project tooling
PATH="$(pwd)/tmp/bin:${PATH}"

# Make sure to start with a clean 'manifests' dir
rm -rf manifests
mkdir -p manifests/setup

# Calling gojsontoyaml is optional, but we would like to generate yaml, not json
jsonnet -J vendor -m manifests "${1-example.jsonnet}" | xargs -I{} sh -c 'cat {} | gojsontoyaml > {}.yaml' -- {}

# Make sure to remove json files
find manifests -type f ! -name '*.yaml' -delete
rm -f kustomization

注意，你需要安装 jsonnet (go get github.com/google/go-jsonnet/cmd/jsonnet) 和 gojsontoyaml (go get github.com/brancz/gojsontoyaml) 才能运行 build.sh。如果你只想要json输出，而不是yaml，那么你可以跳过管道和之后的一切。

这个脚本运行jsonnet代码，然后读取生成的json中的每个key，并将其作为文件名，将该key的值写到该文件中，并将每个json manifest转换为yaml。

应用kub-prometheus

前面的步骤（编译）会在manifest/文件夹中创建了一堆manifest文件。

现在只需按照你的配置使用kubectl来安装Prometheus和Grafana：

# Update the namespace and CRDs, and then wait for them to be availble before creating the remaining resources
$ kubectl apply -f manifests/setup
$ kubectl apply -f manifests/

或者，两个文件夹中的资源可以通过一条命令kubectl apply -Rf manifests来部署，但可能需要多次运行该命令才能成功创建所有组件。

检查monitoring命名空间（或你在namespace:中指定的命名空间），并确保 pods 正在运行。Prometheus 和 Grafana 应该很快就能运行。

容器化安装和编译

如果你不在乎安装了jb或jsonnet或gojsontoyaml，那么可以使用quay.io/coreos/jsonnet-ci容器镜像。从这个kube-prometheus目录中执行以下操作。

$ 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

你可能希望获取在此项目上所做的变更，以便您可以使用。

更新jb

jb可能已经更新了，所以最好是获取这个二进制的最新版本。

$ go get -u github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb

更新kube-prometheus

下面的命令将与上游项目同步

$ jb update

编译 manifests 和 部署

更新后，只需按照 "Compiling "和 "Apply kub-prometheus"下的说明将更改应用到你的集群中。

配置

Jsonnet有一个隐藏字段的概念。这些是不会在结果中呈现的字段。这是用来配置jsonnet中的kube-prometheus组件。在上面自定义Kube-Prometheus例子的jsonnet示例代码中，你可以看到这样的一个例子，其中的命名空间被配置为monitoring。为了不覆盖整个对象，使用jsonnet的+::构造来合并对象，这种方式可以覆盖个别的设置，保留所有其他设置和默认值。

这些是可用的字段及其各自的默认值：

{
    _config+:: {
    namespace: "default",

    versions+:: {
        alertmanager: "v0.17.0",
        nodeExporter: "v0.18.1",
        kubeStateMetrics: "v1.5.0",
        kubeRbacProxy: "v0.4.1",
        prometheusOperator: "v0.30.0",
        prometheus: "v2.10.0",
    },

    imageRepos+:: {
        prometheus: "quay.io/prometheus/prometheus",
        alertmanager: "quay.io/prometheus/alertmanager",
        kubeStateMetrics: "quay.io/coreos/kube-state-metrics",
        kubeRbacProxy: "quay.io/coreos/kube-rbac-proxy",
        nodeExporter: "quay.io/prometheus/node-exporter",
        prometheusOperator: "quay.io/coreos/prometheus-operator",
    },

    prometheus+:: {
        names: 'k8s',
        replicas: 2,
        rules: {},
    },

    alertmanager+:: {
      name: 'main',
      config: |||
        global:
          resolve_timeout: 5m
        route:
          group_by: ['job']
          group_wait: 30s
          group_interval: 5m
          repeat_interval: 12h
          receiver: 'null'
          routes:
          - match:
              alertname: Watchdog
            receiver: 'null'
        receivers:
        - name: 'null'
      |||,
      replicas: 3,
    },

    kubeStateMetrics+:: {
      collectors: '',  // empty string gets a default set
      scrapeInterval: '30s',
      scrapeTimeout: '30s',

      baseCPU: '100m',
      baseMemory: '150Mi',
    },

    nodeExporter+:: {
      port: 9100,
    },
    },
}

Grafana的定义位于不同的项目中 ( https://github.com/brancz/kubernetes-grafana )，但所需的配置可以在同一顶层_config字段中自定义。例如，要允许匿名访问grafana，可以添加以下_config部分：

      grafana+:: {
        config: { // http://docs.grafana.org/installation/configuration/
          sections: {
            "auth.anonymous": {enabled: true},
          },
        },
      },

自定义例子

Jsonnet是一门完整的语言，任何逻辑都可以在其中体现。它还具有强大的合并功能，只需将其合并到提供的对象中，就可以进行任何类型的复杂的自定义。

集群创建工具

一个常见的例子是，并非所有的Kubernetes集群都是以完全相同的方式创建的，这意味着监控它们的配置可能略有不同。对于kubeadm、bootkube、kops和kubespray集群来说，有一些mixins可以轻松配置这些集群。

kubeadm:

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-kubeadm.libsonnet')

bootkube:

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-bootkube.libsonnet')

kops:

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-kops.libsonnet')

kops 与 CoreDNS:

如果你的kops集群使用的是CoreDNS，则需要导入一个额外的mixin。

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-kops.libsonnet') +
(import 'kube-prometheus/kube-prometheus-kops-coredns.libsonnet')

kubespray:

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-kubespray.libsonnet')

kube-aws:

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-kube-aws.libsonnet')

内部仓库（离线仓库）

有些 Kubernetes 安装从内部仓库中获取所有的映像，kube-prometheus 支持这种情况，帮助用户将其使用的每个image同步到内部仓库，并将其生成指向内部仓库。

要生成docker pull/tag/push命令，将上游的镜像同步到internal-registry.com/organization（运行jb命令填充）。

$ jsonnet -J vendor -S --tla-str repository=internal-registry.com/organization sync-to-internal-registry.jsonnet
$ docker pull k8s.gcr.io/addon-resizer:1.8.4
$ docker tag k8s.gcr.io/addon-resizer:1.8.4 internal-registry.com/organization/addon-resizer:1.8.4
$ docker push internal-registry.com/organization/addon-resizer:1.8.4
$ docker pull quay.io/prometheus/alertmanager:v0.16.2
$ docker tag quay.io/prometheus/alertmanager:v0.16.2 internal-registry.com/organization/alertmanager:v0.16.2
$ docker push internal-registry.com/organization/alertmanager:v0.16.2
...

这条命令的输出可以通过附加|sh来传送到shell中执行。

然后用internal-registry.com/organization生成manifests，使用withImageRepository混合（mixin）。

local mixin = import 'kube-prometheus/kube-prometheus-config-mixins.libsonnet';
local kp = (import 'kube-prometheus/kube-prometheus.libsonnet') + {
  _config+:: {
    namespace: 'monitoring',
  },
} + mixin.withImageRepository('internal-registry.com/organization');

{ ['00namespace-' + name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } +
{ ['0prometheus-operator-' + name]: kp.prometheusOperator[name] for name in std.objectFields(kp.prometheusOperator) } +
{ ['node-exporter-' + name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } +
{ ['kube-state-metrics-' + name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } +
{ ['alertmanager-' + name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } +
{ ['prometheus-' + name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } +
{ ['grafana-' + name]: kp.grafana[name] for name in std.objectFields(kp.grafana) }

NodePorts

另一个对探索是帮助mixin是在NodePorts上公开Prometheus、Alertmanager和Grafana的UI。

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-node-ports.libsonnet')

Prometheus对象名

再举一个自定义的例子，默认提供的Prometheus对象的名称可以被覆盖。

((import 'kube-prometheus/kube-prometheus.libsonnet') + {
   prometheus+: {
     prometheus+: {
       metadata+: {
         name: 'my-name',
       },
     },
   },
 }).prometheus.prometheus

node-exporter DaemonSet 命名空间

标准的Kubernetes manifests都是用 ksonnet-lib编写的，所以可以用ksonnet-lib提供的mixins来修改。例如要覆盖node-exporter DaemonSet的命名空间。

local k = import 'ksonnet/ksonnet.beta.3/k.libsonnet';
local daemonset = k.apps.v1beta2.daemonSet;

((import 'kube-prometheus/kube-prometheus.libsonnet') + {
   nodeExporter+: {
     daemonset+:
       daemonset.mixin.metadata.withNamespace('my-custom-namespace'),
   },
 }).nodeExporter.daemonset

Alertmanager配置

Alertmanager配置位于_config.alertmanager.config配置字段中。为了设置一个自定义的Alertmanager配置，只需设置这个字段。

((import 'kube-prometheus/kube-prometheus.libsonnet') + {
   _config+:: {
     alertmanager+: {
       config: |||
         global:
           resolve_timeout: 10m
         route:
           group_by: ['job']
           group_wait: 30s
           group_interval: 5m
           repeat_interval: 12h
           receiver: 'null'
           routes:
           - match:
               alertname: Watchdog
             receiver: 'null'
         receivers:
         - name: 'null'
       |||,
     },
   },
 }).alertmanager.secret

在上面的例子中，配置是内联的，但也可以在jsonnet中通过importstr函数导入的外部文件。

((import 'kube-prometheus/kube-prometheus.libsonnet') + {
   _config+:: {
     alertmanager+: {
       config: importstr 'alertmanager-config.yaml',
     },
   },
 }).alertmanager.secret

添加其他命名空间进行监控

为了监控额外的命名空间，Prometheus服务器需要适当的Role和RoleBinding才能从该命名空间发现目标。默认情况下，Prometheus 服务器被限制在它所需要的三个命名空间中：default、kube-system 和你通过 $._config.namespace 配置的运行的命名空间。这是在$._config.prometheus.namespace中指定的，如果要添加新的命名空间来监控，只需附加额外的命名空间即可。

local kp = (import 'kube-prometheus/kube-prometheus.libsonnet') + {
  _config+:: {
    namespace: 'monitoring',

    prometheus+:: {
      namespaces+: ['my-namespace', 'my-second-namespace'],
    },
  },
};

{ ['00namespace-' + name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } +
{ ['0prometheus-operator-' + name]: kp.prometheusOperator[name] for name in std.objectFields(kp.prometheusOperator) } +
{ ['node-exporter-' + name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } +
{ ['kube-state-metrics-' + name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } +
{ ['alertmanager-' + name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } +
{ ['prometheus-' + name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } +
{ ['grafana-' + name]: kp.grafana[name] for name in std.objectFields(kp.grafana) }

Defining the ServiceMonitor for each additional Namespace

In order to Prometheus be able to discovery and scrape services inside the additional namespaces specified in previous step you need to define a ServiceMonitor resource.
为了让Prometheus能够在上一步中指定的额外命名空间内发现和刮取服务，你需要定义一个ServiceMonitor资源。

Typically it is up to the users of a namespace to provision the ServiceMonitor resource, but in case you want to generate it with the same tooling as the rest of the cluster monitoring infrastructure, this is a guide on how to achieve this.
通常情况下，由命名空间的用户来配置ServiceMonitor资源，但如果你想用与集群监控基础架构的其他部分相同的工具来生成它，这里是关于如何实现这一目标的指南。

You can define ServiceMonitor resources in your jsonnet spec. See the snippet bellow:
你可以在你的jsonnet规范中定义ServiceMonitor资源。请看下面的代码片段。

local kp = (import 'kube-prometheus/kube-prometheus.libsonnet') + {
  _config+:: {
    namespace: 'monitoring',
    prometheus+:: {
      namespaces+: ['my-namespace', 'my-second-namespace'],
    },
  },
  prometheus+:: {
    serviceMonitorMyNamespace: {
      apiVersion: 'monitoring.coreos.com/v1',
      kind: 'ServiceMonitor',
      metadata: {
        name: 'my-servicemonitor',
        namespace: 'my-namespace',
      },
      spec: {
        jobLabel: 'app',
        endpoints: [
          {
            port: 'http-metrics',
          },
        ],
        selector: {
          matchLabels: {
            app: 'myapp',
          },
        },
      },
    },
  },

};

{ ['00namespace-' + name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } +
{ ['0prometheus-operator-' + name]: kp.prometheusOperator[name] for name in std.objectFields(kp.prometheusOperator) } +
{ ['node-exporter-' + name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } +
{ ['kube-state-metrics-' + name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } +
{ ['alertmanager-' + name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } +
{ ['prometheus-' + name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } +
{ ['grafana-' + name]: kp.grafana[name] for name in std.objectFields(kp.grafana) }

NOTE: make sure your service resources has the right labels (eg. 'app': 'myapp') applied. Prometheus use kubernetes labels to discovery resources inside the namespaces.

Static etcd configuration 静态的etcd配置

In order to configure a static etcd cluster to scrape there is a simple kube-prometheus-static-etcd.libsonnet mixin prepared - see etcd.jsonnet for an example of how to use that mixin, and Monitoring external etcd for more information.
为了配置静态etcd集群，有一个简单的kub-prometheus-static-etcd.libsonnet混合器---关于如何使用该混合器的例子，请参阅etcd.jsonnet，更多信息请参见监控外部etcd。

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.)
请注意，由于etcd的设置方式，目前无法在minikube中监控etcd。(minikube的etcd只绑定到127.0.0.0.0.1:2379，而且是在主机网络命名空间内)。

Pod Anti-Affinity（Pod亲和性）

To prevent Prometheus and Alertmanager instances from being deployed onto the same node when possible, one can include the kube-prometheus-anti-affinity.libsonnet mixin:
为了防止 Prometheus 和 Alertmanager 实例在可能的情况下被部署到同一个节点上，可以包含 kub-prometheus-anti-affinity.libsonnet 混合器。

(import 'kube-prometheus/kube-prometheus.libsonnet') +
(import 'kube-prometheus/kube-prometheus-anti-affinity.libsonnet')

Customizing Prometheus alerting/recording rules and Grafana dashboards

自定义普罗米修斯警报/记录规则和Grafana仪表板

See developing Prometheus rules and Grafana dashboards guide.

Exposing Prometheus/Alermanager/Grafana via Ingress

通过Ingress曝光普罗米修斯/Alermanager/Grafana

See exposing Prometheus/Alertmanager/Grafana guide.

Minikube Example

To use an easy to reproduce example, see minikube.jsonnet, which uses the minikube setup as demonstrated in Prerequisites. Because we would like easy access to our Prometheus, Alertmanager and Grafana UIs, minikube.jsonnet exposes the services as NodePort type services.
通过 Ingressa 暴露 Prometheus/Alermanager/Grafana 要使用一个易于重现的例子，请看 minikube.jsonne，它使用了 Prerequisites 中演示的 minikube 设置。因为我们希望方便地访问我们的Prometheus、Alertmanager和Grafana UIs，所以minikube.jsonnet以NodePort类型的服务来显示服务。

Troubleshooting

Authentication problem

The Prometheus /targets page will show the kubelet job with the error 403 Unauthorized, when token authentication is not enabled. Ensure, that the --authentication-token-webhook=true flag is enabled on all kubelet configurations.
当未启用令牌认证时，Prometheus /targets页面将显示kubelet作业的错误403 Unauthorized。请确保 --authentication-token-webhook=true 标志在所有的kubelet配置中都被启用。

Authorization problem

The Prometheus /targets page will show the kubelet job with the error 401 Unauthorized, when token authorization is not enabled. Ensure that the --authorization-mode=Webhook flag is enabled on all kubelet configurations.
Prometheus /targets 页面将显示 kubelet 作业的错误 401 Unauthorized，当令牌授权未启用时。确保在所有的kubelet配置中启用 --authorization-mode=Webhook标志。

kub-state-metrics资源使用情况

In some environments, kube-state-metrics may need additional resources. One driver for more resource needs, is a high number of namespaces. There may be others.
在某些环境中，kub-state-metrics可能需要更多的资源。需要更多资源的一个驱动因素，是大量的命名空间。可能还有其他的驱动因素。

kube-state-metrics resource allocation is managed by addon-resizer You can control it's parameters by setting variables in the config. They default to:
kube-state-metrics资源分配由addon-resizer管理，你可以在config中设置变量来控制它的参数。它们默认为:

kub-state-metrics资源分配由addon-resizer管理

你可以通过在配置中设置变量来控制它的参数。它们的默认值为：

    kubeStateMetrics+:: {
      baseCPU: '100m',
      cpuPerNode: '2m',
      baseMemory: '150Mi',
      memoryPerNode: '30Mi',
    }

贡献

所有在/manifests文件夹中的.yaml文件都是通过Jsonnet生成的。贡献代码提交一般包括以下步骤。

1. 在*.jsonnet文件中进行修改。
2. 提交你的修改。
3. 更新在 jsonnetfile.lock.json: jb update的pinned kube-prometheus依赖关系。
4. make generate生成*.yaml文件。
5. 提交生成的变更。