近期遇到一個問題：某網元yaml中配置了nfs地址及掛載目錄，當nfs異常時，網元進程讀nfs掛載目錄超時卡住，導致線程佔滿，無法響應k8s心跳檢測，一段時間後，k8s重啓該網元pod，在終止pod時，由於nfs異常，umount卡住，導致pod一直處於Terminating狀態。
爲解決上述問題，需要實現如下兩點：
- nfs異常，讀目錄不掛住
- nfs異常，pod刪除不掛住
針對上述第一個疑難，研究nfs參數配置文件：/etc/nfsmount.conf，其中如下幾個參數引起我的注意：
# The number of times a request will be retired before
# generating a timeout
# Retrans=2
#
# The number of minutes that will retry mount
# Retry=2
#
# How to handle times out from servers (Hard is STRONGLY suggested)
# Hard=True
# Soft=False
# The amount of time, in tenths of a seconds, the client
# will wait for a response from the server before retransmitting
# the request.
# Timeo=600
網上對上述幾個參數的含義及配置值說明五花八門，因此我對這幾個參數進行了測試驗證，測試環境：一臺環境用於啓停NFS服務（命令：systemctl start/stop nfs-server.service），另外一臺設備做目錄掛載用：
（1）Retry=2，表示mount的超時時間，單位是分鐘，超過這個時間mount報失敗
關閉nfs，分別設置1分鐘和2分鐘進行測試mount；測試結果證明Retry含義確爲mount超時時間，單位分鐘。
（2）Soft=True，Soft方式掛載系統，若NFS請求超時，則客戶端向調用程序返回錯誤；如果使用Hard方式則客戶端一直重新請求直至成功。默認爲Hard。
默認Hard模式，是讀和umount掛住的主要原因，爲解決上述問題，需要改爲Soft模式。
（3）Timeo=10，客戶端請求超時時間（以十分之一秒爲單位）
這個配置，很多文章都說是客戶端請求重傳前等待時間，含義不好理解，其實就是一次請求的超時時間；單位有的說是秒，有的說是0.1秒，有的說是0.7秒，測試發現單位是0.1秒。
timeo分別設置10和20進行測試，重試次數retrans都是2（加上本身的1次，總次數爲3次），測試結果如下，總超時時間分別是3秒和6秒，符合預期，單位是0.1秒：
（4）Retrans=2，請求重試次數
經測試單位是測試，非時間，測試結果如下：
經過上述研究，進行如下配置修改後，讀取不再超時，pod也能正常刪除，不再掛住了。
ps.
1、若pod一直處於Terminating，也可以強制刪除：kubectl delete pod foo --grace-period=0 --force
2、可使用umount -l -f 執行強制umount操作
3、也可以先建立本地目錄，讓本地目錄mount nfs設備，再將本地目錄通過hostpath掛載到容器中，這樣不管參數是否設置，pod均能刪除，但是如果不設置參數，讀取還會掛住