526互联

关于Prometheus在K8S中的部署方案如何选择，以及分享手工部署的YAML

发布时间 2023-05-26 08:50:45作者: 不背锅运维

关于Prometheus部署方案的选择

在以往的分享中，有分享过使用Prometheus Operator来管理Prometheus。但，在此同时，又抛出了个问题：是手工将Prometheus部署到 Kubernetes 比较好还是使用Prometheus Operator来部署比较好？

对于技术的选型，往往是没有规定死是要用哪一项技术的，而是需要结合业务的需求、运维场景、自身对某项技术的掌握程度、以及其它更多的考量因素来共同决定的：

  1. 如果对 Kubernetes 中的 Prometheus 的自动化部署、管理和配置不是很熟悉，或者需要部署 Prometheus 集群和实现高可用性，那么使用 Prometheus Operator 是更好的选择。
  2. Prometheus Operator 提供了简化 Prometheus 在 Kubernetes 中部署的功能，可以自动处理很多繁琐的任务，如自动部署 Prometheus 和 Alertmanager、自动创建监控目标和规则等。这样可以显著降低部署和维护 Prometheus 的难度和工作量，并增强 Prometheus 在 Kubernetes 中的可靠性和可用性。
  3. 如果有丰富的 Kubernetes 和 Prometheus 的经验，并且需要更加个性化的定制和控制，那么手工将 Prometheus 部署到 Kubernetes 中也是一个不错的选择。
  4. 手工部署虽然相对更复杂，但是也可以充分发挥 Kubernetes 的灵活性和可定制性，例如自定义 Kubernetes Service 和 Endpoints、更加细致的管理数据存储和备份等。这样可以满足更加个性化和定制化的需求，同时增加对 Prometheus 系统的深度理解和掌握。

所以，选择手工部署还是 Prometheus Operator，应该基于具体场景和需求进行综合考虑，以便更好地满足业务和运维的要求。

分享手工将Prometheus部署到K8S（供参考）

下面分享手工将Prometheus部署到 Kubernetes 的yaml，关于使用Prometheus Operator部署可参考我之前的分享或者参考官方文档即可。

提示：本案例中使用Prometheus的数据目录所在的后端存储是rook-ceph，可将其修改为您已有的后端存储，如原生的ceph、nfs等等。

apiVersion: v1
kind: Namespace
metadata:
  name: monitor
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitor
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      evaluation_interval: 15s
    alerting:
      alertmanagers:
        - static_configs:
            - targets:
              # - alertmanager:9093
    rule_files:
      # - "first_rules.yml"
      # - "second_rules.yml"
    scrape_configs:
      - job_name: "prometheus"
        static_configs:
          - targets: ["localhost:9090"]
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: prometheus-pvc
  namespace: monitor
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: rook-ceph-block
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: prometheus
  name: prometheus
  namespace: monitor
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      initContainers:
      - name: "change-prometheus-data-dir-perm"
        image: busybox
        command: ["/bin/sh"]
        args: ["-c", "chown -R 65534:65534 /prometheus"]
        securityContext:
          privileged: true
        volumeMounts:
          - name: prometheus-storage
            mountPath: /prometheus
      containers:
      - image: prom/prometheus:latest
        name: prometheus
        ports:
        - containerPort: 9090
          protocol: TCP
        volumeMounts:
        - name: prometheus-storage
          mountPath: /prometheus
        - name: prometheus-config
          mountPath: /etc/prometheus
          readOnly: true
      volumes:
        - name: prometheus-config
          configMap: 
            name: prometheus-config
        - name: prometheus-storage
          persistentVolumeClaim:
            claimName: prometheus-pvc
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: prometheus
  name: prometheus
  namespace: monitor
spec:
  ports:
  - name: http-port
    nodePort: 30090
    port: 9090
    protocol: TCP
    targetPort: 9090
  selector:
    app: prometheus
  type: NodePort

注意：在上面的yaml中，initContainers 的作用是确保 /prometheus 目录以及其子目录的权限正确，因为 Prometheus 进程通常需要以非特权用户运行。同时，由于该 initContainers 是以特权模式运行的，因此可以确保 Prometheus 容器能够以正确的方式访问挂载的卷，而不会因为权限问题导致运行异常。

本文转载于WX公众号：不背锅运维（喜欢的盆友关注我们）：https://mp.weixin.qq.com/s/JlCgx1mkHqcF2e_ZqkafEw