はじめに

2025年12月時点で生成AIチャットボットは市民権を獲得したと言えるでしょう。あらゆるWebサービスやSaaSには、生成AIチャットボット機能が具備され、我々ユーザーはそれに何の違和感も無く使っていると思います。

このチャット型インターフェースを用いて様々な調べ物をしたり、ソースコードを生成してもらったり、本当に色んなことができるようになってきています。

OpenShift Lightspeedとは

「OpenShift Lightspeed」は、コンテナアプリケーションプラットフォームである「Red Hat OpenShift」の管理運用をインテリジェントにしてくれる標準機能です。外部のLLMプロバイダーと連携し、使い慣れた生成AIチャットボットを介して、OpenShiftに関する質問になんでも回答してくれます。

特に、OpenShift/Kubernetesのスキルレベルがそこまで高くない方や、初めてコンテナアプリケーションの開発運用に挑戦される方々にとっては、一気にスキルレベルを上げるための後押しをしてくれる機能です。

OpenShift Lightspeedは2025年6月にGA（一般提供開始）しています。

生成AIでハイブリッドクラウドの生産性を加速するRed Hat OpenShift Lightspeedの一般提供を開始

OpenShift AIとの連携

OpenShift Lightspeedは、それ単体で利用することはできず、OpenAIやAzure OpenAI Service、IBM watsonx等の外部のLLMプロバイダーとの連携が必要になってきます。このLLMプロバイダーとして、「Red Hat OpenShift AI」を介して動かしているLLMを利用することも可能です。

OpenShift AIを利用することで、OpenShiftクラスタの中に閉じて生成AIチャットボットを利用することができ、非常にセキュアな環境でOpenShiftに関する質問が可能です。また予測可能なコスト内で生成AIチャットボットによるOpenShift管理運用のサポートを受けられます。

Red Hat OpenShift AIは、OpenShift上に構築されたエンタープライズ向けの AI/MLプラットフォームで、データサイエンティストや開発者がモデルの学習・推論・運用を一元管理できます。JupyterLabやモデルサービングのための様々なコンポーネント（KServe、vLLMなど）を統合し、セキュアかつスケーラブルな AIワークフローを実現します。「Red Hat OpenShift AI Operator」をインストールし、カスタムリソースを作成することで、OpenShift AIが利用可能になります。

本当に使い物になるの？

と疑問に思われる方もいらっしゃるかもしれません。それこそ「ChatGPTに聞けばいいんじゃないか？」とも。しかし、OpenShift Lightspeedは単なる「OpenShiftに関する質問に答えてくれるChatGPT的なもの」に留まらず、実際のクラスタの状態やログ情報などの「コンテクスト」に即した「AIアシスタント」として振る舞ってくれるんです！

この辺の便利さを本記事の中では詳しく解説していきます。

この記事を最後まで読むと実現できることのイメージ

OpenShift Lightspeedから指示を出すと、OpenShiftのドキュメントに基づいた種々の回答を生成し、またいくつかのMCP Serverと連携しながら実際のタスクを実行してくれます。

さっそくやっていきます！

記事の内容

本記事は以下の通りの見出しに沿って説明していきます。初期設定から知りたい方は最初からお読みください。

OpenShift AIの設定
gpt-oss-20bをデプロイ
OpenShift Lightspeedのセットアップ
クラスタ連携機能を使ってみる
RBACに基く質問をしてみる
カスタムMCPサーバーを使ってみる

動作環境

なお、OpenShiftクラスタはROSA（Red Hat OpenShift Service on AWS）を用いて、OpenShift 4.20の環境を用いました。また、Compute Nodeの構成は以下の通りとしています。

m6a.2xlarge × 2台
g6e.12xlarge × 1台
「g6e.12xlarge」はNVIDIA L40Sが4機搭載されたEC2インスタンスです。

また、OpenShift AIのバージョンは2.25（Stable, EUSリリース）を用いています。

OpenShift AIのライフサイクルはこちらを御覧ください。2.25はEUSアップデートを利用可能であり、2027年4月26日までのサポートに対応しています。

OpenShift AIの設定

まずはOpenShiftクラスタにOpenShift AI及び依存関係となるOperatorをインストール＆設定していきます。

OpenShift AIの依存関係について

今回の記事の内容に即してLLMをデプロイする場合、最低でも以下のOperatorを追加でインストールする必要があります。

Node Feature Discovery（NFD）Operator
NVIDIA GPU Operator
OpenShift AI Operator

また、各Operatorをインストールすることによって作成可能となるカスタムリソース（CR）も作成が必要です。これらのインストール＆設定に必要なManifestファイル一式は以下に格納してありますのでご活用ください！

https://gitlab.com/masaki-oomura/openshift-lightspeed

事前に、作業環境（PCのターミナル等）からOpenShiftクラスタにログインしておきましょう。なお、ユーザーはcluster-admin権限を有している前提です。

ログインコマンドはGUIからも簡単に取得できます。

ではゴリゴリやっていきます！

今回は時間短縮のため、CLIを使ってやっていきます。GUIを使って操作したい場合は、筆者の別記事等を参考にして頂ければ幸いです。

必要なリポジトリのクローン

# リポジトリをクローン
git clone https://gitlab.com/masaki-oomura/openshift-lightspeed.git

# ディレクトリを移動
cd openshift-lightspeed

NFD Operatorのセットアップ

CLIによるOperatorのインストール手順の通りにやっていきます。

# Namespaceの作成
oc create -f Operators/NFD/nfd-namespace.yaml

# OperatorGroupの作成
oc create -f Operators/NFD/nfd-operatorgroup.yaml

# Subscriptionの作成
oc create -f Operators/NFD/nfd-sub.yaml

# カスタムリソースの作成
oc create -f Operators/NFD/node-feature-discovery.yaml

# 当該Operator関連のPodがデプロイされるNamespaceを切り替え
oc project openshift-nfd

# カスタムリソースのデプロイ状況確認（すべてのPodがRunningになったら次に進む）
oc get pods
NAME                                      READY   STATUS    RESTARTS   AGE
nfd-controller-manager-75bddb6f68-crhhq   1/1     Running   0          4h17m
nfd-gc-7d665bb75d-r4zwr                   1/1     Running   0          4h14m
nfd-master-5bd59fc8cb-4jqzv               1/1     Running   0          4h14m
nfd-worker-7497x                          1/1     Running   0          4h14m
nfd-worker-75fl5                          1/1     Running   0          4h14m
nfd-worker-ck8v7                          1/1     Running   0          4h14m

NVIDIA GPU Operatorのセットアップ

NVIDIAから当該Operatorのインストール方法が公開されていますので、その通りにやっていきます。

# Namespaceの作成
oc create -f Operators/NVIDIA-GPU-Operator/nvidia-gpu-operator.yaml

# OperatorGroupの作成
oc create -f Operators/NVIDIA-GPU-Operator/nvidia-gpu-operatorgroup.yaml

# Subscriptionの作成
oc create -f Operators/NVIDIA-GPU-Operator/nvidia-gpu-sub.yaml

# カスタムリソースの作成
oc create -f Operators/NVIDIA-GPU-Operator/cluster-policy.yaml

# 当該Operator関連のPodがデプロイされるNamespaceを切り替え
oc project nvidia-gpu-operator

# カスタムリソースのデプロイ状況確認（すべてのPodがRunning or Completedになったら次に進む）
oc get pods                
NAME                                           READY   STATUS      RESTARTS        AGE
gpu-feature-discovery-bc765                    1/1     Running     0               4h14m
gpu-operator-74bfc87cc-zdrt6                   1/1     Running     0               4h15m
nvidia-container-toolkit-daemonset-mr4qd       1/1     Running     0               4h14m
nvidia-cuda-validator-x495n                    0/1     Completed   0               4h12m
nvidia-dcgm-exporter-b8v2n                     1/1     Running     1 (4h11m ago)   4h14m
nvidia-dcgm-tsrdd                              1/1     Running     0               4h14m
nvidia-device-plugin-daemonset-4hbgm           1/1     Running     0               4h14m
nvidia-driver-daemonset-9.6.20251110-1-82bgl   2/2     Running     0               4h14m
nvidia-node-status-exporter-mjhxv              1/1     Running     0               4h14m
nvidia-operator-validator-vp4sd                1/1     Running     0               4h14

OpenShift AI Operatorのセットアップ

こちらも、ドキュメント通りにやっていくのみです。

# Namespaceの作成
oc create -f Operators/RHOAI2.25/rhods-operator-namespace.yaml

# OperatorGroupの作成
oc create -f Operators/RHOAI2.25/rhods-operator-group.yaml

# Subscriptionの作成
oc create -f Operators/RHOAI2.25/rhods-operator-subscription.yaml

# カスタムリソースの作成
oc create -f Operators/RHOAI2.25/datascience-cluster.yaml

# 当該Operator関連のPodがデプロイされるNamespaceを切り替え
oc project redhat-ods-applications

# カスタムリソースのデプロイ状況確認（すべてのPodがRunningになったら次に進む）
oc get pods                       
NAME                                                              READY   STATUS    RESTARTS   AGE
codeflare-operator-manager-6674d84879-lt79l                       1/1     Running   0          4h9m
data-science-pipelines-operator-controller-manager-558dfb4fwzgz   1/1     Running   0          4h9m
etcd-744b8fbc68-vlg74                                             1/1     Running   0          4h9m
kserve-controller-manager-5d965c9c94-gq4jh                        1/1     Running   0          4h9m
kubeflow-training-operator-6cc4b855c4-mpftw                       1/1     Running   0          4h9m
kueue-controller-manager-5db9cbdbc-nxztg                          1/1     Running   0          4h9m
llama-stack-k8s-operator-controller-manager-64554d8c6f-lv5dz      1/1     Running   0          4h9m
model-registry-operator-controller-manager-f6c74bc48-tgpqc        1/1     Running   0          4h9m
modelmesh-controller-79bfd857f7-2n6wh                             1/1     Running   0          4h9m
modelmesh-controller-79bfd857f7-cq5tc                             1/1     Running   0          4h9m
modelmesh-controller-79bfd857f7-p6x6h                             1/1     Running   0          4h9m
notebook-controller-deployment-8965d8b7d-hztgv                    1/1     Running   0          4h9m
odh-model-controller-5cc94f974c-x79sm                             1/1     Running   0          4h9m
odh-notebook-controller-manager-9fc6c7fc5-kkq52                   1/1     Running   0          4h9m
rhods-dashboard-58f78c489f-t4jtx                                  3/3     Running   0          4h9m
rhods-dashboard-58f78c489f-xr9tv                                  3/3     Running   0          4h9m
trustyai-service-operator-controller-manager-7b59f7f79d-5xdb5     1/1     Running   0          4h9m

gpt-oss-20bをデプロイ

ここまでで、OpenShift AIのセットアップが完了しました。続いて、LLMをデプロイします。

今回は2025年8月にOpenAIから公開されたオープンウェイトモデル「gpt-oss-20b」を使います。このモデルはコンピューティングリソースの容量を抑えつつ、非常に高い推論性能と、Tool callingの性能を達成していると言えます。ローカルLLMを実現する上で、本記事執筆時点でも非常に有力な選択肢と言えるでしょう。

# Namespaceの作成
oc create -f gpt-oss-20b/Namespace.yaml

# ServingRuntimeをデプロイ
oc create -f gpt-oss-20b/ServingRuntime.yaml

# InferenceServiceをデプロイ
oc create -f gpt-oss-20b/InferenceService.yaml

# LLMがPodとしてデプロイされるNamespaceに切り替え
oc project language-model

# デプロイ状況確認（デプロイ完了まで、おそらく20分くらいかかります...）
oc get pods
NAME                                     READY   STATUS    RESTARTS   AGE
gpt-oss-20b-predictor-6f964d4fd8-kqqpk   2/2     Running   0          25m

お疲れ様でした。さて、ここまでで必要なOperator一式のセットアップが完了し、gpt-oss-20bがデプロイできました。OpenShiftのコンソール画面の右上のアプリケーションボタンをクリックすると、OpenShift AIのコンソール画面のリンクを確認できますので、こちらから移動します。

OpenShiftのログインアカウントでログインすると、OpenShift AIのコンソール画面に推移します。左メニュー「Model Deployments」をクリックすると、デプロイしたgpt-oss-20bを確認できます。ここで「Internal endpoint」をクリックすると、このgpt-oss-20bにクラスタ内からのみアクセス可能なエンドポイントURLを確認することができます。

コピーボタンをクリックし、このエンドポイントURLをメモしておきましょう。後ほどOpenShift Lightspeedの設定で利用します。

カスタムリソース「Inference Service」のマニフェストファイルのspec.predictor.model.argsの内容について、簡単に触れておきます。ここにはvLLMコンテナ実行時の引数（Arguments）を設定できます。

pec:
  predictor:
    ...
    model:
      args:
        - '--enable-chunked-prefill'
        - '--enable-auto-tool-choice'
        - '--tool-call-parser'
        - openai
        - '--tensor-parallel-size'
        - '4'

これらの引数について、簡単に説明します。

--enable-chunked-prefill：
- 大きなプリフィルを小さなチャンクに分割し、逐次アテンション計算を実行することで、デコードリクエストとまとめてバッチ処理することを可能にします。
- これにより、プロンプトのアテンション計算にGPUリソースを要するプレフィルフェーズと、比較的メモリドリブンな処理が行われるデコードフェーズを同時に実行し、ITL（トークン間レイテンシ）を小さくすることが期待できます。（詳細はこちら）
--enable-auto-tool-choice：
- LLMによる自動的なツール呼び出しをONにするために必要な引数です。（詳細はこちら）
- なお、後述の「クラスタ連携機能」を含めた各種MCP Serverとの連携時には必須のオプションになります。
--tool-call-parser openai：
- モデル毎に異なるツールパーサーを指定することのできる引数であり、今回はOpenAI社が提供するモデルのそれ（openai）を指定しました。
- なお、ツールパーサーとは、LLMが出力した自然言語（テキスト）を、プログラムが実行可能な形式（JSONなどのフォーマット）に変換・抽出する機能です。各モデルベンダ毎の差分を吸収し、MCPサーバーを含めた各種ツールとLLM、そしてクライアントアプリケーション（今回の場合はOpenShift Lightspeedがそれに当たります）の連携を実現します。
--tensor-parallel-size：
- 単一のGPUサーバーに複数枚のGPUが実装されている場合、それらのGPUにモデルパラメータを分散して展開可能なのですが、そのために必要な引数です。
- 今回利用する「g6e.12xlarge」はNVIDIA L40Sを4枚実装していますので、同引数の値として4を指定することで、4枚のGPUに分散してgpt-oss-20bを展開できます。（詳細はこちら）

他にもvLLMには起動時に実行可能なオプションが存在しており、詳細はRed Hatのホームページでも確認できますので、よろしければ参考にしてみてください。

vLLM のサーバー引数

では、次はいよいよOpenShift Lightspeedのセットアップです。

OpenShift Lightspeedのセットアップ

これまでのOperatorのセットアップと同様、今回もCLIで実行します。

Manifestファイルの適用

# Namespaceの作成
oc create -f Operators/OpenShift-Lightspeed/ols-namespace.yaml

# OperatorGroupの作成
oc create -f Operators/OpenShift-Lightspeed/ols-operatorgroup.yaml

# Subscriptionの作成
oc create -f Operators/OpenShift-Lightspeed/ols-subs.yaml

# LLM認証情報シークレットの適用
oc create -f Operators/OpenShift-Lightspeed/llm-auth.yaml

# カスタムリソースの作成
oc create -f Operators/OpenShift-Lightspeed/ols-config.yaml

# 当該Operator関連のPodがデプロイされるNamespaceを切り替え
oc project openshift-lightspeed

# カスタムリソースのデプロイ状況確認（すべてのPodがRunningになったら次に進む）
oc get pods
NAME                                                      READY   STATUS    RESTARTS      AGE
lightspeed-app-server-c899959f9-vqvm6                     2/2     Running   0             111s
lightspeed-console-plugin-5c56668c8b-w6rn9                1/1     Running   0             21m
lightspeed-operator-controller-manager-6f95bc7587-trrwb   1/1     Running   0             32m
lightspeed-postgres-server-684f4f644f-9wxb8               1/1     Running   1 (20m ago)   21m

ここで、OpenShift Lightspeedを実行可能にするための重要な設定を司るカスタムリソース「OLSConfig」のManifestをかくにんしておきましょう。主要なフィールドについては、Manifestに直書きしているコメントアウトを確認しておいてください。

ols-config.yamlの内容

apiVersion: ols.openshift.io/v1alpha1
kind: OLSConfig
metadata:
  creationTimestamp: null
  name: cluster
spec:
  llm: #LLMの設定を司るフィールドです
    providers:
      - credentialsSecretRef: #LLMとの通信を認証する情報を格納したシークレットを参照します。このフィールドは必須です。
          name: rhoai-api-keys 
        models: #モデル名を指定します。
          - name: gpt-oss-20b
        name: red_hat_openshift_ai
        type: rhoai_vllm
        # OpenShift AIから払い出されたURLをコピペします。最後は/v1で終わる必要があります。
        url: 'http://gpt-oss-20b-predictor.language-model.svc.cluster.local/v1'
  ols:
    defaultModel: gpt-oss-20b
    defaultProvider: red_hat_openshift_ai
     #クラスタ連携機能を利用する場合に用いるフィールドです
    logLevel: INFO
    storage: {}
    # OpenShift関連のドキュメントを埋め込んだPostgresqlのデータを永続化する設定です。サイズを指定しない場合は1Giの容量が割り当てられます

当該内容は公式ドキュメントの内容も合わせてご確認頂くことをおすすめします。

上記のManifestを適用すると、プロジェクト「openshift-lightspeed」内にOpenShift Lightspeedを構成するコンポーネント一覧が起動してきます。

早速OpenShift Lightspeedにいくつか質問してみましょう！

OpenShift関連の質問をしてみる

右下のアイコンをクリックすると、OpenShift Lightspeedとのチャットウィンドウが開きます。何か適当に質問してみます。「OpenShiftとKubernetesの関係はなんでしょうか？」と聞いてみます。

素晴らしいですね。わかりやすい回答です。単なる回答だけではなく、参照したソースとしてOpenShiftのドキュメントを明示してくれています。この様に、OpenShift関連のドキュメントを活用し、RAGによって拡張生成された回答を返してくれます。

実際のリソースに関する質問をしてみる

次に、OpenShift上にデプロイされている実際のリソースに基づいて回答を依頼してみます。今回は、先程デプロイしたgpt-oss-20bのPodのログについて解説を依頼してみましょう。

gpt-oss-20bのPodのログが確認できる画面にした状態で、右下のLightspeedアイコンをクリックし、チャットを起動します。

「Attach」ボタンをクリックすると、ユーザーで任意のドキュメント埋め込みを実行可能です。OpenShift Lightspeedでは、なんと今開いているリソースを認識し、そのリソースに関するRAGを手軽に実行できます。

現在はgpt-oss-20bのPodを確認しているので、PodのManifest（YAML）や、イベント、ログなどを簡単に貼り付けることができます。今回は「Logs」をクリックしてみます。

すると、Podに含まれるコンテナ名を選択したり、RAGに含ませるログの行数をインタラクティブに指定できる画面が開きます。

「Attach」をクリックすると、チャットに当ログをインプットとして盛り込むことが可能です。さっそく「このログに内容について日本語で教えて下さい。回答には表形式は用いないでください。」と質問してみます。

お〜！kserveコンテナのログについて説明してくれました。OpenShift Lightspeedでは、PodのログやManifestファイルなど、初心者には読み解きが難しい情報についても、このように手軽に質問できます。ぜひ、様々な場面で活用してみてください。

gpt-ossは回答に際して表形式を多用する特性があるとされているのですが、残念ながらOpenShift Lightspeedは現段階においてMarkdown形式の表についてHTML化して表示することができない模様です。故に、箇条書き等の形式を指定してあげると、可読性的にも良い回答が返ってきます。また、現段階ではSystem Promptを設定することもできないため、モデルの特性（優先的に回答する言語、回答形式のクセ等）に応じて、適宜User Promptで指示をしてあげる必要もあります。

クラスタ連携機能を使ってみる

さて、ここまでの内容は、あくまでLLMの事前知識と、クラスタ内で発生しているログ等の情報によるRAGから生成された回答に基くものでした。ここで「クラスタ連携機能」を有効化すると、まさに今OpenShift Lightspeedが動作しているクラスタの情報を取得して回答を生成できるようになります。

どういうことか、実際の回答内容を踏まえてご説明しますね。

ここで、「このクラスタにアタッチされているノードの一覧の情報を教えて下さい。回答には表形式は用いないでください。」というプロンプトを実行してみましょう。

おっと。「このクラスタ」がなんのことかわからないといった趣旨の回答が帰ってきてしまいました。

クラスタ連携機能をONにする

以下のコマンドを有効化することで、クラスタ連携機能を有効化します。これにより、実際のクラスタの状態を自動的に取得し、それに応じた回答を生成してくれるようになります。

oc patch olsconfig cluster --type=json -p='[{"op": "add", "path": "/spec/ols/introspectionEnabled", "value": true}]' -n openshift-lightspeed

コマンドを適用すると、カスタムリソース「OLSConfig」のspec.ols以下に以下のようなサブフィールドが適用されます。

apiVersion: ols.openshift.io/v1alpha1
kind: OLSConfig
...
spec:
  ...
  ols:
    ...
    introspectionEnabled: true
    ...

クラスタ連携機能は現時点ではTechnology Previewでの提供となっています。

では、もう一度同じ質問を実施してみましょう。

お〜！実際のクラスタの情報に即して回答してくれました！これは単なるChatGPTとは別格の「OpenShiftに最適化されたチャットボット」と言えるのではないでしょうか！？

クラスタ連携機能を有効化すると、OpenShift Lightspeedの主要なコンポーネントであるPod「lightspeed-app-server」内にMCPサーバコンテナ「openshift-mcp-server」が起動します。

このMCP Serverを介して、OpenShift Lightspeedがクラスタの各種リソースを取得するためのツール「resouces_list」を利用できるようになります。

RBACに基く質問をしてみる

さて、OpenShiftを管理運用する上で重要な観点のひとつに、適切なRBAC（Role-Based Access Control）があります。OpenShiftのユーザが参照・編集可能なリソースを適切に管理し、たとえば「割り当てられたNamespaceと、それに帰属するリソースしか参照できないようにする」といった制限を適用することはよくある権限設定のあり方です。これは、テナントとしてNamespaceを割り当てられた開発者同士がお互いのリソースを参照できないように隔離したりする上で、必須の権限管理です。

OpenShift Lightspeedでは、ログインしているユーザのRBACに基づいて回答を生成してくれます。さっそく試してみましょう。

まずはcluster-adminで質問

さて、現在ログインしているであろうcluster-admin権限を持つユーザにて「このクラスタに存在するNamespace一覧を箇条書きで出力してください。」と聞いてみます。

-----------------------------------途中省略------------------------------------

おぉ... OpenShiftクラスタに存在するすべてのNamespace一覧を出してきました。これらは、OpenShiftのコンソール画面からも確認可能なNamespace一覧と同様です。

では、Namespace参照権限が限定されたユーザを作成してみて、このユーザでOpenShift Lightspeedを使ってみましょう。

OpenShift Lightspeed利用権限が付いたユーザアカウントを準備する

まずは、Namespace、ユーザ、ロールバインディングのリソースを作成しましょう。

ユーザ作成

今回はROSAを用いてOpenShiftクラスタを作成しているので、「Red Hat Hybrid Cloud Console」からユーザを作成していきます。

既に作成済みのuserがあれば、この手順はスキップして構いません。

既に作成済みのIdPから「Edit」をクリック。

「Add user」をクリック。

ユーザ「user1」を作成し、「Add user」をクリック。これでユーザ「user1」が作成できました。

Namespaceを作成

続いて、以下のコマンドを用いて、Namespace「user1」を作成します。

# Namespaceの作成
oc create -f RBAC-test/user-namespace.yaml

これでNamespace「user1」ができました。

ロールバインディングを作成

これから作成するロールバインディングを一度確認しておきます。コメントアウトに記載の通り、ユーザ「user1」に対して、OpenShift Lightspeedを利用するための権限と、Namespace「user1」のリソースを参照するための権限を付与します。

# OpenShift Lightspeedに関するロールバインディング
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: lightspeed-operator-query-access
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: lightspeed-operator-query-access
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user1
# OpenShift LightspeedのRBACについては以下のサイトにも詳細が掲載されています。
# https://docs.redhat.com/ja/documentation/red_hat_openshift_lightspeed/1.0/html-single/configure/index#ols-about-lightspeed-and-role-based-access-control_ols-configuring-openshift-lightspeed
---
# ユーザ「user1」がNamespace「user1」のみを参照可能にするためのロールバインディング
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: user1-view-access
  namespace: user1
subjects:
  - kind: User
    name: user1
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

こちらのManifestを以下のコマンドを用いて適用します。

# Namespaceの作成
oc create -f RBAC-test/user-rbac.yaml

これで準備ができました！さて、OpenShiftのコンソールにuser1でログインし、OpenShift Lightspeedを利用してみましょう。

権限を制限されたユーザでOpenShift Lightspeedを使ってみる

先程作成したユーザ「user1」は、Namespace「user1」の参照権限を持っています。これは、コンソール画面で参照できるNamespace一覧においても一目瞭然です。

また、OpenShift Lightspeedの利用権限も付与していますので、右下のアイコンからチャットウィンドウを開き、LLMと対話することも可能です。さっそく、「Namespace「user1」には、どんなConfigMapが作成されていますか？箇条書きを用いて、日本語で教えて下さい。」と聞いてみます。

クラスタ連携機能を用いて、当該Namespaceに作成済みのConfigMap一覧をだしてくれました。これらはOpenShiftのコンソール画面からもその一覧を確認できます。

次に、先程cluster-admin権限アカウントにて質問した内容「このクラスタにアタッチされているノードの一覧の情報を教えて下さい。回答には表形式は用いないでください。」を聞いてみます。

お〜！ユーザ「user1」ではクラスタレベルのリソースに関する参照権限が無いため、このような回答が返ってきました。このようにして、OpenShift Lightspeedはログインしているユーザの権限に基く回答にも対応しています。

もちろん、ユーザの権限に関係ない質問にはしっかり答えてくれます。

カスタムMCPサーバーを使ってみる

実は、OpenShift Lightspeedでは追加のMCPサーバーを追加することも可能です。これにより、OpenShift Lightspeedで参照可能な情報を増やし、更にインテリジェントな運用が可能となります。

Cluster Observablity Operatorによるインシデント検知と連携

今回は、Red Hatの公式ブログで公開されている記事「Integrate incident detection with OpenShift Lightspeed via MCP」を参考にして、カスタムMCP Serverを立てます。これにより、実際にクラスタで発生しているインシデント情報を参照した回答生成が可能になります。

Cluster Observablity Operator（COO）のセットアップ

まずはCOOをインストールします。COOはOpenShiftの可観測性（Observability）を向上させる追加のOperatorです。こちらをインストールすることにより、OpenShift MonitoringやOpenShift Logging等と連携した、より実践的なObservabilityを実現することができます。

COOの詳細は、Red Hatの公式ドキュメントを参照ください。

これまでのOperatorのセットアップ同様、CLIで実行していきます。もしGUIでインストールしたい場合は、公式ドキュメントの手順をご確認ください。

# Namespaceの作成
oc create -f Operators/COO/coo-namespace.yaml

# OperatorGroupの作成
oc create -f Operators/COO/coo-operatorgroup.yaml

# Subscriptionの作成
oc create -f Operators/COO/coo-subs.yaml

# カスタムリソースの作成
oc create -f Operators/COO/ui-plugin.yaml

# 当該Operator関連のPodがデプロイされるNamespaceを切り替え
oc project openshift-cluster-observability-operator

# カスタムリソースのデプロイ状況確認（すべてのPodがRunningになったら次に進む）
oc get pods
NAME                                                         READY   STATUS    RESTARTS   AGE
health-analyzer-7d6bc66c66-m24d4                             1/1     Running   0          50m
monitoring-84664fb7cc-lkhwh                                  1/1     Running   0          50m
obo-prometheus-operator-6897d5489b-6mnq2                     1/1     Running   0          50m
obo-prometheus-operator-admission-webhook-67b4576fb9-lrd5m   1/1     Running   0          50m
obo-prometheus-operator-admission-webhook-67b4576fb9-zjwp5   1/1     Running   0          50m
observability-operator-749ccf659b-5drpw                      1/1     Running   0          50m
perses-operator-59dcbdc7c7-s6xxh                             1/1     Running   0          50m

コンソール画面でも、関連コンポーネントがデプロイできていることを確認しました。

なお、今回作成したカスタムリソース「UIPlugin」は、COOと連携して様々な高度なモニタリング情報をOpenShiftコンソール画面に表示することができるものです。

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: monitoring
  namespace: openshift-cluster-observability-operator
spec:
  type: Monitoring
  monitoring:
    incidents:
      enabled: true

今回は、「インシデント検出」を有効化しています。このインシデント検出は、OpenShift内で発生する複数のアラートを関連付けし、ひとつの「インシデント」として括り、その重大度や、インシデントに含まれる個々のアラートの時系列を一目で確認できるようにする機能です。

詳しくは、Red Hat公式ドキュメントをご確認ください。

MCP Serverをデプロイ

引き続き、Red Hatの公式ブログで公開されている記事「Integrate incident detection with OpenShift Lightspeed via MCP」を参考にして、「インシデント検出MCP Server（※開発者プレビュー）」をデプロイします。

oc apply -f https://raw.githubusercontent.com/openshift/cluster-health-analyzer/refs/heads/mcp-dev-preview/manifests/mcp/01_service_account.yaml
oc apply -f https://raw.githubusercontent.com/openshift/cluster-health-analyzer/refs/heads/mcp-dev-preview/manifests/mcp/02_deployment.yaml
oc apply -f https://raw.githubusercontent.com/openshift/cluster-health-analyzer/refs/heads/mcp-dev-preview/manifests/mcp/03_mcp_service.yaml

Namespace「openshift-cluster-observability-operator」にMCP Serverが起動してきました。このMCP ServerをOpenShift Lightspeedから呼び出せるように設定していきます。

OLSConfigにMCP Server情報を登録

OpenShiftコンソール画面のメニュー「エコシステム」から「インストール済みのOperator」を選択し、「OpenShift Lightspeed」をクリック、「OLSConfig」のタブに切り替えます。すると、先程作成したOLSConfig「cluster」を確認できるはずです。

これをクリックし、「YAML」タブに切り替えます。spec以下に、以下の通り追記します。

...
spec:
  llm:
    providers:
      - credentialsSecretRef:
          name: rhoai-api-keys
        models:
          - name: gpt-oss-20b
        name: red_hat_openshift_ai
        type: rhoai_vllm
        url: 'http://gpt-oss-20b-predictor.language-model.svc.cluster.local/v1'
+ featureGates:
+   - MCPServer
+ mcpServers:
+   - name: cluster-health
+     streamableHTTP:
+       enableSSE: false
+       headers:
+         kubernetes-authorization: kubernetes
+       sseReadTimeout: 10
+       timeout: 5
+       url: 'http://cluster-health-mcp-server.openshift-cluster-observability-operator.svc.cluster.local:8085/mcp'
  ols:
...

「保存」をクリックすると、カスタムMCP Serverの設定が反映されます。OpenShift Lightspeedには、このようにして簡単にカスタムMCP Serverを登録することが可能です。

クラスタで発生しているインシデントについて聞いてみる

さっそく「現在発生中（firing）のインシデントの一覧について、日本語で詳しく教えて下さい。回答に表形式は使わないでください。」と聞いてみます。

お〜。インシデントの一覧を取得し、回答してくれました。COOのインシデント検知機能と連携するMCP Serverが提供している「get_incidents」ツールを利用し、現在発生中のインシデントのIDと、その内容について教えてくれています。

もちろん、これらのインシデントについては、OpenShiftのコンソール画面からも確認できますが、このようにOpenShift Lightspeedから自然言語で教えてもらえると、より理解度が深まる気がします。

OpenShift LightspeedからSlackに投稿してもらう

さらにカスタムMCP ServerとしてSlack MCP Serverを追加し、もっと発展的なOpenShift Lightspeed体験を実現してみます。今回使うものは、有志の方が作成してくださったSlack MCP Serverのソースコードです。

Slackの準備

今回は、事前にSlackで「demos」というチャンネルを作成しておきました。

また、同Githubリポジトリに記載の内容に従って、demosチャンネルにアプリを追加しています。

Slackへのアプリ追加はこちらのページから可能です。アプリに与えるべき権限は同リポジトリ内容を参考してください。アプリが無事追加できると、Slackトークン（xから始まる文字列）を確認できるようになるので、これをメモしておいてください。

また、これに加えて、SlackのチームID（Tから始まる文字列）、demosチャンネルのチャンネルID（Cから始まる文字列）をメモしておきます。チームID及びチャンネルIDは、WebブラウザでSlackを開くと取得できる文字列です。

Slack MCP Serverをデプロイする

まずは以下のコマンドにて、Slack MCP ServerをデプロイするためのNamespace「slack-mcp-server」を作成します。

oc new-project slack-mcp-server

続いて、事前に用意しているManifestを適用します。

# Slack MCP Serverにクラスタ内からアクセスするためのServiceリソースを作成
oc create -f slack-mcp-server/service.yaml

# Slack MCP ServerコンテナのDeploymentリソースを作成
oc create -f slack-mcp-server/deployment.yaml

このままだとSlack MCP Serverコンテナのデプロイは完了しません。環境変数として、Slackトークン、チームID、チャンネルIDを与えて上げる必要があります。これらの変数はSecretリソースを介して提供します。今回は、以下のようなSecretの雛形（slack-secret.yaml）を用意しました。

kind: Secret
apiVersion: v1
metadata:
  name: slack-secret
  namespace: slack-mcp-server
  labels:
    app.kubernetes.io/instance: slack-secret
stringData:
  slack-bot-token: "<Your Slack Bot user's Token(start from x)>"
  slack-team-id: "<Your Slack's workspace ID (start from T)>"
  slack-team-ids: "<Your Slack's channel ID (start from C)>"
type: Opaque

slack-bot-token, slack-team-id, slack-team-idsについて、それぞれ自分の環境に応じたものを値として入れておきます。

#slack-secret.yamlを編集（今回はviエディタを使っていますが、お好きなエディタでも構いません）
vi slack-mcp-server/slack-secret.yaml

# 値を編集し、保存してください

# Secretリソースを作成
oc create -f slack-mcp-server/slack-secret.yaml

無事、Namespace「slack-mcp-server」にSlack MCP Serverがデプロイできました。

OLSConfigにSlack MCP Serverの接続先情報を設定する

先程の手順と同様に、カスタムリソース「OLSConfig」に対して、今デプロイしたSlack MCP Serverのアクセス先情報を登録しておきます。

以下の通り、OLSConfigに追記します。

...
spec:
  llm:
    providers:
      - credentialsSecretRef:
          name: rhoai-api-keys
        models:
          - name: gpt-oss-20b
        name: red_hat_openshift_ai
        type: rhoai_vllm
        url: 'http://gpt-oss-20b-predictor.language-model.svc.cluster.local/v1'
  featureGates:
    - MCPServer
  mcpServers:
    - name: cluster-health
      streamableHTTP:
        enableSSE: false
        headers:
          kubernetes-authorization: kubernetes
        sseReadTimeout: 10
        timeout: 5
        url: 'http://cluster-health-mcp-server.openshift-cluster-observability-operator.svc.cluster.local:8085/mcp'
+   - name: slack
+     streamableHTTP:
+       enableSSE: true
+       sseReadTimeout: 10
+       timeout: 5
+       url: 'http://slack-mcp-server.slack-mcp-server.svc.cluster.local:80/sse'
  ols:
...

「保存」をクリックし、Slack MCP Serverの設定情報を反映します。

Slackに投稿を依頼してみる

OpenShift Lightspeedのチャットウィンドウに「このクラスタのNodeの詳細情報と、現在発生しているインシデント情報について、日本語の箇条書きでSlackに投稿してください。Slackのチャンネル名はdemosです。」と入力してみます。

素晴らしいですね。OpenShift Lightspeedに対する指示を受けて、概ね以下の通りタスクが実行されました。

クラスタ連携機能によって起動しているMCP Serverから提供される「resouces_list」ツールを用いてNode一覧情報を取得
インシデント検知機能のMCP Serverから提供される「get_incidents」ツールを用いてインシデント情報を取得
また、Slack MCP Serverから提供される「slack_list_channels」ツールと「slack_post_message」ツールを活用して、demosチャンネルに投稿

Slackの方を確認してみます。

お〜！確かに投稿されています。

最後に

いかがでしたでしょうか？OpenShiftをより賢く使いこなすための様々なサポートを提供してくれる「OpenShift Lightspeed」の実力を感じて頂けたなら幸いです。また、OpenShift AIと連携することで、推論コストを一定程度コントロールしつつ、セキュリティも意識した運用が可能になることも分かって頂けたでしょう。

本記事では割愛しましたが、OpenShift Lightspeedには組織が持つ独自のナレッジやドキュメントを用いてRAGを実装する「BYO Knowledge ツール」という機能も実装されています。
※Technical Previewでの提供

OpenShiftはKubernetesの目指す「Platform for platforms」を体現するべく、日々様々な機能が追加されています。それに伴い、OpenShift管理者が見るべきものも増えていきますし、OpenShiftにこれから挑戦しようとする方のハードルが上がっているのも事実です。このギャップを埋めるためにLLMが役に立つはずです。これまでOpenShiftに慣れ親しんで来た人も、これから挑戦する人も、ぜひOpenShift LightspeedによってインテリジェントなOpenShift運用に踏み出していただきたいと思います。そして、「本当に人間がやるべきこと」に注力して頂ければ幸いです。

おしまい

（おまけ）記事タイトルの元ネタ