存儲的內容

現在云原生越來越流行，很多企業都上馬了K8S，但是這里邊也有很多的坑要填，這篇文章就聊一下K8S節點本地存儲被撐爆的問題，也就是磁盤被占滿的問題。

要解決存儲使用過多的問題，就得先了解存儲中都保存了些什么內容，否則解決不了問題，還可能帶來更多的風險。

鏡像

容器要在節點上運行，kubelet 首先要拉取容器鏡像到節點本地，然后再根據鏡像創建容器。隨著Pod的調度和程序的升級，日積月累，節點本地就會保存大量的容器鏡像，占用大量存儲空間。

如果使用的是Docker容器運行時，這些文件保存在 /var/lib/docker/image/overlay2 目錄下。

可寫層

關于可寫層，了解容器本質的同學應該比較熟悉，容器運行時使用的是一種聯合文件系統技術，它把鏡像中的多層合并起來，然后再增加一個可寫層，容器中寫操作的結果會保存在這一層，這一層存在于容器當前節點的本地存儲中。雖然鏡像中的層是容器實例共享的，但是可寫層是每個容器一份。

假如我們有一個名為 mypod 的Pod實例，在其中創建一個文件：/hello.txt，并寫入?hello k8s?的字符。

$ kubectl exec mypod -- sh -c 'echo "hello k8s" > /hello.txt'
$ kubectl exec mypod -- cat /k8s/hello.txt
hello k8s

如果使用的是Docker容器運行時，可以在Docker的相關目錄中找到可寫層以及剛剛創建的這個文件，它們在? /var/lib/docker/overlay2?這個目錄下。

如果毫無節制的使用可寫層，也會導致大量的本地磁盤空間被占用。

日志

K8S推薦的日志輸出方式是將程序日志直接輸出到標準輸出和標準錯誤，此時容器運行時會捕捉這些數據，并把它們寫到本地存儲，然后再由節點上的日志代理或者Pod中的邊車日志代理轉運到獨立的日志處理中心，以供后續分析使用。

這些日志保存在節點本地的? /var/log/container?目錄下，我們可以實際創建一個Pod來確認下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-log-stdout
spec:
  containers:
  - name: count
    image: busybox:latest
    args: [/bin/sh, -c,
            'i=0; while true; do echo "$i: $(date) a log entry."; i=$((i+1)); usleep 1000; done']

這個Pod每隔1毫秒會寫1條數據到標準輸出。要找到容器運行時根據標準輸出創建的日志文件，首先要找到這個Pod部署的節點，然后登錄到這個節點，就能找到對應的文件了。

如果程序輸出的日志很多，占滿磁盤空間就是早晚的事。

emptyDir

emptyDir 是一種基于節點本地存儲的Volume類型，它通過在本地存儲創建一個空目錄來實際承載Volume。使用這種存儲卷可以在Pod的多個容器之間共享數據，比如一個容器造數據，一個容器消費數據。

看下面這個例子：

apiVersion: v1
kind: Pod
metadata:
  name: pod-vol-empty-dir
spec:
  containers:
  - name: count
    image: busybox:latest
    args: [/bin/sh, -c, 'echo "k8s" > /cache/k8s.txt;sleep 1800']
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

在 spec.volumes[] 中只需要添加一個名為 emptyDir 的字段，它的配置都可以使用默認值，然后這個卷會被掛載到容器的 /cache 路徑。

容器的啟動參數是一個shell命令，它會在容器的 cache 目錄下創建1個名為 k8s.txt 的文件。容器創建后稍等一會，使用下面的命令獲取這個文件的內容：

$ kubectl exec pod-vol-empty-dir -- cat /cache/k8s.txt
k8s

可以看到，文件內容正是容器啟動命令中寫入的?k8s 字符。

K8S會在當前的Node自動創建一個目錄來實際承載這個卷，目錄的位置在Node的? /var/lib/kubelet/pods?路徑下。要查看這個目錄中的內容，需要先找到Pod Id和對應的Node，然后登錄到這個Node，就能找到這個目錄了。minikube中的查找方法如下圖所示：

注意用顏色框圈出來的內容，不同的Pod對應的數據不同。查找Pod Id的命令：

kubectl get pods -o custom-columns=PodName:.metadata.name,PodUID:.metadata.uid,PodNode:.spec.nodeName

如果不對 emptyDir Volume 做一些限制，也是有很大的風險會使用過多的磁盤空間。

存儲的限制方法

通過上文的介紹，我們可以看到，除了容器鏡像是系統機制控制的，其它的內容都跟應用程序有關。

應用程序完全可以控制自己使用的存儲空間，比如少寫點日志，將數據保存到遠程存儲，及時刪除使用完畢的臨時數據，使用LRU等算法控制存儲空間的使用量，等等。不過完全依賴開發者的自覺也不是一件很可靠的事，萬一有BUG呢？所以K8S也提供了一些機制來限制容器可以使用的存儲空間。

K8S的GC

K8S有一套自己的GC控制邏輯，它可以清除不再使用的鏡像和容器。這里我們重點看下對鏡像的清理。

這個清理工作是 kubelet 執行的，它有三個參數來控制如何執行清理：

• imageMinimumGCAge 未使用鏡像進行垃圾回收時，其存在的時間要大于這個閾值，默認是2分鐘。
• imageGCHighThresholdPercent 鏡像占用的磁盤空間比例超過這個閾值時，啟動垃圾回收。默認85。
• ImageGCLowThresholdPercent 鏡像占用的磁盤空間比例低于這個閾值時，停止垃圾回收。默認80。

可以根據自己的鏡像大小和數量的水平來更改這幾個閾值。

日志總量限制

K8S對寫入標準輸出的日志有一個輪轉機制，默認情況下每個容器的日志文件最多可以有5個，每個文件最大允許10Mi，如此每個容器最多保留最新的50Mi日志，再加上Node也可以對Pod數量進行限制，日志使用的本地存儲空間就變得可控了。這個控制也是 kubelet 來執行的，有兩個參數：

• containerLogMaxSize 單個日志文件的最大尺寸，默認為10Mi。
• containerLogMaxFiles 每個容器的日志文件上限，默認為5。

以上文的 pod-log-stdout 這個Pod為例，它的日志輸出量很多就會超過10Mi，我們可以實際驗證下。

不過如果沒有意外，意外將要發生了，K8S的限制不起作用。這是因為我們使用的容器運行時是docker，docker有自己的日志處理方式，這套機制可能過于封閉，K8S無法適配或者不愿意適配。可以更改docker deamon的配置來解決這個問題，在K8S Node中編輯這個文件? /etc/docker/daemon.json?（如果沒有則新建），增加關于日志的配置：

{
    "log-opts": {
        "max-size": "10m",
        "max-file": "5"
    }
}

然后重啟Node上的docker：systemctl restart docker。注意還需要重新創建這個Pod，因為這個配置只對新的容器生效。

在docker運行時下，容器日志實際上位于 /var/lib/docker/containers?中，先找到容器Id，然后就可以觀察到這些日志的變化了：

emptyDir Volume 限制

對于emptyDir類型的卷，可以設置 emptyDir.sizeLimit，比如設置為 100Mi。

apiVersion: v1
kind: Pod
metadata:
  name: pod-vol-empty-dir-limit
spec:
  containers:
  - name: count
    image: busybox:latest
    args: [/bin/sh, -c,
            'while true; do dd if=/dev/zero of=/cache/$(date "+%s").out count=1 bs=5MB; sleep 1; done']
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 100Mi

稍等幾分鐘，然后查詢Pod的事件：

可以看到 kubelet 發現 emptyDir volume 超出了100Mi的限制，然后就把 Pod 關掉了。

臨時數據的總量限制

對于所有類型的臨時性本地數據，包括 emptyDir 卷、容器可寫層、容器鏡像、日志等，K8S也提供了一個統一的存儲請求和限制的設置，如果使用的存儲空間超過限制就會將Pod從當前Node逐出，從而避免磁盤空間使用過多。

然后我們創建一個Pod，它會每秒寫1個5M的文件，同時使用 spec.containers[].resources.requests.limits 給存儲資源設置了一個限制，最大100Mi。

apiVersion: v1
kind: Pod
metadata:
  name: pod-ephemeral-storage-limit
spec:
  containers:
  - name: count
    image: busybox:latest
    args: [/bin/sh, -c,
            'while true; do dd if=/dev/zero of=$(date "+%s").out count=1 bs=5MB; sleep 1; done']
    resources:
      requests:
        ephemeral-storage: "50Mi"
      limits:
        ephemeral-storage: "100Mi"

稍等幾分鐘，然后查詢Pod的事件：

kubectl describe pod pod-ephemeral-storage-limit

可以看到 kubelet 發現Pod使用的本地臨時存儲空間超過了限制的100Mi，然后就把 Pod 關掉了。

通過這些存儲限制，基本上就可以說是萬無一失了。當然還要在節點預留足夠的本地存儲空間，可以根據Pod的數量和每個Pod最大可使用的空間進行計算，否則程序也會因為總是得不到所需的存儲空間而出現無法正常運行的問題。