이 페이지는 Cloud Translation API를 통해 번역되었습니다.

컨테이너 이미지에 레지스트리 미러 사용

이 페이지에서는 gcr.io 같은 공개 레지스트리가 아닌 레지스트리 미러에서 가져온 이미지를 사용하여 클러스터를 만들고 업그레이드하는 방법을 설명합니다. 이 기능은 클러스터 수명 주기 중 언제든지 사용 설정하거나 중지할 수 있습니다.

이 페이지는 스토리지 성능, 사용량, 비용을 구성하고 관리하는 운영자 및 스토리지 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.

레지스트리 미러는 공개 레지스트리의 파일 구조를 복사하거나 미러링하는 공개 레지스트리의 로컬 복사본입니다. 예를 들어 로컬 레지스트리 미러의 경로가 172.18.0.20:5000이라고 가정해 보겠습니다. containerd에서 gcr.io/kubernetes-e2e-test-images/nautilus:1.0과 같은 이미지 pull 요청이 수행되면 containerd가 gcr.io가 아닌 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0 경로에 있는 로컬 레지스트리에서 이미지를 가져오려고 시도합니다. 이미지가 이 로컬 레지스트리 경로에 없으면 gcr.io 공개 레지스트리에서 이미지를 자동으로 가져옵니다.

레지스트리 미러를 사용할 때의 이점은 다음과 같습니다.

공개 레지스트리 중단으로부터 보호합니다.
포드 생성 속도가 빨라집니다.
자체 취약점 스캔을 수행할 수 있습니다.
공개 레지스트리에서 명령어를 실행할 수 있는 빈도에 적용되는 한도를 적용받지 않습니다.

시작하기 전에

네트워크에서 Artifact Registry 서버가 설정되어 있어야 합니다.
레지스트리 서버가 비공개 TLS 인증서를 실행할 경우 인증 기관(CA) 파일이 있어야 합니다.
레지스트리 서버에 인증이 필요하면 적절한 로그인 사용자 인증 정보 또는 Docker 구성 파일이 있어야 합니다.
Red Hat Quay 레지스트리를 사용하는 경우 로컬 레지스트리의 디렉터리 구조를 수동으로 만들어야 할 수 있습니다.
레지스트리 미러를 사용하려면 컨테이너 런타임을 containerd로 설정해야 합니다.
관리자 워크스테이션에 이미지 업로드를 위한 디스크 공간이 충분한지 확인합니다. 이미지 업로드 명령어 bmctl push images는 다운로드한 이미지 패키지 파일을 압축 해제한 다음 모든 이미지 파일을 로컬로 추출한 후 업로드합니다. 이미지를 업로드하려면 다운로드한 이미지 패키지 파일 크기의 3배 이상의 디스크 공간이 필요합니다.

예를 들어 압축된 bmpackages_1.33.0-gke.799.tar.xz 파일은 디스크 공간을 약 12GB 차지하므로 파일을 다운로드하기 전에 디스크 공간이 36GB 이상 있어야 합니다.

업그레이드 건너뛰기 (단일 작업에서 두 개의 부 버전을 업그레이드)를 실행하는 경우 타겟 (N+2) 버전과 중간(N+1) 버전 모두의 이미지 패키지 파일에서 이미지를 업로드해야 합니다. 이 예에 따르면 이미지 업로드에 약 72GB의 여유 디스크 공간이 필요합니다. 중간 버전에 관한 자세한 내용은 레지스트리 미러의 추가 요구사항을 참고하세요.

Google Distributed Cloud에 필요한 모든 이미지 다운로드

bmctl 도구 및 이미지 패키지의 최신 버전을 다운로드 페이지에서 다운로드하세요.

레지스트리 서버에 컨테이너 이미지 업로드

bmctl push images를 사용하여 컨테이너 이미지를 저장소 서버에 업로드하면 bmctl는 다음 단계를 순서대로 실행합니다.

다운로드한 이미지 패키지 압축 tar 파일(예: bmpackages_1.33.100-gke.89.tar.xz)을 bmpackages_1.33.100-gke.89.tar로 압축 해제합니다.
압축 해제된 tar 파일에서 모든 이미지를 bmpackages_1.33.100-gke.89라는 디렉터리로 추출합니다.
각 이미지 파일을 지정된 비공개 레지스트리로 푸시합니다.

bmctl는 기본 인증에 --username 및 --password 값을 사용하여 이미지를 비공개 레지스트리로 푸시합니다.

다음 섹션에서는 이미지를 저장소 서버에 업로드하는 bmctl push images 명령어의 일반적인 변형을 보여줍니다.

레지스트리로 인증하고 TLS 인증서 공유

다음 명령어에는 레지스트리 서버를 사용한 사용자 인증을 위한 --username 및 --password 플래그가 포함되어 있습니다. 이 명령어에는 이미지 푸시 및 풀을 비롯한 보안 레지스트리 서버 통신에 사용되는 CA 전송 계층 보안 (TLS) 인증서를 전달하는 --cacert 플래그도 포함됩니다. 이러한 플래그는 레지스트리 서버에 기본적인 보안을 제공합니다.

레지스트리 서버에 인증이 필요하고 --username 및 --password 플래그를 사용하지 않는 경우 bmctl push images를 실행할 때 사용자 인증 정보를 묻는 메시지가 표시됩니다. 비밀번호를 입력하거나 사용자 인증 정보가 포함된 Docker 구성 파일을 선택할 수 있습니다.

인증 및 비공개 CA 인증서로 이미지를 업로드하려면 다음과 같은 명령어를 사용하세요.

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --username USERNAME \
    --password PASSWORD \
    --cacert CERT_PATH

다음을 바꿉니다.

IMAGES_TAR_FILE_PATH: 다운로드된 이미지 패키지 tar 파일의 경로입니다(예: bmpackages_1.33.100-gke.89.tar.xz).
REGISTRY_IP:PORT: 비공개 레지스트리 서버의 IP 주소와 포트입니다.
USERNAME: 레지스트리 서버에 이미지를 업로드할 액세스 권한이 있는 사용자의 사용자 이름입니다.
PASSWORD: 레지스트리 서버로 인증하기 위한 사용자의 비밀번호입니다.
CERT_PATH: 레지스트리 서버에 비공개 TLS 인증서가 사용되는 경우 CA 인증서 파일의 경로입니다.

예를 들면 다음과 같습니다.

bmctl push images \
    --source bmpackages_1.33.100-gke.89.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --username alex --password pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

사용자 인증 또는 인증서 없이 이미지 업로드

레지스트리 서버에 사용자 이름 및 비밀번호와 같은 사용자 인증 정보가 필요하지 않으면 bmctl 명령어에서 --need-credential=false를 지정합니다. 레지스트리 서버에서 공개 TLS 인증서를 사용하는 경우 --cacert 플래그를 사용하지 않아도 됩니다. 이 유형의 업로드 명령어는 보안이 프로덕션보다 덜 중요한 테스트 환경에 가장 적합합니다.

인증이나 비공개 CA 인증서 없이 이미지를 업로드하려면 다음과 같은 명령어를 사용하세요.

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --need-credential=false

예를 들면 다음과 같습니다.

bmctl push images \
    --source bmpackages_1.33.100-gke.89.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --need-credential=false.

스레드 수 조정

이미지 업로드 루틴은 이미지 패키지 tar 파일의 컨테이너 이미지 크기와 수량으로 인해 시간이 오래 걸릴 수 있습니다. 동시 스레드 수를 늘리면 루틴이 더 빠르게 실행됩니다. --threads 플래그를 사용하여 bmctl push images가 사용하는 병렬 스레드 수를 변경할 수 있습니다.

기본적으로 이미지 업로드 루틴은 4개의 스레드를 사용합니다. 이미지 업로드에 너무 오래 걸리면 이 값을 늘립니다. 벤치마크로, Google 테스트 환경에서 CPU가 4개인 워크스테이션에서 이미지를 업로드하는 데는 병렬 스레드 8개로 약 10분이 걸립니다.

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --cacert CERT_PATH \
    --threads NUM_THREADS

NUM_THREADS을 이미지 업로드를 처리하는 데 사용되는 병렬 스레드 수로 바꿉니다. 기본적으로 bmctl push images는 4개의 병렬 스레드를 사용합니다.

다음 명령어는 업로드 시간을 줄이기 위해 4에서 8로 업로드 스레드 수를 늘립니다.

bmctl push images \
    --source bmpackages_1.33.100-gke.89.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem \
    --threads 8

프록시를 통해 업로드

워크스테이션에서 레지스트리 서버로 이미지를 업로드하기 위해 프록시가 필요한 경우 bmctl 명령어 앞에 프록시 세부정보를 추가하면 됩니다.

HTTPS_PROXY=http://PROXY_IP:PORT bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT \
    --cacert=CERT_PATH

다음을 바꿉니다.

PROXY_IP:PORT: 프록시의 IP 주소와 포트입니다.
IMAGES_TAR_FILE_PATH: 다운로드된 이미지 패키지 tar 파일의 경로입니다(예: bmpackages_1.33.100-gke.89.tar.xz).
REGISTRY_IP:PORT: 비공개 레지스트리 서버의 IP 주소와 포트입니다.
CERT_PATH: 레지스트리 서버에 비공개 TLS 인증서가 사용되는 경우 CA 인증서 파일의 경로입니다.

메시지가 표시되면 사용자 이름과 비밀번호를 입력하거나 Docker 구성 파일을 선택합니다.

다음 명령어는 프록시를 통해 이미지를 업로드합니다.

HTTPS_PROXY=http://10.128.0.136:3128 bmctl push images \
    --source bmpackages_1.33.100-gke.89.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem

`bmctl push images`를 사용하여 자체 네임스페이스 사용

루트 네임스페이스 대신 레지스트리 서버에서 자체 네임스페이스를 사용하려는 경우 containerd는 클러스터 구성 파일의 registryMirrors.endpoint 필드에 비공개 레지스트리의 API 엔드포인트를 제공한 경우 이 네임스페이스에서 가져올 수 있습니다. 엔드포인트는 일반적으로 <REGISTRY_IP:PORT>/v2/<NAMESPACE> 형식입니다. 특정 세부정보는 비공개 레지스트리 사용자 가이드에서 확인하세요. 자세한 내용은 레지스트리 엔드포인트에서 v2 사용 정보를 참고하세요.

bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT/NAMESPACE \
    --cacert=CERT_PATH

NAMESPACE을 레지스트리 서버에서 이미지를 업로드할 네임스페이스의 이름으로 바꿉니다.

예를 들어 198.51.20:5000/test-namespace/에 대한 액세스 권한만 있으면 다음과 같은 명령어를 사용하여 test-namespace 네임스페이스 아래의 모든 이미지를 업로드할 수 있습니다.

bmctl push images \
    --source=./bmpackages_1.33.100-gke.89.tar.xz \
    --private-registry=198.51.20:5000/test-namespace \
    --username=alex \
    --password=pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

그런 다음 클러스터 구성 파일에서 다음 항목을 추가하여 containerd가 test-namespace 네임스페이스에서 가져오게 할 수 있습니다.

registryMirrors:
  - endpoint: https://198.51.20:5000/v2/test-namespace

bmctl push images 명령어에 대한 자세한 내용은 bmctl 명령어 참조를 확인하세요.

레지스트리 미러를 사용하도록 클러스터 구성

클러스터를 만들 때 또는 기존 클러스터를 업데이트할 때마다 클러스터의 레지스트리 미러를 구성할 수 있습니다. 사용하는 구성 방법은 클러스터 유형에 따라 다르며, 사용자 클러스터의 경우 클러스터를 만드는지 아니면 클러스터를 업데이트하는지에 따라 다릅니다. 다음 두 섹션에서는 레지스트리 미러를 구성하는 데 사용할 수 있는 두 가지 방법을 설명합니다.

클러스터 구성 파일의 헤더 섹션 사용

Google Distributed Cloud를 사용하면 클러스터 사양 외부의 레지스트리 미러를 클러스터 구성 파일의 헤더 섹션에 지정할 수 있습니다. 관리자, 하이브리드, 독립형 클러스터의 경우 레지스트리 미러를 지정하는 데 지원되는 유일한 방법입니다. 이 방법은 클러스터 생성 또는 클러스터 업데이트에 적용됩니다.

사용자 클러스터의 경우 클러스터 리소스의 nodeConfig.registryMirrors 섹션을 사용하여 레지스트리 미러 구성을 지정하고 유지하는 것이 좋습니다. 사용자 클러스터를 만들 때 클러스터 구성 파일의 헤더 섹션을 사용하여 레지스트리 미러를 지정할 수 있지만 업데이트 간에 사양이 유지되지는 않습니다.

다음 샘플 클러스터 구성 파일은 엔드포인트가 https://198.51.20:5000인 로컬 레지스트리 미러에서 이미지를 가져오도록 지정합니다. 이 구성 파일의 시작 부분에 표시되는 일부 필드에 대해서는 다음 섹션에서 설명됩니다.

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://198.51.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

클러스터 사양에서 `nodeConfig.registryMirrors` 섹션 사용

레지스트리 미러를 생성하거나 업데이트하는 이 방법은 사용자 클러스터에만 적용됩니다. 관리 클러스터용으로 생성된 보안 비밀을 사용자 클러스터와 공유할 수 있으므로 관리 관리자 또는 하이브리드 클러스터의 nodeConfig.registryMirrors를 사용하여 사용자 클러스터의 클러스터 사양에서 레지스트리 미러를 지정할 수 있습니다.

관리자 클러스터와 동일한 레지스트리 미러를 사용하도록 사용자 클러스터를 구성하려면 다음 단계를 따르세요.

관리자 클러스터 리소스의 nodeConfig.registryMirrors에서 보안 비밀 참조를 포함한 nodeConfig.registryMirror 섹션을 가져옵니다.
```
kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG \
    -o yaml
```
다음을 바꿉니다.
- CLUSTER_NAME: 사용자 클러스터를 관리하는 관리자 또는 하이브리드 클러스터의 이름입니다.
- CLUSTER_NAMESPACE: 관리 클러스터의 네임스페이스 이름입니다.
- ADMIN_KUBECONFIG: 관리 클러스터의 kubeconfig 파일 경로

관리자 클러스터의 nodeConfig.registryMirrors 구성을 사용자 클러스터의 클러스터 구성 파일에 추가합니다.

사용자 클러스터 구성 파일의 registryMirrors 섹션은 다음 예시와 비슷해야 합니다.

---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  nodeConfig:
    containerRuntime: containerd
    registryMirrors:
    -   caCertSecretRef:
        name: the-secret-created-for-the-admin-cluster
        namespace: anthos-creds
      endpoint: https://172.18.0.20:5000
      hosts:
        -   somehost.io
        -   otherhost.io
      pullCredentialSecretRef:
        name: the-image-pull-creds-created-for-the-admin-cluster
        namespace: anthos-creds
...

사용자 클러스터의 레지스트리 미러 구성을 후속으로 변경하려면 사용자 클러스터 구성 파일에서 nodeConfig.registryMirrors를 수정하고 bmctl update로 변경사항을 적용합니다.

클러스터 구성 파일의 헤더 섹션을 사용하여 사용자 클러스터의 레지스트리 미러 구성을 업데이트할 수 없습니다.

`hosts` 필드

containerd는 클러스터 구성 파일의 hosts 섹션에서 로컬로 미러링되는 호스트를 검색합니다. 이러한 호스트는 클러스터 구성 파일(registryMirror.endpoint)에 지정된 레지스트리 미러 엔드포인트에 매핑됩니다. 이전 섹션의 예시 구성 파일에서 hosts 섹션에 나열된 공개 레지스트리는 somehost.io 및 otherhost.io입니다. 이러한 공개 레지스트리가 hosts 섹션에 표시되기 때문에 containerd는 somehost.io 또는 otherhost.io에서 이미지에 대한 pull 요청이 수행될 때 비공개 레지스트리 미러를 먼저 검사합니다.

예를 들어 containerd에서 somehost.io/kubernetes-e2e-test-images/nautilus:1.0에 대한 pull 명령어를 수신한다고 가정해 보겠습니다. somehost.io가 클러스터 구성 파일의 hosts 섹션에 호스트 중 하나로 나열되기 때문에 containerd가 로컬 레지스트리 미러에서 kubernetes-e2e-test-images/nautilus:1.0 이미지를 찾습니다. somehost.io가 hosts 섹션에 나열되지 않은 경우 containerd는 somehost.io의 로컬 미러가 존재한다는 것을 알지 못합니다. 이 경우 containerd는 이미지 미러를 검사하지 않고 somehost.io 공개 레지스트리에서 이미지를 가져옵니다.

기본적으로 Google Distributed Cloud는 gcr.io에서 이미지를 자동으로 미러링하므로 hosts 섹션에서 gcr.io를 호스트로 나열할 필요가 없습니다.

hosts 값과 endpoint 값이 중복되어서는 안 됩니다. 예를 들어 다음 구성 샘플은 엔드포인트 값의 도메인 부분과 일치하는 호스트 europe-docker.pkg.dev를 보여줍니다. 이 경우 hosts 값을 지정하지 않아도 됩니다.

...
registryMirrors:
  ...
  endpoint: https://europe-docker.pkg.dev:5000/v2/cloud-data-fusion-images
  hosts:
    - europe-docker.pkg.dev
    ...

`gcrKeyPath` 필드

Google Distributed Cloud가 Artifact Registry(gcr.io)를 자동으로 사용해서 로컬 레지스트리에 표시되지 않는 이미지를 가져오도록 하려면 Artifact Registry 서비스 계정 키에 대한 경로를 지정해야 합니다. Google Distributed Cloud에는 다른 공개 레지스트리에 대한 키를 제공하기 위한 메커니즘이 없습니다.

이미지가 로컬 레지스트리에 표시되지 않을 때 gcr.io에서 이미지를 가져오는 기능을 사용할 계획이 없으면 클러스터 구성 파일에 gcrKeyPath를 추가할 필요가 없습니다.

`caCertPath` 필드

레지스트리에 비공개 전송 계층 보안(TLS) 인증서가 필요한 경우 이 필드는 서버 루트 CA 인증서 파일 경로를 사용합니다. 이 인증서 파일은 bmctl 명령어를 실행하는 머신인 관리자 워크스테이션에 있어야 합니다. 레지스트리에 비공개 TLS 인증서가 필요하지 않으면 caCertPath 필드를 비워 둘 수 있습니다.

`pullCredentialConfigPath` 필드

레지스트리 서버에 인증 Docker 구성 파일이 필요하지 않으면 pullCredentialConfigPath 필드를 비워 둘 수 있습니다. 이것은 bmctl 명령어를 실행하는 머신의 구성 파일 경로입니다.

사용자 클러스터와 함께 레지스트리 미러 사용

관리자 클러스터가 레지스트리 미러에서 자동으로 이미지를 가져오도록 구성된 경우 사용자 클러스터는 자동으로 이미지를 가져오지 않습니다. 사용자 클러스터가 레지스트리 미러에서 가져오도록 하려면 레지스트리 미러를 사용하도록 클러스터 구성에 설명된 대로 개별적으로 구성해야 합니다.

레지스트리 미러 엔드포인트, 인증서, 가져오기 인증서 업데이트

레지스트리 미러 엔드포인트, 인증서, 가져오기 인증서를 업데이트하려면 다음 안내를 따르세요.

클러스터 구성 파일에서 엔드포인트, CA 인증서 파일, 가져오기 사용자 인증 정보 구성 파일의 경로를 업데이트합니다.
다음을 실행하여 변경사항을 적용합니다.
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
다음을 바꿉니다.
- CLUSTER_NAME: 업데이트하려는 클러스터 이름으로 바꿉니다.
- ADMIN_KUBECONFIG: 관리자 클러스터 구성 파일의 경로로 바꿉니다.

레지스트리 미러에서 이미지를 가져왔는지 확인

다음 단계에 따라 config.toml 파일의 내용을 검사하여 containerd가 로컬 레지스트리에서 이미지를 가져오는지 여부를 확인할 수 있습니다.

노드에 로그인하고 /etc/containerd/config.toml 파일의 콘텐츠를 검사합니다.

config.toml 파일의 plugins."io.containerd.grpc.v1.cri".registry.mirrors 섹션에서 레지스트리 서버가 endpoint 필드에 나열되어 있는지 확인합니다. 다음은 endpoint 필드가 굵게 표시된 예시 config.toml 파일에서 발췌한 부분입니다.

version = 2
root = "/var/lib/containerd"
state = "/run/containerd"
...
[plugins."io.containerd.grpc.v1.cri".registry]
  [plugins."io.containerd.grpc.v1.cri".registry.configs]
    [plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io"]
      [plugins."io.containerd.grpc.v1.cri".registry.configs."privateregistry2.io".tls]
        ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
      endpoint = ["http://privateregistry.io", "https://privateregistry2.io"]
...

레지스트리 미러가 endpoint 필드에 표시되면 노드가 공개 레지스트리가 아닌 레지스트리 미러에서 이미지를 가져옵니다.

레지스트리 미러 설정 문제 해결

컨테이너 런타임 인터페이스 명령줄 도구인 crictl를 사용하여 개별 이미지 파일을 다운로드하여 레지스트리 설정을 테스트할 수 있습니다. 각 이미지 파일에는 의미 있는 버전 문자열이 독립적으로 태그됩니다. 예를 들어 클러스터 API 컨트롤러 이미지는 Google Distributed Cloud 출시 버전으로 태그되고 etcd 이미지는 해당 etcd 버전으로 태그됩니다.

베어메탈용 Google Distributed Cloud 버전 1.31.200-gke.59의 경우 클러스터 API 컨트롤러 이미지 cluster-api-controller와 etcd 이미지 etcd에 다음 태그가 있습니다.

cluster-api-controller:1.31.200-gke.59
etcd:v3.4.30-0-gke.1

레지스트리 미러에서 이미지 가져오기

레지스트리 미러가 네임스페이스를 사용하지 않는 경우 다음 명령어를 사용하여 이미지를 가져옵니다.

crictl pull REGISTRY_IP:PORT/IMAGE_PATH:IMAGE_TAG

네임스페이스를 사용하는 레지스트리 미러에서 이미지 가져오기

레지스트리 미러에서 네임스페이스를 사용하는 경우 다음 명령어를 사용하여 이미지를 가져옵니다.

crictl pull REGISTRY_IP:PORT/NAMESPACE/IMAGE_PATH:IMAGE_TAG

레지스트리 엔드포인트에서 `v2` 사용에 관한 정보

레지스트리에서 커스텀 네임스페이스를 사용하는 경우 클러스터 구성 파일의 레지스트리 엔드포인트 (registryMirror.endpoint)에 v2/을 추가해야 합니다. 네임스페이스를 사용하지 않는 경우 v2를 사용하지 마세요. 두 경우 모두 --private-registry 플래그 값 또는 이미지 가져오기 명령어에 v2를 사용하지 마세요.

네임스페이스 없음

유효:
- endpoint: https://172.18.0.20:5000
- crictl pull 172.18.0.20:5000/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
잘못됨:
- endpoint: https://172.18.0.20:5000/v2
- crictl pull 172.18.0.20:5000/v2/anthos-baremetal-release/etcd:v3.4.30-0-gke.1

네임스페이스 사용

유효:
- endpoint: https://172.18.0.21:5000/v2/namespace
- crictl 172.18.0.21:5000/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
잘못됨:
- endpoint: https://172.18.0.21:5000/namespace
- crictl pull 172.18.0.21:5000/v2/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1