エッジでの Red Hat OpenShift：ゼロタッチ・プロビジョニング

情報テクノロジーは目覚ましい進化を遂げており、デプロイと保守のシナリオは日々変化しています。エッジでのデータとデバイスの処理と管理の必要性はますます高まっているため、このような戦略の導入をサポートし、促進するようにテクノロジーを適応させる必要があります。

Red Hat OpenShift は、特定のインフラストラクチャに依存しないアプリケーション・プラットフォームの管理から、オンプレミスまたはクラウド (プライベート、パブリック、ハイブリッド) へのデプロイメントに至るまで、さまざまなニーズに対応できます。

しかし、あらゆる状況に適応する能力は、時間の経過とともに大きく進化しています。 コンパクトな 3 ノード・デプロイメント・モードやシングルノード構成などの軽量な構成を活用すると、フットプリントを小さくしながらも、同じ柔軟性とパフォーマンス特性を実現できます。 

この柔軟性により、OpenShift は、リモートサイト (支店や個別のコンピューティング/処理サイト) など、コンピューティング能力が限られ、ハードウェアの使用に制限があるシナリオでのデプロイに適応できます。

このようなエッジサイトが多数あるとします。さらに、一元化されたコンピューティング容量とワークロード管理を保証するテクノロジーを使用して、すべてのエッジサイトにアクセスする必要があります。事前定義済みのポリシーやサイトに関連するシナリオに準拠した構成と設定を複製して伝播することができ、何よりも短時間で利用できるため、複雑さが軽減され、複製可能性と信頼性が向上します。

このユースケースには、ゼロタッチ・プロビジョニング (ZTP) が対応します。ゼロタッチ・プロビジョニングは、OpenShift の Assisted Installer の柔軟性と、Red Hat Advanced Cluster Management for Kubernetes が提供する一元化されたクラスタとインフラストラクチャ管理の多用途性および単純性によって実現します。

ゼロタッチ・プロビジョニングは、その名前が示すように、ベアメタルに OpenShift クラスタをプロビジョニングするモードの 1 つです。このタイプのプロビジョニングにより、デバイスと物理的にやり取りすることなく、リモートサイトのニーズに基づいて調整を施した複数のクラスタセットアップを作成できます。そのためには、特定のリソースでクラスタの望ましい構成を宣言する必要があります。Baseboard Management Controller (BMC) とのインターフェイスによるインフラストラクチャノードのプロビジョニング操作と、OpenShift Assisted Installer 機能を利用して行うクラスタのプロビジョニング操作への変換は、どちらも Red Hat Advanced Cluster Management のさまざまなコンポーネントが処理します。

定義されたリソースはすべて自己完結型であるため、Git リポジトリに保存し、OpenShift GitOps Operator (ArgoCD がベース) を使用して適用できます。これによりサイトとクラスタを通常のアプリケーションと同じように定義できます。

下の図にユースケースの例を示します。図からわかるように、この例では、このモードのプロビジョニングは中央データセンター内のハブとして機能する 1 つのクラスタのみを対象とします。

以下で取り上げる機能は現在、テクノロジープレビューの段階ですが、最適化された構成を作成して大規模にデプロイする方法を示しています。

ユースケース：ZTP によるエッジでのシングルノード OpenShift

まず、パズルのように全体像を構成する各ピースを確認してから、それらを組み合わせた全体像がどのようになるかを見ていきます。

このプロセスで使用する主な Red Hat Advanced Cluster Management コンポーネントは次のとおりです。

• OpenShift ベアメタル Operator
• Assisted Installer
• マルチクラスタエンジン - Hive Operator

エッジデバイスに関連する問題については後ほど扱うので、ここではベアメタルを想定します。セットアップモードは、ユーザーが用意したインフラストラクチャと、インストーラーが提供するインフラストラクチャにインストールされたものに基づいてすでに利用可能であり、これをデプロイのさまざまな段階で使用します。

各リモートデバイスはサイトに関連付けられます。これは、設定フェーズで考慮する必要がある基本パラメーターの定義に対応し、SiteConfig と呼ばれるカスタムリソース定義 (CRD) に変換されます。

CRD は以下を定義します。

• ノードの管理に使用する BMC の詳細
• クラスタに関する詳細 (クラスタ名、ドメイン)
• ネットワーク構成 (Pod、サービス、マシンのサブネット)
• ノードの構成 (ネットワーク設定、パーティショニング、ポリシーによって必要なハードニング)

この情報は管理され、サブリソースに変換されます。このサブリソースはデプロイのさまざまな段階をオーケストレーションするためのさまざまなコンポーネントによって管理されます。

単純化するために、ZTP の論理フローを以下に示します。

図の各リソースとその役割について、詳しく見ていきます。

BareMetalHost

BareMetalHost (BMH) は、BMC からの情報を処理します。この情報は、OpenShift 内にベアメタルノードを作成してリモートノードを準備および設定するために、OpenShift ベアメタル Operator によって解釈されます。これはノードプロビジョニングの中核です。これにより、Operator は、実行しようとしているセットアップに合わせてカスタマイズされたブートデバイスをリモートで設定できるからです。

InfraEnv

InfraEnv は、ネットワーク、ホストするノードで使用される NTP サーバー、接続されるノードへのアクセスに使用されるセキュアシェル (SSH) キー、インストールに必要なコンテナイメージにアクセスするための資格情報に関する詳細を定義します。ClusterDeployment リソースとともに、Assisted Installer の検出 ISO を構築するために使用されます。

AgentClusterInstall

バージョン、名前、ネットワーク設定など、クラスタのインストールと設定を続行するためにノードが使用するブートイメージを生成するのに Assisted Installer が使用する情報が含まれています。

ClusterDeployment

AgentClusterInstall で定義された情報を組み合わせ、クラスタを正しくデプロイするために必要なその他の情報を追加します。これらは、ノードのブート ISO に埋め込まれます。

ManagedCluster と KlusterletAddonConfig

Red Hat Advanced Cluster Management のユーザーであれば、これらのリソースはすでに馴染みのあるものかもしれません。これらはクラスタに関する情報を定義し、クラスタを Red Hat Advanced Cluster Management ハブでインポートおよび管理して、通信に必要なサービスを設定できるようにします。

OpenShift インストーラーによるプロビジョニングプロセスとクラスタのセットアップが完了すると、ハブにインストールおよびドッキングされた新しいシングルノードの OpenShift が表示され、ワークロードをデプロイできるようになります。

サマリー

この記事では、エッジシナリオにおける OpenShift 向け ZTP の概念を紹介し、Infrastructure as Code (IaC) アプローチによってプラットフォームのプロビジョニングプロセスをよりシンプルで繰り返し可能、かつスケーラブルなものにする方法を説明しました。

このテクノロジーは継続的開発が行われており、現在は十分に成熟しているため、あらゆるシナリオで完全なアプリケーション・プラットフォームを導入するためのこの革新的な方法を実際に試してみることができます。