you are better than you think

备忘

last update:

kubernetes组件指标梳理

本文梳理指标对应的的kubernetes版本为1.23.1, etcd版本为3.5.1

kube-apiserver 指标

kuber-apiserver暴露了148个指标,梳理后比较重要的指标如下。

# HELP apiserver_request_duration_seconds [STABLE] Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component.
# TYPE apiserver_request_duration_seconds histogram
apiserver响应的时间分布,按照url 和 verb 分类
一般按照instance和verb+时间 汇聚

# HELP apiserver_request_total [STABLE] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code.
# TYPE apiserver_request_total counter
apiserver的请求总数,按照verb、 version、 group、resource、scope、component、 http返回码分类统计

# HELP apiserver_current_inflight_requests [STABLE] Maximal number of currently used inflight request limit of this apiserver per request kind in last second.
# TYPE apiserver_current_inflight_requests gauge
当前最大请求数(利用channel大小限流), 按mutating(非get list watch的请求) 和 readOnly (get list watch)分别限制
超过max-requests-inflight(默认值400)  和 max-mutating-requests-inflight(默认200) 的请求会被限流
apiserver变更时要注意观察,也是反馈集群容量的一个重要指标

# HELP apiserver_response_sizes [STABLE] Response size distribution in bytes for each group, version, verb, resource, subresource, scope and component.
# TYPE apiserver_response_sizes histogram
apiserver 响应大小,单位byte, 按照verb、 version、 group、resource、scope、component分类统计

# HELP watch_cache_capacity [ALPHA] Total capacity of watch cache broken by resource type.
# TYPE watch_cache_capacity gauge
按照资源类型统计的watch缓存大小

# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
每秒钟用户态和系统态cpu消耗时间, 计算apiserver进程的cpu的使用率

# HELP process_resident_memory_bytes Resident memory size in bytes.
# TYPE process_resident_memory_bytes gauge
apiserver的内存使用量(单位:Byte)

# HELP workqueue_adds_total [ALPHA] Total number of adds handled by workqueue
# TYPE workqueue_adds_total counter
apiserver中包含的controller的工作队列,已处理的任务总数

# HELP workqueue_depth [ALPHA] Current depth of workqueue
# TYPE workqueue_depth gauge
apiserver中包含的controller的工作队列深度,表示当前队列中要处理的任务的数量,数值越小越好 
例如APIServiceRegistrationController admission_quota_controller

kubernetes环境鉴权与自动发现

概览文章中提到了k8s的鉴权模式,简单回顾下:

  • RBAC: Role-based access control 是基于角色的访问控制
  • ABAC: Atrribute-based access control 是基于属性的访问控制
  • Node Authorization: 节点鉴权,专门用户kubelet发出的api请求进行鉴权
  • Webhook Authorization: webhook是一种http回调,kube-apiserver配置webhook时, 会设置回调webhook的规则,这些规则中包含了调用的api group、version、operation、scope等信息。

有细心的小伙伴指出,RBAC的角色可以作为ABAC的属性来配置。 感谢小伙伴指正,ABAC可以更细粒度的控制权限,相应配置起来也更复杂。

kubernetes 鉴权

选定RBAC模式后,关于角色,有Role和ClusterRole,对应对象的绑定分别为: RoleBinding 和 ClusterRoleBinding。 Role创建后归属于特定的namespace,一般与特定namespace的权限绑定,而ClusterRole 不属于任何namespace,通常与一组权限绑定。

ClusterRole通常用于 + 定义指定namespace资源的访问权限,并在某个namespace范围内授予访问权限; + 定义指定namespace资源的访问权限,并在跨namespace范围内授予访问权限; + 定义集群范围内的资源访问权限。

官方文档推荐,如果在单个namespace内定义角色则使用Role,如果是定义集群范围的角色,则使用ClusterRole。 要监控kubernetes组件和集群范围内业务以及为了通用性,所以我们选择ClusterRole 和 ClusterRoleBinding。

kubernetes监控

kubernetes监控

云原生包含了开源软件、云计算和应用架构的元素。云计算解决开源软件的运行门槛问题,同时降低了运维成本和基础架构成本; 云原生给出了更多的应用架构规范, 更聚焦于能力和生态。随着kubernetes在基础设施的大规模落地,监控的需求也发生了变化,建设一套更符合云原生规范的监控体系势在必行。

一 监控需求变化

  • 指标周期变短: 相比物理机时代, 基础设施动态化,Pod销毁重建非常频繁,监控指标跟随Pod的生命周期。
  • 指标数量增加: 随着微服务化流行,指标的数量也大幅增长,研发工程师也更愿意埋点,获取服务状态;各种采集器层出不穷,指标应采尽采
  • 指标维度更加丰富:物理机时代监控多从资源视角出发,更关注机器、交换机、中间件的采集;新的监控维度更加丰富,维度标签动辄几十上百个,甚至组合会有高基数问题
  • 基础设施复杂度变高,监控难度增加:kubernetes组件和应用架构模型都需要投入时间去了解学习。kubernetes本身组件都通过/metrics接口暴露了监控数据,但是缺少体系化的文档指导和最佳实践总结
  • 自动发现更重要:相比物理机时代的静态采集,自动发现采集目标的能力变得更重要