hualinux 进阶 1.12： 控制器模型

目录

一、什么是控制器

 1.1 控制器概念

1.2 pod模板

1.3 通过一个例子理解控制器

二、控制器使用场景简单说明

2.1 守护进程型

2.2 非守护进程型

---

上一篇k8s全景图，有一技术，我们只讲了pod，现在继续讲其它，本篇主要是讲 控制器和模板

 

一、什么是控制器

 1.1 控制器概念

根据k8s官方文档对控制器的解说如下：

控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。 例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。

包含一个或多个 Pod 的控制器一些示例包括：

• Deployment
• StatefulSet
• DaemonSet

控制器通常使用您提供的 Pod 模板来创建它所负责的 Pod。

1.2 pod模板

Pod 模板是包含在其他对象中的 Pod 规范，例如 Replication Controllers、 Jobs 和 DaemonSets。 控制器使用 Pod 模板来制作实际使用的 Pod。 下面的示例是一个简单的 Pod 清单，它包含一个打印消息的容器。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Pod 模板就像饼干切割器，而不是指定所有副本的当前期望状态。 一旦饼干被切掉，饼干就与切割器没有关系。 没有“量子纠缠”。 随后对模板的更改或甚至切换到新的模板对已经创建的 Pod 没有直接影响。 类似地，由副本控制器创建的 Pod 随后可以被直接更新。 这与 Pod 形成有意的对比，Pod 指定了属于 Pod 的所有容器的当前期望状态。 这种方法从根本上简化了系统语义，增加了原语的灵活性。

1.3 通过一个例子理解控制器

上面说的都是很官方的东西，用通俗的的说法就是

使用一种 API 对象（Deployment）管理另一种 API 对象（Pod）的方法，在 Kubernetes 中，叫作“控制器”模式（controller pattern）。

上面讲的还是比较没概念，那么我通过 Deployment 例子来说明，如下图：

类似 Deployment 这样的一个控制器，实际上都是由上半部分的控制器定义（包括期望状态），加上下半部分的被控制对象的模板组成的。

这就是为什么，在所有 API 对象的 Metadata 里，都有一个字段叫作 ownerReference，用于保存当前这个 API 对象的拥有者（Owner）的信息。

从上面中明白了什么是一个对象管理另一个对象了吧

这就是一个我们常用的 nginx-deployment，它定义的 Pod 副本个数是 3（spec.replicas=3）

具体的实现上，这个 Deployment，与 ReplicaSet，以及 Pod 的关系是怎样的呢？我们可以用一张图把它描述出来：

这样完全理解上面那句话了吧。

 

二、控制器使用场景简单说明

2.1 守护进程型

1 )无状态应用:非系统级应用
应用场景:常见的http服务器: nginx、apache
推荐控制器: Deployment

2)无状态应用:系统级应用
应用场景:日志和监控收集的客户端，特点就是每个node节点需要且只需要运行1个pod客户端
推荐控制器: DaemonSet

3)有状态应用
应用场景:数据库、消息队列等:如mysq1、redis 集群
推荐控制器: StatefulSet

2.2 非守护进程型

Job控制器:用于-次性任务
Cronjob控制器:用于定时任务