<div id="readability-page-1" class="page"><cite>seungkyua@gmail.com</cite>
 2023. 2. 6. 15:26
 <div>
 TACO 에서는 Kubernetes 에 워크로드를 배포하기 위해서 Decapod 라는 자체 빌드 및 배포 체계를 갖고 있다. Decapod 는 Helm Chart 의 value override 기능과 Kustomize 의 plugin 기능을 개발하여 적용한 또 다른 value override 를 모두 사용하고 있다.
Helm Chart 와 Kustomize 모두 value oeverride 기능을 모두 제공하는데 왜 2가지를 모두 사용할까? 그 이유는 Helm Chart 는 이미 다양하게 제공되고 있는 것들이 많아 가져다 쓰면 되고, value 값들을 하나의 yaml 파일로 합쳐서 관리하기 위해서 Kustomize 의 plugin 을 개발하여 사용하고 있다.
즉, Decapod 체계는 다음과 같은 장점이 있다.
<ol>
<li>Helm Chart 기반으로 default custom value 값을 지정할 수 있다. (decapod-base-yaml)</li>
<li>Kustomize plugin 을 개발하여 각 사이트마다 갖는 여러 helm chart 의 고유 value 값들을 <code>1개의 yaml 파일</code>에 합쳐서 관리할 수 있다.</li>
</ol>
하지만 Helm Chart 를 제공하지 않는 app 들은 어떻게 지원할까? 예를 들어 Kubeflow 의 경우 Helm Chart 를 제공하지 않지만 Kustomize 를 제공하고 있으니 이를 지원하는 방법도 필요해 보인다.
<h2>Kustomize 활용을 위한 기본 디렉토리 (base repo)</h2>
kustomize 는 설치되어 있다고 가정하고 바로 활용을 위한 기본 디렉토리를 살펴보자.
<pre><code>$ tree
.
├── LICENSE
├── README.md
└── service-mesh
 └── nginx
 ├── aws-msa-reference
 │ ├── kustomization.yaml
 │ └── site-values.yaml
 └── base
 ├── kustomization.yaml
 ├── nginx-deployment.yaml
 ├── nginx-service.yaml
 └── site-values.yaml</code></pre>
소스 홈 디렉토리 아래에는 <code>service-mesh</code> 라는 서비스 디렉토리가 있다. 여기에는 nginx, istio, jaeger, kaili 등 다양한 application 이 동시에 설치되어야 하는데 각 app 을 나타내는 디렉토리 (여기서는 편의상 nginx 만 설명한다)가 존재한다.
nginx 설치를 위해서는 보통 nginx-deployment.yaml 과 nginx-service.yaml 이 필요하며 이를 base 디렉토리에 위치시킨다.
<pre><code>$ cat nginx-deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: nginx-blue
 name: nginx-blue
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx-blue
 version: blue
 template:
 metadata:
 labels:
 app: nginx-blue
 version: blue
 spec:
 containers:
 - image: seungkyua/nginx:blue
 name: nginx </code></pre>
<pre><code>$ cat nginx-service.yaml
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-blue-svc
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 selector:
 app: nginx-blue
 version: blue
 type: LoadBalancer</code></pre>
여기까지는 Helm chart 와 동일하다. 다만 chart 는 template 을 활용하여 value 값을 override 할 수 있는데 반하여 kustomize 는 kustomize.yaml 을 통해서 value 값을 override 할 수 있다.
kustomize.yaml 을 지정하고 기본적으로 업데이트할 디폴트 값을 site-values.yaml 이라는 파일에 지정한다.
<code>resources</code> 는 kubernetes 에 설치할 리소스들에 대한 yaml 리스트이고 <code>patchesStrategicMerge</code> 는 kustomize 에서 제공하는 yaml 합성 기능 중에 하나의 방법이다.
아래의 경우에는 site-values.yaml 값과 nginx-deployment.yaml, nginx-service.yaml 값을 합쳐서 만든다.
중복되는 경우에는 site-values.yaml 값을 우선시 한다.
<pre><code>$ cat kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- nginx-deployment.yaml
- nginx-service.yaml

patchesStrategicMerge:
- site-values.yaml</code></pre>
site-values.yaml 에는 override 할 default value 값을 가진다.
deployment 는 replicas 값을, service 는 NodePort 타입과 nodePort 값을 가진다. (이것을 base 값이라 생각하면 이해하기 쉽다. nginx helm chart 는 기본값이 replicas 1 인데 우리는 기본 값을 replicas 2 로 의도한 것이다.)
<pre><code>$ cat site-values.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-blue
spec:
 replicas: 2

---
apiVersion: v1
kind: Service
metadata:
 name: nginx-blue-svc
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 nodePort: 32080
 type: NodePort</code></pre>
여기서 잠깐. nginx-deployment.yaml 과 nginx-service.yaml 값을 처음부터 바꿔서 넣으면 site-values.yaml 이 필요하지 않을 텐데 왜 굳이 이걸 만들지?
그건 kustomize 혹은 helm chart 를 제공하기 때문에 가져다 쓰는 경우도 많은데 원래의 작성 값들을 바꿔서 관리하지 않으려고 하는 의도이다. 업스트림에서 만들어 진 것이 있으면 원본은 그대로 가져다 쓰는 것이 추후 유지 보수 관점에서 편리하기 때문이다.
이제 여기까지 만든 내용을 kustomize 로 build 해 보자.
<pre><code>$ cd service-mesh/nginx

$ kustomize build base

--- output ---
apiVersion: v1
kind: Service
metadata:
 name: nginx-blue-svc
spec:
 ports:
 - nodePort: 32080
 port: 80
 protocol: TCP
 targetPort: 80
 selector:
 app: nginx-blue
 version: blue
 type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: nginx-blue
 name: nginx-blue
spec:
 replicas: 2
 selector:
 matchLabels:
 app: nginx-blue
 version: blue
 template:
 metadata:
 labels:
 app: nginx-blue
 version: blue
 spec:
 containers:
 - image: seungkyua/nginx:blue
 name: nginx</code></pre>
<h2>Site 별 디렉토리 (Site repo)</h2>
이제 특정한 사이트에 다른 값으로 설치해야 한다고 가정해 보자. 
aws-msa-reference 라는 신규 사이트 디렉토리를 만들고 kustomize.yaml 과 value 값을 모아둔 site-values.yaml 을 만든다.
<pre><code>$ tree
.
├── LICENSE
├── README.md
└── service-mesh
 └── nginx
 ├── aws-msa-reference
 │ ├── kustomization.yaml
 │ └── site-values.yaml
 └── base
 ├── kustomization.yaml
 ├── nginx-deployment.yaml
 ├── nginx-service.yaml
 └── site-values.yaml</code></pre>
지금은 service-mesh/nginx 디렉토리 아리에 aws-msa-reference 가 있지만 이 디렉토리는 다른 repo 에서 관리하다가 kustomize build 를 하려할 때 해당 디렉토리로 복사해 오는 방법을 쓸 수 있다. (decapod 에서는 실제로 decapod-site 라는 repo 에 따로 사이트 값들을 관리하고 build 할 때 복사하는 방식을 사용하고 있다)
kustomize.yaml 과 site-values.yaml 을 보자.
<pre><code>$ cat kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base

patchesStrategicMerge:
- site-values.yaml</code></pre>
<pre><code>$ cat site-values.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-blue
spec:
 replicas: 3

---
apiVersion: v1
kind: Service
metadata:
 name: nginx-blue-svc
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 type: LoadBalancer</code></pre>
새로운 신규 사이트에는 replicas 를 3으로 Service Type 을 LoadBalancer 로 설치하고자 한다.
이를 build 하면 다음과 같다.
<pre><code>$ kustomize build aws-msa-reference

--- output ---
apiVersion: v1
kind: Service
metadata:
 name: nginx-blue-svc
spec:
 ports:
 - nodePort: 32080
 port: 80
 protocol: TCP
 targetPort: 80
 selector:
 app: nginx-blue
 version: blue
 type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: nginx-blue
 name: nginx-blue
spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx-blue
 version: blue
 template:
 metadata:
 labels:
 app: nginx-blue
 version: blue
 spec:
 containers:
 - image: seungkyua/nginx:blue
 name: nginx</code></pre>
결과가 site 별로 지정한 값으로 잘 변경되었다.
<h2>어디에 적용할까?</h2>
kustomize 로 빌드된 결과 yaml 들을 특정 repo 에 저장하고 <code>Argo CD</code> 와 같은 tool 을 적용하면 효과적인 <code>GitOps</code> 체계를 만들 수 있다.
<code>Tekton pipeline</code> 이나 <code>Argo workflow</code>, <code>Jenkins pipeline</code> 으로 CI 를 구축하고 <code>Argo CD</code> 로 CD 를 연결하면 <code>GitOps CICD</code> 를 구축할 수 있다. (이것까지 글로 써볼까? ㅎ)

 
 
 </div></div>

안승규(Ahn Seungkyu)의 블로그 (Stay hungry, stay foolish)

TACO 에서는 Kubernetes 에 워크로드를 배포하기 위해서 Decapod 라는 자체 빌드 및 배포 체계를 갖고 있다. Decapod 는 Helm Chart 의 value override 기능과 Kustomize 의 plugin 기능을 개발하여 적용한 또 다른 value override 를 모두 사용하고 있다.
Helm Chart 와 Kustomize 모두 value oeverride 기능을 모두 제공하는데 왜 2가지를 모두 사용할까? 그 이유는 Helm Chart 는 이미 다양하게 제공되고 있는 것들이 많아 가져다 쓰면 되고, value 값들을 하나의 yaml 파일로 합쳐서 관리하기 위해서 Kustomize 의 plugin 을 개발하여 사용하고 있다.
즉, Decapod 체계는 다음과 같은 장점이 있다.
Helm Chart 기반으로 default custom value 값을 지정할 수 있다. (decapod-base-yaml)
Kustomize plugin 을 개발하여 각 사이트마다 갖는 여러 helm chart 의 고유 value 값들을 1개의 yaml 파일에 합쳐서 관리할 수 있다.
하지만 Helm Chart 를 제공하지 않는 app 들은 어떻게 지원할까? 예를 들어 Kubeflow 의 경우 Helm Chart 를 제공하지 않지만 Kustomize 를 제공하고 있으니 이를 지원하는 방법도 필요해 보인다.
Kustomize 활용을 위한 기본 디렉토리 (base repo)
kustomize 는 설치되어 있다고 가정하고 바로 활용을 위한 기본 디렉토리를 살펴보자.
$ tree
.
├── LICENSE
├── README.md
└── service-mesh
    └── nginx
        ├── aws-msa-reference
        │   ├── kustomization.yaml
        │   └── site-values.yaml
        └── base
            ├── kustomization.yaml
            ├── nginx-deployment.yaml
            ├── nginx-service.yaml
            └── site-values.yaml
소스 홈 디렉토리 아래에는 service-mesh 라는 서비스 디렉토리가 있다. 여기에는 nginx, istio, jaeger, kaili 등 다양한 application 이 동시에 설치되어야 하는데 각 app 을 나타내는 디렉토리 (여기서는 편의상 nginx 만 설명한다)가 존재한다.
nginx 설치를 위해서는 보통 nginx-deployment.yaml 과 nginx-service.yaml 이 필요하며 이를 base 디렉토리에 위치시킨다.
$ cat nginx-deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue
  name: nginx-blue
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-blue
      version: blue
  template:
    metadata:
      labels:
        app: nginx-blue
        version: blue
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx 
$ cat nginx-service.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue
    version: blue
  type: LoadBalancer
여기까지는 Helm chart 와 동일하다. 다만 chart 는 template 을 활용하여 value 값을 override 할 수 있는데 반하여 kustomize 는 kustomize.yaml 을 통해서 value 값을 override 할 수 있다.
kustomize.yaml 을 지정하고 기본적으로 업데이트할 디폴트 값을 site-values.yaml 이라는 파일에 지정한다.
resources 는 kubernetes 에 설치할 리소스들에 대한 yaml 리스트이고 patchesStrategicMerge 는 kustomize 에서 제공하는 yaml 합성 기능 중에 하나의 방법이다.
아래의 경우에는 site-values.yaml 값과 nginx-deployment.yaml, nginx-service.yaml 값을 합쳐서 만든다.
중복되는 경우에는 site-values.yaml 값을 우선시 한다.
$ cat kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- nginx-deployment.yaml
- nginx-service.yaml
patchesStrategicMerge:
- site-values.yaml
site-values.yaml 에는 override 할 default value 값을 가진다.
deployment 는 replicas 값을, service 는 NodePort 타입과 nodePort 값을 가진다. (이것을 base 값이라 생각하면 이해하기 쉽다. nginx helm chart 는 기본값이 replicas 1 인데 우리는 기본 값을 replicas 2 로 의도한 것이다.)
$ cat site-values.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-blue
spec:
  replicas: 2
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 32080
  type: NodePort
여기서 잠깐. nginx-deployment.yaml 과 nginx-service.yaml 값을 처음부터 바꿔서 넣으면 site-values.yaml 이 필요하지 않을 텐데 왜 굳이 이걸 만들지?
그건 kustomize 혹은 helm chart 를 제공하기 때문에 가져다 쓰는 경우도 많은데 원래의 작성 값들을 바꿔서 관리하지 않으려고 하는 의도이다. 업스트림에서 만들어 진 것이 있으면 원본은 그대로 가져다 쓰는 것이 추후 유지 보수 관점에서 편리하기 때문이다.
이제 여기까지 만든 내용을 kustomize 로 build 해 보자.
$ cd service-mesh/nginx
$ kustomize build base
--- output ---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - nodePort: 32080
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue
    version: blue
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue
  name: nginx-blue
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-blue
      version: blue
  template:
    metadata:
      labels:
        app: nginx-blue
        version: blue
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx
Site 별 디렉토리 (Site repo)
이제 특정한 사이트에 다른 값으로 설치해야 한다고 가정해 보자. 
aws-msa-reference 라는 신규 사이트 디렉토리를 만들고 kustomize.yaml 과 value 값을 모아둔 site-values.yaml 을 만든다.
$ tree
.
├── LICENSE
├── README.md
└── service-mesh
    └── nginx
        ├── aws-msa-reference
        │   ├── kustomization.yaml
        │   └── site-values.yaml
        └── base
            ├── kustomization.yaml
            ├── nginx-deployment.yaml
            ├── nginx-service.yaml
            └── site-values.yaml
지금은 service-mesh/nginx 디렉토리 아리에 aws-msa-reference 가 있지만 이 디렉토리는 다른 repo 에서 관리하다가 kustomize build 를 하려할 때 해당 디렉토리로 복사해 오는 방법을 쓸 수 있다. (decapod 에서는 실제로 decapod-site 라는 repo 에 따로 사이트 값들을 관리하고 build 할 때 복사하는 방식을 사용하고 있다)
kustomize.yaml 과 site-values.yaml 을 보자.
$ cat kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base
patchesStrategicMerge:
- site-values.yaml
$ cat site-values.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-blue
spec:
  replicas: 3
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  type: LoadBalancer
새로운 신규 사이트에는 replicas 를 3으로 Service Type 을 LoadBalancer 로 설치하고자 한다.
이를 build 하면 다음과 같다.
$ kustomize build aws-msa-reference
--- output ---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - nodePort: 32080
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue
    version: blue
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue
  name: nginx-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-blue
      version: blue
  template:
    metadata:
      labels:
        app: nginx-blue
        version: blue
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx
결과가 site 별로 지정한 값으로 잘 변경되었다.
어디에 적용할까?
kustomize 로 빌드된 결과 yaml 들을 특정 repo 에 저장하고 Argo CD 와 같은 tool 을 적용하면 효과적인 GitOps 체계를 만들 수 있다.
Tekton pipeline 이나 Argo workflow, Jenkins pipeline 으로 CI 를 구축하고 Argo CD 로 CD 를 연결하면 GitOps CICD 를 구축할 수 있다. (이것까지 글로 써볼까? ㅎ)
카카오스토리
트위터
페이스북

Kustomize 활용법 (feat. GitOps 로 가는 길)

댓글