參考https://blog.csdn.net/luanpeng825485697/article/details/80862581 文章中kubectl部分java
linux命令行經過tab鍵自動補全的方式node
source <(kubectl completion bash) echo "source <(kubectl completion bash)" >> ~/.bashr
kubectl annotate – 更新資源的註解。
kubectl api-versions – 以「組/版本」的格式輸出服務端支持的API版本。
kubectl apply – 經過文件名或控制檯輸入,對資源進行配置。
kubectl attach – 鏈接到一個正在運行的容器。
kubectl autoscale – 對replication controller進行自動伸縮。
kubectl cluster-info – 輸出集羣信息。
kubectl config – 修改kubeconfig配置文件。
kubectl create – 經過文件名或控制檯輸入,建立資源。
kubectl delete – 經過文件名、控制檯輸入、資源名或者label selector刪除資源。
kubectl describe – 輸出指定的一個/多個資源的詳細信息。
kubectl edit – 編輯服務端的資源。
kubectl exec – 在容器內部執行命令。
kubectl expose – 輸入replication controller,service或者pod,並將其暴露爲新的kubernetes service。
kubectl get – 輸出一個/多個資源。
kubectl label – 更新資源的label。
kubectl logs – 輸出pod中一個容器的日誌。
kubectl namespace -(已停用)設置或查看當前使用的namespace。
kubectl patch – 經過控制檯輸入更新資源中的字段。
kubectl port-forward – 將本地端口轉發到Pod。
kubectl proxy – 爲Kubernetes API server啓動代理服務器。
kubectl replace – 經過文件名或控制檯輸入替換資源。
kubectl rolling-update – 對指定的replication controller執行滾動升級。
kubectl run – 在集羣中使用指定鏡像啓動容器。
kubectl scale – 爲replication controller設置新的副本數。
kubectl stop – (已停用)經過資源名或控制檯輸入安全刪除資源。
kubectl version – 輸出服務端和客戶端的版本信息。
kubectl cordon 設定node不可以使用|
kubectl uncordon 設定node可使用|
kubectl drain 設定node進入維護模式|python
顯示Pod的更多信息linux
kubectl get pod <pod-name> -o wide
以yaml格式顯示Pod的詳細信息nginx
kubectl get pod <pod-name> -o yaml
建立資源對象creategit
kubectl命令用於根據文件或輸入建立集羣resource。若是已經定義了相應resource的yaml或son文件github
根據yaml配置文件一次性建立service和rcredis
kubectl create -f my-service.yaml -f my-rc.yaml
根據<directory>
目錄下全部.yaml、.yml、.json文件的定義進行建立操做sql
kubectl create -f <directory>
查看資源對象getdocker
get命令用於獲取集羣的一個或一些resource信息。resource包括集羣節點、運行的pod,ReplicationController,service等。
查看全部Pod列表
kubectl get pods
查看rc和service列表
kubectl get rc,service
通常狀況下使用時,須要你加入namespace來肯定在哪一個命名空間下查找
查看safety空間下全部pod在哪一個節點上:
kubectl get pods -o wide -n safety
描述資源對象describe
describe相似於get,一樣用於獲取resource的相關信息。不一樣的是,get得到的是更詳細的resource個性的詳細信息,describe得到的是resource集羣相關的信息。describe命令同get相似,可是describe不支持-o選項,對於同一類型resource,describe輸出的信息格式,內容域相同。
顯示Node的詳細信息
kubectl describe nodes <node-name>
顯示Pod的詳細信息
kubectl describe pods/<pod-name>
顯示由RC管理的Pod的信息
kubectl describe pods <rc-name>
更新替換資源replace
replace命令用於對已有資源進行更新、替換。如前面create中建立的nginx,當咱們須要更新resource的一些屬性的時候,好比修改副本數量,增長、修改label,更改image版本,修改端口等。均可以直接修改原yaml文件,而後執行replace命令。
注:名字不能被更新。另外,若是是更新label,原有標籤的pod將會與更新label後的rc斷開聯繫,有新label的rc將會建立指定副本數的新的pod,可是默認並不會刪除原來的pod。因此此時若是使用get po將會發現pod數翻倍,進一步check會發現原來的pod已經不會被新rc控制,此處只介紹命令不詳談此問題,好奇者可自行實驗。
kubectl replace -f rc-nginx.yaml
修復資源patch
若是一個容器已經在運行,這時須要對一些容器屬性進行修改,又不想刪除容器,或不方便經過replace的方式進行更新。kubernetes還提供了一種在容器運行時,直接對容器進行修改的方式,就是patch命令。
如前面建立pod的label是app=nginx-2,若是在運行過程當中,須要把其label改成app=nginx-3,這patch命令以下:
kubectl patch pod rc-nginx-2-kpiqt -p '{"metadata":{"labels":{"app":"nginx-3"}}}'
刪除資源對象delete
根據resource名或label刪除resource。
基於Pod.yaml定義的名稱刪除Pod
kubectl delete -f pod.yaml
刪除全部包含某個label的Pod和service
kubectl delete pods,services -l name=<label-name>
刪除全部Pod
kubectl delete pods --all
執行容器的命令exec
exec命令一樣相似於docker的exec命令,爲在一個已經運行的容器中執行一條shell命令,若是一個pod容器中,有多個容器,須要使用-c選項指定容器。
執行Pod的data命令,默認是用Pod中的第一個容器執行
kubectl exec <pod-name> data
指定Pod中某個容器執行data命令
kubectl exec <pod-name> -c <container-name> data
經過bash得到Pod中某個容器的TTY,至關於登陸容器
kubectl exec -it <pod-name> -c <container-name> bash
6.Pod的擴容與縮容scale
scale用於程序在負載加劇或縮小時副本進行擴容或縮小,如前面建立的nginx有兩個副本,能夠輕鬆的使用scale命令對副本數進行擴展或縮小。
執行擴容縮容Pod的操做
kubectl scale rc redis --replicas=3
咱們須要確認的是在rc配置文件中定義的replicas數量,當咱們執行上述命令的結果大於replicas的數量時,則咱們執行的命令至關於擴容操做,反之相反,能夠理解爲咱們填寫的數量是咱們須要的Pod數量。須要注意的是,當咱們須要進行永久性擴容時,不要忘記修改rc配置文件中的replicas數量。
7.Pod的滾動升級rolling-update
rolling-update是一個很是重要的命令,對於已經部署而且正在運行的業務,rolling-update提供了不中斷業務的更新方式。rolling-update每次起一個新的pod,等新pod徹底起來後刪除一箇舊的pod,而後再起一個新的pod替換舊的pod,直到替換掉全部的pod。
執行滾動升級操做
kubectl rolling-update redis -f redis-rc.update.yaml
須要注意的是當咱們執行rolling-update命令前須要準備好新的RC配置文件以及ConfigMap配置文件,RC配置文件中須要指定升級後須要使用的鏡像名稱,或者可使用kubeclt rolling-update redis --image=redis-2.0直接指定鏡像名稱的方式直接升級。
日誌logs
logs命令用於顯示pod運行中,容器內程序輸出到標準輸出的內容。跟docker的logs命令相似。若是要得到tail -f 的方式,也可使用-f選項。
kubectl logs rc-nginx-2-kpiqt
標籤label
爲kubernetes集羣的resource打標籤,如前面實例中提到的爲rc打標籤對rc分組。還能夠對nodes打標籤,這樣在編排容器時,能夠爲容器指定nodeSelector將容器調度到指定lable的機器上,如若是集羣中有IO密集型,計算密集型的機器分組,能夠將不一樣的機器打上不一樣標籤,而後將不一樣特徵的容器調度到不一樣分組上。
在1.2以前的版本中,使用kubectl get nodes則能夠列出全部節點的信息,包括節點標籤,1.2版本中再也不列出節點的標籤信息,若是須要查看節點被打了哪些標籤,須要使用describe查看節點的信息。
英文 簡寫
clusters (僅對federation apiservers有效)
componentstatuses (縮寫 cs)
configmaps (縮寫 cm)
daemonsets (縮寫 ds)
deployments (縮寫 deploy)
endpoints (縮寫 ep)
events (縮寫 ev)
horizontalpodautoscalers (縮寫 hpa)
ingresses (縮寫 ing)
jobs
limitranges (縮寫 limits)
namespaces (縮寫 ns)
networkpolicies
nodes (縮寫 no)
persistentvolumeclaims (縮寫 pvc)
persistentvolumes (縮寫 pv)
pods (縮寫 po)
podsecuritypolicies (縮寫 psp)
podtemplates
replicasets (縮寫 rs)
replicationcontrollers (縮寫 rc)
resourcequotas (縮寫 quota)
secrets
serviceaccounts (縮寫 sa)
services (縮寫 svc)
statefulsets
storageclasses
thirdpartyresources
使用默認編輯器 編輯服務器上定義的資源。
使用命令行工具獲取的任何資源均可以使用edit命令編輯。edit命令會打開使用KUBE_EDITOR,GIT_EDITOR 或者EDITOR環境變量定義的編輯器,能夠同時編輯多個資源,但所編輯過的資源只會一次性提交。edit除命令參數外還接受文件名形式。
文件默認輸出格式爲YAML。要以JSON格式編輯,請指定「-o json」選項。
若是在更新資源時報錯,將會在磁盤上建立一個臨時文件來記錄。在更新資源時最多見的錯誤是幾個用戶同時使用編輯器更改服務器上資源,發生這種狀況,你須要將你的更改應用到最新版本的資源上,或者更新保存的臨時副本。
示例
編輯名爲’docker-registry’的service:
kubectl edit svc/docker-registry
使用替代的編輯器
KUBE_EDITOR="nano" kubectl edit svc/docker-registry
編輯名爲「myjob」的service,輸出JSON格式 V1 API版本
kubectl edit job.v1.batch/myjob -o json
以YAML格式輸出編輯deployment「mydeployment」,並將修改的配置保存在annotation中:
kubectl edit deployment/mydeployment -o yaml --save-config
Name | Shorthand | Default | Usage |
filename | f | [] | Filename, directory, or URL to files to use to edit the resource |
include-extended-apis | true | If true, include definitions of new APIs via calls to the API server. [default true] | |
output | o | yaml | Output format. One of: yaml |
record | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. |
|
recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. |
save-config | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. |
|
schema-cache-dir | ~/.kube/schema | If non-empty, load/store cached API schemas in this directory, default is ‘$HOME/.kube/schema’ | |
validate | true | If true, use a schema to validate the input before sending it | |
windows-line-endings | false | Use Windows line-ending |
例如獲取 pod的ip
kubectl -n naftis get pod -l app=naftis-ui -o jsonpath='{.items[0].status.podIP}'
其中咱們經過-l app=naftis-ui
匹配pod,在jsonpath中指定要獲取的資源屬性
部署集羣代理
kubectl apply -f https://raw.githubusercontent.com/aylei/kubectl-debug/master/scripts/agent_daemonset.yml
安裝客戶端插件
# Linux curl -Lo kubectl-debug https://github.com/aylei/kubectl-debug/releases/download/0.0.1/kubectl-debug_0.0.1_linux-amd64 # MacOS curl -Lo kubectl-debug https://github.com/aylei/kubectl-debug/releases/download/0.0.1/kubectl-debug_0.0.1_macos-amd64 chmod +x ./kubectl-debug mv kubectdl-debug /usr/local/bin/
添加客戶端配置文件~/.kube/debug-config
:
agent_port: 10027 # 可使用本身的鏡像 image: nicolaka/netshoot:latest command: - '/bin/bash' - '-l'
配一個Dockerfile,能夠本身構建debug鏡像
# docker build -t luanpeng/lp:debug . FROM ubuntu:18.04 RUN apt update && \ apt install -y python3.6-dev python3-pip openjdk-8-jdk ca-certificates-java ant ntpdate curl iputils-ping net-tools wget tcpdump iftop htop jq unzip zip sqlline iptables telnet vim jmeter && \ ln -s /usr/bin/python3.6 /usr/bin/python && \ ln -s /usr/bin/pip3 /usr/bin/pip && \ pip install aiohttp pika requests ray uvloop asyncio gunicorn && \ rm -rf /root/.cache && \ rm -rf /var/lib/apt/lists/* && \ apt clean
具體到實現上,一條 kubectl debug命令背後是這樣的:
步驟分別是:
插件查詢 ApiServer:demo-pod 是否存在,所在節點是什麼
ApiServer 返回 demo-pod 所在所在節點
插件請求在目標節點上建立 Debug Agent Pod
Kubelet 建立 Debug Agent Pod
插件發現 Debug Agent 已經 Ready,發起 debug 請求(長鏈接)
Debug Agent 收到 debug 請求,建立 Debug 容器並加入目標容器的各個 Namespace 中,建立完成後,與 Debug 容器的 tty 創建鏈接
接下來,客戶端就能夠開始經過 5,6 這兩個鏈接開始 debug 操做。操做結束後,Debug Agent 清理 Debug 容器,插件清理 Debug Agent,一次 Debug 完成。
若是咱們有多個集羣,那咱們就有多個config文件。若是切換須要替換config文件,這比較麻煩,咱們能夠在一個config文件裏面把多個集羣配置在一塊兒。
好比咱們有兩個config文件,分別以下
current-context: "contexts1" apiVersion: v1 kind: Config clusters: - name: "cluster1" cluster: server: "xxxxxxxxxxxxxxxxx" api-version: v1 certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" users: - name: "user1" user: token: "xxxxxxxxxxxxxxxx" contexts: - name: "contexts1" context: user: "user1" cluster: "cluster1"
current-context: "contexts2" apiVersion: v1 kind: Config clusters: - name: "cluster2" cluster: server: "xxxxxxxxxxxxxxxxx" api-version: v1 certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" users: - name: "user2" user: token: "xxxxxxxxxxxxxxxx" contexts: - name: "contexts2" context: user: "user2" cluster: "cluster2"
咱們能夠手動將兩個文件合併成一個
current-context: "contexts1" apiVersion: v1 kind: Config clusters: - name: "cluster1" cluster: server: "xxxxxxxxxxxxxxxxx" api-version: v1 certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" - name: "cluster2" cluster: server: "xxxxxxxxxxxxxxxxx" api-version: v1 certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" users: - name: "user1" user: token: "xxxxxxxxxxxxxxxx" - name: "user2" user: token: "xxxxxxxxxxxxxxxx" contexts: - name: "contexts1" context: user: "user1" cluster: "cluster1" - name: "contexts2" context: user: "user2" cluster: "cluster2"
這樣咱們就能夠經過命令切換集羣了。
kubectl config use-context contexts2
參考:
https://blog.csdn.net/luanpeng825485697/article/details/80874741