Liveness 探测让用户可以自定义判断容器是否健康的条件。如果探测失败，Kubernetes 就会重启容器。 还是举例说明，创建如下 Pod： 启动进程首先创建文件 /tmp/healthy，30 秒后删除，在我们的设定中，如果 /tmp/healthy 文件存在，则认为容器处于正常状态，反正则发生故障。 livenessProbe 部分定义如何执行 Liveness 探测： 探测的方法是：通过

强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性。自愈的默认实现方式是自动重启发生故障的容器。除此之外，用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查，进而实现如下需求： 零停机部署。 避免部署无效的镜像。 更加安全的滚动升级。 下面通过实践学习 Kubernetes 的 Health Check 功能。 默认的健康检查 我们首先学习

kubectl apply 每次更新应用时 Kubernetes 都会记录下当前的配置，保存为一个 revision（版次），这样就可以回滚到某个特定 revision。 默认配置下，Kubernetes 只会保留最近的几个 revision，可以在 Deployment 配置文件中通过 revisionHistoryLimit 属性增加 revision 数量。 下面实践回滚功能。应用有如下三个配置文件

滚动更新是一次只更新一小部分副本，成功后，再更新更多的副本，最终完成所有副本的更新。滚动更新的最大的好处是零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。 实践 下面我们部署三副本应用，初始镜像为 httpd:2.2.31，然后将其更新到 httpd:2.2.32。 httpd:2.2.31 的配置文件如下： 通过 kubectl apply 部署。 部署过程如下： 创建 Deployment

除了 Cluster 内部可以访问 Service，很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service，默认是 ClusterIP。 ClusterIP Service 通过 Cluster 内部的 IP 对外提供服务，只有 Cluster 内的节点和 Pod 可访问，这是默认的 Service 类型，前面实验中的 Service

在 Cluster 中，除了可以通过 Cluster IP 访问 Service，Kubernetes 还提供了更为方便的 DNS 访问。 kubeadm 部署时会默认安装 kube-dns 组件。 kube-dns 是一个 DNS 服务器。每当有新的 Service 被创建，kube-dns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 可以通过

Service deCluster IP 是一个虚拟 IP，是由 Kubernetes 节点上的 iptables 规则管理的。 可以通过 iptables-save 命令打印出当前节点的 iptables 规则，因为输出较多，这里只截取与 httpd-svc Cluster IP 10.99.229.179 相关的信息： 这两条规则的含义是： 如果 Cluster 内的 Pod（源地址来自

我们不应该期望 Kubernetes Pod 是健壮的，而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。 每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP

Linux 中有 cron 程序定时执行任务，Kubernetes 的 CronJob 提供了类似的功能，可以定时执行 Job。CronJob 配置文件示例如下： ① batch/v2alpha1 是当前 CronJob 的 apiVersion。 ② 指明当前资源的类型为 CronJob。 ③ schedule 指定什么时候运行 Job，其格式与 Linux cron 一致。这里 */1 * *

有时，我们希望能同时运行多个 Pod，提高 Job 的执行效率。这个可以通过 parallelism 设置。 这里我们将并行的 Pod 数量设置为 2，实践一下： Job 一共启动了两个 Pod，而且 AGE 相同，可见是并行运行的。 我们还可以通过 completions 设置 Job 成功完成 Pod 的总数： 上面配置的含义是：每次运行两个 Pod，直到总共有 6 个 Pod 成功完成。实践一下：

上一节是 Job 执行成功的情况，如果失败了会怎么样呢？ 修改 myjob.yml，故意引入一个错误： 先删除之前的 Job： 如果将 restartPolicy 设置为 OnFailure 会怎么样？下面我们实践一下，修改 myjob.yml 后重新启动。 运行新的 Job 并查看状态： 当前 SUCCESSFUL 的 Pod 数量为 0，查看 Pod 的状态： 可以看到有多个

容器按照持续运行的时间可分为两类：服务类容器和工作类容器。 服务类容器通常持续提供服务，需要一直运行，比如 http server，daemon 等。工作类容器则是一次性任务，比如批处理程序，完成后容器就退出。 Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都用于管理服务类容器；对于工作类容器，我们用 Job。 先看一个简单的 Job 配置文件 myjob.yml：

本节以 Prometheus Node Exporter 为例演示如何运行自己的 DaemonSet。 Prometheus 是流行的系统监控方案，Node Exporter 是 Prometheus 的 agent，以 Daemon 的形式运行在每个被监控节点上。 如果是直接在 Docker 中运行 Node Exporter 容器，命令为： docker run -d \ -v

本节详细分析两个 k8s 自己的 DaemonSet：kube-flannel-ds 和 kube-proxy 。 kube-flannel-ds 下面我们通过分析 kube-flannel-ds 来学习 DaemonSet。 还记得之前是如何部署 flannel 网络的吗？我们执行了如下两个命令： kubectl apply -f flannel 的 DaemonSet 就定义在 kube-flannel.yml

Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本。DaemonSet 的不同之处在于：每个 Node 上最多只能运行一个副本。 DaemonSet 的典型应用场景有： 在集群的每个节点上运行存储 Daemon，比如 glusterd 或 ceph。 在每个节点上运行日志收集 Daemon，比如 flunentd 或 logstash。 在每个节点上运行监控

默认配置下，Scheduler 会将 Pod 调度到所有可用的 Node。不过有些情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。 Kubernetes 是通过 label 来实现这个功能的。 label 是 key-value 对，各种资源都可以设置

接上节，现在模拟 k8s-node2 故障，关闭该节点。 等待一段时间，Kubernetes 会检查到 k8s-node2 不可用，将 k8s-node2 上的 Pod 标记为 Unknown 状态，并在 k8s-node1 上新创建两个 Pod，维持总副本数为 3。 当 k8s-node2 恢复后，Unknown 的 Pod 会被删除，不过已经运行的 Pod 不会重新调度回 k8s-node2。

伸缩是指在线增加或减少 Pod 的副本数。 Deployment nginx-deployment 初始是两个副本。 k8s-node1 和 k8s-node2 上各跑了一个副本。现在修改 nginx.yml，将副本改成 5 个。 再次执行 kubectl apply： 三个新副本被创建并调度到 k8s-node1 和 k8s-node2 上。 出于安全考虑，默认配置下 Kubernetes 不会将

既然要用 YAML 配置文件部署应用，现在就很有必要了解一下 Deployment 的配置格式，其他 Controller（比如 DaemonSet）非常类似。 还是以 nginx-deployment 为例，配置文件如下图所示： ① apiVersion 是当前配置格式的版本。 ② kind 是要创建的资源类型，这里是 Deployment。 ③ metadata 是该资源的元数据，name 是必需的元数据项。

命令 vs 配置文件 Kubernetes 支持两种方式创建资源： 用 kubectl 命令直接创建，比如： kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2 在命令行中通过参数指定资源的属性。 通过配置文件和 kubectl apply 创建，要完成前面同样的工作，可执行命令： kubectl apply -f nginx.yml