針對Enterprise PKS環境的K8s Cluster Node硬碟空間不足測試及解法

這篇主要是測試Enterprise PKS佈出來的Kubernetes Node 上面的硬碟滿了會造成什麼影響以及要如何解決。其實這個問題應該跟一般Kubernetes環境差不多,只是目前有一些case緣故還是需要在Enterprise PKS環境下測試一下。因此特別針對這部分做測試。

Kubernetes Node上的disk種類

PCF Ops Manager Web GUI > Enterprise PKS Tile > Plan裡,可以設定Enterprise PKS部署出來的Kubernetes Cluster資源,其中有一些欄位是設定node VM的硬碟資訊:

預設BOSH產生出來的node上面會有三顆虛擬硬碟。這裡我們用sda,sdb,sdc來代稱。

  1. sda: Node System Disk,掛載目錄為/,為node VM作業系統的根目錄,這個大小目前是不能設定的,預設3GB。
  2. sdb: Agent Package Disk,掛載目錄為/var/vcap/data...,為存放pks-system以及bosh agent這些必要套件的位置,這個就是PCF Ops Manager上設定的VM Type裡面的disk大小。
  3. sdc: Persistent Disk,掛載目錄/var/vcap/store/...,這個disk在master中是用來存etcd的,因此只要disk沒有掛掉,不管BOSH怎麼修復master,etcd資料都不會消失。如果是worker的話,這個disk是用來存docker container 以及docker imagesdc大小是根據PCF Ops Manager裡面設定的Persistent Disk Type來配置。

當node發生錯誤而啟動BOSH自動修復機制時,只有sdc資料會被保留,其他的都會被清空還原成初始狀態。

上面disk名稱只是方便識別,並非官方取名。

由於disk裡的資料可能會隨著時間成長,例如:log, docker image/container或是一些暫存檔等等。為了確定清楚硬碟塞爆是否會影響Kubernetes服務,因此接下來會測試塞爆三種disk並觀察會發生的情況。

使用到的指令

建立任意大小的檔案

$ fallocate -l <檔案大小> <檔案名稱>

Example:
$ fallocate -l 50G test

查看目錄屬於哪顆disk、大小及使用率

$ df <目錄> -h

Example:
$ df /var/vcap/ -h

查看目錄或檔案大小

$ du -sh <檔案名稱/目錄>

Example:
$ du -sh /var/vcap/

查看docker根目錄

$ docker system info

查看docker image/container數量/大小資訊

$ docker system df

Node System Disk(sda)

測試環境:

  • 1台master, 2台worker

測試結果

  1. Container不會掛掉,正常運行。
  2. BOSH ssh到worker的時候會顯示no space left on device錯誤。
  3. 修復方式
    • 關閉壞掉的node讓BOSH自動修復,產生新的node VM。
    • 如果還能登入node,可以清掉一些資料釋出Node System Disk(sda)空間。

測試流程

  1. 使用kubectl建立deployment到cluster上。

  2. 連到worker VM裡並塞滿sda空間

    # SSH
    bosh -d <deployment> ssh <worker>

    # 切換到/dev/sda1掛載目錄
    cd /var

    # 塞滿空間
    fallocate -l 10G test
  3. Container依然正常運行無異常,但是當執行bosh ssh時出現下圖空間不足錯誤。

Agent Packages Disk(sdb)

測試環境:

  • 1台master, 2台worker

測試結果

  1. Node會掛掉,無法負荷原本的container,因此原本上面跑的container都會變成Evicted狀態。(可能會造成服務中斷)
  2. 如果有額外的node可用,master會佈新的container到別台node上。如果沒有,所有container都會變成Pending狀態。
  3. 修復方式:
    • 清出Agent Packages Disk空間,然後執行monit restart all,這樣node就會恢復正常。

測試流程

  1. 使用kubectl建立deployment到cluster上。

  2. 連到worker VM(b685858b...)裡並塞滿sdb空間

    # SSH
    bosh -d <deployment> ssh <worker>

    # 切換到/dev/sdb2掛載目錄
    cd /var/vcap/data/

    # 塞滿空間
    fallocate -l 10G test
  3. 使用kubectl查看pods狀態,可以看到剛剛被塞爆的worker(b685858b...)上的pods都進入Evicted狀態,且master在其他node產生新的pods。

  4. 使用kubectl describe pods <pod name>查看Evicted pod,可以看到是因為node空間不足導致的。

Persistent Disk(sdc)

測試環境:

  • 1台master, 2台worker

測試結果

與Agent Packages Disk(sdb)結果相同

  1. Node會掛掉,無法負荷原本的container,因此原本上面跑的container都會變成Evicted狀態。(可能會造成服務中斷)
  2. 如果有額外的node可用,master會佈新的container到別台node上。如果沒有,所有container都會變成Pending狀態。
  3. 修復方式:
    • 清出persistent disk空間,然後在node上執行monit restart all指令,這樣node就會恢復正常。

測試流程

  1. 使用kubectl建立deployment到cluster上。

  1. 連到worker VM(3f28d443...)裡並塞滿sdb空間

    # SSH
    bosh -d <deployment> ssh <worker>

    # 切換到/dev/sdc1掛載目錄
    cd /var/vcap/store/docker

    # 塞滿空間
    fallocate -l 50G test
  2. 使用kubectl查看pods狀態,可以看到剛剛被塞爆的worker(3f28d443...)上的pods都進入Evicted狀態,且master在其他node產生新的pods。

擴大Node Disk大小

看到上述測試可以得知disk如果滿了是有可能會影響服務,解決方法除了清掉不必要的檔案釋出空間之外,也可以選擇擴大原有的空間,但目前能擴大的只有sdb以及sdc

官方提供的擴大方式是到PCF Ops Manager去調原plan設定,例如把disk調大資源調多等等, 然後apply change的時候勾選upgrade all cluster, 這樣原有的cluster就會套用新的設定(cpu/memory/persistent disk…),但只能修改原plan數值, 無法修改成不同plan(例如從plan1改成plan2)。詳情可參考連結 ,另外此方法的缺點是要改的話,全部同樣使用該plan的cluster都會一併修改。

除了官方解法外,筆者我想到另外一種比較暴力的方法是直接在vCenter把node的硬碟擴大, 但是實際測試這種方式會導致BOSH那邊不同步引發錯誤,因此目前這是不可行的。

以下是兩種方法的測試流程:

PCF Ops Manager調整Plan設定

  1. 假設目前worker VM (91997fd5...) persistent disk已經被塞爆(預設50G),希望能擴大空間。

  1. PCF Ops Manager Web GUI > Enterprise PKS Tile > Plan將worker的persistent disk調整成75G。

  2. Apply Change

  3. 完成後連到worker VM(91997fd5...)去看,可以看到空間已經成功擴大。

  4. Pod也可以正常的部署在worker VM (91997fd5...)上了。

從vCenter強制調整Node Disk大小

注意這種方式會導致BOSH那邊不同步引發錯誤,因此目前此方法是不可行的,但還是將過程列出來供參考。

  1. 假設目前worker VM (3f28d443...) persistent disk已經被塞爆(預設50G),希望能擴大空間。

  2. 到vCenter上直接去將worker VM persistent disk調整為80G。

  3. 接下來為了避免BOSH將這台worker砍掉,因此要先關閉自動修復機制。

    $ bosh -d <deployment> update-resurrection  off

  4. 接下來將worker VM(3f28d443...)關機。

  5. 可以從bosh vms看到該台worker1 已經變成unresponsive agent狀態,但是BOSH不會將它砍掉。

  6. 接下來到vCenter > Datastore > pcf_disks找到worker VM(3f28d443...)的persistent disk,並擴大它的空間。

    先找出worker1對應的persistent disk(Disk CIDs)

    $ bosh instances -i

    vCenter > Datastore > pcf_disks找到對應的disk,可以發現disk還是50G。

    點擊inflate來擴大硬碟。(這個動作會跑一段時間)

    好了之後可以看到disk已經變80G。

  7. 接下來將worker1開機,但是開好之後還是unresponsive agent

  8. 不得已情況下只好將自動修復開起來,看看BOSH會不會砍掉建立新的worker,然後將persistent disk掛載上去。

    $ bosh -d <deployment> update-resurrection  on

  9. BOSH開始修復,但是修復到最後失敗,硬碟無法掛載,可能是因為disk裡的partition有變動到。到這裡就卡住了,BOSH就無法修復了,也許是某一步做錯或是BOSH本身不支援這種改法,後續如果有成功再來更新此篇,目前暫不將此方法列入解法。

Summary

測試下來的感覺好像跟是不是Enterprise PKS環境沒啥關係xD。不過經過此測試也比較清楚Enterprise PKS運行機制以及針對這種情況的處理方式,但對目前的Enterprise PKS來說,擴大硬碟的機制還是很不彈性,這有可能是受到BOSH的限制,希望未來能夠再加強這部分。

Reference

  1. PKS Plan Resizing - https://community.pivotal.io/s/question/0D50e00005j9wr2/pks-plan-resizing
  2. Changing the thick or thin provisioning of a virtual disk - https://kb.vmware.com/s/article/2014832

文章內容的轉載、重製、發佈,請註明出處: https://pohsienshih.github.io