There is no API

Kubernetes API concept

• All resources can APIreturn their information
• Each Kubernetesobject has a resourceVersionfield, on behalf of the resource stored in the underlying database version. When viewing a resource collection (namespace scope or cluster scope), the response returned by the server will contain the resourceVersion value, which can be used to initiate a watch request to the server. The server will return all changes (create, delete, and update) that have occurred since the provided resourceVersion. This allows the client to retrieve the current state and monitor its changes without missing any change events. When the monitoring connection of the client is disconnected, a new monitoring connection can be restarted from the last resourceVersion returned, or the monitoring operation can be restarted from the beginning after executing a new collection request.
• Using etcd3cluster default save the last 5 分钟changes occurred within. When the requested watch operation fails because the historical version of the resource does not exist, the client must be able to process the returned status code 410 Gone, clear its local cache, re-execute the list operation, and start based on the resourceVersion returned by the new list operation New watch operation
• To deal with the history window is too short, we introduced the bookmark（书签）concept of monitoring events. The event is a special event for the label requested by the client, specified resourceVersionbefore 所有变更are to be transmitted
• View large-scale results in blocks. Two new parameters may be provided on a set request limitandcontinue

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

Resource deletion

Resource deletion goes through two stages: 1) finalization, and 2) removal.

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

When the client first deletes a resource, it .metadata.deletionTimestampwill be set to the current time. Once .metadata.deletionTimestampset, the terminator of the （finalizers）can, at any time, which cleanup work performed in any order external controller to perform an action.
Here is the order because it does not emphasize the potential .metadata.finalizersrisk of being locked out. .metadata.finalizersIt is a shared field, and any subject with relevant permissions can perform reordering operations on it. If the list of finalizers are to be processed in order, it is likely that the component responsible for the first terminator in the list will wait for the signal of the component responsible for the last-ordered terminator in the list (may be a field value change, an external system or other forms ), resulting in deadlock behavior. Without mandatory requirements on the order of the finalizers, the finalizers can be sorted by themselves, and will not introduce any unstable factors due to their order in the list.

When the last terminator is also removed from the resource really etcdremoved in.