k8s常用命令介绍

由 ·  

0    177    1

Tags：

👉 本文共约8235个字，系统预计阅读时间或需31分钟。

本页目录 隐藏
结构模型
理念
kubectl get 列出资源
kubectl describe 查看详情
kubectl logs 查看日志
kubectl create 创建资源
kubectl explain 解释配置
kubectl delete 删除一切
kubectl edit 修改配置
kubectl apply 应用配置
参考
相关文章

本文将介绍 k8s 中的一些最基本的命令，并辅以解释一些基本概念来方便理解，也就是说，本文是一篇偏向实用性而非学术性的文章，如果你想提前了解一下 k8s 相关的知识的话，可以通过以下链接进行学习：

结构模型

k8s 是经典的一对多模型，有一个主要的管理节点master和许多的工作节点slaver。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用。k8s 包括了许多的组件，每个组件都是单运行在一个docker容器中，然后通过自己规划的虚拟网络相互访问。你可以通过kubectl get pod -n kube-system查看所有节点上的组件容器。

在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于”基本使用“来说，这些名字并不重要。

理念

要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。

k8s 把数量众多的服务器重新抽象为一个统一的资源池，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。

命令名类型作用
get查列出某个类型的下属资源
describe查查看某个资源的详细信息
logs查查看某个 pod 的日志
create增新建资源
explain查查看某个资源的配置项
delete删删除某个资源
edit改修改某个资源的配置项
apply改应用某个资源的配置项

kubectl get 列出资源

接下来进入正题，首先来了解一下 k8s 中最最最常用的命令kubectl get，要记住，k8s 把所有的东西都抽象成了资源，而kubectl get就是用来查看这些资源的。最常见的资源就是 pod 。

什么是 pod？

pod(豆荚)。 pod 的概念其实和docker中的容器非常相似。他是 k8s 中的最小工作单位。你可以把 pod 理解成一个一个的小机器人，而 k8s 抽象出来的大资源池就是他们的工厂。

pod 和 docker 容器的关系？

pod 将一个或多个docker容器封装成一个统一的整体进行管理并对外提供服务。

不仅我们自己的服务是要包装成 pod 的，就连 k8s 自己也是运行在一堆 pod 上。接下来就让我们查看一下 k8s 的 pod ：

-n参数指定了要查看哪个命名空间下的 pod 。 k8s 所有的 pod 都被放置在kube-system命名空间下。

什么是命名空间？

命名空间namespace，是 k8s 中”组“的概念，提供同一服务的 pod 就应该被放置同一命名空间下，而不是混杂在一起。k8s 可以用命名空间来做权限控制。如果不指定的话， pod 将被放置在默认的命名空间default下。

执行了kubectl get pod -n kube-system命令后，你就可以看到如下内容：

其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：

  • NAME：第一列是 pod 的名字，k8s 可以为 pod 随机分配一个五位数的后缀。
  • READY：第二列是 pod 中已经就绪的 docker 容器的数量，上文中我们提到了，pod 封装了一个或多个 docker 容器。在这里，1/1的含义为就绪1个容器/共计1个容器。
  • STATUS：第三列是 pod 的当前状态，下面是一些常见的状态：
状态名含义
Running运行中
Error异常，无法提供服务
Pending准备中，暂时无法提供服务
Terminaling结束中，即将被移除
Unknown未知状态，多发生于节点宕机
PullImageBackOff镜像拉取失败
  • RESTART：k8s 可以自动重启 pod，这一行就是标记了 pod 一共重启了多少次。
  • AGE：pod 一共存在了多长时间。

kubectl get可以列出 k8s 中所有资源

这里只介绍了如何用kubectl获取 pod 的列表。但是不要把get和pod绑定在一起，pod 只是 k8s 中的一种服务，你不仅可以get pod，还可以get svc(查看服务)、get rs(查看副本控制器)、get deploy(查看部署)等等等等，虽然说kubectl get pod是最常用的一个，但是如果想查看某个资源而又不知道命令是什么，kbuectl get <资源名>就对了。

如果你想看更多的信息，就可以指定-o wide参数，如下：

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！

加上这个参数之后就可以看到资源的所在ip和所在节点node了。

记得加上 -n

-n可以说是kubectl get命令使用最频繁的参数了，在正式使用中，我们永远不会把资源发布在默认命名空间。所以，永远不要忘记在get命令后面加上-n。

kubectl get命令可以列出 k8s 中的资源，而kubectl get pod是非常常用的查看 pod 的命令。而-n参数则可以指定 pod 所在的命名空间。

kubectl describe 查看详情

kubectl describe命令可以用来查看某一资源的具体信息，他同样可以查看所有资源的详情，不过最常用的还是查看 pod 的详情。他也同样可以使用-n参数指定资源所在的命名空间。

举个例子，我们可以用下面命令来查看刚才 pod 列表中的某个 pod，注意不要忘记把 pod 名称修改成自己的：

然后你就可以看到很多的信息，咱们分开说，首先是基本属性，你可以在详细信息的开头找到它：

基本属性

其中几个比较常用的，例如Node、labels和Controlled By。通过Node你可以快速定位到 pod 所处的机器，从而检查该机器是否出现问题或宕机等。通过labels你可以检索到该 pod 的大致用途及定位。而通过Controlled By，你可以知道该 pod 是由那种 k8s 资源创建的，然后就可以使用kubectl get <资源名>来继续查找问题。例如上文DaemonSet/kube-flannel-ds-amd64，就可以通过kubectl get DaemonSet -n kube-system来获取上一节资源的信息。

内部镜像信息

在中间部分你可以找到像下面一样的Containers段落。该段落详细的描述了 pod 中每个 docker 容器的信息，常用的比如Image字段，当 pod 出现 ImagePullBackOff错误的时候就可以查看该字段确认拉取的什么镜像。其他的字段名都很通俗，直接翻译即可。

事件

在describe查看详情的时候，最常用的信息获取处就是这个Event段落了，你可以在介绍内容的末尾找到它，如下：

是的，如果你看到上面这样，没有任何Events的话，就说明该 pod 一切正常。当 pod 的状态不是Running时，这里一定会有或多或少的问题，长得像下面一样，然后你就可以通过其中的信息分析 pod 出现问题的详细原因了：

kubectl describe <资源名> <实例名>可以查看一个资源的详细信息，最常用的还是比如kubectl describe pod <pod名> -n <命名空间>来获取一个 pod 的基本信息。如果出现问题的话，可以在获取到的信息的末尾看到Event段落，其中记录着导致 pod 故障的原因。

kubectl logs 查看日志

如果你想查看一个 pod 的具体日志，就可以通过kubectl logs <pod名>来查看。注意，这个只能查看 pod 的日志。通过添加-f参数可以持续查看日志。例如，查看kube-system命名空间中某个flannel pod 的日志，注意修改 pod 名称：

然后就可以看到如下输出：

如果你发现某个 pod 的服务有问题，但是状态还是显示Running，就可以使用kubectl logs来查看其详细日志。

kubectl create 创建资源

k8s 中的所有东西都可以通过kubectl create命令创建，无论你是想创建一个 pod 还是一个大型的滚动升级服务deployment，create命令都可以做到。使用create生成一个资源主要有两种常用方法，从yaml配置文件创建 和 简易创建：

从yaml配置文件创建

如果你想让 k8s 生成一个和你想象中一模一样的资源，那你就要充分而详细的描述这个资源，k8s 就提供了这么一个方法，你可以使用yaml格式创建一个文件，按照 k8s 指定好的结构定义一个对象，然后使用如下方法将该文件传递给 k8s。它就可以按照你的描述进行生成了：

例如，使用下面的配置文件就可以创建一个最简单的 pod：

kubia-manual.yaml

然后使用kubectl create -f kubia-manual.yaml即可创建

如果你的配置文件有问题的话那么 k8s 就会报错，如下，错误一般都是拼写导致的，比如下面这个就是Pod.spec.containers[0].ports[0]中存在一个无法识别的名称contaienrPort：

这时你可能会问了，这配置文件里一大堆名字我看不懂啊，不要着急，下一条命令就会解答这个疑惑，但是在此之前，我们先来看一下更简单的 简易创建 模式。

简易创建

k8s 为一些常用的资源提供了简易创建的方法，比如说service、namespace、deployment等，这些方法可以使用kubectl create <资源类型> <资源名>的方式创建。例如我想创建一个名叫hello-world的命名空间，直接使用下面命令即可：

这样就不用再跟大而全的配置文件打交道了，如果你想了解都有哪些资源可以快速生成的话，使用kubectl create -h命令查看。

kubectl create可以通过指定-f <配置文件名.yaml>参数来从一个yaml文件生成资源，也可用使用kubectl create <资源类型> <资源名>来快速生成一个资源。

kubectl explain 解释配置

从上一小节中我们可以知道，k8s 可以通过配置文件来生成资源，而为了尽可能详细的描述资源的模样，k8s 提供了数量庞大的配置项，那么有没有一种方式可以快速的了解到某个配置项的作用呢？有，那就是explain(解释)命令。

咱们来实践一下，翻到上一小节里提到的生成 pod 的配置文件。首先，我想要了解创建 pod 的哪些基本属性都是干什么的，输入kubectl explain pod即可：

可以看到，给出的解释非常详细，并且每个解释的最后都附带了一条链接，便于更加深入的进行了解，好了，那我想要了解matedata(元数据)字段都有哪些配置项怎么办呢？

又是一排十分详细的解释，通过这种方式，我们可以了解到每一个资源的每一个配置项。想了解某个属性的子属性，就加个.继续查。不要说看不懂，我觉得 谷歌翻译 这种东西已经挺常见了。

kubectl delete 删除一切

delete命令的使用非常简单，如下：

比如说你想删除一个名为kubia-4n2tg的 pod。就可以这么写：

如果你想删除所有的 pod，就可以这么写：

如果你想删除一切！那就这么写：

注意！执行删除一切命令没有二次验证，所有资源均会被直接删除，在执行前先考虑下跑路成本。

kubectl edit 修改配置

如果在日常维护过程中，因为某些原因我们需要变更一些服务的设置该怎么办呢？从创建新资源小节我们可以了解到，每个资源都是通过一个yaml配置文件生成的，哪怕是简易创建的资源，也是 k8s 从一个默认的配置文件创建而来的。

我们可以在get命令后附加-o yaml文件查看某个现有资源的配置项。例如，查看 pod kubia-manual的配置项：

执行之后就可以看到一个很长的配置列表，你也可以试一下自己创建的 pod 的配置项，你会发现同样很长，这就是因为 k8s 会读取你提供的信息，并将必要但是你没有提供的其他信息设为默认值填写进去。而kubectl edit就可以编辑刚才打开的这个列表。例如，编辑在create小节中创建的 pod kubia-manual。

之后就会弹出系统设置的默认编辑器。这时我们就可以做任意修改，例如将名称改为kubia-manual-v2。首先定位到metadata.name字段，然后修改他的值：

修改完成后输入:wq保存，随后你会发现， k8s 居然报错了

不要着急，这个是 k8s 做出的限制，你无法修改一个运行中资源的名称或类型。那我们就来修改一下他的其他属性好了。例如将拉取镜像的标签指定为latest。重新edit配置文件，找到spec。containers.image字段，然后在最后添加:latest后保存。随后 k8s 会弹出保存成功，如下：

这时我们再kubectl describe pod kubia-manual查看该 pod 的详情，就可以发现对应的字段已经更新了：

kubectl edit <资源类型> <资源名> 可以编辑一个资源的具体配置项，更详细的文档请参考 k8s 中文网 - kubectl edit 。edit命令在实际使用中更偏向于人工修改某个配置项来解决问题，例如修改镜像地址解决拉取不到镜像的问题。更常用的编辑命令请参见下一节kubectl apply。

kubectl apply 应用配置

上一节我们知道了一个简单快捷的编辑配置方法kubectl edit，但是如果我们想对资源进行大范围的修改呢？总不能打开配置项一个一个手动修改吧。这时候就可以用到我们的kubectl apply命令了。基本用法如下：

kubeclt apply可以说是edit命令的升级版，它和edit最大的区别就是，apply接受一个yaml配置文件，而不是打开一个编辑器去修改。k8s 在接受到这个配置文件后，会根据metadata中的元数据来查找目标资源，如果没有的话则直接新建，如果找到的话就依次比对配置文件之间有什么不同点，然后应用不同的配置。

这么做的好处有很多，例如你通过kubectl apply -f https://some-network-site/resourse.yaml命令从一个网站上部署了你的资源，这样当它的管理者更新了这个配置文件后，你只需要再次执行这个命令就可以应用更新后的内容了，而且完全不用关心修改了哪些配置项。

除了修改手段不同以外，apply命令的行为和edit保持一致，你可以访问 k8s 中文网 - kubectl apply 来查看更多用法。

参考

https://www.jianshu.com/p/8d60ce1587e1

https://www.jianshu.com/p/116ce601a60f

标签：

头像

小麦苗

学习或考证，均可联系麦老师，请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿，我是小麦，需要帮助随时找我哦
  • 18509239930

  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群

  • 个人微店

  • 回到顶部
返回顶部