|
|
|
@@ -6,12 +6,12 @@ weight: 20
|
|
|
|
|
|
|
|
|
|
<!-- overview -->
|
|
|
|
|
|
|
|
|
|
[Kustomize](https://github.com/kubernetes-sigs/kustomize)는
|
|
|
|
|
[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을
|
|
|
|
|
[Kustomize](https://github.com/kubernetes-sigs/kustomize)는
|
|
|
|
|
[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을
|
|
|
|
|
통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다.
|
|
|
|
|
|
|
|
|
|
1.14 이후로, kubectl도
|
|
|
|
|
kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다.
|
|
|
|
|
1.14 이후로, kubectl도
|
|
|
|
|
kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다.
|
|
|
|
|
kustomization 파일을 포함하는 디렉터리 내의 리소스를 보려면 다음 명령어를 실행한다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -29,7 +29,7 @@ kubectl apply -k <kustomization_directory>
|
|
|
|
|
## {{% heading "prerequisites" %}}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다.
|
|
|
|
|
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
|
|
|
|
|
|
|
|
|
|
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
|
|
|
|
|
|
|
|
@@ -47,7 +47,7 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다.
|
|
|
|
|
|
|
|
|
|
### 리소스 생성
|
|
|
|
|
|
|
|
|
|
컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다.
|
|
|
|
|
컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다.
|
|
|
|
|
컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
|
|
|
|
|
Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다.
|
|
|
|
|
|
|
|
|
@@ -207,7 +207,7 @@ metadata:
|
|
|
|
|
|
|
|
|
|
### 교차 편집 필드 설정
|
|
|
|
|
|
|
|
|
|
프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다.
|
|
|
|
|
프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다.
|
|
|
|
|
교차 편집 필드를 설정하는 몇 가지 사용 사례는 다음과 같다.
|
|
|
|
|
|
|
|
|
|
* 모든 리소스에 동일한 네임스페이스를 설정
|
|
|
|
@@ -283,13 +283,13 @@ spec:
|
|
|
|
|
|
|
|
|
|
### 리소스 구성과 사용자 정의
|
|
|
|
|
|
|
|
|
|
프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서
|
|
|
|
|
관리하는 것은 일반적이다.
|
|
|
|
|
프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서
|
|
|
|
|
관리하는 것은 일반적이다.
|
|
|
|
|
Kustomize는 서로 다른 파일들로 리소스를 구성하고 패치나 다른 사용자 정의를 이들에 적용하는 것을 제공한다.
|
|
|
|
|
|
|
|
|
|
#### 구성
|
|
|
|
|
|
|
|
|
|
Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다.
|
|
|
|
|
Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다.
|
|
|
|
|
다음 예제는 디플로이먼트와 서비스로 구성된 NGINX 애플리케이션이다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -344,7 +344,7 @@ EOF
|
|
|
|
|
|
|
|
|
|
#### 사용자 정의
|
|
|
|
|
|
|
|
|
|
패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는
|
|
|
|
|
패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는
|
|
|
|
|
`patchesStrategicMerge`와 `patchesJson6902`를 통해 서로 다른 패치 메커니즘을 지원한다. `patchesStrategicMerge`는 파일 경로들의 리스트이다. 각각의 파일은 [전략적 병합 패치](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)로 분석될 수 있어야 한다. 패치 내부의 네임은 반드시 이미 읽혀진 리소스 네임과 일치해야 한다. 한 가지 일을 하는 작은 패치가 권장된다. 예를 들기 위해 디플로이먼트 레플리카 숫자를 증가시키는 하나의 패치와 메모리 상한을 설정하는 다른 패치를 생성한다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -432,10 +432,10 @@ spec:
|
|
|
|
|
- containerPort: 80
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해,
|
|
|
|
|
Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다.
|
|
|
|
|
Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이
|
|
|
|
|
`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해
|
|
|
|
|
모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해,
|
|
|
|
|
Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다.
|
|
|
|
|
Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이
|
|
|
|
|
`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해
|
|
|
|
|
디플로이먼트 오브젝트의 레플리카 개수를 증가시킬 수 있다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -508,7 +508,7 @@ spec:
|
|
|
|
|
- containerPort: 80
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는
|
|
|
|
|
패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는
|
|
|
|
|
기능도 제공한다. 예를 들어 `kustomization.yaml`의 `images` 필드에 신규 이미지를 지정하여 컨테이너에서 사용되는 이미지를 변경할 수 있다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -566,9 +566,9 @@ spec:
|
|
|
|
|
- containerPort: 80
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어,
|
|
|
|
|
디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자.
|
|
|
|
|
`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다.
|
|
|
|
|
가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어,
|
|
|
|
|
디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자.
|
|
|
|
|
`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다.
|
|
|
|
|
커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 `vars`를 통해 containers에 서비스 네임을 삽입할 수 있다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -655,11 +655,11 @@ spec:
|
|
|
|
|
|
|
|
|
|
## Base와 Overlay
|
|
|
|
|
|
|
|
|
|
Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는
|
|
|
|
|
사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가
|
|
|
|
|
될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로
|
|
|
|
|
다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
|
|
|
|
|
한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며,
|
|
|
|
|
Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는
|
|
|
|
|
사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가
|
|
|
|
|
될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로
|
|
|
|
|
다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
|
|
|
|
|
한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며,
|
|
|
|
|
이들의 위에 사용자 정의도 가질 수 있다.
|
|
|
|
|
|
|
|
|
|
다음은 base에 대한 예이다.
|
|
|
|
@@ -711,7 +711,7 @@ resources:
|
|
|
|
|
EOF
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을
|
|
|
|
|
이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을
|
|
|
|
|
서로 다른 overlay에 추가할 수 있다. 다음 예제는 동일한 base를 사용하는 두 overlay들이다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -732,7 +732,7 @@ EOF
|
|
|
|
|
|
|
|
|
|
## Kustomize를 이용하여 오브젝트를 적용/확인/삭제하는 방법
|
|
|
|
|
|
|
|
|
|
`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다.
|
|
|
|
|
`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다.
|
|
|
|
|
`-k`는 다음과 같이 kustomization 디렉터리를 가리키고 있어야 한다는 것을 주의한다.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
@@ -835,5 +835,3 @@ deployment.apps "dev-my-nginx" deleted
|
|
|
|
|
* [Kubectl Book](https://kubectl.docs.kubernetes.io)
|
|
|
|
|
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
|
|
|
|
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
June Yi