母婴网站怎么做,建设响应式网站,搜索引擎优化课程,深圳软件定制公司排名作者 | Gregoire DAYET 策划 | 田晓旭 IT 团队已经明确意识到对基础设施进行监控的必要性。目前市面上存在着大量适用于传统基础设施且历史悠久的解决方案#xff1a;Nagios、Zabbix 等工具都是其中的代表。但这些工具并不足以解决 Kubernetes 生态系统在多层级抽象与故障排查… 作者 | Gregoire DAYET 策划 | 田晓旭 IT 团队已经明确意识到对基础设施进行监控的必要性。目前市面上存在着大量适用于传统基础设施且历史悠久的解决方案Nagios、Zabbix 等工具都是其中的代表。但这些工具并不足以解决 Kubernetes 生态系统在多层级抽象与故障排查方面的实际需求。不少 DevOps 工程师一次又一次被以下问题所困扰调度失败找不到与以下所有谓词相匹配的节点CPU 不足集群资源监控对于实时跟踪而言至关重要。与传统基础设施相比集群资源一直在不断扩展和变化。我们永远无法知晓自己的 Pod 在集群中的启动位置。出于这些考虑我们需要监控集群的底层资源以及内部集群的运行状态。更重要的是如果不配合警报机制单纯进行监控还远远不够。因为很明显运营工程师不可能整晚对着关键生产集群的仪表板等待。1 为什么要选择 Prometheus 与 Grafana 即使拥有广泛的警报与监控工具可供选择我们为什么要专门点名 Prometheus 与 GrafanaPrometheus Prometheus 是一款开源监控工具。它最初在 Soundcloud 上开发完成但如今已经转化为独立的开源项目从 2016 年开始成为云原生计算基金会(CNCF)的一部分并成为继 Kubernetes 本身之后的第二个项目。也正因为如此这两款组件通常会紧密关联在一起。除此之外Prometheus 不同于其他众多监控工具的一大核心在于其基本架构始终以 pull 为基础。它不断从受到监控的组件当中抓取指标。最后从架构本身来看Prometheus 使用到多维数据模型此模型与 Kubernetes 通过标签组织数据的方式非常相似。与点数据模型相反点数据模型中的每项指标都是唯一的而每个不同的参数都将对应不同的指标而使用 Prometheus所有数据都将按时间序列存储为键 - 值对metric name{label namelabel value, …}Prometheus 架构包含三大主要组件Prometheus 服务器本身用于收集指标并通过 API 应答查询。Pushgateway公布关于临时及短期作业的指标。Alertmanager按照名称提示启用警报发布。Prometheus 架构与生态系统组件我们还将把 prometheusnode_exporter 与 kube_state_metrics 相结合用以发布关于集群的各项指标。Grafana Grafana 是一款颇为流行的 Prometheus 开源(Apache 2.0 许可)可视化层支持以开箱即用的方式按时间查询 Prometheus 数据。实际上从 Grafana 2.5.0 (2015–10–28) 版本开始就已经把 Prometheus 纳入为 Grafana 数据源。最重要的是它非常易于使用其中提供的模板功能可帮助您轻松创建可实时编辑的动态仪表板。最后Grafana 提供良好的说明文档以及广泛的社区共享体系包括各类公共仪表板。在本文中我们将使用两套专为 Kubernetes 设计的公共仪表板。理论到此结束下面开始动手环节2 安装的先决条件 完成演练项目的唯一要求就是拥有一套有效的 Kubernetes 集群。为了简单起见本文将在 AWS EC2 上使用 minikube 完成安装。Minikube 是一种便捷方法能够快速高效地安装一套非生产、主要用于实验室及测试场景的单节点 Kubernetes 集群。由于对资源需求不高而且支持多种现成 K8s 功能大家可以借此在单一计算机上轻松获取 Kubernetes 集群。只要使用虚拟机管理程序在机器上创建本地计算机系统即可正常工作。但这里我们使用 AWS 虚拟机并在演示中使用 Minikube 的 vm-drivernone 模式。3 使用 Helm 安装 Prometheus 与 Grafana 接下来就是安装这两款产品了。这里我们使用 Helm, 这款 Kubernetes 软件包管理器已经在 2019 年 11 月正式更新为 3.0 版本。从历史来看此次更新非常重要因为开发社区对 Helm 进行深度重写借此适应 RBAC 与自定义角色定义等 Kubernetes 发展成果。新版本较以往版本更适合生产要求。以往由于固有安全模型以及高度依赖于存在争议的 Tiller 组件(现已从 3.0 版本中删除)不少 IT 专家都不愿意将 Helm 应用于生产级集群。我们还将使用稳定版 Helmrepo 中的 charts(Helm 打包格式)对 Kubernetes 集群组件及系统指标进行监控。安装 Helm 将稳定版 repo 添加至您的 Helm 安装$ helm repo add stable[https://kubernetes-charts.storage.googleapis.com/](https://kubernetes-charts.storage.googleapis.com/)$ helm repo update接下来我们在 K8s 集群上创建一个自定义命名空间用以管理所有监控栈$kubectlcreate ns monitoring安装 Prometheus 现在我们可以在新创建的监控命名空间中安装 Prometheuschart 了$ helm installprometheusstable/prometheus--namespace monitoringNAME:prometheusLAST DEPLOYED: Tue Apr 14 09:22:27 2020NAMESPACE: monitoringSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:prometheus-server.monitoring.svc.cluster.local[...]接下来我们可以使用 K8s 的本地指令命令创建一个 NodePort借此从集群外部直接与 Pod 通信。请注意如果您不打算在未安装 Grafana 的前提下查询 Prometheus也可以直接跳过此步骤。我们可以看到端口 30568 被自动分配并映射至指向该 Pod 的端口 9090.现在我们可以使用公共 DNS 及浏览器中的 30568 端口访问 Prometheus 端点。接下来我们可以使用以下命令直接查询 Prometheus 以获取各类指标例如命名空间的 CPU 消耗量sum(rate(container_cpu_usage_seconds_total{container_name!”POD”,namespace!””}[5m])) by (namespace)4 安装 Grafana 现在Prometheus 已经安装完成。相较于单独查询各项指标我们可以使用 Grafana 以聚合方式通过统一的仪表板快速查看多项指标。我们再次使用 helm 将 grafana 安装在监控命名空间当中$ helm installgrafanastable/grafana--namespace monitoring可以看到grafanaPod 开始配合 Prometheus 组件运行这里我们再创建一个 NodePort 服务从集群外部访问 Grafana(此步骤为强制要求)$kubectl-n monitoring expose pod grafana-5b74c499c6-kt4bw --typeNodePort--namegrafana-npservice/grafana-np exposed而后将外部端口映射至 Grafana 的侦听端口 3000(这里为 31399)$kubectl-n monitoringgetsvcgrafana-npNAMETYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEgrafana-npNodePort10.111.59.2 80:30368/TCP,3000:31399/TCP 3h8m在浏览器中输入yourPublicDNS:yourPort 与 tada!Grafana 提供用户管理功能在默认情况下您需要使用 admin 用户方可接入。要获取 admin 密码请输入以下命令kubectlget secret — namespace monitoringgrafana-ojsonpath”{.data.admin-password}” | base64 — decode ;echoADMINPASSWORD现在即可开始正式连接。第一步是使用 Kubernetes 的内部 DNS 结构将 Prometheus 配置为数据源http://prometheusServiceName.namespace.svc.cluster.local:port在本示例中为http://prometheus-server.monitoring.svc.cluster.local(:80 可选)现在数据已经添加完成我们将导入两套社区仪表板用于监控我们的工作负载与集群运行情况。这些仪表板应该可以开箱即用。点击 import 按钮并输入 Grafana 仪表板 ID首先安装 1860而后安装 8685现在我们已经拥有了两套工作仪表板我们已经可以轻松监控系统指标与集群配置了5 通过 Slack 频道发布警报 现在我们已经拥有了一套高效的监控解决方案第二步就是激活警报。很明显如果没有警报机制的支持运营团队不可能整天盯着生产环境中的众多仪表板。我们可以通过两种方式在监控栈中实施警报。首先是使用 PrometheusAlertManager 组件(由 helm chart 安装)其次是使用 Garfana 的内置警报功能。这里我们选择后一种方式因为其更易于现实。Grafana 能够通过 Slack、电子邮件、webhook 或者其他通信渠道发布警报。由于我个人经常使用 Slack而且不少企业也在使用 Slack 作为内部通信平台因此本示例就以 Slack 为警报通道。创建 Slack 通知频道 第一步是将 Slack 添加为通知频道。在 Grafana 当中单击左侧的铃铛图标选择通知频道菜单而后创建一个新频道。您将在这里看到多种与 Grafana 相兼容的警报工具。选择 Slack而后输入您的 Slack webhook URL(其他字段为可选项)。如果您还没有 webhook URL请参阅此教程进行创建:https://api.slack.com/messaging/webhooks如此一来您将拥有一个端点用于将消息发送至 Slack 服务器上的特定频道。创建并测试自定义警报 现在频道已经设置完毕接下来使用“K8s Cluster Summary”仪表板而后单击“Cluster Pod Capacity”标题以编辑面板。我们将设置一项警报来监控 Pod 容量在默认情况下每个节点上的 Kubernetes 限制为 110 个。此上限总体属于可靠上限。如果集群中的节点数量受到限制而且已经达到 110 个这一硬上限则剩余的 Pod 将进入挂起状态。而这会在高业务活动强度期间给生产集群扩展造成巨大问题。我们将警报设置为 90 个 Pod回到我们的集群创建一个包含 100 个 nginx 副本的任意部署$kubectlcreate nsloadtestnamespaceloadtestcreated$kubectlcreate deploymentnginx--imagenginx-nloadtestdeployment.apps/nginxcreated$kubectl-nloadtestscale deploymentnginx--replicas100deployment.apps/nginxscaled可以看到由于集群中已经包含 15 个初始 Pod且 Pod 容量迅速增加到 115 个这比许可的 Pod 上限 110 个还多了 5 个。实际上我们可以在仪表板中看到 5 个 Pod 处于待处理状态。5 分钟之后警报进入 ALERTING 状态并在 Slack 频道上发送带有自定义消息及当前值的通知。我们可以将部署缩减至 1 个 Pod$kubectl-nloadtestscale deploymentnginx— replicas1deployment.apps/nginxscaledPod Capacity 已经冷却警报会向 Slack 发送返回正常状态的通知。这项小小的演练非常有趣因为它不仅实施起来相当简单而且足以反映真实的运营场景。关于 Grafana 警报功能还有其他一些注意事项。我们的两套仪表板都使用被称为模板变量的函数。变量是您可以在主机、集群或者命名空间等仪表板之上进行更改的值。根据设计Grafana 不可根据模板变量发出警报原因很多。如果尝试在仪表板的某些面板上放置一些警报则有可能因此而出错。解决方案是为各项警报指定一个特定的主机、集群或者节点而非使用变量进行监控。6 总结 在与 Prometheus 与 Grafana 打过一番交道之后希望大家喜欢这篇文章并感受到监控对于 Kubernetes 生态系统的重要意义。原文链接https://gregoiredayet.medium.com/monitoring-and-alerting-on-your-kubernetes-cluster-with-prometheus-and-grafana-55e4b427b22d今日推荐文章 对话Ruby on Rails之父DHH我们需要重新审视软件开发点个在看少个 bug ?
