В Operator-SDK несколько патчей в одной функции согласования
Я работаю над реализацией оператора с помощью operator-sdk.
У меня есть вопросы о Patch API в операторском SDK(client.Client).
Есть два Patch API, которые Client.Patch а также Client.Status().Patch.
Насколько я знаю, первый (Client.Patch) будет ролью полей патча, кроме Statusв ресурсе. Другой(Client.Status().Patch) будет исправлять Status поле в ресурсе.
На этом этапе могу ли я использовать Patch(Что бы это ни было Client.Status().Patch или Client.Patch) API несколько раз в одной функции Reconcile?
я думал что Patch API изменит версию ресурса, поэтому API не сможет нормально работать, когда я позвоню Patch API несколько раз в одной функции согласования, однако API (Patch) работает хорошо (на самом деле я вызвал 2 раза в одной функции согласования), как я заметил.
Если есть знания, которые я неправильно понял, дайте мне совет.
Спасибо.
1 ответ
Я нашел сообщение в блоге с заголовком: 7 лучших практик для написания операторов Kubernetes: перспектива SRE
И 4-й пункт:
4. Одно изменение пользовательского ресурса за раз
Каждый раз, когда пользовательский ресурс, который отслеживает ваш контроллер, изменяется, цикл согласования запускается снова. Это включает изменения, сделанные пользователем, а также изменения, которые вы делаете в функции согласования или ее подпрограммах. Часто вам нужно обновить настраиваемый ресурс, с которым вы работаете, чтобы добавить информацию. Примером оператора проекта GCP является идентификатор проекта, созданного в GCP. Это обновление заставит цикл согласования выбрать обновленную версию настраиваемого ресурса и запустить еще один запуск согласования.
Вы должны знать об этом, поскольку изменение настраиваемого ресурса и продолжение обработки может привести к состояниям гонки с вновь созданным запросом. Если параллельная обработка включена, немедленно запускается функция согласования. В этом случае вы должны учитывать, что может быть второй запрос, работающий с этим ресурсом одновременно в каждой строке вашего кода. Даже если запросы не обрабатываются параллельно, запросы согласования будут накапливаться при многократном обновлении CustomResource, из-за чего оператор будет излишне занят.
Чтобы снизить риск состояний гонки и избежать накопления запросов, убедитесь, что вы не выполняете несколько изменений в настраиваемом ресурсе или зависимых действиях за один запуск Reconcile. Всякий раз, когда вы обновляете пользовательский ресурс, который просматриваете, просто выйдите из цикла согласования и позвольте следующему запуску продолжиться. Все ваши идемпотентные функции, выполненные ранее, ничего не сделают, и вы можете продолжить с того места, на котором остановились.
Итак, если я правильно понимаю, вы можете внести несколько изменений за один прогон функции согласования, но это обычно считается плохой практикой.