※本記事は OpenShift Virtualization アドベントカレンダーの 3日目の記事です。 qiita.com
はじめに
皆さんこんにちわ、Red Hat Global Learning ServicesでLearning Solution Architectを担当している坂井 大和(@lab8010)です。
主にX.com上でRed Hat製品やサービスについて配信をしているので、もしよければフォローくださると幸いです。
この記事では、『Red Hat OpenShift Virtualizationを使いこなせるエンジニアになる』ために何を学べば良いか、そしてそれにどれぐらいの時間がかかるかを解説します。
また、この記事は2025年10月に東京赤坂で実施された当社の年次イベントRed Hat Summit Connectにおける私の登壇セッションをカスタムした内容としてお届けします。
多くの方から『このセッションのWeb配信はないんですか？』『資料の配布はないのですか？』という嬉しいお声をいただきましたが、私のセッションはWeb配信対象ではなかったので、この記事を持って皆さまの要望にお応えしたいと思います。
※サミコネ担当の方、来年は...配信してくれると嬉しいです。配信を希望されるようなコンテンツ提供を頑張ります。
皆様のお越しをお待ちしております！
— Yamato@Red Hat/Learning Solution Architect (@lab8010) September 25, 2025
私はこちらのテーマで登壇させて頂きます。(残席数も後10席弱です、少しでもご興味のある方は早めのご登録をお勧めします！)
ご登録はこちらのリンクから！(要Red Hatアカウント登録)#RHSummitConnectTokyo#サミコネ東京 https://t.co/FDtVTgIlw4 https://t.co/7A5huwuAje pic.twitter.com/8sbAn1Vlrn
この記事のゴール
この記事を読み終わった頃には、読者様が次のことが出来る状態になって頂きたいと考えています。
- Red Hat OpenShift Virtualizationを管理運用するために必要な知識が必要かわかる
- 同製品の管理運用のために、どのような学習をすれば良いかがわかる
- 上記の学習が、概ねどの程度の時間がかかるのかを理解できる
それでは、早速本編に入っていきましょう。
Q. (おさらい)Red Hat OpenShift Virtualizationとは？
A. 次の記事を参照ください。
本赤帽ブログにて、前回私が投稿した記事にてまとめていますので、まだご覧いただいていない方はそちらを一度参照ください。
Q. 他社の仮想化製品経験があれば割とすぐ使えるものか？
A. アーキテクチャそのものが異なるため、これは少し難しいと思います。
この問は、おそらく多くのユーザーが持つメジャーな疑問です。
私自身、これまで次の製品と関わってきました。
- VMware vSphere (vSphere 4からvSphere 8まで、2009年から2024年頃まで)
- Microsoft Hyper-V (Windows Server 2008から2019頃まで)
特に、VMware vSphereとの付き合いは長く前職ではVMware認定インストラクターとして8年ほど活動していました。
ある年には、グローバルレベルで最高成績のインストラクターとしても表彰を受けました。
そのため、それなりにサーバ仮想化にはそれなりの自信がありました。
そんな私がRed Hat OpenShift Virtualizationと出会ったのは、Red Hatに入社して間も無い頃...『OpenShift Virtualizationできますか？』と日本のトレーニングチームのメンバーから言われ、『仮想化製品はそれなりにやってきたから余裕だろう』と思っていたのですが、根本的にアーキテクチャが異なるため、知れば知るほど既存の知識だけでは対応が難しいことに直ぐに気がつきました。
具体的に私が感じた技術的な差分は次の要素でした。
筆者が考える、他社仮想化製品の経験者が(OpenShift Virtualizationのために)身につけるべき要素
-
YAML(ヤムル)ファイルを用いた宣言型形式によるインフラの定義
-
OpenShiftやKubernetesにおける数々のリソース
-
ストレージとネットワークにおける追加学習
-
使い慣れた機能が同等の機能として存在するかの確認
-
OpenShift Virtualizationに向けた情報収集テクニック
これだけを見せられると『なんだか学習コストが高いんじゃないの？』という感想がすぐ浮かんでくると想像できます。
ここで最初に強調しておきたいのは『Red Hat OpenShiftはKubernetesをコアとする次世代のITインフラストラクチャクラスター*1』だということです。
Kubernetesは元来、大量のコンテナ群を商用基盤として実行できるように設計された機能です。
一方で従来の仮想化基盤ではVMware環境ならvCenter Server、Microsoft環境ならHyper-V マネージャー、Windows Admin Center、System Center Virtual Machine Managerなどを通じて管理をしてきました。
これらはいずれも『仮想マシンを中心とした管理機能を提供するソリューション』です。
そもそも管理対象自体がの想定が違うため、アーキテクチャも違い必要とされてきた機能も異なります。
これは、世の中にサーバ仮想化が登場したばかりの時期にも同じようなことが言えたでしょう。
『サーバを仮想化？物理ベースの方が慣れているし、アーキテクチャを変える必要があるの？』と。
時代は繰り返すとよくいったものですが、今私たちが直面しているアーキテクチャの刷新による再学習は、以前にも起きていたことであり、転換期にはほぼ必然的に起きるものです。
この転換期をRed Hatは公式トレーニングやコンサルティングサービス、TAMなどのサービスなどでお客様を支援しているわけです。
なお、本記事では特に公式トレーニングについて解説をしていきます。
さてここから先は、これらを1つ1つ要素分解しその知識の必要性と学習方法を紹介します。
1. YAML(ヤムル)ファイルを用いた宣言型形式によるインフラの定義
VMware vSphere Client、Microsoft Hyper-V マネージャー、Nutanix Prismなど、多くの仮想化製品では優れたGUIを通じて、最も簡単に仮想化基盤に対してスマートに操作を行うことができます。
先にお伝えすると、Red Hat OpenShift VirtualizationにもWeb UIは存在します。
以下の動画では、そのデモンストレーションの様子が伺えます。
GUIの変化は、これまで運用管理でそれらを多用してきた方からすれば大きなチャレンジになると言えます。
より使いやすくなるのであればWelcomeだと思いますが、そうでない場合は『前の方が良かった』と思う方が多数派となるでしょう。
実際の私の最初の感想としては、仮想マシンの台数の確認、それらのステータスの状態、どのホスト上にいるかなどを識別するのに数回のクリックを経てアクセスすることが多かったので、やや苦労したというのが正直な感想でした。
また、本題に入りますが『YAMLファイルを通じたインフラストラクチャの定義』がOpenShift(Kubernetes)では必要となります。
私自身のこれまでの経験上ではこのYAMLファイルを使用する画面がなかったため、OpenShiftがその初舞台となりました。
YAMLそのものはRed Hat固有のものではなく、様々なベンダーの製品にて使用される有名なデータフォーマットです。
OpenShiftをはじめとするKubernetes環境では、クラスターの制御層がこのファイルの中身で指定された状態を常に再現するように振る舞います。
例えば、上記の図の右側では『常に、nginxのイメージが実行されるコンテナを持つPodを3つ実行するように』努めます。
管理者は『こうあるべきである』という理想の状態をYAMLファイルに記述し、それをOpenShiftに提出(宣言)することでクラスター上に設定を施していくイメージです。
なお、Red Hat OpenShiftでは上述しているブラウザを使用するWeb UIを通じてGUIベースで上記相当の指示を出すことができるようにはなっています。
しかし、OpenShiftを使う以上はこのYAMLの記述を読んだり、編集したりする作業はどこかで行うことにはなるため、徐々に慣れていく必要があります。
YAMLの編集は何を使って行うの？
YAMLは一般的なテキストファイルであるため、特別なソフトウェアがなくともOS標準のテキストエディタがあれば開いたり、編集することは可能です。
しかし、効率よく作業を行いたい場合はVisual Studio Codeなどのアプリ開発者向けのエディターなどを使うことで、改行やインデント(スペースを行頭に用いて頭を揃えること)を行いやすくすることができます。
Red Hatでは、MicrosoftのVisual Studio Codeに対してYAMLファイルに向けた編集や読解がしやすくなるプラグインを提供しています。
YAMLは、Red Hatが提供するAnsibleと呼ばれる構成管理ソリューション(IaC/Infrastructure as Code)でも使用されます。
このように、YAMLはOpenShiftだけでなく他の製品でも使われることが多いので、一度覚えておくと応用できる場面も増えるので、覚えることをお勧めします。
2. OpenShiftやKubernetesにおける数々のリソース
リソースという単語は、それ自体が場面や文脈ごとに異なる意味を持ちます。
OpenShiftやKubernetesにおけるリソースは、次の図に掲載されたものを示します。
Kubernetesをコアとするコンテナオーケストレーション環境では、これらのリソースをうまく組み合わせることでコンテナや仮想マシンのためのインフラストラクチャを構成していきます。
サーバ仮想化系エンジニア向けの言い方をすると、次のようなものはKubernetesにおけるリソースとして登場します。
- 仮想マシン
- 仮想ハードディスク
- 仮想スイッチ
- 仮想スイッチのポートグループ
- 仮想マシンをまとめるリソースプール
- 管理画面にログインするためのユーザー
- そのユーザーを集約するグループ
- ユーザーに対して権限を割り当てるために作成するロール
そして、これらリソースの設定は全てYAML形式で取り扱われます。
再掲しますが、YAMLで記述してOpenShiftクラスターに設定をしても良いですし、OpenShiftが持つWeb UIから設定をしても良いです。
OpenShiftでサーバの仮想化をしたい場合は、どのようなリソースを覚えておく必要があるのか？
あらゆる構成を想定した記述はできないため、主要なものに限定して列挙します。
- 仮想マシンを実行するためのベースとなるVirtualMachine (カスタムリソース)
- Podをネットワークに繋ぐために使用するService(標準リソース)
- 上記サービスをクラスター外のネットワークに公開するRoute(カスタムリソース)
- Podに対し接続したストレージの要件を定義するPVC(標準リソース)
- 仮想ハードディスクのようにデータを保持するPV(標準リソース)
ここに列挙したものはほんのごく一部であり、これら以外のリソースも実際のインフラでは登場します。
なお、説明に含まれる標準リソースはKubernetesがデフォルトで持っている基本的なリソースであり、カスタムリソースはKubernetesが標準的に持っていない追加されたリソースです。RouteはRed Hatが独自に用意したリソースであり、VirtualMachineはKubeVirtと呼ばれるオープンソースプロジェクトが定義したリソースです。
3. ストレージとネットワークに対する追加学習
ITインフラストラクチャにおいて、ストレージとネットワークは非常に重要な要素であることはよく知られています。
特にサーバ仮想化インフラにおいて、ストレージと言えばFCやiSCSIなどを使用したブロックストレージやNFSなどをホストにマウントし、仮想マシンのデータを保存する仮想ハードディスク(VMware vSphereならvmdk/Microsoft Hyper-Vならvhdxなど)をその中に保存します。
ネットワークにおいては、各種ハイパーバイザーにおいてそれぞれで機能面が異なるものの仮想スイッチを用いて仮想マシンの通信を成立させます。
では、Red Hat OpenShift Virtualizationではここにどのような変化が起きるのか？
ストレージ - CSIを通じたストレージの活用とPVCとPVを通じた仮想ディスク
結論から申し上げると、Kubernetesをベースとする環境においても従来利用してきた物理的なストレージ製品などを使用することはできます。
この際、Kubernetesがこうしたストレージ製品と連携をするためにContainer Storage Interface(通称CSI)という仕組み活用する必要があります。
具体的には各ストレージソリューションベンダーは自社のストレージとKubernetes環境を接続するためのCSIドライバーと呼ばれるソフトウェアを提供しているため、それを入手、セットアップをする事でストレージ製品がKubernetes環境で活用可能となります。
この点については、別の記事にて触れていく予定です。
ネットワーク - Podネットワークを使うのか？それとも従来のようなネットワークを使うのか？
Kubernetesは、その発祥のきっかけとしてコンテナワークロードのためのオーケストレーションという歴史があります。
このため、Kubernetesが持つ標準的なネットワークの仕組みはコンテナに向けて用意されており、次のような特性があります。(これらの特性ともつネットワークををPodネットワークと呼ぶ)
- Podは原則1つのネットワークアダプタしか保有できない
- Pod*2は、動的にIPアドレスを受け取り、Podが再起動される度に変化する
- Podが固定的なアクセスポイントを得るためには、Serviceというリソースを構成し、それが持つ固定的なIPアドレスや名前にアクセスをさせるよう構成を組む
このように、Kubernetesにおけるネットワークの実装はサーバ仮想化の環境と比較するとかなり違いがあります。
また、ストレージにはCSIという考え方がありますがネットワークにはContainer Network Interface(通称CNI)が存在し、このCNIに対応するCNIプラグインと呼ばれるものの中からどれを使用するかで提供される機能が変わります。
ちなみにRed Hat OpenShift Virtualizationでは本記事投稿時点の最新版の4.20ではOVN-Kubernetesと呼ばれるCNIプラグインがデフォルトで使用されます。
上述のIPアドレスの動的な割り当てについても以下の記事内で言及があります。
- Creates pod networking including IP Address Management (IPAM) allocation and virtual ethernet (veth) interface for the pod.
さて、ここまでで話が終わると『現在のサーバ仮想化環境向けに構築したネットワーク構成を抜本的に変える必要があるのか？』という疑問が残ります。
これに関しては、実は手段があります。それが『Multus』と呼ばれるCNIプラグインを活用する手法です。
このMultusを使用することで、上記で紹介した以下の構造を変えます。
-
Podは原則1つのネットワークアダプタしか保有できない
端的にいえば、Podに対して2つ目以降の仮想ネットワーク*3アダプタを割り当て可能とし、その2つ目以降のネットワークは従来の仮想スイッチネットワークのようにVLANベースの通信に接続が可能となるという解決手法です。
このMultusは、特にサーバ仮想化だけに使える特別なものではなくコンテナベースのPod環境でも使用可能であり、すでにいくつもの優れたブログ記事も多数存在します。
結論としては、仮想マシンに対しては次のようなネットワーク構成が可能といえます。
- Podネットワークのみを使う
- PodネットワークとMultusにより実現された2つ目以降のネットワークの併用
- Multusにより実現された2つ目以降のネットワークのみの使用
- この構成の場合、以下のスライドの諸注意にあるように一部の機能が使用できなくなります
4. 使い慣れた機能が同等の機能として存在するかの確認
現在活用している仮想基盤で慣れ親しんできた機能がOpenShift Virtualizationにあるかどうか？これは新環境の採用を計画する際に非常に重要なポイントだといえます。
主に次のような機能については質問が多いように感じます。
- 仮想マシンを無停止で物理ホスト間で移行する機能
- 仮想マシンを無停止でストレージ間で移行する機能
- 仮想マシンが実行される物理ホストを、ルールを構成して制御する機能
- 仮想マシンへの通信について、許可拒否相当のポリシーを構成する機能
- 仮想マシンを実行するホストが障害などで停止時に、仮想マシンをフェイルオーバーする機能
ここに挙げられた機能は全てRed Hat OpenShift Virtualizationで利用可能です。
本記事掲載時点で、市場内でニーズが多いこともありVMware by BroadcomのvSphereの機能とOpenShift Virtualizationのどの機能が対応するかについては以下の資料で解説されています。
※これらの情報ソースは都度更新されていくため、詳細はリンク先でご確認ください。
OpenShift Virtualizationに向けた情報収集テクニック
これまで記事でお伝えしてきたように、OpenShift Virtualizationを支えるコアテクノロジーはコンテナオーケストレーションのためのKubernetesです。
下図で示すように、Kubernetesに対しRed Hatが特定の機能を追加し、さらにRed Hatの各種サービスを受けられるようにしたカスタムされたKubernetesがRed Hat OpenShiftです。
(Kubernetesは)オープンソースであり、かつ利用事例も多数あるため、非常に情報が豊富であることが強みです。
しかし、この情報の多さが時として落とし穴になるとも言えます。
インターネット上でKubernetesに関する文書や記事を探せば、多くの情報を得ることは可能です。しかし、これらの情報が必ずしもRed Hat OpenShiftにもマッチするとは言えないということです。いかにKubernetesがOpenShiftにとってのコアテクノロジーではあるとはいえ、Red Hat OpenShift向けに提供されている情報を参照することが望ましいです。
例えていうなら、RHEL上での特定の操作や機能について調べようと思った場合に、CentOS StreamやUbuntuなどの他のディストリビューションでの情報を用いて検索をすると、その検索結果がRHELにとって使えないかもしれない、というのに近いです。
さらに言えば、Kubernetesで提供される機能の一部は仮想マシンには適用できない可能性があることも抑えておきたいです。
Kubernetesの登場における歴史を考えると、Kubernetes＝コンテナのために登場したという背景があり、その機能は原則コンテナのために準備されたものであり、それらは仮想マシンでの利用を想定していないわけです。
例えば、vSphere FT*4のように仮想マシンを二重化して、片方の仮想マシンが停止をしてもシームレスにフェイルオーバーさせる構成を取りたい場合はコンテナベースのPodの場合はDeploymentと呼ばれるリソースがそれに近い*5と言えます。
では、もしvSphere FTと同じようなクラスタリングを構成したい場合はどうするかというと『仮想マシンの間でクラスタリングを構成』します。
Does OpenShift Virtualization support application clustering?
Yes, the Red Hat Enterprise Linux (RHEL) High-Availability Add-on (Pacemaker) and Windows Server Failover Clustering (WSFC) are supported.
引用元
一見この考え方は、『え、せっかくのハイパーバイザー環境なのに、それ自体の機能ではなく仮想マシンの中でクラスタリングを組むの？』と思われるかもしれませんが、vSphereの環境などでも同じアプローチはあります。
VMware vSphereへのWSFCの導入方法 - VMware by Broadcom
なお、RHELで仮想マシンを構成したい場合はHA Add-onを使用しますが、当社の社員により書かれた以下の記事でその詳細に解説がなされています。
本項目におけるポイントをまとめると次のようになります。
- Kubernetesのために書かれた資料は、Red Hat OpenShiftにも適用可能なものとそうでないものに分かれる
- Red Hat OpenShiftのために用意された機能や情報は、OpenShift Virtualizationによって稼働する仮想マシンには適用されないものも存在する
いかに情報が豊富にあるテクノロジーであるとはいえ、OpenShift Virtualizationで使用可能な技術やその情報は、適切に取得していく必要があるということです。
このことはRed Hatの公式ドキュメントを見てみればよくわかります。
こちらはRed Hat OpenShiftのためのドキュメントのトップページです。
こちらはRed Hat OpenShift Virtualizationのためのドキュメントのトップページです。
このようにページが分割されているため、適切に使い分けをするようにしましょう。
同じ名称、単語がついているからといって横着して検索精度を落とすような調べ方をすると後々痛い目を見ます。
あとがき
ここまで、数多くの視点から『従来のハイパーバイザー環境からRed Hat OpenShift Virtualizationへの転換』にはいくつもの新しい視点を身につける必要があることを解説しました。
さて、本記事のタイトルにもあるように数ヶ月で「OpenShift Virtualization Ready」とあるように、実際にはどれくらいの時間が必要かというのを試算したものがこちらです。
- 最短プランは1ヶ月以内コース (実質1-2週間程度)
- 標準的なプランは3ヶ月以内コース
最短プランは1ヶ月以内コース (実質1週間程度)
まず、最短プランについてはこちらをご覧いただきたいと思います。
公式トレーニングが準備されています
上記で挙げている3種類のトレーニングコースがこちらです。
まず最も最短と言える流れはDO156とDO256という2種類のトレーニングの受講です。
これはRed Hat OpenShift Virtualizationをこれから学ぶ方に向けて用意されたいわゆる基本コースであり、前半と後半のように分割されたものです。
Red Hatでは通常トレーニングクラスは原則1週間に1クラスの提供であるため、試算としては2週間といういう計算です。
一方でDO316というコースは、一見DO156とDO256を5日間(つまり約1週間)にまとめあげたコースに見えますが、実際の所やOpenShiftについて既に学習を終えている方を想定した作りとなっており、単純に2コースの合算コースとしてみるには少し厳しいところがあります。
また、DO156とDO256はOpenShiftについての基礎は含まれるかというと、これらについてもOpenShift Virtualizationを使用する上で最低限必要となる要素については触れる程度の感覚です。
もし将来的に仮想マシンだけではなく、コンテナベースでのワークロードの実行もOpenShift上で視野に入れたかったり、より一層Red Hat OpenShiftの多彩な機能の活用に興味を持っている場合は、更なるトレーニングコースの併用も視野に入れるべきです。それがこの後に続く標準的なプランです
標準的なプランは3ヶ月以内コース
Red Hat OpenShiftについてしっかりと基礎から学びたい場合はDO180とDO280という2種類の公式トレーニングで学ぶことができます。
OpenShiftについても学習ステップを前半と後半に分けているためのコース分割です
スライド内にも掲載していますが、Kubernetesの基礎スキルや知識を有した状態でこれらのコースを受講していただくことでより一層学習効果を高めることが期待できます。
理由としては、DO180もDO280もRed Hat OpenShiftが持つ固有の特性などの話もするため、時間の尺の都合上Kubernetesの基礎をゼロからお話しすると多少ビジーになるためです。
以下のように、無償で提供されるKubernetes入門コンテンツなども存在するため、もしRed Hat公式トレーニングをご受講いただく機会がある場合は、事前にこうしたコンテンツも併用活用されるとより一層学習効果を高めることが期待できます。
Linux Foundation、無料オンラインコース「Kubernetes入門」の提供を開始 - The Linux Foundation
そして、上記のDO180やDO280を受講し終えた後に最初に挙げたDO316を受講することで一旦はOpenShift Virtualizationに対しReadyと成れます。
さらに次の要素が必要な場合は追加のトレーニングコースも準備されています。
- Red Hat OpenShiftが持つSoftware Defined Storage機能を使用する*6場合はDO370
- Red Hat OpenShiftが持つより高度な機能を学びたい場合はDO380
このように、構成や要件によっては+αも生まれ、これらも加味すると追加の2週間が発生する試算となります。
ここまでを振り返ると次のような数字となります。
- DO180 4日間 - OpenShiftの基礎(運用編)
- DO280 4日間 - OpenShiftの基礎(構成編)
- DO316 5日間 - OpenShift Virtualizationの基礎
- DO370 5日間 - 外部ストレージを使用する場合は不要
- DO380 5日間 - 本コースで紹介する機能を使わない場合は不要
Red Hatが提供する各種トレーニングの日数の単純な合算で言えば23日間です。
ただし、実際の現場では23日間連続で受講対象者となる方を現場から抜けるかと言えばそれは難しく、これらの受講計画を仮に全て立てるとしても数ヶ月に跨るトレーニング計画となることが一般的でしょう。
さらに言えば、Kubernetesの基礎やRHELの基礎を身につけるために1ヶ月程度と考えてみると概ね3ヶ月程度がOpenShift Virtualization Readyになるための現実的な期間となるでしょう。
この3ヶ月という数字をどう見るかですが、Kubernetesベースの環境は学習コスト(特に時間と学ぶべき範囲)が未知数というイメージをお持ちの方が多い中、具体化された数字が出てくることは組織の成長戦略を立てる上で重要な参考値として働くと思います。
最後に、『Red Hat式の学習法』をお伝えするために次のスライド*7をご紹介します。
Red Hatの公式トレーニングでは、次のものが提供されます。
- コース内容を完全に網羅した専用テキスト(PDFとepubの2種がダウンロード可能)
- 講師による講義(オンライン開催と対面開催の2種)
- コースに対応した専用演習環境でのハンズオン
殆どの技術トレーニングは、講師や教科書からのいわゆるインプット学習に偏りがちですが、Red Hatのトレーニングでは受講生によるハンズオンでのアウトプットを重要視しています。
実際の職務の遂行にあたり、手を動かせることは即戦力たる武器となり、他のエンジニアとの差別化の要因としても強く機能します。
『手を動かせるエンジニア』を目指しましょう
そして、その身につけたスキルをぜひ対外的にも示すことが出来る認定資格として形にしませんか？
Red Hatでは、OpenShift Virtualizationに対するスペシャリストであることを証明するための資格試験と認定資格をご用意しています。
もちろん私も本認定資格は取得済みであり、取得をすると次のようなデジタルバッジが発行されます。
以上の内容をもち、本記事の締めとしたいと思います。
この記事の内容が、少しでもRed Hat OpenShift Virtualizationを活用した組織づくりのお役に立てば幸いです。
*1:Kubernetesそのものに対する認識は、それを取り扱う人によって異なる解釈もあります。この記事では主に読者をサーバ仮想化系インフラエンジニアと想定してこの表現としています
*2:コンテナや仮想マシンの外装となるもので、Kubernetes管理プレーンによる管理対象
*3:セカンダリネットワークと呼ぶ
*4:VMware vSphereで使用可能なRTO=0を実現するための仮想化ミラーリング機能、保護可能な仮想マシンは仮想CPU8コアまでです
*5:コンテナにとってはメモリの情報は揮発的であるため、vSphere FTと同一とは言えません。あくまでも近いだけです
*6:外部ストレージを使用しないケース
*7:このスライドは、本記事冒頭でご紹介しました2025年10月に開催されたRed Hat Summit Connectで使用したスライドであるため、スライド内のタイトルはこのブログ記事とは異なります。
