最常用的kubectl命令(附带场景和截图) —— kubernetes实用随笔（二）

谁借莪１个温暖的怀抱￠ 2022-05-21 00:18 180阅读 0赞

> 系列文章：     
> 
>  [kubernetes和Docker —— kubernetes实用随笔（一）][kubernetes_Docker _ kubernetes]
> 
> [最常用的kubectl命令(附带场景和截图) —— kubernetes实用随笔（二）][kubectl_ _ kubernetes]
> 
> [kubernetes核心对象 —— kubernetes实用随笔（三）][kubernetes_ _ kubernetes]

上几篇博客主要介绍了k8s核心概念、接下来直接上手操作，在操作命令时，最好还是现将概念弄懂，否则排查问题时无从下手。

本文主要介绍kubernetes排查问题时经常用到的命令。这里主要借助kubectl命令来实现。以下列出常用命令，后面会对每个命令进行详细解释，并举例：

<table style="width:592px;">  kubectl核心命令  
 <tbody> 
  <tr> 
   <td style="width:129px;">get</td> 
   <td style="width:460px;">获取列出一个或多个资源的信息。（资源分为pod、instance、service等很多种）</td> 
  </tr> 
  <tr> 
   <td style="width:129px;">describe</td> 
   <td style="width:460px;">输出指定的一个/多个资源的详细信息。（一般describe状态有问题节点，如Pending等）</td> 
  </tr> 
  <tr> 
   <td style="width:129px;">logs</td> 
   <td style="width:460px;"><span style="color:#555555;">输出pod中一个容器的日志。（<span style="color:#555555;">如果pod只包含一个容器则可以省略容器名</span>）</span></td> 
  </tr> 
  <tr> 
   <td style="width:129px;">create</td> 
   <td style="width:460px;">指定Yaml或Json，创建资源。（通过文件或者控制台输入）</td> 
  </tr> 
  <tr> 
   <td style="width:129px;">edit</td> 
   <td style="width:460px;"> <p>编辑服务器上定义的资源。（文件默认输出格式为YAML。要以JSON格式编辑，请指定“-o json”选项。）</p> </td> 
  </tr> 
  <tr> 
   <td style="width:129px;">rolling-update</td> 
   <td style="width:460px;">执行指定ReplicationController的滚动更新。（不中断业务的更新方式）</td> 
  </tr> 
  <tr> 
   <td style="width:129px;">delete</td> 
   <td style="width:460px;">删除一个资源（可以是pod、instance等）</td> 
  </tr> 
  <tr> 
   <td style="width:129px;">exec</td> 
   <td style="width:460px;">在容器内部执行命令</td> 
  </tr> 
 </tbody> 
</table>

# **一、get** #

获取所有namespace：

kubectl get ns

在指定的namespace下获取资源：

kubectl -n {$nameSpace} get pods

以yaml格式输出资源：

kubectl -n {$nameSpace} -o yaml

通用格式：

kubectl get {$sourceType} --all-namespaces

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

*  po（pod）
 *  ns（命名空间namespace）
 *  instance（实例）
 *  svc（service服务）：定义了一个 Pod 的逻辑分组，一种可以访问它们的策略（微服务）。
 *  cm（configMap）：存储全局配置变量的，将分布式系统中不同模块的环境变量统一到一个对象中管理。
 *  ds（deamonSet）：在每台计算节点上运行一个守护进程（如日志采集等）,有时pod处于pending可能是因为某个deamonSet没起来。
 *  deploy（deployment）：用于启动（上线/部署）一个Pod或者ReplicaSet。这个如果有问题，那么其他依赖它来部署的资源就肯定不会正常了。

# **二、describe ** #

描述一个资源：

kubectl -n {$nameSpace} describe {$resourceType} {$resourceName}

# **三、logs** #

查看日志，--tail指定只看最后1000行：

kubectl -n {$nameSpace} logs --tail=1000 {$podName} | less

# **五、create** #

通过配置文件名创建一个集群资源对象。

create -f {$yamlorJsonFilePath}

# **六、edit** #

编辑一个资源文件，这里以编辑configMap资源对象为例（yaml格式）：

kubectl -n {$nameSpace} edit {$resourceType} {$resourceName} -o yaml

# **七、rolling-update** #

执行指定ReplicationController的滚动更新。该命令会创建一个新的RC，等新pod完全起来后删除一个旧的pod，之后重复操作，直到替换掉所有的pod。

kubectl rolling-update {$resourceName} -f {$yamlFile}

# **八、delete** #

指定资源类型和名字删除一个资源：

kubectl -n {$nameSpace} delete {$resourceType} {$resourceName}

批量删除资源：

kubectl -n {$nameSpace} delete {$resourceType} -l {$label}={$labelValue}

# **九、exec** #

exec主要作用是在容器内部执行命令（一般为查看容器内部日志），这里以一个小例子说明kubectl exec命令的作用。

**场景描述：**当我们用命令行，以root用户身份登录机器，要修改HDFS某个目录权限。

此情况一般是不允许的，因为在HDFS中，最高权限并不是root用户，而是hdfs用户，这个时候如果更改，会提示权限不足。如下我们以root用户登录机器，想修改HDFS的/tmp/jbw目录权限为777，发现此目录并不属于root组，没权限修改。

![70][]

查看/tmp/jbw目录，发现其属于hdfs组的hadoop用户。

![70 1][]

尝试着用hdfs用户去执行命令，发现本机上并没有hdfs用户，因为真正的hdfs用户只存在于真实部署HDFS的容器内部。

![70 2][]

但我们如果非要想改其权限应该怎么办呢？那就用kubectl的exec命令，**进入HDFS的任意一个namenode容器内部去更改**就好（前提是以容器化方式部署HDFS）。

1、获取namenode的pod

kubectl get pods | grep namenode

结果如图所示：

![70 3][]

2、任选一个pod进入（**利用kubectl exec命令**）

kubectl exec -it hadoop-hdfs-namenode-hdfs1-765788744-21mft bash

如下已经进入所选pod：

![70 4][]

若看到~，表示进入成功（因为当前目录有所变化，若是在不放心df -h看一下文件系统是否有变化也可）。

如果进入部署HDFS的容器pod内部（这里是进入了部署namenode的一个pod，理论上datenode也可以），这些pod里当然就有hdfs用户了，接下来以hdfs用户执行相应修改目录权限命令即可。

sudo -u hdfs hadoop fs -chmod 777 /tmp/jbw

下图即执行修改目录权限命令结果：

![70 5][]

exit退出当前pod，再查看一下HDFS上的/tmp/jbw目录，就会发现，权限已修改！如下图所示：

![70 6][]

![70 7][]

[kubernetes_Docker _ kubernetes]: https://blog.csdn.net/whdxjbw/article/details/80739529
[kubectl_ _ kubernetes]: https://blog.csdn.net/whdxjbw/article/details/80815950
[kubernetes_ _ kubernetes]: https://blog.csdn.net/whdxjbw/article/details/80798996
[70]: /images/20220521/316515f1a966455eba0b9194fc52715f.png
[70 1]: /images/20220521/916a7547aa5f4538a41afc59244ac565.png
[70 2]: /images/20220521/5dc048c5a67e41feb49fae1cf8902deb.png
[70 3]: /images/20220521/be05c5e2a96848e0b1792072ce936a3d.png
[70 4]: /images/20220521/12c19b1e33744493942cc45e836ed1a6.png
[70 5]: /images/20220521/eb0a90a3c61b481fba315b95769b0d7d.png
[70 6]: /images/20220521/32b2ef8872dd4bd185c36d1da01c411a.png
[70 7]: /images/20220521/b289d0278af14032901b8a3abdbfca54.png