漫画：小黄人学 Kubernetes 对象

Kubernetes中是有很多积木（Building Blocks），比如object model，pod，rs，deployment，namespace之类，这些都是Kubernetes中很重要的东西，学习k8s，这些基础必须要掌握理解。

Kubernetes集群可以通过这个对象模型来表现出不同的持久化的整体，比如：

• 我们是在哪个node上运行哪个容器化的应用程序？

• 应用程序资源消耗

• 应用程序不同的策略

对于每个对象，我们用spec这个field声明我们期望的状态，Kubernetes会通过status这个field记录对象实际的状态并加以管理。随后，Kubernetes的controller manager会想办法让这个对象实际的状态和我们声明期望的状态相同。

我们一般用yaml格式文件来声明创建一个对象

在创建一个对象时，我们需要把spec这个field提供给API Server，这个field会描述我们期望的状态以及一些基础的信息，比如名称。

创建对象的API请求必须有spec这个field以及其它详细信息，并且需要是JSON的格式。当我们用yaml格式提供一个对象的声明后，kubectl会把这个声明转换成JSON格式，然后传给API Server。

1. piVersion: apps/v1beta1

2. kind: Deployment

3. metadata:

4.  name: nginx-deployment

5. spec:

6.    replicas: 3

7.  template:

8.    metadata:

9.      labels:

10.        app: nginx

11.    spec:

12.      containers:

13.             - name: nginx

14.        image: nginx:1.7.9

15.        ports:

16.        - containerPort: 80

以上就是配置文件声明的Deployment对象：

apiVersion指定了我们调用的api的endpoint；

通过kind field，我们指定了我们要创建的对象的类型；

通过metadata，我们给对象附加上了最基本的信息，比如名字；

你可能发现这里面有两个spec的field（spec和spec.template.spec），通过 spec，我们定义了我们对deployment的期望状态，在我们的例子中，我们想要确认，在任何时候，都有至少3个pod在运行。我们再在spec.template.spec里面定义我们要运行的每个pod都应该是什么状态，所以这就是为啥这里会有两个spec的原因。

一旦这个对象被创建了，kubernetes会直接给对象添加一个status的field，如下：

为什么先介绍Pod呢，因为Pod是Kubernetes中最小的一个对象，你要运行的应用程序（web app等）都要被包含在Pod中才能运行，其中一个Pod是一个或者多个容器的逻辑上的集合，通俗来讲，应用被制作成image镜像，镜像要运行在容器中，比如Docker容器，Pod中可以包涵多个运行的容器，所以在k8s上没有Pod，应用程序就没有家。

在Pod中的容器拥有以下的特性：

• 在同一个host上一起进行调度

• 共享同一个network namespace

• 挂载同样的external storage（volumes）

Pod并非一个持久化的东西，很有可能突然挂了，并且没有能力自我修复，这就是为啥我们把它们和controller一起用，这样可以来控制pod的replica，容错，自我修复等等。比较有名的例子比如Deployments，ReplicaSets等。我们通过把Pod的定义（specification，也就是spec）附加到别的对象（也就是之前用的template.spec）来完成。

由于Docker容器之间通信受到Docker网络机制限制，例如，一个应用需要多个容器组成，每个容器之间只需要Localhost通信，这时如果这些容器都在一个Pod中，Localhost通信就很方便实现了。这也是微服务流行起来原因了。

通过给对象打labels可以实现快速查找某个对象，例如，有了label你可以确定这个Pod就是MySql，或者这组全是小黄人呀。

Labels都是由键值对表示，

1. "labels": {

2.  "key1" : "value1",

3.  "key2" : "value2"

4. }

创建一个对象（如Pod）时可以直接给label，也可以在后期随时修改，所以Labels一般被用来组织和选择一些符合条件的对象。label不提供唯一性。

通过这个图片，我们可以看到我们用了两个label：app和env。基于我们的需求，我们可以给我们的pod不同的值。

当然是通过Label Selectors呢，通过Label Selectors，我们可以选择一系列的对象，Kubernetes支持两种Selector类型：

第一种：Equality-Based Selectors

顾名思义，这种selector通过 == 或者 != 来进行选择，比如我们选择一个 env==dev 的对象，就会找出所有有env label，并且值为dev的。

第二种：Set-Based Selectors

这种selector支持通过一系列的值来进行过滤，比如通过in, notin和exist。

举例：env in (dev, qa)

效率瞬间提高呢，在管理Pod对象上，还有其他高效方法吗？

当产品促销，业务处于高峰或低峰时，我们经常需要扩容或缩容，为了实现自动化，k8s增加相应处理对象。

像早期版本中的 ReplicationController，（RC）是master node上Controller Manager的一部分，主要作用是保证每个pod的replica都达到了预期值。不然的话会通过杀死或者新建pod的办法来达到。不过现在已经被ReplicaSet(RS)取代了。

Replica Set 是下一代的Replication Controller，好处在于同时支持equality 和 set based selector（rc只支持equality-based）。目前这是唯一的区别。

ReplicaSets可以独立使用，但它主要被 Deployments用作pod 机制的创建、删除和更新。当使用Deployment时，你不必担心创建pod的ReplicaSets，因为可以通过Deployment实现管理ReplicaSets。

Deployment提供了对于pod和rs的陈述性更新。DeploymentController是master node上Controller Manager的一部分，作用和Controller manager别的一样——确保当前的状态和期望的状态相同。

在下面这个例子中，我们的Deployment创建了一个 rs A，然后rs A又创建了3个pod，并且在每个pod中，都有一个跑了nginx:1.7.9镜像的容器。

接下来，在下一个Deployment中，我们修改了pod的template，把nginx从1.7.9升级到了1.9.1。因为我们升级了期望的状态，所以Deployment会创建一个新的RS B，这个过程被称为Deployment rollout：

当RS B创建完毕的时候，Deployment开始指向它：

在RS之上，Deployment提供了很多特性比如recording，通过这个特性，如果说更新出错，或者更新后的应用出了bug，我们可以rollback到原先的状态。

试想下如果我们有许多个用户，我们想把这些用户组织到不同的team或者project，该怎么办？

这时我们可以通过Kubernetes中的Namespace，它能把kubernetes集群分成好多个小集群。所有在Namespace中创建的resources/objects都是唯一的，不会跨命名空间，这样是不是很方便呢。

一般来说，k8s会有两个默认Namespace：kube-system和default。kube-system一般会用来放一些Kubernetes系统的组件，default会用来放一些属于其它Namespace的对象。我们默认情况下是会连接到default命名空间。kube-public是一个特殊的namespace，可以被所有的用户读，一般用于特殊情况比如初始化一个集群。

我们可以通过使用资源配额（Resource Quotas）来限制每个Namespace的资源。

今天我们介绍了k8s对象模型，以及pod labels Deployment这几个主要对象再Kubernetes中的用途、使用场景，后续咱们学习更多内容。

推荐阅读