摘要

本文介紹k8s集群管理命令Kubectl分類和命令詳解。

內(nèi)容

1. kubectl命令列表分類

（1）Basic Commands(Beginner)基礎(chǔ)命令（初級(jí)）

kubectl create  通過yaml/json 文件或者標(biāo)準(zhǔn)輸入創(chuàng)建一個(gè)資源對(duì)象，支持很多子命令 例如namespace pod deployment service等
kubectl expose  將json/yaml文件中定義的資源對(duì)象的端口暴露給新的service資源對(duì)象
kubectl run 創(chuàng)建并運(yùn)行一個(gè)或多個(gè)容器鏡像
kubectl set 配置資源對(duì)象設(shè)置特定功能

（2）Basic Commands（Intermediate）基礎(chǔ)命令（中級(jí)）

kubectl explain 查看資源對(duì)象的詳細(xì)信息(一般用一編寫yaml的時(shí)候做一個(gè)提示 kubectl explain deployment 會(huì)出現(xiàn)deployment下面可以寫的字段以及字段屬性還有 可以逐級(jí)使用)
kubectl get 獲取一個(gè)或多個(gè)資源對(duì)象的信息
kubectl edit    使用默認(rèn)編輯器編輯服務(wù)器上定義的資源對(duì)象
kubectl delete  通過json/yaml文件、標(biāo)準(zhǔn)舒服、資源名稱或標(biāo)簽選擇器來(lái)刪除資源

（3）DeployCommands 部署命令

kubectl rollout 資源管理對(duì)象的部署
kubectl rollout-update  使用rc（replication controller）來(lái)做滾動(dòng)恩星
kubectl scale   擴(kuò)容或者縮容deployment replicaset replication contrller等
kubectl autoscale   自動(dòng)設(shè)置在k8s系統(tǒng)中運(yùn)行的pod數(shù)量（水平自動(dòng)伸縮）

（4）Cluster Manager Commands 集群管理命令

kubectl cetificate  修改證書資源對(duì)象
kubectl cluster-info    查看集群信息
kubectl top 顯示資源 cpu 內(nèi)存 存儲(chǔ)使用情況
kubectl cordon  標(biāo)記節(jié)點(diǎn)為不可調(diào)度
kubectl uncordon    指定節(jié)點(diǎn)為可調(diào)度
kubectl drain   安全的驅(qū)逐節(jié)點(diǎn)的所有pod
kubectl taint   將一個(gè)或多個(gè)節(jié)點(diǎn)設(shè)置為污點(diǎn)

（5）Troubleshooting adn Debugging Commands 故障排查和調(diào)試命令

kubectl describe    顯示一個(gè)或多個(gè)資源對(duì)象的詳細(xì)信息
kubectl logs    輸出pod資源對(duì)象中一個(gè)容器的日志
kubectl attach  連接到一個(gè)運(yùn)行的容器
kubectl exec    在指定容器內(nèi)執(zhí)行命令
kubectl port-forward    將本機(jī)指定端口映射到pod資源對(duì)象的端口
kubectl proxy   將本機(jī)指定端口映射到kube-apiserver
kubectl cp  用于pod與主機(jī)交換文件
kubectl auth    檢查驗(yàn)證

（6） Advanced Commands 高級(jí)命令

kubectl diff    對(duì)比本地json/yaml文件與kube-apiserver中運(yùn)行的配置文件是否有差異
kubectl apply   通過json/yaml文件 標(biāo)準(zhǔn)輸入對(duì)資源進(jìn)行配置更新或者創(chuàng)建
kubectl patch   通過patch方式修改資源對(duì)象字段（補(bǔ)丁式）
kubectl replace 通過json/yaml文件或者標(biāo)準(zhǔn)輸入來(lái)替換資源對(duì)象
kubectl wait    在一個(gè)或者多個(gè)資源上等待條件達(dá)成
kubectl convert 轉(zhuǎn)換json/yaml文件為不同的資源版本
kubectl kustomize   定制kubernetes配置

（7）Settings Commands 設(shè)置命令

kubectl label   增刪改資源的標(biāo)簽
kubectl annotate    更新一個(gè)或者多個(gè)資源對(duì)象的注釋（annotaion）信息
kubectl completion  命令自動(dòng)補(bǔ)全

（8）Other Commands 其他命令

kubectl config  管理kubeconfig配置文件
kubectl plugin  運(yùn)行命令行插件功能
kubectl version 查看客戶端服務(wù)端的系統(tǒng)版本信息
kubectl api-versions    列出當(dāng)前kubernetes系統(tǒng)支持的資源組和資源版本表現(xiàn)形式為/
kubectl api-resources   列出當(dāng)前kubernetes系統(tǒng)支持的resource資源列表
kubectl options 查看支持的參數(shù)列表

2. Basic Commands(Beginner)基礎(chǔ)命令（初級(jí)）

（1）kubectl create

通過配置文件名或stdin創(chuàng)建一個(gè)集群資源對(duì)象。
支持JSON和YAML格式的文件。

語(yǔ)法

$ create -f FILENAME

示例
通過pod.json文件創(chuàng)建一個(gè)pod。

kubectl create -f ./pod.json

通過stdin的JSON創(chuàng)建一個(gè)pod。

cat pod.json | kubectl create -f -

API版本為v1的JSON格式的docker-registry.yaml文件創(chuàng)建資源。

kubectl create -f docker-registry.yaml --edit --output-version=v1 -o json

（2）kubectl expose

將資源暴露為新的Kubernetes Service。
指定deployment、service、replica set、replication controller或pod ，并使用該資源的選擇器作為指定端口上新服務(wù)的選擇器。deployment 或 replica set只有當(dāng)其選擇器可轉(zhuǎn)換為service支持的選擇器時(shí)，即當(dāng)選擇器僅包含matchLabels組件時(shí)才會(huì)作為暴露新的Service。
資源包括(不區(qū)分大小寫)：
pod（po），service（svc），replication controller（rc），deployment（deploy），replica set（rs）。

語(yǔ)法

$ expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]

示例

為RC的nginx創(chuàng)建service，并通過Service的80端口轉(zhuǎn)發(fā)至容器的8000端口上。

kubectl expose rc nginx --port=80 --target-port=8000

由“nginx-controller.yaml”中指定的type和name標(biāo)識(shí)的RC創(chuàng)建Service，并通過Service的80端口轉(zhuǎn)發(fā)至容器的8000端口上。

kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000

其它詳細(xì)說明

（3）kubectl run

（4）kubectl set 配置資源對(duì)象設(shè)置特定功能

配置應(yīng)用資源。
使用這些命令能幫你更改現(xiàn)有應(yīng)用資源一些信息。

語(yǔ)法

$ set SUBCOMMAND

子命令
image
resources
selector
subject

3. Basic Commands（Intermediate）基礎(chǔ)命令（中級(jí)）

（1）kubectl explain

（2）kubectl get

語(yǔ)法

kubectl get resource_name

常見resource_name

all
certificatesigningrequests (縮寫 csr)
clusterrolebindings
clusterrol
componentstatuses (縮寫 cs)
configmaps (縮寫 cm)
controllerrevisions
cronjobs
customresourcedefinition (縮寫 crd)
daemonsets (縮寫 ds)
deployments (縮寫 deploy)
endpoints (縮寫 ep)
events (縮寫 ev)
horizontalpodautoscalers (縮寫 hpa)
ingresses (縮寫 ing)
jobs
limitranges (縮寫 limits)
namespaces (縮寫 ns)
networkpolicies (縮寫 netpol)
nodes (縮寫 no)
persistentvolumeclaims (縮寫 pvc)
persistentvolumes (縮寫 pv)
poddisruptionbudgets (縮寫 pdb)
podpreset
pods (縮寫 po)
podsecuritypolicies (縮寫 psp)
podtemplates
replicasets (縮寫 rs)
replicationcontrollers (縮寫 rc)
resourcequotas (縮寫 quota)
rolebindings
roles
secrets
serviceaccounts (縮寫 sa)
services (縮寫 svc)
statefulsets (縮寫 sts)
storageclasses (縮寫 sc)

其它可選參數(shù)
用不同的格式查看：

 -o wide/yaml/json

看指定標(biāo)簽的pods，支持’=’, ‘==’, and ‘!=’操作符

-l key=value

舉例

# 查看Master狀態(tài)
kubectl get componentstatuses
 
# 查看所有命名空間
kubectl get namespaces
 
# 列出所有的pods
kubectl get pods
 
# 顯示更多的pods列表信息(例如 pod的ip和所處的node)
kubectl get pods -o wide
 
# 列出名字為web的rc
kubectl get replicationcontroller web
 
# 獲取名字為web-pod-13je7的pod的信息，并以json格式輸出
kubectl get -o json pod web-pod-13je7
 
# 根據(jù)pod文件查找pod，并以json格式輸出
kubectl get -f pod.yaml -o json
 
# 獲取pod容器的狀態(tài)
kubectl get -o template pod/kube-dns-795f5f6f9c-ldxxs --template {{.status.phase}}
 
# 同時(shí)獲取所有的rc和service
kubectl get rc,services
 
# 獲取符合條件的所有rc,svc,pod
kubectl get rc/web service/frontend pods/web-pod-13je7
 
# 獲取所有resource
kubectl get all

（3）kubectl edit

使用默認(rèn)編輯器 編輯服務(wù)器上定義的資源。
使用命令行工具獲取的任何資源都可以使用edit命令編輯。edit命令會(huì)打開使用KUBE_EDITOR，GIT_EDITOR 或者EDITOR環(huán)境變量定義的編輯器，可以同時(shí)編輯多個(gè)資源，但所編輯過的資源只會(huì)一次性提交。edit除命令參數(shù)外還接受文件名形式。
文件默認(rèn)輸出格式為YAML。要以JSON格式編輯，請(qǐng)指定“-o json”選項(xiàng)。
如果在更新資源時(shí)報(bào)錯(cuò)，將會(huì)在磁盤上創(chuàng)建一個(gè)臨時(shí)文件來(lái)記錄。在更新資源時(shí)最常見的錯(cuò)誤是幾個(gè)用戶同時(shí)使用編輯器更改服務(wù)器上資源，發(fā)生這種情況，你需要將你的更改應(yīng)用到最新版本的資源上，或者更新保存的臨時(shí)副本。

語(yǔ)法

$ edit (RESOURCE/NAME | -f FILENAME)

示例
編輯名為'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

（4）kubectl delete

通過配置文件名、stdin、資源名稱或label選擇器來(lái)刪除資源。
支持JSON和YAML格式文件?？梢灾恢付ㄒ环N類型的參數(shù)：文件名、資源名稱或label選擇器。

有些資源，如pod，支持優(yōu)雅的（graceful）刪除，因?yàn)檫@些資源一般是集群中的實(shí)體，所以刪除不可能會(huì)立即生效，這些資源在強(qiáng)制終止之前默認(rèn)定義了一個(gè)周期（寬限期），但是你可以使用--grace-period flag來(lái)覆蓋該值，或者通過pass --now設(shè)置該周期為1。
如果托管Pod的Node節(jié)點(diǎn)已經(jīng)停止或者無(wú)法連接API Server，使用delete命令刪除Pod需等待時(shí)間更長(zhǎng)。要強(qiáng)制刪除資源，需指定- force flag，且設(shè)置周期（寬限期）為0。
如果執(zhí)行強(qiáng)制刪除Pod，則調(diào)度程序會(huì)在節(jié)點(diǎn)釋放這些Pod之前將新的Pod放在這些節(jié)點(diǎn)上，并使之前Pod立即被逐出。

注意：執(zhí)行delete命令時(shí)不會(huì)檢查資源版本，如果在執(zhí)行delete操作時(shí)有人進(jìn)行了更新操作，那么更新操作將連同資源一起被刪除。

語(yǔ)法

$ delete ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

示例
使用 pod.json中指定的資源類型和名稱刪除pod。

kubectl delete -f ./pod.json

根據(jù)傳入stdin的JSON所指定的類型和名稱刪除pod。

cat pod.json | kubectl delete -f -

刪除名為“baz”和“foo”的Pod和Service。

kubectl delete pod,service baz foo

刪除 Label name = myLabel的pod和Service。

kubectl delete pods,services -l name=myLabel

強(qiáng)制刪除dead node上的pod

kubectl delete pod foo --grace-period=0 --force

刪除所有pod

kubectl delete pods --all

Flags

4. DeployCommands 部署命令

（1）kubectl rollout

對(duì)資源進(jìn)行管理，可用資源包括：
deployments
daemonsets

子命令

• history（查看歷史版本）
• pause（暫停資源）
• resume（恢復(fù)暫停資源）
• status（查看資源狀態(tài)）
• undo（回滾版本）

語(yǔ)法

$ rollout SUBCOMMAND

示例
回滾到之前的deployment

kubectl rollout undo deployment/abc

查看daemonet的狀態(tài)

kubectl rollout status daemonset/foo

[1] kubectl rollout history

查看之前推出的版本（歷史版本）。

語(yǔ)法

$ history (TYPE NAME | TYPE/NAME) [flags]

示例
查看deployment的歷史記錄

kubectl rollout history deployment/abc

查看daemonset修訂版3的詳細(xì)信息

kubectl rollout history daemonset/abc --revision=3

[2] kubectl rollout pause

將提供的資源標(biāo)記為暫停,被pause命令暫停的資源不會(huì)被控制器協(xié)調(diào)使用，可以是“kubectl rollout resume”命令恢復(fù)已暫停資源。
目前僅支持的資源：deployments。

語(yǔ)法

$ pause RESOURCE

示例
將deployment標(biāo)記為暫停。＃只要deployment在暫停中，使用deployment更新將不會(huì)生效。

kubectl rollout pause deployment/nginx

[3] kubectl rollout resume

恢復(fù)已暫停的資源

被pause命令暫停的資源將不會(huì)被控制器協(xié)調(diào)使用。可以通過resume來(lái)恢復(fù)資源。目前僅支持恢復(fù)deployment資源。

語(yǔ)法

$ resume RESOURCE

示例
恢復(fù)已暫停的 deployment

kubectl rollout resume deployment/nginx

[4] kubectl rollout status

查看資源的狀態(tài)。

使用—watch = false 來(lái)查看當(dāng)前狀態(tài)，需要查看特定修訂版本狀態(tài) 請(qǐng)使用--revision = N 來(lái)指定。

語(yǔ)法

$ status (TYPE NAME | TYPE/NAME) [flags]

示例
查看deployment的狀態(tài)

kubectl rollout status deployment/nginx

[5] kubectl rollout undo

回滾到之前的版本。

語(yǔ)法

$ undo (TYPE NAME | TYPE/NAME) [flags]

示例
回滾到之前的deployment版本

kubectl rollout undo deployment/abc
kubectl rollout undo --dry-run=true deployment/abc

回滾到daemonset 修訂3版本

kubectl rollout undo daemonset/abc --to-revision=3

（2）kubectl rollout-update

（3）kubectl scale

擴(kuò)容或縮容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod數(shù)量。
scale也可以指定多個(gè)前提條件，如：當(dāng)前副本數(shù)量或 --resource-version ，進(jìn)行伸縮比例設(shè)置前，系統(tǒng)會(huì)先驗(yàn)證前提條件是否成立。

語(yǔ)法

scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)

示例
將名為foo中的pod副本數(shù)設(shè)置為3。

kubectl scale --replicas=3 rs/foo

將由“foo.yaml”配置文件中指定的資源對(duì)象和名稱標(biāo)識(shí)的Pod資源副本設(shè)為3。

kubectl scale --replicas=3 -f foo.yaml

如果當(dāng)前副本數(shù)為2，則將其擴(kuò)展至3。

kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

設(shè)置多個(gè)RC中Pod副本數(shù)量。

kubectl scale --replicas=5 rc/foo rc/bar rc/baz

選項(xiàng)

（4）kubectl autoscale

5. Cluster Manager Commands 集群管理命令

（1）kubectl cetificate

修改證書資源對(duì)象

（2）kubectl cluster-info

查看集群信息

（3）kubectl top

顯示資源 cpu 內(nèi)存 存儲(chǔ)使用情況

（4）kubectl cordon

標(biāo)記節(jié)點(diǎn)為不可調(diào)度

（5）kubectl uncordon

指定節(jié)點(diǎn)為可調(diào)度

（6）kubectl drain

安全的驅(qū)逐節(jié)點(diǎn)的所有pod

（7）kubectl taint（污點(diǎn)和容忍）

Taint（污點(diǎn)）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是優(yōu)化 pod 在集群間的調(diào)度，這跟節(jié)點(diǎn)親和性類似，只不過它們作用的方式相反，具有 taint 的 node 和 pod 是互斥關(guān)系，而具有節(jié)點(diǎn)親和性關(guān)系的 node 和 pod 是相吸的。另外還有可以給 node 節(jié)點(diǎn)設(shè)置 label，通過給 pod 設(shè)置 nodeSelector 將 pod 調(diào)度到具有匹配標(biāo)簽的節(jié)點(diǎn)上。

Taint 和 toleration 相互配合，可以用來(lái)避免 pod 被分配到不合適的節(jié)點(diǎn)上。每個(gè)節(jié)點(diǎn)上都可以應(yīng)用一個(gè)或多個(gè) taint ，這表示對(duì)于那些不能容忍這些 taint 的 pod，是不會(huì)被該節(jié)點(diǎn)接受的。如果將 toleration 應(yīng)用于 pod 上，則表示這些 pod 可以（但不要求）被調(diào)度到具有相應(yīng) taint 的節(jié)點(diǎn)上。

以下分別以為 node 設(shè)置 taint 和為 pod 設(shè)置 toleration 為例。

為 node 設(shè)置 taint

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:NoSchedule

刪除上面的 taint：

kubectl taint nodes node1 key1:NoSchedule-
kubectl taint nodes node1 key1:NoExecute-
kubectl taint nodes node1 key2:NoSchedule-

查看 node1 上的 taint：

kubectl describe nodes node1

為 pod 設(shè)置 toleration
只要在 pod 的 spec 中設(shè)置 tolerations 字段即可，可以有多個(gè) key，如下所示：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
- key: "node.alpha.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

value 的值可以為 NoSchedule、PreferNoSchedule 或 NoExecute。
tolerationSeconds 是當(dāng) pod 需要被驅(qū)逐時(shí)，可以繼續(xù)在 node 上運(yùn)行的時(shí)間。

詳細(xì)使用方法請(qǐng)參考官方文檔。

6. Troubleshooting adn Debugging Commands 故障排查和調(diào)試命令

（1）kubectl describe

輸出指定的一個(gè)/多個(gè)資源的詳細(xì)信息。

此命令組合調(diào)用多條API，輸出指定的一個(gè)或者一組資源的詳細(xì)描述。

$ kubectl describe TYPE NAME_PREFIX

首先檢查是否有精確匹配TYPE和NAME_PREFIX的資源，如果沒有，將會(huì)輸出所有名稱以NAME_PREFIX開頭的資源詳細(xì)信息。

支持的資源包括但不限于（大小寫不限）：pods (po)、services (svc)、 replicationcontrollers (rc)、nodes (no)、events (ev)、componentstatuses (cs)、 limitranges (limits)、persistentvolumes (pv)、persistentvolumeclaims (pvc)、 resourcequotas (quota)和secrets。

語(yǔ)法

kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)

示例
# 描述一個(gè)node

$ kubectl describe nodes kubernetes-minion-emt8.c.myproject.internal

# 描述一個(gè)pod

$ kubectl describe pods/nginx

# 描述pod.json中的資源類型和名稱指定的pod

$ kubectl describe -f pod.json

# 描述所有的pod

$ kubectl describe pods

# 描述所有包含label name=myLabel的pod

$ kubectl describe po -l name=myLabel

# 描述所有被replication controller “frontend”管理的pod（rc創(chuàng)建的pod都以rc的名字作為前綴）

$ kubectl describe pods frontend

選項(xiàng)
-f, --filename=[]: 用來(lái)指定待描述資源的文件名，目錄名或者URL。
-l, --selector="": 用于過濾資源的Label。

繼承自父命令的選項(xiàng)

      --alsologtostderr[=false]: 同時(shí)輸出日志到標(biāo)準(zhǔn)錯(cuò)誤控制臺(tái)和文件。
      --api-version="": 和服務(wù)端交互使用的API版本。
      --certificate-authority="": 用以進(jìn)行認(rèn)證授權(quán)的.cert文件路徑。
      --client-certificate="": TLS使用的客戶端證書路徑。
      --client-key="": TLS使用的客戶端密鑰路徑。
      --cluster="": 指定使用的kubeconfig配置文件中的集群名。
      --context="": 指定使用的kubeconfig配置文件中的環(huán)境名。
      --insecure-skip-tls-verify[=false]: 如果為true，將不會(huì)檢查服務(wù)器憑證的有效性，這會(huì)導(dǎo)致你的HTTPS鏈接變得不安全。
      --kubeconfig="": 命令行請(qǐng)求使用的配置文件路徑。
      --log-backtrace-at=:0: 當(dāng)日志長(zhǎng)度超過定義的行數(shù)時(shí)，忽略堆棧信息。
      --log-dir="": 如果不為空，將日志文件寫入此目錄。
      --log-flush-frequency=5s: 刷新日志的最大時(shí)間間隔。
      --logtostderr[=true]: 輸出日志到標(biāo)準(zhǔn)錯(cuò)誤控制臺(tái)，不輸出到文件。
      --match-server-version[=false]: 要求服務(wù)端和客戶端版本匹配。
      --namespace="": 如果不為空，命令將使用此namespace。
      --password="": API Server進(jìn)行簡(jiǎn)單認(rèn)證使用的密碼。
  -s, --server="": Kubernetes API Server的地址和端口號(hào)。
      --stderrthreshold=2: 高于此級(jí)別的日志將被輸出到錯(cuò)誤控制臺(tái)。
      --token="": 認(rèn)證到API Server使用的令牌。
      --user="": 指定使用的kubeconfig配置文件中的用戶名。
      --username="": API Server進(jìn)行簡(jiǎn)單認(rèn)證使用的用戶名。
      --v=0: 指定輸出日志的級(jí)別。
      --vmodule=: 指定輸出日志的模塊，格式如下：pattern=N，使用逗號(hào)分隔。

（2）kubectl logs

輸出pod中一個(gè)容器的日志。如果pod只包含一個(gè)容器則可以省略容器名。

語(yǔ)法格式

kubectl logs [-f] [-p] POD [-c CONTAINER]

選項(xiàng)

  -c, --container="": 容器名。
  -f, --follow[=false]: 指定是否持續(xù)輸出日志。
  --interactive[=true]: 如果為true，當(dāng)需要時(shí)提示用戶進(jìn)行輸入。默認(rèn)為true。
  --limit-bytes=0: 輸出日志的最大字節(jié)數(shù)。默認(rèn)無(wú)限制。
  -p, --previous[=false]: 如果為true，輸出pod中曾經(jīng)運(yùn)行過，但目前已終止的容器的日志。
  --since=0: 僅返回相對(duì)時(shí)間范圍，如5s、2m或3h，之內(nèi)的日志。默認(rèn)返回所有日志。只能同時(shí)使用since和since-time中的一種。
  --since-time="": 僅返回指定時(shí)間（RFC3339格式）之后的日志。默認(rèn)返回所有日志。只能同時(shí)使用since和since-time中的一種。
  --tail=-1: 要顯示的最新的日志條數(shù)。默認(rèn)為-1，顯示所有的日志。
  --timestamps[=false]: 在日志中包含時(shí)間戳。

示例

# 返回僅包含一個(gè)容器的pod nginx的日志快照
$ kubectl logs nginx

# 返回pod ruby中已經(jīng)停止的容器web-1的日志快照
$ kubectl logs -p -c ruby web-1

# 持續(xù)輸出pod ruby中的容器web-1的日志
$ kubectl logs -f -c ruby web-1

# 僅輸出pod nginx中最近的20條日志
$ kubectl logs --tail=20 nginx

# 輸出pod nginx中最近一小時(shí)內(nèi)產(chǎn)生的所有日志
$ kubectl logs --since=1h nginx

（3）kubectl attach

（4）kubectl exec

在容器內(nèi)部執(zhí)行命令。

語(yǔ)法格式

kubectl exec POD [-c CONTAINER] -- COMMAND [args...]

選項(xiàng)

  -c, --container="": 容器名。如果未指定，使用pod中的一個(gè)容器。
  -p, --pod="": Pod名。
  -i, --stdin[=false]: 將控制臺(tái)輸入發(fā)送到容器。
  -t, --tty[=false]: 將標(biāo)準(zhǔn)輸入控制臺(tái)作為容器的控制臺(tái)輸入。

舉例

# 默認(rèn)在pod 123456-7890的第一個(gè)容器中運(yùn)行“date”并獲取輸出
$ kubectl exec 123456-7890 date

# 在pod 123456-7890的容器ruby-container中運(yùn)行“date”并獲取輸出
$ kubectl exec 123456-7890 -c ruby-container date

# 切換到終端模式，將控制臺(tái)輸入發(fā)送到pod 123456-7890的ruby-container的“bash”命令，并將其輸出到控制臺(tái)/
# 錯(cuò)誤控制臺(tái)的信息發(fā)送回客戶端。
$ kubectl exec 123456-7890 -c ruby-container -i -t -- bash -il

（5）kubectl port-forward

（6）kubectl proxy

（7）kubectl cp

（7）kubectl auth

7. Advanced Commands 高級(jí)命令

（1）kubectl diff

（2）kubectl apply

語(yǔ)法：

kubectl apply -f FILENAME

選項(xiàng)

  -f, --filename=[]: 包含配置信息的文件名，目錄名或者URL。
  -o, --output="": 輸出格式，使用“-o name”來(lái)輸出簡(jiǎn)短格式（資源類型/資源名）。
      --schema-cache-dir="/tmp/kubectl.schema": 如果不為空，將API schema緩存為指定文件，默認(rèn)緩存到“/tmp/kubectl.schema”。
      --validate[=true]: 如果為true，在發(fā)送到服務(wù)端前先使用schema來(lái)驗(yàn)證輸入。

繼承自父命令的選項(xiàng)

      --alsologtostderr[=false]: 同時(shí)輸出日志到標(biāo)準(zhǔn)錯(cuò)誤控制臺(tái)和文件。
      --api-version="": 和服務(wù)端交互使用的API版本。
      --certificate-authority="": 用以進(jìn)行認(rèn)證授權(quán)的.cert文件路徑。
      --client-certificate="": TLS使用的客戶端證書路徑。
      --client-key="": TLS使用的客戶端密鑰路徑。
      --cluster="": 指定使用的kubeconfig配置文件中的集群名。
      --context="": 指定使用的kubeconfig配置文件中的環(huán)境名。
      --insecure-skip-tls-verify[=false]: 如果為true，將不會(huì)檢查服務(wù)器憑證的有效性，這會(huì)導(dǎo)致你的HTTPS鏈接變得不安全。
      --kubeconfig="": 命令行請(qǐng)求使用的配置文件路徑。
      --log-backtrace-at=:0: 當(dāng)日志長(zhǎng)度超過定義的行數(shù)時(shí)，忽略堆棧信息。
      --log-dir="": 如果不為空，將日志文件寫入此目錄。
      --log-flush-frequency=5s: 刷新日志的最大時(shí)間間隔。
      --logtostderr[=true]: 輸出日志到標(biāo)準(zhǔn)錯(cuò)誤控制臺(tái)，不輸出到文件。
      --match-server-version[=false]: 要求服務(wù)端和客戶端版本匹配。
      --namespace="": 如果不為空，命令將使用此namespace。
      --password="": API Server進(jìn)行簡(jiǎn)單認(rèn)證使用的密碼。
  -s, --server="": Kubernetes API Server的地址和端口號(hào)。
      --stderrthreshold=2: 高于此級(jí)別的日志將被輸出到錯(cuò)誤控制臺(tái)。
      --token="": 認(rèn)證到API Server使用的令牌。
      --user="": 指定使用的kubeconfig配置文件中的用戶名。
      --username="": API Server進(jìn)行簡(jiǎn)單認(rèn)證使用的用戶名。
      --v=0: 指定輸出日志的級(jí)別。
      --vmodule=: 指定輸出日志的模塊，格式如下：pattern=N，使用逗號(hào)分隔。

使用kubectl create 和 kubectl apply創(chuàng)建資源對(duì)象的區(qū)別

（3）kubectl patch

（4）kubectl replace

（5）kubectl wait

（6）kubectl convert

（7）kubectl kustomize

8. Settings Commands 設(shè)置命令

（1）kubectl label

更新（增加、修改或刪除）資源上的 label（標(biāo)簽）。
label 必須以字母或數(shù)字開頭，可以使用字母、數(shù)字、連字符、點(diǎn)和下劃線，最長(zhǎng)63個(gè)字符。
如果--overwrite 為 true，則可以覆蓋已有的 label，否則嘗試覆蓋 label 將會(huì)報(bào)錯(cuò)。
如果指定了--resource-version，則更新將使用此資源版本，否則將使用現(xiàn)有的資源版本。

語(yǔ)法

$ label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

示例
給名為foo的Pod添加label unhealthy=true。

kubectl label pods foo unhealthy=true

給名為foo的Pod修改label 為 'status' / value 'unhealthy'，且覆蓋現(xiàn)有的value。

kubectl label --overwrite pods foo status=unhealthy

給 namespace 中的所有 pod 添加 label

kubectl label pods --all status=unhealthy

僅當(dāng)resource-version=1時(shí)才更新 名為foo的Pod上的label。

kubectl label pods foo status=unhealthy --resource-version=1

刪除名為“bar”的label 。（使用“ - ”減號(hào)相連）

kubectl label pods foo bar-

（2）kubectl annotate

更新一個(gè)或多個(gè)資源的Annotations信息。

• Annotations由key/value組成。
• Annotations的目的是存儲(chǔ)輔助數(shù)據(jù)，特別是通過工具和系統(tǒng)擴(kuò)展操作的數(shù)據(jù)，更多介紹在這里。
• 如果--overwrite為true，現(xiàn)有的annotations可以被覆蓋，否則試圖覆蓋annotations將會(huì)報(bào)錯(cuò)。
• 如果設(shè)置了--resource-version，則更新將使用此resource version，否則將使用原有的resource version。

有效資源類型包括：
all
certificatesigningrequests (aka 'csr')
clusterrolebindings
clusterroles
clusters (valid only for federation apiservers)
componentstatuses (aka 'cs')
configmaps (aka 'cm')
controllerrevisions
cronjobs
daemonsets (aka 'ds')
deployments (aka 'deploy')
endpoints (aka 'ep')
events (aka 'ev')
horizontalpodautoscalers (aka 'hpa')
ingresses (aka 'ing')
jobs
limitranges (aka 'limits')
namespaces (aka 'ns')
networkpolicies (aka 'netpol')
nodes (aka 'no')
persistentvolumeclaims (aka 'pvc')
persistentvolumes (aka 'pv')
poddisruptionbudgets (aka 'pdb')
podpreset
pods (aka 'po')
podsecuritypolicies (aka 'psp')
podtemplates
replicasets (aka 'rs')
replicationcontrollers (aka 'rc')
resourcequotas (aka 'quota')
rolebindings
roles
secrets
serviceaccounts (aka 'sa')
services (aka 'svc')
statefulsets
storageclasses
thirdpartyresources

語(yǔ)法

$ annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

示例
更新Pod“foo”，設(shè)置annotation “description”的value “my frontend”，如果同一個(gè)annotation多次設(shè)置，則只使用最后設(shè)置的value值。

kubectl annotate pods foo description='my frontend'

根據(jù)“pod.json”中的type和name更新pod的annotation

kubectl annotate -f pod.json description='my frontend'

更新Pod"foo"，設(shè)置annotation“description”的value“my frontend running nginx”，覆蓋現(xiàn)有的值。

kubectl annotate --overwrite pods foo description='my frontend running nginx'

更新 namespace中的所有pod

kubectl annotate pods --all description='my frontend running nginx'

只有當(dāng)resource-version為1時(shí)，才更新pod ' foo '。

kubectl annotate pods foo description='my frontend running nginx' --resource-version=1

通過刪除名為“description”的annotations來(lái)更新pod ' foo '。#不需要- overwrite flag。

kubectl annotate pods foo description-

（3）kubectl completion

9. Other Commands 其他命令

（1）kubectl config

（2）kubectl plugin

（3）kubectl version

（4）kubectl api-versions

（5）kubectl api-resources

本次分析的版本為1.17.4，使用Calico作為網(wǎng)絡(luò)組件，總共有67種不同的api-resources。

1.  Binding: 已棄用。用于記錄一個(gè)object和另一個(gè)object的綁定關(guān)系。實(shí)際上主要用于將pod和node關(guān)系，所以在1.7版本后已經(jīng)改為在pods.bindings中記錄了。
2.  ComponentStatus: 是一個(gè)全局的list（即不受命名空間影響），記錄了k8s中所有的組件的的相關(guān)信息，比如創(chuàng)建時(shí)間，現(xiàn)在狀態(tài)等。
3.  Configmap: 是一種用于記錄pod本身或其內(nèi)部配置信息的API資源，可以認(rèn)為是通過API形式存儲(chǔ)的配置文件。
4.  Endpoints: 用于記錄每個(gè)service的pod的**真實(shí)物理**ip和port的對(duì)應(yīng)關(guān)系，包括service是TCP還是UDP等。
5.  Event: 用于記錄集群中的事件，可以認(rèn)為類似于日志里的一條記錄。
6.  LimitRange: 用于記錄各個(gè)命名空間中的pod或container對(duì)每種資源的使用限制，一般被包含在pod的定義中。
7.  Namespace: 是一個(gè)全局的list，保存集群中所有的命名空間。
8.  Node: 是一個(gè)全局的list，詳細(xì)記錄了每個(gè)節(jié)點(diǎn)的name, labels, PodCIDR, host IP, hostname, 總資源（cpu，內(nèi)存），可分配資源，各心跳狀態(tài)（網(wǎng)絡(luò)，內(nèi)存，硬盤，PID數(shù)量，kubelet等），kubelet的物理port，各k8s組件image信息，node環(huán)境信息（os, CRI version, kubeProxy version, kubelet version等）。
9.  PersistentVolumeClaim: 記錄用戶對(duì)持久化存儲(chǔ)的要求。
10.  PersistentVolume: 是一個(gè)全局的object，記錄了所有的持久化存儲(chǔ)設(shè)備的信息（類似于node）
11.  Pod: 是對(duì)于使用k8s的開發(fā)者而言最重要的資源，其中包含ownerReference (Node, Demonset等），containers相關(guān)信息（image，啟動(dòng)命令，probe，資源信息，存儲(chǔ)信息，結(jié)束時(shí)行，是否接受service注入環(huán)境變量為等），網(wǎng)絡(luò)設(shè)置（dns設(shè)置，port設(shè)置等），集群調(diào)度相關(guān)信息（優(yōu)先級(jí)，tolerations，affinity，重啟規(guī)則等），pod狀態(tài)（hostIP，podIP，啟動(dòng)時(shí)間等）
12.  PodTemplate: 一般是被包含在其它資源中的一部分，比如Jobs, DaemonSets, Replication Controllers。其初始化剛被創(chuàng)建的pod的k8s相關(guān)的信息，一般是label等。
13.  Replication Controller: 是系統(tǒng)內(nèi)建的最常用的controller，用來(lái)保證Pod的實(shí)際運(yùn)行數(shù)量滿足定義。如果不足則負(fù)責(zé)創(chuàng)建，如果過多則通知一些pod terminate。
14.  ResourceQuota: 用于記錄和限制某個(gè)namespace的中的總的資源消耗，一般用于多用戶下利用namespace對(duì)資源進(jìn)行限制。
15.  Secrets: 實(shí)際上將文件內(nèi)容通過base64編碼后存在etcd中。在Pod中container啟動(dòng)時(shí)可以將secretes作為文件掛載在某一路徑下，如此避免重要信息存儲(chǔ)在image中。
16.  ServiceAccout: 用于授權(quán)集群內(nèi)的pod訪問apiServer。
17.  Service: 非常重要且常見的資源，用于對(duì)外提供統(tǒng)一的Service IP和port，將流量負(fù)載均衡調(diào)整至集群中多個(gè)pod。重要的配置有：cluster IP，port，selector（選擇轉(zhuǎn)發(fā)流量的目的pod），sessionAffinity等。這里提供的負(fù)載均衡是L3 TCP的。
18.  MutatingWebhookConfiguration: 不明（內(nèi)部object）
19.  ValidatingWebhookConfiguration: 不明（內(nèi)部object）
20.  CustomerResourceDefinitions: 自定義資源也是非常重要的一種資源，是各種k8s插件能夠存在的基礎(chǔ)。比如當(dāng)要實(shí)現(xiàn)Clico之類的自定義插件時(shí)，首先需要考慮的就是apiServer如何能夠處理相關(guān)的請(qǐng)求信息。自定義資源的定義便是apiServer處理資源的依據(jù)。這個(gè)話題比較復(fù)雜，在這里不詳細(xì)討論。
21.  APIService: 定義API服務(wù)的資源。一個(gè)API請(qǐng)求有兩種形式，`/apis/GROUP/VERSION/*`這種不被包含在namespace中的（即全局的）和`/apis/GROUP/VERSION/namespaces/NAMESPACE/*`這種被包含在namespace中的。當(dāng)一個(gè)請(qǐng)求到達(dá)apiServer后，必然需要有相應(yīng)的代碼去處理它。每一對(duì)GROUP和VERSION確定一種API，響應(yīng)每一種API請(qǐng)求的代碼被抽象為一種服務(wù)（service）。想象一下自定義資源的相關(guān)API請(qǐng)求到達(dá)apiServer后如何被處理呢？相關(guān)的service也是自定義的并且運(yùn)行在master中，k8s正是根據(jù)APIService來(lái)正確地將請(qǐng)求與正確的service關(guān)聯(lián)。在這里可以定義service名稱，安全設(shè)置，優(yōu)先級(jí)等。
22.  ControllerRevision: 是一個(gè)beta功能，用于Controller保存自己的歷史狀態(tài)便于更新和回滾。
23.  Daemenset: 常見的Pod set種類，用于控制每種pod狀態(tài)（數(shù)量，計(jì)算資源使用，probe等）在定義的范圍內(nèi)，且在每node上最多有一個(gè)。
24.  Replicaset: 常見的Pod set種類但現(xiàn)在基本上不直接使用，用于控制每種pod的狀態(tài)（數(shù)量，計(jì)算資源使用，probe等）在定義的范圍內(nèi)。一個(gè)Replicasets中的各個(gè)pod都應(yīng)是等同的、可互換的，即對(duì)外表現(xiàn)完全相同。就好比所有的氫原子（1質(zhì)子0中子）都是不可區(qū)分的。
25.  Deployment: 最常見的Pod set種類，可以擁有Replicasets和Pod。用于控制擁有的資源的狀態(tài)（數(shù)量，計(jì)算資源使用，probe等）在定義的范圍內(nèi)。
26.  StatefulSet: 常見的Pod set種類。和Deployment的區(qū)別之處是它控制的pod不是可互換的而是在整個(gè)生命周期有不變的標(biāo)簽。這樣，每個(gè)pod可以有自己的DNS名，存儲(chǔ)等。即使pod被刪除后這些信息也會(huì)被恢復(fù)。
27.  TokenReview: 不明，似乎和apiServer的Webhook的token授權(quán)相關(guān)。
28.  LocalSubjectAccessReview: 不明（內(nèi)部object），和一個(gè)命名空間對(duì)用戶/組的授權(quán)檢查相關(guān)。
29.  SelfSubjectAccessReview: 不明（內(nèi)部object），和當(dāng)前用戶檢查自己是否有權(quán)限對(duì)一個(gè)命名空間進(jìn)行操作相關(guān)。
30.  SelfSubjectRulesReivew: 不明（內(nèi)部object），含有當(dāng)前用戶在一個(gè)命名空間內(nèi)能進(jìn)行的操作的列表。和apiServer的授權(quán)安全模式相關(guān)
31.  SubjectAccessReviews: 不明（內(nèi)部object），和用戶/組的授權(quán)檢查相關(guān)，并不限定于某個(gè)命名空間。
32.  HorizontalPodAutoScaler: 控制Pod set（比如Deployment）的pod數(shù)量的資源。可以根據(jù)pod的CPU、內(nèi)存、自定義數(shù)據(jù)動(dòng)態(tài)調(diào)節(jié)pod數(shù)量。在[這里](https://link.zhihu.com/?target=https%3A//kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)可以找到相關(guān)的例子。
33.  CronJob: 定時(shí)運(yùn)行Job pod的資源。
34.  Job: 常見的Pod set種類，會(huì)創(chuàng)建一定數(shù)量的pod，僅當(dāng)特定數(shù)量的pod成功結(jié)束后這個(gè)Job才算成功結(jié)束。創(chuàng)建的pod在結(jié)束后不會(huì)被重啟。
35.  CertificateSigningRequests: 可以認(rèn)為是一個(gè)接口，便于Pod等資源申請(qǐng)獲得一個(gè)X.509證書。這個(gè)證書應(yīng)該被controller approve或者被手動(dòng)approve，之后被合適的對(duì)象簽名。具體可以參考這里。
36.  Lease: 是一個(gè)在1.13版本中加入的資源類型，用于Node向master通知自己的心跳信息。之前的版本中kebulet是通過更新NodeStatus通知master心跳，后來(lái)發(fā)現(xiàn)NodeStatus太大了而心跳信息更新頻繁，導(dǎo)致master壓力較大，于是增加了Lease這種資源。
37.  EndpointSlice: 是含有一個(gè)service的Endpoint的部分信息的資源。原因和Lease類似，對(duì)于含有較多信息的service（比如有很多pod分布在多個(gè)node上）一個(gè)endpoint object可能會(huì)比較大而且被頻繁訪問，所以這種情況下會(huì)有多個(gè)endpointSlice被創(chuàng)建減輕master的壓力。
38.  Event: 描述一個(gè)集群內(nèi)的事件的資源，含有message，event，reason，報(bào)告來(lái)源等詳細(xì)的信息。
39.  Ingresse (APIGroup=extensions): 將被deprecated。
40.  Ingresse (APIGroup=[http://networking.k8s.io](https://link.zhihu.com/?target=http%3A//networking.k8s.io)): 可以簡(jiǎn)單理解為是定義loadbalancer的資源。其中含有一系列規(guī)則，定義了不同url的對(duì)應(yīng)后端，SSL termination等。為什么這個(gè)新的API會(huì)取代前面那個(gè)APIGroup=extensions的Ingress API呢？我查了很多地方?jīng)]有找到具體的文字解釋，但是可以推測(cè)是Ingress正式成為k8s的網(wǎng)絡(luò)模塊的一部分，對(duì)應(yīng)的server（代碼）從extensions遷移到[http://networking.k8s.io](https://link.zhihu.com/?target=http%3A//networking.k8s.io)。
41.  NetworkPolicy: 定義了那些網(wǎng)絡(luò)流量可以去哪些pod的資源。一個(gè)NetworkPolicy可以指定一組pods，定義只有滿足了特定條件（比如源/目的IP，port，pod名等）的網(wǎng)絡(luò)流量可以被相應(yīng)的pod收發(fā)。
42.  RuntimeClass: 這是2019年討論加入的新API資源。[文檔](https://link.zhihu.com/?target=https%3A//github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md%23summary)說明其目的是將容器運(yùn)行時(shí)（Container Runtime）環(huán)境的屬性暴露給k8s的控制層，便于在一個(gè)集群或節(jié)點(diǎn)中支持多種容器運(yùn)行時(shí)環(huán)境。這樣便于未來(lái)創(chuàng)建更具有兼容性的k8s集群。
43.  PodDisruptionBudget: 這一個(gè)API資源使用戶可以對(duì)一組pod定義“k8s可以容忍的實(shí)際running狀態(tài)的pod數(shù)量與預(yù)期的差距”?？紤]這樣一個(gè)情景：一集群中某個(gè)service后一共有5個(gè)相同pod處理其流量，要求至少有一半的pod是可用的，但其中3個(gè)pod由于調(diào)度運(yùn)行在node A上。如果出現(xiàn)node A突然故障等情況導(dǎo)致服務(wù)不可用，暫時(shí)沒有好的辦法處理這種不可避免地意外情況（或者需要讓調(diào)度算法知道這些pod應(yīng)該被盡量均勻分布在個(gè)節(jié)點(diǎn)上，但目前k8s沒有功能強(qiáng)制這種調(diào)度）。但除此之外還有很多可以避免的意外情況，比如在集群維護(hù)或者其它事件的處理過程中，集群管理員可能drain node A，導(dǎo)致三個(gè)pod同時(shí)被結(jié)束從而影響業(yè)務(wù)。針對(duì)這種可避免的意外，若一組pod的數(shù)量因?yàn)榭杀苊獾膋8s操作將會(huì)低于可容忍程度（在PodDisruptionBudget中定義），那么這個(gè)命令會(huì)被阻止并返回失敗。
44.  PodSecurityPolicy: 定義了一個(gè)pod在集群中被創(chuàng)建/運(yùn)行/更新時(shí)需要滿足的條件。
45.  ClusterRole: 定義了集群中policy rule的一些常見集合，比如`system-node`等，用于控制賬戶權(quán)限。
46.  ClusterRoleBinding: 定義了某個(gè)賬戶/組對(duì)ClusterRole的引用，用于賦權(quán)。
47.  Roles: 和前面ClusterRole類似，但是顧名思義ClusterRole是和集群賬戶相關(guān)，Role則被用于其它的賬戶（比如controller使用的service account）
48.  RoleBindings: 定義了某個(gè)賬戶/組對(duì)Role的引用，用于賦權(quán)。
49.  PriorityClass: 定義了pod優(yōu)先級(jí)名稱和對(duì)應(yīng)值的映射。比如`system-cluster-critical`對(duì)應(yīng)的優(yōu)先級(jí)為2000000000。值越大代表優(yōu)先級(jí)越高，那么當(dāng)集群資源不足等情況發(fā)生必須終止一些pod時(shí)，優(yōu)先級(jí)小的pod會(huì)先被終止。為什么不直接用數(shù)值代表優(yōu)先級(jí)呢？因?yàn)檫@樣子很容易出現(xiàn)確定隨意性。比如開發(fā)人員A開發(fā)了一個(gè)非常重要的pod，于是在代碼中將其優(yōu)先級(jí)的值設(shè)置為9999。但是集群集群管理員B可能認(rèn)為9999是一個(gè)小數(shù)字，他創(chuàng)建的隨便一個(gè)pod的優(yōu)先級(jí)都是999999+。于是需要PriorityClass來(lái)進(jìn)行優(yōu)先級(jí)的統(tǒng)一管理和比較。
50.  CSIDriver: 定義了集群中容器存儲(chǔ)驅(qū)動(dòng)的API資源。[CSI](https://link.zhihu.com/?target=https%3A//kubernetes-csi.github.io/docs/introduction.html)代表的是Container Storage Interface，即容器存儲(chǔ)接口。k8s應(yīng)該可以利用各種各樣的存儲(chǔ)服務(wù)，各家云廠商的活開源的。k8s如何知道怎么去用這些存儲(chǔ)服務(wù)呢？那么就是通過這個(gè)CSIDriver資源找到相應(yīng)的驅(qū)動(dòng)。
51.  CSINode: 前面CSIDriver產(chǎn)生的節(jié)點(diǎn)相關(guān)的信息便存在CSINode中。
52.  StorageClass: 定義了可以存在的存儲(chǔ)類型的API資源。
53.  Volumeattachments: 定義了對(duì)一個(gè)node分配/回收存儲(chǔ)空間的請(qǐng)求的API資源。
54.  NetworkSets: 接下來(lái)的都是Calico自定義API資源，就不一一分析了，都與網(wǎng)絡(luò)協(xié)議/安全/管理相關(guān)。
55.  NetworkPolicies: Calico自定義API資源
56.  IPPools: Calico自定義API資源
57.  IPAMHandles: Calico自定義API資源
58.  IPAMConfigs: Calico自定義API資源
59.  IPAMBlocks: Calico自定義API資源
60.  HostEndpoints: Calico自定義API資源
61.  GlobalNetworkSets: Calico自定義API資源
62.  GlobalNetworkPolicies: Calico自定義API資源
63.  FelixConfiguration: Calico自定義API資源
64.  ClusterInformation: Calico自定義API資源
65.  BlockAffinity: Calico自定義API資源
66.  BGPPeer: Calico自定義API資源
67.  BGPConfiguration: Calico自定義API資源

kubernetes 中yaml文件數(shù)據(jù)定義介紹

apiVersion： api版本
kind: 資源類型
metadata: #元數(shù)據(jù)
  name: 名字
  namespace:所在命名空間
  labels: 標(biāo)簽信息（可以多個(gè)）
    ##標(biāo)簽是key：value格式的key，value最長(zhǎng)只能使用63個(gè)字符
    # key只能是以數(shù)字、之母、_、-、點(diǎn)（.）這五類的組合，
     #value可以為空，但只能以數(shù)字及字母開頭或結(jié)尾
    app: 標(biāo)簽內(nèi)容
  annotations: #注釋（不具備什么功能 就是注釋 ）
    zhushi： ”lalalalalalalal saddas”
spec:期望狀態(tài)
  containers:容器信息（可以多個(gè)名稱云鏡像）
  - name: 自定義name名稱
    image：鏡像名
  - name： 
    image：
  nodeSelector:#節(jié)點(diǎn)選擇器（如給指定運(yùn)行在disk為ssd的node上）
    disk: ssd
  imagePullPolicy:#是否使用本地或遠(yuǎn)端的下載鏡像
    #1、Always
    #2、Never
    #3、IfNotPresent
  livenessProbe：#存活性探針
　　　　#1、exec #命令
　　　　#2、httpGet #http請(qǐng)求 指定ip:port
　　　　#3、tcpSocket  #
   readinessProbe：#就緒狀態(tài)探針
 　　　　#1、exec #命令
 　　　　#2、httpGet #http請(qǐng)求 指定ip:port
　　　　#3、tcpSocket  #

（6）kubectl options

參考

（1）英文官方 -
https://kubernetes.io/docs/reference/kubectl/overview/

（2）中文文檔 -
http://docs.kubernetes.org.cn/683.html

（3）Kubectl常用命令詳解
https://blog.csdn.net/weixin_44631350/article/details/89450781