详解kubectl常用命令

一、查看

1、查看集群状态

# 查看客户端及服务端程序版本信息

kubectl version --short=true

# 查看集群信息

kubectl cluster-info

2、查看资源对象

# 查看命名空间

kubectl get namespace

# 查看所有 pod 列表, -n 后跟 namespace, 查看指定的命名空间，-o wide 查看详细信息

kubectlget pod

kubectlget pod -n kube

kubectlget pod -o wide

# -l 标签选择器(多个的话是与逻辑)

kubectl get pods -l app=example

# -w 监视资源变动信息

kubectl get pod-w

# 以yaml格式查看Pod详细信息

kubectlgetpod -o yaml

# 以json格式查看Pod详细信息

kubectlgetpod -o json

# 查看deployment下pod列表

kubectl get pod -n xxx | grep ${deploymentName}

通用格式：kubectl get {$sourceType} --all-namespaces

常用的资源类型（{$resourceType}）有：

node (节点)

po（pod）

ns（命名空间namespace）

instance（实例）

svc（service服务）：定义了一个 Pod 的逻辑分组，一种可以访问它们的策略（微服务）

cm（configMap）：存储全局配置变量的，将分布式系统中不同模块的环境变量统一到一个对象中管理

ds（deamonSet）：在每台计算节点上运行一个守护进程（如日志采集等）,有时pod处于pending可能是因为某个deamonSet没起来

deploy（deployment）：用于启动（上线/部署）一个Pod或者ReplicaSet。这个如果有问题，那么其他依赖它来部署的资源就肯定不会正常了

ingress : 通过http或https暴露集群内部service，给service提供外部URL、负载均衡、SSL/TLS能力以及基于host的方向代理

# 查看 endpoint 列表 kubectlget endpoints

pv：存储卷

pvc:存储卷消费者

3、查看详情

describe类似于get，同样用于获取resource的相关信息。不同的是，get获得的是更详细的resource个性的详细信息，describe获得的是resource集群相关的信息。

describe命令同get类似，但是describe不支持-o选项，对于同一类型resource，describe输出的信息格式，内容域相同。

注：如果发现是查询某个resource的信息，使用get命令能够获取更加详尽的信息。但是如果想要查询某个resource的状态，

如某个pod并不是在running状态，这时需要获取更详尽的状态信息时，就应该使用describe命令。

# 显示 Pod 的详细信息, 特别是查看 Pod 无法创建的时候的日志、Pod的运行事件，比如镜像有没有拉取，容器有没有创建

kubectl describe pod

kubectl describe deployment

kubectl describe service

# 显示 Node 的详细信息

kubectldescribe node [node ip]

# 显示由deployment管理的Pod的信息

kubectl describe pods

# 查看pod中所有容器的信息

kubectl describe pod/{pod_name} -n {namespace}

4、查看日志

# 实时查看日志

kubectl logs -f

# 若 pod 有多个容器，加 -c 指定容器

kubectl logs-f -c

# kubectl attach -c

类似于docker attach的功能，用于取得实时的类似于kubectl logs的信息

5、查看kubernetes配置

6、查看资源对象拥有的字段

kubectlexplain pod

kubectlexplain pod.apiVersion

7、查看节点标签

kubectlget node --show-labels

为kubernetes集群的resource打标签，如前面实例中提到的为rc打标签对rc分组。还可以对nodes打标签，这样在编排容器时，

可以为容器指定nodeSelector将容器调度到指定lable的机器上，如如果集群中有IO密集型，计算密集型的机器分组，可以将不同的机器打上不同标签，

然后将不同特征的容器调度到不同分组上。在1.2之前的版本中，使用kubectl get nodes则可以列出所有节点的信息，包括节点标签，

1.2版本中不再列出节点的标签信息，如果需要查看节点被打了哪些标签，需要使用describe查看节点的信息。

8、文件交换

kubectl cp 用于pod和外部的文件交换，比如如下示例了如何在进行内外文件交换

在pod中创建一个文件message.log

[[email protected] tmp]# kubectl exec -it mysql-478535978-1dnm2 sh
# pwd
/
# cd /tmp
# echo "this is a message from `hostname`" >message.log
# cat message.log
this is a message from mysql-478535978-1dnm2
# exit
拷贝出来并确认
[[email protected]-1 tmp]# kubectl cp mysql-478535978-1dnm2:/tmp/message.log message.log
tar: Removing leading `/' from member names
[[email protected]-1 tmp]# cat message.log
this is a message from mysql-478535978-1dnm2
更改message.log并拷贝回pod
[[email protected]-1 tmp]# echo "information added in `hostname`" >>message.log
[[email protected]-1 tmp]# cat message.log
this is a message from mysql-478535978-1dnm2
information added in ku8-1
[[email protected]-1 tmp]# kubectl cp message.log mysql-478535978-1dnm2:/tmp/message.log
确认更改后的信息
[[email protected]-1 tmp]# kubectl exec mysql-478535978-1dnm2 cat /tmp/message.log
this is a message from mysql-478535978-1dnm2
information added in ku8-1

二、创建/修改资源

1、kubectl create/apply

# 以标准输入创建资源

kubectl create deployment nginx --image=nginx:1.14

# 以文件创建资源

kubectl create -f my-nginx.yaml # create 创建一次

kubectlapply -f my-nginx.yaml # apply 可创建多次

2、kubectl replace/patch

用于对已有资源进行更新、替换。如前面create中创建的nginx，当我们需要更新resource的一些属性的时候，

如修改副本数量，增加、修改label，更改image版本，修改端口等。都可以直接修改原yaml文件，然后执行replace命令（删除原有资源然后重新构建资源）

kubectl replace -f

注意：yaml文件里的metadata的name不能修改（是按照name作为资源的唯一标识）

# 如对正在运行的容器的属性进行在线修改（不删除容器），比如修改pod的label等

kubectl patch pod rc-nginx-2-kpiqt -p '{"metadata":{"labels":{"app":"nginx-3"}}}'

3、kubectl edit

# edit提供了另一种更新resource源的操作，通过edit能够灵活的在一个common的resource基础上，发展出更过的significant resource。

例如，使用edit直接更新前面创建的pod的命令为：

[root@master1 ~]# kubectl edit po rc-nginx-btv4j

上面命令的效果等效于：

kubectl get po rc-nginx-btv4j -o yaml >> /tmp/nginx-tmp.yaml
vim /tmp/nginx-tmp.yaml
/*do some changes here */
kubectl replace -f /tmp/nginx-tmp.yaml

4、kubectl set

# kubectl set resources 用于设置资源的一些范围限制

资源对象中的Pod可以指定计算资源需求（CPU-单位m、内存-单位Mi），即使用的最小资源请求（Requests），

限制（Limits）的最大资源需求，Pod将保证使用在设置的资源数量范围。

对于每个Pod资源，如果指定了Limits（限制）值，并省略了Requests（请求），则Requests默认为Limits的值。

可用资源对象包括(支持大小写)：replicationcontroller、deployment、daemonset、job、replicaset。

例如：

# 将deployment的nginx容器cpu限制为“200m”，将内存设置为“512Mi”
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
# 设置所有nginx容器中 Requests和Limits
$ kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi
# 删除nginx中容器的计算资源值
$ kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0
# kubectl set image 用于更新现有资源的容器镜像
# 将deployment中的nginx容器镜像设置为“nginx：1.9.1”
$ kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
# 所有deployment和rc的nginx容器镜像更新为“nginx：1.9.1”
$ kubectl set image deployments,rc nginx=nginx:1.9.1 --all
# 将daemonset abc的所有容器镜像更新为“nginx：1.9.1”
$ kubectl set image daemonset abc *=nginx:1.9.1
# 从本地文件中更新nginx容器镜像
$ kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

5、kubectl label、annotate

label命令:用于更新（增加、修改或删除）资源上的 label（标签）

label 必须以字母或数字开头，可以使用字母、数字、连字符、点和下划线，最长63个字符。

如果 --overwrite 为 true，则可以覆盖已有的label，否则尝试覆盖label将会报错。

如果指定了--resource-version，则更新将使用此资源版本，否则将使用现有的资源版本。

语法：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'，且覆盖现有的value
$ kubectl label --overwrite pods foo status=unhealthy
# 给 namespace 中的所有 pod 添加 label
$ kubectl label pods --all status=unhealthy
# 仅当resource-version=1时才更新 名为foo的Pod上的label
$ kubectl label pods foo status=unhealthy --resource-version=1
# 删除名为“bar”的label 。（使用“ - ”减号相连）
$ kubectl label pods foo bar-

annotate命令：更新一个或多个资源的Annotations信息。也就是注解信息，可以方便的查看做了哪些操作。

Annotations由key/value组成。

Annotations的目的是存储辅助数据，特别是通过工具和系统扩展操作的数据，更多介绍在这里。

如果--overwrite为true，现有的annotations可以被覆盖，否则试图覆盖annotations将会报错。

如果设置了--resource-version，则更新将使用此resource version，否则将使用原有的resource version。

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

例：

# 更新Pod“foo”，设置annotation “description”的value “my frontend”，如果同一个annotation多次设置，则只使用最后设置的value值
$ kubectl annotate pods foo description='my frontend'
# 根据“pod.json”中的type和name更新pod的annotation
$ kubectl annotate -f pod.json description='my frontend'
# 更新Pod"foo"，设置annotation“description”的value“my frontend running nginx”，覆盖现有的值
$ kubectl annotate --overwrite pods foo description='my frontend running nginx'
# 更新 namespace中的所有pod
$ kubectl annotate pods --all description='my frontend running nginx'
# 只有当resource-version为1时，才更新pod 'foo'
$ kubectl annotate pods foo description='my frontend running nginx' --resource-version=1
# 通过删除名为“description”的annotations来更新pod 'foo'。
# 不需要 -overwrite flag。
$ kubectl annotate pods foo description-

三、启动Pod

# 在集群中创建、启动一个指定的镜像

[root@ku8-1 tmp] # kubectl run nginx --image=nginx:1.16 --port=80 --replicas=1

deployment "nginx" created

[root@ku8-1 tmp] #

从提示看到创建了一个deployment

kubernetes将镜像运行在pod中以方便实施卷和网络共享等管理，使用get pods可以清楚的看到生成了一个pod

[root@ku8-1 tmp] # kubectl get pods

NAME READY STATUS RESTARTS AGE

sonarqube-1880671902-s3fdq 1/1 Running 0 6m

[root@ku8-1 tmp] #

链接：https://www.cnblogs.com/ailiailan/p/14565429.html