pod实际上有一个生命周期。当一个worker node死掉，那么在node上运行的pods也会丢失掉。这时候replicaset 将会动态的驱使集群在后台创建一个新的pods来回到原来所需要的状态来保证应用继续运行。例如一个镜像有三个replicas在运行。这些replicas是可以交换的。那么前端不应该去关心后台的replicas，即使有pods丢失了或者重新创建。在kubernates集群中每个pod都有一个独立的ip地址，即使是在同一个node中，所以需要一种自动的方式来协调pods之间的变化来使你的程序继续工作。
kubernates中的服务也是抽象的，用来定义逻辑上的一组pods和访问他们的策略。services可以降低pods之间依赖的耦合度。一个service就像其他的kubernates对象一样，用yaml或者json来定义。服务所针对的一系列pods是用labelselector来决定的。
虽然每个pod都会有一个独立的ip，但是如果没有service那么这些ip也不会暴露在集群之外。services允许你的应用接收traffic。通过指定不同的type来以不同的方式暴露service：
clusterIP（默认）：在集群内部的ip上暴露服务。这样服务只能在集群内部之间调用。
NodePort: 使用NAT在集群中每个选定节点的相同端口上公开服务.这样在集群外部使用<nodeip><nodeport>来访问服务。是clusterIp的超集。
LoadBalancer: 在当前云中创建外部负载平衡器（如果支持），并向服务分配固定的外部IP。nodeport的超集
externalName:通过返回具有名称的CNAME记录，使用任意名称（由规范中的externalName指定）公开服务.不使用代理。
service路由是跨越一组pods的。服务是一个抽象，它能在不影响你的应用情况下允许你的pod死亡或者复制。相互依赖的pods（比如在一个应用中的前台和后台组件）之间的路由和发现是通过kubernates services来处理的
service使用一组标签和选择器来匹配一组pods，一个分组原语允许对kubernates上的对象进行逻辑操作。label是赋值到对象上的键值对并未可以以多种方式进行引用。
为开发、测试和生产指定对象、嵌入版本标签、使用标记对对象进行分类
Labels can be attached to objects at creation time or later on. They can be modified at any time.
Running Multiple Instances of Your App
扩展部署将确保创建新的Pod，并将其调度到具有可用资源的node。扩展将增加pods的数量到新的需要的状态。kubernates也支持pods的自动扩展。扩展为0也是可以的，这样他会停止所有指定的deployment
运行一个应用的多个实例这也需要一种方式来分发需求到所有的实例上。services集成了负载均衡功能可以分发网络来传输到暴露的deployment的所有的pods上。services也会通过端口来持续监听正在运行的pods，以确保traffic能够发往可用的pods上。
Performing a Rolling Update
滚动升级允许开发者在不宕机的情况下增加一个新的pod实例。新的pods将会被nodes调度，拥有可用的资源。
在执行更新的时候不要影响程序的可用性，默认情况下，更新期间不可用的Pod的最大数量和可以创建的新Pod的最大数量为1这两个操作可以被配置成pods的数量或者百分比。在kubernates中更新是会被标记版本的，任何deployment的更新都可以回退到之前的版本。
就像扩展应用一样，如果deployment公开暴露了端口，在更新的时候service只会将访问负载均衡到可用的pod上。
滚动升级的行为：
将一个应用从一个环境移动到另一个环境。
回滚到之前的版本
持续集成分发应用。