kubectl詳解

舊巷g發表於2023-11-13

kubectl詳解

陳述式資源管理方法：

1.kubernetes 叢集管理叢集資源的唯一入口是透過相應的方法呼叫 apiserver 的介面 2.kubectl 是官方的CLI命令列工具，用於與 apiserver 進行通訊，將使用者在命令列輸入的命令，組織並轉化為 apiserver 能識別的資訊，進而實現管理 k8s 各種資源的一種有效途徑 3.kubectl 的命令大全 kubectl --help k8s中文文件：http://docs.kubernetes.org.cn/683.html 4.對資源的增、刪、查操作比較方便，但對改的操作就不容易了

//檢視版本資訊

kubectl version

image-20231107131231613

//檢視資源物件簡寫

kubectl api-resources

image-20231107132024475

//檢視叢集資訊

kubectl cluster-info

image-20231107132130265

//配置kubectl自動補全

source <(kubectl completion bash)

image-20231107132252802

//node節點檢視日誌

journalctl -u kubelet -f

image-20231107132542956

基本資訊檢視 

kubectl get <resource> [-o wide|json|yaml] [-n namespace]

獲取資源的相關資訊，-n 指定命令空間，-o 指定輸出格式 resource可以是具體資源名稱，如pod nginx-xxx；也可以是資源型別，如pod；或者all(僅展示幾種核心資源，並不完整) --all-namespaces 或 -A ：表示顯示所有名稱空間， --show-labels ：顯示所有標籤 -l app ：僅顯示標籤為app的資源 -l app=nginx ：僅顯示包含app標籤，且值為nginx的資源

//檢視 master 節點狀態

kubectl get componentstatuses
kubectl get cs #可簡寫為cs

image-20231107134240837

//檢視名稱空間

kubectl get namespace
kubectl get ns

image-20231107134457031

//命令空間的作用：用於允許不同 名稱空間 的 相同型別 的資源 重名的

//檢視default名稱空間的所有資源

kubectl get all [-n default]

image-20231107135551580

//建立名稱空間app

kubectl create ns app
kubectl get ns

image-20231107135704043

//刪除名稱空間app

kubectl delete namespace app
kubectl get ns

image-20231107183450533

//建立副本控制器

//在名稱空間kube-public 建立副本控制器（deployment）來啟動Pod（nginx-wl）

kubectl create deployment nginx-wl --image=nginx  -n kube-public

image-20231107184023817

//描述某個資源的詳細資訊

kubectl describe deployment nginx-wl -n kube-public
kubectl describe pod nginx-wl-d47f99cb6-hv6gz -n kube-public

image-20231107184242201

image-20231107184629494

//檢視名稱空間kube-public 中的pod 資訊

kubectl get pods -n kube-public
NAME                       READY   STATUS    RESTARTS   AGE
nginx-wl-d47f99cb6-hv6gz   1/1     Running   0          24m

image-20231107184739637

//跨主機登入容器

//kubectl exec可以跨主機登入容器，docker exec 只能在容器所在主機上登入

kubectl exec -it nginx-wl-d47f99cb6-hv6gz bash -n kube-public

image-20231107184920413

//刪除pod

//刪除（重啟）pod資源，由於存在deployment/rc之類的副本控制器，刪除pod也會重新拉起來

kubectl delete pod nginx-wl-d47f99cb6-hv6gz -n kube-public

image-20231107185509831

//若pod無法刪除，總是處於terminate狀態，則要強行刪除pod

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

image-20231107185914161

#grace-period表示過渡存活期，預設30s，在刪除pod之前允許pod慢慢終止其上的容器程式，從而優雅退出，0表示立即終止pod

//擴縮容

kubectl scale deployment nginx-wl --replicas=2 -n kube-public	# 擴容
kubectl scale deployment nginx-wl --replicas=1 -n kube-public	# 縮容

image-20231107191259075

image-20231107191401664

//刪除副本控制器

kubectl delete deployment nginx-wl -n kube-public
kubectl delete deployment/nginx-wl -n kube-public

image-20231108092050795

//專案的生命週期：建立-->釋出-->更新-->回滾-->刪除

1、建立 kubectl create命令

●建立並執行一個或多個容器映象。 ●建立一個deployment 或job 來管理容器。

kubectl create --help

//啟動 nginx 例項，暴露容器埠 80，設定副本數 3

kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3

kubectl get pods
kubectl get all

image-20231108093342145

2、釋出 kubectl expose命令

●將資源暴露為新的 Service。

kubectl expose --help

//為deployment的nginx建立service，並透過Service的80埠轉發至容器的80埠上，Service的名稱為nginx-service，型別為NodePort

kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

image-20231108103900957

Kubernetes 之所以需要 Service，一方面是因為 Pod 的 IP 不是固定的（Pod可能會重建），另一方面則是因為一組 Pod 例項之間總會有負載均衡的需求。 Service 透過 Label Selector 實現的對一組的 Pod 的訪問。 對於容器應用而言，Kubernetes 提供了基於 VIP（虛擬IP） 的網橋的方式訪問 Service，再由 Service 重定向到相應的 Pod。

service 的 type 型別： ●ClusterIP：提供一個叢集內部的虛擬IP以供Pod訪問（service預設型別)

●NodePort：在每個Node上開啟一個埠以供外部訪問，Kubernetes將會在每個Node上開啟一個埠並且每個Node的埠都是一樣的，透過 NodeIp:NodePort 的方式Kubernetes叢集外部的程式可以訪問Service。 每個埠只能是一種服務，埠範圍只能是 30000-32767。

●LoadBalancer：透過設定LoadBalancer對映到雲服務商提供的LoadBalancer地址。這種用法僅用於在公有云服務提供商的雲平臺上設定Service的場景。透過外部的負載均衡器來訪問，通常在雲平臺部署LoadBalancer還需要額外的費用。 在service提交後，Kubernetes就會呼叫CloudProvider在公有云上為你建立一個負載均衡服務，並且把被代理的Pod的IP地址配置給負載均衡服務做後端。

●externalName：將service名稱對映到一個DNS域名上，相當於DNS服務的CNAME記錄，用於讓Pod去訪問叢集外部的資源，它本身沒有繫結任何的資源。

//檢視pod網路狀態詳細資訊和 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

image-20231108104122893

//檢視關聯後端的節點

kubectl get endpoints

image-20231108121127333

//檢視 service 的描述資訊

kubectl describe svc nginx

image-20231108121248617

//在 node01 節點上操作，檢視負載均衡埠

yum install ipvsadm -y
ipvsadm -Ln

image-20231108121555007

//外部訪問的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叢集組內部訪問的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 節點上操作，同樣方式檢視負載均衡埠 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操作 檢視訪問日誌 kubectl logs nginx-cdb6b5b95-fjm2x kubectl logs nginx-cdb6b5b95-g28wz kubectl logs nginx-cdb6b5b95-x4m24

3、更新 kubectl set

●更改現有應用資源一些資訊。

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

image-20231108121957289

image-20231108163341662

//檢視當前 nginx 的版本號

kubectl describe svc nginx-service
curl -I http://192.168.1.101:31186
curl -I http://192.168.1.102:31186

image-20231108162316972

image-20231108163759923

//將nginx 版本更新為 1.15 版本

kubectl set image deployment/nginx nginx=nginx:1.15

image-20231108170148812

//處於動態監聽 pod 狀態，由於使用的是滾動更新方式，所以會先生成一個新的pod，然後刪除一箇舊的pod，往後依次類推

kubectl get pods -w

 

#滾動更新詳解：

kubectl get all

DESIRED：表示期望的狀態是 10 個 READY 的副本 CURRENT：表示當前副本的總數: 即8 個日副本 + 5 個新副本 UP_TO-DATE：表示當前已經完成更新的副本數: 即 5個新副本 AVAILABLE：表示當前處於 READY 狀態的副本數: 即8個日副本。

image-20231108170420493

kubectl describe deployment/nginx

滾動更新透過引數 maxSurge 和 maxUnavailable 來控制副本替換的數量 maxSurge：此引數控制滾動更新過程中副本總數的超過 DESIRED 的上限。maxSurge 可以是具體的整數（比如 3），也可以是百分百，向上取整。maxSurge 預設值為 25%。 例如，DESIRED 為 10，那麼副本總數的最大值為 10 + 10 * 25% = 13，即 CURRENT 為 13。

maxUnavailable：此引數控制滾動更新過程中，不可用的副本相佔 DESIRED 的最大比例。maxUnavailable 可以是具體的整數（比如 3），也可以是百分百，向下取整。 maxUnavailable 預設值為 25%。 例如，DESIRED 為 10，那麼可用的副本數至少要為 10 - 10 * 25% = 8，即 AVAILABLE 為 8。

因此 maxSurge 值越大，初始建立的新副本數量就越多；maxUnavailable 值越大，初始銷燬的舊副本數量就越多。

理想情況下，DESIRED 為 10 的滾動更新的過程應該是這樣的： 首先建立 3 個新副本使副本總數達到 13 個。 然後銷燬 2 箇舊副本使可用的副本數降到 8 個。 當這 2 箇舊副本成功銷燬後，可再建立 2 個新副本，使副本總數保持為 13 個。 當新副本透過 Readiness 探測後，會使可用副本數增加，超過 8。 進而可以繼續銷燬更多的舊副本，使可用副本數回到 8。 舊副本的銷燬使副本總數低於 13，這樣就允許建立更多的新副本。

這個過程會持續進行，最終所有的舊副本都會被新副本替換，滾動更新完成。

image-20231108170545759

//再看更新好後的 Pod 的 ip 會改變

kubectl get pods -o wide

image-20231108170643629

//再看 nginx 的版本號

curl -I http://192.168.1.101:31186
curl -I http://192.168.1.102:31186

image-20231108170948836

4、回滾 kubectl rollout

●對資源進行回滾管理

kubectl rollout --help

//檢視歷史版本

kubectl rollout history deployment/nginx

image-20231108171045073

//執行回滾到上一個版本

kubectl rollout undo deployment/nginx

image-20231108171216499

image-20231108171412541

//執行回滾到指定版本

kubectl rollout undo deployment/nginx --to-revision=1

image-20231108171605229

//檢查回滾狀態

kubectl rollout status deployment/nginx

image-20231108171710002

5、刪除 kubectl delete

//刪除副本控制器

kubectl delete deployment/nginx

image-20231108171915030

//刪除service

kubectl delete svc/nginx-service
​
kubectl get all

image-20231108172204685

//金絲雀釋出（Canary Release）

Deployment控制器支援自定義控制更新過程中的滾動節奏，如“暫停(pause)”或“繼續(resume)”更新操作。比如等待第一批新的Pod資源建立完成後立即暫停更新過程，此時，僅存在一部分新版本的應用，主體部分還是舊的版本。然後，再篩選一小部分的使用者請求路由到新版本的Pod應用，繼續觀察能否穩定地按期望的方式執行。確定沒問題之後再繼續完成餘下的Pod資源滾動更新，否則立即回滾更新操作。這就是所謂的金絲雀釋出。 （1）更新deployment的版本，並配置暫停deployment

kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx
​
kubectl rollout status deployment/nginx　　#觀察更新狀態

image-20231108174116057

（2）監控更新的過程，可以看到已經新增了一個資源，但是並未按照預期的狀態去刪除一箇舊的資源，就是因為使用了pause暫停命令

kubectl get pods -w 
​
curl [-I] 10.96.135.178
curl [-I] 192.168.1.101:31022

image-20231108182543391

（3）確保更新的pod沒問題了，繼續更新

kubectl rollout resume deployment/nginx

image-20231108182700192

（4）檢視最後的更新情況

kubectl get pods -w 
​
curl [-I]  10.96.135.178
curl [-I] 192.168.1.101:31022

image-20231108182822850

宣告式管理方法：

1.適合於對資源的修改操作 2.宣告式資源管理方法依賴於資源配置清單檔案對資源進行管理 資源配置清單檔案有兩種格式：yaml（人性化，易讀），json（易於api介面解析） 3.對資源的管理，是透過事先定義在統一資源配置清單內，再透過陳述式命令應用到k8s叢集裡 4.語法格式：kubectl create/apply/delete -f xxxx.yaml

//檢視資源配置清單

kubectl get deployment nginx -o yaml

image-20231108182951591

//解釋資源配置清單

kubectl explain deployment.metadata
​
kubectl get service nginx -o yaml
kubectl explain service.metadata

image-20231108183140350

image-20231108183245215

image-20231108183316991

//修改資源配置清單並應用 離線修改： 修改yaml檔案，並用 kubectl apply -f xxxx.yaml 檔案使之生效 注意：當apply不生效時，先使用delete清除資源，再apply建立資源

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

image-20231108184154106

image-20231108184308285

image-20231108184655582

線上修改： 直接使用 kubectl edit service nginx 線上編輯資源配置清單並儲存退出即時生效（如port: 888） PS：此修改方式不會對yaml檔案內容修改

image-20231108190453733

//刪除資源配置清單 陳述式刪除：

kubectl delete service nginx-pod

宣告式刪除：

kubectl delete -f nginx-svc.yaml

相關文章