【云原生 | Kubernetes 系列】---- Operator安装prometheus报错

已于 2022-08-29 13:35:40 修改
阅读量3.2k 收藏 5
点赞数 8
分类专栏： Docker K8s prometheus 文章标签： 云原生 kubernetes prometheus
于 2022-08-29 11:02:28 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-NC-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_29974229/article/details/126580339
版权

The CustomResourceDefinition “prometheuses.monitoring.coreos.com” is invalid: metadata.annotations: Too long: must have at most 262144 bytes

现象:

# kubectl apply -f setup/
customresourcedefinition.apiextensions.k8s.io/alertmanagerconfigs.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/alertmanagers.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/podmonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/probes.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/prometheusrules.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/servicemonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/thanosrulers.monitoring.coreos.com created
namespace/monitoring created
The CustomResourceDefinition "prometheuses.monitoring.coreos.com" is invalid: metadata.annotations: Too long: must have at most 262144 bytes

2. 解决方法:

2.1 删除已经创建的资源

# kubectl delete -f setup/
customresourcedefinition.apiextensions.k8s.io "alertmanagerconfigs.monitoring.coreos.com" deleted
customresourcedefinition.apiextensions.k8s.io "alertmanagers.monitoring.coreos.com" deleted
customresourcedefinition.apiextensions.k8s.io "podmonitors.monitoring.coreos.com" deleted
customresourcedefinition.apiextensions.k8s.io "probes.monitoring.coreos.com" deleted
customresourcedefinition.apiextensions.k8s.io "prometheusrules.monitoring.coreos.com" deleted
customresourcedefinition.apiextensions.k8s.io "servicemonitors.monitoring.coreos.com" deleted
customresourcedefinition.apiextensions.k8s.io "thanosrulers.monitoring.coreos.com" deleted
namespace "monitoring" deleted
Error from server (NotFound): error when deleting "0prometheusCustomResourceDefinition.yaml": customresourcedefinitions.apiextensions.k8s.io "prometheuses.monitoring.coreos.com" not found

2.2 重新创建

把apply换成create就可以了

# kubectl create -f setup/
customresourcedefinition.apiextensions.k8s.io/alertmanagerconfigs.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/alertmanagers.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/podmonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/probes.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/prometheuses.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/prometheusrules.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/servicemonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/thanosrulers.monitoring.coreos.com created
namespace/monitoring created

这样就没有报错了.

云原生 | 在 Kubernetes 中使用 Cilium 替代 Calico 网络插件实践指南!
WeiyiGeek 唯一极客IT知识分享
09-03 2338
Cilium 是一款开源软件，它基于一种名为eBPF的新的Linux内核技术提供动力，用于透明地保护使用 Docker 和 Kubernetes 等Linux 容器管理平台中部署的应用程序服务之间的网络连接，Cilium 主要使用场景是在 Kubernetes 中，但 Cilium 的优势并不仅限于 Kubernetes 环境。在 Kubernetes 环境中，Cilium 可充当网络插件，提供 pod 之间的连接。
云原生之容器编排实践-OpenEuler23.09在线安装Kubernetes与KubeSphere
Heartsuit的博客
06-30 1699
前几篇文章中介绍了如何将ruoyi-cloud项目部署到Kubernetes集群中，包括网关服务、认证服务和系统服务并且对全部服务采用YAML文件的方式来进行部署，这虽然有助于理解K8S组织管理资源的风格与底层机制，但是对于团队中不太熟悉命令行操作的成员不太友好，现在我们借助由青云开源的容器平台KubeSphere来进行可视化的服务部署。KubeSphere是在Kubernetes之上构建的面向云原生应用的分布式操作系统，完全开源，支持多云与多集群管理，提供全栈的IT自动化运维能力；KubeKey一键安装。
Kubectl Install CRD Failed — Annotations Too Long
weixin_45670278的博客
11-01 1074
Kubectl Install CRD Failed — Annotations Too Long
k8s：Too long: must have at most 262144 bytes超过限制，使用--server-side解决
学亮编程手记
11-13 3321
该报错提示您的 CustomResourceDefinition (CRD) “installations.operator.tigera.io” 的 metadata.annotations 字段超过了最大限制。Kubernetes 对 CRD 的注释字段有大小限制，最大为 262,144 字节（约 256 KB）。
【Kubernetes k8s】（两万字超详细）Ubuntu-22.04搭建 k8s-1.30.1集群，开启Dashboard-2.7.0、部署ingress-nginx-1.10.1
m0_54854484的博客
02-06 1237
kubeadm是自动引导整个集群的工具，本质上k8s就是一些容器服务相互配合完成管理集群的任务，如果你知道具体安装哪些容器那么可以不用这个。kubalet是各个节点的总管，它上面都管，管理Pod、资源、日志、节点健康状态等等，它不是一个容器，是一个本地软件，所以必须得安装kubectl是命令行工具，给我们敲命令与k8s交互用的，必须得安装大白话就是：在此之前我们都是直接访问service，让service负载均衡到Pod上，优点是直接，缺点是随着service的增多端口会越来越多，不好记。于是我们在。
kubernetes（k8s） 安装 Prometheus + Grafana
小云的博客
04-24 1566
kubernetes（k8s） 安装 Prometheus + Grafana 组件说明 MetricServer：是kubernetes集群资源使用情况的聚合器，收集数据给kubernetes集群内使用，如 kubectl,hpa,scheduler等。PrometheusOperator：是一个系统监测和警报工具箱，用来存储监控数据。NodeExporter：用于各n...
prometheus 自定义发现seldon-core服务
当时明月在 曾照彩云归
11-09 992
prometheus 提供podMinitor与serviceMonitor用于用户自定义规则，发现需要监控的服务 以下以prometheus安装在monitoring，自定义发现seldon-core服务为例 通过kubectl get serviceMonitor -n monitoring 可以查询到现有的prometheus的服务监控 也可以从prometheus的页面上看到prometheus的service discovery serviceMonitor 自定义发现规则 ap.
K8S环境部署Prometheus
lldhsds的专栏
06-13 1720
记录在K8S 1.18版本环境下部署Prometheus 0.5版本。
《Kubernetes监控篇：基于kube-prometheus-stack部署监控告警系统（方案一）》
东城绝神
10-31 872
《Kubernetes监控篇：基于kube-prometheus-stack部署监控告警系统（方案一）》
K8s（十二）：监控与报警（163邮箱+钉钉）-Prometheus + Grafana + Alertmanager（超详细）
热门推荐
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！✨
04-08 1万+
🔴 K8s（十二）：监控与报警（163邮箱+钉钉）-Prometheus + Grafana + Alertmanager（超详细）
8-1 基于Operator和二进制安装Prometheus系统
分享云原生，容器，运维等干货知识
10-11 571
Prometheus是一个开源系统监控和警报工具包，最初由SoundCloud构建。自2012年推出以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。现在它是一个独立的开源项目，独立于任何公司进行维护。为了强调这一点，也为了明确项目的治理结构，Prometheus在2016年加入了云原生计算基金会，成为继Kubernetes之后的第二个托管项目。
网络插件 Cilium 更换 Calico
qq_49288154的博客
09-13 1416
网络插件更换
Prometheus中PodMonitor配置示例
m0_59539752的博客
02-24 1018
访问 Prometheus Web UI -> Status -> Targets，确认对应 Job 状态为。根据实际需求选择监控方式。
K8s部署prometheus监控K8s细节
zeorg的博客
01-04 1071
此文章做文字描述不做实际操作 prometheus 最好搭建在k8s集群里面（也就是docker里） prometheus 一些配置文件可以再github上找到 https://github.com/coreos/kube-prometheus 部署/root/kube-prometheus/manifests 目录下所有文件 kubectl apply -f /root/kube-prometheus/manifests/ 部署/root/kube-prometheus/manifests/setup
prometheus-k8s中安装部署
因上努力，果上随缘。但行好事，莫问前程。
04-27 858
四、k8s中安装 Prometheus安装方式较多，比如： GitEe:https://gitee.com/liugpwwwroot/k8s-prometheus-grafana/tree/master/prometheus; GItHub:https://github.com/prometheus-operator/kube-prometheus Helm:https://artifacthub.io/packages/helm/grafana/grafana 4.1、prometheu...
kubernetes进阶操作
qq_52804302的博客
12-13 4350
文章目录第三天 Kubernetes进阶实践ETCD常用操作小结Kubernetes调度为何要控制Pod应该如何调度调度的过程NodeSelectornodeAffinitypod亲和性和反亲和性污点（Taints）与容忍（tolerations）Cordon小结Kubernetes集群的网络实现CNI介绍及集群网络选型Flannel网络模型实现剖析vxlan介绍及点对点通信的实现跨主机容器网络的通信brct命令ip命令Flannel的vxlan实现精讲利用host-gw模式提升集群网络性能Kubernet
Kubernetes 之 ConfigMap
zhixingheyi_tian的博客
05-24 855
语法规范 create # kubectl create -f spark-configMap.yaml The ConfigMap "spark-configMap" is invalid: metadata.name: Invalid value: "spark-configMap": a DNS-1123 subdomain must consist of lower case alpha...
kubernetes集群全栈监控报警方案kube-prometheus
weixin_34306446的博客
06-04 925
参考文档 http://www.servicemesher.com/blog/prometheus-operator-manual/ https://github.com/coreos/prometheus-operator https://github.com/coreos/kube-prometheus 背景环境 kubernetes集群1.13版本，纯二进制版本打造，参考k8s1.13集...
为什么很多参数在alertmanager的主配置文件和通过crd alertmanagerconfig里的参数名字不一样，比如group_by和groupBy
最新发布
03-16
<think>好的，我现在需要回答用户的问题：为什么Alertmanager的主配置文件和通过CRD AlertmanagerConfig中的参数名称不一样，比如group_by和groupBy。 首先，我得回顾一下用户之前的对话历史。之前用户遇到了在AlertmanagerConfig中使用email_configs报错的问题，我解释了是因为API版本的问题，旧版本不支持email配置，建议升级并使用新API版本。现在用户的问题是关于参数命名差异，这涉及到Kubernetes CRD的设计和YAML配置的结构差异。 接下来，我需要分析原因。用户提到的例子是group_by（主配置文件）和groupBy（CRD）。这可能是因为不同的配置格式遵循不同的命名约定。主配置文件是YAML格式，通常使用下划线分隔，而Kubernetes资源对象使用驼峰式命名，这是Kubernetes API的常见实践。例如，Kubernetes中的字段通常使用camelCase，而应用程序自身的配置文件可能使用snake_case。 然后，我需要确认这一点。查阅Alertmanager的主配置文档，确认group_by确实是使用下划线的字段。而AlertmanagerConfig作为Kubernetes CRD，其结构需要遵循Kubernetes API的规范，所以会使用驼峰式命名，比如groupBy。 接下来，我应该考虑其他可能的例子，比如receiver和receivers，或者repeat_interval和repeatInterval，来进一步说明这种命名差异。这有助于用户理解这不是单一现象，而是普遍存在的命名规范问题。 还需要解释这种设计的原因，主要是为了符合不同环境的命名约定。主配置文件可能更贴近应用程序自身的配置风格（比如Prometheus、Alertmanager通常使用下划线），而Kubernetes API资源遵循Go语言的驼峰式命名规范，确保与Kubernetes生态的一致性，同时利用Kubernetes的校验机制。 此外，用户可能关心如何正确地在不同的配置文件中使用这些参数，避免混淆。需要提供转换的方法或示例，比如如何将主配置文件中的group_by对应到CRD中的groupBy，并提醒用户查阅官方文档的CRD规范。 最后，总结关键点，帮助用户形成清晰的理解：命名差异源于不同配置格式的命名规范，Kubernetes CRD采用驼峰式，主配置文件用下划线，使用时需注意对应关系，参考官方文档。</think>在Alertmanager主配置文件与`AlertmanagerConfig` CRD中出现参数命名差异的主要原因在于**配置格式规范的不同实现方式**，这是Kubernetes生态中常见的API设计模式。以下从技术层面详细解释： --- ### 一、底层设计差异 1. **原生配置的命名风格** Alertmanager原生配置文件遵循**Snake Case（下划线分隔）**，这是Prometheus生态系统的传统风格，例如： ```yaml route: group_by: ['job', 'cluster'] # 原生配置风格 group_wait: 30s ``` 2. **Kubernetes CRD的命名规范** Kubernetes API资源强制要求使用**Camel Case（驼峰式）**，这是为了保持与Kubernetes核心API的一致性，例如： ```yaml spec: route: groupBy: ['job', 'cluster'] # CRD规范风格 groupWait: 30s ``` --- ### 二、根本原因解析 | 对比维度 | Alertmanager原生配置 | AlertmanagerConfig CRD | |------------------|-----------------------------|----------------------------------| | **语法标准** | YAML with Snake Case | Kubernetes API Camel Case | | **校验机制** | Alertmanager自有校验逻辑 | Kubernetes Schema Validation | | **序列化方式** | 直接映射Go结构体标签 | 通过OpenAPI v3规范定义 | | **字段兼容性** | 跟随Alertmanager版本演进 | 依赖Prometheus Operator版本 | --- ### 三、映射关系对照表（常见字段） | 原生配置字段 | CRD对应字段 | 类型 | |----------------------|---------------------|------------| | `group_by` | `groupBy` | 字符串数组 | | `group_wait` | `groupWait` | 持续时间 | | `group_interval` | `groupInterval` | 持续时间 | | `repeat_interval` | `repeatInterval` | 持续时间 | | `receiver` | `receiver` | 字符串 | | `matchers` | `matchers` | 对象数组 | | `mute_time_intervals`| `muteTimeIntervals` | 字符串数组 | --- ### 四、技术实现原理 1. **Kubernetes API序列化规则** 通过[Kubernetes字段标签](https://kubernetes.io/docs/reference/using-api/api-concepts/#field-validation)自动转换命名格式，底层依赖Go语言的`json`标签实现： ```go type Route struct { GroupBy []string `json:"groupBy"` // CRD字段名 GroupWait string `json:"groupWait"` // 对应原生配置的group_by, group_wait } ``` 2. **Operator的转换逻辑** Prometheus Operator会通过[控制循环](https://prometheus-operator.dev/docs/operator/design/#controller-workflow)将CRD配置**自动转换**为原生格式，关键转换代码如下： ```go func translateRoute(crdRoute *v1alpha1.Route) *alertmanager.Route { return &alertmanager.Route{ GroupBy: crdRoute.GroupBy, // 自动转换groupBy→group_by GroupWait: crdRoute.GroupWait, // ... } } ``` --- ### 五、实践建议 1. **配置时优先参考CRD文档** 使用`kubectl explain`命令实时验证字段： ```bash kubectl explain alertmanagerconfig.spec.route.groupBy ``` 2. **注意数据类型差异** 某些字段在CRD中需要特定格式： ```yaml # 正确写法（带单位的时间） groupWait: "30s" # 错误写法（纯数字） groupWait: 30 ``` 3. **版本兼容性检查** 不同Operator版本支持的字段范围不同： ```bash # 查看CRD定义版本 kubectl get crd alertmanagerconfigs.monitoring.coreos.com -o jsonpath='{.spec.versions[*].name}' ``` --- ### 六、典型错误示例分析 **错误配置**： ```yaml # 错误：混合使用两种命名风格 spec: route: group_by: ['job'] # 应该使用groupBy repeat_interval: "12h" # 应该使用repeatInterval ``` **修正方案**： ```yaml spec: route: groupBy: ['job'] repeatInterval: "12h" ``` --- 通过理解这种设计差异，可以更高效地编写和维护Alertmanager配置，避免因格式问题导致的调试成本。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值