# . Pod调度 在kubernetes系统中，Pod在大部分场景下都只是容器的载体而已，通常需要通过RC、Deployment、 DaemonSet、Job等对象完成Pod的调度和自动控制功能。 1）RC、Deployment：全自动调度 RC的主要功能之一就是自动部署一个容器应用的多份副本，以及继续监控副本的数量，在集群内始终维持用户指定的副本数量。 a）NodeSelector：定向调度 b）NodeAffinity：亲和性调度 2）DaemonSet：特定场景调度 DaemonSet是kubernetes1.2版本新增的一种资源对象，用于管理在集群中每个Node上仅运行一份Pod的副本实例。 DaemonSet的Pod调度策略与RC类似，除了使用系统内置的算法在每台Node上进行调度，也可以在Pod的定义中使用NodeSelector或NodeAffinity来指定满足条件的Node范围进行调度。 3）Job：批处理调度 kubernetes从1.2版本开始支持批处理类型的应用，我们可以通过kubernetes Job资源对象来定义并启动一个批处理任务。批处理任务通常并行启动多个计算进程去处理一批工作项，处理完成后，整个批处理任务结束。 按照批处理任务实现方式的不同，分为： Job Template Expansion模式 Queue with Pod Per Work Item模式 Queue with Variable Pod Count模式 kubernetes将Job分以下三种类型。 1）Non-parallel Jobs 2）Parallel Jobs with a fixed completion count 3）Parallel Jobs with a work queue # . Pod的扩容和缩容 在实际生产系统中，我们经常会遇到某个服务需要扩容的场景，也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。此时我们可以利用RC的Scale机制来完成这些工作。以redis-slave RC为例，已定义的最初副本数量为2，通过kubectl scale命令可以将redis-slave RC控制的Pod副本数量从初始的2更新为3： #kubectl scale rc redis-slave --replicas=3 将--replicas设置为比当前Pod副本数量更小的数字，系统将会“kill掉”一些运行中的容器，以实现应用集群缩容： #kubectl scale rc redis-slave --replicas=1 除了scale方式，还有一种Horizontal Pod Autoscaler(HPA）方式 # . Pod滚动升级 当集群中的某个服务需要升级时，我们需要停止目前与该服务相关的所有Pod，然后重新拉取镜像并启动，如果集群规模比较大，则这个工作就变成了一个挑战，而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。 滚动升级通过执行kubectl rolling-updata命令一键完成，该命令创建一个新的RC，然后自动控制就得RC中的Pod副本的数量逐渐减少到0，同时新的RC中的Pod副本的数量从0逐步增加到目标值，最终实现了Pod的升级。需要注意的是，系统要求新的RC需要与旧的RC在相同的命名空间（Namespace）内，不能吧别人的资产偷偷的转移到自家名下。 需要注意： （1）RC的名字不能与旧的RC名字相同 （2）在Selector中应至少有一个Label与旧的RC的label不同，以标示其为新的RC。 运行kubectl rolling-update redis-master -f redis-masterController-v2.yaml等所有新的Pod启动完成后，旧的Pod也被全部销毁，这样就完成了容器集群的更新工作。 另一种方法，不用配置文件，直接用kubectl rolling-update命令，加上--image参数指定新版镜像名称来完成Pod的滚动升级： #kubectl rolling-update redis-master --image=redis-master:2.0 更新后查看RC #kubectl get rc 如果在更新的过程中发现配置有误，用户可以中断更新操作，并通过执行kubectl rolling-update-rollback完成Pod版本的回滚： #kubectl rolling-update redis-master --image=kubeguide/redis-master:2.0 --rollback 就可以恢复到更新前的版本了。