이 문서에서는 Tanzu Community Edition에서 사용할 패키지 작성에 대해 설명합니다. 패키지가 구현됨에 따라 시간이 지남에 따라 발전하는 설계 문서입니다. 이 자료는 설계 문서일 뿐만 아니라 패키징 프로세스를 안내합니다.
용어
확장, 추가 기능, 핵심 추가 기능, 사용자 관리 추가 기능 등에 대한 정의는 용어집을 참조하십시오. 이 문서의 대부분 패키징 세부 정보는 핵심 및 사용자 관리 패키지와 관련이 있습니다. 그러나 검색, 리포지토리 및 CLI 상호 작용에 대한 대부분의 세부 정보는 사용자 관리 패키지와만 관련이 있습니다.
패키지
외부 타사 소프트웨어 및 기능의 패키징은 Carvel 툴킷을 사용하여 이루어집니다. 최종 결과는 컨테이너 레지스트리에 저장된 OCI 번들입니다. 검색, 배포 및 관리 작업에는 아래와 같이 tanzu CLI가 사용됩니다.
$ tanzu package install gatekeeper --package-name gatekeeper.community.tanzu.vmware.com --version 3.2.3 --namespace default | Installing package 'gatekeeper.community.tanzu.vmware.com' / Getting package metadata for gatekeeper.community.tanzu.vmware.com - Creating service account 'gatekeeper-default-sa' \ Creating cluster admin role 'gatekeeper-default-cluster-role' - Creating package resource / Package install status: Reconciling Added installed package 'gatekeeper' in namespace 'default'
이 경험은 사용자 관리 패키지에 한정됩니다.
이러한 패키지의 검색, 배포 및 관리 방법에 대한 자세한 내용은 패키지 관리를 참조하십시오.
패키징 워크플로우
다음 흐름에서는 사용자 관리 패키지를 패키징하는 방법을 설명합니다. 이러한 단계는 다음 절에서 자세히 설명합니다.
1. 디렉토리 구조 생성
각 패키지는 패키지의 이름을 딴 별도의 디렉터리에 있습니다. create-package make 대상은 디렉토리와 기본 파일을 구성합니다. NAME 및 VERSION 변수를 설정하여 실행할 수 있습니다.
make create-package NAME=gatekeeper VERSION=3.2.3 ─╯ mkdir: created directory 'addons/packages/gatekeeper/3.2.3/bundle/.imgpkg' mkdir: created directory 'addons/packages/gatekeeper/3.2.3/bundle/config/overlay' mkdir: created directory 'addons/packages/gatekeeper/3.2.3/bundle/config/upstream' package bootstrapped at addons/packages/gatekeeper/3.2.3
위 스크립트는 다음과 같은 파일 및 디렉터리 구조를 생성합니다.
addons/packages/gatekeeper ├── 3.2.3 │ ├── README.md │ ├── bundle │ │ ├── .imgpkg │ │ ├── config │ │ │ ├── overlay │ │ │ ├── upstream │ │ │ └── values.yaml │ │ └── vendir.yml │ └── package.yaml └── metadata.yaml
파일 및 디렉터리는 다음 용도로 사용됩니다.
- README: 패키지의 설명서를 포함합니다.
- bundle: 패키지의 imgpkg 번들을 포함합니다.
- bundle/.imgpkg: 번들의 메타데이터를 포함합니다.
- bundle/config/upstream: 패키지의 배포 매니페스트를 포함합니다. 일반적으로 업스트림에서 조달됩니다.
- bundle/config/overlay: 업스트림 매니페스트 위에 적용된 패키지의 오버레이를 포함합니다.
- bundle/config/values.yaml: 사용자가 구성할 수 있는 값입니다.
- bundle/vendir.yml: 업스트림 리소스의 위치를 정의합니다.
- package.yaml: 패키지의 특정 버전에 대한 설명 메타데이터입니다.
- metadata.yaml: 패키지에 대한 설명 메타데이터입니다.
2. 매니페스트를 추가
업스트림과 정렬 상태를 유지하려면 수정되지 않은 매니페스트를 저장합니다. 예를 들어 gatekeeper의 업스트림 매니페스트가 여기에 있습니다. 업스트림 매니페스트의 구성을 저장하면 매니페스트를 쉽게 업데이트하고 오버레이를 통해 사용자 정의를 적용할 수 있습니다.
소스 업스트림 매니페스트의 무결성을 보장하기 위해 vendir가 사용됩니다. 매니페스트가 특정 커밋과 일치하도록 하는 잠금 파일을 다운로드하여 만듭니다.
bundle 디렉터리에서 vendir.yml 파일을 생성/수정하십시오. 다음은 gatekeeper에 대한 구성을 보여 줍니다.
apiVersion: vendir.k14s.io/v1alpha1
kind: Config
minimumRequiredVersion: 0.12.0
directories:
- path: config/upstream
contents:
- path: .
git:
url: https://github.com/open-policy-agent/gatekeeper
ref: v3.2.3
newRootPath: deploy사용할 수 있는 소스는 여러 가지가 있습니다. 패키지는 git 또는 githubReleases를 사용하여 버전을 잠글 수 있는 것이 이상적입니다. http 소스를 사용하는 것은 앞서 언급한 소스와 동일한 보장을 제공하지 않습니다.
이 구성은 벤더가 config/upstream 디렉토리를 관리함을 의미합니다. 자산을 다운로드하고 잠금 파일을 생성하려면 다음을 실행합니다.
vendir sync
이를 위한 make 작업도 있습니다.
make vendir-sync-package PACKAGE=gatekeeper VERSION=3.2.3
잠금 파일이 bundle/vendir.lock.yml에 생성됩니다. 여기에는 다음과 같은 잠금 메타데이터가 포함됩니다.
apiVersion: vendir.k14s.io/v1alpha1
directories:
- contents:
- git:
commitTitle: Prepare v3.2.3 release (#1084)...
sha: 15def468c9cbfffc79c6d8e29c484b71713303ae
tags:
- v3.2.3
path: .
path: config/upstream
kind: LockConfig위와 같이 하면 다음과 같이 디렉토리와 파일이 다음과 같이 표시됩니다.
addons/packages/gatekeeper ├── 3.2.3 │ ├── README.md │ ├── bundle │ │ ├── .imgpkg │ │ ├── config │ │ │ ├── overlays │ │ │ ├── upstream │ │ │ │ └── gatekeeper.yaml │ │ │ └── values.yaml │ │ ├── vendir.lock.yml │ │ └── vendir.yml │ └── package.yaml └── metadata.yaml
3. 오버레이 생성
업스트림에서 수정해야 하는 각 개체(예: Deployment)에 대해 오버레이 파일을 생성해야 합니다. 오버레이는 수정되지 않은 업스트림 매니페스트를 가져오고 위에 특정 구성을 적용하는 데 사용됩니다.
이전 단계에서 추가된 다음 gatekeeper.yaml을 고려합니다.
---
#! upstream.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: gatekeeper-deployment
labels:
app: gatekeeper
spec:
replicas: 1
selector:
matchLabels:
app: gatekeeper
template:
metadata:
labels:
app: gatekeeper
spec:
containers:
- name: gatekeeper
image: gatekeeper:1.14.2
ports:
- containerPort: 80metadata.labels를 정적 값으로 수정하고 spec.replicas를 사용자가 구성할 수 있는 값으로 수정한다고 가정합니다.
bundle/overlay 디렉토리에 overlay-deployment.yaml이라는 파일을 생성합니다.
---
#! overlay-deployment.yaml
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"Deployment", "metadata":{"name":"gatekeeper-deployment"}})
---
metadata:
labels:
#@overlay/match missing_ok=True
class: gatekeeper
#@overlay/match missing_ok=True
owned-by: tanzu
#@overlay/match by=overlay.subset({"kind":"Deployment", "metadata": {"name": "gatekeeper-deployment"}})
---
spec:
#@overlay/match missing_ok=True
replicas: #@ data.values.runtime.replicas⚠️ 컨테이너 이미지 필드를 템플릿화하거나 오버레이하지 마십시오. kbld는 이미지 다이제스트 SHA를 만들거나 참조하는 데 사용됩니다.
자세한 오버레이 설명서는 Carvel 사이트에서 확인할 수 있습니다.
4. 디폴트 값
위에서 정의한 모든 사용자 구성 가능한 값에 대해 values.yaml 파일에는 기본값과 매개 변수가 미치는 영향에 대한 문서가 포함되어야 합니다. 값이 업스트림 값을 재정의하는 경우 해당 업스트림 값을 사용하는 것이 좋습니다. 예를 들어 업스트림 기본 네임스페이스가 foo-ns인 경우 values.yaml 파일의 네임스페이스에 대한 기본 설정으로 foo-ns를 사용하는 것이 좋습니다.
bundle/config에서 values.yaml 파일을 생성/수정합니다.
#@data/values --- #! The namespace in which to deploy gatekeeper. namespace: gatekeeper #! The amount of replicas that should exist in gatekeeper. runtime: replicas: 3
[선택사항]: 템플리팅의 유효성을 확인
위의 항목을 사용하면 오버레이 및 템플리팅이 예상대로 작동하는지 확인할 수 있습니다. 개념 흐름은 다음과 같습니다.
위의 작업을 실행하려면 다음과 같이 ytt를 사용할 수 있습니다. 성공하면 변환된 매니페스트가 표시되고 그렇지 않으면 오류 메시지가 표시됩니다.
ytt -f addons/packages/gatekeeper/3.2.3/bundle/config
5. 이미지 다이제스트를 확인하고 참조
패키지의 무결성을 보장하려면 태그가 아닌 이미지 요약을 참조하는 것이 중요합니다. 태그의 기본 이미지는 임의로 변경될 수 있습니다. 다이제스트를 통해 SHA를 참조하면 모든 풀에서 일관성이 보장됩니다.
kbld는 images.yml이라는 이름을 가진 잠금 파일을 만드는 데 사용됩니다. 이 파일에는 ImagesLock 리소스가 포함되어 있습니다. ImagesLock은 go.sum과 유사합니다. 원본 매니페스트의 이미지 필드는 변환되지 않습니다. 대신 배포 시 SHA가 태그와 스왑 아웃됩니다. 그 관계는 다음과 같습니다.
모든 컨테이너 이미지 참조를 찾고 ImagesLock을 생성하고 다이제스트의 SHA가 참조되는지 확인하려면 다음과 같이 kbld를 실행합니다.
kbld --file addons/packages/gatekeeper/3.2.3/bundle \ --imgpkg-lock-output addons/packages/gatekeeper/3.2.3/bundle/.imgpkg/images.yml
이를 위한 만들기 작업도 있습니다.
make lock-package-images PACKAGE=gatekeeper VERSION=3.2.3
그러면 다음 파일 bundle/.imgpkg/images.yml이 생성됩니다.
---
apiVersion: imgpkg.carvel.dev/v1alpha1
images:
- annotations:
kbld.carvel.dev/id: openpolicyagent/gatekeeper:v3.2.3
image: index.docker.io/openpolicyagent/gatekeeper@sha256:9cd6e864...
kind: ImagesLock이 파일을 bundle/.imgpkg에 배치하면 bundle/config 디렉토리가 오염되지 않고 Kubernetes 클러스터에 배포될 위험이 있습니다. 이 때 다음 디렉터리 및 파일이 있어야 합니다.
addons/packages/gatekeeper ├── 3.2.3 │ ├── README.md │ ├── bundle │ │ ├── .imgpkg │ │ │ └── images.yml │ │ ├── config │ │ │ ├── overlays │ │ │ │ ├── overlay-deployment.yaml │ │ │ ├── upstream │ │ │ │ └── gatekeeper.yaml │ │ │ └── values.yaml │ │ ├── vendir.lock.yml │ │ └── vendir.yml │ └── package.yaml └── metadata.yaml
6. 구성을 번들하고 레지스트리에 배포
모든 매니페스트 및 구성은 OCI 호환 패키지로 번들됩니다. 이렇게 하면 릴리스 시 구성의 불변성을 보장할 수 있습니다. 번들은 컨테이너 레지스트리에 저장됩니다.
imgpkg은 번들을 생성하고 컨테이너 레지스트리에 푸시하는 데 사용됩니다. 기본 컨테이너 레지스트리를 활용하므로 번들을 만들 시스템에 인증을 설정해야 합니다(예: docker login).
패키지에 대한 메타데이터를 캡처하려면 다음 Bundle 파일을 bundle/.imgpkg/bundle.yaml에 추가하십시오.
apiVersion: imgpkg.carvel.dev/v1alpha1
kind: Bundle
metadata:
name: gatekeeper
authors:
- name: Joe Engineer
email: engineerj@example.com
websites:
- url: github.com/open-policy-agent/gatekeeper다음 패키지는 번들을 푸시합니다.
imgpkg push \ --bundle $(OCI_REGISTRY)/gatekeeper/3.2.3:$(BUNDLE_TAG) \ --file addons/packages/gatekeeper/3.2.3/bundle
이를 위한 make 작업도 있습니다.
make push-package PACKAGE=gatekeeper VERSION=3.2.3
그 결과는 다음과 같습니다. 성공적인 푸시가 끝나면 imgpkg이 패키지의 URL 및 다이제스트를 보고합니다. 이 정보는 다음 단계에서 사용됩니다.
===> pushing gatekeeper/3.2.3 dir: . dir: .imgpkg file: .imgpkg/bundle.yml file: .imgpkg/images.yml dir: config dir: config/overlays file: config/overlays/overlay-deployment.yaml dir: config/upstream file: config/upstream/gatekeeper.yaml file: config/values.yaml file: vendir.lock.yml file: vendir.yml Pushed 'projects.registry.vmware.com/tce/gatekeeper@sha256:b7a21027...' Succeeded
7. 패키지 CR을 생성/수정
Package는 소프트웨어에 대한 메타데이터 및 템플리트 정보를 정의하는 데 사용됩니다. Package CR은 모든 애드온에 대해 생성되며 imgpkg 번들을 찾을 수 있는 OCI 레지스트리를 가리킵니다. 또한 이 파일은 버전, 라이센스, 릴리스 노트와 같은 패키지에 대한 일부 버전별 정보도 캡처합니다. Package CR은 다른 패키지와 함께 디렉터리 구조에 저장되며 최종적으로 PackageRepository를 형성합니다. 많은 패키지를 포함하는 PackageRepository 번들이 아닌 Package CR이 클러스터에 배포됩니다. PackageRepository가 배치되면 kapp-controller가 클러스터에서 패키지 CR를 만듭니다. 이 관계는 다음과 같이 볼 수 있습니다.
gatekeeper용 Package의 예는 다음과 같습니다.
apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
name: gatekeeper.community.tanzu.vmware.com.3.2.3
namespace: gatekeeper
spec:
refName: gatekeeper.community.tanzu.vmware.com
version: 3.2.3
releaseNotes: "gatekeeper 3.2.3 https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.2.3"
licenses:
- "Apache 2.0"
template:
spec:
fetch:
- imgpkgBundle:
image: projects.registry.vmware.com/tce/gatekeeper@sha256:b7a21027...
template:
- ytt:
paths:
- config/
- kbld:
paths:
- "-"
- .imgpkg/images.yml
deploy:
- kapp: {}- metadata.name: spec.refName과 version 연속입니다(아래 참조).
- spec.refName: 소비자에게 표시될 이름입니다. 패키지 간에 고유해야 합니다.
- version: 이 패키지 인스턴스의 버전 번호이며 semver를 사용해야 합니다. 사용된 버전은 패키지된 소프트웨어의 버전을 반영해야 합니다. 예를 들어 gatekeeper의 기본 컨테이너 이미지가 버전 3.2.3인 경우 이 패키지는 동일해야 합니다.
- spec.template.spec.fetch[0].imgpkgBundle.image: OCI 레지스트리에 있는 이 패키지 위치의 URL입니다. 이 값은 imgpkg push 명령의 결과에서 가져옵니다.
8. openAPIv3 스키마 생성과 패키지에 내장
아래 언급된 단계에 따라 openAPIv3 스키마 생성을 시작하고, 패키지로 지정합니다. 이 프로세스는 csi, cpi와 같이 정의된 샘플 값을 가진 패키지와 secretgen-controller 및 kapp-controller를 싫어하는 패키지 두 가지 모두에 대해 작동합니다. 샘플 값이 있는 패키지의 경우 sample-values 디렉토리가 버전 디렉토리에 존재한다고 가정합니다.
- 지정된 데이터 값 파일에 대한 스키마 파일(schema.yaml)을 생성합니다. ytt에서는 템플릿에서 데이터 값을 사용하려면 먼저 데이터 값을 선언해야 합니다. 일반적으로 데이터 값 스키마 스키마 작성 방법을 확인하여 스키마를 작성할 때 사용할 수 있는 다양한 주석을 살펴봅니다.
- 다음 make 타겟을 사용해서 openAPI v3 스키마를 생성합니다.
secretgen-controller 패키지를 예로 사용하여 스키마를 생성하고 패키지 yaml 파일에 포함시키겠습니다.
cd ~/community-edition/ make generate-openapischema-package PACKAGE=secretgen-controller VERSION=0.7.1
이 작업은 다음 두 가지 중요한 단계를 수행합니다.
- 값이 선언된 스키마를 준수하는지 확인하는 중입니다. 그렇지 않으면 오류가 발생합니다.
- 유효성을 성공적으로 검사한 경우, openAPIv3 스키마를 생성하고 package.yaml에 내장합니다.
아래 예를 붙여 넣은 secretgen-controller를 위해 생성된 package.yaml에 대한 출력입니다. secretgen-controller용 패키지에 내장된 openAPIv3 스키마 또한 볼 수 있습니다.
apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
name: secretgen-controller.community.tanzu.vmware.com.0.7.1
spec:
refName: secretgen-controller.community.tanzu.vmware.com
version: 0.7.1
releaseNotes: secretgen-controller 0.7.1 https://github.com/vmware-tanzu/carvel-secretgen-controller
licenses:
- Apache 2.0
template:
spec:
fetch:
- imgpkgBundle:
image: projects.registry.vmware.com/tce/secretgen-controller@sha256:4d47a1ece799e3b47428e015804e4c822b58adf8afdcf67175e56245b09fbcd2
template:
- ytt:
paths:
- config/
- kbld:
paths:
- '-'
- .imgpkg/images.yml
deploy:
- kapp: {}
valuesSchema:
openAPIv3:
type: object
additionalProperties: false
description: OpenAPIv3 Schema for secretgen-controller
properties:
secretgenController:
type: object
additionalProperties: false
description: Configuration for secretgen-controller
properties:
namespace:
type: string
default: secretgen-controller
description: The namespace in which to deploy secretgen-controller
createNamespace:
type: boolean
default: true
description: Whether to create namespace specified for secretgen-controller3. 이제 패키지에 make push-package를 사용할 수 있습니다.
이것은 두 가지 단계를 수행합니다.
- package에 내장된 openAPIv3 스키마가 생성된 openAPIv3 스키마와 정확히 일치하는지 확인합니다. 또한 패키지의 imgpkg 번들이 openAPI 스키마 없이 푸시하는 것을 방지합니다.
- 올바른 스키마가 포함된 경우 패키지의 imgpkg 번들을 빌드하고 푸시합니다.
openAPIv3 스키마가 내장된 다음에 secretgen-controller 패키지의 make push-package를 실행하기 위한 출력입니다.
===> pushing secretgen-controller/0.7.1 dir: . dir: .imgpkg file: .imgpkg/bundle.yml file: .imgpkg/images.yml dir: config dir: config/overlays file: config/overlays/change-namespace.yaml file: config/schema.yaml dir: config/upstream file: config/upstream/secretgen-controller.yaml file: config/values.star file: config/values.yaml file: vendir.lock.yml file: vendir.yml Pushed 'projects.registry.vmware.com/tce/secretgen-controller@sha256:4d47a1ece799e3b47428e015804e4c822b58adf8afdcf67175e56245b09fbcd2' Succeeded
이제 위의 출력에서 SHA를 복사하여 package.yaml의 적절한 위치에 붙여 넣습니다.
이제 패키지에 대해 생성된 파일로 PR을 만들 준비가 되었습니다.
9. 패키지 메타데이터
패키지를 생성하는 마지막 단계는 metadata.yaml 파일을 업데이트하는 것입니다. 이 파일에는 버전에 국한되지 않고 패키지에 대한 일반 정보가 포함되어 있습니다. 다음은 파일에 캡처된 메타데이터 유형에 대한 개요입니다.
- 알기 쉬운 이름을 표시
- 간결하고 긴 설명
- 제작 조직
- 메인테이너
- 설명 범주
- SVG 로고
이 시점에서 패키지가 생성, 푸시 및 문서화되었습니다. 패키지가 패키지 리포지토리의 일부로 클러스터에 배포될 준비가 되었습니다.
10. 패키지 저장소 만들기
Tanzu Community Edition은 메인 리포지토리 정의 파일 main.yaml이 보관되는 addons/repos 디렉토리를 유지합니다. 이 파일은 리포지토리에 포함할 패키지의 특정 버전을 정의하는 간단한 사용자 지정 yaml 파일입니다. 이 파일의 예는 다음과 같습니다.
---
packages:
- name: gatekeeper
versions:
- 3.2.3이 파일에서 패키지 리포지토리를 생성하는 makefile 태스크 generate-package-repo가 있습니다. kapp-controller는 현재 패키지 리포지토리가 imgpkgBundle 형식이어야 합니다. 이 작업은 해당 번들을 생성합니다. 작업이 실행되면 make generate-package-repo CHANNEL=main으로 하여 다음 단계를 수행합니다.
- addons/repos/generated/main 디렉토리 만들기
- imgpkg를 위한 addons/repos/generated/main/.imgpkg 만들기
- addons/repos/generated/main/packages/packages.yaml 만들기
- 패키지에 대해 반복하고 패키지 metadata.yaml과 특정 패키지 버전의 패키지를 연결합니다.저장소의 패키지에 yaml을 입력합니다.saml 파일
- imgpkg images.yml 잠금 파일을 만듭니다.
- 번들을 OCI 레지스트리에 푸시합니다.
패키지 리포지토리에 태그 :latest가 지정됩니다
완료되면 클러스터에 패키지 리포지토리를 설치하기 위한 지침이 표시됩니다.
tanzu package repository add repo-name --namespace default --url projects.registry...
Tanzu Community Edition은 주요 평판을 유지하지만 개발 작업이나 여러 버전의 foo 소프트웨어를 제공하기 위해 베타 또는 패키지 foo 평판을 만들 수 있습니다.
일반적인 패키지 고려 사항
배포 후 kapp-controller가 리소스를 변환 방지
kapp-controller에 의해 배포되고 관리되는 리소스가 다른 프로세스에 의해 변환될 수 있습니다. 예를 들어 configmap을 operator와 함께 배포할 수 있습니다. Operator가 configmap을 변환하면 kapp-controller가 업데이트를 트리거하고 configmap을 원래 상태로 다시 새로 고칩니다.
이러한 동작을 방지하기 위해 skip 값으로 설정된 kapp.k14s.io/update-strategy이라는 이름의 주석이 추가됩니다. 오버레이를 통해 이 작업을 수행할 수 있습니다. 다음은 업스트림 configmap에 대해 이 설정을 수행하는 방법의 예입니다.
업스트림 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: config-domain
namespace: knative-serving
labels:
serving.knative.dev/release: "v0.20.0"
annotations:
knative.dev/example-checksum: "74c3fc6a"
data:
_example: |
################################
# #
# EXAMPLE CONFIGURATION #
# #
################################Overlay
---
#! overlay-configmap-configdomain.yaml
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"ConfigMap", "metadata":{"name":"config-domain"}})
---
metadata:
annotations:
#@overlay/match missing_ok=True
kapp.k14s.io/update-strategy: skip위의 내용을 적용하면 업데이트 시 config-domain ConfigMap이 변환되지 않습니다.
이 주석에 대한 자세한 내용은 kapp Apply Ordering 설명서를 참조하십시오.
자산의 배치 순서를 확인
패키지가 다른 구성 요소보다 먼저 특정 구성 요소를 배포하는 것이 중요할 수 있습니다. 예를 들어 ValidatingWebhookConfiguration을 적용하기 전에 검증 웹훅을 충족하는 배포를 실행할 수 있습니다. 이렇게 하면 엔드포인트에 대한 API 트래픽을 차단하기 전에 유효성 검사를 수행하는 서비스가 가동되고 정상인지 확인할 수 있습니다.
이러한 동작을 방지하기 위해 주석 kapp.k14s.io/change-group 및 kapp.k14s.io/change-rule이 사용됩니다. 오버레이를 통해 이 작업을 수행할 수 있습니다. 다음은 업스트림 배포 및 ValidatingWebhookConfiguration에 대해 이 설정을 수행하는 방법의 예입니다.
Upstream
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
control-plane: controller-manager
gatekeeper.sh/operation: audit
gatekeeper.sh/system: "yes"
name: gatekeeper-controller-manager
namespace: gatekeeper-system
annotations:
spec:
---
apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
creationTimestamp: null
labels:
gatekeeper.sh/system: "yes"
name: gatekeeper-validating-webhook-configuration
annotations:
# it is very important this resource (ValidatingWebhookConfiguration) is applied
# last. Otherwise, it can wire up the admission request before components required
# to satisfy it are deployed.
kapp.k14s.io/change-group: "tce.gatekeeper/vwc"
kapp.k14s.io/change-rule: "upsert after upserting tce.gatekeeper/deployment"
webhooks:Overlay
---
#! overlay-deployment-gatekeeperaudit.yaml
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"Deployment", "metadata":{"name":"gatekeeper-controller-manager"}})
---
metadata:
annotations:
#@overlay/match missing_ok=True
kapp.k14s.io/change-group: "tce.gatekeeper/deployment"---
#! overlay-validatingwebhookconfiguration-gatekeeper.yaml
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"ValidatingWebhookConfiguration", "metadata":{"name":"gatekeeper-validating-webhook-configuration"}})
---
metadata:
annotations:
#@overlay/match missing_ok=True
kapp.k14s.io/change-group: "tce.gatekeeper/vwc"
#@overlay/match missing_ok=True
kapp.k14s.io/change-rule: "upsert after upserting tce.gatekeeper/deployment"위의 오버레이를 적용하면 배포가 정상일 때까지 ValidatingWebhookConfiguration이 적용되지 않습니다.
이 주석에 대한 자세한 내용은 kapp Apply Ordering 설명서를 참조하십시오.
설계 보류 중인 세부 정보
이 섹션에서는 설계 작업이 필요한 문제를 다룹니다.
여러 PackageRepository 인스턴스의 버전 관리
PackageRepository의 도입으로 시간이 지남에 따라 증가하는 패키지 인스턴스(패키지+버전)의 수를 어떻게 처리할 것인지 결정해야 합니다.
- 모든 최신 패키지에 대해 default repo를 유지하고 있습니까?
- 오래된 패키지는 어떻게 제공하나요?
출처 : https://tanzucommunityedition.io/docs/v0.10/designs/package-process/
