2.7.2　Hooks与Release生命周期的关系

Hooks允许开发者在Release的一些生命周期中执行特定的动作，比如helm install，默认情况下，这个Release的生命周期如下。

·用户运行helm install foo命令。

·Chart被发送到Tiller。

·yaml模板编写规范校验过后，Tiller渲染foo模板。

·Tiller将渲染后的资源提交到Kubernetes集群中。

·Tiller返回执行结果和Release名称给客户端。

·退出客户端。

Helm给install命令定制了两种Hooks：pre-install和post-install。如果foo这个Chart实现了这两个Hooks，则它的生命周期如下所示。

·用户运行helm install foo命令。

·Chart被发送到Tiller。

·一些校验过后，Tiller渲染foo模板。

·Tiller准备执行pre-install hooks（同时加载Hooks资源到Kubernetes集群中）。

·Tiller根据权重对Hooks（默认权重为0）排序，若权重相同，则根据名称排序。

·Tiller加载Hooks需要的资源。

·Tiller等待Hooks返回Ready。

·Tiller提交剩余的资源到Kubernetes集群中。

·Tiller运行post-install hooks。

·Tiller等待Hooks返回Ready。

·Tiller返回执行结果和Release名称给客户端。

·退出客户端。

Tiller等待Hooks返回Ready是什么意思呢？针对不同的Hooks类型有不同的检查方式，如果这个资源是一个Job类型，Tiller就会一直等待Job成功运行到completion状态。如果这个Job运行失败了，那么Release也会失败。这是一个同步作业，当Job正在运行时，Helm会一直阻塞等待。

对于其他类型的资源，只要Kubernetes集群标志该资源已经加载完毕，Tiller就认为它是Ready的。当在Hooks中声明了很多资源的时候，它们会按串行的顺序执行，如果它们之间设置了权限，那么它们会按权限高低排序后再按序执行。如果资源对按序执行有强依赖性，则非常建议通过权重的形式来标明，不要依赖名称排序。

Hooks创建的资源并不归Release管理。一旦Tiller检测到Hooks达到了Ready状态，后面就不会再管理这个资源了。这意味着用户一旦在Hooks中创建了资源，就不能依赖helm delete删除对应的资源。如果想删除这些资源，用户就需要编写一个pre-delete，post-delete hook命令来删除。