kubectl 安裝
參考https://blog.csdn.net/luanpeng825485697/article/details/80862581 文章中kubectl部分
linux命令行通過tab鍵自動補全的方式
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進入維護模式|
kubectl 輸出格式
顯示Pod的更多信息
kubectl get pod <pod-name> -o wide
以yaml格式顯示Pod的詳細信息
kubectl get pod <pod-name> -o yaml
kubectl 操作示例
創建資源對象create
kubectl命令用於根據文件或輸入創建集群resource。如果已經定義了相應resource的yaml或son文件
根據yaml配置文件一次性創建service和rc
kubectl create -f my-service.yaml -f my-rc.yaml
根據<directory>目錄下所有.yaml、.yml、.json文件的定義進行創建操作
kubectl create -f <directory>
查看資源對象get
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
kubectl edit
使用默認編輯器 編輯服務器上定義的資源。
使用命令行工具獲取的任何資源都可以使用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
Flags
| 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 |
kubectl 獲取資源屬性
例如獲取 pod的ip
kubectl -n naftis get pod -l app=naftis-ui -o jsonpath='{.items[0].status.podIP}'
其中我們通過-l app=naftis-ui 匹配pod，在jsonpath中指定要獲取的資源屬性
kubectl debug
部署集群代理
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 完成。
kubectl 同時管理多個集群
如果我們有多個集群，那我們就有多個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