昨天馮老板發(fā)了一篇文章探討了為什么將數(shù)據(jù)庫放入 K8S 中不是一個明智的選擇。

如果是四年前有人質(zhì)疑容器化數(shù)據(jù)庫我覺得還可以 battle 一下，都 2023 年了還有人不能認清這個大勢，我就有必要來談?wù)勎业目捶恕?/p>

我從 K8s 0.9 版本時就開始做這件事，當時確實略早，CSI 都不成熟，到 1.0 才稍微穩(wěn)定點，當時我在科大訊飛工作，負責(zé)的項目是建設(shè)和維護一整套系統(tǒng)，這套系統(tǒng)最終支撐了公司內(nèi)部的 PaaS 服務(wù)。

我們構(gòu)建了一個 30 臺物理機的集群，別看這個集群很小，但是非常有技術(shù)含量，里面跑了近 3000 個應(yīng)用，而且是各種類型的，包括但不限于微服務(wù)，數(shù)據(jù)庫，消息隊列，緩存等等。這個集群被公司內(nèi)部幾百名開發(fā)人員同時使用，但是整個集群的運維工作只需不到半個人力就能完成，如果沒有 K8s 這一切絕對不可能。

我們還在不影響上層應(yīng)用的情況下，無感知地升級了 Linux 內(nèi)核。這種無感知升級如果沒有 K8s 的支持是無法想象的，光是和各個業(yè)務(wù)線溝通可能都需要半年。

我見過另外一個集群，跑了 400 個數(shù)據(jù)庫而已，堆了 400 臺服務(wù)器和 40 個人的運維團隊，集群的整體利用率卻不到 10%。整個集群無人敢動，只能一直堆人，人肉運維。這種情況雖然可以歸咎于組織的不專業(yè)，但實際上，很多團隊都面臨著類似的挑戰(zhàn)，無法有效地管理和優(yōu)化他們的基礎(chǔ)設(shè)施。

后來我去了阿里，所有的交付類場景數(shù)據(jù)庫全部是跑在 K8s 上。迄今為止我們在容器里跑數(shù)據(jù)庫五年有余，0 故障。

數(shù)據(jù)庫 on K8s：專業(yè)能力的普及化

絕大多數(shù)做業(yè)務(wù)的公司對數(shù)據(jù)庫的處理通常存在兩個問題：要么是數(shù)據(jù)庫管理水平一般，無法充分發(fā)揮數(shù)據(jù)庫的潛能；要么是每年需要在數(shù)據(jù)庫管理上花費大量成本。數(shù)據(jù)庫 on K8s 可以讓這一切標準化，有了標準，人與人之間才可以協(xié)作，生產(chǎn)力改變生產(chǎn)關(guān)系，從而大幅提效，讓絕大多數(shù)不具備專業(yè)能力的團隊享受到專業(yè)能力，本質(zhì)上分工更明確了，就像農(nóng)業(yè)和畜牧業(yè)分離一樣，各自專注于自己的領(lǐng)域，從而提高整體的效率和產(chǎn)出。

以 KubeBlocks 團隊為例，我相信絕大多數(shù)公司在數(shù)據(jù)庫層面的積累和專業(yè)能力都沒有他們強。而且他們將這些實踐經(jīng)驗轉(zhuǎn)化為代碼，寫成了控制器，以極其簡單的方式賦能給其他企業(yè)。K8s 讓這一切成為可能。

你可能會問：為什么不用 Ansible？運維人員可能很推崇 Ansible，因為和他們手頭上的工具很匹配，用起來很順手。Ansible 的核心思想是幫助用戶部署和執(zhí)行運維操作，而 K8s 的控制器則是基于另一種思路：機器能做的事就不應(yīng)該由人來做。通過 Operator，可以實現(xiàn) 24 小時不間斷地同步期望狀態(tài)和實際狀態(tài)，而這是用 Ansible 很難實現(xiàn)的，你用 Ansible 實現(xiàn)是想寫個定時任務(wù)嘛？

這就像在操作系統(tǒng)誕生之前，程序員需要手動給紙帶穿孔來運行程序。有人可能會說，用紙帶也能運行程序，甚至可以把程序刻錄在光盤上運行，為什么還需要操作系統(tǒng)呢？

這其實是同樣的道理：Ansible 對運維人員來說是一款好工具，但 K8s 的目標是消除低端運維工作 (即編寫和執(zhí)行 Ansible 腳本的工作)。通過 K8s，我們可以實現(xiàn)更高效、更自動化的數(shù)據(jù)庫管理，從而讓那些不具備專業(yè)數(shù)據(jù)庫管理能力的團隊也能享受到專業(yè)級的服務(wù)。

數(shù)據(jù)庫 on K8s 的優(yōu)勢

大部分人對于在 K8s 上運行數(shù)據(jù)庫的擔(dān)憂無非就集中在這幾個問題上：

穩(wěn)定性不知道怎么樣？

出了問題我沒法排查？

性能是不是不夠好？

復(fù)雜度

在 K8s 上運行數(shù)據(jù)庫，復(fù)雜度主要分為兩個方面：

1. 建設(shè)這套系統(tǒng)的復(fù)雜度
2. 使用上的復(fù)雜度

第一：建設(shè)這套系統(tǒng)的復(fù)雜度

如果直接基于原生的 K8s (裸 K8s) 去構(gòu)建數(shù)據(jù)庫系統(tǒng)，成本會相對較高，而且對于新手來說，這樣的操作并不友好，你需要自己建設(shè) K8s 存儲驅(qū)動、數(shù)據(jù)庫控制器等多個組件，沒有深厚的專業(yè)知識和實踐經(jīng)驗是搞不定的。

這個時候發(fā)行版的優(yōu)勢就體現(xiàn)出來了，類似于 Linux 系統(tǒng)中，大多數(shù)人更傾向于使用 CentOS、Ubuntu 等發(fā)行版，而不是直接操作內(nèi)核。我們也可以將 K8s 視為一種 “云內(nèi)核”，如果你只是直接使用內(nèi)核而不進行適當?shù)亩ㄖ坪蛢?yōu)化，可能會覺得它不夠好用。因為內(nèi)核本身只是提供了一個框架，很多功能和優(yōu)化需要用戶自己去實現(xiàn)。而 K8s 發(fā)行版則幫助用戶解決了這一問題。例如，Sealos 可以幫你一鍵構(gòu)建包括高可用性集群、存儲插件和數(shù)據(jù)庫在內(nèi)的完整系統(tǒng)。這一切只需要簡單的兩條命令：

$ sealos run labring/kubernetes:v1.27.7 labring/helm:v3.9.4 labring/cilium:v1.13.4 \
     --masters 192.168.64.2,192.168.64.22,192.168.64.20 \
     --nodes 192.168.64.21,192.168.64.19 -p [your-ssh-passwd]
$ sealos run labring/openebs:v3.9.0 labring/mysql:8.0

然后就沒有然后了，一個包含高可用集群、存儲插件和數(shù)據(jù)庫的系統(tǒng)就誕生了。雖然 Ansible 可以幫助你解決安裝問題，但它無法處理運行時的自愈、多租戶等問題，而 on K8s 可以讓數(shù)據(jù)庫 as a Service。

第二：使用上的復(fù)雜度

通過云操作系統(tǒng)發(fā)行版和控制器，用戶可以實現(xiàn)產(chǎn)品化的數(shù)據(jù)庫服務(wù)，而不是靠腳本解決問題。

這個頁面我相信沒有人不會使用吧？即使是菜雞如我，都有能力建設(shè)起一個具有 3 副本的 PostgreSQL 集群，并且包含備份、恢復(fù)和監(jiān)控等功能。這種能力不僅可以賦予企業(yè)中的所有開發(fā)者，也展示了 “云計算思維” 與 “腳本思維” 的根本區(qū)別。云計算讓每個人都能夠提供服務(wù) (as a Service)，而傳統(tǒng)的腳本方法只是運維人員的一種便捷工具。

穩(wěn)定性

我們團隊在數(shù)據(jù)庫領(lǐng)域談不上專業(yè)，都能建立起相當穩(wěn)定的數(shù)據(jù)庫系統(tǒng)，更別說專門研究這個領(lǐng)域的頂尖專家了。這個事情使用者不用操心，扔給專業(yè)的人去做就可以了。

舉個例子，Sealos 公有云目前運行了數(shù)千個應(yīng)用，這些應(yīng)用的數(shù)據(jù)庫都是完全容器化的，由 KubeBlocks 團隊提供支持。一旦數(shù)據(jù)庫出現(xiàn)任何問題，我們只需將問題扔給他們即可。從成本角度來看，隨便招聘一個 DBA 的成本都遠高于我們支付 KubeBlocks 商業(yè)版的費用了，而且 Sealos 還是平臺的建設(shè)方，對于使用數(shù)據(jù)庫的最終用戶來說就更不用關(guān)心了。從目前的運行情況來看，我們的穩(wěn)定性已經(jīng)遠超許多非專業(yè)團隊的運維水平。

而且基本上數(shù)據(jù)庫的生命周期管理就那么多事，穩(wěn)定性問題是會隨著時間的推移被收斂的，這些問題不斷在代碼層面被解決掉，最終用戶關(guān)心的越來越少。這一點類似于 Linux 系統(tǒng)的穩(wěn)定性，隨著技術(shù)的不斷成熟和優(yōu)化，其穩(wěn)定性已經(jīng)達到了非常高的水平。一個良好的軟件架構(gòu)會不斷提升和收斂其魯棒性，并逐漸減少對人的依賴，比如使用 Oracle 的人喝茶時間一定比用開源 MySQL 的人喝茶時間多。

所以無論從現(xiàn)實情況還是理論分析來看，穩(wěn)定性都不應(yīng)該成為用戶在 K8s 上運行數(shù)據(jù)庫的障礙。將數(shù)據(jù)庫運行在 k8s 上，實際上是在利用幾十名頂尖數(shù)據(jù)庫專家的經(jīng)驗，他們將自己的知識和技能沉淀到代碼中，以標準化的方式為用戶服務(wù)。單靠腳本很難將這些經(jīng)驗沉淀得如此徹底和高效。。單靠腳本很難將這些經(jīng)驗沉淀得如此徹底和高效。

性能

說數(shù)據(jù)庫跑容器性能不好的大概率都是不會玩的，KubeBlocks 團隊做過深入的測試與調(diào)優(yōu)，并撰寫了很詳細的分析文章，很多人覺得真復(fù)雜，但是其實這個復(fù)雜的事又不需要用戶去做。這些復(fù)雜性已經(jīng)被內(nèi)嵌在控制器的代碼中，對于最終用戶來說，這一過程并不復(fù)雜。而且，容器對數(shù)據(jù)庫性能的影響幾乎可以忽略不計，真正重要的是磁盤 IO 和網(wǎng)絡(luò)帶寬時延等因素。

OpenEBS 裸盤+數(shù)據(jù)庫控制器的方案就可以有效解決性能問題。有了數(shù)據(jù)庫控制器，就無需依賴于分布式存儲。控制器能夠保證數(shù)據(jù)庫多副本的高性能和高可用性，無論是有狀態(tài)服務(wù)還是無狀態(tài)服務(wù)，對于用戶來說都感覺不到差異。如果實例發(fā)生故障，控制器會自動進行調(diào)整。這才是一種極致的數(shù)據(jù)庫使用體驗。

Sealos 目前已經(jīng)采用了這種解決方案，在保證高可用性的同時，又不犧牲性能。它可以直接對接裸盤，進行自動擴容、備份和恢復(fù)。如果節(jié)點發(fā)生故障，控制器會自動啟動新節(jié)點，同步數(shù)據(jù)并將其加入集群。這些高級功能只能在云操作系統(tǒng)中實現(xiàn)，傳統(tǒng)的腳本方法只能望塵莫及，而且后者通常還需要人工介入，比如半夜掛了就只能 on call 了。

所以在 K8s 上運行數(shù)據(jù)庫不僅沒有性能問題，其穩(wěn)定性甚至都超過了大多數(shù)運維人員的能力。而且，這種方式已經(jīng)做到了簡單易用和自助操作，你要不要用？

不脫離實際場景去否定和肯定

在討論數(shù)據(jù)庫是否應(yīng)該容器化時，我們必須考慮不同的實際應(yīng)用場景。

有些公司的數(shù)據(jù)庫已經(jīng)非常穩(wěn)定的以非容器化的方式在運行了，也不差錢養(yǎng)著一群數(shù)據(jù)庫專家，這樣的情況當然沒有動力把數(shù)據(jù)庫搬到 K8s 上，搬出問題誰來背鍋？例如，銀行通常使用專門的 Oracle 一體機，只需支付訂閱費用即可，這樣的系統(tǒng)很難有遷移的動力。

然而，對于許多業(yè)務(wù)開發(fā)團隊和組織來說，他們現(xiàn)在面臨著一個新的選擇：以極低的成本獲得高度專業(yè)的數(shù)據(jù)庫能力，從而將核心團隊的精力全部集中在業(yè)務(wù)開發(fā)上。

要達到這一效果，他們可以選擇直接使用 RDS (關(guān)系數(shù)據(jù)庫服務(wù)) 這樣的數(shù)據(jù)庫云服務(wù)，或者采用基于 K8s 的數(shù)據(jù)庫解決方案。這種方法需要一個長時間運行的管理進程來替代人工角色，以賦予那些不懂數(shù)據(jù)庫的團隊相應(yīng)的能力。這就是一個大的趨勢，固定成本 (例如開發(fā)控制器的成本) 提升了，但是邊際成本 (每個使用數(shù)據(jù)庫的團隊的成本) 會大幅降低。

當前有很多方案可以做到這一點，比如基于虛擬機或基于 Ansible，但毋庸置疑基于 K8s 的控制器在當前看來是最優(yōu)解。即便是提供類似 RDS 這種能力的服務(wù)，底層使用 k8s 技術(shù)棧也是最優(yōu)解。相比之下，虛擬機就不太行了，重，成本自然高，而且有更多的性能消耗。而像 Ansible 這類工具想要實現(xiàn)自助服務(wù)和多租戶支持，更是異想天開。

總結(jié)

K8s 的重要性

K8s 是個大殺器，像是無崖子一甲子的功力你能發(fā)揮幾成，如果 K8s 不跑數(shù)據(jù)庫，你大概只能發(fā)揮 1 成功力。用好 K8s 能夠極大地增強數(shù)據(jù)庫運維的效能。

技術(shù)進步帶來的分工變革

隨著技術(shù)的不斷進步，數(shù)據(jù)庫的管理者和使用者會逐漸分離，傳統(tǒng)的人工操作正在逐步被自動化程序所取代。在這個過程中，標準化就成了有效協(xié)作的基石。目前沒有看到比容器技術(shù)和 K8s 更強的事實標準誕生，因此，將數(shù)據(jù)庫跑到 K8s 上是大勢所趨。

實踐案例和效益

目前已經(jīng)有很多團隊在成本、易用性、穩(wěn)定性和性能等多個維度上成功實踐了 K8s，取得了顯著的成果，也嘗到了這樣做的甜頭。由奢入儉難，一旦企業(yè)體驗到了 K8s 帶來的好處，很難再回到傳統(tǒng)的運維方式。以 Sealos 為例，從 v2 使用 ansible，到 v3 完全轉(zhuǎn)向 golang，現(xiàn)在已經(jīng)發(fā)展到 v4 和 v5，這種技術(shù)的演進正是基于 “云計算” 和 “云操作系統(tǒng)” 的思維，而不是傳統(tǒng)的 “運維腳本” 思維。腳本連個 API 都實現(xiàn)不了你我談先進生產(chǎn)力？設(shè)計一個系統(tǒng)優(yōu)先考慮的不一定是給人用的，而是給別的系統(tǒng)調(diào)用的，這樣整個自動化才能起飛，這就是為什么 API > CLI > GUI 的原因。

運維角色的轉(zhuǎn)變

目前還是有很多存量市場的 DBA 運維人員想保住自己的飯碗在唱衰這個方向，但是英明的決策者遲早會發(fā)現(xiàn)采用 K8s 可以大幅降低人力成本，提高效率和系統(tǒng)穩(wěn)定性。良禽擇木而棲，希望很多運維同學(xué)能意識到你們在逐漸被取代是事實，當年我們做訊飛云的時候有近 40 人的運維團隊，做完之后連運維這個組都沒了。在阿里云的時候我們團隊也是 0 運維人員。

K8s 的快速成熟和生態(tài)發(fā)展

K8s 在以極快的速度走向更成熟，生態(tài)在蓬勃發(fā)展，誕生了短期的亂象，讓落地實踐變得無所適從。但是不要擔(dān)心，優(yōu)秀的發(fā)行版一定會出現(xiàn)，發(fā)行版就在做 “熵減” 的事情，簡化用戶的使用體驗，就像 Linux 內(nèi)核到 Linux 發(fā)行版的演進一樣，Sealos 就是其中一款基于 K8s 的云操作系統(tǒng)發(fā)行版。我最近一段時間回訪了將近 200 名 Sealos 的付費用戶，沒有一個用戶反饋上面的數(shù)據(jù)庫不會用的，有反饋不穩(wěn)定的，幾個原因，磁盤滿了，升級導(dǎo)致的問題等，這幾個問題都被收斂掉了，最終趨近于 0，至少可以說是比用戶自己搭建的穩(wěn)定性高出好幾個 9。

企業(yè)的選擇

企業(yè)選不選這樣的方案還是根據(jù)自己實際情況來判斷，但是聰明的企業(yè)在嘗試數(shù)據(jù)庫 on K8s 之后會帶來極大的好處，例如選擇了 Sealos + KubeBlocks 的組合，就相當于擁有了：

1. 一個擁有8年以上經(jīng)驗的專業(yè) K8s 團隊。
2. 一個 P10 帶了一幫 P8-9 的頂尖專業(yè)數(shù)據(jù)庫團隊。
3. 一個極友好的產(chǎn)品體驗，魯棒性極高，性能極高的數(shù)據(jù)庫系統(tǒng)。

連招聘一個專家的成本都不到。當然這種選擇一定有阻力，阻力大部分來自于企業(yè)內(nèi)部那些想保住自己飯碗其實可以不太需要的人。

我本可以對馮老板的論調(diào)逐條反擊，但是邊看文章邊寫還是太累了，碎碎念這些，希望看看到底有多少人能有更高級點的認知，希望能聽到更多支持 OR 反對我們的聲音，一起探索真理～文章來源地址http://www.zghlxwxcb.cn/news/detail-749211.html

到了這里，關(guān)于沒錯，數(shù)據(jù)庫確實應(yīng)該放入 K8s 里！的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！