为什么设计 K8s
- 与 Omega 类似，k8s 的核心也是一个共享持久数据仓库（store）， 几个组件会监听这个 store 里的 object 变化；
- Omega 将自己的 store 直接暴露给了受信任的控制平面组件，但 k8s 中的状态 只能通过一个 domain-specific REST API 访问，这个 API 会执行 higher-level versioning, validation, semantics, policy 等操作，支持多种不同类型的客户端；
- 更重要的是，k8s 在设计时就非常注重应用开发者的体验： 首要设计目标就是在享受容器带来的资源利用率提升的同时，让部署和管理复杂分布式系统更简单。
容器作为基本管理单元
围绕容器而非机器构建 management API，将数据中心的核心从机器转移到了应用，这带了了几方面好处：
- 应用开发者和应用运维团队无需再关心机器和操作系统等底层细节；
- 基础设施团队引入新硬件和升级操作系统更加灵活， 可以最大限度减少对线上应用和应用开发者的影响；
- 将收集到的 telemetry 数据（例如 CPU、memory usage 等 metrics）关联到应用而非机器， 显著提升了应用监控和可观测性，尤其是在垂直扩容、 机器故障或主动运维等需要迁移应用的场景。
通用 API 和自愈能力
容器能提供一些通用的 API 注册机制，使管理系统和应用之间无需知道彼此的实现细节就能交换有用信息。
- 在 Borg 中，这个 API 是一系列 attach 到容器的 HTTP endpoints。 例如，
/healthz endpoint 向 orchestrator 汇报应用状态，当检测到一个不健康的应用时， 就会自动终止或重启对应的容器。这种自愈能力（self-healing）是构建可靠分布式系统的最重要基石之一。
- K8s 也提供了类似机制，health check 由用户指定，可以是 HTTP endpoint 也可以一条 shell 命令（到容器内执行）。
用 annotation 描述应用结构信息
容器还能提供或展示其他一些信息。例如，
- Borg 应用可以提供一个字符串类型的状态消息，这个字段可以动态更新；
- K8s 提供了 key-value
annotation， 存储在每个 object metadata 中，可以用来传递应用结构（application structure）信息。 这些 annotations 可以由容器自己设置，也可以由管理系统中的其他组件设置（例如发布系统在更新完容器之后更新版本号）。
容器管理系统还可以将 resource limits、container metadata 等信息传给容器， 使容器能按特定格式输出日志和监控数据（例如用户名、job name、identity）， 或在 node 维护之前打印一条优雅终止的 warning 日志。