5.6. 미러 레지스트리가 있는 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 노드와 함께 미러 레지스트리를 사용할 수 있습니다.
IDMS 또는 ITMS 오브젝트를 사용하여 Windows 노드에서 컨테이너 이미지를 미러링하는 경우 Linux 노드와 다른 다음 동작을 기록해 두십시오.
Windows 노드에서 미러링은 Linux 노드에서 사용하는 이미지 수준이 아닌 레지스트리 수준에서 작동합니다. 따라서 IDMS 또는 ITMS 개체를 사용하여 미러링된 Windows 이미지에는 특정 이름 지정 요구 사항이 있습니다.
네임스페이스의 마지막 부분과 미러 이미지의 이미지 이름은 미러링 중인 이미지와 일치해야 합니다. 예를 들어
mcr.microsoft.com/oss/kubernetes/pause:3.9이미지를 미러링할 때 미러는$mirrorRegistry/<organization>/oss/kubernetes/pause:3.9형식이어야 합니다. 여기서$org는 조직 이름 또는 네임스페이스이거나 완전히 제외될 수 있습니다. 일부 유효한 값은$mirrorRegistry/oss/kubernetes/pause:3.9,$mirrorRegistry/custom/oss/kubernetes/pause:3.9,$mirrorRegistry/x/y/z/oss/kubernetes/pause:3.9입니다.Windows 노드는 ITMS 오브젝트를 사용하여 레지스트리 전체 미러를 구성합니다. 다음 예에서
quay.io/remote-org/image를quay.io/my-org/image에 미러링하도록 구성하면quay.io/remote-org의 모든 이미지에 대해 해당 미러를 사용하는 Windows 노드가 생성됩니다. 따라서quay.io/remote-org/image:tag는quay.io/my-org/image:tag이미지를 사용하지만quay.io/remote-org/different-image:tag를 사용하는 다른 컨테이너도quay.io/remote-org/different-image:tag를 사용하려고 합니다. 이로 인해 설명되지 않은 경우 의도하지 않은 동작이 발생할 수 있습니다.이러한 이유로 ITMS 오브젝트 대신 IDMS 오브젝트에서 다이제스트를 사용하여 컨테이너 이미지를 지정합니다. 다이제스트를 사용하면 컨테이너에서 지정하는 이미지와 가져올 이미지에 동일한 다이제스트가 있는지 확인하여 잘못된 컨테이너 이미지를 사용할 수 없습니다.
5.6.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 정책을 설정할 수 있습니다.
-
이러한 사용자 정의 리소스 오브젝트 각각 다음 정보를 식별합니다.
- 미러링하려는 컨테이너 이미지 저장소의 소스
- 소스 저장소에서 요청된 컨텐츠를 제공하는 각 미러 저장소에 대한 개별 항목
다음 동작 및 노드 드레이닝 동작에 어떤 영향을 미치는지에 유의하십시오.
- IDMS 또는 ICSP CR 오브젝트를 생성하는 경우 MCO는 노드를 드레이닝하거나 재부팅하지 않습니다.
- ITMS CR 오브젝트를 생성하면 MCO가 노드를 비우고 재부팅합니다.
- ITMS, IDMS 또는 ICSP CR 오브젝트를 삭제하면 MCO가 노드를 비우고 재부팅합니다.
ITMS, IDMS 또는 ICSP CR 오브젝트를 수정하면 MCO가 노드를 비우고 재부팅합니다.
중요MCO가 다음 변경 사항을 감지하면 노드를 드레이닝하거나 재부팅하지 않고 업데이트를 적용합니다.
-
머신 구성의
spec.config.passwd.users.sshAuthorizedKeys매개변수에서 SSH 키 변경 -
openshift-config네임 스페이스에서 글로벌 풀 시크릿 또는 풀 시크릿 관련 변경 사항 -
Kubernetes API Server Operator의
/etc/kubernetes/kubelet-ca.crt인증 기관(CA) 자동 교체
-
머신 구성의
MCO가
ImageDigestMirrorSet,ImageTagMirrorSet또는ImageContentSourcePolicy개체 편집과 같은/etc/containers/registries.conf파일의 변경을 감지하면 해당 노드를 비우고 변경 사항을 적용한 다음 노드를 분리합니다. 다음 변경에는 노드 드레이닝이 발생하지 않습니다.-
각 미러에 대해 설정된
pull-from-mirror = "digest-only"매개변수를 사용하여 레지스트리를 추가합니다. -
레지스트리에 설정된
pull-from-mirror = "digest-only"매개변수를 사용하여 미러를 추가합니다. -
unqualified-search-registries목록에 항목이 추가되었습니다.
-
각 미러에 대해 설정된
WMCO(Windows Machine Config Operator)는 IDMS 및 ITMS 리소스에 대한 변경 사항을 감시하고 이러한 변경 사항이 포함된 hosts.toml 컨테이너 구성 파일 세트, 각 소스 레지스트리에 대해 하나의 파일을 생성합니다. 그런 다음 WMCO는 새 레지스트리 구성을 사용하도록 기존 Windows 노드를 업데이트합니다.
미러링된 레지스트리를 사용하여 Windows 노드를 추가하려면 IDMS 및 ITMS 개체를 생성해야 합니다.
5.6.2. 이미지 레지스트리 저장소 미러링 설정 링크 복사링크가 클립보드에 복사되었습니다!
설치 후 미러 구성 CR(사용자 정의 리소스)을 생성하여 소스 이미지 레지스트리에서 미러링된 이미지 레지스트리로 이미지 가져오기 요청을 리디렉션할 수 있습니다.
ImageDigestMirrorSet 및 ImageTagMirrorSet 오브젝트를 통해 미러링된 Windows 이미지에는 " 미러 레지스트리가 있는 Windows 컨테이너 사용"에 설명된 대로 특정 이름 지정 요구 사항이 있습니다.
사전 요구 사항
-
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또는ImageTagMirrorSetCR을 생성하여 소스 및 미러를 자체 레지스트리 및 저장소 쌍과 이미지로 교체합니다.apiVersion: config.openshift.io/v11 kind: ImageDigestMirrorSet2 metadata: name: ubi9repo spec: imageDigestMirrors:3 - mirrors: - example.io/example/ubi-minimal4 - example.com/example2/ubi-minimal5 source: registry.access.redhat.com/ubi9/ubi-minimal6 mirrorSourcePolicy: AllowContactingSource7 - 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:ImageDigestMirrorSetCR에 사용합니다. -
imageTagMirrors:ImageTagMirrorSetCR에 사용합니다.
-
- 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 /hostWMCO가 각 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플래그가 폴백으로 사용됩니다.