반응형
250x250
Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- kubeflow
- JavaScript
- aws cicd
- chart.js
- Spring
- docker
- Spring Error
- 도커
- IntelliJ
- aws
- codedeploy
- AWS CI/CD 구축하기
- bootstrap
- codebuild
- chartjs
- VPN
- Kafka
- Airflow
- redis
- SQL
- codedeploy error
- PostgreSQL
- Python
- codepipeline
- openlens
- node
- java bigdecimal
- COALESCE
- Jenkins
- Flux
Archives
- Today
- Total
목록kustomize (1)
Small Asteroid Blog
Kubernetes에서 Kustomize를 쓰는 이유
Kubernetes를 운영하다 보면 dev / cbt / prod처럼 환경이 여러 개로 나뉘고, 리소스 형태는 같은데 값만 다른 상황이 흔하다.예를 들면 Deployment/Service/Ingress는 동일한 구조를 유지하면서도 환경마다 image tag, replicas, resources, Ingress host, annotation 같은 값은 달라진다.이때 선택지는 보통 두 가지다.환경별로 YAML을 복사해서(dev.yaml, prod.yaml...) 각각 관리한다.공통은 하나로 두고, 환경별 차이만 관리한다. (Kustomize 방식)이 글에서는 두 번째 방식인 Kustomize를 왜 쓰는지, 특히 base는 동일하고 환경별로 다른 내용만 있을 때 어떤 이득이 있는지 정리한다. 문제: 환경별 Y..
클라우드 및 인프라/Kubernetes
2025. 12. 22. 10:22