我們需要記住抽象不是目的，提高效率才是。

虛擬機時代無疑是openstack，那麼對應容器時代就是kubernetes了。所以openstack依舊有其使用場景和價值，但是kubernetes是技術發展的選擇，較高層面上說，kubernetes 更加有效的提高了數據中心的資源的效率。

接下來我們具體一些分析。

Kubernetes最初定義就是容器編排和管理引擎。其管理不同節點上的容器生命周期，這些節點可以是物理機或虛擬機。其具備以下特點：

• 通過一系列調度演算法，可以合理調度Pod到主機
• 提供對服務的自愈能力。其會監控節點和容器運行狀況問題並做出相應的操作。並且kubernetes控制模式是聲明式而非命令式，控制器會不斷對比負載的真實狀態和期望狀態，從而做出糾正偏差的操作。
• 提供存儲，網路，proxy，安全性
• 可擴展

但是隨著kubernetes發展，已經發展成下一代操作系統。在這個萬物皆可CRD的時代，kubernetes作為基石，衍生出了太多的項目。

比如服務網格領域的istio，serverless領域的knative。你可以通過 kubevirt 去管理虛擬機，你也可以通過 Crossplane 管理基礎設施，也可以通過 kubeedge 實現邊緣計算。 而在AI領域，我們可以使用 kuebflow 構建我們的機器學習平台。大數據領域，flink 和 spark 也早已支持kubernetes 作為其資源管理的provider ......

Kubernetes Docker 你會遇到什麼問題

在項目中實施容器技術，你可以遇到下列問題

鏡像遇到的問題

目前docker 鏡像，沒有統一標準，體現在一下幾個方面。

使用OS發行版不統一

在使用過程中會遇到過各種本班的 OS。包括 alpine, debian, ubuntu, centos, oraclelinux, redhat 等等

經過裁剪的 OS 面目全非，不完整

即使是鏡像採用 CentOS 母版，很多鏡像製作者會給操作系統減肥。經過優化後，已經不是官方版本，在使用過程中你會遇到各種麻煩。例如調試的時候需要 curl,wget,telnet,nslookup 等工具在鏡像中沒有。甚至 ps, top, free, find, netstat, ifconfig 命令都沒有。

很多容器都不帶 iptables 所以，即使帶有iptables 在容器中修改規則也很麻煩。

安裝位置不統一

傳統OS 以 CentOS為例，有嚴格的安裝規範，例如:

通常安裝位置是：

/etc/example 配置文件
/bin/sbin 二進位文件
/var/lib/example 數據文件
/var/log/example 日誌文件
/var/run/example PID 文件

/etc/sysconfig/example 啟動參數文件
/etc/system.d/example 啟動腳本

或者被安裝在：

/usr/local/etc 配置文件
/usr/local/bin 可執行文件
/usr/local/share 文檔

最後一種是獨立安裝在：

/usr/local/example 下

容器鏡像那可是五花八門，沒有統一標準，如果不看 Dockerfile 根本不知道作者將文件安裝到了哪裡。

常常存儲目錄被放置在根目錄。例如 /data

Linux 系統也存在BUG

在我的20年執業生涯中是遇到過 Linux 系統有BUG的，還向 Redhat 提交過 BUG。如果你採用的鏡像有BUG，你想過怎麼去debug 嗎？

容器遇到的問題

程序啟動的區別

在Linux是一般是採用守護進程方式啟動。啟動後進入後台，啟動採用 systemd 。

容器中啟動通常是直接運行，這樣的運行方式，相當於你在linux的Shell 終端直接運行一樣，是在前台運行，隨時 CTRL + C 或者關閉終端窗口，程序就會退出。容器採用這種方式啟動，就是為了讓 docker 管理容器，docker 能夠感知到容器的當前狀態，如果程序退出，docker 將會重新啟動這個容器。

守護進程方式需要記錄 pid 即父進程ID，用於後面管理該進程，例如可以實現 HUP 信號處理。也就是 reload 操作，不用退出當前程序實現配置文件刷新。處理 HUP 信號，無需關閉 Socker 埠，也不會關閉線程或進程，用戶體驗更好。

容器是直接運行（前台運行），所以沒有 PID 也不能實現 reload 操作。 配置文件更新需要重新啟動容器，容器啟動瞬間TCP Socker 埠關閉，此時用戶會 timeout。甚至該服務可能會引起集群系統的雪崩效應。

很多鏡像製作者更趨向使用環境變數傳遞啟動參數。

當然你也可以在容器中使用 systemd ，這樣做容器不能直接感知到容器的運行狀態，systemctl stop example 後，容器仍然正常。需要做存活和健康檢查。通過健康狀態判斷容器的工作情況。如果處於非健康狀態，將該節點從負載均衡節點池中將它踢出去。

Linux 啟動一個應用遠遠比docker 啟動一個容器速度要快。因為物理機或者虛擬機的Linux操作系統已經啟動，虛擬機也分配了資源，運行可執行文件基本上是瞬間啟動。而 docker 啟動容器，要分配資源（分配內存和CPU資源，新建文件系統），相當於創建一個虛擬機的過程，最後載入約200MB左右的鏡像，並將鏡像運行起來，所以啟動所需時間較長，有時不可控，尤其是Java應用更為突出。

存儲面臨的問題

傳統 Linux 直接操作本地硬碟，IO性能最大化。

私有雲還好辦公有雲處處受限。

自建的 Docker 或 Kubrnetes 可以使用宿主主機資源，公有雲只能使用網路文件系統和分散式系統。

這也是我的架構中 KVM，Docker，Kubernetes，物理機混合使用的原因，根據業務場景的需要來選擇哪種方案。

物理機上部署 docker 可以分配宿主主機的所有資源，適合做有狀態的服務的存儲持久化的需求。

私有雲 Kubernetes 適合做 CPU密集型運算服務，雖然通過local 卷和 hostPath 可以綁定，但是管理起來不如 Docker 更方便。

NFS 基本是做實驗用的，不能用在生產環境。我20年的職業生涯遇到過很多奇葩，例如 NFS 卡頓，NFS 用一段時間後訪問不了，或者可以訪問，文件內容是舊的等等。

無論是NFS是更先進的分散式文件系統，如果不是 10G乙太網，基本都不能用在生產環境。10年前我用4電口1G網卡做埠聚合勉強可以用於生產環境，不過10年前的互聯網生態跟當今不同，那時還是以圖文為主，確切的說是文字為主，配圖還很少。

所以涉及到存儲使用分散式文件系統的前提是必須是 10G以上乙太網或者8G以上的FC 存儲。這樣才不會有IO瓶頸。任何分散式文件系統都不可能比本地文件系統穩定，除了速度還有延遲等等。

10GB 電口，光口乙太網已經出來十幾年了，相對比較便宜，可以使用 4光口 10G網卡，然後做埠聚合，變成 40G 網口。

現在 40G光口交換機都在10-20萬之間。一個40G的交換口可以分出四個10GB口。

如果使用40GB以上的乙太網，那麼總成本可能會超過物理機+虛擬機的解決方案。

內部域名DNS

由於在集群環境中容器名稱是隨機，IP地址是不固定的，甚至埠也是動態的。為了定位到容器的節點，通常集群中帶有DNS功能，為每個節點分配一個域名，在其他容器中使用域名即可訪問到需要的容器。

看似沒有問題，我的職業生涯中就遇到過DNS的問題，bind,dnsmseq 我都用過，都出現過事故。解析卡頓，ping www.domain.com 後遲遲解析不出IP。最長一次用了幾分鐘才解析到IP地址。

所以後面就非常謹慎，配置文件中我們仍然使用域名，因為修改配置文件可能需要 reload 應用，或者重新部署等等。域名寫入配置，方便IP地址變更。例如 db.host=db.netkiller.cn 同時我們會在 /etc/hosts 中增加 xxx.xxx.xxx.xxx db.netkiller.cn 。這樣主要使用 /etc/hosts 做解析，一旦漏掉 /etc/hosts 配置 DNS 還能工作。

故障分析，DNS 使用 UDP 協議 53 埠，UDP 在網路中傳輸不會返回狀態，有無數種可能導致 DNS 解析失敗。例如內部的交換機繁忙，背板帶寬不夠（用戶存儲轉發數據包，你可以理解就是交換機的內存），路由的問題等等……

容器與網路

相比傳統網路，容器中的網路環境是十分複雜的。傳統網路中一個數據包僅僅經過路由器，交換機，達到伺服器，最多在服務前在增加一些防火牆，負載均衡等設備。

容器網路部分實現方式SDN（軟體定義網路）相比物理機（路由器、交換機、無服務）實現相對複雜。容器裡面使用了IP轉發，埠轉發，軟路由，lvs，7層負載均衡等等技術…… 調試起來非常複雜。docker 的 iptables 規則很頭痛。

例如一個TCP/IP 請求，需要經過多層虛擬網路設備（docker0,bridge0,tun0……）層層轉發，再經過4層和7層的各種應用拆包，封包，最終到達容器內部。

有興趣你可以測試一下對比硬體設備，容器的網路延遲和吞吐量。

容器的管理

傳統服務可以通過鍵盤和顯示器本地管理，OpenSSH 遠程管理，通過配置還能使用串口。

容器的管理讓你抓狂 docker exec 和 kubectl exec 進入後與傳統Linux差異非常大，這是鏡像製作者造成了。

有些鏡像沒有初始化 shell 只有一個 $ 符號

沒有彩色顯示

可能不支持 UTF-8，中文亂碼

可能不是標準 ANSI/XTerm 終端

鍵盤定義五花八門，可能不是美式104鍵盤

國家和時區並不是東八區，上海

HOME 目錄也是不是 /root

想查看埠情況，發現 netstat 和 ss 命令沒有。

想查看IP地址，發現 ifconfig, ip 命令沒有。

想測試IP地址是否暢通，發現 ping, traceroute 沒有。

想測試URL，發現 curl , wget 沒有。

有些鏡像 dnf,yum,apk,apt 可以使用，有些鏡像把包管理也給閹割了，你想安裝上述工具都安裝不了。

卧槽！！！ 一萬匹草泥馬

然後就自己用 Dockerfile 編譯，整出200MB的鏡像，卧槽這麼大。

容器與安全

很多容器的鏡像中是不包含 iptables 的，所以無法做顆粒度很細的容器內部網路安全設置。即使你製作的鏡像帶有iptables ，多數容器的側咯，IP地址和埠是隨機變化的。

綁定IP地址又帶了容器的複雜性。

一旦攻入一個容器，進入容器後，容器與容器間基本是暢通無阻。

在容器中藏一個後門比物理機更容易，如上文所說很多容器中沒有調試相關命令，限制了你排查後門的難度。所以Dockerfile 製作鏡像，最好使用官方鏡像衍生出你的鏡像

容器與監控

談到監控，跳不開 prometheus（普羅米修斯），它並不能覆蓋到所有監控。

我曾經寫過一篇文章《監控的藝術》網上可以搜到。

容器與CI/CD

在DevOps場景中，使用 docker 或 kubernetes 做 CI/CD 是很扯淡的。

當 git 產生提交後，gitlab/jenkins 啟動容器，下載代碼，編譯，打包，測試，產生構建物，編譯 Dockerfile ，上傳 docker 鏡像到 registry，最後部署到容器執行。

卧槽！！！速度能急死你。

於是乎，我們做了 Cache。 不用每次都 pull 鏡像，緩存 Maven 的 .m2 庫，不再清理代碼（mvn clean）提速不少，測試環境湊合用吧。 注意不mvn clean 有時會編譯出錯

至於生產環境，我就不說了，有多少人真用CD部署生產環境。

人員的問題

現實中真正精通容器應用的人很少，容器實在太複雜。Google 將 Kubernetes 設計成大而全系統，想用 Kubernetes 解決所有問題。它涵蓋了幾大塊。

操作系統，虛擬化，軟體定義網路，存儲，容器管理，用戶體系，許可權體系……

我們的大學教育是本科教育專科化，本科教育本應該重視通識教育，我們的教育卻按照專科標準教育。本科是面向學術的起點，專科是面向工作，解決實際問題。

你問一個中國大學生他會什麼，他會說：我會Java，我會Linux……

反應到工作上，就是程序猿不懂運維知識，運維攻城獅不會寫程序。員工更趨向深耕一個領域，很類似現在的醫生教育和醫院體系，專科化，割裂化，導致很多跨科的疾病難以診斷。

於是我提出了「多維度架構」。

最後總結

使用物理機，虛擬機，學習成本，試錯成本，部署成本遠遠低於容器技術。

Google 官方也曾經說過，未來 kubernetes 重點可能會轉向虛擬機。

我個人認為容器更適合CPU密集型的業務。

我的架構中 KVM，Docker，Kubernetes，物理機混合使用，根據業務場景的需要來選擇最佳方案。

前期製作符合你需求的鏡像，可能需要花費很長時間。

我並不覺得opstack會沒落 一個是側重虛擬機生命周期管理 另外一個是容器的編排 適合那種微服務場景下的應用 但現在的趨勢的確是產品微服務化