昨天馮老板發了一篇文章探討了為什么將數據庫放入 K8S 中不是一個明智的選擇。
如果是四年前有人質疑容器化數據庫我覺得還可以 battle 一下，都 2023 年了還有人不能認清這個大勢，我就有必要來談談我的看法了。
我從 K8s 0.9 版本時就開始做這件事，當時確實略早，CSI 都不成熟，到 1.0 才稍微穩定點，當時我在科大訊飛工作，負責的項目是建設和維護一整套系統，這套系統最終支撐了公司內部的 PaaS 服務。
我們構建了一個 30 臺物理機的集群，別看這個集群很小，但是非常有技術含量，里面跑了近 3000 個應用，而且是各種類型的，包括但不限于微服務，數據庫，消息隊列，緩存等等。這個集群被公司內部幾百名開發人員同時使用，但是整個集群的運維工作只需不到半個人力就能完成，如果沒有 K8s 這一切絕對不可能。
我們還在不影響上層應用的情況下，無感知地升級了 Linux 內核。這種無感知升級如果沒有 K8s 的支持是無法想象的，光是和各個業務線溝通可能都需要半年。
我見過另外一個集群，跑了 400 個數據庫而已，堆了 400 臺服務器和 40 個人的運維團隊，集群的整體利用率卻不到 10%。整個集群無人敢動，只能一直堆人，人肉運維。這種情況雖然可以歸咎于組織的不專業，但實際上，很多團隊都面臨著類似的挑戰，無法有效地管理和優化他們的基礎設施。
后來我去了阿里，所有的交付類場景數據庫全部是跑在 K8s 上。迄今為止我們在容器里跑數據庫五年有余，0 故障。
數據庫 on K8s：專業能力的普及化
絕大多數做業務的公司對數據庫的處理通常存在兩個問題：要么是數據庫管理水平一般，無法充分發揮數據庫的潛能；要么是每年需要在數據庫管理上花費大量成本。數據庫 on K8s 可以讓這一切標準化，有了標準，人與人之間才可以協作，生產力改變生產關系，從而大幅提效，讓絕大多數不具備專業能力的團隊享受到專業能力，本質上分工更明確了，就像農業和畜牧業分離一樣，各自專注于自己的領域，從而提高整體的效率和產出。
以 KubeBlocks 團隊為例，我相信絕大多數公司在數據庫層面的積累和專業能力都沒有他們強。而且他們將這些實踐經驗轉化為代碼，寫成了控制器，以極其簡單的方式賦能給其他企業。K8s 讓這一切成為可能。
你可能會問：為什么不用 Ansible？運維人員可能很推崇 Ansible，因為和他們手頭上的工具很匹配，用起來很順手。Ansible 的核心思想是幫助用戶部署和執行運維操作，而 K8s 的控制器則是基于另一種思路：機器能做的事就不應該由人來做。通過 Operator，可以實現 24 小時不間斷地同步期望狀態和實際狀態，而這是用 Ansible 很難實現的，你用 Ansible 實現是想寫個定時任務嘛？
這就像在操作系統誕生之前，程序員需要手動給紙帶穿孔來運行程序。有人可能會說，用紙帶也能運行程序，甚至可以把程序刻錄在光盤上運行，為什么還需要操作系統呢？
這其實是同樣的道理：Ansible 對運維人員來說是一款好工具，但 K8s 的目標是消除低端運維工作 (即編寫和執行 Ansible 腳本的工作)。通過 K8s，我們可以實現更高效、更自動化的數據庫管理，從而讓那些不具備專業數據庫管理能力的團隊也能享受到專業級的服務。
數據庫 on K8s 的優勢
大部分人對于在 K8s 上運行數據庫的擔憂無非就集中在這幾個問題上：
穩定性不知道怎么樣？
出了問題我沒法排查？
性能是不是不夠好？
復雜度
在 K8s 上運行數據庫，復雜度主要分為兩個方面：
- 建設這套系統的復雜度
- 使用上的復雜度
第一：建設這套系統的復雜度
如果直接基于原生的 K8s (裸 K8s) 去構建數據庫系統，成本會相對較高，而且對于新手來說，這樣的操作并不友好，你需要自己建設 K8s 存儲驅動、數據庫控制器等多個組件，沒有深厚的專業知識和實踐經驗是搞不定的。
這個時候發行版的優勢就體現出來了，類似于 Linux 系統中，大多數人更傾向于使用 CentOS、Ubuntu 等發行版，而不是直接操作內核。我們也可以將 K8s 視為一種 “云內核”，如果你只是直接使用內核而不進行適當的定制和優化，可能會覺得它不夠好用。因為內核本身只是提供了一個框架，很多功能和優化需要用戶自己去實現。而 K8s 發行版則幫助用戶解決了這一問題。例如，Sealos 可以幫你一鍵構建包括高可用性集群、存儲插件和數據庫在內的完整系統。這一切只需要簡單的兩條命令：
$ 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
然后就沒有然后了，一個包含高可用集群、存儲插件和數據庫的系統就誕生了。雖然 Ansible 可以幫助你解決安裝問題，但它無法處理運行時的自愈、多租戶等問題，而 on K8s 可以讓數據庫 as a Service。
第二：使用上的復雜度
通過云操作系統發行版和控制器，用戶可以實現產品化的數據庫服務，而不是靠腳本解決問題。
這個頁面我相信沒有人不會使用吧？即使是菜雞如我，都有能力建設起一個具有 3 副本的 PostgreSQL 集群，并且包含備份、恢復和監控等功能。這種能力不僅可以賦予企業中的所有開發者，也展示了 “云計算思維” 與 “腳本思維” 的根本區別。云計算讓每個人都能夠提供服務 (as a Service)，而傳統的腳本方法只是運維人員的一種便捷工具。
穩定性
我們團隊在數據庫領域談不上專業，都能建立起相當穩定的數據庫系統，更別說專門研究這個領域的頂尖專家了。這個事情使用者不用操心，扔給專業的人去做就可以了。
舉個例子，Sealos 公有云目前運行了數千個應用，這些應用的數據庫都是完全容器化的，由 KubeBlocks 團隊提供支持。一旦數據庫出現任何問題，我們只需將問題扔給他們即可。從成本角度來看，隨便招聘一個 DBA 的成本都遠高于我們支付 KubeBlocks 商業版的費用了，而且 Sealos 還是平臺的建設方，對于使用數據庫的最終用戶來說就更不用關心了。從目前的運行情況來看，我們的穩定性已經遠超許多非專業團隊的運維水平。
而且基本上數據庫的生命周期管理就那么多事，穩定性問題是會隨著時間的推移被收斂的，這些問題不斷在代碼層面被解決掉，最終用戶關心的越來越少。這一點類似于 Linux 系統的穩定性，隨著技術的不斷成熟和優化，其穩定性已經達到了非常高的水平。一個良好的軟件架構會不斷提升和收斂其魯棒性，并逐漸減少對人的依賴，比如使用 Oracle 的人喝茶時間一定比用開源 MySQL 的人喝茶時間多。
所以無論從現實情況還是理論分析來看，穩定性都不應該成為用戶在 K8s 上運行數據庫的障礙。將數據庫運行在 k8s 上，實際上是在利用幾十名頂尖數據庫專家的經驗，他們將自己的知識和技能沉淀到代碼中，以標準化的方式為用戶服務。單靠腳本很難將這些經驗沉淀得如此徹底和高效。。單靠腳本很難將這些經驗沉淀得如此徹底和高效。
性能
說數據庫跑容器性能不好的大概率都是不會玩的，KubeBlocks 團隊做過深入的測試與調優，并撰寫了很詳細的分析文章，很多人覺得真復雜，但是其實這個復雜的事又不需要用戶去做。這些復雜性已經被內嵌在控制器的代碼中，對于最終用戶來說，這一過程并不復雜。而且，容器對數據庫性能的影響幾乎可以忽略不計，真正重要的是磁盤 IO 和網絡帶寬時延等因素。
OpenEBS 裸盤+數據庫控制器的方案就可以有效解決性能問題。有了數據庫控制器，就無需依賴于分布式存儲。控制器能夠保證數據庫多副本的高性能和高可用性，無論是有狀態服務還是無狀態服務，對于用戶來說都感覺不到差異。如果實例發生故障，控制器會自動進行調整。這才是一種極致的數據庫使用體驗。
Sealos 目前已經采用了這種解決方案，在保證高可用性的同時，又不犧牲性能。它可以直接對接裸盤，進行自動擴容、備份和恢復。如果節點發生故障，控制器會自動啟動新節點，同步數據并將其加入集群。這些高級功能只能在云操作系統中實現，傳統的腳本方法只能望塵莫及，而且后者通常還需要人工介入，比如半夜掛了就只能 on call 了。
所以在 K8s 上運行數據庫不僅沒有性能問題，其穩定性甚至都超過了大多數運維人員的能力。而且，這種方式已經做到了簡單易用和自助操作，你要不要用？
不脫離實際場景去否定和肯定
在討論數據庫是否應該容器化時，我們必須考慮不同的實際應用場景。
有些公司的數據庫已經非常穩定的以非容器化的方式在運行了，也不差錢養著一群數據庫專家，這樣的情況當然沒有動力把數據庫搬到 K8s 上，搬出問題誰來背鍋？例如，銀行通常使用專門的 Oracle 一體機，只需支付訂閱費用即可，這樣的系統很難有遷移的動力。
然而，對于許多業務開發團隊和組織來說，他們現在面臨著一個新的選擇：以極低的成本獲得高度專業的數據庫能力，從而將核心團隊的精力全部集中在業務開發上。
要達到這一效果，他們可以選擇直接使用 RDS (關系數據庫服務) 這樣的數據庫云服務，或者采用基于 K8s 的數據庫解決方案。這種方法需要一個長時間運行的管理進程來替代人工角色，以賦予那些不懂數據庫的團隊相應的能力。這就是一個大的趨勢，固定成本 (例如開發控制器的成本) 提升了，但是邊際成本 (每個使用數據庫的團隊的成本) 會大幅降低。
當前有很多方案可以做到這一點，比如基于虛擬機或基于 Ansible，但毋庸置疑基于 K8s 的控制器在當前看來是最優解。即便是提供類似 RDS 這種能力的服務，底層使用 k8s 技術棧也是最優解。相比之下，虛擬機就不太行了，重，成本自然高，而且有更多的性能消耗。而像 Ansible 這類工具想要實現自助服務和多租戶支持，更是異想天開。
總結
K8s 的重要性
K8s 是個大殺器，像是無崖子一甲子的功力你能發揮幾成，如果 K8s 不跑數據庫，你大概只能發揮 1 成功力。用好 K8s 能夠極大地增強數據庫運維的效能。
技術進步帶來的分工變革
隨著技術的不斷進步，數據庫的管理者和使用者會逐漸分離，傳統的人工操作正在逐步被自動化程序所取代。在這個過程中，標準化就成了有效協作的基石。目前沒有看到比容器技術和 K8s 更強的事實標準誕生，因此，將數據庫跑到 K8s 上是大勢所趨。
實踐案例和效益
目前已經有很多團隊在成本、易用性、穩定性和性能等多個維度上成功實踐了 K8s，取得了顯著的成果，也嘗到了這樣做的甜頭。由奢入儉難，一旦企業體驗到了 K8s 帶來的好處，很難再回到傳統的運維方式。以 Sealos 為例，從 v2 使用 ansible，到 v3 完全轉向 golang，現在已經發展到 v4 和 v5，這種技術的演進正是基于 “云計算” 和 “云操作系統” 的思維，而不是傳統的 “運維腳本” 思維。腳本連個 API 都實現不了你我談先進生產力？設計一個系統優先考慮的不一定是給人用的，而是給別的系統調用的，這樣整個自動化才能起飛，這就是為什么 API > CLI > GUI 的原因。
運維角色的轉變
目前還是有很多存量市場的 DBA 運維人員想保住自己的飯碗在唱衰這個方向，但是英明的決策者遲早會發現采用 K8s 可以大幅降低人力成本，提高效率和系統穩定性。良禽擇木而棲，希望很多運維同學能意識到你們在逐漸被取代是事實，當年我們做訊飛云的時候有近 40 人的運維團隊，做完之后連運維這個組都沒了。在阿里云的時候我們團隊也是 0 運維人員。
K8s 的快速成熟和生態發展
K8s 在以極快的速度走向更成熟，生態在蓬勃發展，誕生了短期的亂象，讓落地實踐變得無所適從。但是不要擔心，優秀的發行版一定會出現，發行版就在做 “熵減” 的事情，簡化用戶的使用體驗，就像 Linux 內核到 Linux 發行版的演進一樣，Sealos 就是其中一款基于 K8s 的云操作系統發行版。我最近一段時間回訪了將近 200 名 Sealos 的付費用戶，沒有一個用戶反饋上面的數據庫不會用的，有反饋不穩定的，幾個原因，磁盤滿了，升級導致的問題等，這幾個問題都被收斂掉了，最終趨近于 0，至少可以說是比用戶自己搭建的穩定性高出好幾個 9。
企業的選擇
企業選不選這樣的方案還是根據自己實際情況來判斷，但是聰明的企業在嘗試數據庫 on K8s 之后會帶來極大的好處，例如選擇了 Sealos + KubeBlocks 的組合，就相當于擁有了：
- 一個擁有8年以上經驗的專業 K8s 團隊。
- 一個 P10 帶了一幫 P8-9 的頂尖專業數據庫團隊。
- 一個極友好的產品體驗，魯棒性極高，性能極高的數據庫系統。
連招聘一個專家的成本都不到。當然這種選擇一定有阻力，阻力大部分來自于企業內部那些想保住自己飯碗其實可以不太需要的人。
我本可以對馮老板的論調逐條反擊，但是邊看文章邊寫還是太累了，碎碎念這些，希望看看到底有多少人能有更高級點的認知，希望能聽到更多支持 OR 反對我們的聲音，一起探索真理～
sealos 以kubernetes為內核的云操作系統發行版，讓云原生簡單普及
