Prometheus

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. 1、Features Prometheus's main features are: a multi-dimensional data model with time series data identified by metric name and key/value pairs PromQL, a flexible query language to leverage this dimensionality no reliance on distributed storage; single server nodes are autonomous time series collection happens via a pull model over HTTP pushing time series is supported via an intermediary gateway targets are discovered via service discovery or static configuration multiple modes of graphing and

使用kubeadm搭建的集群默认证书有效期是1年，续费证书其实是一件很快的事情。但是就怕出事了才发现，毕竟作为专业搬砖工程师，每天都很忙的。 鉴于此，监控集群证书有效期是一件不得不做的事情。Prometheus作为云原生领域的王者，如果能用它来监控证书有效期并能及时告警，那就再好不过了。 ssl_exporter就是来做这个事情的。ssh_exporter是一个Prometheus Exporter能提供多种针对 SSL 的检测手段，包括：https 证书生效/失效时间、文件证书生效/失效时间，OCSP 等相关指标。 下面就来监听集群证书的有效期。 安装 apiVersion: v1 kind: Service metadata: labels: name: ssl-exporter name: ssl-exporter spec: ports: - name: ssl-exporter protocol: TCP port: 9219 targetPort: 9219 selector: app: ssl-exporter --- apiVersion: apps/v1 kind: Deployment metadata: name: ssl-exporter spec: replicas: 1 selector: matchLabels: app: ssl-exporter

监控系统是运维体系乃至整个软件产品生命周期中最重要的一环，完善的监控可以帮助我们事前及时发现故障，事后快速追查定位问题。而在以微服务为代表的云原生架构体系中，系统分为多个层次，服务之间调用链路复杂，系统中需要监控的目标非常多，如果没有一个完善的监控系统就难以保证整体服务的持续稳定。 监控对象及分层 在实际场景中监控系统按照监控的对象及系统层次结构，从底向上可以依次划分为基础层、中间层、应用层、业务层等多个层面的监控。具体可如图所示： 基础层监控就是对主机服务器(包括宿主机、容器)及其底层资源进行监控，以保证应用程序运行所依赖的基础环境的稳定运行。基础层监控主要有两个方向： 资源利用：是对像I/O利用率、CPU利用率、内存使用率、磁盘使用率、网络负载等这样的硬件资源进行监控。避免因应用程序本身或其它特殊情况引起的硬件资源耗尽而出现的服务故障。 网络通信：是对服务器之间的网络状态进行监控。网络通信是互联网的重要基石，如果主机之间的网络出现如延迟过大、丢包率高这样的网络问题，将会严重影响业务。 需要说明的是，在基于Kubernetes容器化技术的新型云原生基础设施中，基础层的监控不仅要对宿主机本身进行监控，也要对Kubernetes集群状态及其容器资源使用情况进行监控。这在后面我们构建基于Kubernetes的基础层监控体系时将会具体介绍。 中间层监控主要是指对诸如Nginx、Redis

随着微服务架构的流行，迈向云原生的趋势，容器化微服务就成为了持续集成最好的手段，镜像成为了持续交付最好的产物，容器成为了镜像运行最好的环境， kubernetes 成了部署容器最好的生态系统和规范。实践出真知，自学习 kubernetes 以来，写了一系列文章，首先，为了发现知识盲点，查漏补缺，将知识点形成体系，决定将之前写的文章做一个汇总，方便查看；其次，希望打通微服务落地 kubernetes 的任督二脉，探索出一种工作模式，建立一条高度自动化的流水线，于是踏上了西天取经的道路，并梳理出了西游路线图，希望大家和我一起打妖怪，早日到达雷音寺，取得真经，阿弥陀佛，成佛成仙，呵呵；最后，通过梳理明确学习的方向和目标，一步一步前进，勿急勿躁，也鞭策自己不断学习、探索，因为有时真的就懒惰了，嘿嘿，正如四书五经《大学》中所言：“知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能得”，这是我最喜欢的话之一，也是懒惰时常常会想起的一句话，好了，不扯犊子了，嘿嘿。 西游路线图(不断探索中...)： 持续集成 --- development 阶段 代码提交、代码审核、构建编译、单元和功能测试、合并到代码仓库(git)、打包微服务成镜像、上传到镜像仓库 --- 全自动化。 备注：持续集成流程非常重要，特别是互联网行业，产品不断的更新迭代，周期却很短，业务系统微服务化后

在过去的几年中，我们已经看到 Kubernetes 被广泛用作容器编排平台。随之而来的还有不同的方式来操作 Kubernetes 集群。一些企业更喜欢一个集群一租户（硬多租户），而另一些企业更喜欢一个集群 n 租户（软多租户）模型。我们已经看到许多企业都采用后一种模型，因为它可以帮助他们减少很多运营工作。对于软多租户模型，明智地提供成本分配租户的可见性非常重要，以便可以相应地向组织收费。 需求 我们正在运行一个软多租户 Amazon EKS 集群。使用 Kubernetes 命名空间可以实现多租户。现在用于成本报告，AWS 提供了成本资源管理器，如果您想对节点，EBS 和整个网络收取费用，这将非常有用。但是不可能使用它来实现共享资源或池化资源的成本分离。我们希望基于租户创建报告，以便可以将其与预算相对应。市场上有许多用于 Kubernetes 成本报告的解决方案，我们一直在寻找开源的东西，最终选择了 Kubecost。在此博客文章中，我将详细说明如何将 Kubecost 用于多租户 EKS 集群，以获得更好的可见性。 Kubecost Kubecost 可帮助您监视和管理 Kubernetes 环境中的成本和容量。- Kubecost 文档（ https://docs.kubecost.com/ ） Kubecost 既可以作为开源产品也可以作为商业产品。该商业产品具有少量附加功能