北青永恒 - DevOps
type: channel
link: https://www.kococ.cn/category/DevOps
description: 该分类包含众多DevOps落地所应用到的各类组件
items: Alertmanage最详细的配置文件解释
items: 如何选择最佳的 Kubernetes 集群自动伸缩策略
items: Kubernetes排障指南
items: Centos 7.9 使用kubeadm安装kubernetes 1.25.0
items: 镜像批量迁移工具skopeo从docker-registry到harbor
items: docker实用工具：runlike、whaler
items: Kafka运维笔记
items: 在k8s中搭建有状态应用Nacos集群
items: kubernetes coredns添加自定义DNS解析记录
items: Kubernetes-Operator配置自动发现新增ServiceMonitor的NameSpace

Alertmanage最详细的配置文件解释
type: item
date: 2022-11-08T09:51:28+08:00
description: global: #全局配置 resolve_timeout: 5m #全局配置，设置解析超时时间 http_config: #使用 WebHook 发送通知时，默认使用此处配置的 http 相关参数设置。如果不使用 WebHook，请忽略此处的参数。 follow_redirects: true #跟随重定向 smtp_from: 38867033@qq.com #你的邮箱账号 smtp_smarthost: smtp.qq.com:25 #你的邮箱SMTP服务器地址 smtp_auth_username: 38867033@qq.com #你的邮箱名，可以自定义的 smtp_auth_password: <secret> #你的邮箱授权码，如果不明白，那就网上搜 smtp_require_tls: false #你是否启用TLS发信，如果启用，上面的那个25改为465 route: #定义发信路由 receiver: Default #路由名称Default group_by: #将标签值相同的告警事件组合到一个告警消息中发送。 - namespace continue: false #看下面解释 routes: #子路由 - receiver: Watchdog #子路由名称 match: #标签匹配 alertname: Watchdog continue: false - receiver: Critical #子路由名称 match: #标签匹配 severity: critical continue: false group_wait: 30s #分组等候时间 group_interval: 5m #同一分组消息发送间隔时间 repeat_interval: 12h #一模一样的告警消息再次发送时间 inhibit_rules: #抑制规则，博主不懂 - source_match: severity: critical target_match: severity_re: warning|info equal: - namespace - alertname - source_match: severity: warning target_match: severity_re: info equal: - namespace - alertname receivers: #联系人组配置 - name: Default #default组 webhook_configs: #webhook配置 - send_resolved: true #发送已解决的告警消息 http_config: follow_redirects: true url: http://dingtalk:8060/dingtalk/Default-2t88s/send #你webhook的地址 max_alerts: 0 #不知道 - name: Watchdog #Watchdog组 email_configs: #email配置 - send_resolved: true to: ilinux@88.com #发送给谁 from: 38867033@qq.com hello: localhost #test smarthost: smtp.qq.com:25 #邮箱配置 auth_username: 38867033@qq.com auth_password: <secret> headers: From: 38867033@qq.com Subject: '{{ template "email.default.subject" . }}' To: ilinux@88.com html: '{{ template "email.default.html" . }}' require_tls: false webhook_configs: - send_resolved: true http_config: follow_redirects: true url: http://dingtalk:8060/dingtalk/Watchdog-5hi33/send max_alerts: 0 - name: Critical email_configs: - send_resolved: true to: yongheng.liu@nx-engine.com from: 38867033@qq.com hello: localhost smarthost: smtp.qq.com:25 auth_username: 38867033@qq.com auth_password: <secret> headers: From: 38867033@qq.c…

如何选择最佳的 Kubernetes 集群自动伸缩策略
type: item
date: 2022-10-10T17:51:27+08:00
description: 前言这篇内容篇幅比较长，如果不想深入探讨或时间有限，这是全文简述： 在默认设置下，扩展 Kubernetes 集群中的 pod 和节点可能需要几分钟时间。 了解如何调整集群节点的大小、配置水平和集群自动缩放器以及过度配置集群以加快扩展速度。目录当自动伸缩的 Pod 报错Kubernetes 的 Cluster Autoscaler 是如何工作的探索 Pod 自动伸缩提前期为 Kubernetes 节点选择最佳实例大小在 Kubernetes 集群中过度配置节点为 Pod 选择正确的内存和CPU资源关于集群的缩容为什么不基于内存或CPU进行自动伸缩在 Kubernetes 中, 自动伸缩功能包括:Pod水平自动伸缩（Horizontal Pod Autoscaler，HPA）Pod垂直自动伸缩（Vertical Pod Autoscaler，VPA）集群自动伸缩（Cluster Autoscaler，CA）这些自动伸缩组件属于不同的类别，关注点也不同。Horizontal Pod Autoscaler 负责增加 Pod 的副本数量。随着你的应用接收到的流量越来越多，你可以让自动伸缩组件调整副本数量来处理更多的请求。Vertical Pod Autoscaler 的使用场景是，当资源不足无法创建更多的 Pod 副本时，而又仍然需要处理更多的流量。 一个简单的例子，你无法通过简单地添加更多的 Pod 副本来扩容数据库。数据库可能需要进行数据分片或者配置只读节点。 但你可以通过增加内存和CPU资源来让数据库能够处理更多的连接数。 这正是 VPA 的目的，增加 Pod 的资源大小。最后，我们要说说集群自动伸缩组件了。 当你的集群资源不足时，Cluster Autoscaler 会配置一个新的计算单元并将其添加到集群中。如果空节点过多，会移除它们以降低成本。虽然这三个组件都 “自动伸缩” 了一些东西，但它们并不造成相互之间的干扰。它们各自都有自己使用场景，定义和工作机制。并且它们是在独立的项目中开发的，独立的使用。 然而，更重要的是，为了最好的 scaling 你的集群，你必须花些心思去设置好这些 Autoscaler，让我们看个例子。当自动伸缩的 Pod 报错想象一下，有一个应用程序始终需要并使用 1.5GB 内存和 0.25 个 vCPU。 你配置了一个具有 8GB 和 2 个 vCPU 的单个节点的集群 —— 它应该能够完美地容纳四个 pod（并且还有一点额外的空间）。现在，你部署了一个 Pod 并且配置如下：HPA 配置每 10 个请求进来就添加一个 Pod 副本（例如：如果有 40 个并发请求涌入，会扩容到 4 个 Pod 副本）。CA 配置在资源不足时，创建更多的 Node 节点。HPA 可以通过在 deployment 文件中使用 Custom Metrics（例如在 Ingress Controller 中的 queries per second（QPS）） 来扩容 Pod 副本数量。现在，你开始为集群增加 30 个并发请求，并观察一下情况：HPA 开始扩容 Pod。创建了两个 Pod 副本。CA 没有触发 - 没有新增集群 Node 节点。这很好理解，因为现在有足够的内存和 CPU 资源来支持更多的 Pod。你进一步将流量增加到 40 个并发请求，并再次观察：HPA 又创建了一个 Pod。这个 Pod 是 pending 状态并且无法被部署。CA 触发创建了一个新的 Node 节点。新 Node 节点启动 4 分钟后开始工作。之后，pending Pod 也成功被部署了。为什么第四个 Pod 没有部署在第一个 Node 节点上呢？Pod 部署在集群上需要消耗内存，CPU，硬盘空间等资源，在同一个 Node 上，操作系统和 kubelet 组件也需要消耗内存和 CPU 资源。Kubernetes 中一个 Worker Node 节点的内存和 CPU 等资源使用分布如下：需要运行操作系统和一些系统级的守护进程，例如 SSH，Systemd 等。需要运行 Kubernetes Agent 组件，例如 Kubelet，Container Runtime，Node Problem Detector 等。需要运行 Pod。需要保留一些资源用来驱逐阀值 之用。你猜的没错，所有这些配额都是可定制的，但你需要好好计算一下。在一个 8GB 内存和 2vCPU 的单个节点的，可以按如下估算：操作系统运行大概需要 100MB 内存和 0.1vCPU。kubelet 运行大概需要 1.8GB 内存和 0.07vCPU。驱逐阀值大概需要 100MB 内存。剩余的大约 6GB 内存空间和 1.83vCPU 是提供给 Pod 使用的。如果你的集群需要运…

Kubernetes排障指南
type: item
date: 2022-10-09T10:55:24+08:00
description: 原文：https://learnk8s.io/troubleshooting-deployments 一份排障指南流程图。点击下载 PDF 版本。在 Kubernetes 中部署一个应用，需要定义 3 个组件：Deployment - 这是创建名为 Pod 的应用程序副本的菜谱Service - 内部负载均衡器，将流量路由到 PodsIngress - 有关流量如何从集群外部流向您的服务的描述下面是快速的回顾。在 Kubernetes 中，应用程序通过两层负载均衡暴露：内部和外部。 内部的负载平衡被称为 Service，而外部的被称为 Ingress。 Pod 并不是被直接部署的，而是通过 Deployment 创建 Pod 并监测。 假设您希望部署一个简单的 Hello World 应用程序，则该应用程序的 YAML 应该类似于以下内容： hello-world.yamlapiVersion: apps/v1 kind: Deployment metadata: name: my-deployment labels: track: canary spec: selector: matchLabels: any-name: my-app template: metadata: labels: any-name: my-app spec: containers: - name: cont1 image: learnk8s/app:1.0.0 ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: my-service spec: ports: - port: 80 targetPort: 8080 selector: name: app --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-ingress spec: rules: - http: paths: - backend: serviceName: app servicePort: 80 path: /定义很长，很容易忽略组件之间的相互关系。例如：何时使用 80 端口？何时使用 8080 端口？是否应该为每个服务创建一个新端口，避免冲突？标签名称重要吗？到处都应该一样吗？在进行调试之前，让我们回顾一下这三个组件如何相互连接。我们从 Deployment 和 Service 开始。连接 Deployment 和 Service令人惊讶的消息是 Service 和 Deployment 根本没有连接。相反，Service 端直接连接了 Pod，完全跳过了 Deployment。所以你应该关心 Pod 和 Serivce 之前是如何相互关联的。你应该注意以下 3 点：Service 选择器（selector）应该匹配至少一个 Pod 的标签（label）Service targetPort 应该匹配 Pod 内部容器内的的 containerPortService port 可以是任何数字。因为 Serivce 有不同的 IP 地址，所以多个 Service 可以使用相同的端口。下图总结了如何连接端口：通过 Service 暴露下面的 Pod。 创建 Pod 时，应为 Pod 中的每个容器定义 containerPort。 创建服务时，您可以定义 port 和 targetPort，但是您应该选择连接哪一个容器？ tagetPort 和 containerPort 应该总是匹配。 如果您的容器暴露了端口 3000，那么 targetPort 应该总是匹配这个数字。 如果您查看 YAML 文件，可以发现标签和 ports/targetPort 应该匹配：hello-world.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment labels: track: canary spec: selector: matchLabels: any-name: my-app template: metadata: labels: any-name: my-app spec: containers: - name: cont1 image: learnk8s/app:1.0.0 ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: my-service spec: ports: - port: 80 targe…

Centos 7.9 使用kubeadm安装kubernetes 1.25.0
type: item
date: 2022-09-30T11:40:40+08:00
description: 1.机器准备hostnameip地址系统版本cpu内存k8s-master192.168.88.35centos 7.94核8Gk8s-node192.168.88.37centos 7.94核8G2.初始化配置master和node设置主机名hostnamectl set-hostname k8s-master hostnamectl set-hostname k8s-node设置hosts解析cat >> /etc/hosts << EOF 192.168.88.35 k8s-master 192.168.88.37 k8s-node EOF临时关闭防火墙systemctl stop firewalld systemctl disable firwalld关闭selinuxsetenforce 0 sed -i 's/enforcing/disabled/' /etc/selinux/config关闭swap交换分区swapoff -a sed -i '/swap/s/^/#/' /etc/fstab设置内核参数modprobe br_netfilter cat >> /etc/sysctl.conf << EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward=1 EOF sysctl -p设置系统时区为上海timedatectl set-timezone Asia/Shanghai3. 安装Docker自 1.24.x版起,Docker不能再作为Kubernetes的容器运行时了,但因安装Docker会默认安装Containerd且个人觉得Docker用的顺手，所以这里还是安装Docker，也可以直接安装Containerd节省资源添加阿里yum源yum install -y yum-utils device-mapper-persistent-data lvm2 yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo安装并启动yum -y install docker-ce #也可以直接安装containerd #yum -y install containerd systemctl start docker systemctl enable docker添加阿里的镜像源cat > /etc/docker/daemon.json << EOF { "registry-mirrors": ["https://r3ucysd2.mirror.aliyuncs.com"], "exec-opts": ["native.cgroupdriver=systemd"], "storage-driver": "overlay2" } EOF重启更新配置systemctl daemon-reload systemctl restart docker4. 配置Containerd生成默认配置文件并修改containerd config default > /etc/containerd/config.toml sed -i 's/k8s.gcr.io/registry.aliyuncs.com\/google_containers/' /etc/containerd/config.toml重启加载配置systemctl daemon-reload systemctl restart containerd5. 安装kubeadm、kubelet、kubectl添加K8S阿里源cat > /etc/yum.repos.d/kubernetes.repo << EOF [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=0 repo_gpgcheck=0 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF查看可安装版本并安装yum list --showduplicates kubeadm yum install -y kubelet-1.25.0 k…

镜像批量迁移工具skopeo从docker-registry到harbor
type: item
date: 2022-09-20T15:23:00+08:00
description: 背景docker-registry地址：docker-registry.kococ.cn新镜像仓库harbor地址：harbor.kococ.cn本例将docker-registry镜像迁移至 harbor 点我展开 666 安装可以从github项目直接下载使用二进制命令也可以在centos服务器上直接yum安装,需要epel源yum -y install skopeo获取test该namespace下所有服务镜像这里我的原镜像为docker-registrykubectl get deployment,statefulset,daemonset -o custom-columns='NAME:metadata.name,IMAGES:spec.template.spec.containers[*].image' -n test > all-image ## 获取到所有image之后将域名去掉只保留除域名外登录两个镜像仓库docker login harbor.kcooc.cn docker login docker-registry.kococ.cn迁移cat mv-image.sh #!/bin/bash for i in `cat all-image`;do skopeo copy docker://docker-registry.kococ.cn/${i} docker://harbor.kococ.cn/${i} --authfile /root/.docker/config.json done

docker实用工具：runlike、whaler
type: item
date: 2022-05-31T16:34:16+08:00
description: 日常使用docker时，经常会遇到一些很恼火的问题： ① 用dcoker run启动了新容器，但是忘了保存相关参数，过了一段时间后彻底忘记，每次都得docker inspect 然后仔细分析，很费精力 ② 现存的某个docker镜像，如何知道其dockerfile ​github上有大神们针对这俩问题开发了2个工具，还是非常好用的，这里简单介绍下： ​1 runlike 找回run命令该项目的github路径：https://github.com/lavie/runlike runlike有2种常见的安装方式：pip安装和docker容器直接使用# pip 安装 pip install runlike # runlike 后跟容器名或id查询 runlike # 再跟 -p 参数可以自动分行，便于查看 runlike -p pip安装不太方便。其实作者也将该工具打包成docker镜像了，镜像名为assaflavie/runlike 我们可以直接使用容器来跑命令# 给该一次性容器取个别名，以后就可以直接使用runlike了 alias runlike="docker run --rm -v /var/run/docker.sock:/var/run/docker.sock assaflavie/runlike" # 以后就可以直接以下命令查询了 runlike -p 使用举例： ​2 镜像导出Dockerfile该项目的github路径 https://github.com/P3GLEG/Whaler ​和上边的runlike一样，whaler也可以直接用ldocker容器来跑# 给该一次性容器取个别名，以后就可以直接使用whaler了 alias whaler="docker run -t --rm -v /var/run/docker.sock:/var/run/docker.sock:ro pegleg/whaler" # 以后就可以直接以下命令查询了 whaler # 还可以将docker客户端ID设置为特定版本 whaler -sV=1.36 使用举例：

Kafka运维笔记
type: item
date: 2022-03-11T11:05:00+08:00
description: 消息队列的流派什么是 MQMessage Queue（MQ），消息队列中间件。很多人都说：MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。一个分布式系统中两个模块之间通讯要么是HTTP，要么是自己开发的（rpc） TCP，但是这两种协议其实都是原始的协议。HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上WebServer，而且还不支持⻓连接（HTTP 2.0 的库根本找不到）。TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。MQ 所要做的就是在这些协议之上构建一个简单的“协议”——生产者/消费者模型。MQ 带给我的“协议”不是具体的通讯协议，而是更高层次通讯模型。它定义了两个对象——发送数据的叫生产者；接收数据的叫消费者， 提供一个SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议有 Broker 的 MQ这个流派通常有一台服务器作为 Broker，所有的消息都通过它中转。生产者把消息发送给它就结束自己的任务了，Broker 则把消息主动推送给消费者（或者消费者主动轮询）重 Topickafka、JMS（ActiveMQ）就属于这个流派，生产者会发送 key 和数据到 Broker，由 Broker比较 key 之后决定给哪个消费者。这种模式是我们最常⻅的模式，是我们对 MQ 最多的印象。在这种模式下一个 topic 往往是一个比较大的概念，甚至一个系统中就可能只有一个topic，topic 某种意义上就是 queue，生产者发送 key 相当于说：“hi，把数据放到 key 的队列中”如上图所示，Broker 定义了三个队列，key1，key2，key3，生产者发送数据的时候会发送key1 和 data，Broker 在推送数据的时候则推送 data（也可能把 key 带上）。虽然架构一样但是 kafka 的性能要比 jms 的性能不知道高到多少倍，所以基本这种类型的MQ 只有 kafka 一种备选方案。如果你需要一条暴力的数据流（在乎性能而非灵活性）那么kafka 是最好的选择轻 Topic这种的代表是 RabbitMQ（或者说是 AMQP）。生产者发送 key 和数据，消费者定义订阅的队列，Broker 收到数据之后会通过一定的逻辑计算出 key 对应的队列，然后把数据交给队列这种模式下解耦了 key 和 queue，在这种架构中 queue 是非常轻量级的（在 RabbitMQ 中它的上限取决于你的内存），消费者关心的只是自己的 queue；生产者不必关心数据最终给谁只要指定 key 就行了，中间的那层映射在 AMQP 中叫 exchange（交换机）。AMQP 中有四种 exchangeDirect exchange：key 就等于 queueFanout exchange：无视 key，给所有的 queue 都来一份Topic exchange：key 可以用“宽字符”模糊匹配 queueHeaders exchange：无视 key，通过查看消息的头部元数据来决定发给那个queue（AMQP 头部元数据非常丰富而且可以自定义）这种结构的架构给通讯带来了很大的灵活性，我们能想到的通讯方式都可以用这四种exchange 表达出来。如果你需要一个企业数据总线（在乎灵活性）那么 RabbitMQ 绝对的值得一用无 Broker 的 MQ无 Broker 的 MQ 的代表是 ZeroMQ。该作者非常睿智，他非常敏锐的意识到——MQ 是更高级的 Socket，它是解决通讯问题的。所以 ZeroMQ 被设计成了一个“库”而不是一个中间件，这种实现也可以达到——没有 Broker 的目的节点之间通讯的消息都是发送到彼此的队列中，每个节点都既是生产者又是消费者。ZeroMQ做的事情就是封装出一套类似于 Socket 的 API 可以完成发送数据，读取数据ZeroMQ 其实就是一个跨语言的、重量级的 Actor 模型邮箱库。你可以把自己的程序想象成一个 Actor，ZeroMQ 就是提供邮箱功能的库；ZeroMQ 可以实现同一台机器的 RPC 通讯也可以实现不同机器的 TCP、UDP 通讯，如果你需要一个强大的、灵活、野蛮的通讯能力，别犹豫 ZeroMQ一、Kafka介绍Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的 （replica），基于zookeeper协调的分布式消息系统，它的最大的特性就…

在k8s中搭建有状态应用Nacos集群
type: item
date: 2022-02-25T14:09:01+08:00
description: 在k8s中部署的难点在k8s中部署nacos集群和在裸机器上直接部署nacos机器其实差别不大。最主要的区别是k8s中部署的服务没有固定的IP，而nacos集群部署需要配置所有实例的IP地址因Nacos本身是直接拿MySQL的数据,故在此服务中不做持久化操作解决在k8s中通过StatefulSet和Headless Service为每个nacos实例生成一个唯一的dns地址，创建一个普通Service给可客户端使用部署创建数据库配置CMapiVersion: v1 kind: ConfigMap metadata: name: nacos-cm data: mysql.host: "192.168.1.3" mysql.db.name: "nacos_devtest" mysql.port: "3306" mysql.user: "nacos" mysql.password: "nacos"部署Headless Service无头服务SVCHeadless Service为每个Pod（nacos实例）生成一个地址，用作NACOS_SERVERS配置apiVersion: v1 kind: Service metadata: name: nacos-headless labels: app: nacos annotations: service.alpha.kubernetes.io/tolerate-unready-endpoints: "true" spec: ports: - port: 8848 name: server targetPort: 8848 clusterIP: None selector: app: nacos使用StatefulSet控制器部署NacosStatefulSet部署方式为每个POD生成固定的名称，如nacos-0、nacos-1、nacos-2等。apiVersion: apps/v1 kind: StatefulSet metadata: name: nacos spec: serviceName: nacos-headless replicas: 3 template: metadata: labels: app: nacos annotations: pod.alpha.kubernetes.io/initialized: "true" spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "app" operator: In values: - nacos-headless topologyKey: "kubernetes.io/hostname" containers: - name: k8snacos imagePullPolicy: Always image: nacos/nacos-server:latest resources: requests: memory: "2Gi" cpu: "500m" ports: - containerPort: 8848 name: client env: - name: NACOS_REPLICAS value: "3" - name: MYSQL_SERVICE_HOST valueFrom: configMapKeyRef: name: nacos-cm key: mysql.host - name: MYSQL_SERVICE_DB_NAME valueFrom: configMapKeyRef: name: nacos-cm key: mysql.db.name - name: MYSQL_SERVICE_PORT valueFrom: configMapKeyRef: name: nacos-cm key: mysql.port - name: MYSQL_SERVICE_USER valueFrom: configMapKeyRef: name: nacos-cm key: mysql.user - name: MYSQL_SERVICE_PASSWORD valueFrom: configMapKeyRef: name: nacos-cm key: mysql.password - name: MODE value: "cluster" - name: NACOS_SERVER_PORT value: "8848" - name: PREFER_HOST_MODE value: "hostname" - name: NACOS_SE…

kubernetes coredns添加自定义DNS解析记录
type: item
date: 2022-02-25T10:10:18+08:00
description: kubernetes coredns 添加自定义DNS解析记录coredns 自带 hosts 插件， 允许像配置 hosts 一样配置自定义 DNS 解析，修改 kube-system 中 configMap 的 coredns 添加如下设置即可 hosts { 172.21.91.28 cache.redis 172.21.91.28 persistent.redis fallthrough }修改后文件如下.:53 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } hosts { 172.21.91.28 cache.redis 172.21.91.28 persistent.redis fallthrough } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance }

Kubernetes-Operator配置自动发现新增ServiceMonitor的NameSpace
type: item
date: 2022-01-29T14:26:32+08:00
description: 最近在监控k8s当中的Jenkins 的时候,新增ServiceMonitor总是不显示,这里的不显示指的是不在Prometheus-Operator中显示,我认为这其中一定有问题,于是查阅了大量的资料,终于从中找到了答案, 原因竟是Prometheus-Operator在安装的时候默认只会自动发现default,kube-system,monitoring这三个名称空间下新建的ServiceMonitor,而我的ServiceMonitor又是新建在别的名称空间下所以他无法进行自动发现更奇怪的是,网上对这个问题的记录文章几乎为0,我根本找不到,所以才写下这个笔记,供看到的人借鉴!1. 监控其他 namespace 中的 endpoint 资源需要做的操作创建新增命名空间的 role， 用于获取监控的信息。将创建的role绑定到 monitoring 命名空间中的 prometheus-k8s SA。kubectl create ns test namespace=test cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: prometheus-k8s namespace: ${namespace} roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: prometheus-k8s subjects: - kind: ServiceAccount name: prometheus-k8s namespace: monitoring --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: prometheus-k8s namespace: ${namespace} rules: - apiGroups: - "" resources: - services - endpoints - pods verbs: - get - list - watch - apiGroups: - extensions resources: - ingresses verbs: - get - list - watch EOF COPY2. 监控其他 namespace 中的 serviceMonitor 资源serviceMonitorNamespaceSelector 命名空间的标签匹配，不指定时，只匹配自身命名空间的资源serviceMonitorSelector serviceMonitor的标签匹配， 不指定时，只匹配自身命名空间的资源修改 Prometheus 资源配置apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: labels: prometheus: k8s name: k8s namespace: monitoring spec: ... # 增加 ns 匹配的标签 serviceMonitorNamespaceSelector: matchLabels: serviceMonitor: prometheus # 或者 增加下面的匹配，用来匹配 serviceMonitor serviceMonitorSelector: matchLabels: serviceMonitor: prometheus COPY添加命名空间的标签for ns in default kube-system monitoring test; do kubectl patch ns $ns --patch '{"metadata":{"labels":{"serviceMonitor": "prometheus" } } }' done COPY添加 serviceMonitor 的标签kubectl patch -n test servicemonitor demo-app --patch '{"metadata":{"labels":{"serviceMonitor":"prometheus"}}}' --type=merge COPY测试cat <<EOF | kubectl-test apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: ingress-demo-app namespace: test labels: app: ingress-demo-app spec: repli…