OpenShift 仮想化: コンテナ、KVM、仮想マシン

OpenShift 仮想化 (アップストリーム プロジェクト - Kubernetes: KubeVirt を参照)。 ここで и ここで（旧称：コンテナネイティブ仮想化）は、Kubernetesの中核となるエンティティとして仮想マシン（VM）をデプロイおよび管理するために設計されたOpenShiftプラットフォームの機能として導入されました。この種のタスクは、技術的な根本的な違いから技術的に困難です。この目標を達成するために、Red Hat Enterpriseをベースにした使い慣れたテクノロジーが使用されました。 Linux そしてKVMは、長年にわたり当社で使用されており、その有効性が実証されています。

この記事では、VM とコンテナを単一のエンティティとして管理する単一のプラットフォーム内で共存させることを可能にする OpenShift 仮想化の技術的側面について説明します。

計算タスク

コンテナはメカニズムを使用する Linux- プロセス分離とリソース管理のための名前空間やcgroupなどのコア機能。プロセスは通常、PythonやJavaのアプリケーションまたは実行ファイルとして考えられますが、実際には、bash、Emacs、vimなど、あらゆるプロセスが対象となります。

仮想マシンとは何ですか?ハイパーバイザーの観点からは、これもプロセスです。ただし、アプリケーション プロセスではなく、特定の VM の実行を担当する KVM プロセスです。

コンテナー イメージには、KVM 仮想マシンに必要なすべてのツール、ライブラリ、およびファイルが含まれています。実行中の VM のポッドを検査すると、ヘルパーと qemu-kvm プロセスがあることがわかります。さらに、qemu-img、qemu-nbd、virsh などの仮想マシンを管理するための KVM ツールにもアクセスできます。

仮想マシンはポッドであるため、Kubernetes のポッドのすべての機能を自動的に継承します。 VM ポッドは、通常のポッドと同様に、スケジューラ スキームと、テイント、許容、アフィニティ、アンチアフィニティなどの基準の影響を受けます。高可用性などのメリットも得られます。ただし、重要な違いが 1 つあります。それは、通常のポッドは通常の意味でホストからホストへ移行しないということです。ノードがオフラインになると、そのノード上のポッドは終了され、クラスター内の別のノードに再割り当てされます。また、仮想マシンの場合は、ライブ マイグレーションが行われることが予想されます。

このギャップに対処するために、ワーカー ノード間の VM のライブ マイグレーションの初期化、監視、管理を担当するライブ マイグレーション メカニズムを記述するカスタム リソース定義 (CDR) が作成されました。

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

ノードが非アクティブ化されると、エビクション戦略としてライブ マイグレーションが設定されている仮想マシンに対して移行タスクが自動的に作成されます。このようにして、クラスター ノード間を移動するときの仮想マシンの動作を制御できます。他のすべてのポッドと同様に、ライブ マイグレーションの構成と VM の管理の両方を行うことができます。

Сеть

すべての Kubernetes システムは、ソフトウェア SDN ネットワークを使用してノードとポッド間の通信を提供します。 OpenShift も例外ではなく、バージョン 3 以降では、デフォルトで OpenShiftSDN を使用します。さらに、OpenShift 4 には Multus と呼ばれる別の新機能があり、複数のネットワークを利用可能にし、それらのネットワークにポッドを同時に接続できます。

Multusを使用すると、管理者は追加のCNIネットワークを定義でき、それらは専用のクラスタネットワークオペレータを使用してクラスタにデプロイおよび構成されます。Podは、これらのネットワークの1つ以上（通常は標準のOpenShiftSDNと追加のインターフェイス）に接続されます。SR-IOVデバイス、標準 Linux VMの必要に応じて、ブリッジ、MACVLAN、およびIPVLANデバイスをすべて使用できます。下の図は、eth1インターフェイス上のブリッジネットワーク用にMultus CNIを設定する方法を示しています。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
   { "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
   type: Raw

OpenShift 仮想化に関連して、これは VM が SDN をバイパスして外部ネットワークに直接接続できることを意味します。これは、Red Hat Virtualization または VMware vSphere から OpenShift に移行された仮想マシンにとって重要です。2 番目の OSI レイヤーにアクセスできる場合、ネットワーク設定は変更されないためです。これは、VM が SDN をバイパスするネットワーク アドレスを持つ可能性があることも意味します。したがって、特殊なネットワーク アダプタを効果的に使用したり、ネットワーク経由でストレージ システムに直接接続したりできます。

OpenShift 仮想化仮想マシンを作成してネットワークに接続する方法について詳しく学ぶことができます。 ここで。 加えて、 nmstate 演算子は、OpenShift 仮想化の一部としてデプロイされ、ハイパーバイザーの下で使用される物理ノード上でネットワーク構成を作成および管理するためのもう 1 つの使い慣れた方法を提供します。

ストレージ

OpenShift 仮想化内での仮想マシン ディスクの接続と管理は、StorageClasses、Persistent VolumeClaims (PVC)、Persistent Volume (PV) などの Kubernetes の概念と、Kubernetes 環境の標準ストレージ プロトコルを使用して実行されます。これにより、Kubernetes 管理者とアプリケーション チームは、コンテナと仮想マシンの両方を管理する共通の使い慣れた方法を利用できるようになります。また、仮想化環境の多くの管理者にとって、この概念は、OpenStack や他の多くのクラウド プラットフォームで使用されている VM 構成ファイルとディスクを分離するという同じ原理を使用しているため、見慣れたものに聞こえるかもしれません。

ただし、ハイパーバイザーから OpenShift に移行するときにデータを保存する必要があるため、毎回 VM 用に新しいディスクを単純に作成することはできません。はい、新しい VM をデプロイする場合でも、最初から作成するよりもテンプレートから実行する方が常に高速です。したがって、既存のディスクをインポートする機能が必要です。

このタスクを簡素化するために、OpenShift 仮想化では Containerized Data Importer (CDI) プロジェクトをデプロイします。これにより、複数のソースからのディスクのディスク イメージのインポートが PVC エントリの作成までに減ります。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "fedora-disk0"
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
  storageClassName: ocs-gold
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

CDI をアクティブにするのはこのエントリであり、次の図に示す一連のアクションをトリガーします。

CDI が完了すると、PVC には、すぐに使用できる仮想マシン ディスクが含まれ、標準の OpenShift 形式に変換されます。
OpenShift 仮想化を使用する場合、コンテナ用の永続ストレージ機能を実装する Ceph ファイル システムに基づく Red Hat ソリューションである OpenShift Container Storage (OCS) も役立ちます。標準の PVC アクセス方式である RWO (ブロック) および RWX (ファイル) に加えて、OCS は raw ブロック デバイス用の RWX を提供します。これは、高パフォーマンス要件を持つアプリケーションのブロック アクセスを共有するのに非常に役立ちます。さらに、OCS は、アプリケーションがオブジェクト データ ストレージを直接使用できるようにする新しい Object Bucket Claim 標準をサポートしています。

コンテナ内の仮想マシン

OpenShift 仮想化がどのように機能するかを確認したい場合は、OpenShift 仮想化が OpenShift 3.11 以降の一部として Tech Preview バージョンですでに利用可能であることを知っておいてください。既存の OpenShift サブスクリプションの所有者は、追加の手順を行わずに完全に無料で OpenShift 仮想化を使用できます。この投稿の公開時点では、OpenShift 4.4 および OpenShift 仮想化 2.3 が最新です。以前のバージョンを使用している場合は、アップグレードして最新の機能を入手する必要があります。 OpenShift 仮想化の完全にサポートされたバージョンは、2020 年後半にリリースされる予定です。

詳細については、お問い合わせください OpenShift ドキュメント インストール手順については、 Multusセットアップセクション、外部ネットワークの設定に関する情報を提供します。

出所： habr.com