Можно ли использовать конкретную версию configMap в файле развертывания?
Не совсем.
Наиболее близким понятием «версия» является resourceVersion, но он не предназначен для прямого действия пользователя.
См. Соглашения API: контроль и согласованность параллелизма :
Kubernetes использует концепцию версий ресурсов для достижения оптимистичного параллелизма. Все ресурсы Kubernetes имеют поле "resourceVersion" как часть своих метаданных. Эта resourceVersion является строкой, которая идентифицирует внутреннюю версию объекта, которая может использоваться клиентами для определения, когда объекты изменились.
Когда запись будет обновлена, ее версия проверяется по предварительно сохраненному значению, и если она не совпадает, обновление завершается с ошибкой StatusConflict (код состояния HTTP 409).
Сервер resourceVersion изменяется каждый раз, когда изменяется объект. Если resourceVersion включено в операцию PUT, система проверит, что во время цикла чтения / изменения / записи не было других успешных мутаций ресурса, проверив, что текущее значение resourceVersion соответствует указанному значению. .
resourceVersion в настоящее время поддерживается etcd modifiedIndex.
Однако важно отметить, что приложение не должно полагаться на детали реализации системы управления версиями, поддерживаемой Kubernetes. Мы можем изменить реализацию resourceVersion в будущем, например, изменить ее на метку времени или счетчик для каждого объекта.
Единственный способ узнать ожидаемое значение resourceVersion для клиента - это получить его от сервера в ответ на предыдущую операцию, обычно GET. Это значение ДОЛЖНО рассматриваться клиентами как непрозрачные и передаваться неизмененным обратно на сервер.
Клиенты не должны предполагать, что версия ресурса имеет значение для пространств имен, разных видов ресурсов или разных серверов.
В настоящее время значение resourceVersion установлено в соответствии с секвенсором etcd. Вы можете думать об этом как о логических часах, которые сервер API может использовать для заказа запросов.
Тем не менее, мы ожидаем, что реализация resourceVersion изменится в будущем, например, в случае, если мы осколку состояния по виду и / или пространству имен или портируем на другую систему хранения.
В случае конфликта правильное клиентское действие на этом этапе - GET ресурс снова, применить изменения заново и попытаться отправить снова.
Этот механизм может быть использован для предотвращения гонок, таких как:
Client #1 Client #2
GET Foo GET Foo
Set Foo.Bar = "one" Set Foo.Baz = "two"
PUT Foo PUT Foo
Когда эти последовательности происходят параллельно, может быть потеряно либо изменение на Foo.Bar, либо изменение на Foo.Baz.
С другой стороны, при указании resourceVersion один из PUT s завершится ошибкой, поскольку в зависимости от того, какая запись завершится успешно, resourceVersion изменится на Foo.
resourceVersion может использоваться в качестве предварительного условия для других операций (например, GET, DELETE) в будущем, например, для согласованности чтения после записи при наличии кэширования.
Операции «Наблюдение» указывают resourceVersion с использованием параметра запроса. Он используется для указания точки, с которой начинается просмотр указанных ресурсов.
Это может быть использовано для того, чтобы не пропустить никаких мутаций между GET ресурса (или списка ресурсов) и последующим наблюдением, даже если текущая версия ресурса более поздняя.
В настоящее время это основная причина того, что операции со списками (GET в коллекции) возвращают resourceVersion.