![个人头像照片](https://ucc.alicdn.com/avatar/82e4512407ee43d1870ef9df638b0f36.jpeg)
从事于公有云的k8s云原生相关技术领域
本文以troubleshooting的思维为切入点,深入梳理prometheus-operator架构原理,技术上跟阿里云arms_prometheus是相通的,便于在问题场景中快速定位。
阿里云ACK专有集群的master组件基本都是https监听,那么prometheus server是如何鉴权获取到htts监听的metrics指标呢?Tls认证环节无关operator, 主要是prometheus server的认证处理 ,属于prometheus 监控体系通用的理论。先从prometheus最常见场景- pod (apiserver/scheduler/kcm)的tls认证场景开始介绍,然后单独介绍etcd和kubelet的tls认证 。本文通过curl模拟prometheus server获取https metrics 指标,便于对认证机制的理解。
使用ack-prometheus-operator 在阿里云ACK专有版集群里,默认未采集 etcd / scheduler/ kcm/ccm/kube-proxy等管理组件的监控数据,需要手动配置证书、采集等配置。本文目的在于解决由于不正确的配置带来的监控异常,也顺便扫盲“更新Prometheus Server的配置prometheus.yml"这几个词在operator体系中的具体配置步骤。
对k8s集群中的pod进行压测,压测方式是直接访问k8s前的SLB, 压测表现是 SLB (CLB 7层监听)偶发返回499报错。 最终确认问题根因是五元组复用导致串流。 关键词: 偶发499 、压测、k8s
Metrics-server基于cAdvisor收集指标数据,获取、格式化后以metrics API的形式从apiserver对外暴露,核心作用是为kubectl top以及HPA等组件提供决策指标支持。