1. 故障現象

環境在跑自動化測試時列印 error: [ ERROR ] Opening output file '/output.xml' failed: Read-only file system。

2 測試流程

通過 helm chart 部署 pod，在 pod 的指定 container 內執行 robot case。其中，執行的 robot case 需要讀寫檔案。

3. 故障分析

• [ ] 使用者許可權問題

列印 Read-only file system，排查是不是執行 container 的 id 不是 root，導致無法訪問指定目錄。
檢查 helm chart 及 container id ，發現使用者和使用者組均是 root。

kubernetes 平臺上 container 和 host 未做使用者隔離，container 執行的使用者即是 host 上的 root。排除了這點還有什麼限制呢？

• [x] scc

除了 container 配置自身的限制還有 kubernetes 叢集級別的 scc 限制 container 對 host 上檔案系統的訪問。
之所以說是 host 上檔案系統是因為，這裡用到了聯合檔案系統，container 訪問的檔案是對映到 host 上的。

檢視 scc 發現 container 的 serviceaccount 繫結的 scc 設定了 ReadOnlyFileSystem=true。那麼，應該是這裡限制了檔案系統只能是隻讀的。

修改 scc 的 ReadOnlyFileSystem 為 false：

kubectl edit scc <scc_name> -n <project> 

注意繫結到該 scc 的 pod 並未生效，由於 pod 受 deployment controller 控制，這裡直接 delete pod 觸發重啟，重啟之後手動模擬自動化測試，建立檔案 output.xml 成功。

一波未平，一波又起。以為搞定了，重新執行 jenkins 自動化測試發現 pull image 報錯：

rpc error: code = Unknown desc = reading manifest latest in image-registry.openshift-image-registry.svc:5000...
unauthorized: authentication required
 

提示很明顯更改了 ReadOnlyFileSystem 引數，scc 下的 serviceaccount 均有在檔案系統的可讀可寫許可權，這樣的許可權對於新 pull 的 image 也是適用的，那麼在對 pull 的 image 進行更改時也是需要認證的，認證之後才能對 image 進行更改，這是合理的。

同時，這也解釋了為什麼 ReadOnlyFileSystem false 時，測試 case 可以 pull image，而不用認證。因為沒有許可權對 image 進行改動啊。

既然知道了原因解決起來也不難了，給 serviceaccount 新增相應的 pull image 的 role 使得 serviceaccount 可以 pull image：

oc policy add-role-to-user system:image-puller system:serviceaccount:<project>:<serviceaccount_name> -n <project>

重新執行 jenkins 測試，執行成功。