Kubernetes 教學第三篇（Persistent Volume 篇）

我們今天來嘗試架設一套服務：Prometheus + Grafana，這套服務的功能是監控機器的資源使用量（Prometheus），并且繪製成圖表或是發送警報（Grafana）。

架設服務也沒什麽特別的，我們在初篇的時候就已經加入了自己的 Deployment 來新增 Pod；再次篇的時候就把服務公開出去了。

但今天比較特別的事情是，我們要把某些資訊保留下來：

Prometheus 記錄到的機器歷史資源使用量記錄
Grafana 的圖表和警報規則

我們當然不希望每次 Pod 重啓，歷史資料就會消失，更甚至是要重新製作一次 Grafana 的圖表，因此我們要使用一些方式來持久化這些資料。

其實常見的方式有三種：

hostPath
nfs
PV

第一種就是把節點的目錄或文件直接掛載到 Pod 中，具有巨大的安全隱患。也有可能會導致資料的不一致，例如發生 Pod 的轉移。

第二種需要外部的 Infra，我們也暫且不提。

今天我們著重講述的會是第三種，PV（Persistent Volume），他是一種 Cluster Resource，意味著他在 Cluster 中所有的 Node 和 Workload（如 Pods）都共享。

創建 Prometheus + Grafana 的應用程式

Namespace

先創建一個專門爲了這隻應用程式了 namespace：

apiVersion: v1
kind: Namespace
metadata:
  name: monitoring

namespace 提供了一個可以在 cluster 内隔離資源的機制，在同一個 namespace 中的每個 resource 的名字不能重複，但跨 namespace 則沒有這個限制。有很多 resource 都是 namespace-scoping 的，意味著它只能在這個 namespace 中被使用。

我們之前并未指定 namespace 時，就會預設的放入 default 這個 namespace。

Persistent Volume Claim (PVC)

前面粗淺的介紹了 PV 為何物，然而，如果我們要對 K8S cluster 請求一塊專屬的 PV storage，我們需要創建一個 PV Claim 的資源。

PVC 和 PV 的關係，就類似於 Pod 和 Node 的關係；PVC 請求特定的大小、消耗著 PV，而 Pod 請求著特定的 CPU 與 RAM 資源、并消耗著 Node。

在這邊我們分別宣告兩個 PVC，分別給 Prometheus 和 Grafana 使用：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: prometheus-data
  namespace: monitoring
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 12Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana-data
  namespace: monitoring
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi

這邊最特別的是 accessModes，我這邊使用的是 ReadWriteOnce，他意味著那一塊 PV 一次性僅能由一個 Node 做訪問，算是比較安全卻低效的訪問模式，而且這有 deadlock 的風險，我們之後再談。

其他的訪問模式可以參考 Access Modes。

ConfigMap

Prometheus 與 Grafana 比較不同的事情是，大多數的設定我們都需要在 Grafana 的 Web GUI 裏面操作；而 Prometheus 中，我們卻要直接把設定寫在設定檔中。

因此我們需要有一個方法，可以把設定檔 mount 進 container 中。而這個時候我們就可以使用 ConfigMap，因爲它其中一個功能正是被以檔案形式掛載進入 Pod。

我這邊參考了 GitHub Prometheus Example Config 撰寫了以下的 ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
  labels:
    app: prometheus
data:
  prometheus.yml: |
    # my global config
    global:
      scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
      evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
      # scrape_timeout is set to the global default (10s).

    # Alertmanager configuration
    alerting:
      alertmanagers:
        - static_configs:
            - targets:
              # - alertmanager:9093

    # Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
    rule_files:
      # - "first_rules.yml"
      # - "second_rules.yml"

    # A scrape configuration containing exactly one endpoint to scrape:
    # Here it's Prometheus itself.
    scrape_configs:
      # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
      - job_name: "prometheus"
        static_configs:
          - targets: ["0.0.0.0:9090"]

Deployments

以下是 Grafana 的 Deployment 檔：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
        - name: grafana
          image: grafana/grafana
          volumeMounts:
            - name: grafana-storage
              mountPath: /var/lib/grafana
      volumes:
        - name: grafana-storage
          persistentVolumeClaim:
            claimName: grafana-data

這邊來仔細說說其中的內容。首先，基本上每一個 Resource 都會有一個 metadata 的欄位，寫明了這個資源的 namespace、name，或是有時候還有 label 等其它內容，這基本上比較直觀。

比較需要講解的是下面 spec 裏面的 selector 和 template：

selector 代表怎樣的 Pod 會在這個 Deployment 中，這邊寫着 matchLabels: app: grafana，就是有著 app 標簽并且值為 grafana 的 Pod 會被列入這個 Deployment。
template 中有 metadata，代表從這個 template 產生出來的 Pod 會帶有的 metadata，所以我們可以看到，從這個 template 生出來的 Pod 都會帶有 app: grafana 的標簽；因此結合上面的 selector，都會被歸類到 selector。

至於 Volumes 的部分，我們待會和 Prometheus 一起講。

以下是 Prometheus 的 Deployment 檔：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-server
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
        role: intranet-access
    spec:
      containers:
        - name: prometheus
          image: prom/prometheus
          args:
            - "--config.file=/etc/prometheus/prometheus.yml"
            - "--storage.tsdb.path=/prometheus"
          volumeMounts:
            - name: prometheus-storage
              mountPath: /prometheus
            - name: config-volume
              mountPath: /etc/prometheus/prometheus.yml
              subPath: prometheus.yml
      volumes:
        - name: prometheus-storage
          persistentVolumeClaim:
            claimName: prometheus-data
        - name: config-volume
          configMap:
            name: prometheus-config

這邊的 volumes 有兩項，一項是 prometheus-storage，另一項是 config-volume；前者代表著我們之前宣告的那個 PVC，後者則是我們剛剛創建的 ConfigMap。

而掛載進去的方式也很簡單，就是在 container 中加入 volumeMounts 的欄位，寫上下方定義的 volumeName 和 container 内的 mountPath。

而上面的 args 是 Prometheus 的啓動參數，你可以在 GitHub Prometheus Docs 中查閲。

Services

apiVersion: v1
kind: Service
metadata:
  name: prometheus-server
  namespace: monitoring
spec:
  ports:
    - port: 9090
      targetPort: 9090
  selector:
    app: prometheus
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: monitoring
spec:
  ports:
    - port: 3000
      targetPort: 3000
  selector:
    app: grafana

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: monitoring-ingress
  namespace: monitoring

spec:
  ingressClassName: nginx
  rules:
    - host: prometheus.sandb0x.tw
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: prometheus-server
                port:
                  number: 9090

    - host: grafana.sandb0x.tw
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: grafana
                port:
                  number: 3000

基本上這樣就已經能夠正常訪問 Prometheus 和 Grafana 的 Web 頁面了，但實際上還沒辦法正常運作。

因爲我們還沒有加入 Prometheus Exporter，由於 Exporters 的加入是寫在 Prometheus Config，因此我們每變動一次，就必須要重新 Apply ConfigMap，并且重啓 Pod。

通常來講，爲了避免 downtime，我們會使用以下指令：

kubectl rollout restart deployment prometheus-server -n monitoring

他會先啓動新的 Pod，然後再銷毀舊的 Pod，來避免服務下綫。但由於我們的 PVC Access Mode 設定是 RWO（ReadWriteOnce），最多一次性只有一個 Node 能訪問，因此舊的 Pod 在死亡之前，新的 Pod 沒辦法啓動成功，會 CrashLoop。

所以在這個情況，我們必須要用 kubectl delete pods 的方式來刪除舊 Pod，讓他自動重啓，這是現階段我們能做到最好的方式。

對於某些人，這樣子就可以運作了。但對於我，不行。因爲 Microk8s 的預設 ipv4 pool 是 10.1.0.0/16，和我的内網衝突了，所以我還需要調試這個問題，我會把這個部分的步驟寫在下一篇文章。

Kubernetes 教學第一篇（Microk8s 篇）

Kubernetes 教學 第三篇（Persistent Volume 篇）