cadvisor

组件概述 以下是组件图 图片来源于： 此处 Kubernetes采用Master/Slave架构，主要包含如下组件： Master组件包含 API Server:API Gateway,用于和所有的组件进行交互的节点； Controller Manager:业务逻辑的控制中⼼，包含各类控制器模块 Scheduler: 对Pod进行实际调度 ETCD: 用于存储所有Kubernetes的元数据，KV存储 Slave组件 Kubelet: Node和Pod⽣生命周期管理 Kube-Proxy: Pod的对外服务发现代理 cAdvisor:容器监控，目前集成到了kubelet组件中 一般通过kubectl提交命令，然后通过APIServer存储到ETCD，再由各个组件进行watch并做相关处理。 核心资源大图 Pod: 一组容器，是kubernetes系统中的最⼩的调度单元，是直接处理业务的Workload； 应⽤用配置: ConfigMap: 可以存储相关的应用配置信息； Secret: 一般用于存储应用的秘钥信息，通过base64进行编码； PVC: 应用的持久化存储； 应⽤用服务发现: Service: Pod对外服务的负载均衡 Endpoints: 和Service⼀一⼀一对应，表示Pods的IP/Port信息 相关控制器: Deployment : 用于无状态应用的生命周期管理

一、发现问题 在一次系统上线后，我们发现某几个节点在长时间运行后会出现内存持续飙升的问题，导致的结果就是Kubernetes集群的这个节点会把所在的Pod进行驱逐OOM；如果调度到同样问题的节点上，也会出现Pod一直起不来的问题。我们尝试了杀死Pod后手动调度的办法（label），当然也可以排除调度节点。但是在一段时间后还会复现，我们通过监控系统也排查了这段时间的流量情况，但应该和内存持续占用没有关联，这时我们意识到这可能是程序的问题。 二、现象-内存居高不下 发现个别业务服务内存占用触发告警，通过 Grafana 查看在没有什么流量的情况下，内存占用量依然拉平，没有打算下降的样子： 并且观测的这些服务，早年还只是 100MB。现在随着业务迭代和上升，目前已经稳步 4GB，容器限额 Limits 纷纷给它开道，但我想总不能是无休止的增加资源吧，这是一个很大的问题。 三、Pod频繁重启 有的业务服务，业务量小，自然也就没有调整容器限额，因此得不到内存资源，又超过额度，就会进入疯狂的重启怪圈： 重启将近 200 次，告警通知已经爆炸！ 四、排查 猜想一：频繁申请重复对象 出现问题服务的业务特点，那就是基本为图片处理类的功能，例如：图片解压缩、批量生成二维码、PDF 生成等，因此就怀疑是否在量大时频繁申请重复对象，而程序本身又没有及时释放内存，因此导致持续占用。 内存池

点击上方“朱小厮的博客”，选择“ 设为星标” 后台回复" 书 "，获取 来源：22j.co/cfHw 监控系统的历史悠久，是一个很成熟的方向，而 Prometheus 作为新生代的开源监控系统，慢慢成为了云原生体系的事实标准，也证明了其设计很受欢迎。本文主要分享在 Prometheus 实践中遇到的一些问题和思考，如果你对 Kubernetes 监控体系或 Prometheus 的设计还不太了解，可以先看下容器监控系列[1]。 几点原则 监控是基础设施，目的是为了解决问题，不要只朝着大而全去做，尤其是不必要的指标采集，浪费人力和存储资源（To B商业产品例外）。 需要处理的告警才发出来，发出来的告警必须得到处理。 简单的架构就是最好的架构，业务系统都挂了，监控也不能挂。Google SRE 里面也说避免使用 Magic 系统，例如机器学习报警阈值、自动修复之类。这一点见仁见智吧，感觉很多公司都在搞智能 AI 运维。 Prometheus 的局限 Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）。 Prometheus 默认是 Pull 模型，合理规划你的网络，尽量不要转发。 对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos 等方案。

一、rancher基础配置 镜像：prom/prometheus:latest 映射端口：9090:9090 服务连接： blackbox-exporter cadvisor node-exporter 挂载卷： /home/work/prometheus:/etc/prometheus/ 调度： monitor=true 二、配置文件挂载 需要修改监听机器IP： prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s external_labels: monitor: 'exporter-metrics' alerting: alertmanagers: - static_configs : - targets : [ "alertmanager:9093" ] # Settings related to the remote write feature. remote_write: - url : " http://10.116.1.169:28086/api/v1/prom/write?db=prometheus " remote_read: - url : " http://10.116.1.169:28086/api/v1/prom/read?db=prometheus " scrape

Docker是目前最具代表性的容器技术之一，对云计算及虚拟化技术产生了颠覆性的影响。本文对Docker容器在应用中可能面临的安全问题和风险进行了研究，并将Docker容器应用环境中的安全机制与相关解决方案分为容器虚拟化安全、容器安全管理、容器网络安全三部分进行分析。 一、从虚拟化安全到容器安全 1、传统虚拟化技术 虚拟化技术是实现硬件基础设施资源的充分利用、合理分配和有效调度的重要技术手段。例如，在基于OpenStack的典型IaaS服务中，云服务提供商可通过搭建设备集群建立资源池，并将服务器、存储和网络等底层资源进行弹性虚拟化提供给租户。 传统虚拟化技术以虚拟机为管理单元，各虚拟机拥有独立的操作系统内核，不共用宿主机的软件系统资源，因此具有良好的隔离性，适用于云计算环境中的多租户场景。 2、容器技术 容器技术可以看作一种轻量级的虚拟化方式，将应用与必要的执行环境打包成容器镜像，使得应用程序可以直接在宿主机（物理机或虚拟机）中相对独立地运行。容器技术在操作系统层进行虚拟化，可在宿主机内核上运行多个虚拟化环境。相比于传统的应用测试与部署，容器的部署无需预先考虑应用的运行环境兼容性问题；相比于传统虚拟机，容器无需独立的操作系统内核就可在宿主机中运行，实现了更高的运行效率与资源利用率。 Docker是目前最具代表性的容器平台之一，它模糊了传统的IaaS和PaaS的边界，具有持续部署与测试

Docker是目前最具代表性的容器技术之一，对云计算及虚拟化技术产生了颠覆性的影响。本文对Docker容器在应用中可能面临的安全问题和风险进行了研究，并将Docker容器应用环境中的安全机制与相关解决方案分为容器虚拟化安全、容器安全管理、容器网络安全三部分进行分析。 一、从虚拟化安全到容器安全 1、传统虚拟化技术 虚拟化技术是实现硬件基础设施资源的充分利用、合理分配和有效调度的重要技术手段。例如，在基于OpenStack的典型IaaS服务中，云服务提供商可通过搭建设备集群建立资源池，并将服务器、存储和网络等底层资源进行弹性虚拟化提供给租户。 传统虚拟化技术以虚拟机为管理单元，各虚拟机拥有独立的操作系统内核，不共用宿主机的软件系统资源，因此具有良好的隔离性，适用于云计算环境中的多租户场景。 2、容器技术 容器技术可以看作一种轻量级的虚拟化方式，将应用与必要的执行环境打包成容器镜像，使得应用程序可以直接在宿主机（物理机或虚拟机）中相对独立地运行。容器技术在操作系统层进行虚拟化，可在宿主机内核上运行多个虚拟化环境。相比于传统的应用测试与部署，容器的部署无需预先考虑应用的运行环境兼容性问题；相比于传统虚拟机，容器无需独立的操作系统内核就可在宿主机中运行，实现了更高的运行效率与资源利用率。 Docker是目前最具代表性的容器平台之一，它模糊了传统的IaaS和PaaS的边界，具有持续部署与测试

由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod......等等服务，以达到随时掌握Kubernetes集群的内部状况。 此文章是Prometheus监控系列的第一篇，目的也很明确，旨在于寻找一套能够胜任kubernetes集群监控的架构。 k8s监控方案调研 1、cAdvisor + InfluxDB + Grafana 2、Heapster + InfluxDB + Grafana 3、Promethus + kube-state-metrics + Grafana Grafana : 开源DashBoard，后端支持多种数据库，如：Influxdb、Prometheus...，插件也比较多，功能强大。非常适合用于做展示。 InfluxDB : 开源时间序列数据库，性能高效 cAdvisor : 来自 Google 的容器监控工具，也是 Kubelet 内置的容器资源收集工具。它会自动收集本机容器 CPU、内存、网络和文件系统的资源占用情况，并对外提供 cAdvisor 原生的 API。随 kubelet 启动 --cadvisor-port

写在前面 之前部署web网站的时候，架构图中有一环节是监控部分，并且搭建一套有效的监控平台对于运维来说非常之重要，只有这样才能更有效率的保证我们的服务器和服务的稳定运行，常见的开源监控软件有好几种，如zabbix、Nagios、open-flcon还有prometheus,每一种有着各自的优劣势，感谢的童鞋可以自行百度，但是与k8s集群监控，相对于而已更加友好的是Prometheus，今天我们就看看如何部署一套Prometheus全方位监控K8S 主要内容 1.Prometheus架构 2.K8S监控指标及实现思路 3.在K8S平台部署Prometheus 4.基于K8S服务发现的配置解析 5.在K8S平台部署Grafana 6.监控K8S集群中Pod、Node、资源对象 7.使用Grafana可视化展示Prometheus监控数据 8.告警规则与告警通知 1 Prometheus架构 Prometheus 是什么 Prometheus（普罗米修斯）是一个最初在SoundCloud上构建的监控系统。自2012年成为社区开源项目，拥有非常活跃的开发人员和用户社区。为强调开源及独立维护，Prometheus于2016年加入云原生云计算基金会（CNCF），成为继Kubernetes之后的第二个托管项目。 官网地址: https://prometheus.io https://github

1.1 准备工作 首先要搭建K8S集群，请参考另一篇文档： https://www.cnblogs.com/taoweizhong/p/10467795.html 在此基础上，本文安装K8s dashboard、prometheus、grafana进行监控（注意上篇文档中一个虚拟机的IP地址和这里有不同，原因没有配置静态IP）。 本文中涉及容器的部署方式说明： K8s dashboard采用K8S集群管理的部署方式 prometheus和grafana仅仅采用容器化部署，没有采用K8S集群管理的部署。 本文需要下载对应的镜像如下： prom/prometheus latest grafana/grafana latest docker.io/siriuszg/kubernetes-dashboard-amd64 latest docker.io/google/cadvisor v0.24.1（不知道为啥latest无法连接上prometheus） quay.io/prometheus/node-exporter latest 本文组网如下图： 1.2 K8S Dashboard K8S Dashboard是官方的一个基于WEB的用户界面（个人觉得比较简陋），专门用来管理K8S集群，并可展示集群的状态。K8S集群安装好后默认没有包含Dashboard，我们需要额外创建它

POD资源： requests:需求，最低保障 limits:限制，硬限制 CPU： 一颗逻辑CPU（一个核心） 1=1000微核，millicores 500m=0.5CPU 内存： E、P、T、G、M、K Ei、Pi、Ti、Gi、Mi、Ki、 Qos： Guranteed：最高优先级， 确保、保证 同时设置了CPU和内存的requests和limits， cpu.limits=cpu. requests memory.limits=memory.limits Burstable：中间优先级， 至少有一个容器设置CPU或者内存资源requests的属性，当内存资源比较紧缺时将requests分配占用较大的停止 cpu.limits>cpu. requests memory.limits>memory.limits BestEffort：最低优先级， 自动配置，当内存资源比较紧缺时，BestEffort会被优先退出，确保其他类型的正常运行 没有任何一个设置 resources: limits: memory: 1024Mi cpu: 2 requests: cpu: 500m memory: 512Mi HeapSter：（新版本被整合在kubernetes内部，kube1.1后废弃） cAdvisor：收集各node节点上面内存，硬盘，cpu的资源，可以在单节点上面查看采集的结果