一、陳述式資源管理方式
- 1.kubernetes 集群管理集群資源的唯一入口是通過(guò)相應(yīng)的方法調(diào)用 apiserver 的接口
- 2.kubectl 是官方的CLI命令行工具，用于與 apiserver 進(jìn)行通信，將用戶在命令行輸入的命令，組織并轉(zhuǎn)化為 apiserver 能識(shí)別的信息，進(jìn)而實(shí)現(xiàn)管理 k8s 各種資源的一種有效途徑
- 3.kubectl 的命令大全
kubectl --help
k8s中文文檔：http://docs.kubernetes.org.cn/683.html - 4.對(duì)資源的增、刪、查操作比較方便，但對(duì)改的操作就不容易了
1.1基本查看命令
查看版本信息
kubectl version
查看資源對(duì)象簡(jiǎn)寫
kubectl api-resources
查看集群信息
kubectl cluster-info
配置kubectl自動(dòng)補(bǔ)全
source <(kubectl completion bash)
node節(jié)點(diǎn)查看日志
journalctl -u kubelet -f
1.3基本信息查看
命令格式
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的資源
查看 master 節(jié)點(diǎn)狀態(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 create ns app
kubectl get ns
在命名空間kube-public 創(chuàng)建副本控制器（deployment）來(lái)啟動(dòng)Pod（nginx-wl）
kubectl create deployment nginx-wl --image=nginx -n kube-public
描述某個(gè)資源的詳細(xì)信息
kubectl describe deployment nginx-wl -n kube-public
kubectl describe pod nginx-wl-d47f99cb6-hv6gz -n kube-public
查看命名空間kube-public 中的pod 信息
kubectl get pods -n kube-public
NAME READY STATUS RESTARTS AGE
nginx-wl-d47f99cb6-hv6gz 1/1 Running 0 24m
kubectl exec可以跨主機(jī)登錄容器，docker exec 只能在容器所在主機(jī)上登錄
kubectl exec -it nginx-wl-d47f99cb6-hv6gz bash -n kube-public
查看pod中容器日志
kubectl logs myapp-nginx-6555579749-zwspc -n app -c <容器名> -p #-p查看pod重啟前的日志
刪除（重啟）pod資源，由于存在deployment/rc之類的副本控制器，刪除pod也會(huì)重新拉起來(lái)
kubectl delete pod nginx-wl-d47f99cb6-hv6gz -n kube-public
若pod無(wú)法刪除，總是處于terminate狀態(tài)，則要強(qiáng)行刪除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示過(guò)渡存活期，默認(rèn)30s，在刪除pod之前允許pod慢慢終止其上的容器進(jìn)程，從而優(yōu)雅退出，0表示立即終止pod
擴(kuò)縮容
kubectl scale deployment nginx-wl --replicas=2 -n kube-public # 擴(kuò)容
kubectl scale deployment nginx-wl --replicas=1 -n kube-public # 縮容
刪除副本控制器
kubectl delete deployment nginx-wl -n kube-public
kubectl delete deployment/nginx-wl -n kube-public
二、項(xiàng)目的生命周期：創(chuàng)建–>發(fā)布–>更新–>回滾–>刪除
2.1、創(chuàng)建 kubectl create命令
- 創(chuàng)建并運(yùn)行一個(gè)或多個(gè)容器鏡像。
- 創(chuàng)建一個(gè)deployment 或job 來(lái)管理容器。
kubectl create --help
啟動(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
2.2、發(fā)布 kubectl expose命令
- 將資源暴露為新的 Service。
kubectl expose --help
為deployment的nginx創(chuàng)建service，并通過(guò)Service的80端口轉(zhuǎn)發(fā)至容器的80端口上，Service的名稱為nginx-service，類型為NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
- Kubernetes 之所以需要 Service，一方面是因?yàn)?Pod 的 IP 不是固定的（Pod可能會(huì)重建），另一方面則是因?yàn)橐唤M Pod 實(shí)例之間總會(huì)有負(fù)載均衡的需求。
- Service 通過(guò) Label Selector 實(shí)現(xiàn)的對(duì)一組的 Pod 的訪問(wèn)。
- 對(duì)于容器應(yīng)用而言，Kubernetes 提供了基于 VIP（虛擬IP） 的網(wǎng)橋的方式訪問(wèn) Service，再由 Service 重定向到相應(yīng)的 Pod。
service 的 type 類型：
ClusterIP：提供一個(gè)集群內(nèi)部的虛擬IP以供Pod訪問(wèn)（service默認(rèn)類型)
NodePort：在每個(gè)Node上打開(kāi)一個(gè)端口以供外部訪問(wèn)，Kubernetes將會(huì)在每個(gè)Node上打開(kāi)一個(gè)端口并且每個(gè)Node的端口都是一樣的，通過(guò)
NodeIp:NodePort 的方式Kubernetes集群外部的程序可以訪問(wèn)Service。 每個(gè)端口只能是一種服務(wù)，端口范圍只能是
30000-32767。LoadBalancer：通過(guò)設(shè)置LoadBalancer映射到云服務(wù)商提供的LoadBalancer地址。這種用法僅用于在公有云服務(wù)提供商的云平臺(tái)上設(shè)置Service的場(chǎng)景。通過(guò)外部的負(fù)載均衡器來(lái)訪問(wèn)，通常在云平臺(tái)部署LoadBalancer還需要額外的費(fèi)用。
在service提交后，Kubernetes就會(huì)調(diào)用CloudProvider在公有云上為你創(chuàng)建一個(gè)負(fù)載均衡服務(wù)，并且把被代理的Pod的IP地址配置給負(fù)載均衡服務(wù)做后端。externalName：將service名稱映射到一個(gè)DNS域名上，相當(dāng)于DNS服務(wù)的CNAME記錄，用于讓Pod去訪問(wèn)集群外部的資源，它本身沒(méi)有綁定任何的資源。
查看pod網(wǎng)絡(luò)狀態(tài)詳細(xì)信息和 Service暴露的端口
kubectl get pods,svc -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
pod/nginx-cdb6b5b95-fjm2x 1/1 Running 0 44s 172.17.26.3 192.168.80.11 <none>
pod/nginx-cdb6b5b95-g28wz 1/1 Running 0 44s 172.17.36.3 192.168.80.12 <none>
pod/nginx-cdb6b5b95-x4m24 1/1 Running 0 44s 172.17.36.2 192.168.80.12 <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 14d <none>
service/nginx-service NodePort 10.0.0.189 <none> 80:44847/TCP 18s run=nginx
#查看關(guān)聯(lián)后端的節(jié)點(diǎn)
kubectl get endpoints
#查看 service 的描述信息
kubectl describe svc nginx
在 node01 節(jié)點(diǎn)上操作，查看負(fù)載均衡端口
yum install ipvsadm -y
ipvsadm -Ln
//外部訪問(wèn)的IP和端口
TCP 192.168.80.11:44847 rr
-> 172.17.26.3:80 Masq 1 0 0
-> 172.17.36.2:80 Masq 1 0 0
-> 172.17.36.3:80 Masq 1 0 0
pod集群組內(nèi)部訪問(wèn)的IP和端口
TCP 10.0.0.189:80 rr
-> 172.17.26.3:80 Masq 1 0 0
-> 172.17.36.2:80 Masq 1 0 0
-> 172.17.36.3:80 Masq 1 0 0
//在 node02 節(jié)點(diǎn)上操作，同樣方式查看負(fù)載均衡端口
yum install ipvsadm -y
ipvsadm -Ln
TCP 192.168.80.12:44847 rr
-> 172.17.26.3:80 Masq 1 0 0
-> 172.17.36.2:80 Masq 1 0 0
-> 172.17.36.3:80 Masq 1 0 0
TCP 10.0.0.189:80 rr
-> 172.17.26.3:80 Masq 1 0 0
-> 172.17.36.2:80 Masq 1 0 0
-> 172.17.36.3:80 Masq 1 0 0
curl 10.0.0.189
curl 192.168.80.11:44847
在master01操作 查看訪問(wèn)日志
kubectl logs nginx-cdb6b5b95-fjm2x
kubectl logs nginx-cdb6b5b95-g28wz
kubectl logs nginx-cdb6b5b95-x4m24
2.3、更新 kubectl set
- 更改現(xiàn)有應(yīng)用資源一些信息。
kubectl set --help
獲取修改模板
kubectl set image --help
Examples:
# Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'.
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
#查看當(dāng)前 nginx 的版本號(hào)
curl -I http://192.168.80.11:44847
curl -I http://192.168.80.12:44847
//將nginx 版本更新為 1.15 版本
kubectl set image deployment/nginx nginx=nginx:1.15
//處于動(dòng)態(tài)監(jiān)聽(tīng) pod 狀態(tài)，由于使用的是滾動(dòng)更新方式，所以會(huì)先生成一個(gè)新的pod，然后刪除一個(gè)舊的pod，往后依次類推
kubectl get pods -w
滾動(dòng)更新詳解：
** kubectl get all**
- DESIRED：表示期望的狀態(tài)是 10 個(gè) READY 的副本
- CURRENT：表示當(dāng)前副本的總數(shù): 即8 個(gè)日副本 + 5 個(gè)新副本
- UP_TO-DATE：表示當(dāng)前已經(jīng)完成更新的副本數(shù): 即 5個(gè)新副本
- AVAILABLE：表示當(dāng)前處于 READY 狀態(tài)的副本數(shù): 即8個(gè)日副本。
kubectl describe deployment/nginx
滾動(dòng)更新通過(guò)參數(shù) maxSurge 和 maxUnavailable 來(lái)控制副本替換的數(shù)量
maxSurge：此參數(shù)控制滾動(dòng)更新過(guò)程中副本總數(shù)的超過(guò) DESIRED 的上限。maxSurge 可以是具體的整數(shù)（比如 3），也可以是百分百，向上取整。maxSurge 默認(rèn)值為 25%。
例如，DESIRED 為 10，那么副本總數(shù)的最大值為 10 + 10 * 25% = 13，即 CURRENT 為 13。
maxUnavailable：此參數(shù)控制滾動(dòng)更新過(guò)程中，不可用的副本相占 DESIRED 的最大比例。maxUnavailable 可以是具體的整數(shù)（比如 3），也可以是百分百，向下取整。 maxUnavailable 默認(rèn)值為 25%。
例如，DESIRED 為 10，那么可用的副本數(shù)至少要為 10 - 10 * 25% = 8，即 AVAILABLE 為 8。
因此 maxSurge 值越大，初始創(chuàng)建的新副本數(shù)量就越多；maxUnavailable 值越大，初始銷毀的舊副本數(shù)量就越多。
理想情況下，DESIRED 為 10 的滾動(dòng)更新的過(guò)程應(yīng)該是這樣的：
首先創(chuàng)建 3 個(gè)新副本使副本總數(shù)達(dá)到 13 個(gè)。
然后銷毀 2 個(gè)舊副本使可用的副本數(shù)降到 8 個(gè)。
這 2 個(gè)舊副本成功銷毀后，可再創(chuàng)建 2 個(gè)新副本，使副本總數(shù)保持為 13 個(gè)。
當(dāng)新副本通過(guò) Readiness 探測(cè)后，會(huì)使可用副本數(shù)增加，超過(guò) 8。
進(jìn)而可以繼續(xù)銷毀更多的舊副本，使可用副本數(shù)回到 8。
舊副本的銷毀使副本總數(shù)低于 13，這樣就允許創(chuàng)建更多的新副本。
這個(gè)過(guò)程會(huì)持續(xù)進(jìn)行，最終所有的舊副本都會(huì)被新副本替換，滾動(dòng)更新完成。
//再看更新好后的 Pod 的 ip 會(huì)改變
kubectl get pods -o wide
//再看 nginx 的版本號(hào)
curl -I http://192.168.80.11:44847
curl -I http://192.168.80.12:44847
2.4、回滾 kubectl rollout
- 對(duì)資源進(jìn)行回滾管理
kubectl rollout --help
//查看歷史版本
kubectl rollout history deployment/nginx
//執(zhí)行回滾到上一個(gè)版本
kubectl rollout undo deployment/nginx
//執(zhí)行回滾到指定版本
kubectl rollout undo deployment/nginx --to-revision=1
//檢查回滾狀態(tài)
kubectl rollout status deployment/nginx
2.5、刪除 kubectl delete
//刪除副本控制器
kubectl delete deployment/nginx
//刪除service
kubectl delete svc/nginx-service
kubectl get all
金絲雀發(fā)布（Canary Release）
- Deployment控制器支持自定義控制更新過(guò)程中的滾動(dòng)節(jié)奏，如“暫停(pause)”或“繼續(xù)(resume)”更新操作。比如等待第一批新的Pod資源創(chuàng)建完成后立即暫停更新過(guò)程，此時(shí)，僅存在一部分新版本的應(yīng)用，主體部分還是舊的版本。然后，再篩選一小部分的用戶請(qǐng)求路由到新版本的Pod應(yīng)用，繼續(xù)觀察能否穩(wěn)定地按期望的方式運(yùn)行。確定沒(méi)問(wèn)題之后再繼續(xù)完成余下的Pod資源滾動(dòng)更新，否則立即回滾更新操作。這就是所謂的金絲雀發(fā)布。
（1）更新deployment的版本，并配置暫停deployment
kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx
kubectl rollout status deployment/nginx #觀察更新?tīng)顟B(tài)
（2）監(jiān)控更新的過(guò)程，可以看到已經(jīng)新增了一個(gè)資源，但是并未按照預(yù)期的狀態(tài)去刪除一個(gè)舊的資源，就是因?yàn)槭褂昧藀ause暫停命令
kubectl get pods -w
curl [-I] 10.0.0.189
curl [-I] 192.168.80.11:44847
（3）確保更新的pod沒(méi)問(wèn)題了，繼續(xù)更新
kubectl rollout resume deployment/nginx
（4）查看最后的更新情況
kubectl get pods -w
curl [-I] 10.0.0.189
curl [-I] 192.168.80.11:44847
三、聲明式管理方法
- 1.適合于對(duì)資源的修改操作
- 2.聲明式資源管理方法依賴于資源配置清單文件對(duì)資源進(jìn)行管理
- 資源配置清單文件有兩種格式：yaml（人性化，易讀），json（易于api接口解析）
- 3.對(duì)資源的管理，是通過(guò)事先定義在統(tǒng)一資源配置清單內(nèi)，再通過(guò)陳述式命令應(yīng)用到k8s集群里
- 4.語(yǔ)法格式：kubectl create/apply/delete -f xxxx.yaml
//查看資源配置清單
kubectl get deployment nginx -o yaml
//解釋資源配置清單
kubectl explain deployment.metadata
kubectl get service nginx -o yaml
kubectl explain service.metadata
3.1修改資源配置清單并應(yīng)用
離線修改：
- 修改yaml文件，并用 kubectl apply -f xxxx.yaml 文件使之生效
- 注意：當(dāng)apply不生效時(shí)，先使用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
在線修改：文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-640418.html
- 直接使用 kubectl edit service nginx 在線編輯資源配置清單并保存退出即時(shí)生效（如port: 888）
PS：此修改方式不會(huì)對(duì)yaml文件內(nèi)容修改
文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-640418.html
//刪除資源配置清單
陳述式刪除：
kubectl delete service nginx
聲明式刪除：
kubectl delete -f nginx-svc.yaml
到了這里，關(guān)于【云原生】kubectl命令的詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
