Kubenetes-API

Kubernetes API概念

• 所有的资源都可以通过API返回其信息
• 每个 Kubernetes 对象都有一个 resourceVersion 字段，代表该资源在下层数据库中存储的版本。检视资源集合（名字空间作用域或集群作用域）时，服务器返回的响应 中会包含 resourceVersion 值，可用来向服务器发起 watch 请求。 服务器会返回所提供的 resourceVersion 之后发生的所有变更（创建、删除和更新）。 这使得客户端能够取回当前的状态并监视其变更，且不会错过任何变更事件。 客户端的监视连接被断开时，可以从最后返回的 resourceVersion 重启新的监视连接， 或者执行一个新的集合请求之后从头开始监视操作。
• 使用 etcd3 的集群默认保存过去 5 分钟内发生的变更。 当所请求的 watch 操作因为资源的历史版本不存在而失败，客户端必须能够处理 因此而返回的状态代码 410 Gone，清空其本地的缓存，重新执行 list 操作， 并基于新的 list 操作所返回的 resourceVersion 来开始新的 watch 操作
• 为了处理历史窗口过短的问题，我们引入了 bookmark（书签） 监视事件的概念。 该事件是一种特殊事件，用来标示客户端所请求的、指定的 resourceVersion之前 的所有变更都以被发送
• 分块检视大体量结果。集合请求上可以设置两个新的参数 limit 和 continue

  GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN
  

资源删除

资源删除要经过两个阶段：1) 终止（finalization），和 2）去除。

{
  "kind": "ConfigMap",
  "apiVersion": "v1",
  "metadata": {
    "finalizers": {"url.io/neat-finalization", "other-url.io/my-finalizer"},
    "deletionTimestamp": nil,
  }
}

当客户端首先删除某资源时，其.metadata.deletionTimestamp会被设置为当前时间。 一旦 .metadata.deletionTimestamp被设置，则对终结器（finalizers）执行动作 的外部控制器就可以在任何时候、以任何顺序执行其清理工作。
这里不强调顺序是因为很可能带来 .metadata.finalizers被锁定的风险。.metadata.finalizers是一个共享的字段，任何具有相关权限的主体都可以对其 执行重排序的操作。如果终结器列表要按顺序处理，则很可能导致负责列表中第一个 终结器的组件要等待负责列表中排序靠后的终结器的组件的信号（可能是字段值变更、 外部系统或者其他形式），从而导致死锁行为。 在不对终结器顺序作强制要求的情况下，终结器可以自行排序，且不会因为其在列表 中的顺序而引入任何不稳定因素。

当最后一个终结器也被移除时，资源才真正从 etcd中移除。