kubectl工具

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杀掉，然后进行退出，此时对应用实际上是没有任何的影响的。