【51CTO.com快译】不知您是否使用过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)是Horizontal 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/
监控Pods
如下面的命令所示，您可以通过分别向/apis/metrics.k8s.io/v1beta1/pods端点和/apis/metrics.k8s.io/v1beta1/pods/
- 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
用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与内存的使用情况。而kube-state-metrics服务则是协助用户监控有关Pod、节点、以及其他Kubernetes对象的数量、运行状况、以及可用性信息等群集状态。
小结
在本文中，我们学习了如何将Metrics Server安装到集群中，也探讨了如何使用各个级别的监控命令，来获悉Node、Pod和Container的资源使用情况。此外，我们还学习了如何使用Linux的top命令，来分析容器中的进程消耗资源的程度。最后，我们讨论了kubernetes-state-metrics服务在监控Kubernetes对象状态中发挥的作用，以及它与Metrics Server之间的关键性区别。
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
