內容來源:2017 年 11 月 25 日,噹噹網數字業務事業部技術總監李志偉在「Kubernetes Meetup | 北京站」進行《Kubernetes容器雲的互聯網企業實踐》演講分享。IT 大咖說(微信id:itdakashuo)做爲獨家視頻合做方,經主辦方和講者審閱受權發佈。
mysql
閱讀字數:3488 | 9分鐘閱讀web
本次演講主要分享了在Kubernetes領域的實踐和經驗,分別介紹了將原應用遷移到Kubernetes的前期準備以及遷移過程當中使用的規範。sql
不一樣企業開始往容器方向發展的初衷是不同的,有些企業是由於沒有運維工程師或運維團隊,而想要藉助某個平臺實現運維自動化。tomcat
有些企業多是因爲計算資源的利用率比較低。雖然一些大型的互聯網公司都是動輒擁有成千上萬臺服務器,但實際上以我我的的經從來看計算資源的利用率都不高,這裏有不少歷史的緣由,其中之一就是爲了得到更好的隔離性,而實現隔離最好的辦法就是採用從物理機到基於虛擬的私有云技術。服務器
對於有着比較長曆史的公司,應用部署每每會和本地的運行環境強相關,使得遷移變得很是困難,這時也須要有一個好的解決方案來解耦。另外業務總量的繁多,也會帶來管理的複雜度的提升。微信
上面提到的這些問題在咱們的生產實踐中都有不一樣程度的遇到,雖然有不少的解決方案,可是咱們最終仍是選擇了Kubernetes。網絡
Kubernetes首要解決了計算資源利用率低下的問題,得益於此咱們的服務器數量減小了一半。容器化解決了計算資源利用率問題。架構
業務容器鏡像一次構建,就可以運行在多種環境上,這種方式減小了對運行環境的以來,給運維平臺帶來了足夠的靈活性,解決了服務商鎖定的問題,咱們當時考慮的是若是某個IDC服務商不知足服務要求如何作到快速遷移,通常來講大批量的服務遷移代價很是高,須要很長時間,容器化以後業務遷移時間只須要30分鐘左右。運維
經過Kubernetes的架構設計思想咱們還能夠規範網站系統的架構設計。最後還有一點就是它實現了運維自動化。分佈式
要想向容器雲遷移,企業內部須要必定的運維能力,若是企業的規模還不夠大,也能夠考慮一些國內的容器雲服務提供商。下面來講下咱們本身所作的一些準備工做。
首先天然是搭建Kubernetes集羣,私有Docker鏡像倉庫構建採用的是harbor,而後是獨立出來的集羣監控,CI/CD基礎設置使用的是Jenkins和helm,分佈式存儲解決方案用的是Glusterfs。
從2015年末1.0版到以後的1.二、1.3版Kubernetes中的問題仍是比較多的,企業要使用它是須要必定勇氣的。但如今基本上趨於成熟,對於大部分應用不用太多的改造也能夠跑的很好。
即便是這樣,也不是全部的應用均可以遷移到容器雲中,若是應用可以很好的符合雲原生的設計原則固然能夠遷移進來,可是大部分的應用並非按照這樣的設計原則設計的。這個時候最好的辦法是先將業務遷移進來,而後再逐步演進成微服務架構。
在這個過程當中咱們剛開始其實也沒有任何規範,以後才陸續制定了相關規範,下面來具體看下遷移規範。
早期不少系統架構師都將Docker當作輕量級的虛擬機在使用,但這並非最佳實踐,要想正確的使用Docker須要符合如下基本原則:
- 儘量設計成無狀態服務,它帶來的好處就是可以很是容易的作水平擴展
- 儘量消除沒必要要的運行環境依賴,若是容器內業務依賴太多水平擴展就會變的很是困難,在傳統的部署形式下,不管是虛擬機部署仍是物理機部署都常常會產生各類各樣不必的依賴,對於有必定歷史的企業這個問題就會很是嚴重
- 須要持久化的數據寫入到分佈式存儲卷
- 儘量保證業務單一性,這樣可以讓分佈式應用很容易擴展,一樣它也是微服務架構中的設計原則
- 控制輸出到stdout和stderr的日誌寫入量
- 配置與容器鏡像內容分離
- 容器中使用K8S內部dns代替ip地址配置形式
- 日誌採用集中化處理方案(EFk)
- 採用獨立的容器處理定時任務
因爲考慮到測試環境和staging等運行環境的資源利用率並不高,因此就想在一個集羣內部同時運行開發、測試、staging、生產環境。經過NameSpace實現不一樣運行環境的隔離,同時應用軟件在不一樣的運行環境之間也不會產生命名衝突。
在v1.5版以前Service的命名不能超過24個字符,v1.5版以後最多63個字符。另外還須要知足正則regex[a-z]([-a-z0-9]*[a-z0-9])?的要求,這意味着首字母必須是a-z的字母,末字母不能是-,其餘部分能夠是字母數字和-符號。通常來講命名方式都是使用「業務名-應用服務器類型-其餘標識」的形式,如book-tomcat-n一、book-mysql-m1等。
應用健康檢查規範是實現自動化運維的重要組成部分,也是系統故障自動發現和自我恢復的重要手段。目前有兩種健康檢查方式,分別是進程級和業務級。
進程級健康檢查是Kubernetes自己具有的,它用來檢驗容器進程是否存活,是默認開啓的。
業務級的健康檢查由咱們本身實現,它有三點要求,一是必需要檢查自身核心業務是否正常,二是健康檢查程序執行時間要小於健康檢查週期,三是健康檢查程序消耗資源要合理控制,避免出現服務抖動。
健康檢查程序在不一樣環境下有着不一樣的實現:
web服務下采用HTTPGET方式進行健康檢查,須要實現一個「/healthz」URL,這個URL對應的程序須要檢查全部核心服務是否正常,健康檢查程序還應該在異常狀況下輸出每個檢查項的狀態明細。
其餘網絡服務下能夠採用探查容器指定端口狀態來判斷容器健康狀態。
非網絡服務下須要在容器內部執行特定命令,根據退出碼判斷容器健康狀態。
部署容器鏡像時應該避免使用latest tag形式,不然一旦出現問題就難以跟蹤到當前運行的Image版本,也難以進行回滾操做。因此建議每一個容器Image的tag應該用版本號來標識。
早期的1.0版本配置信息都是寫在配置文件中的,要作遷移就須要改不少東西,當時就只有幾種方法能夠傳遞配置信息,其中一種是經過環境變量傳遞,而後內部還要有一個對應機制進行轉化,這實際上是很是麻煩的過程。可是如今有了ConfigMap以後,就只須要將原先的配置文件導入到ConfigMap中就好了。
咱們在作遷移的時候採用的是Jenkins來實現CI/CD的,而後經過Helm來實現軟件包管理,Helm是Kubernetes的官方子項目,做爲企業內部的應用管理是很是方便的,它使得開發者不用再去關注Kubernetes自己而只須要專一於應用開發就夠了。
從官方下載的鏡像都會有默認時區,通常咱們使用的時候都須要更改時區,更改時區的方式有多種,這裏簡單說兩種。一是將容器鏡像的/etc/loacltime根據須要設置爲對應的時區,二是採用配置文件中的volume掛載宿主機對應的localtime文件的方式。推薦採用第二種方式。
在沒有Ingress的時候咱們是使用內建Nginx容器來轉發集羣內部服務,如今則是經過Ingress轉發集羣內部服務,Ingress經過NodePort方式暴露給外網。
上圖展現的是Kubernetes的最佳組合,它以DevOps做爲基礎,上層是k8s加上Containers,頂層構築的是微服務應用。這樣的組合帶來的不只是一個容器雲,更多的是改變了研發流程和組織結構,這主要是受微服務的架構思想影響。
過去完成一個應用的版本發佈可能要多人協同,一旦有緊急發佈的時候就會發現這實際上是很是笨重的。可是若是是基於微服務架構作的應用,每每一到兩我的就能夠維護一個微服務,他們本身就能夠決定這個微服務是否獨立部署上線。
關於微服務和Kubernetes還有一個優點必需要強調,配合CI/CD開發人員終於能夠再也不考慮部署環境的細節了。