kubernetes调度基础

一 、RC 和 RS

1. Replication Controller

Replication Controller，简称 RC，复制控制器，可确保 Pod 副本数达到期望值，也就是 RC 可确保一个 Pod 总 是可用，或一组 Pod 的数量永远处于一个定值。

如果存在的 Pod 大于设定的期望值，RC 会终止额外的 Pod。反之，当 Pod 数量小于期望值时，RC 将启动更多 的 Pod 来保证达到该期望值。

与手动创建 Pod 不同，使用 RC 控制的 Pod，在失败、 删除或终止时会自动替换为正常运行的 Pod，因此，为 达到高可用的效果，即使应用程序只需要一个 Pod，也 应该使用 RC 或其他控制器的方式管理。

RC 类似于进程管理监控程序，监视多个节点上的多个 Pod。

（1）定义 Replication Controller

（2）测试 Pod 数量控制

2. ReplicaSet

ReplicaSet，简称 RS，在 Kubernetes v1.2 版本，由旧 的 Replication Controller 升级而来。与 RC 的主要区别 在于，RS 支持基于集合的 Label Selector (标签选择器) 功能。

RS 主要作用于 Deployment 协调创建、删除和更新 Pod，在实际应用中，虽然 ReplicaSet 可以单独使用， 但一般建议使用 Deployment 来自动管理 ReplicaSet， 除非自定义的 Pod 不需要更新或有其他编排等。

RS 比 RC 具有更强大的功能及灵活性，所以如果只有这 两种选择，建议选择 RS。

定义一个 ReplicaSet 的示例：

二、无状态和有状态应用 特性

1. 无状态应用

无状态应用：不将数据或应用状态存储到集群或永久性 存储空间的应用。

常见的无状态应用包括 Web 服务器、负载均衡器、静态 文件服务器等。

无状态应用特点：

易于扩展：由于无状态应用不保存请求状态，因此可 以轻松地将它们部署在多个服务器上，从而实现水平 扩展。

高可用性：由于无状态应用的每个请求都是独立的， 因此即使某个请求失败，也不会影响其他请求的处 理。这有助于提高应用的可用性。

安全性：无状态应用通常不保存敏感数据，因此不太 可能泄露敏感信息。

可替代性：由于无状态应用不保存请求状态，因此不 同的服务器可以处理相同的请求，这意味着任何一个 服务器都可以替代其他服务器来处理请求。 以 web 服务器为例：客户端的每次请求必须具备自描述 信息，通过这些信息识别客户端身份，服务端不会保存 任何客户端请求者信息。

2. 有状态应用

有状态应用：应用程序的处理需要依赖特定的状态或数 据存储。

“有状态应用”的例子有很多，比如 Redis、MySQL 这样 的数据库，它们的“状态”就是在内存或者磁盘上产生的数 据，是应用的核心价值所在，如果不能够把这些数据及 时保存再恢复，那绝对会是灾难性的后果。

有状态应用特点：

依赖状态：应用程序的处理依赖于特定的状态信息。

数据持久化：有状态应用通常需要将状态数据持久化 存储，以便后续请求可以访问和使用。

有序性：由于有状态应用处理请求时依赖先前的状 态，因此请求之间的顺序可能很重要。

三、Deployment 无状 态应用

在 Kubernetes 中，Deployment 是最常用的 Pod 控制 器，一般用于部署企业内部的无状态服务(微服务居多)， 可利用 Deployment 的高级功能做到无缝迁移、自动扩 缩容、自动容灾、一键回滚等功能。

1. 创建 Deployment

2. 修改生成的 Deploy 文件

3. 测试副本数量控制机制

删除一个 deployment 的 pod

再查看 pod 资源列表

4. 更新 Deployment

更新当前 Deployment 的 Nginx Pod 的底层镜像模板， 并使用 --record 记录当前更改的参数，方便后期回滚更 新。

也可使用 “kubectl edit deployments.apps nginx”命令 对 deployment 资源编辑再更新，后面的 nginx 为 deployment 资源名。

注意: 当且仅当 Deployment 的 Pod 模板 (即.spec.template) 更改时，才会触发，Deployment更 新，例如更改内存、CPU 配置或者容器的 image。