Kubermetrics是一种开源工具，可在简单易懂的用户界面中提供 Kubernetes 集群监控和数据可视化。
要开始讲述 Kubermetrics 如何形成的故事，让我们首先从 Kubernetes 是什么以及它如何尝试解决微服务架构开始。如果您已经熟悉微服务/Docker/Kubernetes，请随时跳到“介绍 Kubermetrics”部分。
一、什么是微服务
微服务没有正式的定义，简单地说，微服务是一种架构风格，它将单个应用程序开发为一组专注于单个目的的小型服务。这种架构风格非常受欢迎，尤其是随着 DevOps 空间的增长。
微服务是设计用于处理多个相关任务的单体式应用程序构建风格的替代方案。单片应用程序往往是具有大量紧密耦合功能的更复杂的应用程序。在单体应用程序中对单个功能进行小的更改可能需要在受影响的功能范围之外对整个平台进行大量编译和测试。
与这种方法相比，微服务架构将单体结构分解为更小、更简单的应用程序，这些应用程序作为松散耦合的服务独立部署，并与应用程序集成（例如事件总线）捆绑在一起。这些服务也应该专注于一个单一的目的并且做得很好。
使用微服务有很多好处，其中一些关键是独立的组件、更容易理解和更好的可扩展性。
二、利用微服务的技术
关于利用微服务的技术栈有很多，由于云原生技术非常盛行，也已深入人心，很多企业也都在落地云原生，我们将参考与 Kubermetrics 应用程序直接相关的技术栈，其中包含Docker及kubernetes。
2.1、Docker
简单来说，Docker 是一种开发人员工具，它通过利用称为容器的隔离环境来简化构建、运行和分发应用程序的过程。
为了解释什么是容器，Docker Solomon Hykes 的创建者说容器是“独立的软件单元，你可以从那里的服务器传送到那里的服务器，从你的笔记本电脑到 EC2 再到裸机巨型服务器，并且它将以相同的方式运行，因为它在进程级别被隔离并拥有自己的文件系统。”
使用中的一个快速示例是假设用户 A 有一个 MacOS系统，而用户 B 有一个 Windows 系统。用户 A 创建了一个适用于他们自己的系统的应用程序，但由于某些操作系统相关问题，用户 B 无法运行该应用程序。通过将应用程序“dockerizing”到一个隔离的环境中，无论用户 B 的操作系统有何差异，该应用程序都可以保证为用户 B 工作。这也超出了操作系统差异，例如类似设备上不同版本的框架等等。
发生这种情况的方法比这要复杂得多，但为了理解 Docker，关键要点是我们能够将应用程序或服务容器化，从而为我们带来好处，例如：
- Docker 容器是简约的，并具有可移植性
- Docker 容器支持可组合性（模块化）
- Docker 容器非常适合规模化并允许编排
Docker 是打包应用程序的绝佳方式，可以非常轻松地与单体应用程序一起使用，但它与微服务的协同作用更大。多亏了 Docker，开发人员可以将每个单独的服务打包到自己的容器中。因此，许多公司正在从单体应用程序过渡到微服务应用程序，同时在此过程中采用 Docker。
2.2、Kubernetes
随着在微服务应用程序中使用Docker，与单体应用程序相比，最终部署了大量容器，单体应用程序围绕整个应用程序的单个容器是标准。正因为如此，围绕容器组织或Kubernetes，最初由谷歌创建（现在由云原生计算基金会维护）。
首先，Kubernetes 是一项如此复杂的Kubernetes 的内容进行高级概述，特别是与 Kubermetrics 相关的部分Kubernetes（简称 K8s）是Kubernetes 一起使用的主要技术是 Docker。一组这些容器组合在一起形成了最小的 K8s 组件，称为pod。这些 Pod 是 Kubernetes 可以控制的基本块，它可以根据需要启动和停止这些 Pod。Pod 部署在工作节点中，这些节点是物理机或更常见的虚拟机。最后，这些工作节点由一个不运行任何容器的主节点控制，它只是处理和管理整个Kubernetes 集群。
这是很多定义，但希望它能解释 K8s 集群的一般结构。现在真正的问题是它实际上做了什么？
Kubernetes 允许您管理多个容器，扩大、缩小和重新启动它们。使用 Kubernetes 的一些主要好处是：
- Kubernetes 在处理流量时处理负载均衡
- Kubernetes 自动部署和扩展容器
- Kubernetes 将替换并重启失败的容器 有了这些知识，我们终于能够深入研究
Kubermetrics
三、Kubermetrics
什么是 Kubermetrics？
Kubermetrics是一个开放源码dev的工具，它提供Kubernetes集群监视 以及数据可视化在一个简单和容易理解的用户接口
Kubermetrics版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！ 解决了什么问题？
Kubermetrics 旨在简化使用 Kubernetes 时的用户体验。尽管 Kubernetes 是一个强大的工具，但它并不包罗万象，试图了解集群内部实际发生的事情可能会非常令人困惑。当开发人员开始使用可能包含数百个甚至数千个节点且每个节点包含多个 Pod 的集群时，这进一步得到了例证。值得庆幸的是，Kubermetrics 有能力帮助开发人员打破 K8s这个怪物。
Kubermetrics 特性
Kubermetrics 带有 3 个单独的页面，提供自己独特的数据和自定义。
主页
按命名空间显示所有节点、deployment、pod、service和ingress的仪表板。
指标页面
我们的指标页面利用完整的 Grafana 集成来定制仪表板。
alerts页面
我们的警报页面利用完整的 Prometheus 集成来访问alerts,、graphs, prom-queries等
Kubermetrics 如何工作？
现在我们将分解如何将 Kubermetrics 安装和部署到您的 K8s 集群中 为了安装 Kubermetrics，您需要克隆我们的 Github 存储库，可以在这里找到。
https://github.com/oslabs-beta/kubermetrics
如果您的集群中没有实现 Prometheus 或 Grafana，则继续“Prometheus 和 Grafana设置”
正常设置
如果您已经在监控命名空间中运行了 Prometheus 和 Grafana，那么只需应用 Kubermetrics yaml 文件。
kubectl apply -f manifests/kubermetrics-depl.yaml确保跳过 Prometheus 和 Grafana 设置部分，因为它会导致集群出现问题
Prometheus 和 Grafana 设置
首先，您需要创建一个新的命名空间来设置监控工具。
kubectl create namespace monitoring设置命名空间后，只需应用整个清单文件夹，这将为您应用每个 yaml 文件，包括 Kubermetrics 部署。
kubectl apply -f manifests您现在需要分别移植 Prometheus 和 Grafana。为此，首先获取 2 个 pod 的名称。
kubectl get pods --namespace=monitoring这将调出监控命名空间中的所有 pod。
复制每个 pod的全名，现在将它们端口转发到相应的端口。Grafana 将使用端口 3000，而Prometheus 将使用端口 9090。您还需要使用单独的终端来端口转发每个 pod。确保使用您的 pod名称而不是下面列出的名称
kubectl port-forward grafana-<6d855fdbd6-zzskc> --namespace=monitoring 3000:3000
k port-forward prometheus-deployment-<599bbd9457–7qpxv> --namespace=monitoring 9090:9090Prometheus 和 Grafana 设置到此结束！
将 Kubermetrics 部署到您的 K8s 集群中 应用适当的 yaml 文件后，您需要获取与 Kubermetrics部署对应的 pod 名称。
kubectl get pods
复制全名，现在将 pod端口转发到端口 3068。第一个参数表示您机器上要转发到的端口，而第二个参数则告诉您要转发 pod
确保使用您的 pod 名称而不是下面列出的名称
kubectl port-forward kubermetrics-depl-<55c55dbf76–9wkrn> 3068:3068有了它，您应该能够访问localhost:3000并看到一个正在运行的应用程序！
参考文献
https://medium.com/@sachem2015/kubermetrics-cluster-visualization-made-simple-d24928f63451