運維總監怒怼開發：你真的需要 K8s 嗎？

最近，小編在知乎上看到這樣一個問題：

運維總監怒怼開發：你真的需要 K8s 嗎？

Kubernetes 以其自動化管理與可擴充性等優點不斷吸引着新使用者，然而，它的配置複雜與資源消耗高等特點也一直被诟病，開發人員或許都曾扪心自問：我們真的需要 Kubernetes 嗎？

秉持着和平交流的學習态度，小編精選了幾位高贊知乎網友的精彩回答，分享給大家學習交流（勿上升、勿引戰）：

1号知乎網友：林英

說句難聽點的，很多項目，springcloud+k8s，整了10幾個後端，一堆伺服器；

日活都沒上萬，日增資料就萬條，那點量，整幾個springboot 弄弄就行，伺服器費用，開發費用一砍，拿來做市場多好，别和我談解耦，你就這點并發，寫個 for 循環，裡面可勁寫 select 語句都不會蹦。

2号知乎網友：泰酷啦

我最近幾年待過的公司，我隻要一進公司，基本上都是主導或力推全面容器化、K8s 化，不論業務體量（當然，微服務是必須的）。

對于連續用了4年 K8s 的我來說，哪怕你隻有三台伺服器，我也要給你部署 K8s。

如果你隻有一台實體機，我恨不得給你虛拟化三台機器出來再裝個 K8s（隻是恨不得而已）。

如果你說沒必要，我下意識的感覺就是你肯定還不熟悉K8s。

下面簡單說一下我已經離不開 K8s 的理由。

從線上費用來講，各種雲已經有托管 master 的叢集在售，你直接買 node 就行，一個 node 和 一個 ecs 的費用相差也不大（同等配置）。

從線下費用來講，不管你用不用 k8s，伺服器是必須的吧，這個無論如何免不了。

從伺服器維護來講，相對傳統的公司伺服器一般會用 esxi 等虛拟化技術将實體機配置設定成若幹個虛拟機，而你用了 k8s 之後，你直接可以将實體機作為叢集的一個 node，免去虛拟化的時間和維護成本，新購機器直接作為 node 加入資源池。

從維護難度來講，你隻要能熟練使用 kubectl，你的大部分運維工作都可以免去 ssh 這個操作了。

我要運作一個應用：

kubectl create deploy xx --image=xxx

我要讓服務可以外部通路：

kubectl expose deploy xx --type xx --target-port xx --port xx

我的應用要擴充一下副本，做下負載均衡：

kubectl scale deploy xx --replicas xx

我要配下域名、轉發、黑白名單：

kubectl edit ing ...

對于CI/CD、服務釋出更新：

kubectl set image xxx app image=xxx 或 helm upgrade ...

回想一下多年以前你寫了一個 300 行的 Shell 隻為所謂的平滑更新一個應用的版本，K8s 依然隻要你 kubectl 一下。

再進階一點，你如果稍具開發技能，對接一下 K8s 的 api，把上面的這些操作做到 UI 讓開發點點點，你會發現，如果你公司本來有 10 個運維，這麼一搞可能兩個就夠了（留一個陪另一個吃飯）。

額，寫到這裡的時候重新看了下題，是對開發來講的哈……那我隻能說，K8s 真的牛……

3号知乎網友：匿名好友

我司都沒有運維部門，技術總監讓我們隻用 Docker 來部署一下，我們寫好 Dockerfile 之後讓生産機器讓跑鏡像，SLB 去反向代理。但容器 down 了 2 天大家都不知道，還是另一個同僚閑的沒事做看看日志才發現不對勁。半夜突然要擴容了怎麼做？随手挑一台機器去部署容器然後手動改 Nginx/SLB ？

很多「總監」意識不到上雲到底上的啥，畢竟它們連 Docker 這種 CRI 容器運作時接口是什麼都沒有搞清楚（不是所有人）。

雲原生除了容器、微服務之外，核心的基礎設施就是容器編排！Google 15 年的積累你說不需要就不需要？

現代運維部門、後端的架構部門，掌握 Kubernetes 已經是必備的了，因為它解決了微服務的部署問題，而且已然是容器編排的事實标準。别和我說 Docker Swarm，Docker 公司自己都放棄了。

4号知乎網友：作死w

不知道該不該用，那就不該用。

前後幹了幾家公司上 K8s 微服務了，統一的體驗就是架構設計稀爛，微服務不微，各種基礎設施缺失或者沒人維護。有的是把 K8s 當 docker-compose 用，有的是野心很大，這也要那也要，但開發維護的人手一隻手數的過來。

想上 K8s 最好問問自己，上 K8s 想解決啥問題？K8s是不是最佳解決方案？做好長期和 K8s 相處的準備了嗎，CI/CD 自動測試 QA 釋出流程怎麼遷移？以及想上微服務的，有足夠的人手維護基礎設施和遷移架構嗎？有踩過坑帶過隊的上司，給你們拆服務、劃邊界、安排漸進重構嗎？

從零開始的項目上 K8s 除了不用在x山代碼裡重構之外，拆服務劃邊界寫文檔還有基礎設施維護等等細碎而且讓人頭大的工作，都是要跟老闆要人力的。

除非上 K8s 還是老辦法一把梭，無非把 docker run 換成 deployment，那這 K8s 其實用了就跟沒用一樣。像是另一位答主說服務 down了幾個月沒人知道。換到K8s上，Pod 不知道啥時候 evicted 了幾個月也一樣沒人知道，節點啥時候挂了幾個月也沒人知道，某台節點莫名其妙挂上了 taint 也不會有人注意，又或者記憶體配額不夠服務OOM重新開機了，代碼報錯了，死鎖了，難道就有人注意了嗎。

問題顯然不是出在用 docker 還是 K8s，換 K8s 出的問題隻會比用 docker run 直接跑的時候更多、更頻繁、更隐蔽。

别把 K8s 當銀彈，回歸理性，好好想想為什麼去用它，怎麼用好它。

5号知乎網友：runzhliu

Kubernetes 的重點在于服務編排，這個才是 Kubernetes 真正流行的原因，當然基于 Kubernetes 上做一些架構的創新的想法一直都沒停止過，未來會有更多的玩法。

回到問題，開發同學想用 Kubernetes 經常都是被 Kubernetes 強大的社群的宣傳所洗腦……這個現象跟十年前 Hadoop/Spark 為代表的大資料架構開始流行很像。

因為很多宣發的文章都把這些新技術宣傳的非常高大上，而比較少會提到這些新技術帶來的技術管理和運維上的負擔。

雖然說大家都是從0開始摸着石頭過河的，但是能過河終究要看人才能力上的儲備，這就要通過存量的員工或者招聘來的員工來實作團隊的建設了。

假設你公司的運維總監找來一個所謂搞過 K8S 的 Leader（實際隻是做 K8S 機器運維的工作），要讓這樣的 Leader 帶領公司的容器化工作，肯定是吃苦頭的，因為實際他隻是搞了機器傳遞的環節，對 K8S 内部的運作機器、容器、核心都不夠熟悉，那麼在招聘人才的時候，也經常會走漏眼，畢竟他自己都不懂，很難指望他能夠建立一個足以應付大型業務的容器團隊。

是以關于到底用不用，除了要考慮公司業務的形态，還得考慮人才和團隊儲備，而不是看了一堆通稿或者分享之後就興緻勃勃開始容器化。

6号知乎網友：RLLvmd

開發代碼邏輯有問題，容易服務終止。K8s 自愈功能自動重新開機容器，一小時重新開機三千多次，硬生生扛下了所有，使用者沒發現服務中斷。

7号知乎網友：網瘾大爺

上個月為了成本優化，把全部200多個節點都輪轉了一遍，除了資料庫節點和一些有狀态服務節點，沒麻煩其他人，總計2天。

這種操作在沒有 K8s 的時候估計得加班搞幾周，稍微不小心就是個P0故障。

8号知乎網友：Chen Moore

一共3、5台EC執行個體的規模你别說K8s了，上個SpringCloud 我都嫌麻煩。

整個 SpringBoot 前面扔個 Nginx 完事，這還是建立在必須得前後端分離用 Java 的基礎上。

真要從0開始，這點規模

我選擇 react / vue + next.js 一把梭。

"你真的需要 K8s 嗎？"歡迎在留言區交流，留下你的觀點~

整理丨dbaplus社群

來源丨zhihu.com/question/430952886/

*僅為提供參考和學習交流，不代表dbaplus社群立場！dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]