Kubernetes(K8s) 解決了哪些問題? 想了解一下 OpenStack 沒落在市場中的原因,以及 K8s 給大家帶來了什麼以前沒有的東西,解決了哪些問題。 隨著容器的火爆,利用容器架構來搭建業務系統的人越來越多。可是,大家在實操中發現,像 Docker 之類的容器引擎,折騰少量容器還行。但如今的雲原生應用、機器學習任務或者大數據分析業務,動輒就要使用成百上千的容器。要管理這麼多容器,Docker 們就力不從心了。 江山代有才人出,各領風騷三五年,有需求就有改變,於是乎,市場上就出現了一批容器編排工具,典型的是 Swarm、Mesos 和 K8S。經過幾年大浪淘沙,K8S「擊敗」Swarm 和 Mesos,幾乎成了當前容器編排的事實標準。 K8S 最初是由 Google 開發的,後來捐贈給了 CNCF(雲原生計算基金會,隸屬 Linux 基金會)。 K8S 的全名是 kubernetes,讀作「庫伯耐踢死」,很多國人既拼不對也寫不對,而 K 和 S 之間有 8 個字母,索性就簡單一點,叫「開八司」了。K8S 是個雜技高手,最擅長的就是「搬箱子」,盤各種容器玩。 K8S 的大致架構,就像上面。Master 節點,用來放「腦子」,「腿腳」搭在工作節點上「搬磚」,工作節點就是實際業務容器的存放地。單個容器或多個關係密切的容器,被編成一組,稱為 pod。K8S 就是以 pod 為單位進行編排操作。同時,K8S 還要和其它相關軟體配合,來完成聯網、存儲、安全等功能。 誕生六年來,K8S 一路高歌,成為容器編排和調度領域的 No.1。但需要注意的是,K8S 和 Docker 們不是替代關係,而是配合關係。K8S 仍然會使用 Docker 之類的容器引擎(Docker、Containerd、RKT、CRI-O 等),來對容器進行生命周期管理。K8S 既然那麼猛,直接拿來用不香嗎?這樣做,看起來沒毛病,K8S 是開源軟體,社區版 K8S 也很完美。 你可以在網上找到各種安裝指導文檔,然後從 github 輕鬆找到最新的版本,然後一步一步搭建集群。只是安裝過程漫長而痛苦,畢竟搭建集群不是我們的目的,我們的目的是利用集群來幹活。 搭一個 K8S 學習環境倒也罷了,權當練手漲經驗。可當我們要搭建生產環境的時候,事情就變得不一樣了。這時候,為了保證集群的可靠性,我們可能要跨多個可用區來部署 K8S 集群。對於大多數人來說,這個工作不太好玩。 不止搭建集群過程很複雜,後期還要面對更繁瑣的 K8S 控制平面維護工作:版本升級、安全管控、數據備份等等。所以,面對生產級別的業務,大家往往喜歡選擇 Turnkey (一站式)的商用方案,而不是自己慢慢鼓搗,老牛拉破車。 目前,各大雲服務商幾乎都推出了 Turnkey 方案,幫助用戶快速搭建 K8S 集群。到底哪家強呢?王婆賣瓜,自賣自誇,似乎沒有定論。但是有個數據很有參考意義,根據諮詢機構「Nucleus Research」的數據,所有雲中 K8S 的工作負載,竟然有 82%都是運行在 Amazon Web Services (AWS) 上的。 So,我們差不多可以這樣說,雲上 K8S,還是 AWS 最強!AWS 提供了一個神器,叫做 Amazon Elastic Kubernetes Service (Amazon EKS),可以快速幫我們搭建高可用的雲上託管 K8S 服務。 ???AWS 優惠大禮包限時發放中,快點擊領取! Amazon EKS 到底牛在哪兒? 作為一個從來沒摸過 K8S 的生手,我用了不到 10 分鐘,就創建了一個橫跨 3 個可用區的生產級集群,實在太魔幻了。整個過程,只需要區區兩步↓ 在添加工作節點的時候,可以選擇各種 Amazon EC2 實例,AWS 準備了豐富的實例類型,滿足不同的容器用途。當然,還可以選擇新酷的 AWS Fargate 工作節點,這是一種 Serverless 的方式,說白了,你不需要去考慮什麼實例呀、伺服器呀,直接按需使用容器即可,要多少有多少,計費精確到容器,而非主機。集群創建完成後,我們就可採用自己習慣的工具,比如 kubectl,像使用標準 K8S 集群一樣,進行各種業務部署的操作了。 除了簡單、易用、生產級高可用以外,Amazon EKS 與社區版的 K8S 是保持同步的,原生體驗完全一致,可以使用社區所有插件和工具… So,不需要額外的學習成本,也不用擔心鎖定,輕鬆遷移。 作為雲上 K8S 大戶,AWS 也充分發揚開源精神,源於社區、反哺社區,不斷為 K8S 項目做貢獻,推動 K8S 的改進。 AWS 為 Amazon EKS 提供了多達 270 種節點,可以滿足所有工作負載和業務需求,並提供為 Amazon EKS 定製優化的操作系統鏡像,高效、安全、開源。同時,Amazon EKS 還與 AWS 其他服務無縫集成,諸如負載均衡、彈性伸縮、身份認證、存儲、安全、監控、日誌,用戶不需要苦逼滴自己造輪子,站在 AWS 肩膀上就行。更令人心動的是,不止於 Amazon EKS,圍繞容器、K8S、微服務這些雲原生的關鍵技術,AWS 提供了一攬子解決方案。 隨著雲計算進入深水區,雲原生的理念越來越深入人心,利用 AWS的「容器全家桶」,用戶可以輕鬆搭建各種高可用「雲原生」服務,把上雲的價值最大化。 如果你喜歡今天的分享,請多多點贊分享給身邊的朋友~??趁現在,開啟雲端之旅!??【一鍵註冊 AWS 海外賬戶,體驗免費套餐】 解決了OpenStack 功能過於全面的問題。OpenStack 想做一個工具箱,解決所有問題。 而K8S想做一把螺絲刀,只解決擰螺絲的問題。(假設現實世界主要的問題就是擰螺絲) 其實計算中心的發展史,就是一個不斷抽象,追求效率的過程。這個效率包括資源利用的效率和工程效率。從物理機,到虛擬機,再到容器,未來可能是serverless。我們的運行程序的載體越來越抽象,資源切割粒度越來越小。有種「坐井觀天」的感覺,你以為你擁有整個操作系統,其實只是底層物理機的一部分(隔離性)。 我們需要記住抽象不是目的,提高效率才是。虛擬機時代無疑是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 你會遇到什麼問題netkiller:Kubernetes Docker 你會遇到什麼問題?zhuanlan.zhihu.com在項目中實施容器技術,你可以遇到下列問題 鏡像遇到的問題 目前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 根本不知道作者將文件安裝到了哪裡。常常存儲目錄被放置在根目錄。例如 /datanetkiller:辦公室工位必備裝備?zhuanlan.zhihu.com 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部署生產環境。netkiller:蘋果M1 處理器現在可以入手嗎??zhuanlan.zhihu.com人員的問題現實中真正精通容器應用的人很少,容器實在太複雜。Google 將 Kubernetes 設計成大而全系統,想用 Kubernetes 解決所有問題。它涵蓋了幾大塊。操作系統,虛擬化,軟體定義網路,存儲,容器管理,用戶體系,許可權體系……我們的大學教育是本科教育專科化,本科教育本應該重視通識教育,我們的教育卻按照專科標準教育。本科是面向學術的起點,專科是面向工作,解決實際問題。你問一個中國大學生他會什麼,他會說:我會Java,我會Linux……反應到工作上,就是程序猿不懂運維知識,運維攻城獅不會寫程序。員工更趨向深耕一個領域,很類似現在的醫生教育和醫院體系,專科化,割裂化,導致很多跨科的疾病難以診斷。於是我提出了「多維度架構」。 最後總結 使用物理機,虛擬機,學習成本,試錯成本,部署成本遠遠低於容器技術。Google 官方也曾經說過,未來 kubernetes 重點可能會轉向虛擬機。我個人認為容器更適合CPU密集型的業務。我的架構中 KVM,Docker,Kubernetes,物理機混合使用,根據業務場景的需要來選擇最佳方案。前期製作符合你需求的鏡像,可能需要花費很長時間。netkiller:Kubernetes(minikube) 私有 registry 使用詳解?zhuanlan.zhihu.comnetkiller:Kubernetes Registry?zhuanlan.zhihu.comnetkiller:怎樣實施 DevOps?面臨什麼問題?如何解決??zhuanlan.zhihu.comnetkiller:多維度架構之分庫分表?zhuanlan.zhihu.comnetkiller:多維度架構之微服務的服務拆分?zhuanlan.zhihu.comnetkiller:多維度架構之消息隊列?zhuanlan.zhihu.comnetkiller:多維度架構之超時時間?zhuanlan.zhihu.comnetkiller:多維度架構之網路損耗?zhuanlan.zhihu.comnetkiller:多維度架構之會話數?zhuanlan.zhihu.com 我並不覺得opstack會沒落 一個是側重虛擬機生命周期管理 另外一個是容器的編排 適合那種微服務場景下的應用 但現在的趨勢的確是產品微服務化 推薦閱讀: 相关文章 {{#data}} {{title}} {{/data}}