背景 Prometheus 是目前云原生架构中监控解决方案中的基石，而对于 “metrics”，“traces” 和 “logs” 是组成云原生架构中“可观测性”的一个基础，当在扩展 Prometheus，那么 Prometheus 提供的基础架构是无法满足需求的（高可用性和可扩展性）， 而高可用性与可扩展性是满足不断增长基础设施的一个基本条件。而 Prometheus 本身并没有提供“弹性”的集群配置，也就是说，多个副本的 Prometheus 实例，对于分布在每个 Pod 上的数据也会不一致，这时也需要保证指标的归档问题。 并且在一定的集群规模下，问题的出现远远大于 Prometheus 本身的能力，例如： 如何经济且搞笑的存储历史数据（TB, PB）？如何快速的查询历史数据？ 如何合并 Promehtues 多个实例收集来的副本数据？ 以及多集群间的监控？ 由于 TSDB 的块同步，Prometheus 严重依赖内存，使得 Prometheus 监控项的扩展将导致集群中的CPU/MEM 的使用加大 .. 解决 Thanos 是一款可以使 Prometheus 获得 ”长期存储“，并具体有”高可用性“ 的 Prometheus 的功能扩展，“Thanos” 源自希腊语“ Athanasios”，英文意思是”不朽“。这也正是 ”Thanos“ 提供的功能：”无限制的对象存储“，并与原生 Prometheus API 高度兼容，你可以理解为 Thanos API 就是 Prometheus API。 Cortexmetrics 与 Thanos 类似，是用通过将 Prometheus 实例的”存储“和”查询“等功能分离到独立的组件中，实现水平扩展。它使用对象存储来持久化历史指标，块存储（TSDB）是他的存储后端；此外，Cortex 还提供了多租户与多租户隔离等功能 联邦集群，联邦集群是 Prometheus 官方提供的一个概念，使用了联邦将允许 Prometheus 从另一个 Prometheus 中抓取选定的指标。可以使用的一些模型如下： 分层联邦：大规模的集群中，Prometheus 部署模型如一个”树形“，高级别的从多个低级实例中抓取指标，并存储聚合 跨服务联邦：Prometheus 从另一个 Prometheus 只抓取指定的数据 图：Prometheus 联邦 Source：https://www....

开始前的实验环境 Resources controller worker-1 worker-2 OS CentOS 7.9 CentOS 7.9 CentOS 7.9 Storage 20GB 20GB 20GB vCPU 2 2 2 RAM 4GB 4GB 4GB NIC 10.0.0.4 10.0.0.4 10.0.0.4 Kubernetes Version 1.19.10 1.19.10 1.19.10 选择匹配 Kubernetes 版本的 Calico 版本 通常情况下，查看 Calico 所支持的 Kubernetes 版本，可以通过路径 Install Calico ==> Kubernetes ==> System requirements 可以找到自己的 Kubernetes 集群所支持的 Calico 版本。 例如在实验环境中，Kubernetes 1.19 版本所支持的版本有 Calico 3.20，这个时候直接 apply 这个版本提供的资源清单即可 如何开启纯 BGP 模式 默认情况下下，Calico 使用的是 full mesh 和 IPIP， 如果想通过在部署时就修改关闭 IPIP 模式，可以通过修改资源清单中的环境变量来关闭 CALICO_IPV4POOL_IPIP: Never。...

原作者 Javier Martínez 背景 在学习 Kubernetes 调度时，有两个重要的概念，“request “与 “limit”，而对应的资源就是“内存” 与 “CPU” ，而这两个决定了 Pod 将如何调度；“request “与 “limit” 也是整个调度系统中的基数因子。 什么是 request 和 limit 在 Kubernetes 中，Limit 是容器可以使用的最大资源量，这表示 “容器” 的内存或 CPU 的使用，永远不会超过 Limit 配置的值。 而另一方面，Request 则是为 “容器” 保留的最低资源保障；换句话来说，Request 则是在调度时，容器被允许所需的配置。 图：Kubernetes 中Limit 和 Request 图示 Source：https://sysdig.com/blog/kubernetes-limits-requests/ 如何配置 request 和 limit 下列清单是 Deployment 的部署清单，他将部署一个 redis 与 一个 busybox yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 kind: Deployment apiVersion: extensions/v1beta1 … template: spec: containers: - name: redis image: redis:5....

背景 对于整个 Kubernetes 集群来说，随着业务不断地打磨，新增指标，那么对于 Prometheus 特性来说，那么内存 与 存储的使用势必是增加。这是对于存储压力是很重的，通常情况下，使用 Prometheus，都会是用于 Kubernetes 集群中，而 应用于 Kubernetes 集中的存储势必是 PVC 之类的网络存储。 这种场景中，我将尝试拆解如何分析和配置 Prometheus 以显著的减少其资源使用并解决高基数问题 高基数 基数 (cardinality) 通俗来说是一个集合中的元素数量 [1] 基数的来源通常为： label 的数量 series(指标) 的数量 时间：label 或者 series 随时间而流失或增加，通常是增加 那么这么看来高基数就是，label, series, 时间这三个集合的笛卡尔积，那么高基数的情况就很正常了。 而高基数带来的则是 Prometheus 资源使用，以及监控的性能。下图是 Grafana Lab 提到的一张图，很好的阐述了高基数这个问题 图：Prometheus中的基数 Source：https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter 如图所示：一个指标 server_responses 他的 label 存在两个 status_code 与 environment ，这代表了一个集合，那他的 label value 是 1~5xx，这个指标的笛卡尔积就是10。 那么此时存在一个问题，如何能定位 基数高不高，Grafana Lab 给出了下面的数据 [1]，但是我不清楚具体的来源或者如何得到的这些值。也就是 label:value 低基数：1: 5 标准基数：1: 80 高基数：1: 10000 为什么指标会指数级增长 在以 Kubernetes 为基础的架构中，随着抽象级别的提高（通常为Pod, Label, 以及更多抽象的拓扑），指标的时间序列也越来越多。因为在这种基础架构中，在传统架构中运行的一个应用的单个裸机，被许多运行分散在许多不同节点上的许多不同微服务的 Pod 所取代。在这些抽象层中的每一个都需要一个标签，以便可以唯一地标识它们，并且这些组件中的每一个都会生成自己的指标，从而创建其独特的时间序列集。...

场景 在配置代理后，GET 请求的变量全部失效，配置如下 conf location /fw { proxy_pass http://127.0.0.1:2952; } 我的需求是，/fw/ 的都发往 2952端口，但实际情况是404，原因为“在没有指定 URI 的情况下，在1.12版本后会传递原有的URI” 这时会导致一个404错误，因为我的后端接口本身就是 /fw/xxx/ 会出现重复 接下来做了一个变量传递 conf location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section; } 这时存在一个问题，就是 GET 请求的变量无法传递过去 解决 nginx 官方给出一个样例，说明了，存在某种情况下，nginx 不会确定请求 URI 中的部分参数 使用正则表达式时 在 localtion 名称内 例如，在这个场景下，proxy_pass 就会忽略原有的请求的URI，而将拼接后的请求转发 conf location /name/ { rewrite /name/([^/]+) /users?name=$1 break; proxy_pass http://127.0.0.1; } 那么这服务我遇到的问题，nginx官方给出了使用方式 当在 proxy_pass 中需要变量，可以使用 $request_uri; 另外也可以使用 $is_args$args 参数 来保证原有的请求参数被传递 conf location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section$is_args$args; } $is_args...