Prometheus-Operator实战部署指南
【免费下载链接】prometheus-operator 
项目地址: https://gitcode.com/gh_mirrors/pro/prometheus-operator
本文详细介绍了在生产环境中部署和配置Prometheus-Operator的完整流程。内容涵盖环境准备与Kubernetes集群要求、使用bundle.yaml快速部署Operator、RBAC配置与权限管理详解以及多命名空间监控策略配置四个核心部分。通过本指南，您将学习如何满足部署前的环境要求，快速部署Operator组件，配置安全的权限管理体系，以及实现跨命名空间的精细化监控策略。
环境准备与Kubernetes集群要求
在开始部署Prometheus-Operator之前，确保您的环境满足以下基本要求。正确的环境配置是成功部署和运行Prometheus-Operator的关键前提。
Kubernetes集群版本要求
Prometheus-Operator对Kubernetes集群版本有明确的要求。根据项目文档，不同版本的Operator对应不同的Kubernetes最低版本：
具体版本对应关系如下表所示：
| Prometheus-Operator版本 | 最低Kubernetes版本 | 推荐Kubernetes版本 | 主要特性 |
|---|---|---|---|
| v0.75.1 (当前) | v1.16.0+ | v1.24.0+ | 完整CRD支持，Webhook验证 |
| v0.60.0+ | v1.16.0+ | v1.22.0+ | 稳定的v1 API |
| v0.39.0+ | v1.16.0+ | v1.19.0+ | 基础Operator功能 |
集群资源要求
部署Prometheus-Operator需要确保集群有足够的资源。以下是推荐的最小资源配置：
# 最小资源需求示例
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
实际生产环境中的资源需求会根据监控规模而变化：
| 监控规模 | CPU需求 | 内存需求 | 存储需求 |
|---|---|---|---|
| 小型集群(<50节点) | 0.5-1核 | 1-2GB | 10-20GB |
| 中型集群(50-200节点) | 1-2核 | 2-4GB | 20-50GB |
| 大型集群(>200节点) | 2-4核 | 4-8GB | 50-100GB+ |
必要的Kubernetes组件
确保您的Kubernetes集群包含以下核心组件且运行正常：
- API Server: 版本兼容的Kubernetes API服务器
- etcd: 稳定的键值存储
- kube-controller-manager: 控制器管理器
- kube-scheduler: 调度器
- kubelet: 节点代理
- CNI插件: 网络插件（Calico、Flannel、Cilium等）
RBAC权限配置
Prometheus-Operator需要特定的RBAC权限来管理监控资源。以下是必需的ClusterRole权限：
具体的权限需求包括：
- 对nodes、services、endpoints、pods的get、list、watch权限
- 对configmaps的get权限
- 对ingresses的get、list、watch权限
- 对自定义资源（CRDs）的完整操作权限
网络要求
确保集群网络满足以下要求：
- Pod网络互通: 所有Pod能够相互通信
- Service发现: CoreDNS或kube-dns正常运行
- 网络策略: 如果需要，配置适当的网络策略允许监控流量
- 入口访问: 确保能够访问需要监控的服务端点
存储配置
根据您的持久化存储需求，准备相应的StorageClass：
| 存储类型 | 适用场景 | 性能要求 | 可用性要求 |
|---|---|---|---|
| Local PV | 测试环境 | 中等 | 单节点 |
| NFS | 开发环境 | 中等 | 高可用 |
| Ceph RBD | 生产环境 | 高 | 高可用 |
| AWS EBS/GCP PD | 云环境 | 高 | 区域可用 |
工具和客户端要求
部署前确保已安装并配置好以下工具：
- kubectl: 版本与集群API版本兼容
- helm (可选): 版本3.0+
- git: 用于克隆代码库
- curl 或 wget: 用于下载部署文件
验证kubectl配置：
kubectl version --short
kubectl cluster-info
kubectl get nodes
环境验证检查清单
在开始部署前，运行以下命令验证环境准备情况：
# 检查Kubernetes版本
kubectl version --short | grep Server
# 检查节点状态
kubectl get nodes -o wide
# 检查存储类
kubectl get storageclass
# 检查DNS服务
kubectl get svc -n kube-system | grep dns
# 检查RBAC是否启用
kubectl api-versions | grep rbac.authorization.k8s.io
通过以上环境准备和验证，您将为一个稳定可靠的Prometheus-Operator部署奠定坚实基础。确保所有要求都满足后，即可进入实际的部署阶段。
使用bundle.yaml快速部署Operator
Prometheus Operator提供了便捷的部署方式，通过单个bundle.yaml文件即可快速在Kubernetes集群中部署完整的Operator及其所需的CRD资源。这种方式特别适合快速验证和测试环境部署。
bundle.yaml文件结构解析
bundle.yaml是一个合并了多个YAML文件的复合清单文件，主要包含以下核心组件：
1. CustomResourceDefinitions (CRDs)
bundle.yaml包含了Prometheus Operator所需的所有CRD定义，这些CRD扩展了Kubernetes API，使得我们可以使用原生Kubernetes资源的方式来管理监控组件：
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: alertmanagers.monitoring.coreos.com
spec:
group: monitoring.coreos.com
names:
kind: Alertmanager
plural: alertmanagers
shortNames:
- am
scope: Namespaced
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
# ... 详细的schema定义
包含的CRD类型如下表所示：
| CRD名称 | 功能描述 | 简称 |
|---|---|---|
prometheuses.monitoring.coreos.com | Prometheus实例管理 | prom |
alertmanagers.monitoring.coreos.com | Alertmanager实例管理 | am |
servicemonitors.monitoring.coreos.com | Service监控配置 | servicemonitor |
podmonitors.monitoring.coreos.com | Pod监控配置 | podmonitor |
prometheusrules.monitoring.coreos.com | Prometheus规则管理 | promrule |
thanosrulers.monitoring.coreos.com | Thanos Ruler管理 | thanosruler |
probes.monitoring.coreos.com | 探测配置管理 | probe |
alertmanagerconfigs.monitoring.coreos.com | Alertmanager配置 | amcfg |
scrapeconfigs.monitoring.coreos.com | 抓取配置管理 | scrapeconfig |
2. RBAC权限配置
bundle.yaml包含了Operator运行所需的所有RBAC资源：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-operator
rules:
- apiGroups: ["monitoring.coreos.com"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["*"]
# ... 更多权限规则
RBAC配置包含以下组件：
- ServiceAccount: prometheus-operator服务账户
- ClusterRole: 集群级别权限定义
- ClusterRoleBinding: 将权限绑定到服务账户
3. Operator部署配置
Operator的核心部署配置：
apiVersion: apps/v1
kind: Deployment
metadata:
name: prometheus-operator
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: prometheus-operator
template:
metadata:
labels:
app.kubernetes.io/name: prometheus-operator
spec:
serviceAccountName: prometheus-operator
containers:
- name: prometheus-operator
image: quay.io/prometheus-operator/prometheus-operator:v0.75.1
args:
- --kubelet-service=kube-system/kubelet
- --log-level=info
- --prometheus-config-reloader=quay.io/prometheus-operator/prometheus-config-reloader:v0.75.1
部署流程详解
步骤1：应用bundle.yaml
使用kubectl命令一键部署：
kubectl create -f bundle.yaml
部署过程流程图：
步骤2：验证部署状态
检查Operator Pod运行状态：
kubectl get pods -n default -l app.kubernetes.io/name=prometheus-operator
检查CRD创建状态：
kubectl get crd | grep monitoring.coreos.com
预期输出应该显示所有CRD都已创建：
alertmanagers.monitoring.coreos.com 2025-08-26T07:51:01Z
alertmanagerconfigs.monitoring.coreos.com 2025-08-26T07:51:01Z
podmonitors.monitoring.coreos.com 2025-08-26T07:51:01Z
prometheuses.monitoring.coreos.com 2025-08-26T07:51:01Z
prometheusrules.monitoring.coreos.com 2025-08-26T07:51:01Z
servicemonitors.monitoring.coreos.com 2025-08-26T07:51:01Z
thanosrulers.monitoring.coreos.com 2025-08-26T07:51:01Z
probes.monitoring.coreos.com 2025-08-26T07:51:01Z
scrapeconfigs.monitoring.coreos.com 2025-08-26T07:51:01Z
步骤3：创建第一个Prometheus实例
部署完成后，可以创建第一个Prometheus实例：
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: example-prometheus
namespace: default
spec:
replicas: 1
serviceAccountName: prometheus
serviceMonitorSelector: {}
resources:
requests:
memory: "400Mi"
cpu: "200m"
limits:
memory: "800Mi"
cpu: "500m"
部署注意事项
1. 命名空间配置
默认情况下，bundle.yaml将Operator部署在default命名空间。如果需要部署到其他命名空间，需要修改以下内容：
- Deployment中的namespace字段
- ServiceAccount的namespace
- ClusterRoleBinding中的subject namespace
2. 镜像版本管理
bundle.yaml中使用的镜像版本是固定的，建议根据实际需求调整版本：
containers:
- name: prometheus-operator
image: quay.io/prometheus-operator/prometheus-operator:v0.75.1
# 可以替换为特定版本
3. 资源限制调整
根据集群规模调整Operator的资源限制：
resources:
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
高级配置选项
自定义配置参数
Operator支持多个启动参数，可以在Deployment中配置：
args:
- --kubelet-service=kube-system/kubelet
- --log-level=info
- --prometheus-config-reloader=quay.io/prometheus-operator/prometheus-config-reloader:v0.75.1
- --config-reloader-cpu=100m
- --config-reloader-memory=50Mi
多副本高可用部署
对于生产环境，建议部署多个Operator副本：
spec:
replicas: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
故障排查
常见问题及解决方案
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| Operator Pod无法启动 | RBAC权限不足 | 检查ClusterRoleBinding配置 |
| CRD创建失败 | API版本不兼容 | 检查Kubernetes版本要求 |
| 镜像拉取失败 | 网络问题或镜像不存在 | 检查镜像仓库可访问性 |
日志查看
查看Operator日志进行故障诊断：
kubectl logs -n default -l app.kubernetes.io/name=prometheus-operator
性能优化建议
资源分配优化
根据集群规模调整资源分配：
resources:
requests:
memory: "128Mi" # 小型集群
cpu: "100m"
limits:
memory: "256Mi"
cpu: "200m"
监控配置
为Operator本身添加监控：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: prometheus-operator
namespace: default
spec:
selector:
matchLabels:
app.kubernetes.io/name: prometheus-operator
endpoints:
- port: http
interval: 30s
通过bundle.yaml部署Prometheus Operator是一种快速、简便的方式，特别适合测试和开发环境。对于生产环境，建议根据具体需求进行定制化配置，并考虑高可用性和监控等方面的需求。
RBAC配置与权限管理详解
在Kubernetes环境中，RBAC（Role-Based Access Control）是确保Prometheus-Operator安全运行的关键组件。正确的RBAC配置不仅保障了Operator的正常功能，还遵循了最小权限原则，确保集群安全。
RBAC架构概览
Prometheus-Operator的RBAC配置涉及两个主要组件：
- Operator自身权限：管理自定义资源和Kubernetes对象
- Prometheus实例权限：用于服务发现和指标抓取
Operator RBAC详细配置
Operator需要广泛的权限来管理监控堆栈，以下是核心ClusterRole配置：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-operator
rules:
- apiGroups: ["monitoring.coreos.com"]
resources:
- alertmanagers
- prometheuses
- servicemonitors
- podmonitors
- prometheusrules
- thanosrulers
- scrapeconfigs
- probes
- alertmanagerconfigs
verbs: ["*"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["*"]
- apiGroups: [""]
resources: ["configmaps", "secrets"]
verbs: ["*"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["list", "delete"]
- apiGroups: [""]
resources: ["services", "endpoints"]
verbs: ["get", "create", "update", "delete"]
- apiGroups: [""]
resources: ["nodes", "namespaces"]
verbs: ["list", "watch"]
权限需求分析表
| 资源类型 | API组 | 操作权限 | 用途说明 |
|---|---|---|---|
| CustomResources | monitoring.coreos.com | 所有操作 | 管理所有监控CRD资源 |
| StatefulSets | apps | 所有操作 | 部署Prometheus/Alertmanager |
| ConfigMaps/Secrets | "" | 所有操作 | 存储配置和敏感信息 |
| Pods | "" | list, delete | 版本迁移时清理旧Pod |
| Services | "" | 所有操作 | 管理operated服务 |
| Nodes | "" | list, watch | kubelet服务发现 |
Prometheus实例RBAC配置
Prometheus服务器需要只读权限来发现和抓取指标：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus
rules:
- apiGroups: [""]
resources:
- nodes
- nodes/metrics
- services
- endpoints
- pods
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get"]
- apiGroups: ["networking.k8s.io"]
resources: ["ingresses"]
verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]
Prometheus权限矩阵
ServiceAccount配置
每个组件都需要独立的ServiceAccount：
Operator ServiceAccount:
apiVersion: v1
kind: ServiceAccount
metadata:
name: prometheus-operator
namespace: monitoring
automountServiceAccountToken: false
Prometheus ServiceAccount:
apiVersion: v1
kind: ServiceAccount
metadata:
name: prometheus
namespace: monitoring
权限绑定策略
使用ClusterRoleBinding进行权限分配：
Operator权限绑定：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prometheus-operator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: prometheus-operator
subjects:
- kind: ServiceAccount
name: prometheus-operator
namespace: monitoring
Prometheus权限绑定：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prometheus
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: prometheus
subjects:
- kind: ServiceAccount
name: prometheus
namespace: monitoring
多命名空间部署策略
在生产环境中，通常采用多命名空间部署模式：
跨命名空间访问配置
对于需要监控多个命名空间的场景，Prometheus需要额外的权限：
# 扩展Prometheus ClusterRole以支持多命名空间
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get", "list", "watch"]
安全最佳实践
- 最小权限原则：只授予必要的权限
- 定期审计：检查RBAC配置是否符合安全要求
- 使用RoleBinding限制范围：在可能的情况下使用RoleBinding而非ClusterRoleBinding
- 禁用自动挂载：设置
automountServiceAccountToken: false - 网络策略：结合NetworkPolicies限制网络访问
故障排查与验证
验证RBAC配置是否正确：
# 检查Operator权限
kubectl auth can-i create prometheuses --as=system:serviceaccount:monitoring:prometheus-operator
# 检查Prometheus权限
kubectl auth can-i list pods --as=system:serviceaccount:monitoring:prometheus
# 查看ClusterRole绑定
kubectl get clusterrolebindings -l app.kubernetes.io/name=prometheus-operator
高级配置场景
自定义ServiceAccount
在Prometheus CRD中指定自定义ServiceAccount：
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: my-prometheus
spec:
serviceAccountName: custom-prometheus-sa
automountServiceAccountToken: false
细粒度权限控制
对于安全要求极高的环境，可以创建更精细的Role：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: prometheus-scrape-access
namespace: application-ns
rules:
- apiGroups: [""]
resources: ["pods", "services", "endpoints"]
verbs: ["get", "list", "watch"]
然后使用RoleBinding将其绑定到Prometheus ServiceAccount。
正确的RBAC配置是Prometheus-Operator稳定运行的基石，通过遵循这些配置指南和最佳实践，可以确保监控系统既功能完备又安全可靠。
多命名空间监控策略配置
在现代Kubernetes环境中，应用程序通常分布在多个命名空间中运行，这要求监控系统能够灵活地跨命名空间进行监控目标发现。Prometheus-Operator通过强大的命名空间选择器机制，提供了精细化的多命名空间监控策略配置能力。
命名空间选择器基础
Prometheus-Operator提供了两种类型的命名空间选择器配置：
- 全局命名空间选择器：在Prometheus CRD级别配置，控制整个Prometheus实例监控哪些命名空间
- 资源级别命名空间选择器：在ServiceMonitor/PodMonitor级别配置，控制单个监控资源的作用范围
Prometheus级别的命名空间选择器
在Prometheus自定义资源中，可以配置多个命名空间选择器来控制不同监控资源的发现范围：
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
namespace: monitoring
spec:
serviceMonitorNamespaceSelector:
matchLabels:
monitored: "true"
serviceMonitorSelector:
matchLabels:
release: prometheus
podMonitorNamespaceSelector:
matchLabels:
pod-monitored: "true"
ruleNamespaceSelector:
matchLabels:
rule-monitored: "true"
scrapeConfigNamespaceSelector:
matchLabels:
config-monitored: "true"
命名空间选择器类型详解
1. LabelSelector基于标签的选择
最常用的命名空间选择方式是通过标签匹配：
# Prometheus配置示例
serviceMonitorNamespaceSelector:
matchLabels:
environment: production
team: backend
# 对应的命名空间标签配置
apiVersion: v1
kind: Namespace
metadata:
name: backend-services
labels:
environment: production
team: backend
monitored: "true"
2. 基于NamespaceSelector的灵活选择
NamespaceSelector提供了更灵活的命名空间选择机制：
# ServiceMonitor配置示例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: cross-namespace-monitor
namespace: monitoring
spec:
namespaceSelector:
any: true # 监控所有命名空间
# 或者指定具体命名空间
# matchNames: ["app-ns1", "app-ns2", "app-ns3"]
selector:
matchLabels:
app: my-app
endpoints:
- port: web
NamespaceSelector支持两种模式：
any: true- 选择所有命名空间matchNames- 选择指定的命名空间列表
多命名空间监控策略模式
模式1：中心化监控所有命名空间
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: central-prometheus
namespace: monitoring
spec:
serviceMonitorNamespaceSelector: {} # 空选择器匹配所有命名空间
serviceMonitorSelector:
matchLabels:
central-monitoring: "true"
模式2：基于环境的隔离监控
# 生产环境Prometheus
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-prod
namespace: monitoring-prod
spec:
serviceMonitorNamespaceSelector:
matchLabels:
environment: production
# 开发环境Prometheus
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-dev
namespace: monitoring-dev
spec:
serviceMonitorNamespaceSelector:
matchLabels:
environment: development
模式3：基于团队的细粒度控制
# 前端团队监控
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-frontend
namespace: monitoring
spec:
serviceMonitorNamespaceSelector:
matchLabels:
team: frontend
# 后端团队监控
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-backend
namespace: monitoring
spec:
serviceMonitorNamespaceSelector:
matchLabels:
team: backend
高级配置技巧
1. 组合使用命名空间和资源选择器
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: advanced-prometheus
namespace: monitoring
spec:
serviceMonitorNamespaceSelector:
matchLabels:
environment: production
serviceMonitorSelector:
matchLabels:
critical: "true"
podMonitorNamespaceSelector:
matchLabels:
environment: production
matchExpressions:
- key: team
operator: In
values: [backend, data]
2. 忽略命名空间选择器
在某些场景下，可能需要临时忽略命名空间选择器的限制：
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
namespace: monitoring
spec:
ignoreNamespaceSelectors: true
serviceMonitorNamespaceSelector:
matchLabels:
environment: production
3. 规则文件的命名空间选择
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-with-rules
namespace: monitoring
spec:
ruleNamespaceSelector:
matchLabels:
rule-namespace: "true"
ruleSelector:
matchLabels:
severity: critical
RBAC配置考虑
多命名空间监控需要相应的RBAC权限配置：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus
rules:
- apiGroups: [""]
resources:
- nodes
- nodes/metrics
- services
- endpoints
- pods
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources:
- configmaps
verbs: ["get"]
- apiGroups: ["monitoring.coreos.com"]
resources:
- servicemonitors
- podmonitors
- prometheusrules
verbs: ["get", "list", "watch"]
监控策略配置最佳实践
1. 标签命名规范
建立统一的命名空间标签规范：
apiVersion: v1
kind: Namespace
metadata:
name: order-service
labels:
environment: production
team: checkout
domain: ecommerce
monitored: "true"
rule-namespace: "true"
2. 分层监控策略
3. 监控配置验证表
| 配置类型 | 选择器类型 | 作用范围 | 使用场景 |
|---|---|---|---|
| ServiceMonitor | namespaceSelector | 跨命名空间服务发现 | 微服务架构 |
| PodMonitor | namespaceSelector | 跨命名空间Pod发现 | DaemonSet监控 |
| Rule | ruleNamespaceSelector | 规则文件管理 | 集中告警规则 |
| 全局 | serviceMonitorNamespaceSelector | 全局服务发现控制 | 环境隔离 |
4. 故障排除指南
当多命名空间监控出现问题时，可以按照以下步骤排查：
- 检查命名空间标签：确保目标命名空间有正确的标签
- 验证RBAC权限：确认Prometheus ServiceAccount有跨命名空间访问权限
- 检查选择器配置：验证namespaceSelector配置是否正确
- 查看Operator日志：检查是否有权限错误或配置错误
# 检查命名空间标签
kubectl get namespaces --show-labels
# 验证Prometheus权限
kubectl auth can-i list servicemonitors --as=system:serviceaccount:monitoring:prometheus -A
# 检查Prometheus配置
kubectl get prometheus -n monitoring -o yaml
通过合理配置多命名空间监控策略，可以实现精细化的监控资源管理，确保监控系统既能够全面覆盖所有需要监控的工作负载，又能够保持清晰的职责边界和资源隔离。
总结
通过本文的全面介绍，我们系统地掌握了Prometheus-Operator的部署与配置要点。从环境准备到快速部署，从RBAC权限管理到多命名空间监控策略，每个环节都至关重要。正确的环境配置是成功部署的基础，bundle.yaml提供了便捷的部署方式，精细的RBAC配置确保了系统安全，而多命名空间监控策略则实现了监控资源的有效管理。遵循这些最佳实践，可以构建出稳定、安全且高效的可观测性平台，为Kubernetes集群的稳定运行提供有力保障。
【免费下载链接】prometheus-operator 项目地址: https://gitcode.com/gh_mirrors/pro/prometheus-operator
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
