第3课 Kubectl常用命令详解

kubectl create  通过yaml/json 文件或者标准输入创建一个资源对象，支持很多子命令 例如namespace pod deployment service等
kubectl expose  将json/yaml文件中定义的资源对象的端口暴露给新的service资源对象
kubectl run 创建并运行一个或多个容器镜像
kubectl set 配置资源对象设置特定功能

kubectl explain 查看资源对象的详细信息(一般用一编写yaml的时候做一个提示 kubectl explain deployment 会出现deployment下面可以写的字段以及字段属性还有 可以逐级使用)
kubectl get 获取一个或多个资源对象的信息
kubectl edit    使用默认编辑器编辑服务器上定义的资源对象
kubectl delete  通过json/yaml文件、标准舒服、资源名称或标签选择器来删除资源

kubectl rollout 资源管理对象的部署
kubectl rollout-update  使用rc（replication controller）来做滚动恩星
kubectl scale   扩容或者缩容deployment replicaset replication contrller等
kubectl autoscale   自动设置在k8s系统中运行的pod数量（水平自动伸缩）

kubectl cetificate  修改证书资源对象
kubectl cluster-info    查看集群信息
kubectl top 显示资源 cpu 内存 存储使用情况
kubectl cordon  标记节点为不可调度
kubectl uncordon    指定节点为可调度
kubectl drain   安全的驱逐节点的所有pod
kubectl taint   将一个或多个节点设置为污点

kubectl describe    显示一个或多个资源对象的详细信息
kubectl logs    输出pod资源对象中一个容器的日志
kubectl attach  连接到一个运行的容器
kubectl exec    在指定容器内执行命令
kubectl port-forward    将本机指定端口映射到pod资源对象的端口
kubectl proxy   将本机指定端口映射到kube-apiserver
kubectl cp  用于pod与主机交换文件
kubectl auth    检查验证

kubectl diff    对比本地json/yaml文件与kube-apiserver中运行的配置文件是否有差异
kubectl apply   通过json/yaml文件 标准输入对资源进行配置更新或者创建
kubectl patch   通过patch方式修改资源对象字段（补丁式）
kubectl replace 通过json/yaml文件或者标准输入来替换资源对象
kubectl wait    在一个或者多个资源上等待条件达成
kubectl convert 转换json/yaml文件为不同的资源版本
kubectl kustomize   定制kubernetes配置

kubectl label   增删改资源的标签
kubectl annotate    更新一个或者多个资源对象的注释（annotaion）信息
kubectl completion  命令自动补全

kubectl config  管理kubeconfig配置文件
kubectl plugin  运行命令行插件功能
kubectl version 查看客户端服务端的系统版本信息
kubectl api-versions    列出当前kubernetes系统支持的资源组和资源版本表现形式为/
kubectl api-resources   列出当前kubernetes系统支持的resource资源列表
kubectl options 查看支持的参数列表

$ create -f FILENAME

kubectl create -f ./pod.json

cat pod.json | kubectl create -f -

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

$ 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]

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

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

$ set SUBCOMMAND

kubectl get 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)

 -o wide/yaml/json

-l key=value

# 查看Master状态
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
 
# 根据pod文件查找pod，并以json格式输出
kubectl get -f pod.yaml -o json
 
# 获取pod容器的状态
kubectl get -o template pod/kube-dns-795f5f6f9c-ldxxs --template {{.status.phase}}
 
# 同时获取所有的rc和service
kubectl get rc,services
 
# 获取符合条件的所有rc,svc,pod
kubectl get rc/web service/frontend pods/web-pod-13je7
 
# 获取所有resource
kubectl get all

$ edit (RESOURCE/NAME | -f FILENAME)

kubectl edit svc/docker-registry

KUBE_EDITOR="nano" kubectl edit svc/docker-registry

kubectl edit job.v1.batch/myjob -o json

kubectl edit deployment/mydeployment -o yaml --save-config

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

kubectl delete -f ./pod.json

cat pod.json | kubectl delete -f -

kubectl delete pod,service baz foo

kubectl delete pods,services -l name=myLabel

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

kubectl delete pods --all

$ rollout SUBCOMMAND

kubectl rollout undo deployment/abc

kubectl rollout status daemonset/foo

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

kubectl rollout history deployment/abc

kubectl rollout history daemonset/abc --revision=3

$ pause RESOURCE

kubectl rollout pause deployment/nginx

$ resume RESOURCE

kubectl rollout resume deployment/nginx

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

kubectl rollout status deployment/nginx

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

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

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

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

kubectl scale --replicas=3 rs/foo

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

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

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

修改证书资源对象

标记节点为不可调度

指定节点为可调度

安全的驱逐节点的所有pod

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

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

kubectl describe nodes node1

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

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

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

$ kubectl describe pods/nginx

$ kubectl describe -f pod.json

$ kubectl describe pods

$ kubectl describe po -l name=myLabel

$ kubectl describe pods frontend

      --alsologtostderr[=false]: 同时输出日志到标准错误控制台和文件。
      --api-version="": 和服务端交互使用的API版本。
      --certificate-authority="": 用以进行认证授权的.cert文件路径。
      --client-certificate="": TLS使用的客户端证书路径。
      --client-key="": TLS使用的客户端密钥路径。
      --cluster="": 指定使用的kubeconfig配置文件中的集群名。
      --context="": 指定使用的kubeconfig配置文件中的环境名。
      --insecure-skip-tls-verify[=false]: 如果为true，将不会检查服务器凭证的有效性，这会导致你的HTTPS链接变得不安全。
      --kubeconfig="": 命令行请求使用的配置文件路径。
      --log-backtrace-at=:0: 当日志长度超过定义的行数时，忽略堆栈信息。
      --log-dir="": 如果不为空，将日志文件写入此目录。
      --log-flush-frequency=5s: 刷新日志的最大时间间隔。
      --logtostderr[=true]: 输出日志到标准错误控制台，不输出到文件。
      --match-server-version[=false]: 要求服务端和客户端版本匹配。
      --namespace="": 如果不为空，命令将使用此namespace。
      --password="": API Server进行简单认证使用的密码。
  -s, --server="": Kubernetes API Server的地址和端口号。
      --stderrthreshold=2: 高于此级别的日志将被输出到错误控制台。
      --token="": 认证到API Server使用的令牌。
      --user="": 指定使用的kubeconfig配置文件中的用户名。
      --username="": API Server进行简单认证使用的用户名。
      --v=0: 指定输出日志的级别。
      --vmodule=: 指定输出日志的模块，格式如下：pattern=N，使用逗号分隔。

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

  -c, --container="": 容器名。
  -f, --follow[=false]: 指定是否持续输出日志。
  --interactive[=true]: 如果为true，当需要时提示用户进行输入。默认为true。
  --limit-bytes=0: 输出日志的最大字节数。默认无限制。
  -p, --previous[=false]: 如果为true，输出pod中曾经运行过，但目前已终止的容器的日志。
  --since=0: 仅返回相对时间范围，如5s、2m或3h，之内的日志。默认返回所有日志。只能同时使用since和since-time中的一种。
  --since-time="": 仅返回指定时间（RFC3339格式）之后的日志。默认返回所有日志。只能同时使用since和since-time中的一种。
  --tail=-1: 要显示的最新的日志条数。默认为-1，显示所有的日志。
  --timestamps[=false]: 在日志中包含时间戳。

# 返回仅包含一个容器的pod nginx的日志快照
$ kubectl logs nginx

# 返回pod ruby中已经停止的容器web-1的日志快照
$ kubectl logs -p -c ruby web-1

# 持续输出pod ruby中的容器web-1的日志
$ kubectl logs -f -c ruby web-1

# 仅输出pod nginx中最近的20条日志
$ kubectl logs --tail=20 nginx

# 输出pod nginx中最近一小时内产生的所有日志
$ kubectl logs --since=1h nginx

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

  -c, --container="": 容器名。如果未指定，使用pod中的一个容器。
  -p, --pod="": Pod名。
  -i, --stdin[=false]: 将控制台输入发送到容器。
  -t, --tty[=false]: 将标准输入控制台作为容器的控制台输入。

# 默认在pod 123456-7890的第一个容器中运行“date”并获取输出
$ kubectl exec 123456-7890 date

# 在pod 123456-7890的容器ruby-container中运行“date”并获取输出
$ kubectl exec 123456-7890 -c ruby-container date

# 切换到终端模式，将控制台输入发送到pod 123456-7890的ruby-container的“bash”命令，并将其输出到控制台/
# 错误控制台的信息发送回客户端。
$ kubectl exec 123456-7890 -c ruby-container -i -t -- bash -il

kubectl apply -f FILENAME

  -f, --filename=[]: 包含配置信息的文件名，目录名或者URL。
  -o, --output="": 输出格式，使用“-o name”来输出简短格式（资源类型/资源名）。
      --schema-cache-dir="/tmp/kubectl.schema": 如果不为空，将API schema缓存为指定文件，默认缓存到“/tmp/kubectl.schema”。
      --validate[=true]: 如果为true，在发送到服务端前先使用schema来验证输入。

      --alsologtostderr[=false]: 同时输出日志到标准错误控制台和文件。
      --api-version="": 和服务端交互使用的API版本。
      --certificate-authority="": 用以进行认证授权的.cert文件路径。
      --client-certificate="": TLS使用的客户端证书路径。
      --client-key="": TLS使用的客户端密钥路径。
      --cluster="": 指定使用的kubeconfig配置文件中的集群名。
      --context="": 指定使用的kubeconfig配置文件中的环境名。
      --insecure-skip-tls-verify[=false]: 如果为true，将不会检查服务器凭证的有效性，这会导致你的HTTPS链接变得不安全。
      --kubeconfig="": 命令行请求使用的配置文件路径。
      --log-backtrace-at=:0: 当日志长度超过定义的行数时，忽略堆栈信息。
      --log-dir="": 如果不为空，将日志文件写入此目录。
      --log-flush-frequency=5s: 刷新日志的最大时间间隔。
      --logtostderr[=true]: 输出日志到标准错误控制台，不输出到文件。
      --match-server-version[=false]: 要求服务端和客户端版本匹配。
      --namespace="": 如果不为空，命令将使用此namespace。
      --password="": API Server进行简单认证使用的密码。
  -s, --server="": Kubernetes API Server的地址和端口号。
      --stderrthreshold=2: 高于此级别的日志将被输出到错误控制台。
      --token="": 认证到API Server使用的令牌。
      --user="": 指定使用的kubeconfig配置文件中的用户名。
      --username="": API Server进行简单认证使用的用户名。
      --v=0: 指定输出日志的级别。
      --vmodule=: 指定输出日志的模块，格式如下：pattern=N，使用逗号分隔。

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

kubectl label pods foo unhealthy=true

kubectl label --overwrite pods foo status=unhealthy

kubectl label pods --all status=unhealthy

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

kubectl label pods foo bar-

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

kubectl annotate pods foo description='my frontend'

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

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

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

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

kubectl annotate pods foo description-

本次分析的版本为1.17.4，使用Calico作为网络组件，总共有67种不同的api-resources。

1.  Binding: 已弃用。用于记录一个object和另一个object的绑定关系。实际上主要用于将pod和node关系，所以在1.7版本后已经改为在pods.bindings中记录了。
2.  ComponentStatus: 是一个全局的list（即不受命名空间影响），记录了k8s中所有的组件的的相关信息，比如创建时间，现在状态等。
3.  Configmap: 是一种用于记录pod本身或其内部配置信息的API资源，可以认为是通过API形式存储的配置文件。
4.  Endpoints: 用于记录每个service的pod的**真实物理**ip和port的对应关系，包括service是TCP还是UDP等。
5.  Event: 用于记录集群中的事件，可以认为类似于日志里的一条记录。
6.  LimitRange: 用于记录各个命名空间中的pod或container对每种资源的使用限制，一般被包含在pod的定义中。
7.  Namespace: 是一个全局的list，保存集群中所有的命名空间。
8.  Node: 是一个全局的list，详细记录了每个节点的name, labels, PodCIDR, host IP, hostname, 总资源（cpu，内存），可分配资源，各心跳状态（网络，内存，硬盘，PID数量，kubelet等），kubelet的物理port，各k8s组件image信息，node环境信息（os, CRI version, kubeProxy version, kubelet version等）。
9.  PersistentVolumeClaim: 记录用户对持久化存储的要求。
10.  PersistentVolume: 是一个全局的object，记录了所有的持久化存储设备的信息（类似于node）
11.  Pod: 是对于使用k8s的开发者而言最重要的资源，其中包含ownerReference (Node, Demonset等），containers相关信息（image，启动命令，probe，资源信息，存储信息，结束时行，是否接受service注入环境变量为等），网络设置（dns设置，port设置等），集群调度相关信息（优先级，tolerations，affinity，重启规则等），pod状态（hostIP，podIP，启动时间等）
12.  PodTemplate: 一般是被包含在其它资源中的一部分，比如Jobs, DaemonSets, Replication Controllers。其初始化刚被创建的pod的k8s相关的信息，一般是label等。
13.  Replication Controller: 是系统内建的最常用的controller，用来保证Pod的实际运行数量满足定义。如果不足则负责创建，如果过多则通知一些pod terminate。
14.  ResourceQuota: 用于记录和限制某个namespace的中的总的资源消耗，一般用于多用户下利用namespace对资源进行限制。
15.  Secrets: 实际上将文件内容通过base64编码后存在etcd中。在Pod中container启动时可以将secretes作为文件挂载在某一路径下，如此避免重要信息存储在image中。
16.  ServiceAccout: 用于授权集群内的pod访问apiServer。
17.  Service: 非常重要且常见的资源，用于对外提供统一的Service IP和port，将流量负载均衡调整至集群中多个pod。重要的配置有：cluster IP，port，selector（选择转发流量的目的pod），sessionAffinity等。这里提供的负载均衡是L3 TCP的。
18.  MutatingWebhookConfiguration: 不明（内部object）
19.  ValidatingWebhookConfiguration: 不明（内部object）
20.  CustomerResourceDefinitions: 自定义资源也是非常重要的一种资源，是各种k8s插件能够存在的基础。比如当要实现Clico之类的自定义插件时，首先需要考虑的就是apiServer如何能够处理相关的请求信息。自定义资源的定义便是apiServer处理资源的依据。这个话题比较复杂，在这里不详细讨论。
21.  APIService: 定义API服务的资源。一个API请求有两种形式，`/apis/GROUP/VERSION/*`这种不被包含在namespace中的（即全局的）和`/apis/GROUP/VERSION/namespaces/NAMESPACE/*`这种被包含在namespace中的。当一个请求到达apiServer后，必然需要有相应的代码去处理它。每一对GROUP和VERSION确定一种API，响应每一种API请求的代码被抽象为一种服务（service）。想象一下自定义资源的相关API请求到达apiServer后如何被处理呢？相关的service也是自定义的并且运行在master中，k8s正是根据APIService来正确地将请求与正确的service关联。在这里可以定义service名称，安全设置，优先级等。
22.  ControllerRevision: 是一个beta功能，用于Controller保存自己的历史状态便于更新和回滚。
23.  Daemenset: 常见的Pod set种类，用于控制每种pod状态（数量，计算资源使用，probe等）在定义的范围内，且在每node上最多有一个。
24.  Replicaset: 常见的Pod set种类但现在基本上不直接使用，用于控制每种pod的状态（数量，计算资源使用，probe等）在定义的范围内。一个Replicasets中的各个pod都应是等同的、可互换的，即对外表现完全相同。就好比所有的氢原子（1质子0中子）都是不可区分的。
25.  Deployment: 最常见的Pod set种类，可以拥有Replicasets和Pod。用于控制拥有的资源的状态（数量，计算资源使用，probe等）在定义的范围内。
26.  StatefulSet: 常见的Pod set种类。和Deployment的区别之处是它控制的pod不是可互换的而是在整个生命周期有不变的标签。这样，每个pod可以有自己的DNS名，存储等。即使pod被删除后这些信息也会被恢复。
27.  TokenReview: 不明，似乎和apiServer的Webhook的token授权相关。
28.  LocalSubjectAccessReview: 不明（内部object），和一个命名空间对用户/组的授权检查相关。
29.  SelfSubjectAccessReview: 不明（内部object），和当前用户检查自己是否有权限对一个命名空间进行操作相关。
30.  SelfSubjectRulesReivew: 不明（内部object），含有当前用户在一个命名空间内能进行的操作的列表。和apiServer的授权安全模式相关
31.  SubjectAccessReviews: 不明（内部object），和用户/组的授权检查相关，并不限定于某个命名空间。
32.  HorizontalPodAutoScaler: 控制Pod set（比如Deployment）的pod数量的资源。可以根据pod的CPU、内存、自定义数据动态调节pod数量。在[这里](https://link.zhihu.com/?target=https%3A//kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)可以找到相关的例子。
33.  CronJob: 定时运行Job pod的资源。
34.  Job: 常见的Pod set种类，会创建一定数量的pod，仅当特定数量的pod成功结束后这个Job才算成功结束。创建的pod在结束后不会被重启。
35.  CertificateSigningRequests: 可以认为是一个接口，便于Pod等资源申请获得一个X.509证书。这个证书应该被controller approve或者被手动approve，之后被合适的对象签名。具体可以参考这里。
36.  Lease: 是一个在1.13版本中加入的资源类型，用于Node向master通知自己的心跳信息。之前的版本中kebulet是通过更新NodeStatus通知master心跳，后来发现NodeStatus太大了而心跳信息更新频繁，导致master压力较大，于是增加了Lease这种资源。
37.  EndpointSlice: 是含有一个service的Endpoint的部分信息的资源。原因和Lease类似，对于含有较多信息的service（比如有很多pod分布在多个node上）一个endpoint object可能会比较大而且被频繁访问，所以这种情况下会有多个endpointSlice被创建减轻master的压力。
38.  Event: 描述一个集群内的事件的资源，含有message，event，reason，报告来源等详细的信息。
39.  Ingresse (APIGroup=extensions): 将被deprecated。
40.  Ingresse (APIGroup=[http://networking.k8s.io](https://link.zhihu.com/?target=http%3A//networking.k8s.io)): 可以简单理解为是定义loadbalancer的资源。其中含有一系列规则，定义了不同url的对应后端，SSL termination等。为什么这个新的API会取代前面那个APIGroup=extensions的Ingress API呢？我查了很多地方没有找到具体的文字解释，但是可以推测是Ingress正式成为k8s的网络模块的一部分，对应的server（代码）从extensions迁移到[http://networking.k8s.io](https://link.zhihu.com/?target=http%3A//networking.k8s.io)。
41.  NetworkPolicy: 定义了那些网络流量可以去哪些pod的资源。一个NetworkPolicy可以指定一组pods，定义只有满足了特定条件（比如源/目的IP，port，pod名等）的网络流量可以被相应的pod收发。
42.  RuntimeClass: 这是2019年讨论加入的新API资源。[文档](https://link.zhihu.com/?target=https%3A//github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md%23summary)说明其目的是将容器运行时（Container Runtime）环境的属性暴露给k8s的控制层，便于在一个集群或节点中支持多种容器运行时环境。这样便于未来创建更具有兼容性的k8s集群。
43.  PodDisruptionBudget: 这一个API资源使用户可以对一组pod定义“k8s可以容忍的实际running状态的pod数量与预期的差距”。考虑这样一个情景：一集群中某个service后一共有5个相同pod处理其流量，要求至少有一半的pod是可用的，但其中3个pod由于调度运行在node A上。如果出现node A突然故障等情况导致服务不可用，暂时没有好的办法处理这种不可避免地意外情况（或者需要让调度算法知道这些pod应该被尽量均匀分布在个节点上，但目前k8s没有功能强制这种调度）。但除此之外还有很多可以避免的意外情况，比如在集群维护或者其它事件的处理过程中，集群管理员可能drain node A，导致三个pod同时被结束从而影响业务。针对这种可避免的意外，若一组pod的数量因为可避免的k8s操作将会低于可容忍程度（在PodDisruptionBudget中定义），那么这个命令会被阻止并返回失败。
44.  PodSecurityPolicy: 定义了一个pod在集群中被创建/运行/更新时需要满足的条件。
45.  ClusterRole: 定义了集群中policy rule的一些常见集合，比如`system-node`等，用于控制账户权限。
46.  ClusterRoleBinding: 定义了某个账户/组对ClusterRole的引用，用于赋权。
47.  Roles: 和前面ClusterRole类似，但是顾名思义ClusterRole是和集群账户相关，Role则被用于其它的账户（比如controller使用的service account）
48.  RoleBindings: 定义了某个账户/组对Role的引用，用于赋权。
49.  PriorityClass: 定义了pod优先级名称和对应值的映射。比如`system-cluster-critical`对应的优先级为2000000000。值越大代表优先级越高，那么当集群资源不足等情况发生必须终止一些pod时，优先级小的pod会先被终止。为什么不直接用数值代表优先级呢？因为这样子很容易出现确定随意性。比如开发人员A开发了一个非常重要的pod，于是在代码中将其优先级的值设置为9999。但是集群集群管理员B可能认为9999是一个小数字，他创建的随便一个pod的优先级都是999999+。于是需要PriorityClass来进行优先级的统一管理和比较。
50.  CSIDriver: 定义了集群中容器存储驱动的API资源。[CSI](https://link.zhihu.com/?target=https%3A//kubernetes-csi.github.io/docs/introduction.html)代表的是Container Storage Interface，即容器存储接口。k8s应该可以利用各种各样的存储服务，各家云厂商的活开源的。k8s如何知道怎么去用这些存储服务呢？那么就是通过这个CSIDriver资源找到相应的驱动。
51.  CSINode: 前面CSIDriver产生的节点相关的信息便存在CSINode中。
52.  StorageClass: 定义了可以存在的存储类型的API资源。
53.  Volumeattachments: 定义了对一个node分配/回收存储空间的请求的API资源。
54.  NetworkSets: 接下来的都是Calico自定义API资源，就不一一分析了，都与网络协议/安全/管理相关。
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资源

apiVersion： api版本
kind: 资源类型
metadata: #元数据
  name: 名字
  namespace:所在命名空间
  labels: 标签信息（可以多个）
    ##标签是key：value格式的key，value最长只能使用63个字符
    # key只能是以数字、之母、_、-、点（.）这五类的组合，
     #value可以为空，但只能以数字及字母开头或结尾
    app: 标签内容
  annotations: #注释（不具备什么功能 就是注释 ）
    zhushi： ”lalalalalalalal saddas”
spec:期望状态
  containers:容器信息（可以多个名称云镜像）
  - name: 自定义name名称
    image：镜像名
  - name： 
    image：
  nodeSelector:#节点选择器（如给指定运行在disk为ssd的node上）
    disk: ssd
  imagePullPolicy:#是否使用本地或远端的下载镜像
    #1、Always
    #2、Never
    #3、IfNotPresent
  livenessProbe：#存活性探针
　　　　#1、exec #命令
　　　　#2、httpGet #http请求 指定ip:port
　　　　#3、tcpSocket  #
   readinessProbe：#就绪状态探针
 　　　　#1、exec #命令
 　　　　#2、httpGet #http请求 指定ip:port
　　　　#3、tcpSocket  #