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

[[403353]]

创新互联服务项目包括个旧网站建设、个旧网站制作、个旧网页制作以及个旧网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，个旧网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到个旧省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

【】不知您是否使用过Prometheus、Azure Monitor、AWS Container Insight之类的可观察性工具，或者是诸如Logic Monitor之类的商业产品，来监控Kubernetes集群，并在仪表板上显示CPU和内存等方面的资源指标?其实，Kubernetes具有一套内置的Metrics API和一个简单的命令行查询界面--kubectl top，可用于获取某个Kubernetes对象的CPU和内存消耗状况的快照。

可用于从集群的Kubelets处收集资源使用数据的Kubernetes Metrics API，是一种依赖于Metrics Server集群的插件。而Metrics API的主要使用者(consumer)是Horizo​​ntal Pod Autoscaler(HPA，)。它使用由Metrics API提供的指标，以及观察到的资源状态值，来缩放Pod的数量。除Metrics API之外，HPA还可从运行在群集上的应用程序(自定义的指标)和群集外的服务(外部指标)中，根据各项设定指标，以实现Pod的自动扩展。通常，外部应用会向HPA提供一些典型示例，包括：基于开源事件的、自动可伸缩性KEDA的服务，以及Logic Monitor。与HPA相似，依赖于Metrics Server的Vertical Pod Autoscaler(VPA，)也可以自动调整Pod中容器的CPU和内存的相关限制。

可见，自动缩放和监控是Metrics API和Metrics Server的两个主要用例。要深入研究Kubernetes监控，我们势必在集群上部署Metrics Server。如果您正在运行AWS EKS集群，那么请参照EKS Metrics Server指南中的相关说明，在集群上安装Kubernetes Metrics Server。具体而言，您可以在终端上使用如下命令，来实现轻松的安装：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml 
 
 
 
 

在默认情况下，Azure AKS群集已经包括了Metrics Server的部署。因此，若要创建准系统(barebone)的AKS集群，请在终端上执行如下AZ命令：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
az group create --name --location australiaeast 
  
  
  
  
az aks create -n --node-count 1 --node-vm-size Standard_B2s --load-balancer-sku basic --node-osdisk-size 32 --resource-group --generate-ssh-keys 
  
  
  
  
az aks get-credentials --resource-group --name 
 
 
 
 

若要验证Metrics Server部署的运行状况，请执行如下命令：

 
 
 
 

  
  
  
  
Shell  
  
  
  
  
kubectl get deployment metrics-server -n kube-system 
 
 
 
 

我们需要在集群上运行一个应用程序，以测试由Metrics Server实现的Metrics API的功效。为此，我们将Azure Voting App(https://github.com/Azure-Samples/azure-voting-app-redis)部署到该群集中。这是一个由Redis作为后端，以Python为前端的简单应用。它的每个后端上都运行着一个Pod。我们可以通过执行如下终端命令，将该应用部署到目标集群中：

 
 
 
 

  
  
  
  
Shell  
  
  
  
  
kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/azure-voting-app-redis/master/azure-vote-all-in-one-redis.yaml 
 
 
 
 

若要获取应用程序前端的外部IP地址，请执行如下命令。值得注意的是，云端环境可能需要等待一段时间，才能为您的服务分配一个外部IP地址：

 
 
 
 

  
  
  
  
Shell  
  
  
  
  
kubectl describe services azure-vote-front | grep 'LoadBalancer Ingress' 
 
 
 
 

现在，让我们在集群上运行一个功能齐全的应用。通过由上述命令获得的IP地址，浏览器可以导航至应用程序的前端界面(如下图所示)。

接下来，让我们开始监控集群中的各种对象，及其状态指标。

监控节点

该端点的Metrics API是：/apis/metrics.k8s.io/。若要访问该API，您可以：

• 通过使用如下命令实现端口转发：

 
 
 
 

  
  
  
  
Shell  
  
  
  
  
kubectl port-forward -n kube-system svc/metrics-server :443 
 
 
 
 

• 使用kubectl的相关命令：

 
 
 
 

  
  
  
  
Shell  
  
  
  
  
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/" | jq '.' 
 
 
 
 

下面，让我们通过向/apis/metrics.k8s.io/v1beta1/端点发送GET请求(如下图所示)，来检查可用于通过API查询的资源：

若要查看集群所有节点的各项指标的快照，请执行如下命令：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | jq '.' 
 
 
 
 

下图展示了终端上的命令输出：

为了将请求的范围缩小到单个节点上，我们可以向/apis/metrics.k8s.io/v1beta1/nodes/ 端点发送GET请求。

监控Pods

如下面的命令所示，您可以通过分别向/apis/metrics.k8s.io/v1beta1/pods端点和/apis/metrics.k8s.io/v1beta1/pods/ 端点发送GET请求，来查询所有Pod或特定Pod的状态指标：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods | jq '.' 
 
 
 
 

下图展示了终端上有关集群中Pod的状况快照：

如果某个Pod由多个容器组成，那么其API的响应将包含每个容器资源的统计信息。您可以使用如下命令将请求定向到单个Pod上。

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods/ 
 
 
 
 

Kubernetes的命令行界面：kubectl top

如果您觉得原始的Metrics API交互并不太方便，则可以使用Kubernetes命令行界面的相关命令--kubectl top(具体命令如下)，来查看所有节点与Pod、以及特定节点与Pod的资源消耗统计信息：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl top node 
  
  
  
  
kubectl top pods --all-namespaces 
 
 
 
 

下图展示了集群中节点和容器的资源状态快照：

监控容器

若要检查某个Pod中各个容器所消耗的资源，请将参数—container添加到top命令中，如下面所示：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl top pods --all-namespaces --containers 
 
 
 
 

提示：若要了解Kubernetes CLI命令的具体用法，请使用命令--kubectl help ，以快速获取。例如，您可以直接输入：kubectl help top。

用top了解容器内部

众所周知，top是在Linux上广为流行的命令，它可以方便用户监控Linux上的不同进程、及其资源的使用情况。而且默认情况下，该命令已安装在每一种Linux发行版上了。在此，我们可以借用该命令，来深入监控容器内部正在运行的各个进程。具体而言，我们可以将shell切入到一个正在运行的容器上，并以非交互模式运行top。请参见如下命令：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl exec  -- top -bn1 
 
 
 
 

由于我们是在默认(default)名称空间中，部署了应用示例Azure Vote App，因此我们将针对该应用程序中的每个pod，执行如下top命令：

 
 
 
 

  
  
  
  
Shell 
  
  
  
  
kubectl get pods -n default -o custom-columns=name:metadata.name --no-headers | xargs -I{} sh -c 'echo {}; kubectl exec {} -- top -bn1' 
 
 
 
 

下图展示了终端上输出的执行结果：

具体输出内容包括：

1. 系统时间、正常运行时间、以及用户会话。

2. 用到的内存：RAM和Swap(磁盘的一部分，功能类似RAM)。

3. 在容器中运行的进程。

4. 基于各种进程花费的CPU时间，得出的CPU使用率。

5. 平均加载时间(如：1、5或15分钟)。

6. 各项任务特征，包括：进程ID、启动进程的用户、Nice值、优先级、内存的消耗、进程的状态、CPU时间、以及进程名称。

监控Kubernetes状态

Kube-state-metrics是一种服务，可用于侦听Kubernetes API服务器，并生成有关对象状态(例如部署、节点和Pod)的状态指标。当然，kube-state-metrics服务不会持久保存数据，它仅通过提供一个测量端点，为所有请求对象的最新数据点提供服务。您可以使用诸如Prometheus之类的工具，来捕获服务端点，并将数据持久性地保存在永久性存储中。

您可以通过GitHub上的相关文档，获悉有关kube-state-metrics服务的背景知识，以及安装与使用指南的更多信息。值得注意的是，kube-state-metrics并不能替代Metrics Server。毕竟Metrics Server可以帮助用户监控群集节点和Pod上的CPU与内存的使用情况。而kub​​e-state-metrics服务则是协助用户监控有关Pod、节点、以及其他Kubernetes对象的数量、运行状况、以及可用性信息等群集状态。

小结

在本文中，我们学习了如何将Metrics Server安装到集群中，也探讨了如何使用各个级别的监控命令，来获悉Node、Pod和Container的资源使用情况。此外，我们还学习了如何使用Linux的top命令，来分析容器中的进程消耗资源的程度。最后，我们讨论了kubernetes-state-metrics服务在监控Kubernetes对象状态中发挥的作用，以及它与Metrics Server之间的关键性区别。

【译稿，合作站点转载请注明原文译者和出处为.com】

本文标题：用MetricsServer对Kubernetes集群实现全面资源监控
标题网址：http://www.shufengxianlan.com/qtweb/news18/294968.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联