kubectl是k8s提供的客户端工具，使用client-go与k8s的apiserver进行交互
kubectl默认会从$HOME/.kube目录下查找文件名为config的文件，也可以通过设置环境变量KUBECONFIG或者通过设置--kubeconfig去指定其它kubeconfig文件
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority-data: xxx
server: https://132.224.201.230:8443
name: test1
contexts:
- context:
cluster: test1
user: test1-admin
name: context-test1
current-context: context-production3
preferences: {}
users:
- name: test1-admin
user:
client-certificate-data: xxx
client-key-data: xxx
若想要用base64编码数据代替认证文件，需要添加后缀-data，将 certificate-authority、client-certificate、client-key改为certificate-authority-data、client-certificate-data、client-key-data
从config文件还原证书的方法：
grep 'client-key-data' /etc/kubernetes/admin.conf | head -n 1 | awk '{print $2}' | base64 -d
grep 'client-certificate-data' /etc/kubernetes/admin.conf | head -n 1 | awk '{print $2}' | base64 -d
查看kubeconfig配置：
kubectl config view
添加集群信息：
kubectl config set-cluster {cluster-name} --certificate-authority=ca.pem --embed-certs=true --server=https://ip:6443
添加用户信息：
kubectl config set-credentials {user-name} --client-certificate=test.crt --client-key=test.key --embed-certs=true
添加context（集群+用户）：
kubectl config set-context {context-name} --cluster={cluster-name} --user={user-name}
查看和切换上下文：
kubectl config get-contexts
kubectl config current-context
kubectl config use-context {context-name}
可以直接在KUBECONFIG中配置多个文件，然后进行多集群config的合并：
export KUBECONFIG=file1:file2:file3 kubectl config view --merge --flatten > ~/.kube/all-config export KUBECONFIG = ~/.kube/all-config
查询集群情况：
kubectl cluster-info
可以以组/版本的格式输出服务端支持的API版本
kubectl api-versions
访问某个具体api
kubectl get --raw “...”
可以使用如下命令查看kubectl支持的所有资源类型：
kubectl api-resources
可以使用如下命令详细了解某一种资源：
kubectl explain <resource>
-
通过get命令获取所有资源对象
kubectl get {$sourceType} -n{$namespace}
{$sourceType}除了是Pod这类具体资源，也可以是all，表示所有Pod、Service、Deployment以及ReplicaSet
namespace不指定时默认是default，也可以是--all-namespaces，表示所有namespace
可以用多种格式对结果进行显示，输出的格式通过-o参数指定：
-o custom-columns=<spec>：根据自定义列名进行输出，以逗号分隔
例如：自定义方式查看Pod的容器运行时：
kubectl get pod -o custom-colimns=NAME:metadata.name,STATUS:.status.phase,RUNTIME_CLASS:.spec.runtimeClassName
-o custom-colimns-file=<filename>：从文件中获取自定义列名进行输出
-o json/yaml：以json/yaml格式显示结果
-o wide：输出额外信息。对于Pod，将输出Pod所在的Node名
-o jsonpath=<template>：出jsonpath表达式定义的字段信息
-o jsonpath-file=<filename>：输出jsonpath表达式定义的字段信息，来源于文件
-o name：仅输出资源对象的名称
-
通过配置文件名创建/删除一个集群资源对象
kubectl apply -f {$FilePath}
{$FilePath}除了是文件路径，也可以是文件夹（如.），表示目录下所有文件
kubectl apply = kubectl create + kubectl replace
资源对象可以使用json格式的资源对象描述文件来描述，Kubernetes API接受和返回的所有JSON对象都遵循同一个模式。为了便于使用，用户一般使用YAML文件居多，但Kubernetes API需要事先自行将其转换为JSON格式后方能提交。
kubectl delete -f {$FilePath}
cat {$FilePath} | kubectl delete -f -
会根据文件中的类型和名词删除资源对象
-
通过patch补丁修改资源对象
$ kubectl patch TYPE NAME -p PATCH
patch可以是json或yaml格式，形如{"spec":{"unschedulable":true}}
-
给集群资源对象打标签
kubectl label nodes node1 key=value kubectl label --overwrite pods pod1 key=value kubectl label pods --all key=value
其中--overwrite表示覆盖，--all表示给所有pods打标签
标签名后加减号表示删除标签：
kubectl label pods pod1 key-
通过label selector，用户可以指定一个对象集合，通过label selector对对象集合进行操作。
Label selector有两种类型，多个表达式可以用逗号连接：
（1）equality-based ：可以使用=、==、!=操作符
（2）set-based ：可以使用in、notin；还可以没有操作符，直接写出某个key、!key，表示过滤有/无某个key的object而不管该key的value是何值
kubectl get pods --show-labels kubectl get pods --show-labels -l env=dev,tie=front kubectl get pods --show-labels -l ’env in (dev,test)’
-
注解
注解和打标签操作类似，把label命令改成annotate命令，然后一样指定类型和对应的名字，后面加上annotation的key:value。
value可以指定一个任意的字符串，比如说加上空格、逗号都可以；
kubectl annotate pods pod1 my-annotate=‘my annotate,ok’
-
复制文件
可以在主机与容器间、容器与容器间相互复制：
kubectl cp -c {$ContainerName} {$PodName}:/1.txt 1.txt
-
将应用代理到本地的端口上
kubectl port-forward svc/{$svcname} 6379:6379
kubectl port-forward pods/{$podname} 6379:6379
-
查看日志
kubectl logs xxx -c {$ContainerName}
-
更新镜像
资源类型形如deployment.v1.apps，也可以简写
-
自定义插件
kubectl可以自定义添加插件。例如开源调试工具kubectl-debug就是kubectl的一个插件，效果类似nsenter
kubectl debug demon-pod
执行后，会先拉取一个带了诊断工具镜像。当这个debug container启动时，会把这个container和要诊断的container的namespace进行挂靠。
此时debug container和要诊断的container是同namespace的。类似网络、内核等，都可以在这个debug container里面实时地进行查看。
如果此时进行logout的话，相当于会把相应的这个debug pod杀掉，然后进行退出，此时对应用实际上是没有任何的影响的。