在Kubernetes中手動恢復(fù)Rook存儲集群
本文轉(zhuǎn)載自微信公眾號「新鈦云服」，作者祝祥 翻譯。轉(zhuǎn)載本文請聯(lián)系新鈦云服公眾號。
Rook介紹
Rook將文件、數(shù)據(jù)塊和對象存儲系統(tǒng)引入到Kubernetes集群，與其他正在使用存儲的應(yīng)用程序和服務(wù)一起無縫運行。
通過這種方式，云原生集群可以在公有云和本地部署中自給自足并且具備可移植性。該項目的開發(fā)目的是使企業(yè)能夠通過動態(tài)應(yīng)用編排，為在本地和公有云環(huán)境中運行的分布式存儲系統(tǒng)實現(xiàn)數(shù)據(jù)中心現(xiàn)代化。
Rook 將存儲軟件轉(zhuǎn)變成自我管理、自我擴展和自我修復(fù)的存儲服務(wù)，通過自動化部署、啟動、配置、供應(yīng)、擴展、升級、遷移、災(zāi)難恢復(fù)、監(jiān)控和資源管理來實現(xiàn)。Rook 底層使用云原生容器管理、調(diào)度和編排平臺提供的能力來提供這些功能。
Rook由Operator和Cluster兩部分組成：
Operator：由一些CRD和一個All in one鏡像構(gòu)成，包含包含啟動和監(jiān)控存儲系統(tǒng)的所有功能。
Cluster：負責(zé)創(chuàng)建CRD對象，指定相關(guān)參數(shù)，包括ceph鏡像、元數(shù)據(jù)持久化位置、磁盤位置、dashboard等等…
Rook使Kubernetes集群中的存儲工作變得輕松了許多。但是，這種簡單性同時也帶來了一些復(fù)雜性。我們希望本文能幫助您避免其中的一些復(fù)雜性，從而使它們簡單化。
為了讓本文更加有趣，讓我們假設(shè)我們剛剛遇到了集群的一個問題……
故障場景
想象一下，您已經(jīng)在K8s集群中配置并啟動了Rook。當前的所有任務(wù)操作都很正常，然后在某些時候出現(xiàn)了以下狀況：
- 新的Pod無法從Ceph掛載RBD鏡像;
- 諸如lsblk和df之類的命令在Kubernetes節(jié)點上不起作用。這表明掛載在節(jié)點上的RBD鏡像出了點問題。您無法讀取它們，這意味著Ceph Mon不可用。
- Ceph Mon和OSD/MGR Pod都無法在集群中運行。
現(xiàn)在是時候回答這個問題了，rook-ceph-operator Pod是什么時候開始啟動的?事實證明，這是最近才發(fā)生的。為什么?菜鳥運維人員可能會突然決定創(chuàng)建一個新的集群!那么，我們又該如何還原舊群集及其數(shù)據(jù)?
讓我們從一個更長更有趣的地方開始，一步一步地研究Rook的內(nèi)部機制并手動恢復(fù)其組件。顯然，有一種更簡短、更恰當?shù)姆椒ǎ菏褂脗浞?。如您所知，有兩種類型的管理員：一種是還沒有使用備份的管理員，另一種是已經(jīng)痛苦地學(xué)會始終使用備份的管理員(我們稍后再討論)。
Rook的手工恢復(fù)歷程
恢復(fù)Ceph Monitor節(jié)點
首先，我們必須檢查ConfigMap的列表：rook-ceph-config和rook-config-override。它們是在部署集群成功后創(chuàng)建的。
注意：在新版本的Rook中，ConfigMaps不再是部署群集成功的唯一標志。
為了繼續(xù)下去，我們必須對所有安裝了RBD鏡像(ls/dev/RBD*)的服務(wù)器進行硬重啟。您可以使用sysrq。此步驟對于卸載所有已掛載的RBD鏡像是必須的，因為在這種情況下，常規(guī)重新啟動將不起作用(系統(tǒng)無法正常的卸載鏡像)。
如您所知，Ceph Monitor守護程序的正常運行是所有Ceph集群的先決條件。下面，讓我們來確認一下它。
Rook將以下組件安裝到Monitor的Pod中：
- Volumes:
- rook-ceph-config:
- Type: ConfigMap (a volume populated by a ConfigMap)
- Name: rook-ceph-config
- rook-ceph-mons-keyring:
- Type: Secret (a volume populated by a Secret)
- SecretName: rook-ceph-mons-keyring
- rook-ceph-log:
- Type: HostPath (bare host directory volume)
- Path: /var/lib/rook/kube-rook/log
- ceph-daemon-data:
- Type: HostPath (bare host directory volume)
- Path: /var/lib/rook/mon-a/data
- Mounts:
- /etc/ceph from rook-ceph-config (ro)
- /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
- /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
- /var/log/ceph from rook-ceph-log (rw)
讓我們仔細看看這個rook-ceph-mons-keyring secret的內(nèi)容：
- kind: Secret
- data:
- keyring: LongBase64EncodedString=
解碼后，我們將獲得具有管理員和Ceph Monitor權(quán)限的常規(guī)密鑰keyring：
- [mon.]
- key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
- caps mon = "allow *"
- [client.admin]
- key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
- caps mds = "allow *"
- caps mon = "allow *"
- caps osd = "allow *"
- caps mgr = "allow *"
現(xiàn)在讓我們分析rook-ceph-admin-keyring secret的內(nèi)容：
- kind: Secret
- data:
- keyring: anotherBase64EncodedString=
我們發(fā)現(xiàn)了啥?
- [client.admin]
- key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
- caps mds = "allow *"
- caps mon = "allow *"
- caps osd = "allow *"
- caps mgr = "allow *"
繼續(xù)查找……例如，以下的這個rook-ceph-mgr-a-keyring secret：
- [mgr.a]
- key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
- caps mon = "allow *"
- caps mds = "allow *"
- caps osd = "allow *"
最終，我們在rook-ceph-monConfigMap中發(fā)現(xiàn)了更多secret：
- kind: Secret
- data:
- admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
- cluster-name: a3ViZS1yb29r
- fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
- mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
它包含原始的keyrings列表，并且是上述所有keyrings的來源。
如你所知，Rook存儲在兩個不同的地方存儲這個數(shù)據(jù)。因此，讓我們看一下主機目錄中的keyring，這些keyring已安裝到包含Ceph Monitor和OSD的Pod中。為此，我們必須在/var/lib/rook/mon-a/data/keyring節(jié)點上找到相應(yīng)的目錄并檢查其內(nèi)容：
- # cat /var/lib/rook/mon-a/data/keyring
- [mon.]
- key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
- caps mon = "allow *"
這里的secret不同于ConfigMap中的secret。
管理員keyring又是怎么的呢?它也是存在的：
- # cat /var/lib/rook/kube-rook/client.admin.keyring
- [client.admin]
- key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx=
- caps mds = "allow *"
- caps mon = "allow *"
- caps osd = "allow *"
- caps mgr = "allow *"
這也是當前問題所在。當發(fā)生了故障時：一切看起來都像是在重新創(chuàng)建集群，而實際上卻沒有。
顯然，secret包含新的keyring，并且與我們的舊群集不匹配。這就是為什么我們必須：
- 使用/var/lib/rook/mon-a/data/keyring文件(或備份)中的Ceph Monitorkeyring;
- 更換rook-ceph-mons-keyring secret中的keyring;
- 在rook-ceph-monConfigMap中指定admin和monitorkeyring;
- 刪除Ceph Monitor的Pod。
在短暫的等待之后，Ceph Monitor再次啟動并運行。這是一個比較好的開始!
還原OSD
現(xiàn)在我們需要進入rook-operatorPod。執(zhí)行ceph mon dump后顯示所有Ceph Monitor均已就位，ceph -s表示它們已達到法定人數(shù)。但是，如果我們查看OSD Tree(ceph osd tree)，則會發(fā)現(xiàn)一些奇怪的現(xiàn)象：OSD開始出現(xiàn)，但它們?yōu)榭??？磥砦覀儽仨氁阅撤N方式還原它們。但是如何做?
同時，在我們的ConfigMaps中，我們終于得到了我們所需要的rook-ceph-config，rook-config-override(以及其他比如名稱為rook-ceph osd-$nodename-config的ConfigMaps)：
- kind: ConfigMap
- data:
- osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'
如上，我們可以看到，osd掛載目錄與osd id都已經(jīng)混亂!
讓我們將operator Pod的數(shù)量縮小到零，刪除OSD容器生成的Deployment文件，并修復(fù)這些ConfigMap。但是，我們從何處獲得節(jié)點之間OSD分布的正確映射關(guān)系?
- 如果我們深入研究節(jié)點上的/mnt/osd[1–2]目錄，也許，在那里可以找到一些東西。
- 在/mnt/osd1中有兩個子目錄，它們是osd0和osd16。第二個子文件夾與ConfigMap(16)中定義的子文件夾相同。
- 查看它們的大小，我們看到osd0比osd16更大。
我們得出結(jié)論，osd0是我們需要的“舊”OSD。它在ConfigMap中被定義為/mnt/osd1(因為我們使用基于目錄的osd)。
我們一步一步地深入研究節(jié)點并修復(fù)ConfigMap。完成后，我們可以運行rook-operator pod并分析其日志，會發(fā)現(xiàn)以下的流程：
- “我是集群的管理員”;
- “我在節(jié)點上找到物理磁盤”;
- “我發(fā)現(xiàn)了Ceph Monitor”;
- “好的，Ceph Monitor已達到法定人數(shù);”
- “我正在開始OSD部署……”。
讓我們通過進入Rook operator的pod來檢查集群的狀況。好吧，看起來我們在幾個節(jié)點的OSD名稱上犯了一些錯誤!這沒什么大不了的：我們修復(fù)了ConfigMaps，刪除了新osd的冗余目錄，等等，最后，我們的集群狀態(tài)終于變成了HEALTH_OK!
讓我們檢查一下存儲池中的鏡像：
- # rbd ls -p kube
- pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
- pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
- pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
- pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
- pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
- pvc-c0800871-0749-40ab-8545-b900b83eeee9
- pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
- …
現(xiàn)在一切就緒，集群已恢復(fù)!
快速偷懶的恢復(fù)方法
對于已經(jīng)做好備份的場景，恢復(fù)過程更簡單，歸結(jié)為以下幾點：
- 將Rook-operator的部署規(guī)?？s小到零;
- 刪除除Rook operator之外的所有部署;
- 從備份還原所有secret和ConfigMap;
- 恢復(fù)/var/lib/rook/mon-*節(jié)點上目錄的內(nèi)容;
- 還原CephCluster，CephFilesystem，CephBlockPool，CephNFS，CephObjectStoreCRD(如果他們不知何故丟失);
- 將Rook-operator的部署擴展回1。
提示和技巧
始終進行備份!
以下是一些技巧，可避免在急需這些備份時避免這些情況：
- 如果您打算對集群進行一些涉及服務(wù)器重啟的大規(guī)模操作，我們建議將rook-operator部署縮減為零，以防止它“觸發(fā)故障”。
- 預(yù)先為Ceph Monitor指定nodeAffinity;
- 密切注意預(yù)配置 ROOK_MON_HEALTHCHECK_INTERVAL和ROOK_MON_OUT_TIMEOUT值。
結(jié)論
毫無疑問，Rook作為Kubernetes存儲的整體結(jié)構(gòu)中的附加層簡化了基礎(chǔ)架構(gòu)中的存儲管理，但是也使某些事情變得很復(fù)雜。你的每一個操作以及選擇都必須是經(jīng)過深思熟慮的。
順便說一下，最近官方在Rook文檔(https://github.com/rook/rook/commit/b651239d3f9a793c95b5c06668b7f28771254082#diff-8c0c983d538cce2b49678395777c3cb9)中增加了“將現(xiàn)有Rook Ceph群集納入新的Kubernetes群集” 部分。
您可以在其中找到將現(xiàn)有Rook Ceph群集引入新的Kubernetes群集所需的步驟的詳細說明，以及如何恢復(fù)由于某種原因而失敗的集群。
原文：https://blog.flant.com/manual-recovery-of-a-rook-cluster-in-kubernetes/
