diff --git a/.vuepress/config.js b/.vuepress/config.js
index 0ff2f0b..c3db7b7 100644
--- a/.vuepress/config.js
+++ b/.vuepress/config.js
@@ -185,6 +185,7 @@ module.exports = {
children: [
'k8s-intermediate/workload/pod',
'k8s-intermediate/workload/pod-lifecycle',
+ 'k8s-intermediate/workload/init-container',
]
},
'k8s-intermediate/config-map',
diff --git a/glossary/idempotent.md b/glossary/idempotent.md
new file mode 100644
index 0000000..4ccd4a9
--- /dev/null
+++ b/glossary/idempotent.md
@@ -0,0 +1,126 @@
+---
+description: 本文解析了幂等的概念
+---
+
+# 幂等
+
+
+
+本文转载自 [关于高并发和分布式中的幂等处理，你真的知道吗？](https://www.jianshu.com/p/cea3675a590b)
+
+
+
+#### **我们先来谈下幂等的概念**
+
+**抽象概念**
+
+> 幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
+
+在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数。
+
+用通俗的话讲：就是针对一个操作，不管做多少次，产生效果或返回的结果都是一样的
+
+**举几个例子：**
+
+1.比如前端对同一表单数据的重复提交，后台应该只会产生一个结果。
+
+2.比如我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱。
+
+3.比如发送消息，也应该只发一次，同样的短信如果多次发给用户，用户会崩溃。
+
+4.比如创建业务订单，一次业务请求只能创建一个，不能出现创建多个订单。
+
+还有很多诸如此类的，这些逻辑都需要幂等的特性来支持。
+
+
+
+#### **实现幂等性的技术方案**
+
+**查询操作**
+
+> 查询一次和查询多次，在数据不变的情况下，查询结果是一样的，select是天然的幂等操作。
+
+**删除操作**
+
+> 删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个)
+
+**唯一索引，防止新增脏数据**
+
+> 拿资金账户和用户账户来说，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，在新增的时候只有一个请求成功，剩下都会抛出唯一索引重复异常。比如`org.springframework.dao.DuplicateKeyException`，这时候再查询一次就可以了，数据存在，返回结果。
+
+**token机制，防止页面重复提交**
+
+> 要求：页面的数据只能被点击提交一次
+>
+> 发生原因：由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交
+>
+> 解决办法：
+>
+> 集群环境：采用token加redis
+>
+> 单JVM环境：采用token加redis或token加jvm内存
+>
+> 处理流程：
+>
+> 数据提交前要向服务的申请token，token放到redis或jvm内存，token有效时间
+>
+> 提交后后台校验token，同时删除token，生成新的token返回
+>
+> token特点：要申请，一次有效性，可以限流。
+
+注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，
+
+存在并发问题，不建议使用
+
+#### **悲观锁**
+
+获取数据的时候加锁获取 select * from table_xxx where id=’xxx’ for update;
+
+注意：id字段一定是主键或者唯一索引，不然是锁表，会出事的。悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用。
+
+#### **乐观锁**
+
+> 乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。乐观锁的实现方式多种多样可以通过version或者其他状态条件：
+>
+> 1.通过版本号实现 update table_xxx set name=#name#,version=version+1 where version=#version#
+>
+> 2.通过条件限制 update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0
+>
+> 要求：avai_amount-subAmount >=0
+>
+> 这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高。
+
+注意：乐观锁的更新操作，最好用主键或者唯一索引来更新，这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好。
+
+update table_xxx set name=#name#,version=version+1 where id=#id# and version=#version#
+
+update table_xxx set avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0
+
+#### **分布式锁**
+
+还是拿插入数据的例子，如果是分布是系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，其实就是为了控制多线程并发的操作，也是分布式系统中经常用到的解决思路。
+
+#### **select + insert**
+
+并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了。
+
+**注意****：**核心高并发流程不要用这种方法。
+
+#### **状态机幂等**
+
+在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机(状态变更图)，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。
+
+注意：订单等单据类业务，存在很长的状态流转，一定要深刻理解状态机，对业务系统设计能力提高有很大帮助。
+
+#### **对外提供接口的api如何保证幂等**
+
+如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)。
+
+**重点：**
+
+对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。
+
+#### **最后总结：**
+
+幂等性应该是合格程序员的一个基因，在设计系统时，是首要考虑的问题，尤其是在像第三方支付平台，银行，互联网金融公司等涉及的网上资金系统，既要高效，数据也要准确，所以不能出现多扣款，多打款等问题，这样会很难处理，并会大大降低用户体验。
+
diff --git a/learning/README.md b/learning/README.md
index 3cb0207..ae907bc 100644
--- a/learning/README.md
+++ b/learning/README.md
@@ -17,6 +17,8 @@ description: Kubernetes 学习路径推荐
* [通过互联网访问您的应用](/learning/k8s-intermediate/ingress.html)
* 工作负载
* [Pod 容器组](/learning/k8s-intermediate/workload/pod.html)
+ * [Pod 生命周期](/learning/k8s-intermediate/workload/pod-lifecycle.html)
+ * [Pod 初始化容器](/learning/k8s-intermediate/workload/init-container.html)
* [使用 ConfigMap 配置您的应用程序](/learning/k8s-intermediate/config-map.html)
* [使用私有 registry 中的 docker 镜像](/learning/k8s-intermediate/private-registry.html)
* 持久化数据
@@ -24,35 +26,14 @@ description: Kubernetes 学习路径推荐
* [存储卷 PV 和存储卷声明 PVC](/learning/k8s-intermediate/persistent/pv.html)
* [存储类 StorageClass](/learning/k8s-intermediate/persistent/storage-class.html)
-## **课程推荐**
+## **Kubernetes 实战**
-作者认为，基础比较好的同学，在学完 **Kubernetes 入门** 部分的内容后，就可以根据 Kubernetes 的官网文档和 docker 的官网文档，结合实际项目将 Kubernetes 应用得很好。同时，作者也在逐步完善 **Kubernetes 进阶** 的学习内容，更好的帮助大家在项目中落地 Kubernetes。但是鉴于时间和进度的原因，短期内仍然不能很好的通过 www.kuboard.cn 满足 Kubernetes 爱好者迫切的学习意愿。
+在 Kubernetes 上部署 Spring Cloud 微服务：
-在这种情况下，作者向大家推荐一份视频课程。该课程价格为 99 元，新注册用户享有 30 元现金优惠，也就是只需要 69 元 即可购买该套课程。
-点击此处购买 深入剖析Kubernetes ，或扫描图片中的二维码。
-
-
-
-
-
-
diff --git a/learning/k8s-intermediate/workload/init-container.assets/image-20190907171451988.png b/learning/k8s-intermediate/workload/init-container.assets/image-20190907171451988.png
new file mode 100644
index 0000000..59efeb1
Binary files /dev/null and b/learning/k8s-intermediate/workload/init-container.assets/image-20190907171451988.png differ
diff --git a/learning/k8s-intermediate/workload/init-container.md b/learning/k8s-intermediate/workload/init-container.md
new file mode 100644
index 0000000..134147f
--- /dev/null
+++ b/learning/k8s-intermediate/workload/init-container.md
@@ -0,0 +1,103 @@
+---
+description: 本文描述了 Kubernetes Pod 中的初始化容器的概念、使用场景和使用方法。初始化容器是容器组中 app 容器启动之前执行的容器。可能包含 setup 脚本，或其他工具进程
+---
+
+# Pod 初始化容器
+
+参考文档： Kubernetes 官网 [Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
+
+## 初始化容器介绍
+
+Pod 可以包含多个工作容器，也可以包含一个或多个初始化容器，初始化容器在工作容器启动之前执行。
+
+初始化容器与工作容器完全相同，除了如下几点：
+
+* 初始化容器总是运行并自动结束
+* kubelet 按顺序执行 Pod 中的初始化容器，前一个初始化容器成功结束后，下一个初始化容器才开始运行。所有的初始化容器成功执行后，才开始启动工作容器
+* 如果 Pod 的任意一个初始化容器执行失败，kubernetes 将反复重启该 Pod，直到初始化容器全部成功（除非 Pod 的 restartPolicy 被设定为 Never）
+* 初始化容器的 Resource request / limits 处理不同，请参考 [Resources](#Resources)
+* 初始化容器不支持 [就绪检查 readiness probe](/learning/k8s-intermediate/workload/pod-lifecycle.html#container-probes)，因为初始化容器必须在 Pod ready 之前运行并结束
+
+## 使用初始化容器
+
+初始化容器可以指定不同于工作容器的镜像，这使得初始化容器相较于直接在工作容器中编写启动相关的代码更有优势：
+
+* 初始化容器可以包含工作容器中没有的工具代码或者自定义代码。例如：您无需仅仅为了少量的 setup 工作（使用 sed, awk, python 或 dig 进行环境设定）而重新从一个基础镜像制作另外一个镜像
+* 初始化容器可以更安全地执行某些使工作容器变得不安全的代码
+* 应用程序的镜像构建者和部署者可以各自独立地工作，而无需一起构建一个镜像
+* 初始化容器相较于工作容器，可以以另外一个视角处理文件系统。例如，他们可以拥有访问 Secrets 的权限，而工作容器却不一定被授予该权限
+* 初始化容器在任何工作容器启动之前结束运行，这个特性使得我们可以阻止或者延迟工作容器的启动，直到某些前提条件得到满足。一旦前提条件满足，所有的工作容器将同时并行启动
+
+### Examples
+
+下面是一些使用初始化容器的例子：
+
+* 使用一行 shell 命令，等待某一个 Service 启动后再启动工作容器
+
+ ``` sh
+ for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
+ ```
+
+* 使用 Pod 的信息将其注册到某一个远程服务：
+
+ ``` sh
+ curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()'
+ ```
+
+* 等候一定时间再启动工作容器
+
+ ```sh
+ sleep 60
+ ```
+
+* 将 Git repository 克隆到一个数据卷
+* 根据某些参数，运行一个模板工具动态生成工作容器所需要的配置文件
+
+### 在 Kuboard 中使用初始化容器
+
+Kuboard 工作负载编辑器中支持定义初始化容器，如下图所示，左下角可 ***添加初始化容器*** 初始化容器按照添加的顺序显示在容器组中，且始终显示在工作容器的前面。
+
+
+
+
+## 初始化容器的行为
+
+* Pod 的启动时，首先初始化网络和数据卷，然后按顺序执行每一个初始化容器。任何一个初始化容器都必须成功退出，才能开始下一个初始化容器。如果某一个容器启动失败或者执行失败，kubelet 将根据 Pod 的 restartPolicy 决定是否重新启动 Pod。
+* 只有所有的初始化容器全都执行成功，Pod 才能进入 ready 状态。初始化容器的端口是不能够通过 kubernetes Service 访问的。Pod 在初始化过程中处于 Pending 状态，并且同时有一个 type 为 `initializing` status 为 `True` 的 [Condition](./pod-lifecycle.html#pod-conditions)
+* 如果 Pod 重启，所有的初始化容器也将被重新执行。
+* 您可以重启、重试、重新执行初始化容器，因此初始化容器中的代码必须是 **幂等** 的。具体来说，向 emptyDir 写入文件内容的代码应该考虑到该文件已经存在的情况。请参考 [幂等](/glossary/idempotent.html) 获得更多信息
+* 您可以组合使用就绪检查和 activeDeadlineSeconds ，以防止初始化容器始终失败。
+* Pod 中不能包含两个同名的容器（初始化容器和工作容器也不能同名）。
+
+
+### Resources
+
+在确定初始化容器的执行顺序以后，以下 resource 使用规则将适用：
+
+* 所有初始化容器中最高的 resource request/limit 是最终生效的 request/limit
+* 对于 Pod 来说，最终生效的 resource request/limit 是如下几个当中较高的一个：
+ * 所有工作容器某一个 resource request/limit 的和
+ * 最终生效的初始化容器的 request/limit 的和
+* Kubelet 依据最终生效的 request/limit 执行调度，这意味着，在执行初始化容器时，就已经为 Pod 申请了其资源需求
+
+
+
+### Pod 重启的原因
+
+Pod 重启时，所有的初始化容器都会重新执行，Pod 重启的原因可能有：
+
+* 用户更新了 Pod 的定义，并改变了初始化容器的镜像
+ * 改变任何一个初始化容器的镜像，将导致整个 Pod 重启
+ * 改变工作容器的镜像，将只重启该工作容器，而不重启 Pod
+* Pod 容器基础设施被重启（例如 docker engine），这种情况不常见，通常只有 node 节点的 root 用户才可以执行此操作
+* Pod 中所有容器都已经结束，restartPolicy 是 Always，且初始化容器执行的记录已经被垃圾回收，此时将重启整个 Pod
\ No newline at end of file
diff --git a/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907122721669.png b/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907122721669.png
new file mode 100644
index 0000000..4cf37a2
Binary files /dev/null and b/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907122721669.png differ
diff --git a/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907141952059.png b/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907141952059.png
new file mode 100644
index 0000000..746b213
Binary files /dev/null and b/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907141952059.png differ
diff --git a/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907143026772.png b/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907143026772.png
new file mode 100644
index 0000000..ef1ca2b
Binary files /dev/null and b/learning/k8s-intermediate/workload/pod-lifecycle.assets/image-20190907143026772.png differ
diff --git a/learning/k8s-intermediate/workload/pod-lifecycle.md b/learning/k8s-intermediate/workload/pod-lifecycle.md
index 7c1479c..c1daf19 100644
--- a/learning/k8s-intermediate/workload/pod-lifecycle.md
+++ b/learning/k8s-intermediate/workload/pod-lifecycle.md
@@ -1,9 +1,133 @@
---
-description: Pod 容器组的生命周期
+description: 本文描述了 Kubernetes 中 Pod 容器组的生命周期
---
# Pod 生命周期
参考文档： Kubernetes 官网文档 [Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)
-进行中...
+[[TOC]]
+
+## Pod phase
+
+Pod phase 代表其所处生命周期的阶段。Pod phase 并不是用来代表其容器的状态，也不是一个严格的状态机。
+
+phase 的可能取值有：
+
+| Phase | 描述 |
+| ------------ | ------------------------------------------------------------ |
+| Pending | Kubernetes 已经创建并确认该 Pod。此时可能有两种情况：Pod 还未完成调度（例如没有合适的节点）正在从 docker registry 下载镜像 |
+| Running | 该 Pod 已经被绑定到一个节点，并且该 Pod 所有的容器都已经成功创建。其中至少有一个容器正在运行，或者正在启动/重启 |
+| Succeeded | Pod 中的所有容器都已经成功终止，并且不会再被重启 |
+| Failed | Pod 中的所有容器都已经终止，至少一个容器终止于失败状态：容器的进程退出码不是 0，或者被系统 kill |
+| Unknown | 因为某些未知原因，不能确定 Pod 的状态，通常的原因是 master 与 Pod 所在节点之间的通信故障 |
+
+## Pod conditions
+
+每一个 Pod 都有一个数组描述其是否达到某些指定的条件。Pod condition 数组在 Kuboard 中的显示如下图所示：
+
+
+
+该数组的每一行可能有六个字段：
+
+| 字段名 | 描述 |
+| ---------------------------------------------------------- | ------------------------------------------------------------ |
+| type | type 是最重要的字段，可能的取值有：**PodScheduled：** Pod 已被调度到一个节点**Ready：** Pod 已经可以接受服务请求，应该被添加到所匹配 Service 的负载均衡的资源池**Initialized：**Pod 中所有初始化容器已成功执行**Unschedulable：**不能调度该 Pod（缺少资源或者其他限制）**ContainersReady：**Pod 中所有容器都已就绪 |
+| status | 能的取值有：TrueFalseUnknown |
+| reason | Condition 发生变化的原因，使用一个符合驼峰规则的英文单词描述 |
+| message | Condition 发生变化的原因的详细描述，human-readable |
+| lastTransitionTime | Condition 发生变化的时间戳 |
+| lastProbeTime | 上一次针对 Pod 做健康检查/就绪检查的时间戳 |
+
+
+## Container probes
+
+Probe 是指 kubelet 周期性地探测容器的状况。有三种类型的 Probe：
+
+* **ExecAction：** 在容器内执行一个指定的命令。如果该命令的退出状态码为 0，则成功
+* **TCPSocketAction：** 探测容器的指定 TCP 端口，如果该端口处于 open 状态，则成功
+* **HTTPGetAction：** 探测容器指定端口/路径上的 HTTP Get 请求，如果 HTTP 响应状态码在 200 到 400（不包含400）之间，则成功
+
+Probe 有三种可能的结果：
+
+* **Success：** 容器通过检测
+* **Failure：** 容器未通过检测
+* **Unknown：** 检测执行失败，此时 kubelet 不做任何处理
+
+Kubelet 可以在两种情况下对运行中的容器执行 Probe：
+
+* **就绪检查 readinessProbe：** 确定容器是否已经就绪并接收服务请求。如果就绪检查失败，kubernetes 将该 Pod 的 IP 地址从所有匹配的 Service 的资源池中移除掉。
+* **健康检查 livenessProbe：** 确定容器是否正在运行。如果健康检查失败，kubelete 将结束该容器，并根据 restart policy（重启策略）确定是否重启该容器。
+
+### 何时使用 健康检查/就绪检查？
+
+* 如果容器中的进程在碰到问题时可以自己 crash，您并不需要执行健康检查；kubelet 可以自动的根据 Pod 的 restart policy（重启策略）执行对应的动作
+
+* 如果您希望在容器的进程无响应后，将容器 kill 掉并重启，则指定一个健康检查 liveness probe，并同时指定 restart policy（重启策略）为 Always 或者 OnFailure
+
+* 如果您想在探测 Pod 确实就绪之后才向其分发服务请求，请指定一个就绪检查 readiness probe。此时，就绪检查的内容可能和健康检查相同。就绪检查适合如下几类容器：
+ * 初始化时需要加载大量的数据、配置文件
+ * 启动时需要执行迁移任务
+ * 其他
+
+::: tip
+如果您想在删除 Pod 前停止向其分发服务请求，您无需为此而指定就绪检查。在删除 Pod 时，kubelete 自动将 Pod 置于 unready 状态，并等待其中的容器停止。
+:::
+
+### Kuboard 中配置健康检查/就绪检查
+
+Kuboard 可以在工作负载编辑器中配置健康检查/就绪检查，界面如下所示：
+
+
+
+
+
+## Container States
+
+一旦 Pod 被调度到节点上，kubelet 便开始使用容器引擎（通常是 docker）创建容器。容器有三种可能的状态：Waiting / Running / Terminated：
+
+* **Waiting：** 容器的初始状态。处于 Waiting 状态的容器，仍然有对应的操作在执行，例如：拉取镜像、应用 Secrets等。
+* **Running：** 容器处于正常运行的状态。容器进入 Running 状态之后，如果指定了 postStart hook，该钩子将被执行。
+* **Terminated：** 容器处于结束运行的状态。容器进入 Terminated 状态之前，如果指定了 preStop hook，该钩子将被执行。
+
+在 Kuboard 的工作负载查看界面中可查看到容器的状态如下图所示：
+
+
+
+
+
+## Restart policy
+
+定义 Pod 或工作负载时，可以指定 restartPolicy，可选的值有：
+
+* Always （默认值）
+* OnFailure
+* Never
+
+restartPolicy 将作用于 Pod 中的所有容器。kubelete 将在五分钟内，按照递延的时间间隔（10s, 20s, 40s ......）尝试重启已退出的容器，并在十分钟后再次启动这个循环，直到容器成功启动，或者 Pod 被删除。
+
+
+## Pod lifetime
+
+通常，如果没有人或者控制器删除 Pod，Pod 不会自己消失。只有一种例外，那就是 Pod 处于 Scucceeded 或 Failed 的 phase，并超过了垃圾回收的时长（在 kubernetes master 中通过 terminated-pod-gc-threshold 参数指定），kubelet 自动将其删除。
+
+
diff --git a/overview/README.md b/overview/README.md
index 879fa16..30e70da 100644
--- a/overview/README.md
+++ b/overview/README.md
@@ -126,40 +126,14 @@ Kuboard 为 Kubernetes 初学者设计了如下学习路径：
* [通过互联网访问您的应用](/learning/k8s-intermediate/ingress.html)
* 工作负载
* [Pod 容器组](/learning/k8s-intermediate/workload/pod.html)
+ * [Pod 生命周期](/learning/k8s-intermediate/workload/pod-lifecycle.html)
+ * [Pod 初始化容器](/learning/k8s-intermediate/workload/init-container.html)
* [使用 ConfigMap 配置您的应用程序](/learning/k8s-intermediate/config-map.html)
* [使用私有 Registry 中的 docker 镜像](/learning/k8s-intermediate/private-registry.md)
* 持久化数据
* [数据卷 Volume](/learning/k8s-intermediate/persistent/volume.html)
* [存储卷 PV 和存储卷声明 PVC](/learning/k8s-intermediate/persistent/pv.html)
* [存储类 StorageClass](/learning/k8s-intermediate/persistent/storage-class.html)
- * 进阶路线一
- * 在实际项目中锻炼，完成各种与微服务、容器化、Kubernetes更多高级功能的学习、理解和应用
- * **适合人群：** 身边有人带路，并且技术功底比较强的人，能够自行翻阅大量 docker / kubernetes 的官网英文资料。这些人在完成上面的 Kubernetes 入门教程之后，基本上可以在项目中开始实战了。
- * 进阶路线二
- * 购买一套口碑比较好的视频课程，例如 深入剖析Kubernetes ，由 Kubernetes 社区资深成员与项目维护者 张磊 创作，价钱也仅相当于两杯咖啡的样子。
- * **适合人群：** 技术功底相对薄弱，想要多学习一些理论，在理解 docker / kubernetes 等官网英文资料存在一定困难的人群
-
-
### Kubernetes 有经验者
diff --git a/overview/change-log-on-the-way.md b/overview/change-log-on-the-way.md
index ff607db..068ab6e 100644
--- a/overview/change-log-on-the-way.md
+++ b/overview/change-log-on-the-way.md
@@ -5,4 +5,7 @@
* 存储卷声明去掉分配模式的字段
* 存储卷声明增加 Volume Modes 字段
* 存储卷声明将 读写模式 修改为 Access Modes
-* graceful period
+* 删除容器组时 - graceful period
+* Pod Conditions: lastProbeTime/reason/message
+* Pod restartPolicy
+* 初始化容器不支持就绪检查