徹底搞懂K8S相關知識
相信很多人對他的名字都不陌生,但是很多人卻把他和docker相關的關系分不清,也沒有搞懂它到底是用來做什么的,能幫助我們解決哪些問題,今天我就給大家詳細的講一下。
K8S,它的全稱,是kubernetes,Kubernetes 這個單詞來自于希臘語,含義是舵手或領航員。K8S是它的縮寫,用“8”字替代了“ubernete”這8個字符,所有我們一般都會叫它k8s,和Docker不同,K8S的創造者,是大名鼎鼎行業巨頭谷歌,K8S并不是一件全新的發明。它的前身,是Google自己搗鼓了十多年的Borg系統,K8S是2014年6月由Google公司正式公布出來并宣布開源的。
k8s和docker有什么關系
我們都知道隨著docker人氣迅速攀升,越來越多的公司和開發者都把自己公司的業務遷移到docker容器平臺,這樣以來很多人就發現一個問題,自己公司業務一臺docker容器根本沒有辦法滿足當前需求,這時候我們首先想到的就是增加服務器,在每臺服務器都安裝docker容器,如果你的服務拆分不是很多這樣的確可以解決當前問題,但是如果有上百個微服務,你還是用以前方式管理docker那就非常吃力了,這時候我們可能會想,有沒有一款能把所有docker容器進行統一管理的平臺,沒錯k8s是為容器服務而生的一個可移植容器的編排管理工具,越來越多的公司正在擁抱k8s,并且當前k8s已經主導了云業務流程,推動了微服務架構等熱門技術的普及和落地。
說白了k8s就是用來管理docker容器的,以前我們運行一個容器都是直接調用docker創建容器的,這樣以來隨著docker實力越來越多我們維護就非常困難了,假設我現在有30多個服務,如果沒有用容器編排工具我們就需要自己計算每個服務占用多少空間,一個docker容器部署多少個服務,這些都是需要提前計算好的,但是隨著我們系統訪問量不斷增加,可能以前只4g運行內存的現在可能需要調整到8g,那以前節點明顯就不夠用了,我們就需要手動部署到新機器上去,如果你使用了k8s,你只需要把新的節點加入k8s集群,剩下的工作就都是交給k8s來幫你完成了。
k8s能幫我們做什么
版本回退
我們都知道只要是程序就可能存在bug,如果發現新發布的程序版本有問題,我們可以立即回退到原來的版本。
服務自愈
k8s默認會有監控檢查機制,說白了就是不斷的curl你服務的端口發現不通或者其他異常問題,一旦某一個容器崩潰,能夠快速速啟動新的容器。
彈性伸縮
當我們某個服務訪問量比較高的時候發現一個節點已經無法正常處理我們業務請求了,我們可以動態的調整pod數量達實現擴容效果,如果某個服務訪問不高我們就可以減少pod數量實現動態擴容,而且k8s實現擴容和縮容是非常簡單的只需要一條命令即可搞定。
負載均衡
如果由于某個服務訪問量比較高,那么相當于一個服務起動了多個容器,如果我們用傳統方式肯定還需要使用nginx相關的負載均衡中間件,但是如果使用了k8s能自動實現請求的負載均衡。
存儲卷掛載
如果你項目中有使用nfs或者其它文件系統存儲文件,我們可以直接在k8s創建存儲卷掛著nfs了,比較常見的就是我們服務是微服務項目我們的文件存儲系統和文件分析系統是兩個服務這時候我們就可以掛著nfs,兩個服務使用同一個文件系統效果。
再帶大家認識一下k8s基本架構
?一個k8s集群主要是由控制節點(master)、工作節點(node)構成,每個節點上都會安裝不同的組件。
master節點主要負責集群的管理 ,master節點包含以下組件。
- ApiServer : 資源操作的唯一入口,接收用戶輸入的命令,提供認證、授權、API注冊和發現等機制。
- Scheduler : 負責集群資源調度,按照預定的調度策略將Pod調度到相應的node節點上。
- ControllerManager : 負責維護集群的狀態,比如程序部署安排、故障檢測、自動擴展、滾動更新等。
- Etcd :負責存儲集群中各種資源對象的信息。
node節點負責為容器提供運行環境,也就是正在干活的節點。
- Kubelet : 負責維護容器的生命周期,即通過控制docker,來創建、更新、銷毀容器
- KubeProxy : 負責提供集群內部的服務發現和負載均衡
- Docker : 負責節點上容器的各種操作
以部署一個Nginx服務來說明Kubernetes系統各個組件調用關系。
- 首先需要明確,一旦Kubernetes環境啟動之后,master和node都會將自身的信息存儲到etcd數據庫中。
- 一個Nginx服務的安裝請求首先會被發送到master節點上的API Server組件。
- API Server組件會調用Scheduler組件來決定到底應該把這個服務安裝到那個node節點上。此時,它會從etcd中讀取各個node節點的信息,然后按照一定的算法進行選擇,并將結果告知API Server。
- API Server調用Controller-Manager去調用Node節點安裝Nginx服務。
- Kubelet接收到指令后,會通知Docker,然后由Docker來啟動一個Nginx的Pod。Pod是Kubernetes的最小操作單元,容器必須跑在Pod中。
- 一個Nginx服務就運行了,如果需要訪問Nginx,?就需要通過kube-proxy來對Pod產生訪問的代理,這樣,外界用戶就可以訪問集群中的Nginx服務了
最后我們再來了解一下k8s核心概念
官網提供架構圖
Master:集群控制節點,每個集群需要至少一個master節點負責集群的管控。
Node:工作負載節點,由master分配容器到這些node工作節點上,然后node節點上的docker負責容器的運行。
Pod:kubernetes的最小控制單元,容器都是運行在pod中的,一個pod中可以有1個或者多個容器。
Controller:控制器,通過它來實現對pod的管理,比如啟動pod、停止pod、伸縮pod的數量等等。
Service:pod對外服務的統一入口,下面可以維護者同一類的多個pod。
Label:標簽,用于對pod進行分類,同一類pod會擁有相同的標簽。
NameSpace:命名空間,用來隔離pod的運行環境。
Linux常用命令
查看節點信息
namespace創建/刪除
在k8s運行pod
Pod運行中的一組容器,Pod是kubernetes中應用的最小單位。
示例:運行一個名稱為nginx,副本數為3,標簽為app=example,鏡像為nginx:1.10,端口為80的容器實例。
查看容器內所有pod
顯示pod節點的標簽信息
根據指定標簽匹配到具體的pod
查看pod創建詳細過程
查看指定pod的信息
查看pod詳細信息
查看pod日志,其實就查看服務本身日志,類似docker logs
指定時間段輸出日志
指定時間戳輸出日志
進入容器里面里面
Service概念
我們已經能夠利用Deployment來創建一組Pod來提供具有高可用性的服務,雖然每個Pod都會分配一個單獨的Pod的IP地址,但是卻存在如下的問題:
Pod的IP會隨著Pod的重建產生變化。
Pod的IP僅僅是集群內部可見的虛擬的IP,外部無法訪問。
創建集群內部可訪問的Service
kubectl expose deployment xxx --name=服務名 --type=ClusterIP --port=暴露的端口 --target-port=指向集群中的Pod的端口 [-n 命名空間]。
會產生一個CLUSTER-IP,這個就是service的IP,在Service的生命周期內,這個地址是不會變化的。
查看Service
創建集群外部可訪問的Service
kubectl expose deployment xxx --name=服務名 --type=NodePort --port=暴露的端口 --target-port=指向集群中的Pod的端口 [-n 命名空間]
擴縮容
更新鏡像
將deployment中的nginx容器鏡像設置為“nginx:1.9.1”。
版本回退
歷史記錄。
查看某個歷史詳情。
回滾(回到上次)。
回滾(回到指定版本)。