您好,登錄后才能下訂單哦!
本篇內容介紹了“K8S中kubectl命令怎么使用”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
kubernetes集群管理集群資源的唯一入口是通過相應的方法調用apiserver的接口
kubectl 是官方的CLI命令行工具,用于與apiserver 進行通信,將用戶在命令行輸入的命令,組織并轉化為apiserver能識別的信息,進而實現管理k8s 各種資源的一種有效途徑
kubectl 的命令大全
kubectl --help
對資源的增、刪、查操作比較方便,但對改的操作就不容易
kubectl version
kubectl api-resources
kubectl cluster-info
source <(kubectl completion bash)
注意:此時命令補全功能切換環境后是不生效的,如果要使切換環境后也生效需要配置全局環境變量
vim /etc/bashrc ..... source <(kubectl completion bash) #在底部添加
journalctl -u kubelet -f 或者直接查看日志 cat /var/log/messages
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的資源
kubectl get componentstatuseskubectl get cs
命令空間的作用:用于允許不同 命令空間的相同類型的資源重名
kubectl get name space kubectl get ns
kubectl get all [-n default]
kubectl create ns app kubectl get ns
kubectl delete namespace app kubectl get ns
例:在命名空間kube-public 創建副本控制器( deployment) 來啟動Pod (nginx-cc)
kubectl create deployment nginx-cc --image=nginx -n kube-public
描述某個資源的詳細信息
kubectl describe deployment nginx-cc -n kube-public kubectl describe pod nginx-cc-5d7d5c6b54 -n kube-public
kubectl get pods -n kube-public
kubectl exec可以跨主機登錄容器,docker exec 只能在容器所在主機上登錄
kubectl exec -it nginx-cc-df5946cf-6k8rf bash -n kube-public
由于存在deployment/rc之類的副本控制器,刪除pod也會重新拉起來
kubectl delete pod nginx-cc-xxxxx -n kube-public
若pod無法刪除,總是處于terminate狀態, 則要強行刪除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0 #grace-period表示過渡存活期,默認30s,在刪除pod之前允許POD慢慢終止其上的容器進程, 從而優雅退出,0表示立即終止pod
kubectl scale deployment nginx-cc --replicas=3 -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-public
創建–>發布–>更新–>回滾–>刪除
創建并運行一個或多個容器鏡像
創建一個 deployment 或 job 來管理容器
kubectl run --help
##啟動 nginx 實例,暴露容器端口80,設置副本數 3 kubectl run nginx --image=nginx:1.14 --port=80 【--replicas=3】 注:【--replicas=3】 只是用老版本的k8s ,現在的新版本不能使用 kubectl get pods kubectl get all
將資源暴露為新的Service
kubectl expose --help
為deployment(無狀態部署)的nginx創建service, 并通過Service的80端口轉發至容器的80端口上,Service的名稱為nginx-service, 類型為NodePort
kubectl expose pod nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
Kubernetes之所以需要Service, 一方面是因為Pod的IP 不是固定的(Pod可能會重建),另一方面則是因為一組Pod實例之間總會有負載均衡的需求。
Service通過label Selector實現的對一組的Pod的訪問。
對于容器應用而言,Kubernetes 提供了基于VIP (虛擬IP)的網橋的方式訪問 Service, 再由Service 重定向到相應的Pod。
service的類型:1、ClusterIP:提供一個集群內部的虛擬IP以供Pod訪問( service默認類型
2、NodePort:在每個Node.上打開一個端口以供外部訪問,Kubernetes將會在每個Node.上打開一個端口并且每個Node的端口都是一樣的,通過NodeIp:NodePort的方式Kubernetes集群外部的程序可以訪問Service。
注:每個端口只能是一種服務,端口范圍只能是30000-32767
3、LoadBalancer:通過外部的負載均衡器來訪問,通常在云平臺部署LoadBalancer還需要額外的費用。
kubectl get pods,svc -o wide
kubectl get endpoints
kubect1 describe svc nginx
更改現有應用資源一些信息
kubectl set --help
kubectl set image --help
curl -I http://192.168.111.20:31828 curl -I http://192.168.111.30:31828
kubectl set image pod/nginx-deployment nginx=nginx:1.15
處于動態監聽pod狀態,由于使用的是滾動更新方式,所以會先生成--個新的pod,然后刪除--個舊的pod,往后依次類推(動態更新的)
kubectl get pods -o wide
kubectl rollout --help
kubectl rollout history deployment/nginx-test01 -n app
kubectl rollout undo deployment.apps/nginx-test01 -n app
kubectl rollout undo deployment.apps/nginx-test01 --to-revision=3 -n app
kubectl rollout status deployment/nginx
//刪除副本控制器 [root@master ~]# kubectl delete deployment/nginx deployment.extensions "nginx" deleted //刪除service [root@master ~]# kubectl delete svc/nginx-service service "nginx-service" deleted [root@master ~]# kubectl get all NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 15h service/nginx NodePort 10.96.59.53 <none> 80:31670/TCP 15h
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 #觀察更新狀態 (2)監控更新的過程,可以看到已經新增了一個資源,但是并未按照預期的狀態去刪除一個舊的資源, 就是因為使用了pause暫停命令 kubectl get pods -W curl [-I] 10.0.0.189 curl [-I] 192.168.111.20:44847 (3)確保更新的pod沒問題了,繼續更新 kubectl rollout resume deployment/nginx (4)查看最后的更新情況 kubectl get pods -W curl [-I] 10.0.0.189 curl [-I] 192.168.111.20:44847
適合于對資源的修改操作
聲明式資源管理方法依賴于資源配置清單文件對資源進行管理
資源配置清單文件有兩種格式: yaml(人性化,易讀),json(易于api接口解析)
對資源的管理,是通過事先定義在統一資源配置清單內,再通過陳述式命令應用到k8s集群里
語法格式: kubectl create/apply/delete -f xxxx. yaml
YAML,即 YAML Ain’t a Markup Language(YAML 不是一種標記語言)的遞歸縮寫。YAML 其實意思是 Yet Another Markup Language(仍是一種標記語言)。它主要強度這種語言是以數據為中心,而不是以標記為中心,而像 XML 語言就使用了大量的標記。
YAML 可讀性高,易于理解,用來表達數據序列化的格式。它的語法和其他高級語言類似,還可以簡單表達數組、散列表,標量等數據形態。它使用空白符號縮進和大量依賴外觀的特色,特別適合用來表達或編輯數據結構、各種配置文件。
YAML 配置文件后綴為.yml,例如application.yml。
yaml 和 json 的主要區別:
YAML 使用空格縮進,這是 Python 開發人員熟悉的領域。
JavaScript 開發人員喜歡 JSON,因為它是 JavaScript 的一個子集,可以直接在 JavaScript 中解釋和編寫,同時使用簡寫方式聲明 JSON,在使用沒有空格的典型變量名時,不需要鍵中的雙引號。
有很多解析器在 YAML 和 JSON 的所有語言中都能很好地工作。
在許多情況下,YAML 的空白格式可以更容易查看,因為格式化需要更人性化的方法。
如果您的編輯器中沒有空格可見或縮進線指示符,那么 YAML 的空白雖然更緊湊,更容易查看,但可能難以手動編輯。
JSON 的序列化和反序列化要快得多,因為要檢查的功能明顯少于 YAML,這使得更小更輕的代碼能夠處理 JSON。
一個常見的誤解是 YAML 需要較少的標點符號并且比 JSON 更緊湊,但這完全是錯誤的。空格是不可見的,所以看起來字符較少,但是如果你計算實際的空格是必要的,以便正確解釋 YAML 以及正確的縮進,你會發現 YAML 實際上需要比 JSON 更多的字符。JSON 不使用空格來表示層次結構或分組,并且可以通過刪除不必要的空格來輕松展平,以實現更緊湊的傳輸。
Kubernetes支持YAML和JSON 格式管理資源對象
JSON格式:主要用于api接口之間消息的傳遞
YAML格式:用于配置和管理,YAML的配置參數格式比較清晰
語法格式:
大小寫敏感
以空格的方式縮進標識層級關系
通常開頭縮進兩個空格(統一層級對應即可)
不支持制表符“tab”縮進,只使用空格縮進
關鍵詞字符后縮進一個空格,比如冒號,逗號后面需要縮進一個字符
“---”表示YAML格式,一個文件的開始支持以“#”表示注釋
控制器定義
被控制對象
字段說明:
apiVersion | API版本 |
kind | 資源類型 |
metadata | 資源元數據 |
spec | 資源規格 |
replicas | 副本數量 |
selector | 標簽選擇器 |
template | Pod模板 |
metadata | Pod元數據 |
spec | Pod規格 |
container | 容器配置 |
K8S---apiVersion對照表:點擊這里
kubectl api-versions
如果是業務場景,一般首選使用 apps/v1(apps/v1 從 v1.9 版本開始提供 API)。
在 k8s v1.16 版本之前使用的是 extensions/v1beta1,extensions/v1beta1 從 v1.20 版本開始不再提供 Ingress 資源。
帶有 beta 字樣的代表的是測試版本,不用在生產環境中。
mkdir /opt/demo cd /opt/demo/ 參考模板: vim nginx-deployment.yaml apiVersion: apps/v1 #指定api版本標簽 kind: Deployment #定義資源的類型/角色,deployment 為副本控制器, 此處資源類型可以是Deployment、Job、 Ingress、 Service等 metadata: #定義資源的元數據信息,比如資源的名稱、namespace、標簽等信息 name: nginx-deployment #定義資源的名稱,在同一個namespace空間中必須是唯一的 labels: #定義資源標簽(Pod的標簽) app: nginx spec: #定義deployment資源需要的參數屬性,諸如是否在容器失敗時重新啟動容器的屬性 replicas: 3 #定義副本數量 selector : #定義標簽選擇器 matchLabels: #定義匹配標簽 app: nginx #匹配上面的標簽,需與上面的標簽定義的app保持一致 template: #定義業務模板,如果有多個副本,所有副本的屬性會按照模板的相關配置進行匹配 metadata: labels: app: nginx spec: containers: #定義容器屬性 - name: nginx #定義一個容器名,一個- name: 定義一個容器 image: nginx:1.15.4 #定義容器使用的鏡像以及版本 ports: - containerPort: 80 #定義容器的對外的端口 實例: vim nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: kube-public labels: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx-demo1 template: metadata: labels: app: nginx-demo1 spec: containers: - name: nginx image: nginx:1.15.4 ports: - name: http containerPort: 80
kubectl create -f nginx-deployment.yaml 或者 kubectl apply -f nginx-deployment.yaml
kubectl get pods -o wide -n kube-public kubectl get deploy -n kube-public
apiVersion: v1 kind: Service metadata: name: nginx-demo1 namespace: kube-public labels: name: nginx-demo1 spec: type: NodePort ports: - port: 8080 targetPort: 80 nodePort: 31333 selector: app: nginx-demo1
kubectl apply -f nginx-server.yaml kubectl get svc -n kube-public
在瀏覽器輸入 nodeIP: nodePort 即可訪問 http://192.168.111.20:31333 http://192.168.111.30:31333
●port
port是k8s集群內部訪問service的端口,即通過clusterIP: port可以從Pod所在的Node. 上訪問到service
●nodePort
nodePort是外部訪問k8s集群中service的端口,通過nodeIP: nodePort 可以從外部訪問到某個service。
●targetPort
targetPort是Pod的端口,從port或nodePort來的流量經過kube-proxy 反向代理負載均衡轉發到后端Pod的targetPort上,最后進入容器。
●containerPort
containerPort是Pod內部容器的端口,targetPort 映射到containerPort
kubectl run --dry-run 打印相應的API 對象 而不執行創建
--dry-run
:試運行
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run
--dry-run
表示試運行,不真正執行命令(測試命令是否正確),即并不會真的創建出 pod 和 deployment 實例,去掉該參數后即可真正執行命令。
使用--dry-run
試運行可不觸發生成命令,然后通過-o yaml
可實現對其 yaml 資源配置清單的查看
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml
可通過 -o json 查看該命令產生的 json 配置清單
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o json
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > nginx-test.yaml
模板: vim nginx-test.yaml apiVersion: apps/v1betal #api 版本改成 api/v1 kind: Deployment metadata: creationTimestamp: null #刪除 labels: run: nginx-test name: nginx-test spec: replicas: 3 selector: matchLabels: run: nginx-test strategy: {} #刪除 template: metadata: creationTimestamp: null #刪除 labels: run: nginx-test spec: containers: - image: nginx name: nginx-test ports: - containerPort: 80 resources: {} #刪除 status: {} #刪除 例: apiVersion: v1 kind: Service metadata: labels: name: nginx-demo2 name: nginx-demo2 namespace: kube-public spec: ports: - port: 8044 protocol: TCP targetPort: 80 selector: run: nginx-demo2 type: NodePort
kubectl apply -f nginx-test.yaml kubectl get svc -n kube-public
kubectl get pod/nginx-deployment-6f9f6d866c-2w9gz -o yaml -n kube-public ###注現在最新版本的kubctl get 不支持 --export 參數
kubectl get deployment.apps/nginx-deployment -o yaml -n kube-public > my-deploy.yaml
explain 可一層層的查看相關資源對象的幫助信息
kubectl explain deployments.spec.template.spec.containers 或 kubectl explain pods.spec.containers
沒有相關資源,使用run或者create命令--dry-run
選項,后期可以修改yaml文件。
kubectl run my-deploy --image=nginx --dry-run -o yaml > my-deploy.yaml
已有相關資源,使用get命令 【--export
選項 :適用老版本的kubectl】
kubectl get deploy/nginx-deployment -o=yaml -n kube-public > new.yaml
yaml文件的學習方法
(1)多看別人(官方)寫的,能讀懂
(2)能照著現場的文件改著用
(3)遇到不懂的,善用kubectl explain ...命令查
“K8S中kubectl命令怎么使用”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。