Q: healthcheck 是否等待 after_start 退出后再进行验证?
A: after_start 不是用于 healthcheck 这个目的的，主要是有些业务需要数据预热等需求，成功失败与否都会通过日志反馈出来。对于 healthcheck 而言，它是针对于单个容器状态进行检测，如果有使用类似于 ELB 一样的 proxy 则会通过这个状态来判断是否进行动态切流。
Q: after_start 是否有退出状态验证?
A: after_start 的成功与否都会在日志中表现出来，可以参考这里，当然了如果有强制需要 after_start ，那么这里可以增加容器回收流程。
Q: healthcheck 是否允许脚本方法判断而非固定使用 HTTP. 比如应对 Java 工程中的 dubbo rpc 框架?
A: TCP 的验证需要跟业务逻辑耦合，不如 HTTP 的来得简单，因此在 Agent 实现中我们暂时只实现了 HTTP 逻辑校验和 TCP 联通校验，针对这个可以根据自身的需求进行定制。对于我们来说，不是很希望平台层面的组件去关心业务的实现并去耦合其逻辑。
Q: 没有累计次数吧？比如像 k8s 的 successThreshold, failureThreshold 等，重试多少次成功或失败才会认为其可用或不可用。
A: 我们的健康检查和 k8s 的出发点还是有些不同的。对 k8s 来说，它关注的是一个 Pod 意义上的 healthcheck，因此需要有这类检测冗余来满足最小服务单元 Pod 对外的稳定性。对于我们来说 Pod 是个逻辑上的机器组结构，最小服务单元就是容器本身，因此冗余并没太多存在的意义。
在实际生产中，上层应用看到的是一组容器来提供这一类服务，因此单个容器探测是否健康并不会对这一组容器行为造成太大影响，无外乎就是本来 1000 个容器在支撑这个服务，而有一个临时被切走了流量变成只有 999 个容器在支撑了。当然具体生产过程中还会更加复杂，比如报警机制的反馈一类的。具体到冗余有没有必要，要根据不同生产来做不同的选择，就我们目前所支撑的业务来说，暂时没这个需求也就没动力去做了。
Q: 平滑升级的并发粒度可控么, 看 specs 中没有相关的参数控制，比如初始粒度为1, 成功后可递增。
A: 在新的 replace 接口中，是允许控制 replace 步进的。
Q: 当初是基于什么原因考虑 把容器创建这些容器的操作放在了 core 而非 agent 上呢？
A: 早期我们刚开始做 Eru 前身也就是 NBE 的时候就采用过 Core 下发 Agent 执行的架构，但这样会带来几个问题：
- Agent 必须高可用，并且得有一个地方能准确的反馈其部署情况。同时在高压力情况下 Agent 的处理效率要足够高，不然就会造成 Node 不可限制的资源消耗增多，影响已经有的容器运行。
- 对于 Core 而言，要么你需要对 Agent 的可用程度进行管理和维护，但这样一来整个 Core 就是带状态的了，大集群横向扩展会比较麻烦。一个 workaround 的方法是每个 Core 都有全量 Agent 的信息，但这样会造成近似于惊群效应。当然也可以把任务下发到 mq 一类的基础设施去执行，但这样一来首先这类基础设施也需要高可用，另外同样的关于系统状态一致性的获取和检测都是一件比较麻烦的事。我们希望 Eru 是旁路的，也就是说无论 Core-Agent 是否有问题都不应该影响现有的容器运行，而每多增加一个组件所需要花费在信息一致性上的成本就越高。
- 安全性考虑，Agent 开放什么协议，开放什么端口，再去包装一层 Docker 的 API 是否有必要，这些也是需要权衡的。相比较之下 Core 目前只需要通过 https 直连 daemon，并不需要做太多其他操作还是要复杂了不少。简单可依赖，高可用可扩展是当时写 Eru2 的目的之一。
大概就是这 3 点，Eru 来说希望更加纯粹一些，所以 Core 做成了无状态。同时现在的结构当一个 Core 已经性能不够的时候完全可以通过 LVS-(CORE, CORE, CORE...) 这样的结构来进行扩展。至于 Agent 它只需要负责好自己的一亩三分地尽可能的不要对 Node 性能预估造成影响就可以了。