kubectl применить с stringData в секрете не удаляет поля

Question

(с использованием kubernetes v1.15.7 в мини-кубе и соответствующей версии клиента и мини-куба 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

---

Однако, если я сделаю то же самое, используя stringData вместо для первого kubectl, примените , он не удалит отсутствующий ключ во втором:

First kubectl apply:

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

Секунда kubectl apply (остается прежней, за исключением замены значения MY_KEY на b2hubyEK для отображения изменения 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 перед обработкой патча.