我正在尝试进行部署并监视 k8s 事件，直到使用k8s 节点 api（观看）准备好部署：https://github.com/kubernetes-client/javascript/blob/master/examples/typescript/watch/观看示例.ts
我已经读过这一部分： https: //kubernetes.io/docs/reference/using-api/api-concepts/#watch-bookmarks一遍又一遍，但从客户的角度来看，我仍然无法理解：
小智 12
我将尝试从客户的角度回答您的问题：
\n其目的是减少对资源类型发出 Watch 请求的客户端对 kube-apiserver 的负载。书签的目的是让客户端知道服务器已向客户端发送了resourceVersion书签事件中指定的所有事件。这是为了确保如果客户端的监视失败或通道关闭（超时后），客户端可以\xc2\xa0resourceVersion恢复书签事件中最后返回的监视。它更像是一个检查点事件，没有真正的变异事件，如添加、修改、删除。
客户端可能已经缓存了作为常规“添加”、“修改”、“删除”事件的一部分接收到的资源版本，但请考虑以下情况：您正在查看的资源在过去 30 分钟内没有更新，并且您resourceVersion缓存的资源版本是“100”。\n\xc2\xa0
在没有书签事件的情况下，您将尝试从“100”恢复，但服务器可能返回“410 Gone”，表明它没有该版本或版本太旧。在这种情况下，客户端将必须执行一个列表来获取最新的资源版本并从那里启动监视，或者通过不指定资源版本从最新的位置启动监视，这对于服务器处理来说更昂贵。
\n如果存在书签事件，服务器可能会尝试向您发送资源版本为“150”的书签事件，表明您已处理完该版本，并且在重新启动时您可以从那里开始处理。\n\xc2\ xa0\n文档中的这个人为示例说明了这一点。您在 rv="10245" 处启动观察程序，处理一些直到 rv="10596" 的事件，然后服务器向您发送一个带有 rv="12746" 的书签，以便在重新启动时您可以从那里开始处理。
\nGET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true\n---\n\n200 OK \nTransfer-Encoding: chunked \nContent-Type: application/json\n\n{\n "type": "ADDED",\n "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}\n}\n...\n{\n "type": "BOOKMARK",\n "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }\n}\n为了有效地处理您观看的资源上的更改事件，处理书签似乎比不处理更好。不过，无法保证书签的传送 - 服务器可能不支持它（如果它运行的是旧版本的 Kubernetes），或者可能根本不发送书签。
\n是的，您完全可以这样做，但是如果您使用书签，丢失事件的可能性就会降低。还要记住，它不仅有利于客户端，也有利于 kube-apiserver，因为如果它具有您在书签中收到的“新鲜”资源版本，它可以从本地缓存返回事件，如果没有，它将不得不执行从 etcd 中一致读取。我推荐这个视频，以了解 Watch 事件的幕后运作方式。
\n根据您所使用的客户端库，用法可能会有所不同，但在原始 HTTP 请求中，您可以指定此查询参数： llowWatchBookmarks=true
\nGET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true\n如果您使用client-go，有一个名为 Reflector 的工具，这就是它请求书签的方式。
\n从 Bookmark 事件中提取 resourceVersion 并将其缓存起来，以便在您因任何原因尝试重新启动观察程序时使用。
\n| 归档时间： |
|
| 查看次数： |
2433 次 |
| 最近记录： |