如何在 kind 中部署 kube-prometheus-stack：用 Helm 搭一套可访问的 Grafana、Prometheus 和 Alertmanager 练习环境

这套方案到底在做什么#

先用最短的话解释一下。

kube-prometheus-stack 不是单独装一个 Prometheus。

它本质上是一个基于 Prometheus Operator 的 Kubernetes 监控方案，通常会把这些组件一起部署出来：

• Prometheus：采集和存储指标
• Grafana：看图表和 Dashboard
• Alertmanager：处理告警
• node-exporter：采集节点指标
• kube-state-metrics：采集 Kubernetes 对象状态指标
• Prometheus Operator：用 Kubernetes CRD 管理监控配置

它和“手工装一个 Prometheus + 自己写一堆抓取规则”的区别在于：

• 你不再主要依赖手写 scrape_config
• 而是通过 ServiceMonitor、PodMonitor、PrometheusRule 这些 Kubernetes 资源管理监控

这就是为什么它更适合拿来练 Kubernetes 监控。

你需要提前准备什么#

本文默认你本机已经有这些工具：

• kind
• kubectl
• helm
• 一个能正常运行的 Docker / 容器运行环境

你可以先简单确认一下：

1
kind version
2
kubectl version --client
3
helm version

如果这三条命令都能正常输出版本，再继续往下做。

第一步：先把实验文件按仓库结构放好#

如果你准备把这套练习长期保留下来，推荐不要把 YAML 和命令散落在桌面目录里，而是单独放进一个实验仓库。

这次对应的仓库是：

这篇里用到的监控实验放在 observability/ 子目录下。

我现在这套内容对应的目录结构是：

1
~/Code/k8s-lab/
2
├── README.md
3
└── observability/
4
    ├── README.md
5
    ├── clusters/
6
    │   └── kind/
7
    │       └── obs/
8
    │           └── kind-observability.yaml
9
    ├── helm/
10
    │   ├── ingress-nginx/
11
    │   │   └── values.yaml
12
    │   └── kube-prometheus-stack/
13
    │       └── values.yaml
14
    ├── manifests/
15
    │   └── demo/
16
    │       ├── namespace.yaml
17
    │       ├── prometheus-example-app.yaml
18
    │       └── servicemonitor.yaml
19
    └── scripts/
20
        ├── install.sh
21
        ├── uninstall.sh
22
        └── port-forward.sh

先进入实验目录：

1
cd ~/Code/k8s-lab/observability

第二步：查看并使用 kind 集群配置#

这份 kind 配置文件放在：

1
clusters/kind/obs/kind-observability.yaml

内容如下：

1
kind: Cluster
2
apiVersion: kind.x-k8s.io/v1alpha4
3
nodes:
4
  - role: control-plane
5
    extraPortMappings:
6
      - containerPort: 30080
7
        hostPort: 8080
8
        protocol: TCP
9
      - containerPort: 30443
10
        hostPort: 8443
11
        protocol: TCP
12
  - role: worker
13
  - role: worker

手动创建集群时，可以这样执行：

1
kind create cluster --name obs --config clusters/kind/obs/kind-observability.yaml
2
kubectl get nodes -o wide

第三步：安装 ingress-nginx#

这个 chart 的 values 文件放在：

1
helm/ingress-nginx/values.yaml

内容如下：

1
controller:
2
  service:
3
    type: NodePort
4
    nodePorts:
5
      http: 30080
6
      https: 30443

先加仓库并更新索引：

1
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
2
helm repo update

再通过 values 文件安装：

1
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
2
  -n ingress-nginx \
3
  --create-namespace \
4
  -f helm/ingress-nginx/values.yaml \
5
  --wait

如果你宿主机的代理写的是本地回环地址，比如：

• HTTP_PROXY=http://127.0.0.1:7890
• HTTPS_PROXY=http://127.0.0.1:7890

要注意：helm repo update 在宿主机上能走代理，不代表 kind 节点里拉镜像也能走同一个地址。

ingress-nginx 真正卡住的地方，通常不是 Helm 本身，而是集群节点里的 containerd 在拉这些镜像时仍然访问自己的 127.0.0.1:7890：

• registry.k8s.io/ingress-nginx/controller
• registry.k8s.io/ingress-nginx/kube-webhook-certgen

这时常见现象是：

• helm upgrade --install 很慢
• 最后 --wait 超时或 context canceled
• kubectl get pods -n ingress-nginx 里出现 ImagePullBackOff

可以直接看事件确认：

1
kubectl get events -n ingress-nginx --sort-by=.lastTimestamp

如果输出里出现类似报错：

1
proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused

说明问题不在 values，也不在 Ingress 资源本身，而是在 kind 节点内部拿不到宿主机上的本地代理。

这种情况下，推荐直接用实验仓库里的 observability/scripts/install.sh 安装。脚本已经把这类本地代理场景处理掉了：当它检测到 HTTP_PROXY / HTTPS_PROXY 指向 127.0.0.1 或 localhost 时，会自动把 kind 节点里 containerd 的代理改写成 Docker kind 网络中的宿主机网关地址，再继续安装。

如果你想手工指定，也可以显式传：

1
KIND_NODE_PROXY=http://172.18.0.1:7890 ./scripts/install.sh

这里的 172.18.0.1 只是当前默认 Docker bridge/kind 网络里常见的宿主机网关地址，实际环境如果不同，请改成你机器上的真实网关地址。

检查结果：

1
kubectl get pods -n ingress-nginx
2
kubectl get svc -n ingress-nginx

第三步：给本地域名做 hosts 映射#

把这几个域名加到本机 /etc/hosts：

1
echo "127.0.0.1 grafana.local prometheus.local alertmanager.local" | sudo tee -a /etc/hosts

后面访问地址就是：

• http://grafana.local:8080
• http://prometheus.local:8080
• http://alertmanager.local:8080

第五步：查看 kube-prometheus-stack 的 values 文件#

这个 values 文件放在：

1
helm/kube-prometheus-stack/values.yaml

内容如下：

1
fullnameOverride: kps
2

3
grafana:
4
  enabled: true
5
  adminPassword: admin
6
  defaultDashboardsTimezone: browser
7
  ingress:
8
    enabled: true
9
    ingressClassName: nginx
10
    hosts:
11
      - grafana.local
12
    path: /
13

14
prometheus:
15
  ingress:
16
    enabled: true
17
    ingressClassName: nginx
18
    hosts:
19
      - prometheus.local
20
    paths:
21
      - /
22
  prometheusSpec:
23
    retention: 2d
24
    scrapeInterval: 15s
25
    evaluationInterval: 15s
26

27
    serviceMonitorSelectorNilUsesHelmValues: false
28
    podMonitorSelectorNilUsesHelmValues: false
29
    ruleSelectorNilUsesHelmValues: false
30

31
    serviceMonitorNamespaceSelector: {}
32
    podMonitorNamespaceSelector: {}
33
    ruleNamespaceSelector: {}
34

35
    resources:
36
      requests:
37
        cpu: 200m
38
        memory: 512Mi
39
      limits:
40
        memory: 2Gi
41

42
alertmanager:
43
  ingress:
44
    enabled: true
45
    ingressClassName: nginx
46
    hosts:
47
      - alertmanager.local
48
    paths:
49
      - /
50
  alertmanagerSpec:
51
    retention: 120h
52

53
kubeControllerManager:
54
  enabled: false
55

56
kubeScheduler:
57
  enabled: false
58

59
kubeEtcd:
60
  enabled: false

1
retention: 2d
2
scrapeInterval: 15s
3
evaluationInterval: 15s

1
serviceMonitorSelectorNilUsesHelmValues: false
2
podMonitorSelectorNilUsesHelmValues: false
3
ruleSelectorNilUsesHelmValues: false
4

5
serviceMonitorNamespaceSelector: {}
6
podMonitorNamespaceSelector: {}
7
ruleNamespaceSelector: {}

1
resources:
2
  requests:
3
    cpu: 200m
4
    memory: 512Mi
5
  limits:
6
    memory: 2Gi

1
kubeControllerManager:
2
  enabled: false
3

4
kubeScheduler:
5
  enabled: false
6

7
kubeEtcd:
8
  enabled: false

第六步：安装 kube-prometheus-stack#

先加仓库并更新：

1
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
2
helm repo update

创建命名空间并安装：

1
kubectl create namespace monitoring
2

3
helm upgrade --install kps prometheus-community/kube-prometheus-stack \
4
  -n monitoring \
5
  -f helm/kube-prometheus-stack/values.yaml \
6
  --wait \
7
  --timeout 10m

如果你已经把脚本也放进仓库，其实这里也可以直接走：

1
./scripts/install.sh

这个脚本会顺序完成：

• 创建 kind 集群
• 安装 ingress-nginx
• 安装 kube-prometheus-stack
• 应用 manifests/demo/ 里的示例资源
• 打印 Ingress 和 ServiceMonitor 检查结果

也就是说，手工命令适合你逐步理解，脚本适合你后面重复搭环境。

安装完成后检查：

1
kubectl get pods -n monitoring
2
kubectl get svc -n monitoring
3
kubectl get ingress -n monitoring
4
kubectl get prometheus -n monitoring
5
kubectl get alertmanager -n monitoring
6
kubectl get servicemonitors -A

第六步：访问 Grafana、Prometheus 和 Alertmanager#

浏览器访问：

• http://grafana.local:8080
• http://prometheus.local:8080
• http://alertmanager.local:8080

Grafana 默认登录信息：

1
用户名：admin
2
密码：admin

第八步：部署一个带 metrics 的示例应用#

真正能说明你已经理解这套体系的，不是把 Grafana 打开，而是把自己的应用接进来。

这套示例资源现在拆到了：

1
manifests/demo/
2
├── namespace.yaml
3
├── prometheus-example-app.yaml
4
└── servicemonitor.yaml

你可以逐个应用：

1
kubectl apply -f manifests/demo/namespace.yaml
2
kubectl apply -f manifests/demo/prometheus-example-app.yaml
3
kubectl apply -f manifests/demo/servicemonitor.yaml

也可以直接交给前面的 ./scripts/install.sh 一次性处理。

检查结果：

1
kubectl get pods -n demo
2
kubectl get svc -n demo
3
kubectl get servicemonitor -n demo

第九步：去 Prometheus 页面验证 Target 和指标#

打开：

• http://prometheus.local:8080

然后进入：

• Status -> Targets

如果配置正确，你应该能看到和 demo/prometheus-example-app 相关的 Target。

再试两个简单查询：

1
version

1
http_requests_total

第十步：这套环境起来以后，应该重点练什么#

环境搭好以后，不要只停留在“我会访问 Grafana”。

更值得练的是下面这些内容：

1. Grafana Dashboard 是怎么自动出现的
2. Prometheus 的 Targets 为什么会 Up 或 Down
3. ServiceMonitor 是怎么发现 Service 的
4. kube-state-metrics 到底提供了哪些 Kubernetes 对象指标
5. node-exporter 到底提供了哪些节点指标
6. PrometheusRule 应该怎么写
7. Alertmanager 怎么接收和分组告警
8. Helm values 是怎么覆盖默认 chart 配置的

可以重点看这些命令：

1
kubectl get servicemonitors -A
2
kubectl describe servicemonitor -n demo prometheus-example-app
3

4
kubectl get prometheusrules -A
5
kubectl get pods -n monitoring
6
kubectl logs -n monitoring deploy/kps-operator
7

8
kubectl get secret -n monitoring
9
kubectl get cm -n monitoring | grep grafana

常见问题 1：为什么我要先装 ingress-nginx#

因为这篇的目标不只是把监控栈“装进去”，还包括让你能从浏览器稳定访问多个服务。

如果没有 Ingress，你当然也可以：

• 用 kubectl port-forward
• 或者改成 NodePort

但那样每个服务都要单独处理，体验不统一，也不利于理解 Kubernetes 中的入口流量管理。

常见问题 2：为什么 values 里要关闭 controller-manager、scheduler、etcd#

不是因为它们不重要，而是因为在本地 kind 环境里，它们经常会带来不必要的 Down Target 噪音。

先关掉的目的是：

• 让主流程先跑通
• 让你先把注意力放在应用接入和监控链路上
• 后面如果你要继续深挖控制平面监控，再单独打开排查

常见问题 3：为什么要单独写 ServiceMonitor#

因为这是 Prometheus Operator 的核心使用方式。

传统 Prometheus 更偏向：

• 手工维护抓取配置

而在 Kubernetes 里，更自然的方式是：

• 让监控配置也变成 Kubernetes 资源
• 让应用通过标签和资源声明被自动发现

这就是 ServiceMonitor 的价值。

清理环境#

如果你练完了，想一键清理，现在更推荐直接用仓库里的脚本：

1
./scripts/uninstall.sh

如果你还想顺便删除 Prometheus Operator 相关 CRD：

1
DELETE_CRDS=true ./scripts/uninstall.sh

如果你只是临时不想走 Ingress，也可以改用：

1
./scripts/port-forward.sh grafana
2
./scripts/port-forward.sh prometheus
3
./scripts/port-forward.sh alertmanager

这样后面重看这套实验时，不只是命令还在，连安装、清理和调试入口都已经整理好了。

这篇流程做完以后，你真正掌握了什么#

如果你把上面这一套完整跑通，收获不只是“会装一个监控组件”。

更准确地说，你已经练到了这些内容：

• 会在 kind 里搭一个可访问的监控实验环境
• 知道 ingress-nginx 在这里承担什么角色
• 知道 kube-prometheus-stack 为什么比单独装 Prometheus 更适合 Kubernetes
• 知道 ServiceMonitor 是怎么把应用接进 Prometheus 的
• 知道如何验证 Target、指标和 Dashboard 是否真的生效

如果你后面继续深入这套环境，可以把练习重点放在这些方向：

• 调整 ServiceMonitor 和 PodMonitor 的发现范围
• 自己写一条 PrometheusRule 做告警实验
• 给 Alertmanager 配一个真实的告警接收方式
• 观察某个应用从暴露指标到进入 Dashboard 的完整链路

这样再回头看这篇流程时，你就不只是“照着装完一套环境”，而是真的把 Kubernetes 监控体系从部署、发现到验证完整走了一遍。