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常用命令
檢視節點資訊
kubectl get node
namespace建立/刪除
kubectl create ns ${空間名稱}
kubectl delete ns ${空間名稱}
在k8s執行pod
Pod執行中的一組容器,Pod是kubernetes中應用的最小單位
示例:執行一個名稱為nginx,副本數為3,標籤為app=example,映象為nginx:1.10,埠為80的容器例項
kubectl run nginx --replicas=3 --labels="app=example" --image=nginx:1.10 --port=80
檢視容器內所有pod
kubectl get pod -A
顯示pod節點的標籤資訊
kubectl get pod --show-labels
根據指定標籤匹配到具體的pod
kubectl get pods -l app=example
檢視pod建立詳細過程
kubectl describe pod ${pod名稱} -n ${空間名稱}
檢視指定pod的資訊
kubectl get pod ${pod名稱} -n ${空間名稱}
檢視pod詳細資訊
kubectl get pod -o wide
檢視pod日誌,其實就檢視服務本身日誌,類似docker logs
kubectl logs ${pod名稱} -n ${空間名稱}
指定時間段輸出日誌
kubectl logs ${pod名稱} --since=1h
指定時間戳輸出日誌
kubectl logs ${pod名稱} --since-time=2022-12-01T15:00:00Z
進入容器裡面裡面
kubectl exec -ti ${pod名稱} /bin/bash
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的生命週期內,這個地址是不會變化的
kubectl expose deployment nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n test
檢視Service
kubectl get svg [-n 名稱空間] [-o wide]
建立叢集外部可訪問的Service
kubectl expose deployment xxx --name=服務名 --type=NodePort --port=暴露的埠 --target-port=指向叢集中的Pod的埠 [-n 名稱空間]
kubectl expose deploy nginx --name=svc-nginx2 --type=NodePort --port=80 --target-port=80 -n test
擴縮容
kubectl scale --replicas=5 deployment/my-nginx
kubectl edit deployment my-nginx
更新映象
將deployment中的nginx容器映象設定為“nginx:1.9.1”
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
版本回退
歷史記錄
kubectl rollout history deployment ${pod名稱}
檢視某個歷史詳情
kubectl rollout history deployment my-nginx--revision=2
回滾(回到上次)
kubectl rollout undo deployment ${pod名稱}
回滾(回到指定版本)
kubectl rollout undo deployment my-nginx--to-revision=2