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

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

可用于从集群的用M源监Kubelets处收集资源使用数据的Kubernetes Metrics API，是群实一种依赖于Metrics Server集群的插件。而Metrics API的现全主要使用者(consumer)是Horizo​​ntal Pod Autoscaler(HPA，)。面资它使用由Metrics API提供的用M源监指标，以及观察到的群实资源状态值，来缩放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/<pod name> 

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 <pod name> -- 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】

很赞哦!（66549）