在 k8s 中部署 Prometheus
k8s 的监控
k8s 默认以及推荐的监控体系是它自己的一套东西:Heapster + cAdvisor + Influxdb + Grafana,具体可以看 这里 。
包括 k8s 自身的 HPA (Horizontal Pod Autoscaler),默认从 Heapster 中获取数据 进行自动伸缩。(顺便提一句,当你部署完 k8s 集群之后,如果从 Dashboard 中看不到监控数据,往往就是因为你没有部署 Heapster,或者网络层有问题, Dashboard 无法访问 Heapster。)
那,这跟我们介绍的 Prometheus 有什么关系?
首先,它们都是一套监控解决方案,而 k8s 没有把 Prometheus 作为默认监控,因此,如果你想直接使用 HPA,你还是需要部署 Heapster。
其次,kubelet 中的 cAdvisor 其实是支持 Prometheus 作为存储的后端的,只是相对于 Prometheus 自己的 SD 解决方案来说,太弱了点。
最后,k8s 1.6 之后,在 annotations 中配置 custom metrics 的方式已经被移除了,而根据
Prometheus 的监控数据来进行自动伸缩还是很有可操作性的。
部署
其实部署很简单,关键是配置,因此这里着重介绍下,如何配置。
Relabel
首先,先来了解下,什么是 relabel_config。
就如字面意思而言,它的作用是 Prometheus 抓取 metrics 之前,就将对象相关的 labels 重写。下面是它几个重要的 label:
- __address__:默认为 host:port,也是之后抓取之后 instance 的值;
- __scheme__:http or https ?;
- __metrics_path__:就是 metrics path,默认为 /metrics;
- __param_${name}:用来作为 URL parameter,比如 http://…/metrics?name=value;
- __meta_:这个开头的配置都是 SD 相关的配置;
Kubernetes SD
其次,上次提到,我们可以用到 Service Discovery 这个功能,其中就包含 Kubernetes SD。
它包含四种角色:
- node
- service
- pod
- endpoints
由于篇幅所限,这里只是简单介绍下其中的 node 还有 pod 角色:
- job_name: 'kubernetes-nodes' scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: node relabel_configs: # 即从 __meta_kubernetes_node_label_<labelname> 这个配置中取出 labelname 以及 value - action: labelmap regex: __meta_kubernetes_node_label_(.+) # 配置 address 为 k8s api 的地址,相关的 ca 证书以及 token 在上面配置 - target_label: __address__ replacement: kubernetes.default.svc:443 # 取出所有的 node,然后设置 /api/v1/nodes/<node_name>/proxy/metrics 为 metrics path - source_labels: - __meta_kubernetes_node_name regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}/proxy/metrics
接下来的这个 pod 角色挺重要:
- job_name: 'kubernetes-pods' kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: kubernetes_pod_name
在定义了这个角色之后,你只要在你部署的应用 Pod 描述中,加入以下 annotations 就能让 Prometheus 自动发现此 Pod 并采集监控数据了:
annotations: prometheus.io/scrape: "true" prometheus.io/port: "<your app port>"
其它详细配置请看 这里。
Kubernetes Deployment
最后,部署 Prometheus,需要注意的是,我们已经在 k8s 之外单独部署了一套,为了统一处理,在这里是打算作为中转的。
apiVersion: v1 kind: ConfigMap metadata: name: prometheus namespace: kube-system labels: app: prometheus data: prometheus.yml: |- # 省略,在这里定义你需要的配置 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: prometheus namespace: kube-system spec: replicas: 1 template: metadata: labels: app: prometheus spec: containers: - name: prometheus image: prom/prometheus:latest args: - '-config.file=/prometheus-data/prometheus.yml' # 显然,这里没有用 `Stateful Sets`,存储时间不用太长 - '-storage.local.retention=48h0m0s' ports: - name: prometheus containerPort: 9090 volumeMounts: - name: data-volume mountPath: /prometheus-data volumes: - name: data-volume configMap: name: prometheus # 简单处理,直接使用 NodePort 暴露服务,你也可以使用 Ingress apiVersion: v1 kind: Service metadata: name: prometheus namespace: kube-system spec: selector: app: prometheus ports: - name: prometheus protocol: TCP port: 9090 nodePort: 30090 type: NodePort
Prometheus Federate
而在我们外部单独的 Prometheus 中,需要配置 Federate,将 k8s 中 Prometheus 采集的 metrics 全部同步出来。
- job_name: 'federate' scrape_interval: 15s honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job=~".+"}' # 取 k8s 里面部署的 Prometheus 中所有的 job 数据 static_configs: - targets: - '<k8s-node1>:30090' - '<k8s-node2>:30090' - '<k8s-node3>:30090'
本文转自CSDN-在 k8s 中部署 Prometheus
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
k8s使用deployment升级
概念 Deployment(中文意思为部署、调度)提供了一种更加简单的更新RC和Pod的机制,K8S版本1.2实现的。通过在Deployment中描述所期望的集群状态,Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康,90%的功能与RC完全一样,可以看做新一代的RC。 功能 Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务,恢复上线 任务,回滚到以前某一版本(成功/稳定)的Deployment等功能,在某种程度上,Deployment可以实现无人值守的上线,大大降低上线过程的复杂沟通、操作风险。 RC全部功能:Deployment继承了RC全部功能。 事件和状态查看:可以查看Deployment的升级详细进度和状态。 回滚:当升级pod镜像或者相关参数时发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。 版本记录:每次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。 暂停和启动:对于每一次升级,都能够随时暂停和启动。...
- 下一篇
Kubernetes—— K8S基础(完全参考总结于张磊《深入剖析Kubernetes》
K8S基础 K8S基础架构 K8S解决的问题是什么? k8s全景图 k8s Secret对象 声明式API K8S基础架构 基础架构图如下所示,我们可以看到master 节点和Node节点。 Master节点是控制节点,由三个紧密协作的独立组件组合而成。其中,APIServer负责API服务;Controller Manager负责负责容器编排;Scheduler负责容器调度。 Node节点是计算节点,其中也有很多其他组件 (1)kubelet,主要负责同容器运行时打交道 (2)CRI,远程调用接口,定义了容器运行时的各项核心操作 (3)OCI,通过容器运行时规范同底层的Linux系统进行交互,即把CRI请求翻译成对Linux操作系统的调用(操作Linux的Cgroups和Namespace) K8S解决的问题是什么? 对于大多数用户来说,k8s的主要作用是在一个给定的集群上把一个应用运行起来。更进一步说,k8s需要提供的是网关、水平拓展、监控、备份、灾难恢复等一系列运维能力。 并且在任务与任务之间的关系处理,才是作业编排和系统管理最困难的地方。 k8s对容器的访问进行了分类,首先总结...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2全家桶,快速入门学习开发网站教程
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8编译安装MySQL8.0.19
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Docker安装Oracle12C,快速搭建Oracle学习环境