【无标题】 - 技术栈

1. 实验目标

基于 Kubernetes 搭建一个简单电商系统，实现：

前后端业务容器化部署
MariaDB 数据存储
Prometheus 业务监控
kube-state-metrics Kubernetes状态监控
Alertmanager 告警管理
Prometheus异常检测
Kubernetes Pod自动恢复

整体架构：

复制代码

                    用户浏览器
                         |
                         |
              http://192.168.116.169:31080
                         |
                         ↓
              ecommerce-frontend
                    (node1)
                         |
                         ↓
              ecommerce-backend
                    (node1)
                         |
                         ↓
          MariaDB 10.6.19
       192.168.116.169:3306
                         |
                         ↓
              /metrics (业务指标)
                         |
                         ↓
              Prometheus
            master:30090
                         |
                         ↓
             Alertmanager
            master:30093
                         |
                         ↓
          告警展示 / 自动恢复

2. 实验环境

2.1 Kubernetes集群

节点	IP	用途
master	192.168.116.168	K8s控制节点、Prometheus、Alertmanager
node1	192.168.116.169	电商业务节点 + MariaDB数据库
node2	192.168.116.170	原有IoT业务节点

2.2 版本信息

复制代码

Kubernetes: v1.20.15
Docker: 20.10.24
操作系统: CentOS 7.9
Prometheus: v2.45.0
Alertmanager: v0.26.0
MariaDB: 10.6.19

2.3 数据库说明

MariaDB 是独立部署在 node1 上的物理服务，IP：192.168.116.169:3306，不是 K8s 中的 Pod。验证连接：

3. 服务端口规划

多项目共用一个 K8s 集群时，NodePort 是稀缺资源，必须提前分配避免冲突。

3.1 端口分配表

组件	运行位置	访问方式	端口	说明
电商前端	node1	NodePort	31080	用户访问商城页面
电商后端	node1	ClusterIP	5000	前端调用后端接口
MariaDB	node1物理机	物理端口	3306	存储商品、订单数据
Prometheus	master	NodePort	30090	监控页面
Alertmanager	master	NodePort	30093	告警管理页面
kube-state-metrics	kube-system	ClusterIP	8080	K8s状态指标

3.2 访问入口汇总

用途	地址
电商商城页面	`http://192.168.116.169:31080`
Prometheus监控面板	`http://192.168.116.168:30090`
Alertmanager告警管理	`http://192.168.116.168:30093`
后端Metrics指标	`http://ecommerce-backend:5000/metrics`（集群内部）
MariaDB数据库	`192.168.116.169:3306`

3.3 端口设计思路

31080：电商前端 NodePort，用户通过浏览器访问
30090：Prometheus NodePort，用于查看监控数据和告警状态
30093：Alertmanager NodePort，用于查看告警接收情况
5000：后端 ClusterIP，仅集群内部访问，不对外暴露

后端服务只需要被前端 Pod 调用，不需要外部直接访问。使用 ClusterIP 更安全，也节省 NodePort 资源。

4. 项目目录说明

4.1 目录结构

复制代码

4.2 目录作用说明

目录/文件	作用
`backend/`	Flask后端代码 + Dockerfile
`frontend/`	前端静态页面 + Nginx镜像
`k8s/`	电商业务的 Deployment + Service
`manifests/`	监控组件（Prometheus、Alertmanager等）
`*.tar`	监控组件镜像（直接放在 ecommerce 根目录）

5. 部署电商业务

5.1 后端镜像

查看已构建的镜像：

复制代码

5.2 部署业务

在 master 执行：

复制代码

5.3 查看 Service

访问前端页面：

复制代码

6. 部署 kube-state-metrics

6.1 为什么需要 kube-state-metrics？

kube-state-metrics 将 Kubernetes 对象状态（Pod、Deployment、Node）转换为 Prometheus 可读取指标。没有它，Prometheus 只能看到容器资源使用情况，无法感知 Pod 是否 Crash、Deployment 副本数是否正常。

核心指标示例：

kube_pod_status_phase{pod="xxx", phase="Running"} → 1
kube_deployment_status_replicas{deployment="xxx"} → 期望副本数

6.2 部署

复制代码

kubectl apply -f /root/ecommerce/manifests/kube-state-metrics.yaml

6.3 验证

复制代码

7. 部署 Prometheus

7.1 文件说明

文件	作用
`prometheus-deployment.yaml`	部署 Prometheus 容器
`prometheus-service.yaml`	暴露 9090 端口（NodePort: 30090）
`prometheus-config.yaml`	配置采集目标和 scrape 规则
`prometheus-rules.yaml`	告警规则定义

7.3 验证

复制代码

访问 Prometheus UI：

复制代码

8. 添加业务监控指标

8.1 业务指标说明

后端 Flask 应用提供 /metrics 端点，暴露以下指标：

指标名	类型	说明
`ecommerce_orders_total`	Counter	累计订单数
`ecommerce_checkout_queue_length`	Gauge	当前队列长度

访问 Prometheus Targets 页面：

复制代码

状态显示 UP 表示采集成功。

9. 配置告警规则

9.1 告警规则设计思路

prometheus-rules.yaml 定义异常条件：

yaml

复制代码

- alert: EcommerceCheckoutQueueHigh
  expr: ecommerce_checkout_queue_length > 10
  for: 30s
  labels:
    severity: warning
  annotations:
    summary: "订单队列积压超过10"

设计逻辑：

expr：触发条件，队列长度 > 10
for：持续 30s，避免瞬时抖动误报
severity：严重程度分级

9.2 查看规则

10. 部署 Alertmanager

10.1 文件说明

文件	作用
`alertmanager-config.yaml`	配置接收方式和路由规则
`alertmanager-deployment.yaml`	部署 Alertmanager 容器
`alertmanager-service.yaml`	暴露 9093 端口（NodePort: 30093）

10.2 部署

复制代码

kubectl apply -f alertmanager-config.yaml
kubectl apply -f alertmanager-deployment.yaml
kubectl apply -f alertmanager-service.yaml

10.3 验证

复制代码

访问 Alertmanager UI：

11. 模拟业务异常

11.1 进入后端 Pod

复制代码

kubectl exec -it $(kubectl get pod -l app=ecommerce-backend -o name) -- sh

11.2 模拟队列积压

后端提供了专门的测试接口 /api/test/queue：

复制代码

python -c "
import urllib.request

req = urllib.request.Request(
    'http://localhost:5000/api/test/queue',
    method='POST'
)

print(
    urllib.request.urlopen(req)
    .read()
    .decode()
)
"

多次调用后，队列长度指标上升。

11.3 观察指标变化

在 Prometheus 查询：

复制代码

ecommerce_checkout_queue_length

12. 查看告警触发

12.1 Prometheus 告警状态

访问 Prometheus Alerts 页面：

邮件警告：

状态变化链路：

Inactive（正常）→ Pending（30s等待）→ Firing（触发）

12.2 Alertmanager 查看告警

访问 Alertmanager UI：

复制代码

【截图12】Alertmanager 告警列表

显示 EcommerceCheckoutQueueHigh 告警已接收。

说明：Alertmanager 完成告警接收和展示验证。邮件通知功能因 QQ SMTP TLS 配置兼容性问题未继续展开，不影响核心监控链路验证。

13. Kubernetes 自动恢复验证

13.1 为什么 K8s 能自动恢复？

Deployment 控制器保证 replicas 副本数。当 Pod 被删除时，ReplicaSet 控制器检测到实际副本数少于期望值，自动创建新 Pod。

13.2 手动删除 Pod

复制代码

kubectl delete pod -l app=ecommerce-backend

13.3 观察自动恢复

复制代码

kubectl get pods -w

14. 实验总结

14.1 完整链路

text用户访问 → 电商业务 → 业务指标采集 → Prometheus监控 → Alertmanager告警 → Kubernetes自动恢复

14.2 掌握技能

Kubernetes 业务部署（Deployment/Service）
自定义业务指标暴露（Prometheus Client）
Prometheus 监控配置（Targets/Rules）
Alertmanager 告警管理
Kubernetes 自愈机制（ReplicaSet 自动恢复）

14.3 核心设计思路总结

组件	设计思路
端口规划	多项目共存时提前分配端口，避免冲突
kube-state-metrics	将 K8s 对象状态转换为 Prometheus 指标
告警规则	持续30s异常才触发，防止误报
自动恢复	Deployment 控制器的 ReplicaSet 机制