发生了什么?
在我看来,这像是个bug。当注解由同一个字段管理器进行管理时,包括注解更改的服务器端PATCH操作会将更改合并,而不是完全替换注解。
你期望会发生什么?
当注解在服务器端由与引入它们的字段管理器相同的字段管理器进行PATCH操作时,希望注解被替换。如果行为是正确的,那么用服务器端 PATCH来替换整个Map的机制是什么?
我们如何尽可能最小精确地重现它?
需要提供的测试用例
我们需要了解其他信息吗?
这是对话捕获:
在下面的示例中,有一个带有注解的命名空间。命名空间通过带有注解 "a: x" 添加,PATCH操作应该用 "b: y" (相同的字段管理器)替换它们。然而,它们被合并了:"annotations":{"a":"x","b":"y"}
。
发送:
POST https://192.168.121.2:8443/api/v1/namespaces?fieldManager=kubernator&fieldValidation=Warn
Accept: application/json
User-Agent: OpenAPI-Generator/28.1.0/python
Content-Type: application/json
{"apiVersion": "v1", "kind": "Namespace", "metadata": {"name": "ns1", "annotations": {"a": "x"}}}
接收:
201 Created
Audit-Id: 53d3660e-11f8-4acb-8614-66ee7ef69451
Cache-Control: no-cache, private
Content-Type: application/json
X-Kubernetes-Pf-Flowschema-Uid: 5c8f085c-4351-4402-a445-6dd0bd78700c
X-Kubernetes-Pf-Prioritylevel-Uid: 48c26814-1353-4e9f-b65b-5d5542e5c295
Date: Sun, 07 Jan 2024 23:23:03 GMT
Content-Length: 566
{"kind":"Namespace","apiVersion":"v1","metadata":{"name":"ns1","uid":"0a95b535-34ad-48a4-9fe3-8812d09b4343","resourceVersion":"276","creationTimestamp":"2024-01-07T23:23:03Z","labels":{"kubernetes.io/metadata.name":"ns1"},"annotations":{"a":"x"},"managedFields":[{"manager":"kubernator","operation":"Update","apiVersion":"v1","time":"2024-01-07T23:23:03Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:a":{}},"f:labels":{".":{},"f:kubernetes.io/metadata.name":{}}}}}]},"spec":{"finalizers":["kubernetes"]},"status":{"phase":"Active"}}
发送:
PATCH https://192.168.121.2:8443/api/v1/namespaces/ns1?dryRun=All&fieldManager=kubernator&fieldValidation=Warn&force=True
Accept: application/json
Content-Type: application/apply-patch+yaml
User-Agent: OpenAPI-Generator/28.1.0/python
{"apiVersion": "v1", "kind": "Namespace", "metadata": {"name": "ns1", "annotations": {"b": "y"}}}
接收:
200 OK
Audit-Id: 8caa380e-e3cf-4379-8188-12b1b73304c9
Cache-Control: no-cache, private
Content-Type: application/json
X-Kubernetes-Pf-Flowschema-Uid: 5c8f085c-4351-4402-a445-6dd0bd78700c
X-Kubernetes-Pf-Prioritylevel-Uid: 48c26814-1353-4e9f-b65b-5d5542e5c295
Date: Sun, 07 Jan 2024 23:23:05 GMT
Content-Length: 746
{"kind":"Namespace","apiVersion":"v1","metadata":{"name":"ns1","uid":"0a95b535-34ad-48a4-9fe3-8812d09b4343","resourceVersion":"276","creationTimestamp":"2024-01-07T23:23:03Z","labels":{"kubernetes.io/metadata.name":"ns1"},"annotations":{"a":"x","b":"y"},"managedFields":[{"manager":"kubernator","operation":"Apply","apiVersion":"v1","time":"2024-01-07T23:23:05Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{"f:b":{}}}}},{"manager":"kubernator","operation":"Update","apiVersion":"v1","time":"2024-01-07T23:23:03Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:a":{}},"f:labels":{".":{},"f:kubernetes.io/metadata.name":{}}}}}]},"spec":{"finalizers":["kubernetes"]},"status":{"phase":"Active"}}
Kubernetes版本
1.28.4
云提供商
N/A
操作系统版本
N/A
安装工具
容器运行时(CRI)和版本(如适用)
相关插件(CNI,CSI等)和版本(如适用)
5条答案
按热度按时间c9qzyr3d1#
/sig api-machinery
8tntrjer2#
这可能不是bug,注解的默认补丁策略应该是合并。
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#deployment-v1-apps
您可以在此URL查看某些资源的默认补丁策略。尽管它没有明确声明注解的补丁策略,但我认为它应该是合并,并且应该故意这样设置,而不是一个bug。
fiei3ece3#
@Ithrael
这是环境变量,而不是注解。看起来注解没有任何补丁策略。但是我想让你注意以下几点:
注解作为一组显示由相关字段管理器管理:
"."
。那么字段管理器如何通过服务器端补丁替换整个集合?如果注解只能通过服务器端补丁添加/替换,或者清单需要在一个操作中删除注解(可能使清单处于非法状态)来替换值,那么对我来说这似乎是一个行为错误。此外,“.”的存在变得毫无意义,这显然不是意图所在。
dw1jzc5e4#
这是预期的任何具有隐含"合并"行为的数据集合的行为,应该是仅从各个字段管理器中合并值,但每个字段管理器都应该能够覆盖/替换其自身的值。我不确定
"."
会赋予什么特权,除了能够覆盖整个集合的能力,但如何实现这一点-这个机制让我困惑。wb1gzix05#
/triage accepted