1.k8s陳述資源管理方法的說明

1.1 管理k8s核心資源的三種基本方法?

陳述式資源管理方法

--主要依賴命令行工具kubectl進(jìn)行管理
優(yōu)點(diǎn)
可以滿足90%以上的使用場景
對資源的增、刪、查操作比較容易

缺點(diǎn)
命令冗長，復(fù)雜，難以記憶
特定場景下，無法實(shí)現(xiàn)管理需求
對資源的修改麻煩，需要patch來使用json串更改。

聲明式資源管理方法

主要依賴統(tǒng)一資源配置清單進(jìn)行管理

GUI式資源管理方法

主要依賴圖形化操作界面進(jìn)行管理

1.2 kubectl命令行工具 的說明

k8s在2.0 版本后就增加kubectl自動(dòng)補(bǔ)全

二進(jìn)制安裝的k8s,kubectl工具沒有自動(dòng)補(bǔ)全功能(其他方式安裝的未驗(yàn)證),可以使用以下方式開啟命令自動(dòng)補(bǔ)全

vim /etc/bashrc
source <(kubectl completion bash)
?
?
su

??2.k8s集群中的基本信息查看

2.1? k8s中基本管理信息的查看?

（1）查看版本信息

kubectl version

（2）查看資源對象簡寫

kubectl api-resources?

（4）node節(jié)點(diǎn)查看日志

journalctl -u kubelet -f

2.2???k8s基本信息查看

1）獲取資源信息

?
kubectl get <resource> [-o wide | json | yaml] [-n namespace]
獲取資源的相關(guān)信息，-n指定命令空間，-o指定輸出格式
resource可以是具體資源名稱，如pod nginx -xxx;也可以是資源類型，如pod; 或者all (僅展示幾種核心資源，并不完整)
--all-namespaces 或-A :表示顯示所有命令空間，
--show-labels :顯示所有標(biāo)簽
-l app:僅顯示標(biāo)簽為app的資源
-l app=nginx :僅顯示包含app標(biāo)簽， 且值為nginx的資源

（2）查看master節(jié)點(diǎn)狀態(tài)?

kubectl get componentstatuses
kubectl get cs

（3）?查看命令空間

kubectl get namespaces
kubectl get ns

（4）查看default命名空間的所有資源?

2.3 k8s資源的基本管理?

?（1）?創(chuàng)建命名空間

kubectl create ns test
kubectl get ns

（2）刪除命名空間?

（3）?在命名空間中創(chuàng)建副本控制器來啟動(dòng)Pod?

kubectl create deployment nginx-test --image=nginx -n kube-public
kubectl get pod -n kube-public

（4） 查看指定資源的詳細(xì)信息?

?
kubectl describe deployment nginx-test -n kube-public
kubectl describe pod nginx-test-795d659f45-hnpnm ?-n kube-public

（5）?查看命名空間中的pod信息?

kubectl get pods -n ?kube-system

（6） 跨主機(jī)登錄容器

kubectl exec -it nginx-test-795d659f45-qf84v bash -n kube-public

（7）pod資源的刪除?

kubectl get pods -n kube-public?
?
kubectl delete pod nginx-test-795d659f45-hnpnm ?-n kube-public?
?
kubectl get pods -n kube-public?

（8）強(qiáng)行刪除pod?

kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0

#grace-period表示過渡存活期，默認(rèn)30s，在刪除pod之前允許POD慢慢終止其上的容器進(jìn)程，從而優(yōu)雅退出，0表示立即終u止pod

（9） 對相同的pod數(shù)進(jìn)行增加，減少?

擴(kuò)容
kubectl scale deployment nginx-test --replicas=3 -n kube-public
s縮容
kubectl scale deployment nginx-test --replicas=1 -n kube-public

（10）刪除副本控制器

?
kubectl delete deployment nginx-test -n kube-public
或者
kubectl delete deployment/nginx-test -n kube-public
?
#這里的/ ?相當(dāng)于是 空格 也有著隔開說明關(guān)系的作用

?（11）特列創(chuàng)建的方式

kubectl 創(chuàng)建pod 又被稱為 自助式的創(chuàng)建，run的創(chuàng)建每次只能創(chuàng)建一個(gè)pod（不能被擴(kuò)容和縮容），且不受pod控制器的管理。也就是當(dāng)pod被刪除后，不再被拉起。?

kubectl ?run ?nginx ?--images=nginx

3. 項(xiàng)目的生命周期管理

對于一個(gè)k8s的項(xiàng)目，它的聲明周期大致可以分為以下幾個(gè)步驟：

創(chuàng)建 —>> 發(fā)布 —>> 更新 —>> 回滾 —>> 刪除

3.1 創(chuàng)建項(xiàng)目?

創(chuàng)建并運(yùn)行一個(gè)或多個(gè)容器鏡像
創(chuàng)建一個(gè)deployment或job來管理容器
kubectl run --help或則 kubectl run -h
?
//啟動(dòng)nginx 實(shí)例，暴露容器端口80，設(shè)置副本數(shù)3
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
?
kubectl get pods
kubectl get all

3.2 發(fā)布項(xiàng)目?

?
1.將資源暴露為新的Service
kubectl expose --help
?
2.為deployment的nginx創(chuàng)建service，并通過Service的80端口轉(zhuǎn)發(fā)至容器的80端口上，Service的名稱為nginx-service，類型為NodePort
kubectl expose deployment nginx?--port=8000 --target-port=80 --name=nginx-service --type=NodePort
==========================================================
Kubernetes之所以需要Service， 一方面是因?yàn)镻od的IP 不是固定的(Pod可能會(huì)重建)，另一方面則是因?yàn)橐唤MPod實(shí)例之間總會(huì)有負(fù)載均衡的需求。Service通過label Selector實(shí)現(xiàn)的對一組的Pod的訪問。
對于容器應(yīng)用而言，Kubernetes 提供了基于VIP (虛擬IP)的網(wǎng)橋的方式訪問 Service， 再由Service 重定向到相應(yīng)的Pod。
?
service類型:
●ClusterIP:提供一個(gè)集群內(nèi)部的虛擬IP以供Pod訪問( service默認(rèn)類型)
●NodePort:在每個(gè)Node.上打開一個(gè)端口以供外部訪問，Kubernetes將會(huì)在每個(gè)Node.上打開一個(gè)端口并且每個(gè)Node的端口都是一樣的，通過NodeIp:NodePort的方式Kubernetes集群外部的程序可以訪問Service。
注:每個(gè)端口只能是一種服務(wù)，端口范圍只能是30000-32767
●LoadBalancer:通過外部的負(fù)載均衡器來訪問，通常在云平臺(tái)部署LoadBalancer還需要額外的費(fèi)用。
==========================================================
3.查看pod網(wǎng)絡(luò)狀態(tài)詳細(xì)信息和Service暴露的端口
kubectl get pods,svc -o wide
?
4.查看關(guān)聯(lián)后端的節(jié)點(diǎn)
kubectl get endpoints
?
5.查看service的描述信息
kubect1 describe svc nginx-app
?

6.分半在node01和node02節(jié)點(diǎn)上操作，查看負(fù)載均衡端口
yum install ipvsadm -y
ipvsadm -Ln

7.在master01主節(jié)點(diǎn)分別在3個(gè)pod內(nèi)寫入網(wǎng)頁文件

kubectl get pods

kubectl exec -it nginx-app-64ffbd575f-7hjxn ?bash
echo "<h1>this is test1</h1>" > /usr/share/nginx/html/index.html
kubectl exec -it nginx-app-64ffbd575f-bs29c bash
echo "<h1>this is test2</h1>" > /usr/share/nginx/html/index.html
kubectl exec -it nginx-app-64ffbd575f-r49dt ?bash
echo "<h1>this is test3</h1>" >/usr/share/nginx/html/index.html
?
8.瀏覽器訪問clusterip和nodeport

curl 10.96.76.164:8000
curl 192.168.73.105:31539
curl 192.168.73.106:31539
curl 192.168.73.107:31539
?
?
?
8.在master01操作 查看訪問日志
kubectl logs nginx-app-64ffbd575f-7hjxn
kubectl logs nginx-app-64ffbd575f-bs29c?
kubectl logs nginx-app-64ffbd575f-r49dt

3.3 項(xiàng)目的更新?

?（1）查看資源模板的使用

kubectl set --help
?
//獲取修改模板
kubectl set image --help
?

（2）進(jìn)行項(xiàng)目中應(yīng)用的版本更新?

#查看當(dāng)前pod中nginx的版本號
curl -I 192.168.73.105:31539
curl -I 192.168.73.106:31539
curl -I 192.168.73.107:31539
?

#版本更替
kubectl set image deployment/nginx?nginx=nginx:1.16
?

?
#版本更替前，可以開啟一個(gè)新的終端，對pod進(jìn)行動(dòng)態(tài)追蹤，觀察pod的變化
kubectl get pods -w
?

curl -I 192.168.73.105:31539
curl -I 192.168.73.106:31539
curl -I 192.168.73.107:31539

3.4 項(xiàng)目的回滾?

每一個(gè)的項(xiàng)目版本更新都會(huì)經(jīng)過測試，并不是所有的新版本都會(huì)優(yōu)于舊版版，為了防止更新后，發(fā)現(xiàn)新版的服務(wù)優(yōu)化不如舊版本，此時(shí)后悔。所以k8s在項(xiàng)目中設(shè)置了回滾功能?

（1）查看歷史回滾點(diǎn)?

kubectl rollout history deployment/nginx-app

（2）進(jìn)行回滾?

#回滾到上一個(gè)回滾點(diǎn)中
kubectl rollout undo deployment/nginx
?
#進(jìn)行指定回滾點(diǎn)回滾
kubectl rollout undo deployment/nginx?--to-revision=3

3.5 進(jìn)行項(xiàng)目的刪除?

1.刪除副本控制器
kubectl delete deployment.apps/nginx-app
?
2.刪除service資源
kubectl delete service/nginx-service
?
kubectl get all

?4. 三種常用的項(xiàng)目發(fā)布方式

應(yīng)用程序升級面臨最大挑戰(zhàn)是新舊業(yè)務(wù)切換，將軟件從測試的最后階段帶到生產(chǎn)環(huán)境，同時(shí)要保證系統(tǒng)不間斷提供服務(wù)。而最為常見三種發(fā)布方式分別為：藍(lán)綠發(fā)布，灰度發(fā)布和滾動(dòng)發(fā)布。

三種發(fā)布方式的最終目的都是為了減小或避免對應(yīng)用項(xiàng)目更新時(shí)，對客戶使用的影響。

4.1 ?藍(lán)綠發(fā)布?

?首先將所有的應(yīng)用服務(wù)集群為藍(lán)綠兩組，首先將綠組的集群從負(fù)載均衡中移除，藍(lán)組則繼續(xù)對用戶提供服務(wù)。此時(shí)移除的綠組進(jìn)行服務(wù)的升級，等升級完畢后，再從新將綠組接入到負(fù)載均衡中為用戶提供服務(wù)。

再把藍(lán)組進(jìn)行移除，進(jìn)行服務(wù)升級，升級完畢后再接入到負(fù)載均衡的集群中。此時(shí)整個(gè)項(xiàng)目集群得進(jìn)行升級完畢，我們將此稱為藍(lán)綠發(fā)布
?

特點(diǎn)

如果出問題，影響范圍較大；

發(fā)布策略簡單；

用戶無感知，平滑過渡；

升級/回滾速度快。

缺點(diǎn)

需要準(zhǔn)備正常業(yè)務(wù)使用資源的兩倍以上服務(wù)器，防止升級期間單組無法承載業(yè)務(wù)突發(fā)；

短時(shí)間內(nèi)浪費(fèi)一定資源成本；

基礎(chǔ)設(shè)施無改動(dòng)，增大升級穩(wěn)定性。

藍(lán)綠發(fā)布在早期物理服務(wù)器時(shí)代，還是比較昂貴的，由于云計(jì)算普及，成本也大大降低。
?

4.2 灰度發(fā)布?

灰度發(fā)布又叫金絲雀發(fā)布，灰度是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式（為什么叫金絲雀發(fā)布（Canary）？以前，曠工開礦，在下礦洞前需要檢查下方是否有毒氣，礦工們先會(huì)放一只金絲雀進(jìn)去探是否有有毒氣體，看金絲雀能否活下來。）

該過程類似于游戲中的體驗(yàn)服，首先會(huì)讓一部分用戶進(jìn)行使用測試，如果沒什么問題后，會(huì)逐步面積推廣，徹底替代舊的版本?
?

特點(diǎn)

• 保證整體系統(tǒng)穩(wěn)定性，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問題，影響范圍可控；

• 新功能逐步評估性能，穩(wěn)定性和健康狀況，如果出問題影響范圍很小，相對用戶體驗(yàn)也少；

• 用戶無感知，平滑過渡。

缺點(diǎn)

• 自動(dòng)化要求高

4.3?滾動(dòng)發(fā)布?

? ? ? 滾動(dòng)發(fā)布就是剛剛我們在k8s中使用的項(xiàng)目服務(wù)更新方式。滾動(dòng)發(fā)布是指每次只升級一個(gè)或多個(gè)服務(wù)，升級完成后加入生產(chǎn)環(huán)境，不斷執(zhí)行這個(gè)過程，直到集群中的全部舊版本升級新版本。??

特點(diǎn)

• 用戶無感知，平滑過渡；

• 節(jié)約資源。

缺點(diǎn)

• 部署時(shí)間慢，取決于每階段更新時(shí)間；

• 發(fā)布策略較復(fù)雜；

• 無法確定OK的環(huán)境，不易回滾。

三種方式的對比總結(jié)

• 藍(lán)綠發(fā)布：兩套環(huán)境交替升級，舊版本保留一定時(shí)間便于回滾。

• 灰度發(fā)布：根據(jù)比例將老版本升級，例如80%用戶訪問是老版本，20%用戶訪問是新版本。

• 滾動(dòng)發(fā)布：按批次停止老版本實(shí)例，啟動(dòng)新版本實(shí)例。

5. 金絲雀發(fā)布方式的運(yùn)用?

?Deployment控制器支持自定義控制更新過程中的滾動(dòng)節(jié)奏，如“暫停(pause)”或“繼續(xù)(resume)”更新操作。比如等待第一批新的Pod資源創(chuàng)建完成后立即暫停更新過程，此時(shí)，僅存在一部分新版本的應(yīng)用，主體部分還是舊的版本。然后，再篩選一小部分的用戶請求路由到新版本的Pod應(yīng)用，繼續(xù)觀察能否穩(wěn)定地按期望的方式運(yùn)行。確定沒問題之后再繼續(xù)完成余下的Pod資源滾動(dòng)更新，否則立即回滾更新操作。這就是所謂的金絲雀發(fā)布。
?

（1）進(jìn)行金絲雀的更新方式

?
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
? ?
kubectl expose deployment nginx --port=8000 --target-port=80 --name=nginx-service --type=NodePort ?#先創(chuàng)建資源并創(chuàng)建3個(gè)副本
?
kubectl set image deployment nginx nginx=nginx:1.16 && kubectl rollout pause deployment nginx ? ? ?#更新并暫停
?
kubectl rollout status deployment nginx ? ?#觀察更新狀態(tài)

（2）?監(jiān)控更新的過程

可以看到已經(jīng)新增了一個(gè)資源，但是并未按照預(yù)期的狀去刪除一個(gè)舊的資源，就是因?yàn)槭褂昧藀ause暫停命令
kubectl get pods,svc -o wide
kubectl get pods -w
curl -I 192.168.73.106:31589

（3）繼續(xù)更新?

kubectl rollout resume deployment nginx

總結(jié)?

1.查看版本信息
kubectl version
?
2.查看資源對象簡寫
kubectl api-resources?
?
3.查看集群信息
kubectl cluster-info
?
4.配置kubectl自動(dòng)補(bǔ)全
source <(kubectl completion bash)
?
5.node節(jié)點(diǎn)查看日志
journalctl -u kubelet -f
?
?
創(chuàng)建
kubectl create 控制器
kubectl run 自助式
kubectl scale --replicas=
?
發(fā)布，創(chuàng)建 service
kubectl expose
?
更新
kubectl set image
?
回滾
kubectl rollout undo
?
刪除
kubectl delete 控制器|pod ...
?
查看資源狀態(tài)
kubectl get ... -o wide [-l 標(biāo)簽] [--show-lables] [-n ...] [-A] -w
?
查看詳細(xì)信息
kubectl describe
?
查看日志
kubectl logs
?
進(jìn)入pod容器
kubectl exec -it
?
查看資源縮寫
kubectl api-resource
?
灰度發(fā)布/金絲雀發(fā)布
kubectl set image ... && kubectl rollout pause（暫停操作） ...
?
如果驗(yàn)證沒有問題
kubectl rollout resume（恢復(fù)操作）
滾動(dòng)更新
先更新一部分（個(gè)數(shù)|比例默認(rèn)25%）pod資源，更新完畢后再刪除一部分資源文章來源地址http://www.zghlxwxcb.cn/news/detail-520148.html

到了這里，關(guān)于【云原生】k8s中kubectl陳述式資源管理的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！