Registry

Red Hat OpenShift Service on AWS 4

AWS의 Red Hat OpenShift Service는 소스 코드에서 이미지를 빌드하고 배포하며 라이프사이클을 관리할 수 있습니다.

Red Hat OpenShift Documentation Team

초록

Red Hat OpensShift Service on AWS는 로컬에서 이미지를 관리하기 위해 AWS 환경의 Red Hat OpenShift Service에 배포할 수 있는 내부 통합 컨테이너 이미지 레지스트리를 제공합니다.

1장. OpenShift 이미지 레지스트리 개요

AWS의 Red Hat OpenShift Service는 소스 코드에서 이미지를 빌드하고 배포하며 라이프사이클을 관리할 수 있습니다. 로컬에서 이미지를 관리하기 위해 AWS 환경의 Red Hat OpenShift Service에 배포할 수 있는 내부 통합 컨테이너 이미지 레지스트리를 제공합니다. 이 개요에는 OpenShift 이미지 레지스트리에 중점을 두고 있는 AWS의 Red Hat OpenShift Service와 함께 일반적으로 사용되는 레지스트리의 참조 정보와 링크가 포함되어 있습니다.

1.1. OpenShift 이미지 레지스트리의 일반 용어집

이 용어집은 레지스트리 콘텐츠에 사용되는 공통 용어를 정의합니다.

컨테이너
소프트웨어 및 모든 종속 항목을 구성하는 경량의 실행 가능한 이미지입니다. 컨테이너는 운영 체제를 가상화하므로 데이터 센터, 퍼블릭 또는 프라이빗 클라우드 또는 로컬 호스트에서 컨테이너를 실행할 수 있습니다.
이미지 레지스트리 Operator
이미지 레지스트리 Operator는 openshift-image-registry 네임스페이스에서 실행되며 해당 위치의 레지스트리 인스턴스를 관리합니다.
이미지 리포지터리
이미지 리포지터리는 관련 컨테이너 이미지와 이미지를 식별하는 태그의 컬렉션입니다.
미러 레지스트리
미러 레지스트리는 AWS 이미지에 Red Hat OpenShift Service의 미러를 보유한 레지스트리입니다.
namespace
네임스페이스는 단일 클러스터 내에서 리소스 그룹을 격리합니다.
Pod
Pod는 Kubernetes에서 가장 작은 논리 단위입니다. Pod는 작업자 노드에서 실행할 하나 이상의 컨테이너로 구성됩니다.
프라이빗 레지스트리
레지스트리는 컨테이너 이미지 레지스트리 API를 구현하는 서버입니다. 프라이빗 레지스트리는 사용자가 콘텐츠에 액세스할 수 있도록 인증이 필요한 레지스트리입니다.
public registry
레지스트리는 컨테이너 이미지 레지스트리 API를 구현하는 서버입니다. 공용 레지스트리는 콘텐츠를 공개적으로 제공하는 레지스트리입니다.
Quay.io
Red Hat에서 제공하고 유지 관리하는 공용 Red Hat Quay Container Registry 인스턴스는 대부분의 컨테이너 이미지와 Operator를 AWS 클러스터의 Red Hat OpenShift Service에 제공합니다.
OpenShift 이미지 레지스트리
OpenShift 이미지 레지스트리는 이미지를 관리하기 위해 AWS의 Red Hat OpenShift Service에서 제공하는 레지스트리입니다.
레지스트리 인증
개인 이미지 리포지토리에서 이미지를 푸시하고 가져오려면 레지스트리에서 자격 증명을 사용하여 사용자를 인증해야 합니다.
Route
AWS 인스턴스의 Red Hat OpenShift Service 외부의 사용자 및 애플리케이션에서 Pod에 대한 네트워크 액세스를 허용하는 서비스를 노출합니다.
축소
복제본 수를 줄이기 위해 다음을 수행합니다.
확장
복제본 수를 늘리려면 다음을 수행합니다.
service
서비스는 일련의 Pod에 실행 중인 애플리케이션을 노출합니다.

1.2. 통합된 OpenShift 이미지 레지스트리

AWS의 Red Hat OpenShift Service는 클러스터에서 표준 워크로드로 실행되는 내장 컨테이너 이미지 레지스트리를 제공합니다. 레지스트리는 인프라 Operator에 의해 설정 및 관리됩니다. 사용자가 기존 클러스터 인프라의 상단에서 실행되는 이미지를 관리하여 실제 워크로드를 처리할 수있는 기본 솔루션을 제공합니다. 이 레지스트리는 다른 클러스터 워크로드처럼 확장 또는 축소할 수 있으며 특정 인프라 프로비저닝을 필요로하지 않습니다. 또한 클러스터 사용자 인증 및 권한 부여 시스템에 통합되어 이미지 리소스에 대한 사용자 권한을 정의하여 이미지를 만들고 액세스 권한을 제어할 수 있습니다.

일반적으로 레지스트리는 클러스터에 빌드된 이미지의 게시 대상과 클러스터에서 실행되는 워크로드의 이미지 소스로 사용됩니다. 새 이미지가 레지스트리로 푸시되면 클러스터에 새 이미지에 대한 알림이 전송되고 다른 구성 요소는 업데이트된 이미지에 응답하여 이를 사용할 수 있습니다.

이미지 데이터는 두 위치에 저장됩니다. 실제 이미지 데이터는 클라우드 스토리지 또는 파일 시스템 볼륨과 같은 설정 가능한 스토리지 위치에 저장됩니다. 표준 클러스터 API가 공개되어 액세스 제어를 수행하는 데 사용되는 이미지 메타 데이터는 표준 API 리소스, 특히 이미지 및 이미지 스트림으로 저장됩니다.

1.3. 타사 레지스트리

AWS의 Red Hat OpenShift Service는 타사 레지스트리의 이미지를 사용하여 컨테이너를 생성할 수 있지만 이러한 레지스트리가 통합된 OpenShift 이미지 레지스트리와 동일한 이미지 알림 지원을 제공하지는 않습니다. 이 경우 AWS의 Red Hat OpenShift Service는 이미지 스트림 생성 시 원격 레지스트리에서 태그를 가져옵니다. 가져온 태그를 새로 고치려 면 oc import-image <stream>을 실행합니다. 새 이미지가 감지되면 이전 빌드 및 배포가 다시 생성됩니다.

1.3.1. 인증

AWS의 Red Hat OpenShift Service는 레지스트리와 통신하여 사용자가 제공한 자격 증명을 사용하여 개인 이미지 리포지토리에 액세스할 수 있습니다. 이를 통해 AWS의 Red Hat OpenShift Service는 프라이빗 리포지토리로 이미지를 푸시하고 가져올 수 있습니다.

1.3.1.1. Podman을 사용한 레지스트리 인증

일부 컨테이너 이미지 레지스트리에는 액세스 권한이 필요합니다. Podman은 컨테이너 및 컨테이너 이미지를 관리하고 이미지 레지스트리와 상호 작용하기 위한 오픈 소스 툴입니다. Podman을 사용하여 인증 정보를 인증하고, 레지스트리 이미지를 가져오고, 로컬 이미지를 로컬 파일 시스템에 저장할 수 있습니다. 다음은 Podman을 사용하여 레지스트리를 인증하는 일반적인 예입니다.

절차

  1. Red Hat Ecosystem Catalog 를 사용하여 Red Hat Repository에서 특정 컨테이너 이미지를 검색하고 필요한 이미지를 선택합니다.
  2. 이 이미지 가져오기 를 클릭하여 컨테이너 이미지의 명령을 찾습니다.
  3. 다음 명령을 실행하여 로그인하고 사용자 이름과 암호를 입력하여 인증합니다.

    $ podman login registry.redhat.io
     Username:<your_registry_account_username>
     Password:<your_registry_account_password>
  4. 다음 명령을 실행하여 이미지를 다운로드하여 로컬에 저장합니다.

    $ podman pull registry.redhat.io/<repository_name>

1.4. Red Hat Quay 레지스트리

엔터프라이즈급 컨테이너 이미지 레지스트리가 필요한 경우 Red Hat Quay는 호스팅 서비스와 자체 데이터 센터 또는 클라우드 환경에 설치할 수있는 소프트웨어로 사용할 수 있습니다. Red Hat Quay의 고급 기능에는 지역 복제, 이미지 스캔 및 이미지 롤백 기능이 포함되어 있습니다.

Quay.io 사이트를 방문하여 호스팅된 Quay 레지스트리 계정을 설정합니다. 그 후 Quay 튜토리얼에 따라 Quay 레지스트리에 로그인하고 이미지 관리를 시작합니다.

원격 컨테이너 이미지 레지스트리와 마찬가지로 AWS의 Red Hat OpenShift Service에서 Red Hat Quay 레지스트리에 액세스할 수 있습니다.

추가 리소스

1.5. 인증이 활성화된 Red Hat 레지스트리

Red Hat Ecosystem Catalog의 Container 이미지 섹션을 통해 제공되는 모든 컨테이너 이미지는 이미지 레지스트리의 registry.redhat.io.에 호스트됩니다.

레지스트리 registry.redhat.io 는 AWS의 Red Hat OpenShift Service의 이미지 및 호스팅 콘텐츠에 액세스하려면 인증이 필요합니다. 새 레지스트리로 마이그레이션한 후 기존 레지스트리를 일정 기간 동안 사용할 수 있습니다.

참고

AWS의 Red Hat OpenShift Service는 registry.redhat.io 에서 이미지를 가져오므로 이를 사용하도록 클러스터를 구성해야 합니다.

새 레지스트리는 다음과 같은 방법으로 인증에 표준 OAuth 메커니즘을 사용합니다.

  • 인증 토큰: 관리자에 의해 생성되는 토큰으로 이는 시스템에 컨테이너 이미지 레지스트리에 대한 인증 기능을 제공하는 서비스 계정입니다. 서비스 계정은 사용자 계정 변경의 영향을 받지 않으므로 인증에 토큰을 사용하는 것은 안정적이고 유연한 인증 방법입니다. 이는 프로덕션 클러스터에 대해 지원되는 유일한 인증 옵션입니다.
  • 웹 사용자 이름 및 암호: 이는 access.redhat.com과 같은 리소스에 로그인하는 데 사용하는 표준 인증 정보 집합입니다. AWS의 Red Hat OpenShift Service에서 이 인증 방법을 사용할 수는 있지만 프로덕션 배포에는 지원되지 않습니다. 이 인증 방법은 이 인증 방법을 Red Hat OpenShift Service on AWS 외부의 독립형 프로젝트로 제한합니다.

사용자 이름 및 암호 또는 인증 토큰 중 하나의 인증 정보를 사용하여 podman login을 사용하고 새 레지스트리의 콘텐츠에 액세스합니다.

모든 이미지 스트림은 설치 풀 시크릿을 사용하여 인증할 새 레지스트리를 가리킵니다.

다음 위치 중 하나에 인증 정보를 배치해야합니다.

  • openshift 네임 스페이스. openshift 네임스페이스의 이미지 스트림을 가져올 수 있도록 인증 정보가 openshift 네임스페이스에 있어야 합니다.
  • 호스트: Kubernetes에서 이미지를 가져올 때 호스트의 인증 정보를 사용하므로 호스트에 인증 정보가 있어야합니다.

2장. AWS의 Red Hat OpenShift Service의 이미지 레지스트리 Operator

2.1. AWS의 Red Hat OpenShift Service의 이미지 레지스트리

Image Registry Operator는 OpenShift 이미지 레지스트리의 단일 인스턴스를 설치하고 레지스트리 스토리지 설정을 포함하여 모든 레지스트리 구성을 관리합니다.

컨트롤 플레인이 배포된 후 Operator는 클러스터에서 감지된 설정을 기반으로 기본 configs.imageregistry.operator.openshift.io 리소스 인스턴스를 생성합니다.

전체 configs.imageregistry.operator.openshift.io 리소스를 정의하는 데 사용할 수 있는 정보가 충분하지 않으면 불완전한 리소스가 정의되고 Operator는 누락된 항목에 대한 정보로 리소스 상태를 업데이트합니다.

이미지 레지스트리 Operator는 openshift-image-registry 네임 스페이스에서 실행되며 해당 위치의 레지스트리 인스턴스도 관리합니다. 레지스트리의 모든 설정 및 워크로드 리소스는 해당 네임 스페이스에 있습니다.

중요

pruner를 관리하기위한 이미지 레지스트리 Operator의 동작은 이미지 레지스트리 Operator의 ClusterOperator 개체에 지정된 ManagementState와는 별개입니다. 이미지 레지스트리 Operator가 Managed 상태가 아닌 경우 이미지 pruner는 Pruning 사용자 정의 리소스로 설정 및 관리할 수 있습니다.

그러나 이미지 레지스트리 Operator의 managementState는 배포된 이미지 pruner 작업의 동작을 변경합니다.

  • Managed: 이미지 pruner의 --prune-registry 플래그가 true로 설정됩니다.
  • Removed: 이미지 pruner의 --prune-registry 플래그가 false 로 설정되어 etcd의 이미지 메타 데이터만 정리합니다.
  • Unmanaged : 이미지 pruner의 --prune-registry 플래그가 false로 설정됩니다.

2.2. 가용성 영역에 대한 이미지 레지스트리 Operator 배포

이미지 레지스트리 Operator의 기본 구성에서는 이미지 레지스트리 Pod를 토폴로지 영역에 분배하여 모든 Pod가 영향을 받는 전체 영역 장애의 경우 지연된 복구 시간을 방지합니다.

영역 관련 토폴로지 제약 조건을 사용하여 배포하는 경우 Image Registry Operator의 기본값은 다음과 같습니다.

영역 관련 토폴로지 제약 조건을 사용하여 배포된 이미지 레지스트리 Operator

  topologySpreadConstraints:
  - labelSelector:
      matchLabels:
        docker-registry: default
    maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
  - labelSelector:
      matchLabels:
        docker-registry: default
    maxSkew: 1
    topologyKey: node-role.kubernetes.io/worker
    whenUnsatisfiable: DoNotSchedule
  - labelSelector:
      matchLabels:
        docker-registry: default
    maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule

클러스터 관리자는 configs.imageregistry.operator.openshift.io/cluster 사양 파일을 구성하여 기본 topologySpreadConstraints 를 덮어쓸 수 있습니다. 이 경우에는 사용자가 제공하는 제약 조건만 적용됩니다.

2.3. 이미지 레지스트리 Operator 설정 매개 변수

ingresscontrollers.operator.openshift.io 리소스에서 제공되는 설정 매개변수는 다음과 같습니다.

매개변수설명

managementState

Managed: Operator는 설정 리소스가 업데이트되면 레지스트리를 업데이트합니다.

Unmanaged: Operator는 설정 리소스에 대한 변경을 무시합니다.

Removed: Operator는 레지스트리 인스턴스를 제거하고 Operator가 프로비저닝한 모든 스토리지를 삭제합니다.

logLevel

레지스트리 인스턴스의 logLevel을 설정합니다. 기본값은 Normal입니다.

logLevel 에 대한 다음 값이 지원됩니다.

  • Normal
  • Debug
  • Trace
  • TraceAll

httpSecret

기본적으로 생성되는 업로드의 보안을 위해 레지스트리에 필요한 값입니다.

operatorLogLevel

operatorLogLevel 구성 매개변수는 Operator 자체에 대한 의도 기반 로깅과 Operator가 자체적으로 해석해야 하는 집계된 로깅 선택을 관리하는 간단한 방법을 제공합니다. 이 구성 매개변수의 기본값은 Normal 입니다. 세분화된 제어를 제공하지 않습니다.

operatorLogLevel 의 다음 값이 지원됩니다.

  • Normal
  • Debug
  • Trace
  • TraceAll

proxy

마스터 API 및 업스트림 레지스트리를 호출할 때 사용할 프록시를 정의합니다.

storage

Storagetype: 레지스트리 스토리지 설정에 대한 세부 정보 (예: S3 버킷 위치 정보 등)입니다. 일반적으로 기본적으로 설정됩니다.

readOnly

레지스트리 인스턴스가 새 이미지를 푸시하거나 기존 이미지를 삭제하려는 시도를 거부해야하는지 여부를 나타냅니다.

requests

API 요청 제한 세부 사항입니다. 추가 요청을 대기열에 추가하기 전에 지정된 레지스트리 인스턴스가 처리할 병렬 요청 수를 제어합니다.

defaultRoute

기본 호스트 이름을 사용하여 외부 경로를 정의할지 여부를 결정합니다. 활성화된 경우 경로는 암호화된 데이터를 다시 암호화합니다. 기본값은 false입니다.

routes

생성할 추가 경로의 배열입니다. 경로의 호스트 이름과 인증서를 지정합니다.

rolloutStrategy

이미지 레지스트리 배포에 대한 롤아웃 전략을 정의합니다. 기본값은 RollingUpdate 입니다.

replicas

레지스트리의 복제본 수입니다.

disableRedirect

백엔드로 리디렉션하지 않고 모든 데이터를 레지스트리를 통해 라우팅할지 여부를 제어합니다. 기본값은 false입니다.

spec.storage.managementState

AWS에 클러스터를 새로 설치하거나 업그레이드할 때 Image Registry Operator에서 spec.storage.managementState 매개변수를 Managed 로 설정합니다.

  • Managed: Image Registry Operator에서 기본 스토리지를 관리합니다. Image Registry Operator의 managementStateRemoved로 설정되면 스토리지가 삭제됩니다.

    • managementStateManaged로 설정된 경우 Image Registry Operator는 기본 스토리지 장치에 일부 기본 구성을 적용합니다. 예를 들어 Managed로 설정된 경우 Operator는 레지스트리에서 암호화를 사용할 수 있도록 S3 버킷에서 활성화합니다. 제공하는 스토리지에 기본 설정을 적용하지 않으려면 managementStateUnmanaged로 설정해야 합니다.
  • Unmanaged: Image Registry Operator에서 스토리지 설정을 무시합니다. Image Registry Operator의 managementStateRemoved로 설정되어도 스토리지가 삭제되지 않습니다. 버킷 또는 컨테이너 이름과 같은 기본 스토리지 장치 구성을 제공한 후 spec.storage.managementState에는 아직 값을 설정하지 않은 경우, Image Registry Operator에서 이를 Unmanaged로 구성합니다.

2.4. CRD를 사용하여 이미지 레지스트리 기본 경로 활성화

AWS의 Red Hat OpenShift Service에서 Registry Operator는 OpenShift 이미지 레지스트리 기능을 제어합니다. Operator는 configs.imageregistry.operator.openshift.io CRD (Custom Resource Definition)에 의해 정의됩니다.

이미지 레지스트리 기본 경로를 자동으로 활성화해야하는 경우 이미지 레지스트리 Operator CRD 패치를 적용합니다.

프로세스

  • 이미지 레지스트리 Operator CRD에 패치를 적용합니다.

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'

2.5. 이미지 레지스트리 액세스를 위한 추가 신뢰 저장소 구성

image.config.openshift.io/cluster 사용자 지정 리소스에는 이미지 레지스트리 액세스 중에 신뢰할 수 있는 추가 인증 기관이 포함된 구성 맵에 대한 참조가 포함될 수 있습니다.

사전 요구 사항

  • 인증 기관(CA)은 PEM으로 인코딩되어야 합니다.

절차

openshift-config 네임 스페이스에 구성 맵을 만들고 image.config.openshift.io 사용자 지정 리소스에서 AdditionalTrustedCA의 해당 이름을 사용하여 외부 레지스트리에 연결할 때 신뢰할 수있는 추가 CA를 제공할 수 있습니다.

구성 맵 키는 이 CA가 신뢰할 수있는 포트가 있는 레지스트리의 호스트 이름이며 PEM 인증서 콘텐츠는 신뢰할 수 있는 각 추가 레지스트리 CA의 값입니다.

이미지 레지스트리 CA 구성 맵의 예

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

1
레지스트리에 registry-with-port.example.com:5000 같은 포트가 있는 경우 :..로 교체되어야 합니다.

다음 절차에 따라 추가 CA를 구성할 수 있습니다.

  1. 추가 CA를 구성하려면 다음을 실행합니다.

    $ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
    $ oc edit image.config.openshift.io cluster
    spec:
      additionalTrustedCA:
        name: registry-config

2.6. 이미지 레지스트리 Operator의 스토리지 인증 정보 설정

configs.imageregistry.operator.openshift.io 및 ConfigMap 리소스 외에도 스토리지 인증 정보 설정은 openshift-image-registry 네임 스페이스 내에 있는 별도의 시크릿 리소스를 통해 Operator에게 제공됩니다.

image-registry-private-configuration-user 시크릿은 스토리지 액세스 및 관리에 필요한 인증 정보를 제공합니다. 기본 인증 정보가 검색되면 Operator가 사용하는 기본 인증 정보를 덮어씁니다.

절차

  • 필요한 키가 포함된 AWS 시크릿에서 Red Hat OpenShift Service를 생성합니다.

    $ oc create secret generic image-registry-private-configuration-user --from-literal=KEY1=value1 --from-literal=KEY2=value2 --namespace openshift-image-registry

3장. 레지스트리 액세스

로그 및 메트릭보기, 레지스트리 보안 및 공개 등 레지스트리에 액세스하는 방법은 다음 섹션에 설명된 내용을 사용하십시오.

레지스트리에 직접 액세스하여 podman 명령을 시작할 수 있습니다. 이를 통해 podman push 또는 podman pull과 같은 작업을 사용하여 통합 레지스트리에서 이미지를 직접 푸시하거나 풀할 수 있습니다. 이를 위해 podman login 명령을 사용하여 레지스트리에 로그인해야 합니다. 수행할 수있는 작업은 다음 섹션에 설명된대로 사용자 권한에 따라 달라집니다.

3.1. 사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • IDP(ID 공급자)를 구성해야합니다.
  • 예를 들어 podman pull 명령을 사용하는 경우 이미지를 가져오려면 사용자에게 registry-viewer 역할이 있어야합니다. 이 역할을 추가하려면 다음 명령을 실행합니다.

    $ oc policy add-role-to-user registry-viewer <user_name>
  • 예를 들어 podman push 명령을 사용할 때 이미지를 작성하거나 푸시하는 경우:

    • 사용자에게 registry-editor 역할이 있어야 합니다. 이 역할을 추가하려면 다음 명령을 실행합니다.

      $ oc policy add-role-to-user registry-editor <user_name>
    • 클러스터에 이미지를 내보낼 수 있는 기존 프로젝트가 있어야 합니다.

3.2. 클러스터에서 직접 레지스트리에 액세스

클러스터 내부에서 레지스트리에 액세스할 수 있습니다.

절차

내부 경로를 사용하여 클러스터에서 레지스트리에 액세스합니다.

  1. 노드 이름을 가져와서 노드에 액세스합니다.

    $ oc get nodes
    $ oc debug nodes/<node_name>
  2. 노드에서 ocpodman 과 같은 툴에 대한 액세스를 활성화하려면 root 디렉터리를 /host 로 변경합니다.

    sh-4.2# chroot /host
  3. 액세스 토큰을 사용하여 컨테이너 이미지 레지스트리에 로그인합니다.

    sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
    sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

    다음과 같은 로그인 확인 메시지가 표시되어야합니다.

    Login Succeeded!
    참고

    사용자 이름에 모든 값을 지정할 수 있으므로 토큰에는 필요한 모든 정보가 포함됩니다. 콜론이 포함된 사용자 이름을 지정하면 로그인에 실패합니다.

    이미지 레지스트리 Operator가 경로를 생성하므로 default-route-openshift-image-registry.<cluster_name>과 유사합니다.

  4. 레지스트리에 대해 podman pullpodman push 작업을 수행합니다.

    중요

    모든 이미지를 가져올 수 있지만 system:registry 역할이 추가된 경우 프로젝트의 레지스트리에만 이미지를 푸시할 수 있습니다.

    다음 예에서는 다음을 사용합니다.

    구성 요소

    <registry_ip>

    172.30.124.220

    <port>

    5000

    <project>

    openshift

    <image>

    image

    <tag>

    생략됨 (기본값 latest)

    1. 모든 이미지를 가져옵니다.

      sh-4.2# podman pull <name.io>/<image>
    2. <registry_ip>:<port>/<project>/<image> 형식으로 새 이미지에 태그를 지정합니다. AWS의 Red Hat OpenShift Service가 레지스트리에 이미지를 올바르게 배치하고 나중에 액세스할 수 있도록 이 풀 사양에 프로젝트 이름이 표시되어야 합니다.

      sh-4.2# podman tag <name.io>/<image> image-registry.openshift-image-registry.svc:5000/openshift/<image>
      참고

      사용자가 이미지를 작성하거나 푸시할 수 있도록 지정된 프로젝트에 대한 system:image-builder 역할이 있어야합니다. 그렇지 않으면 다음 단계의 podman push가 실패합니다. 테스트를 위해 이미지를 푸시할 새 프로젝트를 만들 수 있습니다.

    3. 새로 태그가 지정된 이미지를 레지스트리로 푸시합니다.

      sh-4.2# podman push image-registry.openshift-image-registry.svc:5000/openshift/<image>

3.3. 레지스트리 pod 상태 확인

클러스터 관리자는 openshift-image-registry 프로젝트에서 실행중인 이미지 레지스트리 pod를 나열하고 해당 상태를 확인할 수 있습니다.

전제 조건

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

절차

  1. openshift-image-registry 프로젝트의 pod를 나열하고 상태를 확인합니다.

    $ oc get pods -n openshift-image-registry

    출력 예

    NAME READY STATUS RESTARTS AGE
    cluster-image-registry-operator-764bd7f846-qqtpb 1/1 Running 0 78m
    image-registry-79fb4469f6-llrln 1/1 Running 0 77m
    node-ca-hjksc 1/1 Running 0 73m
    node-ca-tftj6 1/1 Running 0 77m
    node-ca-wb6ht 1/1 Running 0 77m
    node-ca-zvt9q 1/1 Running 0 74m

3.4. 레지스트리 로그보기

oc logs 명령을 사용하여 레지스트리의 로그를 확인할 수 있습니다.

프로세스

  1. 배포에서 oc logs 명령을 사용하여 컨테이너 이미지 레지스트리의 로그를 표시합니다.

    $ oc logs deployments/image-registry -n openshift-image-registry

    출력 예

    2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
    2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
    2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
    2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
    2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

3.5. 레지스트리 메트릭 액세스

OpenShift Container 레지스트리는 Prometheus 메트릭에 대한 엔드 포인트를 제공합니다. Prometheus는 독립형 오픈 소스 시스템 모니터링 및 경고 툴킷입니다.

메트릭은 레지스트리 엔드 포인트의 /extensions/v2/metrics 경로에 표시됩니다.

절차

클러스터 역할을 사용하여 메트릭 쿼리를 실행하여 메트릭에 액세스할 수 있습니다.

클러스터 역할

  1. 메트릭에 액세스하는 데 필요한 클러스터 역할이 없는 경우 클러스터 역할을 생성합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: prometheus-scraper
    rules:
    - apiGroups:
      - image.openshift.io
      resources:
      - registry/metrics
      verbs:
      - get
    EOF
  2. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.

    $ oc adm policy add-cluster-role-to-user prometheus-scraper <username>

메트릭 쿼리

  1. 사용자 토큰을 가져옵니다.

    openshift:
    $ oc whoami -t
  2. 노드 또는 Pod 내부에서 메트릭 쿼리를 실행합니다. 예를 들면 다음과 같습니다.

    $ curl --insecure -s -u <user>:<secret> \ 1
        https://image-registry.openshift-image-registry.svc:5000/extensions/v2/metrics | grep imageregistry | head -n 20

    출력 예

    # HELP imageregistry_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which the image registry was built.
    # TYPE imageregistry_build_info gauge
    imageregistry_build_info{gitCommit="9f72191",gitVersion="v3.11.0+9f72191-135-dirty",major="3",minor="11+"} 1
    # HELP imageregistry_digest_cache_requests_total Total number of requests without scope to the digest cache.
    # TYPE imageregistry_digest_cache_requests_total counter
    imageregistry_digest_cache_requests_total{type="Hit"} 5
    imageregistry_digest_cache_requests_total{type="Miss"} 24
    # HELP imageregistry_digest_cache_scoped_requests_total Total number of scoped requests to the digest cache.
    # TYPE imageregistry_digest_cache_scoped_requests_total counter
    imageregistry_digest_cache_scoped_requests_total{type="Hit"} 33
    imageregistry_digest_cache_scoped_requests_total{type="Miss"} 44
    # HELP imageregistry_http_in_flight_requests A gauge of requests currently being served by the registry.
    # TYPE imageregistry_http_in_flight_requests gauge
    imageregistry_http_in_flight_requests 1
    # HELP imageregistry_http_request_duration_seconds A histogram of latencies for requests to the registry.
    # TYPE imageregistry_http_request_duration_seconds summary
    imageregistry_http_request_duration_seconds{method="get",quantile="0.5"} 0.01296087
    imageregistry_http_request_duration_seconds{method="get",quantile="0.9"} 0.014847248
    imageregistry_http_request_duration_seconds{method="get",quantile="0.99"} 0.015981195
    imageregistry_http_request_duration_seconds_sum{method="get"} 12.260727916000022

    1
    &lt ;user > 오브젝트는 임의의 값일 수 있지만 < secret > 태그는 사용자 토큰을 사용해야 합니다.

4장. 레지스트리 공개

기본적으로 OpenShift 이미지 레지스트리는 TLS를 통해 트래픽을 제공하도록 클러스터 설치 중에 보호됩니다. AWS의 이전 Red Hat OpenShift Service 버전과 달리 레지스트리는 설치시 클러스터 외부에 노출되지 않습니다.

4.1. 기본 레지스트리를 수동으로 공개

클러스터 내에서 기본 OpenShift 이미지 레지스트리에 로그인하는 대신 라우팅을 사용하여 외부 액세스 권한을 확보할 수 있습니다. 이 외부 액세스를 사용하면 라우팅 주소를 사용하여 클러스터 외부에서 레지스트리에 로그인하고 라우팅 호스트를 사용하여 기존 프로젝트에 이미지를 태그 지정하거나 푸시할 수 있습니다.

사전 요구 사항

  • 다음 사전 요구 사항이 자동으로 수행됩니다.

    • 레지스트리 Operator를 배포합니다.
    • Ingress Operator를 배포합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

절차

configs.imageregistry.operator.openshift.io 리소스에서 defaultRoute 매개변수를 사용하여 경로를 노출할 수 있습니다.

defaultRoute 를 사용하여 레지스트리를 공개하려면 다음을 수행합니다.

  1. defaultRoutetrue 로 설정합니다.

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. 기본 레지스트리 경로를 가져옵니다.

    $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
  3. Ingress Operator의 인증서를 가져옵니다.

    $ oc get secret -n openshift-ingress  router-certs-default -o go-template='{{index .data "tls.crt"}}' | base64 -d | sudo tee /etc/pki/ca-trust/source/anchors/${HOST}.crt  > /dev/null
  4. 다음 명령을 사용하여 경로를 신뢰하도록 클러스터의 기본 인증서를 활성화합니다.

    $ sudo update-ca-trust enable
  5. 기본 경로를 사용하여 podman으로 로그인합니다.

    $ sudo podman login -u kubeadmin -p $(oc whoami -t) $HOST

4.2. 수동으로 보안 레지스트리 공개

클러스터 내에서 OpenShift 이미지 레지스트리에 로그인하는 대신 라우팅을 사용하여 외부 액세스 권한을 얻을 수 있습니다. 이를 통해 라우팅 주소를 사용하여 클러스터 외부에서 레지스트리에 로그인하고 라우팅 호스트를 사용하여 기존 프로젝트에 이미지를 태그 지정하거나 푸시할 수 있습니다.

사전 요구 사항

  • 다음 사전 요구 사항이 자동으로 수행됩니다.

    • 레지스트리 Operator를 배포합니다.
    • Ingress Operator를 배포합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

절차

configs.imageregistry.operator.openshift.io 리소스에서 DefaultRoute 매개 변수를 사용하거나 사용자 지정 라우팅을 사용하여 라우팅을 공개할 수 있습니다.

DefaultRoute를 사용하여 레지스트리를 공개하려면 다음을 수행합니다.

  1. DefaultRouteTrue로 설정합니다.

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. podman으로 로그인합니다.

    $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
    $ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST 1
    1
    --tls-verify=false는 클러스터의 기본 라우팅 인증서를 신뢰할 수없는 경우 필요합니다. Ingress Operator를 사용하여 신뢰할 수있는 사용자 지정 인증서를 기본 인증서로 설정할 수 있습니다.

사용자 지정 라우팅을 사용하여 레지스트리를 공개하려면 다음을 수행합니다.

  1. 라우팅의 TLS 키로 보안 시크릿을 만듭니다.

    $ oc create secret tls public-route-tls \
        -n openshift-image-registry \
        --cert=</path/to/tls.crt> \
        --key=</path/to/tls.key>

    이 단계는 선택 사항입니다. 보안 시크릿을 생성하지 않으면 라우팅은 Ingress Operator의 기본 TLS 구성을 사용합니다.

  2. 레지스트리 Operator에서 다음을 수행합니다.

    spec:
      routes:
        - name: public-routes
          hostname: myregistry.mycorp.organization
          secretName: public-route-tls
    ...
    참고

    레지스트리 라우팅에 대한 사용자 지정 TLS 구성을 제공하는 경우에만 secretName을 설정합니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.