[proposal] better lifecycle management about core HOT 4 CLOSED

一条条说

1. 首先 agent 和 core 是完全解耦的，我觉得应该先从一个视角解决现有问题再考虑另外一个视角。这里来看你耦合了 agent 和 core，这样的坏处在于 core 是否需要知道有 docker events 的存在，多 core 状态一致性怎么办。
2. 没啥，就是老设计
3. 这一点我的问题在于既然都 removed 了，如果对于外部用户来说知道这个状态意味着元数据就不删除？
4. unknown 的问题在于，现在 status 的反馈是单向的，这样好处在于 core 其实无状态，也不关心资源使用方状态，agent or libvirt or cli 说啥就是啥。这样如果机器 crash，agent 没定时上报，谁去把元数据标记为 unknown

from core.

4. core 自己标记. core 开一个 goroutine watch key, 过期就设为 unknown; 不过这样的话 core 的 watch 接口要重新实现, 不能直接转发 watch etcd key

3. 是参考 k8s pod 有两个状态 succeed / failed 是已经完成运行的 pod, 通过 successfulJobsHistoryLimit / failedJobsHistoryLimit 来清理

1. 是; 不过现在其实已经有一点点耦合了, healthy 状态必须由 agent 上报, 而 zero 那边有些业务必须依赖 healthy 状态的 refresh 做事; 不过目前也只是 healthy 状态依赖 agent, 而容器生命周期和资源管理依然是不依赖 agent...

from core.

感觉改动太大, 好处又有限, 还是不要这么搞

from core.

4. 这个 core 开 goroutine 就有问题。。如果多个 core，你还得有个分布式锁，不然以哪个 core 的操作为主呢
5. 这个设计的原因在于 api server 和 kubelet 是完全解耦的，后者负责生命周期也只需要关心一台机器的生命周期，core 很难做到这点
6. healthy 其实是算接口定义吧，等于 core 有这个接口，下面无论哪个 agent 都应该 follow 这个接口定义

from core.