Всем привет!
«Масштаб» может привносить затруднения, про которые не думаешь на малых объемах. Это применимо и к манифестам Kubernetes: чем больше становится приложение, растет его функционал и возможности, тем в большую «кашу» превращается папка с конфигурациями.
В статье автор предлагает интересный подход к структуре хранения манифестов. Все строится вокруг создания пространства папок, где каждая из них представляет отдельный Kind (Deployment, Service, ConfigMap и т.д.).
Приводится наглядный пример использования подобного подхода и рекомендации автора:
🍭 Сокращайте длинные аббревиатуры привычными аналогами при именовании файлов (например,
🍭 Используйте идентичные имена файлов между «Kind-директориями»
🍭 Не используйте тип сущности в ее названии (например nginx-service.yaml)
🍭 Именуйте ресурсы по аналогии с именами файлов, в которых они определяются
Такой подход упрощает восприятие конфигурации приложения и сокращает вероятность ошибки (например, из-за разных способов написания service/svc). Удобен ли Вам подобный подход к хранению манифестов приложений, стали бы вы его использовать?
«Масштаб» может привносить затруднения, про которые не думаешь на малых объемах. Это применимо и к манифестам Kubernetes: чем больше становится приложение, растет его функционал и возможности, тем в большую «кашу» превращается папка с конфигурациями.
В статье автор предлагает интересный подход к структуре хранения манифестов. Все строится вокруг создания пространства папок, где каждая из них представляет отдельный Kind (Deployment, Service, ConfigMap и т.д.).
Приводится наглядный пример использования подобного подхода и рекомендации автора:
🍭 Сокращайте длинные аббревиатуры привычными аналогами при именовании файлов (например,
hpas вместо horizontalpodautoscalers)🍭 Используйте идентичные имена файлов между «Kind-директориями»
🍭 Не используйте тип сущности в ее названии (например nginx
🍭 Именуйте ресурсы по аналогии с именами файлов, в которых они определяются
Такой подход упрощает восприятие конфигурации приложения и сокращает вероятность ошибки (например, из-за разных способов написания service/svc). Удобен ли Вам подобный подход к хранению манифестов приложений, стали бы вы его использовать?