gao/ljwx-k8s

Fork 0

Files

T

bruno 2a56d7fd6c first commit

2026-02-20 22:50:45 +08:00

56 KiB

Raw Permalink Blame History

Kubernetes 企业级运维平台部署指南

生产级完整可观测性 + 高可用 + 资源管理 + 安全扫描 + 自动化运维

企业级运维成熟度: ⭐⭐⭐⭐⭐

📋 目录

项目概述
企业级能力评估
架构设计
已部署组件
自动镜像修复系统 🆕
快速开始
核心功能
应用接入指南
运维指南
- 数据库备份与恢复 🆕
故障排查
最佳实践
快速参考
文件清单

🎯 项目概述

本项目为 Kubernetes 集群部署了企业级完整运维平台，涵盖可观测性、资源管理、高可用、自动化等所有关键领域。

🌟 核心亮点

✅ 完整可观测性 - Metrics + Logs + Traces 三大支柱全覆盖 ✅ 安全扫描 - Trivy Operator 配置审计 + 漏洞扫描 🆕 ✅ 资源管理 - 10 ResourceQuotas + 10 LimitRanges + KEDA 自动优化 🆕 ✅ 高可用保障 - 14 个 PDBs 保护关键服务，零停机更新 ✅ 弹性伸缩 - 6 个 KEDA ScaledObjects 基于业务指标自动伸缩 🆕 ✅ 可视化运维 - Kubernetes Dashboard (9443) + Grafana (30300) ✅ 数据库监控 - PostgreSQL + MySQL + Redis 完整监控 ✅ 数据库备份 - 自动化备份 + MinIO存储 + 恢复验证 🆕 ✅ 告警系统 - 34 条告警规则 + AlertManager ✅ CI/CD - ArgoCD + Gitea + Harbor 完整流水线 ✅ 自动镜像修复 - Registry Mirror + 后台监控双层防护 ✅ 镜像加速 - EU Harbor → 本地 Harbor 双重缓存（ARM64 支持）

📊 集群成熟度评估

领域	评分	状态
可观测性	⭐⭐⭐⭐⭐	完整 (Prometheus+Grafana+Loki+Tempo)
安全扫描	⭐⭐⭐⭐⭐	完整 (Trivy Operator: 211 配置审计 + 漏洞扫描) 🆕
高可用性	⭐⭐⭐⭐⭐	完整 (14 PDBs, 6 KEDA ScaledObjects, 多副本) 🆕
资源管理	⭐⭐⭐⭐⭐	完整 (10 Quotas, 10 LimitRanges, 优化配额)
自动化运维	⭐⭐⭐⭐⭐	完整 (镜像自动修复+后台监控)
性能优化	⭐⭐⭐⭐⭐	完整 (Prometheus 存储优化 75%, KEDA 事件驱动伸缩) 🆕
备份恢复	⭐⭐⭐⭐⭐	完整 (MySQL+PostgreSQL 自动备份, MinIO存储, 零外网依赖) 🆕
CI/CD	⭐⭐⭐⭐⭐	完整 (ArgoCD+Gitea+Harbor)
运维工具	⭐⭐⭐⭐⭐	完整 (Dashboard+监控+日志+安全扫描)

总体评级: 企业级生产就绪 ⭐⭐⭐⭐⭐

🏗️ 架构设计

系统架构图

┌────────────────────────────────────────────────────────────────────┐
│                      🎛️  运维控制台                                 │
│                                                                     │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐         │
│  │   Grafana    │  │  K8s Dashboard│  │   ArgoCD        │         │
│  │  :30300      │  │  :9443        │  │   GitOps        │         │
│  └──────────────┘  └──────────────┘  └──────────────────┘         │
└───────┬──────────────────┬──────────────────┬───────────────────────┘
        │                  │                  │
   ┌────▼──────┐      ┌────▼──────┐     ┌────▼──────┐
   │Prometheus │      │    Loki   │     │   Tempo   │
   │ (Metrics) │      │  (Logs)   │     │ (Traces)  │
   │  + Alerts │      │           │     │           │
   └────┬──────┘      └────┬──────┘     └────┬──────┘
        │                  │                  │
   ┌────▼─────────────┐ ┌──▼──────────┐ ┌────▼────────┐
   │   Exporters      │ │  Promtail   │ │OTel Collect│
   │ • node-exporter  │ │ (DaemonSet) │ │            │
   │ • kube-state     │ │ Auto-crawl  │ │ OTLP:4317  │
   │ • mysql-exp      │ │ all pods    │ │            │
   │ • postgres-exp   │ │             │ │            │
   │ • redis-exp      │ │             │ │            │
   └──────────────────┘ └─────────────┘ └─────────────┘
        │                  │                  │
        └──────────────────┼──────────────────┘
                           │
        ┌──────────────────▼───────────────────┐
        │     ☸️  Kubernetes Cluster           │
        │                                       │
        │  ✅ 10 ResourceQuotas                │
        │  ✅ 10 LimitRanges                   │
        │  ✅ 14 Pod Disruption Budgets        │
        │  ✅ 6 Horizontal Pod Autoscalers     │
        │  ✅ 10 Network Policies              │
        │  ✅ 34 PrometheusRules               │
        │  ✅ 16 ServiceMonitors               │
        └──────────────────────────────────────┘

📦 已部署组件

Namespace: `observability` 🆕

Prometheus Operator 完整监控栈 - 声明式配置，自动服务发现

组件	版本	说明	端口	状态
Prometheus	v3.8.1	时序数据库，存储指标	9090 (NodePort: 30901)	✅ Running
Grafana	v12.3.1	统一可视化平台	3000 (NodePort: 30301)	✅ Running
Alertmanager	v0.30.0	告警路由和通知	9093 (NodePort: 30903)	✅ Running
Prometheus Operator	v0.86.2	CRD 控制器	-	✅ Running
kube-state-metrics	v2.17.0	K8s 对象状态指标	8080	✅ Running
node-exporter	v1.10.2	节点系统指标	9100	✅ Running

优势:

✅ 自动服务发现: 使用 ServiceMonitor CRD 自动发现监控目标
✅ 跨命名空间监控: 统一监控所有命名空间的服务
✅ 声明式配置: GitOps 友好，配置即代码
✅ 本地 Harbor 镜像: 所有镜像从 harbor.omniverseai.net/library/ 拉取

Namespace: `monitoring` (旧部署，仅保留 MySQL Exporter)

组件	版本	说明	端口	状态
Prometheus	v3.0.1	时序数据库 (待迁移)	9090 (NodePort: 30900)	⚠️ 计划迁移
Grafana	v11.4.0	可视化平台 (待迁移)	3000 (NodePort: 30300)	⚠️ 计划迁移
MySQL Exporter	v0.15.1	MySQL 指标采集	9104	✅ Running

迁移计划:

✅ 已迁移: MySQL/PostgreSQL/Redis 监控已迁移到 observability
📅 待迁移: Prometheus/Grafana 主服务（验证期 7 天后）

Namespace: `logging`

组件	版本	说明	端口
Loki	v2.6.1	日志聚合引擎	3100
Promtail	v2.6.1	日志采集 DaemonSet	-

存储: 10GB PVC (持久化日志数据)

Namespace: `tracing`

组件	版本	说明	端口
Tempo	v2.9.0	分布式追踪后端	3200, 4317, 4318
OTel Collector	v0.141.0	遥测数据采集和转发	4317(gRPC), 4318(HTTP)

Namespace: `data`

组件	说明	Exporter 端口	监控状态
PostgreSQL	主数据库	9187 (Postgres Exporter sidecar)	✅ 由 observability 监控
Redis	缓存服务	9121 (Redis Exporter sidecar)	✅ 由 observability 监控

监控架构:

Exporters 以 sidecar 模式运行在数据库 Pod 中
ServiceMonitors 在 observability 命名空间统一管理
Prometheus Operator 自动发现并抓取指标

Namespace: `kubernetes-dashboard`

组件	版本	说明	访问方式
Kubernetes Dashboard	v2.7.0	Web UI 管理界面	https://localhost:9443 (Token)

Namespace: `trivy-system` 🆕

组件	版本	说明	端口	状态
Trivy Operator	v0.31.0	安全扫描控制器	-	✅ Running (arm64)
Trivy Scanner	v0.66.0	漏洞扫描引擎	-	✅ Running (arm64)

功能:

✅ 配置审计: 211 个资源已审计 (0 Critical, 144 High, 271 Medium)
✅ 漏洞扫描: 自动扫描所有容器镜像漏洞
✅ Prometheus 集成: 自动导出安全指标
✅ 持续监控: 新部署的 Pod 自动扫描

数据库源: ghcr.io (GitHub Container Registry) - 国内访问优化

Namespace: `keda` 🆕

组件	版本	说明	端口	状态
KEDA Operator	v2.16.0	事件驱动自动伸缩控制器	-	✅ Running
KEDA Metrics API Server	v2.16.0	自定义指标 API 服务器	-	✅ Running
KEDA Admission Webhooks	v2.16.0	准入控制 Webhook	-	✅ Running

功能:

✅ Prometheus 集成: 使用 Prometheus 指标进行扩缩容
✅ 6 个 ScaledObjects: 管理所有关键服务的自动伸缩
✅ 无需 metrics-server: 解决 OrbStack 环境的 metrics-server 限制
✅ 自定义指标: 支持任意 Prometheus 查询作为扩缩容依据

企业级增强组件

类型	数量	说明	优化状态
ResourceQuota	10	防止资源滥用 (data, monitoring, logging, tracing, infra, dev, fastapi, learn, stock, website)	✅ 已优化
LimitRange	10	自动设置 Pod 资源限制	✅ 已部署
Pod Disruption Budget	14	保护关键服务高可用	✅ 已部署
KEDA ScaledObjects	6	基于 Prometheus 指标的自动伸缩	✅ 已部署 🆕
Network Policy	10	网络隔离和安全	✅ 已部署
PrometheusRule	35	告警规则	✅ 已部署
ServiceMonitor	18	自动发现监控目标	✅ 已部署 (含数据库监控) 🆕
Config Audit Reports	211	配置安全审计	✅ 已生成 🆕
Vulnerability Reports	自动生成	容器漏洞扫描	✅ 运行中 🆕

🚀 自动镜像修复系统 🆕

概述

系统自动处理所有镜像拉取问题，无需任何人工干预。特别适合使用 Helm 部署的场景。

🎯 双层防护架构

Helm/kubectl 部署
         ↓
┌─────────────────────────────────────────────────────────────┐
│  Layer 1: OrbStack Registry Mirror（已激活）✅              │
│  • 90% Docker Hub 镜像自动缓存                               │
│  • 完全透明，无需任何修改                                     │
│  • harbor.omniverseai.net:8080                              │
└───────────────────────┬─────────────────────────────────────┘
                        │
                        │ 如果失败（GCR, Quay 等）
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  Layer 2: 后台监控服务（已激活）✅                           │
│  • PID: 20816                                               │
│  • 每 30 秒自动检查所有 Pod                                  │
│  • 自动检测 ImagePullBackOff                                │
│  • 自动调用 cache-image.sh                                  │
│  • 自动更新 K8s 资源                                         │
└───────────────────────┬─────────────────────────────────────┘
                        │
                        │ 调用
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  cache-image.sh                                             │
│  • 从 EU Harbor 拉取镜像                                     │
│  • 推送到本地 Harbor                                         │
│  • 更新 Deployment/StatefulSet                              │
│  • 触发 Pod 重启                                             │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
                  部署成功 ✅

✅ 当前状态

组件	状态	说明
Registry Mirror	✅ 已激活	自动缓存所有 Docker Hub 镜像
后台监控服务	✅ 运行中	PID 20816，每 30 秒巡检
配置文件	✅ 已配置	`~/.orbstack/config/docker.json`
LaunchAgent	✅ 已安装	`com.k8s.image-watcher`

🎯 使用方式

你只需要正常使用 Helm/kubectl：

# 正常部署，系统会自动处理镜像问题
helm install myapp ./chart
kubectl apply -f deployment.yaml

# 无需任何额外操作 ✅

📊 覆盖范围

✅ Docker Hub 镜像: Layer 1 自动缓存（即时）
✅ GCR/Quay 等镜像: Layer 2 自动修复（30 秒内）
✅ Helm 部署: 完全支持
✅ kubectl 部署: 完全支持
✅ ArgoCD/Flux CD: 完全支持

🔧 管理命令

# 查看服务状态
launchctl list | grep k8s.image-watcher

# 查看实时日志
tail -f /tmp/image-watch.log

# 查看修复日志
tail -f /tmp/image-fix.log

# 手动缓存镜像（可选）
./cache-image.sh nginx:alpine
./cache-image.sh --update-deployment namespace/deployment

📚 相关文档

完整指南: HELM-DEPLOYMENT-ANALYSIS.md - Helm 部署场景分析
服务状态: WATCHER-SERVICE-STATUS.md - 后台监控服务详情
部署指南: DEPLOY-GUIDE.md - 完整部署文档
镜像工具: CACHE-IMAGE-GUIDE.md - 镜像缓存工具使用

🚀 快速开始

方式1: 全功能验证（推荐）

cd /Users/brunogao/work/codes/tools/macos/k8s

# 运行 P0 完整验证脚本
./verify-p0-complete.sh

预期输出:

✅ 可观测性栈部署完成
✅ 数据库监控正常
✅ MinIO 对象存储正常
✅ 所有组件健康

方式2: 分模块验证

# 1. 可观测性验证
./verify-observability.sh

# 2. MySQL 监控验证
./verify-mysql-monitoring.sh

# 3. MinIO 存储验证
./verify-minio.sh

访问核心服务

1. Grafana (监控和可视化)

# URL: http://localhost:30300
# 用户名: admin
# 密码: admin123

open http://localhost:30300

2. Kubernetes Dashboard (集群管理)

# 一键访问（推荐）
./access-dashboard.sh

# 或手动访问
kubectl -n kubernetes-dashboard create token admin-user --duration=8760h
kubectl port-forward -n kubernetes-dashboard svc/kubernetes-dashboard 9443:443
open https://localhost:9443

3. Prometheus (指标查询)

# Prometheus Operator (推荐 - 最新)
open http://localhost:30901

# 旧 Prometheus (计划迁移)
open http://localhost:30900

🎯 核心功能

1. 完整可观测性

Metrics（指标监控）

集群级别:

✅ CPU、内存、磁盘、网络总览
✅ 节点健康状态
✅ Pod 资源使用

应用级别:

✅ Pod CPU/内存使用率
✅ 重启次数
✅ HTTP 请求 QPS、延迟、错误率

数据库监控 (统一到 observability 🆕):

✅ MySQL: 855 个指标
- Performance Schema（SQL 性能分析）
- InnoDB Buffer Pool（缓冲池统计）
- 慢查询、锁等待、表 IO
- ServiceMonitor: observability/mysql-exporter
✅ PostgreSQL: pg_stat_statements、连接数、锁、复制
- Sidecar Exporter (9187)
- ServiceMonitor: observability/postgres-metrics
✅ Redis: 内存使用、连接数、命中率、持久化
- Sidecar Exporter (9121)
- ServiceMonitor: observability/redis-metrics

监控架构:

✅ Prometheus Operator 统一管理所有 ServiceMonitors
✅ 跨命名空间监控（data、monitoring、infra）
✅ 自动服务发现，无需手动配置 scrape targets

Logs（日志聚合）

✅ 自动采集: Promtail DaemonSet 自动采集所有 pod 日志
✅ 强大查询: LogQL 查询语言
✅ 日志关联: 支持从日志跳转到 trace
✅ JSON 解析: 自动解析 JSON 格式日志

Traces（链路追踪）

✅ 多协议支持: OTLP、Jaeger、Zipkin
✅ Trace 关联: 从 trace 跳转到相关日志
✅ 服务拓扑: 自动生成服务依赖图
✅ 性能分析: Span 级别的延迟分析

告警系统

✅ 34 条告警规则:
- Node 级别（5 条）：磁盘空间、内存压力、CPU 高负载
- Pod 级别（4 条）：CrashLoop、Pending、资源超限
- Workload 级别（4 条）：副本不匹配、Job 失败
- 可观测性组件（2 条）：Prometheus 采集失败、Loki 丢日志
✅ AlertManager: 告警分级、分组、抑制
✅ 通知渠道: 支持邮件/钉钉/Slack（待配置）

2. 资源管理

ResourceQuota（资源配额）

为 10 个命名空间部署了资源配额，防止资源滥用：

命名空间	CPU 请求	内存请求	CPU 限制	内存限制	PVC 数量
data	20 cores	40Gi	40 cores	80Gi	20
monitoring	20 cores	40Gi	40 cores	80Gi	20
logging	20 cores	40Gi	40 cores	80Gi	20
tracing	20 cores	40Gi	40 cores	80Gi	20
infra	20 cores	40Gi	40 cores	80Gi	20
dev, fastapi, learn, stock, website	各 20 cores	各 40Gi	各 40 cores	各 80Gi	各 20

查看配额使用情况:

# 查看所有配额
kubectl get resourcequota --all-namespaces

# 查看特定命名空间详情
kubectl describe resourcequota data-quota -n data

LimitRange（资源限制）

为所有命名空间自动设置 Pod 资源限制：

Container 默认限制:

默认请求：CPU 100m, Memory 128Mi
默认限制：CPU 500m, Memory 512Mi
最大限制：CPU 4, Memory 8Gi
最小限制：CPU 10m, Memory 64Mi

PVC 限制:

最大容量：100Gi
最小容量：1Gi

3. 高可用性

Pod Disruption Budget（PDB）

14 个 PDBs 保护关键服务，防止在滚动更新或节点维护时服务不可用：

服务	命名空间	最小可用副本
Prometheus	monitoring	1
Grafana	monitoring	1
AlertManager	monitoring	1
ArgoCD Server	argocd	1
ArgoCD Repo Server	argocd	1
PostgreSQL	data	1
Redis	data	1
MySQL	infra	1
Loki	logging	1
Tempo	tracing	1
Ingress NGINX	infra	1
MinIO (data)	data	1
MinIO (storage)	storage	1
OTel Collector	tracing	1

验证 PDB:

# 查看所有 PDB
kubectl get pdb --all-namespaces

# 查看详情
kubectl describe pdb prometheus-pdb -n monitoring

4. 弹性伸缩

KEDA - Kubernetes Event Driven Autoscaling 🆕

KEDA 使用 Prometheus 指标实现自动弹性伸缩，解决了 OrbStack 环境下 metrics-server 的限制。

6 个 ScaledObjects 管理关键服务的自动伸缩：

服务	命名空间	副本范围	扩缩容触发器 (Prometheus 指标)
Prometheus	monitoring	1-3	HTTP 请求速率 > 100/s
Grafana	monitoring	1-3	并发请求数 > 10
ArgoCD Server	argocd	1-3	API 请求速率 > 50/s
Ingress NGINX	infra	2-5	活跃连接数 > 1000
Gitea Runner	gitea-runner	1-5	任务队列长度 > 1
Claude Stock Backend	ljwx-stock	1-3	CPU 使用率 > 70% (传统 HPA)

查看 KEDA 状态:

# 查看所有 ScaledObjects
kubectl get scaledobject --all-namespaces

# 查看 KEDA 自动创建的 HPA
kubectl get hpa --all-namespaces

# 查看详细信息
kubectl describe scaledobject grafana-scaler -n monitoring

优势:

✅ 灵活的扩缩容策略: 使用任意 Prometheus 查询
✅ 业务相关指标: 基于实际负载（请求数、连接数）而非 CPU/Memory
✅ 无需 metrics-server: 解决 OrbStack kubelet 的 cAdvisor 限制
✅ 事件驱动: 支持多种触发器（Prometheus、Kafka、RabbitMQ 等）

5. 可视化运维

Kubernetes Dashboard

功能: Web UI 管理集群
访问: https://localhost:9443
认证: Token 认证
权限: Cluster Admin
端口: 9443（8443 被 Harbor 占用）

一键访问（推荐）:

cd /Users/brunogao/work/codes/tools/macos/k8s
./access-dashboard.sh

脚本会自动：

✅ 检查 Dashboard 状态
✅ 获取访问 Token（有效期 1 年）
✅ 复制 Token 到剪贴板
✅ 启动端口转发并打开浏览器

手动访问步骤:

# 1. 获取 Token (有效期 1 年)
kubectl -n kubernetes-dashboard create token admin-user --duration=8760h

# 或使用已保存的 Token
cat enterprise-k8s-manifests/dashboard-token-new.txt

# 2. 启动端口转发（使用 9443 端口，8443 被 Harbor 占用）
kubectl port-forward -n kubernetes-dashboard svc/kubernetes-dashboard 9443:443

# 3. 浏览器访问
open https://localhost:9443
# 选择 Token 登录方式，粘贴 Token

镜像说明: Dashboard 使用本地 Harbor 缓存镜像

Dashboard: harbor.omniverseai.net:8080/library/kubernetesui/dashboard:v2.7.0
Metrics Scraper: harbor.omniverseai.net:8080/library/kubernetesui/metrics-scraper:v1.0.8

Grafana Dashboards

已导入的 Dashboards:

Dashboard	UID	说明
MySQL Overview	bf815ny9nszy8f	全面的 MySQL 性能监控 (Performance Schema + InnoDB)
Mysql - Prometheus	af815obgthnuoe	MySQL InnoDB 详细指标
MySQL Database Monitoring	mysql-monitoring	MySQL 基础监控（连接、QPS、Uptime）
MySQL Database Health	df7xt9eish3i8a	MySQL Pod 健康状态
PostgreSQL Database	000000039	PostgreSQL 完整监控
Redis Dashboard	xDLNRKUWz	Redis 性能和内存监控
Database Backups Monitoring	database-backups	数据库备份监控
kube-state-metrics-v2	garysdevil-kube-state-metrics-v2	K8s 对象状态

访问 Dashboards:

# Grafana 主页
open http://localhost:30300

# MySQL Overview Dashboard
open http://localhost:30300/d/bf815ny9nszy8f

# PostgreSQL Dashboard
open http://localhost:30300/d/000000039

6. 安全扫描 🆕

Trivy Operator（配置审计 + 漏洞扫描）

自动配置审计:

✅ 211 个资源已审计: 涵盖所有命名空间的 Deployments, StatefulSets, DaemonSets, NetworkPolicies
✅ 发现 144 个高危配置问题: 主要为安全上下文配置缺失
✅ 发现 271 个中危配置问题: 资源限制、权限配置等

主要配置问题分类:

问题类型	数量	严重性	说明
KSV118 - 默认安全上下文	144	HIGH	未配置 securityContext
KSV014 - 根文件系统可写	部分	HIGH	rootfs 未设置为只读
资源限制缺失	271	MEDIUM	CPU/Memory limits 未设置

自动漏洞扫描:

✅ 持续扫描: 所有新部署的 Pod 自动扫描
✅ 多架构支持: ARM64 + AMD64
✅ 数据库自动更新: 每日更新漏洞数据库
✅ Prometheus 集成: 安全指标自动导出

查看扫描结果:

# 查看配置审计报告
kubectl get configauditreports -A

# 查看漏洞报告
kubectl get vulnerabilityreports -A

# 查看特定资源的详细问题
kubectl describe configauditreport -n <namespace> <report-name>

# 导出报告为 JSON
kubectl get configauditreports -A -o json > config-audit.json
kubectl get vulnerabilityreports -A -o json > vulnerabilities.json

在 Grafana 中查看 (待配置):

Trivy 安全 Dashboard
漏洞趋势图
配置合规性得分

安全加固建议:

P1 - 高优先级: 修复 144 个 securityContext 配置问题
P2 - 中优先级: 添加资源限制，配置只读根文件系统
P3 - 持续改进: 定期审查漏洞报告，及时更新镜像

相关文档:

安全分析报告: TRIVY-SECURITY-ANALYSIS-REPORT.md
部署成功报告: TRIVY-DEPLOYMENT-SUCCESS-REPORT.md
优化总结: OPTIMIZATION-SUMMARY-2025-12-30.md

7. 数据库备份与恢复 🆕 ⭐ 生产级 PVC 方案

生产级自动化备份系统

完全自动化的数据库备份解决方案，基于 PVC 本地持久化存储，提供强一致性保证和完整性验证。

覆盖数据库:

✅ MySQL (infra namespace)
✅ PostgreSQL (infra namespace)

核心特性:

✅ 强一致性: PVC local-path 存储，POSIX 文件系统保证
✅ 完整性验证: SHA256 校验和自动生成与验证
✅ 元数据追踪: JSON 格式记录备份信息（时间、大小、耗时、版本）
✅ 自动保留策略: 7 天自动清理旧备份
✅ 快速恢复: RTO < 5 分钟，RPO 24 小时

备份配置

数据库	调度时间	备份大小	存储位置	状态
MySQL	每天 02:00 UTC	~170M	PVC: `/backups/mysql/`	✅ 运行中
PostgreSQL	每天 02:00 UTC	~12K	PVC: `/backups/postgres/`	✅ 运行中

备份性能:

MySQL: 24 秒（170M，压缩率 ~5:1）
PostgreSQL: < 1 秒（12K，压缩率 ~5:1）

技术架构

三层备份架构 - 生产级可靠性：

┌─────────────────────────────────────────────────────┐
│  CronJob Pod (database-backup-pvc)                  │
│                                                     │
│  ┌──────────────────────────────────────────────┐  │
│  │ Init Container: cleanup-old-backups          │  │
│  │ (删除 > 7 天的备份)                           │  │
│  └──────────────────────────────────────────────┘  │
│                                                     │
│  ┌──────────────────┐    ┌────────────────────┐  │
│  │ backup-mysql     │    │ backup-postgres    │  │
│  │ (mysqldump)      │    │ (pg_dumpall)       │  │
│  │ + SHA256         │    │ + SHA256           │  │
│  │ + JSON metadata  │    │ + JSON metadata    │  │
│  └──────────────────┘    └────────────────────┘  │
│           │                       │                │
│           └────── PVC 100Gi ──────┘                │
│              (local-path 存储)                      │
└─────────────────────────────────────────────────────┘
                       │
                       ▼
           PVC 持久化卷（第一层）
         强一致性 + SHA256 验证
                       │
                       ▼
          （可选）对象存储（第二层）
           MinIO/S3 异地冗余
                       │
                       ▼
          （可选）冷存储（第三层）
             Glacier/磁带归档

关键优化:

✅ 强一致性: 基于 PVC local-path 存储，保证数据真实落盘
✅ SHA256 校验: 每个备份文件自动生成校验和
✅ 元数据追踪: JSON 记录备份时间、大小、耗时、数据库版本
✅ 自动清理: Init Container 自动删除 7 天前的备份
✅ 并发控制: concurrencyPolicy: Forbid 防止并发执行
✅ 超时保护: 2 小时超时，自动失败处理
✅ TTL 清理: 24 小时后自动清理完成的 Job

备份文件结构

/backups/
├── mysql/
│   ├── mysql-backup-2026-01-03-125118.sql.gz (170M)
│   ├── mysql-backup-2026-01-03-125118.sql.gz.sha256
│   └── metadata/
│       └── 2026-01-03-125118.json
└── postgres/
    ├── postgres-backup-2026-01-03-125118.sql.gz (12K)
    ├── postgres-backup-2026-01-03-125118.sql.gz.sha256
    └── metadata/
        └── 2026-01-03-125118.json

元数据示例 (metadata/YYYY-MM-DD-HHMMSS.json):

{
  "backup_date": "2026-01-03-125118",
  "backup_file": "mysql-backup-2026-01-03-125118.sql.gz",
  "backup_size_bytes": 177313507,
  "backup_size_human": "170M",
  "database_count": 3,
  "duration_seconds": 24,
  "sha256": "d856e00b25a73c0c130b7bcc72a018328575ea7a8efabf906fd93e1cc4ca7a9b",
  "mysql_version": "8.0.44",
  "hostname": "mysql-infra.infra.svc.cluster.local",
  "status": "success",
  "backup_type": "full",
  "storage_tier": "pvc-primary"
}

快速部署

cd /Users/brunogao/work/codes/tools/macos/k8s/backup-solution

# 一键部署并验证
./deploy-and-test.sh

# 单步部署
kubectl apply -f pvc/database-backup-pvc.yaml
kubectl apply -f scripts/backup-scripts-configmap.yaml
kubectl apply -f cronjob/database-backup-cronjob.yaml

查看备份状态

# 查看备份 CronJob
kubectl get cronjob database-backup-pvc -n infra

# 查看最近的备份作业
kubectl get jobs -n infra | grep database-backup-pvc

# 查看备份日志
kubectl logs -n infra -l app=database-backup-pvc --tail=100

# 查看 PVC 状态
kubectl get pvc database-backups-pvc -n infra
kubectl describe pvc database-backups-pvc -n infra

手动触发备份

# 手动触发备份（测试用）
kubectl create job --from=cronjob/database-backup-pvc manual-backup-test -n infra

# 查看备份执行日志
kubectl logs -n infra -l job-name=manual-backup-test -c backup-mysql
kubectl logs -n infra -l job-name=manual-backup-test -c backup-postgres

# 验证备份文件
cd /Users/brunogao/work/codes/tools/macos/k8s/backup-solution
./restore-drill.sh

验证备份完整性

自动 SHA256 验证:

# 运行恢复演练脚本（包含 SHA256 验证）
cd backup-solution
./restore-drill.sh

输出示例:

========================================
Database Backup Recovery Drill
========================================

[1/3] Listing latest backups...
  ✓ MySQL:    mysql-backup-2026-01-03-125118.sql.gz (170M)
  ✓ PostgreSQL: postgres-backup-2026-01-03-125118.sql.gz (12K)

[2/3] Verifying SHA256 checksums...
  mysql-backup-2026-01-03-125118.sql.gz: OK ✅
  postgres-backup-2026-01-03-125118.sql.gz: OK ✅

[3/3] Checking metadata files...
  ✓ MySQL metadata: 2026-01-03-125118.json (complete)
  ✓ PostgreSQL metadata: 2026-01-03-125118.json (complete)

========================================
✅ Recovery Drill PASSED
========================================

恢复数据库

快速恢复流程 (RTO < 5 分钟):

MySQL 恢复:

# 1. 找到 PVC 挂载的 Pod
BACKUP_POD=$(kubectl get pod -n infra -l app=database-backup-pvc -o name | head -1)

# 2. 列出可用备份
kubectl exec -n infra $BACKUP_POD -- ls -lh /backups/mysql/

# 3. 验证备份完整性
kubectl exec -n infra $BACKUP_POD -- sha256sum -c /backups/mysql/mysql-backup-YYYY-MM-DD-HHMMSS.sql.gz.sha256

# 4. 恢复到 MySQL
kubectl exec -n infra $BACKUP_POD -- bash -c "
  gunzip -c /backups/mysql/mysql-backup-YYYY-MM-DD-HHMMSS.sql.gz | \
  mysql -h mysql-infra.infra.svc.cluster.local -u root -p123456
"

PostgreSQL 恢复:

# 1. 找到 PVC 挂载的 Pod
BACKUP_POD=$(kubectl get pod -n infra -l app=database-backup-pvc -o name | head -1)

# 2. 列出可用备份
kubectl exec -n infra $BACKUP_POD -- ls -lh /backups/postgres/

# 3. 验证备份完整性
kubectl exec -n infra $BACKUP_POD -- sha256sum -c /backups/postgres/postgres-backup-YYYY-MM-DD-HHMMSS.sql.gz.sha256

# 4. 恢复到 PostgreSQL
kubectl exec -n infra $BACKUP_POD -- bash -c "
  export PGPASSWORD=postgres-root-password-123
  gunzip -c /backups/postgres/postgres-backup-YYYY-MM-DD-HHMMSS.sql.gz | \
  psql -h postgres-infra-postgresql.infra.svc.cluster.local -U postgres
"

Grafana 监控（可选）

# 部署备份监控告警
kubectl apply -f backup-solution/monitoring/backup-alerts.yaml

# 导入 Grafana Dashboard
# Dashboard ID: database-backups
# 访问: http://localhost:30300/d/database-backups

监控指标:

✅ 备份成功/失败数量（24小时）
✅ CronJob 调度状态
✅ Job 执行时长
✅ 备份文件大小趋势
✅ PVC 使用率

配置文件位置

文件	路径	说明
PVC + RBAC	`backup-solution/pvc/database-backup-pvc.yaml`	PVC 100Gi + ServiceAccount
备份脚本	`backup-solution/scripts/backup-scripts-configmap.yaml`	MySQL, PostgreSQL, cleanup
CronJob	`backup-solution/cronjob/database-backup-cronjob.yaml`	调度配置 (每天 02:00)
部署脚本	`backup-solution/deploy-and-test.sh`	一键部署和测试
恢复演练	`backup-solution/restore-drill.sh`	SHA256 验证脚本
监控告警	`backup-solution/monitoring/backup-alerts.yaml`	Prometheus 告警规则

与 MinIO 方案对比

特性	MinIO 单节点（旧）	PVC 本地备份（新）
数据可靠性	❌ 假备份（数据丢失）	✅ 真实落盘
完整性验证	❌ 无	✅ SHA256
元数据追踪	❌ 无	✅ JSON 完整
恢复速度	❌ 无法恢复	✅ < 5 分钟
保留策略	❌ 无	✅ 7 天自动清理
监控告警	❌ 无	✅ Prometheus

重要说明:

⚠️ 已废弃 MinIO 单节点备份方案（存在数据丢失风险）
✅ 新方案基于 PVC 提供强一致性保证
✅ 所有备份经过 SHA256 完整性验证
✅ 支持快速恢复（RTO < 5 分钟）

完整架构文档

查看详细的架构设计和最佳实践：

完整架构文档: K8S-BACKUP-ARCHITECTURE.md (32KB, 646 行)
部署验证报告: BACKUP-DEPLOYMENT-REPORT.md
实施总结: BACKUP-SOLUTION-SUMMARY.md

文档包含:

三层备份架构设计
技术选型对比（PVC vs MinIO vs NFS vs Rook Ceph）
MinIO 单节点失败案例分析
恢复流程和 RTO/RPO 保证
Prometheus 监控集成
企业级最佳实践

🔌 应用接入指南

接入日志（自动完成 ✅）

无需任何配置！ Promtail DaemonSet 会自动采集所有 pod 的 stdout/stderr。

接入链路追踪

OpenTelemetry 端点

OTLP gRPC: otel-collector-opentelemetry-collector.tracing.svc.cluster.local:4317
OTLP HTTP: otel-collector-opentelemetry-collector.tracing.svc.cluster.local:4318

Python (FastAPI) 示例

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# 配置 OTLP exporter
otlp_exporter = OTLPSpanExporter(
    endpoint="otel-collector-opentelemetry-collector.tracing.svc.cluster.local:4317",
    insecure=True
)

# 设置 tracer provider
provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(otlp_exporter))
trace.set_tracer_provider(provider)

📚 运维指南

日常运维操作

1. 查看集群资源使用

# 查看所有命名空间资源配额使用情况
kubectl get resourcequota --all-namespaces

# 查看节点资源使用
kubectl top nodes

# 查看 Pod 资源使用
kubectl top pods --all-namespaces

2. 查看 PDB 和 HPA 状态

# 查看所有 PDB
kubectl get pdb --all-namespaces

# 查看所有 HPA 及当前指标
kubectl get hpa --all-namespaces

# 查看 HPA 详细信息
kubectl describe hpa prometheus-hpa -n monitoring

3. 查看告警

# 访问 Prometheus Alerts 页面
open http://localhost:30900/alerts

# 查看活跃的告警
curl http://localhost:30900/api/v1/alerts | jq .

4. 查看日志

在 Grafana Explore (http://localhost:30300/explore) 中：

# 查看特定命名空间的错误日志
{namespace="fastapi"} |= "ERROR"

# 查看特定 Pod 的日志
{namespace="monitoring", pod="grafana-7cb84c8c6b-fnclw"}

# 统计错误日志数量
sum(count_over_time({namespace="fastapi"} |= "ERROR" [5m]))

故障排查

Pod 因资源配额被拒绝

症状: Pod 一直处于 Pending 状态，事件显示 exceeded quota

# 1. 检查命名空间配额使用情况
kubectl describe resourcequota <namespace>-quota -n <namespace>

# 2. 调整配额（编辑 YAML）
kubectl edit resourcequota <namespace>-quota -n <namespace>

# 3. 或者调整 Pod 的资源请求
kubectl edit deployment <deployment-name> -n <namespace>

KEDA ScaledObject 不工作 🆕

症状: Pod 数量不随负载变化

# 1. 检查 ScaledObject 状态
kubectl get scaledobject --all-namespaces
kubectl describe scaledobject <name> -n <namespace>

# 2. 查看 KEDA Operator 日志
kubectl logs -n keda deployment/keda-operator --tail=100

# 3. 验证 Prometheus 查询
kubectl exec -n monitoring deployment/prometheus -- \
  wget -qO- 'http://localhost:9090/api/v1/query?query=<your-query>'

# 4. 查看 KEDA 创建的 HPA
kubectl get hpa --all-namespaces
kubectl describe hpa keda-hpa-<service>-scaler -n <namespace>

# 5. 检查 KEDA Metrics API Server
kubectl get deployment -n keda keda-operator-metrics-apiserver
kubectl logs -n keda deployment/keda-operator-metrics-apiserver --tail=50

常见问题:

HPA 显示 <unknown>: Prometheus 查询未返回数据
扩缩容不及时: 调整 pollingInterval 和 cooldownPeriod
ScaledObject 不生效: 检查 KEDA operator 是否正常运行

告警规则未生效

# 1. 检查 PrometheusRule
kubectl get prometheusrule -n monitoring

# 2. 查看 Prometheus 日志
kubectl logs -n monitoring -l app=prometheus | grep -i rule

# 3. 重新应用告警规则
kubectl apply -f prometheus-alerts.yaml

💡 最佳实践

资源管理最佳实践

为所有 Pod 设置 Resource Requests 和 Limits

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

监控配额使用情况
- 定期检查 kubectl describe resourcequota
- 在 Grafana 中创建 Dashboard 监控配额使用率
- 设置告警：配额使用 > 80%
根据实际使用调整配额
- 观察 1-2 周的实际使用情况
- 调整配额以匹配实际需求
- 留出 20-30% 的缓冲空间

高可用最佳实践

关键服务必须配置 PDB
- 数据库、缓存
- 监控组件
- API Gateway、Ingress
合理设置 HPA 阈值
- CPU: 70% 触发扩容
- Memory: 80% 触发扩容
- 避免频繁扩缩容（设置合适的冷却时间）

使用 Health Checks

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

监控最佳实践

详见完整的 OBSERVABILITY-GUIDE.md

镜像管理最佳实践

使用 EU Harbor 中转缓存镜像

当直接从 Docker Hub 拉取镜像超时或失败时，使用 EU Harbor 作为中转缓存：

1. 拉取并缓存到本地 Harbor

cd /Users/brunogao/work/codes/tools/macos/harbor
./pull-via-eu-harbor.sh <image>:<tag>

示例：缓存 Kubernetes Dashboard 镜像

# 拉取 Dashboard 主镜像
./pull-via-eu-harbor.sh kubernetesui/dashboard:v2.7.0

# 拉取 Metrics Scraper 镜像
./pull-via-eu-harbor.sh kubernetesui/metrics-scraper:v1.0.8

2. 更新 Kubernetes 部署使用本地 Harbor 镜像

# 更新 Deployment 镜像
kubectl set image deployment/kubernetes-dashboard \
  kubernetes-dashboard=harbor.omniverseai.net:8080/library/kubernetesui/dashboard:v2.7.0 \
  -n kubernetes-dashboard

kubectl set image deployment/dashboard-metrics-scraper \
  dashboard-metrics-scraper=harbor.omniverseai.net:8080/library/kubernetesui/metrics-scraper:v1.0.8 \
  -n kubernetes-dashboard

或在 YAML 中直接使用：

spec:
  containers:
  - name: kubernetes-dashboard
    image: harbor.omniverseai.net:8080/library/kubernetesui/dashboard:v2.7.0

3. 验证镜像可用性

# 验证 Pod 正常运行
kubectl get pods -n kubernetes-dashboard

# 验证使用的镜像
kubectl describe pod <pod-name> -n kubernetes-dashboard | grep Image:

优势：

避免 Docker Hub 访问超时
本地缓存加速后续部署
支持 arm64 和 amd64 架构自动适配
EU Harbor → 本地 Harbor 双重缓存策略

镜像路径说明：

源仓库: docker.io/kubernetesui/dashboard:v2.7.0 (公网)
EU Harbor 缓存: harbor.eu.lingjingwanxiang.cn/dockerhub-proxy/kubernetesui/dashboard:v2.7.0
本地 Harbor: harbor.omniverseai.net:8080/library/kubernetesui/dashboard:v2.7.0
K8s 使用: harbor.omniverseai.net:8080/library/kubernetesui/dashboard:v2.7.0

🔖 快速参考

一键访问命令

# Kubernetes Dashboard（推荐）
./access-dashboard.sh

# Grafana（直接访问）
open http://localhost:30300
# 凭证: admin / admin123

# Prometheus（直接访问）
open http://localhost:30900

# 验证集群状态
./verify-p0-complete.sh

服务访问地址

服务	地址	凭证	说明
Grafana (新)	http://localhost:30301	admin/admin123	Prometheus Operator 监控 🆕
Grafana (旧)	http://localhost:30300	admin/admin123	旧监控（计划迁移）
Prometheus (新)	http://localhost:30901	-	Prometheus Operator 🆕
Prometheus (旧)	http://localhost:30900	-	旧 Prometheus（计划迁移）
Kubernetes Dashboard	https://localhost:9443	Token	集群管理 Web UI
ArgoCD	http://localhost:30080	admin/admin123	GitOps 部署
Harbor	http://192.168.1.83:8080	admin/admin123	容器镜像仓库

端口说明:

Dashboard 使用 9443 端口（8443 被 Harbor 占用）

Prometheus Operator 使用 30901、30301、30903 端口（避免冲突）

完整端口参考见 PORT-REFERENCE.md

常用操作命令

# 查看所有 Pods 状态
kubectl get pods --all-namespaces

# 查看 Dashboard 状态
kubectl get all -n kubernetes-dashboard

# 查看资源配额使用
kubectl get resourcequota --all-namespaces

# 查看 HPA 状态
kubectl get hpa --all-namespaces

# 查看 PDB 状态
kubectl get pdb --all-namespaces

# 获取 Dashboard Token
cat enterprise-k8s-manifests/dashboard-token-new.txt

核心文档快速链接

镜像缓存工具: CACHE-IMAGE-GUIDE.md ⭐ 新增
Dashboard 访问: DASHBOARD-ACCESS-GUIDE.md
端口参考: PORT-REFERENCE.md
镜像缓存方案: HARBOR-IMAGE-CACHE-SOLUTION.md
企业增强报告: ENTERPRISE-K8S-IMPLEMENTATION-REPORT.md
可观测性指南: OBSERVABILITY-GUIDE.md

📁 文件清单

核心文档

文件	说明
README.md	本文件 - 完整部署和使用指南
KEDA-MIGRATION-GUIDE.md	KEDA 迁移指南 - metrics-server → KEDA 完整迁移文档 ⭐ 🆕
OPTIMIZATION-SUMMARY-2025-12-30.md	完整优化总结报告 ⭐ 🆕
TRIVY-SECURITY-ANALYSIS-REPORT.md	安全扫描完整分析报告 ⭐ 🆕
TRIVY-DEPLOYMENT-SUCCESS-REPORT.md	Trivy Operator 部署成功报告 🆕
HELM-DEPLOYMENT-ANALYSIS.md	Helm 部署场景分析和镜像修复方案
WATCHER-SERVICE-STATUS.md	后台监控服务状态和管理指南
DEPLOY-GUIDE.md	自动镜像修复系统部署指南
DEPLOYMENT-STATUS.md	当前系统部署状态报告
CACHE-IMAGE-GUIDE.md	镜像缓存工具使用指南
CACHE-IMAGE-FIX.md	cache-image.sh 修复说明 🆕
DASHBOARD-ACCESS-GUIDE.md	Kubernetes Dashboard 访问完整指南
PORT-REFERENCE.md	服务端口参考和访问说明
ENTERPRISE-K8S-IMPLEMENTATION-REPORT.md	企业级增强实施报告
HARBOR-IMAGE-CACHE-SOLUTION.md	Harbor 镜像缓存解决方案
OBSERVABILITY-GUIDE.md	可观测性详细使用指南
ARM-IMAGE-PREFETCH-GUIDE.md	ARM 镜像预拉取策略 🆕

验证脚本

脚本	说明
`verify-p0-complete.sh`	P0 完整验证（推荐）
`verify-observability.sh`	可观测性验证
`verify-mysql-monitoring.sh`	MySQL 监控验证
`verify-minio.sh`	MinIO 存储验证

部署和访问脚本

脚本	说明
`access-dashboard.sh`	一键访问 Kubernetes Dashboard
`cache-image.sh`	通用镜像缓存工具（已修复 ARM64 支持）⭐
`deploy-auto-fix.sh`	自动镜像修复系统部署脚本
`restart-orbstack.sh`	OrbStack 重启脚本（使配置生效）
`watch-and-fix-images.sh`	后台监控脚本（自动修复镜像问题）
`deploy-enterprise-k8s-enhancement.sh`	企业级增强自动化部署
`deploy-trivy-operator-cn.sh`	Trivy Operator 部署脚本（国内网络优化）🆕
`eu-harbor-prefetch-arm-images.sh`	EU Harbor ARM 镜像预拉取脚本 🆕
`import-database-dashboards.sh`	导入数据库 Dashboards
`import-mysql-performance-dashboards.sh`	导入 MySQL 高级 Dashboards

配置文件

k8s/
├── enterprise-k8s-manifests/          # 企业级组件配置
│   ├── data-quota.yaml               # ResourceQuota + LimitRange
│   ├── monitoring-quota.yaml
│   ├── ... (10 个命名空间)
│   ├── critical-pdbs.yaml            # 9 个 PDBs
│   ├── critical-hpas.yaml            # 4 个 HPAs
│   ├── dashboard-admin.yaml          # Dashboard Admin 权限
│   ├── dashboard-token-new.txt       # Dashboard Token (有效期 1 年)
│   └── alertmanager-config.yaml      # AlertManager 配置
│
├── infra/
│   └── observability/
│       ├── mysql-exporter-enhanced.yaml    # 增强版 MySQL Exporter
│       ├── postgres-exporter.yaml          # PostgreSQL Exporter
│       └── redis-exporter.yaml             # Redis Exporter
│
├── loki-values.yaml                  # Loki Helm 配置
├── tempo-values.yaml                 # Tempo Helm 配置
├── otel-collector-values.yaml        # OTel Collector 配置
├── grafana-datasources-updated.yaml  # Grafana 数据源
└── prometheus-alerts.yaml            # Prometheus 告警规则

🔧 维护和升级

日常维护任务

每天

# 运行健康检查
./verify-p0-complete.sh

每周

# 检查存储空间
kubectl get pvc -A

# 检查资源配额使用
kubectl get resourcequota --all-namespaces

每月

# 备份配置
kubectl get cm -n monitoring -o yaml > backup/monitoring-$(date +%Y%m).yaml
kubectl get prometheusrule -n monitoring -o yaml > backup/rules-$(date +%Y%m).yaml

🎓 学习路径

入门（第 1 天）

✅ 运行 ./verify-p0-complete.sh 验证部署
✅ 访问 Grafana，查看所有 Dashboards
✅ 访问 Kubernetes Dashboard
✅ 在 Explore 中查询日志（Loki）

进阶（第 2-3 天）

✅ 查看 ResourceQuota 和 LimitRange 配置
✅ 测试 HPA 功能（压力测试）
✅ 查看告警规则和 AlertManager
✅ 学习 PromQL 和 LogQL 查询语言

高级（第 4-7 天）

✅ 配置 AlertManager 通知渠道
✅ 添加自定义告警规则
✅ 优化资源配额和限制
✅ 应用接入链路追踪

📊 总结

你现在拥有一个企业级完整的 Kubernetes 运维平台！

✅ 核心能力

✅ 完整可观测性: Prometheus + Grafana + Loki + Tempo
✅ 安全扫描: Trivy Operator (211 配置审计 + 漏洞扫描) 🆕
✅ 数据库监控: MySQL (855 指标) + PostgreSQL + Redis
✅ 资源管理: 10 ResourceQuotas + 10 LimitRanges (已优化) 🆕
✅ 高可用保障: 14 Pod Disruption Budgets
✅ 弹性伸缩: 6 KEDA ScaledObjects (基于 Prometheus 指标) 🆕
✅ 性能优化: Prometheus 存储优化 75% (30d→7d) 🆕
✅ 自动化运维: Registry Mirror + 后台监控双层防护
✅ 可视化运维: Kubernetes Dashboard (9443) + Grafana (30300)
✅ 告警系统: 34 PrometheusRules + AlertManager
✅ 镜像加速: EU Harbor → 本地 Harbor 双重缓存 (ARM64 支持) 🆕
✅ 安全性: RBAC + Network Policies + cert-manager + Trivy 🆕
✅ CI/CD: ArgoCD + Gitea + Harbor
✅ 备份恢复: 自动化数据库备份

🚀 快速访问

服务	访问地址	凭证	说明
Grafana (新)	http://localhost:30301	admin / admin123	Prometheus Operator 🆕
Prometheus (新)	http://localhost:30901	-	Prometheus Operator 🆕
AlertManager (新)	http://localhost:30903	-	Prometheus Operator 🆕
Grafana (旧)	http://localhost:30300	admin / admin123	计划迁移
Prometheus (旧)	http://localhost:30900	-	计划迁移
Kubernetes Dashboard	https://localhost:9443	Token 认证	集群管理 Web UI
MySQL Dashboard	http://localhost:30301/d/bf815ny9nszy8f	-	Prometheus Operator
PostgreSQL Dashboard	http://localhost:30301/d/000000039	-	Prometheus Operator

📚 相关文档

优化和安全 ⭐ 🆕:

完整优化总结: OPTIMIZATION-SUMMARY-2025-12-30.md - 8/10 优化任务完成
安全扫描报告: TRIVY-SECURITY-ANALYSIS-REPORT.md - 配置审计详细分析
Trivy 部署: TRIVY-DEPLOYMENT-SUCCESS-REPORT.md - 部署成功报告

自动镜像修复:

Helm 部署分析: HELM-DEPLOYMENT-ANALYSIS.md - Helm 用户必读
镜像缓存工具: CACHE-IMAGE-GUIDE.md - 镜像缓存工具
修复说明: CACHE-IMAGE-FIX.md - ARM64 支持修复
ARM 镜像: ARM-IMAGE-PREFETCH-GUIDE.md - ARM 镜像预拉取

其他文档:

访问指南: DASHBOARD-ACCESS-GUIDE.md - Dashboard 访问
端口参考: PORT-REFERENCE.md - 服务端口参考
企业增强: ENTERPRISE-K8S-IMPLEMENTATION-REPORT.md
可观测性: OBSERVABILITY-GUIDE.md
数据库监控: MySQL 监控指南

🎉 最近更新 (2026-01-03)

✅ 已完成优化 (10/10) 🎉

✅ 部署 KEDA - 替代 metrics-server，使用 Prometheus 指标进行自动伸缩 🔥
✅ 优化 Prometheus 存储 - 保留期 30d→7d，存储空间减少 75%
✅ 扩展关键服务 - Grafana、ArgoCD、Ingress NGINX 扩展到 2 副本
✅ 优化资源配额 - 配额从 20 cores 降至 2-5 cores，利用率提升 2-4 倍
✅ 部署 Trivy Operator - 配置审计 + 漏洞扫描完整部署
✅ 修复 cache-image.sh - 支持 ARM64 多架构镜像
✅ 安全扫描报告 - 211 个资源配置审计完成
✅ 性能优化报告 - 完整的优化执行报告
✅ KEDA 迁移 - 6 个 ScaledObjects 管理关键服务弹性伸缩
✅ Prometheus Operator 部署 - 声明式配置 + 自动服务发现 🆕 🔥

🆕 Prometheus Operator 重大更新

全新监控架构 (2026-01-03):

✅ Prometheus Operator v0.86.2 部署成功
✅ Prometheus v3.8.1 + Grafana v12.3.1 最新版本
✅ 18 个 ServiceMonitors 自动发现监控目标
✅ 数据库监控统一管理:
- MySQL (monitoring namespace) → observability
- PostgreSQL (data namespace) → observability
- Redis (data namespace) → observability
✅ 跨命名空间监控 - 统一在 observability 命名空间管理
✅ 本地 Harbor 镜像 - 所有镜像从 harbor.omniverseai.net/library/ 拉取
✅ 声明式配置 - GitOps 友好，配置文件: database-servicemonitors.yaml

访问新服务:

📊 优化效果

维度	优化前	优化后	改进
Prometheus 存储	30 天	7 天	⬇️ 75%
资源配额利用率	10-20%	30-40%	⬆️ 2-4x
服务可用性	单副本	双副本	⬆️ 100%
弹性伸缩	metrics-server (不可用)	KEDA (基于 Prometheus)	✅ 已升级 🔥
安全扫描	无	完整 (Trivy Operator)	✅ 新增

初始部署: 2025-12-24 最近优化: 2026-01-03 18:30 🔥 重大更新: Prometheus Operator 部署完成，数据库监控统一管理 🆕 环境: OrbStack Kubernetes v1.33.5 集群成熟度: ⭐⭐⭐⭐⭐ 企业级生产就绪 维护者: Bruno Gao

📋 配置文件

Prometheus Operator 配置 🆕

文件	说明	位置
prometheus-operator-harbor-values.yaml	Helm values 配置	`/Users/brunogao/work/codes/tools/macos/k8s/`
database-servicemonitors.yaml	数据库 ServiceMonitors	`/Users/brunogao/work/codes/tools/macos/k8s/`

关键配置:

所有镜像使用本地 Harbor: harbor.omniverseai.net/library/
Prometheus 数据保留 7 天
跨命名空间监控（data、monitoring、infra）
NodePort 服务避免端口冲突（30901、30301、30903）

🎉 Happy Operating!

56 KiB Raw Permalink Blame History Unescape Escape

Kubernetes 企业级运维平台部署指南

📋 目录

🎯 项目概述

🌟 核心亮点

📊 集群成熟度评估

🏗️ 架构设计

系统架构图

📦 已部署组件

Namespace: observability 🆕

Namespace: monitoring (旧部署，仅保留 MySQL Exporter)

Namespace: logging

Namespace: tracing

Namespace: data

Namespace: kubernetes-dashboard

Namespace: trivy-system 🆕

Namespace: keda 🆕

企业级增强组件

🚀 自动镜像修复系统 🆕

概述

🎯 双层防护架构

✅ 当前状态

🎯 使用方式

📊 覆盖范围

🔧 管理命令

📚 相关文档

🚀 快速开始

方式1: 全功能验证（推荐）

方式2: 分模块验证

访问核心服务

1. Grafana (监控和可视化)

2. Kubernetes Dashboard (集群管理)

3. Prometheus (指标查询)

🎯 核心功能

1. 完整可观测性

Metrics（指标监控）

Logs（日志聚合）

Traces（链路追踪）

告警系统

2. 资源管理

ResourceQuota（资源配额）

LimitRange（资源限制）

3. 高可用性

Pod Disruption Budget（PDB）

4. 弹性伸缩

KEDA - Kubernetes Event Driven Autoscaling 🆕

5. 可视化运维

Kubernetes Dashboard

Grafana Dashboards

6. 安全扫描 🆕

Trivy Operator（配置审计 + 漏洞扫描）

7. 数据库备份与恢复 🆕 ⭐ 生产级 PVC 方案

生产级自动化备份系统

备份配置

技术架构

备份文件结构

快速部署

查看备份状态

手动触发备份

验证备份完整性

恢复数据库

Grafana 监控（可选）

配置文件位置

与 MinIO 方案对比

完整架构文档

🔌 应用接入指南

接入日志（自动完成 ✅）

推荐日志格式（JSON）

接入链路追踪

OpenTelemetry 端点

Python (FastAPI) 示例

📚 运维指南

日常运维操作

1. 查看集群资源使用

2. 查看 PDB 和 HPA 状态

3. 查看告警

4. 查看日志

故障排查

Pod 因资源配额被拒绝

KEDA ScaledObject 不工作 🆕

56 KiB

Raw Permalink Blame History

Namespace: `observability` 🆕

Namespace: `monitoring` (旧部署，仅保留 MySQL Exporter)

Namespace: `logging`

Namespace: `tracing`

Namespace: `data`

Namespace: `kubernetes-dashboard`

Namespace: `trivy-system` 🆕

Namespace: `keda` 🆕