Red Hat OpenShift Virtualization での VM への接続

OpenShift Virtualization はコンテナ化されていないアプリケーション向けの優れたソリューションですが、従来の仮想化製品やベアメタルシステムと比べていくつかの課題が生じることも事実です。仮想マシン (VM) との対話は、そうした課題の 1 つです。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 アクセスには、SSH でアクセスできるように VM の OS を設定する必要があります。SSH の要件については、VM のイメージのドキュメントを参照してください。

• Pod ネットワーク

  サービスを使用してポートを公開することで、VM へのネットワーク接続が許可されます。VM のポートは、サービスを使用して公開できます。一般的なポートは、22 (ssh)、5900+ (VNC)、3389 (RDP) などです。このブログ記事では、3 種類のサービスについて説明します。

  • ClusterIP

    ClusterIP サービスは、VM のポートをクラスタ内部に公開します。これにより、VM は相互に通信できますが、クラスタ外部からの接続は許可されません。

  • NodePort

    NodePort サービスは、クラスタノードを介してクラスタ外部に VM のポートを公開します。VM のポートは、ノードのポートにマッピングされます。通常、ノード上のポートは VM 上のポートと同じではありません。VM にアクセスするには、ノードの IP と適切なポート番号に接続します。

  • LoadBalancer (LB)

    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 上にあります。

MetalLB は、このネットワークから VM に 4 つの IP アドレス (10.19.3.112-115) を提供するように設定されています。

クラスタノードには、10.19.136.0/24 ネットワーク上にセカンダリー・ネットワーク・インタフェースがあります。このセカンダリーネットワークには、IP アドレスを提供する DHCP サーバーがあります。

クラスタには次の Operator がインストールされています。これらの Operator はすべて Red Hat, Inc. によって提供されています。

クラスタ上ではいくつかの VM が実行されています。これらの VM は、blog という名前空間で実行されます。

• Fedora 38 VM の「fedora」
• Red Hat Enterprise Linux 9 (RHEL9) VM の「rhel9」
• Windows 11 VM の「win11」

UI を介した接続

UI を使用して VM を表示すると、さまざまなタブが表示されます。そのすべてに、VM に関するさまざまな側面を表示し、設定するための手段があります。その中の 1 つが、 [Console] タブです。このタブでは、VM に接続するための 3 つの方法として、VNC コンソール、シリアルコンソール、デスクトップビューアー (RDP) が提供されます。RDP 方式は、Microsoft Windows を実行している VM の場合にのみ表示されます。

VNC コンソール

VNC コンソールは、どの VM についても常に使用できます。VNC サービスは OpenShift Virtualization によって提供され、VM のオペレーティングシステム (OS) の設定を必要とせず、この設定なしで利用できます。

シリアルコンソール

シリアルコンソールを使うには、VM の OS 内で設定が必要です。OS が VM のシリアルポートに出力するように設定されていない場合、この接続方法は機能しません。Red Hat が提供する VM イメージは、ブート情報をシリアルポートに出力するように設定され、VM のブートプロセスが完了するとログインプロンプトを表示します。 

デスクトップビューアー

この接続を行うには、VM にリモートデスクトップ (RDP) サービスがインストールされており、かつ実行されている必要があります。[Console] タブで RDP を使用した接続を選択すると、現在その VM 用の RDP サービスがないことが示され、サービスを作成するためのオプションが提供されます。このオプションを選択すると、[Expose RDP Service] チェックボックスを含むポップアップウィンドウが表示されます。このボックスをオンにするとその VM 用のサービスが作成され、RDP で接続できるようになります。

サービスが作成されると、[Console] タブに RDP 接続のための情報が表示されます。 

[Launch Remote Desktop] ボタンも表示されます。このボタンを選択すると、 console.rdp というファイルがダウンロードされます。 .rdp ファイルを開くように設定されている場合、ブラウザーは RDP クライアントで console.rdp ファイルを開きます。

virtctl コマンドを使用した接続

 virtctl コマンドは、WebSocket プロトコルのネットワークトンネルを使用して、VM への VNC、シリアルコンソール、SSH アクセスを提供します。

•  virtctl コマンドを実行するユーザーは、コマンドラインからクラスタにログインする必要があります。
• ユーザーが VM と同じ名前空間にいない場合、 --namespace オプションを指定する必要があります。

 virtctl およびその他のクライアントの適切なバージョンはクラスタからダウンロードできます。その際に使用する URL は、 https://console-openshift-console.apps.CLUSTERNAME.CLUSTERDOMAIN/command-line-tools のような形式になります。また、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 ~]$ 

また、 virtctl scp コマンドを使用すると、ファイルを VM に転送できます。ここであえて言及したのは、このコマンドは virtctl ssh コマンドと同じように機能するからです。

ポートフォワーディング

 virtctl コマンドは、ユーザーのローカルポートから VM のポートにトラフィックを転送することもできます。この仕組みの詳細については、OpenShift のドキュメントを参照してください。

この用途の 1 つは、ローカルの OpenSSH クライアントを VM に転送することです。 virtctl コマンドの組み込み ssh クライアントを使用するよりも堅牢です。この実行例については、Kubevirt のドキュメントを参照してください。

別の用途として、ポートを公開するために OpenShift サービスを作成したくない場合に、これを使用して VM 上のサービスに接続できます。

たとえば、 fedora-proxy という名前の VM があり、NGINX Web サーバーがインストールされているとします。VM のカスタムスクリプトによって、統計情報が process-status.out という名前のファイルに書き込まれます。ファイルの内容に関心があるのは私だけかもしれませんが、一日中このファイルを確認する必要があるとします。その場合、 virtctl port-forward コマンドを使用して、ノート PC またはデスクトップのローカルポートを 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

Pod ネットワークの公開ポートを介した接続 (サービス)

サービス

OpenShift のサービスは、受信トラフィック用に VM のポートを公開するために使用されます。この受信トラフィックは、他の VM や Pod から送信される場合もあれば、クラスタ外部のソースから送信される場合もあります。

このブログ記事では、ClusterIP、NodePort、LoadBalancer という 3 種類のサービスを作成する方法を紹介します。ClusterIP サービスタイプは、外部からの VM へのアクセスを許可しません。3 つのタイプのすべてが、VM と Pod 間の内部アクセスを提供します。これは、クラスタ内の VM が相互に通信するために推奨される方法です。次の表に、3 種類のサービスとそれらにより許可されるアクセスの範囲を示します。

サービスは、 virtctl expose コマンドを使用するか、YAML で定義することで作成できます。YAML を使用したサービス作成には、コマンドラインと UI のどちらも使用できます。

まず、Virtctl コマンドを使用してサービスを定義しましょう。

virtctl コマンドを使用したサービスの作成

 virtctl コマンドを使用する際には、そのユーザーがクラスタにログインしている必要があります。ユーザーが VM と同じ名前空間にいない場合、 --namespace オプションを使用して、VM が存在する名前空間を指定できます。

 virtctl expose vm コマンドは、VM のポートを公開するために使用できるサービスを作成します。以下は、サービスを作成するときに virtctl expose コマンドで使用される一般的なオプションです。

次のコマンドは、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 ファイルは、2 つのポート (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

このファイルの主な設定項目は次のとおりです。

コマンドラインからサービスを作成する

YAML ファイルの 2 つのサービスをコマンドラインから作成しましょう。使用するコマンドは 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

1 つのサービスで 2 つのポートが公開されていることがわかります。今度は 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] タブでも確認できるほか、これまでと同様に 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 を簡単に有効化できます。このドロップダウンでは、NodePort および LoadBalancer のいずれのサービスも簡単に作成できます。 

サービスタイプを選択すると、サービスが作成されます。UI に、サービスへの接続に使用できるコマンドと、このコマンドによって作成されたサービスが表示されます。 

RDP を有効にする操作は、VM の [Console] タブで行います。VM が Windows ベースの VM の場合、コンソール・ドロップダウンの選択肢に [Desktop viewer] が追加されます。 

選択すると、 [Create RDP Service] のオプションが表示されます。 

オプションを選択すると、 [Expose RDP Service] ポップアップが表示されます。 

サービスが作成されると、[Console] タブに接続情報が表示されます。 

ClusterIP サービスを使用した接続の例

ClusterIP タイプのサービスは、VM がクラスタ内部で相互に接続できるようにします。これは、データベースインスタンスなど、1 つの 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 サービスを使用した接続の例

この例では、NodePort を使用して windows11 VM から RDP を公開します。これにより、[Console] タブを使用するよりも簡単にこの VM のデスクトップに接続できます。この接続は、クラスタノードの IP を把握している信頼できるユーザー向けと言えます。

OVNKubernetes に関する注意事項

OpenShift インストーラーの最新バージョンは、デフォルトで OVNKubernetes ネットワークスタックを使用します。クラスタが OVNKubernetes ネットワークスタックを実行していて、NodePort サービスが使用されている場合、 routingViaHost が有効化されるまで、VM からの Egress トラフィックは機能しません。

クラスタにシンプルなパッチを適用することで、NodePort サービスを使用するときに Egress トラフィックが有効化されます。

$ 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 サービスを使用した接続の例

NodePort サービスを作成しましょう。まず、YAML ファイルでサービスを定義します。

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 接続に使用できるクライアントプログラムの 1 つです。このプログラムに、クラスタで公開されている 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 サービスを使用した接続の例

LoadBalancer サービスを作成しましょう。まず YAML ファイルでサービスを定義します。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 に接続していて、サービスを使用して公開した標準の RDP ポート 3389 が使用されていることが確認できます。 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 Operator を使用すると、クラスタをデプロイした後にノード上で物理インタフェースを設定できます。ブリッジ、VLAN、ボンドなど、さまざまな設定を適用できます。これを使用して、クラスタ内の各ノード上の未使用のインタフェースにブリッジを設定します。NMState Operator の使用方法の詳細は、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 nce コマンドを使用して、個々のノード設定の状態を表示します。設定が適用されると、両方のコマンドの 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) にアタッチすることはできます。以下では、nad-brint という NAD を作成し、ノード上に作成された brint ブリッジにアタッチします。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 を適用した後、NAD は oc get network-attachment-definition コマンドを使用して表示できます。

$ oc create -f brint-nad.yaml 
networkattachmentdefinition.k8s.cni.cncf.io/nad-brint created
      
$ oc get network-attachment-definition
NAME         AGE
nad-brint    19s

NAD は、UI から [Networking] -> [NetworkAttachmentDefinitions] に移動して作成することもできます。

レイヤー 2 インタフェースを使用した接続の例

NAD の作成後は、ネットワーク・インタフェースを VM に追加したり、既存のインタフェースを変更して使用したりすることができます。VM の詳細に移動して [Network interfaces] タブを選択すると、新しいインタフェースを追加できます。 [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 からブリッジを通過し、物理ネットワーク・インタフェースから外に転送されます。トラフィックは Pod ネットワークをバイパスし、ブリッジされたインタフェースが存在するネットワーク上にあるように見えます。この方法で接続されている場合、VM はどのファイアウォールでも保護されず、VM のポートは SSH と VNC に使用されるものを含めすべてアクセス可能です。

まとめ

OpenShift Virtualization 内で実行されている VM に接続するさまざまな方法を確認しました。これらの方法は、正常に動作していない VM のトラブルシューティングを行うためだけでなく、日常業務で VM に接続するための手段にもなります。VM はクラスタ内でローカルに相互に通信できます。また、クラスタの外部にあるシステムから直接、またはクラスタの Pod ネットワークを使用してアクセスできます。これは、物理システムや他のプラットフォーム上の VM を OpenShift Virtualization へと移行するのに役立ちます。