Kustomize Glossary

출처 : https://kubectl.docs.kubernetes.io/references/kustomize/glossary/

Application

애플리케이션은 데이터베이스가 지원하는 웹서버 앞의 로드 밸런서와 같이 공통된 목적으로 관련된 k8 리소스의 그룹입니다. 리소스 라벨링, 이름 지정 및 메타데이터 체계는 지금까지 목록 및 제거와 같은 집단 작업을 위해 리소스를 함께 그룹화하는 데 사용되어 왔습니다.

이 제안에서는 이 아이디어를 보다 공식적으로 설명하고 애플리케이션 수준 작업과 대시보드를 지원하기 위해 애플리케이션이라는 새로운 k8s 리소스에 대해 설명합니다.

kustomize는 k8s 리소스를 구성하며, 제안된 애플리케이션 리소스는 또 다른 리소스일 뿐입니다.

apply

k8s의 컨텍스트에서 동사 apply는 클러스터를 변경하기 위한 kubectl 명령과 진행 중인 API 엔드포인트를 가리킨다.

전체 리소스 목록의 형태로 원하는 것을 클러스터에 적용한다.

클러스터는 이를 이전에 적용된 상태 및 실제 상태와 병합하여 클러스터의 조정 루프가 생성하려고 시도하는 새로운 원하는 상태에 도달합니다. 이것이 k8s에서 레벨 기반 상태 관리의 기초입니다.

base

베이스(base)는 다른 kustomization이 참조하는 kustomization입니다.

오버레이를 포함한 모든 kustomization는 다른 kustomization의 기반이 될 수 있습니다.

베이스는 자신을 참조하는 오버레이에 대한 지식이 없습니다.

간단한 gitops 관리의 경우, 베이스 구성은 해당 목적 전용 git 리포지토리의 유일한 콘텐츠가 될 수 있다. 오버레이도 마찬가지입니다. 리포지토리를 변경하면 빌드, 테스트 및 배포 주기가 생성될 수 있습니다.

bespoke configuration

bespoke configuration은 특정 조직에서 자체 목적을 위해 내부적으로 만들고 유지 관리하는 kustomization 및 일부 리소스입니다.

bespoke configuration과 관련된 워크플로는 다른 사람의 업그레이드를 주기적으로 캡처하는 개념이 없기 때문에 기성 구성과 관련된 워크플로보다 더 간단합니다.

custom resource definition

Custom Resource Definition(CRD 사양)를 만들어 k8s API를 확장할 수 있습니다.

이것은 ConfigMaps, Deployments 등과 같은 기본 리소스와 함께 사용할 수 있는 완전히 새로운 리소스인 사용자 지정 리소스(CD)를 정의합니다.

Kustomize는 CD를 사용자 정의할 수 있지만 그렇게 하려면 구조를 올바르게 해석할 수 있도록 해당 CRD도 제공해야 합니다.

declarative application management

Kustomize는 k8 클러스터 관리에 관한 일련의 모범 사례인 선언적 애플리케이션 관리를 지원하고자 합니다.

간단히 말해, kustomize는 다음을 수행해야 합니다.

• 맞춤형, 기성품, 상태 비저장, 상태 저장 등 모든 구성에서 작동합니다.
• 일반적인 사용자 정의 및 변형 생성(예: 개발 대 스테이징 대 프로덕션)을 지원합니다.
• 네이티브 k8s API를 숨기지 않고 노출하고 가르치세요.
• 버전 관리 통합에 마찰 없이 검토 및 감사 추적을 지원하세요.
• 유닉스 방식으로 다른 도구와 함께 작성하세요.
• 템플릿, 도메인별 언어 등의 경계를 넘나들며 다른 목표를 달성하는 것을 피하세요.

generator

generator는 리소스를 그대로 사용하거나 transformer에 공급할 수 있는 리소스를 만듭니다.

gitops

git 리포지토리를 단일 데이터 소스로 사용하고 해당 데이터가 변경되면 조치(예: 빌드, 테스트 또는 배포)를 취하는 Devops 또는 CICD 워크플로입니다.

kustomization

kustomization이라는 용어는 kustomization.yaml 파일 또는 더 일반적으로는 kustomization.yaml 파일과 이 파일이 즉시 참조하는 모든 상대 파일 경로(URL 지정이 필요 없는 모든 로컬 데이터)를 포함하는 디렉터리(루트)를 가리킨다.

즉, 누군가 kustomize와 함께 사용할 수 있는 kustomization을 제공하면 다음과 같은 형태가 될 수 있습니다.

• kustomization.yaml이라는 파일 하나,
• (해당 YAML 파일과 그 파일이 참조하는 것을 포함하는) tarball,
• git 아카이브(같은 형태),
• git 리포지토리에 대한 URL 등입니다.

kustomization 파일에는 다음 네 가지 범주에 속하는 필드가 포함됩니다:

• resources – 사용자 지정할 기존 리소스. 예시 필드: resources, crds.
• generators – 새로 만들어야 할 리소스. 예제 필드: configMapGenerator(레거시), secretGenerator(레거시), generators(v2.1).
• transformers – 앞서 언급한 리소스에 대해 수행할 작업. 예시 필드: namePrefix, nameSuffix, images, commonLabels, patchesJson6902 등 및 보다 일반적인 transformers(v2.1) 필드.
• meta – 위의 모든 또는 일부에 영향을 줄 수 있는 필드. 예시 필드: 변수, 네임스페이스, apiVersion, 종류 등.

kustomization root

kustomization.yaml 파일을 바로 포함하는 디렉토리입니다.

kustomization 파일이 처리될 때 루트 외부의 파일에 액세스할 수 있거나 액세스할 수 없을 수 있습니다.

리소스 YAML 파일이나 ConfigMap 또는 Secret을 위한 name=value 쌍을 포함하는 텍스트 파일, 패치 변환에 사용할 패치를 나타내는 파일과 같은 데이터 파일은 루트 내부 또는 아래에 있어야 하므로 상대 경로로만 지정됩니다.

이 보안 기능을 완화하기 위해 특수 플래그(v2.1에서는 –load_restrictions none)가 제공되어 패치 파일을 둘 이상의 kustomization에서 공유할 수 있도록 허용합니다.

다른 kustomization(kustomization.yaml 파일이 포함된 다른 디렉토리)은 URL, 절대 경로 또는 상대 경로로 참조할 수 있습니다.

kustomization A가 kustomization B에 종속되어 있는 경우

• B는 A를 포함하지 않을 수 있습니다.
• B는 일시적으로라도 A에 종속되지 않을 수 있습니다.

A가 B를 포함할 수 있지만 이 경우 A가 B의 리소스에 직접 종속되도록 하고 B의 kustomization.yaml 파일을 제거하는 것이 가장 간단할 수 있습니다(즉, B를 A에 흡수).

일반적으로 B는 A와 형제 관계에 있는 디렉토리에 있거나 완전히 독립된 git 리포지토리에 있으며 모든 kustomization에서 참조할 수 있습니다.

일반적인 레이아웃은 다음과 같다.

├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── overlays
    ├── dev
    │   ├── kustomization.yaml
    │   └── patch.yaml
    ├── prod
    │   ├── kustomization.yaml
    │   └── patch.yaml
    └── staging
        ├── kustomization.yaml
        └── patch.yaml

세 개의 루트 dev, prod 및 staging(아마도)은 모두 기본 루트를 참조합니다. 확실히 하려면 kustomization.yaml 파일을 검사해야 한다.

kubernetes

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈 소스 시스템입니다.

흔히 k8s로 약칭합니다.

kubernetes-style object

쿠버네티스에서 요구하는 필드가 포함된 YAML 또는 JSON 파일로 표현되는 객체. 기본적으로 유형을 식별하는 kind 필드, 특정 인스턴스를 식별하는 메타데이터/이름 필드, 버전을 식별하는 apiVersion 필드(둘 이상의 버전이 있는 경우)만 있습니다.

kustomize

kustomize는 k8s 스타일 객체를 대상으로 하는 선언적 구성의 템플릿 없는 구조화된 사용자 지정을 지원하는 명령줄 도구입니다.

kustomize가 k8s를 대상으로 한다는 것은 API 리소스, 이름, 레이블, 네임스페이스 등과 같은 k8s 개념 및 리소스 패치의 의미를 어느 정도 이해하고 있다는 것을 의미합니다.

kustomize는 DAM의 구현입니다.

off-the-shelf configuration

off-the-shelf 구성은 다른 사람들이 사용할 수 있도록 의도적으로 어딘가에 게시한 리소스 및 kustomization 지정입니다.

예를 들어 다음과 같은 github 리포지토리를 만들 수 있습니다:

github.com/username/someapp/
  kustomization.yaml
  deployment.yaml
  configmap.yaml
  README.md

그런 다음 누군가가 이 리포지토리를 fork하고(github에서) 로컬 디스크에 포크를 복제하여 커스터마이징할 수 있습니다.

이 복제본은 추가 커스터마이징을 위한 사용자 자체 오버레이의 베이스 역할을 할 수 있습니다.

overlay

오버레이는 다른 kustomization에 의존하는 kustomization입니다.

오버레이가 참조하는 파일 경로, URI 또는 기타 방법을 통한 kustomization을 베이스라고 합니다.

오버레이는 베이스가 없으면 사용할 수 없습니다.

오버레이는 다른 오버레이의 베이스 역할을 할 수 있습니다.

오버레이는 공통 베이스의 다양한 변형(예: 개발, QA, 스테이징 및 프로덕션 환경 변형)을 만들기 때문에 둘 이상 있을 때 가장 의미가 있습니다.

이러한 변형은 동일한 전체 리소스를 사용하며 배포의 복제본 수, 특정 파드에 대한 CPU, 컨피그맵에 사용되는 데이터 소스 등 비교적 간단한 방식으로 달라집니다.

하나는 다음과 같이 클러스터를 구성합니다:

 kustomize build someapp/overlays/staging |\
     kubectl apply -f -

 kustomize build someapp/overlays/production |\
     kubectl apply -f -

베이스의 사용은 암시적입니다. 오버레이의 kustomization은 베이스를 가리킵니다.

루트도 참조하세요.

package

패키지라는 단어는 kustomize에서 의미가 없습니다. kustomize는 예를 들어 apt 또는 rpm과 같은 전통적 패키지 관리 도구와 혼동해서는 안 되기 때문입니다.

patch

리소스를 수정하는 일반적인 지침입니다.

비슷한 기능을 하지만 표기법이 다른 두 가지 대체 기술, 즉 전략적 병합 패치와 JSON 패치가 있습니다.

patchStrategicMerge

patchStrategicMerge는 strategic-merge-style 패치(SMP)입니다.

SMP는 k8s 리소스에 대한 불완전한 YAML 사양처럼 보입니다. SMP에는 패치할 리소스의 그룹/버전/종류/이름을 설정하는 TypeMeta 필드와 새 필드 값(예: 이미지 태그)을 지정하기 위한 중첩 구조에 들어갈 수 있는 나머지 필드만 포함됩니다.

기본적으로 SMP는 값을 대체합니다. 이는 일반적으로 대상 값이 단순한 문자열인 경우에 바람직하지만 대상 값이 목록인 경우에는 바람직하지 않을 수 있습니다.

이 기본 동작을 변경하려면 지시어를 추가하세요. YAML 패치에서 인식되는 지시어는 대체(기본값)와 삭제(이 참고 사항 참조)입니다.

사용자 정의 리소스의 경우 SMP는 json 병합 패치로 취급됩니다.

재미있는 사실 – 모든 리소스 파일을 SMP로 사용할 수 있으며, 동일한 그룹/버전/종류/이름을 가진 다른 리소스의 일치하는 필드를 덮어쓰되 다른 모든 필드는 그대로 유지합니다.

TODO(모노폴): 예제에 ptr을 추가합니다.

patchJson6902

patchJson6902는 쿠버네티스 리소스와 리소스를 변경하는 방법을 지정하는 JSONPatch를 참조한다.

패치Json6902는 패치전략병합이 할 수 있는 거의 모든 작업을 수행할 수 있지만 구문은 더 간결하다. 이 예제를 참조하세요.

plugin

kustomize에 의해 사용되지만 반드시 kustomize로 컴파일되지는 않는 코드 덩어리로, kustomization의 일부로 쿠버네티스 리소스를 생성 및/또는 변환하는 데 사용된다.

자세한 내용은 여기를 참고한다.

resource

REST-ful API의 컨텍스트에서 리소스는 GET, PUT 또는 POST와 같은 HTTP 작업의 대상 오브젝트이다. k8s는 클라이언트와 상호 작용할 수 있는 REST-ful API 서페이스를 제공한다.

리소스는 배포 또는 컨피그맵과 같은 k8s API 개체를 설명하는 YAML 또는 JSON 파일의 루트 상대 경로이거나, kustomization의 경로 또는 kustomization으로 리졸브되는 URL입니다.

보다 일반적으로 리소스는 종류와 메타데이터/이름 필드가 있는 개체를 정의하는 모든 올바른 YAML 파일일 수 있습니다.

root

kustomization root 참조.

sub-target / sub-application / sub-package

사물이 아닌 sub-whatever입니다. 베이스와 오버레이만 있습니다.

target

target은 kustomize build하기 위한 인자입니다:

 kustomize build $target

target은 kustomization의 경로 또는 URL이어야 합니다.

target은 적용 작업에 보낼 사용자 지정 리소스를 만드는 데 필요한 모든 정보를 포함하거나 참조합니다.

대상은 base 또는 overlay일 수 있습니다.

transformer

트랜스포머는 리소스를 수정하거나 단순히 리소스를 방문하여 kustomize 빌드 과정에서 리소스에 대한 정보를 수집할 수 있습니다.

variant

variant(변형)은 클러스터에서 기본에 오버레이를 적용한 결과입니다.

예를 들어 staging 오버레이와 production 오버레이는 모두 공통 베이스를 수정하여 별개의 이형 변형을 만듭니다.

스테이징 변형은 품질 보증 테스트에 노출되거나 다음 프로덕션 버전의 모습을 보고자 하는 일부 외부 사용자에게 노출되는 리소스 집합입니다.

프로덕션 변종은 프로덕션 트래픽에 노출되는 리소스 집합으로, 많은 수의 복제본과 더 높은 CPU 및 메모리 요청을 사용하는 배포를 사용할 수 있습니다.