Kubernetes 基本概念

本节主要介绍 Resource、Namespace 以及操作 Resource。

Resource

Resource 是 Kubernetes 的一个基础概念,kubernets 用 Resource 来表示集群中的各个资源。比如Pod节点(主机)、Container容器、Proxy路由、Config配置文件等等。这些概念听起来差别很大,但是却有很多共同的基本属性。比如名称、创建时间、标签、uuid 等。kubernetes 对这些信息进行抽象,提供了一个通用的 metadata 结构,再加上各个 resource 自己的其它信息,构成了一个形式类似的数据结构。我们可以拿一个节点的信息和一个配置文件的信息看下。

查看一个配置文件的信息:

kubectl get cm cluster-info -n kube-public -o yaml

查看一个节点的信息:

kubectl get node master -o yaml

结果如下(信息较长已经截断):

命令解释:

  • get: 查看某个资源
  • -o yaml: 输出格式为 yaml, 也可以选择 json
  • node/cm: 想要查看的资源的类型, node 表示节点, cm(configmap) 表示配置文件
  • -n: 查看某个 namespace 下的资源,后续会详细介绍

对比二者,我们可以发现有很多的共同字段:

  • kind: 表示类型,比如节点是 Node , 配置文件是 ConfigMap
  • apiVersion: api 版本,可能会升级,会有不同的版本,不同版本的 resource 所包含的字段可能不一样
  • spec: 一般都是这个 resource 自己的特定信息,比如如果是节点的话会记录自己的 ip、内存等等信息,配置文件的话会记录具体的配置信息。有的资源可能没这个字段(可能叫别的名字)。
  • metadata: 基本信息,所有的 resource 都会有这个字段,且结构一样
  • name: 这个 resource 的名称
  • resourceVersion: 版本,修改此 resource 后会向上增加
  • selfLink: 通过 http api 访问此 resource 的路径
  • uid: uuid,唯一标示
  • creationTimestamp: 创建时间
  • labels: 这个 resource 的标签,我们可以用这些标签来做过滤匹配等等
  • annotations:类似于 labels, 记录一些附加信息。但 annotaitons 记录的信息不能用来做过滤匹配等等。
  • namespace: 资源所属的命名空间。有的资源有,有的资源没有。后面会详细介绍

在后面的实验中,我们会频繁地使用 resource 这个概念。这里只做初步的介绍以及展示。

Namespace

上面的示例中,我们可以看到在 ConfigMap 的 metadata 中有 namespace 这个字段,但在 Node 中却没有。kubernetes 里的资源分为两类,一种是属于 Namespace 的,一种不属于。

Namespace 的作用主要是用于名称隔离。kubernetes 的场景是面向多用户的,想象一下,用户 A 想创建一个服务叫 service, 用户 B 也想创建一个叫 service 的服务。这时候就不好办了,需要有一个类似于工作空间的东西将大家隔离起来,让大家不受名称冲突的困扰。这个东西就是 Namespace。

在 kubernetes 中,Namespace 也是一种 Resource,它有着类似于上节所介绍的结构。我们可以查看集群提前创建好的 kube-system 这个 namespace:

kubectl get ns kube-system -o yaml

注: ns 即 namespace 的简写。有很多资源都有命令行里的简写形式,比如 cm -> ConfigMap。

yaml 格式的输出结果里展示这个 ns 的一些具体信息。比如它的 status 是活跃中的(Active)。如果我们将这个 ns 删除, 它会有一段时间处于删除中。

集群创建完之后,会默认创建三个 namespace:

  • default: 默认的 namespace,也是我们最常用的。在命令行里面如果要查看属于 namespace 下的资源时可以忽略掉 -n 参数。(后续实验会介绍)
  • kube-system: 系统的 namespace,系统的一些组件都运行在这个 namespace 下面 (后续实验会详细介绍)
  • kube-public: 存放系统信息的 namespace, 一般不需要关注。

我们通过 kubectl 命令查看到这些 namespaces:

kubectl get ns

注:前面使用的 kubectl get 命令都是获取单个 resource 的信息。这里涉及到了另外一种操作,即列出某种资源。这时候会以表格形式输出各个资源的基本信息。

因为 namespace 本身不属于 namespace,所以只用指定类型即可(ns)。其他属于 namespace 的资源比如 ConfigMap 在查看时,还是需要制定 -n 参数,以指明要查看哪个 namespace 下的 ConfigMap。

可以看到输出结果展示了所有的 namespace 的名称、状态以及创建时间等,非常简单明了。

前面介绍的主要是 kubectl 的查看功能。 kubectl 还有对资源进行增删改等其他操作。因为 namespace 和 ConfigMap 都属于结构比较简单的资源,我们就分别以它们为例来介绍下如何使用 kubectl 操作 resource。

操作 namespace

创建 namespace 的操作很简单,因为 namespace 最重要的信息是它的名字,我们可以直接通过以下命令创建一个 namespace:

kubectl create ns nstest1

返回结果告诉我们已经创建成功。然后我们就可以通过 kubectl 来查看这个 namespace 了:

kubectl get ns nstest1 -o yaml

kubectl 与 kubernetes api 是通过 rest api 进行交互,我们使用的 kubectl 命令也是通过命令行里传入的参数生成合适的 body 发送给 api server。这个过程我们可以通过给 kubectl 的命令加上一个 -v 参数来看到详细步骤:

kubectl create ns nstest2 -v=9

9 表示日志的级别,一般数字越大信息越详细。

屏幕会输出 kubectl 与 api server 交互时详细的调用参数:

其执行的过程如下:

  • 读取 kubectl 的配置文件,判断需要与哪个 api server 交互。
  • 生成了 request body, 可以看到跟我们创建完成之后看到的 yaml(json) 数据很类似。
  • 调用 API,终端里打印了详细的参数以及结果。
  • 输出结果。

对于 kubectl 来说,它大多数的操作最终都是类似的形式。生成 body, 调用 apiserver ,返回结果。只是在很多地方,它做了简化处理,让用户不用填写具体的参数细节。除了像 create ns 这样特定的命令之外,它还有一些很通用的命令。

文件名:nstest3.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: nstest3

执行:

kubectl create -f /share/lesson/kubernetes/nstest3.yaml

与 test 以及 test-2 的创建进行对比,他们的结果除了名字都是类似的。不同的是,创建 test-3 我们用的是一种更为通用的方式,将需要创建资源的信息保存到 yaml 中,并使用 create 命令去创建。yaml 是比较常用的格式,也可以用 json。内容上可以包含任何资源,比如 Namespace、ConfigMap 等,不局限于 namespace。因为它是通用的,在后面我们也会经常用到这个命令。

需要注意的是,我们创建时使用的 yaml 和创建好的 yaml 的字段有一些不同。创建用的 yaml 字段较少,是因为多的那些字段,是 api server 自动添加上去的,我们不能自己提供,或者即使自己提供了 api server 也会覆盖。这些字段常见的有:

  • uid
  • creationTimestamp
  • selfLink
  • resourceVersion
  • status: status 也是很多资源常见的一个字段,表示资源的状态。这个字段也只有在创建成功之后才有意义。

操作 ConfigMap

上面介绍了如何创建 ns, 有了 ns,我们可以熟悉一下如何操作 ConfigMap。 ConfigMap 是属于 namespace 的资源,可以用之前创建的 test namespace。

首先简单介绍下 ConfigMap 的基本概念:它很像环境变量或者很多软件的配置文件,存储了一些 key-value 对。类似于 namespace, kubectl 也提供了一些简便的命令来直接创建 ConfigMap:

kubectl create cm config --from-literal=a=a --from-literal=b=b -n default -v=9

命令解释:

  • cm: ConfigMap 的简写
  • config: 要创建的 ConfigMap 的名称,可以自己定义
  • --from-literal=a=a:表示直接从命令行指定 key-value 值,a=a 的格式是=,这个参数也可以指定多次
  • -n default: 在 default这个 namespace 下面创建 ConfigMap
  • -v=9:显示创建过程的详细信息

我们在结果里看到了与创建 namespace 时类似的输出,只是 body 和 response 的区别。对于 kubectl 来说,不管是创建什么资源,都是 rest api 调用,所以我们能一直看到这种相似性。

查看我们已经创建好的 ConfigMap:

kubectl get cm config -n default -o yaml

metadata 部分与 namespace 的类似,除了 namespace 字段。data 就是 ConfigMap 的数据部分,也就是刚才我们从命令行里面指定的参数。

删除一个资源也很简单,因为我们并不需要知道具体的资源内容,只需要知道类型以及名字即可。

删除刚才创建的 ConfigMap:

kubectl delete cm config -n default

删除刚才创建的 Namespace:

kubectl delete ns nstest1 nstest2 nstest3

需要注意的是,因为 namespace 下的资源和 namespace 本身有一种从属关系。namespace 不存在时其下面的资源也没有多大意义,所以删除 namespace 时会将 namespace 下的资源一并删除。所以上面的删除 ConfigMap 即使不写最终的效果也是相同的。

移动端设备除iPad Pro外,其它移动设备仅能阅读基础的文本文字。
建议使用PC或笔记本电脑,浏览器使用Chrome或FireFox进行浏览,以开启左侧互动实验区来提升学习效率,推荐使用的分辨率为1920x1080或更高。
我们坚信最好的学习是参与其中这一理念,并致力成为中文互联网上体验更好的学练一体的IT技术学习交流平台。
您可加QQ群:575806994,一起学习交流技术,反馈网站使用中遇到问题。
内容、课程、广告等相关合作请扫描右侧二维码添加好友。

狐狸教程 Copyright 2021

进入全屏