Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

OpenShift용 Windows 컨테이너 지원

OpenShift Container Platform 4.16

Windows 컨테이너용 Red Hat OpenShift 가이드

Red Hat OpenShift Documentation Team

초록

Windows 컨테이너용 Red Hat OpenShift는 OpenShift Container Platform에서 Microsoft Windows Server 컨테이너를 실행하기 위한 기본 지원을 제공합니다. 이 가이드에서는 모든 세부 정보를 제공합니다.

1장. Windows Containers 용 Red Hat OpenShift 지원 개요

컴퓨팅 머신 세트를 생성하거나 구성 맵 을 통해 기존 BYOH(Bring-Your-Own-Host) Window 인스턴스를 지정하여 Windows 노드를 추가할 수 있습니다.

참고

베어 메탈 또는 공급자와 무관한 클러스터에서 컴퓨팅 머신 세트는 지원되지 않습니다.

Linux 및 Windows를 포함한 워크로드의 경우 OpenShift Container Platform을 사용하면 Windows Server 컨테이너에서 실행되는 Windows 워크로드를 배포하는 동시에 RHCOS(Red Hat Enterprise Linux CoreOS) 또는 RHEL(Red Hat Enterprise Linux)에서 호스팅되는 기존 Linux 워크로드를 제공할 수 있습니다. 자세한 내용은 Windows 컨테이너 워크로드 시작을 참조하십시오.

클러스터에서 Windows 워크로드를 실행하려면 WMCO가 필요합니다. WMCO는 클러스터에서의 Windows 워크로드 배포 및 관리 프로세스를 오케스트레이션합니다. 자세한 내용은 Windows 컨테이너 워크로드를 활성화하는 방법을 참조하십시오.

Windows MachineSet 오브젝트를 생성하여 지원되는 Windows 워크로드를 새 Windows 머신으로 이동할 수 있도록 인프라 Windows 머신 세트 및 관련 머신을 생성할 수 있습니다. 여러 플랫폼에서 Windows MachineSet 오브젝트를 생성할 수 있습니다.

Windows 워크로드를 Windows 컴퓨팅 노드에 예약 할 수 있습니다.

Windows Machine Config Operator 업그레이드를 수행하여 Windows 노드에 최신 업데이트가 있는지 확인할 수 있습니다.

특정 머신을 삭제하여 Windows 노드를 제거할 수 있습니다.

BYOH(Bring-Your-Own-Host) Windows 인스턴스를 사용하여 Windows Server VM을 다시 사용하고 OpenShift Container Platform으로 가져올 수 있습니다. BYOH Windows 인스턴스는 Windows 서버가 오프라인 상태가 되는 경우 주요 중단을 완화하려는 사용자에게 유용합니다. BYOH Windows 인스턴스를 OpenShift Container Platform 4.8 이상 버전의 노드로 사용할 수 있습니다.

다음을 수행하여 Windows 컨테이너 워크로드를 비활성화 할 수 있습니다.

  • Windows Machine Config Operator 제거
  • Windows Machine Config Operator 네임스페이스 삭제

2장. 릴리스 노트

2.1. Red Hat OpenShift support for Windows Containers 릴리스 노트

Windows Containers 용 Red Hat OpenShift의 릴리스 노트는 OpenShift Container Platform의 모든 Windows 컨테이너 워크로드 기능을 제공하는 WMCO(Windows Machine Config Operator)의 개발을 추적합니다.

2.1.1. Windows Machine Config Operator 번호 지정

WMCO의 Y-stream 릴리스는 OpenShift Container Platform 릴리스 간에 z-stream 릴리스만 있는 OpenShift Container Platform과 함께 제공됩니다. WMCO 번호 지정은 관련 OpenShift Container Platform 버전을 y 스트림 위치에 반영합니다. 예를 들어 WMCO의 현재 릴리스는 OpenShift Container Platform 버전 4.16과 관련이 있습니다. 따라서 번호 지정은 WMCO 10.15.z입니다.

2.1.2. Red Hat Windows Machine Config Operator 10.16.1 릴리스 노트

이번 WMCO 릴리스는 OpenShift Container Platform 클러스터에서 Windows 컴퓨팅 노드를 실행하기 위한 새로운 기능 및 버그 수정을 제공합니다. WMCO 10.16.1의 구성 요소는 RHSA-2024:5749 로 릴리스되었습니다.

2.1.2.1. 버그 수정
  • 이전 버전에서는 Windows VM의 PowerShell ExecutionPolicy 가 제한으로 설정된 경우 WICD(Windows Instance Config Daemon)에서 Windows 노드 생성에 필요한 해당 VM에서 명령을 실행할 수 없었습니다. 이번 수정으로 이제 PowerShell 명령을 실행할 때 VM의 실행 정책을 바이패스합니다. 그 결과#187CD는 VM에 예상대로 Windows 노드를 생성할 수 있습니다. (OCPBUGS-37609)

2.2. Windows Machine Config Operator의 이전 릴리스 노트

다음 릴리스 노트는 WMCO(Windows Machine Config Operator) 이전 버전에 대한 것입니다.

2.2.1. Red Hat Windows Machine Config Operator 10.16.0 릴리스 노트

이번 WMCO 릴리스는 OpenShift Container Platform 클러스터에서 Windows 컴퓨팅 노드를 실행하기 위한 버그 수정을 제공합니다. WMCO 10.16.0의 구성 요소는 RHBA-2024:5014 에서 릴리스되었습니다.

2.2.1.1. 새로운 기능 및 개선 사항
2.2.1.1.1. 연결이 끊긴 네트워크에서 WMCO가 지원됨

WMCO는 이제 연결이 끊긴 네트워크가 있는 환경에서 지원되며, 이는 의도적으로 인터넷 접속을 방해하는 클러스터이며, 제한된 클러스터 또는 Air-gapped 클러스터라고도 합니다.

자세한 내용은 미러 레지스트리가 있는 Windows 컨테이너 사용을 참조하십시오.

2.2.1.1.2. WMCO는 미러링된 레지스트리에서 이미지를 가져올 수 있습니다.

WMCO는 이제 ImageDigestMirrorSet (IDMS) 및 ImageTagMirrorSet (ITMS) 오브젝트를 모두 사용하여 미러링된 레지스트리에서 이미지를 가져올 수 있습니다.

자세한 내용은 이미지 레지스트리 저장소 미러링 이해를 참조하십시오.

2.2.1.1.3. Windows 노드에 대해 파일 시스템 지표 표시

이제 OpenShift Container Platform 웹 콘솔의 노드 세부 정보 페이지의 사용률 타일에 있는 Windows 노드에 파일 시스템 지표를 사용할 수 있습니다. PromQL(Prometheus Query Language) 쿼리를 실행하여 메트릭 을 쿼리할 수 있습니다. 이전에 차트에서 데이터 포인트를 찾을 수 없음을 보고했습니다.

2.2.1.1.4. Windows 노드에서 Pod에 대한 Pod 네트워크 메트릭 표시

이제 OpenShift Container Platform 웹 콘솔의 Pod 세부 정보 페이지에서 Windows Pod 에서 네트워크를 사용할 수 있습니다. PromQL 쿼리를 실행하여 메트릭을 쿼리할 수 있습니다. 이전에 차트에서 데이터 포인트를 찾을 수 없음을 보고했습니다.

2.2.1.1.5. Pod CPU 및 메모리 메트릭이 Windows 노드의 Pod에 표시

OpenShift Container Platform 웹 콘솔의 Pod 및 Pod 세부 정보 페이지에서 Windows Pod 에 CPU 및 메모리 사용량 메트릭을 사용할 수 있습니다. PromQL 쿼리를 실행하여 메트릭을 쿼리할 수 있습니다. 이전에 차트에서 데이터 포인트를 찾을 수 없음을 보고했습니다.

2.2.1.1.6. Kubernetes 업그레이드

WMCO는 이제 Kubernetes 1.29를 사용합니다.

2.2.1.2. 버그 수정

mightCD 서비스 계정에 필요한 시크릿이 없기 때문에 WMCO가 Nutanix 클러스터에서 Windows 노드를 올바르게 구성할 수 없었습니다. 이번 수정으로 WMCO는 mightCD 서비스 계정에 대해 장기 토큰 시크릿을 생성합니다. 결과적으로 WMCO는 Nutanix에서 Windows 노드를 구성할 수 있습니다. (OCPBUGS-22680)

이전에는 WMCO가 사용자 클러스터 전체 프록시 구성에서 쉼표를 together으로 잘못 교체한 단계였습니다. 이 동작으로 인해 Windows에서 noProxy 환경 변수에 설정된 값을 무시했습니다. 결과적으로 WMCO는 no-proxy 매개변수에 지정된 끝점에 대한 프록시를 통해 트래픽을 잘못 전송했습니다. 이번 수정으로 쉼표를 together으로 교체한 종료 단계가 제거되었습니다. 결과적으로 Windows 노드에서 클러스터 내부 엔드포인트 또는 no-proxy 매개변수에 존재하는 끝점으로 웹 요청이 프록시를 통과하지 않습니다. (OCPBUGS-24264)

이전에는 네트워킹 구성 스크립트에서 잘못된 논리로 인해 WMCO가 포함된 CNI 구성 파일의 반환을 변경 사항으로 잘못 읽고 파일을 수정으로 식별했습니다. 이 Bahavior로 인해 CNI 구성이 불필요하게 다시 로드되어 컨테이너가 다시 시작되고 간단한 네트워크 중단이 발생할 수 있었습니다. 이번 수정을 통해 이제 CNI 구성이 실제로 수정된 경우에만 CNI 구성을 다시 로드합니다. (OCPBUGS-2887)

이전 버전에서는 Windows Server 2019에 있는 라우팅 문제로 인해 특정 조건에서 그리고 1시간 이상의 실행 시간 후에 Windows Server 2019의 워크로드가 클러스터의 다른 컨테이너와 통신할 때 패킷 손실이 발생할 수 있었습니다. 이번 수정에서는 kube-proxy 내에서 직접 서버 반환(DSR) 라우팅을 활성화합니다. 결과적으로 DSR은 요청 및 응답 트래픽이 다른 네트워크 경로를 사용하여 Windows Server 2019 내에서 버그를 우회합니다. (OCPBUGS-26761)

이전에는 Windows 노드의 kubelet이 프라이빗 Amazon Elastic Container Registries(ECR)로 인증할 수 없었습니다. 이 오류로 인해 kubelet에서 이러한 레지스트리에서 이미지를 가져올 수 없었습니다. 이번 수정으로 kubelet은 이러한 레지스트리에서 예상대로 이미지를 가져올 수 있습니다. (OCPBUGS-26602)

이전에는 Azure 클러스터에서 WMCO가 클러스터에서 외부 CCO(Cloud Controller Manager)가 사용 중인지 확인했습니다. CCM을 사용하는 경우 Operator는 구성 논리를 적절하게 조정합니다. CCM을 확인하는 데 사용한 WMCO가 제거되었으므로 WMCO가 CCM을 사용하지 않은 것처럼 진행했습니다. 이번 수정을 통해 검사를 제거합니다. 결과적으로 WMCO는 항상 Azure 클러스터에서 필요한 논리를 구성합니다. (OCPBUGS-31626)

이전에는 Windows 인스턴스에 대한 SSH 연결을 통해 실행된 명령을 실행할 때 WMCO가 오류 메시지를 기록했습니다. 일부 명령이 실패할 것으로 예상되므로 이 동작이 올바르지 않았습니다. 예를 들어 WMCO가 노드를 재부팅하면 Operator는 인스턴스에서 PowerShell 명령을 실행합니다. 즉 SSH 연결이 예상대로 재부팅됩니다. 이번 수정을 통해 이제 실제 오류만 기록됩니다. (OCPBUGS-20255)

이전 버전에서는 kube-apiserver-to-kubelet-client-ca 인증서를 교체한 후 Windows 노드에서 kubetl-ca.crt 파일의 콘텐츠가 올바르게 채워지지 않았습니다. 이번 수정으로 인증서 교체 후 kubetl-ca.crt 파일에 올바른 인증서가 포함되어 있습니다. (OCPBUGS-22237)

이전 버전에서는 Windows AD 도메인 컨트롤러의 일부인 인스턴스의 kubelet 호스트 이름에 DNS 접미사가 누락되어 클라우드 공급자가 이름으로 VM을 찾지 못했습니다. 이번 수정으로 DNS 접미사가 호스트 이름 확인에 포함됩니다. 결과적으로 WMCO는 AD 도메인 컨트롤러의 일부인 Windows 인스턴스를 구성하고 결합할 수 있습니다. (OCPBUGS-34758)

이전에는 사용자가 클러스터에 제공된 레지스트리 인증서가 각 노드의 Windows 신뢰 저장소에 로드되지 않았습니다. 결과적으로 자체 서명된 CA가 필요하므로 미러 레지스트리에서 이미지를 가져오지 못했습니다. 이번 수정을 통해 레지스트리 인증서가 각 노드의 Windows 신뢰 저장소에 로드됩니다. 결과적으로 자체 서명된 CA를 사용하여 미러 레지스트리에서 이미지를 가져올 수 있습니다. (OCPBUGS-36408)

이전에는 WMCO 네임스페이스에 여러 서비스 계정 토큰 시크릿이 있는 경우 Windows 노드를 스케일링할 수 없었습니다. 이번 수정으로 WMCO는 생성된 시크릿만 사용하고 WMCO 네임스페이스의 다른 서비스 계정 토큰 시크릿을 무시합니다. 결과적으로 Windows 노드가 올바르게 확장됩니다. (OCPBUGS-37481)

이전 버전에서는 역방향 DNS 조회 서비스를 사용할 수 없는 오류(예: 역방향 DNS 조회 서비스)로 인해 역방향 DNS 조회가 실패한 경우 WMCO가 VM 호스트 이름을 사용하여 CSR(인증서 서명 요청)을 승인해야 하는지 확인하지 않았습니다. 결과적으로 IP 주소로 구성된 BYOH(Your-Own-Host) Windows 노드를 사용할 수 없었습니다. 이번 수정으로 역방향 DNS를 사용할 수 없는 경우 BYOH 노드가 올바르게 추가됩니다. (OCPBUGS-36643)

2.3. Windows Machine Config Operator 전제 조건

다음 정보는 Windows Machine Config Operator에 지원되는 플랫폼 버전, Windows Server 버전 및 네트워킹 구성에 대해 자세히 설명합니다. 해당 플랫폼과 관련된 모든 정보는 vSphere 설명서를 참조하십시오.

2.3.1. WMCO 지원 설치 방법

WMCO는 설치 관리자 프로비저닝 인프라(IPI) 클러스터에 Windows 노드 설치를 완벽하게 지원합니다. 기본 OpenShift Container Platform 설치 방법입니다.

사용자 프로비저닝 인프라(UPI) 클러스터의 경우 WMCO는 platform으로 설치된 UPI 클러스터에만 Windows 노드 설치를 지원합니다. install-config.yaml 파일(bare-metal 또는 provider-agnostic)에 설정된 필드는 none 필드와 BYOH(Bring Your Own Host) 사용 사례에만 해당합니다. 다른 플랫폼에서는 UPI가 지원되지 않습니다.

2.3.2. WMCO 10.16.0 지원 플랫폼 및 Windows Server 버전

다음 표에는 해당 플랫폼에 따라 WMCO 10.16.0에서 지원하는 Windows Server 버전이 나열되어 있습니다. 나열되지 않은 Windows Server 버전은 지원되지 않으며 이를 사용하려고 하면 오류가 발생합니다. 이러한 오류를 방지하려면 플랫폼에 적절한 버전만 사용하십시오.

플랫폼지원되는 Windows Server 버전

AWS(Amazon Web Services)

  • Windows Server 2022, OS 빌드 20348.681 이상 [1]
  • Windows Server 2019, 버전 1809

Microsoft Azure

  • Windows Server 2022, OS Build 20348.681 이상
  • Windows Server 2019, 버전 1809

VMware vSphere

Windows Server 2022, OS Build 20348.681 이상

GCP(Google Cloud Platform)

Windows Server 2022, OS Build 20348.681 이상

Nutanix

Windows Server 2022, OS Build 20348.681 이상

베어 메탈 또는 공급자와 무관

  • Windows Server 2022, OS Build 20348.681 이상
  • Windows Server 2019, 버전 1809
  1. 연결이 끊긴 클러스터의 경우 Windows AMI에는 EC2LaunchV2 에이전트 버전 2.0.1643 이상이 설치되어 있어야 합니다. 자세한 내용은 AWS 문서 의 최신 버전의 EC2Launch v2 설치를 참조하십시오.

2.3.3. 지원되는 네트워킹

OVN-Kubernetes가 있는 하이브리드 네트워킹은 지원되는 유일한 네트워킹 구성입니다. 이 기능에 대한 자세한 내용은 아래 추가 리소스를 참조하십시오. 다음 표에서는 플랫폼에 따라 사용할 네트워킹 구성 유형과 Windows Server 버전을 간략하게 설명합니다. 클러스터를 설치할 때 네트워크 구성을 지정해야 합니다.

참고
  • WMCO는 하이브리드 네트워킹 또는 OpenShift SDN 없이 OVN-Kubernetes를 지원하지 않습니다.
  • Dual NIC는 WMCO 관리 Windows 인스턴스에서 지원되지 않습니다.
표 2.1. 플랫폼 네트워킹 지원
플랫폼지원되는 네트워킹

AWS(Amazon Web Services)

OVN-Kubernetes로 하이브리드 네트워킹

Microsoft Azure

OVN-Kubernetes로 하이브리드 네트워킹

VMware vSphere

사용자 지정 VXLAN 포트가 있는 OVN-Kubernetes를 사용한 하이브리드 네트워킹

GCP(Google Cloud Platform)

OVN-Kubernetes로 하이브리드 네트워킹

Nutanix

OVN-Kubernetes로 하이브리드 네트워킹

베어 메탈 또는 공급자와 무관

OVN-Kubernetes로 하이브리드 네트워킹

표 2.2. 하이브리드 OVN-Kubernetes Windows Server 지원
OVN-Kubernetes로 하이브리드 네트워킹지원되는 Windows Server 버전

기본 VXLAN 포트

  • Windows Server 2022, OS Build 20348.681 이상
  • Windows Server 2019, 버전 1809

사용자 지정 VXLAN 포트

Windows Server 2022, OS Build 20348.681 이상

추가 리소스

2.4. Windows Machine Config Operator에서 알려진 제한 사항

WMCO(Windows 노드)에서 관리하는 Windows 노드로 작업할 때 다음과 같은 제한 사항에 유의하십시오.

  • 다음 OpenShift Container Platform 기능은 Windows 노드에서 지원되지 않습니다.

    • 이미지 빌드
    • OpenShift Pipelines
    • OpenShift Service Mesh
    • 사용자 정의 프로젝트 OpenShift 모니터링
    • OpenShift Serverless
    • 수평 Pod 자동 스케일링
    • 수직 Pod 자동 스케일링

  • 다음 Red Hat 기능은 Windows 노드에서 지원되지 않습니다.

  • Dual NIC는 WMCO 관리 Windows 인스턴스에서 지원되지 않습니다.
  • Windows 노드는 배포 구성을 사용하여 생성된 워크로드를 지원하지 않습니다. 배포 또는 기타 방법을 사용하여 워크로드를 배포할 수 있습니다.
  • Windows Containers 용 Red Hat OpenShift 지원은 트렁크 포트를 통해 클러스터에 Windows 노드를 추가하는 것을 지원하지 않습니다. Windows 노드 추가에 지원되는 유일한 네트워킹 구성은 VLAN에 대한 트래픽을 전송하는 액세스 포트를 사용하는 것입니다.
  • Windows Containers 용 Red Hat OpenShift 지원은 영어(미국) 이외의 Windows 운영 체제 언어를 지원하지 않습니다.
  • Windows 운영 체제의 제한으로 인해 240.0.0.0 과 같은 클래스 E의 clusterNetwork CIDR 주소는 Windows 노드와 호환되지 않습니다.

  • Kubernetes에서 다음 노드 기능 제한 사항을 확인했습니다.

    • 대규모 페이지는 Windows 컨테이너에서 지원되지 않습니다.
    • 권한 있는 컨테이너는 Windows 컨테이너에서 지원되지 않습니다.
  • Kubernetes는 여러 API 호환성 문제를 확인했습니다.

3장. 지원 요청

Red Hat OpenShift에 대한 Windows 컨테이너 지원이 제공되며 설치 가능한 선택적 구성 요소로 사용할 수 있습니다. Red Hat OpenShift에 대한 Windows 컨테이너 지원은 OpenShift Container Platform 서브스크립션의 일부가 아닙니다. 추가 Red Hat 서브스크립션이 필요하며 적용 범위 및 서비스 수준 계약에 따라 지원됩니다.

Red Hat OpenShift에 대한 Windows 컨테이너 지원을 받으려면 별도의 서브스크립션이 있어야 합니다. 이 추가 Red Hat 서브스크립션이 없으면 프로덕션 클러스터에 Windows 컨테이너 워크로드를 배포할 수 없습니다. Red Hat 고객 포털을 통해 지원을 요청할 수 있습니다.

자세한 내용은 Windows Containers 용 Red Hat OpenShift 지원에 대한 Red Hat OpenShift Container Platform 라이프 사이클 정책 문서를 참조하십시오.

이러한 추가 Red Hat 서브스크립션이 없는 경우 공식 지원이 없는 배포인 Community Windows Machine Config Operator를 사용할 수 있습니다.

4장. Windows 컨테이너 워크로드 이해

Windows Containers 용 Red Hat OpenShift 지원은 OpenShift Container Platform에서 Microsoft Windows Server 컨테이너를 실행하기 위한 기본 지원을 제공합니다. Linux 및 Windows 워크로드가 혼합된 동시 환경을 관리하는 경우 OpenShift Container Platform을 사용하면 RHCOS(Red Hat Enterprise Linux CoreOS) 또는 RHEL(Red Hat Enterprise Linux)에서 호스팅되는 기존 Linux 워크로드를 제공하면서 Windows Server 컨테이너에서 실행 중인 Windows 워크로드를 배포할 수 있습니다.

참고

Windows 노드가 배치된 클러스터에 대한 멀티 테넌시는 지원되지 않습니다. 여러 워크로드가 공유 인프라 및 리소스에서 작동하는 경우 클러스터는 멀티 테넌트 로 간주됩니다. 인프라에서 실행 중인 하나 이상의 워크로드를 신뢰할 수 없는 경우 다중 테넌트 환경은 hostile로 간주됩니다.

적대적인 멀티 테넌트 클러스터에서는 모든 Kubernetes 환경에서 보안 문제가 발생합니다. Pod 보안 정책 또는 노드에 대한 보다 세분화된 역할 기반 액세스 제어(RBAC)와 같은 추가 보안 기능을 통해 환경을 더 어렵게 활용할 수 있습니다. 그러나 유해한 멀티 테넌트 워크로드를 실행하도록 선택하는 경우 하이퍼바이저가 사용할 수 있는 유일한 보안 옵션입니다. Kubernetes용 보안 도메인에는 개별 노드가 아닌 전체 클러스터가 포함됩니다. 이러한 유형의 유해한 멀티 테넌트 워크로드의 경우 물리적으로 분리된 클러스터를 사용해야 합니다.

Windows Server 컨테이너는 공유 커널을 사용하여 리소스 격리를 제공하지만 다중 테넌시 시나리오에서는 사용되지 않습니다.

추가 리소스

4.1. Windows 워크로드 관리

클러스터에서 Windows 워크로드를 실행하려면 먼저 WMCO(Windows Machine Config Operator)를 설치해야 합니다. WMCO는 Linux 기반 Operator로, Linux 기반 컨트롤 플레인 및 컴퓨팅 노드에서 실행됩니다. WMCO는 클러스터에서의 Windows 워크로드 배포 및 관리 프로세스를 오케스트레이션합니다.

그림 4.1. WMCO 설계

WMCO 워크플로

Windows 워크로드를 배포하기 전, Windows 컴퓨팅 노드를 생성한 후 클러스터에 참여하도록 해야 합니다. Windows 노드는 클러스터에서 Windows 워크로드를 호스팅하고 다른 Linux 기반 컴퓨팅 노드와 함께 실행할 수 있습니다. 호스트 Windows Server 컴퓨팅 머신으로 설정된 Windows 컴퓨팅 머신을 생성하여 Windows 컴퓨팅 노드를 생성할 수 있습니다. Windows OS 이미지를 지정하는 컴퓨팅 머신 세트에 Windows별 레이블을 적용해야 합니다.

WMCO는 Windows 레이블이 있는 머신을 감시합니다. Windows 컴퓨팅 머신 세트가 감지되고 해당 머신이 프로비저닝되면 WMCO는 기본 Windows 가상 머신(VM)을 구성하여 클러스터에 컴퓨팅 노드로 참여할 수 있습니다.

그림 4.2. Windows 및 Linux 워크로드

Windows 및 Linux 워크로드

WMCO는 Windows 인스턴스와 상호 작용하는 데 사용되는 개인 키가 포함된 네임스페이스에 사전 결정된 시크릿이 있을 것으로 예상합니다. WMCO는 부팅 시 이 시크릿을 확인하고 사용자가 생성한 Windows MachineSet 오브젝트에서 참조해야 하는 사용자 데이터 시크릿을 생성합니다. 그런 다음 WMCO는 사용자 데이터 시크릿을 개인 키에 해당하는 공개 키로 채웁니다. 이 데이터를 사용하여 SSH 연결을 통해 클러스터가 Windows VM에 연결할 수 있습니다.

클러스터가 Windows VM과 관련된 연결을 설정한 후 Linux 기반 노드와 비슷한 방법을 사용하여 Windows 노드를 관리할 수 있습니다.

참고

OpenShift Container Platform 웹 콘솔은 Linux 노드에서 사용 가능할 수 있는 Windows 노드용과 거의 동일한 모니터링 기능을 제공합니다. 그러나 현재 Windows 노드에서 실행 중인 Pod에 대한 워크로드 그래프 모니터링 기능은 사용할 수 없습니다.

Windows 노드에 Windows 워크로드 예약은 테인트, 허용 오차 및 노트 선택기와 같은 일반적인 Pod 예약 방법으로 수행할 수 있습니다. 아니면, RuntimeClass 오브젝트를 사용하여 Windows 워크로드를 Linux 워크로드 및 기타 Windows 버전 워크로드와 차별화할 수 있습니다.

4.2. Windows 노드 서비스

다음 Windows별 서비스가 각 Windows 노드에 설치됩니다.

Service설명

kubelet

Windows 노드를 등록하고 상태를 관리합니다.

CNI(컨테이너 네트워크 인터페이스) 플러그인

Windows 노드에 대한 네트워킹을 노출합니다.

WICD(Windows Instance Config Daemon)

인스턴스가 작업자 노드로 작동하도록 Windows 인스턴스에서 실행 중인 모든 서비스의 상태를 유지 관리합니다.

Windows Exporter

Windows 노드에서 Prometheus 지표 내보내기

Kubernetes Cloud Controller Manager (CCM)

기본 Azure 클라우드 플랫폼과 상호 작용합니다.

hybrid-overlay

OpenShift Container Platform HNS(Host Network Service)를 생성합니다.

kube-proxy

외부 통신을 허용하는 노드에서 네트워크 규칙을 유지합니다.

컨테이너된 컨테이너 런타임

전체 컨테이너 라이프사이클을 관리합니다.

CSI 프록시

CSI 드라이버가 노드에서 스토리지 작업을 수행할 수 있으므로 컨테이너화된 CSI 드라이버가 Windows 노드에서 실행될 수 있습니다.

5장. Windows 컨테이너 워크로드 활성화

Windows 워크로드를 클러스터에 추가하기 전에 OpenShift Container Platform OperatorHub에서 사용 가능한 WMCO(Windows Machine Config Operator)를 설치해야 합니다. WMCO는 클러스터에서의 Windows 워크로드 배포 및 관리 프로세스를 오케스트레이션합니다.

참고

Dual NIC는 WMCO 관리 Windows 인스턴스에서 지원되지 않습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 설치 관리자 프로비저닝 인프라를 사용하거나 install-config.yaml 파일에 설정된 platform: none 필드가 있는 사용자 프로비저닝 인프라를 사용하여 클러스터가 설치되어 있어야 합니다.
  • 클러스터를 위한 OVN-Kubernetes를 사용하여 하이브리드 네트워킹이 구성되었습니다. 자세한 내용은 하이브리드 네트워킹 구성을 참조하십시오.
  • OpenShift Container Platform 클러스터 버전 4.6.8 이상이 실행 중입니다.
참고

WMCO에 의해 배포된 Windows 인스턴스는 컨테이너화된 컨테이너 런타임을 사용하여 구성됩니다. WMCO는 런타임을 설치하고 관리하므로 노드에 컨테이너를 수동으로 설치하지 않는 것이 좋습니다.

추가 리소스

5.1. Windows Machine Config Operator 설치

웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 Windows Machine Config Operator를 설치할 수 있습니다.

참고

Windows 운영 체제의 제한으로 인해 240.0.0.0 과 같은 클래스 E의 clusterNetwork CIDR 주소는 Windows 노드와 호환되지 않습니다.

5.1.1. 웹 콘솔을 사용하여 Windows Machine Config Operator 설치

OpenShift Container Platform 웹 콘솔을 사용하여 WMCO(Windows Machine Config Operator)를 설치할 수 있습니다.

참고

Dual NIC는 WMCO 관리 Windows 인스턴스에서 지원되지 않습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 관리자로 Operator → OperatorHub 페이지로 이동합니다.
  2. 키워드로 필터링 상자를 사용하여 카탈로그에서 Windows Machine Config Operator를 검색합니다. Windows Machine Config Operator 타일을 클릭합니다.
  3. Operator에 대한 정보를 확인하고 설치를 클릭합니다.

  4. Operator 설치 페이지에서 다음을 수행합니다.

    1. stable 채널을 업데이트 채널로 선택합니다. stable 채널을 사용하면 WMCO의 안정적인 최신 릴리스를 설치할 수 있습니다.
    2. WMCO는 단일 네임스페이스에서만 사용 가능해야 하므로 설치 모드가 사전 구성됩니다.
    3. WMCO용으로 설치된 네임스페이스를 선택합니다. 기본 Operator 권장 네임스페이스는 openshift-windows-machine-config-operator입니다.
    4. 네임스페이스에서 Operator 권장 클러스터 모니터링 활성화 확인란을 클릭하여 WMCO에 대한 클러스터 모니터링을 활성화합니다.

    5. 승인 전략을 선택합니다.

      • 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
      • 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.

  5. 설치를 클릭합니다. 설치된 Operator 페이지에 이제 WMCO가 나열됩니다.

    참고

    WMCO는 사용자가 정의한 네임스페이스에 openshift-windows-machine-config-operator와 같이 자동으로 설치됩니다.

  6. WMCO가 성공적으로 설치되었는지 확인하려면 상태가 성공으로 표시되는지 확인합니다.

5.1.2. CLI를 사용하여 Windows Machine Config Operator 설치

OpenShift CLI(oc)를 사용하여 WMCO(Windows Machine Config Operator)를 설치할 수 있습니다.

참고

Dual NIC는 WMCO 관리 Windows 인스턴스에서 지원되지 않습니다.

프로세스

  1. WMCO를 위한 네임스페이스를 생성합니다.

    1. WMCO를 위한 네임스페이스 오브젝트 YAML 파일을 생성합니다. 예를 들어, wmco-namespace.yaml은 다음과 같습니다.

      Copy to Clipboard Toggle word wrap 
      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-windows-machine-config-operator
      1 
      
  labels:
    openshift.io/cluster-monitoring: "true"
      2
      1
      openshift-windows-machine-config-operator 네임스페이스에 WMCO를 배포하는 것이 좋습니다.
      2
      WMCO에 대한 클러스터 모니터링을 활성화하려면 이 레이블이 필요합니다.

    2. 네임스페이스를 생성합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc create -f <file-name>.yaml

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

      Copy to Clipboard Toggle word wrap 
      $ oc create -f wmco-namespace.yaml

  2. WMCO를 위한 Operator 그룹을 생성합니다.

    1. OperatorGroup 오브젝트 YAML 파일을 생성합니다. 예를 들어, wmco-og.yaml은 다음과 같습니다.

      Copy to Clipboard Toggle word wrap 
      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: windows-machine-config-operator
  namespace: openshift-windows-machine-config-operator
spec:
  targetNamespaces:
  - openshift-windows-machine-config-operator

    2. Operator 그룹을 생성합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc create -f <file-name>.yaml

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

      Copy to Clipboard Toggle word wrap 
      $ oc create -f wmco-og.yaml

  3. 네임스페이스가 WMCO를 구독하도록 합니다.

    1. 서브스크립션 오브젝트 YAML 파일을 생성합니다. 예를 들어, wmco-sub.yaml은 다음과 같습니다.

      Copy to Clipboard Toggle word wrap 
      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: windows-machine-config-operator
  namespace: openshift-windows-machine-config-operator
spec:
  channel: "stable"
      1 
      
  installPlanApproval: "Automatic"
      2 
      
  name: "windows-machine-config-operator"
  source: "redhat-operators"
      3 
      
  sourceNamespace: "openshift-marketplace"
      4
      1
      stable을 채널로 지정합니다.
      2
      승인 전략을 설정합니다. 자동 또는 수동을 설정할 수 있습니다.
      3
      windows-machine-config-operator 패키지 매니페스트가 포함된 redhat-operators 카탈로그 소스를 지정합니다. OpenShift Container Platform이 제한된 네트워크(연결이 끊긴 클러스터)에 설치된 경우 OLM(Operator Lifecycle Manager)을 구성할 때 생성된 CatalogSource 오브젝트의 이름을 지정합니다.
      4
      카탈로그 소스의 네임스페이스입니다. 기본 OperatorHub 카탈로그 소스에는 openshift-marketplace를 사용합니다.

    2. 서브스크립션을 생성합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc create -f <file-name>.yaml

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

      Copy to Clipboard Toggle word wrap 
      $ oc create -f wmco-sub.yaml

      이제 WMCO가 openshift-windows-machine-config-operator에 설치됩니다.

  4. WMCO 설치를 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get csv -n openshift-windows-machine-config-operator

    출력 예

    Copy to Clipboard Toggle word wrap 
    NAME                                    DISPLAY                           VERSION   REPLACES   PHASE
windows-machine-config-operator.2.0.0   Windows Machine Config Operator   2.0.0                Succeeded

5.2. Windows Machine Config Operator에 대한 시크릿 구성

WMCO(Windows Machine Config Operator)를 실행하려면 개인 키가 포함된 WMCO 네임스페이스에 시크릿을 생성해야 합니다. 이를 위해서는 WMCO가 Windows VM(가상 머신)과 통신할 수 있도록 허용되어야 합니다.

사전 요구 사항

  • OLM(Operator Lifecycle Manager)을 사용하여 WMCO(Windows Machine Config Operator)를 설치했습니다.
  • RSA 키가 포함된 PEM 인코딩 파일이 생성되었습니다.

절차

  • Windows VM에 액세스하기 위해 필요한 시크릿을 정의합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create secret generic cloud-private-key --from-file=private-key.pem=${HOME}/.ssh/<key> \
    -n openshift-windows-machine-config-operator
    1
1
openshift-windows-machine-config-operator와 같이 WMCO 네임스페이스에 개인 키를 생성해야 합니다.

클러스터를 설치할 때 사용한 것과 다른 개인 키를 사용하는 것이 좋습니다.

5.3. 프록시 지원 클러스터에서 Windows 컨테이너 사용

WMCO(Windows Machine Config Operator)는 클러스터의 내부 네트워크 외부의 외부 요청을 수행할 때 클러스터 전체 송신 프록시 구성을 사용하고 사용할 수 있습니다.

이를 통해 프록시 지원 클러스터에서 Windows 노드를 추가하고 워크로드를 실행할 수 있으므로 Windows 노드에서 프록시 서버 뒤에서 보안된 레지스트리에서 이미지를 가져오거나 사용자 정의 공개 키 인프라를 사용하는 클러스터 외부 서비스 및 서비스에 요청할 수 있습니다.

참고

클러스터 전체 프록시는 사용자 워크로드가 아닌 시스템 구성 요소에만 영향을 미칩니다.

프록시 지원 클러스터에서 WMCO는 클러스터에 설정된 NO_PROXY,HTTP_PROXY 및 HTTPS_PROXY 값을 알고 있습니다. WMCO는 프록시 환경 변수가 변경되었는지 주기적으로 확인합니다. 불일치가 있는 경우 WMCO는 Windows 인스턴스에서 프록시 환경 변수를 조정하고 업데이트합니다.

프록시 지원 클러스터의 Windows 노드에서 생성된 Windows 워크로드는 기본적으로 Linux 노드와 동일하게 노드의 프록시 설정을 상속하지 않습니다. 또한 기본적으로 PowerShell 세션은 프록시 지원 클러스터의 Windows 노드에서 프록시 설정을 상속하지 않습니다.

추가 리소스

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 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

절차

  1. 미러링된 저장소를 설정합니다.

    • Red Hat Quay Repository Mirroring에 설명된대로 Red Hat Quay를 사용하여 미러링된 저장소를 설정합니다. Red Hat Quay를 사용하면 한 저장소에서 다른 저장소로 이미지를 복사하고 시간이 지남에 따라 해당 저장소를 반복해서 자동으로 동기화할 수 있습니다.

    • skopeo 와 같은 툴을 사용하여 소스 저장소에서 미러링된 저장소로 이미지를 수동으로 복사합니다.

      예를 들어, Red Hat Enterprise Linux(RHEL) 7 또는 RHEL 8 시스템에 skopeo RPM 패키지를 설치한 후 다음 예와 같이 skopeo 명령을 사용합니다.

      Copy to Clipboard Toggle word wrap 
      $ 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 명령을 사용하여 이미지를 미러링할 수 있습니다.

    Copy to Clipboard Toggle word wrap 
    $ skopeo copy \
docker://mcr.microsoft.com/oss/kubernetes/pause:3.9\
docker://example.io/oss/kubernetes/pause:3.9
  2. OpenShift Container Platform 클러스터에 로그인합니다.

  3. 필요에 따라 ImageDigestMirrorSet 또는 ImageTagMirrorSet CR을 생성하여 소스 및 미러를 자체 레지스트리 및 저장소 쌍과 이미지로 교체합니다.

    Copy to Clipboard Toggle word wrap 
    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: 소스 저장소에서 이미지를 가져 오는 지속적인 시도를 방지합니다.

  4. 새 오브젝트를 생성합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create -f registryrepomirror.yaml

  5. 미러링된 구성 설정이 적용되었는지 확인하려면 노드 중 하나에서 다음을 수행하십시오.

    1. 노드를 나열합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get node

      출력 예

      Copy to Clipboard Toggle word wrap 
      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.29.4
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.29.4
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.29.4
ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.29.4
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.29.4
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.29.4

    2. 디버깅 프로세스를 시작하고 노드에 액세스합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc debug node/ip-10-0-147-35.ec2.internal

      출력 예

      Copy to Clipboard Toggle word wrap 
      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`

    3. 루트 디렉토리를 /host 로 변경합니다.

      Copy to Clipboard Toggle word wrap 
      sh-4.2# chroot /host

    4. WMCO가 각 Windows 인스턴스의 각 레지스트리에 대해 hosts.toml 파일을 생성했는지 확인합니다. 이전 예제 IDMS 오브젝트의 경우 다음 파일 구조에 세 개의 파일이 있어야 합니다.

      Copy to Clipboard Toggle word wrap 
      $ tree $config_path

      출력 예

      Copy to Clipboard Toggle word wrap 
      C:/k/containerd/registries/
|── registry.access.redhat.com
|   └── hosts.toml
|── mirror.example.com
|   └── hosts.toml
└── docker.io
    └── hosts.toml:

      다음 출력은 이전 예제 IDMS 오브젝트가 적용된 hosts.toml 컨테이너 설정 파일을 나타냅니다.

      host.toml 파일의 예

      Copy to Clipboard Toggle word wrap 
      $ 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

    5. 소스에서 이미지를 노드로 가져와 미러링에 의해 해결되는지 확인합니다.

      Copy to Clipboard Toggle word wrap 
      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...

저장소 미러링 문제 해결

저장소 미러링 절차가 설명대로 작동하지 않는 경우 저장소 미러링 작동 방법에 대한 다음 정보를 사용하여 문제를 해결하십시오.

  • 가져온 이미지는 첫 번째 작동 미러를 사용하여 공급합니다.
  • 주요 레지스트리는 다른 미러가 작동하지 않는 경우에만 사용됩니다.
  • 시스템 컨텍스트에서 Insecure 플래그가 폴백으로 사용됩니다.

5.5. 노드를 정상적으로 재부팅

WMCO(Windows Machine Config Operator)는 가능한 한 노드 재부팅을 최소화합니다. 그러나 변경 사항이 정확하고 안전하게 적용되도록 특정 작업 및 업데이트를 재부팅해야 합니다. Windows 노드를 안전하게 재부팅하려면 정상 재부팅 프로세스를 사용하십시오. 표준 OpenShift Container Platform 노드를 정상적으로 재부팅하는 방법에 대한 자세한 내용은 노드 설명서의 "노드 재부팅"을 참조하십시오.

노드를 재부팅하기 전에 노드에서 데이터가 손실되지 않도록 etcd 데이터를 백업하는 것이 좋습니다.

참고

클러스터를 관리하기 위해 kubeconfig 파일에 인증서가 없는 대신 사용자가 oc login 명령을 수행해야 하는 단일 노드 OpenShift 클러스터의 경우 노드를 차단하고 드레이닝한 후 oc adm 명령을 사용할 수 없을 수 있습니다. 이는 cordon으로 인해 openshift-oauth-apiserver 포드가 실행되지 않기 때문입니다. 다음 절차에 표시된 대로 SSH를 사용하여 노드에 액세스할 수 있습니다.

단일 노드 OpenShift 클러스터에서는 차단 및 드레인 시 Pod를 다시 예약할 수 없습니다. 그러나 이렇게 하면 Pod, 특히 워크로드 Pod, 관련 리소스를 올바르게 중지하고 해제하는 시간이 제공됩니다.

절차

노드를 정상적으로 재시작하려면 다음을 수행합니다.

  1. 노드를 예약 불가능으로 표시합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc adm cordon <node1>

  2. 실행 중인 모든 Pod를 제거하려면 노드를 드레이닝합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force

    PDB(사용자 정의 Pod 중단 예산)와 연결된 Pod를 제거할 수 없는 오류가 표시될 수 있습니다.

    오류 예

    Copy to Clipboard Toggle word wrap 
    error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

    이 경우 drain 명령을 다시 실행하여 PDB 검사를 바이패스하는 disable-eviction 플래그를 추가합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction

  3. Windows 노드에 SSH로 연결하고 다음 명령을 실행하여 PowerShell을 입력합니다.

    Copy to Clipboard Toggle word wrap 
    C:\> powershell

  4. 다음 명령을 실행하여 노드를 다시 시작합니다.

    Copy to Clipboard Toggle word wrap 
    C:\>  Restart-Computer -Force

  5. AWS(Amazon Web Services)의 Windows 노드는 EC2 인스턴스 메타데이터 경로 및 HNS(Host Network Service) 네트워크와의 불일치로 인해 정상 재부팅 후 READY 상태로 되돌아가지 않습니다.

    재부팅 후 AWS의 모든 Windows 노드에 SSH로 연결하고 쉘 프롬프트에서 다음 명령을 실행하여 경로를 추가합니다.

    Copy to Clipboard Toggle word wrap 
    C:\> route add 169.254.169.254 mask 255.255.255.0 <gateway_ip>

    다음과 같습니다.

    169.254.169.254
    EC2 인스턴스 메타데이터 끝점의 주소를 지정합니다.
    255.255.255.255
    EC2 인스턴스 메타데이터 끝점의 네트워크 마스크를 지정합니다.
    <gateway_ip>

    다음 명령을 실행하여 찾을 수 있는 Windows 인스턴스에서 게이트웨이의 해당 IP 주소를 지정합니다.

    Copy to Clipboard Toggle word wrap 
    C:\> ipconfig | findstr /C:"Default Gateway"

  6. 재부팅이 완료되면 다음 명령을 실행하여 노드를 예약 가능으로 표시합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc adm uncordon <node1>

  7. 노드가 준비되었는지 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get node <node1>

    출력 예

    Copy to Clipboard Toggle word wrap 
    NAME    STATUS  ROLES    AGE     VERSION
<node1> Ready   worker   6d22h   v1.18.3+b0068a8

추가 리소스

5.6. 추가 리소스

6장. Windows 머신 세트 생성

6.1. AWS에서 Windows 머신 세트 생성

AWS(Amazon Web Services)의 OpenShift Container Platform 클러스터에서 특정 목적을 수행하기 위해 Windows MachineSet 오브젝트를 생성할 수 있습니다. 예를 들어, 지원되는 워크로드를 새 Windows 머신으로 이동할 수 있도록 인프라 Windows MachineSet 및 관련 머신을 생성할 수 있습니다.

사전 요구 사항
  • OLM(Operator Lifecycle Manager)을 사용하여 WMCO(Windows Machine Config Operator)를 설치했습니다.

  • 지원되는 Windows Server를 운영 체제 이미지로 사용하고 있습니다.

    Windows Server 릴리스에 적합한 대로 다음 aws 명령 중 하나를 사용하여 유효한 AMI 이미지를 쿼리합니다.

    Windows Server 2022 명령 예

    Copy to Clipboard Toggle word wrap 
    $ aws ec2 describe-images --region <aws_region_name> --filters "Name=name,Values=Windows_Server-2022*English*Core*Base*" "Name=is-public,Values=true" --query "reverse(sort_by(Images, &CreationDate))[*].{name: Name, id: ImageId}" --output table

    Windows Server 2019 명령 예

    Copy to Clipboard Toggle word wrap 
    $ aws ec2 describe-images --region <aws_region_name> --filters "Name=name,Values=Windows_Server-2019*English*Core*Base*" "Name=is-public,Values=true" --query "reverse(sort_by(Images, &CreationDate))[*].{name: Name, id: ImageId}" --output table

    다음과 같습니다.

    <aws_region_name>
    AWS 리전의 이름을 지정합니다.
  • 연결이 끊긴 클러스터의 경우 Windows AMI에는 EC2LaunchV2 에이전트 버전 2.0.1643 이상이 설치되어 있어야 합니다. 자세한 내용은 AWS 문서 의 최신 버전의 EC2Launch v2 설치를 참조하십시오.

6.1.1. Machine API 개요

Machine API는 업스트림 Cluster API 프로젝트 및 사용자 정의 OpenShift Container Platform 리소스를 기반으로 하는 주요 리소스의 조합입니다.

OpenShift Container Platform 4.16 클러스터의 경우 Machine API는 클러스터 설치가 완료된 후 모든 노드 호스트 프로비저닝 관리 작업을 수행합니다. 이 시스템으로 인해 OpenShift Container Platform 4.16은 퍼블릭 또는 프라이빗 클라우드 인프라에 더하여 탄력적이고 동적인 프로비저닝 방법을 제공합니다.

두 가지 주요 리소스는 다음과 같습니다.

Machine
노드의 호스트를 설명하는 기본 단위입니다. 머신에는 providerSpec 사양이 있으며 이는 다른 클라우드 플랫폼에 제공되는 컴퓨팅 노드 유형을 설명합니다. 예를 들어 컴퓨팅 노드의 머신 유형은 특정 시스템 유형과 필수 메타데이터를 정의할 수 있습니다.
머신 세트

MachineSet 리소스는 컴퓨팅 머신 그룹입니다. 컴퓨팅 머신 세트는 컴퓨팅 머신에 연관되어 있고 복제본 세트는 pod에 연관되어 있습니다. 더 많은 컴퓨팅 머신이 필요하거나 확장해야 하는 경우 컴퓨팅 요구 사항에 맞게 MachineSet 리소스의 replicas 필드를 변경합니다.

주의

컨트롤 플레인 시스템은 컴퓨팅 머신 세트로 관리할 수 없습니다.

컨트롤 플레인 머신 세트는 컴퓨팅 머신에 제공하는 컴퓨팅 머신 세트와 유사한 지원되는 컨트롤 플레인 시스템에 대한 관리 기능을 제공합니다.

자세한 내용은 "컨트롤 플레인 머신 관리"를 참조하십시오.

다음 사용자 지정 리소스는 클러스터에 더 많은 기능을 추가할 수 있습니다.

머신 자동 스케일러

MachineAutoscaler 리소스는 클라우드에서 컴퓨팅 머신을 자동으로 확장합니다. 지정된 컴퓨팅 머신 세트에서 노드의 최소 및 최대 스케일링 경계를 설정할 수 있으며 머신 자동 스케일러는 해당 노드 범위를 유지합니다.

MachineAutoscaler 객체는 ClusterAutoscaler 객체를 설정한 후에 사용할 수 있습니다. ClusterAutoscaler 및 MachineAutoscaler리소스는 모두 ClusterAutoscalerOperator 오브젝트에서 사용 가능합니다.

Cluster autoscaler

이 리소스는 업스트림 클러스터 자동 스케일러 프로젝트를 기반으로 합니다. OpenShift Container Platform 구현에서는 컴퓨팅 머신 세트 API를 확장하여 Machine API와 통합됩니다. 클러스터 자동 스케일러를 사용하여 다음과 같은 방법으로 클러스터를 관리할 수 있습니다.

  • 코어, 노드, 메모리, GPU와 같은 리소스에 대한 클러스터 전체 스케일링 제한을 설정합니다.
  • 중요도가 낮은 Pod에 대해 클러스터가 Pod 및 새 노드가 온라인 상태가 되지 않도록 우선 순위를 설정합니다.
  • 노드를 확장할 수는 있지만 축소할 수 없도록 스케일링 정책을 설정합니다.
머신 상태 점검
MachineHealthCheck 리소스는 머신의 비정상적인 상태를 감지하여 삭제한 후 지원되는 플랫폼에서 새 머신을 생성합니다.

OpenShift Container Platform 버전 3.11에서는 클러스터가 머신 프로비저닝을 관리하지 않았기 때문에 다중 영역 아키텍처를 쉽게 롤아웃할 수 없었습니다. OpenShift Container Platform 버전 4.1부터 이러한 프로세스가 더 쉬워졌습니다. 각 컴퓨팅 머신 세트의 범위는 단일 영역으로 지정되므로 설치 프로그램은 사용자를 대신하여 가용성 영역 전체에 컴퓨팅 머신 세트를 보냅니다. 또한 계산이 동적이고 영역 장애가 발생하여 머신을 재조정해야하는 경우 처리할 수 있는 영역을 확보할 수 있습니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다. Autoscaler는 클러스터의 수명 기간 동안 최적의 균형을 유지합니다.

6.1.2. AWS에서 Windows MachineSet 오브젝트를 위한 샘플 YAML

이 샘플 YAML은 WMCO(Windows Machine Config Operator)에서 응답할 수 있는 AWS(Amazon Web Services)에서 실행 중인 Windows MachineSet 오브젝트를 정의합니다.

Copy to Clipboard Toggle word wrap 
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <infrastructure_id>-windows-worker-<zone>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          ami:
            id: <windows_container_ami>
9 

          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile
10 

          instanceType: m5a.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone>
11 

            region: <region>
12 

          securityGroups:
          - filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-node
13 

          - filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-lb
14 

          subnet:
            filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-subnet-private-<zone>
15 

          tags:
            - name: kubernetes.io/cluster/<infrastructure_id>
16 

              value: owned
          userDataSecret:
            name: windows-user-data
17 

            namespace: openshift-machine-api
1 3 5 10 13 14 15 16
클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. 다음 명령을 실행하여 인프라 ID를 가져올 수 있습니다.
Copy to Clipboard Toggle word wrap 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
인프라 ID, 작업자 레이블 및 영역을 지정합니다.
7
컴퓨팅 머신 세트를 Windows 머신으로 구성합니다.
8
Windows 노드를 컴퓨팅 머신으로 구성합니다.
9
컨테이너 런타임이 설치된 지원되는 Windows 이미지의 AMI ID를 지정합니다.
참고

연결이 끊긴 클러스터의 경우 Windows AMI에는 EC2LaunchV2 에이전트 버전 2.0.1643 이상이 설치되어 있어야 합니다. 자세한 내용은 AWS 문서 의 최신 버전의 EC2Launch v2 설치를 참조하십시오.

11
us-east-1a와 같이 AWS 영역을 지정합니다.
12
us-gov-east-1과 같이 AWS 리전을 지정합니다.
17
첫 번째 Windows 머신을 구성할 때 WMCO에 의해 생성되었습니다. 그 후 모든 후속 컴퓨팅 머신 세트에 대해 windows-user-data 를 사용할 수 있습니다.

6.1.3. 컴퓨팅 머신 세트 생성

설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 배포합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.
  • 연결이 끊긴 환경의 경우 MachineSet CR(사용자 정의 리소스)에 지정된 이미지에 OpenSSH 서버 v0.0.1.0이 설치되어 있어야 합니다.

프로세스

  1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 <file_name>.yaml이라는 이름을 지정합니다.

    <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

  2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

    1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machinesets -n openshift-machine-api

      출력 예

      Copy to Clipboard Toggle word wrap 
      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      출력 예

      Copy to Clipboard Toggle word wrap 
      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      클러스터 인프라 ID입니다.
      2
      기본 노드 레이블입니다.
      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 worker 및 infra 유형 머신만 생성할 수 있습니다.

      3
      컴퓨팅 머신 세트 CR의 <providerSpec> 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 <providerSpec> 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

  3. 다음 명령을 실행하여 MachineSet CR을 생성합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create -f <file_name>.yaml

검증

  • 다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machineset -n openshift-machine-api

    출력 예

    Copy to Clipboard Toggle word wrap 
    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    새 컴퓨팅 머신 세트를 사용할 수 있으면 DESIRED 및 CURRENT 값이 일치합니다. 컴퓨팅 머신 세트를 사용할 수 없는 경우 몇 분 기다렸다가 명령을 다시 실행합니다.

6.1.4. 추가 리소스

6.2. Azure에서 Windows 머신 세트 생성

Microsoft Azure의 OpenShift Container Platform 클러스터에서 특정 목적을 수행하기 위해 Windows MachineSet 오브젝트를 생성할 수 있습니다. 예를 들어, 지원되는 워크로드를 새 Windows 머신으로 이동할 수 있도록 인프라 Windows MachineSet 및 관련 머신을 생성할 수 있습니다.

사전 요구 사항
  • OLM(Operator Lifecycle Manager)을 사용하여 WMCO(Windows Machine Config Operator)를 설치했습니다.
  • 지원되는 Windows Server를 운영 체제 이미지로 사용하고 있습니다.

6.2.1. Machine API 개요

Machine API는 업스트림 Cluster API 프로젝트 및 사용자 정의 OpenShift Container Platform 리소스를 기반으로 하는 주요 리소스의 조합입니다.

OpenShift Container Platform 4.16 클러스터의 경우 Machine API는 클러스터 설치가 완료된 후 모든 노드 호스트 프로비저닝 관리 작업을 수행합니다. 이 시스템으로 인해 OpenShift Container Platform 4.16은 퍼블릭 또는 프라이빗 클라우드 인프라에 더하여 탄력적이고 동적인 프로비저닝 방법을 제공합니다.

두 가지 주요 리소스는 다음과 같습니다.

Machine
노드의 호스트를 설명하는 기본 단위입니다. 머신에는 providerSpec 사양이 있으며 이는 다른 클라우드 플랫폼에 제공되는 컴퓨팅 노드 유형을 설명합니다. 예를 들어 컴퓨팅 노드의 머신 유형은 특정 시스템 유형과 필수 메타데이터를 정의할 수 있습니다.
머신 세트

MachineSet 리소스는 컴퓨팅 머신 그룹입니다. 컴퓨팅 머신 세트는 컴퓨팅 머신에 연관되어 있고 복제본 세트는 pod에 연관되어 있습니다. 더 많은 컴퓨팅 머신이 필요하거나 확장해야 하는 경우 컴퓨팅 요구 사항에 맞게 MachineSet 리소스의 replicas 필드를 변경합니다.

주의

컨트롤 플레인 시스템은 컴퓨팅 머신 세트로 관리할 수 없습니다.

컨트롤 플레인 머신 세트는 컴퓨팅 머신에 제공하는 컴퓨팅 머신 세트와 유사한 지원되는 컨트롤 플레인 시스템에 대한 관리 기능을 제공합니다.

자세한 내용은 "컨트롤 플레인 머신 관리"를 참조하십시오.

다음 사용자 지정 리소스는 클러스터에 더 많은 기능을 추가할 수 있습니다.

머신 자동 스케일러

MachineAutoscaler 리소스는 클라우드에서 컴퓨팅 머신을 자동으로 확장합니다. 지정된 컴퓨팅 머신 세트에서 노드의 최소 및 최대 스케일링 경계를 설정할 수 있으며 머신 자동 스케일러는 해당 노드 범위를 유지합니다.

MachineAutoscaler 객체는 ClusterAutoscaler 객체를 설정한 후에 사용할 수 있습니다. ClusterAutoscaler 및 MachineAutoscaler리소스는 모두 ClusterAutoscalerOperator 오브젝트에서 사용 가능합니다.

Cluster autoscaler

이 리소스는 업스트림 클러스터 자동 스케일러 프로젝트를 기반으로 합니다. OpenShift Container Platform 구현에서는 컴퓨팅 머신 세트 API를 확장하여 Machine API와 통합됩니다. 클러스터 자동 스케일러를 사용하여 다음과 같은 방법으로 클러스터를 관리할 수 있습니다.

  • 코어, 노드, 메모리, GPU와 같은 리소스에 대한 클러스터 전체 스케일링 제한을 설정합니다.
  • 중요도가 낮은 Pod에 대해 클러스터가 Pod 및 새 노드가 온라인 상태가 되지 않도록 우선 순위를 설정합니다.
  • 노드를 확장할 수는 있지만 축소할 수 없도록 스케일링 정책을 설정합니다.
머신 상태 점검
MachineHealthCheck 리소스는 머신의 비정상적인 상태를 감지하여 삭제한 후 지원되는 플랫폼에서 새 머신을 생성합니다.

OpenShift Container Platform 버전 3.11에서는 클러스터가 머신 프로비저닝을 관리하지 않았기 때문에 다중 영역 아키텍처를 쉽게 롤아웃할 수 없었습니다. OpenShift Container Platform 버전 4.1부터 이러한 프로세스가 더 쉬워졌습니다. 각 컴퓨팅 머신 세트의 범위는 단일 영역으로 지정되므로 설치 프로그램은 사용자를 대신하여 가용성 영역 전체에 컴퓨팅 머신 세트를 보냅니다. 또한 계산이 동적이고 영역 장애가 발생하여 머신을 재조정해야하는 경우 처리할 수 있는 영역을 확보할 수 있습니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다. Autoscaler는 클러스터의 수명 기간 동안 최적의 균형을 유지합니다.

6.2.2. Azure에서 Windows MachineSet 오브젝트를 위한 샘플 YAML

이 샘플 YAML은 Microsoft Azure에서 WMCO(Windows Machine Config Operator)가 응답할 수 있는 Windows MachineSet 오브젝트를 정의합니다.

Copy to Clipboard Toggle word wrap 
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <windows_machine_set_name>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
9 

            offer: WindowsServer
            publisher: MicrosoftWindowsServer
            resourceID: ""
            sku: 2019-Datacenter-with-Containers
            version: latest
          kind: AzureMachineProviderSpec
          location: <location>
10 

          managedIdentity: <infrastructure_id>-identity
11 

          networkResourceGroup: <infrastructure_id>-rg
12 

          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Windows
          publicIP: false
          resourceGroup: <infrastructure_id>-rg
13 

          subnet: <infrastructure_id>-worker-subnet
          userDataSecret:
            name: windows-user-data
14 

            namespace: openshift-machine-api
          vmSize: Standard_D2s_v3
          vnet: <infrastructure_id>-vnet
15 

          zone: "<zone>"
16
1 3 5 11 12 13 15
클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. 다음 명령을 실행하여 인프라 ID를 가져올 수 있습니다.
Copy to Clipboard Toggle word wrap 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
Windows 컴퓨팅 머신 세트 이름을 지정합니다. Azure의 Windows 머신 이름은 15자 이하여야 합니다. 따라서 컴퓨팅 머신 세트 이름은 머신 이름이 생성되는 방식으로 인해 9자를 초과할 수 없습니다.
7
컴퓨팅 머신 세트를 Windows 머신으로 구성합니다.
8
Windows 노드를 컴퓨팅 머신으로 구성합니다.
9
2019-Datacenter-with-Containers SKU를 정의하는 WindowsServer 이미지 제공을 지정합니다.
10
centralus와 같이 Azure 리전을 지정합니다.
14
첫 번째 Windows 머신을 구성할 때 WMCO에 의해 생성되었습니다. 그 후 모든 후속 컴퓨팅 머신 세트에 대해 windows-user-data 를 사용할 수 있습니다.
16
머신을 배치할 리전 내 영역을 지정합니다. 해당 리전이 지정한 영역을 지원하는지 확인합니다.

6.2.3. 컴퓨팅 머신 세트 생성

설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 배포합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.
  • 연결이 끊긴 환경의 경우 MachineSet CR(사용자 정의 리소스)에 지정된 이미지에 OpenSSH 서버 v0.0.1.0이 설치되어 있어야 합니다.

프로세스

  1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 <file_name>.yaml이라는 이름을 지정합니다.

    <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

  2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

    1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machinesets -n openshift-machine-api

      출력 예

      Copy to Clipboard Toggle word wrap 
      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      출력 예

      Copy to Clipboard Toggle word wrap 
      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      클러스터 인프라 ID입니다.
      2
      기본 노드 레이블입니다.
      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 worker 및 infra 유형 머신만 생성할 수 있습니다.

      3
      컴퓨팅 머신 세트 CR의 <providerSpec> 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 <providerSpec> 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

  3. 다음 명령을 실행하여 MachineSet CR을 생성합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create -f <file_name>.yaml

검증

  • 다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machineset -n openshift-machine-api

    출력 예

    Copy to Clipboard Toggle word wrap 
    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    새 컴퓨팅 머신 세트를 사용할 수 있으면 DESIRED 및 CURRENT 값이 일치합니다. 컴퓨팅 머신 세트를 사용할 수 없는 경우 몇 분 기다렸다가 명령을 다시 실행합니다.

6.2.4. 추가 리소스

6.3. GCP에서 Windows 머신 세트 생성

Google Cloud Platform (GCP)의 OpenShift Container Platform 클러스터에서 특정 목적을 충족하기 위해 Windows MachineSet 오브젝트를 생성할 수 있습니다. 예를 들어, 지원되는 워크로드를 새 Windows 머신으로 이동할 수 있도록 인프라 Windows MachineSet 및 관련 머신을 생성할 수 있습니다.

사전 요구 사항
  • OLM(Operator Lifecycle Manager)을 사용하여 WMCO(Windows Machine Config Operator)를 설치했습니다.
  • 지원되는 Windows Server를 운영 체제 이미지로 사용하고 있습니다.

6.3.1. Machine API 개요

Machine API는 업스트림 Cluster API 프로젝트 및 사용자 정의 OpenShift Container Platform 리소스를 기반으로 하는 주요 리소스의 조합입니다.

OpenShift Container Platform 4.16 클러스터의 경우 Machine API는 클러스터 설치가 완료된 후 모든 노드 호스트 프로비저닝 관리 작업을 수행합니다. 이 시스템으로 인해 OpenShift Container Platform 4.16은 퍼블릭 또는 프라이빗 클라우드 인프라에 더하여 탄력적이고 동적인 프로비저닝 방법을 제공합니다.

두 가지 주요 리소스는 다음과 같습니다.

Machine
노드의 호스트를 설명하는 기본 단위입니다. 머신에는 providerSpec 사양이 있으며 이는 다른 클라우드 플랫폼에 제공되는 컴퓨팅 노드 유형을 설명합니다. 예를 들어 컴퓨팅 노드의 머신 유형은 특정 시스템 유형과 필수 메타데이터를 정의할 수 있습니다.
머신 세트

MachineSet 리소스는 컴퓨팅 머신 그룹입니다. 컴퓨팅 머신 세트는 컴퓨팅 머신에 연관되어 있고 복제본 세트는 pod에 연관되어 있습니다. 더 많은 컴퓨팅 머신이 필요하거나 확장해야 하는 경우 컴퓨팅 요구 사항에 맞게 MachineSet 리소스의 replicas 필드를 변경합니다.

주의

컨트롤 플레인 시스템은 컴퓨팅 머신 세트로 관리할 수 없습니다.

컨트롤 플레인 머신 세트는 컴퓨팅 머신에 제공하는 컴퓨팅 머신 세트와 유사한 지원되는 컨트롤 플레인 시스템에 대한 관리 기능을 제공합니다.

자세한 내용은 "컨트롤 플레인 머신 관리"를 참조하십시오.

다음 사용자 지정 리소스는 클러스터에 더 많은 기능을 추가할 수 있습니다.

머신 자동 스케일러

MachineAutoscaler 리소스는 클라우드에서 컴퓨팅 머신을 자동으로 확장합니다. 지정된 컴퓨팅 머신 세트에서 노드의 최소 및 최대 스케일링 경계를 설정할 수 있으며 머신 자동 스케일러는 해당 노드 범위를 유지합니다.

MachineAutoscaler 객체는 ClusterAutoscaler 객체를 설정한 후에 사용할 수 있습니다. ClusterAutoscaler 및 MachineAutoscaler리소스는 모두 ClusterAutoscalerOperator 오브젝트에서 사용 가능합니다.

Cluster autoscaler

이 리소스는 업스트림 클러스터 자동 스케일러 프로젝트를 기반으로 합니다. OpenShift Container Platform 구현에서는 컴퓨팅 머신 세트 API를 확장하여 Machine API와 통합됩니다. 클러스터 자동 스케일러를 사용하여 다음과 같은 방법으로 클러스터를 관리할 수 있습니다.

  • 코어, 노드, 메모리, GPU와 같은 리소스에 대한 클러스터 전체 스케일링 제한을 설정합니다.
  • 중요도가 낮은 Pod에 대해 클러스터가 Pod 및 새 노드가 온라인 상태가 되지 않도록 우선 순위를 설정합니다.
  • 노드를 확장할 수는 있지만 축소할 수 없도록 스케일링 정책을 설정합니다.
머신 상태 점검
MachineHealthCheck 리소스는 머신의 비정상적인 상태를 감지하여 삭제한 후 지원되는 플랫폼에서 새 머신을 생성합니다.

OpenShift Container Platform 버전 3.11에서는 클러스터가 머신 프로비저닝을 관리하지 않았기 때문에 다중 영역 아키텍처를 쉽게 롤아웃할 수 없었습니다. OpenShift Container Platform 버전 4.1부터 이러한 프로세스가 더 쉬워졌습니다. 각 컴퓨팅 머신 세트의 범위는 단일 영역으로 지정되므로 설치 프로그램은 사용자를 대신하여 가용성 영역 전체에 컴퓨팅 머신 세트를 보냅니다. 또한 계산이 동적이고 영역 장애가 발생하여 머신을 재조정해야하는 경우 처리할 수 있는 영역을 확보할 수 있습니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다. Autoscaler는 클러스터의 수명 기간 동안 최적의 균형을 유지합니다.

6.3.2. GCP에서 Windows MachineSet 오브젝트를 위한 샘플 YAML

이 샘플 YAML 파일은 WMCO(Windows Machine Config Operator)에서 사용할 수 있는 GCP(Google Cloud Platform)에서 실행되는 Windows MachineSet 오브젝트를 정의합니다.

Copy to Clipboard Toggle word wrap 
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <infrastructure_id>-windows-worker-<zone_suffix>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone_suffix>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone_suffix>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <windows_server_image>
9 

            sizeGb: 128
            type: pd-ssd
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          networkInterfaces:
          - network: <infrastructure_id>-network
10 

            subnetwork: <infrastructure_id>-worker-subnet
          projectID: <project_id>
11 

          region: <region>
12 

          serviceAccounts:
          - email: <infrastructure_id>-w@<project_id>.iam.gserviceaccount.com
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
          - <infrastructure_id>-worker
          userDataSecret:
            name: windows-user-data
13 

          zone: <zone>
14
1 3 5 10
클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. 다음 명령을 실행하여 인프라 ID를 가져올 수 있습니다.
Copy to Clipboard Toggle word wrap 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
인프라 ID, 작업자 레이블, 영역 접미사(예:a)를 지정합니다.
7
머신 세트를 Windows 머신으로 구성합니다.
8
Windows 노드를 컴퓨팅 머신으로 구성합니다.
9
지원되는 Windows Server 버전의 이미지에 대한 전체 경로를 지정합니다.
11
이 클러스터가 생성된 GCP 프로젝트를 지정합니다.
12
us-central1 과 같은 GCP 리전을 지정합니다.
13
첫 번째 Windows 머신을 구성할 때 WMCO에 의해 생성됩니다. 이후에는, 모든 후속 머신 세트에서 Windows-user-data를 사용할 수 있습니다.
14
us-central1-a 와 같이 선택한 리전 내의 영역을 지정합니다.

6.3.3. 컴퓨팅 머신 세트 생성

설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 배포합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

프로세스

  1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 <file_name>.yaml이라는 이름을 지정합니다.

    <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

  2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

    1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machinesets -n openshift-machine-api

      출력 예

      Copy to Clipboard Toggle word wrap 
      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      출력 예

      Copy to Clipboard Toggle word wrap 
      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      클러스터 인프라 ID입니다.
      2
      기본 노드 레이블입니다.
      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 worker 및 infra 유형 머신만 생성할 수 있습니다.

      3
      컴퓨팅 머신 세트 CR의 <providerSpec> 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 <providerSpec> 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

  3. 다음 명령을 실행하여 MachineSet CR을 생성합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create -f <file_name>.yaml

검증

  • 다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machineset -n openshift-machine-api

    출력 예

    Copy to Clipboard Toggle word wrap 
    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    새 컴퓨팅 머신 세트를 사용할 수 있으면 DESIRED 및 CURRENT 값이 일치합니다. 컴퓨팅 머신 세트를 사용할 수 없는 경우 몇 분 기다렸다가 명령을 다시 실행합니다.

6.3.4. 추가 리소스

6.4. Nutanix에서 Windows MachineSet 오브젝트 생성

Nutanix의 OpenShift Container Platform 클러스터에서 특정 목적을 충족하기 위해 Windows MachineSet 오브젝트를 생성할 수 있습니다. 예를 들어, 지원되는 워크로드를 새 Windows 머신으로 이동할 수 있도록 인프라 Windows MachineSet 및 관련 머신을 생성할 수 있습니다.

사전 요구 사항
  • OLM(Operator Lifecycle Manager)을 사용하여 WMCO(Windows Machine Config Operator)를 설치했습니다.
  • 지원되는 Windows Server를 운영 체제 이미지로 사용하고 있습니다.
  • 내부 API 서버 URL api-int.<cluster_name>.<base_domain > 에 대한 새 DNS 항목을 추가하여 외부 API 서버 URL api.<cluster_name>.<base_domain >을 가리킵니다. 이 항목은 CNAME 또는 추가 A 레코드일 수 있습니다.

6.4.1. Machine API 개요

Machine API는 업스트림 Cluster API 프로젝트 및 사용자 정의 OpenShift Container Platform 리소스를 기반으로 하는 주요 리소스의 조합입니다.

OpenShift Container Platform 4.16 클러스터의 경우 Machine API는 클러스터 설치가 완료된 후 모든 노드 호스트 프로비저닝 관리 작업을 수행합니다. 이 시스템으로 인해 OpenShift Container Platform 4.16은 퍼블릭 또는 프라이빗 클라우드 인프라에 더하여 탄력적이고 동적인 프로비저닝 방법을 제공합니다.

두 가지 주요 리소스는 다음과 같습니다.

Machine
노드의 호스트를 설명하는 기본 단위입니다. 머신에는 providerSpec 사양이 있으며 이는 다른 클라우드 플랫폼에 제공되는 컴퓨팅 노드 유형을 설명합니다. 예를 들어 컴퓨팅 노드의 머신 유형은 특정 시스템 유형과 필수 메타데이터를 정의할 수 있습니다.
머신 세트

MachineSet 리소스는 컴퓨팅 머신 그룹입니다. 컴퓨팅 머신 세트는 컴퓨팅 머신에 연관되어 있고 복제본 세트는 pod에 연관되어 있습니다. 더 많은 컴퓨팅 머신이 필요하거나 확장해야 하는 경우 컴퓨팅 요구 사항에 맞게 MachineSet 리소스의 replicas 필드를 변경합니다.

주의

컨트롤 플레인 시스템은 컴퓨팅 머신 세트로 관리할 수 없습니다.

컨트롤 플레인 머신 세트는 컴퓨팅 머신에 제공하는 컴퓨팅 머신 세트와 유사한 지원되는 컨트롤 플레인 시스템에 대한 관리 기능을 제공합니다.

자세한 내용은 "컨트롤 플레인 머신 관리"를 참조하십시오.

다음 사용자 지정 리소스는 클러스터에 더 많은 기능을 추가할 수 있습니다.

머신 자동 스케일러

MachineAutoscaler 리소스는 클라우드에서 컴퓨팅 머신을 자동으로 확장합니다. 지정된 컴퓨팅 머신 세트에서 노드의 최소 및 최대 스케일링 경계를 설정할 수 있으며 머신 자동 스케일러는 해당 노드 범위를 유지합니다.

MachineAutoscaler 객체는 ClusterAutoscaler 객체를 설정한 후에 사용할 수 있습니다. ClusterAutoscaler 및 MachineAutoscaler리소스는 모두 ClusterAutoscalerOperator 오브젝트에서 사용 가능합니다.

Cluster autoscaler

이 리소스는 업스트림 클러스터 자동 스케일러 프로젝트를 기반으로 합니다. OpenShift Container Platform 구현에서는 컴퓨팅 머신 세트 API를 확장하여 Machine API와 통합됩니다. 클러스터 자동 스케일러를 사용하여 다음과 같은 방법으로 클러스터를 관리할 수 있습니다.

  • 코어, 노드, 메모리, GPU와 같은 리소스에 대한 클러스터 전체 스케일링 제한을 설정합니다.
  • 중요도가 낮은 Pod에 대해 클러스터가 Pod 및 새 노드가 온라인 상태가 되지 않도록 우선 순위를 설정합니다.
  • 노드를 확장할 수는 있지만 축소할 수 없도록 스케일링 정책을 설정합니다.
머신 상태 점검
MachineHealthCheck 리소스는 머신의 비정상적인 상태를 감지하여 삭제한 후 지원되는 플랫폼에서 새 머신을 생성합니다.

OpenShift Container Platform 버전 3.11에서는 클러스터가 머신 프로비저닝을 관리하지 않았기 때문에 다중 영역 아키텍처를 쉽게 롤아웃할 수 없었습니다. OpenShift Container Platform 버전 4.1부터 이러한 프로세스가 더 쉬워졌습니다. 각 컴퓨팅 머신 세트의 범위는 단일 영역으로 지정되므로 설치 프로그램은 사용자를 대신하여 가용성 영역 전체에 컴퓨팅 머신 세트를 보냅니다. 또한 계산이 동적이고 영역 장애가 발생하여 머신을 재조정해야하는 경우 처리할 수 있는 영역을 확보할 수 있습니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다. Autoscaler는 클러스터의 수명 기간 동안 최적의 균형을 유지합니다.

6.4.2. Nutanix에서 Windows MachineSet 오브젝트를 위한 샘플 YAML

이 샘플 YAML은 WMCO(Windows Machine Config Operator)가 응답할 수 있는 Nutanix에서 실행되는 Windows MachineSet 오브젝트를 정의합니다.

Copy to Clipboard Toggle word wrap 
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <infrastructure_id>-windows-worker-<zone>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          bootType: ""
9 

          categories: null
          cluster:
10 

            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-credentials
11 

          image:
12 

            name: <image_id>
            type: name
          kind: NutanixMachineProviderConfig
13 

          memorySize: 16Gi
14 

          project:
            type: ""
          subnets:
15 

          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi
16 

          userDataSecret:
            name: windows-user-data
17 

          vcpuSockets: 4
18 

          vcpusPerSocket: 1
19
1 3 5
클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. 다음 명령을 실행하여 인프라 ID를 가져올 수 있습니다.
Copy to Clipboard Toggle word wrap 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
인프라 ID, 작업자 레이블 및 영역을 지정합니다.
7
컴퓨팅 머신 세트를 Windows 머신으로 구성합니다.
8
Windows 노드를 컴퓨팅 머신으로 구성합니다.
9
컴퓨팅 시스템에서 사용하는 부팅 유형을 지정합니다. 부팅 유형에 대한 자세한 내용은 가상화 된 환경에서 UEFI, Secure Boot 및 TPM 이해를 참조하십시오. 유효한 값은 Legacy,SecureBoot 또는 UEFI 입니다. 기본값은 Legacy 입니다.
참고

OpenShift Container Platform 4.16에서 레거시 부팅 유형을 사용해야 합니다.

10
Nutanix Prism Element 클러스터 구성을 지정합니다. 이 예에서 클러스터 유형은 uuid 이므로 uuid 스탠자가 있습니다.
11
클러스터의 시크릿 이름을 지정합니다. 이 값은 변경하지 마십시오.
12
사용할 이미지를 지정합니다. 클러스터의 기존 기본 컴퓨팅 머신 세트의 이미지를 사용합니다.
13
클라우드 공급자 플랫폼 유형을 지정합니다. 이 값은 변경하지 마십시오.
14
Gi에 있는 클러스터의 메모리 양을 지정합니다.
15
서브넷 구성을 지정합니다. 이 예에서 서브넷 유형은 uuid 이므로 uuid 스탠자가 있습니다.
16
Gi의 시스템 디스크 크기를 지정합니다.
17
사용자 데이터 YAML 파일의 시크릿 이름을 openshift-machine-api 네임스페이스에 지정합니다. 설치 프로그램이 기본 컴퓨팅 시스템 세트에 채우는 값을 사용합니다.
18
vCPU 소켓 수를 지정합니다.
19
소켓당 vCPU 수를 지정합니다.

6.4.3. 컴퓨팅 머신 세트 생성

설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 배포합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

프로세스

  1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 <file_name>.yaml이라는 이름을 지정합니다.

    <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

  2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

    1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machinesets -n openshift-machine-api

      출력 예

      Copy to Clipboard Toggle word wrap 
      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      출력 예

      Copy to Clipboard Toggle word wrap 
      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      클러스터 인프라 ID입니다.
      2
      기본 노드 레이블입니다.
      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 worker 및 infra 유형 머신만 생성할 수 있습니다.

      3
      컴퓨팅 머신 세트 CR의 <providerSpec> 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 <providerSpec> 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

  3. 다음 명령을 실행하여 MachineSet CR을 생성합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create -f <file_name>.yaml

검증

  • 다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machineset -n openshift-machine-api

    출력 예

    Copy to Clipboard Toggle word wrap 
    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    새 컴퓨팅 머신 세트를 사용할 수 있으면 DESIRED 및 CURRENT 값이 일치합니다. 컴퓨팅 머신 세트를 사용할 수 없는 경우 몇 분 기다렸다가 명령을 다시 실행합니다.

6.4.4. 추가 리소스

6.5. vSphere에서 Windows 머신 세트 생성

VMware vSphere의 OpenShift Container Platform 클러스터에서 특정 목적을 수행하기 위해 Windows MachineSet 오브젝트를 생성할 수 있습니다. 예를 들어, 지원되는 워크로드를 새 Windows 머신으로 이동할 수 있도록 인프라 Windows MachineSet 및 관련 머신을 생성할 수 있습니다.

사전 요구 사항
  • OLM(Operator Lifecycle Manager)을 사용하여 WMCO(Windows Machine Config Operator)를 설치했습니다.
  • 지원되는 Windows Server를 운영 체제 이미지로 사용하고 있습니다.

6.5.1. Machine API 개요

Machine API는 업스트림 Cluster API 프로젝트 및 사용자 정의 OpenShift Container Platform 리소스를 기반으로 하는 주요 리소스의 조합입니다.

OpenShift Container Platform 4.16 클러스터의 경우 Machine API는 클러스터 설치가 완료된 후 모든 노드 호스트 프로비저닝 관리 작업을 수행합니다. 이 시스템으로 인해 OpenShift Container Platform 4.16은 퍼블릭 또는 프라이빗 클라우드 인프라에 더하여 탄력적이고 동적인 프로비저닝 방법을 제공합니다.

두 가지 주요 리소스는 다음과 같습니다.

Machine
노드의 호스트를 설명하는 기본 단위입니다. 머신에는 providerSpec 사양이 있으며 이는 다른 클라우드 플랫폼에 제공되는 컴퓨팅 노드 유형을 설명합니다. 예를 들어 컴퓨팅 노드의 머신 유형은 특정 시스템 유형과 필수 메타데이터를 정의할 수 있습니다.
머신 세트

MachineSet 리소스는 컴퓨팅 머신 그룹입니다. 컴퓨팅 머신 세트는 컴퓨팅 머신에 연관되어 있고 복제본 세트는 pod에 연관되어 있습니다. 더 많은 컴퓨팅 머신이 필요하거나 확장해야 하는 경우 컴퓨팅 요구 사항에 맞게 MachineSet 리소스의 replicas 필드를 변경합니다.

주의

컨트롤 플레인 시스템은 컴퓨팅 머신 세트로 관리할 수 없습니다.

컨트롤 플레인 머신 세트는 컴퓨팅 머신에 제공하는 컴퓨팅 머신 세트와 유사한 지원되는 컨트롤 플레인 시스템에 대한 관리 기능을 제공합니다.

자세한 내용은 "컨트롤 플레인 머신 관리"를 참조하십시오.

다음 사용자 지정 리소스는 클러스터에 더 많은 기능을 추가할 수 있습니다.

머신 자동 스케일러

MachineAutoscaler 리소스는 클라우드에서 컴퓨팅 머신을 자동으로 확장합니다. 지정된 컴퓨팅 머신 세트에서 노드의 최소 및 최대 스케일링 경계를 설정할 수 있으며 머신 자동 스케일러는 해당 노드 범위를 유지합니다.

MachineAutoscaler 객체는 ClusterAutoscaler 객체를 설정한 후에 사용할 수 있습니다. ClusterAutoscaler 및 MachineAutoscaler리소스는 모두 ClusterAutoscalerOperator 오브젝트에서 사용 가능합니다.

Cluster autoscaler

이 리소스는 업스트림 클러스터 자동 스케일러 프로젝트를 기반으로 합니다. OpenShift Container Platform 구현에서는 컴퓨팅 머신 세트 API를 확장하여 Machine API와 통합됩니다. 클러스터 자동 스케일러를 사용하여 다음과 같은 방법으로 클러스터를 관리할 수 있습니다.

  • 코어, 노드, 메모리, GPU와 같은 리소스에 대한 클러스터 전체 스케일링 제한을 설정합니다.
  • 중요도가 낮은 Pod에 대해 클러스터가 Pod 및 새 노드가 온라인 상태가 되지 않도록 우선 순위를 설정합니다.
  • 노드를 확장할 수는 있지만 축소할 수 없도록 스케일링 정책을 설정합니다.
머신 상태 점검
MachineHealthCheck 리소스는 머신의 비정상적인 상태를 감지하여 삭제한 후 지원되는 플랫폼에서 새 머신을 생성합니다.

OpenShift Container Platform 버전 3.11에서는 클러스터가 머신 프로비저닝을 관리하지 않았기 때문에 다중 영역 아키텍처를 쉽게 롤아웃할 수 없었습니다. OpenShift Container Platform 버전 4.1부터 이러한 프로세스가 더 쉬워졌습니다. 각 컴퓨팅 머신 세트의 범위는 단일 영역으로 지정되므로 설치 프로그램은 사용자를 대신하여 가용성 영역 전체에 컴퓨팅 머신 세트를 보냅니다. 또한 계산이 동적이고 영역 장애가 발생하여 머신을 재조정해야하는 경우 처리할 수 있는 영역을 확보할 수 있습니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다. Autoscaler는 클러스터의 수명 기간 동안 최적의 균형을 유지합니다.

6.5.2. Windows 컨테이너 워크로드를 위한 vSphere 환경 준비

vSphere Windows VM✓ 이미지를 생성하고 WMCO의 내부 API 서버와의 통신을 활성화하여 Windows 컨테이너 워크로드를 위한 vSphere 환경을 준비해야 합니다.

6.5.2.1. vSphere Windows VM 골든 이미지 생성

vSphere Windows VM(가상 머신) 골든 이미지를 생성합니다.

사전 요구 사항

  • OpenSSH 서버에서 키 기반 인증을 구성하는 데 사용되는 개인/공용 키 쌍을 생성했습니다. 개인 키는 WMCO(Windows Machine Config Operator) 네임스페이스에서 구성해야 합니다. 이 작업은 WMCO가 Windows VM과 통신할 수 있도록 하는 데 필요합니다. 자세한 내용은 "Windows Machine Config Operator의 시크릿 구성" 섹션을 참조하십시오.
참고

Windows VM을 생성할 때 몇 가지 경우에 Microsoft PowerShell 명령을 사용해야 합니다. 이 가이드의 PowerShell 명령은 PS C:\> 접두사로 구분됩니다.

프로세스

  1. 호환되는 Windows Server 버전을 선택합니다. 현재 WMCO(Windows Machine Config Operator)의 안정적인 버전은 OS 수준 컨테이너 네트워킹 패치 KB5012637 과 함께 Windows Server 2022 Long-Term Servicing 채널을 지원합니다.

  2. 호환되는 Windows Server 버전과 함께 VM golden 이미지를 사용하여 vSphere 클라이언트에 새 VM을 생성합니다. 호환되는 버전에 대한 자세한 내용은 "Windows Machine Config Operator 사전 요구 사항"섹션 "Windows Containers 용 Red Hat OpenShift 지원 릴리스 노트" 섹션을 참조하십시오.

    중요

    VM의 가상 하드웨어 버전은 OpenShift Container Platform의 인프라 요구 사항을 충족해야 합니다. 자세한 내용은 OpenShift Container Platform 설명서의 "VMware vSphere 인프라 요구 사항" 섹션을 참조하십시오. 또한 가상 시스템 하드웨어 버전에 대한 VMware의 설명서를 참조할 수 있습니다.

  3. Windows VM에서 VMware Tools 버전 11.0.6 이상을 설치 및 구성합니다. 자세한 내용은 VMware Tools 설명서를 참조하십시오.

  4. Windows VM에 VMware Tools를 설치한 후 다음을 확인합니다.

    1. C:\ProgramData\VMware\VMware Tools\tools.conf 파일은 다음 항목과 함께 있습니다.

      Copy to Clipboard Toggle word wrap 
      exclude-nics=

      tools.conf 파일이 없는 경우 exclude-nics 옵션을 사용하여 주석을 제거하고 빈 값으로 설정합니다.

      이 항목을 사용하면 하이브리드 오버레이에 의해 Windows VM에서 생성된 복제된 vNIC가 무시되지 않습니다.

    2. Windows VM의 vCenter에는 유효한 IP 주소가 있습니다.

      Copy to Clipboard Toggle word wrap 
      C:\> ipconfig

    3. VMTools Windows 서비스가 실행 중입니다.

      Copy to Clipboard Toggle word wrap 
      PS C:\> Get-Service -Name VMTools | Select Status, StartType
  5. Windows VM에 OpenSSH 서버를 설치하고 구성합니다. 자세한 내용은 Microsoft의 OpenSSH 설치에 대한 설명서를 참조하십시오.

  6. 관리자에 대한 SSH 액세스 권한을 설정합니다. 이 작업을 수행하려면 사용자에 대한 Microsoft 문서를 참조하십시오.

    중요

    명령에 사용되는 공개 키는 시크릿을 보유한 WMCO 네임스페이스에서 나중에 생성하는 개인 키에 대응해야 합니다. 자세한 내용은 "Windows Machine Config Operator의 시크릿 구성" 섹션을 참조하십시오.

  7. 컨테이너 로그에 수신 연결을 허용하는 Windows VM에서 새 방화벽 규칙을 생성해야 합니다. 다음 PowerShell 명령을 실행하여 TCP 포트 10250에서 방화벽 규칙을 생성합니다.

    Copy to Clipboard Toggle word wrap 
    PS C:\> New-NetFirewallRule -DisplayName "ContainerLogsPort" -LocalPort 10250 -Enabled True -Direction Inbound -Protocol TCP -Action Allow -EdgeTraversalPolicy Allow
  8. Windows VM을 다시 사용할 수 있도록 복제합니다. 자세한 내용은 기존 가상 머신을 복제 하는 방법에 대한 VMware 설명서를 참조하십시오.

  9. 복제된 Windows VM에서 Windows Sysprep 툴 을 실행합니다.

    Copy to Clipboard Toggle word wrap 
    C:\> C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown /unattend:<path_to_unattend.xml>
    1
    1
    unattend.xml 파일의 경로를 지정합니다.
    참고

    Windows 이미지에서 sysprep 명령을 실행할 수 있는 횟수에 제한이 있습니다. 자세한 내용은 Microsoft 설명서를 참조하십시오.

    WMCO에 필요한 모든 변경 사항을 유지관리하는 unattend.xml 예시가 제공됩니다. 이 예제를 수정해야 합니다. 직접 사용할 수 없습니다.

    예 6.1. 예시 unattend.xml

    Copy to Clipboard Toggle word wrap 
    <?xml version="1.0" encoding="UTF-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
   <settings pass="specialize">
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <InputLocale>0409:00000409</InputLocale>
         <SystemLocale>en-US</SystemLocale>
         <UILanguage>en-US</UILanguage>
         <UILanguageFallback>en-US</UILanguageFallback>
         <UserLocale>en-US</UserLocale>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <SkipAutoActivation>true</SkipAutoActivation>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-SQMApi" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <CEIPEnabled>0</CEIPEnabled>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <ComputerName>winhost</ComputerName>
    1 
    
      </component>
   </settings>
   <settings pass="oobeSystem">
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <AutoLogon>
            <Enabled>false</Enabled>
    2 
    
         </AutoLogon>
         <OOBE>
            <HideEULAPage>true</HideEULAPage>
            <HideLocalAccountScreen>true</HideLocalAccountScreen>
            <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
            <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
            <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
            <NetworkLocation>Work</NetworkLocation>
            <ProtectYourPC>1</ProtectYourPC>
            <SkipMachineOOBE>true</SkipMachineOOBE>
            <SkipUserOOBE>true</SkipUserOOBE>
         </OOBE>
         <RegisteredOrganization>Organization</RegisteredOrganization>
         <RegisteredOwner>Owner</RegisteredOwner>
         <DisableAutoDaylightTimeSet>false</DisableAutoDaylightTimeSet>
         <TimeZone>Eastern Standard Time</TimeZone>
         <UserAccounts>
            <AdministratorPassword>
               <Value>MyPassword</Value>
    3 
    
               <PlainText>true</PlainText>
            </AdministratorPassword>
         </UserAccounts>
      </component>
   </settings>
</unattend>
    1
    Kubernetes의 이름 사양 을 따라야 하는 ComputerName 을 지정합니다. 이러한 사양은 새 VM을 생성하는 동안 결과 템플릿에서 수행된 게스트 OS 사용자 지정에도 적용됩니다.
    2
    부팅 시 오픈 터미널에 관리자 권한이 있는 터미널을 떠나는 보안 문제를 방지하려면 자동 로그인을 비활성화합니다. 이는 기본값이며 변경할 수 없습니다.
    3
    MyPassword 자리 표시자를 Administrator 계정의 암호로 바꿉니다. 이렇게 하면 기본 제공 관리자 계정에 기본적으로 빈 암호가 없습니다. 암호 선택을 위한 Microsoft의 모범 사례를 따르십시오.

    Sysprep 도구가 완료되면 Windows VM의 전원을 끕니다. 더 이상 이 VM을 사용하거나 전원을 켜지 않아야 합니다.

  10. Windows VM을 vCenter의 템플릿으로 변환합니다.
6.5.2.1.1. 추가 리소스
6.5.2.2. vSphere에서 WMCO를 위한 내부 API 서버와의 통신 활성화

WMCO(Windows Machine Config Operator)는 내부 API 서버 끝점에서 Ignition 구성 파일을 다운로드합니다. Windows 가상 머신(VM)이 Ignition 구성 파일을 다운로드할 수 있고 구성된 VM의 kubelet이 내부 API 서버와 통신할 수 있도록 내부 API 서버와의 통신을 활성화해야 합니다.

사전 요구 사항

  • vSphere에 클러스터가 설치되어 있습니다.

절차

  • 외부 API 서버 URL api.<cluster_name>.<base_domain>을 가리키는 api-int.<cluster_name>.<base_domain>에 새로운 DNS 항목을 추가합니다. 이 항목은 CNAME 또는 추가 A 레코드일 수 있습니다.
참고

외부 API 끝점이 이미 vSphere의 초기 클러스터 설치의 일부로 생성되었습니다.

6.5.3. vSphere에서 Windows MachineSet 오브젝트를 위한 샘플 YAML

이 샘플 YAML은 VMware vSphere에서 WMCO(Windows Machine Config Operator)가 응답할 수 있는 Windows MachineSet 오브젝트를 정의합니다.

Copy to Clipboard Toggle word wrap 
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <windows_machine_set_name>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 128
9 

          kind: VSphereMachineProviderSpec
          memoryMiB: 16384
          network:
            devices:
            - networkName: "<vm_network_name>"
10 

          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <windows_vm_template_name>
11 

          userDataSecret:
            name: windows-user-data
12 

          workspace:
             datacenter: <vcenter_data_center_name>
13 

             datastore: <vcenter_datastore_name>
14 

             folder: <vcenter_vm_folder_path>
15 

             resourcePool: <vsphere_resource_pool>
16 

             server: <vcenter_server_ip>
17
1 3 5
클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. 다음 명령을 실행하여 인프라 ID를 가져올 수 있습니다.
Copy to Clipboard Toggle word wrap 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
Windows 컴퓨팅 머신 세트 이름을 지정합니다. 컴퓨팅 머신 세트 이름은 vSphere에서 머신 이름이 생성되는 방식으로 인해 9자를 초과할 수 없습니다.
7
컴퓨팅 머신 세트를 Windows 머신으로 구성합니다.
8
Windows 노드를 컴퓨팅 머신으로 구성합니다.
9
vSphere VMDK(가상 머신 디스크)의 크기를 지정합니다.
참고

이 매개변수는 Windows 파티션의 크기를 설정하지 않습니다. unattend.xml 파일을 사용하거나 필요한 디스크 크기로 vSphere Windows 가상 머신(VM) 골든 이미지를 생성하여 Windows 파티션의 크기를 조정할 수 있습니다.

10
컴퓨팅 머신 세트를 배포할 vSphere VM 네트워크를 지정합니다. 이 VM 네트워크는 클러스터에 다른 Linux 컴퓨팅 시스템이 상주하는 위치여야 합니다.
11
사용할 Windows vSphere VM 템플릿의 전체 경로를 지정합니다(예: golden-images/windows-server-template ). 이름은 고유해야 합니다.
중요

원래 VM 템플릿을 지정하지 마십시오. VM 템플릿이 꺼져 있어야 하며 새 Windows 시스템에 대해 복제해야 합니다. VM 템플릿을 시작하면 VM 템플릿이 플랫폼의 VM으로 구성되므로 컴퓨팅 머신 세트에서 구성을 적용할 수 있는 템플릿으로 사용되지 않습니다.

12
Windows-user-data는 첫 번째 Windows 머신이 구성될 때 WMCO에 의해 생성됩니다. 그 후 모든 후속 컴퓨팅 머신 세트에 대해 windows-user-data 를 사용할 수 있습니다.
13
컴퓨팅 머신 세트를 배포할 vCenter 데이터 센터를 지정합니다.
14
컴퓨팅 머신 세트를 배포할 vCenter 데이터 저장소를 지정합니다.
15
vCenter의 vSphere VM 폴더에 경로(예: /dc1/vm/user-inst-5ddjd)를 지정합니다.
16
선택 사항: Windows VM을 위한 vSphere 리소스 풀을 지정합니다.
17
vCenter 서버 IP 또는 정규화된 도메인 이름을 지정합니다.

6.5.4. 컴퓨팅 머신 세트 생성

설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 배포합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.
  • 연결이 끊긴 환경의 경우 MachineSet CR(사용자 정의 리소스)에 지정된 이미지에 OpenSSH 서버 v0.0.1.0이 설치되어 있어야 합니다.

프로세스

  1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 <file_name>.yaml이라는 이름을 지정합니다.

    <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

  2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

    1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machinesets -n openshift-machine-api

      출력 예

      Copy to Clipboard Toggle word wrap 
      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.

      Copy to Clipboard Toggle word wrap 
      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      출력 예

      Copy to Clipboard Toggle word wrap 
      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      클러스터 인프라 ID입니다.
      2
      기본 노드 레이블입니다.
      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 worker 및 infra 유형 머신만 생성할 수 있습니다.

      3
      컴퓨팅 머신 세트 CR의 <providerSpec> 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 <providerSpec> 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

  3. 다음 명령을 실행하여 MachineSet CR을 생성합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create -f <file_name>.yaml

검증

  • 다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machineset -n openshift-machine-api

    출력 예

    Copy to Clipboard Toggle word wrap 
    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    새 컴퓨팅 머신 세트를 사용할 수 있으면 DESIRED 및 CURRENT 값이 일치합니다. 컴퓨팅 머신 세트를 사용할 수 없는 경우 몇 분 기다렸다가 명령을 다시 실행합니다.

6.5.5. 추가 리소스

7장. Windows 컨테이너 워크로드 예약

Windows 워크로드를 Windows 컴퓨팅 노드에 예약할 수 있습니다.

사전 요구 사항

  • OLM(Operator Lifecycle Manager)을 사용하여 WMCO(Windows Machine Config Operator)를 설치했습니다.
  • Windows 컨테이너를 OS 이미지로 사용하고 있습니다.
  • Windows 컴퓨팅 머신 세트를 생성했습니다.

7.1. Windows Pod 배치

Windows 워크로드를 클러스터에 배포하기 전에 Pod가 올바르게 할당되도록 Windows 노드 스케줄링을 구성해야 합니다. Windows 노드를 호스팅하는 머신이 있으므로 Linux 기반 노드와 동일하게 관리됩니다. 유사하게, 테인트, 허용 오차, 노드 선택기와 같은 방법을 사용하여 적절한 Windows 노드에 Windows Pod도 예약되어야 합니다.

여러 운영 체제가 있고 동일한 클러스터에서 여러 Windows OS 변형을 실행할 수 있는 경우 RuntimeClass 오브젝트를 사용하여 Windows Pod를 기본 Windows OS 변형에 매핑해야 합니다. 예를 들어, 다른 Windows Server 컨테이너 버전에서 여러 Windows 노드가 있는 경우 클러스터는 호환되지 않는 Windows OS 변형에 Windows Pod를 예약할 수 있습니다. 클러스터의 각 Windows OS 변형에 대해 RuntimeClass 오브젝트가 구성되어 있어야 합니다. 클러스터에서 사용 가능한 Windows OS 변형만 있는 경우에는 RuntimeClass 오브젝트를 사용하는 것이 좋습니다.

자세한 내용은 호스트 및 컨테이너 버전 호환성에 대한 Microsoft 문서를 참조하십시오.

또한 워크로드 Pod에서 spec.os.name.windows 매개변수를 설정하는 것이 좋습니다. WMCO(Windows Machine Config Operator)는 이 필드를 사용하여 검증을 위해 Pod 운영 체제를 신뢰할 수 있으며 Windows별 SCC(보안 컨텍스트 제약 조건)를 적용하는 데 사용됩니다. 현재 이 매개변수는 Pod 예약에 영향을 미치지 않습니다. 이 매개변수에 대한 자세한 내용은 Kubernetes Pod 설명서 를 참조하십시오.

중요

컨테이너 기본 이미지는 격리자를 예약할 노드에서 실행 중인 동일한 Windows OS 버전 및 빌드 번호여야 합니다.

또한 Windows 노드를 한 버전에서 다른 버전으로 업그레이드하는 경우(예: 20H2에서 2022로 이동) 새 버전과 일치하도록 컨테이너 기본 이미지를 업그레이드해야 합니다. 자세한 내용은 Windows 컨테이너 버전 호환성을 참조하십시오.

추가 리소스

7.2. 스케줄링 메커니즘을 캡슐화하기 위해 RuntimeClass 오브젝트 생성

RuntimeClass 오브젝트를 사용하면 테인트 및 허용 오차와 같은 스케줄링 방식을 편리하게 사용할 수 있습니다. 사용자는 테인트 및 허용 오차를 캡슐화는 런타임 클래스를 배포한 후 이를 Pod에 적용하여 적절한 노드에 예약할 수 있습니다. 여러 운영 체제 변형을 지원하는 클러스터에도 런타임 클래스를 생성해야 합니다.

절차

  1. RuntimeClass 오브젝트 YAML 파일을 생성합니다. 예를 들어, runtime-class.yaml은 다음과 같습니다.

    Copy to Clipboard Toggle word wrap 
    apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: windows2019
    1 
    
handler: 'runhcs-wcow-process'
scheduling:
  nodeSelector:
    2 
    
    kubernetes.io/os: 'windows'
    kubernetes.io/arch: 'amd64'
    node.kubernetes.io/windows-build: '10.0.17763'
  tolerations:
    3 
    
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "windows"
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "Windows"
    1
    RuntimeClass 오브젝트 이름을 지정하며, 이는 이 런타임 클래스로 관리할 Pod에 정의됩니다.
    2
    이 런타임 클래스를 지원하는 노드에 존재해야 하는 레이블을 지정합니다. 이 런타임 클래스를 사용하는 Pod는 이 선택기와 일치하는 노드에만 예약할 수 있습니다. 런타임 클래스의 노드 선택기는 Pod의 기존 노드 선택기와 병합됩니다. 충돌이 발생하면 Pod를 노드에 예약할 수 없습니다.
    • Windows 2019의 경우 node.kubernetes.io/windows-build: '10.0.17763' 라벨을 지정합니다.
    • Windows 2022의 경우 node.kubernetes.io/windows-build: '10.0.20348' 라벨을 지정합니다.
    3
    허용 중에 이 런타임 클래스와 함께 실행 중인 pod(중복 제외)에 추가하려면 허용 오차를 지정합니다. 이 작업을 수행하면 Pod 및 런타임 클래스에서 허용되는 노드 집합이 결합됩니다.

  2. RuntimeClass 오브젝트를 생성합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc create -f <file-name>.yaml

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

    Copy to Clipboard Toggle word wrap 
    $ oc create -f runtime-class.yaml

  3. Pod에 RuntimeClass 오브젝트를 적용하여 적절한 운영 체제 변형에 예약되어 있는지 확인합니다.

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: Pod
metadata:
  name: my-windows-pod
spec:
  runtimeClassName: windows2019
    1 
    
# ...
    1
    Pod 예약을 관리할 런타임 클래스를 지정합니다.

7.3. 샘플 Windows 컨테이너 워크로드 배포

Windows 컴퓨팅 노드를 사용 가능한 경우 Windows 컨테이너 워크로드를 클러스터에 배포할 수 있습니다.

참고

이 샘플 배포는 참조용으로만 제공됩니다.

예시 Service 오브젝트

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: Service
metadata:
  name: win-webserver
  labels:
    app: win-webserver
spec:
  ports:
    # the port that this service should serve on
  - port: 80
    targetPort: 80
  selector:
    app: win-webserver
  type: LoadBalancer

예시 Deployment 오브젝트

Copy to Clipboard Toggle word wrap 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver
  name: win-webserver
spec:
  selector:
    matchLabels:
      app: win-webserver
  replicas: 1
  template:
    metadata:
      labels:
        app: win-webserver
      name: win-webserver
    spec:
      containers:
      - name: windowswebserver
        image: mcr.microsoft.com/windows/servercore:ltsc2019
1 

        imagePullPolicy: IfNotPresent
        command:
        - powershell.exe
2 

        - -command
        - $listener = New-Object System.Net.HttpListener; $listener.Prefixes.Add('http://*:80/'); $listener.Start();Write-Host('Listening at http://*:80/'); while ($listener.IsListening) { $context = $listener.GetContext(); $response = $context.Response; $content='<html><body><H1>Red Hat OpenShift + Windows Container Workloads</H1></body></html>'; $buffer = [System.Text.Encoding]::UTF8.GetBytes($content); $response.ContentLength64 = $buffer.Length; $response.OutputStream.Write($buffer, 0, $buffer.Length); $response.Close(); };
        securityContext:
          runAsNonRoot: false
          windowsOptions:
            runAsUserName: "ContainerAdministrator"
      os:
        name: "windows"
      runtimeClassName: windows2019
3

1
사용할 컨테이너 이미지를 지정합니다. mcr.microsoft.com/powershell:<tag > 또는 mcr.microsoft.com/windows/servercore:<tag > . 컨테이너 이미지는 노드에서 실행되는 Windows 버전과 일치해야 합니다.
  • Windows 2019의 경우 ltsc2019 태그를 사용합니다.
  • Windows 2022의 경우 ltsc2022 태그를 사용합니다.
2
컨테이너에서 실행할 명령을 지정합니다.
  • mcr.microsoft.com/powershell:<tag > 컨테이너 이미지의 경우 이 명령을 pwsh.exe 로 정의해야 합니다.
  • mcr.microsoft.com/windows/servercore:<tag > 컨테이너 이미지의 경우 이 명령을 powershell.exe 로 정의해야 합니다.
3
클러스터의 Windows 운영 체제 변형에 대해 생성한 런타임 클래스를 지정합니다.

7.4. Windows CSI 드라이버 지원

Windows Containers 용 Red Hat OpenShift 지원은 클러스터의 모든 Windows 노드에 CSI Proxy 를 설치합니다. CSI 프록시는 CSI 드라이버가 노드에서 스토리지 작업을 수행할 수 있는 플러그인입니다.

Windows 워크로드와 함께 영구 스토리지를 사용하려면 스토리지 공급자의 설명서에 설명된 대로 특정 Windows CSI 드라이버 데몬 세트를 배포해야 합니다. 기본적으로 WMCO는 Windows CSI 드라이버 데몬 세트를 자동으로 생성하지 않습니다. Kubernetes CSI 개발자 문서의 프로덕션 드라이버 목록을 참조하십시오.

참고

Red Hat은 Kubernetes CSI 개발자 설명서에 나열된 타사 프로덕션 드라이버를 지원하지 않습니다.

7.5. 컴퓨팅 머신 세트 수동 스케일링

컴퓨팅 머신 세트에서 머신 인스턴스를 추가하거나 제거하려면 컴퓨팅 머신 세트를 수동으로 스케일링할 수 있습니다.

이는 완전히 자동화된 설치 프로그램에 의해 프로비저닝된 인프라 설치와 관련이 있습니다. 사용자 지정 사용자 프로비저닝 인프라 설치에는 컴퓨팅 머신 세트가 없습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터 및 oc 명령행을 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

프로세스

  1. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 머신 세트를 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machinesets.machine.openshift.io -n openshift-machine-api

    컴퓨팅 머신 세트는 <clusterid>-worker-<aws-region-az> 형식으로 나열됩니다.

  2. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 시스템을 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machines.machine.openshift.io -n openshift-machine-api

  3. 다음 명령을 실행하여 삭제할 컴퓨팅 머신에 주석을 설정합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc annotate machines.machine.openshift.io/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"

  4. 다음 명령 중 하나를 실행하여 컴퓨팅 머신 세트를 확장합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc scale --replicas=2 machinesets.machine.openshift.io <machineset> -n openshift-machine-api

    또는 다음을 수행합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc edit machinesets.machine.openshift.io <machineset> -n openshift-machine-api
    작은 정보

    다음 YAML을 적용하여 컴퓨팅 머신 세트를 확장할 수 있습니다.

    Copy to Clipboard Toggle word wrap 
    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2

    컴퓨팅 머신 세트를 확장 또는 축소할 수 있습니다. 새 머신을 사용할 수 있을 때 까지 몇 분 정도 소요됩니다.

    중요

    기본적으로 머신 컨트롤러는 성공할 때까지 머신이 지원하는 노드를 드레이닝하려고 합니다. Pod 중단 예산을 잘못 구성하는 등 일부 상황에서는 드레이닝 작업이 성공하지 못할 수 있습니다. 드레이닝 작업이 실패하면 머신 컨트롤러에서 머신 제거를 진행할 수 없습니다.

    특정 머신에서 machine.openshift.io/exclude-node-draining 에 주석을 달아 노드 드레이닝을 건너뛸 수 있습니다.

검증

  • 다음 명령을 실행하여 의도한 시스템의 삭제를 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machines.machine.openshift.io

8장. Windows 노드 업그레이드

WMCO(Windows Machine Config Operator)를 업그레이드하여 Windows 노드에 최신 업데이트가 있는지 확인할 수 있습니다.

8.1. Windows Machine Config Operator 업그레이드

현재 클러스터 버전과 호환되는 새로운 버전의 WMCO(Windows Machine Config Operator)가 릴리스되면 Operator는 OLM(Operator Lifecycle Manager)을 사용할 때 함께 설치된 업그레이드 채널과 서브스크립션 승인 전략을 기반으로 업그레이드됩니다. WMCO 업그레이드로 인해 Windows 머신의 Kubernetes 구성 요소가 업그레이드됩니다.

참고

새로운 버전의 WMCO로 업그레이드하고 클러스터 모니터링을 사용하려면 WMCO 네임스페이스에 openshift.io/cluster-monitoring=true 레이블이 지정되어야 합니다. 기존 WMCO 네임스페이스에 레이블을 추가하고 이미 Windows 노드가 구성된 경우 WMCO Pod를 다시 시작하여 그래프 모니터링을 허용합니다.

장치를 중단할 필요가 없는 업그레이드의 경우 WMCO는 이전 버전의 WMCO에 의해 구성된 Windows 머신을 종료하고 현재 버전을 사용하여 이를 다시 생성합니다. 이는 머신 오브젝트를 삭제하여 수행되며, 이로 인해 Windows 노드가 드레이닝 및 삭제됩니다. 편리한 업그레이드를 위해, WMCO는 모든 구성된 노드에 버전 주석을 추가합니다. 업그레이드 중에 버전 주석이 일치하지 않으면 Windows 머신이 삭제되고 다시 생성됩니다. 업그레이드하는 동안 서비스 중단을 최소화하기 위해 WMCO는 한 번에 하나의 Windows 머신만 업데이트합니다.

업데이트 후 워크로드 Pod에서 spec.os.name.windows 매개변수를 설정하는 것이 좋습니다. WMCO는 이 필드를 사용하여 검증을 위해 Pod 운영 체제를 신뢰할 수 있으며 Windows별 SCC(보안 컨텍스트 제약 조건)를 적용하는 데 사용됩니다.

중요

WMCO는 Windows 운영 체제 업데이트가 아닌 Kubernetes 구성 요소를 업데이트해야 합니다. VM을 생성할 때 Windows 이미지를 제공하므로 업데이트된 이미지를 제공해야 합니다. MachineSet 사양에서 이미지 구성을 변경하여 업데이트된 Windows 이미지를 제공할 수 있습니다.

OLM(Operator Lifecycle Manager)을 사용한 Operator 업그레이드에 대한 자세한 내용은 설치된 Operator 업데이트를 참조하십시오.

9장. BYOH (Bring-Your-Own-Host) Windows 인스턴스를 노드로 사용

BYOH (Bring-Your-Own-Host) 를 사용하면 Windows Server VM의 용도를 변경하여 OpenShift Container Platform에 가져올 수 있습니다. BYOH Windows 인스턴스는 Windows 서버가 오프라인 상태가 되는 경우 주요 중단을 완화하려는 사용자에게 유용합니다.

9.1. BYOH Windows 인스턴스 구성

BYOH Windows 인스턴스를 생성하려면 WMCO(Windows Machine Config Operator) 네임스페이스에 구성 맵을 생성해야 합니다.

사전 요구 사항

노드에 따라 클러스터에 연결할 Windows 인스턴스는 다음 요구사항을 충족해야 합니다.

  • 인스턴스는 클러스터의 Linux 작업자 노드와 동일한 네트워크에 있어야 합니다.
  • 포트 22가 열려 있어야 하며 SSH 서버를 실행 중이어야 합니다.
  • SSH 서버의 기본 쉘은 Windows 명령 쉘 또는 cmd.exe여야 합니다.
  • 로그 수집을 위해 포트 10250이 열려 있어야 합니다.
  • 관리자는 인증된 SSH 키로 설정된 시크릿에 사용되는 개인 키가 있습니다.
  • 설치 관리자 프로비저닝 인프라(IPI) AWS 클러스터에 대한 BYOH Windows 인스턴스를 생성하는 경우 작업자 노드에 대한 컴퓨팅 머신 세트의 spec.template.spec.value.tag 값과 일치하는 AWS 인스턴스에 태그를 추가해야 합니다. 예: kubernetes.io/cluster/<cluster_id>: owned 또는 kubernetes.io/cluster/<cluster_id>: shared.
  • vSphere에서 BYOH Windows 인스턴스를 생성하는 경우 내부 API 서버와의 통신을 활성화해야 합니다.

  • 인스턴스의 호스트 이름은 다음 표준을 포함하는 RFC 1123 DNS 레이블 요구 사항을 따라야 합니다.

    • 소문자 영숫자 또는 '-'만 포함합니다.
    • 영숫자 문자로 시작합니다.
    • 영숫자 문자로 끝납니다.
참고

WMCO에 의해 배포된 Windows 인스턴스는 컨테이너화된 컨테이너 런타임을 사용하여 구성됩니다. WMCO가 런타임을 설치하고 관리하므로 노드에 containerd를 수동으로 설치하지 않는 것이 좋습니다.

프로세스

  1. 추가할 Windows 인스턴스를 설명하는 WMCO 네임스페이스에 windows-instances라는 ConfigMap을 생성합니다.

    참고

    username=<username> 으로 포맷하는 동안 주소를 키로 사용하여 구성 맵의 데이터 섹션에서 각 항목을 포맷합니다.

    구성 맵 예

    Copy to Clipboard Toggle word wrap 
    kind: ConfigMap
apiVersion: v1
metadata:
  name: windows-instances
  namespace: openshift-windows-machine-config-operator
data:
  10.1.42.1: |-
    1 
    
    username=Administrator
    2 
    
  instance.example.com: |-
    username=core

    1
    WMCO가 DNS 이름 또는 IPv4 주소인 SSH를 통해 인스턴스에 연결하는 데 사용하는 주소입니다. 이 주소에 대한 DNS PTR 레코드가 있어야 합니다. 조직에서 DHCP를 사용하여 IP 주소를 할당하는 경우 BYOH 인스턴스가 포함된 DNS 이름을 사용하는 것이 좋습니다. 그러지 않으면 인스턴스에 새 IP 주소가 할당될 때마다 windows-instances ConfigMap을 업데이트해야 합니다.
    2
    사전 요구 사항에서 생성된 관리자의 이름입니다.

9.2. BYOH Windows 인스턴스 제거

구성 맵에서 인스턴스의 항목을 삭제하여 클러스터에 연결된 BYOH 인스턴스를 제거할 수 있습니다. 인스턴스를 삭제하면 해당 인스턴스가 클러스터에 추가되기 전의 상태로 되돌아갑니다. 이러한 인스턴스에 로그 및 컨테이너 런타임 아티팩트가 추가되지 않습니다.

인스턴스를 완전히 제거하려면 WMCO에 제공된 현재 개인 키로 액세스할 수 있어야 합니다. 예를 들어 이전 예제에서 10.1.42.1 인스턴스를 제거하려면 구성 맵이 다음으로 변경됩니다.

Copy to Clipboard Toggle word wrap 
kind: ConfigMap
apiVersion: v1
metadata:
  name: windows-instances
  namespace: openshift-windows-machine-config-operator
data:
  instance.example.com: |-
    username=core

windows-instances 삭제는 노드에 추가된 모든 Windows 인스턴스를 해체하라는 요청으로 간주됩니다.

10장. Windows 노드 제거

호스트 Windows 머신을 삭제하여 Windows 노드를 제거할 수 있습니다.

10.1. 특정 머신 삭제

특정 머신을 삭제할 수 있습니다.

중요

클러스터가 컨트롤 플레인 시스템 세트를 사용하지 않는 경우 컨트롤 플레인 시스템을 삭제하지 마십시오.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

프로세스

  1. 다음 명령을 실행하여 클러스터에 있는 머신을 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get machine -n openshift-machine-api

    명령 출력에는 <clusterid>-<role>-<cloud_region> 형식의 머신 목록이 포함되어 있습니다.

  2. 삭제할 머신을 확인합니다.

  3. 다음 명령을 실행하여 시스템을 삭제합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc delete machine <machine> -n openshift-machine-api
    중요

    기본적으로 머신 컨트롤러는 성공할 때까지 머신이 지원하는 노드를 드레이닝하려고 합니다. Pod 중단 예산을 잘못 구성하는 등 일부 상황에서는 드레이닝 작업이 성공하지 못할 수 있습니다. 드레이닝 작업이 실패하면 머신 컨트롤러에서 머신 제거를 진행할 수 없습니다.

    특정 머신에서 machine.openshift.io/exclude-node-draining 에 주석을 달아 노드 드레이닝을 건너뛸 수 있습니다.

    삭제한 머신이 머신 세트에 속하는 경우 지정된 복제본 수를 충족하기 위해 새 머신이 즉시 생성됩니다.

11장. Windows 컨테이너 워크로드 비활성화

WMCO(Windows Machine Config Operator)의 설치를 제거하고 WMCO를 설치할 때 기본적으로 추가된 네임스페이스를 삭제하여 Windows 컨테이너 워크로드를 실행하는 기능을 비활성화할 수 있습니다.

11.1. Windows Machine Config Operator 제거

클러스터에서 WMCO(Windows Machine Config Operator)의 설치를 제거할 수 있습니다.

사전 요구 사항

  • Windows 워크로드를 호스팅하는 Windows 머신 오브젝트를 삭제합니다.

절차

  1. Operators → OperatorHub 페이지에서 키워드로 필터링 상자를 사용하여 Red Hat Windows Machine Config Operator를 검색합니다.
  2. Red Hat Windows Machine Config Operator 타일을 클릭합니다. Operator 타일은 Operator가 설치되었음을 나타냅니다.
  3. Windows Machine Config Operator 설명자 페이지에서 제거를 클릭합니다.

11.2. Windows Machine Config Operator 네임스페이스 삭제

기본적으로 WMCO(Windows Machine Config Operator)에 대해 생성된 네임스페이스를 삭제할 수 있습니다.

사전 요구 사항

  • WMCO가 클러스터에서 제거됩니다.

절차

  1. openshift-windows-machine-config-operator 네임스페이스에서 생성된 모든 Windows 워크로드를 제거합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc delete --all pods --namespace=openshift-windows-machine-config-operator

  2. openshift-windows-machine-config-operator 네임스페이스의 모든 Pod가 삭제되거나 종료 상태를 보고하는지 확인합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc get pods --namespace openshift-windows-machine-config-operator

  3. openshift-windows-machine-config-operator 네임스페이스를 삭제합니다.

    Copy to Clipboard Toggle word wrap 
    $ oc delete namespace openshift-windows-machine-config-operator

추가 리소스

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat, Inc.