[CICD] Kustomzie

ArgoCD에 배포되는 여러 코드를 보면 Kustomzie를 사용하는 경우를 많이 보이고 많이 효율적인것 같아서 한번 찾아보고

 Kustomzie가 무엇인지 어떻게 사용하는지 정리해봤다.

 

 Kustomzie란?

쿠버네티스 리소스의 구성파일인  yaml파일을 변경하지 않고 필드를 재정의하여 새로운 쿠버네티스 리소스를 생성하는 도구로 Kustomize 공식문서에 따르면 아래와 같이 소개하고 있다

 

1. 템플릿이 없는 방식으로 구성 파일을 커스터마이징 하는 데 도움이 됩니다.

2. 커스터마이징을 더 쉽게 하기 위해 Generator, Transformer와 같은 여러 편리한 방법을 제공합니다.

 

해당 글에 내용을 바탕으로 실습했다 깃 허브도 블로그 분 주소다.

https://malwareanalysis.tistory.com/402

github 링크: https://github.com/choisungwook/kustomize-example

 

github repo를 다운로드 받고 example_1폴더에 있는 파일을 살펴보면 아래와 같다

pod.yaml과 Kustomzation.yaml 파일이 있고 내용은 아래와 같다.

pod.yaml

Kustomization.yaml

우선 각 파일을 설명 전에 Kustomzation.yaml를 배포해보자 

여기서 kustomize build 명령어가 kubectl에 내장되어 별도 설치가 필요 없다고한다.

즉 kubectl kustomize명령어로 kustomize를 빌드 및 실행 가능하다 명령어는 아래와 같다.

 

# kustomize통해서 생성할 리소스 빌드
kubectl kustomize ./
# kustomize.yaml 파일 통해서 배포
kubectl kustomize ./ | kubectl apply -f -

생성할 리소스를 빌드해보면 위에서 확인 pod.yaml의 이미지가 nginx:latest에서 kustomize.yaml에서 명시한 nginx:1.23.1로 바뀐것을 확인할 수 있다.

 

즉 처음에 보여줬던 아래 그림처럼 yaml과 kustomize를 합쳐 필드가 재정의된 yaml을 생성할 수 있다.

그럼  kustomize.yaml이 무엇일까? 

kustomize가 실행될 때 어떤 필드를 재정의할 것인가를 설정하는 파일로 여러가지 필드를 사용하여 설정할 수 있고 기본 필드는 4개의 필드가 존재한다. 

• resources : kustomize를 적용할 쿠버네티스 리소스(yaml파일)
• generators : 새로 생성할 필드를 설정
• transformers : 기존 필드 변경을 설정
• validators : 검증

공식문서 https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/

 

resources

위에서 보았듣이 resources 필드는 kustomize를 적용할 yaml파일을 선택한다.

 

generators

Generators는 새로운 쿠버네티스 리소스 또는 필드를 생성한다.

configmap, secret 등을 생성 한다고 한다. repo의 example_3폴더에 있는 예제를 보면 아래와 같다

Kustomization.yaml

application.properties에는 Foo=Bar 값만 넣은 상태고 Kustomization.yaml에는 generator가 명시된 상태이다

이 상태에서 출력하면 아래와 같이 configmap이 생성되고 Foo=Bar가 담겨져 있는것을 확인 가능하며 metadata.name이름 뒤에는 랜덤값이 붙는다. (generatorOptions 설정을 추가하여 랜덤값을 제거 가능)

 

계속해서 generators를 알아보면 repo의 example_4 폴더를 확인하면 폴더와 내용은 아래와 같다.

example_3 폴더에서 configmap가 마운트된 디플로이먼트 yaml 파일이다.

deployment.yaml의 마운트 내용

이 상태에서 출력하면 아래와 같이 configMap의 이름을 example-configmap-1라 명시해도 generators를 통해 생성된 configmap이름에 랜덤값도 포함되어있는것을 확인 가능하다.

 

transformers

Transformers는 필드 값을 변경한다. 처음에 배포한 Kustomization.yaml 파일에서 images 또한 transformer의 하나로

nginx:latest에서 nginx:1.23.1로 변한것을 확인 가능 

즉 필드는 resources → generators → transformers → validators 순서로 실행되며

1) kustomize.yaml에 resources에 정의된  yaml파일을 읽고

2) generators(새로운 필드를 추가) 후

3) transformers(필드를 수정)하고 validators(검증)을 한다.

 

 

 cross-cutting

 Generators 또는 Transformers로 필드가 재정의될 때 참조되는 다른 필드도 같이 재정의된다.

즉 Label, annotation 같이 수정되면 해당 리소스에 영향이 미치는 다른 필드들도 교차편집 된다

metadata.label뿐만 아니라 spec에 있는 label로 변경되며 annotation또한 metadata.annotations과 sepc.annotations 필드가 수정된다.

 

repo의 example_5 폴더를 확인하면 아래와 같다.

해당 파일들을 빌드해보면 kustomize.yaml파일에서 명시된 부분 뿐만아니라 해당 리소스에 영향이 미치는 다른 필드들도 교차편집 된다

 

또한 연관관계가 설정된 쿠버네티스 필드를 감지해서 자동으로 수정한다.

예를 들어 Ingress는 service name을 참조하는데, kustomize 명령어로 service name이 변경되면 Ingress의 service name도 자동 수정된다.

 

repo의 example_8폴더를 가고 파일들 확인해보면 아래와 같다.

아래와 같이 리소스 네임에 dev-를 추가하고 dev-helloworld라는 라벨을 추가했다.

빌드한 값은 아래와 같이고 결과 값처럼  label, name이 재정의되고 참조되는 필드 값도 같이 수정된 것을 확인할 수 있다.

 

base/overlays

kustomize 실행결과를 다른 디렉토리에서 불러서 사용하는 것을 Base/Overlay라고한다

주로 환경을 dev, stage, prod처럼 구분해서 배포를 진행할 때 사용한다 한다.

 

repo의 example_9폴더에 있는 예제이며 base폴더와 overlays폴더가 있습니다. 그리고 각각 폴더에 kustomization.yaml파일이 있다

각 디렉토리에 kustomize.yaml은 다음과 같다.

여기서 overlays 디렉토리에서 빌드해보면 base에서 kustomize.yaml에 명시된 deployment가 가져와진다.

위처럼 bases만 사용해서 타 디렉토리에서  kustomize.yaml에 명시된 deployment를 가져오고 transfer를 사용하여 이름 앞에 dev-를 넣어준것을 확인할 수 있다.

 

 

참조 : https://malwareanalysis.tistory.com/402