Вы можете использовать Kubernetes в качестве хранилища конфигурации, на ваш взгляд, просто вам, вероятно, не стоит этого хотеть. Сохраняя конфигурацию в виде кода, вы получаете несколько преимуществ:
- Изменения конфигурации получают регулярные проверки кода.
- Они становятся версионными, легко распространяемыми и т. Д.
- Они могут быть проверены, окрашены и все, что вы пожелаете.
- Они могут быть реорганизованы, совместно использовать код и задокументированы.
- И все это происходит до того, как фактически будет отослан в Кубернетес.
Это может показаться плохим («но тогда моя конфигурация устарела!»), Но имейте в виду, что конфигурация на самом деле никогда не устарела - то, что вы сказали Kubernetes, что хотите запустить 3 реплики, не означает, что они есть, или если бы это было 1, это временно не сейчас, и так далее.
Конфигурация выражает намерение . Требуется другой процесс, чтобы фактически заметить, когда ваше намерение меняется или не соответствует действительности, и сделать это так. Для Kubernetes это хранилище и т. Д., И это зависит от мастера, чтобы в цикле навсегда убедиться, что сохраненное намерение соответствует реальности. Для вас хранилище - это управление исходным кодом, и любой процесс, который вы хотите, автоматизированный или нет, может в цикле навсегда гарантировать, что ваш код в конечном итоге будет отражен в Kubernetes.
Таким образом, команда отката - это очень быстрый ярлык «пожалуйста, сделайте это прямо сейчас !». Это потому, что ваша конфигурация была неправильной, а у вас нет времени, чтобы это исправить. Как только вы откатитесь, вы должны будете отслеживать свою конфигурацию и обновлять ее там же. В некотором смысле, это действительно дублирование, но это редкое событие по сравнению с обычным потоком, и общие преимущества перевешивают этот недостаток.