4.9. 사용자 정의 카탈로그 관리
클러스터 관리자 및 Operator 카탈로그 관리자는 OpenShift Container Platform의 OLM(Operator Lifecycle Manager)에서 번들 형식을 사용하여 패키지된 사용자 정의 카탈로그를 생성하고 관리할 수 있습니다.
Kubernetes는 후속 릴리스에서 제거된 특정 API를 주기적으로 사용하지 않습니다. 결과적으로 Operator는 API를 제거한 Kubernetes 버전을 사용하는 OpenShift Container Platform 버전에서 시작하여 제거된 API를 사용할 수 없습니다.
클러스터가 사용자 정의 카탈로그를 사용하는 경우 Operator 작성자가 워크로드 문제를 방지하고 호환되지 않는 업그레이드를 방지하는 방법에 대한 자세한 내용은 OpenShift Container Platform 버전과의 Operator 호환성 제어를 참조하십시오.
추가 리소스
4.9.1. 사전 요구 사항
-
opm
CLI 를 설치합니다.
4.9.2. 파일 기반 카탈로그
파일 기반 카탈로그는 OLM(Operator Lifecycle Manager) 카탈로그 형식의 최신 버전입니다. 일반 텍스트 기반(JSON 또는 YAML)과 이전 SQLite 데이터베이스 형식의 선언적 구성 진화이며 완전히 이전 버전과 호환됩니다.
OpenShift Container Platform 4.11부터 기본 Red Hat 제공 Operator 카탈로그는 파일 기반 카탈로그 형식으로 제공됩니다. 더 이상 사용되지 않는 SQLite 데이터베이스 형식으로 릴리스된 4.10을 통한 OpenShift Container Platform 4.6의 기본 Red Hat 제공 Operator 카탈로그입니다.
SQLite 데이터베이스 형식과 관련된 opm
하위 명령, 플래그 및 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 기능은 계속 지원되며 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 사용하는 카탈로그에 사용해야 합니다.
와 같은 SQLite 데이터베이스 형식을 사용하기 위한 많은 opm 하위 명령과 플래그는 파일 기반 카탈로그 형식으로 작동하지 않습니다. 파일 기반 카탈로그 사용에 대한 자세한 내용은 oc-mirror 플러그인을 사용하여 Operator Framework 패키징 형식 및 연결이 끊긴 설치의 이미지 미러링 을 참조하십시오.
opm
index prune
4.9.2.1. 파일 기반 카탈로그 이미지 생성
opm
CLI를 사용하여 더 이상 사용되지 않는 gRPC 데이터베이스 형식을 대체하는 일반 텍스트 파일 기반 카탈로그 형식(JSON 또는 YAML)을 사용하는 카탈로그 이미지를 생성할 수 있습니다.
사전 요구 사항
-
opm
-
podman
버전 1.9.3+ - 번들 이미지를 빌드하여 Docker v2-2를 지원하는 레지스트리로 내보냄
프로세스
카탈로그를 초기화합니다.
다음 명령을 실행하여 카탈로그의 디렉터리를 생성합니다.
$ mkdir <catalog_dir>
opm generate dockerfile
명령을 실행하여 카탈로그 이미지를 빌드할 수 있는 Dockerfile을 생성합니다.$ opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry:v4.11 1
- 1
-i
플래그를 사용하여 공식 Red Hat 기본 이미지를 지정합니다. 그러지 않으면 Dockerfile에서 기본 업스트림 이미지를 사용합니다.
Dockerfile은 이전 단계에서 생성한 카탈로그 디렉터리와 동일한 상위 디렉터리에 있어야 합니다.
디렉터리 구조의 예
. 1 ├── <catalog_dir> 2 └── <catalog_dir>.Dockerfile 3
opm init
명령을 실행하여 Operator의 패키지 정의로 카탈로그를 채웁니다.$ opm init <operator_name> \ 1 --default-channel=preview \ 2 --description=./README.md \ 3 --icon=./operator-icon.svg \ 4 --output yaml \ 5 > <catalog_dir>/index.yaml 6
이 명령은 지정된 카탈로그 구성 파일에
olm.package
선언적 구성 blob을 생성합니다.
opm render
명령을 실행하여 카탈로그에 번들을 추가합니다.$ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ 1 --output=yaml \ >> <catalog_dir>/index.yaml 2
참고채널에는 하나 이상의 번들이 포함되어야 합니다.
번들에 채널 항목을 추가합니다. 예를 들어 다음 예제를 사양에 맞게 수정하고 <
catalog_dir>/index.yaml
파일에 추가합니다.채널 항목 예
--- schema: olm.channel package: <operator_name> name: preview entries: - name: <operator_name>.v0.1.0 1
- 1
<operator_name>
뒤의 마침표(.
)를 버전v
앞에 포함해야 합니다. 그렇지 않으면 항목이opm validate
명령을 전달하지 못합니다.
파일 기반 카탈로그를 확인합니다.
카탈로그 디렉터리에 대해
opm validate
명령을 실행합니다.$ opm validate <catalog_dir>
오류 코드가
0
인지 확인합니다.$ echo $?
출력 예
0
podman build
명령을 실행하여 카탈로그 이미지를 빌드합니다.$ podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>
카탈로그 이미지를 레지스트리로 푸시합니다.
필요한 경우
podman login
명령을 실행하여 대상 레지스트리로 인증합니다.$ podman login <registry>
podman push
명령을 실행하여 카탈로그 이미지를 푸시합니다.$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
추가 리소스
4.9.2.2. 파일 기반 카탈로그 이미지 업데이트 또는 필터링
opm
CLI를 사용하여 파일 기반 카탈로그 형식을 사용하는 카탈로그 이미지를 업데이트하거나 필터링할 수 있습니다. 기존 카탈로그 이미지의 콘텐츠를 추출 및 수정하여 카탈로그에서 하나 이상의 Operator 패키지 항목을 업데이트, 추가 또는 제거할 수 있습니다. 그런 다음 업데이트된 카탈로그 버전으로 이미지를 다시 빌드할 수 있습니다.
또는 미러 레지스트리에 카탈로그 이미지가 이미 있는 경우 oc-mirror CLI 플러그인을 사용하여 업데이트된 카탈로그 버전의 해당 카탈로그 이미지에서 제거된 이미지를 자동으로 정리하고 대상 레지스트리에 미러링할 수 있습니다.
oc-mirror 플러그인 및 이 사용 사례에 대한 자세한 내용은 "미러 미러 레지스트리 콘텐츠 업데이트" 섹션, 특히 "oc-mirror 플러그인을 사용하여 연결이 끊긴 설치를 위한 이미지 미러링" 섹션, 특히 "이미지 실행" 섹션을 참조하십시오.
사전 요구 사항
-
opm
CLI. -
podman
버전 1.9.3 이상. - 파일 기반 카탈로그 이미지입니다.
이 카탈로그와 관련된 워크스테이션에서 최근에 초기화된 카탈로그 디렉터리 구조입니다.
초기화된 카탈로그 디렉터리가 없는 경우 디렉터리를 생성하고 Dockerfile을 생성합니다. 자세한 내용은 "파일 기반 카탈로그 이미지 생성" 절차의 " catalog" 단계를 참조하십시오.
프로세스
YAML 형식의 카탈로그 이미지의 콘텐츠를 카탈로그 디렉터리의
index.yaml
파일에 추출합니다.$ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \ -o yaml > <catalog_dir>/index.yaml
참고또는
-o json
플래그를 사용하여 JSON 형식으로 출력할 수 있습니다.하나 이상의 Operator 패키지 항목을 업데이트, 추가 또는 제거하여 결과
index.yaml
파일의 내용을 사양으로 수정합니다.중요번들이 카탈로그에 게시되면 사용자 중 하나가 설치되었다고 가정합니다. 해당 버전이 설치된 사용자를 방지하려면 카탈로그의 이전에 게시된 모든 번들에 현재 또는 최신 채널 헤드에 대한 업데이트 경로가 있는지 확인합니다.
예를 들어 Operator 패키지를 제거하려면 다음 예제에
olm.package
,olm.channel
,olm.bundle
blobs 세트가 나열되어 있으며 카탈로그에서 패키지를 제거하려면 삭제해야 합니다.예 4.1. 삭제된 항목의 예
--- defaultChannel: release-2.7 icon: base64data: <base64_string> mediatype: image/svg+xml name: example-operator schema: olm.package --- entries: - name: example-operator.v2.7.0 skipRange: '>=2.6.0 <2.7.0' - name: example-operator.v2.7.1 replaces: example-operator.v2.7.0 skipRange: '>=2.6.0 <2.7.1' - name: example-operator.v2.7.2 replaces: example-operator.v2.7.1 skipRange: '>=2.6.0 <2.7.2' - name: example-operator.v2.7.3 replaces: example-operator.v2.7.2 skipRange: '>=2.6.0 <2.7.3' - name: example-operator.v2.7.4 replaces: example-operator.v2.7.3 skipRange: '>=2.6.0 <2.7.4' name: release-2.7 package: example-operator schema: olm.channel --- image: example.com/example-inc/example-operator-bundle@sha256:<digest> name: example-operator.v2.7.0 package: example-operator properties: - type: olm.gvk value: group: example-group.example.io kind: MyObject version: v1alpha1 - type: olm.gvk value: group: example-group.example.io kind: MyOtherObject version: v1beta1 - type: olm.package value: packageName: example-operator version: 2.7.0 - type: olm.bundle.object value: data: <base64_string> - type: olm.bundle.object value: data: <base64_string> relatedImages: - image: example.com/example-inc/example-related-image@sha256:<digest> name: example-related-image schema: olm.bundle ---
-
index.yaml
파일에 변경 사항을 저장합니다. 카탈로그를 확인합니다.
$ opm validate <catalog_dir>
카탈로그를 다시 빌드합니다.
$ podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>
업데이트된 카탈로그 이미지를 레지스트리로 푸시합니다.
$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
검증
-
웹 콘솔에서 관리
클러스터 설정 구성 페이지의 OperatorHub 구성 리소스로 이동합니다. 업데이트된 카탈로그 이미지의 pull 사양을 사용하도록 카탈로그 소스를 추가하거나 기존 카탈로그 소스를 업데이트합니다.
자세한 내용은 이 섹션의 "추가 리소스"의 "클러스터에 카탈로그 소스 추가"를 참조하십시오.
-
카탈로그 소스가 READY 상태인 후 Operator
OperatorHub 페이지로 이동하여 수행된 변경 사항이 Operator 목록에 반영되었는지 확인합니다.
4.9.3. SQLite 기반 카탈로그
Operator 카탈로그의 SQLite 데이터베이스 형식은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.
OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.
4.9.3.1. SQLite 기반 인덱스 이미지 생성
opm
CLI를 사용하여 SQLite 데이터베이스 형식을 기반으로 인덱스 이미지를 생성할 수 있습니다.
사전 요구 사항
-
opm
-
podman
버전 1.9.3+ - 번들 이미지를 빌드하여 Docker v2-2를 지원하는 레지스트리로 내보냄
프로세스
새 인덱스를 시작합니다.
$ opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \1 --tag <registry>/<namespace>/<index_image_name>:<tag> \2 [--binary-image <registry_base_image>] 3
인덱스 이미지를 레지스트리로 내보냅니다.
필요한 경우 대상 레지스트리로 인증합니다.
$ podman login <registry>
인덱스 이미지를 내보냅니다.
$ podman push <registry>/<namespace>/<index_image_name>:<tag>
4.9.3.2. SQLite 기반 인덱스 이미지 업데이트
사용자 정의 인덱스 이미지를 참조하는 카탈로그 소스를 사용하도록 OperatorHub를 구성하면 클러스터 관리자가 인덱스 이미지에 번들 이미지를 추가하여 클러스터에 사용 가능한 Operator를 최신 상태로 유지할 수 있습니다.
opm index add
명령을 사용하여 기존 인덱스 이미지를 업데이트할 수 있습니다.
사전 요구 사항
-
opm
-
podman
버전 1.9.3+ - 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.
- 기존 카탈로그 소스에서 인덱스 이미지를 참조합니다.
절차
번들 이미지를 추가하여 기존 인덱스를 업데이트합니다.
$ opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1 --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2 --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3 --pull-tool podman 4
다음과 같습니다.
<registry>
-
레지스트리의 호스트 이름(예:
quay.io
또는mirror.example.com
)을 지정합니다. <namespace>
-
레지스트리의 네임스페이스(예:
ocs-dev
또는abc
)를 지정합니다. <new_bundle_image>
-
레지스트리에 추가할 새 번들 이미지를 지정합니다(예:
ocs-operator
). <digest>
-
번들 이미지의 SHA 이미지 ID 또는 다이제스트를 지정합니다(예:
c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41)
. <existing_index_image>
-
이전에 내보낸 이미지를
abc-redhat-operator-index
와 같이 지정합니다. <existing_tag>
-
이전에 내보낸 이미지 태그(예:
4.11
)를 지정합니다. <updated_tag>
-
업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다 (예:
4.11.1
).
명령 예
$ opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.11 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.11.1 \ --pull-tool podman
업데이트된 인덱스 이미지를 내보냅니다.
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
OLM(Operator Lifecycle Manager)이 정기적으로 카탈로그 소스에서 참조하는 인덱스 이미지를 자동으로 폴링하면 새 패키지가 성공적으로 추가되었는지 확인합니다.
$ oc get packagemanifests -n openshift-marketplace
4.9.3.3. SQLite 기반 인덱스 이미지 필터링
Operator 번들 포맷을 기반으로 하는 인덱스 이미지는 Operator 카탈로그의 컨테이너화된 스냅샷입니다. 원하는 Operator만 포함하는 소스 인덱스 복사본을 생성하는 패키지 목록을 제외한 모든 인덱스의 인덱스를 필터링하거나 정리 할 수 있습니다.
사전 요구 사항
-
podman
버전 1.9.3+ -
grpcurl
(제3자 명령줄 도구) -
opm
- Docker v2-2를 지원하는 레지스트리에 액세스
절차
대상 레지스트리로 인증합니다.
$ podman login <target_registry>
정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.
컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.
$ podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.11
출력 예
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.11... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
별도의 터미널 세션에서
grpcurl
명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.$ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
packages.out
파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.패키지 목록 조각의 예
... { "name": "advanced-cluster-management" } ... { "name": "jaeger-product" } ... { { "name": "quay-operator" } ...
-
podman run
명령을 실행한 터미널 세션에서 Ctrl 및 C를 눌러 컨테이너 프로세스를 중지합니다.
다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.
$ opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.11 \1 -p advanced-cluster-management,jaeger-product,quay-operator \2 [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \3 -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.11 4
다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.11
<namespace>
는 레지스트리의 기존 네임스페이스입니다.
4.9.4. 클러스터에 카탈로그 소스 추가
OpenShift Container Platform 클러스터에 카탈로그 소스를 추가하면 사용자를 위한 Operator를 검색하고 설치할 수 있습니다. 클러스터 관리자는 인덱스 이미지를 참조하는 CatalogSource
오브젝트를 생성할 수 있습니다. OperatorHub는 카탈로그 소스를 사용하여 사용자 인터페이스를 채웁니다.
또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리
사전 요구 사항
- 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.
절차
인덱스 이미지를 참조하는
CatalogSource
오브젝트를 생성합니다.다음을 사양에 맞게 수정하고
catalogsource.yaml
파일로 저장합니다.apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog namespace: openshift-marketplace 1 annotations: olm.catalogImageTemplate: 2 "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}" spec: sourceType: grpc image: <registry>/<namespace>/<index_image_name>:<tag> 3 displayName: My Operator Catalog publisher: <publisher_name> 4 updateStrategy: registryPoll: 5 interval: 30m
- 1
- 카탈로그 소스를 모든 네임스페이스의 사용자가 전역적으로 사용할 수 있도록 하려면
openshift-marketplace
네임스페이스를 지정합니다. 그러지 않으면 카탈로그의 범위가 지정되고 해당 네임스페이스에 대해서만 사용할 수 있도록 다른 네임스페이스를 지정할 수 있습니다. - 2
- 선택 사항:
olm.catalogImageTemplate
주석을 인덱스 이미지 이름으로 설정하고 이미지 태그의 템플릿을 구성할 때 표시된 대로 하나 이상의 Kubernetes 클러스터 버전 변수를 사용합니다. - 3
- 인덱스 이미지를 지정합니다. 이미지 이름 뒤에 태그를 지정하는 경우 (예:
:v4.11
) 카탈로그 소스 Pod는Always
라는 이미지 가져오기 정책을 사용합니다. 즉, Pod는 컨테이너를 시작하기 전에 항상 이미지를 가져옵니다. 다이제스트(예:@sha256:<id
>)를 지정하는 경우 이미지 가져오기 정책은IfNotPresent
입니다. 즉, 노드에 아직 존재하지 않는 경우에만 Pod에서 이미지를 가져옵니다. - 4
- 카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다.
- 5
- 카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.
파일을 사용하여
CatalogSource
오브젝트를 생성합니다.$ oc apply -f catalogSource.yaml
다음 리소스가 성공적으로 생성되었는지 확인합니다.
Pod를 확인합니다.
$ oc get pods -n openshift-marketplace
출력 예
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
카탈로그 소스를 확인합니다.
$ oc get catalogsource -n openshift-marketplace
출력 예
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
패키지 매니페스트 확인합니다.
$ oc get packagemanifest -n openshift-marketplace
출력 예
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
이제 OpenShift Container Platform 웹 콘솔의 OperatorHub 페이지에서 Operator를 설치할 수 있습니다.
4.9.5. 프라이빗 레지스트리에서 Operator용 이미지에 액세스
OLM(Operator Lifecycle Manager)에서 관리하는 Operator와 관련된 특정 이미지가 개인 레지스트리라고도 하는 인증된 컨테이너 이미지 레지스트리에서 호스팅되는 경우 OLM 및 OperatorHub는 기본적으로 이미지를 가져올 수 없습니다. 액세스를 활성화하려면 레지스트리의 인증 정보가 포함된 풀 시크릿을 생성할 수 있습니다. OLM은 카탈로그 소스에서 하나 이상의 가져오기 보안을 참조함으로써 Operator 및 카탈로그 네임스페이스에 보안을 배치하여 설치를 허용할 수 있습니다.
Operator 또는 해당 Operand에 필요한 기타 이미지에서도 프라이빗 레지스트리에 액세스해야 할 수 있습니다. 이 시나리오에서 OLM은 대상 테넌트 네임스페이스에 보안을 배치하지 않지만 필요한 액세스 권한을 활성화하기 위해 글로벌 클러스터 가져오기 보안 또는 개별 네임스페이스 서비스 계정에 인증 자격 증명을 추가할 수 있습니다.
OLM에서 관리하는 Operator에 적절한 가져오기 액세스 권한이 있는지 확인할 때는 다음 유형의 이미지를 고려해야 합니다.
- 인덱스 이미지
-
CatalogSource
오브젝트는 Operator 번들 형식을 사용하고 이미지 레지스트리에서 호스팅되는 컨테이너 이미지로 패키지된 카탈로그 소스에 해당하는 인덱스 이미지를 참조할 수 있습니다. 인덱스 이미지가 프라이빗 레지스트리에서 호스팅되는 경우 시크릿을 사용하여 가져오기 액세스 권한을 활성화할 수 있습니다. - 번들 이미지
- Operator 번들 이미지는 컨테이너 이미지로 패키지되어 Operator의 고유 버전을 나타내는 메타데이터와 매니페스트입니다. 카탈로그 소스에서 참조한 번들 이미지가 하나 이상의 프라이빗 레지스트리에서 호스팅되는 경우 보안을 사용하여 가져오기 액세스 권한을 활성화할 수 있습니다.
- Operator 및 Operand 이미지
카탈로그 소스에서 설치한 Operator에서 Operator 이미지 자체 또는 조사하는 Operand 이미지 중 하나로 프라이빗 이미지를 사용하는 경우 Operator가 설치되지 않습니다. 배포에 필수 레지스트리 인증에 대한 액세스 권한이 없기 때문입니다. 카탈로그 소스의 보안을 참조해도 OLM에서 Operand가 설치된 대상 테넌트 네임스페이스에 보안을 배치할 수 없습니다.
대신 클러스터의 모든 네임스페이스에 대한 액세스 권한을 제공하는
openshift-config
네임스페이스의 글로벌 클러스터 가져오기 보안에 인증 세부 정보를 추가하면 됩니다. 또는 전체 클러스터에 대한 액세스 권한을 제공할 수 없는 경우 대상 테넌트 네임스페이스의default
서비스 계정에 가져오기 보안을 추가할 수 있습니다.
사전 요구 사항
다음 중 한 개 이상이 프라이빗 레지스트리에서 호스팅됩니다.
- 인덱스 이미지 또는 카탈로그 이미지.
- Operator 번들 이미지.
- Operator 또는 Operand 이미지.
프로세스
필요한 각 프라이빗 레지스트리에 대해 보안을 생성합니다.
프라이빗 레지스트리에 로그인하여 레지스트리 자격 증명 파일을 생성하거나 업데이트합니다.
$ podman login <registry>:<port>
참고레지스트리 자격 증명의 파일 경로는 레지스트리에 로그인하는 데 사용하는 컨테이너 툴에 따라 다를 수 있습니다.
podman
CLI의 경우 기본 위치는${XDG_RUNTIME_DIR}/containers/auth.json
입니다.docker
CLI의 경우 기본 위치는/root/.docker/config.json
입니다.보안당 하나의 레지스트리에 대한 자격 증명만 포함하고 여러 레지스트리의 자격 증명은 별도의 보안에서 관리하는 것이 좋습니다. 이후 단계에서
CatalogSource
오브젝트에 여러 보안을 포함할 수 있으며 OpenShift Container Platform은 이미지를 가져오는 동안 사용할 수 있도록 보안을 단일 가상 자격 증명 파일에 병합합니다.기본적으로 레지스트리 자격 증명 파일은 둘 이상의 레지스트리 또는 하나의 레지스트리에 있는 여러 리포지토리의 세부 정보를 저장할 수 있습니다. 파일의 현재 콘텐츠를 확인합니다. 예를 들면 다음과 같습니다.
여러 레지스트리에 대한 자격 증명을 저장하는 파일
{ "auths": { "registry.redhat.io": { "auth": "FrNHNydQXdzclNqdg==" }, "quay.io": { "auth": "fegdsRib21iMQ==" }, "https://quay.io/my-namespace/my-user/my-image": { "auth": "eWfjwsDdfsa221==" }, "https://quay.io/my-namespace/my-user": { "auth": "feFweDdscw34rR==" }, "https://quay.io/my-namespace": { "auth": "frwEews4fescyq==" } } }
이 파일은 이후 단계에서 보안을 생성하는 데 사용되므로 파일마다 하나의 레지스트리에만 세부 정보를 저장해야 합니다. 이 작업은 다음 방법 중 하나를 사용하여 수행할 수 있습니다.
-
podman logout <registry>
명령을 사용하여 원하는 레지스트리 하나만 남을 때까지 추가 레지스트리의 자격 증명을 제거합니다. 레지스트리 자격 증명 파일을 편집하고 레지스트리 세부 정보를 분리하여 여러 파일에 저장합니다. 예를 들면 다음과 같습니다.
하나의 레지스트리에 대한 자격 증명을 저장하는 파일
{ "auths": { "registry.redhat.io": { "auth": "FrNHNydQXdzclNqdg==" } } }
또 다른 레지스트리에 대한 자격 증명을 저장하는 파일
{ "auths": { "quay.io": { "auth": "Xd2lhdsbnRib21iMQ==" } } }
-
프라이빗 레지스트리의 인증 자격 증명 정보가 포함된
openshift-marketplace
네임스페이스에 보안을 생성합니다.$ oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
이 단계를 반복하여 다른 필수 프라이빗 레지스트리에 대한 추가 보안을 생성하고
--from-file
플래그를 업데이트하여 다른 레지스트리 자격 증명 파일 경로를 지정합니다.
기존
CatalogSource
오브젝트를 생성하거나 업데이트하여 하나 이상의 보안을 참조합니다.apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog namespace: openshift-marketplace spec: sourceType: grpc secrets: 1 - "<secret_name_1>" - "<secret_name_2>" image: <registry>:<port>/<namespace>/<image>:<tag> displayName: My Operator Catalog publisher: <publisher_name> updateStrategy: registryPoll: interval: 30m
- 1
spec.secrets
섹션을 추가하고 필요한 보안을 지정합니다.
구독한 Operator에서 참조하는 Operator 또는 Operand 이미지에 프라이빗 레지스트리에 대한 액세스 권한이 필요한 경우 클러스터의 모든 네임스페이스 또는 개별 대상 테넌트 네임스페이스에 액세스 권한을 제공하면 됩니다.
클러스터의 모든 네임스페이스에 액세스 권한을 제공하려면
openshift-config
네임스페이스의 글로벌 클러스터 가져오기 보안에 인증 세부 정보를 추가합니다.주의클러스터 리소스는 클러스터의 사용성을 일시적으로 제한할 수 있는 새 글로벌 가져오기 보안에 맞게 조정해야 합니다.
글로벌 가져오기 보안에서
.dockerconfigjson
파일을 추출합니다.$ oc extract secret/pull-secret -n openshift-config --confirm
필요한 프라이빗 레지스트리 또는 레지스트리에 대한 인증 자격 증명을 사용하여
.dockerconfigjson
파일을 업데이트한 후 새 파일로 저장합니다.$ cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1 > new_dockerconfigjson
- 1
<registry>:<port>/<namespace>
를 프라이빗 레지스트리 세부 정보로 교체하고<token>
을 인증 자격 증명으로 교체합니다.
새 파일을 사용하여 글로벌 가져오기 보안을 업데이트합니다.
$ oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson
개별 네임스페이스를 업데이트하려면 대상 테넌트 네임스페이스에 액세스해야 하는 Operator의 서비스 계정에 가져오기 보안을 추가합니다.
테넌트 네임스페이스에서
openshift-marketplace
용으로 생성한 보안을 다시 생성합니다.$ oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
테넌트 네임스페이스를 검색하여 Operator의 서비스 계정 이름을 확인합니다.
$ oc get sa -n <tenant_namespace> 1
- 1
- Operator가 개별 네임스페이스에 설치된 경우 해당 네임스페이스를 검색합니다. Operator가 모든 네임스페이스에 설치된 경우
openshift-operators
네임스페이스를 검색합니다.
출력 예
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s 1
- 1
- 설치된 etcd Operator의 서비스 계정입니다.
Operator의 서비스 계정에 보안을 연결합니다.
$ oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull
추가 리소스
- 레지스트리 자격 증명에 사용되는 보안 유형을 포함하여 보안 유형에 대한 자세한 내용은 보안이란? 을 참조하십시오.
- 이 시크릿 변경이 미치는 영향에 대한 자세한 내용은 글로벌 클러스터 풀 시크릿 업데이트를 참조하십시오.
- 가져오기 보안을 네임스페이스별 서비스 계정에 연결하는 방법에 대한 자세한 내용은 Pod에서 다른 보안 레지스트리의 이미지를 참조하도록 허용 을 참조하십시오.
4.9.6. 기본 OperatorHub 소스 비활성화
Red Hat 및 커뮤니티 프로젝트에서 제공하는 콘텐츠를 소싱하는 Operator 카탈로그는 OpenShift Container Platform을 설치하는 동안 기본적으로 OperatorHub용으로 구성됩니다. 클러스터 관리자는 기본 카탈로그 세트를 비활성화할 수 있습니다.
프로세스
OperatorHub
오브젝트에disableAllDefaultSources: true
를 추가하여 기본 카탈로그의 소스를 비활성화합니다.$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리
4.9.7. 사용자 정의 카탈로그 제거
클러스터 관리자는 관련 카탈로그 소스를 삭제하여 이전에 클러스터에 추가된 사용자 정의 Operator 카탈로그를 제거할 수 있습니다.
프로세스
-
웹 콘솔의 관리자 화면에서 관리자
클러스터 설정으로 이동합니다. - 구성 탭을 클릭한 다음 OperatorHub 를 클릭합니다.
- 소스 탭을 클릭합니다.
-
제거할 카탈로그의 옵션 메뉴
를 선택한 다음 카탈로그 소스 삭제를 클릭합니다.