用MetricsServer实现Kubernetes集群全面的资源监控_0

【.com快译】不知道大家有没有使用过Prometheus、AzureMonitor、AWSContainerInsight等可观察性工具，或者LogicMonitor等商业产品，来监控Kubernetes集群，在dashboard上显示CPU、内存等资源指标？事实上，Kubernetes有一套内置的MetricsAPI和一个简单的命令行查询接口——kubectltop，可以用来获取Kubernetes对象的CPU和内存消耗的快照。KubernetesMetricsAPI是一个依赖于MetricsServer集群的插件，可用于从集群的Kubelet中收集资源使用数据。MetricsAPI的主要用户（消费者）是Horizo??ntalPodAutoscaler(HPA)。它使用MetricsAPI提供的指标以及观察到的资源状态值来扩展Pod的数量。除了MetricsAPI之外，HPA还可以设置集群上运行的应用程序的指标（自定义指标）和集群外的服务（外部指标）以自动扩展Pod。通常，外部应用程序会提供一些典型的HPA示例，包括：开源的基于事件的、可自动扩展的KEDA服务，以及LogicMonitor。与HPA类似，依赖于MetricsServer的VerticalPodAutoscaler(VPA)也可以自动调整Pod中容器的CPU和内存相关限制。可以看出，自动伸缩和监控是MetricsAPI和MetricsServer的两个主要用例。要深入Kubernetes监控，我们必须在集群上部署MetricsServer。如果您正在运行AWSEKS集群，请按照EKSMetricsServer指南中的说明在集群上安装KubernetesMetricsServer。具体可以在终端使用如下命令实现简易安装：Shellkubectlapply-fhttps://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml默认情况下，AzureAKS集群已经包含MetricsServer的部署。因此，要创建准系统AKS集群，请在终端执行以下AZ命令：Shellazgroupcreate--name--locationaustraliaeastazakscreate-n--node-count1--node-vm-sizeStandard_B2s--load-balancer-skubasic--node-osdisk-size32--resource-group--generate-ssh-keysazaksget-credentials--resource-group--name要验证MetricsServer部署的健康状况，请执行以下命令：Shellkubectlgetdeploymentmetrics-server-nkube-system我们需要在集群上运行一个应用程序来测试MetricsServer实现的MetricsAPI的有效性。为此，我们将Azure投票应用程序(https://github.com/Azure-Samples/azure-voting-app-redis)部署到该集群中。这是一个简单的应用程序，以Redis为后端，Python为前端。它有一个在每个后端运行的Pod。我们可以通过执行以下终端命令将应用程序部署到目标集群：Shellkubectlapply-fhttps://raw.githubusercontent.com/Azure-Samples/azure-voting-app-redis/master/azure-vote-all-in-one-redis.yaml要获取应用前端的外部IP地址，请执行以下命令。值得注意的是，云环境可能需要一段时间才能为您的服务分配外部IP地址：Shellkubectldescribeservicesazure-vote-front|grep'LoadBalancerIngress'现在，让我们在集群上运行一个功能齐全的应用程序。通过上述命令获取的IP地址，浏览器可以导航到应用程序的前端界面（如下图）。接下来，让我们开始监控集群中的各种对象，以及它们的状态指标。监控节点的这个端点的MetricsAPI是：/apis/metrics.k8s.io/。要访问API，您可以：使用以下命令进行端口转发：Shellkubectlport-forward-nkube-systemsvc/metrics-server:443使用kubectl相关命令：Shellkubectlget--raw"/apis/metrics.k8s.io/v1beta1/"|jq'.'接下来，让我们通过向/apis/metrics.k8s.io/v1beta1/端点发送GET请求来检查可用于通过API查询的资源，如下图所示：查看集群获取指标快照所有节点，请执行以下命令：Shellkubectlget--raw/apis/metrics.k8s.io/v1beta1/nodes|jq'.'缩小到单个节点，我们可以向/apis/metrics.k8s.io/v1beta1/nodes/端点发送GET请求。如下命令所示监控Pod，可以通过分别向/apis/metrics.k8s.io/v1beta1/pods端点和/apis/metrics.k8s.io/v1beta1/pods/端点发送GET请求来查询所有Pod或者特定Pod的状态指示器：Shellkubectlget--raw/apis/metrics.k8s.io/v1beta1/pods|jq'.'下图是终端上集群中Pod的状态快照：如果一个Pod由多个容器服务组成，那么其API的响应中会包含每个容器资源的统计信息。您可以使用以下命令将请求定向到各个Pod。Shellkubectlget--raw/apis/metrics.k8s.io/v1beta1/namespaces/default/pods/Kubernetes命令行界面：kubectltop如果觉得原来的MetricsAPI交互不是很方便，可以使用Kubernetes命令行接口上的相关命令--kubectltop（具体命令如下）查看所有节点和Pod的资源消耗统计，以及特定节点和Pod：Shellkubectltopnodekubectltoppods--all-namespaces下图显示资源集群中节点和容器的状态快照：监控容器要查看Pod中各个容器消耗的资源，请在top命令中添加参数--container，如下所示：Shellkubectltoppods--all-namespaces--containers提示：了解KubernetesCLI命令的具体用法，请使用命令--kubectlhelp快速获取。比如可以直接输入：kubectlhelptop。使用top了解容器内部。众所周知，top是Linux上一个广为流行的命令。它可以方便用户监控Linux上的不同进程及其资源使用情况。默认情况下，此命令安装在每个Linux发行版上。在这里，我们可以使用这条命令来深度监控容器内部运行的各个进程。具体来说，我们可以shell进入一个正在运行的容器并以非交互模式运行top。请参考以下命令：Shellkubectlexec--top-bn1由于我们在default（默认）命名空间中部署了应用示例AzureVoteApp，因此我们将对应用中的每个pod执行如下top命令：Shellkubectlgetpods-ndefault-ocustom-columns=name:metadata.name--no-headers|xargs-I{}sh-c'echo{};kubectlexec{}--top-bn1'下图为终端输出的执行结果：具体的输出包括：1.系统时间、正常运行时间和用户会话。2、使用的内存：RAM和Swap（磁盘的一部分，作用类似于RAM）。3.运行在容器中的进程。4.CPU使用率基于各个进程所花费的CPU时间。5.平均加载时间（例如：1、5或15分钟）。6、每个任务的特征，包括：进程ID、启动进程的用户、Nice值、优先级、内存消耗、进程状态、CPU时间、进程名称。监控Kubernetes状态Kube-state-metrics是一项服务，可用于侦听KubernetesAPI服务器并生成有关对象（如部署、节点和Pod）状态的状态指标。当然，kube-state-metrics服务不会持久化数据，它只是通过提供一个指标端点来为所有请求的对象提供最新的数据点。您可以使用Prometheus等工具来捕获服务端点并将数据保存在持久性存储中。您可以通过GitHub上的相关文档了解更多关于kube-state-metrics服务的背景，以及安装和使用指南。值得注意的是，kube-state-metrics并不是MetricsServer的替代品。毕竟，MetricsServer可以帮助用户监控集群节点和Pod上的CPU和内存使用情况。kube-state-metrics服务帮助用户监控集群状态，包括Pod、节点和其他Kubernetes对象的数量、健康和可用性信息。总结在本文中，我们学习了如何将MetricsServer安装到集群中，还讨论了如何使用各个级别的监控命令来了解Node、Pod和Container的资源使用情况。此外，我们还学习了如何使用linuxtop命令来分析容器中进程对资源的消耗程度。最后，我们讨论了kubernetes-state-metrics服务在监控Kubernetes对象状态中的作用，以及它与MetricsServer之间的主要区别。【翻译稿件，合作网站转载请注明原译者和出处.com】