- kubernetes和Docker —— kubernetes实用随笔（一）
- 最常用的kubectl命令(附带场景和截图) —— 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
再通过edit命令查看其声明样式：
kubectl -n kube-system edit instance container-log以yaml文件格式输出k8s对象。我们可以在其中清楚的看到每一个细节，我们只要对此作出修改，Kubernetes就会帮我们重新更新对象。kind指明了当前对象属于什么类型（这里以instance为例）。
Kubernetes在为我们创建好对象后直接给对象添加一个status的field，即上图倒数第二行，具体的样子如下图，你可以看到当前实例instance内部所有model的状态，排查问题时用的上。
以上只是带着大家看了下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。
接下来，如果我们想让副本数直接变成4，则直接在Deployment中修改与ReplicSet的spec定义即可，k8s会直接创建一个新的Pod，并将其加入到当前ReplicSet中。
但如果现在想把Pod中的Nginx镜像从1.7升级到1.7，那么就不仅仅是上面那么简单了，具体会做什么呢？Deployment会创建一个新的ReplicSetB，创建与ReplicSetA类似。创建好后，Deployment便会指向新的ReplicSetB。如下图所示：
那么，这里我们可能会有疑问，我们为什么要用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
另外，需要指出的是，我们一般查询某个资源的状态，或者想对某个资源进行操作，需要加上-n参数，指定命名空间。因为不同命名空间可以重名，若不指定命名空间，k8s无法确认你想对哪个命名空间下的资源进行操作。当然我们也可以在命令的末尾加上--all-namespaces，表明在所有命名空间下进行操作。
kubectl get po --all-namespaces
其实，NameSpace用处很大，个人觉得NameSpace被用到的最机智地方体就现在当今的云计算平台中的租户概念中，一个租户可以申请购买一些实例，这些不同的实例都运行在同一个租户下，我们不同的租户其实就是不同的NameSpace。大家相互不影响。同时我们也可以用Resource Quotas来限制每个NameSpace资源，这样就能方便地按需分配。
总算是写完了，不容易啊，这篇写的最久的一篇，希望对大家理解Kubernetes有帮助！共勉！