目錄
一、理論
1.K8S資源管理方法
2.kubectl 管理命令
3.項目的生命周期
4.Kubernetes 服務發(fā)布方式
5.金絲雀發(fā)布(Canary Release)部署
6.聲明式管理方法
二、實驗
?1.kubectl 管理命令
2.項目的生命周期
3.金絲雀發(fā)布(Canary Release)部署
4.聲明式管理方法
三、問題
1.為何每個pod有兩個標簽
四、總結
一、理論
1.K8S資源管理方法
（1）管理K8S資源的三種基本方法：
① 陳述式資源管理方法-使用cli工具進行管理。
② 聲明式資源管理方式-主要依耐資源配置清單。
③ GUI式資源管理方法-主要依耐圖形界面。2.kubectl 管理命令
（1）陳述式資源管理方法
kubernetes集群管理集群資源的唯一入口是通過相應的方法調用apiserver的接口
kubectl 是官方的CLI命令行工具，用于與apiserver 進行通信，將用戶在命令行輸入的命令，組織并轉化為apiserver能識別的信息，進而實現(xiàn)管理k8s 各種資源的一種有效途徑
kubectl 的命令大全：?kubectl --help
對資源的增、刪、查操作比較方便，但對改的操作就不容易了
?
①?查看版本信息
kubectl version
②看資源對象簡寫
kubectl api-resources
③查查看集群信息
kubectl cluster-info
④配置kubectl自動補全
source <(kubectl completion bash)
注意：此時命令補全功能切換環(huán)境后是不生效的，如果要使切換環(huán)境后也生效需要配置全局環(huán)境變量
vim /etc/bashrc
.....
source <(kubectl completion bash) #在底部添加⑤?node節(jié)點查看日志
journalctl -u kubelet -f
或者直接查看日志
cat /var/log/messages(2)??基本信息查看
①獲取資源的相關信息
獲取資源的相關信息，-n指定命令空間，-o指定輸出格式
resource可以是具體資源名稱，如pod nginx -xxx;也可以是資源類型，如pod; 或者all (僅展示幾種核心資源，并不完整)
--all-namespaces 或-A :表示顯示所有命令空間，
--show-labels :顯示所有標簽
-l app:僅顯示標簽為app的資源
-l app=nginx :僅顯示包含app標簽， 且值為nginx的資源
kubectl get <resource> [-o wide | json | yaml] [-n namespace]
②查看master 節(jié)點狀態(tài)
kubectl get componentstatuses
kubectl get cs③查看命令空間
命令空間的作用:用于允許不同 命令空間的相同類型的資源重名
kubectl get namespace
kubectl get ns④查看default命名空間的所有資源
kubectl get all -n default
⑤?創(chuàng)建命名空間 (app)
kubectl create ns app
kubectl get ns⑥刪除命名空間(app)
kubectl delete namespace app
kubectl get ns⑦?在命名空間創(chuàng)建副本控制器啟動Pod
例：在命名空間kube-public 創(chuàng)建副本控制器( deployment) 來啟動Pod (nginx-w1)、(nginx-cc)
kubectl create deployment nginx-wl --image=nginx -n kube-public
kubectl create deployment nginx-cc --image=nginx -n kube-public⑧描述某個資源的詳細信息
kubectl describe deployment nginx-wl -n kube-public
kubectl describe pod nginx-wl-647d7fff95 -n kube-public
kubectl describe deployment nginx-cc -n kube-public
kubectl describe pod nginx-cc-5d7d5c6b54 -n kube-public⑨?查看命名空間kube-public中的pod信息
kubectl get pods -n kube-public
⑩?kubectl exec
kubectl exec可以跨主機登錄容器，docker exec 只能在容器所在主機上登錄
kubectl exec -it nginx-cc-5d7d5c6b54-454mx bash -n kube-public??重啟（刪除）pod資源
由于存在deployment/rc之類的副本控制器，刪除pod也會重新拉起來
kubectl delete pod nginx-cc-5d7d5c6b54-454mx -n kube-public
若pod無法刪除，總是處于terminate狀態(tài)， 則要強行刪除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示過渡存活期，默認30s，在刪除pod之前允許POD慢慢終止其上的容器進程，從而優(yōu)雅退出，0表示立即終止pod???擴容縮容
kubectl scale deployment nginx-cc --replicas=2 -n kube-public #擴容
kubectl scale deployment nginx-cc --replicas=1 -n kube-public #縮容? ?刪除副本控制器
kubectl delete deployment nginx-cc -n kube-public
kubectl delete deployment/nginx-cc -n kube-public3.項目的生命周期
(1)? 聲明周期
創(chuàng)建–>發(fā)布–>更新–>回滾–>刪除（2）創(chuàng)建kubectl run命令
創(chuàng)建并運行一個或多個容器鏡像
創(chuàng)建一個deployment或job來管理容器
kubectl run --help
啟動nginx 實例，暴露容器端口80，設置副本數(shù)3
kubectl run nginx --image=nginx:1.14 --port=80 --replicas=3
kubectl get pods
kubectl get all（3）發(fā)布kubectl expose命令
將資源暴露為新的Service
kubectl expose --help
為deployment的nginx創(chuàng)建service， 并通過Service的80端口轉發(fā)至容器的80端口上，Service的名稱為nginx-service， 類型為NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
Kubernetes之所以需要Service， 一方面是因為Pod的IP 不是固定的(Pod可能會重建)，另一-方面則是因為- -組Pod
實例之間總會有負載均衡的需求。
Service通過label Selector實現(xiàn)的對一組的Pod的訪問。
對于容器應用而言，Kubernetes 提供了基于VIP (虛擬IP)的網(wǎng)橋的方式訪問 Service， 再由Service 重定向到相應的Pod。
service的類型:
●ClusterIP:提供一個集群內部的虛擬IP以供Pod訪問( service默認類型)
●NodePort:在每個Node.上打開一個端口以供外部訪問，Kubernetes將會在每個Node.上打開一個端口并且每個Node的端口都是一樣的，通過NodeIp:NodePort的方式Kubernetes集群外部的程序可以訪問Service。
注:每個端口只能是一種服務，端口范圍只能是30000-32767
●LoadBalancer:通過外部的負載均衡器來訪問，通常在云平臺部署LoadBalancer還需要額外的費用。查看pod網(wǎng)絡狀態(tài)詳細信息和Service暴露的端口
kubectl get pods,svc -o wide
查看關聯(lián)后端的節(jié)點
kubectl get endpoints
查看service 的描述信息
kubect1 describe svc nginx
在node01 節(jié)點上操作，查看負載均衡端口
yum install ipvsadm -y
ipvsadm -Lncurl 10.1.10.182
curl 192.168.204.173:31462在master01操作 查看訪問日志
kubectl logs nginx-65fc77987d-65j99
kubectl logs nginx-65fc77987d-m4jsj
kubectl logs nginx-65fc77987d-vqpds （4）更新kubectl?set
更改現(xiàn)有應用資源一些信息
kubectl set --help
獲取修改模板
kubectl set image --help
查看當前nginx 的版本號
curl -I http://192.168.204.171:31462
curl -I http://192.168.204.173:31462將nginx 版本更新為1.15版本
kubectl set image deployment/nginx nginx=nginx:1.15
處于動態(tài)監(jiān)聽pod狀態(tài)，由于使用的是滾動更新方式，所以會先生成--個新的pod，然后刪除--個舊的pod，往后依次類推（動態(tài)更新的）
kubectl get pods -w再看更新好后的Pod的ip會改變
kubectl get pods -o wide
再看nginx 的版本號
curl -I http://192.168.204.173:31462
curl -I http://192.168.204.175:31462（5）回滾kubectl?rollout
對資源進行回滾管理
kubectl rollout --help
查看歷史版本
kubectl rollout history deployment/nginx
執(zhí)行回滾到上一個版本
kubectl rollout undo deployment/nginx
執(zhí)行回滾到指定版本
kubectl rollout undo deployment/nginx --to-revision=2
檢查回滾狀態(tài)
kubectl rollout status deployment/nginx
（6）刪除kubectl delete
刪除副本控制器
kubectl delete deployment/nginx
刪除service
kubectl delete svc/nginx-service
kubectl get all4.Kubernetes 服務發(fā)布方式
（1）方式
應用程序升級面臨最大挑戰(zhàn)是新舊業(yè)務切換，將軟件從測試的最后階段帶到生產環(huán)境，同時要保證系統(tǒng)不間斷提供服務。而最為常見三種發(fā)布方式分別為：藍綠發(fā)布，灰度發(fā)布和滾動發(fā)布。
三種發(fā)布方式的最終目的都是為了減小或避免對應用項目更新時，對客戶使用的影響，盡可能避免因發(fā)布導致的流量丟失或服務不可用問題。
?
（2）藍綠發(fā)布
首先將所有的應用服務集群為藍綠兩組，首先將綠組的集群從負載均衡中移除，藍組則繼續(xù)對用戶提供服務。此時移除的綠組進行服務的升級，等升級完畢后，再從新將綠組接入到負載均衡中為用戶提供服務。
再把藍組進行移除，進行服務升級，升級完畢后再接入到負載均衡的集群中。此時整個項目集群得進行升級完畢，我們將此稱為藍綠發(fā)布。
項目邏輯上分為AB組，在項目系統(tǒng)時，首先把A組從負載均衡中摘除，進行新版本的部署。B組仍然繼續(xù)提供服務。
當A組升級完畢，負載均衡重新接入A組，再把B組從負載列表中摘除，進行新版本的部署。A組重新提供服務。
最后，B組也升級完成，負載均衡重新接入B組，此時，AB組版本都已經(jīng)升級完成，并且都對外提供服務。
特點：
如果出問題，影響范圍較大；
發(fā)布策略簡單；
用戶無感知，平滑過渡；
升級/回滾速度快。
缺點：
需要準備正常業(yè)務使用資源的兩倍以上服務器，防止升級期間單組無法承載業(yè)務突發(fā)；
短時間內浪費一定資源成本；
基礎設施無改動，增大升級穩(wěn)定性。藍綠發(fā)布在早期物理服務器時代，還是比較昂貴的，由于云計算普及，成本也大大降低。
（3）灰度發(fā)布（金絲雀發(fā)布）
灰度發(fā)布又叫金絲雀發(fā)布，灰度是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式（為什么叫金絲雀發(fā)布（Canary）？以前，曠工開礦，在下礦洞前需要檢查下方是否有毒氣，礦工們先會放一只金絲雀進去探是否有有毒氣體，看金絲雀能否活下來。）
該過程類似于游戲中的體驗服，首先會讓一部分用戶進行使用測試，如果沒什么問題后，會逐步面積推廣，徹底替代舊的版本
灰度發(fā)布只升級部分服務，即讓一部分用戶繼續(xù)用老版本，一部分用戶開始用新版本，如果用戶對新版本沒什么意見，那么逐步擴大范圍，把所有用戶都遷移到新版本上面來。
特點：
保證整體系統(tǒng)穩(wěn)定性，在初始灰度的時候就可以發(fā)現(xiàn)、調整問題，影響范圍可控；
新功能逐步評估性能，穩(wěn)定性和健康狀況，如果出問題影響范圍很小，相對用戶體驗也少；
用戶無感知，平滑過渡。
缺點：
自動化要求高
部署過程：
從LB摘掉灰度服務器，升級成功后再加入LB；
少量用戶流量到新版本；
如果灰度服務器測試成功，升級剩余服務器。
灰度發(fā)布是通過切換線上并存版本之間的路由權重，逐步從一個版本切換為另一個版本的過程。
（4）滾動發(fā)布
滾動發(fā)布是指每次只升級一個或多個服務，升級完成后加入生產環(huán)境，不斷執(zhí)行這個過程，直到集群中的全部舊版本升級新版本。
紅色：正在更新的實例
藍色：更新完成并加入集群的實例
綠色：正在運行的實例
特點：
用戶無感知，平滑過渡；
節(jié)約資源。
缺點：
部署時間慢，取決于每階段更新時間；
發(fā)布策略較復雜；
無法確定OK的環(huán)境，不易回滾。
部署過程：
先升級1個副本，主要做部署驗證；
每次升級副本，自動從LB上摘掉，升級成功后自動加入集群；
事先需要有自動更新策略，分為若干次，每次數(shù)量/百分比可配置；
回滾是發(fā)布的逆過程，先從LB摘掉新版本，再升級老版本，這個過程一般時間比較長；
自動化要求高。
5.金絲雀發(fā)布(Canary Release)部署
（1）概念
Deployment控制器支持自定義控制更新過程中的滾動節(jié)奏，如“暫停(pause)”或“繼續(xù)(resume)”更新操作。比如等待第一批新的Pod資源創(chuàng)
? ? ? ? 建完成后立即暫停更新過程，此時，僅存在一部分新版本的應用，主體部分還是舊的版本。然后，再篩選一小部分的用戶請求路由到新版本的Pod應用，繼續(xù)觀察能否穩(wěn)定地按期望的方式運行。確定沒問題之后再繼續(xù)完成余下的Pod資源滾動更新，否則立即回滾更新操作。這就是所謂的金絲雀發(fā)布。
?
（2）第一種方式（相同service）
更新deployment的版本，并配置暫停deployment
kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx
具體步驟：
[root@master ~]# kubectl run nginx --image=nginx:1.14 --port=80 --replicas=3
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/nginx created
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-65fc77987d-hxqww 1/1 Running 0 11s
nginx-65fc77987d-kj4kj 1/1 Running 0 11s
nginx-65fc77987d-n7v9h 1/1 Running 0 11s
nginx-deployment-6959f4b694-nds9n 1/1 Running 0 44h
nginx-deployment-6959f4b694-qm5p9 1/1 Running 0 44h
nginx-deployment-6959f4b694-qmpd6 1/1 Running 0 44h
[root@master ~]# kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
service/nginx-service exposed
[root@master ~]# kubectl set image deployment/nginx nginx=nginx:1.15
deployment.extensions/nginx image updated
[root@master ~]# kubectl get pods,svc -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/nginx-6cbd4b987c-6t2nt 1/1 Running 0 29s 10.244.2.11 node01 <none> <none>
pod/nginx-6cbd4b987c-bqtfp 1/1 Running 0 27s 10.244.1.16 node02 <none> <none>
pod/nginx-6cbd4b987c-g4xxm 1/1 Running 0 25s 10.244.1.17 node02 <none> <none>
pod/nginx-deployment-6959f4b694-nds9n 1/1 Running 0 44h 10.244.2.4 node01 <none> <none>
pod/nginx-deployment-6959f4b694-qm5p9 1/1 Running 0 44h 10.244.1.5 node02 <none> <none>
pod/nginx-deployment-6959f4b694-qmpd6 1/1 Running 0 44h 10.244.2.5 node01 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 2d3h <none>
service/nginx NodePort 10.1.110.139 <none> 80:32249/TCP 47h app=nginx
service/nginx-deployment NodePort 10.1.45.225 <none> 30000:30118/TCP 44h run=nginx-deployment
service/nginx-service NodePort 10.1.217.6 <none> 80:32755/TCP 51s run=nginx
[root@master ~]# curl -I http://192.168.204.173:32755
HTTP/1.1 200 OK
Server: nginx/1.15.12
Date: Wed, 06 Sep 2023 08:42:15 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Apr 2019 13:08:19 GMT
Connection: keep-alive
ETag: "5cb5d3c3-264"
Accept-Ranges: bytes
[root@master ~]# curl -I http://192.168.204.175:32755
HTTP/1.1 200 OK
Server: nginx/1.15.12
Date: Wed, 06 Sep 2023 08:42:18 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Apr 2019 13:08:19 GMT
Connection: keep-alive
ETag: "5cb5d3c3-264"
Accept-Ranges: bytes
[root@master ~]# kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx
deployment.extensions/nginx image updated
deployment.extensions/nginx paused
[root@master ~]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
nginx-65fc77987d-2b6b9 1/1 Running 0 8s
nginx-6cbd4b987c-6t2nt 1/1 Running 0 84s
nginx-6cbd4b987c-bqtfp 1/1 Running 0 82s
nginx-6cbd4b987c-g4xxm 1/1 Running 0 80s
nginx-deployment-6959f4b694-nds9n 1/1 Running 0 44h
nginx-deployment-6959f4b694-qm5p9 1/1 Running 0 44h
nginx-deployment-6959f4b694-qmpd6 1/1 Running 0 44h
^C[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-65fc77987d-2b6b9 1/1 Running 0 2m12s
nginx-6cbd4b987c-6t2nt 1/1 Running 0 3m28s
nginx-6cbd4b987c-bqtfp 1/1 Running 0 3m26s
nginx-6cbd4b987c-g4xxm 1/1 Running 0 3m24s
nginx-deployment-6959f4b694-nds9n 1/1 Running 0 45h
nginx-deployment-6959f4b694-qm5p9 1/1 Running 0 45h
nginx-deployment-6959f4b694-qmpd6 1/1 Running 0 45h
[root@master ~]# curl -I http://192.168.204.173:32755
HTTP/1.1 200 OK
Server: nginx/1.15.12
Date: Wed, 06 Sep 2023 08:45:09 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Apr 2019 13:08:19 GMT
Connection: keep-alive
ETag: "5cb5d3c3-264"
Accept-Ranges: bytes
[root@master ~]# curl -I http://192.168.204.175:32755
HTTP/1.1 200 OK
Server: nginx/1.15.12
Date: Wed, 06 Sep 2023 08:45:14 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Apr 2019 13:08:19 GMT
Connection: keep-alive
ETag: "5cb5d3c3-264"
Accept-Ranges: bytes
[root@master ~]# curl -I http://192.168.204.171:32755
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Wed, 06 Sep 2023 08:45:22 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 04 Dec 2018 14:44:49 GMT
Connection: keep-alive
ETag: "5c0692e1-264"
Accept-Ranges: bytes
[root@master ~]#
監(jiān)控更新的過程，可以看到已經(jīng)新增了一個資源，但是并未按照預期的狀態(tài)去刪除一個舊的資源， 就是因為使用了pause暫停命令
kubectl get pods -w
(2) 第二種方式（不同service）
#創(chuàng)建新的資源
kubectl create deployment nginx-cc --image=nginx:1.14 --port=80 --replicas=3
kubectl get pod
#創(chuàng)建新的資源
kubectl create deployment nginx-cc --image=nginx:1.14 --port=80 --replicas=3
kubectl get pod
#查看詳細信息
kubectl describe pod
#查看詳細信息
kubectl describe pod
#另開一個終端進行實時跟蹤
kubectl get pod -w
#在原本的終端更新資源類型
kubectl set image deployment nginx-cc nginx=nginx:1.15 && kubectl rollout pause deployment nginx-summer
kubectl get pod
kubectl get all
#監(jiān)控更新的過程，可以看到已經(jīng)新增了一個資源，但是并未按照預期的狀態(tài)去刪除一個舊的資源，就是因為使用了pause暫停命令
kubectl get pods -w
#查看詳細地址
kubectl get pod -owide
#查看連接并查看版本
curl -I 10.244.1.37
curl -I 10.244.2.32
curl -I 10.244.2.31
curl -I 10.244.2.33
#對端口進行外放訪問設置
kubectl expose deployment nginx-cc --port=80 --target-port=80 --type=NodePort
#查看設置的內容
kubectl get svc
#瀏覽器訪問測試
http://192.168.204.171:31441/
#查看詳細信息
kubectl describe svc nginx-cc
#查看 Kubernetes 集群中的服務端點信息
kubectl get endpoints
#詳細信息
kubectl describe endpoints nginx-cc
#金絲雀隔離新的pod測試新的版本是否有問題，給pod做隔離，需要單獨的標簽
#創(chuàng)建新的pod并給端口
kubectl expose deployment nginx-cc --name=new-nginx-cc --port=80 --target-port=80 --type=NodePort
kubectl get svc
kubectl get endpoints
#編輯服務對象
kubectl edit svc new-nginx-cc
復制里面的文件內容編輯新的yaml文件
#獲取 Pod 的列表
kubectl get pod --show-labels
kubectl describe pod nginx-cc-9c9886cb5-ww9tp
#編輯yaml文件
vim new-nginx-cc.yaml
#粘貼并加以修改，做標簽分離
#刪除新的標簽
kubectl delete svc new-nginx-cc
#取當前集群中所有服務對象的列表
kubectl get svc
#創(chuàng)建或更新服務對象
kubectl apply -f new-nginx-cc.yaml
#再次被執(zhí)行，目的是獲取已經(jīng)更新后的服務對象列表
kubectl get svc
#訪問測試
curl -I 10.1.149.41
#復制舊的yaml配置文件，復制apiVersion: v1—————— type: NodePort
kubectl edit svc nginx-cc
#查看標簽，復制標簽
kubectl get pod --show-labels
#編輯配置文件，將標簽粘貼
vim nginx-cc.yaml
#刪除現(xiàn)有的
kubectl delete svc nginx-cc
#查看已刪除的
kubectl get svc
#再次新創(chuàng)建
kubectl apply -f nginx-cc.yaml
#查看創(chuàng)建的
kubectl get svc
#獲取當前集群中所有的終結點
kubectl get endpoints
#獲取當前集群中所有的 Pod 列表
kubectl get pod -owide
#登錄新的pod測試
kubectl exec -it nginx-cc-64dcd8d75b-lg2l6 bash
#測試訪問
kubectl exec -it nginx-cc-64dcd8d75b-lg2l6 bash
cd /usr/share/nginx/html/
echo "this is blue-update" > index.html
exit
#查看端口，并且瀏覽器訪問
kubectl get svc
#此新的就是給測試更新玩家使用
http://192.168.204.171:32234/
#登錄舊1的pod中測試
kubectl get pod
kubectl exec -it nginx-cc-7775bc9d99-7x28n bash
cd /usr/share/nginx/html/
echo "this is web1" > index.html
exit
#登錄舊2的pod中測試
kubectl get pod
kubectl exec -it nginx-cc-7775bc9d99-jlwhm bash
cd /usr/share/nginx/html/
echo "this is web2" > index.html
exit
#登錄舊3的pod中測試
kubectl get pod
kubectl exec -it nginx-cc-7775bc9d99-xqxmv bash
cd /usr/share/nginx/html/
echo "this is web3" > /usr/share/nginx/html/index.html
exit
kubectl get svc
#訪問網(wǎng)頁，等待刷新變化
http://192.168.204.171:32605/
#查看更新狀態(tài)信息
kubectl rollout status deployment nginx-cc
#確保更新的pod沒問題了，繼續(xù)更新
kubectl rollout resume deployment nginx-cc
#查看最后的更新情況
kubectl get pods -w
#查看端口及地址
kubectl get svc
#訪問測試
curl -I 192.168.204.171:31872
curl -I 10.1.149.41
6.聲明式管理方法
1.適合于對資源的修改操作
2.聲明式資源管理方法依賴于資源配置清單文件對資源進行管理資源配置清單文件有兩種格式: yaml (人性化，易讀)，json (易于api接口解析)
3.對資源的管理，是通過事先定義在統(tǒng)–資源配置清單內，再通過陳述式命令應用到k8s集群里
4.語法格式: kubectl create/app1y/delete -f xxxx.yaml
（1）查看資源配置清單
kubectl get deployment nginx -o yaml
（2）解釋資源配置清單
kubectl explain deployment.metadata
kubectl get service nginx -o yaml
kubectl explain service.metadata（3）修改資源配置清單并應用
離線修改:
修改yaml文件，并用kubectl apply -f xxxx.yaml文件使之生效
注意:當apply不生效時， 先使用delete清除資源，再apply創(chuàng)建資源kubectl get service nginx -o yaml > nginx-svc.yaml
vim nginx-svc.yaml
#修改port: 8080
kubectl delete -f nginx-svc.yaml
kubectl apply -f nginx-svc.yaml
kubectl get svc在線修改:
直接使用kubectl edit service nginx
在線編輯資源配置清單并保存退出即時生效(如port:888)
PS:此修改方式不會對yaml文件內容修改刪除資源配置清單:
陳述式刪除:
kubectl delete service nginx
聲明式刪除:
kubectl delete -f nginx-svc.yaml二、實驗
?1.kubectl 管理命令
（1）陳述式資源管理方法
①?查看版本信息
②看資源對象簡寫
③查查看集群信息
④配置kubectl自動補全
注意：此時命令補全功能切換環(huán)境后是不生效的，如果要使切換環(huán)境后也生效需要配置全局環(huán)境變量
⑤?node節(jié)點查看日志
或者直接查看日志
(2)??基本信息查看
①獲取資源的相關信息
kubectl get <resource> [-o wide | json | yaml] [-n namespace]
②查看master 節(jié)點狀態(tài)
簡寫命令
③查看命令空間
命令空間的作用:用于允許不同 命令空間的相同類型的資源重名
④查看default命名空間的所有資源
⑤?創(chuàng)建命名空間 (app)
⑥刪除命名空間(app)
⑦?在命名空間創(chuàng)建副本控制器啟動Pod
例：在命名空間kube-public 創(chuàng)建副本控制器( deployment) 來啟動Pod (nginx-w1)、(nginx-cc)
nginx-w1:
nginx-cc:
⑧描述某個資源的詳細信息
nginx-w1:
nginx-cc:
⑨?查看命名空間kube-public中的pod信息
⑩?kubectl exec
kubectl exec可以跨主機登錄容器，docker exec 只能在容器所在主機上登錄
登出
??重啟（刪除）pod資源
由于存在deployment/rc之類的副本控制器，刪除pod也會重新拉起來
若pod無法刪除，總是處于terminate狀態(tài)， 則要強行刪除pod
又重新生成了
強制刪除
???擴容縮容
擴容
縮容
? ?刪除副本控制器
2.項目的生命周期
(1)? 聲明周期
創(chuàng)建–>發(fā)布–>更新–>回滾–>刪除（2）創(chuàng)建kubectl run命令
創(chuàng)建并運行一個或多個容器鏡像
創(chuàng)建一個deployment或job來管理容器
啟動nginx 實例，暴露容器端口80，設置副本數(shù)3
（3）發(fā)布kubectl expose命令
將資源暴露為新的Service
為deployment的nginx創(chuàng)建service， 并通過Service的80端口轉發(fā)至容器的80端口上，Service的名稱為nginx-service， 類型為NodePort
查看pod網(wǎng)絡狀態(tài)詳細信息和Service暴露的端口
查看ngxinx-service暴露出的端口
查看關聯(lián)后端的節(jié)點
查看service 的描述信息
在node01 節(jié)點上操作，查看負載均衡端口
如已安裝，無需再安裝ipvsadm,否則ipvsadm -Ln會查不到內容
在master01操作 查看訪問日志
（4）更新kubectl?set
更改現(xiàn)有應用資源一些信息
獲取修改模板
查看當前nginx 的版本號
將nginx 版本更新為1.15版本
處于動態(tài)監(jiān)聽pod狀態(tài)，由于使用的是滾動更新方式，所以會先生成--個新的pod，然后刪除--個舊的pod，往后依次類推（動態(tài)更新的）
再看更新好后的Pod的ip會改變
再看nginx 的版本號
（5）回滾kubectl?rollout
對資源進行回滾管理
查看歷史版本
執(zhí)行回滾到上一個版本
執(zhí)行回滾到指定版本
檢查回滾狀態(tài)
（6）刪除kubectl delete
刪除副本控制器
刪除service
3.金絲雀發(fā)布(Canary Release)部署
（1）第一種方式（相同service）
更新deployment的版本，并配置暫停deployment
新生成3個副本
更新deployment的版本
監(jiān)控更新的過程，可以看到已經(jīng)新增了一個資源，但是并未按照預期的狀態(tài)去刪除一個舊的資源， 就是因為使用了pause暫停命令
（2）第二種方式（不同service）
創(chuàng)建新的資源
查看詳細信息(node節(jié)點地址、IP地址、nginx版本)
另開一個終端進行實時跟蹤
在原本的終端更新資源類型
監(jiān)控更新的過程，可以看到已經(jīng)新增了一個資源，但是并未按照預期的狀態(tài)去刪除一個舊的資源，就是因為使用了pause暫停命令
查看詳細地址
查看連接并查看版本（使用clusterip訪問4次，出現(xiàn)了3次1.14.2版本和1次1.15.12版本）
對端口進行外放訪問設置
查看設置的內容
瀏覽器訪問測試
查看詳細信息
查看 Kubernetes 集群中的服務端點信息
詳細信息
金絲雀隔離新的pod測試新的版本是否有問題，給pod做隔離，需要單獨的標簽：
創(chuàng)建新的pod并給端口
查詢service
查詢端點
編輯服務對象
先去除編號
復制里面的文件內容編輯新的yaml文件
獲取 Pod 的列表
粘貼并加以修改，做標簽分離
刪除新的標簽，取當前集群中所有服務對象的列表
創(chuàng)建或更新服務對象
再次被執(zhí)行，目的是獲取已經(jīng)更新后的服務對象列表
訪問測試
復制舊的yaml配置文件，復制apiVersion: v1到?type: NodePort
查看標簽，復制標簽
編輯配置文件，將標簽粘貼
刪除現(xiàn)有的
查看已刪除的
再次新創(chuàng)建
查看創(chuàng)建的
獲取當前集群中所有的終結點
所有新流量訪問new-nginx-cc
所有老流量訪問ngin-cc
獲取當前集群中所有的 Pod 列表
登錄新的pod測試訪問
查看端口，并且瀏覽器訪問
此新的就是給測試更新使用
登錄舊1的pod中測試
登錄舊2的pod中測試
登錄舊3的pod中測試
獲取nginx-cc 的svc
訪問網(wǎng)頁，等待刷新變化
查看更新狀態(tài)信息
確保更新的pod沒問題了，繼續(xù)更新
查看最后的更新情況（開始滾動更新）
pod數(shù)量回到了3個
查看端口及地址
訪問測試
查看端點
查看pod詳細信息
4.聲明式管理方法
?（1）查看資源配置清單
（2）解釋資源配置清單
（3）修改資源配置清單并應用
離線修改:
在線修改:
直接使用kubectl edit service nginx
在線編輯資源配置清單并保存退出即時生效(如port:888)
PS:此修改方式不會對yaml文件內容修改刪除資源配置清單:
陳述式刪除:
?
聲明式刪除:
三、問題
1.為何每個pod有兩個標簽
（1）問題
每個有pod兩個標簽app和pod-template-hash
（2）原因分析
此時每個pod都標有兩個標簽： app，它指定pod屬于哪個應用、組件或微服務。 pod-template-hash 標簽,` 是 deploy 自動給它生成 rs 和 pod 加上的。 標簽的值是 rs 名稱的后綴，一是讓 rs 生成不重復，而是可以唯一識別 rs。 deploy 可以生成多個 rs，其中這個標簽的值也會跟著變化。
（3）含義
參數(shù) pod-template-hash=9c9886cb5的意義：?通過對 ReplicaSet 的 PodTemplate 進行哈希處理，確保 Deployment 的子 ReplicaSets 不重疊沖突。
四、總結
?管理K8S資源的三種基本方法：
① 陳述式資源管理方法-使用cli工具進行管理。
② 聲明式資源管理方式-主要依耐資源配置清單。
③ GUI式資源管理方法-主要依耐圖形界面。金絲雀發(fā)布：
會有一個對外暴露測試，沒有問題再更新剩余的，更新一個對外開放一個金絲雀新版本做pod隔離：
金絲雀隔離新的pod測試新的版本是否有問題，給pod做隔離，舊標簽nginx-cc需要新單獨的標簽：new-nginx-cc陳述式資源管理方法
#查看版本信息
kubectl version
#查看資源對象簡寫
kubectl api-resources
#查看集群信息
kubectl cluster-info
#node 節(jié)點查看日志
journalctl -u kubelet -f
#或者直接查看日志
cat /var/log/messages配置kubectl自動補全：文章來源：http://www.zghlxwxcb.cn/news/detail-697469.html
1.臨時生效
source <(kubectl completion bash)
2.永久生效
vim /etc/bashrc
.....
source <(kubectl completion bash) #在底部添加kubectl創(chuàng)建和刪除相關命令：文章來源地址http://www.zghlxwxcb.cn/news/detail-697469.html
命令 說明
run 在集群上運行一個鏡像
create 使用文件或者標準輸入的方式創(chuàng)建一個資源
delete 使用文件或者標準輸入以及資源名稱或者標簽選擇器來刪除某個資源到了這里，關于云原生Kubernetes:kubectl管理命令的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
