2. 程式人生 > >Kubernetes 主節點宕機恢復記錄 MountVolume.SetUp failed for volume "kube-dns-config"

Kubernetes 主節點宕機恢復記錄 MountVolume.SetUp failed for volume "kube-dns-config"

阿新 • • 發佈：2019-01-01

       今天早上，發現原來執行的好好的Kubernetes叢集不能正常工作了，dashboard介面打不開，主節點上 docker ps 不顯示任何執行中容器，重啟 kubelet 後，短暫恢復，之後再次陷入不可用狀態，經過反覆重啟觀察，發現是etcd不斷重啟，最後失敗，導致其它元件相繼失敗。

        etcd 日誌如下：

2018-02-06 02:25:24.564269 I | etcdmain: etcd Version: 3.0.17
2018-02-06 02:25:24.564531 I | etcdmain: Git SHA: cc198e2
2018-02-06 02:25:24.564544 I | etcdmain: Go Version: go1.6.4
2018-02-06 02:25:24.564554 I | etcdmain: Go OS/Arch: linux/amd64
2018-02-06 02:25:24.564563 I | etcdmain: setting maximum number of CPUs to 8, total number of available CPUs is 8
2018-02-06 02:25:24.564636 N | etcdmain: the server is already initialized as member before, starting as etcd member...
2018-02-06 02:25:24.565021 I | etcdmain: listening for peers on http://localhost:2380
2018-02-06 02:25:24.565114 I | etcdmain: listening for client requests on 127.0.0.1:2379
2018-02-06 02:25:24.568360 I | etcdserver: recovered store from snapshot at index 5900621
2018-02-06 02:25:24.568399 I | etcdserver: name = default
2018-02-06 02:25:24.568406 I | etcdserver: data dir = /var/lib/etcd
2018-02-06 02:25:24.568413 I | etcdserver: member dir = /var/lib/etcd/member
2018-02-06 02:25:24.568418 I | etcdserver: heartbeat = 100ms
2018-02-06 02:25:24.568423 I | etcdserver: election = 1000ms
2018-02-06 02:25:24.568428 I | etcdserver: snapshot count = 10000
2018-02-06 02:25:24.568464 I | etcdserver: advertise client URLs = http://127.0.0.1:2379
2018-02-06 02:25:24.760641 I | etcdserver: restarting member 8e9e05c52164694d in cluster cdf818194e3a8c32 at commit index 5904480
2018-02-06 02:25:24.760850 I | raft: 8e9e05c52164694d became follower at term 12
2018-02-06 02:25:24.760904 I | raft: newRaft 8e9e05c52164694d [peers: [8e9e05c52164694d], term: 12, commit: 5904480, applied: 5900621, 

lastindex: 5904480, lastterm: 12]
2018-02-06 02:25:24.761062 I | api: enabled capabilities for version 3.0
2018-02-06 02:25:24.761111 I | membership: added member 8e9e05c52164694d [http://localhost:2380] to cluster cdf818194e3a8c32 from store
2018-02-06 02:25:24.761125 I | membership: set the cluster version to 3.0 from store
2018-02-06 02:25:24.829180 I | mvcc: restore compact to 2314830
2018-02-06 02:25:24.975979 I | etcdserver: starting server... [version: 3.0.17, cluster version: 3.0]
2018-02-06 02:25:25.661519 I | raft: 8e9e05c52164694d is starting a new election at term 12
2018-02-06 02:25:25.661581 I | raft: 8e9e05c52164694d became candidate at term 13
2018-02-06 02:25:25.661596 I | raft: 8e9e05c52164694d received vote from 8e9e05c52164694d at term 13
2018-02-06 02:25:25.661620 I | raft: 8e9e05c52164694d became leader at term 13
2018-02-06 02:25:25.661645 I | raft: raft.node: 8e9e05c52164694d elected leader 8e9e05c52164694d at term 13
2018-02-06 02:25:25.663336 I | etcdserver: published {Name:default ClientURLs:[http://127.0.0.1:2379]} to cluster cdf818194e3a8c32
2018-02-06 02:25:25.663379 I | etcdmain: ready to serve client requests
2018-02-06 02:25:25.663797 N | etcdmain: serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!
2018-02-06 02:25:37.403730 W | etcdserver: apply entries took too long [25.315155ms for 1 entries]
2018-02-06 02:25:37.403752 W | etcdserver: avoid queries with large range/delete range!
2018-02-06 02:25:49.930163 N | osutil: received terminated signal, shutting down...

        查詢好多資料，大多說是 etcd 版本問題，可是原來是好好的呀！！！明顯不是這個問題。

       費了半天勁，最終排查出的問題是：主節點機器磁碟空間不夠了，/ 目錄使用率達到了92%

       刪除部分檔案後，磁碟使用率降到70%，重新啟動 kubelet，發現etcd不再重啟退出了，但是 kube-dns 一直啟動不起來

       提示錯誤：

Events:
  FirstSeen	LastSeen	Count	From				SubObjectPath	Type		Reason			Message
  ---------	--------	-----	----				-------------	--------	------			-------
  1h		35m		36	kubelet, inm-bj-vip-ms04			Warning		FailedMount		Unable to mount volumes for pod "kube-dns-2425271678-bgzzp_kube-system(d7381d67-fb52-11e7-a2f6-0050568b6632)": timeout expired waiting for volumes to attach/mount for pod "kube-system"/"kube-dns-2425271678-bgzzp". list of unattached/unmounted volumes=[kube-dns-config]
  1h		35m		36	kubelet, inm-bj-vip-ms04			Warning		FailedSync		Error syncing pod
  1h		34m		48	kubelet, inm-bj-vip-ms04			Warning		FailedMount		MountVolume.SetUp failed for volume "kube-dns-config" : stat /var/lib/kubelet/pods/d7381d67-fb52-11e7-a2f6-0050568b6632/volumes/kubernetes.io~configmap/kube-dns-config: no such file or directory
  30m		30m		1	kubelet, inm-bj-vip-ms04			Normal		SuccessfulMountVolume	MountVolume.SetUp succeeded for volume "kube-dns-token-3hdnc" 
  28m		10m		9	kubelet, inm-bj-vip-ms04			Warning		FailedMount		Unable to mount volumes for pod "kube-dns-2425271678-bgzzp_kube-system(d7381d67-fb52-11e7-a2f6-0050568b6632)": timeout expired waiting for volumes to attach/mount for pod "kube-system"/"kube-dns-2425271678-bgzzp". list of unattached/unmounted volumes=[kube-dns-config]
  28m		10m		9	kubelet, inm-bj-vip-ms04			Warning		FailedSync		Error syncing pod
  30m		10m		18	kubelet, inm-bj-vip-ms04			Warning		FailedMount		MountVolume.SetUp failed for volume "kube-dns-config" : stat /var/lib/kubelet/pods/d7381d67-fb52-11e7-a2f6-0050568b6632/volumes/kubernetes.io~configmap/kube-dns-config: no such file or directory
  10m		10m		1	kubelet, inm-bj-vip-ms04			Normal		SuccessfulMountVolume	MountVolume.SetUp succeeded for volume "kube-dns-token-3hdnc" 
  10m		9m		6	kubelet, inm-bj-vip-ms04			Warning		FailedMount		MountVolume.SetUp failed for volume "kube-dns-config" : stat /var/lib/kubelet/pods/d7381d67-fb52-11e7-a2f6-0050568b6632/volumes/kubernetes.io~configmap/kube-dns-config: no such file or directory
  9m		9m		1	kubelet, inm-bj-vip-ms04			Normal		SuccessfulMountVolume	MountVolume.SetUp succeeded for volume "kube-dns-token-3hdnc" 
  7m		5m		2	kubelet, inm-bj-vip-ms04			Warning		FailedMount		Unable to mount volumes for pod "kube-dns-2425271678-bgzzp_kube-system(d7381d67-fb52-11e7-a2f6-0050568b6632)": timeout expired waiting for volumes to attach/mount for pod "kube-system"/"kube-dns-2425271678-bgzzp". list of unattached/unmounted volumes=[kube-dns-config]
  7m		5m		2	kubelet, inm-bj-vip-ms04			Warning		FailedSync		Error syncing pod
  9m		3m		11	kubelet, inm-bj-vip-ms04			Warning		FailedMount		MountVolume.SetUp failed for volume "kube-dns-config" : stat /var/lib/kubelet/pods/d7381d67-fb52-11e7-a2f6-0050568b6632/volumes/kubernetes.io~configmap/kube-dns-config: no such file or directory
  1m		1m		1	kubelet, inm-bj-vip-ms04			Normal		SuccessfulMountVolume	MountVolume.SetUp succeeded for volume "kube-dns-token-3hdnc" 
  1m		50s		8	kubelet, inm-bj-vip-ms04			Warning		FailedMount		MountVolume.SetUp failed for volume "kube-dns-config" : stat /var/lib/kubelet/pods/d7381d67-fb52-11e7-a2f6-0050568b6632/volumes/kubernetes.io~configmap/kube-dns-config: no such file or directory


          感覺是掛載卷問題，嘗試重新安裝網路都沒有效果  ^~^|||

  最後，發大招，關閉 kubelet 和 docker 後，刪除所有容器， 進入 /var/lib/kubelet/pods ，直接把 kube-dns 的pod 刪掉（pod的名字在錯誤日誌裡有，這裡就是d7381d67-fb52-11e7-a2f6-0050568b6632），再重啟docker和 kubelet，dns服務恢復！！！

        末尾附上 dns 恢復依次執行的命令：

# systemctl stop kubelet
# docker kill $(docker ps -a -q)
# docker rm $(docker ps -a -q)
# systemctl stop docker
# cd /var/lib/kubelet/pods
# mv d7381d67-fb52-11e7-a2f6-0050568b6632 /tmp
# systemctl start docker
# systemctl start kubelet


相關推薦

Kubernetes 主節點宕機恢復記錄 MountVolume.SetUp failed for volume "kube-dns-config"

       今天早上，發現原來執行的好好的Kubernetes叢集不能正常工作了，dashboard介面打不開，主節點上 docker ps 不顯示任何執行中容器，重啟 kubelet 後，短暫恢復，之後再次陷入不可用狀態，經過反覆重啟觀察，發現是etcd不斷重啟，最後失

Redis 中哨兵sentinel 機制、從宕機及恢復、主庫宕機及恢復解決方案

目錄 什麼是哨兵 原理 環境 設定哨兵 從宕機及恢復 主宕機及恢復 配置多個哨兵 1、什麼是哨兵 哨兵是對Redis的系統的執行情況的監控，它是一個獨立程序，功能有二個： 監控主資料庫和從資料庫是否執行正常； 主資料出現故障後

Kubernetes叢集的主節點備份與恢復

通常安裝模式下（如使用kubeadm）的Kubernetes叢集，主節點（Master）只有一個，而且叢集資料儲存服務etcd也只運行了一個例項。如果遇到極端情況（如整機故障、主硬碟損壞、資料誤刪除等）導致master節點無法訪問，則整個叢集都將無法訪問或出現異常現象。所以master節點機器效能要求不一定很

MGR 多主模式節點宕機重啟

1，初始主節點宕機 當mysql服務程序還在: 執行如下命名  mysql>  select * from performance_schema.replication_group_members; +---------------------------+--------

cluster-node-timeout redis節點宕機被發現的時間 從節點接替主節點的時間

cluster-node-timeout  redis節點宕機被發現的時間  也是主節點服務宕機 從節點頂替上來需要的時間把cluster-node-timeout引數設定一個較小的值，比如6000（6

mahout demo——本質上是基於Hadoop的分步式算法實現，比如多節點的數據合並，數據排序，網路通信的效率，節點宕機重算，數據分步式存儲

fin urn [] return uid content 3.0 stock blank 摘自：http://blog.fens.me/mahout-recommendation-api/ 測試程序：RecommenderTest.java 測試數據集：item.csv

redis集群節點宕機

div 強一致 clust info post 超過半數 mage 在一起 情況下 redis集群是有很多個redis一起工作，那麽就需要這個集群不是那麽容易掛掉，所以呢，理論上就應該給集群中的每個節點至少一個備用的redis服務。這個備用的redis稱為從節點（slave

（轉）計算節點宕機了怎麽辦？

-shared schedule ins com put 宕機 opensta 請求 TP 比如硬件故障或者斷電造成整臺計算節點無法工作，該節點上運行的 instance 如何恢復呢？ 用 Shelve 或者 Migrate 可不可以？ 很不幸，這兩個操作都要求 insta

redis主庫宕機後重啟，主庫和從庫的資料丟失

redis主庫宕機後重啟，主庫和從庫的資料丟失   解決方法： 假如主庫127.0.0.1 6379，從庫127.0.0.1 6380 1.在從資料庫中執行SLAVEOF NO ONE命令，斷開主從關係並且提升為主庫繼續服務； 2

Oracle RAC一節點宕機導致另一節點HANG的問題分析

        正所謂“福無雙至，禍不單行”，生產上有套2節點Oracle 11.2.0.4資料庫，其中2節點因硬體故障宕機，1節點去HANG住了。我們一起來分析這起故障。     &

存在單點故障的namenode宕機恢復測試

前提：如果namenode沒有做HA，那麼至少應該啟用secondarynamenode，以便namenode宕機之後手動恢復資料 實驗環境：3個節點（cenos 6.10） 測試前資料：    1.為了確保資料儘可能恢復，手動checkpoint一下 [[email

redis叢集節點宕機

https://www.cnblogs.com/dadonggg/p/8628735.html   redis叢集是有很多個redis一起工作，那麼就需要這個叢集不是那麼容易掛掉，所以呢，理論上就應該給叢集中的每個節點至少一個備用的redis服務。這個備用的redis稱為從節點（slave）。

Kubernetes Master節點災備恢復操作指南---升級版

ado gin store points true meta cli 3rd -- 本文檔簡述了Kubernetes主節點災備恢復的相關步驟，供在發生k8s master崩潰時操作。 就算是在k8s裏部署了etcd群集, 主節點控制組件的高可用節點，災備恢復也是必須要實現

redis主從結構，主庫宕機

前提：現在有主從結構，主庫沒有配置持久化，從庫配置AOF。(主庫用來備份和寫服務，從庫用來提供讀服務) 非常危險的動作：重新啟動主庫。 要知道這樣一來，最壞情況資料將全部丟失。因為主庫沒有配置持久化，所以主庫的data目錄只有從庫連線主庫請求resync的時候做快照留下來的dump.rdb檔

Redis Cluster遷移目標節點宕機下填坑

問題背景 應@冬洪兄邀請，讓我把最近在處理Redis Cluster中遇到的坑分享下，由於個人時間問題，大致整理了一個比較大，比較坑的問題，它可能會導致叢集部分slot不可用，甚至需要重建叢集。如果對redis cluster不瞭解的可以檢視redis原理分享。

redis叢集實現(六) 容災與宕機恢復

實現叢集，一個重要的保證就是高可用性，要在各種軟體和硬體的故障情況下仍然能夠提供服務。一般來說有兩種解決思路，一種是每一個節點互相之間都會進行資料互動以及監控，出現故障的時候，各個節點都可以做協調任務。另一種就是增加一個協調元件來對叢集進行實時監控以及故障處理。現在使用比較

計算節點宕機後，vm的遷移方法

當計算節點異常斷電或者發生故障後，導致計算節點無法正常工作，這時該計算節點上面的vm如何遷移到別的可用計算節點上呢？ 由於宕機的計算節點上面的nova-compute服務已經down了，所以shelve和migrate操作無法執行，會報錯。 nova中提供了Evacuate

[2015.6.21]阿里雲香港節點宕機，業務中斷13小時

6月21日，阿里雲香港節點9點30分左右突然全線崩潰，截止當天晚上22點左右逐漸恢復，歷時13小時，並且還不是全面恢復。 甚至有部分使用者出現數據丟失，微博網友@routerpipe提出，“網路恢復了，但資料盤資料損毀。” 公有云出現故障宕機並不少見，即使AWS也曾出現過宕機事件，但此次阿里雲香港節

Utorrent宕機恢復種子下載

宕機儲存Utorrent種子不被刪除方法： 保了200多個種，宕機了重啟就沒有什麼下載的種子的記錄，要一個個匯入實在奔潰。 從被刪除的resume.dat恢復很有壓力。 簡單的方法： 在還沒有宕

MySQL主從複製之主庫宕機處理

主庫宕機  Master DOWN機-企業場景一主多從宕機從庫切換主繼續和從同步過程詳解登陸從庫，show processlist;檢視兩個執行緒的更新狀態；檢視所有從庫中，檢視/application/mysql-5.6.20/data/mysql.info確保更新完畢，看