kubernetes核心对象 —— kubernetes实用随笔（三）

柔情只为你懂 2022-05-22 13:04 189阅读 0赞

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

这篇开始就主要对kubernetes核心对象进行讲解。我们可以把Kubernetes构建容器的过程当做一个制造积木零件和搭建积木的过程。首先我们通过一种方式去描述积木零件长什么样子，机床就为我们生成什么样的零件。接着我们再利用造好的各个零件去组装成我们想要的积木造型，最终完成我们业务需求要求的积木模型。

而Kubernetes中的这些积木零件就是像namespace、pod、instance这样的对象。Kubernetes有一个非常完善的对象模型，此对象模型一般由yaml格式的文件去声明（其实k8s最终会将yaml格式转换为json格式送给api server的），我们只需要在这个文件里面的spec字段指明我们想要的效果，之后通过kubectl的create命令，Kubernetes的controller manager就会想方设法创建一个新的对象，并让这个新的对象的状态最终与我们声明的一致。

# **初识：** #

如我们我们可以先获取所有命名空间下的实例instance：

kubectl get instance --all-namespaces -o wide

![70][]

![70 1][]

再通过edit命令查看其声明样式：

kubectl -n kube-system edit instance container-log

以yaml文件格式输出k8s对象。我们可以在其中清楚的看到每一个细节，我们只要对此作出修改，Kubernetes就会帮我们重新更新对象。kind指明了当前对象属于什么类型（这里以instance为例）。

![70 2][]

Kubernetes在为我们创建好对象后直接给对象添加一个status的field，即上图倒数第二行，具体的样子如下图，你可以看到当前实例instance内部所有model的状态，排查问题时用的上。

![70 3][]

以上只是带着大家看了下instance对象的一些相关内容， 下面我们正式开始搞事情！依次介绍k8s中常用的对象到底有哪些。

# **一、Pod** #

就像原子是不可分割的最小物质一样（其实还是可以分割成夸克的，但一般在计算机领域‘原子’就相当于不可分la），pod是Kubernetes中最小的对象，不可分。我们需要部署的web app或者其他可执行程序都需要放在pod中才能在Kubernetes的管理下运行，一个pod中可以有多个容器。总的来说，我们的应用一般是被制作成image镜像，运行在像Docker这样的容器中，而一个pod里可以有多个容器，组合共同实现复杂的业务需求。

这些在同一个pod中的容器当然需要服从统一规范了，比如他们需要在同一个host主机上进行调度，共享同一个网络命名空间，挂载在同一块外部磁盘上等。大家大概了解一下就好。

这里需要指出，我们一般不直接在yaml文件中声明kind为pod类型，因为pod可能会突然挂掉，挂掉后就gg了，因为它没有自我修复功能，所以我们一般是在其他Kubernetes对象中的spec field中定义pod的，比如deployment、ReplicaSets（副本集）。

另外，我们为什么要在容器之上建立一层Pod呢？其实是因为Docker容器之间通信会受到Docker网络机制限制，如果我们现在的应用由多个容器组成，而这些容器若都在同一个Pod中时，他们之间就可以直接通过LocalHost进行通信，极为方便，微服务正是借助此思想。

# **二、Labels 和 Label Selectors** #

多个容器在一个Pod内，多个Pod变完整地构建了我们整个业务生态。呢么我们的Pod可能有很多很多个，如何才能快速定位，找到我们所需要的Pod呢？labels就是为我们搞这个事情的。每一个Pod可以指定一个Labels，每个labels里可能会有多个键值对，每个键值对代表一个label，这些label键值对不提供唯一性。也即每个Pod可以有多个label。

"labels":{
       "key1":"value1",
       "key2":"value2"
    }

LabelSelectors即根据label的取值选中某个Pod，具体支持两种类型的Label Selector。

Equality-Based Selectors 基于相等比较的。如：label in (key1,key2)。

Set-Based Selectors 基于一系列值选择的。如：label==“key1”。

我们可以通过标签来批量删除资源对象，如：

kubectl -n kube-system delete pods -l {$yourLabelKey}={$yourLabelValue}

# **三、ReplicSet 和 Replication Controller** #

他们两都是用来保证每个pod的replic副本数达到了预期值。因为当我们业务在短期内增长较快的时候，我们需要对集群进行扩容（如增加pod的数量），我们只要保证了ReplicSet的正确性，那么Kubernetes就会自动地为让我们集群达到预期的状态。

他们两者的区别是，ReplicSet是下一代的Replication Controller，ReplicSet同时支持Equality-Based Selectors和 Set-Based Selectors 。而Replication Controller只支持Equality-Based Selectors。

需要指出的是ReplicSet可以独立使用。我们也可以在Deployment对象里通过利用ReplicSet实现Pod的创建删除或更新。

# **四、Deployment** #

Deployment对象提供了Pod和ReplicSet的描述和更新。它提供了一种简单的更新Pod或ReplicSet的机制，目的是保证Pod的数量和健康状况。

如下图，我们创建了个Deployment对象，通过此Deployment里的spec声明ReplicSet，指定副本数为3，那么创建出来的Deployment对象会维护一个由k8s创建出的ReplicSet对象，这个ReplicSet对象便会根据指定的副本数创建或删除Pod，直到Pod数达到要求，这些Pod与定义ReplicSet的template共同组成了ReplicSet。

![70 4][]

接下来，如果我们想让副本数直接变成4，则直接在Deployment中修改与ReplicSet的spec定义即可，k8s会直接创建一个新的Pod，并将其加入到当前ReplicSet中。

但如果现在想把Pod中的Nginx镜像从1.7升级到1.7，那么就不仅仅是上面那么简单了，具体会做什么呢？Deployment会创建一个新的ReplicSetB，创建与ReplicSetA类似。创建好后，Deployment便会指向新的ReplicSetB。如下图所示：

![70 5][]

那么，这里我们可能会有疑问，我们为什么要用Deployment去维护ReplicSet，而不是直接用ReplicSet呢？**其实基于ReplicSet的Deployment能够提供很多特性，如recording，如果我们升级后出现了bug，那么就可以通过Deployment的recording特性，很方便地roolback回去。但如果只有ReplicSet，那就gg了。**

# **五、NameSpace** #

**   **     关于NameSpace，你说有用，它就很有用，你说它没用，只是可能平时用到的并不是太多，就像一名备胎暖男。你可以养多个备胎暖男，但他们都不知道互相的存在。算了不继续比喻下去了。

言归正传，NameSpace可以将Kubernetes集群划分为多个独立的空间，在这些空间你你可以分别唯一地创建你需要的资源对象。无需担心重复。

我们这里介绍3个基本的命名空间。

一、kube-syytem：存放k8s核心组件。

二、default：默认连接到的命名空间。

三、kube-public：可被所有用户读的，一般在初始化集群时候用作配置信息存储。

通过kubectl命令，查看所有NameSpace：

kubectl get namespaces

![70 6][]

另外，需要指出的是，我们一般查询某个资源的状态，或者想对某个资源进行操作，需要加上-n参数，指定命名空间。因为不同命名空间可以重名，若不指定命名空间，k8s无法确认你想对哪个命名空间下的资源进行操作。当然我们也可以在命令的末尾加上--all-namespaces，表明在所有命名空间下进行操作。

kubectl get po --all-namespaces

![70 7][]

其实，NameSpace用处很大，个人觉得NameSpace被用到的最机智地方体就现在**当今的云计算平台中的租户**概念中，一个租户可以申请购买一些实例，这些不同的实例都运行在同一个租户下，我们不同的租户其实就是不同的NameSpace。大家相互不影响。同时我们也可以用Resource Quotas来限制每个NameSpace资源，这样就能方便地按需分配。

总算是写完了，不容易啊，这篇写的最久的一篇，希望对大家理解Kubernetes有帮助！共勉！

[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/20220522/095dd670ae50478c9e20b237348b71bd.png
[70 1]: /images/20220522/203ebd213f7e4c3ab88f5320f2702541.png
[70 2]: /images/20220522/d2ffacd2211640a69a26342925daa0ba.png
[70 3]: /images/20220522/f9518c53879340258aa599ec73a32fb7.png
[70 4]: /images/20220522/9fbf6566ad294a3c94a3f66f2bc982ac.png
[70 5]: /images/20220522/d970753336ef46949b738c1c70784cb8.png
[70 6]: /images/20220522/d0dcc46bced746e0a680994b7d24c589.png
[70 7]: /images/20220522/f659d3c5e4a84f539f2a7eb0edd5d61e.png