1. 控制器
1.1 ReplicationController
ReplicationController会持续监控正在运⾏的pod列表，并保证相应“类型”的pod的数⽬与期望相符。如正在运⾏的pod太少，它会根据 pod模板创建新的副本。如正在运⾏的pod太多，它将删除多余的副本。
⼀个ReplicationController有三个主要部分
label selector（标签选择器），⽤于确定ReplicationController作⽤域中有哪些pod
replica count（副本个数），指定应运⾏的pod数量
pod template（pod模板），⽤于创建新的pod副本
注 意 pod 实 例 永 远 不 会 重 新 安 置 到 另 ⼀ 个 节 点 。 相 反 ，ReplicationController会创建⼀个全新的pod实例，它与正在替换的实例⽆关。
如果不是更改某个pod的标签⽽是修改了ReplicationController的标签选择器，你认为会发⽣什么？如果你的答案是“它会让所有的pod脱离ReplicationController的管理，导致它创建三个新的pod”，那么恭喜你，答对了。这表明你了解了 ReplicationController 的 ⼯ 作 ⽅ 式 。
- 修改pod模板
ReplicationController的pod模板可以随时修改。更改pod模板就像⽤⼀个曲奇⼑替换另⼀个。它只会影响你之后切出的曲奇，并且不会影响你已经剪切的曲奇。
1.2 ReplicaSet
ReplicaSet的类似资源。它是 新 ⼀ 代 的 ReplicationController ，从现在起，你应该始终创建ReplicaSet⽽不是ReplicationController。你通常不会直接创建它们，⽽是在创建更⾼层级的Deployment资源时⾃动创建它们。
ReplicaSet的⾏为与ReplicationController完全相同，但pod选择器的表达能⼒更强。
举个例⼦， 单个 ReplicationController ⽆ 法 将 pod 与 标 签env=production和env=devel同时匹配。它只能匹配带有env=devel标签的 pod或带有env=devel标签的pod。但是⼀个ReplicaSet可以匹配两组pod并将它们视为⼀个⼤组。
1.3 DaemonSet
DaemonSet在每个节点上只运⾏⼀个pod副本。
要在所有集群节点上运⾏⼀个pod，需要创建⼀个DaemonSet对象。DaemonSet确保创建⾜够的pod，并在⾃⼰的节点上部署每个pod。
尽管ReplicaSet（或ReplicationController）确保集群中存在期望数量的pod副本，但DaemonSet并没有期望的副本数的概念。它不需要，因为它的⼯作是确保⼀个pod匹配它的选择器并在每个节点上运⾏。
如果节点下线，DaemonSet不会在其他地⽅重新创建pod。但是，当将⼀个新节点添加到集群中时，DaemonSet会⽴刻部署⼀个新的pod实例。
1.4 Job
Kubernetes通过Job允许你运⾏⼀种pod，该pod在内部进程成功结束时，不重启容器。⼀旦任务完成，pod就被认为处于完成状态。
在发⽣节点故障时，该节点上由Job管理的pod将按照ReplicaSet的 pod的⽅式，重新安排到其他节点。如果进程本⾝异常退出（进程返回错误退出代码时），可以将Job配置为重新启动容器。
在⼀个pod的定义中，可以指定在容器中运⾏的进程结束时，Kubernetes会做什么。这是通过pod配置的属性restartPolicy完成的，默认为Always。
Job pod不能使⽤默认策略，因为它们不是要⽆限期地运⾏。因此，需要明确地将重启策略设置为OnFailure或Never。此设置防⽌容器在完成任务时重新启动。
Job可以配置为创建多个pod实例，并以并⾏或串⾏⽅式运⾏它们。
在pod配置中设置activeDeadlineSeconds属性，可以限制pod的时间。如果pod运⾏时间超过此时间，系统将尝试终⽌pod，并将Job标记为失败。
1.5 CronJob
在计划的时间内，CronJob资源会创建Job资源，然后Job创建pod。在正常情况下，CronJob总是为计划中配置的每个执⾏创建⼀个 Job，但可能会同时创建两个Job，或者根本没有创建。为了解决第⼀个问题，你的任务应该是幂等的（多次⽽不是⼀次运⾏不会得到不希望的结果）。对于第⼆个问题，请确保下⼀个任务运⾏完成本应该由上⼀次的（错过的）运⾏完成的任何⼯作。
2. 探测
Kubernetes有以下三种探测容器的机制：
- HTTP GET探针
对容器的IP地址（你指定的端⼜和路径）执⾏ HTTP GET请求。如果探测器收到响应，并且响应状态码不代表错误（换句话说，如果HTTP响应状态码是2xx或3xx），则认为探测成功。如果服务器返回错误响应状态码或者根本没有响应，那么探测就被认为是失败的，容器将被重新启动。
- TCP套接字探针
尝试与容器指定端口建⽴TCP连接。如果连接成功建⽴，则探测成功。否则，容器重新启动。
- Exec探针
在容器内执⾏任意命令，并检查命令的退出状态码。如果状态码是0，则探测成功。所有其他状态码都被认为失败。
2.1 存活探针
2.2 就绪探针
就绪探针将定期在容器内执⾏ls/var/ready命令。如果⽂件存在，则 ls命令返回退出码0，否则返回⾮零的退出码。如果⽂件存在，则就绪探针将成功；否则，它会失败。
务必定义就绪探针，需要强调。⾸先，如果没有将就绪探针添加到pod中，它们⼏乎会⽴即成为服务端点。如果应⽤程序需要很长时间才能开始监听传⼊连接，则在服务启动但尚未准备好接收传⼊连接时，客户端请求将被转发到该pod。因此，客户端会看到“连接被拒绝”类型的错误。
应该始终定义⼀个就绪探针，即使它只是向基准URL发送 HTTP请求⼀样简单。
