Kustomize

Gom3rye 2025. 8. 11. 17:45

728x90

Kustomize

묶어서 배포할 수 있게 해주는 것

쿠버네티스 커뮤니티 sig-cli가 제공하는 매니페스트 템플레이팅 툴
환경마다 매니페스트를 생성하거나 특정 필드를 덮어쓰는 기능이 있어서 효율적으로 매니페스트를 생성할 수 있다.
헬름은 설정을 채워나가는 방식인데 반해 kustomize는 기본값을 덮어쓰는 형태로 설정할 수 있는 것이 특징이다.
kustomize라는 별도의 명령어가 있었는데 현재는 kubectl의 하위 명령어

여러 매니페스트 결합

sample-deployment.yaml 파일 작성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas:
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.16
        
# 리소스 생성
kubectl apply -f sample-deployment.yaml

service-lb.yaml 작성

apiVersion: v1
kind: Service
metadata:
  name: sample-lb
spec:
  type: LoadBalancer
  ports:
  - name: "http-port"
    protocol: "TCP"
    port: 8080
    targetPort: 80
    nodePort: 30082
  selector:
    app: sample-app
    
# 리소스 생성
kubectl apply -f service-lb.yaml
# 지금은 잘 되지만 sample-deployment로 만들어진 pod를 지우고 curl 192.168.56.240:8080 (EXTERNAL-IP:PORT) 해보면 안 됨
# -> pod가 없기 때문 => 애플리케이션을 만들고 service를 만들어야 하는데 그러지 못한 케이스

애플리케이션 만들고 service 만들기

service 지우고 애플리케이션 지우기

2개의 리소스 파일을 묶어주는 kustomization.yaml 파일 생성

resources:
- sample-deployment.yaml
- service-lb.yaml

# 빌드 결과 미리보기 (See the rendered YAML from Kustomize.)
kubectl kustomize kustomization.ymal파일경로
kubectl kustomize .
# 적용
kubectl apply -k kustomization.yaml파일경로
kubectl apply -k .
# 확인
kubectl get svc
## service가 만들어져 있다.
## sample-lb    LoadBalancer   10.105.104.213   192.168.56.240   8080:30082/TCP   2m51s
# 삭제
kubectl delete -k .

네임스페이스 바꾸기

namespace: sample-namespace
resources:
- sample-deployment.yaml
- service-lb.yaml

# 네임스페이스 없으면 만들기
kubectl create namespace sample-namespace
# 리소스 생성
kubectl apply -k .
# 네임스페이스가 sample-namespace로 바뀌었기 때문에 kubectl get pods 하면 아무것도 안나옴
# 해당 네임스페이스에서 확인
kubectl get pods -n sample-namespace
## sample-deployment-774c976f8d-mn66j   1/1     Running   0     21s

공통된 이름 부여

namePrefix와 nameSuffix를 이용하면 공통된 이름을 부여할 수 있다.

namePrefix: prefix-
nameSuffix: -suffix
resources:
- sample-deployment.yaml
- service-lb.yaml

# kubectl get service -n sample-namespace로 항상 지워줘야 한다. (nodeport는 중복 안되니까)
kubectl apply -k .
## service/prefix-sample-lb-suffix created
## deployment.apps/prefix-sample-deployment-suffix created
kubectl get pods
## prefix-sample-deployment-suffix-774c976f8d-9lp5m   1/1     Running   0          43s

공통 메타데이터 설정

commonLabel이나 commonAnnotations를 이용하면 리소스에 공통 레이블이나 어노테이션을 부여할 수 있다.

commonLabels:
  label1: label1-val
commonAnnotations:
  annotation: annotation1-val

resources:
- sample-deployment.yaml
- service-lb.yaml

# 리소스 생성
kubectl apply -k .
kubectl describe pod sample-deployment
## 결과
Labels:           app=sample-app
                  label1=label1-val

이미지 변경

images 를 사용하면 리소스에 사용되는 이미지를 변경할 수 있다.
이름에 일치하는 이미지는 모두 변경되기 때문에 여러 deployment 등이 이는 경우 모두에 영향을 준다.

images:
- name: nginx
  newName: amsy810/echo-nginx
  newTag: v2.0
resources:
- sample-deployment.yaml
- service-lb.yaml

오버레이로 값 덮어 쓰기

메타 데이터 계열의 필드는 이전 방식으로 수정이 가능하다.
세부적인 설정은 오버레이 기능을 이용해서 리소스에 대해 패치해서 변경 가능하다.
서비스 환경이나 스테이징마다 레플리카 수나 CPU/메모리 리소스 변경을 쉽게 수행한다.
디렉토리 안에 기본 매니페스트를 등록해두고 bases로 설정한다.
서비스 환경이나 스테이징 또는 시스템의 환경에 따라 설정을 덮어쓰기 하는 매니페스트를 patches로 지정한다.

실습

kustomization.yaml 파일 수정

resources:
  - sample-deployment.yaml
  - service-lb.yaml

patches:
  - path: patch-replicas.yaml
    target:
      kind: Deployment
      name: sample-deployment

patch-replicas.yaml 파일 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 10

kubectl apply -k . 후에 kubectl kustomize . 을 해보면 replicas가 10으로 바뀐 것을 볼 수 있다.

Production 환경과 Staging 환경 나누어서 배포

staging 디렉토리 생성
디렉토리 내부에 kustomization.yaml 생성

resources:
  - ../../base

patches:
  - path: patch-replicas.yaml
    target:
      kind: Deployment
      name: sample-deployment

images:
  - name: nginx
    newTag: staging

staging 디렉토리 내부에 patch-replicas.yaml 파일 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 1

production 디렉토리 생성
디렉토리 내부에 kustomization.yaml 생성

resources:
  - ../../base

patches:
  - path: patch-replicas.yaml
    target:
      kind: Deployment
      name: sample-deployment

images:
  - name: nginx
    newTag: production

production 디렉토리 내부에 patch-replicas.yaml 파일 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 1

Configmap과 시크릿의 동적 생성

새로 생성된 컨피그맵의 이름은 데이터 구조에서 계산 해시값이 접미사로 부여된다.
컨피그맵 데이터가 변경된 경우에는 새로운 이름으로 컨피그맵이 생성된다.
새로운 컨피그맵이 만들어지더라도 이전 컨피그맵은 그대로 남아 있다.
실습
- generate-sample 이라는 디렉토리를 생성
- sample-deployment.yaml 파일 작성
- vi generate-sample/sample-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.16
        envFrom:
        - configMapRef:
            name: generated-configmap

값을 저장할 sample.txt 파일 생성 (/generate-sample 폴더 안에)
- vi generate-sample/sample.txt
- this is a testfile. 작성
kustomization.yaml 파일 생성

resources:
  - sample-deployment.yaml
configMapGenerator:  
  - name: generated-configmap
    literals:
     - KEY1=VAL1
    files:
      - ./sample.txt
     
kyla@masternode:~/kustomize$ kubectl apply -k generate-sample
## configmap/generated-configmap-bdk6h5tgt4 created
## deployment.apps/sample-deployment created

→ 현재까지의 위치는 모두 kustomize 폴더고 kubectl kustomize generate-sample 을 해보면 generated-configmpa이 생성되는 걸 미리 볼 수 있다.

kubectl 의 kustomize 하위 명령

kustomize: 결과로 만들어질 yaml 파일의 결과를 보여준다.
- kubectl kustomize base
- kubectl kustomize generate-sample
apply -k: 적용
get -k: 정보 조회

describe -k: 자세히 보기
build 결과 저장 (-o 옵션 이용)

Helm

쿠버네티스의 패키지 관리자

레드햇 계열의 Yum이나 데비안 계열의 APT에 해당하는 개념
오픈 소스 소프트웨어
레디스 클러스터 구성이나 워드 프레스 환경 등의 소프트웨어를 하나의 명령어로 쿠버네티스 클러스터에 배포할 수 있다.
롤링 업데이트 등에서 지원하는 것이 많아서 쿠버네티스에 최적화된 설정으로 사용할 수 있는 장점이 있다.

헬름 설치

다운로드 받아서 직접 설치: curl -sL https://get.helm.sh/helm-v버전-운영체제종류-amd64.tar.gz -o 저장파일경로
- curl -sL https://get.helm.sh/helm-v3.18.4-linux-amd64.tar.gz -o /tmp/hel.tar.gz
- 압축 해제: tar -xvf /tmp/hel.tar.gz
- helm을 아무데서나 호출할 수 있도록 /usr/local/bin으로 이동
  - sudo mv linux-amd64/helm /usr/local/bin/helm
- 실행 권한 부여
  - sudo chmod 755 /usr/local/bin/helm
- 자동 완성 기능 활성화
  - source <(helm completion bash)
스크립트를 받아서 설치 (자동으로 최신 버전을 받아서 설치)
패키지 매니저(apt, yum, brew 등)를 이용해서 설치

Chart

쿠버네티스 리소스들을 패키지 형태로 묶어 놓은 배포 단위
쿠버네티스 앱을 배포하기 위한 설치 패키지
역할
- 애플리케이션 설치 자동화: Deployment, Service, ConfigMap, Ingress 등 여러 리소스를 한 번에 설치
- 환경별 설정 분리: values.yaml 파일에서 dev/prod 설정만 변경해서 재사용
- 버전 관리: 차트 버전을 지정해서 동일한 배포를 재현 가능
- 의존성 관리: 다른 차트와 함께 배포 가능

저장소 추가

헬름은 기본적으로 저장소가 설정되어 있지 않는다.
stable 저장소 추가
- 헬름이 관리하는 공식 차트는 각각의 성숙도에 따라 stable과 incubator로 구분한다.
- 각 차트는 github에서 관리한다.
- stable과 incubator의 차이
  - 업데이트 가능 여부
  - 데이터 영속성 가능
  - 보안
  - 적절한 기본값이 제공
  - 쿠버네티스 모범 사례에 따라 설정

저장소 추가

helm repo add stable https://charts.helm.sh/stable

bitnami 저장소 추가
- bitnami 저장소: Bitnami가 유지 관리하는 인기 오픈소스 애플리케이션 차트를 모아 놓은 공식 차트 레포지토리
- MySQL, WordPress, Redis, Nginx, Kafka 같은 앱들을 쉽게 배포 가능
- 대부분 production ready 수준의 앱들이라서 테스트 뿐 아니라 배포에도 사용 가능하다.

저장소 추가

helm repo add bitnami https://charts.bitnami.com/bitnami

저장소 확인

helm repo list

저장소 업데이트
- helm repo update

wordpress 설치 및 삭제

검색 (저장소만 검색)

helm search repo wordpress

artifact hub

여러 헬름 저장소를 통합 검색할 수 있는 서비스
헬름 커뮤니티가 관리하는 저장소는 물론 다양한 OSS(Open Source Software) 가 제공하는 헬름 저장소도 등록되어 있다.
여기서 검색할 때는 repo 대신에 hub를 설정해서 검색
- helm search hub wordpress
설정 가능한 파라미터 확인
- helm show values bitnami/wordpress
readme 확인
- helm show readme bitnami/wordpress

설치 및 삭제

helm install sample-wordpress bitnami/wordpress --version 25.0.8

helm uninstall sample-wordpress

728x90