一、陳述式資源管理
1. 陳述式資源管理方法
- kubernetes 集群管理集群資源的唯一入口是通過相應(yīng)的方法調(diào)用 apiserver 的接口；
- kubectl 是官方的CLI命令行工具，用于與 apiserver 進行通信，將用戶在命令行輸入的命令，組織并轉(zhuǎn)化為 apiserver 能識別的信息，進而實現(xiàn)管理 k8s 各種資源的一種有效途徑；
- kubectl 的命令大全：
kubectl --help
k8s中文文檔：http://docs.kubernetes.org.cn/683.html
- 對資源的增、刪、查操作比較方便，但對改的操作就不容易了
#查看版本信息/
kubectl version
#查看資源對象簡寫
kubectl api-resources
#查看集群信息
kubectl cluster-info
#配置kubectl自動補全，此命令只在當前命令界面生效，如果想要永久生效可以在.bashrc或者/etc/bashrc文件中添加
source <(kubectl completion bash)
#node節(jié)點查看日志
journalctl -u kubelet -f
2. 基本信息查看
#獲取資源的相關(guān)信息
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 節(jié)點狀態(tài)
kubectl get componentstatuses
kubectl get cs
#查看命名空間
kubectl get namespace
kubectl get ns
#命令空間的作用：用于允許不同 命名空間 的 相同類型 的資源 重名的，即在同一個命名空間下不能有同名的資源
#指定查看kubernetes-dashboard命名空間下下的資源
kubectl get -n kubernetes-dashboard svc
#查看kubernetes-dashboard命名空間的所有資源
kubectl get all -n kubernetes-dashboard
#查看kubernetes-dashboard命名空間下資源 信息
kubectl get -n kubernetes-dashboard pods -o wide
#根據(jù)標簽查看kubernetes-dashboard命名空間下資源信息
kubectl get pods -A -l app=flannel
#查看只包含k8s-app鍵值對的資源信息
kubectl get pods -A -l k8s-app
#指定查看某個鍵值對的資源信息
kubectl get pods -A -l k8s-app=kubernetes-dashboard --show-labels
#創(chuàng)建命名空間app
kubectl create ns app
kubectl get ns
#刪除命名空間app
kubectl delete namespace app
kubectl get ns
#在命名空間kube-public 創(chuàng)建副本控制器（deployment）來啟動Pod（nginx-test）
kubectl create deployment nginx-test --image=nginx -n kube-public
#描述某個資源的詳細信息
kubectl describe deployment nginx-test -n kube-public
kubectl describe pod -n kube-public nginx-test-795d659f45-pvdx9
#查看命名空間kube-public 中的pod 信息
kubectl get pods -n kube-public
NAME READY STATUS RESTARTS AGE
nginx-test-795d659f45-pvdx9 1/1 Running 0 11m
#kubectl exec可以跨主機登錄容器，docker exec 只能在容器所在主機上登錄
kubectl exec -it nginx-test-795d659f45-pvdx9 bash -n kube-public
#刪除（重啟）pod資源，由于存在deployment/rc之類的副本控制器，刪除pod也會重新拉起來
kubectl delete pod nginx-test-795d659f45-pvdx9 -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-test --replicas=2 -n kube-public # 擴容
kubectl scale deployment nginx-test --replicas=1 -n kube-public # 縮容
#刪除副本控制器
kubectl delete deployment nginx-test -n kube-public
kubectl delete deployment/nginx-test -n kube-public
3. 項目周期管理
項目的生命周期：創(chuàng)建–>發(fā)布–>更新–>回滾–>刪除
3.1 創(chuàng)建 kubectl create 命令
創(chuàng)建并運行一個或多個容器鏡像。
創(chuàng)建一個 deployment 或 job 來管理容器。
#啟動 nginx 實例，暴露容器端口 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ā)布 kubectl expose命令
將資源暴露為新的 Service。
kubectl expose --help
#為deployment的nginx創(chuàng)建service，并通過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，一方面是因為 Pod 的 IP 不是固定的（Pod可能會重建），另一方面則是因為一組 Pod 實例之間總會有負載均衡的需求。
Service 通過 Label Selector 實現(xiàn)的對一組的 Pod 的訪問。
對于容器應(yīng)用而言，Kubernetes 提供了基于 VIP（虛擬IP） 的網(wǎng)橋的方式訪問 Service，再由 Service 重定向到相應(yīng)的 Pod。
| service 的 type 類型 | 功能 |
|---|---|
| ClusterIP | 提供一個集群內(nèi)部的虛擬IP以供Pod訪問（service默認類型) |
| NodePort | 在每個Node上打開一個端口以供外部訪問，Kubernetes將會在每個Node上打開一個端口并且每個Node的端口都是一樣的，通過 NodeIp:NodePort 的方式Kubernetes集群外部的程序可以訪問Service。 每個端口只能是一種服務(wù)，默認端口范圍只能是 30000-32767。 |
| LoadBalance | 使用外接負載均衡器完成到服務(wù)的負載分發(fā)，注意此模式需要外部云環(huán)境支持。借助第三方的云負載均衡器，將請求分發(fā)到所有的Node上，其底層還是NodePort LoadBalancer和NodePort很相似，目的都是向外部暴露一個端口，區(qū)別在于LoadBalancer會在集群的外部再來做一個負載均衡設(shè)備，而這個設(shè)備需要外部環(huán)境支持的，外部服務(wù)發(fā)送到這個設(shè)備上的請求，會被設(shè)備負載之后轉(zhuǎn)發(fā)到集群中。 |
| externalName | 將service名稱映射到一個DNS域名上，相當于DNS服務(wù)的CNAME記錄，用于讓Pod去訪問集群外部的資源，它本身沒有綁定任何的資源。 |
#查看pod網(wǎng)絡(luò)狀態(tài)詳細信息和 Service暴露的端口
kubectl get pods,svc -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/nginx-d9d8cf5c7-kfgh5 1/1 Running 0 9m41s 10.244.2.5 node02 <none> <none>
pod/nginx-d9d8cf5c7-pjjg4 1/1 Running 0 9m41s 10.244.1.4 node01 <none> <none>
pod/nginx-d9d8cf5c7-w4rzc 1/1 Running 0 9m41s 10.244.1.5 node01 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5h20m <none>
service/nginx-service NodePort 10.96.221.68 <none> 80:31233/TCP 3m29s app=nginx
#查看關(guān)聯(lián)后端的節(jié)點
kubectl get endpoints
#查看 service 的描述信息
kubectl describe svc nginx
#在 node01 節(jié)點上操作，查看負載均衡端口
yum install ipvsadm -y
ipvsadm -Ln
#外部訪問的IP和端口
TCP 192.168.145.12:31233 rr
-> 10.244.1.4:80 Masq 1 0 0
-> 10.244.1.5:80 Masq 1 0 0
-> 10.244.2.5:80 Masq 1 0 0
#pod集群組內(nèi)部訪問的IP和端口
TCP 10.96.221.68:80 rr
-> 10.244.1.4:80 Masq 1 0 0
-> 10.244.1.5:80 Masq 1 0 0
-> 10.244.2.5:80 Masq 1 0 0
#在 node02 節(jié)點上操作，同樣方式查看負載均衡端口
yum install ipvsadm -y
ipvsadm -Ln
TCP 192.168.145.13:31233 rr
-> 10.244.1.4:80 Masq 1 0 0
-> 10.244.1.5:80 Masq 1 0 0
-> 10.244.2.5:80 Masq 1 0 0
TCP 10.96.221.68:80 rr
-> 10.244.1.4:80 Masq 1 0 0
-> 10.244.1.5:80 Masq 1 0 0
-> 10.244.2.5:80 Masq 1 0 0
curl 10.96.221.68
curl 192.168.145.11:6443
#在master01操作 查看訪問日志
kubectl logs nginx-d9d8cf5c7-kfgh5
kubectl logs nginx-d9d8cf5c7-pjjg4
kubectl logs nginx-d9d8cf5c7-w4rzc
3.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
#查看當前 nginx 的版本號
curl -I http://192.168.145.11:31233
curl -I http://192.168.145.12:31223
#將nginx 版本更新為 1.15 版本
kubectl set image deployment/nginx nginx=nginx:1.15
#處于動態(tài)監(jiān)聽 pod 狀態(tài)，由于使用的是滾動更新方式，所以會先生成一個新的pod，然后刪除一個舊的pod，往后依次類推
kubectl get pods -w
---------------------------------------------------------------------------------------------
#滾動更新詳解：
kubectl get all
DESIRED：表示期望的狀態(tài)是 10 個 READY 的副本
CURRENT：表示當前副本的總數(shù): 即8 個日副本 + 5 個新副本
UP_TO-DATE：表示當前已經(jīng)完成更新的副本數(shù): 即 5個新副本
AVAILABLE：表示當前處于 READY 狀態(tài)的副本數(shù): 即8個日副本。
kubectl describe deployment/nginx
滾動更新通過參數(shù) maxSurge 和 maxUnavailable 來控制副本替換的數(shù)量
maxSurge：此參數(shù)控制滾動更新過程中副本總數(shù)的超過 DESIRED 的上限。maxSurge 可以是具體的整數(shù)（比如 3），也可以是百分百，向上取整。maxSurge 默認值為 25%。
例如，DESIRED 為 10，那么副本總數(shù)的最大值為 10 + 10 * 25% = 13，即 CURRENT 為 13。
maxUnavailable：此參數(shù)控制滾動更新過程中，不可用的副本相占 DESIRED 的最大比例。maxUnavailable 可以是具體的整數(shù)（比如 3），也可以是百分百，向下取整。 maxUnavailable 默認值為 25%。
例如，DESIRED 為 10，那么可用的副本數(shù)至少要為 10 - 10 * 25% = 8，即 AVAILABLE 為 8。
因此 maxSurge 值越大，初始創(chuàng)建的新副本數(shù)量就越多；maxUnavailable 值越大，初始銷毀的舊副本數(shù)量就越多。
理想情況下，DESIRED 為 10 的滾動更新的過程應(yīng)該是這樣的：
首先創(chuàng)建 3 個新副本使副本總數(shù)達到 13 個。
然后銷毀 2 個舊副本使可用的副本數(shù)降到 8 個。
當這 2 個舊副本成功銷毀后，可再創(chuàng)建 2 個新副本，使副本總數(shù)保持為 13 個。
當新副本通過 Readiness 探測后，會使可用副本數(shù)增加，超過 8。
進而可以繼續(xù)銷毀更多的舊副本，使可用副本數(shù)回到 8。
舊副本的銷毀使副本總數(shù)低于 13，這樣就允許創(chuàng)建更多的新副本。
這個過程會持續(xù)進行，最終所有的舊副本都會被新副本替換，滾動更新完成。
---------------------------------------------------------------------------------------------
#再看更新好后的 Pod 的 ip 會改變
kubectl get pods -o wide
#再看 nginx 的版本號
curl -I http://192.168.145.11:30574
curl -I http://192.168.145.12:30574
3.4 回滾 kubectl rollout
對資源進行回滾管理
#查看歷史版本
kubectl rollout history deployment/nginx
#執(zhí)行回滾到上一個版本
kubectl rollout undo deployment/nginx
#執(zhí)行回滾到指定版本
kubectl rollout undo deployment/nginx --to-revision=1
#檢查回滾狀態(tài)
kubectl rollout status deployment/nginx
3.5 刪除 kubectl delete
#刪除副本控制器
kubectl delete deployment/nginx
#刪除service
kubectl delete svc/nginx-service
kubectl get all
4. kubectl 的發(fā)布策略
4.1 藍綠發(fā)布
??概念定義：藍綠發(fā)布是一種以最小的停機時間做服務(wù)升級的策略。需要維護的兩個版本的環(huán)境分別稱為 “藍環(huán)境” 和 “綠環(huán)境”。一般當前生產(chǎn)流量指向環(huán)境為綠環(huán)境，而在藍環(huán)境上部署新版本，短時間內(nèi)作為測試環(huán)境。
??發(fā)布流程：首先將一半的服務(wù)流量從負載均衡列表中移除，并且更新服務(wù)版本，驗證新版本沒有問題后，將生產(chǎn)流量指向藍環(huán)境，然后對于老版本的綠環(huán)境進行版本升級，最后將所有服務(wù)流量加回負載均衡。
??特點：
- 升級過程無需停機，用戶感知小
- 升級過程一半資源提供服務(wù)
- 升級/回滾速度快
- 如果出了問題，影響面較廣
4.2 紅黑發(fā)布
??概念定義：與藍綠發(fā)布類似，紅黑發(fā)布也是通過兩個環(huán)境完成軟件版本的升級，將當前生產(chǎn)流量指向的環(huán)境稱為紅環(huán)境，新版本環(huán)境稱為黑環(huán)境。
??發(fā)布流程：需申請新資源用于部署黑環(huán)境，在黑環(huán)境部署新版本的服務(wù)；黑環(huán)境部署完成后，一次性將生產(chǎn)流量指向黑環(huán)境；釋放紅環(huán)境的資源。
??特點：
- 升級過程無需停機，用戶感知小
- 短時間內(nèi)需要使用雙倍資源
??與藍綠發(fā)布相比，紅黑發(fā)布充分利用了云計算的彈性伸縮的優(yōu)勢，實現(xiàn)：
- 簡化發(fā)布流程
- 避免在升級的過程中，由于只有一半資源提供服務(wù)，而導(dǎo)致的系統(tǒng)過載問題
4.3 灰度發(fā)布（金絲雀發(fā)布）
??Deployment控制器支持自定義控制更新過程中的滾動節(jié)奏，如“暫停(pause)”或“繼續(xù)(resume)”更新操作。比如等待第一批新的Pod資源創(chuàng)建完成后立即暫停更新過程，此時，僅存在一部分新版本的應(yīng)用，主體部分還是舊的版本。然后，再篩選一小部分的用戶請求路由到新版本的Pod應(yīng)用，繼續(xù)觀察能否穩(wěn)定地按期望的方式運行。確定沒問題之后再繼續(xù)完成余下的Pod資源滾動更新，否則立即回滾更新操作。這就是所謂的金絲雀發(fā)布。
??（1）更新deployment的版本，并配置暫停deployment
kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx
kubectl rollout status deployment/nginx #觀察更新狀態(tài)
??（2）監(jiān)控更新的過程，可以看到已經(jīng)新增了一個資源，但是并未按照預(yù)期的狀態(tài)去刪除一個舊的資源，就是因為使用了pause暫停命令
kubectl get pods -w
curl [-I] 10.0.0.189
curl [-I] 192.168.145.11:44847
??（3）確保更新的pod沒問題了，繼續(xù)更新
kubectl rollout resume deployment/nginx
??（4）查看最后的更新情況
kubectl get pods -w
curl [-I] 10.0.0.189
curl [-I] 192.168.145.11:44847
4.4 滾動發(fā)布
??在金絲雀發(fā)布基礎(chǔ)上的進一步優(yōu)化改進，是一種自動化程度較高的發(fā)布方式，用戶體驗比較平滑，是目前成熟型技術(shù)組織所采用的主流發(fā)布方式。
二、聲明式資源管理
1. 聲明式管理方法
- 適合于對資源的修改操作
- 聲明式資源管理方法依賴于資源配置清單文件對資源進行管理
資源配置清單文件有兩種格式：yaml（人性化，易讀），json（易于api接口解析）
-
對資源的管理，是通過事先定義在統(tǒng)一資源配置清單內(nèi)，再通過陳述式命令應(yīng)用到k8s集群里
-
語法格式：
kubectl create/apply/delete -f xxxx.yaml
2. 資源管理
#查看資源配置清單
kubectl get deployment nginx -o yaml
#解釋資源配置清單
kubectl explain deployment.metadata
kubectl get service nginx -o yaml
kubectl explain service.metadata
#修改資源配置清單并應(yīng)用
離線修改：
修改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文件內(nèi)容修改
文章來源：http://www.zghlxwxcb.cn/news/detail-636063.html
#刪除資源配置清單
陳述式刪除：
kubectl delete service nginx
聲明式刪除：
kubectl delete -f nginx-svc.yaml
文章來源地址http://www.zghlxwxcb.cn/news/detail-636063.html
總結(jié)
1. k8s 資源管理方式
#陳述式資源管理
kubectl create <資源類型> <資源名稱> -n 命名空間 [選項]
--image=鏡像 --replicas=副本數(shù) --port=容器端口
kubectl get <資源類型|all> [資源名稱] -n 命名空間 -o wide|yaml|json -w
kubectl describe <資源類型> <資源名稱> -n 命名空間
kubectl delete <資源類型> <資源名稱>|--all -n 命名空間 [--force --grace-period=0]
立即終止Pod運行，強制刪除資源
kubectl exec -it -n 命名空間 <Pod資源名稱> [-c 容器名稱] sh|bash
kubectl logs -n 命名空間 <Pod資源名稱> [-c 容器名稱] [-p]
kubectl scale -n 命名空間 deployment <資源名稱> --replicas=副本數(shù)
kubectl expose -n 命名空間 deployment <資源名稱> --name <自定義svc資源名稱> --port <clusterIP的端口> --target-port <容器的端口> --type <svc的類型>
kubectl create svc <svc資源類型> <資源名稱> --tcp=<clusterIP的端口>:<容器的端口>
kubectl set image deployment <資源名稱> <容器名>=<鏡像名>
kubectl rollout history deployment <資源名稱>
kubectl rollout undo deployment <資源名稱> [--to-revision= ]
kubectl rollout status deployment <資源名稱>
#聲明式資源管理
kubectl apply|create -f XXX.yaml
kubectl delete -f XXXml
kubectl edit <資源類型> <資源名稱>
kubectl explain <資源類型>.<字段1>.<字段2>
2. service 的四種類型
ClusterIp #默認的service資源的類型，提供clusterIP供K8S集群內(nèi)部訪問。
NodePort #會在每個Node節(jié)點上開啟一個端口，K8S集群內(nèi)部和外部的用戶可以通過NodeIP:NodePot訪問service以及關(guān)聯(lián)的Pod。
LoadBalancer #使用公有云的LB服務(wù)和service做映射，用戶可以使用公有云LB服務(wù)的IP地址即可將請求轉(zhuǎn)發(fā)到Node節(jié)點，再通過NodeIP:NodePort訪問service以及其關(guān)聯(lián)的Pod。
ExternaName #相當于給一個域名或IP做別名，Pod可以通過這個service訪問相關(guān)的外部服務(wù)。
3. service 的端口
prot #service 資源的 clusterIp 所使用的端口
nodePort #在 NodePort 類型的 service 所定義的，在每個node節(jié)點上開啟的端口（默認范圍30000~32767）
targePort #service 將 port 或 nodeport 轉(zhuǎn)發(fā)到的后端 Pod 的容器端口
containerPort #創(chuàng)建 Pod 時所指定的容器端口
K8S集群內(nèi)部 http://clusterIP:port ---> podIP:containerPort
K8S集群外部 http://nodeIP:nodeport ---> podIP:containerPort
4. 應(yīng)用的發(fā)布策略
藍綠發(fā)布
滾動發(fā)布
灰度發(fā)布/金絲雀發(fā)布
kubectl set image deployment <資源名稱> <容器名>=<鏡像名> && kubectl rollout pause deployment <資源名稱>
kubectl rollout resume deployment <資源名稱>
25% max unavailable 滾動更新過程中，銷毀的Pod數(shù)量不超過期望副本數(shù)的25%，向下取整
25% max surge 滾動更新過程中，新增的Pod數(shù)量不超過期望副本數(shù)的25%，向上取整
期望的Pod副本數(shù)是10個，銷毀的數(shù)量2，新增3 整個更新過程中Pod的數(shù)量會一致保持在 8 ~ 13
到了這里，關(guān)于【Kubernetes】Kubernetes之kubectl詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
