5.4. 미러 레지스트리가 있는 Windows 컨테이너 사용
WMCO(Windows Machine Config Operator)는 미러 레지스트리에서 이미지를 가져오도록 클러스터를 구성하도록 ImageDigestMirrorSet
(IDMS) 또는 ImageTagMirrorSet
(ITMS) 오브젝트를 사용하여 퍼블릭 레지스트리에서 아닌 레지스트리 미러 레지스트리에서 이미지를 가져올 수 있습니다.
미러 레지스트리는 다음과 같은 이점이 있습니다.
- 공개 레지스트리 중단 방지
- 노드 및 Pod 생성 속도 향상
- 조직의 방화벽 뒤에서 이미지를 가져옵니다.
미러 레지스트리는 연결이 끊긴 또는 Air-gapped 네트워크의 OpenShift Container Platform 클러스터에서도 사용할 수 있습니다. 연결이 끊긴 네트워크는 직접 인터넷 연결이 없는 제한된 네트워크입니다. 클러스터가 인터넷에 액세스할 수 없으므로 외부 컨테이너 이미지를 참조할 수 없습니다.
미러 레지스트리를 사용하려면 다음과 같은 일반적인 단계가 필요합니다.
- Red Hat Quay와 같은 툴을 사용하여 미러 레지스트리를 만듭니다.
- 컨테이너 이미지 레지스트리 자격 증명 파일을 생성합니다.
- 온라인 이미지 저장소의 이미지를 미러 레지스트리로 복사합니다.
이러한 단계에 대한 자세한 내용은 "연결 해제된 설치 미러링 정보"를 참조하십시오.
미러 레지스트리를 생성하고 이미지를 미러링한 후 ImageDigestMirrorSet
(IDMS) 또는 ImageTagMirrorSet
(ITMS) 오브젝트를 사용하여 각 Pod 사양을 업데이트하지 않고도 미러 레지스트리에서 이미지를 가져오도록 클러스터를 구성할 수 있습니다. IDMS 및 ITMS 오브젝트는 소스 이미지 레지스트리의 리포지토리에서 이미지를 가져오기 위해 요청을 리디렉션하고 대신 미러 저장소에서 이를 해결하도록 합니다.
IDMS 또는 ITMS 개체를 변경하면 WMCO가 새 정보를 사용하여 Windows 노드의 적절한 hosts.toml
파일을 자동으로 업데이트합니다. WMCO는 미러 설정이 변경되면 각 Windows 노드를 순차적으로 업데이트합니다. 따라서 이러한 업데이트에 필요한 시간은 클러스터의 Windows 노드 수에 따라 증가합니다.
또한 WMCO가 구성한 Windows 노드는 컨테이너된 컨테이너 런타임에 의존하므로 WMCO는 레지스트리 설정에 따라 컨테이너 구성 파일을 최신 상태로 유지합니다. 새 노드의 경우 이러한 파일은 생성 시 인스턴스에 복사됩니다. 기존 노드의 경우 미러 레지스트리를 활성화한 후 레지스트리 컨트롤러는 SSH를 사용하여 각 노드에 액세스하고 생성된 구성 파일을 복사하여 기존 파일을 교체합니다.
머신 세트 또는 BYOH(Bring-Your-Own-Host) Windows 노드와 함께 미러 레지스트리를 사용할 수 있습니다.
추가 리소스
5.4.1. 이미지 레지스트리 저장소 미러링 이해
컨테이너 레지스트리 저장소 미러링을 설정하면 다음 작업을 수행할 수 있습니다.
- 소스 이미지 레지스트리의 저장소에서 이미지를 가져오기 위해 요청을 리디렉션하고 미러링된 이미지 레지스트리의 저장소에서 이를 해석하도록 OpenShift Container Platform 클러스터를 설정합니다.
- 하나의 미러가 다운된 경우 다른 미러를 사용할 수 있도록 각 대상 저장소에 대해 여러 미러링된 저장소를 확인합니다.
OpenShift Container Platform의 저장소 미러링에는 다음 속성이 포함되어 있습니다.
- 이미지 풀은 레지스트리 다운타임에 탄력적으로 대처할 수 있습니다.
- 연결이 끊긴 환경의 클러스터는 중요한 위치(예: quay.io)에서 이미지를 가져오고 회사 방화벽 뒤의 레지스트리에서 요청된 이미지를 제공하도록 할 수 있습니다.
- 이미지 가져오기 요청이 있으면 특정한 레지스트리 순서로 가져오기를 시도하며 일반적으로 영구 레지스트리는 마지막으로 시도합니다.
-
입력한 미러 정보가 OpenShift Container Platform 클러스터의 모든 Windows 노드의 적절한
hosts.toml
컨테이너 구성 파일에 추가됩니다. - 노드가 소스 저장소에서 이미지를 요청하면 요청된 컨텐츠를 찾을 때 까지 미러링된 각 저장소를 차례로 시도합니다. 모든 미러가 실패하면 클러스터는 소스 저장소를 시도합니다. 성공하면 이미지를 노드로 가져올 수 있습니다.
저장소 미러링은 다음과 같은 방법으로 설정할 수 있습니다.
OpenShift Container Platform 설치 시
OpenShift Container Platform에 필요한 컨테이너 이미지를 가져온 다음 해당 이미지를 회사 방화벽 뒤에 배치하면 연결이 끊긴 환경에 있는 데이터 센터에 OpenShift Container Platform을 설치할 수 있습니다.
OpenShift Container Platform 설치 후
OpenShift Container Platform 설치 중에 미러링을 구성하지 않은 경우 다음 CR(사용자 정의 리소스) 오브젝트를 사용하여 설치 후 설치할 수 있습니다.
-
ImageDigestMirrorSet
(IDMS). 이 오브젝트를 사용하면 다이제스트 사양을 사용하여 미러링된 레지스트리에서 이미지를 가져올 수 있습니다. IDMS CR을 사용하면 이미지 가져오기에 실패하는 경우 소스 레지스트리에서 지속적인 시도를 허용하거나 중지하는 fall back 정책을 설정할 수 있습니다. -
ImageTagMirrorSet
(ITMS). 이 오브젝트를 사용하면 이미지 태그를 사용하여 미러링된 레지스트리에서 이미지를 가져올 수 있습니다. ITMS CR을 사용하면 이미지 가져오기에 실패하는 경우 소스 레지스트리에서 지속적으로 시도하려는 시도를 허용하거나 중지하는 fall back 정책을 설정할 수 있습니다.
-
이러한 사용자 정의 리소스 오브젝트 각각 다음 정보를 식별합니다.
- 미러링하려는 컨테이너 이미지 저장소의 소스
- 소스 저장소에서 요청된 컨텐츠를 제공하는 각 미러 저장소에 대한 개별 항목
WMCO(Windows Machine Config Operator)는 IDMS 및 ITMS 리소스에 대한 변경 사항을 감시하고 이러한 변경 사항이 포함된 hosts.toml
컨테이너 구성 파일 세트, 각 소스 레지스트리에 대해 하나의 파일을 생성합니다. 그런 다음 WMCO는 새 레지스트리 구성을 사용하도록 기존 Windows 노드를 업데이트합니다.
미러링된 레지스트리를 사용하여 Windows 노드를 추가하려면 IDMS 및 ITMS 개체를 생성해야 합니다.
5.4.2. 이미지 레지스트리 저장소 미러링 설정
설치 후 미러 구성 CR(사용자 정의 리소스)을 생성하여 소스 이미지 레지스트리에서 미러링된 이미지 레지스트리로 이미지 가져오기 요청을 리디렉션할 수 있습니다.
ImageDigestMirrorSet
및 ImageTagMirrorSet
개체를 통해 미러링된 Windows 이미지에는 특정 이름 지정 요구 사항이 있습니다. 네임스페이스의 마지막 부분과 미러 이미지의 이미지 이름은 미러링 중인 이미지와 일치해야 합니다. 예를 들어 mcr.microsoft.com/oss/kubernetes/pause:3.9
이미지를 미러링할 때 미러 이미지에 < mirror_registry>/<optional_namespaces>/oss/kubernetes/pause:3.9
형식이 있어야 합니다. optional_namespaces
는 모든 수의 선행 리포지토리 네임스페이스일 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
미러링된 저장소를 설정합니다.
- Red Hat Quay Repository Mirroring에 설명된대로 Red Hat Quay를 사용하여 미러링된 저장소를 설정합니다. Red Hat Quay를 사용하면 한 저장소에서 다른 저장소로 이미지를 복사하고 시간이 지남에 따라 해당 저장소를 반복해서 자동으로 동기화할 수 있습니다.
skopeo
와 같은 툴을 사용하여 소스 저장소에서 미러링된 저장소로 이미지를 수동으로 복사합니다.예를 들어, Red Hat Enterprise Linux(RHEL) 7 또는 RHEL 8 시스템에 skopeo RPM 패키지를 설치한 후 다음 예와 같이
skopeo
명령을 사용합니다.$ skopeo copy --all \ docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \ docker://example.io/example/ubi-minimal
이 예제에는
example.io
라는 컨테이너 이미지 레지스트리가 있으며,registry.access.redhat.com
에서ubi9/ubi-minimal
이미지를 복사할example
이라는 이미지 저장소가 있습니다. 미러링된 레지스트리를 생성한 후 OpenShift Container Platform 클러스터를 구성하여 소스 저장소의 요청을 미러링된 저장소로 리디렉션할 수 있습니다.
중요mcr.microsoft.com/oss/kubernetes/pause:3.9
이미지를 미러링해야 합니다. 예를 들어 다음skopeo
명령을 사용하여 이미지를 미러링할 수 있습니다.$ skopeo copy \ docker://mcr.microsoft.com/oss/kubernetes/pause:3.9\ docker://example.io/oss/kubernetes/pause:3.9
- OpenShift Container Platform 클러스터에 로그인합니다.
필요에 따라
ImageDigestMirrorSet
또는ImageTagMirrorSet
CR을 생성하여 소스 및 미러를 자체 레지스트리 및 저장소 쌍과 이미지로 교체합니다.apiVersion: config.openshift.io/v1 1 kind: ImageDigestMirrorSet 2 metadata: name: ubi9repo spec: imageDigestMirrors: 3 - mirrors: - example.io/example/ubi-minimal 4 - example.com/example2/ubi-minimal 5 source: registry.access.redhat.com/ubi9/ubi-minimal 6 mirrorSourcePolicy: AllowContactingSource 7 - mirrors: - mirror.example.com source: registry.redhat.io mirrorSourcePolicy: NeverContactSource - mirrors: - docker.io source: docker-mirror.internal mirrorSourcePolicy: AllowContactingSource
- 1
- 이 CR과 함께 사용할 API를 나타냅니다.
config.openshift.io/v1
이어야 합니다. - 2
- 풀 유형에 따라 오브젝트의 종류를 나타냅니다.
-
ImageDigestMirrorSet
: 다이제스트 참조 이미지를 가져옵니다. -
ImageTagMirrorSet
: 태그 참조 이미지를 가져옵니다.
-
- 3
- 이미지 가져오기 방법 유형을 나타냅니다.
-
imageDigestMirrors
:ImageDigestMirrorSet
CR에 사용합니다. -
imageTagMirrors
:ImageTagMirrorSet
CR에 사용합니다.
-
- 4
- 미러링된 이미지 레지스트리 및 저장소의 이름을 나타냅니다.
- 5
- 선택 사항: 각 대상 저장소에 대한 보조 미러 저장소를 나타냅니다. 하나의 미러가 다운되면 대상 저장소에서 다른 미러를 사용할 수 있습니다.
- 6
- 이미지 가져오기 사양에서 참조하는 레지스트리 및 리포지토리 소스를 나타냅니다.
- 7
- 선택 사항: 이미지 가져오기에 실패하는 경우 대체 정책을 표시합니다.
-
AllowContactingSource
: 소스 저장소에서 이미지를 계속 가져올 수 있습니다. 이는 기본값입니다. -
NeverContactSource
: 소스 저장소에서 이미지를 가져 오는 지속적인 시도를 방지합니다.
-
새 오브젝트를 생성합니다.
$ oc create -f registryrepomirror.yaml
미러링된 구성 설정이 적용되었는지 확인하려면 노드 중 하나에서 다음을 수행하십시오.
노드를 나열합니다.
$ oc get node
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-137-44.ec2.internal Ready worker 7m v1.30.3 ip-10-0-138-148.ec2.internal Ready master 11m v1.30.3 ip-10-0-139-122.ec2.internal Ready master 11m v1.30.3 ip-10-0-147-35.ec2.internal Ready worker 7m v1.30.3 ip-10-0-153-12.ec2.internal Ready worker 7m v1.30.3 ip-10-0-154-10.ec2.internal Ready master 11m v1.30.3
디버깅 프로세스를 시작하고 노드에 액세스합니다.
$ oc debug node/ip-10-0-147-35.ec2.internal
출력 예
Starting pod/ip-10-0-147-35ec2internal-debug ... To use host binaries, run `chroot /host`
루트 디렉토리를
/host
로 변경합니다.sh-4.2# chroot /host
WMCO가 각 Windows 인스턴스의 각 레지스트리에 대해
hosts.toml
파일을 생성했는지 확인합니다. 이전 예제 IDMS 오브젝트의 경우 다음 파일 구조에 세 개의 파일이 있어야 합니다.$ tree $config_path
출력 예
C:/k/containerd/registries/ |── registry.access.redhat.com | └── hosts.toml |── mirror.example.com | └── hosts.toml └── docker.io └── hosts.toml:
다음 출력은 이전 예제 IDMS 오브젝트가 적용된
hosts.toml
컨테이너 설정 파일을 나타냅니다.host.toml 파일의 예
$ cat "$config_path"/registry.access.redhat.com/host.toml server = "https://registry.access.redhat.com" # default fallback server since "AllowContactingSource" mirrorSourcePolicy is set [host."https://example.io/example/ubi-minimal"] capabilities = ["pull"] [host."https://example.com/example2/ubi-minimal"] # secondary mirror capabilities = ["pull"] $ cat "$config_path"/registry.redhat.io/host.toml # "server" omitted since "NeverContactSource" mirrorSourcePolicy is set [host."https://mirror.example.com"] capabilities = ["pull"] $ cat "$config_path"/docker.io/host.toml server = "https://docker.io" [host."https://docker-mirror.internal"] capabilities = ["pull", "resolve"] # resolve tags
소스에서 이미지를 노드로 가져와 미러링에 의해 해결되는지 확인합니다.
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...
저장소 미러링 문제 해결
저장소 미러링 절차가 설명대로 작동하지 않는 경우 저장소 미러링 작동 방법에 대한 다음 정보를 사용하여 문제를 해결하십시오.
- 가져온 이미지는 첫 번째 작동 미러를 사용하여 공급합니다.
- 주요 레지스트리는 다른 미러가 작동하지 않는 경우에만 사용됩니다.
-
시스템 컨텍스트에서
Insecure
플래그가 폴백으로 사용됩니다.