对于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: v1kind: Namespacemetadata:  name: monitor---apiVersion: v1kind: ConfigMapmetadata:  name: prometheus-config  namespace: monitordata:  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: v1kind: PersistentVolumeClaimmetadata:  name: prometheus-pvc  namespace: monitorspec:  accessModes:    - ReadWriteOnce  resources:    requests:      storage: 100Gi  storageClassName: rook-ceph-block---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: prometheus  name: prometheus  namespace: monitorspec:  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: v1kind: Servicemetadata:  labels:    app: prometheus  name: prometheus  namespace: monitorspec:  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