initialization 剖析
1.配置需要 initialization 的资源类型 ：
InitializerConfiguration（https://kubernetes.io/docs/admin/extensible-admission-controllers/#configure-initializers-on-the-fly） 对象允许你配置被 initializers 分配到的资源类型。
举个例子来说，你可以进行创建，将“myproxy”initializer 添加到类型apps/v1beta1.Deployment 和 v1.DeamonSet 对象中。你可以尽可能多地创建 InitializerConfigurations，它们将适用于所有命名空间 。
2.API 服务器将为新资源分配 initializers：
当你向 apiserver 提交 Deployment 对象时，将更新 Deployment 的metadata.initalizers.pending 并在其中添加“myproxy”值。此字段显示当前分配给资源的initializers 。
准确的说，不是由 apiserver 添加 initializers。有一个名为“Initializer”的准入控制插件，这使整个 initialization 流程成为可能。它通过将 –admission-controller=Initializer 标志添加到 kube-apiserver 来进行启用 。
3.可以编写一个控制器来检测资源情况：
你开发并部署到集群的自定义控制器使用Watch API 来对新的资源进行监听，捕获并进行所需的修改。
4.等待修改资源的轮次：
一旦你的控制器通过 Watch API 拦截一个对象，它只能修改对象，如果它在初始化器列表（metadata.initializers.pending[0]）的第一个元素上检查到它的名字的话。否则，这意味着它是一些其他 initializers 修改资源的轮次，而现在应该跳过修改。
5.完成修改, 生成下一个 initializer。
完成对资源的修改后, 控制器应从对象的 metadata.initializers.pending 列表中删除其名称, 并将该对象保存回 API 服务器。
6.不存在更多 initializers 时, 资源准备好进行实现：
当 Kubernetes API 服务器检测到该对象没有其他挂起的 initializers 时, 它会判定对象 “已initialized”。Kubernetes 调度程序和其他控制器可以检测到完全 initialized 的对象并加以利用。
您可以同时在群集上运行多个 initializers。这些自定义控制器中的每一个都将收到有关对资源 (如 Pods) 的修改的通知, 但他们会等待轮次来对对象进行修改，直到他们在列表中检测他们的名字。
Initializers：在 Kubernetes API 中进行实现
在不知道它们实际上是如何在 Kubernetes API 服务器之下实现的情况下，你可以对 initializers 进行开发和部署 。我们来详细讨论一下它是如何在 Kubernetes API 中进行实现的：
简而言之, 当一个 Pod 资源提交到 API 并被分配一个待定的 initializers 列表时, 直到 initialization 完成，它实际上都不会被安排。Kubernetes 调度程序, 这个所谓的调度程序其实是另一个控制器，检测在 API 服务器中显示的 pod，并分配给每个节点。
那么, 为什么调度程序和其他控制器在初始化之前无法看到该对象, 即使该对象保存在 API 服务器 （和预计数据库中）, 并且对某些其他控制器 （即 initializers）可见？
答案是存在一个叫 includeUninitialized 的请求参数。此参数默认为 false, 因此, API 将未初始化的对象从默认客户端（如 kubectl）和控制器 (如调度程序) 隐藏在 “监视” 或 “列表” 之类的请求中。所以你开发的 initializers 必须设置 includeUninitialized = true 查询参数才能监测这些对象。
Initializers 阻止创建请求。当创建对象的请求提交到 API 服务器时, 它不会马上返回, 并且请求会一直被阻止, 直到 initialization 完成。如果使用的是 kubectl, 并且对象在 uninitialized 状态下被阻止, 你会在30秒后发现 kubectl 超时。
