在secret中使用stringData的kubectl apply不会删除字段

Question

(在minikube中使用kubernetes v1.15.7，并匹配客户端版本和minikube 1.9.0(

如果我kubectl apply一个像这样的秘密：

apiVersion: v1
data:
MY_KEY: dmFsdWUK
MY_SECRET: c3VwZXJzZWNyZXQK
kind: Secret
metadata:
name: my-secret
type: Opaque

然后随后kubectl apply一个秘密删除MY_secret字段，如下所示：

apiVersion: v1
data:
MY_KEY: dmFsdWUK
kind: Secret
metadata:
name: my-secret
type: Opaque

结果中的data字段是我kubectl get机密时所期望的：

data:
MY_KEY: dmFsdWUK

---

但是，如果我对第一个kubectl apply使用stringData而不是执行相同的操作，它不会删除第二个上丢失的密钥：

第一个kubectl apply:

apiVersion: v1
stringData:
MY_KEY: value
MY_SECRET: supersecret
kind: Secret
metadata:
name: my-secret
type: Opaque

第二个kubectl apply(保持不变，只是用b2hubyEK替换MY_KEY的值以显示配置DID更改(

apiVersion: v1
data:
MY_KEY: b2hubyEK
kind: Secret
metadata:
name: my-secret
type: Opaque

应用第二种情况后的kubectl get结果：

data:
MY_KEY: b2hubyEK
MY_SECRET: c3VwZXJzZWNyZXQ=

如果第二种情况使用stringData，则该字段也不会被删除。因此，似乎一旦stringData被使用一次，就不可能在不删除机密的情况下删除字段。这是个虫子吗？或者在使用stringData时，我应该做一些不同的事情吗？

Answer 1

kubectl apply需要在此处合并/修补更改。如何应用计算差异和合并更改中描述了这一工作原理

我建议将kustomize与kubectl apply -k一起使用，并使用secretGenerator为每次更改创建一个唯一的机密名称。然后，您正在练习不可变基础结构，不会遇到此类问题。

一个全新的配置管理工具是kpt，kpt live apply可能也是一个有趣的解决方案。

Answer 2

问题是stringData是一个只写字段。它没有收敛行为，因此破坏了合并补丁生成器系统。大多数高级工具通过在处理补丁之前转换为普通data来解决此问题。