• 作者：二二向箔
• 链接：https://www.jianshu.com/p/ef9879dfb9ef

概述

Prometheus提供了本地存储，即tsdb时序数据库，本地存储给Prometheus带来了简单高效的使用体验，prometheus2.0以后压缩数据能力也得到了很大的提升。可以在单节点的情况下满足大部分用户的监控需求。

但本地存储也限制了Prometheus的可扩展性，带来了数据持久化等一系列的问题。为了解决单节点存储的限制，prometheus没有自己实现集群存储，而是提供了远程读写的接口，让用户自己选择合适的时序数据库来实现prometheus的扩展性。

Prometheus 1.x版本的TSDB（V2存储引擎）基于LevelDB，并且使用了和Facebook Gorilla一样的压缩算法，能够将16个字节的数据点压缩到平均1.37个字节。

Prometheus 2.x版本引入了全新的V3存储引擎，提供了更高的写入和查询性能

以下所有内容均基于prometheus2.7版本

• 作者：二二向箔
• 链接：https://www.jianshu.com/p/273b1a7d4cab

系统架构图

1.x版本的Prometheus的架构图为：

目前Prometheus版本为2.7，架构图为：

Prometheus从exporter拉取数据，或者间接地通过网关gateway拉取数据（如果在k8s内部署，可以使用服务发现的方式），它默认本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中，采集到的数据有两个去向，一个是报警，另一个是可视化。PromQL和其他API可视化地展示收集的数据，并通过Alertmanager提供报警能力。

前言

在 Kubernetes 中，为了保证业务不中断或业务SLA不降级，需要将应用进行集群化部署。通过PodDisruptionBudget 控制器可以设置应用POD集群处于运行状态最低个数，也可以设置应用POD集群处于运行状态的最低百分比，这样可以保证在主动销毁应用POD的时候，不会一次性销毁太多的应用POD，从而保证业务不中断或业务SLA不降级。

PodDisruptionBudget 简介

Pod Disruption Budget (pod 中断 预算) 简称PDB，含义其实是终止pod前通过 labelSelector 机制获取正常运行的pod数目的限制，目的是对自愿中断的保护措施。

Kubernetes version >= 1.7 才支持 PodDisruptionBudget

• 作者：邵欢庆
• 链接：https://kuboard.cn/guide/proxy/#%E4%BB%A3%E7%90%86%E9%85%8D%E7%BD%AE

Kuboard Proxy

借助 Kuboard Proxy，登录 Kuboard 的用户可以直接访问 Service/Pod，而无需为 Service 做额外的 NodePort、Ingress 等配置。Kuboard Proxy 是 kubectl proxy 命令一种替代选项。

与 kubectl proxy 相比：

• 用户可以直接在 Kuboard 界面进行操作，而无需使用命令行；
• 用户权限控制；
• 支持更加细致的 rebase 控制；
• 可以对接支持 Auth-Proxy 认证方式的后端服务，实现单点登录，例如 Grafana。

本文后面的章节将描述 Kuboard Proxy 的基本使用方法。并有另外三篇文档对 Kuboard Proxy 做进一步的阐述：

• 授权用户访问 Kuboard Proxy
• 为什么我的网页通过 Kuboard Proxy 代理后显示不正常 - Rebase - （少数情况）
• 通过 Auth-Proxy 实现 Grafana 与 Kuboard 的单点登录

• 作者：Waldeinsamkeit4
• 链接：https://www.jianshu.com/p/38d90e39e536

前言

Elasticsearch Docker 部署请参考 Docker-compose 部署 ELK

内容摘要

Kaniko 简介

Kaniko 是 Google 造的轮子之一，用于在 Kubernetes 上无需特权模式构建 docker image。

Kaniko 不依赖Docker daemon守护程序，而是完全在userspace中执行Dockerfile中的每个命令。这使您可以在没有特权模式或没有运行Docker daemon的环境（例如：Kubernetes集群）中构建容器镜像。

• 作者：尜尜人物
• 链接：https://www.cnblogs.com/littlecharacter/p/9342129.html

一、数据库瓶颈

不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。

1、IO瓶颈

第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。

第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。

2、CPU瓶颈

第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。

第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。

• 作者：二二向箔
• 链接：https://www.jianshu.com/p/3f29d826a7d8

目录

一. 概述

本文是kubelet源码阅读的先导片，先了解kubelet的主要配置和功能以及一些注意事项，后面走读源码的时候才会更加顺畅，不然一堆 config 的初始化和chan处理，不知道支持哪些新特性，啥场景会用到，看了也没啥意思。

症状表现

服务器CPU资源使用一直处于100%的状态，通过 top 命令查看，发现可疑进程 kdevtmpfsi。通过 google搜索，发现这是挖矿病毒。