OpenShift Virtualization은 컨테이너화되지 않은 애플리케이션을 위한 훌륭한 솔루션을 제공하지만, 레거시 가상화 제품 및 베어메탈 시스템과 비교하면 몇 가지 문제가 있습니다. 이러한 과제 중 하나는 가상 머신(VM)과의 상호작용과 관련이 있습니다. OpenShift는 일반적으로 애플리케이션을 구성하고 관리하기 위한 수신 연결, 최소한 VM에서 관리 또는 사용에 필요로 하는 연결과 동일한 유형이 필요 없는 컨테이너화된 애플리케이션을 위해 설계되었습니다.
이 블로그에서는 OpenShift Virtualization 환경에서 실행되는 VM에 액세스하는 몇 가지 방법을 설명합니다. 다음은 이러한 방법을 간략하게 요약한 것입니다.
OpenShift 사용자 인터페이스(UI)
UI를 통한 VNC 연결은 VM의 콘솔에 대한 직접적인 액세스를 제공하며 OpenShift Virtualization에서 제공합니다. Red Hat에서 제공하는 이미지를 사용하는 경우 UI를 통한 직렬연결에 구성이 필요하지 않습니다. 이러한 연결 방법은 VM 관련 문제를 해결하는 데 유용합니다.
virtctl 명령
virtctl
명령은 WebSocket을 사용하여 VM에 연결합니다. VNC 콘솔, 직렬 콘솔 및 VM에 대한 SSH 액세스를 제공합니다. VNC 콘솔 액세스 및 직렬 콘솔 액세스는 UI에서와 같이 OpenShift Virtualization에서 제공합니다. VNC 콘솔에 액세스하려면 클라이언트에서virtctl
명령을 실행하는 VNC 클라이언트가 필요합니다. 직렬 콘솔 액세스에는 UI를 통한 직렬 콘솔 액세스와 동일한 VM 구성이 필요합니다. SSH 액세스를 사용하려면 VM의 OS를 SSH 액세스용으로 구성해야 합니다. SSH 요구 사항은 VM의 이미지 설명서를 참조하십시오.포드 네트워크
서비스를 사용하여 포트를 노출하면 VM에 대한 네트워크 연결이 허용됩니다. VM의 모든 포트는 서비스를 사용하여 노출할 수 있습니다. 공통 포트는 22(ssh), 5900+(VNC), 3389(RDP)입니다. 이 블로그에서는 세 가지 유형의 서비스를 소개합니다.
ClusterIP
ClusterIP 서비스는 클러스터에 내부적으로 VM의 포트를 노출합니다. 이렇게 하면 VM이 서로 통신할 수 있지만 클러스터 외부에서의 연결은 허용되지 않습니다.
NodePort
NodePort 서비스는 클러스터 노드를 통해 클러스터 외부에 VM의 포트를 노출합니다. VM의 포트는 노드의 포트에 매핑됩니다. 노드의 포트는 일반적으로 VM의 포트와 동일하지 않습니다. VM은 노드 IP 및 적절한 포트 번호에 연결하여 액세스합니다.
LB(LoadBalancer)
LB 서비스는 VM에서 사용할 IP 주소 풀을 제공합니다. 이 서비스 유형은 VM의 포트를 클러스터 외부에 노출합니다. 얻거나 지정된 IP 주소 풀은 VM에 연결하는 데 사용됩니다.
계층 2 인터페이스
클러스터 노드의 네트워크 인터페이스는 VM에 대한 L2 연결을 허용하는 브리지로 구성할 수 있습니다. VM의 인터페이스는 NetworkAttachmentDefinition을 사용하여 브리지에 연결합니다. 그러면 클러스터의 네트워크 스택을 무시하고 VM의 인터페이스를 브리지된 네트워크에 직접 노출합니다. 클러스터의 네트워크 스택을 우회하여 클러스터의 기본 제공 보안도 우회합니다. VM은 네트워크에 연결된 물리 서버와 동일하게 보호되어야 합니다.
클러스터에 대한 간략한 소개
이 블로그에서 사용하는 클러스터는 wd 라고 하며 example.org 도메인에 있습니다. 이는 3개의 베어메탈 컨트롤 플레인 노드(wcp-0, wcp-1, wcp-2)와 3개의 베어메탈 작업자 노드(wwk-0, wwk-1, wwk-2)로 구성됩니다. 이러한 노드는 클러스터의 기본 네트워크인 10.19.3.0/24에 있습니다.
노드 | 역할 | IP | FQDN |
---|---|---|---|
wcp-0 | 컨트롤 플레인 | 10.19.3.95 | wcp-0.wd.example.org |
wcp-1 | 컨트롤 플레인 | 10.19.3.94 | wcp-1.wd.example.org |
wcp-2 | 컨트롤 플레인 | 10.19.3.93 | wcp-2.wd.example.org |
wwk-0 | 작업자 | 10.19.3.92 | wwk-0.wd.example.org |
wwk-1 | 작업자 | 10.19.3.91 | wwk-1.wd.example.org |
wwk-2 | 작업자 | 10.19.3.90 | wwk-2.wd.example.org |
MetalLB는 이 네트워크에서 VM에 4개의 IP 주소(10.19.3.112~115)를 제공하도록 구성됩니다.
클러스터 노드의 10.19.136.0/24 네트워크에는 보조 네트워크 인터페이스가 있습니다. 이 보조 네트워크에는 IP 주소를 제공하는 DHCP 서버가 있습니다.
클러스터에는 다음과 같은 오퍼레이터가 설치되어 있습니다. 모든 오퍼레이터는 Red Hat, Inc.에서 제공합니다.
오퍼레이터 | 이 오퍼레이터가 설치된 이유 |
---|---|
쿠버네티스 NMState 오퍼레이터 | 노드에서 두 번째 인터페이스를 구성하는 데 사용됨 |
OpenShift Virtualization | VM을 실행하는 메커니즘 제공 |
로컬 스토리지 | 로컬 HDD를 사용할 때 OpenShift Data Foundation 오퍼레이터에 필요 |
MetalLB 오퍼레이터 | 이 블로그에서 사용하는 LoadBalancing 서비스를 제공 |
OpenShift Data Foundation | 클러스터에 스토리지를 제공합니다. 스토리지는 노드에서 두 번째 HDD를 사용하여 생성됩니다. |
클러스터에서 실행 중인 VM이 몇 개 있습니다. VM은 블로그 네임스페이스에서 실행됩니다.
- Fedora로 불리는 Fedora 38 VM
- rhel9로 불리는 Red Hat Enterprise Linux 9(RHEL9) VM
- win11으로 불리는 Windows 11 VM
UI를 통해 연결
UI를 통해 VM을 조회할 때 다양한 탭이 표시됩니다. 모두 VM과 관련된 다양한 측면을 보거나 구성하는 메서드를 제공합니다. 특히 하나의 탭은 Console (콘솔) 탭입니다. 이 탭에서는 VNC 콘솔, 직렬 콘솔 또는 RDP(데스크탑 뷰어)의 세 가지 VM 연결 방법을 제공합니다. RDP 방법은 Microsoft Windows를 실행하는 VM에 대해서만 표시됩니다.
VNC 콘솔
VNC 콘솔은 모든 VM에서 항상 사용할 수 있습니다. VNC 서비스는 OpenShift Virtualization에서 제공하며 VM 운영 체제(OS)를 구성할 필요 없이 바로 사용 가능합니다.

직렬 콘솔
직렬 콘솔을 사용하려면 VM의 OS 내에서 구성해야 합니다. OS가 VM의 직렬 포트로 출력되도록 구성되지 않은 경우 이 연결 방법은 작동하지 않습니다. Red Hat에서 제공하는 VM 이미지는 부팅 정보를 직렬 포트로 출력하고 VM이 부팅 프로세스를 완료하면 로그인 프롬프트를 제공하도록 구성됩니다.

데스크탑 뷰어
이 연결을 사용하려면 VM에 원격 데스크톱(Remote Desktop, RDP) 서비스가 설치되어 실행 중이어야 합니다. Console(콘솔) 탭에서 RDP를 사용하여 연결하도록 선택하면 시스템에서 현재 VM에 대한 RDP 서비스가 없다고 표시하고 새로 생성하는 옵션을 제공합니다. 이 옵션을 선택하면 RDP 서비스 노출(Expose RDP Service) 확인란이 있는 팝업 창이 생성됩니다. 이 확인란을 선택하면 RDP 연결을 허용하는 VM에 대한 서비스가 생성됩니다.

서비스가 생성되면 Console(콘솔) 탭에 RDP 연결에 대한 정보가 표시됩니다.

Launch Remote Desktop(원격 데스크탑 시작) 버튼도 표시됩니다. 이 버튼을 선택하면 console.rdp라는 파일이 다운로드됩니다. 브라우저가 .rdp
파일을 열도록 구성된 경우 RDP 클라이언트에서 console.rdp 파일이 열립니다.
virtctl 명령을 사용하여 연결
virtctl
명령은 WebSocket 프로토콜을 통해 네트워크 터널을 사용하여 VM에 대한 VNC, 직렬 콘솔 및 SSH 액세스를 제공합니다.
-
virtctl
명령을 실행하는 사용자는 커맨드라인에서 클러스터에 로그인해야 합니다. - 사용자가 VM과 동일한 네임스페이스에 있지 않은 경우
--namespace
옵션을 지정해야 합니다.
virtctl
및 기타 클라이언트의 올바른 버전은 https://console-openshift-console.apps.CLUSTERNAME.CLUSTERDOMAIN/command-line-tools와 유사한 URL에서 클러스터에서 다운로드할 수 있습니다. UI 상단에 있는 물음표 아이콘을 클릭하고 Command line tools(커맨드라인 툴)를 선택하여 다운로드할 수도 있습니다.
VNC 콘솔
virtctl
명령은 OpenShift Virtualization에서 제공하는 VNC 서버에 연결합니다. virtctl
명령을 실행하는 시스템에는 virtctl
명령과 VNC 클라이언트가 설치되어 있어야 합니다.
VNC 연결을 열려면 virtctl vnc
명령을 실행하면 됩니다. 연결에 대한 정보가 터미널에 표시되고 새 VNC 콘솔 세션이 표시됩니다.

직렬 콘솔
virtctl
명령을 사용하여 직렬 콘솔에 연결하려면 virtctl console
을 실행합니다. 앞에서 설명한 대로 VM이 직렬 포트로 출력되도록 구성된 경우 부팅 프로세스 또는 로그인 프롬프트의 출력이 표시되어야 합니다.
$ virtctl console rhel9
Successfully connected to rhel9 console. The escape sequence is ^]
[ 8.463919] cloud-init[1145]: Cloud-init v. 22.1-7.el9_1 running 'modules:config' at Wed, 05 Apr 2023 19:05:38 +0000. Up 8.41 seconds.
[ OK ] Finished Apply the settings specified in cloud-config.
Starting Execute cloud user/final scripts...
[ 8.898813] cloud-init[1228]: Cloud-init v. 22.1-7.el9_1 running 'modules:final' at Wed, 05 Apr 2023 19:05:38 +0000. Up 8.82 seconds.
[ 8.960342] cloud-init[1228]: Cloud-init v. 22.1-7.el9_1 finished at Wed, 05 Apr 2023 19:05:38 +0000. Datasource DataSourceNoCloud [seed=/dev/vdb][dsmode=net]. Up 8.95 seconds
[ OK ] Finished Execute cloud user/final scripts.
[ OK ] Reached target Cloud-init target.
[ OK ] Finished Crash recovery kernel arming.
Red Hat Enterprise Linux 9.1 (Plow)
Kernel 5.14.0-162.18.1.el9_1.x86_64 on an x86_64
Activate the web console with: systemctl enable --now cockpit.socket
rhel9 login: cloud-user
Password:
Last login: Wed Apr 5 15:05:15 on ttyS0
[cloud-user@rhel9 ~]$
SSH
ssh 클라이언트는 virtctl ssh
명령을 사용하여 호출합니다. 이 명령에 -i
옵션을 사용하면 사용자가 사용할 개인 키를 지정할 수 있습니다.
$ virtctl ssh cloud-user@rhel9-one -i ~/.ssh/id_rsa_cloud-user
Last login: Wed May 3 16:06:41 2023
[cloud-user@rhel9-one ~]$
VM에 파일을 전송하는 데 사용할 수 있는 virtctl scp
명령도 있습니다. 여기서 이 명령을 언급하는 이유는 virtctl ssh
명령과 유사하게 작동하기 때문입니다.
포트 전달
virtctl
명령은 사용자의 로컬 포트에서 VM의 포트로 트래픽을 전달할 수도 있습니다. 이 명령의 작동 방식에 대한 자세한 내용은 OpenShift 설명서 를 참조하세요.
한 가지 용도는 virtctl
명령의 빌트인 ssh 클라이언트를 사용하는 대신 더 강력한 로컬 OpenSSH 클라이언트를 VM에 전달하는 것입니다. 이 작업에 대한 예는 Kubevirt 설명서 를 참조하세요.
또 다른 용도는 OpenShift 서비스를 생성하여 포트를 노출하는 것을 원치 않는 경우 VM의 서비스에 연결하는 것입니다.
예를 들어, 저한테 NGINX 웹 서버가 설치된 fedora-proxy 라는 VM이 있습니다. VM의 사용자 정의 스크립트는 process-status.out이라는 파일에 일부 통계를 작성합니다. 파일 내용에 관심이 있는 사람은 저뿐이지만 하루 종일 이 파일을 보려고 합니다. virtctl port-forward
명령을 사용하여 노트북 또는 데스크탑의 로컬 포트를 VM의 포트 80으로 전달할 수 있습니다. 필요할 때마다 데이터를 수집할 수 있는 짧은 스크립트를 작성할 수 있습니다.
#! /bin/bash
# Create a tunnel
virtctl port-forward vm/fedora-proxy 22080:80 &
# Need to give a little time for the tunnel to come up
sleep 1
# Get the data
curl http://localhost:22080/process-status.out
# Stop the tunnel
pkill -P $$
스크립트를 실행하면 원하는 데이터를 가져와서 자동으로 정리합니다.
$ gather_stats.sh
{"component":"","level":"info","msg":"forwarding tcp 127.0.0.1:22080 to 80","pos":"portforwarder.go:23","timestamp":"2023-05-04T14:27:54.670662Z"}
{"component":"","level":"info","msg":"opening new tcp tunnel to 80","pos":"tcp.go:34","timestamp":"2023-05-04T14:27:55.659832Z"}
{"component":"","level":"info","msg":"handling tcp connection for 22080","pos":"tcp.go:47","timestamp":"2023-05-04T14:27:55.689706Z"}
Test Process One Status: Bad
Test Process One Misses: 125
Test Process Two Status: Good
Test Process Two Misses: 23
포드 네트워크에서 노출된 포트를 통해 연결(서비스)
서비스
OpenShift의 서비스는 수신 트래픽에 대해 VM의 포트를 노출하는 데 사용됩니다. 이 수신 트래픽은 소스가 다른 VM 및 포드일 수도 있고 클러스터 외부에 있을 수도 있습니다.
이 블로그에서는 세 가지 유형의 서비스(ClusterIP, NodePort, LoadBalancer)를 생성하는 방법을 보여줍니다. ClusterIP 서비스 유형은 VM에 대한 외부 액세스를 허용하지 않습니다. 세 가지 유형 모두 VM과 포드 간에 내부 액세스를 제공합니다. 이는 클러스터 내의 VM이 서로 통신하는 데 사용되는 기본 방법입니다. 다음 표에는 세 가지 서비스 유형과 액세스 가능 범위가 나열되어 있습니다.
글꼴 | 클러스터 내부 DNS의 내부 범위 | 외부 범위 |
---|---|---|
ClusterIP | <service-name>.<namespace>.svc.cluster.local | 없음 |
NodePort | <service-name>.<namespace>.svc.cluster.local | 클러스터 노드의 IP 주소 |
LoadBalancer | <service-name>.<namespace>.svc.cluster.local | LoadBalancers IPAddressPools의 외부 IP 주소 |
서비스는 virtctl expose
명령을 사용하거나 YAML에서 정의하여 생성할 수 있습니다. YAML을 사용하여 서비스를 생성하는 작업은 커맨드라인 또는 UI에서 수행할 수 있습니다.
먼저 Virtctl 명령을 사용하여 서비스를 정의해 보겠습니다.
virtctl 명령을 사용한 서비스 생성
virtctl
명령을 사용하는 경우 사용자가 클러스터에 로그인해야 합니다. 사용자가 VM과 동일한 네임스페이스에 있지 않은 경우 --namespace
옵션을 사용하여 VM이 있는 네임스페이스를 지정할 수 있습니다.
virtctl expose vm
명령은 VM의 포트를 노출하는 데 사용할 수 있는 서비스를 생성합니다. 다음은 서비스를 생성할 때 virtctl expose
명령과 함께 사용되는 일반적인 옵션입니다.
--name | 생성할 서비스의 이름입니다. |
--type | 생성할 서비스 유형(ClusterIP, NodePort, LoadBalancer)을 지정하는 옵션입니다. |
--port | 서비스가 트래픽에 대해 수신하는 포트 번호입니다. |
--target-port | 선택 사항입니다. 노출할 VM의 포트입니다. 지정하지 않으면 --port와 동일합니다. |
--protocol | 선택 사항입니다. 서비스에서 수신해야 하는 프로토콜입니다. 기본값은 TCP입니다. |
다음 명령은 RHEL9라는 VM에 대한 ssh 액세스를 위한 서비스를 생성합니다.
$ virtctl expose vm rhel9 --name rhel9-ssh --type NodePort --port 22
서비스를 보고 클러스터 외부에서 VM에 액세스하는 데 사용할 포트를 결정합니다.
$ oc get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rhel9-ssh NodePort 172.30.244.228 <none> 22:32317/TCP 3s
지금은 포트를 삭제하겠습니다.
$ oc delete service rhel9-ssh
service "rhel9-ssh" deleted
YAML을 사용한 서비스 생성
YAML을 사용하여 서비스를 생성하는 작업은 oc create -f
명령을 사용하거나 UI의 편집기를 사용하여 커맨드라인에서 수행할 수 있습니다. 두 방법 모두 유효하며, 각각 장점이 있습니다. 커맨드라인은 스크립팅이 더 쉽지만 UI는 서비스를 정의하는 데 사용되는 스키마에 대한 도움말을 제공합니다.
먼저 두 방법 모두에 대해 동일한 YAML 파일에 대해 알아보겠습니다.
단일 서비스 정의는 단일 포트 또는 여러 포트를 노출할 수 있습니다. 아래 YAML 파일은 ssh 트래픽과 VNC 트래픽에 각각 하나씩 두 개의 포트를 노출하는 서비스 정의의 예입니다. 포트는 NodePort로 노출됩니다. 주요 항목에 대한 설명은 YAML 뒤에 나열됩니다.
apiVersion: v1
kind: Service
metadata:
name: rhel-services
namespace: blog
spec:
ports:
- name: ssh
protocol: TCP
nodePort: 31798
port: 22000
targetPort: 22
- name: vnc
protocol: TCP
nodePort: 31799
port: 22900
targetPort: 5900
type: NodePort
selector:
kubevirt.io/domain: rhel9
다음은 파일에서 주의해야 할 몇 가지 설정입니다.
metadata.name | 서비스의 이름으로, 네임스페이스 내에서 고유합니다. |
metadata.namespace | 서비스가 있는 네임스페이스입니다. |
spec.ports.name | 정의할 포트의 이름입니다. |
spec.ports.protocol | 네트워크 트래픽의 프로토콜로, TCP 또는 UDP입니다. |
spec.ports.nodePort | 클러스터 외부에 노출되는 포트입니다. 클러스터 내에서 고유합니다. |
spec.ports.port | 클러스터 네트워크 내에서 내부적으로 사용되는 포트입니다. |
spec.ports.targetPort | VM에서 노출하는 포트입니다. 여러 VM에서 동일한 포트를 노출할 수 있습니다. |
spec.type | 생성할 서비스 유형입니다. 여기서는 NodePort를 사용합니다. |
spec.selector | 서비스를 VM에 바인딩하는 데 사용되는 선택기입니다. 예시는 fedora라는 VM에 바인딩합니다. |
커맨드라인에서 서비스 생성
커맨드라인에서 YAML 파일에 두 개의 서비스를 생성해 보겠습니다. 사용할 명령은 oc create -f
입니다.
$ oc create -f service-two.yaml
service/rhel-services created
$ oc get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rhel-services NodePort 172.30.11.97 <none> 22000:31798/TCP,22900:31799/TCP 4s
두 개의 포트가 단일 서비스에 노출되어 있음을 확인할 수 있습니다. 이제 oc delete service
명령을 사용하여 서비스를 제거해 보겠습니다.
$ oc delete service rhel-services
service "rhel-services" deleted
UI에서 서비스 생성
UI를 사용하여 동일한 서비스를 생성해 보겠습니다. UI를 사용하여 서비스를 생성하려면 Networking(네트워킹) -> Services(서비스)로 이동한 다음 Create Service(서비스 생성)를 선택합니다. 서비스 정의와 스키마에 대한 참조가 미리 입력되어 있는 편집기가 열립니다. 위의 YAML을 편집기에 붙여넣고 Create(생성)을 선택하여 서비스를 생성합니다.

Create(생성)를 선택하면 서비스의 세부 정보가 표시됩니다.

VM에 연결된 서비스는 VM Details(VM 세부 정보) 탭에서 또는 앞에서와 같이 oc get service
명령을 사용하여 커맨드라인에서 볼 수도 있습니다. 앞에서 한 것과 마찬가지로 서비스를 제거하겠습니다.
$ oc get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rhel-services NodePort 172.30.11.97 <none> 22000:31798/TCP,22900:31799/TCP 4s
$ oc delete service rhel-services
service "rhel-services" deleted
SSH 및 RDP 서비스를 쉽게 생성하는 방법
UI는 VM에서 SSH 및 RDP 서비스를 생성하는 간단한 포인트 앤 클릭 방법을 제공합니다.
VM의 Details(세부 정보) 탭에는 SSH service type(SSH 서비스 유형)이라는 드롭다운이 있어 SSH를 쉽게 활성화할 수 있습니다. 드롭다운에서는 NodePort 또는 LoadBalancer 서비스도 쉽게 생성할 수 있습니다.

서비스 유형을 선택하면 서비스가 생성됩니다. UI에 서비스 및 서비스에서 생성한 서비스에 연결하는 데 사용할 수 있는 명령이 표시됩니다.

VM의 Console(콘솔) 탭을 통해 RDP를 활성화합니다. VM이 Windows 기반 VM인 경우 콘솔 드롭다운에서 Desktop viewer(데스크탑 뷰어)가 옵션이 됩니다.

선택하면 Create RDP Service(RDP 서비스 생성) 옵션이 표시됩니다.

옵션을 선택하면 Expose RDP Service(RDP 서비스 노출)에 대한 팝업이 제공됩니다.

서비스가 생성되면 Console(콘솔) 탭에 연결 정보가 표시됩니다.

ClusterIP 서비스를 사용한 연결의 예
ClusterIP 유형의 서비스를 사용하면 VM이 클러스터 내부에서 서로 연결할 수 있습니다. 이는 하나의 VM이 데이터베이스 인스턴스와 같은 다른 VM에 서비스를 제공하는 경우에 유용합니다. VM에서 데이터베이스를 구성하는 대신 ClusterIP를 사용하여 Fedora VM에서 SSH를 노출해 보겠습니다.
Fedora VM의 SSH 포트를 클러스터에 내부적으로 노출하는 서비스를 생성하는 YAML 파일을 생성해 보겠습니다.
apiVersion: v1
kind: Service
metadata:
name: fedora-internal-ssh
namespace: blog
spec:
ports:
- protocol: TCP
port: 22
selector:
kubevirt.io/domain: fedora
type: ClusterIP
구성을 적용해 보겠습니다.
$ oc create -f service-fedora-ssh-clusterip.yaml
service/fedora-internal-ssh created
$ oc get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
fedora-internal-ssh ClusterIP 172.30.202.64 <none> 22/TCP 7s
RHEL9 VM을 사용하면 SSH를 사용하여 Fedora VM에 연결할 수 있습니다.
$ virtctl console rhel9
Successfully connected to rhel9 console. The escape sequence is ^]
rhel9 login: cloud-user
Password:
Last login: Wed May 10 10:20:23 on ttyS0
[cloud-user@rhel9 ~]$ ssh fedora@fedora-internal-ssh.blog.svc.cluster.local
The authenticity of host 'fedora-internal-ssh.blog.svc.cluster.local (172.30.202.64)' can't be established.
ED25519 key fingerprint is SHA256:ianF/CVuQ4kxg6kYyS0ITGqGfh6Vik5ikoqhCPrIlqM.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'fedora-internal-ssh.blog.svc.cluster.local' (ED25519) to the list of known hosts.
Last login: Wed May 10 14:25:15 2023
[fedora@fedora ~]$
NodePort 서비스를 사용한 연결의 예
이 예제에서는 Console(콘솔) 탭을 사용하는 것보다 더 나은 경험을 위해 데스크탑에 연결할 수 있도록 NodePort를 사용하여 windows11 VM에서 RDP를 노출해 보갰습니다. 이 연결은 신뢰할 수 있는 사용자가 클러스터 노드의 IP를 알고 있기 때문에 사용할 수 있습니다.
OVNKubernetes에 대한 참고 사항
최신 버전의 OpenShift 설치 프로그램은 기본적으로 OVNKubernetes 네트워크 스택을 사용합니다. 클러스터에서 OVNKubernetes 네트워크 스택을 실행 중이고 NodePort 서비스를 사용하는 경우 VM의 송신 트래픽은 routingViaHost 가 활성화될 때까지 작동하지 않습니다.
클러스터에 대한 간단한 패치는 NodePort 서비스를 사용할 때 송신 트래픽을 활성화합니다.
$ oc patch network.operator cluster -p '{"spec": {"defaultNetwork": {"ovnKubernetesConfig": {"gatewayConfig": {"routingViaHost": true}}}}}' --type merge
$ oc get network.operator cluster -o yaml
apiVersion: operator.openshift.io/v1
kind: Network
spec:
defaultNetwork:
ovnKubernetesConfig:
gatewayConfig:
routingViaHost: true
...
클러스터에서 OpenShiftSDN 네트워크 스택을 사용하거나 MetalLB 서비스를 사용하는 경우에는 이 패치가 필요하지 않습니다.
NodePort 서비스를 사용한 연결의 예
먼저 YAML 파일에 정의하여 NodePort 서비스를 생성해 보겠습니다.
apiVersion: v1
kind: Service
metadata:
name: win11-rdp-np
namespace: blog
spec:
ports:
- name: rdp
protocol: TCP
nodePort: 32389
port: 22389
targetPort: 3389
type: NodePort
selector:
kubevirt.io/domain: windows11
서비스를 생성합니다.
$ oc create -f service-windows11-rdp-nodeport.yaml
service/win11-rdp-np created
$ oc get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
win11-rdp-np NodePort 172.30.245.211 <none> 22389:32389/TCP 5s
NodePort 서비스이므로 모든 노드의 IP를 사용하여 연결할 수 있습니다. oc get nodes
명령은 노드의 IP 주소를 표시합니다.
$ oc get nodes -o=custom-columns=Name:.metadata.name,IP:status.addresses[0].address
Name IP
wcp-0 10.19.3.95
wcp-1 10.19.3.94
wcp-2 10.19.3.93
wwk-0 10.19.3.92
wwk-1 10.19.3.91
wwk-2 10.19.3.90
xfreerdp
프로그램은 RDP 연결에 사용할 수 있는 하나의 클라이언트 프로그램입니다. 클러스터에 노출된 RDP 포트를 사용하여 wcp-0 노드에 연결하도록 지시하겠습니다.
$ xfreerdp /v:10.19.3.95:32389 /u:cnvuser /p:hiddenpass
[14:32:43:813] [19743:19744] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0
[14:32:43:813] [19743:19744] [WARN][com.freerdp.crypto] - CN = DESKTOP-FCUALC4
[14:32:44:118] [19743:19744] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32
[14:32:44:118] [19743:19744] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[14:32:44:130] [19743:19744] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[14:32:44:130] [19743:19744] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
[14:32:45:209] [19743:19744] [WARN][com.freerdp.core.rdp] - pduType PDU_TYPE_DATA not properly parsed, 562 bytes remaining unhandled. Skipping.
VM에 연결되었습니다.

LoadBalancer 서비스를 사용한 연결의 예
먼저 YAML 파일에서 정의하여 LoadBalancer 서비스를 생성해 보겠습니다. Windows VM을 사용하고 RDP를 노출합니다.
apiVersion: v1
kind: Service
metadata:
name: win11-rdp-lb
namespace: blog
spec:
ports:
- name: rdp
protocol: TCP
port: 3389
targetPort: 3389
type: LoadBalancer
selector:
kubevirt.io/domain: windows11
서비스를 생성합니다. 자동으로 IP를 가져오는 것을 확인할 수 있습니다.
$ oc create -f service-windows11-rdp-loadbalancer.yaml
service/win11-rdp-lb created
$ oc get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
win11-rdp-lb LoadBalancer 172.30.125.205 10.19.3.112 3389:31258/TCP 3s
서비스에서 EXTERNAL-IP 에 연결하고 서비스를 사용하여 노출한 3389의 표준 RDP 포트에 연결되어 있음을 확인할 수 있습니다. xfreerdp
명령의 출력에 연결에 성공했음이 표시됩니다.
$ xfreerdp /v:10.19.3.112 /u:cnvuser /p:changeme
[15:51:21:333] [25201:25202] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0
[15:51:21:333] [25201:25202] [WARN][com.freerdp.crypto] - CN = DESKTOP-FCUALC4
[15:51:23:739] [25201:25202] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32
[15:51:23:739] [25201:25202] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[15:51:23:752] [25201:25202] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[15:51:23:752] [25201:25202] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
[15:51:24:922] [25201:25202] [WARN][com.freerdp.core.rdp] - pduType PDU_TYPE_DATA not properly parsed, 562 bytes remaining unhandled. Skipping.
위와 동일한 스크린샷이므로 스크린샷을 첨부하지 않습니다.
계층 2 인터페이스를 사용한 연결
VM의 인터페이스를 내부적으로 사용하고 공개적으로 노출할 필요가 없는 경우 NetworkAttachmentDefinition을 사용하고 노드에서 브리지된 인터페이스를 사용하여 연결하는 것이 좋습니다. 이 방법은 클러스터 네트워크 스택을 우회합니다. 즉, 클러스터 네트워크 스택에서 각 데이터 패킷을 처리할 필요가 없으므로 네트워크 트래픽의 성능이 향상될 수 있습니다.
이 방법에는 몇 가지 단점이 있습니다. VM이 네트워크에 직접 노출되며 클러스터 보안으로 보호되지 않습니다. VM이 손상되면 침입자가 VM이 연결된 네트워크에 액세스할 수 있습니다. 이 방법을 사용하는 경우 VM의 운영 체제 내에서 적절한 보안을 제공하도록 주의해야 합니다.
NMState
Red Hat에서 제공하는 NMState 오퍼레이터는 클러스터가 배포된 후 노드에서 물리적 인터페이스를 구성하는 데 사용할 수 있습니다. 브리지, VLAN, 본드 등 다양한 구성을 적용할 수 있습니다. 이를 사용하여 클러스터의 각 노드에서 사용하지 않는 인터페이스에 브리지를 구성합니다. NMState 오퍼레이터 사용에 대한 자세한 내용은 OpenShift 설명서 를 참조하세요.
노드의 사용되지 않는 인터페이스에 간단한 브리지를 구성해 보겠습니다. 인터페이스는 DHCP를 제공하고 10.19.142.0 네트워크에서 주소를 전달하는 네트워크에 연결됩니다. 다음 YAML은 ens5f1 네트워크 인터페이스에 brint 라는 브리지를 생성합니다.
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: brint-ens5f1
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
desiredState:
interfaces:
- name: brint
description: Internal Network Bridge
type: linux-bridge
state: up
ipv4:
enabled: false
bridge:
options:
stp:
enabled: false
port:
- name: ens5f1
YAML 파일을 적용하여 작업자 노드에 브리지를 생성합니다.
$ oc create -f brint.yaml
nodenetworkconfigurationpolicy.nmstate.io/brint-ens5f1 created
oc get nncp
명령을 사용하여 NodeNetworkConfigurationPolicy의 상태를 확인합니다. oc get nnce
명령을 사용하여 개별 노드 구성의 상태를 확인합니다. 구성이 적용되면 두 명령의 STATUS에 Available 이 표시되고, REASON에 SuccessfullyConfigured가 표시됩니다.
$ oc get nncp
NAME STATUS REASON
brint-ens5f1 Progressing ConfigurationProgressing
$ oc get nnce
NAME STATUS REASON
wwk-0.brint-ens5f1 Pending MaxUnavailableLimitReached
wwk-1.brint-ens5f1 Available SuccessfullyConfigured
wwk-2.brint-ens5f1 Progressing ConfigurationProgressing
NetworkAttachmentDefinition
VM은 생성한 브리지에 직접 연결할 수 없지만 NetworkAttachmentDefinition(NAD)에는 연결할 수 있습니다. 다음은 노드에서 생성된 brint 브리지에 연결되는 nad-brint 라는 NAD를 생성합니다. NAD를 생성하는 방법에 대한 설명은 OpenShift 설명서 를 참조하세요.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: nad-brint
annotations:
k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/brint
spec:
config: '{
"cniVersion": "0.3.1",
"name": "nad-brint",
"type": "cnv-bridge",
"bridge": "brint",
"macspoofchk": true
}'
YAML을 적용한 후에는 oc get network-attachment-definition
명령을 사용하여 NAD를 볼 수 있습니다.
$ oc create -f brint-nad.yaml
networkattachmentdefinition.k8s.cni.cncf.io/nad-brint created
$ oc get network-attachment-definition
NAME AGE
nad-brint 19s
Networking -> NetworkAttachmentDefinitions로 이동하여 UI에서 NAD를 생성할 수도 있습니다.
계층 2 인터페이스를 사용한 연결의 예
생성된 NAD를 사용하여 네트워크 인터페이스를 VM에 추가하거나 기존 인터페이스를 수정하여 이를 사용하도록 할 수 있습니다. VM의 세부 정보로 이동하고 Network interface(네트워크 인터페이스) 탭을 선택하여 새 인터페이스를 추가하겠습니다. Add network interface(네트워크 인터페이스 추가)옵션을 선택합니다. 기존 인터페이스는 옆에 있는 케밥 메뉴를 선택하여 수정할 수 있습니다.

VM을 다시 시작하면 VM 세부 정보의 Overview(개요) 탭에 DHCP에서 수신한 IP 주소가 표시됩니다.

이제 브리지된 인터페이스의 DHCP 서버에서 획득한 IP 주소를 사용하여 VM에 연결할 수 있습니다.
$ ssh cloud-user@10.19.142.213 -i ~/.ssh/id_rsa_cloud-user
The authenticity of host '10.19.142.213 (10.19.142.213)' can't be established.
ECDSA key fingerprint is SHA256:0YNVhGjHmqOTL02mURjleMtk9lW5cfviJ3ubTc5j0Dg.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.19.142.213' (ECDSA) to the list of known hosts.
Last login: Wed May 17 11:12:37 2023
[cloud-user@rhel9 ~]$
SSH 트래픽은 VM에서 브리지를 통해 물리 네트워크 인터페이스로 전달됩니다. 트래픽이 포드 네트워크를 우회하고 브리지된 인터페이스가 상주하는 네트워크에 있는 것으로 표시됩니다. 이 방식으로 연결된 경우 VM은 방화벽으로 보호되지 않으며 ssh 및 VNC에 사용되는 포트를 포함하여 VM의 모든 포트에 액세스할 수 있습니다.
결론
OpenShift Virtualization 내에서 실행되는 VM에 연결하는 다양한 방법을 살펴보았습니다. 이러한 방법은 제대로 작동하지 않는 VM의 문제를 해결하고 일상적인 사용을 위해 VM에 연결하는 방법을 제공합니다. VM은 클러스터 내에서 로컬로 서로 상호작용할 수 있습니다. 또는 클러스터 외부의 시스템은 직접 또는 클러스터 포드 네트워크를 사용하여 VM에 액세스할 수 있습니다. 이는 다른 플랫폼의 물리 시스템과 VM을 OpenShift Virtualization으로 이전하는 데 유용합니다.
저자 소개
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.