Kubernetes容器监控原理与源码分析(一)——API与数据来源

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: ## 前言本系列主要基于v1.24.0版本的Kubelet部分源代码,进行Kubernetes中容器监控的底层原理介绍与代码分析。## Kubelet中的监控API在Kubelet Server提供的监控API中,大致可以分为两类:stats(统计数据)和metrics(指标数据)。从命名和实际作用来看,前者提供了粗粒度的基础监控能力,目前用于各种内置组件;而后者用于持久化地进行细粒度的容器

前言

本系列主要基于v1.24.0版本的Kubelet部分源代码,进行Kubernetes中容器监控的底层原理介绍与代码分析。

Kubelet中的监控API

在Kubelet Server提供的监控API中,大致可以分为两类:stats(统计数据)和metrics(指标数据)。从命名和实际作用来看,前者提供了粗粒度的基础监控能力,目前用于各种内置组件;而后者用于持久化地进行细粒度的容器监控,主要提供给Prometheus等。

统计类API

在v1.24.0版本中,目前统计类接口仅包含/stats/summary,该接口提供了节点和Pod的统计信息。节点部分包括CPU、内存、网络、文件系统、容器运行时、Rlimit的统计。Pod部分主要提供Pod相关的基础统计与卷、临时存储、进程统计外,主要还包括了各个容器的统计信息。容器部分值得关注的是,该接口中提供了用户自定义指标。方法实现如下:

func (h *handler) handleSummary(request *restful.Request, response *restful.Response) {
    onlyCPUAndMemory := false
    
    ...
    
    if onlyCluAndMemoryParam, found := request.Request.Form["only_cpu_and_memory"]; found &&
        len(onlyCluAndMemoryParam) == 1 && onlyCluAndMemoryParam[0] == "true" {
        onlyCPUAndMemory = true
    }
    var summary *statsapi.Summary
    if onlyCPUAndMemory {
        summary, err = h.summaryProvider.GetCPUAndMemoryStats()
    } else {
        forceStatsUpdate := false
        summary, err = h.summaryProvider.Get(forceStatsUpdate)
    }
    
    ...
}

查看SummaryProvider的实现可以发现,该实际上就是对stats.Provider的封装。

type SummaryProvider interface {
    Get(updateStats bool) (*statsapi.Summary, error)
    GetCPUAndMemoryStats() (*statsapi.Summary, error)
}

type summaryProviderImpl struct {
    kubeletCreationTime metav1.Time
    systemBootTime metav1.Time

    provider Provider
}

在handler的处理逻辑中,它提供了一个只返回CPU和Memory信息的选项onlyCPUAndMemory,如果只关心cpu和内存信息,通过此选项可以去除多余的统计信息,metrics-server(_< 0.6.0版本_)中就默认设置了该值。该部分需要注意的是,如果获取的是完整信息,那么监控信息是从缓存中获取的,这里特指CPU中的NanoCoreUsage不会更新,只有调用onlyCPUAndMemory才会将该值更新。如果基于接口做定制开发需要将forceStatsUpdate修改为true以保证NanoCoreUsage的准确性。
此外,在最新版本的0.6.x版本的metrics-server中已经不再依赖该接口,而是采用了Kubelet中的/metrics/resource接口进行资源的监控,在老版本集群中部署metrics-server时需要注意不兼容问题。

指标类API

Kubelet Server提供的指标类API目前包括以下四个:

  • /metrics:提供kubelet自身相关的一些监控,包括:apiserver请求、go gc/内存/线程相关、kubelet子模块关键信息、client-go等指标
  • /metrics/cadvisor:提供Pod/容器监控信息
  • /metrics/probes:提供对容器Liveness/Readiness/Startup探针的指标数据
  • /metrics/resource:提供Pod/容器的CPU用量、wss内存、启动时间基础指标数据

上述四个接口返回的指标信息默认都是Promtheus格式。一般来说,指标想要转化为Promtheus格式需要实现Prometheus client的Registerer和Gatherer接口,而在K8s中对应的封装实现就是KubeRegistry。这里我们先跳过Prometheus client的实现原理和其他非容器指标相关的实现,而是来看看容器指标数据是如何获取到并转化返回的。

r := compbasemetrics.NewKubeRegistry()

includedMetrics := cadvisormetrics.MetricSet{
    // 指标白名单设置
    ...
}

cadvisorOpts := cadvisorv2.RequestOptions{
    IdType:    cadvisorv2.TypeName,
    // 每次仅返回一条数据
    Count:     1,
    Recursive: true,
}

r.RawMustRegister(metrics.NewPrometheusCollector(prometheusHostAdapter{s.host}, containerPrometheusLabelsFunc(s.host), includedMetrics, clock.RealClock{}, cadvisorOpts))
r.RawMustRegister(metrics.NewPrometheusMachineCollector(prometheusHostAdapter{s.host}, includedMetrics))

s.restfulCont.Handle(cadvisorMetricsPath,
                     compbasemetrics.HandlerFor(r, compbasemetrics.HandlerOpts{ErrorHandling: compbasemetrics.ContinueOnError}),
                    )

在Prometheus Client的注册逻辑里,返回数据需要实现指标收集器(Collector)部分。这里可以看到,Kubelet提供了两种数据收集器,一部分是Pod/容器的指标收集器,另一部分是节点指标收集器。

func NewPrometheusMachineCollector(i infoProvider, includedMetrics container.MetricSet) *PrometheusMachineCollector {
    c := &PrometheusMachineCollector{

        infoProvider: i,
        errors: prometheus.NewGauge(prometheus.GaugeOpts{
            Namespace: "machine",
            Name:      "scrape_error",
            Help:      "1 if there was an error while getting machine metrics, 0 otherwise.",
        }),
        machineMetrics: []machineMetric{
            {
                name:      "machine_cpu_physical_cores",
                help:      "Number of physical CPU cores.",
                valueType: prometheus.GaugeValue,
                getValues: func(machineInfo *info.MachineInfo) metricValues {
                    return metricValues{{value: float64(machineInfo.NumPhysicalCores), timestamp: machineInfo.Timestamp}}
                },
            },
            
            // 其他指标的类似实现
            ...
        }...)
    }
    return c
}

可以看到收集器实际上主要是通过getValues方法把infoProvider提供的数据结构从原始结构转成Prometheus中的指标,同时每个指标需要定义其名称、类型以及描述。节点和Pod/容器对应的原始数据结构都定义在cAdvisor的API Spec中,即MachineInfo和ContainerStats。

type infoProvider interface {
    // GetRequestedContainersInfo gets info for all requested containers based on the request options.
    GetRequestedContainersInfo(containerName string, options v2.RequestOptions) (map[string]*info.ContainerInfo, error)
    // GetVersionInfo provides information about the version.
    GetVersionInfo() (*info.VersionInfo, error)
    // GetMachineInfo provides information about the machine.
    GetMachineInfo() (*info.MachineInfo, error)
}

而从上面KubeRegistry的注册逻辑中可以看到,infoProvider的实现又需要通过prometheusHostAdapter进行一次转换,其转换前的实现接口为HostInterface。

type prometheusHostAdapter struct {
    host HostInterface
}

func (a prometheusHostAdapter) GetRequestedContainersInfo(containerName string, options cadvisorv2.RequestOptions) (map[string]*cadvisorapi.ContainerInfo, error) {
    return a.host.GetRequestedContainersInfo(containerName, options)
}
func (a prometheusHostAdapter) GetVersionInfo() (*cadvisorapi.VersionInfo, error) {
    return a.host.GetVersionInfo()
}
func (a prometheusHostAdapter) GetMachineInfo() (*cadvisorapi.MachineInfo, error) {
    return a.host.GetCachedMachineInfo()
}

在HostInterface的定义中,查看监控相关的部分接口,prometheusHostAdapter需要的VersionInfo和MachineInfo是由Kubelet实现的,而GetRequestedContainersInfo即容器相关监控信息的接口则由前面提到的stats.Provider中实现。

type HostInterface interface {
    stats.Provider
    GetVersionInfo() (*cadvisorapi.VersionInfo, error)
    GetCachedMachineInfo() (*cadvisorapi.MachineInfo, error)
    GetRunningPods() ([]*v1.Pod, error)
    GetHostname() string
    
    // 省略监控无关接口
}

监控数据提供方Stats Provider

Provider定义

基于上一节分析,可以了解到Kubelet Server中返回的监控信息,无论是统计类信息还是指标类信息,容器相关的部分都是通过stats.Provider获取的。那么我们看看stats.Provider部分是如何定义的:

type Provider interface {

    // ListPodStats 返回Pod管理的容器统计信息
    ListPodStats() ([]statsapi.PodStats, error)
    // ListPodCPUAndMemoryStats 返回Pod管理的容器统计信息(CPU/内存部分)
    ListPodCPUAndMemoryStats() ([]statsapi.PodStats, error)
    // ListPodStatsAndUpdateCPUNanoCoreUsage 返回Pod管理的容器统计信息,这个方法会强制更新cpu的NanoCoreUsage信息,主要用于部分未内部集成cAdvisor的CRI Runtime实现。详见:https://github.com/kubernetes/kubernetes/issues/72788
    ListPodStatsAndUpdateCPUNanoCoreUsage() ([]statsapi.PodStats, error)
    // ImageFsStats 返回镜像文件系统的统计信息
    ImageFsStats() (*statsapi.FsStats, error)

    // GetCgroupStats 通过指定的cgroup名称返回统计信息及网络用量
    GetCgroupStats(cgroupName string, updateStats bool) (*statsapi.ContainerStats, *statsapi.NetworkStats, error)
    // GetCgroupCPUAndMemoryStats 通过指定的cgroupName返回CPU和内存统计信息
    GetCgroupCPUAndMemoryStats(cgroupName string, updateStats bool) (*statsapi.ContainerStats, error)

    // RootFsStats 返回节点根分区的统计信息
    RootFsStats() (*statsapi.FsStats, error)

    // GetContainerInfo 通过Pod Uid返回该Pod管理的容器的指标信息
    GetContainerInfo(podFullName string, uid types.UID, containerName string, req *cadvisorapi.ContainerInfoRequest) (*cadvisorapi.ContainerInfo, error)
    // GetRawContainerInfo 通过容器名返回容器的指标信息,如果开启了subcontainers选项,则该方法会返回所有子容器的指标信息
    GetRawContainerInfo(containerName string, req *cadvisorapi.ContainerInfoRequest, subcontainers bool) (map[string]*cadvisorapi.ContainerInfo, error)
    // GetRequestedContainersInfo 通过容器名返回容器的指标信息,同事提供了一些cAdvisor特定的可选参数
    GetRequestedContainersInfo(containerName string, options cadvisorv2.RequestOptions) (map[string]*cadvisorapi.ContainerInfo, error)

    // GetPodByName 通过Pod的命名空间和名称返回具体的Pod信息
    GetPodByName(namespace, name string) (*v1.Pod, bool)
    // GetNode 返回节点规格信息
    GetNode() (*v1.Node, error)
    // GetNodeConfig 返回节点配置信息
    GetNodeConfig() cm.NodeConfig
    // ListVolumesForPod 通过Pod Uid返回对应Pod使用的卷统计信息
    ListVolumesForPod(podUID types.UID) (map[string]volume.Volume, bool)
    // ListBlockVolumesForPod 通过Pod Uid返回对应Pod使用的块设备卷统计信息
    ListBlockVolumesForPod(podUID types.UID) (map[string]volume.BlockVolume, bool)
    // GetPods 返回节点上运行的所有Pod的信息
    GetPods() []*v1.Pod

    // RlimitStats 返回系统的rlimit统计
    RlimitStats() (*statsapi.RlimitStats, error)

    // GetPodCgroupRoot 返回管理所有Pod的根Cgroup节点路径
    GetPodCgroupRoot() string
    // GetPodByCgroupfs 通过cgroup路径名查找并返回Pod信息
    GetPodByCgroupfs(cgroupfs string) (*v1.Pod, bool)
}

通过上面Provider的接口划分,我们大致了解了Kubelet在监控方面提供的能力,主要包括容器、Pod、节点、文件系统的统计信息或指标信息等。其中不少接口都用到了cgroup。
cgroup(control group)是Linux内核中用于限制、记录和隔离一组进程的资源使用(CPU、内存、磁盘 I/O、网络等)的模块,它与namespace一起作为基石构成了容器基础技术的实现。绝大部分场景下,大家对他比较熟悉的点在于其发挥的资源划分和限制能力,例如K8S中Pod与Container的CPU/内存资源Limit。除了资源限制能力外,实际上cgroup每个子系统还具有对应的统计能力。以CPU子系统为例,它可以统计CPU在用户空间和内核空间的运行时长分配、设置Limit后的CPU限流次数和限流总时长等:

Cgroup是以树形结构来划分和组织系统内的各个进程的,Kubelet在运行时会创建一个kubepods的叶节点。而根据Pod的QoS等级划分,不同Pod被放在不同的QoS叶节点下。对应的,容器本身作为Pod管理的最小单元,其被划分在Pod的叶节点以下(_需开启containerd中runc的SystemdCgroup选项,否则container由containerd cgroup单独管理_)。

大致了解了Cgroup之后,细心的你就能想明白在Provider中不太容易理的GetRawContainerInfo和GetRequestedContainersInfo接口的用法,即参数中的Container指的不仅是被Pod管理的Container,其实指的也是Cgroup的叶节点。它可以是Container/Pod/QoS/Kubepods,甚至是节点本身(即"/")。这也能解释为什么会有subcontainers这个参数,毕竟Container作为最小运行单元肯定是不存在子容器这个说法的。subcontainers可以直接理解为是否包含子节点的信息,GetRawContainerInfo接口实际上是提供了当前节点与子节点的统计信息。

Provider初始化

provider初始化包含在Kubelet的初始化流程中,通过useLegacyCadvisorStats开关,Kubelet会进行会在CadvisorStatsProvider和CRIStatsProvider中选择一种作为实际实现。

func NewMainKubelet(kubeCfg *kubeletconfiginternal.KubeletConfiguration, kubeDeps *Dependencies, ... ){
    
    // 其他初始化流程
    ...

    hostStatsProvider := stats.NewHostStatsProvider(kubecontainer.RealOS{}, func(podUID types.UID) string {
        return getEtcHostsPath(klet.getPodDir(podUID))
    })
    if kubeDeps.useLegacyCadvisorStats {
        klet.StatsProvider = stats.NewCadvisorStatsProvider(
            klet.cadvisor,
            klet.resourceAnalyzer,
            klet.podManager,
            klet.runtimeCache,
            klet.containerRuntime,
            klet.statusManager,
            hostStatsProvider)
    } else {
        klet.StatsProvider = stats.NewCRIStatsProvider(
            klet.cadvisor,
            klet.resourceAnalyzer,
            klet.podManager,
            klet.runtimeCache,
            kubeDeps.RemoteRuntimeService,
            kubeDeps.RemoteImageService,
            hostStatsProvider,
utilfeature.DefaultFeatureGate.Enabled(features.DisableAcceleratorUsageMetrics)    utilfeature.DefaultFeatureGate.Enabled(features.PodAndContainerStatsFromCRI))
    }
    
}

对比两者的初始化方法可以分析得出其主要的数据来源都是cadvisor和resourceAnalyzer,其他参数是主要作为一些辅助选项。resourceAnalyzer主要提供了节点资源消耗的统计,除了文件系统相关的统计,其主要实现还是我们之前提到的SummaryProvider。
那么基本可以得出一个结论,无论是哪种实现,容器相关的监控都主要来自于cAdvisor。

总结

本篇文章中,我们主要了解了Kubelet Server在对外提供的监控API中统计类和指标类的划分,并了解到容器监控的部分主要由Stats Provider定义。同时,我们也知道了目前Kubelet中对于Stats Provider的实现主要有两种——CadvisorStatsProvider和CRIStatsProvider。接下来的一篇文章,我们会对这两种实现进行深入的对比分析,并分析两种Provider的实现是如何使用cAdvisor接口提供容器监控数据。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
6天前
|
Kubernetes 监控 Cloud Native
|
1天前
|
存储 运维 Kubernetes
云端迁移:备份中心助力企业跨云迁移K8s容器服务平台
本文将简要介绍阿里云容器服务ACK的备份中心,并以某科技公司在其实际的迁移过程中遇到具体挑战为例,阐述如何有效地利用备份中心来助力企业的容器服务平台迁移项目。
|
1天前
|
前端开发 JavaScript API
探索GraphQL:如何构建高效的数据API
【10月更文挑战第25天】在现代Web开发中,API的效率和灵活性至关重要。本文探讨了如何利用GraphQL构建高效的数据API。GraphQL通过声明式查询方式,允许客户端精确指定所需数据,减少数据传输量,提高API效率。文章介绍了设置GraphQL服务器、设计API Schema、实现解析函数及调整前后端交互的具体步骤,展示了GraphQL的优势和应用场景。
11 2
|
4天前
|
存储 Kubernetes C++
Kubernetes VS Docker Swarm:哪个容器编排工具更适合你?
随着容器技术的快速发展,容器编排工具成为了现代软件开发和运维的重要环节。在众多容器编排工具中,Kubernetes和Docker Swarm无疑是最受欢迎的两个。本文将从技术特性、易用性和社区支持三个方面,对Kubernetes和Docker Swarm进行比较,以帮助您选择更适合您需求的容器编排工具。
19 3
|
6天前
|
缓存 监控 测试技术
获取API接口数据的最佳实践详解
在开发过程中,与API进行交互是获取数据和服务的关键步骤。本文详细介绍了10个最佳实践,包括明确需求和文档、错误处理、数据验证、性能优化、安全性、日志和监控、版本控制、代码复用和维护、测试以及遵守法律和道德规范,帮助开发者更高效地从API获取数据,确保数据的准确性、安全性和性能。
|
2天前
|
运维 Kubernetes Cloud Native
云原生入门:Kubernetes和容器化的未来
【10月更文挑战第23天】本文将带你走进云原生的世界,探索Kubernetes如何成为现代软件部署的心脏。我们将一起揭开容器化技术的神秘面纱,了解它如何改变软件开发和运维的方式。通过实际的代码示例,你将看到理论与实践的结合,感受到云原生技术带来的革命性影响。无论你是初学者还是有经验的开发者,这篇文章都将为你开启一段新的旅程。让我们一起踏上这段探索之旅,解锁云原生技术的力量吧!
|
5天前
|
存储 数据可视化 API
API接口数据获取流程的细化
本文概述了API的基础知识、获取API访问权限的方法、编写代码调用API的步骤、数据处理与分析技巧以及数据安全与合规的重要性,并提供了社交媒体数据分析、天气预报应用和电商数据分析等API数据获取的应用实例,旨在帮助读者全面了解和实践API接口数据获取的流程。
|
5天前
|
缓存 监控 API
抖音抖店 API 请求获取宝贝详情数据的调用频率限制如何调整?
抖音抖店API请求获取宝贝详情数据的调用频率受限,需遵循平台规则。开发者可通过提升账号等级、申请更高配额、优化业务逻辑(如缓存数据、异步处理、批量请求)及监控调整等方式来应对。
|
7天前
|
缓存 负载均衡 API
抖音抖店API请求获取宝贝详情数据、原价、销量、主图等参数可支持高并发调用接入演示
这是一个使用Python编写的示例代码,用于从抖音抖店API获取商品详情,包括原价、销量和主图等信息。示例展示了如何构建请求、处理响应及提取所需数据。针对高并发场景,建议采用缓存、限流、负载均衡、异步处理及代码优化等策略,以提升性能和稳定性。
|
14天前
|
Prometheus 监控 Cloud Native
如何查看商品销量 API 接口的性能指标数据?
要查看商品销量 API 接口的性能指标数据,可以通过以下几种方法:1. 使用第三方或开源 API 监控工具,如 Datadog、New Relic、Prometheus 和 Grafana;2. 在代码中手动记录时间戳或使用性能测量库;3. 查看 API 提供商的文档和报告;4. 进行负载测试,使用工具如 Apache JMeter 和 Gatling。这些方法可以帮助你全面评估 API 的性能表现。
37 2

热门文章

最新文章

相关产品

  • 容器服务Kubernetes版