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

37次阅读

共计 3272 个字符，预计需要花费 9 分钟才能阅读完成。

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

对于技术的选型，往往是没有规定死是要用哪一项技术的，而是须要联合业务的需要、运维场景、本身对某项技术的把握水平、以及其它更多的考量因素来独特决定的：

如果对 Kubernetes 中的 Prometheus 的自动化部署、治理和配置不是很相熟，或者须要部署 Prometheus 集群和实现高可用性，那么应用 Prometheus Operator 是更好的抉择。
Prometheus Operator 提供了简化 Prometheus 在 Kubernetes 中部署的性能，能够主动解决很多繁琐的工作，如主动部署 Prometheus 和 Alertmanager、主动创立监控指标和规定等。这样能够显著升高部署和保护 Prometheus 的难度和工作量，并加强 Prometheus 在 Kubernetes 中的可靠性和可用性。
如果有丰盛的 Kubernetes 和 Prometheus 的教训，并且须要更加个性化的定制和管制，那么手工将 Prometheus 部署到 Kubernetes 中也是一个不错的抉择。
手工部署尽管绝对更简单，然而也能够充分发挥 Kubernetes 的灵活性和可定制性，例如自定义 Kubernetes Service 和 Endpoints、更加粗疏的治理数据存储和备份等。这样能够满足更加个性化和定制化的需要，同时减少对 Prometheus 零碎的深度了解和把握。

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

上面分享手工将 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

正文完