Kustomize (외부자료)

lumination 2025. 2. 28. 19:03

2025. 2. 28. 19:03

https://devopscube.com/kustomize-tutorial/

이 Kustomize 튜토리얼에서는 Kustomize 개념을 모두 배우고 Kubernetes 클러스터에서 Kustomize를 사용하여 애플리케이션을 배포합니다.

목차 표시

Kustomize 사용 사례

Kustomize에 대해 알아보기 전에, Kubernetes 매니페스트를 사용하여 애플리케이션을 배포하는 데 발생하는 문제부터 알아보겠습니다 .

Kubernetes 에 애플리케이션을 배포하려고 하며 dev, uat, prod 등 여러 환경이 있는 경우를 가정해 보겠습니다. 각 환경에서 배포에 대한 구성이 다를 수 있습니다 .

예를 들어, dev 및 uat에서는 롤링 업데이트가 필요하지 않지만 prod에서는 필요할 수 있습니다. 또한 각 환경에서 다른 복제본, 다른 CPU 및 메모리 리소스, 주석 등이 필요할 수 있습니다. 그뿐만 아니라 애플리케이션은 모든 환경에서 변경되는 Configmaps 및 Secrets를 통해 속성을 사용할 수 있습니다.

따라서 각 환경의 요구 사항에 맞게 배포를 사용자 정의해야 합니다.

이 문제에 대한 간단한 해결책은 각 환경별로 세 개의 별도 디렉토리를 만들고, 해당 폴더에 모든 Kubernetes 매니페스트를 추가하는 것입니다.

하지만 확장 가능한 솔루션은 아닙니다. 새로운 애플리케이션이 온보딩되거나 새로운 구성 파일이 추가되면 폴더의 모든 YAML 파일을 수동으로 관리하기 어렵기 때문입니다. 이로 인해 구성 드리프트 문제가 발생할 수도 있습니다.

YAML에서 구성을 대체하는 스크립트를 만들 수 있지만 서비스가 많은 경우 좋은 방법이 아닙니다.

이러한 모든 문제는 Kustomize를 사용하여 해결할 수 있습니다 . 또한 다른 구성 도구와 차별화되는 한 가지 특징은 Kubernetes 클러스터를 관리하기 위한 명령줄 인터페이스인 kubectl과의 긴밀한 통합입니다.

다음 주제에서는 Kustomize 개념과 그 이점을 자세히 살펴보겠습니다. 또한 Nginx 배포를 사용하여 Kubernetes 배포를 단순화하는 방법을 보여드리기 위해 Kustomize의 실제 예를 살펴보겠습니다.

Kustomize란 무엇인가요?

Kustomize 는 Kubernetes를 위한 오픈소스 구성 관리 도구입니다.

이를 통해 원래 YAML 파일을 수정하지 않고도 선언적 방식으로 여러 환경에 대한 배포 , Daemonset , 서비스, configMap 등과 같은 Kubernetes 객체를 정의하고 관리할 수 있습니다 . 간단히 말해서, YAML에 대한 단일 진실 소스가 있으며 환경 요구 사항에 따라 기본 YAML 위에 필요한 구성을 패치합니다.

공식 문서에는 다음과 같이 나와 있습니다.

kustomize를 사용하면 다양한 목적에 맞게 템플릿이 없는 원시 YAML 파일을 사용자 정의하여 원본 YAML을 그대로 유지하고 사용할 수 있습니다.

Kustomize에는 Base와 Overlays라는 두 가지 핵심 개념이 있습니다 . Kustomize를 사용하면 모든 환경에서 기본 파일(일반 YAML)을 재사용하고 각 환경에 대한 오버레이 (패치) 사양을 재사용할 수 있습니다.

오버레이는 매니페스트 파일의 사용자 지정 버전을 만드는 프로세스입니다( 기본 매니페스트 + 오버레이 매니페스트 = 사용자 지정 매니페스트 파일).

모든 사용자 정의 사양은 kustomization.yaml 파일 내에 포함되어 있습니다.

사용자 정의 기능

Kustomize의 주요 기능은 다음과 같습니다.

Kubernetes YAML과 동일한 선언적 구성을 갖춘 구성 도구 역할을 합니다.
원본 파일을 변경하지 않고도 리소스를 수정할 수 있습니다.
모든 리소스에 공통적인 라벨과 주석을 추가할 수 있습니다.
배포되는 환경에 따라 컨테이너 이미지를 수정할 수 있습니다.
Kustomize는 또한 환경 파일이나 키-값 쌍을 사용하여 비밀과 configMaps를 생성하는 기능 secretGenerator과 함께 제공됩니다.configMapGenerator

이러한 모든 개념과 기능은 nginx 배포를 사용하여 Kustomize를 실제로 사용하는 방법을 보여드리는 섹션에서 더 자세히 설명하겠습니다 .

Kustomize 설치

참고: Kustomize를 설치하기 전에 Kubernetes 클러스터가 실행 중이어야 하며, 로컬 머신에 kubectl이 설치되어 있고 클러스터에 연결되어 있어야 합니다.

Kustomize는 오픈소스 도구이며 독립 실행형 바이너리 또는 kubectl 플러그인으로 제공됩니다. Kustomize 설치는 매우 쉽습니다.

쿠벡틀 쿠스토마이즈

kustomize 모듈은 kubectl에 내장되어 있습니다. kubectl을 통해 직접 customize를 사용할 수 있습니다. 다음 명령을 사용하여 확인할 수 있습니다.

kubectl kustomize --help

독립형 Kustomize

아래 언급된 스크립트는 자동으로 OS를 감지하고 Kustomize를 설치합니다.

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash

설치 후 아래 명령을 실행하여 확인하세요. Kustomize의 최신 적절한 버전이 표시됩니다. 버전이 표시되지 않으면 터미널을 닫고 새 터미널을 열어 명령을 실행하세요.

kustomize version

여전히 문제가 있으면 bash: kustomize: command not found error아래 명령을 실행하고 다시 확인하세요. 이렇게 하면 경로가 설정됩니다.

sudo install -o root -g root -m 0755 kustomize /usr/local/bin/kustomize

Kustomize는 MAC과 Windows에 각각 brew과 를 사용하여 설치할 수도 있습니다 .chocolatey

MAC 사용자의 경우:

brew install kustomize

Windows 사용자의 경우:

choco install kustomize

Kustomize 이해하기

먼저, 다음의 Kustomize 핵심 개념을 이해해야 합니다.

kustomization.yaml파일
베이스 및 오버레이
변압기
패치

각 개념을 살펴보겠습니다.

kustomization.yaml 파일

이 kustomization.yaml파일은 Kustomize 도구에서 사용되는 기본 파일입니다.

Kustomize를 실행하면 .이라는 파일을 찾습니다 kustomization.yaml. 이 파일에는 Kustomize에서 관리해야 하는 모든 Kubernetes 리소스(YAML 파일) 목록이 들어 있습니다. 또한 사용자 지정 매니페스트를 생성하기 위해 적용하려는 모든 사용자 지정도 들어 있습니다.

여기 예제 kustomization.yaml파일이 있습니다. 모든 구성에 대해 걱정하지 마세요. 다음 섹션에서 모든 필드에 대해 알아봅니다.

베이스 및 오버레이

Base 폴더는 모든 환경에서 동일하게 될 구성을 나타냅니다. 모든 Kubernetes 매니페스트를 Base에 넣습니다. 덮어쓸 수 있는 기본값이 있습니다.

반면에 Overlays 폴더는 환경별로 동작을 사용자 지정할 수 있게 해줍니다. 각 환경에 대해 Overlay를 만들 수 있습니다. 덮어쓰고 변경하려는 모든 속성과 매개변수를 지정합니다.

기본적으로 Kustomize는 패치 지시어를 사용하여 기존 Base 표준 k8s 구성 파일을 방해하지 않고 환경별 변경 사항을 도입합니다. 패치는 잠시 후에 살펴보겠습니다.

변압기

이름에서 알 수 있듯이, 트랜스포머는 한 구성을 다른 구성으로 변환하는 것입니다. 트랜스포머를 사용하면 기본 Kubernetes YAML 구성을 변환할 수 있습니다. Kustomize에는 여러 개의 기본 트랜스포머가 있습니다. 몇 가지 일반적인 트랜스포머를 살펴보겠습니다.

commonLabel– 모든 Kubernetes 리소스에 레이블을 추가합니다.
namePrefix
– 모든 리소스 이름 에 공통 접두사를 추가합니다.
nameSuffix
– 모든 리소스 이름 에 공통 접미사를 추가합니다.
Namespace– 모든 리소스에 공통 네임스페이스를 추가합니다.
commonAnnotations– 모든 리소스에 주석을 추가합니다.

예를 들어 보겠습니다. 아래 이미지에서 우리는 사용자 정의에 레이블이 추가되는 곳 commonLabels을 사용했습니다.kustomization.yaml env: devdeployment.yaml.

이미지 트랜스포머

특정 배포에 사용될 이미지를 수정할 수 있습니다.

다음 예에서 이미지 변환기는 nginx언급된 대로 이미지 이름을 확인하고 파일 에 deployment.yaml있는 새 이름으로 변경합니다 . 태그도 변경할 수 있습니다.ubuntukustomization.yaml

패치(오버레이)

패치 또는 오버레이는 Kubernetes 구성을 수정하는 또 다른 방법을 제공합니다. 구성에서 변경할 수 있는 보다 구체적인 섹션을 제공합니다. 제공해야 하는 매개변수는 3개입니다.

Operation Type:추가하거나 제거하거나 교체하다
Target:수정하고 싶은 리소스 이름
Value:추가되거나 대체될 값 이름입니다. 제거 작업 유형의 경우 값이 없습니다.

패치를 정의하는 방법은 두 가지가 있습니다.

JSON 6902 및
전략적 병합 패치.

JSON 6902 패치

이런 방식으로 우리가 제공해야 하는 세부 정보는 대상 과 패치 세부 정보 , 즉 작업, 경로, 새 값입니다.

patches:
  - target:
      kind: Deployment
      name: web-deployment
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 5

다음 이미지는 JSON 패치 워크플로를 보여줍니다.

전략적 병합 패치

이런 식으로 모든 패치 세부 사항은 표준 k8s 구성과 유사합니다. 원래 매니페스트 파일이 되고, 수정해야 할 필드만 추가합니다.

다음은 인라인 전략적 병합 패치의 예입니다.

patches:
  - patch: |-
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: web-deployment
      spec:
        replicas: 5

파일에서 패치

두 가지 유형의 패치에 대해 인라인 구성 대신 별도의 파일 방법을 사용할 수 있습니다. YAML 파일에 모든 패치 세부 정보를 지정하고 kustomization.yaml패치 지시문 아래의 파일을 참조합니다.

예를 들어, kustomization.yaml다음과 같이 패치 파일을 언급해야 합니다. YAML 파일의 상대 경로를 지정해야 합니다.

patches:
- path: replicas.yaml

replicas.yaml그리고 아래와 같이 변경 사항을 적용할 수 있습니다 .

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 5

이제 Kustomize의 기본 개념을 모두 잘 이해했으므로, 배운 내용을 실제 구현에 적용해 보겠습니다.

Kustomize를 사용하여 애플리케이션 배포

다양한 환경을 포함하는 실제 배포 시나리오를 통해 Kustomize가 어떻게 작동하는지 살펴보겠습니다.

참고 : 데모 목적으로 두 가지 환경만 있는 간단한 YAML 파일을 제공했습니다. 실제 프로젝트에서 YAML은 다른 객체와 더 많은 배포 환경으로 더 복잡해질 수 있습니다.

다음과 같은 시나리오를 가정해 보자.

Nginx 웹 서버는 개발 및 프로덕션에 배포되어야 합니다.
개발 단계에서는 복제본 2개, Nodeport 서비스, 그리고 적은 메모리와 CPU 리소스만 갖춘 배포만 필요합니다.
프로덕션에서는 4개의 복제본, 다른 CPU 및 메모리 제한, 롤링 업데이트 전략, NodePort가 없는 서비스를 갖춘 배포가 필요합니다.

Kustomize를 사용하여 이를 어떻게 달성할 수 있는지 살펴보겠습니다.

Github Repo: 이 가이드에 사용된 모든 매니페스트는 Kustomize Github Repo 에 호스팅됩니다 .

Kustomize를 사용하기 위한 디렉토리 구조는 다음과 같습니다.

├── kustomize
  ├── base
    │   ├── deployment.yaml
    │   ├── service.yaml
    │   ├── kustomization.yaml
    └ overlays
        ├── dev
        │   ├── deployment-dev.yaml
        |   ├── service-dev.yaml
        │   └── kustomization.yaml
        └── prod
            ├── deployment-prod.yaml
            ├── service-prod.yaml
            └── kustomization.yaml

GitHub repo 파일을 참조로 사용하거나 다음 명령을 사용하여 해당 폴더와 파일을 만들 수 있습니다.

mkdir -p kustomize/base && 
    touch kustomize/base/deployment.yaml \
         kustomize/base/service.yaml \
         kustomize/base/kustomization.yaml && 
    mkdir -p kustomize/overlays/dev && 
    touch kustomize/overlays/dev/deployment-dev.yaml \
         kustomize/overlays/dev/service-dev.yaml \
         kustomize/overlays/dev/kustomization.yaml && 
    mkdir -p kustomize/overlays/prod && 
    touch kustomize/overlays/prod/deployment-prod.yaml \
         kustomize/overlays/prod/service-prod.yaml \
         kustomize/overlays/prod/kustomization.yaml

기본 폴더부터 시작해 보겠습니다.

기본 폴더

기본 폴더에는 배포, 서비스 및 kustomization 파일이 들어 있습니다. 이 기본 폴더에서 모든 환경에 공통될 수 있는 모든 구성이 포함된 배포 및 서비스 YAML을 추가합니다.

base/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

base/service.yaml

apiVersion: v1
  kind: Service
  metadata:
    name: web-service
  spec:
    selector:
      app: web
    ports:
    - name: http
      port: 80

base/kustomization.yaml

아래 파일에서는 deployment.yaml및 를 service.yaml 리소스로 참조합니다.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
  
resources:
- deployment.yaml
- service.yaml

Dev 오버레이 폴더

Dev 오버레이 파일을 정의해 봅시다. 우리는 단지 변경하고 싶으므로 deployment.yaml정의만 할 것입니다.

deployment-dev.yaml

개발 배포에서는 복제본을 1에서 2로만 늘리고 싶습니다. 변경 사항만 정의하고 다른 것은 정의하지 않는다는 것을 알 수 있습니다. Kustomize는 기본 배포 파일을 확인하고 비교하여 변경 사항을 적절히 패치합니다. 그것이 Kustomize의 장점입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3 # Update the replica count to 3
  template:
    spec:
      containers:
      - name: nginx
        resources:
          limits:
            cpu: "200" # Lower CPU limit to 200m (0.2 CPU cores)
            memory: "256Mi" # Lower memory limit to 256 MiB
          requests:
            cpu: "100" # Lower CPU request to 100m (0.1 CPU cores)
            memory: "128Mi"

service-dev.yaml

개발에서는 nodeport가 있는 서비스가 필요합니다. 그래서 Nodeport 유형의 오버레이를 만들 것입니다.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: NodePort

kustomization.yaml

블로그에서 앞서 논의했듯이, 우리는 분리 파일 방법을 사용하여 전략적 병합 패치를 사용하고 있습니다. 또한 여기서도 리소스를 정의했음을 알 수 있습니다. 이것이 Kustomize가 기본 파일의 경로를 알아야 하는 이유입니다.

이전 Kustomize 버전에서는 리소스 대신 기지를 사용할 수 있었습니다.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- ../../base

patches:
- path: deployment-dev.yaml
- path: service-dev.yaml

패치 검토 및 적용

패치를 검토해 봅시다. 아래 명령을 사용하여 패치를 검토하고 모든 것이 올바른지 확인할 수 있습니다.

kustomize build overlays/dev

그러면 아래와 같이 Kubernetes 매니페스트가 렌더링됩니다.

보시 다시피 배포에서 복제본 수가 2로 증가했고 , 다양한 CPU 및 메모리 리소스와 서비스 유형이 NodePort로 변경되었습니다. 이제 이것이 개발 환경에 필요한 구성입니다.

다음 명령을 사용하여 사용자 지정 매니페스트를 배포할 수 있습니다.

kustomize build overlays/dev | kubectl apply -f -

다음 kubectl 명령을 사용할 수도 있습니다.

kubectl apply -k overlays/dev

Prod 오버레이 폴더

deployment-prod.yaml

프로덕션 배포에서는 배포 복제본 4개와 다양한 메모리, CPU 리소스를 사용하는 RollingUpdate 전략을 추가합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  template:
    replicas: 4 # Update the replica count to 3
    spec:
      containers:
      - name: nginx
        resources:
          limits:
            cpu: "1" # Lower CPU limit to 200m (0.2 CPU cores)
            memory: "1Gi" # Lower memory limit to 256 MiB
          requests:
            cpu: "500" # Lower CPU request to 100m (0.1 CPU cores)
            memory: "512Mi" # Lower memory request to 128 MiB
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

service-prod.yaml

서비스 유형을 NodePort로 변경하고 있습니다.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: NodePort

kustomization.yaml

prod kustomization.yaml에서 몇 가지 변경을 해야 하기 때문에 패치를 위해 두 파일의 절대 경로를 추가했습니다.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- ../../base

patches:
- path: deployment-prod.yaml
- path: service-prod.yaml

구성과 패치를 검토하려면 아래 명령을 다시 실행하세요.

kustomize build overlays/prod

또는 다음과 같이 kubectl 명령과 함께 Kustomize를 사용할 수 있습니다.

kubectl kustomize overlays/prod

패치 검토 및 적용

모든 것이 잘 되었다면 아래 명령을 실행하여 지금 배포할 수 있습니다.

kustomize build overlays/prod | kubectl apply -f -

또는 다음과 같이 kubectl 명령을 사용할 수 있습니다.

kubectl apply -k overlays/prod

배포 후 아래 명령을 실행하여 객체를 확인할 수 있습니다.

kubectl get deployments
kubectl get services
kubectl get pods

다음 명령을 사용하면 모든 객체를 한 번에 볼 수 있습니다.

kubectl get all

Configmap 및 Secret Generators를 Kustomize하세요

Kustomize에는 Configmap과 Secret을 생성하는 기능이 있습니다.

Kustomization YAML에는 두 개의 지원되는 필드가 있습니다.

configMapGenerator 및
비밀 생성기

Kuztomize Configmap Generators 가이드를 확인해 보세요. 여기에서 사용 사례와 워크플로가 실질적으로 설명되어 있습니다.

Kustomize 문제 해결 – 일반적인 문제

Kustomize 버전은 Kubernetes 클러스터 버전과 호환되어야 합니다. Kustomize는 이전 Kubernetes 버전에서 지원되지 않는 기능이나 변경 사항을 도입할 수 있습니다.
오버레이를 사용하여 사용자 지정을 적용하는 경우 파일에서 오버레이를 올바르게 지정했는지 확인하세요 kustomization.yaml. 각 오버레이는 올바른 경로와 함께 필드 아래에 나열되어야 합니다 . 적용된 변경 사항으로 최종 구성을 resources실행하거나 생성해야 합니다 kustomize build.kustomize build <overlay-path>
와 같은 오류 메시지가 나타나는 경우 "kustomize: command not found"Kustomize가 설치되어 있고 시스템 PATH에 포함되어 있는지 확인하세요.
Kustomize는 구성 및 사용자 정의를 정의하기 위해 YAML 파일을 사용합니다. YAML 파일이 올바르게 포맷되고, 올바르게 들여쓰기가 되어 있으며, 유효한 구문을 가지고 있는지 확인하십시오.

Kustomize 사용의 이점

Kustomize의 이점은 다음과 같습니다.

간소화된 구성 관리: Kustomize는 사용하기 쉽고, 구조적이고 모듈식 방식으로 구성을 정의할 수 있으므로 Kubernetes 구성을 보다 쉽게 관리하고 사용자 정의할 수 있습니다.
재사용성: Kustomize를 사용하면 모든 환경에서 기본 파일 중 하나를 재사용하고 각 환경에 대한 사양을 오버레이할 수 있습니다. 이렇게 하면 새 배포마다 처음부터 만들지 않고도 공통 구성을 재사용할 수 있으므로 시간과 노력을 절약할 수 있습니다.
버전 제어: Kustomize를 사용하면 Kubernetes 구성의 버전을 제어할 수 있으므로 필요한 경우 변경 사항을 추적하고 이전 구성으로 롤백하기가 더 쉽습니다.
템플릿 무료: Kustomize는 템플릿이 없습니다. Helm과 비교했을 때 모든 줄을 매개변수화할 필요 없이 Kubernetes API의 모든 기능을 표현합니다.
Kustomize는 Kubernetes 명령줄 인터페이스에서 기본적으로 실행할 수 있습니다.
Kustomize에는 리소스를 수정하는 변환기가 내장되어 있으며 플러그인 메커니즘을 통해 확장할 수 있습니다.
Kustomize에는 템플릿 언어가 없으므로 일반적인 YAML을 사용하여 구성을 빠르게 나타낼 수 있습니다.
Kustomize는 독립형 Golang 패키지와 CLI 도구로 제공되므로 사용자 도구 및 워크플로와 쉽게 통합할 수 있습니다.
kubectl 1.14 이상 버전이 있다면 Kustomize를 설치하지 않고도 사용할 수 있습니다. kubectl을 사용하면 템플릿을 건드리지 않고도 구성을 선언적으로 변경할 수 있습니다.

Kustomize 모범 사례

Kustomize의 모범 사례는 다음과 같습니다.

기본 리소스, 오버레이, 패치를 별도의 디렉토리에 보관하면 다양한 구성 간의 명확성과 분리를 유지하는 데 도움이 됩니다.
Kustomize를 사용하는 동안 일반적인 Kubernetes 모범 사례를 준수하는 것이 필수적입니다.
네임스페이스, 공통 메타데이터와 같은 공통 값을 기본 파일에 유지하도록 하세요.
개발 중이거나 git에 push하기 전에 kubectl kustomize cfg fmt file_name 명령을 실행하여 파일을 포맷하고 들여쓰기를 올바르게 설정하세요.
Kustomize 구성을 배포하기 전에 구성을 검증하고 철저한 테스트를 수행하여 구성이 예상대로 작동하는지 확인하세요.
Kustomize를 CI/CD(지속적인 통합/지속적인 배포) 파이프라인에 통합하여 배포 프로세스를 자동화하세요.
Kustomize는 edit 하위 명령을 사용하여 파일을 필수적으로 업데이트하는 기능을 제공합니다 kustomization.yaml. 따라서 레이블, 네임스페이스 등을 추가하고 이미지와 복제본을 수정하는 데 edit 명령을 사용합니다.

Kustomize 대 Helm

몇 가지 차이점은 다음과 같습니다.

Helm은 후크 및 릴리스 관리와 같은 고급 기능을 제공하여 복잡한 배포에 적합합니다. Kustomize는 더 간단하고 직관적입니다.
Helm은 복잡한 템플릿을 가지고 있는 반면, Kustomize에는 템플릿이 없습니다.
Kustomize는 별도의 설정이 필요하지 않습니다. 반면에 Helm은 설정해야 합니다.
Helm은 쉽게 공유하고 재사용할 수 있는 사전 구축된 차트를 대량으로 제공하는 반면, Kustomize는 구성을 공유할 수 있지만 중앙 저장소가 부족합니다.
Kustomize는 배우기 쉬운 반면, Helm은 차트와 템플릿과 같은 추가 개념을 도입하기 때문에 어려움이 있습니다.
Kustomize는 오버레이와 패치를 사용하여 기존 구성을 수정하는 반면, Helm은 차트를 사용하여 애플리케이션을 패키징하고 관리합니다.

Kustomize FAQs

Kutomize에 관해 자주 묻는 질문 중 일부를 살펴보겠습니다.

Kustomize는 Helm과 어떻게 다릅니까?

Kustomize와 Helm은 모두 Kubernetes를 위한 구성 관리 도구이지만, 접근 방식이 다릅니다. Kustomize는 템플릿을 사용하지 않고 구성을 관리하는 네이티브 및 선언적 방법을 제공하는 데 중점을 둡니다. 반면 Helm은 차트와 템플릿을 사용하여 애플리케이션을 패키징하고 배포합니다.

Kustomize를 어떻게 설치하나요?

Kustomize는 독립 실행형 바이너리로 배포되므로 다양한 플랫폼에 쉽게 설치할 수 있습니다.

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash

공식 GitHub 저장소에서 바이너리를 다운로드하거나 Homebrew(macOS/Linux용) 또는 Chocolatey(Windows용)와 같은 패키지 관리자를 사용할 수 있습니다.

brew install kustomize    //mac
choco install kustomize   //windows

Kustomize를 기존 Kubernetes 구성과 함께 사용할 수 있나요?

Kustomize는 기존 Kubernetes 구성을 관리하는 데 사용할 수 있습니다. 기존 YAML 파일이 있는 디렉토리에 Kustomization 파일을 만들고 필요에 따라 구성을 사용자 정의하기 위해 오버레이를 정의하는 것으로 시작할 수 있습니다.

Kustomize가 비밀 관리를 처리할 수 있나요?

Kustomize는 비밀 관리에 대한 지원을 제공합니다. Kustomization 파일에서 비밀 생성기를 정의할 수 있으며, 지정된 규칙에 따라 동적으로 비밀을 생성할 수 있습니다. 이를 통해 민감한 정보를 구성 파일에서 분리할 수 있습니다.

Kustomize는 GitOps 워크플로와 호환됩니까?

Kustomize는 GitOps 워크플로와 호환됩니다. 기본 구성, 오버레이 및 Kustomization 파일을 버전 제어하고 Git 및 CI/CD 파이프라인과 같은 도구를 사용하여 Kubernetes 구성을 관리하고 배포할 수 있습니다.

Kustomize는 Kubernetes에서 공식적으로 지원되나요?

Kustomize는 Kubernetes의 공식 하위 프로젝트이며 Kubernetes SIG-CLI(Special Interest Group – Command Line Interface) 커뮤니티에서 유지 관리합니다. 인기를 얻었으며 Kubernetes 생태계에서 널리 사용됩니다.

결론

이 Kustomize 튜토리얼에서 우리는 Kustomize가 어떤 문제를 해결하는지와 그 이점에 대해 논의했습니다. 나아가, 우리는 Kustomize의 설치 부분과 몇 가지 핵심 개념을 확인했습니다.

또한 Kustomize를 사용하여 Kubernetes에 애플리케이션을 배포하는 방법도 배웠습니다. 그런 다음 Secret/Config Map 생성기에 대해 이야기하고 Helm과 비교했습니다.

kubectlKustomize의 가장 큰 장점은 다른 프로그램 과 통합되어 있어서 사용하기 매우 쉽다는 점입니다 .

Kubernetes를 배우고 있다면 Kubernetes 학습 로드맵을 확인하여 Kubernetes에 대한 지식을 심화하세요.

저작자표시

'Kubernetes > tool' 카테고리의 다른 글

etcd 백업 (0)	2025.03.17
install kubenetes (0)	2025.03.04
Helm (외부자료) (0)	2025.02.27
(1) KIND란? (0)	2025.01.24
(2) KIND 활용 예제 MSA 샘플 (0)	2025.01.24

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

lumination