|Index|SUSE Edge ドキュメント
SUSE Edge 3.6

SUSE Edge ドキュメント

 
発行日: 2026-05-27
図の一覧
表の一覧
例の一覧

SUSE Edge 3.6 ドキュメント

 

SUSE Edge ドキュメントへようこそ。高レベルのアーキテクチャの概要、クイックスタート、検証済みの設計、コンポーネントの使用方法に関するガイダンス、サードパーティの統合、およびエッジコンピューティングインフラストラクチャとワークロードの管理に関するベスト プラクティスをご覧いただけます。

1 SUSE Edgeとは

 

SUSE Edge は、エッジにおけるインフラストラクチャとクラウドネイティブアプリケーションの展開という特有の課題に対処するための、専用に構築され、緊密に統合され、包括的に検証されたエンドツーエンドのソリューションです。その主な焦点は、初期展開のイメージ構築、ノードのプロビジョニングとオンボーディング、アプリケーションの展開、監視、そして完全なライフサイクル運用にわたる、独断的でありながらも非常に柔軟で、拡張性が高く、安全なプラットフォームを提供することです。このプラットフォームは、安全で安定した認定済みのSUSE Linuxプラットフォームを提供してきた30年以上の歴史と、Rancherポートフォリオによる拡張性が高く機能豊富なKubernetes管理を提供してきた経験の両方と一貫性のある、最高クラスのオープンソースソフトウェアを基盤としてゼロから構築されています。SUSE Edge は、これらの機能を基盤として構築されており、小売、医療、輸送、物流、通信、スマートマニュファクチャリング、産業用IoTなど、幅広い市場セグメントに対応できる機能を提供します。

2 設計思想

 

このソリューションは、顧客の要件や期待が大きく異なるため、「万能な」エッジプラットフォームは存在しないという考えに基づいて設計されています。エッジデプロイメントでは、大規模なスケーラビリティ、制限されたネットワーク可用性、物理的なスペースの制約、新たなセキュリティの脅威と攻撃ベクトル、ハードウェアアーキテクチャとシステムリソースの多様性、レガシーインフラストラクチャおよびアプリケーションのデプロイメントとインターフェース接続の要件、そして長寿命の顧客ソリューションなど、最も困難な課題のいくつかを解決し、継続的に進化させることが求められます。これらの課題の多くは、データセンター内やパブリッククラウド内でのインフラストラクチャやアプリケーションのデプロイメントといった従来の考え方とは異なるため、設計をより詳細に検討し、一般的な前提の多くを見直す必要があります。

例えば、私たちはミニマリズム、モジュール性、運用の容易さに価値を見出しています。システムが複雑であればあるほど故障しやすくなるため、エッジ環境ではミニマリズムが重要です。数百から数十万もの拠点に目を向けると、複雑なシステムは複雑な方法で故障します。当社のソリューションにおけるモジュール性により、ユーザーの選択肢が広がり、デプロイされたプラットフォームにおける不要な複雑さが排除されます。また、これらと運用の容易さとのバランスを取る必要もあります。人間はプロセスを何千回も繰り返す際にミスを犯す可能性があるため、プラットフォームは潜在的なミスを確実に復旧できるようにし、現場の技術者による訪問の必要性を排除すると同時に、一貫性と標準化にも努めるべきです。

3 高度なアーキテクチャ

 

SUSE Edgeの高レベルシステムアーキテクチャは、「管理」クラスターと「ダウンストリーム」クラスターという2つの主要なカテゴリに分類されます。管理クラスターは、1つまたは複数のダウンストリームクラスターのリモート管理を担当します。ただし、エッジサイトに外部接続がなく、独立して動作する必要がある状況など、特定の状況下ではダウンストリームクラスターがリモート管理なしで動作する必要があることも認識されています。SUSE Edgeにおいて、管理クラスターとダウンストリームクラスターの両方の運用に使用される技術コンポーネントは大部分が共通していますが、システム仕様と、その上で実行されるアプリケーションの両面で異なる可能性が高いです。つまり、管理クラスターはシステム管理とライフサイクル運用を可能にするアプリケーションを実行し、ダウンストリームクラスターはユーザーアプリケーションを提供するという要件を満たします。

3.1 SUSE Edgeで使用されるコンポーネント

 

SUSE Edgeは、既存のSUSEおよびRancherコンポーネントと、エッジコンピューティングで求められる制約や複雑さに対処するためにEdgeチームが構築した追加機能およびコンポーネントで構成されています。管理クラスターとダウンストリームクラスターの両方で使用されるコンポーネントについて、簡略化された高レベルのアーキテクチャ図とともに以下に説明します。なお、これは網羅的なリストではありません。

3.1.1 管理クラスタ

 
suse edge management cluster

  • 管理:これは、接続されたダウンストリームクラスターのプロビジョニングとライフサイクルを管理するために使用される、SUSE Edgeの中央集権的な部分です。管理クラスターには、通常、以下のコンポーネントが含まれます。

    • Rancher Prime (第4章 「Rancher」)によるマルチクラスター管理。ダウンストリームクラスターのオンボーディングと、インフラストラクチャおよびアプリケーションの継続的なライフサイクル管理のための共通ダッシュボードを実現します。また、包括的なテナント分離と`IDP`（IDプロバイダー）統合、サードパーティ製統合および拡張機能の広範なマーケットプレイス、ベンダーニュートラルなAPIも提供します。

    • SUSE Multi-Linux ManagerによるLinuxシステム管理。ダウンストリームクラスター上で実行される基盤となるLinuxオペレーティングシステム（*SUSE Linux Micro (第7章 「SUSE Linux Micro」)）の自動化されたLinuxのパッチおよび設定管理を実現します。このコンポーネントはコンテナ化されていますが、現時点では他の管理コンポーネントとは別のシステム上で実行する必要があるため、上記の図では「Linux管理」とラベル付けされています。

    • 特定のSUSE Edgeリリースへの管理クラスターコンポーネントのアップグレードを処理する専用のライフサイクル管理 (第19章 「Upgrade Controller」)コントローラー。

    • Elemental (第10章 「Elemental」)を使用したRancher Primeへのリモートシステムオンボーディング。接続されたエッジノードを目的のKubernetesクラスターにレイトバインディングし、GitOpsなどを介したアプリケーションデプロイメントを実現します。

    • ダウンストリームクラスターおよびその上で実行されるアプリケーションのプロビジョニングとライフサイクルを管理するための、Fleet (第6章 「Fleet」)と呼ばれるオプションのGitOpsエンジン。

    • 管理クラスター自体を支える基盤として、ベースオペレーティングシステムにはSUSE Linux Micro (第7章 「SUSE Linux Micro」)が、管理クラスターアプリケーションをサポートするKubernetesディストリビューションにはRKE2 (第12章 「RKE2」)が採用されています。

3.1.2 ダウンストリームクラスタ

 
suse edge downstream cluster

  • ダウンストリーム:これはSUSE Edgeの分散部分であり、エッジでユーザーワークロードを実行するために使用されます。つまり、エッジロケーション自体で実行されているソフトウェアであり、通常は以下のコンポーネントで構成されています。

    • K3s (第11章 「K3s」)やRKE2 (第12章 「RKE2」)のような安全で軽量なディストリビューションを含む、Kubernetesディストリビューションの選択肢（`RKE2`は政府機関や規制の厳しい業界での使用向けに強化、認定、最適化されています）。

    • SUSE Security (第14章 「SUSE Security」)により、イメージの脆弱性スキャン、ディープパケットインスペクション、リアルタイムの脅威および脆弱性保護などのセキュリティ機能が有効になります。

    • SUSE Storage (第13章 「SUSE Storage」)を使用したソフトウェアブロックストレージにより、軽量で永続的、回復力があり、スケーラブルなブロックストレージが可能になります。

    • SUSE Linux Micro (第7章 「SUSE Linux Micro」)を使用した、軽量でコンテナに最適化された強化済みLinuxオペレーティングシステムであり、エッジでコンテナや仮想マシンを実行するためのイミュータブル（不変）で回復力の高いOSを提供します。SUSE Linux MicroはAArch64アーキテクチャとAMD64/Intel 64アーキテクチャの両方で利用可能であり、遅延に敏感なアプリケーション（通信業界のユースケースなど）向けに`Real-Time Kernel`もサポートしています。

    • 接続されたクラスター（つまり、管理クラスターへの接続性を持つクラスター）の場合、2つのエージェントがデプロイされます。Rancher Primeへの接続を管理するためのRancher System Agentと、Linuxソフトウェアアップデートを適用するためにSUSE Multi-Linux Managerから指示を受けるためのvenv-salt-minionです。切断されたクラスターの管理には、これらのエージェントは不要です。

3.2 ［Connectivity (接続］

 
suse edge connected architecture

上の図は、*接続された*ダウンストリームクラスターと、それらが管理クラスターに接続される仕組みの概要を示しています。管理クラスターは、ダウンストリームクラスターとターゲット管理クラスター間のネットワーク接続状況に応じて、オンプレミスおよびクラウドの両方の環境において、さまざまな基盤インフラストラクチャプラットフォーム上にデプロイできます。これが機能するための唯一の要件は、ダウンストリームクラスターノードと管理インフラストラクチャを接続するネットワーク経由で、APIおよびコールバックURLにアクセスできることです。

この接続が確立されるメカニズムは、ダウンストリームクラスターのデプロイメカニズムとは異なる点に留意することが重要です。これについては次のセクションで詳しく説明しますが、基本的な理解として、接続されたダウンストリームクラスターを「管理対象」クラスターとして確立するための主なメカニズムが3つあります。

  1. ダウンストリームクラスターは、最初は「切断された」状態でデプロイされ（例：Edge Image Builder (第8章 「Edge Image Builder」)を使用）、接続が可能になった時点で管理クラスターにインポートされます。

  2. ダウンストリームクラスターは、ビルトインのオンボーディングメカニズムを使用するように構成されます。 （例：Elemental (第10章 「Elemental」)を使用） そして、初回起動時に自動的に管理クラスターに登録されるため、クラスター構成のレイトバインディングが可能になります。

  3. ダウンストリームクラスターはベアメタル管理機能（CAPI + Metal3）でプロビジョニングされており、クラスターがデプロイおよび構成されると（Rancher Turtlesオペレーター経由で）、自動的に管理クラスターにインポートされます。

注記
注記

大規模なデプロイメントの規模に対応し、地理的に分散した環境における帯域幅やレイテンシの懸念を最適化し、停止や管理クラスターのアップグレード時の混乱を最小限に抑えるために、複数の管理クラスターを実装することが推奨されます。現在の管理クラスターのスケーラビリティ制限とシステム要件は こちらで確認できます。

4 一般的なエッジデプロイメントパターン

 

さまざまな動作環境とライフサイクル要件のため、SUSE Edgeが運用されている市場セグメントやユースケースに大まかに適合する、いくつかの異なるデプロイメントパターンへのサポートを実装しました。お客様のニーズに合わせてSUSE Edgeプラットフォームに慣れていただけるよう、これらの各デプロイメントパターンに関するクイックスタートガイドを作成しました。現在サポートしている3つのデプロイメントパターンを以下に説明し、それぞれのクイックスタートページへのリンクを記載します。

4.1 「Phone Home」ネットワークプロビジョニング

 

中央の管理クラスターがハードウェアを直接管理できない環境で運用している場合があります（例：リモートネットワークがファイアウォールの背後にある、または帯域外管理インターフェースがない場合。これらはエッジでよく見られる「PC」タイプのハードウェアで一般的です）。このシナリオでは、ハードウェアが起動される際に、その出荷先を知る必要なく、クラスターとそのワークロードをリモートでプロビジョニングするためのツールを提供します。これは、多くの人がエッジコンピューティングと聞いて思い浮かべるものです。エッジロケーションで数千から数万台の未知のシステムが起動し、安全に「Phone Home（自動接続）」して自身の身元を検証し、何をすべきかという指示を受け取るというものです。ここでの要件は、工場でマシンにプリイメージを作成するか、USBなどを介してブートイメージを接続してシステムの電源を入れる以外、ユーザーの介入をほとんど必要としないプロビジョニングとライフサイクル管理を想定しています。この分野における主な課題は、現場にあるこれらのデバイスの規模、一貫性、セキュリティ、およびライフサイクルに対処することです。

このソリューションは、場所、システムタイプ、仕様、または最初に電源が投入された時期に関係なく、システムがプロビジョニングおよびオンボーディングされる方法において、非常に高い柔軟性と一貫性を提供します。SUSE Edgeは、Edge Image Builderを介してシステムの完全な柔軟性とカスタマイズを可能にし、ノードのオンボーディングとKubernetesプロビジョニングのためにRancherのElemental製品の登録機能を活用し、オペレーティングシステムのパッチにはSUSE Multi-Linux Managerを活用します。このソリューションのクイックスタートは第1章 「Elementalを使用したリモートホストのオンボーディング」にあります。

4.2 イメージベースのプロビジョニング

 

スタンドアロン環境、エアギャップ(された)環境、またはネットワークが制限された環境で運用する必要があるお客様向けに、SUSE Edgeは、エッジでのシングルノードおよびマルチノードの高可用性Kubernetesクラスターを実現するために必要なすべてのデプロイメントアーティファクトを含む、完全にカスタマイズ可能なインストールメディアを生成できるソリューションを提供します。これには、必要なワークロードや追加のレイヤーコンポーネントが含まれ、外部へのネットワーク接続や集中管理プラットフォームの介入なしで利用可能です。ユーザーエクスペリエンスは、『phone home』ソリューションと同様に、ターゲットシステムにインストールメディアが提供される点が特徴ですが、ソリューション自体はその場で起動します。このシナリオでは、結果として得られたクラスターを Rancher に接続して継続的に管理すること（つまり、大規模な再構成や再デプロイなしで「切断」モードから「接続」モードへ移行すること）が可能ですが、分離した状態で運用を続けることもできます。どちらの場合も、ライフサイクル操作を自動化するための同じ一貫したメカニズムを適用できることに注意してください。

さらに、このソリューションを使用して、あらゆるタイプのエッジインフラストラクチャをプロビジョニングするための最も迅速かつシンプルな方法となり得るため、「ダイレクトネットワークプロビジョニング」モデルと「phone home ネットワークプロビジョニング」モデルの両方をサポートする集中インフラストラクチャをホストする管理クラスターを迅速に作成できます。このソリューションは、SUSE Edge Image Builderの機能を最大限に活用して、完全にカスタマイズされた無人インストールメディアを作成します。クイックスタートは第2章 「Edge Image Builderを使用したスタンドアロンクラスター」にあります。

5 SUSE Edge スタック検証

 

すべての SUSE Edge リリースは、緊密に統合され、徹底的に検証されたコンポーネントで構成されており、これらは1つのユニットとしてバージョン管理されています。コンポーネント間の統合をテストするだけでなく、強制的な障害シナリオ下でシステムが期待どおりに動作することを保証する継続的インテグレーションおよびスタック検証の取り組みの一環として、SUSE Edge チームはすべてのテスト実行とその結果を公開しています。結果とすべての入力パラメータは ci.edge.suse.com で確認できます。

6 コンポーネントの全リスト

 

コンポーネントの全リストと、それぞれの概要説明および SUSE Edge での使用方法へのリンクを以下に示します。

パート I クイックスタート

 

クイックスタートはこちら

  • 1 Elementalを使用したリモートホストのオンボーディング

    • このセクションでは、SUSE Edgeの一部として「phone home network provisioning」ソリューションについて説明します。ここでは、Elementalを使用してノードのオンボーディングを支援します。Elementalは、リモートホストの登録と、KubernetesによるクラウドネイティブOSの一元管理を可能にするソフトウェアスタックです。SUSE Edgeスタックでは、Elementalの登録機能を使用してリモートホストをRancherにオンボーディングします。これにより、ホストを一元管理プラットフォームに統合し、そこからKubernetesクラスターや階層化された…

  • 2 Edge Image Builderを使用したスタンドアロンクラスター

    • Edge Image Builder (EIB) は、完全にエアギャップされたシナリオであっても、マシンの起動用にカスタマイズされた起動可能な (CRB) ディスクイメージを生成するプロセスを効率化するツールです。EIBは、SUSE Edgeの3つのデプロイメントフットプリントすべてで使用するデプロイメントイメージを作成するために使用されます。ユーザーの追加やタイムゾーンの設定といった最小限のカスタマイズから、複雑なネットワーク構成の設定、マルチノードKubernetesクラスターのデプロイメント、顧客ワークロードのデプロイメント、Rancher/ElementalおよびSUSE Multi-…

  • 3 SUSE Multi-Linux Manager

    • SUSE Edge 3.6 (5.0.6) に含まれているSUSE Multi-Linux Managerのバージョンは、SUSE Linux Micro 6.2をまだサポートしていません。これは将来のSUSE Edge 3.6リリースで更新され、サポートされる予定です。

1 Elementalを使用したリモートホストのオンボーディング

 

このセクションでは、SUSE Edgeの一部として「phone home network provisioning」ソリューションについて説明します。ここでは、Elementalを使用してノードのオンボーディングを支援します。Elementalは、リモートホストの登録と、KubernetesによるクラウドネイティブOSの一元管理を可能にするソフトウェアスタックです。SUSE Edgeスタックでは、Elementalの登録機能を使用してリモートホストをRancherにオンボーディングします。これにより、ホストを一元管理プラットフォームに統合し、そこからKubernetesクラスターや階層化されたコンポーネント、アプリケーション、およびそれらのライフサイクルをすべて共通の場所からデプロイおよび管理できるようになります。

このアプローチは、制御したいデバイスが管理クラスターと同じネットワーク上にない場合や、より直接的な制御を可能にする帯域外管理コントローラーが搭載されていない場合、またエッジで多くの異なる「未知の」システムを起動し、それらを大規模に安全にオンボーディングおよび管理する必要があるシナリオで役立ちます。これは、小売、産業用IoT、またはデバイスがインストールされるネットワークをほとんど制御できないその他の分野のユースケースにおける一般的なシナリオです。

1.1 上位レベルのアーキテクチャ

 
quickstart elemental architecture

1.2 必要なリソース

 

以下に、このクイックスタートを実行するための最小限のシステム要件および環境要件を説明します。

  • 集中管理クラスター用のホスト（RancherおよびElementalをホストするもの）：

    • 開発またはテスト用に最低8 GBのRAMと20 GBのディスク容量（本番環境での使用については こちらを参照）

  • プロビジョニング対象のノード、つまりエッジデバイス（デモやテスト目的であれば仮想マシンを使用可能）

    • 最低4GBのRAM、2 CPUコア、20 GBのディスク

  • 管理クラスターの解決可能なホスト名、またはsslip.ioのようなサービスで使用する静的IPアドレス

  • Edge Image Builderを使用してインストールメディアを構築するためのホスト

    • PodmanをサポートするSLES 15 SP6、openSUSE Leap 15.6、またはその他の互換性のあるオペレーティングシステムを実行していること。

    • Kubectl、 Podman、および Helmがインストールされていること

  • 起動用のUSBフラッシュ ドライブ（物理ハードウェアを使用する場合）

  • こちらから入手可能な、最新のSUSE Linux Micro 6.2 SelfInstall ISOイメージのダウンロード済みコピー。

注記
注記

ターゲットマシン上の既存のデータは、このプロセスの一環として上書きされます。ターゲットデプロイメントノードに接続されているUSBストレージデバイスやディスク上のデータは、必ずバックアップしてください。

このガイドは、アップストリームクラスタをホストするためのDigital Oceanドロップレットと、ダウンストリームデバイスとしてのIntel NUCを使用して作成されています。インストールメディアの構築には、SUSE Linux Enterprise Serverが使用されます。

1.3 ブートストラップクラスタを構築します

 

まずは、RancherとElementalをホストできるクラスタを作成することから始めます。このクラスタは、ダウンストリームノードが接続されているネットワークからルーティング可能である必要があります。

1.3.1 Kubernetesクラスタを作成します

 

ハイパースケーラー（Azure、AWS、Google Cloudなど）を使用している場合、クラスタをセットアップする最も簡単な方法は、ビルトインツールを使用することです。このガイドでは簡潔にするため、これらの各オプションのプロセスについては詳しく説明しません。

ベアメタルや、Kubernetesディストリビューション自体も提供する必要がある他のホスティングサービスにインストールする場合は、 RKE2の使用をお勧めします。

1.3.2 DNSを設定します。

 

続行する前に、クラスタへのアクセスを設定する必要があります。クラスタ自体のセットアップと同様に、DNSの構成方法はホストされている場所によって異なります。

ヒント
ヒント

DNSレコードの設定を処理したくない場合（例えば、これが一時的なテストサーバーである場合など）、代わりに sslip.ioのようなサービスを使用できます。このサービスを使用すると、任意のIPアドレスを`<address>.sslip.io`で解決できます。

1.4 Rancher をインストールします

 

Rancherをインストールするには、作成したばかりのクラスタのKubernetes APIにアクセスする必要があります。これは、使用されているKubernetesのディストリビューションによって異なります。

RKE2の場合、kubeconfigファイルは`/etc/rancher/rke2/rke2.yaml`に書き込まれています。 このファイルをローカルシステム上の`~/.kube/config`として保存します。 正しく外部からルーティング可能なIPアドレスまたはホスト名を含めるように、ファイルを編集する必要がある場合があります。

Rancher ドキュメントのコマンドを使用して、Rancher を簡単にインストールできます。

cert-manager をインストールします。

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
 --namespace cert-manager \
 --create-namespace \
 --set crds.enabled=true

次に、Rancher 自体をインストールします。

helm repo add rancher-prime https://charts.rancher.com/server-charts/prime
helm repo update
helm install rancher rancher-prime/rancher \
  --namespace cattle-system \
  --create-namespace \
  --set hostname=<DNS or sslip from above> \
  --set replicas=1 \
  --set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN> \
  --version 2.14.2
注記
注記

これが本番システムを目的としている場合は、cert-manager を使用して（Let’s Encrypt などの）実際の証明書を設定してください。

設定したホスト名にブラウザでアクセスし、使用した bootstrapPassword で Rancher にログインします。簡単なセットアッププロセスが案内されます。

1.5 Elemental をインストールします

 

Rancher がインストールされたので、Elemental オペレーターと必要な CRD をインストールできます。Elemental の Helm チャートは OCI アーティファクトとして公開されているため、他のチャートよりもインストールが少し簡単です。 Rancher をインストールしたのと同じシェル、または Rancher 内のブラウザのシェルからインストールできます。

helm install --create-namespace -n cattle-elemental-system \
 elemental-operator-crds \
 oci://registry.suse.com/rancher/elemental-operator-crds-chart \
 --version 1.9.0

helm install -n cattle-elemental-system \
 elemental-operator \
 oci://registry.suse.com/rancher/elemental-operator-chart \
 --version 1.9.0

1.5.1 （オプション）Elemental UI 拡張機能をインストールします

 

  1. Elemental UI を使用するには、Rancher インスタンスにログインし、左上の3本線メニューをクリックします。

    Elemental 拡張機能 1 のインストール

  2. このページの「Available（利用可能）」タブから、Elemental カードの「Install（インストール）」をクリックします。

    Elemental 拡張機能 2 のインストール

  3. 拡張機能をインストールすることを確認します。

    Elemental 拡張機能 3 のインストール

  4. インストール後、ページをリロードするように求められます。

    Elemental 拡張機能 4 のインストール

  5. リロードすると、「OS Management（OS 管理）」グローバルアプリから Elemental 拡張機能にアクセスできるようになります。

    Elemental 拡張機能へのアクセス

1.6 Elemental を設定します。

 

簡略化のため、変数 $ELEM に設定ディレクトリのフルパスを設定することをお勧めします。

export ELEM=$HOME/elemental
mkdir -p $ELEM

マシンがElementalに登録できるようにするには、fleet-default 名前空間に MachineRegistration オブジェクトを作成する必要があります。

このオブジェクトの基本バージョンを作成しましょう。

cat << EOF > $ELEM/registration.yaml
apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  name: ele-quickstart-nodes
  namespace: fleet-default
spec:
  machineName: "\${System Information/Manufacturer}-\${System Information/UUID}"
  machineInventoryLabels:
    manufacturer: "\${System Information/Manufacturer}"
    productName: "\${System Information/Product Name}"
EOF

kubectl apply -f $ELEM/registration.yaml
注記
注記

cat コマンドは、Bashがテンプレート化しないように、各 $ をバックスラッシュ (\) でエスケープします。手動でコピーする場合は、バックスラッシュを削除してください。

オブジェクトが作成されたら、割り当てられたエンドポイントを見つけてメモします。

REGISURL=$(kubectl get machineregistration ele-quickstart-nodes -n fleet-default -o jsonpath='{.status.registrationURL}')

あるいは、UIからこれを行うこともできます。

UI拡張機能

  1. OS管理拡張機能から、［登録エンドポイントの作成］をクリックします。

    「登録の作成」をクリック

  2. この設定に名前を付けます。

    名前の追加
    注記
    注記

    Edge Image Builderを使用した以下の手順でデータが上書きされるため、クラウド設定フィールドは無視してかまいません。

  3. 次に、下までスクロールし、マシン登録時に作成されるリソースへ追加する各ラベルに対して［ラベルの追加］をクリックします。これは、マシンを識別するのに役立ちます。

    ラベルの追加

  4. ［作成］をクリックして、設定を保存します。

  5. 登録が作成されると、登録URLが表示されます。［コピー］をクリックしてアドレスをコピーできます。

    URL のコピー
    ヒント
    ヒント

    その画面から離れてしまった場合は、左側のメニューで「Registration Endpoints」をクリックし、作成したエンドポイントの名前をクリックしてください。

    この URL は次のステップで使用します。

1.7 イメージ をビルドします

 

Elemental の現在のバージョンには独自のインストールメディアをビルドする方法がありますが、SUSE Edge 3.6 では代わりに Kiwi と Edge Image Builder を使用するため、結果として得られるシステムは SUSE Linux Micro をベースオペレーティングシステムとしてビルドされます。

ヒント
ヒント

Kiwi の詳細については、まず Kiwi Image Builder プロセス (第26章 「Kiwiを使用して更新されたSUSE Linux Microイメージを構築する」) に従って新しいイメージをビルドしてください。Edge Image Builder については、Edge Image Builder 入門ガイド (第2章 「Edge Image Builderを使用したスタンドアロンクラスター」) および コンポーネントドキュメント (第8章 「Edge Image Builder」) を確認してください。

Podman がインストールされている Linux システムから、ディレクトリを作成し、Kiwi によってビルドされるベースイメージを配置します。

mkdir -p $ELEM/eib_quickstart/base-images
cp /path/to/{micro-base-image-iso} $ELEM/eib_quickstart/base-images/
mkdir -p $ELEM/eib_quickstart/elemental
curl $REGISURL -o $ELEM/eib_quickstart/elemental/elemental_config.yaml
cat << EOF > $ELEM/eib_quickstart/eib-config.yaml
apiVersion: 1.3
image:
    imageType: iso
    arch: x86_64
    baseImage: SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
    outputImageName: elemental-image.iso
operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2
  isoConfiguration:
    installDevice: /dev/vda
  users:
    - username: root
      encryptedPassword: \$6\$jHugJNNd3HElGsUZ\$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
  packages:
    sccRegistrationCode: XXX
EOF
注記
注記

  • time セクションはオプションですが、証明書やクロックスキューに関する潜在的な問題を回避するために設定することを強く推奨します。この例で示されている値は、あくまで例示用です。お客様の特定の要件に合わせて調整してください。

  • エンコードされていないパスワードは eib です。

  • 公式ソースから必要な RPM をダウンロードしてインストールするには sccRegistrationCode が必要です（代わりに、elemental-register および elemental-system-agent RPM を手動でサイドロードすることも可能です）。

  • cat コマンドは、Bashがテンプレート化しないように、各 $ をバックスラッシュ (\) でエスケープします。手動でコピーする場合は、バックスラッシュを削除してください。

  • インストール中にインストールデバイスは消去されます。

podman run --privileged --rm -it -v $ELEM/eib_quickstart/:/eib \
 registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
 build --definition-file eib-config.yaml

物理デバイスを起動する場合は、イメージを USB フラッシュ ドライブに書き込む必要があります。これは次のように実行できます。

sudo dd if=/eib_quickstart/elemental-image.iso of=/dev/<PATH_TO_DISK_DEVICE> status=progress

1.8 ダウンストリームノード を起動します

 

インストールメディアを作成しましたので、それを使用してダウンストリームノードを起動できます。

Elemental で制御する各システムについて、インストールメディアを追加してデバイスを起動してください。インストール後、システムは再起動し、自動的に登録されます。

UI 拡張機能を使用している場合は、「Inventory of Machines」にノードが表示されるはずです。

注記
注記

ログインプロンプトが表示されるまでインストールメディアを取り外さないでください。初回起動時は、USBスティック上のファイルにまだアクセスしています。

1.9 ダウンストリームクラスタ群を作成する

 

Elementalを使用して新しいクラスタをプロビジョニングする際に作成する必要があるオブジェクトが2つあります。

  • Linux
  • UI拡張機能

1つ目は MachineInventorySelectorTemplate です。このオブジェクトを使用すると、クラスタとインベントリ内のマシン間のマッピングを指定できます。

  1. インベントリ内のラベルを持つ任意のマシンに一致するセレクタを作成します：

    cat << EOF > $ELEM/selector.yaml
apiVersion: elemental.cattle.io/v1beta1
kind: MachineInventorySelectorTemplate
metadata:
  name: location-123-selector
  namespace: fleet-default
spec:
  template:
    spec:
      selector:
        matchLabels:
          locationID: '123'
EOF

  2. リソースをクラスタに適用します：

    kubectl apply -f $ELEM/selector.yaml

  3. マシンの名前を取得し、一致するラベルを追加します：

    MACHINENAME=$(kubectl get MachineInventory -n fleet-default | awk 'NR>1 {print $1}')

kubectl label MachineInventory -n fleet-default \
 $MACHINENAME locationID=123

  4. シンプルなシングルノードのK3sクラスタリソースを作成し、それをクラスタに適用します：

    cat << EOF > $ELEM/cluster.yaml
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
  name: location-123
  namespace: fleet-default
spec:
  kubernetesVersion: v1.35.4+k3s1
  rkeConfig:
    machinePools:
      - name: pool1
        quantity: 1
        etcdRole: true
        controlPlaneRole: true
        workerRole: true
        machineConfigRef:
          kind: MachineInventorySelectorTemplate
          name: location-123-selector
          apiVersion: elemental.cattle.io/v1beta1
EOF

kubectl apply -f $ELEM/cluster.yaml

これらのオブジェクトを作成すると、インストールしたばかりの新しいノードを使用して新しいKubernetesクラスターが起動するのを確認できるはずです。

1.10 ノードのリセット（オプション）

 

SUSE Rancher Elementalは「ノードリセット」を実行する機能をサポートしており、Rancherからクラスター全体が削除された場合、クラスターから単一のノードが削除された場合、またはマシンインベントリからノードが手動で削除された場合に、オプションでトリガーできます。これは、孤立したリソースをリセットしてクリーンアップし、クリーンアップされたノードを自動的にマシンインベントリに戻して再利用できるようにしたい場合に便利です。これはデフォルトでは有効になっていないため、削除されたシステムはクリーンアップされません（つまり、データは削除されず、Kubernetesクラスターリソースはダウンストリームクラスター上で動作し続けます）。そのため、データを消去し、Elementalを介してマシンをRancherに再登録するには手動での介入が必要になります。

この機能をデフォルトで有効にしたい場合は、`MachineRegistration`で`config.elemental.reset.enabled: true`を追加して明示的に有効にする必要があります。例：

config:
  elemental:
    registration:
      auth: tpm
    reset:
      enabled: true

そうすれば、この`MachineRegistration`に登録されているすべてのシステムは、設定内に`elemental.cattle.io/resettable: 'true'`アノテーションを自動的に受け取ります。個々のノードでこれらを手動で行いたい場合（例：このアノテーションがない既存の`MachineInventory`がある場合や、すでにノードをデプロイ済みの場合など）、`MachineInventory`を変更して`resettable`設定を追加できます。例：

apiVersion: elemental.cattle.io/v1beta1
kind: MachineInventory
metadata:
  annotations:
    elemental.cattle.io/os.unmanaged: 'true'
    elemental.cattle.io/resettable: 'true'

SUSE Edge 3.1では、Elemental Operatorがオペレーティングシステム上にマーカーを配置し、それが自動的にクリーンアッププロセスをトリガーします。これにより、すべてのKubernetesサービスが停止され、すべての永続データが削除され、すべてのKubernetesサービスがアンインストールされ、残っているKubernetes/Rancherディレクトリがクリーンアップされ、元のElemental MachineRegistration`設定を介してRancherへの再登録が強制されます。これは自動的に行われるため、手動で介入する必要はありません。呼び出されるスクリプトは/opt/edge/elemental_node_cleanup.sh`にあり、マーカーが配置されると`systemd.path`を介してトリガーされるため、即座に実行されます。

警告
警告

`resettable`機能を使用する場合、Rancherからノードやクラスターを削除した際の動作として、データを消去して再登録を強制することが前提となります。この状況ではデータが確実に失われるため、自動リセットを実行することが確実な場合にのみ使用してください。

1.11 次のステップ

 

このガイドを使用した後に調査することをお勧めするリソースをいくつか紹介します。

2 Edge Image Builderを使用したスタンドアロンクラスター

 

Edge Image Builder (EIB) は、完全にエアギャップされたシナリオであっても、マシンの起動用にカスタマイズされた起動可能な (CRB) ディスクイメージを生成するプロセスを効率化するツールです。EIBは、SUSE Edgeの3つのデプロイメントフットプリントすべてで使用するデプロイメントイメージを作成するために使用されます。ユーザーの追加やタイムゾーンの設定といった最小限のカスタマイズから、複雑なネットワーク構成の設定、マルチノードKubernetesクラスターのデプロイメント、顧客ワークロードのデプロイメント、Rancher/ElementalおよびSUSE Multi-Linux Managerを介した集中管理プラットフォームへの登録など、包括的に構成されたイメージの提供まで、柔軟に対応できます。EIBはコンテナイメージ内で実行されるため、プラットフォーム間で非常に移植性が高く、必要なすべての依存関係が自己完結しているため、ツールを操作するために使用されるシステムのインストール済みパッケージへの影響を最小限に抑えることができます。

注記
注記

マルチノードシナリオの場合、EIBはMetalLBとEndpoint Copier Operatorを自動的にデプロイし、同じビルド済みイメージを使用してプロビジョニングされたホストが自動的にKubernetesクラスターに参加できるようにします。

詳細については、Edge Image Builderの概要 (第8章 「Edge Image Builder」)をお読みください。

警告
警告

Edge Image Builder 1.3.3.1は、SUSE Linux Micro 6.2イメージのカスタマイズをサポートしています。 SUSE Linux Enterprise Micro 5.5や6.0などの古いバージョンはサポートされていません。

2.1 前提条件

 
注記
注記

非本番環境の目的であれば、openSUSE Leap 15.6またはopenSUSE Tumbleweedをビルドホストマシンとして使用できます。 互換性のあるコンテナランタイムが利用可能であれば、他のオペレーティングシステムでも機能する可能性があります。

2.1.1 EIBイメージの取得

 

EIBコンテナイメージは公開されており、イメージビルドホストで以下のコマンドを実行することで、SUSE Edgeレジストリからダウンロードできます。

podman pull registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1

2.2 イメージ設定ディレクトリの作成

 

EIBはコンテナ内で実行されるため、ホストから設定ディレクトリをマウントする必要があります。これにより、目的の設定を指定できるようになり、ビルドプロセス中にEIBが必要な入力ファイルやサポートアーティファクトにアクセスできるようになります。このディレクトリは特定の構造に従う必要があります。このディレクトリがホームディレクトリに存在し、「eib」という名前であると想定して作成しましょう。

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR/base-images

前のステップで、SUSE Linux Micro 6.2入力イメージをホストする「base-images」ディレクトリを作成しました。イメージが設定ディレクトリにコピーされていることを確認しましょう。

cp /path/to/SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso $CONFIG_DIR/base-images/slemicro.iso
注記
注記

EIBの実行中、元のベースイメージは*変更されません*。EIB設定ディレクトリのルートに、目的の設定が適用された新しいカスタマイズ済みバージョンが作成されます。

この時点での設定ディレクトリは、以下のようになっているはずです。

└── base-images/
    └── slemicro.iso

2.3 イメージ定義ファイルの作成

 

定義ファイルには、Edge Image Builderがサポートする構成可能なオプションの大部分が記述されています。オプションの完全な例はhttps://github.com/suse-edge/edge-image-builder/blob/release-1.3/pkg/image/testdata/full-valid-example.yaml[こちら]で確認できます。また、以下で説明するものよりも包括的な例については、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/building-images.md[アップストリームのイメージ構築ガイド]を参照することをお勧めします。OSイメージ用の非常に基本的な定義ファイルから始めましょう。

cat << EOF > $CONFIG_DIR/iso-definition.yaml
apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
EOF

この定義は、AMD64/Intel 64ベースのシステムの出力イメージを生成することを指定しています。さらなる変更のベースとして使用されるイメージは、iso`イメージで、名前は`slemicro.iso、$CONFIG_DIR/base-images/slemicro.iso`に配置されていることが想定されています。また、EIBによるイメージの変更完了後、出力イメージには`eib-image.iso`という名前が付けられ、デフォルトでは$CONFIG_DIR`に配置されることも示されています。

これで、ディレクトリ構造は以下のようになっているはずです。

├── iso-definition.yaml
└── base-images/
    └── slemicro.iso

以下のセクションでは、一般的な操作の例をいくつか説明します。

2.3.1 オペレーティングシステム（OS）の設定

 

EIBの`operatingSystem`セクションは、オペレーティングシステムのインストール先やイメージサイズなどを設定するためのものです。 これはオプションのセクションであり、1つ以上のカスタマイズを適用する場合を除き、含める必要はありません。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-Base-RT-SelfInstall.iso
operatingSystem:
  isoConfiguration:
    installDevice: /dev/disk/by-id/ata-QEMU_HARDDISK_111-disk1 # first defined disk

タイプ固有の設定. カスタマイズするイメージのタイプに応じて、以下のオプションセクションのいずれかを含めることができます。

  • isoConfiguration - オプション。このセクションの設定はISOイメージにのみ適用されます。

  • installDevice - オプション。インストールデバイスとして使用するディスクを指定します。これはブロックデバイスである必要があり、デフォルトではディスク上のデータは自動的に消去されます。 さらに、この属性を指定するとGRUBオーバーライドがトリガーされ、ユーザーにインストール開始を促すことなくオペレーティングシステムが自動的にインストールされるため、完全に無人で自動化されたインストールが可能になります。省略した場合、ユーザーはGRUBメニューから「Install」オプションを選択する必要があり、さらにインストールディスクの選択や、その過程でデバイスが消去されることの確認も求められます。

    注記
    注記

    installDevice`セクションで使用されるデバイスは、/dev/sda`として指定するか、/dev/disk/by-id、/dev/disk/by-path`という命名規則を使用して、適切なデバイスが使用されていることを確認できます。 libvirt VMを使用している場合、VMのディスクを作成する際に`serial`属性値を指定できます（例：`serial=111-disk1）。これにより、installDevice`値で`by-id`という命名規則（例：/dev/disk/by-id/ata-QEMU_HARDDISK_111-disk1`）を使用して使用できるようになります（ATAデバイスを使用している場合、`libvirt`は自動的にIDの先頭に`ata-QEMU_HARDDISK_`を付加します。virtioデバイスの場合は`virtio-`を付加します。詳細については、 #17670 virtio issueを参照してください）。

  • rawConfiguration - オプション。このセクションの設定は、RAWイメージにのみ適用されます。

  • diskSize - オプション。EIBが最終的なイメージをリサイズする際に設定する、希望するRAWディスクイメージサイズを指定します。これは、ディスクイメージが、イメージに埋め込まれるあらゆるアーティファクトを収容できる十分な大きさであることを確認するために重要です。システムが起動時に自動的に拡張されてブロックデバイスのサイズを満たすため、SDカードのサイズ（直接ディスクに書き込む場合はブロックデバイスのサイズ）よりわずかに小さく設定することをお勧めします。これはオプションですが、強く推奨されます。「M」（メガバイト）、「G」（ギガバイト）、または「T」（テラバイト）をサフィックスとして付けた整数で指定します（例：「32G」）。

  • luksKey - 暗号化されたイメージには必須です。暗号化されたRAWイメージに対して指定されたLUKSキーは、EIBがビルドプロセスを完了するために必要です。

  • expandEncryptedPartition - オプション。デフォルトでは無効になっています。有効にすると、暗号化されたパーティションが自動的に最大サイズまで拡張されます。例：`diskSize`が`25G`で、このフィールドが`true`の場合、EIBはビルドプロセス中に暗号化されたパーティションを`25G`まで拡張します。

2.3.2 OSユーザーの設定

 

EIBでは、パスワードやSSHキーなどのログイン情報を持つユーザーを事前に設定でき、固定のrootパスワードを設定することも可能です。この例の一部としてrootパスワードを固定します。最初のステップは、`OpenSSL`を使用して一方向暗号化されたパスワードを作成することです。

openssl passwd -6 SecurePassword

これにより、以下のような出力が得られます。

$6$G392FCbxVgn[...]Y7zTXnC1

次に、定義ファイルに`operatingSystem`というセクションを追加し、その中に`users`配列を含めることができます。結果として得られるファイルは、以下のようになります。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgn[...]Y7zTXnC1
注記
注記

さらにユーザーを追加したり、ホームディレクトリを作成したり、ユーザーIDを設定したり、SSHキー認証を追加したり、グループ情報を変更したりすることも可能です。その他の例については、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/building-images.md[アップストリームのイメージ構築ガイド]を参照してください。

2.3.3 OS時刻の設定

 

time`セクションはオプションですが、証明書やクロックスキューに関する潜在的な問題を回避するために設定することを強く推奨します。EIBは、ここでのパラメータに応じてchronydおよび/etc/localtime`を設定します。

operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2

  • `timezone`は、「地域/場所」（例:「Europe/London」）の形式でタイムゾーンを指定します。完全なリストは、Linuxシステムで`timedatectl list-timezones`を実行することで確認できます。

  • ntp - NTPの設定に関連する属性を定義します（chronydを使用）：

  • forceWait - 他のサービスを開始する前に、chronydがタイムソースの同期を試みるよう要求します（タイムアウトは180秒）。

  • pools - chronydがデータソースとして使用するプールのリストを指定します（`iburst`を使用して初期同期にかかる時間を短縮します）。

  • servers - chronydがデータソースとして使用するサーバーのリストを指定します（`iburst`を使用して初期同期にかかる時間を短縮します）。

注記
注記

この例で提供されている値は、説明のみを目的としています。お客様の特定の要件に合わせて調整してください。

2.3.4 証明書の追加

 

`certificates`ディレクトリに保存されている拡張子が「.pem」または「.crt」の証明書ファイルは、ノードのシステム全体の証明書ストアにインストールされます。

.
├── definition.yaml
└── certificates
    ├── my-ca.pem
    └── my-ca.crt

詳細については、 「TLS証明書による通信の保護」ガイドを参照してください。

2.3.5 オペレーティングシステムファイルの追加

 

イメージ構成ディレクトリの`os-files`ディレクトリに配置されたファイルは、ビルドされたイメージのファイルシステムに自動的にコピーされます。 コピーされる際、正確なディレクトリ構造が保持されます。 例えば、ファイルが`os-files/etc`という名前のサブディレクトリに存在する場合、そのファイルはビルドされたイメージの`/etc`ディレクトリに配置されます。

注記
注記

`os-files`ディレクトリが存在する場合、空であってはなりません。

.
├── definition.yaml
└── os-files
    └── etc
        └── ssh
            └── sshd_config

2.3.6 RPMパッケージの設定

 

EIBの主な機能の1つは、イメージに追加のソフトウェアパッケージを追加するメカニズムを提供することです。これにより、インストール完了時にシステムがインストールされたパッケージをすぐに活用できるようになります。EIBでは、ユーザーは以下を指定できます。

  • イメージ定義内のリストによるパッケージ名での指定

  • これらのパッケージを検索するネットワークリポジトリ

  • リストされたパッケージを公式のSUSEリポジトリから検索するためのSUSE Customer Center (SCC) 認証情報

  • `$CONFIG_DIR/rpms`ディレクトリを介した、ネットワークリポジトリに存在しないカスタムRPMのサイドロード

  • 同じディレクトリ（$CONFIG_DIR/rpms/gpg-keys）を介した、サードパーティパッケージの検証を有効にするためのGPGキー

EIBは、イメージビルド時にパッケージ解決処理を実行します。ベースイメージを入力として受け取り、リストで指定されたか、ローカルで提供されたすべてのパッケージの取得とインストールを試みます。EIBは、すべてのパッケージを依存関係を含めて出力イメージ内のリポジトリにダウンロードし、最初の起動プロセス中にこれらをインストールするようにシステムに指示します。このプロセスをイメージビルド中に実行することで、エッジノードなどの目的のプラットフォームで、初回起動時にパッケージが確実にインストールされるようになります。これは、運用中にネットワーク経由でパッケージを取得するのではなく、追加パッケージをイメージに組み込んでおきたい環境（エアギャップ環境やネットワークが制限された環境など）でも有利です。

これを実証する簡単な例として、サードパーティのベンダーがサポートするNVIDIAリポジトリにある`nvidia-container-toolkit` RPMパッケージをインストールします。

  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

結果として得られる定義ファイルは次のようになります。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgn[...]Y7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

上記は簡単な例ですが、念のため、イメージ生成を実行する前にNVIDIAパッケージ署名キーをダウンロードしてください。

$ mkdir -p $CONFIG_DIR/rpms/gpg-keys
$ curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey > $CONFIG_DIR/rpms/gpg-keys/nvidia.gpg
警告
警告

この方法でRPMを追加することは、サポートされているサードパーティ製コンポーネントや、ユーザーが提供（および保守）するパッケージを追加することを目的としています。このメカニズムは、通常SUSE Linux Microでサポートされないパッケージの追加には使用しないでください。このメカニズムを使用して（サポートされていない）openSUSEリポジトリからコンポーネントを追加した場合（新しいリリースやサービスパックからのものを含む）、依存関係の解決によってオペレーティングシステムのコア部分が置き換えられ、結果としてシステムが期待通りに動作しているように見えても、サポート対象外の構成になる可能性があります。不明な点がある場合は、SUSEの担当者に連絡し、希望する構成がサポート可能かどうかを確認してください。

注記
注記

追加の例を含むより包括的なガイドは、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/installing-packages.md[アップストリームのパッケージインストールガイド]にあります。

2.3.7 Kubernetesクラスターとユーザーワークロードの設定

 

EIBのもう一つの特徴は、単一ノードおよびマルチノードの高可用性Kubernetesクラスターのデプロイを自動化するために使用できることです。これらは「インプレースで起動」されます（つまり、調整のための集中管理インフラストラクチャを一切必要としません）。このアプローチの主な目的は、エアギャップ環境やネットワーク制限のある環境でのデプロイですが、完全かつ無制限のネットワークアクセスが利用可能な場合でも、スタンドアロンクラスターを迅速に起動する方法としても機能します。

この方法により、カスタマイズされたオペレーティングシステムのデプロイだけでなく、Kubernetes構成、Helmチャートを介した追加のレイヤーコンポーネント、および提供されたKubernetesマニフェストを介したユーザーワークロードを指定することも可能になります。ただし、この方法を使用する背後にある設計原則は、ユーザーがエアギャップを望んでいるとデフォルトで想定することです。したがって、イメージ定義で指定されたすべてのアイテムはイメージ内に取り込まれ、これにはユーザーが提供したワークロードも含まれます。EIBは、定義によって必要とされる検出されたイメージがローカルにコピーされ、結果としてデプロイされたシステム内の組み込みイメージレジストリによって提供されることを保証します。

次の例では、既存のイメージ定義を使用してKubernetes構成を指定します（この例ではシステムとその役割がリストされていないため、デフォルトで単一ノードと想定します）。これにより、EIBは単一ノードのRKE2 Kubernetesクラスターをプロビジョニングするように指示されます。ユーザーが提供したワークロード（マニフェスト経由）とレイヤーコンポーネント（Helm経由）の両方のデプロイの自動化を示すために、SUSE Edge Helmチャートを介してKubeVirtをインストールし、Kubernetesマニフェストを介してNGINXをインストールします。既存のイメージ定義に追加する必要がある追加の構成は次のとおりです。

kubernetes:
  version: v1.35.4+rke2r1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt
        version: 306.0.2+up0.7.0
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge/charts

結果として得られる完全な定義ファイルは、次のようになります。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgn[...]Y7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64
kubernetes:
  version: v1.35.4+k3s1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt
        version: 306.0.2+up0.7.0
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge/charts
注記
注記

マルチノードデプロイメント、カスタムネットワーク、Helmチャートのオプション/値などのその他の例については、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/building-images.md[アップストリームドキュメント]を参照してください。

2.3.8 ネットワークの設定

 

このクイックスタートの最後の例では、EIBによって生成されたイメージでシステムがプロビジョニングされる際に立ち上がるネットワークを設定してみましょう。ネットワーク設定が提供されない限り、デフォルトのモデルでは、起動時に検出されたすべてのインターフェースでDHCPが使用されることを理解しておくことが重要です。しかし、これは必ずしも望ましい設定とは限りません。特にDHCPが利用できず、静的設定を提供する必要がある場合や、ボンド、LACP、VLANなどのより複雑なネットワーク設定を行う必要がある場合、あるいはホスト名、DNSサーバー、ルートなどの特定のパラメータを上書きする必要がある場合には特にそうです。

EIBは、対象システムがMACアドレスにより一意に識別される場合にノードごとに設定を適用するか、すべてのマシンに同一の設定を上書き適用するオプションを提供します。これは、システムのMACアドレスが不明な場合に特に有用です。EIBは、Network Manager Configurator（略して`nmc`）という追加ツールを使用します。これはSUSE Edgeチームによって構築されたツールで、 nmstate.io宣言型ネットワークスキーマに基づいてカスタムネットワーク設定を適用できるようにするものです。起動時に、起動中のノードを識別し、サービスが立ち上がる前に目的のネットワーク設定を適用します。

次に、必要な`network`ディレクトリ内のノード固有のファイル（目的のホスト名に基づく）に目的のネットワーク状態を記述することで、単一インターフェースを持つシステムの静的ネットワーク設定を適用します。

mkdir $CONFIG_DIR/network

cat << EOF > $CONFIG_DIR/network/host1.local.yaml
routes:
  config:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
dns-resolver:
  config:
    server:
    - 192.168.122.1
    - 8.8.8.8
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: 34:8A:B1:4B:16:E7
  ipv4:
    address:
    - ip: 192.168.122.50
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    enabled: false
EOF
警告
警告

上記の例は、仮想マシン上でテストが実行されていることを前提として、デフォルトの`192.168.122.0/24`サブネット用に設定されています。MACアドレスを忘れないように、環境に合わせて調整してください。同じイメージを使用して複数のノードをプロビジョニングできるため、EIB（`nmc`経由）によって構成されるネットワークは、MACアドレスによってノードを一意に識別できるかどうかに依存します。そのため、起動中に`nmc`が各マシンに正しいネットワーク設定を適用します。つまり、インストール先のシステムのMACアドレスを知っておく必要があるということです。あるいは、デフォルトの動作はDHCPに依存することですが、`configure-network.sh`フックを利用してすべてのノードに共通の設定を適用することもできます。詳細については、ネットワークガイド (第9章 「エッジネットワーキング」)を参照してください。

結果として得られるファイル構造は次のようになります:

├── iso-definition.yaml
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

作成したネットワーク設定が解析され、必要なNetworkManager接続ファイルが自動的に生成されて、EIBによって作成される新しいインストールイメージに挿入されます。これらのファイルはホストのプロビジョニング中に適用され、完全なネットワーク設定が適用されます。

注記
注記

上記の設定に関するより包括的な説明とこの機能の例については、エッジネットワーキングコンポーネント (第9章 「エッジネットワーキング」)を参照してください。

2.4 イメージのビルド

 

ベースイメージとEIBが使用するイメージ定義が準備できたので、イメージをビルドしましょう。これには、単に`podman`を使用して「build」コマンドでEIBコンテナを呼び出し、定義ファイルを指定します:

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file iso-definition.yaml

コマンドの出力は次のようになります:

Setting up Podman API listener...
Downloading file: dl-manifest-1.yaml 100% (498/498 B, 9.5 MB/s)
Pulling selected Helm charts... 100% (1/1, 43 it/min)
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Resolving package dependencies...
Rpm .......................... [SUCCESS]
Os Files ..................... [SKIPPED]
Systemd ...................... [SKIPPED]
Fips ......................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Populating Embedded Artifact Registry... 100% (3/3, 10 it/min)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Downloading file: rke2-images-core.linux-amd64.tar.zst 100% (657/657 MB, 48 MB/s)
Downloading file: rke2-images-cilium.linux-amd64.tar.zst 100% (368/368 MB, 48 MB/s)
Downloading file: rke2.linux-amd64.tar.gz 100% (35/35 MB, 50 MB/s)
Downloading file: sha256sum-amd64.txt 100% (4.3/4.3 kB, 6.2 MB/s)
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Cleanup ...................... [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Build complete, the image can be found at: eib-image.iso

ビルドされたISOイメージは`$CONFIG_DIR/eib-image.iso`に保存されます:

├── iso-definition.yaml
├── eib-image.iso
├── _build
│   └── cache/
│       └── ...
│   └── build-<timestamp>/
│       └── ...
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

各ビルドは、`$CONFIG_DIR/_build/`内にタイムスタンプ付きのフォルダーを作成します。これには、ビルドのログ、ビルド中に使用されたアーティファクト、およびCRBイメージに追加されるすべてのスクリプトとアーティファクトを含む`combustion`ディレクトリと`artefacts`ディレクトリが含まれます。

このディレクトリの内容は次のようになります:

├── build-<timestamp>/
│   │── combustion/
│   │   ├── 05-configure-network.sh
│   │   ├── 10-rpm-install.sh
│   │   ├── 12-keymap-setup.sh
│   │   ├── 13b-add-users.sh
│   │   ├── 20-k8s-install.sh
│   │   ├── 26-embedded-registry.sh
│   │   ├── 48-message.sh
│   │   ├── network/
│   │   │   ├── host1.local/
│   │   │   │   └── eth0.nmconnection
│   │   │   └── host_config.yaml
│   │   ├── nmc
│   │   └── script
│   │── artefacts/
│   │   │── registry/
│   │   │   ├── hauler
│   │   │   ├── nginx:<version>-registry.tar.zst
│   │   │   ├── rancher_kubectl:<version>-registry.tar.zst
│   │   │   └── registry.suse.com_suse_sles_15.6_virt-operator:<version>-registry.tar.zst
│   │   │── rpms/
│   │   │   └── rpm-repo
│   │   │       ├── addrepo0
│   │   │       │   ├── nvidia-container-toolkit-<version>.rpm
│   │   │       │   ├── nvidia-container-toolkit-base-<version>.rpm
│   │   │       │   ├── libnvidia-container1-<version>.rpm
│   │   │       │   └── libnvidia-container-tools-<version>.rpm
│   │   │       ├── repodata
│   │   │       │   ├── ...
│   │   │       └── zypper-success
│   │   └── kubernetes/
│   │       ├── rke2_installer.sh
│   │       ├── registries.yaml
│   │       ├── server.yaml
│   │       ├── images/
│   │       │   ├── rke2-images-cilium.linux-amd64.tar.zst
│   │       │   └── rke2-images-core.linux-amd64.tar.zst
│   │       ├── install/
│   │       │   ├── rke2.linux-amd64.tar.gz
│   │       │   └── sha256sum-amd64.txt
│   │       └── manifests/
│   │           ├── dl-manifest-1.yaml
│   │           └── kubevirt.yaml
│   ├── createrepo.log
│   ├── eib-build.log
│   ├── embedded-registry.log
│   ├── helm
│   │   └── kubevirt
│   │       └── kubevirt-0.4.0.tgz
│   ├── helm-pull.log
│   ├── helm-template.log
│   ├── iso-build.log
│   ├── iso-build.sh
│   ├── iso-extract
│   │   └── ...
│   ├── iso-extract.log
│   ├── iso-extract.sh
│   ├── modify-raw-image.sh
│   ├── network-config.log
│   ├── podman-image-build.log
│   ├── podman-system-service.log
│   ├── prepare-resolver-base-tarball-image.log
│   ├── prepare-resolver-base-tarball-image.sh
│   ├── raw-build.log
│   ├── raw-extract
│   │   └── ...
│   └── resolver-image-build
│       └──...
└── cache
    └── ...

ビルドが失敗した場合、`eib-build.log`が情報を含む最初のログとなります。そこから、デバッグのために失敗したコンポーネントへと案内されます。

この時点で、すぐに使用できるイメージが用意できているはずです:

  1. SUSE Linux Micro 6.2をデプロイする

  2. ルートパスワードを設定する

  3. `nvidia-container-toolkit`パッケージをインストールする

  4. コンテンツをローカルで提供するように組み込みコンテナレジストリを設定する

  5. シングルノードのRKE2をインストールする

  6. 静的ネットワーク設定を行う

  7. KubeVirtをインストールします

  8. ユーザーが提供したマニフェストをデプロイします

2.5 イメージビルドプロセスのデバッグ

 

イメージビルドプロセスが失敗した場合は、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/debugging.md[アップストリームのデバッグガイド]を参照してください。

2.6 新しくビルドしたイメージのテスト

 

新しくビルドしたCRBイメージのテスト方法については、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/testing-guide.md[アップストリームのイメージテストガイド]を参照してください。

3 SUSE Multi-Linux Manager

 
警告
警告

SUSE Edge 3.6 (5.0.6) に含まれているSUSE Multi-Linux Managerのバージョンは、SUSE Linux Micro 6.2をまだサポートしていません。これは将来のSUSE Edge 3.6リリースで更新され、サポートされる予定です。

SUSE Multi-Linux ManagerはSUSE Edgeに含まれており、エッジデプロイメントのすべてのノードでSUSE Linux Microを基盤となるオペレーティングシステムとして一貫して最新の状態に保つための自動化と制御を提供します。また、エッジノード上のKubernetesおよびKubernetesにデプロイされたアプリケーションの管理にも使用できます。

このクイックスタートガイドは、エッジノードにオペレーティングシステムの更新を提供することを目的として、SUSE Multi-Linux Managerをできるだけ早く使いこなせるようにすることを意図しています。このクイックスタートガイドでは、ストレージのサイジング、ステージング目的での追加ソフトウェアチャネルの作成と管理、または大規模なデプロイメントのためのユーザー、システムグループ、組織の管理といったトピックについては説明していません。本番環境で使用する場合は、包括的な SUSE Multi-Linux Manager Documentationに目を通すことを強くお勧めします。

SUSE Multi-Linux Managerを効果的に使用するためにSUSE Edgeを準備するには、以下のステップが必要です。

  • SUSE Multi-Linux Manager Serverをデプロイおよび設定します。

  • SUSE Linux Microパッケージリポジトリを同期します。

  • システムグループを作成します。

  • 起動キーを作成します。

  • Edge Image Builderを使用して、SUSE Multi-Linux Manager登録用のインストールメディアを準備します。

3.1 SUSE Multi-Linux Manager Serverのデプロイ

 

SUSE Multi-Linux Manager 5.1のインスタンスが既に実行されている場合は、このステップをスキップできます。

SUSE Multi-Linux Manager Serverは、専用の物理サーバー上、自身のハードウェア上の仮想マシンとして、またはクラウド内で実行できます。SUSE Multi-Linux Server用の事前設定済み仮想マシンイメージが、サポートされているパブリッククラウド向けに提供されています。

このクイックスタートでは、 https://www.suse.com/download/suse-manager/またはSUSE Customer Centerで見つけることができる、AMD64/Intel 64用の「qcow2」イメージ`SUSE-Manager-Server.x86_64-5.0.4-Qcow-5.0-2025-04.qcow2`を使用します。このイメージは、KVMなどのハイパーバイザー上で仮想マシンとして機能します。常に最新バージョンのイメージを確認し、新規インストールにはそれを使用してください。

SUSE Multi-Linux Manager Serverは、サポートされている他のハードウェアアーキテクチャにもインストールできます。その場合は、ハードウェアアーキテクチャに一致するイメージを選択してください。

イメージをダウンロードしたら、少なくとも以下の最小ハードウェア仕様を満たす仮想マシンを作成します。

  • 16 GB RAM

  • 4つの物理コアまたは仮想コア

  • 少なくとも100GBの追加ブロックデバイス

qcow2イメージを使用する場合、オペレーティングシステムをインストールする必要はありません。イメージをルートパーティションとして直接接続できます。

エッジノードが後で完全修飾ドメイン名（「FQDN」）を含むホスト名でSUSE Multi-Linux Manager Serverにアクセスできるように、ネットワークを設定する必要があります。

SUSE Multi-Linux Managerを初めて起動するときは、いくつかの初期設定を行う必要があります。

  • キーボードレイアウトを選択します。

  • ライセンス契約を承認します。

  • タイムゾーンを選択します。

  • オペレーティングシステムのrootパスワードを入力します。

次の手順は、「root」ユーザーとして実行する必要があります。

次のステップでは、SUSE Customer Centerで確認できるSUSE Multi-Linux Manager Extensionの登録コードが必要です。同じコードを、SUSE Linux MicroとSUSE Multi-Linux Managerの両方の登録に使用できます。

SUSE Linux Microを登録します。

transactional-update register -r <REGCODE> -e <your_email>

SUSE Multi-Linux Managerを登録します。

transactional-update register -p SUSE-Manager-Server/5.0/x86_64 -r <REGCODE>

製品文字列は、ハードウェアアーキテクチャによって異なります。例えば、64ビットArmシステムでSUSE Multi-Linux Managerを使用している場合、文字列は「SUSE-Manager-Server/5.0/aarch64」となります。

再起動

システムを更新

transactional-update

変更がなかった場合を除き、再起動して更新を適用します。

SUSE Multi-Linux Managerは、Podmanによって管理されるコンテナを介して提供されます。`mgradm`コマンドがセットアップと設定を処理します。

警告
警告

SUSE Multi-Linux Manager Serverのホスト名が、管理対象のエッジノードがネットワーク内で適切に解決できる完全修飾ドメイン名（「FQDN」）で構成されていることが非常に重要です。

SUSE Multi-Linux Manager Serverコンテナをインストールおよび設定する前に、以前に追加した追加のブロックデバイスを準備する必要があります。そのためには、仮想マシンがそのデバイスに割り当てた名前を知る必要があります。例えば、ブロックデバイスが`/dev/vdb`である場合、次のコマンドを使用してSUSE Multi-Linux Managerで使用するように設定できます。

mgr-storage-server /dev/vdb

SUSE Multi-Linux Managerをデプロイ

mgradm install podman <FQDN>

CA証明書のパスワードを指定します。このパスワードは、ログインパスワードとは異なるものにする必要があります。通常、後で入力する必要はありませんが、書き留めておくことをお勧めします。

「admin」ユーザのパスワードを指定します。これは、SUSE Multi-Linux Managerにログインするための初期ユーザです。後で、フル権限または制限付き権限を持つ追加ユーザを作成できます。

3.2 SUSE Multi-Linux Managerの設定

 

デプロイが完了したら、先ほど指定したホスト名を使用してSUSE Multi-Linux ManagerのWeb UIにログインできます。初期ユーザは「admin」です。前の手順で指定したパスワードを使用してください。

次の手順では、SUSE Customer Centerの組織の「Users」タブの2番目のサブタブにある組織認証情報が必要です。これらの認証情報を使用して、SUSE Multi-Linux Managerはサブスクリプションを持つすべての製品を同期できます。

`Admin > Setup Wizard`を選択します。

`Organization Credentials`タブで、SUSE Customer Centerで見つけた`Username`と`Password`を使用して新しい認証情報を作成します。

次のタブ`SUSE Products`を開きます。SUSE Customer Centerとの最初のデータ同期が完了するまで待つ必要があります。

リストにデータが表示されたら、フィルターを使用して「Micro 6.2」のみを表示します。 エッジノードが動作するハードウェアアーキテクチャ（x86_64`または`aarch64）用のSUSE Linux Micro 6.2のチェックボックスにチェックを入れてください。

`Add Products`をクリックします。これにより、SUSE Linux Microのメインパッケージリポジトリ（「チャネル」）が追加され、SUSE Managerクライアントツールのチャネルがサブチャネルとして自動的に追加されます。

インターネット接続によっては、最初の同期に時間がかかります。次の手順を開始できます。

`Systems > System Groups`の下で、システムがオンボードされたときに自動的に参加するグループを少なくとも1つ作成します。グループはシステムを分類する重要な方法であり、構成やアクションを一連のシステム全体に一度に適用できます。これらは概念的にKubernetesのラベルと似ています。

ユーティリティメニューの`+ Create Group`をクリックし、

短い名前（例：「Edge Nodes」）と長い説明を入力します。

`Systems > Activation Keys`の下で、アクティベーションキーを少なくとも1つ作成します。アクティベーションキーは、システムがSUSE Multi-Linux Managerにオンボードされるときに自動的に適用される構成プロファイルと考えることができます。特定のエッジノードを別のグループに追加したり、異なる構成を使用したりする場合は、それらのために別個のアクティベーションキーを作成し、後でEdge Image Builderで使用してカスタマイズされたインストールメディアを作成できます。

アクティベーションキーの一般的な高度な使用例としては、テストクラスターを最新のアップデートを含むソフトウェアチャネルに割り当て、本番クラスターをテストクラスターでテストした後にのみ最新のアップデートを取得するソフトウェアチャネルに割り当てることが挙げられます。

ユーティリティメニューの`+ Create Key`をクリックし、

短い説明（例：「Edge Nodes」）を選択します。 キーを識別する一意の名前を入力してください（例：AMD64/Intel 64ハードウェアアーキテクチャ対応のエッジノード用「edge-x86_64」）。 キーには番号のプレフィックスが自動的に追加されます。デフォルトの組織の場合、番号は常に「1」です。SUSE Multi-Linux Managerで追加の組織を作成し、それらの組織に対してキーを作成した場合、その番号は異なる可能性があります。

クローンされたソフトウェアチャネルを作成していない場合は、ベースチャネルの設定を「SUSE Manager Default」のままにしておくことができます。これにより、エッジノードに対して正しいSUSE更新リポジトリが自動的に割り当てられます。

「子チャネル」として、アクティベーションキーを使用するハードウェアアーキテクチャの「推奨を含める」スライダーを選択します。これにより、「SUSE-Manager-Tools-For-SL-Micro-6.2」チャネルが追加されます。

「グループ」タブで、以前に作成したグループを追加します。このアクティベーションキーを使用してオンボードされたすべてのノードは、自動的にそのグループに追加されます。

3.3 Edge Image Builderでカスタマイズされたインストールイメージを作成する

 

Edge Image Builderを使用するには、podmanでLinuxベースのコンテナを起動できる環境さえあれば十分です。

最小限のラボ環境であれば、SUSE Multi-Linux Manager Serverが実行されている仮想マシンをそのまま使用することも可能です。仮想マシンに十分なディスク容量があることを確認してください。これは本番環境での使用には推奨されない構成です。Edge Image Builderの動作確認済みホストオペレーティングシステムについては、2.1項 「前提条件」を参照してください。

ルートユーザとしてSUSE Multi-Linux Manager Serverホストにログインします。

Edge Image Builderコンテナをプルします。

podman pull registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1

ディレクトリ`/opt/eib`とサブディレクトリ`base-images`を作成します。

mkdir -p /opt/eib/base-images

このクイックスタートでは、SUSE Linux Microイメージの「self-install」フレーバーを使用します。そのイメージは、後で物理的なUSBメモリに書き込み、物理サーバーへのインストールに使用できます。サーバーにBMC（ベースボード管理コントローラー）経由でインストールISOをリモート接続するオプションがある場合は、その方法を使用することもできます。最後に、そのイメージはほとんどの仮想化ツールでも使用できます。

イメージを物理ノードに直接プリロードするか、VMから直接起動したい場合は、「raw」イメージフレーバーを使用することもできます。

これらのイメージは、SUSEカスタマーセンターまたは https://www.suse.com/download/sle-micro/にあります。

イメージ`SL-Micro.x86_64-6.2-Default-SelfInstall-GM.install.iso`をダウンロードまたはコピーして`base-images`ディレクトリに配置し、「slemicro.iso」という名前を付けます。

Arm®ベースのビルドホスト上でAArch64イメージをビルドすることは、SUSE Edge 3.6におけるテクノロジープレビューです。ほとんどの場合動作しますが、まだサポートされていません。試してみたい場合は、64ビットArmマシン上でPodmanを実行している必要があり、すべての例とコードスニペットの「x86_64」を「aarch64」に置き換える必要があります。

`/opt/eib`に`iso-definition.yaml`という名前のファイルを作成します。これがEdge Image Builderのビルド定義です。

以下は、SL Micro 6.2をインストールし、ルートパスワード、追加ユーザ、キーマップを設定し、CockpitのグラフィカルUIを起動して、ノードをSUSE Multi-Linux Managerに登録する簡単な例です。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
  - username: root
    createHomeDir: true
    encryptedPassword: $6$aaBTHyqDRUMY1HAp$pmBY7.qLtoVlCGj32XR/Ogei4cngc3f4OX7fwBD/gw7HWyuNBOKYbBWnJ4pvrYwH2WUtJLKMbinVtBhMDHQIY0
  - username: admin
    createHomeDir: true
    encryptedPassword: $6$8EGZXU1iFcLiHHxk$Hs3nVtzO.yZhApT.YBHaNvLRZvXG3Iv/km92BtiNiGXhSSUG0ZbNHxlm7c//ROFj3W9M5xIkB.RLQpPKOFxP91
  keymap: de
  systemd:
    enable:
      - cockpit.socket
  packages:
    noGPGCheck: true
  suma:
    host: ${fully qualified hostname of your SUSE Multi-Linux Manager Server}
    activationKey: 1-edge-x86_64

Edge Image Builderは、ネットワークの設定、ノードへのKubernetesの自動インストール、さらにはHelmチャートを使用してアプリケーションをデプロイすることも可能です。より包括的な例については、第2章 「Edge Image Builderを使用したスタンドアロンクラスター」を参照してください。

`baseImage`には、`base-images`ディレクトリ内で使用するISOの実際のファイル名を指定してください。

この例では、ルートパスワードは「root」となります。使用する安全なパスワードのパスワードハッシュを作成する方法については、2.3.2項 「OSユーザーの設定」を参照してください。

Cockpitではルートユーザとしての接続が禁止されているため、追加のユーザーが必要です。この例では、そのユーザーは「admin」で、パスワードも「admin」です。

キーマップは、インストール後にシステムで使用する実際のキーボードレイアウトに設定してください。

注記
注記

RPMパッケージを確認するためのGPGキーを提供しないため、`noGPGCheck: true`オプションを使用します。本番環境での使用を推奨する、より安全な設定を網羅したガイドは、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/installing-packages.md[アップストリーム installing packages guide]で確認できます。

何度か言及したように、SUSE Multi-Linux Managerホストには、エッジノードが起動するネットワーク内で解決可能な完全修飾ホスト名が必要です。

`activationKey`の値は、SUSE Multi-Linux Managerで作成したキーと一致している必要があります。

インストール後にエッジノードをSUSE Multi-Linux Managerに自動的に登録するインストールイメージを構築するには、以下の2つのアーティファクトを準備する必要があります。

  • SUSE Multi-Linux Managerの管理エージェントをインストールするSalt minionパッケージ

  • SUSE Multi-Linux ManagerサーバーのCA証明書

3.3.1 venv-salt-minionパッケージをダウンロードする

 

`/opt/eib`に、サブディレクトリ`rpms`を作成します。

`venv-salt-minion`パッケージをSUSE Multi-Linux Managerサーバーからそのディレクトリにダウンロードします。Web UIから取得する場合は、`Software > Channel List`でパッケージを見つけてSUSE-Manager-Tools …​チャネルからダウンロードするか、curlのようなツールを使用してSUSE Multi-Linux Managerの「起動リポジトリ」からダウンロードできます。

curl -O http://${HOSTNAME_OF_SUSE_MANAGER}/pub/repositories/slmicro/6/1/bootstrap/x86_64/venv-salt-minion-3006.0-8.1.x86_64.rpm

より新しいリリースがすでに公開されている場合、実際のパッケージ名は異なる可能性があります。選択可能なパッケージが複数ある場合は、常に最新のものを選んでください。

SUSE Multi-Linux Managerの リリースノートに記載されている問題を回避するために、最新バージョンのビルドキーパッケージを`rpms`ディレクトリに配置する必要もあります（このドキュメント作成時点では`suse-build-key-12.0-slfo.1.1_3.1.noarch.rpm`）。これは、SL MicroのPoolチャネルの`Packages`タブから、SUSE Multi-Linux Managerの`Software`セクションで見つけることができます。`Details`ビューに`Download`ボタンがあります。

3.4 SUSE Multi-Linux ManagerのCA証明書をダウンロードする

 

`/opt/eib`に、サブディレクトリ`certificates`を作成します。

SUSE Multi-Linux ManagerからCA証明書をそのディレクトリにダウンロードします。

curl -O http://${HOSTNAME_OF_SUSE_MANAGER}/pub/RHN-ORG-TRUSTED-SSL-CERT
警告
警告

証明書の名前を`RHN-ORG-TRUSTED-SSL-CERT.crt`に変更する必要があります。Edge Image Builderは、インストール中にエッジノード上で証明書がインストールされ、有効化されることを確認します。

これで、Edge Image Builderを実行できます。

cd /opt/eib
podman run --rm -it --privileged -v /opt/eib:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file iso-definition.yaml

YAML定義ファイルに別の名前を使用している場合や、別のバージョンのEdge Image Builderを使用したい場合は、それに応じてコマンドを調整する必要があります。

ビルドが完了すると、インストールISOが`/opt/eib`ディレクトリに`eib-image.iso`として作成されます。

そのイメージを使用して、SUSE Multi-Linux Managerへの登録を試みるノードをデプロイできるようになりました。

ノードのインストールが完全に終了すると、そのキーがSUSE Multi-Linux Managerの`pending`セクションに`Salt/Keys`として表示されます。キーを承認すると、ノードは自動的にSUSE Multi-Linux Managerにオンボードされ、そのプロセスが完了した後に`Systems`リストに表示されます。アクティベーションキーで指定したシステムグループが割り当てられます。

追加の設定を適用する前に、再起動をスケジュールすることをお勧めします。

キーの受け入れは、 こちらで説明されているホワイトリストを使用して完全に自動化できることにご留意ください。

パート II コンポーネント

 

エッジ用コンポーネントのリスト

  • 4 Rancher

    • https://ranchermanager.docs.rancher.com/v2.14.のRancherドキュメントを参照してください

  • 5 Rancherダッシュボード拡張機能

    • 拡張機能を使用すると、ユーザー、開発者、パートナー、および顧客はRancher UIを拡張および強化できます。SUSE EdgeはKubeVirtダッシュボード拡張機能を提供します。

  • 6 Fleet

    • Fleetは、ユーザーがローカルクラスタをより詳細に制御し、GitOpsを通じて継続的に監視できるように設計された、コンテナ管理およびデプロイメントエンジンです。Fleetはスケーリング能力だけでなく、クラスターに何がインストールされているかを正確に監視するための高度な制御と可視性をユーザーに提供します。

  • 7 SUSE Linux Micro

    • SUSE Linux Micro公式ドキュメントを参照してください

  • 8 Edge Image Builder

    • 公式リポジトリを参照してください。

  • 9 エッジネットワーキング

    • このセクションでは、SUSE Edgeソリューションにおけるネットワーク設定へのアプローチについて説明します。 SUSE Linux MicroでNetworkManagerを宣言的な方法で設定する方法と、関連ツールがどのように統合されているかを説明します。

  • 10 Elemental

    • Elementalは、Kubernetesによる完全なクラウドネイティブOSの一元管理を可能にするソフトウェアスタックです。Elementalスタックは、Rancher自体またはエッジノードのいずれかに存在する多数のコンポーネントで構成されています。主要コンポーネントは以下の通りです。

  • 11 K3s

    • K3sは、無人環境、リソースが制限された環境、遠隔地、またはIoTアプライアンス内の本番ワークロード向けに設計された、高可用性を備えた認定Kubernetesディストリビューションです。

  • 12 RKE2

    • RKE2公式ドキュメントを参照してください。

  • 13 SUSE Storage

    • SUSE Storageは、Kubernetes向けに設計された、軽量で信頼性が高く、ユーザーフレンドリーな分散ブロックストレージシステムです。これは、Rancher Labsによって最初に開発され、現在はCNCFの下でインキュベーションされているオープンソースプロジェクトであるLonghornに基づいた製品です。

  • 14 SUSE Security

    • SUSE Securityは、L7ネットワークセキュリティ、ランタイムセキュリティ、サプライチェーンセキュリティ、およびコンプライアンスチェックを統合パッケージとして提供する、Kubernetes向けのセキュリティソリューションです。

  • 15 MetalLB

    • MetalLB公式ドキュメントを参照してください。

  • 16 Endpoint Copier Operator

    • Endpoint Copier Operatorは、KubernetesのServiceとEndpointのコピーを作成し、それらをsyncし続けることを目的としたKubernetesオペレーターです。

  • 17 エッジ仮想化

    • このセクションでは、エッジ仮想化を使用してエッジノード上で仮想マシンを実行する方法について説明します。エッジ仮想化は、軽量な仮想化のユースケース向けに設計されており、仮想化アプリケーションとコンテナ化アプリケーションの両方の展開と管理に共通のワークフローが利用されることが想定されています。

  • 18 System Upgrade Controller

    • System Upgrade Controllerのドキュメントを参照してください。

  • 19 Upgrade Controller

    • 以下のSUSE Edgeプラットフォームコンポーネントのアップグレードを実行できるKubernetesコントローラー：

  • 20 SUSE Multi-Linux Manager

    • SUSE Multi-Linux ManagerはSUSE Edgeに含まれており、エッジデプロイメントのすべてのノードで基盤となるオペレーティングシステムであるSUSE Linux Microを常に最新の状態に保つための自動化と制御を提供します。

4 Rancher

 

https://ranchermanager.docs.rancher.com/v2.14.のRancherドキュメントを参照してください

Rancherは、複数の環境にわたるKubernetesクラスタのデプロイ、運用、監視を効率化する、強力なオープンソースのKubernetes管理プラットフォームです。オンプレミス、クラウド、エッジのいずれでクラスタを管理する場合でも、RancherはすべてのKubernetesニーズに対応する統合された一元管理プラットフォームを提供します。

4.1 Rancherの主な機能

 

  • マルチクラスタ管理:Rancherの直感的なインターフェースにより、パブリッククラウド、プライベートデータセンター、エッジロケーションなど、どこからでもKubernetesクラスタを管理できます。

  • セキュリティとコンプライアンス:Rancherは、Kubernetes環境全体でセキュリティポリシー、ロールベースのアクセス制御（RBAC）、およびコンプライアンス基準を適用します。

  • クラスタ運用の簡素化:Rancherはクラスタのプロビジョニング、アップグレード、トラブルシューティングを自動化し、あらゆる規模のチームのKubernetes運用を簡素化します。

  • 一元化されたアプリケーションカタログ:Rancherのアプリケーションカタログは、多様なHelmチャートとKubernetes Operatorを提供し、コンテナ化されたアプリケーションのデプロイと管理を容易にします。

  • 継続的デリバリ:RancherはGitOpsとCI/CDパイプラインをサポートしており、自動化された効率的なアプリケーションデリバリープロセスを実現します。

4.2 SUSE EdgeにおけるRancherの利用

 

RancherはSUSE Edgeスタックにいくつかのコア機能を提供します。

4.2.1 一元化されたKubernetes管理

 

多数の分散クラスタを伴う一般的なエッジデプロイメントにおいて、RancherはこれらのKubernetesクラスタを管理するための中心的なコントロールプレーンとして機能します。プロビジョニング、アップグレード、監視、トラブルシューティングのための統合インターフェースを提供し、運用を簡素化して一貫性を確保します。

4.2.2 クラスタ展開の簡素化

 

Rancherは、軽量なSUSE Linux Microオペレーティングシステム上でのKubernetesクラスタ作成を効率化し、堅牢なKubernetes機能によるエッジインフラストラクチャの展開を容易にします。

4.2.3 アプリケーションの展開と管理

 

統合されたRancherアプリケーションカタログにより、SUSE Edgeクラスタ全体でのコンテナ化されたアプリケーションの展開と管理が簡素化され、エッジワークロードのシームレスな展開が可能になります。

4.2.4 セキュリティとポリシーの適用

 

Rancherは、ポリシーに基づくガバナンストール、ロールベースのアクセス制御（RBAC）、および外部認証プロバイダーとの統合を提供します。これは、分散環境において不可欠なSUSE Edgeデプロイメントのセキュリティとコンプライアンスを維持するのに役立ちます。

4.3 ベストプラクティス

 

4.3.1 GitOps

 

RancherにはFleetがビルトインコンポーネントとして含まれており、Gitに保存されたコードを使用してクラスタ設定とアプリケーションのデプロイメントを管理できます。

4.3.2 監視

 

Rancherには、PrometheusやGrafanaなどの監視およびログ記録ツールが組み込まれており、クラスタの健全性とパフォーマンスを包括的に把握できます。

4.4 Edge Image Builderを使用したインストール

 

SUSE Edgeは、SUSE Linux Micro OSのベースイメージをカスタマイズするために第8章 「Edge Image Builder」を使用しています。 EIBによってプロビジョニングされたKubernetesクラスタ上にRancherをエアギャップ(された)インストールするには、25.6項 「Rancherインストール」に従ってください。

4.5 その他の資料

 

5 Rancherダッシュボード拡張機能

 

拡張機能を使用すると、ユーザー、開発者、パートナー、および顧客はRancher UIを拡張および強化できます。SUSE EdgeはKubeVirtダッシュボード拡張機能を提供します。

Rancherダッシュボード拡張機能に関する一般的な情報については、`https://ranchermanager.docs.rancher.com/v2.14/integrations-in-rancher/rancher-extensions[Rancher documentation]`を参照してください。

5.1 インストール

 

ダッシュボード拡張機能を含むすべてのSUSE Edge 3.6コンポーネントは、OCIアーティファクトとして配布されます。SUSE Edge拡張機能をインストールするには、RancherダッシュボードUI、Helm、またはFleetを使用できます。

5.1.1 RancherダッシュボードUIを使用したインストール

 

  1. ナビゲーションサイドバーの*Configuration*セクションにある*Extensions*をクリックします。

  2. Extensionsページで、右上の縦3点リーダメニューをクリックし、*Manage Repositories*を選択します。

    各拡張機能は、独自のOCIアーティファクトを介して配布されます。これらはSUSE Edge Helmチャートリポジトリから入手できます。

  3. *Repositoriesページ*で、`Create`をクリックします。

  4. フォームでリポジトリ名とURLを指定し、`Create`をクリックします。

    SUSE Edge HelmチャートリポジトリURL: oci://registry.suse.com/edge/charts

    dashboard extensions create oci repository

  5. 拡張機能リポジトリがリストに追加され、`Active`状態になっていることが確認できます。

    dashboard extensions repositories list

  6. ナビゲーションサイドバーの*Configuration*セクションにある*Extensions*に戻ります。

    *Available*タブで、インストール可能な拡張機能を確認できます。

    dashboard extensions available extensions

  7. 拡張機能カードで`Install`をクリックし、インストールを確定します。

    拡張機能がインストールされると、Rancher UIは`https://ranchermanager.docs.rancher.com/v2.14/integrations-in-rancher/rancher-extensions#installing-extensions[]`で説明されているようにページをリロードするよう促します。

5.1.2 Helmを使用したインストール

 
# KubeVirt extension
helm install kubevirt-dashboard-extension oci://registry.suse.com/edge/charts/kubevirt-dashboard-extension --version 306.0.4+up1.3.3 --namespace cattle-ui-plugin-system
注記
注記

拡張機能は cattle-ui-plugin-system ネームスペースにインストールする必要があります。

注記
注記

拡張機能がインストールされた後、RancherダッシュボードUIをリロードする必要があります。

5.1.3 Fleetを使ったインストール

 

Fleetを使用してダッシュボード拡張機能をインストールするには、カスタム gitRepo バンドル設定ファイルを指す Git リポジトリを指定する fleet.yaml リソースを定義する必要があります。

# KubeVirt extension fleet.yaml
defaultNamespace: cattle-ui-plugin-system
helm:
  releaseName: kubevirt-dashboard-extension
  chart: oci://registry.suse.com/edge/charts/kubevirt-dashboard-extension
  version: "306.0.4+up1.3.3"
注記
注記

releaseName プロパティは必須であり、拡張機能が正しくインストールされるように拡張機能名と一致させる必要があります。

cat <<- EOF | kubectl apply -f -
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: edge-dashboard-extensions
  namespace: fleet-local
spec:
  repo: https://github.com/suse-edge/fleet-examples.git
  branch: main
  paths:
  - fleets/kubevirt-dashboard-extension/
EOF

詳細については、第6章 「Fleet」 および fleet-examples リポジトリを参照してください。

拡張機能がインストールされると、Extensions セクションの Installed タブに一覧表示されます。これらはアプリ/Marketplace を介してインストールされるわけではないため、Third-Party ラベルが付けられます。

installed dashboard extensions

5.2 KubeVirt ダッシュボード拡張機能

 

KubeVirt 拡張機能は、RancherダッシュボードUIに基本的な仮想マシン管理機能を提供します。その機能については、17.7.2項 「KubeVirt Rancherダッシュボード拡張機能の使用」 で説明されています。

6 Fleet

 

Fleetは、ユーザーがローカルクラスタをより詳細に制御し、GitOpsを通じて継続的に監視できるように設計された、コンテナ管理およびデプロイメントエンジンです。Fleetはスケーリング能力だけでなく、クラスターに何がインストールされているかを正確に監視するための高度な制御と可視性をユーザーに提供します。

Fleetは、生のKubernetes YAML、Helmチャート、Kustomize、またはこれら3つの任意の組み合わせのGitからのデプロイメントを管理できます。ソースに関係なく、すべてのリソースは動的にHelmチャートに変換され、Helmがクラスター内のすべてのリソースをデプロイするためのエンジンとして使用されます。その結果、ユーザーはクラスターの高度な制御、一貫性、および監査可能性を享受できます。

Fleetの仕組みの詳細については、 Fleet Architectureを参照してください。

6.1 Helmを使用したFleetのインストール

 

FleetはRancherに組み込まれていますが、Helmを使用して任意のKubernetesクラスター上にスタンドアロンアプリケーションとして インストールすることもできます。

6.2 RancherでのFleetの使用

 

RancherはFleetを使用して、管理対象クラスター全体にアプリケーションをデプロイします。Fleetによる継続的デリバリは、大規模なGitOpsを導入し、多数のクラスターで実行されるアプリケーションを管理するように設計されています。

FleetはRancherの統合コンポーネントとして優れた機能を発揮します。Rancherで管理されるクラスターには、インストール/インポートプロセスの一環としてFleetエージェントが自動的にデプロイされ、そのクラスターは直ちにFleetによる管理が可能になります。

6.3 Rancher UIでのFleetへのアクセス

 

FleetはRancherにプリインストールされており、Rancher UIの*Continuous Delivery*オプションによって管理されます。

fleet dashboard

継続的デリバリセクションは、以下の項目で構成されています。

6.3.1 ダッシュボード

 

すべてのワークスペースにわたるすべてのGitOpsリポジトリの概要ページ。リポジトリを持つワークスペースのみが表示されます。

6.3.2 Gitリポジトリ

 

選択したワークスペース内のGitOpsリポジトリのリストです。ページ上部のドロップダウンリストを使用して、アクティブなワークスペースを選択します。

6.3.3 クラスタ

 

管理対象クラスタのリストです。デフォルトでは、すべてのRancher管理対象クラスタが`fleet-default`ワークスペースに追加されます。fleet-local`ワークスペースには、ローカル（管理）クラスタが含まれます。ここから、クラスタの `Pause または Force update を実行するか、もしくはクラスタを別のワークスペースに移動することが可能です。クラスタを編集すると、クラスタのグループ化に使用されるラベルや注釈を更新できます。

6.3.4 クラスタグループ

 

このセクションでは、セレクタを使用してワークスペース内のクラスタをカスタムグループ化できます。

6.3.5 詳細

 

「詳細」セクションでは、ワークスペースやその他の関連するFleetリソースを管理できます。

6.4 Rancherダッシュボードを使用してRancherおよびFleetでKubeVirtをインストールする例

 

  1. `fleet.yaml`ファイルを含むGitリポジトリを作成します。

    defaultNamespace: kubevirt
helm:
  chart: "oci://registry.suse.com/edge/charts/kubevirt"
  version: "306.0.2+up0.7.0"
  # kubevirt namespace is created by kubevirt as well, we need to take ownership of it
  takeOwnership: true

  2. Rancherダッシュボードで、*☰ > Continuous Delivery > Git Repos*に移動し、`Add Repository`をクリックします。

  3. リポジトリ作成ウィザードに従ってGitリポジトリを作成します。名前、リポジトリURL（前のステップで作成したGitリポジトリを参照）を入力し、適切なブランチまたはリビジョンを選択します。より複雑なリポジトリの場合は、*パス*を指定して、単一のリポジトリ内で複数のディレクトリを使用します。

    fleet create repo1

  4. `Next`をクリックします。

  5. 次のステップでは、ワークロードのデプロイ先を定義できます。クラスタの選択にはいくつかの基本的なオプションがあります。クラスタを選択しない、すべてのクラスタを選択する、または特定の管理対象クラスタやクラスタグループ（定義されている場合）を直接選択することができます。「詳細」オプションを使用すると、YAMLを介してセレクタを直接編集できます。

    fleet create repo2

  6. `Create`をクリックします。リポジトリが作成されます。これ以降、ワークロードはリポジトリ定義に一致するクラスタ上にインストールされ、同期が維持されます。

6.5 デバッグと問題解決

 

「詳細」ナビゲーションセクションでは、低レベルのFleetリソースの概要を提供します。 バンドルは、Gitからのリソースのオーケストレーションに使用される内部リソースです。Gitリポジトリがスキャンされると、1つ以上のバンドルが生成されます。

特定のリポジトリに関連するバンドルを見つけるには、Gitリポジトリの詳細ページに移動し、`Bundles`タブをクリックします。

fleet repo bundles

各クラスターについて、バンドルは作成されたBundleDeploymentリソースに適用されます。BundleDeploymentの詳細を表示するには、Gitリポジトリ詳細ページの右上にある`Graph`ボタンをクリックします。 *リポジトリ > バンドル > BundleDeployments*のグラフが読み込まれます。グラフ内のBundleDeploymentをクリックして詳細を確認し、`Id`をクリックしてBundleDeploymentのYAMLを表示します。

fleet repo graph

Fleetのトラブルシューティングのヒントに関する詳細については、 こちらを参照してください。

6.6 Fleetの例

 

Edgeチームは、Fleetを使用してEdgeプロジェクトをインストールする例を含む リポジトリを管理しています。

Fleetプロジェクトには、 fleet-examplesリポジトリが含まれており、 Gitリポジトリ構造のすべてのユースケースを網羅しています。

7 SUSE Linux Micro

 

SUSE Linux Micro公式ドキュメントを参照してください

SUSE Linux Microは、エッジ向けの軽量で安全なオペレーティングシステムです。SUSE Linux Enterprise Microは、SUSE Linux Enterpriseのエンタープライズ強化コンポーネントと開発者が最新の不変のOSに求める機能をマージします。その結果、使いやすく、クラス最高のコンプライアンスを備えた、信頼性の高いインフラストラクチャプラットフォームが得られます。

7.1 SUSE EdgeはどのようにSUSE Linux Microを使用しますか？

 

当社は、プラットフォームスタックのベースオペレーティングシステムとしてSUSE Linux Microを使用しています。これにより、安全で安定した最小限の基盤を用いて、構築作業を円滑に進めることができます。

SUSE Linux Microは、ファイルシステム（Btrfs）スナップショットを使用して、アップグレードで問題が発生した場合に簡単にロールバックできるという独自の特徴があります。これにより、問題が発生した場合でも、物理的なアクセスなしでプラットフォーム全体の安全なリモートアップグレードが可能になります。

7.2 ベストプラクティス

 

7.2.1 インストールメディア

 

SUSE EdgeはEdge Image Builder (第8章 「Edge Image Builder」)を使用して、SUSE Linux Microの自己インストール用インストールイメージを事前構成します。

7.2.2 ローカル管理

 

SUSE Linux MicroにはCockpitが付属しており、Webアプリケーションを通じてホストをローカルで管理できます。

このサービスはデフォルトで無効になっていますが、systemdサービス`cockpit.socket`を有効にすることで開始できます。 Cockpitはデフォルトでrootログインを禁止しているため、管理者権限を持つユーザーを作成することを推奨します。詳細については、https://documentation.suse.com/sle-micro/6.2/[SUSE Linux Micro公式ドキュメント]を参照してください。

7.3 当バージョンの注意事項

 

  • 現在、SUSE Linux Microではデスクトップ環境は利用できませんが、コンテナ化されたソリューションが開発中です。

8 Edge Image Builder

 

公式リポジトリを参照してください。

Edge Image Builder (EIB) は、マシンの起動用に、カスタマイズされた起動可能（CRB）ディスクイメージの生成を効率化するツールです。これらのイメージにより、単一のイメージでSUSEソフトウェアスタック全体の包括的なデプロイメントが可能になります。

EIBはすべてのプロビジョニングシナリオに対応するCRBイメージを作成できますが、ネットワークが制限されている、または完全に隔離されたエアギャップ(された)環境でのデプロイメントにおいて、EIBは非常に大きな価値を発揮します。

8.1 SUSE EdgeはどのようにEdge Image Builderを使用しますか？

 

SUSE Edgeは、さまざまなシナリオに対応するカスタマイズされたSUSE Linux Microイメージを簡素かつ迅速に構成するためにEIBを使用します。これらのシナリオには、以下のような仮想マシンおよびベアメタルマシンのブートストラップが含まれます。

  • K3s/RKE2 Kubernetesの完全なエアギャップ(された)環境でのデプロイメント（シングルおよびマルチノード）

  • HelmチャートおよびKubernetesマニフェストの完全なエアギャップ(された)環境でのデプロイメント

  • Elemental API経由でのRancherへの登録

  • Metal3

  • カスタマイズされたネットワーク（例：静的IP、ホスト名、VLAN、ボンディングなど）

  • カスタマイズされたオペレーティングシステムの構成（例：ユーザー、グループ、パスワード、SSHキー、プロキシ、NTP、カスタムSSL証明書など）

  • ホストレベルおよびサイドロードされたRPMパッケージのエアギャップ(された)環境でのインストール（依存関係の解決を含む）

  • OS管理のためのSUSE Multi-Linux Managerへの登録

  • 組み込みコンテナイメージ

  • カーネルのコマンドライン引数

  • 起動時に有効/無効にするSystemdユニット

  • 手動タスク用のカスタムスクリプトおよびファイル

8.2 はじめに

 

Edge Image Builderの使用方法とテストに関する包括的なドキュメントは、https://github.com/suse-edge/edge-image-builder/tree/release-1.3/docs[こちら]にあります。

さらに、基本的なデプロイメントシナリオを網羅した第2章 「Edge Image Builderを使用したスタンドアロンクラスター」も参照してください。

このツールに慣れましたら、EIBのヒントとコツのセクション (パートIV「ヒントとトラブルシューティング」)ページで、さらに役立つ情報をご覧ください。

8.3 当バージョンの注意事項

 

  • EIBは、Helmチャートをテンプレート化し、テンプレート内のすべてのイメージを解析することで、Helmチャートに対してエアギャップ処理を施します。Helmチャートがすべてのイメージをテンプレート内に保持せず、代わりにイメージをサイドロードする場合、EIBはそれらのイメージを自動的にエアギャップすることはできません。この解決策として、検出されなかったイメージを定義ファイルの`embeddedArtifactRegistry`セクションに手動で追加してください。

9 エッジネットワーキング

 

このセクションでは、SUSE Edgeソリューションにおけるネットワーク設定へのアプローチについて説明します。 SUSE Linux MicroでNetworkManagerを宣言的な方法で設定する方法と、関連ツールがどのように統合されているかを説明します。

9.1 NetworkManagerの概要

 

NetworkManagerは、プライマリネットワーク接続とその他の接続インタフェースを管理するツールです。

NetworkManagerは、ネットワーク設定を目的の状態を含む接続ファイルとして保存します。 これらの接続は、`/etc/NetworkManager/system-connections/`ディレクトリにファイルとして保存されます。

NetworkManagerの詳細については、https://documentation.suse.com/sle-micro/6.2/html/Micro-network-configuration/index.html[SUSE Linux Microドキュメント]を参照してください。

9.2 nmstateの概要

 

nmstateは、事前定義されたスキーマを介してネットワーク設定用の宣言型APIを提供する、広く採用されているライブラリ（および付属のCLIツール）です。

nmstateの詳細については、 アップストリームドキュメントを参照してください。

9.3 次のように入力します。NetworkManager Configurator (nmc)

 

SUSE Edgeで利用可能なネットワークカスタマイズオプションは、NetworkManager Configurator、略して_nmc_と呼ばれるCLIツールを介して実現されます。 これはnmstateライブラリによって提供される機能を活用しており、そのため、静的IPアドレス、DNSサーバー、VLAN、ボンディング、ブリッジなどの設定を完全に行うことができます。 このツールを使用すると、事前定義された目的の状態からネットワーク設定を生成し、それらを多くの異なるノードに自動化された方法で適用できます。

NetworkManager Configurator (nmc)の詳細については、 アップストリームリポジトリを参照してください。

9.4 SUSE EdgeはどのようにNetworkManager Configuratorを使用しますか？

 

SUSE Edgeは、さまざまなプロビジョニングモデルにおけるネットワークのカスタマイズに_nmc_を利用します。 * イメージベースのプロビジョニングシナリオにおける宣言型静的設定 (第2章 「Edge Image Builderを使用したスタンドアロンクラスター」)

9.5 Edge Image Builderによる設定

 

Edge Image Builder (EIB) は、単一のOSイメージで複数のホストを構成できるようにするツールです。 このセクションでは、宣言型アプローチを使用して目的のネットワーク状態を記述する方法、それらがどのように対応するNetworkManager接続に変換されるか、そしてプロビジョニングプロセス中にどのように適用されるかを示します。

9.5.1 前提条件

 

このガイドに従う場合は、以下のものがすでに用意されていることを前提としています。

  • SLES 15 SP6またはopenSUSE Leap 15.6を実行しているAMD64/Intel 64物理ホスト（または仮想マシン）

  • 利用可能なコンテナランタイム（例：Podman）

  • こちらにあるSUSE Linux Micro 6.2 RAWイメージのコピー

9.5.2 Edge Image Builderコンテナイメージの取得

 

EIBコンテナイメージは公開されており、以下のコマンドを実行することでSUSE Edgeレジストリからダウンロードできます。

podman pull registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1

9.5.3 イメージ構成ディレクトリの作成

 

設定ディレクトリの作成から始めましょう。

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR/base-images

次に、ダウンロードしたベースイメージのコピーを設定ディレクトリに確実に移動します。

mv /path/to/downloads/SL-Micro.x86_64-6.2-Base-GM.raw $CONFIG_DIR/base-images/
注記
注記

EIBがベースイメージの入力を変更することはありません。変更を加えた新しいイメージが作成されます。

この時点での設定ディレクトリは、以下のようになっているはずです。

└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw

9.5.4 イメージ定義ファイルの作成

 

定義ファイルには、Edge Image Builderがサポートする構成可能なオプションの大部分が記述されています。

OSイメージの非常に基本的な定義ファイルから始めましょう。

cat << EOF > $CONFIG_DIR/definition.yaml
apiVersion: 1.3
image:
  arch: x86_64
  imageType: raw
  baseImage: SL-Micro.x86_64-6.2-Base-GM.raw
  outputImageName: modified-image.raw
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
EOF

`image`セクションは必須であり、入力イメージ、そのアーキテクチャとタイプ、および出力イメージの名前を指定します。 `operatingSystem`セクションはオプションであり、`root/eib`ユーザー名/パスワードを使用してプロビジョニングされたシステムへのログインを有効にするための構成が含まれています。

注記
注記

`openssl passwd -6 <password>`を実行して、独自の暗号化されたパスワードを自由に使用してください。

この時点での設定ディレクトリは、以下のようになっているはずです。

├── definition.yaml
└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw

9.5.5 ネットワーク構成の定義

 

目的のネットワーク構成は、作成したばかりのイメージ定義ファイルの一部ではありません。 これらを特別な`network/`ディレクトリの下に配置します。作成しましょう。

mkdir -p $CONFIG_DIR/network

前述のように、NetworkManager Configurator（nmc）ツールは、定義済みのスキーマ形式の入力を想定しています。 さまざまなネットワークオプションの設定方法については、 アップストリームのNMStateの例のドキュメントで確認できます。

このガイドでは、3つの異なるノードでネットワークを設定する方法を説明します。

  • 2つのイーサネットインターフェイスを使用するノード

  • ネットワークボンディングを使用するノード

  • ネットワークブリッジを使用するノード

警告
警告

本番環境のビルド、特にKubernetesクラスターを構成する場合は、完全に異なるネットワーク設定を使用することは推奨されません。 ネットワーク構成は、一般的にノード間、あるいは少なくとも特定のクラスター内の役割間で均一である必要があります。 このガイドには、参考例としてさまざまなオプションが含まれています。

注記
注記

以下では、IPアドレス範囲`192.168.122.1/24`を持つデフォルトの`libvirt`ネットワークを想定しています。 環境が異なる場合は、それに応じて調整してください。

`node1.suse.com`と呼ぶ最初のノードの目的の状態を作成しましょう。

cat << EOF > $CONFIG_DIR/network/node1.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: eth0
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: eth0
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E1
    ipv4:
      address:
        - ip: 192.168.122.50
          prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      enabled: false
  - name: eth3
    type: ethernet
    state: down
    mac-address: 34:8A:B1:4B:16:E2
    ipv4:
      address:
        - ip: 192.168.122.55
          prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      enabled: false
EOF

この例では、2つのイーサネットインターフェイス（eth0およびeth3）の目的の状態、要求されたIPアドレス、ルーティング、およびDNS解決を定義します。

警告
警告

すべてのイーサネットインターフェイスのMACアドレスがリストされていることを確認する必要があります。 これらは、プロビジョニングプロセス中にノードの識別子として使用され、どの構成を適用すべきかを決定するために役立ちます。 このようにして、単一のISOまたはRAWイメージを使用して複数のノードを構成できます。

次は、`node2.suse.com`と呼ぶ2番目のノードで、ネットワークボンディングを使用します。

cat << EOF > $CONFIG_DIR/network/node2.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: bond99
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: bond99
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: bond99
    type: bond
    state: up
    ipv4:
      address:
        - ip: 192.168.122.60
          prefix-length: 24
      enabled: true
    link-aggregation:
      mode: balance-rr
      options:
        miimon: '140'
      port:
        - eth0
        - eth1
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E3
    ipv4:
      enabled: false
    ipv6:
      enabled: false
  - name: eth1
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E4
    ipv4:
      enabled: false
    ipv6:
      enabled: false
EOF

この例では、IPアドレッシングを有効にしない2つのイーサネットインターフェイス（eth0およびeth1）の目的の状態と、ラウンドロビンポリシーを持つボンド、およびネットワークトラフィックの転送に使用されるそれぞれの宛先アドレスを定義します。

最後に、ネットワークブリッジを利用する3番目で最後の目的の状態ファイルを作成します。これを`node3.suse.com`と呼びます。

cat << EOF > $CONFIG_DIR/network/node3.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: linux-br0
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: linux-br0
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E5
    ipv4:
      enabled: false
    ipv6:
      enabled: false
  - name: linux-br0
    type: linux-bridge
    state: up
    ipv4:
      address:
        - ip: 192.168.122.70
          prefix-length: 24
      dhcp: false
      enabled: true
    bridge:
      options:
        group-forward-mask: 0
        mac-ageing-time: 300
        multicast-snooping: true
        stp:
          enabled: true
          forward-delay: 15
          hello-time: 2
          max-age: 20
          priority: 32768
      port:
        - name: eth0
          stp-hairpin-mode: false
          stp-path-cost: 100
          stp-priority: 32
EOF

この時点での設定ディレクトリは、以下のようになっているはずです。

├── definition.yaml
├── network/
│   │── node1.suse.com.yaml
│   │── node2.suse.com.yaml
│   └── node3.suse.com.yaml
└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw
注記
注記

`network/`ディレクトリ内のファイル名は意図的なものです。 これらは、プロビジョニングプロセス中に設定されるホスト名に対応しています。

9.5.6 OSイメージのビルド

 

必要な構成がすべて整いましたので、単に以下を実行してイメージをビルドできます。

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file definition.yaml

出力は以下のような内容である必要があります。

Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Rpm .......................... [SKIPPED]
Systemd ...................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Embedded Artifact Registry ... [SKIPPED]
Keymap ....................... [SUCCESS]
Kubernetes ................... [SKIPPED]
Certificates ................. [SKIPPED]
Building RAW image...
Kernel Params ................ [SKIPPED]
Image build complete!

上記のコードスニペットは、`Network`コンポーネントが正常に構成されたことを示しており、エッジノードのプロビジョニングに進むことができます。

注記
注記

ログファイル（network-config.log）および対応するNetworkManager接続ファイルは、イメージ実行のタイムスタンプ付きディレクトリの下にある、結果の`_build`ディレクトリで確認できます。

9.5.7 エッジノードのプロビジョニング

 

作成されたRAWイメージをコピーしましょう。

mkdir edge-nodes && cd edge-nodes
for i in {1..4}; do cp $CONFIG_DIR/modified-image.raw node$i.raw; done

ビルドされたイメージを4回コピーしましたが、3つのノードのネットワーク構成しか指定していないことに気づくでしょう。 これは、どの目的の構成にも一致しないノードをプロビジョニングした場合に何が起こるかを紹介するためでもあります。

注記
注記

このガイドでは、ノードプロビジョニングの例として仮想化を使用します。BIOSで必要な拡張機能が有効になっていることを確認してください（詳細は こちらを参照してください）。

コピーされたrawディスクを使用して仮想マシンを作成するために、`virt-install`を使用します。 各仮想マシンは、10 GBのRAMと6つのvCPUを使用します。

9.5.7.1 最初のノードのプロビジョニング

 

仮想マシンを作成しましょう。

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=node1.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E1 --network default,mac=34:8A:B1:4B:16:E2 --virt-type kvm --import
注記
注記

上記で説明した目的の状態にあるものと同じMACアドレスでネットワークインタフェースを作成することが重要です。

操作が完了すると、次のようなものが表示されます。

Starting install...
Creating domain...

Running text console command: virsh --connect qemu:///system console node1
Connected to domain 'node1'
Escape character is ^] (Ctrl + ])


Welcome to SUSE Linux Micro 6.0 (x86_64) - Kernel 6.4.0-18-default (tty1).

SSH host key: SHA256:XN/R5Tw43reG+QsOw480LxCnhkc/1uqMdwlI6KUBY70 (RSA)
SSH host key: SHA256:/96yGrPGKlhn04f1rb9cXv/2WJt4TtrIN5yEcN66r3s (DSA)
SSH host key: SHA256:Dy/YjBQ7LwjZGaaVcMhTWZNSOstxXBsPsvgJTJq5t00 (ECDSA)
SSH host key: SHA256:TNGqY1LRddpxD/jn/8dkT/9YmVl9hiwulqmayP+wOWQ (ED25519)
eth0: 192.168.122.50
eth1:


Configured with the Edge Image Builder
Activate the web console with: systemctl enable --now cockpit.socket

node1 login:

これで、`root:eib`の資格情報のペアを使用してログインできるようになりました。 ここで提示された`virsh console`よりも好む場合は、ホストにSSHで接続することもできます。

ログインしたら、すべての設定が適切に行われていることを確認しましょう。

ホスト名が正しく設定されていることを確認します。

node1:~ # hostnamectl
 Static hostname: node1.suse.com
 ...

ルーティングが正しく構成されていることを確認します。

node1:~ # ip r
default via 192.168.122.1 dev eth0 proto static metric 100
192.168.122.0/24 dev eth0 proto static scope link metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.50 metric 100

インターネット接続が利用可能であることを確認します。

node1:~ # ping google.com
PING google.com (142.250.72.78) 56(84) bytes of data.
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=1 ttl=56 time=13.2 ms
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=2 ttl=56 time=13.4 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 13.248/13.304/13.361/0.056 ms

イーサネットインターフェイスが正確に2つ構成されており、そのうちの1つだけがアクティブであることを確認します。

node1:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e1 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.50/24 brd 192.168.122.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e2 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3

node1:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1  7e211aea-3d14-59cf-a4fa-be91dac5dbba  ethernet  --      /etc/NetworkManager/system-connections/eth1.nmconnection

2番目のインターフェイスが、目的のネットワーク状態で事前定義された`eth3`ではなく、`eth1`になっていることに気づくでしょう。 これは、NetworkManager Configurator（nmc）が、OSがMACアドレス`34:8a:b1:4b:16:e2`を持つNICに異なる名前を割り当てたことを検出し、それに応じて設定を調整できるためです。

プロビジョニングのCombustionフェーズを検査して、これが実際に発生したことを確認します。

node1:~ # journalctl -u combustion | grep nmc
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Identified host: node1.suse.com
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Set hostname: node1.suse.com
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Processing interface 'eth0'...
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Processing interface 'eth3'...
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Using interface name 'eth1' instead of the preconfigured 'eth3'
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc] Successfully applied config

残りのノードをプロビジョニングしますが、最終的な構成の相違点のみを示します。 プロビジョニングしようとしているすべてのノードに対して、上記のチェックの一部またはすべてを自由に行ってください。

9.5.7.2 2番目のノードのプロビジョニング

 

仮想マシンを作成しましょう。

virt-install --name node2 --ram 10000 --vcpus 6 --disk path=node2.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E3 --network default,mac=34:8A:B1:4B:16:E4 --virt-type kvm --import

仮想マシンが起動して実行されたら、このノードがボンドインタフェースを使用していることを確認できます。

node2:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond99 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond99 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff permaddr 34:8a:b1:4b:16:e4
    altname enp0s3
    altname ens3
4: bond99: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.60/24 brd 192.168.122.255 scope global noprefixroute bond99
       valid_lft forever preferred_lft forever

ルーティングがボンドを使用していることを確認します。

node2:~ # ip r
default via 192.168.122.1 dev bond99 proto static metric 100
192.168.122.0/24 dev bond99 proto static scope link metric 100
192.168.122.0/24 dev bond99 proto kernel scope link src 192.168.122.60 metric 300

静的接続ファイルが適切に使用されていることを確認します。

node2:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME    UUID                                  TYPE      DEVICE  FILENAME
bond99  4a920503-4862-5505-80fd-4738d07f44c6  bond      bond99  /etc/NetworkManager/system-connections/bond99.nmconnection
eth0    dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1    0523c0a1-5f5e-5603-bcf2-68155d5d322e  ethernet  eth1    /etc/NetworkManager/system-connections/eth1.nmconnection

9.5.7.3 3番目のノードのプロビジョニング

 

仮想マシンを作成しましょう。

virt-install --name node3 --ram 10000 --vcpus 6 --disk path=node3.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E5 --virt-type kvm --import

仮想マシンが起動して実行されたら、このノードがネットワークブリッジを使用していることを確認できます。

node3:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master linux-br0 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e5 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
3: linux-br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.70/24 brd 192.168.122.255 scope global noprefixroute linux-br0
       valid_lft forever preferred_lft forever

ルーティングがブリッジを使用していることを確認します。

node3:~ # ip r
default via 192.168.122.1 dev linux-br0 proto static metric 100
192.168.122.0/24 dev linux-br0 proto static scope link metric 100
192.168.122.0/24 dev linux-br0 proto kernel scope link src 192.168.122.70 metric 425

静的接続ファイルが適切に使用されていることを確認します。

node3:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME       UUID                                  TYPE      DEVICE     FILENAME
linux-br0  1f8f1469-ed20-5f2c-bacb-a6767bee9bc0  bridge    linux-br0  /etc/NetworkManager/system-connections/linux-br0.nmconnection
eth0       dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0       /etc/NetworkManager/system-connections/eth0.nmconnection

9.5.7.4 4番目のノードのプロビジョニング

 

最後に、MACアドレスによる事前定義された構成のいずれにも一致しないノードをプロビジョニングします。 このような場合、デフォルトでDHCPを使用してネットワークインタフェースを構成します。

仮想マシンを作成しましょう。

virt-install --name node4 --ram 10000 --vcpus 6 --disk path=node4.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --virt-type kvm --import

仮想マシンが起動して実行されたら、このノードがネットワークインタフェースにランダムなIPアドレスを使用していることを確認できます。

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:56:63:71 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.86/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0
       valid_lft 3542sec preferred_lft 3542sec
    inet6 fe80::5054:ff:fe56:6371/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

nmcがこのノードに対して静的設定の適用に失敗したことを確認します。

localhost:~ # journalctl -u combustion | grep nmc
Apr 23 12:15:45 localhost.localdomain combustion[1357]: [2024-04-23T12:15:45Z ERROR nmc] Applying config failed: None of the preconfigured hosts match local NICs

イーサネットインタフェースがDHCP経由で設定されたことを確認します。

localhost:~ # journalctl | grep eth0
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7801] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7802] device (eth0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7929] device (eth0): carrier: link connected
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7931] device (eth0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7944] device (eth0): Activation: starting connection 'Wired Connection' (300ed658-08d4-4281-9f8c-d1b8882d29b9)
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7945] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7947] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7953] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7964] dhcp4 (eth0): activation: beginning transaction (timeout in 90 seconds)
Apr 23 12:15:33 localhost.localdomain NetworkManager[704]: <info>  [1713874533.1272] dhcp4 (eth0): state changed new lease, address=192.168.122.86

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME              UUID                                  TYPE      DEVICE  FILENAME
Wired Connection  300ed658-08d4-4281-9f8c-d1b8882d29b9  ethernet  eth0    /var/run/NetworkManager/system-connections/default_connection.nmconnection

9.5.8 統合ノード設定

 

既知のMACアドレスに依存することが選択肢とならない場合があります。このような場合、_統合設定_を選択できます。これにより、`_all.yaml`ファイルで設定を指定し、プロビジョニングされたすべてのノードに適用できるようになります。

異なる設定構造を使用してエッジノードを構築およびプロビジョニングします。[image-config-dir-creation]から9.5.5項 「ネットワーク構成の定義」までのすべての手順に従ってください。

この例では、2つのイーサネットインターフェイス（eth0およびeth1）の目的の状態を定義します。1つはDHCPを使用し、もう1つは静的IPアドレスを割り当てます。

mkdir -p $CONFIG_DIR/network

cat <<- EOF > $CONFIG_DIR/network/_all.yaml
interfaces:
- name: eth0
  type: ethernet
  state: up
  ipv4:
    dhcp: true
    enabled: true
  ipv6:
    enabled: false
- name: eth1
  type: ethernet
  state: up
  ipv4:
    address:
    - ip: 10.0.0.1
      prefix-length: 24
    enabled: true
    dhcp: false
  ipv6:
    enabled: false
EOF

イメージをビルドしましょう。

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file definition.yaml

イメージが正常にビルドされたら、それを使用して仮想マシンを作成しましょう。

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=$CONFIG_DIR/modified-image.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --network default --virt-type kvm --import

プロビジョニング処理には数分かかる場合があります。完了したら、提供された資格情報を使用してシステムにログインしてください。

ルーティングが正しく設定されていることを確認します。

localhost:~ # ip r
default via 192.168.122.1 dev eth0 proto dhcp src 192.168.122.100 metric 100
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 metric 101
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.100 metric 100

インターネット接続が利用可能であることを確認します。

localhost:~ # ping google.com
PING google.com (142.250.72.46) 56(84) bytes of data.
64 bytes from den16s08-in-f14.1e100.net (142.250.72.46): icmp_seq=1 ttl=56 time=14.3 ms
64 bytes from den16s08-in-f14.1e100.net (142.250.72.46): icmp_seq=2 ttl=56 time=14.2 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 14.196/14.260/14.324/0.064 ms

イーサネットインタフェースが設定され、アクティブになっていることを確認してください。

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:26:44:7a brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    inet 192.168.122.100/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0
       valid_lft 3505sec preferred_lft 3505sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:ec:57:9e brd ff:ff:ff:ff:ff:ff
    altname enp7s0
    inet 10.0.0.1/24 brd 10.0.0.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1  0523c0a1-5f5e-5603-bcf2-68155d5d322e  ethernet  eth1    /etc/NetworkManager/system-connections/eth1.nmconnection

localhost:~ # cat /etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70

[ipv4]
dhcp-client-id=mac
dhcp-send-hostname=true
dhcp-timeout=2147483647
ignore-auto-dns=false
ignore-auto-routes=false
method=auto
never-default=false

[ipv6]
addr-gen-mode=0
dhcp-timeout=2147483647
method=disabled

localhost:~ # cat /etc/NetworkManager/system-connections/eth1.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
id=eth1
interface-name=eth1
type=802-3-ethernet
uuid=0523c0a1-5f5e-5603-bcf2-68155d5d322e

[ipv4]
address0=10.0.0.1/24
dhcp-timeout=2147483647
method=manual

[ipv6]
addr-gen-mode=0
dhcp-timeout=2147483647
method=disabled

9.5.9 カスタムネットワーク設定

 

Edge Image Builderのデフォルトのネットワーク設定についてはすでに説明しましたが、これはNetworkManager Configuratorに依存しています。 ただし、カスタムスクリプトを使用して変更するオプションもあります。このオプションは非常に柔軟でMACアドレスにも依存しませんが、単一のイメージで複数のノードを起動する場合、使用するのがはるかに不便であるという制限があります。

注記
注記

/network ディレクトリの下にある、目的のネットワーク状態を記述したファイルを使用して、デフォルトのネットワーク設定を使用することをお勧めします。 その動作がユースケースに適用できない場合にのみ、カスタムスクリプトを選択してください。

異なる設定構造を使用してエッジノードを構築およびプロビジョニングします。[image-config-dir-creation]から9.5.5項 「ネットワーク構成の定義」までのすべての手順に従ってください。

この例では、プロビジョニングされたすべてのノードで eth0 インターフェイスに静的設定を適用し、NetworkManagerによって自動的に作成された有線接続を削除および無効化するカスタムスクリプトを作成します。これは、クラスター内のすべてのノードが同一のネットワーク設定を持つようにしたい場合に有益であり、そのため、イメージ作成前に各ノードのMACアドレスを気にする必要がありません。

まず、接続ファイルを /custom/files ディレクトリに保存することから始めましょう。

mkdir -p $CONFIG_DIR/custom/files

cat << EOF > $CONFIG_DIR/custom/files/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
autoconnect-retries=1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70
wait-device-timeout=60000

[ipv4]
dhcp-timeout=2147483647
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-timeout=2147483647
method=disabled
EOF

静的設定が作成されたので、カスタムネットワークスクリプトも作成します。

mkdir -p $CONFIG_DIR/network

cat << EOF > $CONFIG_DIR/network/configure-network.sh
#!/bin/bash
set -eux

# Remove and disable wired connections
mkdir -p /etc/NetworkManager/conf.d/
printf "[main]\nno-auto-default=*\n" > /etc/NetworkManager/conf.d/no-auto-default.conf
rm -f /var/run/NetworkManager/system-connections/* || true

# Copy pre-configured network configuration files into NetworkManager
mkdir -p /etc/NetworkManager/system-connections/
cp eth0.nmconnection /etc/NetworkManager/system-connections/
chmod 600 /etc/NetworkManager/system-connections/*.nmconnection
EOF

chmod a+x $CONFIG_DIR/network/configure-network.sh
注記
注記

nmcバイナリは引き続きデフォルトで含まれるため、必要に応じて configure-network.sh スクリプトで使用することもできます。

警告
警告

カスタムスクリプトは、常に設定ディレクトリ内の /network/configure-network.sh に配置する必要があります。ファイルが存在する場合、他のすべてのファイルは無視されます。 YAML形式の静的構成とカスタムスクリプトの両方を同時に使用してネットワークを構成することはできません。

この時点での設定ディレクトリは、以下のようになっているはずです。

├── definition.yaml
├── custom/
│   └── files/
│       └── eth0.nmconnection
├── network/
│   └── configure-network.sh
└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw

イメージをビルドしましょう。

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file definition.yaml

イメージが正常にビルドされたら、それを使用して仮想マシンを作成しましょう。

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=$CONFIG_DIR/modified-image.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --virt-type kvm --import

プロビジョニング処理には数分かかる場合があります。完了したら、提供された資格情報を使用してシステムにログインしてください。

ルーティングが正しく構成されていることを確認します。

localhost:~ # ip r
default via 192.168.122.1 dev eth0 proto dhcp src 192.168.122.185 metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.185 metric 100

インターネット接続が利用可能であることを確認します。

localhost:~ # ping google.com
PING google.com (142.250.72.78) 56(84) bytes of data.
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=1 ttl=56 time=13.6 ms
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=2 ttl=56 time=13.6 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.592/13.599/13.606/0.007 ms

接続ファイルを使用してイーサネットインタフェースが静的に設定され、アクティブになっていることを確認してください。

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:31:d0:1b brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.185/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection

localhost:~ # cat  /etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
autoconnect-retries=1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70
wait-device-timeout=60000

[ipv4]
dhcp-timeout=2147483647
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-timeout=2147483647
method=disabled

10 Elemental

 

Elementalは、Kubernetesによる完全なクラウドネイティブOSの一元管理を可能にするソフトウェアスタックです。Elementalスタックは、Rancher自体またはエッジノードのいずれかに存在する多数のコンポーネントで構成されています。主要コンポーネントは以下の通りです。

  • elemental-operator - Rancher上に存在し、クライアントからの登録要求を処理するコアオペレーターです。

  • elemental-register - エッジノード上で実行され、`elemental-operator`を介した登録を可能にするクライアントです。

  • elemental-system-agent - エッジノード上に存在するエージェントです。その設定は`elemental-register`から供給され、`rancher-system-agent`を設定するための`plan`を受け取ります。

  • rancher-system-agent - エッジノードが完全に登録されると、これが`elemental-system-agent`から引き継ぎ、Rancher Managerからのさらなる`plans`（Kubernetesインストールなど）を待機します。

ElementalとRancherとの関係に関する詳細については、 Elementalアップストリームドキュメントを参照してください。

10.1 SUSE EdgeはどのようにElementalを使用しますか？

 

私たちは、Metal3が選択肢にない場合（例えば、BMCがない、またはデバイスがNATゲートウェイの背後にある場合など）に、リモートデバイスを管理するためにElementalの一部を使用しています。このツールにより、オペレーターは、デバイスの出荷先や出荷時期が不明な段階でも、ラボでデバイスを起動できます。具体的には、`elemental-register`および`elemental-system-agent`コンポーネントを活用して、「phone home」ネットワークプロビジョニングのユースケース向けに、SUSE Linux MicroホストをRancherにオンボーディングできるようにしています。Edge Image Builder (EIB) を使用してデプロイメントイメージを作成する場合、EIBの設定ディレクトリに登録構成を指定することで、Elementalを介したRancherによる自動登録を実現できます。

注記
注記

SUSE Edge 3.6では、Elementalのオペレーティングシステム管理の側面は活用して*いない*ため、Rancherを介してオペレーティングシステムのパッチ適用を管理することはできません。デプロイメントイメージの構築にElementalツールを使用する代わりに、SUSE EdgeはEdge Image Builderツールを使用し、登録設定を取り込みます。

10.2 ベストプラクティス

 

10.2.1 インストールメディア

 

「phone homeネットワークプロビジョニング」デプロイメントフットプリントにおいて、Rancherへの登録にElementalを活用できるデプロイメントイメージを構築するSUSE Edge推奨の方法は、Elementalを使用したリモートホストのオンボーディング (第1章 「Elementalを使用したリモートホストのオンボーディング」)クイックスタートで詳述されている手順に従うことです。

10.2.2 ラベル

 

Elementalは`MachineInventory` CRDでインベントリを追跡し、ラベルに基づいてKubernetesクラスターをデプロイするマシンを選択するなど、インベントリを選択する方法を提供します。これにより、ユーザーはハードウェアを購入する前であっても、インフラストラクチャのニーズのほとんど（すべてではないにしても）を事前に定義できるようになります。また、ノードはそれぞれのインベントリオブジェクトでラベルを追加/削除できるため（追加のフラグ`--label "FOO=BAR"`を指定して`elemental-register`を再実行することで）、ノードがどこで起動されたかを検出し、Rancherに通知するスクリプトを作成できます。

10.3 当バージョンの注意事項

 

  • Elemental UIは現在、インストールメディアの構築や、「Elemental Teal」以外のオペレーティングシステムを更新する方法を認識していません。これについては、将来のリリースで対処される予定です。

11 K3s

 

K3sは、無人環境、リソースが制限された環境、遠隔地、またはIoTアプライアンス内の本番ワークロード向けに設計された、高可用性を備えた認定Kubernetesディストリビューションです。

単一の小さなバイナリとしてパッケージ化されているため、インストールと更新が迅速かつ簡単です。

11.1 SUSE EdgeはどのようにK3sを使用しますか

 

K3sは、SUSE Edgeスタックを支えるKubernetesディストリビューションとして使用できます。 これは、SUSE Linux Microオペレーティングシステムにインストールすることを前提としています。

SUSE EdgeスタックのKubernetesディストリビューションとしてK3sを使用することは、etcdをバックエンドとして使用することが制約に合わない場合にのみ推奨されます。etcdをバックエンドとして使用できる場合は、RKE2 (第12章 「RKE2」)を使用することをお勧めします。

11.2 ベストプラクティス

 

11.2.1 インストール

 

SUSE Edgeスタックの一部としてK3sをインストールする推奨方法は、Edge Image Builder (EIB) を使用することです。K3sをデプロイするように設定する方法の詳細については、そのドキュメント (第8章 「Edge Image Builder」)を参照してください。

HAセットアップおよびElementalセットアップを自動的にサポートします。

11.2.2 GitOpsワークフローのためのFleet

 

SUSE Edgeスタックは、推奨されるGitOpsツールとしてFleetを使用します。 そのインストールと使用に関する詳細については、本ドキュメントのFleetセクション (第6章 「Fleet」)を参照してください。

11.2.3 ストレージ管理

 

K3sにはlocal-pathストレージが事前設定されており、シングルノードクラスターに適しています。 複数のノードにまたがるクラスターには、SUSE Storage (第13章 「SUSE Storage」)の使用を推奨します。

11.2.4 負荷分散とHA

 

EIBを使用してK3sをインストールした場合、この部分はすでにEIBドキュメントのHAセクションで説明されています。

それ以外の場合は、MetalLBドキュメント (第21章 「K3s上のMetalLB（レイヤー2モードを使用）」)に従ってMetalLBをインストールおよび設定する必要があります。

12 RKE2

 

RKE2公式ドキュメントを参照してください。

RKE2は、以下によってセキュリティとコンプライアンスに重点を置いた、完全に準拠したKubernetesディストリビューションです。

  • クラスタが最小限のオペレータの介入でCIS Kubernetesベンチマークv1.6またはv1.23に合格できるようにするデフォルトと設定オプションを提供すること

  • FIPS 140-2コンプライアンスを有効にすること

  • RKE2ビルドパイプラインで trivyを使用して、コンポーネントのCVEを定期的にスキャンすること

RKE2は、コントロールプレーンのコンポーネントをkubeletによって管理される静的ポッドとして起動します。組み込みのコンテナランタイムはcontainerdです。

注意:RKE2は、現在ターゲットとしている別のユースケースとセクターを伝えるために、RKE Governmentとしても知られています。

12.1 RKE2とK3sの比較

 

K3sは、エッジ、IoT、ARMに焦点を当てた、完全に準拠した軽量なKubernetesディストリビューションであり、使いやすさとリソースが制限された環境向けに最適化されています。

RKE2は、RKEの1.xバージョン（以下、RKE1と呼びます）とK3sの両方の長所を兼ね備えています。

K3sからは、そのユーザビリティ、運用の容易さ、デプロイモデルを継承しています。

RKE1からは、アップストリームのKubernetesとの密接な整合性を継承しています。K3sは、エッジデプロイメント向けに最適化するため、アップストリーム Kubernetes から一部乖離していますが、RKE1 と RKE2 はアップストリームと密接に整合性を保つことができます。

12.2 SUSE EdgeはどのようにRKE2を使用していますか？

 

RKE2はSUSE Edgeスタックの基本的な構成要素です。これはSUSE Linux Micro (第7章 「SUSE Linux Micro」)の上で動作し、エッジワークロードのデプロイに必要な標準的なKubernetesインターフェースを提供します。

12.3 ベストプラクティス

 

12.3.1 インストール

 

SUSE Edgeスタックの一部としてRKE2をインストールする推奨方法は、Edge Image Builder（EIB）を使用することです。RKE2をデプロイするための設定方法の詳細については、EIBドキュメント (第8章 「Edge Image Builder」)を参照してください。

EIBは、RKE2のバージョン指定、 サーバーや エージェントの設定など、RKE2が必要とするあらゆるパラメータをサポートする柔軟性を備えており、すべてのエッジユースケースをカバーします。

12.3.2 高可用性

 

HAデプロイメントの場合、EIBはMetalLB (第15章 「MetalLB」)とEndpoint Copier Operator (第16章 「Endpoint Copier Operator」)を自動的にデプロイおよび構成し、RKE2 APIエンドポイントを外部に公開します。

12.3.3 ネットワーキング

 

SUSE Edgeスタックは、 Ciliumと Calicoをサポートしており、デフォルトの CNI は Cilium です。また、Pod が複数のネットワークインタフェースを必要とする場合は、 Multusメタプラグインも使用できます。RKE2スタンドアロンは、 より広範なCNIオプションをサポートしています。

12.3.4 ストレージ

 

RKE2は、いかなる種類の永続ストレージクラスやオペレーターも提供しません。複数のノードにまたがるクラスターには、SUSE Storage (第13章 「SUSE Storage」)の使用が推奨されます。

SUSE Storageは、Kubernetes向けに設計された、軽量で信頼性が高く、ユーザーフレンドリーな分散ブロックストレージシステムです。これは、Rancher Labsによって最初に開発され、現在はCNCFの下でインキュベーションされているオープンソースプロジェクトであるLonghornに基づいた製品です。

13.1 前提条件

 

このガイドに従う場合、以下のものがすでに利用可能であることを前提としています。

  • SUSE Linux Micro 6.2がインストールされたホストが、物理・仮想を問わず少なくとも1台必要です。

  • K3sまたはRKE2のいずれかがインストールされたKubernetesクラスターが必要です。

  • Helm

13.2 SUSE Storageの手動インストール

 

13.2.1 Open-iSCSIのインストール

 

SUSE Storageをデプロイおよび使用するための主要な要件は、`open-iscsi`パッケージのインストールと、すべてのKubernetesノードで実行される`iscsid`デーモンです。 Longhornはホスト上の`iscsiadm`に依存してKubernetesに永続ボリュームを提供するため、これが必要です。

インストールしましょう。

transactional-update pkg install open-iscsi

SUSE Linux Microはイミュータブル（変更不可）なオペレーティングシステムであるため、操作が完了すると、パッケージは新しいスナップショットにのみインストールされることに注意することが重要です。 それをロードし、`iscsid`デーモンを実行開始させるには、作成したばかりの新しいスナップショットで再起動する必要があります。 準備ができたら、rebootコマンドを発行してください。

reboot
ヒント
ヒント

open-iscsiのインストールに関する追加のヘルプについては、https://longhorn.io/docs/1.11.2/deploy/install/#installing-open-iscsi[公式Longhornドキュメント]を参照してください。

13.2.2 SUSE Storageのインストール

 

KubernetesクラスターにSUSE Storageをインストールする方法はいくつかあります。 このガイドではHelmによるインストール手順を説明しますが、別の方法を希望する場合は、https://longhorn.io/docs/1.11.2/deploy/install/[公式ドキュメント]に従ってください。

  1. Rancherアプリケーションコレクションにログインします。

    helm registry login dp.apps.rancher.io --username $APPS.RANCHER.IO_USERNAME --password $APPS.RANCHER.IO_ACCESS_TOKEN

  2. `longhorn-system`ネームスペースにSUSE Storageをインストールし、コンテナレジストリの認証情報を追加します。

    helm install longhorn oci://dp.apps.rancher.io/charts/suse-storage \
  --version 1.11.2 \
  --namespace longhorn-system \
  --create-namespace \
  --set privateRegistry.createSecret=true \
  --set privateRegistry.registryUrl=dp.apps.rancher.io \
  --set privateRegistry.registryUser=$APPS.RANCHER.IO_USERNAME \
  --set privateRegistry.registryPasswd=$APPS.RANCHER.IO_ACCESS_TOKEN \
  --set privateRegistry.registrySecret=application-collection

  3. デプロイが成功したことを確認します：

    kubectl -n longhorn-system get pods
    localhost:~ # kubectl -n longhorn-system get pods
NAME                                                READY   STATUS    RESTARTS        AGE
csi-attacher-7656559cf4-pkhh6                       1/1     Running   0               103s
csi-attacher-7656559cf4-pnzw5                       1/1     Running   0               103s
csi-attacher-7656559cf4-z94mm                       1/1     Running   0               103s
csi-provisioner-6d9cf6456d-kcwtq                    1/1     Running   0               103s
csi-provisioner-6d9cf6456d-mvvml                    1/1     Running   0               103s
csi-provisioner-6d9cf6456d-q4f88                    1/1     Running   0               103s
csi-resizer-f587cd467-clr2n                         1/1     Running   0               103s
csi-resizer-f587cd467-z28v4                         1/1     Running   0               103s
csi-resizer-f587cd467-zxmtx                         1/1     Running   0               103s
csi-snapshotter-6dcdf78684-757mg                    1/1     Running   0               103s
csi-snapshotter-6dcdf78684-8ktgc                    1/1     Running   0               103s
csi-snapshotter-6dcdf78684-ffsqr                    1/1     Running   0               103s
engine-image-ei-099f845a-lvdtr                      1/1     Running   0               2m21s
instance-manager-4adffddaffe02374cd5635b8a6113de7   1/1     Running   0               111s
longhorn-csi-plugin-w7pwr                           3/3     Running   0               103s
longhorn-driver-deployer-6886fb84bc-wm9h6           1/1     Running   2 (2m32s ago)   2m45s
longhorn-manager-zblbl                              2/2     Running   0               2m45s
longhorn-ui-6bcc65d4bd-mcn6r                        1/1     Running   0               2m45s
longhorn-ui-6bcc65d4bd-rwf97                        1/1     Running   0               2m45s

13.3 SUSE Storage ボリュームの作成

 

SUSE Storage は、ポッド用の PersistentVolume オブジェクトを自動的にプロビジョニングするために、StorageClass と呼ばれる Kubernetes リソースを利用します。 StorageClass は、管理者が提供するストレージの クラス や プロファイル を記述するための手段であると考えてください。

いくつかのデフォルトオプションを指定して StorageClass を作成しましょう：

kubectl apply -f - <<EOF
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""
  fsType: "ext4"
EOF

StorageClass が配置されたので、それを参照する PersistentVolumeClaim が必要です。 PersistentVolumeClaim (PVC) は、ユーザーによるストレージの要求です。PVC は PersistentVolume リソースを消費します。 要求では、特定のサイズやアクセスモードを指定できます（例：読み取り/書き込みで1回マウント、または読み取り専用で複数回マウントなど）。

PersistentVolumeClaim を作成しましょう：

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: longhorn-volv-pvc
  namespace: longhorn-system
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-example
  resources:
    requests:
      storage: 2Gi
EOF

以上です！PersistentVolumeClaim が作成されたら、それを Pod にアタッチする作業に進むことができます。 Pod がデプロイされると、Kubernetes は Longhorn Volume を作成し、ストレージが利用可能な場合はそれを Pod にバインドします。

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
  namespace: longhorn-system
spec:
  containers:
  - name: volume-test
    image: nginx:stable-alpine
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: volv
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: volv
    persistentVolumeClaim:
      claimName: longhorn-volv-pvc
EOF
ヒント
ヒント

Kubernetes におけるストレージの概念は複雑ですが、重要なトピックです。最も一般的な Kubernetes リソースについて簡単に触れましたが、Longhorn が提供する 用語ドキュメント に目を通しておくことをお勧めします。

この例では、結果は次のようになるはずです：

localhost:~ # kubectl get storageclass
NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn (default)   driver.longhorn.io   Delete          Immediate           true                   12m
longhorn-example     driver.longhorn.io   Delete          Immediate           true                   24s

localhost:~ # kubectl get pvc -n longhorn-system
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
longhorn-volv-pvc   Bound    pvc-f663a92e-ac32-49ae-b8e5-8a6cc29a7d1e   2Gi        RWO            longhorn-example   54s

localhost:~ # kubectl get pods -n longhorn-system
NAME                                                READY   STATUS    RESTARTS      AGE
csi-attacher-5c4bfdcf59-qmjtz                       1/1     Running   0             14m
csi-attacher-5c4bfdcf59-s7n65                       1/1     Running   0             14m
csi-attacher-5c4bfdcf59-w9xgs                       1/1     Running   0             14m
csi-provisioner-667796df57-fmz2d                    1/1     Running   0             14m
csi-provisioner-667796df57-p7rjr                    1/1     Running   0             14m
csi-provisioner-667796df57-w9fdq                    1/1     Running   0             14m
csi-resizer-694f8f5f64-2rb8v                        1/1     Running   0             14m
csi-resizer-694f8f5f64-z9v9x                        1/1     Running   0             14m
csi-resizer-694f8f5f64-zlncz                        1/1     Running   0             14m
csi-snapshotter-959b69d4b-5dpvj                     1/1     Running   0             14m
csi-snapshotter-959b69d4b-lwwkv                     1/1     Running   0             14m
csi-snapshotter-959b69d4b-tzhwc                     1/1     Running   0             14m
engine-image-ei-5cefaf2b-hvdv5                      1/1     Running   0             14m
instance-manager-0ee452a2e9583753e35ad00602250c5b   1/1     Running   0             14m
longhorn-csi-plugin-gd2jx                           3/3     Running   0             14m
longhorn-driver-deployer-9f4fc86-j6h2b              1/1     Running   0             15m
longhorn-manager-z4lnl                              1/1     Running   0             15m
longhorn-ui-5f4b7bbf69-bln7h                        1/1     Running   3 (14m ago)   15m
longhorn-ui-5f4b7bbf69-lh97n                        1/1     Running   3 (14m ago)   15m
volume-test                                         1/1     Running   0             26s

13.4 UIへのアクセス

 

kubectl または Helm を使用して SUSE Storage をインストールした場合は、クラスターへの外部トラフィックを許可するために Ingress コントローラーをセットアップする必要があります。認証はデフォルトでは有効になっていません。Rancherカタログアプリが使用されていた場合、Rancherはアクセス制御（rancher-proxy）を備えたIngressコントローラーを自動的に作成しました。

  1. Longhornの外部サービスIPアドレスを取得します。

    kubectl -n longhorn-system get svc

  2. longhorn-frontend IPアドレスを取得したら、ブラウザーでそのアドレスに移動してUIの使用を開始できます。

13.5 Edge Image Builderを使用したインストール

 

SUSE Edgeは、ベースとなるSUSE Linux Micro OSイメージをカスタマイズするために第8章 「Edge Image Builder」を使用しています。 その上にSUSE Storageを搭載したRKE2クラスターをプロビジョニングする方法を説明します。

定義ファイルを作成しましょう。

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR

cat << EOF > $CONFIG_DIR/iso-definition.yaml
apiVersion: 1.3
image:
  imageType: iso
  baseImage: SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
  arch: x86_64
  outputImageName: eib-image.iso
kubernetes:
  version: v1.35.4+rke2r1
  helm:
    charts:
      - name: suse-storage
        releaseName: longhorn
        version: 1.11.2
        repositoryName: rancher-application-collection
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
    repositories:
      - name: rancher-application-collection
        url: oci://dp.apps.rancher.io/charts
        authentication:
          username: $APPS.RANCHER.IO_USERNAME
          password: $APPS.RANCHER.IO_ACCESS_TOKEN
embeddedArtifactRegistry:
  registries:
    - uri: dp.apps.rancher.io
      authentication:
        username: $APPS.RANCHER.IO_USERNAME
        password: $APPS.RANCHER.IO_ACCESS_TOKEN
  images:
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-attacher:4.11.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-provisioner:5.3.0-14.1
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-resizer:2.1.0-6.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-snapshotter:8.5.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-livenessprobe:2.18.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-node-driver-registrar:2.16.0-13.2
    - name: dp.apps.rancher.io/containers/longhorn-backing-image-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-engine:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-instance-manager:1.11.2-4.3
    - name: dp.apps.rancher.io/containers/longhorn-manager:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-share-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-ui:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/rancher-support-bundle-kit:0.0.84-9.4
operatingSystem:
  packages:
    sccRegistrationCode: <reg-code>
    packageList:
      - open-iscsi
  users:
  - username: root
    encryptedPassword: \$6\$jHugJNNd3HElGsUZ\$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
EOF
注記
注記

Helmチャートの値は、`helm.charts[].valuesFile`で提供される別のファイルを使用してカスタマイズできます。 詳細については、https://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/building-images.md#kubernetes[アップストリームのドキュメント]を参照してください。

イメージをビルドしましょう。

podman run --rm --privileged -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file $CONFIG_DIR/iso-definition.yaml

イメージのビルドが完了したら、それを使用して物理ホストまたは仮想ホストにOSをインストールできます。 プロビジョニングが完了したら、`root:eib`の資格情報ペアを使用してシステムにログインできます。

SUSE Storageが正常にデプロイされたことを確認してください。

localhost:~ # /var/lib/rancher/rke2/bin/kubectl --kubeconfig /etc/rancher/rke2/rke2.yaml -n longhorn-system get pods
NAME                                                READY   STATUS    RESTARTS        AGE
csi-attacher-5c4bfdcf59-qmjtz                       1/1     Running   0               103s
csi-attacher-5c4bfdcf59-s7n65                       1/1     Running   0               103s
csi-attacher-5c4bfdcf59-w9xgs                       1/1     Running   0               103s
csi-provisioner-667796df57-fmz2d                    1/1     Running   0               103s
csi-provisioner-667796df57-p7rjr                    1/1     Running   0               103s
csi-provisioner-667796df57-w9fdq                    1/1     Running   0               103s
csi-resizer-694f8f5f64-2rb8v                        1/1     Running   0               103s
csi-resizer-694f8f5f64-z9v9x                        1/1     Running   0               103s
csi-resizer-694f8f5f64-zlncz                        1/1     Running   0               103s
csi-snapshotter-959b69d4b-5dpvj                     1/1     Running   0               103s
csi-snapshotter-959b69d4b-lwwkv                     1/1     Running   0               103s
csi-snapshotter-959b69d4b-tzhwc                     1/1     Running   0               103s
engine-image-ei-5cefaf2b-hvdv5                      1/1     Running   0               109s
instance-manager-0ee452a2e9583753e35ad00602250c5b   1/1     Running   0               109s
longhorn-csi-plugin-gd2jx                           3/3     Running   0               103s
longhorn-driver-deployer-9f4fc86-j6h2b              1/1     Running   0               2m28s
longhorn-manager-z4lnl                              1/1     Running   0               2m28s
longhorn-ui-5f4b7bbf69-bln7h                        1/1     Running   3 (2m7s ago)    2m28s
longhorn-ui-5f4b7bbf69-lh97n                        1/1     Running   3 (2m10s ago)   2m28s
注記
注記

このインストールは、完全にエアギャップ(された)環境では機能しません。 そのような場合は、25.8項 「SUSE Storageのインストール」を参照してください。

SUSE Securityは、L7ネットワークセキュリティ、ランタイムセキュリティ、サプライチェーンセキュリティ、およびコンプライアンスチェックを統合パッケージとして提供する、Kubernetes向けのセキュリティソリューションです。

SUSE Securityは、複数のコンテナのプラットフォームとしてデプロイされる製品であり、各コンテナはさまざまなポートやインターフェースを介して通信します。その内部では、基盤となるコンテナセキュリティコンポーネントとしてNeuVectorを使用しています。SUSE Securityプラットフォームは、以下のコンテナで構成されています。

  • マネージャWebベースのコンソールを提供するステートレスコンテナです。通常は1つあれば十分であり、どこでも実行可能です。マネージャのエラーが発生しても、コントローラやEnforcerの動作には一切影響しません。ただし、特定の通知（イベント）や最近の接続データはマネージャによってメモリ内にキャッシュされるため、これらを表示することはできなくなります。

  • コントローラSUSE Securityの「コントロールプレーン」はHA構成でデプロイする必要があるため、ノード障害が発生しても設定が失われることはありません。これらはどこでも実行可能ですが、その重要性から「管理」ノード、マスターノード、またはインフラノードに配置されることが一般的です。

  • EnforcerこのコンテナはDaemonSetとしてデプロイされるため、保護対象のすべてのノードに1つのEnforcerが配置されます。通常はすべてのワーカーノードにデプロイされますが、マスターノードやインフラノードでもデプロイできるようにスケジューリングを有効にすることも可能です。注意:Enforcerがクラスターノード上に存在せず、そのノード上のポッドから接続が発生した場合、SUSE Securityはそれらを「管理対象外」のワークロードとしてラベル付けします。

  • スキャナーコントローラの指示に従い、ビルトインのCVEデータベースを使用して脆弱性スキャンを実行します。スキャン容量を増やすために、複数のスキャナーをデプロイできます。スキャナーはどこでも実行できますが、多くの場合、コントローラが実行されているノードで実行されます。スキャナーノードのサイジングに関する考慮事項については、以下を参照してください。スキャナーは、ビルドフェーズでのスキャンに使用する場合、例えばスキャンをトリガーして結果を取得し、スキャナーを停止するパイプライン内で、独立して呼び出すこともできます。スキャナーには最新のCVEデータベースが含まれているため、毎日更新する必要があります。

  • アップデーター。アップデーターは、CVEデータベースの更新が必要なときに、KubernetesのCronジョブを通じてスキャナーの更新をトリガーします。ご使用の環境に合わせて必ず設定してください。

SUSE Securityのより詳細なオンボーディングおよびベストプラクティスに関するドキュメントは、 こちらから入手できます。

14.1 SUSE EdgeはどのようにSUSE Securityを使用しますか？

 

SUSE Edgeは、エッジデプロイメントの出発点として、より軽量なSUSE Security構成を提供します。

14.2 重要な注意事項

 

  • `Scanner`コンテナには、スキャン対象のイメージをメモリにプルして開くための十分なメモリが必要です。1 GBを超えるイメージをスキャンするには、スキャナーのメモリを、想定される最大のイメージサイズよりわずかに大きく増やしてください。

  • 保護モードでは、高いネットワーク接続が予想されます。`Enforcer`は、保護（インラインファイアウォールブロッキング）モード時に、接続およびペイロード（DLP）の可能性を保持・検査するためにCPUとメモリを必要とします。メモリを増やし、`Enforcer`にCPUコアを割り当てることで、十分なパケットフィルタリング容量を確保できます。

14.3 Edge Image Builderを使用したインストール

 

SUSE Edgeは、ベースとなるSUSE Linux Micro OSイメージをカスタマイズするために第8章 「Edge Image Builder」を使用しています。 EIBによってプロビジョニングされたKubernetesクラスター上でSUSE Securityを、エアギャップ(された)環境でインストールするには、25.7項 「SUSE Securityインストール」に従ってください。

15 MetalLB

 

MetalLB公式ドキュメントを参照してください。

MetalLBは、標準的なルーティングプロトコルを使用する、ベアメタルKubernetesクラスター向けのロードバランサー実装です。

ベアメタル環境では、ネットワークロードバランサーのセットアップはクラウド環境よりも著しく複雑です。クラウドセットアップにおける単純なAPI呼び出しとは異なり、ベアメタルでは、高可用性（HA）を管理したり、単一ノードのロードバランサーに固有の潜在的な単一障害点（SPOF）に対処したりするために、専用のネットワークアプライアンス、またはロードバランサーと仮想IP（VIP）構成の組み合わせが必要になります。これらの構成は容易に自動化できず、コンポーネントが動的にスケールアップおよびスケールダウンするKubernetesデプロイメントにおいて課題となります。

MetalLBは、Kubernetesモデルを活用して、ベアメタルセットアップであってもクラウド環境で動作しているかのように、ロードバランサー型のサービスを作成することで、これらの課題に対処します。

L2モード（ARP _トリック_を使用）または BGPを介した、2つの異なるアプローチがあります。主にL2は特別なネットワーク機器を必要としませんが、一般的にはBGPの方が優れています。ユースケースによります。

15.1 SUSE EdgeはどのようにMetalLBを使用しますか？

 

SUSE EdgeはMetalLBを3つの主要な方法で使用します。

  • ロードバランサーソリューションとして：MetalLBは、ベアメタルマシンのロードバランサーソリューションとして機能します。

  • HA K3s/RKE2セットアップの場合：MetalLBは、仮想IPアドレスを使用してKubernetes APIの負荷分散を可能にします。

  • L3 BGPソリューションとして、MetalLBはサービスIPへのルートを近隣のルーターにアドバタイズします。

注記
注記

APIを公開できるようにするため、Endpoint Copier Operator (第16章 「Endpoint Copier Operator」)を使用し、`kubernetes`サービスから`kubernetes-vip`ロードバランサーサービスへのK8s APIエンドポイントをsyncし続けます。

15.2 ベストプラクティス

 

L2モードでのMetalLBのインストールについては第21章 「K3s上のMetalLB（レイヤー2モードを使用）」で、L3モードについては第22章 「K3s上のMetalLB（レイヤー3モードを使用）」で説明されています。

高可用性トポロジーを実現するために`kube-api-server`の前にMetalLBをインストールするガイドは、第24章 「Kubernetes APIサーバーの前にあるMetalLB」にあります。

15.3 当バージョンの注意事項

 

  • K3sには、Klipper`と呼ばれるロードバランサーソリューションが付属しています。MetalLBを使用するには、`Klipper`を無効にする必要があります。これは、 K3sドキュメントで説明されているように、--disable servicelb`オプションを指定してK3sサーバーを起動することで実行できます。

16 Endpoint Copier Operator

 

Endpoint Copier Operatorは、KubernetesのServiceとEndpointのコピーを作成し、それらをsyncし続けることを目的としたKubernetesオペレーターです。

16.1 SUSE EdgeはどのようにEndpoint Copier Operatorを使用しますか？

 

SUSE Edgeにおいて、Endpoint Copier OperatorはK3s/RKE2クラスターの高可用性（HA）セットアップを実現する上で重要な役割を果たします。これは、タイプ`kubernetes-vip`の`LoadBalancer`サービスを作成し、そのEndpointがKubernetesのEndpointと常に同期されるようにすることで実現されます。MetalLB (第15章 「MetalLB」)は`kubernetes-vip`サービスの管理に活用されており、公開されたIPアドレスは他のノードからクラスターに参加するために使用されます。

16.2 ベストプラクティス

 

Endpoint Copier Operatorの使用に関する包括的なドキュメントは、 こちらにあります。

さらに、Endpoint Copier OperatorとMetalLBを使用したK3s/RKE2 HAセットアップの実現に関するガイド (第21章 「K3s上のMetalLB（レイヤー2モードを使用）」)も参照してください。

16.3 当バージョンの注意事項

 

現在、Endpoint Copier Operatorは1つのService/Endpointのみを扱うように制限されています。複数のService/Endpointをサポートするための機能強化が将来的に計画されています。

17 エッジ仮想化

 

このセクションでは、エッジ仮想化を使用してエッジノード上で仮想マシンを実行する方法について説明します。エッジ仮想化は、軽量な仮想化のユースケース向けに設計されており、仮想化アプリケーションとコンテナ化アプリケーションの両方の展開と管理に共通のワークフローが利用されることが想定されています。

SUSE Edge 仮想化には、仮想マシンを実行するための2つの方法があります。

  1. ホストレベルでlibvirt+qemu-kvmを介して仮想マシンを手動でデプロイする（Kubernetesが関与しない場合）

  2. Kubernetesベースの仮想マシン管理のためにKubeVirtオペレーターをデプロイする

どちらのオプションも有効ですが、以下では2番目のオプションのみを扱います。SUSE Linux Microが提供する標準のすぐに使える仮想化メカニズムを使用したい場合は、包括的なガイドが こちらにあります。これは主にSUSE Linux Enterprise Server向けに書かれていますが、概念はほぼ同じです。

本ガイドでは、まず、すでにデプロイ済みのシステムに追加の仮想化コンポーネントをデプロイする方法を説明し、続いて、Edge Image Builderを使用して初期デプロイにこの構成を組み込む方法を説明するセクションを設けています。基本事項を確認せず、手動で設定を行いたい場合は、そのセクションまでスキップしてください。

17.1 KubeVirtの概要

 

KubeVirtを使用すると、他のコンテナ化されたワークロードと並行して、Kubernetesで仮想マシンを管理できます。これは、Linux仮想化スタックのユーザスペース部分をコンテナ内で実行することで実現されます。これにより、ホストシステムへの要件が最小限に抑えられ、セットアップと管理が容易になります。

KubeVirtのアーキテクチャの詳細については、アップストリームのドキュメントを参照してください。

17.2 前提条件

 

このガイドに従う場合、以下のものがすでに利用可能であることを前提としています。

  • SUSE Linux Micro 6.2がインストールされ、BIOSで仮想化拡張機能が有効になっている物理ホストが少なくとも1台（詳細はhttps://documentation.suse.com/sles/15-SP6/html/SLES-all/cha-virt-support.html#sec-kvm-requires-hardware[こちら]を参照）。

  • ノード全体に、K3s/RKE2 Kubernetesクラスターがすでに展開されており、クラスターへのスーパーユーザアクセスを可能にする適切な`kubeconfig`があること。

  • ルートユーザへのアクセス — これらの手順は、あなたがルートユーザであり、not sudo を使って権限を昇格させていないことを前提としています。

  • ローカル環境で Helm が利用可能であり、Kubernetes クラスターへの設定のプッシュおよび必要なイメージのダウンロードが可能な適切なネットワーク接続があることを確認してください。

17.3 エッジ仮想化の手動インストール

 

このガイドでは Kubernetes のデプロイ手順については説明しませんが、SUSE Edge に適したバージョンの K3s または RKE2 がインストールされており、標準の kubectl コマンドをスーパーユーザーとして実行できるように kubeconfig が構成されていることを前提としています。ノードがシングルノードクラスターを構成していることを前提としていますが、マルチノードデプロイメントでも大きな違いはありません。

SUSE Edge Virtualization は、以下の3つの個別の Helm チャートを介してデプロイメントされます。

  • KubeVirt:仮想化のコアコンポーネントであり、Kubernetes が仮想マシンをデプロイおよび管理できるようにするために必要な Kubernetes CRD、オペレーター、およびその他のコンポーネントです。

  • KubeVirt Dashboard Extension:仮想マシンの起動/停止やコンソールへのアクセスなど、基本的な仮想マシン管理を可能にするオプションの Rancher UI 拡張機能です。

  • Containerized Data Importer (CDI):KubeVirt の永続ストレージ統合を可能にする追加コンポーネントです。仮想マシンがデータ用に既存の Kubernetes ストレージバックエンドを使用できるようにするだけでなく、ユーザーが仮想マシン用のデータボリュームをインポートまたはクローンすることも可能にします。

これらの Helm チャートはそれぞれ、現在使用している SUSE Edge リリースに合わせてバージョン管理されています。本番環境やサポート対象の用途では、SUSE Registry にあるアーティファクトを使用してください。

まず、kubectl アクセスが機能していることを確認します。

$ kubectl get nodes

以下のような出力が表示されるはずです。

NAME                   STATUS   ROLES                       AGE     VERSION
node1.edge.rdo.wales   Ready    control-plane,etcd,master   4h20m   v1.30.5+rke2r1
node2.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1
node3.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1

これで、KubeVirt および Containerized Data Importer (CDI) Helm チャートのインストールに進むことができます。

$ helm install kubevirt oci://registry.suse.com/edge/charts/kubevirt --namespace kubevirt-system --create-namespace
$ helm install cdi oci://registry.suse.com/edge/charts/cdi --namespace cdi-system --create-namespace

数分以内に、すべての KubeVirt および CDI コンポーネントがデプロイされます。これは、kubevirt-system および cdi-system 名前空間にデプロイされたすべてのリソースを確認することで検証できます。

KubeVirt リソースの検証:

$ kubectl get all -n kubevirt-system

以下のような出力が表示されるはずです。

NAME                                   READY   STATUS    RESTARTS      AGE
pod/virt-operator-5fbcf48d58-p7xpm     1/1     Running   0             2m24s
pod/virt-operator-5fbcf48d58-wnf6s     1/1     Running   0             2m24s
pod/virt-handler-t594x                 1/1     Running   0             93s
pod/virt-controller-5f84c69884-cwjvd   1/1     Running   1 (64s ago)   93s
pod/virt-controller-5f84c69884-xxw6q   1/1     Running   1 (64s ago)   93s
pod/virt-api-7dfc54cf95-v8kcl          1/1     Running   1 (59s ago)   118s

NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubevirt-prometheus-metrics   ClusterIP   None            <none>        443/TCP   2m1s
service/virt-api                      ClusterIP   10.43.56.140    <none>        443/TCP   2m1s
service/kubevirt-operator-webhook     ClusterIP   10.43.201.121   <none>        443/TCP   2m1s
service/virt-exportproxy              ClusterIP   10.43.83.23     <none>        443/TCP   2m1s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/virt-handler   1         1         1       1            1           kubernetes.io/os=linux   93s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/virt-operator     2/2     2            2           2m24s
deployment.apps/virt-controller   2/2     2            2           93s
deployment.apps/virt-api          1/1     1            1           118s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/virt-operator-5fbcf48d58     2         2         2       2m24s
replicaset.apps/virt-controller-5f84c69884   2         2         2       93s
replicaset.apps/virt-api-7dfc54cf95          1         1         1       118s

NAME                            AGE     PHASE
kubevirt.kubevirt.io/kubevirt   2m24s   Deployed

CDI リソースの検証:

$ kubectl get all -n cdi-system

以下のような出力が表示されるはずです。

NAME                                   READY   STATUS    RESTARTS   AGE
pod/cdi-operator-55c74f4b86-692xb      1/1     Running   0          2m24s
pod/cdi-apiserver-db465b888-62lvr      1/1     Running   0          2m21s
pod/cdi-deployment-56c7d74995-mgkfn    1/1     Running   0          2m21s
pod/cdi-uploadproxy-7d7b94b968-6kxc2   1/1     Running   0          2m22s

NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/cdi-uploadproxy          ClusterIP   10.43.117.7    <none>        443/TCP    2m22s
service/cdi-api                  ClusterIP   10.43.20.101   <none>        443/TCP    2m22s
service/cdi-prometheus-metrics   ClusterIP   10.43.39.153   <none>        8080/TCP   2m21s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cdi-operator      1/1     1            1           2m24s
deployment.apps/cdi-apiserver     1/1     1            1           2m22s
deployment.apps/cdi-deployment    1/1     1            1           2m21s
deployment.apps/cdi-uploadproxy   1/1     1            1           2m22s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/cdi-operator-55c74f4b86      1         1         1       2m24s
replicaset.apps/cdi-apiserver-db465b888      1         1         1       2m21s
replicaset.apps/cdi-deployment-56c7d74995    1         1         1       2m21s
replicaset.apps/cdi-uploadproxy-7d7b94b968   1         1         1       2m22s

VirtualMachine カスタムリソース定義（CRD）がデプロイされていることを確認するには、以下を使用して検証できます。

$ kubectl explain virtualmachine

これにより VirtualMachine オブジェクトの定義が出力されるはずであり、以下のように表示されます。

GROUP:      kubevirt.io
KIND:       VirtualMachine
VERSION:    v1

DESCRIPTION:
    VirtualMachine handles the VirtualMachines that are not running or are in a
    stopped state The VirtualMachine contains the template to create the
    VirtualMachineInstance. It also mirrors the running state of the created
    VirtualMachineInstance in its status.
(snip)

17.4 仮想マシンのデプロイ

 

KubeVirt と CDI がデプロイされたので、 openSUSE Tumbleweed に基づく単純な仮想マシンを定義してみましょう。この仮想マシンは最も単純な設定であり、他のポッドと同じネットワーク設定にするために標準の「ポッドネットワーク」を使用しています。また、非永続ストレージを採用しているため、 PVC を持たないコンテナと同様に、ストレージはエフェメラル (一時的) になります。

$ cat <<EOF > user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: tumbleweed
  namespace: default
spec:
  runStrategy: Always
  template:
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: quay.io/containerdisks/opensuse-tumbleweed:1.0.0
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: $(cat user-data.yaml | base64 -w 0)
        name: cloudinitdisk
EOF

これにより、VirtualMachine が作成されたことが出力されるはずです。

virtualmachine.kubevirt.io/tumbleweed created

この VirtualMachine 定義は最小限であり、設定に関する詳細はほとんど指定されていません。これは単に、2 GB のメモリを備えたマシンタイプ「 q35」であり、エフェメラル containerDisk (つまり、リモートイメージリポジトリのコンテナイメージに保存されるディスクイメージ) に基づくディスクイメージを使用すること、および起動時にユーザー作成とパスワード強制のためにのみ使用される base64 エンコードされた cloudInit ディスクを指定していることを示しています (base64 -d を使用してデコードしてください)。

注記
注記

この仮想マシンイメージはテスト専用です。このイメージは公式にサポートされておらず、ドキュメントの例としてのみ提供されています。

このマシンは openSUSE Tumbleweed ディスクイメージをダウンロードする必要があるため、起動に数分かかります。ダウンロードが完了したら、仮想マシンの情報を確認して、仮想マシンの詳細を表示できます。

$ kubectl get vmi

これにより、仮想マシンが起動されたノードと、仮想マシンの IP アドレスが表示されます。ポッドネットワークを使用しているため、報告される IP アドレスは他のポッドと同様であり、そのようにルーティング可能であることに注意してください。

NAME         AGE     PHASE     IP           NODENAME               READY
tumbleweed   4m24s   Running   10.42.2.98   node3.edge.rdo.wales   True

これらのコマンドを Kubernetes クラスターノード自体で実行し、トラフィックをポッドに直接ルーティングする CNI (Cilium など) を使用している場合は、マシン自体に直接 ssh できるはずです。以下の IP アドレスを、仮想マシンに割り当てられたものに置き換えてください。

$ ssh suse@10.42.2.98
(password is "suse")

この仮想マシンに入ったら自由に操作できますが、リソースが制限されており、ディスク容量が 1 GB しかないことに注意してください。終了したら、Ctrl-D または exit を実行して SSH セッションから切断します。

仮想マシンプロセスは、引き続き標準の Kubernetes ポッドにラップされています。VirtualMachine CRD は目的の仮想マシンを表すものですが、仮想マシンが実際に起動されるプロセスは、他のアプリケーションと同様に、標準の Kubernetes ポッドである virt-launcher ポッドを介して行われます。起動した仮想マシンごとに、virt-launcher ポッドがあることがわかります。

$ kubectl get pods

これにより、定義した Tumbleweed マシンの virt-launcher ポッドが表示されるはずです。

NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-tumbleweed-8gcn4   3/3     Running   0          10m

この`virt-launcher`ポッドの中を見ると、`libvirt`プロセスと`qemu-kvm`プロセスが実行されていることがわかります。ポッド自体に入って内部を確認できます。その際、以下のコマンドを自分のポッド名に合わせて調整する必要があることに注意してください。

$ kubectl exec -it virt-launcher-tumbleweed-8gcn4 -- bash

ポッドに入ったら、プロセスを確認するとともに、virsh コマンドを実行してみてください。qemu-system-x86_64 バイナリが実行されている様子と、仮想マシンを監視するための特定のプロセスを確認できます。また、ディスクイメージの場所や、ネットワークがどのように接続されているか（tap デバイスとして）も確認できます。

qemu@tumbleweed:/> ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ssl    0:00 /usr/bin/virt-launcher-monitor --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kube
   12 ?        Sl     0:01 /usr/bin/virt-launcher --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kubevirt/con
   24 ?        Sl     0:00 /usr/sbin/virtlogd -f /etc/libvirt/virtlogd.conf
   25 ?        Sl     0:01 /usr/sbin/virtqemud -f /var/run/libvirt/virtqemud.conf
   83 ?        Sl     0:31 /usr/bin/qemu-system-x86_64 -name guest=default_tumbleweed,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-default_tumbleweed/master-key.aes"} -machine pc-q35-7.1,usb
  286 pts/0    Ss     0:00 bash
  320 pts/0    R+     0:00 ps ax

qemu@tumbleweed:/> virsh list --all
 Id   Name                 State
------------------------------------
 1    default_tumbleweed   running

qemu@tumbleweed:/> virsh domblklist 1
 Target   Source
---------------------------------------------------------------------------------------------
 sda      /var/run/kubevirt-ephemeral-disks/disk-data/tumbleweed-containerdisk-0/disk.qcow2
 sdb      /var/run/kubevirt-ephemeral-disks/cloud-init-data/default/tumbleweed/noCloud.iso

qemu@tumbleweed:/> virsh domiflist 1
 Interface   Type       Source   Model                     MAC
------------------------------------------------------------------------------
 tap0        ethernet   -        virtio-non-transitional   e6:e9:1a:05:c0:92

qemu@tumbleweed:/> exit
exit

最後に、この仮想マシンを削除してクリーンアップしましょう。

$ kubectl delete vm/tumbleweed
virtualmachine.kubevirt.io "tumbleweed" deleted

17.5 virtctl の使用

 

標準的な Kubernetes CLI ツールである kubectl に加え、KubeVirt には付随する CLI ユーティリティが用意されており、仮想化の世界と Kubernetes が設計された世界との間のギャップを埋めるような方法でクラスターとやり取りすることができます。例えば、virtctl ツールは、仮想マシンのライフサイクル管理（起動、停止、再起動など）、仮想コンソールへのアクセス、仮想マシンイメージのアップロード、さらには API や CRD を直接使用せずにサービスなどの Kubernetes 構成要素とやり取りする機能を提供します。

virtctl ツールの最新の安定版をダウンロードしましょう。

$ export VERSION=v0.7.0
$ wget https://github.com/kubevirt/kubevirt/releases/download/$VERSION/virtctl-$VERSION-linux-amd64

異なるアーキテクチャや Linux 以外のマシンを使用している場合は、他のリリースを こちらから見つけることができます。続行する前にこれを実行可能にする必要があります。また、`$PATH`内の場所に移動しておくと便利かもしれません。

$ mv virtctl-$VERSION-linux-amd64 /usr/local/bin/virtctl
$ chmod a+x /usr/local/bin/virtctl

その後、virtctl コマンドラインツールを使用して仮想マシンを作成できます。以前の仮想マシンを複製してみましょう。出力を直接`kubectl apply`にパイプしていることに注意してください。

$ cat <<EOF >  user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ alias virtctl=echo
$ virtctl create vm --name virtctl-example --memory=1Gi \
    --volume-containerdisk=src:quay.io/containerdisks/opensuse-tumbleweed:1.0.0 \
    --cloud-init-user-data "$(cat user-data.yaml | base64 -w 0)"

これで仮想マシンが実行されていることが表示されるはずです（コンテナイメージがキャッシュされるため、今回ははるかに早く起動するはずです）。

$ kubectl get vmi
NAME              AGE   PHASE     IP           NODENAME               READY
virtctl-example   52s   Running   10.42.2.29   node3.edge.rdo.wales   True

これで`virtctl`を使用して仮想マシンに直接接続できます。

$ virtctl ssh suse@virtctl-example
(password is "suse" - Ctrl-D to exit)

`virtctl`で使用できる他のコマンドはたくさんあります。例えば、ネットワークが機能していない場合に`virtctl console`を使用してシリアルコンソールにアクセスしたり、`virtctl guestosinfo`を使用して包括的なOS情報を取得したりできます。ただし、ゲストに`qemu-guest-agent`がインストールされ、実行されている必要があります。

最後に、仮想マシンを一時停止して再開してみましょう。

$ virtctl pause vm virtctl-example
VMI virtctl-example was scheduled to pause

VirtualMachine オブジェクトが Paused と表示され、VirtualMachineInstance オブジェクトが Running と表示されますが、READY=False であることがわかります。

$ kubectl get vm
NAME              AGE     STATUS   READY
virtctl-example   8m14s   Paused   False

$ kubectl get vmi
NAME              AGE     PHASE     IP           NODENAME               READY
virtctl-example   8m15s   Running   10.42.2.29   node3.edge.rdo.wales   False

また、仮想マシンに接続できなくなったこともわかります。

$ virtctl ssh suse@virtctl-example
can't access VMI virtctl-example: Operation cannot be fulfilled on virtualmachineinstance.kubevirt.io "virtctl-example": VMI is paused

仮想マシンを再開して、もう一度試してみましょう。

$ virtctl unpause vm virtctl-example
VMI virtctl-example was scheduled to unpause

これで接続を再確立できるはずです。

$ virtctl ssh suse@virtctl-example
suse@vmi/virtctl-example.default's password:
suse@virtctl-example:~> exit
logout

最後に、仮想マシンを削除しましょう。

$ kubectl delete vm/virtctl-example
virtualmachine.kubevirt.io "virtctl-example" deleted

17.6 単純なIngressネットワーキング

 

このセクションでは、仮想マシンを標準のKubernetesサービスとして公開し、例えば Traefik with RKE2 や Traefik with K3s といったKubernetes Ingressサービス経由で利用可能にする方法を説明します。このドキュメントでは、これらのコンポーネントがすでに適切に設定されており、適切なDNSポインタ（例えばワイルドカードなど）を使用して、適切なIngress解決のためにKubernetesサーバーノードまたはIngress仮想IPを指していることを前提としています。

注記
注記

SUSE Edge 3.1以降で、K3sをマルチサーバーノード構成で使用している場合、Ingress用にMetalLBベースのVIPを設定する必要があったかもしれませんが、RKE2ではこれは不要です。

この例の環境では、別のopenSUSE Tumbleweed仮想マシンがデプロイされ、cloud-initを使用して起動時にNGINXが単純なWebサーバーとしてインストールされます。また、呼び出しが行われた際に期待通りに動作することを確認するため、単純なメッセージが返されるように設定されています。これを行う方法を確認するには、以下の出力の base64 -d セクションをご覧ください。

それでは、この仮想マシンを作成しましょう。

$ cat <<EOF > user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: ingress-example
  namespace: default
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        app: nginx
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: quay.io/containerdisks/opensuse-tumbleweed:1.0.0
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: $(cat user-data.yaml | base64 -w 0)
        name: cloudinitdisk
EOF

この仮想マシンが正常に起動したら、virtctl コマンドを使用して、外部ポート 8080、ターゲットポート 80（NGINXがデフォルトでリスンするポート）で VirtualMachineInstance を公開できます。ここでは、仮想マシンオブジェクトとポッド間のマッピングを認識できるため、virtctl コマンドを使用します。これにより、新しいサービスが作成されます。

$ virtctl expose vmi ingress-example --port=8080 --target-port=80 --name=ingress-example
Service ingress-example successfully exposed for vmi ingress-example

そうすると、適切なサービスが自動的に作成されます。

$ kubectl get svc/ingress-example
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                         AGE
ingress-example   ClusterIP      10.43.217.19    <none>            8080/TCP                        9s

次に、kubectl create ingress を使用すると、このサービスを指すIngressオブジェクトを作成できます。ここでのURL（ ingress オブジェクトでは「ホスト」として知られています）をDNS設定に合わせて調整し、ポート 8080 を指すようにしてください。

$ kubectl create ingress ingress-example --rule=ingress-example.suse.local/=ingress-example:8080

DNSが正しく設定されていれば、すぐにURLに対してcurlを実行できるはずです。

$ curl ingress-example.suse.local
It works!

この仮想マシンとそのサービスおよびイングレスリソースを削除してクリーンアップしましょう。

$ kubectl delete vm/ingress-example svc/ingress-example ingress/ingress-example
virtualmachine.kubevirt.io "ingress-example" deleted
service "ingress-example" deleted
ingress.networking.k8s.io "ingress-example" deleted

17.7 Rancher UI拡張機能の使用

 

SUSE Edge VirtualizationはRancher Manager用のUI拡張機能を提供し、RancherダッシュボードUIを使用した基本的な仮想マシン管理を可能にします。

17.7.1 インストール

 

インストールガイダンスについては、Rancher Dashboard Extensions (第5章 「Rancherダッシュボード拡張機能」)を参照してください。

17.7.2 KubeVirt Rancherダッシュボード拡張機能の使用

 

この拡張機能により、Cluster Explorerに新しい*KubeVirt*セクションが追加されます。このセクションは、KubeVirtがインストールされているすべての管理対象クラスターに追加されます。

この拡張機能を使用すると、KubeVirt仮想マシンリソースを直接操作して、仮想マシンのライフサイクルを管理できます。

17.7.2.1 仮想マシンの作成

 

  1. 左側のナビゲーションでKubeVirtが有効な管理対象クラスターをクリックし、*Cluster Explorer*に移動します。

  2. *KubeVirt > Virtual Machines*ページに移動し、画面右上の`Create from YAML`をクリックします。

  3. 仮想マシンの定義を入力または貼り付けて、`Create`を押します。「仮想マシンのデプロイ」セクションの仮想マシン定義を参考にしてください。

virtual machines page

17.7.2.2 仮想マシンのアクション

 

各仮想マシンの右側にある*⋮*ドロップダウンリストからアクセスできるアクションメニューを使用して、開始、停止、一時停止、またはソフト再起動のアクションを実行できます。または、アクションを実行する仮想マシンを選択して、リストの上部にあるグループアクションを使用することもできます。

アクションを実行すると、仮想マシンの実行戦略に影響を与える可能性があります。詳細については、 KubeVirtドキュメントの表を参照してください。

17.7.2.3 仮想マシンコンソールへのアクセス

 

「Virtual machines」リストには、*VNCまたはシリアルコンソール*を使用してマシンに接続できる`Console`ドロップダウンリストが用意されています。このアクションは、実行中のマシンでのみ利用可能です。

仮想マシンを起動した直後は、コンソールにアクセスできるようになるまで少し時間がかかる場合があります。

vnc console ui

17.8 Edge Image Builderを使用したインストール

 

SUSE Edgeは、ベースとなるSUSE Linux Micro OSイメージをカスタマイズするために第8章 「Edge Image Builder」を使用しています。 25.9項 「KubeVirtおよびCDIのインストール」に従って、EIBによってプロビジョニングされたKubernetesクラスター上で、KubeVirtとCDIの両方をエアギャップ(された)インストールしてください。

18 System Upgrade Controller

 

System Upgrade Controllerのドキュメントを参照してください。

System Upgrade Controller（SUC）は、汎用的なKubernetesネイティブのアップグレードコントローラー（ノード用）を提供することを目的としています。これは、アップグレードポリシーや要件を定義するための新しいCRDである「Plan」を導入します。Planとは、クラスター内のノードの変更を意図した計画です。

18.1 SUSE EdgeはどのようにSystem Upgrade Controllerを使用しますか？

 

SUSE Edgeは`SUC`を使用して、管理クラスターおよびダウンストリームクラスターにおけるOSとKubernetesのバージョンアップグレードに関連するさまざまな「Day 2」オペレーションを促進します。

「Day 2」オペレーションは`SUC Plans`を通じて定義されます。これらのプランに基づいて、`SUC`は各ノードにワークロードをデプロイし、それぞれの「Day 2」オペレーションを実行します。

`SUC`は第19章 「Upgrade Controller」内でも使用されます。SUCとUpgrade Controllerの主な違いの詳細については、19.2項 「Upgrade Controller vs System Upgrade Controller」を参照してください。

18.2 System Upgrade Controllerのインストール

 
重要
重要

Rancher v2.10.0以降、`System Upgrade Controller`は自動的にインストールされます。

以下の手順は、環境がRancherによって管理されていない場合、またはRancherのバージョンが`v2.10.0`より低い場合のみ実行してください。

suse-edge/fleet-examplesリポジトリにあるFleet (第6章 「Fleet」)を使用してSUCをインストールすることをお勧めします。

注記
注記

`suse-edge/fleet-examples`リポジトリによって提供されるリソースは、*必ず*有効なfleet-examplesリリースから使用する必要があります。使用する必要があるリリースを確認するには、リリースノート (第41章 「リリースノート」)を参照してください。

Fleetを使用してSUCをインストールできない場合は、RancherのHelmチャートリポジトリからインストールするか、RancherのHelmチャートを独自のサードパーティGitOpsワークフローに組み込むことができます。

このセクションでは、次の内容について説明します。

18.2.1 System Upgrade Controller Fleetのインストール

 

Fleetを使用する場合、SUCのデプロイに使用できるリソースは2つあります：

18.2.1.1 System Upgrade Controllerのインストール - GitRepo

 
注記
注記

このプロセスは、Rancher UIが利用可能な場合は、それを通じて行うこともできます。詳細については、Rancher UIでのFleetへのアクセスを参照してください。

*管理*クラスターで：

  1. SUCをデプロイするクラスターを決定します。これは、*管理*クラスター上の適切なFleetワークスペースにSUC `GitRepo`リソースをデプロイすることで実行されます。デフォルトでは、Fleetには2つのワークスペースがあります：

    • fleet-local - *管理*クラスターにデプロイする必要があるリソース用。

    • fleet-default - *ダウンストリーム*クラスターにデプロイする必要があるリソース用。

      Fleetワークスペースの詳細については、アップストリームのドキュメントを参照してください。

  2. `GitRepo`リソースをデプロイします：

    • 管理クラスターにSUCをデプロイするには：

      kubectl apply -n fleet-local -f - <<EOF
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: system-upgrade-controller
spec:
  revision: release-3.6.1
  paths:
  - fleets/day2/system-upgrade-controller
  repo: https://github.com/suse-edge/fleet-examples.git
EOF

    • ダウンストリームクラスターにSUCをデプロイするには：

      注記
      注記

      以下のリソースをデプロイする前に、Fleetがどのダウンストリームクラスターにリソースをデプロイすべきかを認識できるよう、有効な targets 設定を 指定する必要があります。ダウンストリームクラスターへのマッピング方法については、ダウンストリームクラスターへのマッピング を参照してください。

      kubectl apply -n fleet-default -f - <<EOF
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: system-upgrade-controller
spec:
  revision: release-3.6.1
  paths:
  - fleets/day2/system-upgrade-controller
  repo: https://github.com/suse-edge/fleet-examples.git
  targets:
  - clusterSelector: CHANGEME
  # Example matching all clusters:
  # targets:
  # - clusterSelector: {}
EOF

  3. GitRepo リソースがデプロイされていることを確認します:

    # Namespace will vary based on where you want to deploy SUC
kubectl get gitrepo system-upgrade-controller -n <fleet-local/fleet-default>

NAME                        REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
system-upgrade-controller   https://github.com/suse-edge/fleet-examples.git   release-3.6.1   1/1

  4. System Upgrade Controllerのデプロイメントを検証します:

    kubectl get deployment system-upgrade-controller -n cattle-system
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
system-upgrade-controller   1/1     1            1           2m20s

18.2.1.2 System Upgrade Controllerのインストール - Bundle

 

このセクションでは、fleet-cli を使用して、標準のFleet構成から Bundle リソースをビルドおよびデプロイする方法を説明します。

  1. ネットワークアクセスが可能なマシンで fleet-cli をダウンロードします:

    注記
    注記

    ダウンロードするfleet-cliのバージョンが、クラスターにデプロイされているFleetのバージョンと一致していることを確認してください。

    • Macユーザー向けには、fleet-cli のHomebrew Formulaeが用意されています。

    • LinuxおよびWindowsユーザー向けには、各Fleet リリースの assets としてバイナリが提供されています。

      • Linux AMD：

        curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/vv0.15.2/fleet-linux-amd64

      • Linux ARM：

        curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/vv0.15.2/fleet-linux-arm64

  2. fleet-cli を実行可能にしてください:

    chmod +x fleet-cli

  3. 使用する suse-edge/fleet-examples リリース をクローンします:

    git clone -b release-3.6.1 https://github.com/suse-edge/fleet-examples.git

  4. fleet-examples リポジトリにあるSUC fleetに移動します:

    cd fleet-examples/fleets/day2/system-upgrade-controller

  5. SUCをデプロイするクラスターを決定します。これは、管理クラスター内の適切なFleetワークスペースにSUCバンドルをデプロイすることで実行されます。デフォルトでは、Fleetには2つのワークスペースがあります：

    • fleet-local - *管理*クラスターにデプロイする必要があるリソース用。

    • fleet-default - *ダウンストリーム*クラスターにデプロイする必要があるリソース用。

      Fleetワークスペースの詳細については、アップストリームのドキュメントを参照してください。

  6. SUCをダウンストリームクラスターのみにデプロイする場合は、特定のクラスターに一致する targets.yaml ファイルを作成してください:

    cat > targets.yaml <<EOF
targets:
- clusterSelector: CHANGEME
EOF

    ダウンストリームクラスターへのマッピング方法については、ダウンストリームクラスターへのマッピング を参照してください。

  7. バンドルのビルドに進みます:

    注記
    注記

    fleet-examples/fleets/day2/system-upgrade-controller ディレクトリにfleet-cliを*ダウンロードしない*ように注意してください。そうしないと、バンドルに同梱されてしまい、推奨されません。

    • 管理クラスターにSUCをデプロイするには、以下を実行します。

      fleet-cli apply --compress -n fleet-local -o - system-upgrade-controller . > system-upgrade-controller-bundle.yaml

    • ダウンストリームクラスターにSUCをデプロイするには、以下を実行します。

      fleet-cli apply --compress --targets-file=targets.yaml -n fleet-default -o - system-upgrade-controller . > system-upgrade-controller-bundle.yaml

      このプロセスの詳細については、Helmチャートをバンドルに変換するを参照してください。

      fleet-cli apply コマンドの詳細については、fleet applyを参照してください。

  8. system-upgrade-controller-bundle.yaml バンドルを管理クラスターのマシンに転送します。

    scp system-upgrade-controller-bundle.yaml <machine-address>:<filesystem-path>

  9. 管理クラスター上で、system-upgrade-controller-bundle.yaml バンドルをデプロイします。

    kubectl apply -f system-upgrade-controller-bundle.yaml

  10. 管理クラスター上で、バンドルがデプロイされていることを検証します。

    # Namespace will vary based on where you want to deploy SUC
kubectl get bundle system-upgrade-controller -n <fleet-local/fleet-default>

NAME                        BUNDLEDEPLOYMENTS-READY   STATUS
system-upgrade-controller   1/1

  11. バンドルをデプロイしたFleetワークスペースに基づいて、クラスターに移動し、SUCのデプロイを検証します。

    注記
    注記

    SUCは常に cattle-system ネームスペースにデプロイされます。

    kubectl get deployment system-upgrade-controller -n cattle-system
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
system-upgrade-controller   1/1     1            1           111s

18.2.2 System Upgrade ControllerのHelmインストール

 

  1. Rancherチャートリポジトリを追加します。

    helm repo add rancher-charts https://charts.rancher.io/

  2. SUCチャートをデプロイします。

    helm install system-upgrade-controller rancher-charts/system-upgrade-controller --version 109.0.1 --set global.cattle.psp.enabled=false -n cattle-system --create-namespace

    これにより、Edge 3.6 プラットフォームで必要とされるSUCバージョン v0.19.1 がインストールされます。

  3. SUCのデプロイメントを検証します。

    kubectl get deployment system-upgrade-controller -n cattle-system
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
system-upgrade-controller   1/1     1            1           37s

18.3 System Upgrade Controllerプランの監視

 

SUCプランは、以下の方法で確認できます。

重要
重要

SUCプラン用にデプロイされたポッドは、実行成功後 15 分間保持されます。その後、それらを作成した対応するジョブによって削除されます。この期間を過ぎてもPodのログにアクセスできるようにするには、クラスターのログ記録を有効にする必要があります。Rancherでこれを行う方法の詳細については、https://ranchermanager.docs.rancher.com/v2.14/integrations-in-rancher/logging[Rancher Integration with Logging Services]を参照してください。

18.3.1 Upgrade Controllerプランの監視 - Rancher UI

 

特定のSUCプランのPodログを確認するには：

  1. 左上隅にある*☰ → <your-cluster-name>*

  2. [Workloads] → > [Pods]を選択します。

  3. `Only User Namespaces`ドロップダウンメニューを選択し、`cattle-system`ネームスペースを追加します。

  4. Podフィルターバーに、SUCプランPodの名前を入力します。名前は次のテンプレート形式になります：apply-<plan_name>-on-<node_name>

    注記
    注記

    特定のSUCプランに対して、`Completed`と`Unknown`の両方のPodが存在する場合があります。これは想定される動作であり、一部のアップグレードの性質上発生します。

  5. ログを確認するPodを選択し、*⋮ → View Logs*に移動します。

18.3.2 Upgrade Controllerプランの監視 - 手動

 
注記
注記

以下の手順では、`kubectl`が*SUC Plans*がデプロイされているクラスターに接続するように構成されていることを前提としています。

  1. デプロイされた*SUC*プランを一覧表示します：

    kubectl get plans -n cattle-system

  2. *SUC*プランのPodを取得します：

    kubectl get pods -l upgrade.cattle.io/plan=<plan_name> -n cattle-system
    注記
    注記

    特定のSUCプランに対して、`Completed`と`Unknown`の両方のPodが存在する場合があります。これは想定される動作であり、一部のアップグレードの性質上発生します。

  3. Podのログを取得します：

    kubectl logs <pod_name> -n cattle-system

19 Upgrade Controller

 

以下のSUSE Edgeプラットフォームコンポーネントのアップグレードを実行できるKubernetesコントローラー：

  • オペレーティングシステム（SUSE Linux Micro）

  • Kubernetes（K3sおよびRKE2）

  • 追加コンポーネント（Rancher、Elemental、SUSE Securityなど）

Upgrade Controllerは、上記のコンポーネントの複雑さを単一の`user-facing`リソースにカプセル化することで、アップグレードプロセスを効率化し、そのリソースがアップグレードの*トリガー*として機能します。ユーザーはこのリソースを構成するだけで、残りは`Upgrade Controller`が処理します。

注記
注記

`Upgrade Controller`は現在、SUSE Edgeプラットフォームのアップグレードを、*エアギャップされていない管理クラスター*向けにのみサポートしています。詳細については、19.8項 「既知の制限事項」セクションを参照してください。

19.1 SUSE Edgeはどのようにアップグレードコントローラーを使用しますか？

 

*アップグレードコントローラー*は、管理クラスターをあるSUSE Edgeリリースバージョンから次のバージョンへアップグレードするために必要な（以前は手動だった）「Day 2」運用を自動化する上で不可欠です。

この自動化を実現するために、アップグレードコントローラーはSystem Upgrade Controller (第18章 「System Upgrade Controller」)やHelm Controllerといったツールを利用します。

アップグレードコントローラーの仕組みの詳細については、19.5項 「Upgrade Controllerはどのように機能しますか？」を参照してください。

アップグレードコントローラーの既知の制限事項については、19.8項 「既知の制限事項」を参照してください。

アップグレードコントローラーとSystem Upgrade Controllerの違いに関する情報については、19.2項 「Upgrade Controller vs System Upgrade Controller」を参照してください。

19.2 Upgrade Controller vs System Upgrade Controller

 

System Upgrade Controller (SUC) (第18章 「System Upgrade Controller」)は、特定のKubernetesノードにアップグレード手順を伝播させる汎用ツールです。

SUSE Edgeプラットフォーム向けの「Day 2」運用の一部はサポートしていますが、すべてをカバーしているわけ*ではありません*。さらに、サポートされている運用であっても、ユーザーは複数の`SUC Plans`を手動で構成、維持、デプロイする必要があり、これはエラーが発生しやすく、予期しない問題につながる可能性があります。

これにより、SUSE Edgeプラットフォームのさまざまな「Day 2」運用管理の複雑さを自動化し、抽象化するツールの必要性が生じました。こうして、`Upgrade Controller`が開発されました。これは、アップグレードを駆動する単一の`user-facing resource`を導入することで、アップグレードプロセスを簡素化します。ユーザーはこのリソースを管理するだけでよく、残りは`Upgrade Controller`が処理します。

19.3 Upgrade Controllerのインストール

 

19.3.1 前提条件

 

19.3.2 手順

 

  1. 管理クラスターにUpgrade ControllerのHelmチャートをインストールします：

    helm install upgrade-controller oci://registry.suse.com/edge/charts/upgrade-controller --version 306.0.4+up0.1.3 --create-namespace --namespace upgrade-controller-system

  2. Upgrade Controllerのデプロイメントを検証します：

    kubectl get deployment -n upgrade-controller-system

  3. Upgrade Controllerのポッドを検証します：

    kubectl get pods -n upgrade-controller-system

  4. Upgrade Controllerのポッドログを検証します：

    kubectl logs <pod_name> -n upgrade-controller-system

19.4 Edge Image Builderを使用したUpgrade Controllerのインストール

 

上記の手動インストールに代わる方法として、Edge Image Builder (第8章 「Edge Image Builder」)によって調整される初期デプロイの一部としてUpgrade Controllerをインストールすることも可能です。

この場合、EIB設定ファイルに以下のHelmチャート設定を追加する必要があります：

kubernetes:
  helm:
    charts:
      - name: cert-manager
        repositoryName: jetstack
        version: {version-cert-manager}
        targetNamespace: cert-manager
        valuesFile: certmanager-values.yaml
        createNamespace: true
        installationNamespace: kube-system
      - name: upgrade-controller
        version: {version-upgrade-controller-chart}
        repositoryName: suse-edge-charts
        targetNamespace: upgrade-controller-system
        createNamespace: true
        installationNamespace: kube-system

19.5 Upgrade Controllerはどのように機能しますか？

 

Edgeリリースのアップグレードを実行するために、Upgrade Controllerは2つの新しいKubernetes カスタムリソースを導入します：

  • UpgradePlan (19.6.1項 「UpgradePlan」) - ユーザーによって作成されます。Edgeリリースのアップグレードに関する設定を保持します。

  • ReleaseManifest (19.6.2項 「ReleaseManifest」) - Upgrade Controllerによって作成されます。特定のEdgeリリースバージョンに固有のコンポーネントバージョンを保持します。このファイルはユーザーが編集してはいけません。

Upgrade Controllerは、ユーザーが`UpgradePlan`リソースの`releaseVersion`プロパティで指定したEdgeリリースバージョンのコンポーネントデータを保持する`ReleaseManifest`リソースの作成に進みます。

`ReleaseManifest`のコンポーネントデータを使用して、アップグレードコントローラは以下の順序でEdgeリリースコンポーネントのアップグレードに進みます。

  1. オペレーティングシステム(OS) (19.5.1項 「オペレーティングシステムのアップグレード」)。

  2. Kubernetes (19.5.2項 「Kubernetesのアップグレード」)。

  3. 追加コンポーネント (19.5.3項 「追加コンポーネントのアップグレード」)。

注記
注記

アップグレードプロセス中、アップグレードコントローラは作成された`UpgradePlan`にアップグレード情報を継続的に出力します。アップグレードプロセスの追跡方法の詳細については、アップグレードプロセスの追跡 (19.7項 「アップグレードプロセスの追跡」)を参照してください。

19.5.1 オペレーティングシステムのアップグレード

 

オペレーティングシステムをアップグレードするために、Upgrade Controllerは以下の命名テンプレートを持つSUC (第18章 「System Upgrade Controller」)プランを作成します。

  • コントロールプレーンノードのオペレーティングシステムアップグレードに関連するSUCプランの場合 - control-plane-<os-name>-<os-version>-<suffix>。

  • ワーカーノードのオペレーティングシステムアップグレードに関連するSUCプランの場合 - workers-<os-name>-<os-version>-<suffix>。

これらのプランに基づいて、SUCはクラスターの各ノード上に実際のオペレーティングシステムアップグレードを実行するワークロードを作成します。

`ReleaseManifest`に応じて、オペレーティングシステムのアップグレードには以下が含まれる場合があります。

  • パッケージのみの更新 - Edgeリリース間でオペレーティングシステムのバージョンが変更されないユースケース用。

  • 完全なオペレーティングシステムの移行 - Edgeリリース間でオペレーティングシステムのバージョンが変更されるユースケース用。

アップグレードは、コントロールプレーンノードから開始して、*1*ノードずつ実行されます。コントロールプレーンノードのアップグレードが完了した場合にのみ、ワーカーノードのアップグレードが開始されます。

注記
注記

Upgrade Controllerは、クラスターに指定されたタイプのノードが*1*つより多い場合、クラスターのノードに対してドレインを実行するようにオペレーティングシステムのSUCプランを設定します。

コントロールプレーンノードが*1*つより多く、ワーカーノードが*1つのみ*であるクラスターの場合、コントロールプレーンノードに対してのみドレインが実行され、その逆も同様です。

ノードのドレインを完全に無効にする方法については、UpgradePlan (19.6.1項 「UpgradePlan」)セクションを参照してください。

19.5.2 Kubernetesのアップグレード

 

クラスターのKubernetesディストリビューションをアップグレードするために、Upgrade Controllerは次の命名テンプレートを持つSUC (第18章 「System Upgrade Controller」)プランを作成します。

  • コントロールプレーンノードのKubernetesアップグレードに関連するSUCプランの場合 - control-plane-<k8s-version>-<suffix>。

  • ワーカーノードのKubernetesアップグレードに関連するSUCプランの場合 - workers-<k8s-version>-<suffix>。

これらのプランに基づいて、SUCはクラスターの各ノード上で実際のKubernetesアップグレードを実行するワークロードを作成します。

Kubernetesのアップグレードは、コントロールプレーンノードから開始され、*1*ノードずつ実行されます。コントロールプレーンノードのアップグレードが完了した場合にのみ、ワーカーノードのアップグレードが開始されます。

注記
注記

Upgrade Controllerは、指定されたタイプのノードが*1*つより多いクラスターの場合、クラスターのノードに対してドレインを実行するようにKubernetes SUCプランを構成します。

コントロールプレーンノードが*1より大きい*かつワーカーノードが*1つのみ*の場合、コントロールプレーンノードに対してのみドレインが実行され、反対の場合はワーカーノードに対してのみ実行されます。

ノードのドレインを完全に無効にする方法については、19.6.1項 「UpgradePlan」を参照してください。

19.5.3 追加コンポーネントのアップグレード

 

現在、すべての追加コンポーネントはHelmチャートを介してインストールされています。特定のリリースに含まれるコンポーネントの完全なリストについては、リリースノート (第41章 「リリースノート」)を参照してください。

EIB (第8章 「Edge Image Builder」)を通じてデプロイされたHelmチャートの場合、Upgrade Controllerは各コンポーネントの既存のHelmChart CRを更新します。

EIB以外でデプロイされたHelmチャートの場合、Upgrade Controllerは各コンポーネントに対して`HelmChart`リソースを作成します。

`HelmChart`リソースの作成/更新後、Upgrade Controllerはhelm-controllerに依存してこの変更を検知し、実際のコンポーネントのアップグレードを進めます。

チャートは、`ReleaseManifest`内の順序に基づいて順番にアップグレードされます。追加の値は、`UpgradePlan`を介して渡すこともできます。新しいSUSE Edgeリリースでチャートのバージョンが変更されない場合、アップグレードは行われません。詳細については、19.6.1項 「UpgradePlan」を参照してください。

19.6 Kubernetes API拡張機能

 

Upgrade Controllerによって導入されたKubernetes APIへの拡張機能。

19.6.1 UpgradePlan

 

Upgrade Controllerは、カスタムリソースと呼ばれる新しいKubernetes `UpgradePlan`を導入します。

`UpgradePlan`はUpgrade Controllerの指示メカニズムとして機能し、以下の構成をサポートします。

  • releaseVersion - クラスターのアップグレード先となるEdgeリリースバージョン。リリースバージョンはセマンティックバージョニングに従う必要があり、リリースノート (第41章 「リリースノート」)から取得する必要があります。

  • disableDrain - オプション。ノードドレインを無効にするかどうかをUpgrade Controllerに指示します。中断バジェットを持つワークロードがある場合に便利です。

    • コントロールプレーンノードのドレインを無効にする例：

      spec:
  disableDrain:
    controlPlane: true

    • コントロールプレーンおよびワーカーノードのドレインを無効にする例：

      spec:
  disableDrain:
    controlPlane: true
    worker: true

  • helm - オプション。Helm経由でインストールされたコンポーネントの追加値を指定します。

    警告
    警告

    このフィールドは、アップグレードに不可欠な値に対してのみ使用することをお勧めします。標準的なチャート値の更新は、それぞれのチャートが次のバージョンにアップグレードされた後に行う必要があります。

    • 例:

      spec:
  helm:
  - chart: foo
    values:
      bar: baz

19.6.2 ReleaseManifest

 

Upgrade Controllerは、カスタムリソースと呼ばれる新しいKubernetes `ReleaseManifest`を導入します。

`ReleaseManifest`リソースはUpgrade Controllerによって作成され、*1つ*の特定のEdgeリリースバージョンに関するコンポーネントデータを保持します。つまり、各Edgeリリースバージョンのアップグレードは、異なる`ReleaseManifest`リソースによって表されます。

警告
警告

Release Manifestは常にUpgrade Controllerによって作成される必要があります。

`ReleaseManifest`リソースを手動で作成または編集することは推奨されません。そうすることを決定したユーザーは、*自己責任*で行う必要があります。

Release Manifestが提供するコンポーネントデータには、以下が含まれますが、これらに限定されません。

  • オペレーティングシステムデータ - バージョン、サポートされているアーキテクチャ、追加のアップグレードデータなど。

  • Kubernetesディストリビューションデータ - RKE2/K3s サポート対象バージョン

  • 追加コンポーネントデータ - SUSE Helmチャートデータ（場所、バージョン、名前など）

Release Manifestの例については、https://github.com/suse-edge/upgrade-controller/blob/main/config/samples/lifecycle_v1alpha1_releasemanifest.yaml[アップストリーム]ドキュメントを参照してください。これはあくまで例であり、有効な ReleaseManifest リソースとして作成することを意図したものではありませんのでご注意ください。

19.7 アップグレードプロセスの追跡

 

このセクションは、ユーザーが UpgradePlan リソースを作成した後にUpgrade Controllerが開始するアップグレードプロセスを追跡およびデバッグするための手段です。

19.7.1 全般

 

アップグレードプロセスの状態に関する一般的な情報は、Upgrade Planのステータス条件で確認できます。

Upgrade Planリソースのステータスは、以下の方法で確認できます。

kubectl get upgradeplan <upgradeplan_name> -n upgrade-controller-system -o yaml
例 19.1: Upgrade Plan実行の例：
 
apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  namespace: upgrade-controller-system
spec:
  releaseVersion: 3.6
status:
  conditions:
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Control plane nodes are being upgraded
    reason: InProgress
    status: "False"
    type: OSUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Kubernetes upgrade is not yet started
    reason: Pending
    status: Unknown
    type: KubernetesUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Rancher upgrade is not yet started
    reason: Pending
    status: Unknown
    type: RancherUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Longhorn upgrade is not yet started
    reason: Pending
    status: Unknown
    type: LonghornUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: MetalLB upgrade is not yet started
    reason: Pending
    status: Unknown
    type: MetalLBUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: CDI upgrade is not yet started
    reason: Pending
    status: Unknown
    type: CDIUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: KubeVirt upgrade is not yet started
    reason: Pending
    status: Unknown
    type: KubeVirtUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: NeuVector upgrade is not yet started
    reason: Pending
    status: Unknown
    type: NeuVectorUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: EndpointCopierOperator upgrade is not yet started
    reason: Pending
    status: Unknown
    type: EndpointCopierOperatorUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Elemental upgrade is not yet started
    reason: Pending
    status: Unknown
    type: ElementalUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: SRIOV upgrade is not yet started
    reason: Pending
    status: Unknown
    type: SRIOVUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Metal3 upgrade is not yet started
    reason: Pending
    status: Unknown
    type: Metal3Upgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: RancherTurtles upgrade is not yet started
    reason: Pending
    status: Unknown
    type: RancherTurtlesUpgraded
  observedGeneration: 1
  sucNameSuffix: 90315a2b6d

ここでは、Upgrade Controllerがアップグレードのスケジュールを試みるすべてのコンポーネントを確認できます。各条件は以下のテンプレートに従います。

  • lastTransitionTime - このコンポーネントの条件が最後にステータスを変更した日時。

  • message - 特定のコンポーネント条件の現在のアップグレード状態を示すメッセージ。

  • reason - 特定のコンポーネント条件の現在のアップグレード状態。可能な reasons は以下の通りです。

    • Succeeded - 特定のコンポーネントのアップグレードが成功しました。

    • Failed - 特定のコンポーネントのアップグレードが失敗しました。

    • InProgress - 特定のコンポーネントのアップグレードが現在進行中です。

    • Pending - 特定のコンポーネントのアップグレードはまだスケジュールされていません。

    • Skipped - 特定のコンポーネントがクラスター上で見つからないため、そのアップグレードはスキップされます。

    • Error - 特定のコンポーネントで一時的なエラーが発生しました。

  • status - 現在の条件 type のステータス。True、False、Unknown のいずれかです。

  • type - 現在アップグレード中のコンポーネントのインジケーター。

Upgrade Controller は、タイプ OSUpgraded および KubernetesUpgraded のコンポーネント条件に対して SUC プランを作成します。これらのコンポーネントに対して作成された SUC プランをさらに追跡するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

他のすべてのコンポーネント条件タイプは、helm-controller によって作成されたリソースを表示することでさらに追跡できます。詳細については、19.7.2項 「Helm Controller」 を参照してください。

Upgrade Controller によってスケジュールされたアップグレード計画は、次の場合に successful としてマークされます:

  1. Pending または InProgress のコンポーネント条件はありません。

  2. lastSuccessfulReleaseVersion プロパティは、アップグレード計画の設定で指定されている releaseVersion を指します。このプロパティは、アップグレードプロセスが成功すると、Upgrade Controller によってアップグレード計画のステータスに追加されます。

例 19.2: 成功した UpgradePlan の例:
 
apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  namespace: upgrade-controller-system
spec:
  releaseVersion: 3.6
status:
  conditions:
  - lastTransitionTime: "2024-10-01T06:26:48Z"
    message: All cluster nodes are upgraded
    reason: Succeeded
    status: "True"
    type: OSUpgraded
  - lastTransitionTime: "2024-10-01T06:26:59Z"
    message: All cluster nodes are upgraded
    reason: Succeeded
    status: "True"
    type: KubernetesUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart rancher upgrade succeeded
    reason: Succeeded
    status: "True"
    type: RancherUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart longhorn is not installed
    reason: Skipped
    status: "False"
    type: LonghornUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Specified version of chart metallb is already installed
    reason: Skipped
    status: "False"
    type: MetalLBUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart cdi is not installed
    reason: Skipped
    status: "False"
    type: CDIUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart kubevirt is not installed
    reason: Skipped
    status: "False"
    type: KubeVirtUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart neuvector-crd is not installed
    reason: Skipped
    status: "False"
    type: NeuVectorUpgraded
  - lastTransitionTime: "2024-10-01T06:27:14Z"
    message: Specified version of chart endpoint-copier-operator is already installed
    reason: Skipped
    status: "False"
    type: EndpointCopierOperatorUpgraded
  - lastTransitionTime: "2024-10-01T06:27:14Z"
    message: Chart elemental-operator upgrade succeeded
    reason: Succeeded
    status: "True"
    type: ElementalUpgraded
  - lastTransitionTime: "2024-10-01T06:27:15Z"
    message: Chart sriov-crd is not installed
    reason: Skipped
    status: "False"
    type: SRIOVUpgraded
  - lastTransitionTime: "2024-10-01T06:27:19Z"
    message: Chart metal3 is not installed
    reason: Skipped
    status: "False"
    type: Metal3Upgraded
  - lastTransitionTime: "2024-10-01T06:27:27Z"
    message: Chart rancher-turtles is not installed
    reason: Skipped
    status: "False"
    type: RancherTurtlesUpgraded
  lastSuccessfulReleaseVersion: 3.6
  observedGeneration: 1
  sucNameSuffix: 90315a2b6d

19.7.2 Helm Controller

 

このセクションでは、helm-controller によって作成されたリソースを追跡する方法について説明します。

注記
注記

以下の手順では、kubectl が Upgrade Controller がデプロイされているクラスターに接続するように構成されていることを前提としています。

  1. 特定のコンポーネントの HelmChart リソースを見つけます:

    kubectl get helmcharts -n kube-system

  2. HelmChart リソースの名前を使用して、helm-controller によって作成されたアップグレード Pod を見つけます:

    kubectl get pods -l helmcharts.helm.cattle.io/chart=<helmchart_name> -n kube-system

# Example for Rancher
kubectl get pods -l helmcharts.helm.cattle.io/chart=rancher -n kube-system
NAME                         READY   STATUS      RESTARTS   AGE
helm-install-rancher-tv9wn   0/1     Completed   0          16m

  3. コンポーネント固有の Pod のログを表示します:

    kubectl logs <pod_name> -n kube-system

19.8 既知の制限事項

 

  • ダウンストリームクラスターのアップグレードは、まだ Upgrade Controller によって管理されていません。ダウンストリームクラスターをアップグレードする方法については、第33章 「ダウンストリームクラスタ群」 を参照してください。

  • Upgrade Controllerは、EIB (第8章 「Edge Image Builder」)を通じてデプロイされる追加の SUSE Edge Helmチャートについて、その HelmChart CR が kube-system ネームスペースにデプロイされていることを前提としています。これを行うには、EIB定義ファイルで installationNamespace プロパティを設定してください。詳細については、アップストリームのドキュメントを参照してください。

  • 現在、Upgrade Controllerには、管理クラスター上で現在実行されているEdgeリリースバージョンを特定する方法はありません。クラスター上で現在実行されているEdgeリリースバージョンよりも新しいEdgeリリースバージョンを必ず指定してください。

  • 現在、Upgrade Controllerは 非エアギャップ(された) 環境のアップグレードのみをサポートしています。エアギャップ(された) 環境でのアップグレードはまだできません。

20 SUSE Multi-Linux Manager

 

SUSE Multi-Linux ManagerはSUSE Edgeに含まれており、エッジデプロイメントのすべてのノードで基盤となるオペレーティングシステムであるSUSE Linux Microを常に最新の状態に保つための自動化と制御を提供します。

詳細については、第3章 「SUSE Multi-Linux Manager」および SUSE Multi-Linux Manager Documentationを参照してください。

パート III ハウツーガイド

 

ハウツーガイドとベストプラクティス

  • 21 K3s上のMetalLB（レイヤー2モードを使用）

    • MetalLBは、標準的なルーティングプロトコルを使用する、ベアメタルKubernetesクラスター向けのロードバランサー実装です。

  • 22 K3s上のMetalLB（レイヤー3モードを使用）

    • MetalLBは、標準的なルーティングプロトコルを使用する、ベアメタルKubernetesクラスター向けの負荷分散実装です。

  • 23 K3s上のMetalLB（FRR-K8sモードを使用）

    • MetalLBは、標準的なルーティングプロトコルを使用する、ベアメタルKubernetesクラスター向けのロードバランサー実装です。

  • 24 Kubernetes APIサーバーの前にあるMetalLB

    • このガイドでは、MetalLBサービスを使用して、3つのコントロールプレーンノードを持つHAクラスター上でRKE2/K3s APIを外部に公開する方法を説明します。 これを実現するために、タイプ`LoadBalancer`のKubernetesサービスを手動で作成します。次に、クラスター内のすべてのコントロールプレーンノードのIPを保持する`EndpointSlices`オブジェクトが自動的に作成されます。 EndpointSlicesをクラスター内で発生するイベント（ノードの追加/削除、またはノードのオフライン化）と継続的に同期させるために、Endpoint Copier Operator …

  • 25 Edge Image Builder を使用したエアギャップ(された)デプロイメント

    • このガイドでは、Edge Image Builder(EIB) (第8章 「Edge Image Builder」) を利用して、SUSE Linux Micro 6.2 上で SUSE Edge コンポーネントの一部を完全にエアギャップ(された)環境でデプロイする方法を説明します。これにより、EIB によって作成されたカスタマイズ済みで起動可能な (CRB) イメージで起動し、インターネット接続や手動の手順なしで、指定されたコンポーネントを RKE2 または K3s クラスターにデプロイできるようになります。この構成は、デプロイに必要なすべてのアーティファクトを OS イメージに事前に組み込…

  • 26 Kiwiを使用して更新されたSUSE Linux Microイメージを構築する

    • このセクションでは、Edge Image Builder、Cluster API (CAPI) + Metal3で使用する、またはディスクイメージをブロックデバイスに直接書き込むための、更新されたSUSE Linux Microイメージの生成方法について説明します。このプロセスは、初期システムブートイメージに最新のパッチを含める必要がある場合（インストール後のパッチ転送を最小限に抑えるため）、またはCAPIを使用するシナリオで、ホストをその場でアップグレードするよりも新しいイメージでオペレーティングシステムを再インストールすることが望ましい場合に役立ちます。

21 K3s上のMetalLB（レイヤー2モードを使用）

 

MetalLBは、標準的なルーティングプロトコルを使用する、ベアメタルKubernetesクラスター向けのロードバランサー実装です。

このガイドでは、MetalLBをレイヤー2（L2）モードでデプロイする方法を説明します。

21.1 MetalLBを使用する理由

 

MetalLBがベアメタルKubernetesクラスターでのロードバランシングにおいて魅力的な選択肢である理由はいくつかあります。

  1. Kubernetesとのネイティブな統合:MetalLBはKubernetesとシームレスに統合されるため、使い慣れたKubernetesツールや手法を使用して簡単にデプロイおよび管理できます。

  2. ベアメタルとの互換性:クラウドベースのロードバランサーとは異なり、MetalLBは、従来のロードバランサーが利用できない、または実現不可能なオンプレミス環境向けに特別に設計されています。

  3. 複数のプロトコルをサポート:MetalLBはレイヤー2モードとBGP（Border Gateway Protocol）モードの両方をサポートしており、さまざまなネットワークアーキテクチャや要件に対応できる柔軟性を備えています。

  4. 高可用性:MetalLBは、ロードバランシングの役割を複数のノードに分散させることで、サービスの可用性と信頼性を確保します。

  5. スケーラビリティ:MetalLBは大規模なデプロイメントに対応でき、Kubernetesクラスターとともにスケーリングして、増大する需要を満たすことができます。

レイヤー2モードでは、1つのノードがローカルネットワークに対してサービスをアドバタイズする役割を担います。ネットワークの観点からは、そのマシンに複数のIPアドレスがネットワークインタフェースに割り当てられているように見えるだけです。

レイヤー2モードの最大の利点はその汎用性です。特別なハードウェアや高度なルーターを必要とせず、あらゆるイーサネットネットワークで動作します。

21.2 K3s上のMetalLB（L2を使用）

 

このクイックスタートでは、L2モードを使用します。 これは、特別なネットワーク機器は必要なく、ネットワーク範囲内で3つの空きIPアドレスが必要であることを意味します。

21.3 前提条件

 

  • MetalLBをデプロイするK3sクラスター。

警告
警告

K3sには、Klipperという独自のサービスロードバランサーが付属しています。MetalLBを実行するには、 それを無効にする必要があります。Klipperを無効にするには、`--disable=servicelb`フラグを使用してK3sをインストールする必要があります。

  • Helm

  • ネットワーク範囲内の3つの未割り当てIPアドレス。この例では`192.168.122.10-192.168.122.12`

重要
重要

これらのIPアドレスが割り当てられていないことを確認する必要があります。 DHCP環境では、二重割り当てを避けるため、これらのアドレスをDHCPプールに含めないようにする必要があります。

21.4 展開

 

SUSE Edgeソリューションの一部として公開されているMetalLB Helmチャートを使用します。

helm install \
  metallb oci://registry.suse.com/edge/charts/metallb \
  --namespace metallb-system \
  --create-namespace

while ! kubectl wait --for condition=ready -n metallb-system $(kubectl get\
 pods -n metallb-system -l app.kubernetes.io/component=controller -o name)\
 --timeout=10s; do
 sleep 2
done

21.5 設定

 

この時点で、インストール作業は完了です。それでは、例の値を使用して 設定を行います。

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ip-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.122.10/32
  - 192.168.122.11/32
  - 192.168.122.12/32
EOF
cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: ip-pool-l2-adv
  namespace: metallb-system
spec:
  ipAddressPools:
  - ip-pool
EOF

これで、使用する準備が整いました。L2モードでは、以下のような多くの項目をカスタマイズできます。

その他、 BGPに関する多くの設定が可能です。

21.5.1 TraefikとMetalLB

 

TraefikはK3sでデフォルトでデプロイされ（ https://docs.k3s.io/networking#traefik-ingress-controller`--disable=traefik`で無効化可能）、デフォルトで`LoadBalancer`として公開されます（Klipperで使用するため）。しかし、Klipperを無効にする必要があるため、イングレス用のTraefikサービスは依然として`LoadBalancer`タイプです。そのため、MetalLBをデプロイする時点で、最初のIPが自動的にTraefik Ingressに割り当てられます。

# Before deploying MetalLB
kubectl get svc -n kube-system traefik
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
traefik   LoadBalancer   10.43.44.113   <pending>     80:31093/TCP,443:32095/TCP   28s
# After deploying MetalLB
kubectl get svc -n kube-system traefik
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
traefik   LoadBalancer   10.43.44.113   192.168.122.10   80:31093/TCP,443:32095/TCP   3m10s

これはプロセスの後ほど (21.6.1項 「MetalLBを使用したイングレス」)適用されます。

21.6 使用方法

 

デプロイメントの例を作成してみましょう。

cat <<- EOF | kubectl apply -f -
---
apiVersion: v1
kind: Namespace
metadata:
  name: hello-kubernetes
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: hello-kubernetes
  namespace: hello-kubernetes
  labels:
    app.kubernetes.io/name: hello-kubernetes
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kubernetes
  namespace: hello-kubernetes
  labels:
    app.kubernetes.io/name: hello-kubernetes
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: hello-kubernetes
  template:
    metadata:
      labels:
        app.kubernetes.io/name: hello-kubernetes
    spec:
      serviceAccountName: hello-kubernetes
      containers:
        - name: hello-kubernetes
          image: "paulbouwer/hello-kubernetes:1.10"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          env:
          - name: HANDLER_PATH_PREFIX
            value: ""
          - name: RENDER_PATH_PREFIX
            value: ""
          - name: KUBERNETES_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: KUBERNETES_POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: KUBERNETES_NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: CONTAINER_IMAGE
            value: "paulbouwer/hello-kubernetes:1.10"
EOF

そして最後に、サービスです。

cat <<- EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: hello-kubernetes
  namespace: hello-kubernetes
  labels:
    app.kubernetes.io/name: hello-kubernetes
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: hello-kubernetes
EOF

実際に動作している様子を見てみましょう。

kubectl get svc -n hello-kubernetes
NAME               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
hello-kubernetes   LoadBalancer   10.43.127.75   192.168.122.11   80:31461/TCP   8s

curl http://192.168.122.11
<!DOCTYPE html>
<html>
<head>
    <title>Hello Kubernetes!</title>
    <link rel="stylesheet" type="text/css" href="/css/main.css">
    <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Ubuntu:300" >
</head>
<body>

  <div class="main">
    <img src="/images/kubernetes.png"/>
    <div class="content">
      <div id="message">
  Hello world!
</div>
<div id="info">
  <table>
    <tr>
      <th>namespace:</th>
      <td>hello-kubernetes</td>
    </tr>
    <tr>
      <th>pod:</th>
      <td>hello-kubernetes-7c8575c848-2c6ps</td>
    </tr>
    <tr>
      <th>node:</th>
      <td>allinone (Linux 5.14.21-150400.24.46-default)</td>
    </tr>
  </table>
</div>
<div id="footer">
  paulbouwer/hello-kubernetes:1.10 (linux/amd64)
</div>
    </div>
  </div>

</body>
</html>

21.6.1 MetalLBを使用したイングレス

 

Traefikはすでにイングレスコントローラーとして機能しているため、次のような`Ingress`オブジェクトを使用してHTTP/HTTPSトラフィックを公開できます。

IP=$(kubectl get svc -n kube-system traefik -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
cat <<- EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-kubernetes-ingress
  namespace: hello-kubernetes
spec:
  rules:
  - host: hellok3s.${IP}.sslip.io
    http:
      paths:
        - path: "/"
          pathType: Prefix
          backend:
            service:
              name: hello-kubernetes
              port:
                name: http
EOF

続いて：

curl http://hellok3s.${IP}.sslip.io
<!DOCTYPE html>
<html>
<head>
    <title>Hello Kubernetes!</title>
    <link rel="stylesheet" type="text/css" href="/css/main.css">
    <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Ubuntu:300" >
</head>
<body>

  <div class="main">
    <img src="/images/kubernetes.png"/>
    <div class="content">
      <div id="message">
  Hello world!
</div>
<div id="info">
  <table>
    <tr>
      <th>namespace:</th>
      <td>hello-kubernetes</td>
    </tr>
    <tr>
      <th>pod:</th>
      <td>hello-kubernetes-7c8575c848-fvqm2</td>
    </tr>
    <tr>
      <th>node:</th>
      <td>allinone (Linux 5.14.21-150400.24.46-default)</td>
    </tr>
  </table>
</div>
<div id="footer">
  paulbouwer/hello-kubernetes:1.10 (linux/amd64)
</div>
    </div>
  </div>

</body>
</html>

MetalLBが正しく動作していることを確認します。

% arping hellok3s.${IP}.sslip.io

ARPING 192.168.64.210
60 bytes from 92:12:36:00:d3:58 (192.168.64.210): index=0 time=1.169 msec
60 bytes from 92:12:36:00:d3:58 (192.168.64.210): index=1 time=2.992 msec
60 bytes from 92:12:36:00:d3:58 (192.168.64.210): index=2 time=2.884 msec

上記の例では、トラフィックは次のように流れます。

  1. `hellok3s.${IP}.sslip.io`は実際のIPに解決されます。

  2. 次に、トラフィックは`metallb-speaker`ポッドによって処理されます。

  3. `metallb-speaker`はトラフィックを`traefik`コントローラーにリダイレクトします。

  4. 最後に、Traefikはリクエストを`hello-kubernetes`サービスに転送します。

22 K3s上のMetalLB（レイヤー3モードを使用）

 

MetalLBは、標準的なルーティングプロトコルを使用する、ベアメタルKubernetesクラスター向けの負荷分散実装です。

このガイドでは、MetalLBをレイヤー3（L3）BGPモードでデプロイする方法を説明します。

22.1 MetalLBを使用する理由

 

MetalLBがベアメタルKubernetesクラスターでの負荷分散において魅力的な選択肢である理由はいくつかあります。

  1. Kubernetesとのネイティブ統合:MetalLBはKubernetesとシームレスに統合されるため、使い慣れたKubernetesツールや手法を使用して簡単にデプロイおよび管理できます。

  2. ベアメタル互換性:クラウドベースのロードバランサーとは異なり、MetalLBは、従来のロードバランサーが利用できない、または実現不可能なオンプレミス環境向けに特別に設計されています。

  3. 複数のプロトコルをサポート:MetalLBはレイヤー2およびレイヤー3 BGP（Border Gateway Protocol）モードの両方をサポートしており、さまざまなネットワークアーキテクチャや要件に対して柔軟性を提供します。

  4. 高可用性:負荷分散の役割を複数のノードに分散させることで、MetalLBはサービスの高可用性と信頼性を確保します。

  5. スケーラビリティ:MetalLBは大規模なデプロイメントに対応でき、Kubernetesクラスターとともにスケーリングして、増大する需要に対応します。

レイヤー2モードでは、1つのノードがローカルネットワークに対してサービスをアドバタイズする役割を担います。ネットワークの観点からは、そのマシンが複数のIPアドレスをネットワークインタフェースに割り当てられているように見えるだけです。

レイヤー2モードの大きな利点はその汎用性です。特別なハードウェアや高度なルーターを必要とせず、あらゆるイーサネットネットワークで動作します。

22.2 K3s上のMetalLB（レイヤー3モードを使用）

 

このクイックスタートでは、L3モードを使用します。 これは、ネットワーク範囲内にBGP機能を持つ隣接ルーターが必要であることを意味します。

22.3 前提条件

 

  • MetalLBをデプロイするK3sクラスター。

  • BGPプロトコルをサポートするネットワーク上のルーター。

  • サービス用のネットワーク範囲内にある空きIPアドレス。この例では、`192.168.10.100`です。

重要
重要

このIPアドレスが割り当てられていないことを確認する必要があります。 DHCP環境では、二重割り当てを避けるため、このアドレスはDHCPプールの一部であってはなりません。

22.4 サービスIPアドレスをアドバタイズするための設定

 

デフォルトでは、BGPは構成されているすべてのピアに対してサービスIPアドレスをアドバタイズします。通常ルーターであるこれらのピアは、32ビットのネットワークマスクを持つ各サービスIPアドレスのルートを受信します。この例では、FRRベースのルーターを使用します。これはクラスターと同じネットワーク上にあります。次に、MetalLBのBGP機能を使用して、そのFRRベースのルーターにサービスをアドバタイズします。

22.5 展開

 

SUSE Edgeソリューションの一部として公開されているMetalLB Helmチャートを使用します。

helm install \
  metallb oci://registry.suse.com/edge/charts/metallb \
  --namespace metallb-system \
  --create-namespace

while ! kubectl wait --for condition=ready -n metallb-system $(kubectl get\
 pods -n metallb-system -l app.kubernetes.io/component=controller -o name)\
 --timeout=10s; do
 sleep 2
done

22.6 設定

 

  1. この時点で、インストール作業は完了です。`IPAddressPool`を作成します。

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: bgp-pool
  namespace: metallb-system
  labels:
    app: httpd
spec:
  addresses:
  - 192.168.10.100/32
  autoAssign: true
  avoidBuggyIPs: false
  serviceAllocation:
    namespaces:
    - metallb-system
    priority: 100
    serviceSelectors:
    - matchExpressions:
      - key: serviceType
        operator: In
        values:
        - httpd
EOF

  1. `BGPPeer`を構成します。

注記
注記

FRRルーターのASNは1000で、私たちの`BGPPeer`は1001になります。また、FRRルーターのIPアドレスが192.168.3.140であることも確認できます。

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: mypeertest
spec:
  peerAddress: 192.168.3.140
  peerASN: 1000
  myASN: 1001
  routerID: 4.4.4.4
EOF

  1. BGPAdvertisement (L3) を作成します。

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-test
  namespace: metallb-system
spec:
  ipAddressPools:
  - bgp-pool
EOF

22.7 使用方法

 

  1. サービスを含むサンプルアプリケーションを作成します。この場合、`IPAddressPool`からのIPアドレスは、そのサービスに対して`192.168.10.100`となります。

cat <<- EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deployment
  namespace: metallb-system
  labels:
    app: httpd
spec:
  replicas: 3
  selector:
    matchLabels:
      pod-label: httpd
  template:
    metadata:
      labels:
        pod-label: httpd
    spec:
      containers:
      - name: httpdcontainer
        image: image: docker.io/library/httpd:2.4
        ports:
          - containerPort: 80
            protocol: TCP
      restartPolicy: Always

---
apiVersion: v1
kind: Service
metadata:
  name: http-service
  namespace: metallb-system
  labels:
    serviceType: httpd
spec:
  selector:
    pod-label: httpd
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 8080
    name: 8080-tcp
    targetPort: 80
EOF

  1. 確認するには、FRRルーターにログインして、BGPアドバタイズによって作成されたルートを確認してください。

42178089cba5# show ip bgp all

For address family: IPv4 Unicast
BGP table version is 3, local router ID is 2.2.2.2, vrf id 0
Default local pref 100, local AS 1000
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

   Network          Next Hop            Metric LocPrf Weight Path
* i172.16.0.0/24    1.1.1.1                  0    100      0 i
*>                  0.0.0.0                  0         32768 i
* i172.17.0.0/24    3.3.3.3                  0    100      0 i
*>                  0.0.0.0                  0         32768 i
*= 192.168.10.100/32
                    192.168.3.162                          0 1001 i
*=                  192.168.3.163                          0 1001 i
*>                  192.168.3.161                          0 1001 i

Displayed  3 routes and 7 total paths
kubectl get svc -n hello-kubernetes
NAME               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
hello-kubernetes   LoadBalancer   10.43.127.75   192.168.122.11   80:31461/TCP   8s

  1. このルーターがネットワークのデフォルトゲートウェイである場合は、そのネットワーク上のボックスから curl コマンドを実行して、httpdサンプルアプリに到達できることを確認できます。

# curl http://192.168.10.100:8080
<html><body><h1>It works!</h1></body></html>
#

23 K3s上のMetalLB（FRR-K8sモードを使用）

 

MetalLBは、標準的なルーティングプロトコルを使用する、ベアメタルKubernetesクラスター向けのロードバランサー実装です。

このガイドでは、レイヤー3 FRR-K8s BGPモードでMetalLBをデプロイする方法を説明します。

23.1 K3s上のMetalLB（FRR-K8sを使用）

 
注記
注記

FRR-K8sは現在、テクノロジープレビュー機能です。FRR-K8sのコミュニティドキュメントは こちらです。

このクイックスタートでは、FRR-K8sモードを使用します。

23.2 前提条件

 

  • FRR-K8sのすべての前提条件は、空きIPアドレスが必要である点を除き、第22章 「K3s上のMetalLB（レイヤー3モードを使用）」の場合と同じです。

    注記
    注記

    ここでの例にはサービスのセットアップが含まれていないため、IPアドレスは不要です。

  • MetalLBをデプロイするK3sクラスター。

  • BGPプロトコルをサポートするネットワーク上のルーター。

23.3 着信ルートを受け入れるための構成

 

デフォルトの状態で、MetalLB BGPは構成されているすべてのBGPピアに対してサービスIPアドレスをアドバタイズします。通常ルーターであるこれらのピアは、32ビットのネットワークマスクを持つ各サービスIPアドレスのルートを受信します。FRRConfiguration CRでFRR-K8sを使用する場合、外部ルーターからルートを受信することも可能です。これらの外部ルートは、各ノードのルーティングテーブルに表示されます。これには複数の利点がありますが、主な利点は、外部ネットワークが変更されたときにノード上のLinuxルーティングテーブルを手動で更新する必要がなくなることです。特に、デフォルトゲートウェイ経由のトラフィック送信を回避したい場合に有効です。

23.4 展開

 

SUSE Edgeソリューションの一部として公開されているMetalLB Helmチャートを使用します。FRR-K8sはMetalLBのサブチャートであることに注意してください。有効にするには、`frrk8s.enabled`を`true`に設定します。FRR-K8sには、ネームスペースに対するいくつかの高い権限も必要です。

kubectl create namespace metallb-system
kubectl label namespace metallb-system pod-security.kubernetes.io/enforce=privileged
kubectl label namespace metallb-system pod-security.kubernetes.io/audit=privileged
kubectl label namespace metallb-system pod-security.kubernetes.io/warn=privileged
helm install metallb \
  oci://registry.suse.com/edge/charts/metallb \
  --namespace metallb-system \
  --set frrk8s.enabled=true --set frrk8s.external=false


while ! kubectl wait --for condition=ready -n metallb-system $(kubectl get\
 pods -n metallb-system -l app.kubernetes.io/component=controller -o name)\
 --timeout=10s; do
 sleep 2
done

`metallb-system`ネームスペースに4つのポッドがあり、すべて問題なく実行されていることを確認してください。

k get pods -n metallb-system
NAME                                                      READY   STATUS    RESTARTS     AGE
metallb-controller-7fbfd8977d-m2q9t                       1/1     Running   0            46s
metallb-metallb-frr-k8s-9w7wl                             6/6     Running   0            46s
metallb-metallb-frr-k8s-webhook-server-5d9d67ffd6-8jqnc   1/1     Running   1 (6s ago)   46s
metallb-speaker-qx8bl                                     1/1     Running   0            46s

この時点で、MetalLBとFRR-K8sのインストールは完了です。

23.5 設定

 

  1. FRR-K8s用の`FRRConfiguration`を作成します。

    cat <<-EOF | kubectl apply -f -
apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: frrdemo
  namespace: metallb-system
spec:
  bgp:
    routers:
    - asn: 64513
      neighbors:
        - address: 192.168.20.154
          asn: 64512
          port: 179
          toAdvertise:
            allowed:
              mode: all
          toReceive:
            allowed:
              mode: all
EOF

    外部BGPルーターのASNは64512ですが、私たちの`BGPPeer`は64513になります。外部BGPルーターのIPアドレスが192.168.20.154であることも確認できます。

  2. FRRConfigurationがデプロイされていることを確認してください。

    k get FRRConfiguration -A
NAMESPACE        NAME      AGE
metallb-system   frrdemo   4s
    注記
    注記

    上記の`toReceive`設定により、クラスターはすべての着信ルートを受け入れるようになります。外部ルーターによってはノードのルーティングテーブルが一杯になる可能性があるため、本番環境では推奨されない場合があります。 受信フィルターの方法に関するドキュメントを参照してください。

FRR-K8sでは、これらすべての設定が必要です。外部BGPルーターが受信しているすべてのルートがクラスターと共有され、すべてのノードのルーティングテーブルが更新されます。

セットアップは第22章 「K3s上のMetalLB（レイヤー3モードを使用）」に記載されている方法でテストできます。これらのセットアップを組み合わせるには、いくつかの要件があります。

  • FRR-K8sの設定は別のクラスターで行われます。これはクラスター内部のルーティングを回避するために必要です。

  • 両方のセットアップを一致させるには、ASN IDとルーターIPアドレスの変更が必要です。

これら両方のセットアップが完了すると、以下が確認できます。

  • 第22章 「K3s上のMetalLB（レイヤー3モードを使用）」で説明されているクラスターにデプロイメントとサービスを適用すると、サービスへのルートが外部FRRルーターで確認できるようになります。

  • ルートは、FRR-K8sクラスター上のすべてのノードに追加されます。

注記
注記

FRRルーティングの標準構成では、ルートはFRRルーターのIPアドレスに設定されたネクストホップと共有されます。FRRルーターのIPアドレスを使用せずにネクストホップを実現するには、FRRルーター上の`/etc/frr/frr.conf`ファイルに「neighbor BGPPG next-hop-unchanged」という行と「neighbor BGPPG as-override」という行を追加します。これを設定すると、FRR-K8sクラスター上のノードはサービスへの直接ルートを取得します。

24 Kubernetes APIサーバーの前にあるMetalLB

 

このガイドでは、MetalLBサービスを使用して、3つのコントロールプレーンノードを持つHAクラスター上でRKE2/K3s APIを外部に公開する方法を説明します。 これを実現するために、タイプ`LoadBalancer`のKubernetesサービスを手動で作成します。次に、クラスター内のすべてのコントロールプレーンノードのIPを保持する`EndpointSlices`オブジェクトが自動的に作成されます。 EndpointSlicesをクラスター内で発生するイベント（ノードの追加/削除、またはノードのオフライン化）と継続的に同期させるために、Endpoint Copier Operator (第16章 「Endpoint Copier Operator」)をデプロイします。このオペレーターは、デフォルトの`kubernetes` EndpointSlicesで発生するイベントを監視し、管理対象のEndpointSlicesを自動的に更新して同期を維持します。 管理対象サービスはタイプ`LoadBalancer`であるため、MetalLBはそれに静的な`ExternalIP`を割り当てます。この`ExternalIP`は、APIサーバーとの通信に使用されます。

24.1 前提条件

 

  • RKE2/K3sをデプロイするための3つのホスト。

    • ホスト名がそれぞれ異なることを確認してください。

    • テスト目的であれば、これらは仮想マシンでも構いません。

  • ネットワーク内に少なくとも2つの利用可能なIPアドレス（Traefik Ingressコントローラーの公開サービス用に1つ、管理対象サービス用に1つ）。

  • Helm

24.2 RKE2/K3sのインストール

 
注記
注記

新規クラスターではなく既存のクラスターを使用する場合は、このステップをスキップして次のステップに進んでください。

まず、後で管理対象サービスの`ExternalIP`に使用するネットワーク内の空きIPアドレスを確保する必要があります。

最初のホストにSSHで接続し、目的のディストリビューションをクラスターモードでインストールします。

RKE2の場合:

# As a root user, create the /etc/rancher/rke2/config.yaml config file with the following content:

mkdir -p /etc/rancher/rke2/
cat <<EOF > /etc/rancher/rke2/config.yaml
# An example of the config.yaml file for a server node:
write-kubeconfig-mode: "0644"
ingress-controller: traefik
tls-san:
  - "${VIP_SERVICE_IP}"
  - "https://${VIP_SERVICE_IP}.sslip.io"
EOF

# Install RKE2
curl -sfL https://get.rke2.io | INSTALL_RKE2_EXEC="server" sh -

# Enable and start the RKE2 service with the configuration specified in the config.yaml file
systemctl enable rke2-server.service
systemctl start rke2-server.service

# Fetch the cluster token to be used later:
RKE2_TOKEN=$(tr -d '\n' < /var/lib/rancher/rke2/server/node-token)

K3sの場合:

# Export the free IP mentioned above
export VIP_SERVICE_IP=<ip>
export INSTALL_K3S_SKIP_START=false

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --cluster-init \
 --disable=servicelb --write-kubeconfig-mode=644 --tls-san=${VIP_SERVICE_IP} \
 --tls-san=https://${VIP_SERVICE_IP}.sslip.io" K3S_TOKEN=foobar sh -
注記
注記

k3s server`コマンドで--disable=servicelb`フラグが指定されていることを確認してください。

重要
重要

これ以降、コマンドはローカルマシンで実行してください。

外部からAPIサーバーにアクセスするには、RKE2/K3s VMのIPが使用されます。

# Replace <node-ip> with the actual IP of the machine
export NODE_IP=<node-ip>
export KUBE_DISTRIBUTION=<k3s/rke2>

scp ${NODE_IP}:/etc/rancher/${KUBE_DISTRIBUTION}/${KUBE_DISTRIBUTION}.yaml ~/.kube/config && sed \
 -i '' "s/127.0.0.1/${NODE_IP}/g" ~/.kube/config && chmod 600 ~/.kube/config

24.3 既存のクラスターの設定

 
注記
注記

この手順は、既存のRKE2/K3sクラスターを使用する場合にのみ有効です。

既存のクラスターを使用するには、tls-san`フラグを変更する必要があります。さらに、K3sの場合は`servicelb LBを無効にする必要があります。

RKE2またはK3sサーバーのフラグを変更するには、ディストリビューションに応じて、クラスター内のすべてのVM上の`/etc/systemd/system/rke2.service`または`/etc/systemd/system/k3s.service`ファイルのいずれかを変更する必要があります。

フラグは`ExecStart`に挿入する必要があります。次に例を示します。

RKE2の場合:

# Replace the <vip-service-ip> with the actual ip
ExecStart=/usr/local/bin/rke2 \
    server \
        '--write-kubeconfig-mode=644' \
        '--tls-san=<vip-service-ip>' \
        '--tls-san=https://<vip-service-ip>.sslip.io' \

K3sの場合:

# Replace the <vip-service-ip> with the actual ip
ExecStart=/usr/local/bin/k3s \
    server \
        '--cluster-init' \
        '--write-kubeconfig-mode=644' \
        '--disable=servicelb' \
        '--tls-san=<vip-service-ip>' \
        '--tls-san=https://<vip-service-ip>.sslip.io' \

次に、新しい設定を読み込むために以下のコマンドを実行する必要があります。

systemctl daemon-reload
systemctl restart ${KUBE_DISTRIBUTION}

24.4 MetalLBのインストール

 

`MetalLB`をデプロイするには、MetalLB on K3s (第21章 「K3s上のMetalLB（レイヤー2モードを使用）」)ガイドを使用できます。

NOTE:`VIP_SERVICE_IP`のIPアドレスが、クラスター内の既存の`IPAddressPools`と重複しないようにしてください。

管理対象サービス専用の`IpAddressPool`と`L2Advertisement`を作成します。

*NOTE:*以下のIPAddressPoolは、`default`ネームスペース内のタイプ`LoadBalancer`のサービスに割り当てられます。そこに複数の`LoadBalancer`サービスが存在する場合は、このVIPサービスを明示的に一致させるために、追加の ServiceSelectorsを設定できます。

# Export the VIP_SERVICE_IP on the local machine
# Replace with the actual IP
export VIP_SERVICE_IP=<ip>

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: kubernetes-vip-ip-pool
  namespace: metallb-system
spec:
  addresses:
  - ${VIP_SERVICE_IP}/32
  serviceAllocation:
    priority: 100
    namespaces:
      - default
EOF
cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: kubernetes-vip-l2-adv
  namespace: metallb-system
spec:
  ipAddressPools:
  - kubernetes-vip-ip-pool
EOF

24.5 Endpoint Copier Operatorのインストール

 
helm install \
endpoint-copier-operator oci://registry.suse.com/edge/charts/endpoint-copier-operator \
--namespace endpoint-copier-operator \
--create-namespace

上記のコマンドにより、2つのレプリカを持つ`endpoint-copier-operator`オペレーターのデプロイメントがデプロイされます。一方がリーダーとなり、もう一方が必要に応じてリーダーの役割を引き継ぎます。

次に`kubernetes-vip`サービスをデプロイする必要があります。これにより、オペレーターによって調整が行われ、設定されたポートとIPを持つEndpointSlicesが作成されます。

RKE2の場合:

cat <<-EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-vip
  namespace: default
spec:
  ports:
  - name: rke2-api
    port: 9345
    protocol: TCP
    targetPort: 9345
  - name: k8s-api
    port: 6443
    protocol: TCP
    targetPort: 6443
  type: LoadBalancer
EOF

K3sの場合:

cat <<-EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-vip
  namespace: default
spec:
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: https
    port: 6443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: LoadBalancer
EOF

`kubernetes-vip`サービスが正しいIPアドレスを持っていることを確認します。

kubectl get service kubernetes-vip -n default \
 -o=jsonpath='{.status.loadBalancer.ingress[0].ip}'

`default`ネームスペース内の`kubernetes-vip-*`および`kubernetes`EndpointSlicesリソースが同じIPを指していることを確認してください。

kubectl get endpointslices | grep kubernetes

すべてが正しい場合、最後にすべきことは、`Kubeconfig`内で`VIP_SERVICE_IP`を使用することです。

sed -i '' "s/${NODE_IP}/${VIP_SERVICE_IP}/g" ~/.kube/config

これ以降、すべての kubectl は kubernetes-vip サービスを経由します。

24.6 コントロールプレーンノードの追加

 

プロセス全体を監視するために、ターミナルタブをあと2つ開くことができます。

1つ目のターミナル:

watch kubectl get nodes

2つ目のターミナル:

watch kubectl get endpointslices

次に、2番目と3番目のノードで以下のコマンドを実行します。

RKE2の場合:

# As a root user, create the /etc/rancher/rke2/config.yaml config file with the following content:

mkdir -p /etc/rancher/rke2/
cat <<EOF > /etc/rancher/rke2/config.yaml
# An example of the config.yaml file for an additional server node:
server: https://${VIP_SERVICE_IP}:9345
write-kubeconfig-mode: "0644"
ingress-controller: traefik
tls-san:
  - "${VIP_SERVICE_IP}"
  - "https://${VIP_SERVICE_IP}.sslip.io"
# The one from above
token: ${RKE2_TOKEN}
EOF

# Install RKE2
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE="server" sh -

# Enable the RKE2 service with the configuration specified in the config.yaml file

systemctl enable --now rke2-server.service

# Fetch the cluster token to be used later:
RKE2_TOKEN=$(tr -d '\n' < /var/lib/rancher/rke2/server/node-token)

K3sの場合:

# Export the VIP_SERVICE_IP in the VM
# Replace with the actual IP
export VIP_SERVICE_IP=<ip>
export INSTALL_K3S_SKIP_START=false

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
 --server https://${VIP_SERVICE_IP}:6443 --disable=servicelb \
 --write-kubeconfig-mode=644" K3S_TOKEN=foobar sh -

25 Edge Image Builder を使用したエアギャップ(された)デプロイメント

 

25.1 紹介

 

このガイドでは、Edge Image Builder(EIB) (第8章 「Edge Image Builder」) を利用して、SUSE Linux Micro 6.2 上で SUSE Edge コンポーネントの一部を完全にエアギャップ(された)環境でデプロイする方法を説明します。これにより、EIB によって作成されたカスタマイズ済みで起動可能な (CRB) イメージで起動し、インターネット接続や手動の手順なしで、指定されたコンポーネントを RKE2 または K3s クラスターにデプロイできるようになります。この構成は、デプロイに必要なすべてのアーティファクトを OS イメージに事前に組み込み、起動時にすぐに利用できるようにしたいお客様にとって非常に望ましいものです。

ここでは、以下のエアギャップ(された)インストールについて説明します。

警告
警告

EIB は、提供された Helm チャートおよび Kubernetes マニフェストで参照されているすべてのイメージを解析し、事前にダウンロードします。ただし、その一部は実行時にコンテナイメージをプルし、それに基づいて Kubernetes リソースを作成しようとする場合があります。このような場合は、完全にエアギャップ(された)環境を構築するために、定義ファイルに必要なイメージを手動で指定する必要があります。

25.2 前提条件

 

このガイドに従う場合は、すでに EIB (第8章 「Edge Image Builder」) に精通していることを前提としています。そうでない場合は、クイックスタートガイド (第2章 「Edge Image Builderを使用したスタンドアロンクラスター」) に従って、以下で実践する概念をより深く理解してください。

25.3 Libvirt ネットワーク設定

 
注記
注記

エアギャップ(された)環境へのデプロイをデモするために、このガイドではシミュレートされたエアギャップ(された) libvirt ネットワークを使用し、以下の設定をそれに合わせて調整します。独自のデプロイメントでは、次のステップで紹介する host1.local.yaml 設定を変更する必要がある場合があります。

同じ libvirt ネットワーク設定を使用したい場合は、手順に従ってください。NICI 2.6.4が不要な場合は、25.4項 「ベースディレクトリの構成」に進みます。

DHCP 用の IP アドレス範囲 192.168.100.2/24 を持つ分離されたネットワーク設定を作成しましょう。

cat << EOF > isolatednetwork.xml
<network>
  <name>isolatednetwork</name>
  <bridge name='virbr1' stp='on' delay='0'/>
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.2' end='192.168.100.254'/>
    </dhcp>
  </ip>
</network>
EOF

あとは、ネットワークを作成して開始するだけです。

virsh net-define isolatednetwork.xml
virsh net-start isolatednetwork

25.4 ベースディレクトリの構成

 

ベースディレクトリの構成はすべてのコンポーネントで共通であるため、ここで設定します。

まず、必要なサブディレクトリを作成します。

export CONFIG_DIR=$HOME/config
mkdir -p $CONFIG_DIR/base-images
mkdir -p $CONFIG_DIR/network
mkdir -p $CONFIG_DIR/kubernetes/helm/values

使用する予定のベースイメージを必ず base-images ディレクトリに追加してください。このガイドでは、 こちら にあるセルフインストール ISO に焦点を当てます。

ダウンロードしたイメージをコピーしましょう。

cp SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso $CONFIG_DIR/base-images/slemicro.iso
注記
注記

EIB がベースイメージ入力を変更することはありません。

目的のネットワーク設定を含むファイルを作成しましょう。

cat << EOF > $CONFIG_DIR/network/host1.local.yaml
routes:
  config:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.100.1
    next-hop-interface: eth0
    table-id: 254
  - destination: 192.168.100.0/24
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
dns-resolver:
  config:
    server:
    - 192.168.100.1
    - 8.8.8.8
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: 34:8A:B1:4B:16:E7
  ipv4:
    address:
    - ip: 192.168.100.50
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    enabled: false
EOF

この構成により、プロビジョニングされたシステム（指定された MAC アドレスを使用）に以下が存在することが保証されます。

  • 静的 IP アドレスを持つイーサネットインターフェイス

  • ルーティング。

  • DNS

  • ホスト名 (host1.local)

結果として得られるファイル構造は、次のようになります。

├── kubernetes/
│   └── helm/
│       └── values/
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

25.5 ベース定義ファイル

 

Edge Image Builder は、定義ファイル を使用して SUSE Linux Micro イメージを変更します。これらのファイルには、構成可能なオプションの大部分が含まれています。 これらのオプションの多くはさまざまなコンポーネントセクションで繰り返されるため、ここではそれらをリストして説明します。

ヒント
ヒント

定義ファイル内のカスタマイズオプションの完全なリストは、 アップストリームドキュメント にあります。

すべての定義ファイルに存在する以下のフィールドを見ていきます。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
kubernetes:
  version: v1.35.4+rke2r1
embeddedArtifactRegistry:
  images:
    - ...

image セクションは必須であり、入力イメージ、そのアーキテクチャとタイプ、および出力イメージの名前を指定します。

operatingSystem セクションはオプションであり、root/eib ユーザー名/パスワードを使用してプロビジョニングされたシステムへのログインを有効にするための設定が含まれています。

kubernetes セクションはオプションであり、Kubernetes のタイプとバージョンを定義します。RKE2 ディストリビューションを使用します。K3s を希望する場合は、kubernetes.version: v1.35.4+k3s1 を使用してください。`kubernetes.nodes`フィールドで明示的に設定しない限り、このガイドでブートストラップするすべてのクラスターはシングルノードクラスターとなります。

`embeddedArtifactRegistry`セクションには、特定のコンポーネントに対して実行時にのみ参照およびプルされるすべてのイメージが含まれます。

25.6 Rancherインストール

 
注記
注記

デモンストレーションされるRancher (第4章 「Rancher」)デプロイメントは、デモンストレーションの目的のために大幅に簡素化されています。実際のデプロイメントでは、構成に応じて追加のアーティファクトが必要になる場合があります。

Rancher 2.14.2リリースアセットには、エアギャップインストールに必要なすべてのイメージがリストされた`rancher-images.txt`ファイルが含まれています。

合計で600以上のコンテナイメージがあるため、結果として生成されるCRBイメージは約30GBになります。Rancherのインストールでは、そのリストを最小限の動作構成まで削減します。そこから、デプロイメントに必要なイメージを追加できます。

定義ファイルを作成し、削減したイメージリストを含めます。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
kubernetes:
  version: v1.35.4+rke2r1
  manifests:
    urls:
    - https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.crds.yaml
  helm:
    charts:
      - name: rancher
        version: 2.14.2
        repositoryName: rancher-prime
        valuesFile: rancher-values.yaml
        targetNamespace: cattle-system
        createNamespace: true
        installationNamespace: kube-system
      - name: cert-manager
        installationNamespace: kube-system
        createNamespace: true
        repositoryName: jetstack
        targetNamespace: cert-manager
        version: 1.20.1
    repositories:
      - name: jetstack
        url: https://charts.jetstack.io
      - name: rancher-prime
        url: https://charts.rancher.com/server-charts/prime
embeddedArtifactRegistry:
  images:
    - name: registry.rancher.com/rancher/backup-restore-operator:v10.0.2
    - name: registry.rancher.com/rancher/compliance-operator:v1.4.1
    - name: registry.rancher.com/rancher/fleet-agent:v0.15.2
    - name: registry.rancher.com/rancher/fleet:v0.15.2
    - name: registry.rancher.com/rancher/hardened-addon-resizer:1.8.23-build20260413
    - name: registry.rancher.com/rancher/hardened-calico:v3.31.5-build20260415
    - name: registry.rancher.com/rancher/hardened-cluster-autoscaler:v1.10.3-build20260414
    - name: registry.rancher.com/rancher/hardened-cni-plugins:v1.9.1-build20260415
    - name: registry.rancher.com/rancher/hardened-coredns:v1.14.2-build20260416
    - name: registry.rancher.com/rancher/hardened-dns-node-cache:1.26.8-build20260416
    - name: registry.rancher.com/rancher/hardened-etcd:v3.6.7-k3s1-build20260415
    - name: registry.rancher.com/rancher/hardened-flannel:v0.28.4-build20260415
    - name: registry.rancher.com/rancher/hardened-k8s-metrics-server:v0.8.1-build20260413
    - name: registry.rancher.com/rancher/hardened-kubernetes:v1.35.4-rke2r1-build20260416
    - name: registry.rancher.com/rancher/hardened-multus-cni:v4.2.4-build20260310
    - name: registry.rancher.com/rancher/hardened-multus-dynamic-networks-controller:v0.3.7-build20260310
    - name: registry.rancher.com/rancher/hardened-multus-thick:v4.2.4-build20260310
    - name: registry.rancher.com/rancher/hardened-traefik:v3.6.13-build20260416
    - name: registry.rancher.com/rancher/hardened-whereabouts:v0.9.3-build20260408
    - name: registry.rancher.com/rancher/k3s-upgrade:v1.35.4-k3s1
    - name: registry.rancher.com/rancher/klipper-helm:v0.9.17-build20260422
    - name: registry.rancher.com/rancher/klipper-lb:v0.4.16
    - name: registry.rancher.com/rancher/kubectl:v1.35.2
    - name: registry.rancher.com/rancher/kuberlr-kubectl:v7.0.3
    - name: registry.rancher.com/rancher/local-path-provisioner:v0.0.35
    - name: registry.rancher.com/rancher/machine:v0.15.0-rancher142
    - name: registry.rancher.com/rancher/nginx-ingress-controller:v1.14.5-hardened2
    - name: registry.rancher.com/rancher/prom-prometheus:v3.8.1
    - name: registry.rancher.com/rancher/prometheus-federator:v6.0.0
    - name: registry.rancher.com/rancher/pushprox:v0.1.10
    - name: registry.rancher.com/rancher/rancher-agent:v2.14.2
    - name: registry.rancher.com/rancher/rancher-csp-adapter:v9.0.0
    - name: registry.rancher.com/rancher/rancher-webhook:v0.10.6
    - name: registry.rancher.com/rancher/rancher:v2.14.2
    - name: registry.rancher.com/rancher/remotedialer-proxy:v0.7.2
    - name: registry.rancher.com/rancher/rke2-cloud-provider:v1.35.4-0.20260415195656-e51c0636351d-build20260415
    - name: registry.rancher.com/rancher/rke2-runtime:v1.35.4-rke2r1
    - name: registry.rancher.com/rancher/rke2-upgrade:v1.35.4-rke2r1
    - name: registry.rancher.com/rancher/scc-operator:v0.4.1
    - name: registry.rancher.com/rancher/security-scan:v0.9.1
    - name: registry.rancher.com/rancher/shell:v0.1.24
    - name: registry.rancher.com/rancher/supportability-review-app-frontend:v0.19.0
    - name: registry.rancher.com/rancher/supportability-review-internal:latest
    - name: registry.rancher.com/rancher/supportability-review-operator:v0.19.0
    - name: registry.rancher.com/rancher/supportability-review:latest
    - name: registry.rancher.com/rancher/system-agent-installer-k3s:v1.35.4-k3s1
    - name: registry.rancher.com/rancher/system-agent-installer-rke2:v1.35.4-rke2r1
    - name: registry.rancher.com/rancher/system-agent:v0.3.16-suc
    - name: registry.rancher.com/rancher/system-upgrade-controller:v0.19.1
    - name: registry.rancher.com/rancher/turtles:v0.26.2
    - name: registry.rancher.com/rancher/ui-plugin-catalog:4.15.0
    - name: registry.rancher.com/rancher/kubectl:v1.20.2
    - name: registry.rancher.com/rancher/mirrored-ingress-nginx-kube-webhook-certgen:v1.6.7

600以上のコンテナイメージの完全なリストと比較して、この削減版には約60個しか含まれていないため、新しいCRBイメージは約7GBになります。

Rancher用のHelm値ファイルも作成する必要があります。

cat << EOF > $CONFIG_DIR/kubernetes/helm/values/rancher-values.yaml
hostname: 192.168.100.50.sslip.io
replicas: 1
bootstrapPassword: "adminadminadmin"
systemDefaultRegistry: registry.rancher.com
useBundledSystemChart: true
EOF
警告
警告

`systemDefaultRegistry`を`registry.rancher.com`に設定すると、Rancherは起動時にCRBイメージ内で開始される組み込みアーティファクトレジストリ内のイメージを自動的に検索できるようになります。このフィールドを省略すると、ノード上でコンテナイメージが見つからない可能性があります。

イメージをビルドしましょう。

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file eib-iso-definition.yaml

出力は以下のようになるはずです。

Downloading file: dl-manifest-1.yaml 100% |██████████████████████████████████████████████████████████████████████████████| (583/583 kB, 12 MB/s)
Pulling selected Helm charts... 100% |███████████████████████████████████████████████████████████████████████████████████████████| (2/2, 3 it/s)
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Rpm .......................... [SKIPPED]
Os Files ..................... [SKIPPED]
Systemd ...................... [SKIPPED]
Fips ......................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Populating Embedded Artifact Registry... 100% |███████████████████████████████████████████████████████████████████████████| (56/56, 8 it/min)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Downloading file: rke2-images-core.linux-amd64.tar.zst 100% |███████████████████████████████████████████████████████████| (644/644 MB, 29 MB/s)
Downloading file: rke2-images-cilium.linux-amd64.tar.zst 100% |█████████████████████████████████████████████████████████| (400/400 MB, 29 MB/s)
Downloading file: rke2.linux-amd64.tar.gz 100% |███████████████████████████████████████████████████████████████████████████| (36/36 MB, 30 MB/s)
Downloading file: sha256sum-amd64.txt 100% |█████████████████████████████████████████████████████████████████████████████| (4.3/4.3 kB, 29 MB/s)
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Cleanup ...................... [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Build complete, the image can be found at: eib-image.iso

ビルドされたイメージを使用するノードがプロビジョニングされたら、Rancherのインストールを確認できます。

/var/lib/rancher/rke2/bin/kubectl get all -n cattle-system --kubeconfig /etc/rancher/rke2/rke2.yaml

出力は以下のようになり、すべてが正常にデプロイされたことが示されます。

NAME                                            READY   STATUS      RESTARTS   AGE
pod/helm-operation-6l6ld                        0/2     Completed   0          107s
pod/helm-operation-8tk2v                        0/2     Completed   0          2m2s
pod/helm-operation-blnrr                        0/2     Completed   0          2m49s
pod/helm-operation-hdcmt                        0/2     Completed   0          3m19s
pod/helm-operation-m74c7                        0/2     Completed   0          97s
pod/helm-operation-qzzr4                        0/2     Completed   0          2m30s
pod/helm-operation-s9jh5                        0/2     Completed   0          3m
pod/helm-operation-tq7ts                        0/2     Completed   0          2m41s
pod/rancher-99d599967-ftjkk                     1/1     Running     0          4m15s
pod/rancher-webhook-79798674c5-6w28t            1/1     Running     0          2m27s
pod/system-upgrade-controller-56696956b-trq5c   1/1     Running     0          104s

NAME                      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/rancher           ClusterIP   10.43.255.80   <none>        80/TCP,443/TCP   4m15s
service/rancher-webhook   ClusterIP   10.43.7.238    <none>        443/TCP          2m27s

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/rancher                     1/1     1            1           4m15s
deployment.apps/rancher-webhook             1/1     1            1           2m27s
deployment.apps/system-upgrade-controller   1/1     1            1           104s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/rancher-99d599967                     1         1         1       4m15s
replicaset.apps/rancher-webhook-79798674c5            1         1         1       2m27s
replicaset.apps/system-upgrade-controller-56696956b   1         1         1       104s

`\https://192.168.100.50.sslip.io`にアクセスし、先ほど設定した`adminadminadmin`パスワードでログインすると、Rancherダッシュボードが表示されます。

air gapped rancher

25.7 SUSE Securityインストール

 

Rancherのインストールとは異なり、SUSE SecurityのインストールではEIBでの特別な処理は必要ありません。EIBは、その基盤となるコンポーネントであるNeuVectorが必要とするすべてのイメージを自動的にエアギャップ化します。

定義ファイルを作成します。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
kubernetes:
  version: v1.35.4+rke2r1
  helm:
    charts:
      - name: neuvector-crd
        version: 109.0.2+up2.10.2
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector-values.yaml
      - name: neuvector
        version: 109.0.2+up2.10.2
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector-values.yaml
    repositories:
      - name: rancher-charts
        url: https://charts.rancher.io/

また、NeuVector用のHelm値ファイルも作成します。

cat << EOF > $CONFIG_DIR/kubernetes/helm/values/neuvector-values.yaml
controller:
  replicas: 1
manager:
  enabled: false
cve:
  scanner:
    enabled: false
    replicas: 1
k3s:
  enabled: true
crdwebhook:
  enabled: false
EOF

イメージをビルドしましょう。

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file eib-iso-definition.yaml

出力は以下のようになるはずです。

Pulling selected Helm charts... 100% |███████████████████████████████████████████████████████████████████████████████████████████| (2/2, 4 it/s)
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Rpm .......................... [SKIPPED]
Os Files ..................... [SKIPPED]
Systemd ...................... [SKIPPED]
Fips ......................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Populating Embedded Artifact Registry... 100% |██████████████████████████████████████████████████████████████████████████████| (5/5, 13 it/min)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Cleanup ...................... [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Build complete, the image can be found at: eib-image.iso

ビルドされたイメージを使用するノードがプロビジョニングされたら、SUSE Securityのインストールを確認できます。

/var/lib/rancher/rke2/bin/kubectl get all -n neuvector --kubeconfig /etc/rancher/rke2/rke2.yaml

出力は以下のようになり、すべてが正常にデプロイされたことが示されます。

NAME                                            READY   STATUS      RESTARTS   AGE
pod/neuvector-cert-upgrader-job-bxbnz           0/1     Completed   0          3m39s
pod/neuvector-controller-pod-7d854bfdc7-nhxjf   1/1     Running     0          3m44s
pod/neuvector-enforcer-pod-ct8jm                1/1     Running     0          3m44s

NAME                                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
service/neuvector-svc-admission-webhook   ClusterIP   10.43.234.241   <none>        443/TCP                         3m44s
service/neuvector-svc-controller          ClusterIP   None            <none>        18300/TCP,18301/TCP,18301/UDP   3m44s
service/neuvector-svc-crd-webhook         ClusterIP   10.43.50.190    <none>        443/TCP                         3m44s

NAME                                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/neuvector-enforcer-pod   1         1         1       1            1           <none>          3m44s

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/neuvector-controller-pod   1/1     1            1           3m44s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/neuvector-controller-pod-7d854bfdc7   1         1         1       3m44s

NAME                                        SCHEDULE    TIMEZONE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/neuvector-cert-upgrader-pod   0 0 1 1 *   <none>     True      0        <none>          3m44s
cronjob.batch/neuvector-updater-pod         0 0 * * *   <none>     False     0        <none>          3m44s

NAME                                    STATUS     COMPLETIONS   DURATION   AGE
job.batch/neuvector-cert-upgrader-job   Complete   1/1           7s         3m39s

25.8 SUSE Storageのインストール

 

Longhornの 公式ドキュメントには、エアギャップインストールに必要なすべてのイメージがリストされた`longhorn-images.txt`ファイルが含まれています。 Rancherコンテナレジストリからのミラー化された対応イメージを定義ファイルに含めます。 作成しましょう。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
  packages:
    sccRegistrationCode: [reg-code]
    packageList:
      - open-iscsi
kubernetes:
  version: v1.35.4+rke2r1
  helm:
    charts:
      - name: suse-storage
        releaseName: longhorn
        repositoryName: rancher-application-collection
        targetNamespace: longhorn-system
        createNamespace: true
        version: 1.11.2
    repositories:
      - name: rancher-application-collection
        url: oci://dp.apps.rancher.io/charts
        authentication:
          username: $APPS.RANCHER.IO_USERNAME
          password: $APPS.RANCHER.IO_ACCESS_TOKEN
embeddedArtifactRegistry:
    registries:
      - uri: dp.apps.rancher.io
        authentication:
          username: $APPS.RANCHER.IO_USERNAME
          password: $APPS.RANCHER.IO_ACCESS_TOKEN
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-attacher:4.11.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-provisioner:5.3.0-14.1
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-resizer:2.1.0-6.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-snapshotter:8.5.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-livenessprobe:2.18.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-node-driver-registrar:2.16.0-13.2
    - name: dp.apps.rancher.io/containers/longhorn-backing-image-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-engine:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-instance-manager:1.11.2-4.3
    - name: dp.apps.rancher.io/containers/longhorn-manager:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-share-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-ui:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/rancher-support-bundle-kit:0.0.84-9.4
注記
注記

定義ファイルに`open-iscsi`パッケージがリストされていることにお気づきでしょう。これは、LonghornがKubernetesに永続ボリュームを提供するために、異なるノードで実行されている`iscsiadm`デーモンに依存しているため必要です。

イメージをビルドしましょう。

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file eib-iso-definition.yaml

出力は以下のようになるはずです。

Setting up Podman API listener...
Pulling selected Helm charts... 100% |██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 3 it/s)
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Resolving package dependencies...
Rpm .......................... [SUCCESS]
Os Files ..................... [SKIPPED]
Systemd ...................... [SKIPPED]
Fips ......................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Populating Embedded Artifact Registry... 100% |███████████████████████████████████████████████████████████████████████████████████████████████████████████| (15/15, 20956 it/s)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Downloading file: rke2-images-core.linux-amd64.tar.zst 100% (782/782 MB, 108 MB/s)
Downloading file: rke2-images-cilium.linux-amd64.tar.zst 100% (367/367 MB, 104 MB/s)
Downloading file: rke2.linux-amd64.tar.gz 100% (34/34 MB, 108 MB/s)
Downloading file: sha256sum-amd64.txt 100% (3.9/3.9 kB, 7.5 MB/s)
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Cleanup ...................... [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Build complete, the image can be found at: eib-image.iso

ビルドされたイメージを使用するノードがプロビジョニングされたら、Longhornのインストールを確認できます。

/var/lib/rancher/rke2/bin/kubectl get all -n longhorn-system --kubeconfig /etc/rancher/rke2/rke2.yaml

出力は以下のようになり、すべてが正常にデプロイされたことが示されます。

NAME                                                    READY   STATUS    RESTARTS   AGE
pod/csi-attacher-787fd9c6c8-sf42d                       1/1     Running   0          2m28s
pod/csi-attacher-787fd9c6c8-tb82p                       1/1     Running   0          2m28s
pod/csi-attacher-787fd9c6c8-zhc6s                       1/1     Running   0          2m28s
pod/csi-provisioner-74486b95c6-b2v9s                    1/1     Running   0          2m28s
pod/csi-provisioner-74486b95c6-hwllt                    1/1     Running   0          2m28s
pod/csi-provisioner-74486b95c6-mlrpk                    1/1     Running   0          2m28s
pod/csi-resizer-859d4557fd-t54zk                        1/1     Running   0          2m28s
pod/csi-resizer-859d4557fd-vdt5d                        1/1     Running   0          2m28s
pod/csi-resizer-859d4557fd-x9kh4                        1/1     Running   0          2m28s
pod/csi-snapshotter-6f69c6c8cc-r62gr                    1/1     Running   0          2m28s
pod/csi-snapshotter-6f69c6c8cc-vrwjn                    1/1     Running   0          2m28s
pod/csi-snapshotter-6f69c6c8cc-z65nb                    1/1     Running   0          2m28s
pod/engine-image-ei-4623b511-9vhkb                      1/1     Running   0          3m13s
pod/instance-manager-6f95fd57d4a4cd0459e469d75a300552   1/1     Running   0          2m43s
pod/longhorn-csi-plugin-gx98x                           3/3     Running   0          2m28s
pod/longhorn-driver-deployer-55f9c88499-fbm6q           1/1     Running   0          3m28s
pod/longhorn-manager-dpdp7                              2/2     Running   0          3m28s
pod/longhorn-ui-59c85fcf94-gg5hq                        1/1     Running   0          3m28s
pod/longhorn-ui-59c85fcf94-s49jc                        1/1     Running   0          3m28s

NAME                                  TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/longhorn-admission-webhook    ClusterIP   10.43.77.89    <none>        9502/TCP   3m28s
service/longhorn-backend              ClusterIP   10.43.56.17    <none>        9500/TCP   3m28s
service/longhorn-conversion-webhook   ClusterIP   10.43.54.73    <none>        9501/TCP   3m28s
service/longhorn-frontend             ClusterIP   10.43.22.82    <none>        80/TCP     3m28s
service/longhorn-recovery-backend     ClusterIP   10.43.45.143   <none>        9503/TCP   3m28s

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/engine-image-ei-4623b511   1         1         1       1            1           <none>          3m13s
daemonset.apps/longhorn-csi-plugin        1         1         1       1            1           <none>          2m28s
daemonset.apps/longhorn-manager           1         1         1       1            1           <none>          3m28s

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/csi-attacher               3/3     3            3           2m28s
deployment.apps/csi-provisioner            3/3     3            3           2m28s
deployment.apps/csi-resizer                3/3     3            3           2m28s
deployment.apps/csi-snapshotter            3/3     3            3           2m28s
deployment.apps/longhorn-driver-deployer   1/1     1            1           3m28s
deployment.apps/longhorn-ui                2/2     2            2           3m28s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/csi-attacher-787fd9c6c8               3         3         3       2m28s
replicaset.apps/csi-provisioner-74486b95c6            3         3         3       2m28s
replicaset.apps/csi-resizer-859d4557fd                3         3         3       2m28s
replicaset.apps/csi-snapshotter-6f69c6c8cc            3         3         3       2m28s
replicaset.apps/longhorn-driver-deployer-55f9c88499   1         1         1       3m28s
replicaset.apps/longhorn-ui-59c85fcf94                2         2         2       3m28s

25.9 KubeVirtおよびCDIのインストール

 

KubeVirtとCDIの両方のHelmチャートは、それぞれのオペレーターのみをインストールします。 システムの残りの部分をデプロイするのはオペレーターの役割であるため、必要なコンテナイメージをすべて定義ファイルに含める必要があります。作成しましょう。

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
kubernetes:
  version: v1.35.4+rke2r1
  helm:
    charts:
      - name: kubevirt
        repositoryName: suse-edge
        version: 306.0.2+up0.7.0
        targetNamespace: kubevirt-system
        createNamespace: true
        installationNamespace: kube-system
      - name: cdi
        repositoryName: suse-edge
        version: 306.0.2+up0.7.0
        targetNamespace: cdi-system
        createNamespace: true
        installationNamespace: kube-system
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge/charts
embeddedArtifactRegistry:
  images:
    - name: registry.suse.com/suse/sles/15.7/cdi-apiserver:1.64.0-150700.9.6.1
    - name: registry.suse.com/suse/sles/15.7/cdi-controller:1.64.0-150700.9.6.1
    - name: registry.suse.com/suse/sles/15.7/cdi-operator:1.64.0-150700.9.6.1
    - name: registry.suse.com/suse/sles/15.7/cdi-uploadproxy:1.64.0-150700.9.6.1
    - name: registry.suse.com/suse/sles/15.7/virt-api:1.7.0-150700.3.16.2
    - name: registry.suse.com/suse/sles/15.7/virt-controller:1.7.0-150700.3.16.2
    - name: registry.suse.com/suse/sles/15.7/virt-handler:1.7.0-150700.3.16.2
    - name: registry.suse.com/suse/sles/15.7/virt-launcher:1.7.0-150700.3.16.2
    - name: registry.suse.com/suse/sles/15.7/virt-operator:1.7.0-150700.3.16.2

イメージをビルドしましょう。

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file eib-iso-definition.yaml

出力は以下のようになるはずです。

Pulling selected Helm charts... 100% |███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 48 it/min)
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Rpm .......................... [SKIPPED]
Os Files ..................... [SKIPPED]
Systemd ...................... [SKIPPED]
Fips ......................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Populating Embedded Artifact Registry... 100% |██████████████████████████████████████████████████████████████████████████████████████████████████████████| (15/15, 4 it/min)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Cleanup ...................... [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Build complete, the image can be found at: eib-image.iso

ビルドされたイメージを使用するノードがプロビジョニングされたら、KubeVirtとCDIの両方のインストールを確認できます。

KubeVirtの確認:

/var/lib/rancher/rke2/bin/kubectl get all -n kubevirt-system --kubeconfig /etc/rancher/rke2/rke2.yaml

出力は以下のようになり、すべてが正常にデプロイされたことが示されます。

NAME                                  READY   STATUS    RESTARTS   AGE
pod/virt-api-59cb997648-mmt67         1/1     Running   0          2m34s
pod/virt-controller-69786b785-7cc96   1/1     Running   0          2m8s
pod/virt-controller-69786b785-wq2dz   1/1     Running   0          2m8s
pod/virt-handler-2l4dm                1/1     Running   0          2m8s
pod/virt-operator-7c444cff46-nps4l    1/1     Running   0          3m1s
pod/virt-operator-7c444cff46-r25xq    1/1     Running   0          3m1s

NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubevirt-operator-webhook     ClusterIP   10.43.167.109   <none>        443/TCP   2m36s
service/kubevirt-prometheus-metrics   ClusterIP   None            <none>        443/TCP   2m36s
service/virt-api                      ClusterIP   10.43.18.202    <none>        443/TCP   2m36s
service/virt-exportproxy              ClusterIP   10.43.142.188   <none>        443/TCP   2m36s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/virt-handler   1         1         1       1            1           kubernetes.io/os=linux   2m8s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/virt-api          1/1     1            1           2m34s
deployment.apps/virt-controller   2/2     2            2           2m8s
deployment.apps/virt-operator     2/2     2            2           3m1s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/virt-api-59cb997648         1         1         1       2m34s
replicaset.apps/virt-controller-69786b785   2         2         2       2m8s
replicaset.apps/virt-operator-7c444cff46    2         2         2       3m1s

NAME                            AGE    PHASE
kubevirt.kubevirt.io/kubevirt   3m1s   Deployed

CDIの確認:

/var/lib/rancher/rke2/bin/kubectl get all -n cdi-system --kubeconfig /etc/rancher/rke2/rke2.yaml

出力は以下のようになり、すべてが正常にデプロイされたことが示されます。

NAME                                   READY   STATUS    RESTARTS   AGE
pod/cdi-apiserver-5598c9bf47-pqfxw     1/1     Running   0          3m44s
pod/cdi-deployment-7cbc5db7f8-g46z7    1/1     Running   0          3m44s
pod/cdi-operator-777c865745-2qcnj      1/1     Running   0          3m48s
pod/cdi-uploadproxy-646f4cd7f7-fzkv7   1/1     Running   0          3m44s

NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/cdi-api                  ClusterIP   10.43.2.224    <none>        443/TCP    3m44s
service/cdi-prometheus-metrics   ClusterIP   10.43.237.13   <none>        8080/TCP   3m44s
service/cdi-uploadproxy          ClusterIP   10.43.114.91   <none>        443/TCP    3m44s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cdi-apiserver     1/1     1            1           3m44s
deployment.apps/cdi-deployment    1/1     1            1           3m44s
deployment.apps/cdi-operator      1/1     1            1           3m48s
deployment.apps/cdi-uploadproxy   1/1     1            1           3m44s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/cdi-apiserver-5598c9bf47     1         1         1       3m44s
replicaset.apps/cdi-deployment-7cbc5db7f8    1         1         1       3m44s
replicaset.apps/cdi-operator-777c865745      1         1         1       3m48s
replicaset.apps/cdi-uploadproxy-646f4cd7f7   1         1         1       3m44s

25.10 SUSE Private Registryのインストール

 

SUSE Private Registryをエアギャップ(された)デプロイメントに含めるには、必要なHelmチャートと新しいイメージ用の埋め込みアーティファクトを含めるように定義ファイルを更新する必要があります。

定義ファイルを更新しましょう：

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
kubernetes:
  version: v1.35.4+rke2r1
  helm:
    charts:
      - name: metallb
        version: 306.0.2+up0.15.3
        targetNamespace: metallb-system
        createNamespace: true
        repositoryName: suse-edge-charts
        installationNamespace: kube-system
      - name: suse-storage
        releaseName: longhorn
        repositoryName: rancher-application-collection
        targetNamespace: longhorn-system
        createNamespace: true
        version: 1.11.2
      - name: private-registry-helm
        createNamespace: true
        installationNamespace: kube-system
        repositoryName: privateregistry
        targetNamespace: suse-private-registry
        valuesFile: privateregistry.yaml
        version: 1.1.1
    repositories:
      - name: privateregistry
        authentication:
          username: ${PRIVATE_REGISTRY_USERNAME}
          password: ${PRIVATE_REGISTRY_PASSWORD}
        plainHTTP: false
        skipTLSVerify: false
        url: oci://registry.suse.com/private-registry
      - name: rancher-application-collection
        url: oci://dp.apps.rancher.io/charts
        authentication:
          username: $APPS.RANCHER.IO_USERNAME
          password: $APPS.RANCHER.IO_ACCESS_TOKEN
embeddedArtifactRegistry:
  registries:
    - uri: registry.suse.com
      authentication:
        username: ${PRIVATE_REGISTRY_USERNAME}
        password: ${PRIVATE_REGISTRY_PASSWORD}
    - uri: dp.apps.rancher.io
        authentication:
          username: $APPS.RANCHER.IO_USERNAME
          password: $APPS.RANCHER.IO_ACCESS_TOKEN
  images:
    - name: registry.suse.com/private-registry/harbor-core:1.1.1-1.19
    - name: registry.suse.com/private-registry/harbor-jobservice:1.1.1-1.19
    - name: registry.suse.com/private-registry/harbor-portal:1.1.1-1.20
    - name: registry.suse.com/private-registry/harbor-registry:1.1.1-1.19
    - name: registry.suse.com/private-registry/harbor-registryctl:1.1.1-1.19
    - name: registry.suse.com/private-registry/harbor-trivy-adapter:1.1.1-1.24
注記
注記

特定の認証情報が必要になります。これは、公式の SUSE Private Registry documentationに従うことで取得できます。 また、${PRIVATE_REGISTRY_USERNAME}`変数と${PRIVATE_REGISTRY_PASSWORD}`変数を変更する必要があります。必要なコンポーネントバージョンを含むイメージを必ずリストしてください。

次に、SUSE Private Registryを適切に設定するために必要なKubernetesマニフェストを追加する必要があります。

以下のファイルで、SUSE Private Registry用に予約された静的IPを使用して`${MGMT_CLUSTER_REGISTRY_IP}`を変更する必要があります：

  1. kubernetes/manifests/metallb-registry.yaml

    apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: private-registry
  namespace: metallb-system
spec:
  ipAddressPools:
  - private-registry-pool
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: private-registry-pool
  namespace: metallb-system
spec:
  addresses:
  - ${MGMT_CLUSTER_REGISTRY_IP}/32
  serviceAllocation:
    namespaces:
    - suse-private-registry

  2. kubernetes/helm/values/privateregistry.yaml

    core:
  secretName: suse-registry-tls
expose:
  tls:
    certSource: secret
    enabled: true
    secret:
      secretName: suse-registry-tls
  type: loadBalancer
externalURL: https://${MGMT_CLUSTER_REGISTRY_IP}
persistence:
  persistentVolumeClaim:
    registry:
      size: 20Gi

最後に、以下の内容で`kubernetes/manifests/suse-private-registry-creds.yaml`を作成する必要があります：

apiVersion: v1
kind: Secret
metadata:
  name: suse-registry
  namespace: suse-private-registry
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: ${DOCKER_CONFIG_JSON_BASE64}
---
apiVersion: v1
kind: Secret
metadata:
    name: suse-registry-tls
    namespace: suse-private-registry
type: kubernetes.io/tls
data:
    tls.crt: ${TLS_CRT_BASE64}
    tls.key: ${TLS_KEY_BASE64}

`${DOCKER_CONFIG_JSON_BASE64}`用のdocker config json（base64）を正しく設定するには、以下を実行します：

# ${DOCKER_CONFIG_JSON_BASE64} CONTENT
echo -n '{"auths": {"<MGMT_CLUSTER_REGISTRY_IP>": {"username": "<USERNAME>", "password": "<PASSWORD>", "auth": "<AUTH>"}}}' | base64

ここで、IPは以前に設定した`${MGMT_CLUSTER_REGISTRY_IP}`と同じであり、username、password、および`auth`は SUSE Private Registry official documentationから取得できます。

${TLS_CRT_BASE64}`および${TLS_KEY_BASE64}`用のbase64エンコードされたTLS証明書とキー（tls.crt`および`tls.key）を生成するには、以下を実行して独自のものを作成できます：

# Generate a self-signed certificate and key
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365 -nodes

# Convert them to base64 for the suse-private-registry-creds.yaml file
cat cert.pem | base64 -w 0
cat key.pem | base64 -w 0

SUSE Private Registryを検証します：

/var/lib/rancher/rke2/bin/kubectl get pods -n suse-private-registry --kubeconfig /etc/rancher/rke2/rke2.yaml

出力は以下のようになり、すべてが正常にデプロイされたことが示されます。

NAME                                                      READY   STATUS    RESTARTS   AGE
pod/private-registry-harbor-core-588fd4876f-8tqnv         1/1     Running   0          4m30s
pod/private-registry-harbor-database-0                    1/1     Running   0          4m30s
pod/private-registry-harbor-jobservice-7658f97fbc-4vq6n   1/1     Running   0          4m30s
pod/private-registry-harbor-portal-5455ccc4bc-jpmt5       1/1     Running   0          4m30s
pod/private-registry-harbor-redis-0                       1/1     Running   0          4m30s
pod/private-registry-harbor-registry-5648b9d89-wdswz      2/2     Running   0          4m30s
pod/private-registry-harbor-trivy-0                       1/1     Running   0          4m30s

25.11 トラブルシューティング

 

イメージのビルド中に問題が発生した場合や、処理のさらなるテストやデバッグをご希望の場合は、 アップストリームドキュメントを参照してください。

26 Kiwiを使用して更新されたSUSE Linux Microイメージを構築する

 

このセクションでは、Edge Image Builder、Cluster API (CAPI) + Metal3で使用する、またはディスクイメージをブロックデバイスに直接書き込むための、更新されたSUSE Linux Microイメージの生成方法について説明します。このプロセスは、初期システムブートイメージに最新のパッチを含める必要がある場合（インストール後のパッチ転送を最小限に抑えるため）、またはCAPIを使用するシナリオで、ホストをその場でアップグレードするよりも新しいイメージでオペレーティングシステムを再インストールすることが望ましい場合に役立ちます。

このプロセスでは、 Kiwiを使用してイメージビルドを実行します。SUSE Edgeには、ヘルパーユーティリティが組み込まれており、全体的なプロセスを簡素化するコンテナ化されたバージョンが付属しているため、必要なターゲット*プロファイル*を指定できます。プロファイルは、必要な出力イメージのタイプを定義します。一般的なものを以下に示します。

  • \"Base\" - パッケージセットが削減されたSUSE Linux Microディスクイメージ（podmanが含まれています）。

  • \"Base-SelfInstall\" - 上記の「Base」に基づくSelfInstallイメージ。

  • \"Base-RT\" - 上記の「Base」と同じですが、代わりにリアルタイム（rt）カーネルを使用します。

  • \"Base-RT-SelfInstall\" - 上記の「Base-RT」に基づくSelfInstallイメージ

  • \"Default\" - 上記の「Base」に基づくSUSE Linux Microディスクイメージですが、仮想化スタック、Cockpit、salt-minionなど、いくつかのツールが追加されています。

  • \"Default-SelfInstall\" - 上記の「Default」に基づくSelfInstallイメージ

詳細については、 SUSE Linux Micro 6.2のドキュメントを参照してください。

注記
注記

このプロセスはAMD64/Intel 64アーキテクチャとAArch64アーキテクチャの両方で機能しますが、構築するイメージと同じアーキテクチャのビルドホストを使用する必要があります。言い換えると、AArch64イメージを構築するにはAArch64ビルドホストを使用する必要があり、AMD64/Intel 64の場合も同様です。現時点ではクロスビルドはサポートされていません。

26.1 前提条件

 

Kiwiイメージビルダーには以下が必要です。

  • 構築するイメージと同じアーキテクチャのSUSE Linux Micro 6.2ホスト（「ビルドシステム」）が必要です。

  • ビルドシステムは、`SUSEConnect`を介してすでに登録されている必要があります（登録は、SUSEリポジトリから最新のパッケージを取得するために使用されます）。

  • 必要なパッケージを取得するために使用できるインターネット接続。プロキシ経由で接続する場合、ビルドホストを事前に設定しておく必要があります。

  • ビルドホスト上でSELinuxを無効にする必要があります（SELinuxのラベリングはコンテナ内で行われ、ホストのポリシーと競合する可能性があるためです）。

  • コンテナイメージ、ビルドルート、および生成される出力イメージを格納するために、少なくとも10GBの空きディスク容量が必要です。

26.2 はじめに

 

特定の制限により、現在はSELinuxを無効にする必要があります。SUSE Linux Micro 6.2 イメージビルドホストに接続し、SELinuxが無効になっていることを確認してください。

# setenforce 0

生成されたイメージを保存するために、Kiwiビルドコンテナと共有する出力ディレクトリを作成します。

# mkdir ~/output

SUSEレジストリから最新のKiwiビルダーイメージをプルします。

# podman pull registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1
(...)

26.3 デフォルトイメージのビルド

 

これは、コンテナイメージの実行時に引数が指定されなかった場合のKiwiイメージコンテナのデフォルトの動作です。次のコマンドは、2つのディレクトリをコンテナにマッピングして podman を実行します。

  • 基盤となるホスト上の /etc/zypp/repos.d SUSE Linux Microパッケージリポジトリディレクトリが必要です。

  • 上記で作成した出力 ~/output ディレクトリが必要です。

Kiwiイメージコンテナでは、build-image ヘルパースクリプトを次のように実行する必要があります。

# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ~/output:/tmp/output \
    -it registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1 build-image
(...)
注記
注記

このスクリプトを初めて実行する場合、開始直後に「ERROR:」というエラーで *失敗 することが予想されます。「Early loop device test failed, please retry the container run.*」というエラーは、基盤となるホストシステム上で作成されたループデバイスが、コンテナイメージ内で即座に認識されないことに起因する現象です。コマンドをもう一度実行するだけで、問題なく処理が進むはずです。

数分後、イメージはローカルの出力ディレクトリで見つかります。

(...)
INFO: Image build successful, generated images are available in the 'output' directory.

# ls -1 output/
SLE-Micro.x86_64-6.2.changes
SLE-Micro.x86_64-6.2.packages
SLE-Micro.x86_64-6.2.raw
SLE-Micro.x86_64-6.2.verified
build
kiwi.result
kiwi.result.json

26.4 他のプロファイルでのイメージビルド

 

異なるイメージプロファイルをビルドするには、Kiwiコンテナイメージヘルパースクリプトの「-p」コマンドオプションを使用します。例えば、「Default-SelfInstall」ISOイメージをビルドするには次のようにします。

# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ~/output:/tmp/output \
    -it registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1 build-image -p Default-SelfInstall
(...)
注記
注記

データ損失を防ぐため、`output`ディレクトリ内にイメージが存在する場合、Kiwiは実行を拒否します。`rm -f output/*`に進む前に、出力ディレクトリの内容を削除する必要があります。

あるいは、リアルタイムカーネル ("kernel-rt") を使用してSelfInstall ISOイメージをビルドするには、次のようにします。

# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ~/output:/tmp/output \
    -it registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1 build-image -p Base-RT-SelfInstall
(...)

26.5 大きなセクタサイズでのイメージのビルド

 

一部のハードウェアでは、標準の512バイトではなく、大きなセクタサイズ（例: 4096 bytes）のイメージが必要です。コンテナ化されたKiwiビルダーは、「-b」パラメータを指定することで、大きなブロックサイズのイメージを生成する機能をサポートしています。例えば、大きなセクタサイズで「Default-SelfInstall」イメージをビルドするには、次のようにします。

# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ~/output:/tmp/output \
    -it registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1 build-image -p Default-SelfInstall -b
(...)

26.6 カスタムKiwiイメージ定義ファイルの使用

 

高度なユースケースでは、カスタムKiwiイメージ定義ファイル (SL-Micro.kiwi) を、必要なビルド後スクリプトと共に使用できます。これには、SUSE Edgeチームによって事前にパッケージ化されたデフォルトの定義を上書きする必要があります。

新しいディレクトリを作成し、ヘルパースクリプトが参照しているコンテナイメージ内の場所にマッピングします (/micro-sdk/defs)。

# mkdir ~/mydefs/
# cp /path/to/SL-Micro.kiwi ~/mydefs/
# cp /path/to/config.sh ~/mydefs/
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ~/output:/tmp/output -v ~/mydefs/:/micro-sdk/defs/ \
    -it registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1 build-image
(...)
警告
警告

これは高度なユースケースでのみ必要であり、サポート上の問題を引き起こす可能性があります。詳細なアドバイスやガイダンスについては、SUSEの担当者にお問い合わせください。

コンテナに含まれるデフォルトのKiwiイメージ定義ファイルを取得するには、以下のコマンドを使用できます。

$ podman create --name kiwi-builder registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1
$ podman cp kiwi-builder:/micro-sdk/defs/SL-Micro.kiwi .
$ podman cp kiwi-builder:/micro-sdk/defs/SL-Micro.kiwi.4096 .
$ podman rm kiwi-builder
$ ls ./SL-Micro.*
(...)

パート IV ヒントとトラブルシューティング

 

エッジコンポーネントのヒントとコツ

  • 27 Edge Image Builder

    • Linux以外の環境でこれらの手順に従ってイメージをビルドしている場合、おそらく仮想マシン経由で`Podman`を実行しています。デフォルトでは、この仮想マシンには少量のシステムリソースしか割り当てられないように構成されており、RPM解決プロセスなどのリソースを大量に消費する操作中に`Edge Image Builder`が不安定になる可能性があります。Podman Desktop（設定の歯車アイコン→、Podmanマシンの編集アイコン）を使用するか、podman-machine-set コマンドを使用して直接、podmanマシンのリソースを調整する必要があります。

  • 28 Elemental

    • RKE2またはK3sを使用する場合、管理クラスターからのサービス（このコンテキストではRancher）はデフォルトでは公開されないため、公開する必要があります。 RKE2とK3sの両方にTraefik Ingressコントローラーがあります。 現在のワークフローでは、サービスをアナウンスするためにMetalLB（L2またはBGPアドバタイズメント経由）を使用し、それぞれのIngressコントローラーを使用して`HelmChartConfig`経由でIngressを作成することが推奨されています。新しいIngressオブジェクトを作成すると、既存のセットアップが上書きされるためです。

27 Edge Image Builder

 

27.1 Common(通常のネットワーキング)

 

  • Linux以外の環境でこれらの手順に従ってイメージをビルドしている場合、おそらく仮想マシン経由で`Podman`を実行しています。デフォルトでは、この仮想マシンには少量のシステムリソースしか割り当てられないように構成されており、RPM解決プロセスなどのリソースを大量に消費する操作中に`Edge Image Builder`が不安定になる可能性があります。Podman Desktop（設定の歯車アイコン→、Podmanマシンの編集アイコン）を使用するか、podman-machine-set コマンドを使用して直接、podmanマシンのリソースを調整する必要があります。

  • 現時点では、`Edge Image Builder`はクロスアーキテクチャ設定でイメージをビルドできません。つまり、以下で実行する必要があります。

    • SL Micro AArch64イメージをビルドするための`aarch64`システム（Apple Siliconなど）

    • SL Micro AMD64/Intel 64イメージをビルドするための`x86_64`システム。

27.2 SUSE Linux Micro

 

  • 起動時にカーネルモジュールをロードするには、対応する`/etc/modprobe.d/module.conf`ファイルを使用します。Edge Image Builderを使用して、対応する`os-files`フォルダーを作成します。

.
├── definition.yaml
└── os-files
    └── etc
        └── modprobe.d
            └── module.conf

詳細については、 SUSE Linux Enterprise Serverドキュメントの「カーネルモジュールの管理」セクションを参照してください。

27.3 Kubernetes

 

  • マルチノードのKubernetesクラスターを作成するには、定義ファイルの`kubernetes`セクションを次のように調整する必要があります。

    • `kubernetes.nodes`の下にすべてのサーバーノードとエージェントノードをリストする

    • `kubernetes.network.apiVIP`の下で、すべての非イニシャライザーノードがクラスターに参加するために使用する仮想IPアドレスを設定する

    • オプションで、`kubernetes.network.apiHost`の下でクラスターにアクセスするためのドメインアドレスを指定するAPIホストを設定する。この設定の詳細については、 Kubernetesセクションのドキュメントを参照してください。

  • Edge Image Builder`は、各ノードのホスト名を使用して、そのKubernetesタイプ（`server`または`agent）を判別します。この構成は定義ファイルで管理されますが、マシンの一般的なネットワーク設定には、第9章 「エッジネットワーキング」で説明されているDHCP構成のいずれかを利用できます。

28 Elemental

 

28.1 Common(通常のネットワーキング)

 

28.1.1 Rancherサービスを公開する

 

RKE2またはK3sを使用する場合、管理クラスターからのサービス（このコンテキストではRancher）はデフォルトでは公開されないため、公開する必要があります。 RKE2とK3sの両方にTraefik Ingressコントローラーがあります。 現在のワークフローでは、サービスをアナウンスするためにMetalLB（L2またはBGPアドバタイズメント経由）を使用し、それぞれのIngressコントローラーを使用して`HelmChartConfig`経由でIngressを作成することが推奨されています。新しいIngressオブジェクトを作成すると、既存のセットアップが上書きされるためです。

  1. Rancher Primeを（Helm経由で）インストールし、必要な値を構成します

    hostname: rancher-192.168.64.101.sslip.io
replicas: 1
bootstrapPassword: Admin
global.cattle.psp.enabled: "false"
    ヒント
    ヒント

    詳細については、 Rancherインストールドキュメントに従ってください。

  2. Rancherを公開するためにLoadBalancerサービスを作成します

    kubectl apply -f - <<EOF
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ingressClass:
      isDefaultClass: true
    ports:
      web:
        hostPort: null    # disallow hostPort
        exposedPort: 80
      websecure:
        hostPort: null    # disallow hostPort
        exposedPort: 443
    service:
      enabled: true
      type: LoadBalancer
      spec:
        externalTrafficPolicy: Local
        allocateLoadBalancerNodePorts: false  # k8s GA from 1.24; supported by MetalLB
EOF

  3. Helmの値で以前セットアップしたIPアドレスを使用して、サービス用のIPアドレスプールを作成します。

    kubectl apply -f - <<EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ingress-ippool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.64.101/32
  serviceAllocation:
    priority: 100
    serviceSelectors:
    - matchExpressions:
      - {key: app.kubernetes.io/name, operator: In, values: [rke2-traefik]}
EOF

  4. IPアドレスプール用のL2アドバタイズメントを作成します。

    kubectl apply -f - <<EOF
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: ingress-l2-adv
  namespace: metallb-system
spec:
  ipAddressPools:
  - ingress-ippool
EOF

  5. Elementalが正しくインストールされていることを確認します。

    1. 管理ノードにElementalオペレーターとElemental UIをインストールします。

    2. ダウンストリームノードにElemental設定と登録コードを追加します。これにより、Edge Image Builderがそのマシンにリモート登録オプションを含めるようになります。

ヒント
ヒント

詳細情報や例については、[install-elemental]および[configure-elemental]を確認してください。

28.2 ハードウェア固有

 

28.2.1 Trusted Platform Module

 

Trusted Platform Module（TPM）構成を適切に処理する必要があります。 そうしないと、以下のようなエラーが発生します。

Nov 25 18:17:06 eled elemental-register[4038]: Error: registering machine: cannot generate authentication token: opening tpm for getting attestation data: TPM device not available

これは、次のいずれかのアプローチで軽減できます。

  • 仮想マシンの設定でTPMを有効にする

MacOSでUTMを使用した例

TPM

  • `MachineRegistration`リソースでTPMシードに負の値を指定してTPMをエミュレートします

apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  name: ...
  namespace: ...
spec:
    ...
    elemental:
      ...
      registration:
        emulate-tpm: true
        emulated-tpm-seed: -1

  • `MachineRegistration`リソースでTPMを無効にします

apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  name: ...
  namespace: ...
spec:
    ...
    elemental:
      ...
      registration:
        emulate-tpm: false

パート V サードパーティの統合

 

サードパーティ製ツールの統合方法

  • 29 NATS

    • NATSは、ますますハイパーコネクテッド化が進む世界のために構築された接続技術です。これは、クラウドベンダー、オンプレミス、エッジ、Web、モバイルデバイスのあらゆる組み合わせにおいて、アプリケーションが安全に通信できるようにする単一の技術です。NATSは、緊密に統合されながらも、簡単かつ独立してデプロイできるオープンソース製品群で構成されています。NATSは、マイクロサービス、エッジコンピューティング、モバイル、IoTなどのユースケースにわたり、世界中の何千もの企業で使用されており、従来のメッセージングを拡張または置き換えるために使用できます。

  • 30 SUSE Linux Micro上のNVIDIA GPU群

    • 本ガイドでは、SUSE Linux Micro 6.2上で、ビルド済みの オープンソースドライバーを使用してホストレベルのNVIDIA GPUサポートを実装する方法を説明します。これらは、NVIDIAの GPU Operatorによって動的にロードされるのではなく、オペレーティングシステムに組み込まれているドライバーです。この構成は、デプロイに必要なすべてのアーティファクトをイメージに事前に組み込みたい場合や、Kubernetesを介してユーザーがドライバーのバージョンを選択するような動的なドライバーバージョンの選択が要件ではない場合に非常に適しています。本ガイドでは、まずすでにデプロイ済みの…

29 NATS

 

NATSは、ますますハイパーコネクテッド化が進む世界のために構築された接続技術です。これは、クラウドベンダー、オンプレミス、エッジ、Web、モバイルデバイスのあらゆる組み合わせにおいて、アプリケーションが安全に通信できるようにする単一の技術です。NATSは、緊密に統合されながらも、簡単かつ独立してデプロイできるオープンソース製品群で構成されています。NATSは、マイクロサービス、エッジコンピューティング、モバイル、IoTなどのユースケースにわたり、世界中の何千もの企業で使用されており、従来のメッセージングを拡張または置き換えるために使用できます。

29.1 アーキテクチャ

 

NATSは、メッセージの形式でアプリケーション間のデータ交換を可能にするインフラストラクチャです。

29.1.1 NATSクライアントアプリケーション

 

NATSクライアントライブラリを使用すると、アプリケーションは異なるインスタンス間でパブリッシュ、サブスクライブ、リクエスト、およびリプライを行うことができます。 これらのアプリケーションは、一般的に`client applications`と呼ばれます。

29.1.2 NATSサービスインフラストラクチャ

 

NATSサービスは、相互に接続し、NATSサービスインフラストラクチャを提供するように構成された1つ以上のNATSサーバープロセスによって提供されます。NATSサービスインフラストラクチャは、エンドデバイス上で実行される単一のNATSサーバープロセスから、すべての主要なクラウドプロバイダーと世界のすべての地域にまたがる多数のクラスターからなるパブリックなグローバルスーパー・クラスターまで拡張可能です。

29.1.3 シンプルなメッセージング設計

 

NATSを使用すると、アプリケーションはメッセージを送受信することで簡単に通信できます。これらのメッセージはサブジェクト文字列によって宛先指定および識別され、ネットワークの場所に依存しません。 データはメッセージとしてエンコードおよびフレーム化され、パブリッシャーによって送信されます。メッセージは、1つ以上のサブスクライバーによって受信、デコード、および処理されます。

29.1.4 NATS JetStream

 

NATSには、JetStreamと呼ばれるビルトインの分散永続化システムがあります。 JetStreamは、今日のテクノロジーにおけるストリーミングの課題である複雑さ、脆弱性、スケーラビリティの欠如を解決するために作成されました。JetStreamは、パブリッシャーとサブスクライバーの結合に関する問題も解決します（メッセージがパブリッシュされたときに、サブスクライバーがメッセージを受信するために稼働している必要があります）。 NATS JetStreamに関する詳細情報は こちらをご覧ください。

29.2 インストール

 

29.2.1 K3s上へのNATSのインストール

 

NATSは複数のアーキテクチャ向けに構築されているため、K3s (第11章 「K3s」)に簡単にインストールできます。

NATSのデフォルト値を上書きするための値ファイルを作成しましょう。

cat > values.yaml <<EOF
cluster:
  # Enable the HA setup of the NATS
  enabled: true
  replicas: 3

nats:
  jetstream:
    # Enable JetStream
    enabled: true

    memStorage:
      enabled: true
      size: 2Gi

    fileStorage:
      enabled: true
      size: 1Gi
      storageDirectory: /data/
EOF

それでは、Helmを使用してNATSをインストールしましょう：

helm repo add nats https://nats-io.github.io/k8s/helm/charts/
helm install nats nats/nats --namespace nats --values values.yaml \
 --create-namespace

上記の`values.yaml`ファイルを使用すると、次のコンポーネントが`nats`ネームスペースに配置されます：

  1. 3つのコンテナを含むNATSステートフルセットのHAバージョン：NATSサーバー + 設定リローダーおよびメトリクスサイドカー。

  2. セットアップの検証に使用できる`NATS`ユーティリティのセットが付属しているNATSボックスコンテナ。

  3. JetStreamは、ポッドにバインドされた`PVCs`が付属するキー・バリュー・バックエンドも活用します。

29.2.1.1 セットアップをテストする

 
kubectl exec -n nats -it deployment/nats-box -- /bin/sh -l

  1. テストサブジェクトのサブスクリプションを作成します：

    nats sub test &

  2. テストサブジェクトにメッセージを送信します：

    nats pub test hi

29.2.1.2 クリーンアップ

 
helm -n nats uninstall nats
rm values.yaml

29.2.2 K3sのバックエンドとしてのNATS

 

K3sが活用するコンポーネントの1つに KINEがあります。これは、本来リレーショナルデータベースを対象とした代替ストレージバックエンドでetcdを置き換えることを可能にするシムです。 JetStreamはキー・バリューAPIを提供するため、NATSをK3sクラスターのバックエンドにすることが可能です。

K3sにビルトインされたNATSを簡単にするPRはすでにマージされていますが、その変更はまだK3sのリリースに 含まれていません。

このため、K3sバイナリは手動でビルドする必要があります。

29.2.2.1 K3sのビルド

 
git clone --depth 1 https://github.com/k3s-io/k3s.git && cd k3s

次のコマンドは、K3sでNATSのビルトイン機能を有効にするために、ビルドタグに`nats`を追加します。

sed -i '' 's/TAGS="ctrd/TAGS="nats ctrd/g' scripts/build
make local

<node-ip> を、K3sを起動するノードの実際のIPアドレスに置き換えてください。

export NODE_IP=<node-ip>
sudo scp dist/artifacts/k3s-arm64 ${NODE_IP}:/usr/local/bin/k3s
注記
注記

K3sをローカルでビルドするには、buildx Docker CLIプラグインが必要です。 $ make local が失敗した場合は、 手動でインストール できます。

29.2.2.2 NATS CLIのインストール

 
TMPDIR=$(mktemp -d)
nats_version="nats-0.0.35-linux-arm64"
curl -o "${TMPDIR}/nats.zip" -sfL https://github.com/nats-io/natscli/releases/download/v0.0.35/${nats_version}.zip
unzip "${TMPDIR}/nats.zip" -d "${TMPDIR}"

sudo scp ${TMPDIR}/${nats_version}/nats ${NODE_IP}:/usr/local/bin/nats
rm -rf ${TMPDIR}

29.2.2.3 K3sバックエンドとしてのNATSの実行

 

ノード上で ssh し、nats を指す --datastore-endpoint フラグを指定してK3sを実行します。

注記
注記

以下のコマンドはK3sをフォアグラウンドプロセスとして起動するため、ログを簡単に追跡して問題がないか確認できます。 現在のターミナルをブロックしないように、コマンドの前に & フラグを追加してバックグラウンドプロセスとして開始できます。

k3s server  --datastore-endpoint=nats://
注記
注記

NATSバックエンドを備えたK3sサーバーを slemicro VM上で永続的にするには、以下のスクリプトを実行します。これにより、必要な設定を含む systemd サービスが作成されます。

export INSTALL_K3S_SKIP_START=false
export INSTALL_K3S_SKIP_DOWNLOAD=true

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
 --datastore-endpoint=nats://"  sh -

29.2.2.4 トラブルシューティング

 

以下のコマンドをノード上で実行し、ストリームに関するすべてが正常に機能していることを確認できます。

nats str report -a
nats str view -a

30 SUSE Linux Micro上のNVIDIA GPU群

 

30.1 概要

 

本ガイドでは、SUSE Linux Micro 6.2上で、ビルド済みの オープンソースドライバーを使用してホストレベルのNVIDIA GPUサポートを実装する方法を説明します。これらは、NVIDIAの GPU Operatorによって動的にロードされるのではなく、オペレーティングシステムに組み込まれているドライバーです。この構成は、デプロイに必要なすべてのアーティファクトをイメージに事前に組み込みたい場合や、Kubernetesを介してユーザーがドライバーのバージョンを選択するような動的なドライバーバージョンの選択が要件ではない場合に非常に適しています。本ガイドでは、まずすでにデプロイ済みのシステムに追加コンポーネントをデプロイする方法を説明し、続いてEdge Image Builderを使用してこの構成を初期デプロイに組み込む方法を説明するセクションを設けています。基本的な手順や手動でのセットアップをスキップしたい場合は、そのセクションに直接進んでください。

これらのドライバーのサポートは、SUSEとNVIDIAの緊密な協力体制のもとで提供されており、ドライバーはSUSEによってパッケージリポジトリの一部としてビルドおよび提供されている点に留意することが重要です。ただし、ドライバーの使用方法や組み合わせについて懸念や質問がある場合は、SUSEまたはNVIDIAのアカウントマネージャーに問い合わせてサポートを受けてください。 NVIDIA AI Enterprise (NVAIE) を使用する予定がある場合は、 NVAIE認定GPUを使用していることを確認してください。これには_場合によっては_、NVIDIA独自のドライバーの使用が必要になることがあります。不明な点がある場合は、NVIDIAの担当者に相談してください。

NVIDIA GPU Operatorの統合に関する詳細情報は、本ガイドでは_取り扱っていません_。Kubernetes向けのNVIDIA GPU Operatorの統合についてはここでは取り上げませんが、本ガイドのほとんどの手順に従って基盤となるオペレーティングシステムをセットアップし、NVIDIA GPU Operator Helmチャートの`driver.enabled=false`フラグを使用して_プリインストール済み_のドライバーを有効にするだけで、ホストにインストールされているドライバーをそのまま使用できます。より包括的な手順については、NVIDIAの こちらを参照してください。

30.2 前提条件

 

本ガイドでは、以下の環境がすでに用意されていることを前提としています。

  • SUSE Linux Micro 6.2がインストールされたホストが少なくとも1台（物理または仮想）。

  • ホストがサブスクリプションに登録されていること（パッケージへのアクセスに必要です）。評価版は こちらから入手できます。

  • 互換性のあるNVIDIA GPUがインストールされていること（または、SUSE Linux Microが実行されている仮想マシンに_完全に_パススルーされていること）。

  • ルートユーザへのアクセス権があること。これらの手順は、ユーザがルートユーザであり、`sudo`を使用して権限を_昇格させていない_ことを前提としています。

30.3 手動インストール

 

本セクションでは、NVIDIAオープンソースドライバーがSUSE Linux Microのコアパッケージリポジトリに含まれるようになったため、必要なRPMパッケージをインストールするのと同じくらい簡単に、NVIDIAドライバーをSUSE Linux Microオペレーティングシステムに直接インストールする方法を説明します。実行可能パッケージのコンパイルやダウンロードは不要です。以下では、最新のGPUをサポートする「G06」世代のドライバの展開手順を説明します（詳細については こちらを参照してください）。お使いのシステムのNVIDIA GPUに適したドライバ世代を選択してください。最新のGPUの場合、「G06」ドライバが最も一般的な選択肢です。

作業を始める前に、SUSEがSUSE Linux Microの一部として提供するNVIDIAオープンソースドライバ以外に、セットアップのために追加のNVIDIAコンポーネントが必要になる場合があることを理解しておくことが重要です。これには、OpenGLライブラリ、CUDAツールキット、`nvidia-smi`などのコマンドラインユーティリティ、`nvidia-container-toolkit`などのコンテナ統合コンポーネントが含まれる場合があります。これらのコンポーネントの多くは、NVIDIAのプロプライエタリ（独自）ソフトウェアであるか、NVIDIAではなくSUSEが提供する意味がないため、SUSEからは提供されていません。そのため、手順の一環として、これらのコンポーネントにアクセスできるように追加のリポジトリを設定し、これらのツールの使用方法の例をいくつか説明して、完全に機能するシステムを構築します。SUSEリポジトリとNVIDIAリポジトリを区別することが重要です。NVIDIAが提供するパッケージバージョンとSUSEがビルドしたパッケージバージョンの間で不一致が生じることがあるためです。これは通常、SUSEが新しいバージョンのオープンソースドライバーを公開した際に、それに対応するパッケージがNVIDIAのリポジトリで利用可能になるまでに数日かかる場合に発生します。

選択するドライバーのバージョンがGPUと互換性があり、CUDA要件を満たしていることを、以下を確認して確かめることをお勧めします。

  • CUDAリリースノート

  • 展開しようとしているドライバーのバージョンがhttps://download.nvidia.com/suse/sle15sp6/x86_64/[NVIDIAリポジトリ]内の対応するバージョンと一致していること、およびサポートコンポーネントのパッケージバージョンが同等であることを確認してください。

ヒント
ヒント

NVIDIAオープンソースドライバーのバージョンを確認するには、ターゲットマシンで`zypper se -s nvidia-open-driver`を実行するか、https://scc.suse.com/packages?name=SUSE%20Linux%20Micro&version=6.2&arch=x86_64[SUSE Linux Micro 6.2 for AMD64/Intel 64]で「nvidia-open-driver」を検索するために_SUSEカスタマセンター_を利用してください。

SUSEカスタマセンター

NVIDIAリポジトリで同等のバージョンが利用可能であることを確認したら、ホストオペレーティングシステムにパッケージをインストールする準備が整います。そのためには、`transactional-update`セッションを開く必要があります。これにより、基盤となるオペレーティングシステムの新しい読み取り/書き込みスナップショットが作成され、イミュータブル（変更不可）なプラットフォームに変更を加えることができます（`transactional-update`の詳細については、https://documentation.suse.com/sle-micro/6.2/html/Micro-transactional-updates/index.html[こちら]を参照してください）。

transactional-update shell

`transactional-update`シェルに入ったら、NVIDIAから追加のパッケージリポジトリを追加します。これにより、例えば`nvidia-smi`などの追加ユーティリティを取り込むことができます。

zypper ar https://download.nvidia.com/suse/sle15sp6/ nvidia-suse-main
zypper --gpg-auto-import-keys refresh

その後、ドライバーと追加ユーティリティ用の`nvidia-compute-utils`をインストールできます。ユーティリティが不要な場合は省略できますが、テスト目的であれば、この段階でインストールしておく価値があります。

zypper install -y --auto-agree-with-licenses nvidia-open-driver-G06-signed-kmp nvidia-compute-utils-G06
注記
注記

インストールが失敗する場合、選択したドライバーバージョンとNVIDIAがリポジトリで提供しているものとの間で依存関係の不一致が発生している可能性があります。前のセクションを参照して、バージョンが一致していることを確認してください。別のドライバーバージョンのインストールを試みてください。例えば、NVIDIAリポジトリに以前のバージョンがある場合は、インストールコマンドで`nvidia-open-driver-G06-signed-kmp=550.54.14`を指定して、一致するバージョンを指定してみてください。

次に、サポートされているGPUを使用していない場合（リストは こちらにあることを覚えておいてください）、モジュールレベルでサポートを有効にすることでドライバーが機能するかどうかを確認できますが、結果は環境によって異なる場合があります。_サポートされている_GPUを使用している場合は、このステップをスキップしてください。

sed -i '/NVreg_OpenRmEnableUnsupportedGpus/s/^#//g' /etc/modprobe.d/50-nvidia-default.conf

これらのパッケージをインストールしたので、`transactional-update`セッションを終了する時です。

exit
注記
注記

続行する前に、`transactional-update`セッションを終了したことを確認してください。

ドライバーをインストールしたので、再起動する時です。SUSE Linux Microはイミュータブルなオペレーティングシステムであるため、前のステップで作成した新しいスナップショットに再起動する必要があります。ドライバーはこの新しいスナップショットにのみインストールされるため、自動的に行われるこの新しいスナップショットへの再起動なしにドライバーを読み込むことはできません。準備ができたら、reboot コマンドを実行してください。

reboot

システムが正常に再起動したら、再度ログインし、`nvidia-smi`ツールを使用して、ドライバーが正常に読み込まれ、GPUへのアクセスと列挙の両方が可能であることを確認してください。

nvidia-smi

このコマンドの出力には、以下の出力と同様の内容が表示されるはずです。なお、以下の例では2つのGPUを使用しています。

+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.29.06              Driver Version: 545.29.06    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB          Off | 00000000:17:00.0 Off |                    0 |
| N/A   29C    P0              35W / 250W |      4MiB / 40960MiB |      0%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB          Off | 00000000:CA:00.0 Off |                    0 |
| N/A   30C    P0              33W / 250W |      4MiB / 40960MiB |      0%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+

これで、SUSE Linux MicroシステムへのNVIDIAドライバーのインストールと検証プロセスは完了です。

30.4 手動インストールのさらなる検証

 

この段階で検証できたのは、ホストレベルでNVIDIAデバイスにアクセスでき、ドライバーが正常に読み込まれているということだけです。しかし、それが機能していることを確認したい場合、簡単なテストとして、GPUがユーザスペースアプリケーションから（理想的にはコンテナ経由で、そして実際のワークロードで通常使用されるCUDAライブラリを通じて）命令を受け取れることを検証するのがよいでしょう。そのためには、nvidia-container-toolkit(NVIDIA Container Toolkit)をインストールすることで、ホストOSにさらなる変更を加えることができます。まず、別の`transactional-update`シェルを開きます。なお、これは前のステップで単一のトランザクションとして実行することも可能でした。完全に自動化する方法については後のセクションで説明します。

transactional-update shell

次に、NVIDIA Container Toolkitリポジトリから`nvidia-container-toolkit`パッケージをインストールします。

  • 以下の`nvidia-container-toolkit.repo`には、安定版 (nvidia-container-toolkit) と実験版 (nvidia-container-toolkit-experimental) のリポジトリが含まれています。安定版リポジトリは、本番環境での使用が推奨されます。実験版リポジトリは、デフォルトで無効になっています。

zypper ar https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
zypper --gpg-auto-import-keys install -y nvidia-container-toolkit

準備ができたら、`transactional-update`シェルを終了できます。

exit

…​そして、マシンを再起動して新しいスナップショットに切り替えます。

reboot
注記
注記

前述のとおり、変更を有効にするには、`transactional-shell`から終了したことを確認し、マシンを再起動する必要があります。

マシンを再起動したら、システムがNVIDIA Container Toolkitを使用してデバイスを正常に列挙できることを確認できます。出力は冗長になり、INFOおよびWARNメッセージが表示されますが、ERRORメッセージは表示されないはずです。

nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

これにより、マシン上で起動されたすべてのコンテナが、検出されたNVIDIA GPUデバイスを使用できるようになります。準備ができたら、podmanベースのコンテナを実行できます。podman`を介してこれを行うことは、コンテナ内からNVIDIAデバイスへのアクセスを検証する優れた方法であり、後の段階でKubernetesを使用して同じことを行うための確信につながります。https://registry.suse.com/repositories/bci-bci-base-16-0[SLE BCI] に基づき、前のコマンドで処理されたラベル付きNVIDIAデバイスへのアクセス権を `podman に付与し、単にBashコマンドを実行します。

podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable -it registry.suse.com/bci/bci-base:latest bash

これで、一時的なpodmanコンテナ内からコマンドが実行されます。これは基盤となるシステムへのアクセス権を持たず、一時的なものであるため、ここで行うことは永続化されず、基盤となるホスト上の何かを壊すことはできないはずです。コンテナ内にいるため、必要なCUDAライブラリをインストールできます。その際、ドライバー こちら に適したCUDAバージョンを再度確認してください。ただし、nvidia-smi の以前の出力に、必要なCUDAバージョンが表示されているはずです。以下の例では、CUDA 12.3 をインストールし、GPUを完全に検証できるように多くのサンプル、デモ、開発キットをプルしています。

zypper ar https://developer.download.nvidia.com/compute/cuda/repos/sles15/x86_64/ cuda-suse
zypper in -y cuda-libraries-devel-12-3 cuda-minimal-build-12-3 cuda-demo-suite-12-3

これが正常にインストールされたら、コンテナを終了しないでください。deviceQuery CUDAサンプルを実行します。これはCUDAを介したGPUアクセスを包括的に検証するもので、コンテナ自体の中から実行します。

/usr/local/cuda-12/extras/demo_suite/deviceQuery

成功した場合、以下のような出力が表示されるはずです。コマンドの最後にある`Result = PASS`メッセージに注意してください。また、以下の出力ではシステムが2つのGPUを正しく識別していますが、お客様の環境には1つしかない場合があることにも注意してください。

/usr/local/cuda-12/extras/demo_suite/deviceQuery Starting...

 CUDA Device Query (Runtime API) version (CUDART static linking)

Detected 2 CUDA Capable device(s)

Device 0: "NVIDIA A100-PCIE-40GB"
  CUDA Driver Version / Runtime Version          12.2 / 12.1
  CUDA Capability Major/Minor version number:    8.0
  Total amount of global memory:                 40339 MBytes (42298834944 bytes)
  (108) Multiprocessors, ( 64) CUDA Cores/MP:     6912 CUDA Cores
  GPU Max Clock rate:                            1410 MHz (1.41 GHz)
  Memory Clock rate:                             1215 Mhz
  Memory Bus Width:                              5120-bit
  L2 Cache Size:                                 41943040 bytes
  Maximum Texture Dimension Size (x,y,z)         1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384)
  Maximum Layered 1D Texture Size, (num) layers  1D=(32768), 2048 layers
  Maximum Layered 2D Texture Size, (num) layers  2D=(32768, 32768), 2048 layers
  Total amount of constant memory:               65536 bytes
  Total amount of shared memory per block:       49152 bytes
  Total number of registers available per block: 65536
  Warp size:                                     32
  Maximum number of threads per multiprocessor:  2048
  Maximum number of threads per block:           1024
  Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
  Max dimension size of a grid size    (x,y,z): (2147483647, 65535, 65535)
  Maximum memory pitch:                          2147483647 bytes
  Texture alignment:                             512 bytes
  Concurrent copy and kernel execution:          Yes with 3 copy engine(s)
  Run time limit on kernels:                     No
  Integrated GPU sharing Host Memory:            No
  Support host page-locked memory mapping:       Yes
  Alignment requirement for Surfaces:            Yes
  Device has ECC support:                        Enabled
  Device supports Unified Addressing (UVA):      Yes
  Device supports Compute Preemption:            Yes
  Supports Cooperative Kernel Launch:            Yes
  Supports MultiDevice Co-op Kernel Launch:      Yes
  Device PCI Domain ID / Bus ID / location ID:   0 / 23 / 0
  Compute Mode:
     < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >

Device 1: <snip to reduce output for multiple devices>
     < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >
> Peer access from NVIDIA A100-PCIE-40GB (GPU0) -> NVIDIA A100-PCIE-40GB (GPU1) : Yes
> Peer access from NVIDIA A100-PCIE-40GB (GPU1) -> NVIDIA A100-PCIE-40GB (GPU0) : Yes

deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 12.3, CUDA Runtime Version = 12.3, NumDevs = 2, Device0 = NVIDIA A100-PCIE-40GB, Device1 = NVIDIA A100-PCIE-40GB
Result = PASS

ここから、他のCUDAワークロードの実行を継続できます。コンパイラやCUDAエコシステムの他の側面を使用して、さらなるテストを実行してください。完了したらコンテナから終了することができますが、コンテナ内にインストールしたものはすべて一時的なものであり（失われます！）、基盤となるオペレーティングシステムには影響を与えていないことに注意してください。

exit

30.5 Kubernetesによる実装

 

SUSE Linux MicroでのNVIDIAオープンソースドライバーのインストールと使用が確認できましたので、同じマシン上でKubernetesを構成する方法を見ていきましょう。このガイドではKubernetesのデプロイ手順については説明しませんが、 K3sまたは RKE2がインストールされており、標準の`kubectl`コマンドをスーパーユーザとして実行できるようにkubeconfigが適切に構成されていることを前提としています。ここではノードがシングルノードクラスターを形成していると想定していますが、コア手順はマルチノードクラスターでも同様です。まず、`kubectl`アクセスが機能していることを確認してください。

kubectl get nodes

以下のような内容が表示されるはずです。

NAME       STATUS   ROLES                       AGE   VERSION
node0001   Ready    control-plane,etcd,master   13d   v1.35.4+rke2r1

確認できるのは、k3s/rke2のインストールがホスト上のNVIDIA Container Toolkitを検出し、containerd（k3s/rke2が使用するコンテナランタイムインターフェース）へのNVIDIAランタイム統合を自動構成したということです。containerdの`config.toml`ファイルを確認して、これを確定します。

tail -n8 /var/lib/rancher/rke2/agent/etc/containerd/config.toml

以下のような内容が表示されるはずです。K3sの対応する場所は`/var/lib/rancher/k3s/agent/etc/containerd/config.toml`です。

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia"]
  runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia".options]
  BinaryName = "/usr/bin/nvidia-container-runtime"
注記
注記

これらのエントリが存在しない場合、検出に失敗した可能性があります。これは、マシンまたはKubernetesサービスが再起動されていないことが原因である可能性があります。必要に応じて、上記のように手動でこれらを追加してください。

次に、NVIDIA `RuntimeClass`をデフォルトに追加するKubernetesランタイムとして構成する必要があります。これにより、GPUへのアクセスを必要とするポッドに対するユーザーからのリクエストが、`containerd`構成で設定された`nvidia-container-runtime`を介して、NVIDIA Container Toolkitを使用して実行できるようになります。

kubectl apply -f - <<EOF
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: nvidia
handler: nvidia
EOF

次のステップは、 NVIDIA Device Pluginを構成することです。これにより、NVIDIA Container Toolkitと連携して、クラスター内で使用可能なリソースとしてNVIDIA GPUを活用するようにKubernetesが構成されます。このツールは、最初にGPU、ドライバー、その他の機能（GLなど）を含む基盤となるホスト上のすべての機能を検出し、GPUリソースを要求してアプリケーションの一部としてそれらを使用できるようにします。

まず、NVIDIA Device Plugin用のHelmリポジトリを追加および更新する必要があります。

helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
helm repo update

これで、NVIDIA Device Pluginをインストールできます。

helm upgrade -i nvdp nvdp/nvidia-device-plugin --namespace nvidia-device-plugin --create-namespace --version 0.14.5 --set runtimeClassName=nvidia

数分後、利用可能なノードで検出を完了し、検出されたGPUの数でノードにタグを付ける新しいポッドが実行されます。

kubectl get pods -n nvidia-device-plugin
NAME                              READY   STATUS    RESTARTS      AGE
nvdp-nvidia-device-plugin-jp697   1/1     Running   2 (12h ago)   6d3h

kubectl get node node0001 -o json | jq .status.capacity
{
  "cpu": "128",
  "ephemeral-storage": "466889732Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "32545636Ki",
  "nvidia.com/gpu": "1",                      <----
  "pods": "110"
}

これで、このGPUを使用しようとするNVIDIAポッドを作成する準備が整いました。CUDA Benchmarkコンテナで試してみましょう。

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nbody-gpu-benchmark
  namespace: default
spec:
  restartPolicy: OnFailure
  runtimeClassName: nvidia
  containers:
  - name: cuda-container
    image: nvcr.io/nvidia/k8s/cuda-sample:nbody
    args: ["nbody", "-gpu", "-benchmark"]
    resources:
      limits:
        nvidia.com/gpu: 1
    env:
    - name: NVIDIA_VISIBLE_DEVICES
      value: all
    - name: NVIDIA_DRIVER_CAPABILITIES
      value: all
EOF

すべてが順調に進めば、ログを確認してベンチマーク情報を確認できます。

kubectl logs nbody-gpu-benchmark
Run "nbody -benchmark [-numbodies=<numBodies>]" to measure performance.
    -fullscreen       (run n-body simulation in fullscreen mode)
    -fp64             (use double precision floating point values for simulation)
    -hostmem          (stores simulation data in host memory)
    -benchmark        (run benchmark to measure performance)
    -numbodies=<N>    (number of bodies (>= 1) to run in simulation)
    -device=<d>       (where d=0,1,2.... for the CUDA device to use)
    -numdevices=<i>   (where i=(number of CUDA devices > 0) to use for simulation)
    -compare          (compares simulation results running once on the default GPU and once on the CPU)
    -cpu              (run n-body simulation on the CPU)
    -tipsy=<file.bin> (load a tipsy model file for simulation)

NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

> Windowed mode
> Simulation data stored in video memory
> Single precision floating point simulation
> 1 Devices used for simulation
GPU Device 0: "Turing" with compute capability 7.5

> Compute 7.5 CUDA device: [Tesla T4]
40960 bodies, total time for 10 iterations: 101.677 ms
= 165.005 billion interactions per second
= 3300.103 single-precision GFLOP/s at 20 flops per interaction

最後に、アプリケーションでOpenGLが必要な場合は、ホストレベルで必要なNVIDIA OpenGLライブラリをインストールできます。NVIDIA Device PluginとNVIDIA Container Toolkitを使用すれば、それらをコンテナで利用可能にできます。これを行うには、次のようにパッケージをインストールします。

transactional-update pkg install nvidia-gl-G06
注記
注記

このパッケージをアプリケーションで利用できるようにするには、再起動が必要です。NVIDIA Device Pluginは、NVIDIA Container Toolkitを介してこれを自動的に再検出するはずです。

30.6 Edge Image Builderによる統合

 

さて、SUSE Linux Micro上でアプリケーションとGPUの全機能が実証できたので、次は第8章 「Edge Image Builder」を使用して、デプロイ可能/利用可能なISOまたはRAWディスクイメージとしてすべてをまとめて提供したいと考えます。このガイドではEdge Image Builderの使用方法は説明しませんが、そのようなイメージを構築するために必要な設定ファイルを提供します。以下に、必要なすべてのコンポーネントがすぐにデプロイされるようにするための、必要なKubernetes構成ファイルと併せたイメージ定義の例を示します。以下に示す例のEdge Image Builderディレクトリのディレクトリ構造は次のとおりです。

.
├── base-images
│   └── SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
├── eib-config-iso.yaml
├── kubernetes
│   ├── config
│   │   └── server.yaml
│   ├── helm
│   │   └── values
│   │       └── nvidia-device-plugin.yaml
│   └── manifests
│       └── nvidia-runtime-class.yaml
└── rpms
    └── gpg-keys
        └── nvidia-container-toolkit.key

これらのファイルを確認してみましょう。まず、ユーティリティとOpenGLパッケージもデプロイする、K3sを実行するシングルノードクラスター用のサンプルイメージ定義を以下に示します（eib-config-iso.yaml）。

apiVersion: 1.3
image:
  arch: x86_64
  imageType: iso
  baseImage: SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
  outputImageName: deployimage.iso
operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      pools:
        - 2.suse.pool.ntp.org
  isoConfiguration:
    installDevice: /dev/sda
  users:
    - username: root
      encryptedPassword: $6$XcQN1xkuQKjWEtQG$WbhV80rbveDLJDz1c93K5Ga9JDjt3mF.ZUnhYtsS7uE52FR8mmT8Cnii/JPeFk9jzQO6eapESYZesZHO9EslD1
  packages:
    packageList:
      - nvidia-open-driver-G06-signed-kmp-default
      - nvidia-compute-utils-G06
      - nvidia-gl-G06
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://download.nvidia.com/suse/sle15sp6/
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64
    sccRegistrationCode: [snip]
kubernetes:
  version: v1.35.4+k3s1
  helm:
    charts:
      - name: nvidia-device-plugin
        version: v0.14.5
        installationNamespace: kube-system
        targetNamespace: nvidia-device-plugin
        createNamespace: true
        valuesFile: nvidia-device-plugin.yaml
        repositoryName: nvidia
    repositories:
      - name: nvidia
        url: https://nvidia.github.io/k8s-device-plugin
注記
注記

これは単なる例です。要件や期待に合わせてカスタマイズする必要があるかもしれません。さらに、SUSE Linux Microを使用している場合は、パッケージの依存関係を解決し、NVIDIAドライバーをプルするために、独自の`sccRegistrationCode`を提供する必要があります。

これに加えて、起動時にKubernetesによって読み込まれるように、追加のコンポーネントを加える必要があります。EIBディレクトリには、まず`kubernetes`ディレクトリが必要であり、その中に設定、Helmチャートの値、および必要な追加マニフェスト用のサブディレクトリが必要です。

mkdir -p kubernetes/config kubernetes/helm/values kubernetes/manifests

次に、CNIを選択し（未選択の場合はデフォルトでCiliumが使用されます）、SELinuxを有効にすることで、（オプションの）Kubernetes構成をセットアップします。

cat << EOF > kubernetes/config/server.yaml
cni: cilium
ingress-controller: traefik
selinux: true
EOF

次に、NVIDIA RuntimeClassがKubernetesクラスター上に作成されていることを確認します。

cat << EOF > kubernetes/manifests/nvidia-runtime-class.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: nvidia
handler: nvidia
EOF

組み込みのHelmコントローラーを使用して、Kubernetes自体を通じてNVIDIA Device Pluginをデプロイします。 チャートのvaluesファイルにランタイムクラスを指定します。

cat << EOF > kubernetes/helm/values/nvidia-device-plugin.yaml
runtimeClassName: nvidia
EOF

先に進む前に、NVIDIA Container Toolkit RPMの公開鍵を取得する必要があります。

mkdir -p rpms/gpg-keys
curl -o rpms/gpg-keys/nvidia-container-toolkit.key https://nvidia.github.io/libnvidia-container/gpgkey

Kubernetesバイナリ、コンテナイメージ、Helmチャート（および参照されるすべてのイメージ）を含む必要なすべてのアーティファクトは自動的にエアギャップ化されます。つまり、デプロイ時のシステムは、デフォルトでインターネット接続を必要としません。あとは SUSEダウンロードページからSUSE Linux Micro ISOを取得し（`base-images`ディレクトリに配置します）、Edge Image Builderツールを呼び出してISOを生成するだけです。例を完了するために、イメージのビルドに使用されたコマンドを以下に示します。

podman run --rm --privileged -it -v /path/to/eib-files/:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file eib-config-iso.yaml

詳細な手順については、Edge Image Builderのhttps://github.com/suse-edge/edge-image-builder/blob/release-1.3/docs/building-images.md[ドキュメント]を参照してください。

30.7 問題の解決

 

30.7.1 nvidia-smiがGPUを検出しない

 

`dmesg`を使用してカーネルメッセージを確認します。これが`NvKMSKapDevice`を割り当てられないことを示している場合は、サポートされていないGPUの回避策を適用してください。

sed -i '/NVreg_OpenRmEnableUnsupportedGpus/s/^#//g' /etc/modprobe.d/50-nvidia-default.conf

注意:上記の手順でカーネルモジュールの設定を変更した場合、それを有効にするには、カーネルモジュールをリロードするか、再起動する必要があります。

パート VI Day 2運用

 

このセクションでは、管理者が管理クラスターおよびダウンストリームクラスターの両方で、さまざまな「Day 2」運用タスクを処理する方法について説明します。

  • 31 エッジ 3.6 移行

    • このセクションでは、management および downstream クラスタを SUSE Edge 3.5 から SUSE Edge 3.6.0 へマイグレーションする方法を説明します。

  • 32 管理クラスタ

    • 現在、management クラスターで「Day 2」操作を実行する方法は2つあります。

  • 33 ダウンストリームクラスタ群

    • このセクションでは、`downstream`クラスタの各部分において「Day 2」オペレーションを実行するための方法を説明します。

31 エッジ 3.6 移行

 

このセクションでは、management および downstream クラスタを SUSE Edge 3.5 から SUSE Edge 3.6.0 へマイグレーションする方法を説明します。

重要
重要

クラスタのマイグレーションは、必ず latest Z-stream の SUSE Edge 3.5 リリースから実行してください。

必ず SUSE Edge 3.6.0 リリースへマイグレーションしてください。マイグレーション後のアップグレードについては、管理 (第32章 「管理クラスタ」) を参照してください。 および ダウンストリーム (第33章 「ダウンストリームクラスタ群」) クラスタ セクション。

次の表に、さまざまな種類のクラスタとクラスタをアップグレードする方法を示します。

表 31.1: ダウンストリームクラスタの種類とアップグレード方法
 
クラスタのタイプメソッド

EIBでプロビジョニングされたクラスタ

詳細については31.1.3項 「Fleet」を参照してください。

Phone-homeでプロビジョニングされたクラスタ

Kubernetesバージョンのアップグレードについては Kubernetesバージョンのアップグレード を、SUC、オペレーティングシステム、その他のコンポーネントについては ダウンストリームクラスタ群 (第33章 「ダウンストリームクラスタ群」) を参照してください。

31.1 管理クラスタ

 

この章の構成は次のとおりです。

31.1.1項 「前提条件」 - マイグレーション開始前に完了すべき前提条件の手順。

31.1.2項 「Upgrade Controller」 - management を使用して 第19章 「Upgrade Controller」 クラスタマイグレーションを実行する方法。

31.1.3項 「Fleet」 - management を使用して 第6章 「Fleet」 クラスタマイグレーションを実行する方法。

31.1.1 前提条件

 

31.1.1.1 Metal3 CA証明書設定の移行

 
注記
注記

TLSを使用する外部メディアサーバーに対して追加の信頼済みCAを使用するMetal3デプロイメントにのみ適用されます。

Metal3 Helmチャートでは、信頼済みCA証明書の設定方法が変更されました。以前は、追加のCAは`tls-ca-additional`ブール値を持つシークレット（additionalTrustedCAs）を介して提供されていました。新しいバージョンでは、`global.trustedCAs`値によって参照される完全なCAバンドルを含むConfigMapが使用されます。

Metal3に対して追加の信頼済みCAを設定している場合は、シークレットベースのアプローチからConfigMapベースのアプローチに移行する必要があります。

  1. 既存のシークレットからCAバンドルを含むConfigMapを作成します。

    古いシークレットから証明書を抽出します。

    kubectl get secret tls-ca-additional -n metal3-system -o jsonpath='{.data}' | \
  jq -r 'to_entries[] | .value' | base64 -d > ca-bundle.pem

    オプション - システムCAバンドルを含める: Metal3のデプロイメントでパブリックCAも信頼する必要がある場合（HTTPS経由で外部リソースにアクセスする場合など）、カスタムCAに加えてシステムCAバンドルを含める必要があります。コンテナイメージからシステムCAバンドルを抽出し、カスタムCAの先頭に追加します。

    # Extract system CAs from a container image (using podman or docker)
podman run --rm registry.suse.com/bci/bci-base:latest cat /etc/ssl/certs/ca-certificates.crt > system-cas.pem

# Combine system CAs with your custom CAs
cat system-cas.pem ca-bundle.pem > combined-ca-bundle.pem
mv combined-ca-bundle.pem ca-bundle.pem
    重要
    重要

    システムCAバンドルを含める場合、それを最新の状態に保つ責任はユーザーにあります。コンテナイメージ内のシステムCAは、CA証明書の期限切れや失効に伴い、時間の経過とともに古くなる可能性があります。更新されたコンテナイメージからシステムCAバンドルを再抽出して、定期的に更新する必要があります。

    最終的なCAバンドルを使用してConfigMapを作成します。

    kubectl create configmap tls-ca-bundle -n metal3-system --from-file=ca-bundle.pem=ca-bundle.pem

  2. 新しいConfigMap参照を使用するようにMetal3 Helm値を更新します。

    変更前:

    global:
  additionalTrustedCAs: true

    宛先:

    global:
  trustedCAs: tls-ca-bundle

  3. 新しい構成でMetal3 Helmチャートをアップグレードした後、古いシークレットを削除できます。

    kubectl delete secret tls-ca-additional -n metal3-system

31.1.2 Upgrade Controller

 
重要
重要

Upgrade Controller`は現在、*非エアギャップ(された)管理*クラスターに対するSUSE Edge`リリース移行のみをサポートしています。

このセクションでは、以下のトピックについて説明します。

31.1.2.1項 「前提条件」 - `Upgrade Controller`に固有の前提条件。

31.1.2.2項 「移行手順」 - Upgrade Controller`を使用してmanagement`クラスターを新しい`SUSE Edge`バージョンに移行する手順。

31.1.2.1 前提条件

 
31.1.2.1.1 SUSE Edge 3.6 Upgrade Controller
 

Upgrade Controller`を使用する前に、目的のSUSE Edge`リリースへの移行が可能なバージョンで実行されていることを確認する必要があります。

これには次の操作を行います。

  1. 以前の`Upgrade Controller`リリースから`SUSE Edge`が既にデプロイされている場合は、そのチャートをアップグレードしてください。

    helm upgrade upgrade-controller -n upgrade-controller-system oci://registry.suse.com/edge/charts/upgrade-controller --version 306.0.4+up0.1.3

  2. `Upgrade Controller`がデプロイされて*いない*場合は、19.3項 「Upgrade Controllerのインストール」に従ってください。

31.1.2.2 移行手順

 

Upgrade Controller`を使用したmanagement`クラスターの移行は、基本的にアップグレードの実行と似ています。

唯一の違いは、UpgradePlan`で3.6.0`リリースバージョンを*指定する必要がある*点です。

apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  # Change to the namespace of your Upgrade Controller
  namespace: CHANGE_ME
spec:
  releaseVersion: 3.6.0

上記の`UpgradePlan`を使用して移行を行う方法については、Upgrade Controller アップグレード処理 (32.1項 「Upgrade Controller」)を参照してください。

31.1.3 Fleet

 
注記
注記

可能な限り、移行には31.1.2項 「Upgrade Controller」を使用してください。

`Upgrade Controller`でカバーされていないユースケースについてのみ、このセクションを参照してください。

Fleet`を使用したmanagement`クラスターの移行は、基本的にアップグレードの実行と似ています。

*主な*違いは以下の通りです。

  1. Fleetは、`suse-edge/fleet-examples`リポジトリのrelease-3.6.0リリースから*使用する必要があります*。

  2. アップグレードが予定されているチャートは、SUSE Edge 3.6.0`リリースと互換性のあるバージョンに*アップグレードする必要があります*。SUSE Edge 3.6.0`コンポーネントのリストについては、41.4項 「リリース 3.6.0」を参照してください。

重要
重要

`SUSE Edge 3.6.0`移行を確実に成功させるため、ユーザーは上記で概説した点に従うことが重要です。

上記の点を考慮し、移行を実行するために必要な手順の包括的なガイドについては、`management`クラスタFleet (32.2項 「Fleet」)のドキュメントに従ってください。

31.2 ダウンストリームクラスタ

 

31.2.1項 「Fleet」 - downstream を使用して 第6章 「Fleet」 クラスタマイグレーションを実行する方法。

31.2.1 Fleet

 

`downstream`を使用した`Fleet`クラスタの移行は、基本的にアップグレードの実行と似ています。

*主な*違いは以下の通りです。

  1. Fleetは、`suse-edge/fleet-examples`リポジトリのrelease-3.6.0リリースから*使用する必要があります*。

  2. アップグレードが予定されているチャートは、SUSE Edge 3.6.0`リリースと互換性のあるバージョンに*アップグレードする必要があります*。SUSE Edge 3.6.0`コンポーネントのリストについては、41.4項 「リリース 3.6.0」を参照してください。

重要
重要

`SUSE Edge 3.6.0`移行を確実に成功させるため、ユーザーは上記で概説した点に従うことが重要です。

上記の点を考慮し、移行を実行するために必要な手順の包括的なガイドについては、`downstream`クラスタFleet (33.1項 「Fleet」)のドキュメントに従ってください。

32 管理クラスタ

 

現在、management クラスターで「Day 2」操作を実行する方法は2つあります。

  1. 第19章 「Upgrade Controller」 - 32.1項 「Upgrade Controller」 を通じて

  2. 第6章 「Fleet」 - 32.2項 「Fleet」 を通じて

32.1 Upgrade Controller

 
重要
重要

`Upgrade Controller`は現在、*非エアギャップ管理*クラスターに対する`Day 2`操作のみをサポートしています。

このセクションでは、Day 2`クラスターをある`management`プラットフォームバージョンから別のバージョンへアップグレードする際に関連する、さまざまなSUSE Edge`操作の実行方法について説明します。

`Day 2`操作はUpgrade Controller (第19章 「Upgrade Controller」)によって自動化されており、以下が含まれます。

32.1.1 前提条件

 

`management`クラスターをアップグレードする前に、以下の前提条件を満たす必要があります。

  1. SCC registered nodes - クラスターノードのOSが、アップグレード先の`SUSE Edge`リリース (第41章 「リリースノート」)で指定されているOSバージョンをサポートするサブスクリプションキーで登録されていることを確認してください。

  2. Upgrade Controller - `Upgrade Controller`が`management`クラスターにデプロイされていることを確認してください。インストール手順については、19.3項 「Upgrade Controllerのインストール」を参照してください。

32.1.2 アップグレード

 

  1. SUSE Edge`クラスターのアップグレード先となるリリース (第41章 「リリースノート」)バージョンを決定します。`management

  2. `management`クラスターに、目的の`UpgradePlan`を指定する`release version`をデプロイします。`UpgradePlan`は、`Upgrade Controller`のネームスペースにデプロイする必要があります。

    kubectl apply -n <upgrade_controller_namespace> -f - <<EOF
apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
spec:
  # Version retrieved from release notes
  releaseVersion: 3.X.Y
EOF
    注記
    注記

    `UpgradePlan`に対して追加の設定を行いたいユースケースがあるかもしれません。可能なすべての設定については、19.6.1項 「UpgradePlan」を参照してください。

  3. `UpgradePlan`を`Upgrade Controller’s`ネームスペースにデプロイすると、`upgrade process`が開始されます。

    注記
    注記

    実際の`upgrade process`の詳細については、19.5項 「Upgrade Controllerはどのように機能しますか？」を参照してください。

    `upgrade process`の追跡方法については、19.7項 「アップグレードプロセスの追跡」を参照してください。

32.1.3 アップグレード後の手順

 

最新の`SUSE Edge` z-streamから`3.5`への`3.6.0`のアップグレードでは、Upgrade Controller`がアップグレードプロセスを完了した後に、最終的な手動手順を実行する必要がある場合があります。これらは、SUSE Edge`リリース以降、`3.6`で唯一サポートされるイングレスコントローラーとしてIngress-NGINXをTraefikに置き換えることに関連しています。

注記
注記

RKE2/K3sに統合された`Traefik`イングレスプロバイダーは、SUSE Edge 3.6`リリースでサポートされる唯一のイングレスコントローラーです。複雑なイングレス移行シナリオをサポートするために`Ingress-NGINX`と`Traefik`を一時的に並行して実行することは可能ですが、それはSUSE Edge`管理クラスターやダウンストリームクラスターがバージョン`3.6`にアップグレードされた後、かつ移行に必要な期間に限られます。

RKE2 Ingress NGINXからTraefikへの移行 ガイドでは、`Traefik`イングレスコントローラーが廃止された`Ingress-NGINX`に置き換わった後に利用可能なイングレス移行パスの詳細を提供しています。

もし、アップグレード開始前の管理クラスターでデフォルトのIngress-NGINXを使用しており、`Traefik`イングレスコントローラーを利用していなかった場合は、アップグレード後に`Traefik`を手動でデプロイする必要があります。

まず、デプロイ済みのIngress-NGINXインスタンスが適切に設定されていることを確認します（例：２つのイングレスコントローラー間でPodの不要なhostPort競合を回避するために）：

kubectl apply -f - <<- EOF
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-ingress-nginx
  namespace: kube-system
spec:
  valuesContent: |-
    controller:
      hostPort:
        enabled: false  # not needed when exposing through a type:LoadBalancer service
      config:
        use-forwarded-headers: "true"
        enable-real-ip: "true"
      publishService:
        enabled: true
      service:
        enabled: true
        type: LoadBalancer
        externalTrafficPolicy: Local
EOF

次に、`Traefik`と`rke2-traefik-crd`の両方のHelmチャートをインストールすることで、`rke2-traefik`のデプロイを進めることができます。

注記
注記

以下に示すように`HelmChart`マニフェストを使ってこれらのHelmチャートをデプロイすることで、`Upgrade Controller`が将来の管理クラスターアップグレード時にもこれらのHelmチャートのアップグレードを担うことを保証します。

kubectl apply -f - <<- EOF
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: rke2-traefik-crd
  namespace: kube-system
spec:
  chart: rke2-traefik-crd
  version: {rke2-traefik-crd Helm chart version}
  repo: https://rke2-charts.rancher.io
  bootstrap: false
  failurePolicy: reinstall
  backOffLimit: 20
  targetNamespace: kube-system
  set:
    global.cattle.systemDefaultRegistry: registry.rancher.com
    global.rke2DataDir: /var/lib/rancher/rke2
    global.systemDefaultRegistry: registry.rancher.com
---
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: rke2-traefik
  namespace: kube-system
spec:
  chart: rke2-traefik
  version: {rke2-traefik Helm chart version}
  repo: https://rke2-charts.rancher.io
  bootstrap: false
  failurePolicy: reinstall
  backOffLimit: 20
  targetNamespace: kube-system
  set:
    global.cattle.systemDefaultRegistry: registry.rancher.com
    global.rke2DataDir: /var/lib/rancher/rke2
    global.systemDefaultRegistry: registry.rancher.com
  valuesContent: |-
    ingressClass:
      isDefaultClass: false  # if traefik deployed alongside ingress-nginx
    ports:
      web:
        hostPort: null    # disallow hostPort
        exposedPort: 80
      websecure:
        hostPort: null    # disallow hostPort
        exposedPort: 443
    service:
      enabled: true
      type: LoadBalancer
      spec:
        externalTrafficPolicy: Local
        allocateLoadBalancerNodePorts: false  # k8s GA from 1.24; supported by MetalLB
    providers:
      kubernetesIngressNginx:  # this provider allows traefik to "understand" most of the ingress-nginx annotations
        enabled: true
        ingressClass: "rke2-ingress-nginx-migration"
        controllerClass: "rke2.​cattle.​io/ingress-nginx-migration"
EOF

{rke2-traefik-crd Helm chart version}`と{rke2-traefik-crd Helm chart version}`は、アップグレードしたRKE2/K3sのバージョンにより定められたものです。

最後のステップでは、LoadBalancerタイプのサービスを通じて`Traefik`サービスを公開するために、MetalLBが必要とするオブジェクトを作成します：

kubectl apply -f - <<- EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ingress-ippool-traefik
  namespace: metallb-system
spec:
  addresses:
  - {EXTERNAL_IP_FOR_TRAEFIK_SERVICE}/32
  serviceAllocation:
    priority: 100
    serviceSelectors:
    - matchExpressions:
      - {key: app.kubernetes.io/name, operator: In, values: [rke2-traefik]}
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: ingress-l2-adv-traefik
  namespace: metallb-system
spec:
  ipAddressPools:
  - ingress-ippool-traefik
EOF

これで、`Traefik`と`Ingress-NGINX`が並行して稼働し、一方からもう一方へ安全に必要なイングレスの移行を実施できるようになります。

重要
重要

すべてのイングレスが移行され、`Ingress-NGINX`が不要になったら、不必要なリソース消費を防ぐために、必ずこれをアンインストールし、関連する全てのリソースをクリーンアップしてください。

32.2 Fleet

 

本セクションでは、Fleet (第6章 「Fleet」)コンポーネントを使用して「Day 2」オペレーションを実行する方法について説明します。

本セクションでは、以下のトピックを扱います。

  1. 32.2.1項 「コンポーネント」 - すべての「Day 2」オペレーションで使用されるデフォルトコンポーネント。

  2. 32.2.2項 「ユースケースの特定」 - 使用されるFleetカスタムリソースの概要と、さまざまな「Day 2」オペレーションのユースケースへの適合性について説明します。

  3. 32.2.3項 「Day 2 ワークフロー」 - Fleetを使用して「Day 2」オペレーションを実行するためのワークフローガイドを提供します。

  4. 32.2.4項 「OSのアップグレード」 - Fleetを使用してOSアップグレードを実行する方法について説明します。

  5. 32.2.5項 「Kubernetesバージョンのアップグレード」 - Fleetを使用してKubernetesバージョンのアップグレードを実行する方法について説明します。

  6. 32.2.6項 「Helmチャートのアップグレード」 - Fleetを使用してHelmチャートのアップグレードを実行する方法について説明します。

32.2.1 コンポーネント

 

以下に、Fleetを使用して「Day 2」オペレーションを正常に実行するために、`management`クラスター上にセットアップする必要があるデフォルトコンポーネントの説明を記載します。

32.2.1.1 Rancher

 

オプション。`downstream clusters`の管理および`System Upgrade Controller`への`management cluster`のデプロイを担当します。

詳細については、第4章 「Rancher」を参照してください。

32.2.1.2 System Upgrade Controller (SUC)

 

*System Upgrade Controller*は、`Plan`と呼ばれるカスタムリソースを通じて提供される設定データに基づき、指定されたノードでタスクを実行する役割を担います。

*SUC*は、オペレーティングシステムおよびKubernetesディストリビューションのアップグレードに積極的に活用されています。

*SUC*コンポーネントの詳細およびEdgeスタックにおける位置付けについては、第18章 「System Upgrade Controller」を参照してください。

32.2.2 ユースケースの特定

 

Fleetは、KubernetesおよびHelmリソースの管理を可能にするために、2種類のカスタムリソースを使用します。

以下に、これらのリソースの目的と、「Day 2」オペレーションの文脈において最適なユースケースに関する情報を記載します。

32.2.2.1 GitRepo

 

GitRepo`は、`Fleet`が`Bundles`を作成するためのGitリポジトリを表すFleet (第6章 「Fleet」)リソースです。各 `Bundle は、GitRepo リソース内で定義された設定パスに基づいて作成されます。詳細については、 GitRepoマニュアルを参照してください。

「Day 2」運用のコンテキストでは、GitRepo リソースは通常、Fleet GitOps アプローチを利用する 非エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために使用されます。

あるいは、ローカル git サーバーを介してリポジトリ設定をミラーリングすることを条件に、エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために GitRepo リソースを使用することもできます。

32.2.2.2 バンドル

 

Bundles は、ターゲットクラスターにデプロイされる raw Kubernetes リソースを保持します。通常、これらは GitRepo リソースから作成されますが、手動でデプロイできるユースケースもあります。詳細については、 Bundleマニュアルを参照してください。

「Day 2」運用のコンテキストでは、Bundle リソースは通常、ローカル GitOps 手順（例：ローカル git サーバー）を使用しない エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために使用されます。

あるいは、ユースケースで GitOps ワークフロー（Git リポジトリの使用など）が許可されない場合は、非エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために Bundle リソースを使用することもできます。

32.2.3 Day 2 ワークフロー

 

以下は、management クラスターを特定の Edge リリースにアップグレードする際に従うべき「Day 2」ワークフローです。

  1. OS upgrade (32.2.4項 「OSのアップグレード」)

  2. Kubernetes version upgrade (32.2.5項 「Kubernetesバージョンのアップグレード」)

  3. Helm チャートアップグレード (32.2.6項 「Helmチャートのアップグレード」)

32.2.4 OSのアップグレード

 

このセクションでは、第6章 「Fleet」と第18章 「System Upgrade Controller」を使用してオペレーティングシステムのアップグレードを実行する方法について説明します。

このセクションでは、以下のトピックについて説明します。

  1. 32.2.4.1項 「コンポーネント」 - アップグレードプロセスで使用される追加コンポーネント。

  2. 32.2.4.2項 「概要」 - アップグレードプロセスの概要。

  3. 32.2.4.3項 「要件」 - アップグレードプロセスの要件。

  4. 32.2.4.4項 「OS アップグレード - SUC プランのデプロイメント」 - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法についての情報。

32.2.4.1 コンポーネント

 

このセクションでは、`OS upgrade`プロセスがデフォルトの「Day 2」コンポーネント (32.2.1項 「コンポーネント」)の代わりに使用するカスタムコンポーネントについて説明します。

32.2.4.1.1 systemd.service
 

特定のノードでのOSアップグレードは、systemd.serviceによって処理されます。

OSがEdgeのバージョン間で必要とするアップグレードの種類に応じて、異なるサービスが作成されます。

上記のサービスは、OSアップグレードが必要なmanagementクラスター上に配置する必要がある`SUC plan`を通じて、各ノードに配布されます。

32.2.4.2 概要

 

managementクラスターノードのオペレーティングシステムのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。

*Fleet*は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。

注記
注記

`SUC plans`は、特定のタスクを一連のノード上で実行するために`SUC`が従うべき手順を記述するカスタムリソースです。`SUC plan`がどのようなものかの例については、アップストリームリポジトリを参照してください。

OS SUC plans`は、特定のFleet ワークスペースに GitRepoまたは Bundleリソースをデプロイすることで、各クラスターに配布されます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`OS SUC plans）を目的のクラスターにデプロイします。

注記
注記

`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細については32.2.2項 「ユースケースの特定」を確認してください。

`OS SUC plans`は次のワークフローを記述します。

  1. OSアップグレードの前に、必ずノードをcordonしてください。

  2. `control-plane`ノードの前に、必ず`worker`ノードをアップグレードしてください。

  3. 常に*one*ノードずつクラスターをアップグレードしてください。

`OS SUC plans`がデプロイされると、ワークフローは次のようになります。

  1. SUCはデプロイされた`OS SUC plans`を調整し、*各ノード*に`Kubernetes Job`を作成します。

  2. `Kubernetes Job`は、パッケージのアップグレードまたはOS移行のいずれかのためにsystemd.service (32.2.4.1.1項 「systemd.service」)を作成します。

  3. 作成された`systemd.service`は、特定のノードでOSアップグレードプロセスをトリガーします。

    重要
    重要

    OSアップグレードプロセスが完了すると、システムに更新を適用するために、対応するノードが`rebooted`されます。

上記の説明の図を以下に示します。

fleet day2 management os upgrade

32.2.4.3 要件

 

全般:

  1. SCC登録済みマシン - すべてのmanagementクラスターノードは、それぞれの`https://scc.suse.com/`が目的のRPMリポジトリに正常に接続できるようにするために必要な`systemd.service`に登録されている必要があります。

    重要
    重要

    OSバージョンの移行（例: 6.1 → 6.2）を必要とするEdgeリリースの場合は、SCCキーが新しいバージョンへの移行をサポートしていることを確認してください。

  2. SUCプランの許容設定がノードの許容設定と一致していることを確認してください - Kubernetesクラスターノードにカスタム*テイント*がある場合は、*SUCプラン*にそれらのテイントに対する許容設定を必ず追加してください。デフォルトでは、*SUCプラン*は*コントロールプレーン*ノードに対する許容設定のみを持っています。デフォルトの許容設定（tolerations）には以下が含まれます：

    • CriticalAddonsOnly=true:NoExecute

    • node-role.kubernetes.io/control-plane:NoSchedule

    • node-role.kubernetes.io/etcd:NoExecute

      注記
      注記

      追加の許容設定は、各プランの .spec.tolerations セクションの下に追加する必要があります。OS アップグレードに関連する SUC プラン は、fleets/day2/system-upgrade-controller-plans/os-upgrade の下の suse-edge/fleet-examples リポジトリにあります。有効なリポジトリ release タグのプランを使用していることを確認してください。

      コントロールプレーン SUC プランのカスタム許容設定を定義する例は次のようになります：

      apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: os-upgrade-control-plane
spec:
  ...
  tolerations:
  # default tolerations
  - key: "CriticalAddonsOnly"
    operator: "Equal"
    value: "true"
    effect: "NoExecute"
  - key: "node-role.kubernetes.io/control-plane"
    operator: "Equal"
    effect: "NoSchedule"
  - key: "node-role.kubernetes.io/etcd"
    operator: "Equal"
    effect: "NoExecute"
  # custom toleration
  - key: "foo"
    operator: "Equal"
    value: "bar"
    effect: "NoSchedule"
...

エアギャップ(された):

  1. SUSE RPM リポジトリのミラーリング - OS RPM リポジトリはローカルにミラーリングし、systemd.service がそれらにアクセスできるようにする必要があります。これは、RMT または SUMA のいずれかを使用して実現できます。

32.2.4.4 OS アップグレード - SUC プランのデプロイメント

 
重要
重要

この手順を使用して以前にアップグレードされた環境の場合、ユーザーは以下のいずれかの手順が完了していることを確認する必要があります：

  • Remove any previously deployed SUC Plans related to older Edge release versions from the management cluster - 既存の GitRepo/Bundle ターゲット設定 から目的のクラスターを削除するか、GitRepo/Bundle リソースを完全に削除することで実行できます。

  • Reuse the existing GitRepo/Bundle resource - リソースのリビジョンを、目的の suse-edge/fleet-examples リリース に適したフリートを保持する新しいタグに向けることで実行できます。

これは、古い Edge リリースバージョンの SUC Plans との競合を避けるために行われます。

ユーザーがアップグレードを試みる際に management クラスター上に既存の SUC Plans が存在する場合、次のようなフリートエラーが表示されます：

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

32.2.4.2項 「概要」 で述べたように、OS のアップグレードは、以下のいずれかの方法で目的のクラスターに SUC plans を送信することによって行われます：

どのリソースを使用すべきかを判断するには、32.2.2項 「ユースケースの特定」 を参照してください。

サードパーティの GitOps ツールから OS SUC plans をデプロイしたいユースケースについては、32.2.4.4.3項 「SUCプランのデプロイ - サードパーティのGitOpsワークフロー」 を参照してください。

32.2.4.4.1 SUC プランのデプロイメント - GitRepo リソース
 

必要な OS SUC plans を送信する GitRepo リソースは、以下のいずれかの方法でデプロイできます：

  1. Rancher UI - 32.2.4.4.1.1項 「GitRepoの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. リソースを手動でデプロイ (32.2.4.4.1.2項 「GitRepoの作成 - 手動」) して、management cluster に適用します。

デプロイ後、ターゲットクラスターのノードのOSアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

32.2.4.4.1.1 GitRepoの作成 - Rancher UI
 

Rancher UIを通じて GitRepo リソースを作成するには、公式の ドキュメント に従ってください。

Edgeチームは、すぐに使用できる Fleet を維持管理しています。環境によっては、このFleetを直接使用することも、テンプレートとして使用することもできます。

重要
重要

必ず有効な Edge release タグからこのFleetを使用してください。

Fleetが提供する SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから os-upgrade Fleetを直接参照できます。

カスタム変更が必要な場合（カスタムテイントの追加など）、ユーザーは別のリポジトリから os-upgrade Fleetを参照し、必要に応じてSUCプランに変更を追加できるようにする必要があります。

GitRepo が suse-edge/fleet-examples リポジトリのFleetを使用するように構成する方法の例は、こちらで確認できます。

32.2.4.4.1.2 GitRepoの作成 - 手動
 

  1. GitRepo リソースをプルします：

    curl -o os-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/gitrepos/day2/os-upgrade-gitrepo.yaml

  2. GitRepo 設定を編集します：

    • spec.targets セクションを削除します - ダウンストリームクラスターにのみ必要です。

      # Example using sed
sed -i.bak '/^  targets:/,$d' os-upgrade-gitrepo.yaml && rm -f os-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i os-upgrade-gitrepo.yaml

    • GitRepo のネームスペースを fleet-local ネームスペースに向けます - これは管理クラスターにリソースをデプロイするために行います。

      # Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' os-upgrade-gitrepo.yaml && rm -f os-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i os-upgrade-gitrepo.yaml

  3. `management cluster`に*GitRepo*リソースを適用します。

    kubectl apply -f os-upgrade-gitrepo.yaml

  4. `fleet-local`ネームスペースの下で、作成された*GitRepo*リソースを表示します。

    kubectl get gitrepo os-upgrade -n fleet-local

# Example output
NAME            REPO                                              COMMIT         BUNDLEDEPLOYMENTS-READY   STATUS
os-upgrade      https://github.com/suse-edge/fleet-examples.git   release-3.6.1  0/0
32.2.4.4.2 SUCプランのデプロイメント - Bundleリソース
 

必要なを配布する*Bundle*`OS SUC Plans`リソースは、以下のいずれかの方法でデプロイできます。

  1. Rancher UI - 32.2.4.4.2.1項 「Bundleの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. リソースを手動でデプロイ (32.2.4.4.2.2項 「バンドルの作成 - 手動」) して、management cluster に適用します。

デプロイ後、ターゲットクラスターのノードのOSアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

32.2.4.4.2.1 Bundleの作成 - Rancher UI
 

Edgeチームは、以下の手順で使用できるすぐに使えるbundleを管理しています。

重要
重要

必ず有効なEdge releaseタグのこのBundleを使用してください。

RancherのUIからBundleを作成するには：

  1. 左上隅で、*☰ → Continuous Delivery*をクリックします。

  2. Advanced > *Bundles*に移動します。

  3. *Create from YAML*を選択します。

  4. ここから、以下のいずれかの方法でBundleを作成できます。

    注記
    注記

    Bundleが配布する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationを追加する場合など）。以下の手順で生成されるBundleに、それらの変更を必ず含めてください。

    1. `suse-edge/fleet-examples`からbundle contentを手動でコピーし、*Create from YAML*ページに貼り付けます。

    2. 目的のreleaseタグからsuse-edge/fleet-examplesリポジトリをクローンし、*Create from YAML*ページの*Read from File*オプションを選択します。そこからBundleの場所（bundles/day2/system-upgrade-controller-plans/os-upgrade）に移動し、Bundleファイルを選択します。これにより、*Create from YAML*ページにBundleの内容が自動的に入力されます。

  5. Rancher UIでバンドルを編集します。

    • Bundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...

    • Bundle`の*ターゲット*クラスターを変更して、`local（管理）クラスターを指すようにします。

      spec:
  targets:
  - clusterName: local
      注記
      注記

      `local`クラスターの名前が異なる場合があるユースケースがいくつかあります。

      `local`クラスター名を取得するには、以下のコマンドを実行します。

      kubectl get clusters.fleet.cattle.io -n fleet-local

  6. ［作成］を選択します。

32.2.4.4.2.2 バンドルの作成 - 手動
 

  1. *バンドル*リソースをプルします。

    curl -o os-upgrade-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/bundles/day2/system-upgrade-controller-plans/os-upgrade/os-upgrade-bundle.yaml

  2. `Bundle`設定を編集します。

    • Bundle`の*ターゲット*クラスターを変更して、`local（管理）クラスターを指すようにします。

      spec:
  targets:
  - clusterName: local
      注記
      注記

      `local`クラスターの名前が異なる場合があるユースケースがいくつかあります。

      `local`クラスター名を取得するには、以下のコマンドを実行します。

      kubectl get clusters.fleet.cattle.io -n fleet-local

    • Bundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...

  3. *バンドル*リソースを`management cluster`に適用します。

    kubectl apply -f os-upgrade-bundle.yaml

  4. 作成された*バンドル*リソースを`fleet-local`ネームスペースの下で表示します。

    kubectl get bundles -n fleet-local
32.2.4.4.3 SUCプランのデプロイ - サードパーティのGitOpsワークフロー
 

ユーザーが`OS SUC plans`を独自のサードパーティGitOpsワークフロー（例: Flux）に組み込みたいというユースケースがあるかもしれません。

必要なOSアップグレードリソースを取得するには、まず使用するsuse-edge/fleet-examplesリポジトリのEdge リリースタグを特定します。

その後、リソースは`fleets/day2/system-upgrade-controller-plans/os-upgrade`にあります。ここで：

  • `plan-control-plane.yaml`は、*コントロールプレーン*ノード用のSUCプランリソースです。

  • `plan-worker.yaml`は、*ワーカー*ノード用のSUCプランリソースです。

  • `secret.yaml`は、systemd.service (32.2.4.1.1項 「systemd.service」)を作成する役割を担う`upgrade.sh`スクリプトを含むシークレットです。

  • `config-map.yaml`は、`upgrade.sh`スクリプトによって使用される設定を保持するConfigMapです。

重要
重要

これらの`Plan`リソースは`System Upgrade Controller`によって解釈されるため、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUCの展開に関する情報については、18.2項 「System Upgrade Controllerのインストール」を参照してください。

OSアップグレード用の*SUC Plans*を展開するためにGitOpsワークフローをどのように使用できるかをより深く理解するには、overview (32.2.4.2項 「概要」)を参照すると役立ちます。

32.2.5 Kubernetesバージョンのアップグレード

 

このセクションでは、第6章 「Fleet」と第18章 「System Upgrade Controller」を使用してKubernetesのアップグレードを実行する方法について説明します。

このセクションでは、以下のトピックについて説明します。

  1. 32.2.5.1項 「コンポーネント」 - アップグレードプロセスで使用される追加コンポーネント。

  2. 32.2.5.2項 「概要」 - アップグレードプロセスの概要。

  3. 32.2.5.3項 「要件」 - アップグレードプロセスの要件。

  4. 32.2.5.4項 「K8sアップグレード - SUCプランのデプロイメント」 - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法に関する情報。

32.2.5.1 コンポーネント

 

このセクションでは、デフォルトの「Day 2」コンポーネント (32.2.1項 「コンポーネント」)に加えて`K8s upgrade`プロセスが使用するカスタムコンポーネントについて説明します。

32.2.5.1.1 rke2-upgrade
 

特定のノードのRKE2バージョンをアップグレードするためのコンテナイメージ。

*SUCプラン*に基づいて*SUC*によって作成されたPodを通じて提供されます。このプランは、RKE2のアップグレードが必要な各*クラスター*に配置する必要があります。

`rke2-upgrade`イメージがどのようにアップグレードを実行するかについての詳細は、アップストリームドキュメントを参照してください。

32.2.5.1.2 k3s-upgrade
 

特定のノードのK3sバージョンをアップグレードするためのコンテナイメージ。

*SUCプラン*に基づいて*SUC*によって作成されたPodを通じて提供されます。このプランは、K3sのアップグレードが必要な各*クラスター*に配置する必要があります。

`k3s-upgrade`イメージがどのようにアップグレードを実行するかについての詳細は、アップストリームドキュメントを参照してください。

32.2.5.2 概要

 

managementクラスターノードのKubernetesディストリビューションのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。

`Fleet`は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。

注記
注記

`SUC plans`は、特定のタスクを一連のノードで実行するために*SUC*が従うべき手順を記述したカスタムリソースです。`SUC plan`の例については、アップストリームリポジトリを参照してください。

K8s SUC plans`は、 GitRepoまたは Bundleリソースを特定のFleet workspaceにデプロイすることで、各クラスターにデプロイされます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`K8s SUC plans）を目的のクラスター（複数可）にデプロイします。

注記
注記

`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細については32.2.2項 「ユースケースの特定」を参照してください。

`K8s SUC plans`は以下のワークフローを記述します。

  1. K8sのアップグレード前には、必ずノードをコードンしてください。

  2. 常に`control-plane`ノードを`worker`ノードより先にアップグレードしてください。

  3. 常に`control-plane`ノードは*一つ*ずつ、`worker`ノードは*二つ*ずつアップグレードしてください。

`K8s SUC plans`がデプロイされたら、ワークフローは次のようになります。

  1. SUCはデプロイされた`K8s SUC plans`を同期し、*各ノード*に`Kubernetes Job`を作成します。

  2. Kubernetesのディストリビューションに応じて、Jobはrke2-upgrade (32.2.5.1.1項 「rke2-upgrade」)またはk3s-upgrade (32.2.5.1.2項 「k3s-upgrade」)コンテナイメージのいずれかを実行するPodを作成します。

  3. 作成されたPodは、以下のワークフローに従います。

    1. ノード上の既存の`rke2/k3s`バイナリを、`rke2-upgrade/k3s-upgrade`イメージから取得したものに置き換えます。

    2. 実行中の`rke2/k3s`プロセスを停止します。

  4. `rke2/k3s`プロセスを停止すると再起動がトリガーされ、更新されたバイナリを実行する新しいプロセスが起動し、その結果、Kubernetesディストリビューションはアップグレードされたバージョンになります。

上記の説明の図を以下に示します。

fleet day2 management k8s upgrade

32.2.5.3 要件

 

  1. Kubernetesディストリビューションをバックアップしてください:

    1. *RKE2クラスター*については、RKE2 バックアップおよびリストアのドキュメントを参照してください。

    2. *K3sクラスター*については、K3s バックアップおよびリストアのドキュメントを参照してください。

  2. SUCプランのトレラレーションがノードのトレラレーションと一致していることを確認しましょう - Kubernetesクラスターのノードにカスタム*テイント*がある場合は、*SUCプラン*でそれらのテイントに対するトレラレーションを必ず追加してください。デフォルトでは、*SUC Plans*には*control-plane*ノードに対するトレラレーションのみが含まれています。デフォルトのトレラレーションには以下が含まれます：

    • CriticalAddonsOnly=true:NoExecute

    • node-role.kubernetes.io/control-plane:NoSchedule

    • node-role.kubernetes.io/etcd:NoExecute

      注記
      注記

      追加のトレラレーションは、各プランの`.spec.tolerations`セクションの下に追加する必要があります。Kubernetesバージョンアップグレードに関連する*SUC Plans*は、suse-edge/fleet-examplesリポジトリの以下にあります。

      • *RKE2*の場合 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade

      • *K3s*の場合 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade

      有効なリポジトリreleaseタグのプランを使用していることを確認してください。

      RKE2 control-plane SUCプランのカスタムトレラレーションを定義する例は、次のようになります。

      apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: rke2-upgrade-control-plane
spec:
  ...
  tolerations:
  # default tolerations
  - key: "CriticalAddonsOnly"
    operator: "Equal"
    value: "true"
    effect: "NoExecute"
  - key: "node-role.kubernetes.io/control-plane"
    operator: "Equal"
    effect: "NoSchedule"
  - key: "node-role.kubernetes.io/etcd"
    operator: "Equal"
    effect: "NoExecute"
  # custom toleration
  - key: "foo"
    operator: "Equal"
    value: "bar"
    effect: "NoSchedule"
...

32.2.5.4 K8sアップグレード - SUCプランのデプロイメント

 
重要
重要

この手順を使用して以前にアップグレードされた環境の場合、ユーザーは以下の*いずれかの*手順が完了していることを確認する必要があります。

  • Remove any previously deployed SUC Plans related to older Edge release versions from the management cluster - 既存の`GitRepo/Bundle`target configurationから目的のクラスターを削除するか、`GitRepo/Bundle`リソース自体を削除することで実行できます。

  • Reuse the existing GitRepo/Bundle resource - リソースのリビジョンを、目的の`suse-edge/fleet-examples`releaseに適したフリートを保持する新しいタグに向けることで実行できます。

これは、古いEdgeリリースバージョンの`SUC Plans`との競合を避けるために行われます。

ユーザーがアップグレードを試みた際に、managementクラスター上に既存の`SUC Plans`が存在する場合、以下のフリートエラーが表示されます。

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

32.2.5.2項 「概要」で述べたように、Kubernetesのアップグレードは、以下のいずれかの方法で目的のクラスターに`SUC plans`を配布することによって行われます。

どのリソースを使用すべきかを判断するには、32.2.2項 「ユースケースの特定」を参照してください。

サードパーティのGitOpsツールから`K8s SUC plans`をデプロイしたいユースケースについては、32.2.5.4.3項 「SUC プランの展開 - サードパーティの GitOps ワークフロー」を参照してください。

32.2.5.4.1 SUCプランのデプロイ - GitRepoリソース
 

必要な`K8s SUC plans`を配布する*GitRepo*リソースは、以下のいずれかの方法でデプロイできます。

  1. Rancher UI - 32.2.5.4.1.1項 「GitRepoの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. management cluster にリソースを 手動でデプロイ (32.2.5.4.1.2項 「GitRepoの作成 - 手動」) することによって。

デプロイ後、ターゲットクラスターのノードのKubernetesアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

32.2.5.4.1.1 GitRepoの作成 - Rancher UI
 

Rancher UIを通じて GitRepo リソースを作成するには、公式の ドキュメント に従ってください。

Edgeチームは、RKE2 および K3s のKubernetesディストリビューション向けに、すぐに使用できるフリート（Fleet）を維持しています。環境に応じて、このフリートを直接使用することも、テンプレートとして使用することもできます。

重要
重要

これらのフリートは、必ず有効なEdge リリース タグから使用してください。

これらのフリートに同梱されている SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから直接フリートを参照できます。

カスタム変更が必要な場合（カスタムTolerationを追加する場合など）、ユーザーは別のリポジトリからフリートを参照する必要があります。これにより、必要に応じてSUCプランに変更を加えることができます。

suse-edge/fleet-examples リポジトリのフリートを使用した GitRepo リソースの設定例：

32.2.5.4.1.2 GitRepoの作成 - 手動
 

  1. GitRepo リソースをプルします：

    • RKE2 クラスターの場合：

      curl -o rke2-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/gitrepos/day2/rke2-upgrade-gitrepo.yaml

    • K3s クラスターの場合：

      curl -o k3s-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/gitrepos/day2/k3s-upgrade-gitrepo.yaml

  2. *GitRepo*構成を編集します。

    • `spec.targets`セクションを削除します。これはダウンストリームクラスターにのみ必要です。

      • RKE2の場合：

        # Example using sed
sed -i.bak '/^  targets:/,$d' rke2-upgrade-gitrepo.yaml && rm -f rke2-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i rke2-upgrade-gitrepo.yaml

      • K3sの場合：

        # Example using sed
sed -i.bak '/^  targets:/,$d' k3s-upgrade-gitrepo.yaml && rm -f k3s-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i k3s-upgrade-gitrepo.yaml

    • GitRepo`の名前空間をfleet-local`名前空間に向けます。これは、管理クラスター上にリソースをデプロイするために行われます。

      • RKE2の場合：

        # Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' rke2-upgrade-gitrepo.yaml && rm -f rke2-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i rke2-upgrade-gitrepo.yaml

      • K3sの場合：

        # Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' k3s-upgrade-gitrepo.yaml && rm -f k3s-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i k3s-upgrade-gitrepo.yaml

  3. *GitRepo*リソースを`management cluster`に適用します。

    # RKE2
kubectl apply -f rke2-upgrade-gitrepo.yaml

# K3s
kubectl apply -f k3s-upgrade-gitrepo.yaml

  4. 作成された*GitRepo*リソースを`fleet-local`名前空間の下で表示します。

    # RKE2
kubectl get gitrepo rke2-upgrade -n fleet-local

# K3s
kubectl get gitrepo k3s-upgrade -n fleet-local

# Example output
NAME           REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    https://github.com/suse-edge/fleet-examples.git   fleet-local   0/0
rke2-upgrade   https://github.com/suse-edge/fleet-examples.git   fleet-local   0/0
32.2.5.4.2 SUCプランのデプロイ - バンドルリソース
 

必要な`Kubernetes upgrade SUC Plans`を出荷する*Bundle*リソースは、以下のいずれかの方法でデプロイできます。

  1. Rancher UI - 32.2.5.4.2.1項 「バンドルの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. management cluster にリソースを 手動でデプロイ (32.2.5.4.2.2項 「バンドルの作成 - 手動」) することによって。

デプロイ後、ターゲットクラスターのノードのKubernetesアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

32.2.5.4.2.1 バンドルの作成 - Rancher UI
 

Edgeチームは、rke2およびk3sの両方のKubernetesディストリビューションですぐに使用できるバンドルを維持管理しています。環境に応じて、これらのバンドルを直接使用することも、テンプレートとして使用することもできます。

重要
重要

必ず有効なEdge releaseタグからこのバンドルを使用してください。

RancherのUIからバンドルを作成するには、以下の手順を実行します。

  1. 左上隅にある*☰ → Continuous Delivery*をクリックします。

  2. Advanced > *Bundles*に移動します。

  3. *Create from YAML*を選択します。

  4. ここから、以下のいずれかの方法でバンドルを作成できます。

    注記
    注記

    バンドルが出荷する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationsを追加する場合など）。以下の手順で生成されるバンドルに、これらの変更が含まれていることを確認してください。

    1. `suse-edge/fleet-examples`からRKE2またはK3sのバンドルコンテンツを、*Create from YAML*ページに手動でコピーします。

    2. 目的のreleaseタグからsuse-edge/fleet-examplesリポジトリをクローンし、*Create from YAML*ページで*Read from File*オプションを選択します。そこから、必要なバンドル（RKE2の場合は`bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml`、K3sの場合は`bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml`）に移動します。これにより、*Create from YAML*ページにバンドルコンテンツが自動入力されます。

  5. Rancher UIでバンドルを編集します。

    • Bundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...

    • Bundle`の*target*クラスターを変更して、`local（管理）クラスターを指すようにします。

      spec:
  targets:
  - clusterName: local
      注記
      注記

      `local`クラスターの名前が異なる場合があるユースケースがいくつかあります。

      `local`クラスター名を取得するには、以下のコマンドを実行します。

      kubectl get clusters.fleet.cattle.io -n fleet-local

  6. *Create*を選択します。

32.2.5.4.2.2 バンドルの作成 - 手動
 

  1. *Bundle*リソースをプルします。

    • RKE2 クラスターの場合：

      curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml

    • K3s クラスターの場合：

      curl -o k3s-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml

  2. `Bundle`設定を編集します。

    • Bundle`の*target*クラスターを変更して、`local（管理）クラスターを指すようにします。

      spec:
  targets:
  - clusterName: local
      注記
      注記

      `local`クラスターの名前が異なる場合があるユースケースがいくつかあります。

      `local`クラスター名を取得するには、以下のコマンドを実行します。

      kubectl get clusters.fleet.cattle.io -n fleet-local

    • Bundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...

  3. `management cluster`に*Bundle*リソースを適用します。

    # For RKE2
kubectl apply -f rke2-plan-bundle.yaml

# For K3s
kubectl apply -f k3s-plan-bundle.yaml

  4. fleet-local 名前空間の下で作成された Bundle リソースを表示します。

    # For RKE2
kubectl get bundles rke2-upgrade -n fleet-local

# For K3s
kubectl get bundles k3s-upgrade -n fleet-local

# Example output
NAME           BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    0/0
rke2-upgrade   0/0
32.2.5.4.3 SUC プランの展開 - サードパーティの GitOps ワークフロー
 

ユーザーが Kubernetes upgrade SUC plans を独自のサードパーティ GitOps ワークフロー (例: Flux) に組み込みたいというユースケースがあるかもしれません。

必要な K8s アップグレードリソースを取得するには、まず使用する suse-edge/fleet-examples リポジトリの Edge release タグを特定します。

その後、リソースは以下から入手できます。

  • RKE2 クラスターのアップグレードの場合:

    • control-plane ノード用 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-control-plane.yaml

    • worker ノード用 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-worker.yaml

  • K3s クラスターのアップグレードの場合:

    • control-plane ノード用 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-control-plane.yaml

    • worker ノード用 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-worker.yaml

重要
重要

これらの Plan リソースは System Upgrade Controller によって解釈され、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUC 展開に関する情報については、18.2項 「System Upgrade Controllerのインストール」を参照してください。

Kubernetes バージョンアップグレードのために SUC Plans をデプロイする GitOps ワークフローをより深く理解するには、Fleet を用いた更新手順の overview (32.2.5.2項 「概要」) を確認することが有益です。

32.2.6 Helmチャートのアップグレード

 

このセクションでは、次の部分について説明します。

  1. 32.2.6.1項 「エアギャップ(された)環境の準備」 - Edge関連のOCIチャートおよびイメージをプライベートレジストリに配布する方法に関する情報が記載されています。

  2. 32.2.6.2項 「アップグレード手順」 - さまざまなHelmチャートアップグレードのユースケースと、そのアップグレード手順に関する情報が記載されています。

32.2.6.1 エアギャップ(された)環境の準備

 
32.2.6.1.1 HelmチャートFleetにアクセスできることを確認してください。
 

環境のサポート状況に応じて、次のいずれかのオプションを選択できます。

  1. `management cluster`からアクセス可能なローカルGitサーバーで、チャートのFleetリソースをホストします。

  2. FleetのCLIを使用して、HelmチャートをBundleに変換します。これにより、直接使用できるようになり、どこかでホストする必要がなくなります。FleetのCLIは、リリースページから取得できます。Macユーザーの場合は、fleet-cli Homebrew Formulaeが用意されています。

32.2.6.1.2 Edgeリリースバージョンに必要なアセットを見つける
 

  1. 「Day 2」のリリースページに移動し、チャートのアップグレード先となるEdgeリリースを見つけて、*Assets*をクリックします。

  2. *「Assets」*セクションから、次のファイルをダウンロードします。

    リリースファイル

    説明

    edge-save-images.sh

    `edge-release-images.txt`ファイルで指定されたイメージをプルし、'.tar.gz’アーカイブ内にパッケージ化します。

    edge-save-oci-artefacts.sh

    特定のEdgeリリースに関連するOCIチャートイメージをプルし、'.tar.gz’アーカイブ内にパッケージ化します。

    edge-load-images.sh

    '.tar.gz’アーカイブからイメージをロードし、リタグしてプライベートレジストリにプッシュします。

    edge-load-oci-artefacts.sh

    Edge OCI '.tgz’チャートパッケージを含むディレクトリを取得し、それらをプライベートレジストリにロードします。

    edge-release-helm-oci-artefacts.txt

    特定のEdgeリリースに関連するOCIチャートイメージのリストが含まれています。

    edge-release-images.txt

    特定のEdgeリリースに関連するイメージのリストが含まれています。

32.2.6.1.3 Edgeリリースイメージのアーカイブを作成します
 

インターネットに接続されたマシンで：

  1. `edge-save-images.sh`を実行可能にします：

    chmod +x edge-save-images.sh

  2. イメージアーカイブを生成します：

    ./edge-save-images.sh --source-registry registry.suse.com

  3. これにより、`edge-images.tar.gz`という名前のロード可能なアーカイブが作成されます。

    注記
    注記

    `-i|--images`オプションが指定されている場合、アーカイブの名前が異なることがあります。

  4. このアーカイブを*エアギャップ(された)*マシンにコピーします：

    scp edge-images.tar.gz <user>@<machine_ip>:/path
32.2.6.1.4 Edge OCIチャートイメージのアーカイブを作成します
 

インターネットに接続されたマシンで：

  1. `edge-save-oci-artefacts.sh`を実行可能にします：

    chmod +x edge-save-oci-artefacts.sh

  2. OCIチャートイメージのアーカイブを生成します：

    ./edge-save-oci-artefacts.sh --source-registry registry.suse.com

  3. これにより、`oci-artefacts.tar.gz`という名前のアーカイブが作成されます。

    注記
    注記

    `-a|--archive`オプションが指定されている場合、アーカイブの名前が異なることがあります。

  4. このアーカイブを*エアギャップ(された)*マシンにコピーします：

    scp oci-artefacts.tar.gz <user>@<machine_ip>:/path
32.2.6.1.5 Edgeリリースイメージをエアギャップ(された)マシンにロードします
 

エアギャップ(された)マシンで：

  1. プライベートレジストリにログインします（必要な場合）：

    podman login <REGISTRY.YOURDOMAIN.COM:PORT>

  2. `edge-load-images.sh`を実行可能にします：

    chmod +x edge-load-images.sh

  3. スクリプトを実行し、以前に*コピーした*`edge-images.tar.gz`アーカイブを渡します：

    ./edge-load-images.sh --source-registry registry.suse.com --registry <REGISTRY.YOURDOMAIN.COM:PORT> --images edge-images.tar.gz
    注記
    注記

    これにより、edge-images.tar.gz`からすべてのイメージがロードされ、タグが付け直されて、--registry`オプションで指定されたレジストリにプッシュされます。

32.2.6.1.6 Edge OCIチャートイメージをエアギャップ(された)マシンにロードします
 

エアギャップ(された)マシンで：

  1. プライベートレジストリにログインします（必要な場合）：

    podman login <REGISTRY.YOURDOMAIN.COM:PORT>

  2. `edge-load-oci-artefacts.sh`を実行可能にします：

    chmod +x edge-load-oci-artefacts.sh

  3. コピーした`oci-artefacts.tar.gz`アーカイブをuntar(する)：

    tar -xvf oci-artefacts.tar.gz

  4. これにより、`edge-release-oci-tgz-<date>`という命名テンプレートを持つディレクトリが作成されます

  5. このディレクトリを`edge-load-oci-artefacts.sh`スクリプトに渡して、Edge OCIチャートイメージをプライベートレジストリにロードします：

    注記
    注記

    このスクリプトは、helm CLIが環境にプレインストールされていることを前提としています。Helmのインストール手順については、Installing Helmを参照してください。

    ./edge-load-oci-artefacts.sh --archive-directory edge-release-oci-tgz-<date> --registry <REGISTRY.YOURDOMAIN.COM:PORT> --source-registry registry.suse.com
32.2.6.1.7 Kubernetesディストリビューションでプライベートレジストリを設定します。
 

RKE2については、Private Registry Configurationを参照してください。

K3sについては、Private Registry Configurationを参照してください。

32.2.6.2 アップグレード手順

 

このセクションでは、次のHelmアップグレード手順のユースケースについて説明します。

  1. 32.2.6.2.1項 「新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合」

  2. 32.2.6.2.2項 「Fleetで管理されているHelmチャートをアップグレードしたい」

  3. 32.2.6.2.3項 「EIB経由でデプロイされたHelmチャートをアップグレードしたい」

重要
重要

手動でデプロイされたHelmチャートは、確実にアップグレードすることはできません。32.2.6.2.1項 「新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合」メソッドを使用してHelmチャートを再デプロイすることをお勧めします。

32.2.6.2.1 新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合
 

このセクションでは、次の方法について説明します。

  1. 32.2.6.2.1.1項 「チャートのFleetリソースを準備する」

  2. 32.2.6.2.1.2項 「チャートのFleetをデプロイする」

  3. 32.2.6.2.1.3項 「デプロイされたHelmチャートを管理する」

32.2.6.2.1.1 チャートのFleetリソースを準備する
 

  1. 使用するEdge releaseタグから、チャートのFleetリソースを取得します。

  2. HelmチャートのFleet（fleets/day2/chart-templates/<chart>）に移動します。

  3. GitOpsワークフローを使用する予定がある場合は、チャートのFleetディレクトリを、GitOpsを実行するGitリポジトリにコピーします。

  4. 必要に応じて、Helmチャートで*values*の設定が必要な場合は、コピーしたディレクトリ内の`.helm.values`ファイルにある`fleet.yaml`設定を編集してください。

  5. 必要に応じて、環境に合わせてチャートのFleetにリソースを追加する必要があるユースケースも考えられます。Fleetディレクトリを拡張する方法については、Git Repository Contentsを参照してください。

注記
注記

場合によっては、FleetがHelm操作に使用するデフォルトのタイムアウトでは不十分であり、次のようなエラーが発生することがあります。

failed pre-install: context deadline exceeded

そのような場合は、`fleet.yaml`ファイルの`helm`設定の下にtimeoutSecondsプロパティを追加してください。

*例*として、`longhorn`ヘルムチャートの場合は次のようになります：

  • ユーザーGitリポジトリの構造：

    <user_repository_root>
├── longhorn
│   └── fleet.yaml
└── longhorn-crd
    └── fleet.yaml

  • `fleet.yaml`ユーザー`Longhorn`データが含まれるコンテンツ：

    defaultNamespace: longhorn-system

helm:
  # timeoutSeconds: 10
  releaseName: "longhorn"
  chart: "longhorn"
  repo: "https://charts.rancher.io/"
  version: "1.11.2"
  takeOwnership: true
  # custom chart value overrides
  values:
    # Example for user provided custom values content
    defaultSettings:
      deletingConfirmationFlag: true

# https://fleet.rancher.io/bundle-diffs
diff:
  comparePatches:
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: engineimages.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: nodes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: volumes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
    注記
    注記

    これらは、`longhorn`チャートに対するカスタム設定を説明するために使用される単なる例の値です。これらは`longhorn`チャートのデプロイメントガイドラインとして扱うべきでは*ありません*。

32.2.6.2.1.2 チャートのFleetをデプロイする
 

GitRepo (32.2.6.2.1.2.1項 「GitRepo」)またはBundle (32.2.6.2.1.2.2項 「バンドル」)のいずれかを使用して、チャートのFleetをデプロイできます。

注記
注記

Fleetのデプロイ中に`Modified`メッセージが表示された場合は、対応する`comparePatches`エントリをFleetの`diff`セクションに必ず追加してください。詳細については、変更されたGitRepoを無視するためのDiffの生成を参照してください。

32.2.6.2.1.2.1 GitRepo
 

FleetのGitRepoリソースには、チャートのFleetリソースにアクセスする方法と、それらのリソースを適用する必要があるクラスターに関する情報が保持されています。

`GitRepo`リソースは、Rancher UIを通じてデプロイするか、または手動で`management cluster`にデプロイすることもできます。

手動*デプロイ用の*Longhorn`GitRepo`リソースの例：

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: longhorn-git-repo
  namespace: fleet-local
spec:
  # If using a tag
  # revision: user_repository_tag
  #
  # If using a branch
  # branch: user_repository_branch
  paths:
  # As seen in the 'Prepare your Fleet resources' example
  - longhorn
  - longhorn-crd
  repo: user_repository_url
32.2.6.2.1.2.2 バンドル
 

Bundleリソースには、Fleetによってデプロイされる必要がある生のKubernetesリソースが保持されています。通常は`GitRepo`アプローチの使用が推奨されますが、環境がエアギャップ(された)状態でローカルGitサーバーをサポートできないユースケースでは、`Bundles`がHelmチャートFleetをターゲットクラスターにデプロイするのに役立ちます。

Bundle`は、Rancher UI（`Continuous Delivery → Advanced → Bundles → Create from YAML）を通じて、または正しいFleetネームスペースに`Bundle`リソースを手動でデプロイすることでデプロイできます。Fleetネームスペースの詳細については、アップストリームのドキュメントを参照してください。

Edge Helmチャート用の`Bundles`は、FleetのHelmチャートをバンドルに変換するアプローチを利用して作成できます。

以下に、longhornおよびlonghorn-crd HelmチャートFleetテンプレートから`Bundle`リソースを作成し、このバンドルを`management cluster`に手動でデプロイする方法の例を示します。

注記
注記

ワークフローを説明するために、以下の例ではsuse-edge/fleet-examples ディレクトリ構造を使用しています。

  1. longhornチャートFleetテンプレートに移動します：

    cd fleets/day2/chart-templates/longhorn/longhorn

  2. FleetがHelmチャートをデプロイすべきクラスターを指示する`targets.yaml`ファイルを作成します。

    cat > targets.yaml <<EOF
targets:
# Match your local (management) cluster
- clusterName: local
EOF
    注記
    注記

    ローカルクラスタの名前が異なる場合があるユースケースがいくつか存在します。

    ローカルクラスタ名を取得するには、以下のコマンドを実行します。

    kubectl get clusters.fleet.cattle.io -n fleet-local

  3. fleet-cliを使用して、Longhorn HelmチャートFleetをBundleリソースに変換します。

    注記
    注記

    FleetのCLIは、リリース*アセット*ページ（fleet-linux-amd64）から取得できます。

    Macユーザー向けには、fleet-cliのHomebrew Formulaeが用意されています。

    fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - longhorn-bundle > longhorn-bundle.yaml

  4. longhorn-crdチャートのFleetテンプレートに移動します。

    cd fleets/day2/chart-templates/longhorn/longhorn-crd

  5. FleetがHelmチャートをデプロイすべきクラスターを指示する`targets.yaml`ファイルを作成します。

    cat > targets.yaml <<EOF
targets:
# Match your local (management) cluster
- clusterName: local
EOF

  6. fleet-cliを使用して、Longhorn CRD HelmチャートFleetをBundleリソースに変換します。

    fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - longhorn-crd-bundle > longhorn-crd-bundle.yaml

  7. `longhorn-bundle.yaml`および`longhorn-crd-bundle.yaml`ファイルを`management cluster`にデプロイします。

    kubectl apply -f longhorn-crd-bundle.yaml
kubectl apply -f longhorn-bundle.yaml

これらの手順に従うことで、指定されたすべてのmanagementクラスターに`SUSE Storage`が確実にデプロイされます。

32.2.6.2.1.3 デプロイされたHelmチャートを管理する
 

Fleetでデプロイした後、Helmチャートのアップグレードについては32.2.6.2.2項 「Fleetで管理されているHelmチャートをアップグレードしたい」を参照してください。

32.2.6.2.2 Fleetで管理されているHelmチャートをアップグレードしたい
 

  1. 目的のEdgeリリースと互換性を持たせるために、チャートをアップグレードする必要があるバージョンを決定します。EdgeリリースごとのHelmチャートバージョンは、リリースノート (第41章 「リリースノート」)から確認できます。

  2. Fleetで監視されているGitリポジトリで、Helmチャートの`fleet.yaml`ファイルを編集し、リリースノート (第41章 「リリースノート」)から正しいチャートの*バージョン*と*リポジトリ*を指定します。

  3. 変更をコミットしてリポジトリにプッシュすると、目的のHelmチャートのアップグレードがトリガーされます。

32.2.6.2.3 EIB経由でデプロイされたHelmチャートをアップグレードしたい
 

第8章 「Edge Image Builder」は、`HelmChart`リソースを作成し、RKE2/K3s Helm統合機能によって導入された`helm-controller`を利用することで、Helmチャートをデプロイします。

`EIB`経由でデプロイされたHelmチャートが確実にアップグレードされるように、ユーザーはそれぞれの`HelmChart`リソースに対してアップグレードを行う必要があります。

以下の情報をご覧ください。

32.2.6.2.3.1 概要
 

`EIB`経由でデプロイされたHelmチャートは、eib-charts-upgraderと呼ばれる`fleet`を通じてアップグレードされます。

この`fleet`は、*ユーザー提供*のデータを処理して、特定のHelmChartリソースのセットを*更新*します。

これらのリソースを更新するとhelm-controllerがトリガーされ、変更された`HelmChart`リソースに関連付けられたHelmチャートが*アップグレード*されます。

ユーザーが行う必要があるのは、以下の操作のみです。

  1. アップグレードが必要な各Helmチャートのアーカイブをローカルでプルします。

  2. これらのアーカイブをgenerate-chart-upgrade-data.sh`generate-chart-upgrade-data.sh`スクリプトに渡します。このスクリプトは、これらのアーカイブのデータを`eib-charts-upgrader`Fleetに含めます。

  3. `eib-charts-upgrader`Fleetを`management cluster`にデプロイします。これは、`GitRepo`または`Bundle`リソースのいずれかを通じて行われます。

デプロイされると、`eib-charts-upgrader`はFleetの助けを借りて、そのリソースを目的のmanagementクラスターに配布します。

これらのリソースには以下が含まれます。

  1. *ユーザー提供*のHelmチャートデータを保持する`Secrets`のセット。

  2. 前述の`Secrets`をマウントし、それに基づいて対応するHelmChartリソースをパッチする`Pod`をデプロイする`Kubernetes Job`。

前述の通り、これにより`helm-controller`がトリガーされ、実際のHelmチャートのアップグレードが実行されます。

上記の説明の図を以下に示します。

fleet day2 management helm eib upgrade
32.2.6.2.3.2 アップグレード手順
 

  1. 正しいリリースタグから`suse-edge/fleet-examples`リポジトリをクローンします。

  2. プルしたHelmチャートアーカイブを保存するディレクトリを作成します。

    mkdir archives

  3. 新しく作成したアーカイブディレクトリ内で、アップグレードするHelmチャートのアーカイブをpullします：

    cd archives
helm pull [chart URL | repo/chartname]

# Alternatively if you want to pull a specific version:
# helm pull [chart URL | repo/chartname] --version 0.0.0

  4. 目的のリリースタグの*アセット*から、`generate-chart-upgrade-data.sh`スクリプトをダウンロードします。

  5. `generate-chart-upgrade-data.sh`スクリプトを実行します：

    chmod +x ./generate-chart-upgrade-data.sh

./generate-chart-upgrade-data.sh --archive-dir /foo/bar/archives/ --fleet-path /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader

    --archive-dir`ディレクトリ内の各チャートアーカイブに対して、スクリプトはチャートのアップグレードデータを含む`Kubernetes Secret YAML`ファイルを生成し、--fleet-path`で指定されたFleetの`base/secrets`ディレクトリに保存します。

    `generate-chart-upgrade-data.sh`スクリプトは、生成された`Kubernetes Secret YAML`ファイルがFleetによってデプロイされたワークロードで正しく使用されるように、Fleetに追加の変更を適用します。

    重要
    重要

    ユーザーは、`generate-chart-upgrade-data.sh`スクリプトが生成するものに対して変更を加えるべきではありません。

以下の手順は、実行している環境によって異なります：

  1. GitOpsをサポートしている環境（例：エアギャップ環境ではない、またはエアギャップ環境だがローカルGitサーバーのサポートが許可されている場合）の場合：

    1. GitOpsに使用するリポジトリに`fleets/day2/eib-charts-upgrader` Fleetをコピーします。

      注記
      注記

      `generate-chart-upgrade-data.sh`スクリプトによって行われた変更がFleetに含まれていることを確認してください。

    2. eib-charts-upgrader Fleetのすべてのリソースを配送するために使用される`GitRepo`リソースを設定します。

      1. Rancher UIを通じた`GitRepo`の設定とデプロイについては、Rancher UIでのFleetへのアクセスを参照してください。

      2. `GitRepo`の手動設定とデプロイについては、デプロイの作成を参照してください。

  2. GitOpsをサポートしていない環境（例：エアギャップで、ローカルGitサーバーの使用が許可されていない場合）の場合：

    1. rancher/fleet`のリリースページから`fleet-cli`バイナリをダウンロードします（Linuxの場合は`fleet-linux-amd64）。Macユーザー向けには、使用可能なHomebrew Formulaeがあります - fleet-cli。

    2. eib-charts-upgrader Fleetに移動します：

      cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader

    3. どこにデプロイするかをFleetに指示する`targets.yaml`ファイルを作成します：

      cat > targets.yaml <<EOF
targets:
# To map the local(management) cluster
- clusterName: local
EOF
      注記
      注記

      local クラスターの名前が異なる場合がある使用事例がいくつかあります。

      local クラスター名を取得するには、以下のコマンドを実行します。

      kubectl get clusters.fleet.cattle.io -n fleet-local

    4. fleet-cli を使用して、Fleet を Bundle リソースに変換します。

      fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yaml

      これにより、eib-charts-upgrader Fleet からのすべてのテンプレート化されたリソースを保持する Bundle (bundle.yaml) が作成されます。

      fleet apply コマンドの詳細については、「fleet apply」を参照してください。

      Fleet を Bundle に変換する方法の詳細については、「Convert a Helm Chart into a Bundle」を参照してください。

    5. Bundle をデプロイする。これには、次の2つの方法があります。

      1. Rancher の UI を使用する場合 - 継続的デリバリ → Advanced → Bundles → Create from YAML に移動し、bundle.yaml の内容を貼り付けるか、Read from File オプションをクリックしてファイル自体を渡します。

      2. 手動 - bundle.yaml ファイルを`management cluster`内にデプロイします。

これらの手順を実行すると、GitRepo/Bundle リソースが正常にデプロイされます。このリソースは Fleet によって取得され、その内容はユーザーが前の手順で指定したターゲットクラスターにデプロイされる。この処理の概要については、「32.2.6.2.3.1項 「概要」」を参照してください。

アップグレードの処理を追跡する方法については、32.2.6.2.3.3項 「例」 を参照してください。

重要
重要

チャートのアップグレードが正常に確認できたら、Bundle/GitRepo リソースを削除する。

これにより、不要になったアップグレードリソースを management クラスターから削除することで、将来的なバージョン競合の発生を防ぐことができます。

32.2.6.2.3.3 例
 
注記
注記

以下の例は、EIB を介してデプロイされた Helm チャートを management クラスター上で別のバージョンにアップグレードする方法を示しています。この例で使用されているバージョンは*推奨されているものではありません*のでご注意ください。Edge リリース固有の推奨バージョンについては、「リリースノート (第41章 「リリースノート」)」を参照してください。

使用事例:

  • `management`クラスターで、Longhornの古いバージョンが実行されています。

  • クラスターはEIBを通じてデプロイされており、次のイメージ定義_snippet_を使用しています。

    kubernetes:
  helm:
    charts:
    - name: longhorn-crd
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    - name: longhorn
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    repositories:
    - name: rancher-charts
      url: https://charts.rancher.io/
...

  • SUSE Storage`は、Edge 3.6リリースと互換性のあるバージョンにアップグレードする必要があります。つまり、1.11.2`にアップグレードする必要があります。

  • `management cluster`は*エアギャップ(された)*であり、ローカルGitサーバーのサポートがなく、Rancherが正常にセットアップされていると想定されます。

アップグレード手順 (32.2.6.2.3.2項 「アップグレード手順」)に従ってください。

  1. `release-3.6.1`タグから`suse-edge/fleet-example`リポジトリをクローンします。

    git clone -b release-3.6.1 https://github.com/suse-edge/fleet-examples.git

  2. `Longhorn`アップグレードアーカイブを保存するディレクトリを作成します。

    mkdir archives

  3. 目的の`Longhorn`チャートアーカイブバージョンをプルします。

    # First add the Rancher Helm chart repository
helm repo add rancher-charts https://charts.rancher.io/

# Pull the Longhorn 1.11.2 chart archive
helm pull oci://dp.apps.rancher.io/charts/suse-storage --version 1.11.2

  4. `archives`ディレクトリの外で、`suse-edge/fleet-examples`リリースtagから`generate-chart-upgrade-data.sh`スクリプトをダウンロードします。

  5. ディレクトリのセットアップは次のようになります。

    .
├── archives
│   └── longhorn-1.11.2.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
|   |   |   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       └── kustomization.yaml
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

  6. `generate-chart-upgrade-data.sh`スクリプトを実行します：

    # First make the script executable
chmod +x ./generate-chart-upgrade-data.sh

# Then execute the script
./generate-chart-upgrade-data.sh --archive-dir ./archives --fleet-path ./fleet-examples/fleets/day2/eib-charts-upgrader

    スクリプト実行後のディレクトリ構造は次のようになります。

    .
├── archives
│   └── longhorn-1.11.2.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
│   │   │   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       ├── kustomization.yaml
│   │   │   │   │       ├── longhorn-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   │       └── longhorn-crd-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

    gitで変更されたファイルは次のようになります。

    Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   fleets/day2/eib-charts-upgrader/base/patches/job-patch.yaml
    modified:   fleets/day2/eib-charts-upgrader/base/secrets/kustomization.yaml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-VERSION.yaml
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-crd-VERSION.yaml

  7. Bundle Fleet用の`eib-charts-upgrader`を作成します。

    1. まず、Fleet自体に移動します。

      cd ./fleet-examples/fleets/day2/eib-charts-upgrader

    2. 次に、`targets.yaml`ファイルを作成します。

      cat > targets.yaml <<EOF
targets:
- clusterName: local
EOF

    3. 次に、`fleet-cli`バイナリを使用してFleetをBundleに変換します。

      fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yaml

  8. Rancher UIからBundleをデプロイします：

    day2 helm chart upgrade example 1
    図 32.1: Rancher UIからBundleをデプロイする
     

    ここから、*Read from File*を選択し、システム上の`bundle.yaml`ファイルを見つけます。

    これにより、RancherのUI内で`Bundle`が自動的に入力されます。

    ［Create］を選択します。

  9. デプロイが成功すると、Bundleは次のようになります：

    day2 helm chart upgrade example 2
    図 32.2: Bundleのデプロイに成功しました
     

`Bundle`のデプロイが成功した後、アップグレードの処理を監視するには：

  1. `Upgrade Pod`のログを確認します：

    day2 helm chart upgrade example 3 management

  2. 次に、helm-controllerによってアップグレード用に作成されたPodのログを確認します：

    1. Pod名は次のテンプレートになります - helm-install-longhorn-<random-suffix>

    2. Podは、`HelmChart`リソースがデプロイされたネームスペースに配置されます。今回の場合は`kube-system`です。

      day2 helm chart upgrade example 4 management
      図 32.3: 正常にアップグレードされたLonghornチャートのログ
       

  3. Rancherの`HelmCharts`セクション（More Resources → HelmCharts）に移動して、`HelmChart`のバージョンが更新されていることを確認します。チャートがデプロイされたネームスペースを選択します。この例では`kube-system`になります。

  4. 最後に、Longhorn Podが実行されていることを確認します。

上記の検証を行った後、Longhorn Helmチャートが`1.11.2`バージョンにアップグレードされたと判断して問題ありません。

32.2.6.2.3.4 サードパーティのGitOpsツールを使用したHelmチャートのアップグレード
 

Fleet以外のGitOpsワークフロー（例：Flux）でこのアップグレード手順を使用したいというユースケースがあるかもしれません。

アップグレード手順に必要なリソースを作成するには、generate-chart-upgrade-data.sh スクリプトを使用して、ユーザーが提供したデータで eib-charts-upgrader Fleet を設定できます。この方法の詳細については、32.2.6.2.3.2項 「アップグレード手順」を参照してください。

セットアップが完了したら、Kustomize を使用して、クラスターにデプロイ可能な完全に機能するソリューションを生成できます。

cd /foo/bar/fleets/day2/eib-charts-upgrader

kustomize build .

GitOps ワークフローにソリューションを含める場合は、fleet.yaml ファイルを削除し、残りの部分を有効な Kustomize セットアップとして使用できます。最初に generate-chart-upgrade-data.sh スクリプトを実行して、アップグレード先の Helm チャートのデータで Kustomize セットアップを設定できるようにすることを忘れないでください。

このワークフローの使用方法を理解するには、32.2.6.2.3.1項 「概要」 と 32.2.6.2.3.2項 「アップグレード手順」 を参照すると役立ちます。

33 ダウンストリームクラスタ群

 

このセクションでは、`downstream`クラスタの各部分において「Day 2」オペレーションを実行するための方法を説明します。

33.1 Fleet

 

本セクションでは、Fleet (第6章 「Fleet」)コンポーネントを使用して「Day 2」オペレーションを実行する方法について説明します。

本セクションでは、以下のトピックを扱います。

  1. 33.1.1項 「コンポーネント」 - すべての「Day 2」オペレーションで使用されるデフォルトコンポーネント。

  2. 33.1.2項 「ユースケースの特定」 - 使用されるFleetカスタムリソースの概要と、さまざまな「Day 2」オペレーションのユースケースへの適合性について説明します。

  3. 33.1.3項 「Day 2 ワークフロー」 - Fleetを使用して「Day 2」オペレーションを実行するためのワークフローガイドを提供します。

  4. 33.1.4項 「OSのアップグレード」 - Fleetを使用してOSアップグレードを実行する方法について説明します。

  5. 33.1.5項 「Kubernetesバージョンのアップグレード」 - Fleetを使用してKubernetesバージョンのアップグレードを実行する方法について説明します。

  6. 33.1.6項 「Helmチャートのアップグレード」 - Fleetを使用してHelmチャートのアップグレードを実行する方法について説明します。

33.1.1 コンポーネント

 

以下に、Fleetを使用して「Day 2」オペレーションを正常に実行するために、`downstream`クラスター上にセットアップする必要があるデフォルトコンポーネントの説明を記載します。

33.1.1.1 System Upgrade Controller (SUC)

 
注記
注記

*Must*は、各ダウンストリームクラスターに必ずデプロイする必要があります。

*System Upgrade Controller*は、`Plan`と呼ばれるカスタムリソースを通じて提供される設定データに基づき、指定されたノードでタスクを実行する役割を担います。

*SUC*は、オペレーティングシステムおよびKubernetesディストリビューションのアップグレードに積極的に活用されています。

*SUC*コンポーネントの詳細およびEdgeスタックにおける位置付けについては、第18章 「System Upgrade Controller」を参照してください。

*SUC*のデプロイ方法については、まずユースケースを特定 (33.1.2項 「ユースケースの特定」)してから、System Upgrade Controllerのインストール - GitRepo (18.2.1.1項 「System Upgrade Controllerのインストール - GitRepo」)またはSystem Upgrade Controllerのインストール - Bundle (18.2.1.2項 「System Upgrade Controllerのインストール - Bundle」)を参照してください。

33.1.2 ユースケースの特定

 

Fleetは、KubernetesおよびHelmリソースの管理を可能にするために、2種類のカスタムリソースを使用します。

以下に、これらのリソースの目的と、「Day 2」オペレーションの文脈において最適なユースケースに関する情報を記載します。

33.1.2.1 GitRepo

 

GitRepo`は、`Fleet`が`Bundles`を作成するためのGitリポジトリを表すFleet (第6章 「Fleet」)リソースです。各 `Bundle は、GitRepo リソース内で定義された設定パスに基づいて作成されます。詳細については、 GitRepoマニュアルを参照してください。

「Day 2」運用のコンテキストでは、GitRepo リソースは通常、Fleet GitOps アプローチを利用する 非エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために使用されます。

あるいは、ローカル git サーバーを介してリポジトリ設定をミラーリングすることを条件に、エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために GitRepo リソースを使用することもできます。

33.1.2.2 バンドル

 

Bundles は、ターゲットクラスターにデプロイされる raw Kubernetes リソースを保持します。通常、これらは GitRepo リソースから作成されますが、手動でデプロイできるユースケースもあります。詳細については、 Bundleマニュアルを参照してください。

「Day 2」運用のコンテキストでは、Bundle リソースは通常、ローカル GitOps 手順（例：ローカル git サーバー）を使用しない エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために使用されます。

あるいは、ユースケースで GitOps ワークフロー（Git リポジトリの使用など）が許可されない場合は、非エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために Bundle リソースを使用することもできます。

33.1.3 Day 2 ワークフロー

 

以下は、downstream クラスターを特定の Edge リリースにアップグレードする際に従うべき「Day 2」ワークフローです。

  1. OS upgrade (33.1.4項 「OSのアップグレード」)

  2. Kubernetes version upgrade (33.1.5項 「Kubernetesバージョンのアップグレード」)

  3. Helm チャートアップグレード (33.1.6項 「Helmチャートのアップグレード」)

33.1.4 OSのアップグレード

 

このセクションでは、第6章 「Fleet」と第18章 「System Upgrade Controller」を使用してオペレーティングシステムのアップグレードを実行する方法について説明します。

このセクションでは、以下のトピックについて説明します。

  1. 33.1.4.1項 「コンポーネント」 - アップグレードプロセスで使用される追加コンポーネント。

  2. 33.1.4.2項 「概要」 - アップグレードプロセスの概要。

  3. 33.1.4.3項 「要件」 - アップグレードプロセスの要件。

  4. 33.1.4.4項 「OS アップグレード - SUC プランのデプロイメント」 - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法についての情報。

33.1.4.1 コンポーネント

 

このセクションでは、`OS upgrade`プロセスがデフォルトの「Day 2」コンポーネント (33.1.1項 「コンポーネント」)の代わりに使用するカスタムコンポーネントについて説明します。

33.1.4.1.1 systemd.service
 

特定のノードでのOSアップグレードは、systemd.serviceによって処理されます。

OSがEdgeのバージョン間で必要とするアップグレードの種類に応じて、異なるサービスが作成されます。

上記のサービスは、OSアップグレードが必要なdownstreamクラスター上に配置する必要がある`SUC plan`を通じて、各ノードに配布されます。

33.1.4.2 概要

 

downstreamクラスターノードのオペレーティングシステムのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。

*Fleet*は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。

注記
注記

`SUC plans`は、特定のタスクを一連のノード上で実行するために`SUC`が従うべき手順を記述するカスタムリソースです。`SUC plan`がどのようなものかの例については、アップストリームリポジトリを参照してください。

OS SUC plans`は、特定のFleet ワークスペースに GitRepoまたは Bundleリソースをデプロイすることで、各クラスターに配布されます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`OS SUC plans）を目的のクラスターにデプロイします。

注記
注記

`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細については33.1.2項 「ユースケースの特定」を確認してください。

`OS SUC plans`は次のワークフローを記述します。

  1. OSアップグレードの前に、必ずノードをcordonしてください。

  2. `control-plane`ノードの前に、必ず`worker`ノードをアップグレードしてください。

  3. 常に*one*ノードずつクラスターをアップグレードしてください。

`OS SUC plans`がデプロイされると、ワークフローは次のようになります。

  1. SUCはデプロイされた`OS SUC plans`を調整し、*各ノード*に`Kubernetes Job`を作成します。

  2. `Kubernetes Job`は、パッケージのアップグレードまたはOS移行のいずれかのためにsystemd.service (33.1.4.1.1項 「systemd.service」)を作成します。

  3. 作成された`systemd.service`は、特定のノードでOSアップグレードプロセスをトリガーします。

    重要
    重要

    OSアップグレードプロセスが完了すると、システムに更新を適用するために、対応するノードが`rebooted`されます。

上記の説明の図を以下に示します。

fleet day2 downstream os upgrade

33.1.4.3 要件

 

全般:

  1. SCC登録済みマシン - すべてのdownstreamクラスターノードは、それぞれの`https://scc.suse.com/`が目的のRPMリポジトリに正常に接続できるようにするために必要な`systemd.service`に登録されている必要があります。

    重要
    重要

    OSバージョンの移行（例: 6.1 → 6.2）を必要とするEdgeリリースの場合は、SCCキーが新しいバージョンへの移行をサポートしていることを確認してください。

  2. SUCプランの許容設定がノードの許容設定と一致していることを確認してください - Kubernetesクラスターノードにカスタム*テイント*がある場合は、*SUCプラン*にそれらのテイントに対する許容設定を必ず追加してください。デフォルトでは、*SUCプラン*は*コントロールプレーン*ノードに対する許容設定のみを持っています。デフォルトの許容設定（tolerations）には以下が含まれます：

    • CriticalAddonsOnly=true:NoExecute

    • node-role.kubernetes.io/control-plane:NoSchedule

    • node-role.kubernetes.io/etcd:NoExecute

      注記
      注記

      追加の許容設定は、各プランの .spec.tolerations セクションの下に追加する必要があります。OS アップグレードに関連する SUC プラン は、fleets/day2/system-upgrade-controller-plans/os-upgrade の下の suse-edge/fleet-examples リポジトリにあります。有効なリポジトリ release タグのプランを使用していることを確認してください。

      コントロールプレーン SUC プランのカスタム許容設定を定義する例は次のようになります：

      apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: os-upgrade-control-plane
spec:
  ...
  tolerations:
  # default tolerations
  - key: "CriticalAddonsOnly"
    operator: "Equal"
    value: "true"
    effect: "NoExecute"
  - key: "node-role.kubernetes.io/control-plane"
    operator: "Equal"
    effect: "NoSchedule"
  - key: "node-role.kubernetes.io/etcd"
    operator: "Equal"
    effect: "NoExecute"
  # custom toleration
  - key: "foo"
    operator: "Equal"
    value: "bar"
    effect: "NoSchedule"
...

エアギャップ(された):

  1. SUSE RPM リポジトリのミラーリング - OS RPM リポジトリはローカルにミラーリングし、systemd.service がそれらにアクセスできるようにする必要があります。これは、RMT または SUMA のいずれかを使用して実現できます。

33.1.4.4 OS アップグレード - SUC プランのデプロイメント

 
重要
重要

この手順を使用して以前にアップグレードされた環境の場合、ユーザーは以下のいずれかの手順が完了していることを確認する必要があります：

  • Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - 既存の GitRepo/Bundle ターゲット設定 から目的のクラスターを削除するか、GitRepo/Bundle リソースを完全に削除することで実行できます。

  • Reuse the existing GitRepo/Bundle resource - リソースのリビジョンを、目的の suse-edge/fleet-examples リリース に適したフリートを保持する新しいタグに向けることで実行できます。

これは、古い Edge リリースバージョンの SUC Plans との競合を避けるために行われます。

ユーザーがアップグレードを試みる際に downstream クラスター上に既存の SUC Plans が存在する場合、次のようなフリートエラーが表示されます：

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

33.1.4.2項 「概要」 で述べたように、OS のアップグレードは、以下のいずれかの方法で目的のクラスターに SUC plans を送信することによって行われます：

どのリソースを使用すべきかを判断するには、33.1.2項 「ユースケースの特定」 を参照してください。

サードパーティの GitOps ツールから OS SUC plans をデプロイしたいユースケースについては、33.1.4.4.3項 「SUCプランのデプロイ - サードパーティのGitOpsワークフロー」 を参照してください。

33.1.4.4.1 SUC プランのデプロイメント - GitRepo リソース
 

必要な OS SUC plans を送信する GitRepo リソースは、以下のいずれかの方法でデプロイできます：

  1. Rancher UI - 33.1.4.4.1.1項 「GitRepoの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. リソースを手動でデプロイ (33.1.4.4.1.2項 「GitRepoの作成 - 手動」) して、management cluster に適用します。

デプロイ後、ターゲットクラスターのノードのOSアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

33.1.4.4.1.1 GitRepoの作成 - Rancher UI
 

Rancher UIを通じて GitRepo リソースを作成するには、公式の ドキュメント に従ってください。

Edgeチームは、すぐに使用できる Fleet を維持管理しています。環境によっては、このFleetを直接使用することも、テンプレートとして使用することもできます。

重要
重要

必ず有効な Edge release タグからこのFleetを使用してください。

Fleetが提供する SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから os-upgrade Fleetを直接参照できます。

カスタム変更が必要な場合（カスタムテイントの追加など）、ユーザーは別のリポジトリから os-upgrade Fleetを参照し、必要に応じてSUCプランに変更を追加できるようにする必要があります。

GitRepo が suse-edge/fleet-examples リポジトリのFleetを使用するように構成する方法の例は、こちらで確認できます。

33.1.4.4.1.2 GitRepoの作成 - 手動
 

  1. GitRepo リソースをプルします：

    curl -o os-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/gitrepos/day2/os-upgrade-gitrepo.yaml

  2. GitRepo 設定を編集し、spec.targets の下に目的のターゲットリストを指定します。デフォルトでは、GitRepo の suse-edge/fleet-examples リソースは、どのダウンストリームクラスターにも マッピングされていません。

    • すべてのクラスターに一致させるには、デフォルトの GitRepo ターゲット を次のように変更します：

      spec:
  targets:
  - clusterSelector: {}

    • あるいは、より詳細なクラスター選択が必要な場合は、ダウンストリームクラスターへのマッピング を参照してください。

  3. `management cluster`に*GitRepo*リソースを適用します。

    kubectl apply -f os-upgrade-gitrepo.yaml

  4. `fleet-default`ネームスペースの下で、作成された*GitRepo*リソースを表示します。

    kubectl get gitrepo os-upgrade -n fleet-default

# Example output
NAME            REPO                                              COMMIT         BUNDLEDEPLOYMENTS-READY   STATUS
os-upgrade      https://github.com/suse-edge/fleet-examples.git   release-3.6.1  0/0
33.1.4.4.2 SUCプランのデプロイメント - Bundleリソース
 

必要なを配布する*Bundle*`OS SUC Plans`リソースは、以下のいずれかの方法でデプロイできます。

  1. Rancher UI - 33.1.4.4.2.1項 「Bundleの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. リソースを手動でデプロイ (33.1.4.4.2.2項 「バンドルの作成 - 手動」) して、management cluster に適用します。

デプロイ後、ターゲットクラスターのノードのOSアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

33.1.4.4.2.1 Bundleの作成 - Rancher UI
 

Edgeチームは、以下の手順で使用できるすぐに使えるbundleを管理しています。

重要
重要

必ず有効なEdge releaseタグのこのBundleを使用してください。

RancherのUIからBundleを作成するには：

  1. 左上隅で、*☰ → Continuous Delivery*をクリックします。

  2. Advanced > *Bundles*に移動します。

  3. *Create from YAML*を選択します。

  4. ここから、以下のいずれかの方法でBundleを作成できます。

    注記
    注記

    Bundleが配布する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationを追加する場合など）。以下の手順で生成されるBundleに、それらの変更を必ず含めてください。

    1. `suse-edge/fleet-examples`からbundle contentを手動でコピーし、*Create from YAML*ページに貼り付けます。

    2. 目的のreleaseタグからsuse-edge/fleet-examplesリポジトリをクローンし、*Create from YAML*ページの*Read from File*オプションを選択します。そこからBundleの場所（bundles/day2/system-upgrade-controller-plans/os-upgrade）に移動し、Bundleファイルを選択します。これにより、*Create from YAML*ページにBundleの内容が自動的に入力されます。

  5. `Bundle`の*target*クラスターを変更します。

    • すべてのダウンストリームクラスターに一致させるには、デフォルトのBundle `.spec.targets`を以下のように変更します。

      spec:
  targets:
  - clusterSelector: {}

    • より詳細なダウンストリームクラスターのマッピングについては、ダウンストリームクラスターへのマッピングを参照してください。

  6. ［作成］を選択します。

33.1.4.4.2.2 バンドルの作成 - 手動
 

  1. *バンドル*リソースをプルします。

    curl -o os-upgrade-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/bundles/day2/system-upgrade-controller-plans/os-upgrade/os-upgrade-bundle.yaml

  2. `Bundle`の*ターゲット*設定を編集し、`spec.targets`の下に目的のターゲットリストを指定します。デフォルトでは、`Bundle`の`suse-edge/fleet-examples`リソースは、どのダウンストリームクラスターにも*マップされません*。

    • すべてのクラスターに一致させるには、デフォルトの Bundle ターゲット を次のように変更します：

      spec:
  targets:
  - clusterSelector: {}

    • あるいは、より詳細なクラスター選択が必要な場合は、ダウンストリームクラスターへのマッピング を参照してください。

  3. *バンドル*リソースを`management cluster`に適用します。

    kubectl apply -f os-upgrade-bundle.yaml

  4. 作成された*バンドル*リソースを`fleet-default`ネームスペースの下で表示します。

    kubectl get bundles -n fleet-default
33.1.4.4.3 SUCプランのデプロイ - サードパーティのGitOpsワークフロー
 

ユーザーが`OS SUC plans`を独自のサードパーティGitOpsワークフロー（例: Flux）に組み込みたいというユースケースがあるかもしれません。

必要なOSアップグレードリソースを取得するには、まず使用するsuse-edge/fleet-examplesリポジトリのEdge リリースタグを特定します。

その後、リソースは`fleets/day2/system-upgrade-controller-plans/os-upgrade`にあります。ここで：

  • `plan-control-plane.yaml`は、*コントロールプレーン*ノード用のSUCプランリソースです。

  • `plan-worker.yaml`は、*ワーカー*ノード用のSUCプランリソースです。

  • `secret.yaml`は、systemd.service (33.1.4.1.1項 「systemd.service」)を作成する役割を担う`upgrade.sh`スクリプトを含むシークレットです。

  • `config-map.yaml`は、`upgrade.sh`スクリプトによって使用される設定を保持するConfigMapです。

重要
重要

これらの`Plan`リソースは`System Upgrade Controller`によって解釈されるため、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUCの展開に関する情報については、18.2項 「System Upgrade Controllerのインストール」を参照してください。

OSアップグレード用の*SUC Plans*を展開するためにGitOpsワークフローをどのように使用できるかをより深く理解するには、overview (33.1.4.2項 「概要」)を参照すると役立ちます。

33.1.5 Kubernetesバージョンのアップグレード

 
重要
重要

このセクションでは、NOT Rancher (第4章 「Rancher」)インスタンスを通じて作成されたダウンストリームクラスターのKubernetesアップグレードについて説明します。`Rancher`で作成されたクラスターのKubernetesバージョンをアップグレードする方法については、Kubernetesのアップグレードとロールバックを参照してください。

このセクションでは、第6章 「Fleet」と第18章 「System Upgrade Controller」を使用してKubernetesのアップグレードを実行する方法について説明します。

このセクションでは、以下のトピックについて説明します。

  1. 33.1.5.1項 「コンポーネント」 - アップグレードプロセスで使用される追加コンポーネント。

  2. 33.1.5.2項 「概要」 - アップグレードプロセスの概要。

  3. 33.1.5.3項 「要件」 - アップグレードプロセスの要件。

  4. 33.1.5.4項 「K8sアップグレード - SUCプランのデプロイメント」 - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法に関する情報。

33.1.5.1 コンポーネント

 

このセクションでは、デフォルトの「Day 2」コンポーネント (33.1.1項 「コンポーネント」)に加えて`K8s upgrade`プロセスが使用するカスタムコンポーネントについて説明します。

33.1.5.1.1 rke2-upgrade
 

特定のノードのRKE2バージョンをアップグレードするためのコンテナイメージ。

*SUCプラン*に基づいて*SUC*によって作成されたPodを通じて提供されます。このプランは、RKE2のアップグレードが必要な各*クラスター*に配置する必要があります。

`rke2-upgrade`イメージがどのようにアップグレードを実行するかについての詳細は、アップストリームドキュメントを参照してください。

33.1.5.1.2 k3s-upgrade
 

特定のノードのK3sバージョンをアップグレードするためのコンテナイメージ。

*SUCプラン*に基づいて*SUC*によって作成されたPodを通じて提供されます。このプランは、K3sのアップグレードが必要な各*クラスター*に配置する必要があります。

`k3s-upgrade`イメージがどのようにアップグレードを実行するかについての詳細は、アップストリームドキュメントを参照してください。

33.1.5.2 概要

 

downstreamクラスターノードのKubernetesディストリビューションのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。

`Fleet`は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。

注記
注記

`SUC plans`は、特定のタスクを一連のノードで実行するために*SUC*が従うべき手順を記述したカスタムリソースです。`SUC plan`の例については、アップストリームリポジトリを参照してください。

K8s SUC plans`は、 GitRepoまたは Bundleリソースを特定のFleet workspaceにデプロイすることで、各クラスターにデプロイされます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`K8s SUC plans）を目的のクラスター（複数可）にデプロイします。

注記
注記

`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細については33.1.2項 「ユースケースの特定」を参照してください。

`K8s SUC plans`は以下のワークフローを記述します。

  1. K8sのアップグレード前には、必ずノードをコードンしてください。

  2. 常に`control-plane`ノードを`worker`ノードより先にアップグレードしてください。

  3. 常に`control-plane`ノードは*一つ*ずつ、`worker`ノードは*二つ*ずつアップグレードしてください。

`K8s SUC plans`がデプロイされたら、ワークフローは次のようになります。

  1. SUCはデプロイされた`K8s SUC plans`を同期し、*各ノード*に`Kubernetes Job`を作成します。

  2. Kubernetesのディストリビューションに応じて、Jobはrke2-upgrade (33.1.5.1.1項 「rke2-upgrade」)またはk3s-upgrade (33.1.5.1.2項 「k3s-upgrade」)コンテナイメージのいずれかを実行するPodを作成します。

  3. 作成されたPodは、以下のワークフローに従います。

    1. ノード上の既存の`rke2/k3s`バイナリを、`rke2-upgrade/k3s-upgrade`イメージから取得したものに置き換えます。

    2. 実行中の`rke2/k3s`プロセスを停止します。

  4. `rke2/k3s`プロセスを停止すると再起動がトリガーされ、更新されたバイナリを実行する新しいプロセスが起動し、その結果、Kubernetesディストリビューションはアップグレードされたバージョンになります。

上記の説明の図を以下に示します。

fleet day2 downstream k8s upgrade

33.1.5.3 要件

 

  1. Kubernetesディストリビューションをバックアップしてください:

    1. *RKE2クラスター*については、RKE2 バックアップおよびリストアのドキュメントを参照してください。

    2. *K3sクラスター*については、K3s バックアップおよびリストアのドキュメントを参照してください。

  2. SUCプランのトレラレーションがノードのトレラレーションと一致していることを確認しましょう - Kubernetesクラスターのノードにカスタム*テイント*がある場合は、*SUCプラン*でそれらのテイントに対するトレラレーションを必ず追加してください。デフォルトでは、*SUC Plans*には*control-plane*ノードに対するトレラレーションのみが含まれています。デフォルトのトレラレーションには以下が含まれます：

    • CriticalAddonsOnly=true:NoExecute

    • node-role.kubernetes.io/control-plane:NoSchedule

    • node-role.kubernetes.io/etcd:NoExecute

      注記
      注記

      追加のトレラレーションは、各プランの`.spec.tolerations`セクションの下に追加する必要があります。Kubernetesバージョンアップグレードに関連する*SUC Plans*は、suse-edge/fleet-examplesリポジトリの以下にあります。

      • *RKE2*の場合 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade

      • *K3s*の場合 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade

      有効なリポジトリreleaseタグのプランを使用していることを確認してください。

      RKE2 control-plane SUCプランのカスタムトレラレーションを定義する例は、次のようになります。

      apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: rke2-upgrade-control-plane
spec:
  ...
  tolerations:
  # default tolerations
  - key: "CriticalAddonsOnly"
    operator: "Equal"
    value: "true"
    effect: "NoExecute"
  - key: "node-role.kubernetes.io/control-plane"
    operator: "Equal"
    effect: "NoSchedule"
  - key: "node-role.kubernetes.io/etcd"
    operator: "Equal"
    effect: "NoExecute"
  # custom toleration
  - key: "foo"
    operator: "Equal"
    value: "bar"
    effect: "NoSchedule"
...

33.1.5.4 K8sアップグレード - SUCプランのデプロイメント

 
重要
重要

この手順を使用して以前にアップグレードされた環境の場合、ユーザーは以下の*いずれかの*手順が完了していることを確認する必要があります。

  • Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - 既存の`GitRepo/Bundle`target configurationから目的のクラスターを削除するか、`GitRepo/Bundle`リソース自体を削除することで実行できます。

  • Reuse the existing GitRepo/Bundle resource - リソースのリビジョンを、目的の`suse-edge/fleet-examples`releaseに適したフリートを保持する新しいタグに向けることで実行できます。

これは、古いEdgeリリースバージョンの`SUC Plans`との競合を避けるために行われます。

ユーザーがアップグレードを試みた際に、downstreamクラスター上に既存の`SUC Plans`が存在する場合、以下のフリートエラーが表示されます。

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

33.1.5.2項 「概要」で述べたように、Kubernetesのアップグレードは、以下のいずれかの方法で目的のクラスターに`SUC plans`を配布することによって行われます。

どのリソースを使用すべきかを判断するには、33.1.2項 「ユースケースの特定」を参照してください。

サードパーティのGitOpsツールから`K8s SUC plans`をデプロイしたいユースケースについては、33.1.5.4.3項 「SUC プランの展開 - サードパーティの GitOps ワークフロー」を参照してください。

33.1.5.4.1 SUCプランのデプロイ - GitRepoリソース
 

必要な`K8s SUC plans`を配布する*GitRepo*リソースは、以下のいずれかの方法でデプロイできます。

  1. Rancher UI - 33.1.5.4.1.1項 「GitRepoの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. management cluster にリソースを 手動でデプロイ (33.1.5.4.1.2項 「GitRepoの作成 - 手動」) することによって。

デプロイ後、ターゲットクラスターのノードのKubernetesアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

33.1.5.4.1.1 GitRepoの作成 - Rancher UI
 

Rancher UIを通じて GitRepo リソースを作成するには、公式の ドキュメント に従ってください。

Edgeチームは、RKE2 および K3s のKubernetesディストリビューション向けに、すぐに使用できるフリート（Fleet）を維持しています。環境に応じて、このフリートを直接使用することも、テンプレートとして使用することもできます。

重要
重要

これらのフリートは、必ず有効なEdge リリース タグから使用してください。

これらのフリートに同梱されている SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから直接フリートを参照できます。

カスタム変更が必要な場合（カスタムTolerationを追加する場合など）、ユーザーは別のリポジトリからフリートを参照する必要があります。これにより、必要に応じてSUCプランに変更を加えることができます。

suse-edge/fleet-examples リポジトリのフリートを使用した GitRepo リソースの設定例：

33.1.5.4.1.2 GitRepoの作成 - 手動
 

  1. GitRepo リソースをプルします：

    • RKE2 クラスターの場合：

      curl -o rke2-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/gitrepos/day2/rke2-upgrade-gitrepo.yaml

    • K3s クラスターの場合：

      curl -o k3s-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/gitrepos/day2/k3s-upgrade-gitrepo.yaml

  2. GitRepo 設定を編集し、spec.targets の下に目的のターゲットリストを指定します。デフォルトでは、GitRepo の suse-edge/fleet-examples リソースは、どのダウンストリーム クラスターにも NOT マッピングされていません。

    • すべてのクラスターに一致させるには、デフォルトの GitRepo target を次のように変更します：

      spec:
  targets:
  - clusterSelector: {}

    • あるいは、より詳細なクラスター選択が必要な場合は、Mapping to Downstream Clustersを参照してください。

  3. *GitRepo*リソースを`management cluster`に適用します。

    # RKE2
kubectl apply -f rke2-upgrade-gitrepo.yaml

# K3s
kubectl apply -f k3s-upgrade-gitrepo.yaml

  4. 作成された*GitRepo*リソースを`fleet-default`名前空間の下で表示します。

    # RKE2
kubectl get gitrepo rke2-upgrade -n fleet-default

# K3s
kubectl get gitrepo k3s-upgrade -n fleet-default

# Example output
NAME           REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    https://github.com/suse-edge/fleet-examples.git   fleet-default   0/0
rke2-upgrade   https://github.com/suse-edge/fleet-examples.git   fleet-default   0/0
33.1.5.4.2 SUCプランのデプロイ - バンドルリソース
 

必要な`Kubernetes upgrade SUC Plans`を出荷する*Bundle*リソースは、以下のいずれかの方法でデプロイできます。

  1. Rancher UI - 33.1.5.4.2.1項 「バンドルの作成 - Rancher UI」 を通じて（`Rancher`が利用可能な場合）。

  2. management cluster にリソースを 手動でデプロイ (33.1.5.4.2.2項 「バンドルの作成 - 手動」) することによって。

デプロイ後、ターゲットクラスターのノードのKubernetesアップグレードプロセスを監視するには、18.3項 「System Upgrade Controllerプランの監視」 を参照してください。

33.1.5.4.2.1 バンドルの作成 - Rancher UI
 

Edgeチームは、rke2およびk3sの両方のKubernetesディストリビューションですぐに使用できるバンドルを維持管理しています。環境に応じて、これらのバンドルを直接使用することも、テンプレートとして使用することもできます。

重要
重要

必ず有効なEdge releaseタグからこのバンドルを使用してください。

RancherのUIからバンドルを作成するには、以下の手順を実行します。

  1. 左上隅にある*☰ → Continuous Delivery*をクリックします。

  2. Advanced > *Bundles*に移動します。

  3. *Create from YAML*を選択します。

  4. ここから、以下のいずれかの方法でバンドルを作成できます。

    注記
    注記

    バンドルが出荷する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationsを追加する場合など）。以下の手順で生成されるバンドルに、これらの変更が含まれていることを確認してください。

    1. `suse-edge/fleet-examples`からRKE2またはK3sのバンドルコンテンツを、*Create from YAML*ページに手動でコピーします。

    2. 目的のreleaseタグからsuse-edge/fleet-examplesリポジトリをクローンし、*Create from YAML*ページで*Read from File*オプションを選択します。そこから、必要なバンドル（RKE2の場合は`bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml`、K3sの場合は`bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml`）に移動します。これにより、*Create from YAML*ページにバンドルコンテンツが自動入力されます。

  5. `Bundle`の*target*クラスターを変更します。

    • すべてのダウンストリームクラスターと一致させるには、デフォルトのバンドル`.spec.targets`を以下のように変更します。

      spec:
  targets:
  - clusterSelector: {}

    • より詳細なダウンストリームクラスターのマッピングについては、Mapping to Downstream Clustersを参照してください。

  6. *Create*を選択します。

33.1.5.4.2.2 バンドルの作成 - 手動
 

  1. *Bundle*リソースをプルします。

    • RKE2 クラスターの場合：

      curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml

    • K3s クラスターの場合：

      curl -o k3s-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml

  2. `Bundle`の*target*設定を編集し、`spec.targets`の下に目的のターゲットリストを指定します。デフォルトでは、`Bundle`の`suse-edge/fleet-examples`リソースは、どのダウンストリームクラスターにも NOT マッピングされていません。

    • すべてのクラスターに一致させるには、デフォルトの Bundle target を次のように変更します：

      spec:
  targets:
  - clusterSelector: {}

    • あるいは、より詳細なクラスター選択が必要な場合は、Mapping to Downstream Clustersを参照してください。

  3. `management cluster`に*Bundle*リソースを適用します。

    # For RKE2
kubectl apply -f rke2-plan-bundle.yaml

# For K3s
kubectl apply -f k3s-plan-bundle.yaml

  4. fleet-default 名前空間の下で作成された Bundle リソースを表示します。

    # For RKE2
kubectl get bundles rke2-upgrade -n fleet-default

# For K3s
kubectl get bundles k3s-upgrade -n fleet-default

# Example output
NAME           BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    0/0
rke2-upgrade   0/0
33.1.5.4.3 SUC プランの展開 - サードパーティの GitOps ワークフロー
 

ユーザーが Kubernetes upgrade SUC plans を独自のサードパーティ GitOps ワークフロー (例: Flux) に組み込みたいというユースケースがあるかもしれません。

必要な K8s アップグレードリソースを取得するには、まず使用する suse-edge/fleet-examples リポジトリの Edge release タグを特定します。

その後、リソースは以下から入手できます。

  • RKE2 クラスターのアップグレードの場合:

    • control-plane ノード用 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-control-plane.yaml

    • worker ノード用 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-worker.yaml

  • K3s クラスターのアップグレードの場合:

    • control-plane ノード用 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-control-plane.yaml

    • worker ノード用 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-worker.yaml

重要
重要

これらの Plan リソースは System Upgrade Controller によって解釈され、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUC 展開に関する情報については、18.2項 「System Upgrade Controllerのインストール」を参照してください。

Kubernetes バージョンアップグレードのために SUC Plans をデプロイする GitOps ワークフローをより深く理解するには、Fleet を用いた更新手順の overview (33.1.5.2項 「概要」) を確認することが有益です。

33.1.6 Helmチャートのアップグレード

 

このセクションでは、次の部分について説明します。

  1. 33.1.6.1項 「エアギャップ(された)環境の準備」 - Edge関連のOCIチャートおよびイメージをプライベートレジストリに配布する方法に関する情報が記載されています。

  2. 33.1.6.2項 「アップグレード手順」 - さまざまなHelmチャートアップグレードのユースケースと、そのアップグレード手順に関する情報が記載されています。

33.1.6.1 エアギャップ(された)環境の準備

 
33.1.6.1.1 HelmチャートFleetにアクセスできることを確認してください。
 

環境のサポート状況に応じて、次のいずれかのオプションを選択できます。

  1. `management cluster`からアクセス可能なローカルGitサーバーで、チャートのFleetリソースをホストします。

  2. FleetのCLIを使用して、HelmチャートをBundleに変換します。これにより、直接使用できるようになり、どこかでホストする必要がなくなります。FleetのCLIは、リリースページから取得できます。Macユーザーの場合は、fleet-cli Homebrew Formulaeが用意されています。

33.1.6.1.2 Edgeリリースバージョンに必要なアセットを見つける
 

  1. 「Day 2」のリリースページに移動し、チャートのアップグレード先となるEdgeリリースを見つけて、*Assets*をクリックします。

  2. *「Assets」*セクションから、次のファイルをダウンロードします。

    リリースファイル

    説明

    edge-save-images.sh

    `edge-release-images.txt`ファイルで指定されたイメージをプルし、'.tar.gz’アーカイブ内にパッケージ化します。

    edge-save-oci-artefacts.sh

    特定のEdgeリリースに関連するOCIチャートイメージをプルし、'.tar.gz’アーカイブ内にパッケージ化します。

    edge-load-images.sh

    '.tar.gz’アーカイブからイメージをロードし、リタグしてプライベートレジストリにプッシュします。

    edge-load-oci-artefacts.sh

    Edge OCI '.tgz’チャートパッケージを含むディレクトリを取得し、それらをプライベートレジストリにロードします。

    edge-release-helm-oci-artefacts.txt

    特定のEdgeリリースに関連するOCIチャートイメージのリストが含まれています。

    edge-release-images.txt

    特定のEdgeリリースに関連するイメージのリストが含まれています。

33.1.6.1.3 Edgeリリースイメージのアーカイブを作成します
 

インターネットに接続されたマシンで：

  1. `edge-save-images.sh`を実行可能にします：

    chmod +x edge-save-images.sh

  2. イメージアーカイブを生成します：

    ./edge-save-images.sh --source-registry registry.suse.com

  3. これにより、`edge-images.tar.gz`という名前のロード可能なアーカイブが作成されます。

    注記
    注記

    `-i|--images`オプションが指定されている場合、アーカイブの名前が異なることがあります。

  4. このアーカイブを*エアギャップ(された)*マシンにコピーします：

    scp edge-images.tar.gz <user>@<machine_ip>:/path
33.1.6.1.4 Edge OCIチャートイメージのアーカイブを作成します
 

インターネットに接続されたマシンで：

  1. `edge-save-oci-artefacts.sh`を実行可能にします：

    chmod +x edge-save-oci-artefacts.sh

  2. OCIチャートイメージのアーカイブを生成します：

    ./edge-save-oci-artefacts.sh --source-registry registry.suse.com

  3. これにより、`oci-artefacts.tar.gz`という名前のアーカイブが作成されます。

    注記
    注記

    `-a|--archive`オプションが指定されている場合、アーカイブの名前が異なることがあります。

  4. このアーカイブを*エアギャップ(された)*マシンにコピーします：

    scp oci-artefacts.tar.gz <user>@<machine_ip>:/path
33.1.6.1.5 Edgeリリースイメージをエアギャップ(された)マシンにロードします
 

エアギャップ(された)マシンで：

  1. プライベートレジストリにログインします（必要な場合）：

    podman login <REGISTRY.YOURDOMAIN.COM:PORT>

  2. `edge-load-images.sh`を実行可能にします：

    chmod +x edge-load-images.sh

  3. スクリプトを実行し、以前に*コピーした*`edge-images.tar.gz`アーカイブを渡します：

    ./edge-load-images.sh --source-registry registry.suse.com --registry <REGISTRY.YOURDOMAIN.COM:PORT> --images edge-images.tar.gz
    注記
    注記

    これにより、edge-images.tar.gz`からすべてのイメージがロードされ、タグが付け直されて、--registry`オプションで指定されたレジストリにプッシュされます。

33.1.6.1.6 Edge OCIチャートイメージをエアギャップ(された)マシンにロードします
 

エアギャップ(された)マシンで：

  1. プライベートレジストリにログインします（必要な場合）：

    podman login <REGISTRY.YOURDOMAIN.COM:PORT>

  2. `edge-load-oci-artefacts.sh`を実行可能にします：

    chmod +x edge-load-oci-artefacts.sh

  3. コピーした`oci-artefacts.tar.gz`アーカイブをuntar(する)：

    tar -xvf oci-artefacts.tar.gz

  4. これにより、`edge-release-oci-tgz-<date>`という命名テンプレートを持つディレクトリが作成されます

  5. このディレクトリを`edge-load-oci-artefacts.sh`スクリプトに渡して、Edge OCIチャートイメージをプライベートレジストリにロードします：

    注記
    注記

    このスクリプトは、helm CLIが環境にプレインストールされていることを前提としています。Helmのインストール手順については、Installing Helmを参照してください。

    ./edge-load-oci-artefacts.sh --archive-directory edge-release-oci-tgz-<date> --registry <REGISTRY.YOURDOMAIN.COM:PORT> --source-registry registry.suse.com
33.1.6.1.7 Kubernetesディストリビューションでプライベートレジストリを設定します。
 

RKE2については、Private Registry Configurationを参照してください。

K3sについては、Private Registry Configurationを参照してください。

33.1.6.2 アップグレード手順

 

このセクションでは、次のHelmアップグレード手順のユースケースについて説明します。

  1. 33.1.6.2.1項 「新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合」

  2. 33.1.6.2.2項 「Fleetで管理されているHelmチャートをアップグレードしたい」

  3. 33.1.6.2.3項 「EIB経由でデプロイされたHelmチャートをアップグレードしたい」

重要
重要

手動でデプロイされたHelmチャートは、確実にアップグレードすることはできません。33.1.6.2.1項 「新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合」メソッドを使用してHelmチャートを再デプロイすることをお勧めします。

33.1.6.2.1 新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合
 

このセクションでは、次の方法について説明します。

  1. 33.1.6.2.1.1項 「チャートのFleetリソースを準備する」

  2. 33.1.6.2.1.2項 「チャートのFleetをデプロイする」

  3. 33.1.6.2.1.3項 「デプロイされたHelmチャートを管理する」

33.1.6.2.1.1 チャートのFleetリソースを準備する
 

  1. 使用するEdge releaseタグから、チャートのFleetリソースを取得します。

  2. HelmチャートのFleet（fleets/day2/chart-templates/<chart>）に移動します。

  3. GitOpsワークフローを使用する予定がある場合は、チャートのFleetディレクトリを、GitOpsを実行するGitリポジトリにコピーします。

  4. 必要に応じて、Helmチャートで*values*の設定が必要な場合は、コピーしたディレクトリ内の`.helm.values`ファイルにある`fleet.yaml`設定を編集してください。

  5. 必要に応じて、環境に合わせてチャートのFleetにリソースを追加する必要があるユースケースも考えられます。Fleetディレクトリを拡張する方法については、Git Repository Contentsを参照してください。

注記
注記

場合によっては、FleetがHelm操作に使用するデフォルトのタイムアウトでは不十分であり、次のようなエラーが発生することがあります。

failed pre-install: context deadline exceeded

そのような場合は、`fleet.yaml`ファイルの`helm`設定の下にtimeoutSecondsプロパティを追加してください。

*例*として、`longhorn`ヘルムチャートの場合は次のようになります：

  • ユーザーGitリポジトリの構造：

    <user_repository_root>
├── longhorn
│   └── fleet.yaml
└── longhorn-crd
    └── fleet.yaml

  • `fleet.yaml`ユーザー`Longhorn`データが含まれるコンテンツ：

    defaultNamespace: longhorn-system

helm:
  # timeoutSeconds: 10
  releaseName: "longhorn"
  chart: "longhorn"
  repo: "https://charts.rancher.io/"
  version: "1.11.2"
  takeOwnership: true
  # custom chart value overrides
  values:
    # Example for user provided custom values content
    defaultSettings:
      deletingConfirmationFlag: true

# https://fleet.rancher.io/bundle-diffs
diff:
  comparePatches:
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: engineimages.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: nodes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: volumes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
    注記
    注記

    これらは、`longhorn`チャートに対するカスタム設定を説明するために使用される単なる例の値です。これらは`longhorn`チャートのデプロイメントガイドラインとして扱うべきでは*ありません*。

33.1.6.2.1.2 チャートのFleetをデプロイする
 

GitRepo (33.1.6.2.1.2.1項 「GitRepo」)またはBundle (33.1.6.2.1.2.2項 「バンドル」)のいずれかを使用して、チャートのFleetをデプロイできます。

注記
注記

Fleetのデプロイ中に`Modified`メッセージが表示された場合は、対応する`comparePatches`エントリをFleetの`diff`セクションに必ず追加してください。詳細については、変更されたGitRepoを無視するためのDiffの生成を参照してください。

33.1.6.2.1.2.1 GitRepo
 

FleetのGitRepoリソースには、チャートのFleetリソースにアクセスする方法と、それらのリソースを適用する必要があるクラスターに関する情報が保持されています。

`GitRepo`リソースは、Rancher UIを通じてデプロイするか、または手動で`management cluster`にデプロイすることもできます。

手動*デプロイ用の*Longhorn`GitRepo`リソースの例：

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: longhorn-git-repo
  namespace: fleet-default
spec:
  # If using a tag
  # revision: user_repository_tag
  #
  # If using a branch
  # branch: user_repository_branch
  paths:
  # As seen in the 'Prepare your Fleet resources' example
  - longhorn
  - longhorn-crd
  repo: user_repository_url
  targets:
  # Match all clusters
  - clusterSelector: {}
33.1.6.2.1.2.2 バンドル
 

Bundleリソースには、Fleetによってデプロイされる必要がある生のKubernetesリソースが保持されています。通常は`GitRepo`アプローチの使用が推奨されますが、環境がエアギャップ(された)状態でローカルGitサーバーをサポートできないユースケースでは、`Bundles`がHelmチャートFleetをターゲットクラスターにデプロイするのに役立ちます。

Bundle`は、Rancher UI（`Continuous Delivery → Advanced → Bundles → Create from YAML）を通じて、または正しいFleetネームスペースに`Bundle`リソースを手動でデプロイすることでデプロイできます。Fleetネームスペースの詳細については、アップストリームのドキュメントを参照してください。

Edge Helmチャート用の`Bundles`は、FleetのHelmチャートをバンドルに変換するアプローチを利用して作成できます。

以下に、longhornおよびlonghorn-crd HelmチャートFleetテンプレートから`Bundle`リソースを作成し、このバンドルを`management cluster`に手動でデプロイする方法の例を示します。

注記
注記

ワークフローを説明するために、以下の例ではsuse-edge/fleet-examples ディレクトリ構造を使用しています。

  1. longhornチャートFleetテンプレートに移動します：

    cd fleets/day2/chart-templates/longhorn/longhorn

  2. FleetがHelmチャートをデプロイすべきクラスターを指示する`targets.yaml`ファイルを作成します。

    cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF

    より詳細なダウンストリームクラスターの選択については、ダウンストリームクラスターへのマッピングを参照してください。

  3. fleet-cliを使用して、Longhorn HelmチャートFleetをBundleリソースに変換します。

    注記
    注記

    FleetのCLIは、リリース*アセット*ページ（fleet-linux-amd64）から取得できます。

    Macユーザー向けには、fleet-cliのHomebrew Formulaeが用意されています。

    fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-bundle > longhorn-bundle.yaml

  4. longhorn-crdチャートのFleetテンプレートに移動します。

    cd fleets/day2/chart-templates/longhorn/longhorn-crd

  5. FleetがHelmチャートをデプロイすべきクラスターを指示する`targets.yaml`ファイルを作成します。

    cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF

  6. fleet-cliを使用して、Longhorn CRD HelmチャートFleetをBundleリソースに変換します。

    fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-crd-bundle > longhorn-crd-bundle.yaml

  7. `longhorn-bundle.yaml`および`longhorn-crd-bundle.yaml`ファイルを`management cluster`にデプロイします。

    kubectl apply -f longhorn-crd-bundle.yaml
kubectl apply -f longhorn-bundle.yaml

これらの手順に従うことで、指定されたすべてのdownstreamクラスターに`SUSE Storage`が確実にデプロイされます。

33.1.6.2.1.3 デプロイされたHelmチャートを管理する
 

Fleetでデプロイした後、Helmチャートのアップグレードについては33.1.6.2.2項 「Fleetで管理されているHelmチャートをアップグレードしたい」を参照してください。

33.1.6.2.2 Fleetで管理されているHelmチャートをアップグレードしたい
 

  1. 目的のEdgeリリースと互換性を持たせるために、チャートをアップグレードする必要があるバージョンを決定します。EdgeリリースごとのHelmチャートバージョンは、リリースノート (第41章 「リリースノート」)から確認できます。

  2. Fleetで監視されているGitリポジトリで、Helmチャートの`fleet.yaml`ファイルを編集し、リリースノート (第41章 「リリースノート」)から正しいチャートの*バージョン*と*リポジトリ*を指定します。

  3. 変更をコミットしてリポジトリにプッシュすると、目的のHelmチャートのアップグレードがトリガーされます。

33.1.6.2.3 EIB経由でデプロイされたHelmチャートをアップグレードしたい
 

第8章 「Edge Image Builder」は、`HelmChart`リソースを作成し、RKE2/K3s Helm統合機能によって導入された`helm-controller`を利用することで、Helmチャートをデプロイします。

`EIB`経由でデプロイされたHelmチャートが確実にアップグレードされるように、ユーザーはそれぞれの`HelmChart`リソースに対してアップグレードを行う必要があります。

以下の情報をご覧ください。

33.1.6.2.3.1 概要
 

`EIB`経由でデプロイされたHelmチャートは、eib-charts-upgraderと呼ばれる`fleet`を通じてアップグレードされます。

この`fleet`は、*ユーザー提供*のデータを処理して、特定のHelmChartリソースのセットを*更新*します。

これらのリソースを更新するとhelm-controllerがトリガーされ、変更された`HelmChart`リソースに関連付けられたHelmチャートが*アップグレード*されます。

ユーザーが行う必要があるのは、以下の操作のみです。

  1. アップグレードが必要な各Helmチャートのアーカイブをローカルでプルします。

  2. これらのアーカイブをgenerate-chart-upgrade-data.sh`generate-chart-upgrade-data.sh`スクリプトに渡します。このスクリプトは、これらのアーカイブのデータを`eib-charts-upgrader`Fleetに含めます。

  3. `eib-charts-upgrader`Fleetを`management cluster`にデプロイします。これは、`GitRepo`または`Bundle`リソースのいずれかを通じて行われます。

デプロイされると、`eib-charts-upgrader`はFleetの助けを借りて、そのリソースを目的のdownstreamクラスターに配布します。

これらのリソースには以下が含まれます。

  1. *ユーザー提供*のHelmチャートデータを保持する`Secrets`のセット。

  2. 前述の`Secrets`をマウントし、それに基づいて対応するHelmChartリソースをパッチする`Pod`をデプロイする`Kubernetes Job`。

前述の通り、これにより`helm-controller`がトリガーされ、実際のHelmチャートのアップグレードが実行されます。

上記の説明の図を以下に示します。

fleet day2 downstream helm eib upgrade
33.1.6.2.3.2 アップグレード手順
 

  1. 正しいリリースタグから`suse-edge/fleet-examples`リポジトリをクローンします。

  2. プルしたHelmチャートアーカイブを保存するディレクトリを作成します。

    mkdir archives

  3. 新しく作成したアーカイブディレクトリ内で、アップグレードするHelmチャートのアーカイブをpullします：

    cd archives
helm pull [chart URL | repo/chartname]

# Alternatively if you want to pull a specific version:
# helm pull [chart URL | repo/chartname] --version 0.0.0

  4. 目的のリリースタグの*アセット*から、`generate-chart-upgrade-data.sh`スクリプトをダウンロードします。

  5. `generate-chart-upgrade-data.sh`スクリプトを実行します：

    chmod +x ./generate-chart-upgrade-data.sh

./generate-chart-upgrade-data.sh --archive-dir /foo/bar/archives/ --fleet-path /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader

    --archive-dir`ディレクトリ内の各チャートアーカイブに対して、スクリプトはチャートのアップグレードデータを含む`Kubernetes Secret YAML`ファイルを生成し、--fleet-path`で指定されたFleetの`base/secrets`ディレクトリに保存します。

    `generate-chart-upgrade-data.sh`スクリプトは、生成された`Kubernetes Secret YAML`ファイルがFleetによってデプロイされたワークロードで正しく使用されるように、Fleetに追加の変更を適用します。

    重要
    重要

    ユーザーは、`generate-chart-upgrade-data.sh`スクリプトが生成するものに対して変更を加えるべきではありません。

以下の手順は、実行している環境によって異なります：

  1. GitOpsをサポートしている環境（例：エアギャップ環境ではない、またはエアギャップ環境だがローカルGitサーバーのサポートが許可されている場合）の場合：

    1. GitOpsに使用するリポジトリに`fleets/day2/eib-charts-upgrader` Fleetをコピーします。

      注記
      注記

      `generate-chart-upgrade-data.sh`スクリプトによって行われた変更がFleetに含まれていることを確認してください。

    2. eib-charts-upgrader Fleetのすべてのリソースを配送するために使用される`GitRepo`リソースを設定します。

      1. Rancher UIを通じた`GitRepo`の設定とデプロイについては、Rancher UIでのFleetへのアクセスを参照してください。

      2. `GitRepo`の手動設定とデプロイについては、デプロイの作成を参照してください。

  2. GitOpsをサポートしていない環境（例：エアギャップで、ローカルGitサーバーの使用が許可されていない場合）の場合：

    1. rancher/fleet`のリリースページから`fleet-cli`バイナリをダウンロードします（Linuxの場合は`fleet-linux-amd64）。Macユーザー向けには、使用可能なHomebrew Formulaeがあります - fleet-cli。

    2. eib-charts-upgrader Fleetに移動します：

      cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader

    3. どこにデプロイするかをFleetに指示する`targets.yaml`ファイルを作成します：

      cat > targets.yaml <<EOF
targets:
# To match all downstream clusters
- clusterSelector: {}
EOF

      ターゲットクラスターのマッピング方法については、アップストリーム ドキュメント を参照してください。

    4. fleet-cli を使用して、Fleet を Bundle リソースに変換します。

      fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml

      これにより、eib-charts-upgrader Fleet からのすべてのテンプレート化されたリソースを保持する Bundle (bundle.yaml) が作成されます。

      fleet apply コマンドの詳細については、「fleet apply」を参照してください。

      Fleet を Bundle に変換する方法の詳細については、「Convert a Helm Chart into a Bundle」を参照してください。

    5. Bundle をデプロイする。これには、次の2つの方法があります。

      1. Rancher の UI を使用する場合 - 継続的デリバリ → Advanced → Bundles → Create from YAML に移動し、bundle.yaml の内容を貼り付けるか、Read from File オプションをクリックしてファイル自体を渡します。

      2. 手動 - bundle.yaml ファイルを`management cluster`内にデプロイします。

これらの手順を実行すると、GitRepo/Bundle リソースが正常にデプロイされます。このリソースは Fleet によって取得され、その内容はユーザーが前の手順で指定したターゲットクラスターにデプロイされる。この処理の概要については、「33.1.6.2.3.1項 「概要」」を参照してください。

アップグレードの処理を追跡する方法については、33.1.6.2.3.3項 「例」 を参照してください。

重要
重要

チャートのアップグレードが正常に確認できたら、Bundle/GitRepo リソースを削除する。

これにより、不要になったアップグレードリソースを downstream クラスターから削除することで、将来的なバージョン競合の発生を防ぐことができます。

33.1.6.2.3.3 例
 
注記
注記

以下の例は、EIB を介してデプロイされた Helm チャートを downstream クラスター上で別のバージョンにアップグレードする方法を示しています。この例で使用されているバージョンは*推奨されているものではありません*のでご注意ください。Edge リリース固有の推奨バージョンについては、「リリースノート (第41章 「リリースノート」)」を参照してください。

使用事例:

  • `doc-example`という名前のクラスターで、Longhornの古いバージョンが実行されています。

  • クラスターはEIBを通じてデプロイされており、次のイメージ定義_snippet_を使用しています。

    kubernetes:
  helm:
    charts:
    - name: longhorn-crd
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    - name: longhorn
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    repositories:
    - name: rancher-charts
      url: https://charts.rancher.io/
...

  • SUSE Storage`は、Edge 3.6リリースと互換性のあるバージョンにアップグレードする必要があります。つまり、1.11.2`にアップグレードする必要があります。

  • `management cluster`の管理を担当する`doc-example`は*エアギャップ(された)*であり、ローカルGitサーバーのサポートがなく、Rancherが正常にセットアップされていると想定されます。

アップグレード手順 (33.1.6.2.3.2項 「アップグレード手順」)に従ってください。

  1. `release-3.6.1`タグから`suse-edge/fleet-example`リポジトリをクローンします。

    git clone -b release-3.6.1 https://github.com/suse-edge/fleet-examples.git

  2. `Longhorn`アップグレードアーカイブを保存するディレクトリを作成します。

    mkdir archives

  3. 目的の`Longhorn`チャートアーカイブバージョンをプルします。

    # First add the Rancher Helm chart repository
helm repo add rancher-charts https://charts.rancher.io/

# Pull the Longhorn 1.11.2 chart archive
helm pull oci://dp.apps.rancher.io/charts/suse-storage --version 1.11.2

  4. `archives`ディレクトリの外で、`suse-edge/fleet-examples`リリースtagから`generate-chart-upgrade-data.sh`スクリプトをダウンロードします。

  5. ディレクトリのセットアップは次のようになります。

    .
├── archives
│   └── longhorn-1.11.2.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
|   |   |   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       └── kustomization.yaml
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

  6. `generate-chart-upgrade-data.sh`スクリプトを実行します：

    # First make the script executable
chmod +x ./generate-chart-upgrade-data.sh

# Then execute the script
./generate-chart-upgrade-data.sh --archive-dir ./archives --fleet-path ./fleet-examples/fleets/day2/eib-charts-upgrader

    スクリプト実行後のディレクトリ構造は次のようになります。

    .
├── archives
│   └── longhorn-1.11.2.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
│   │   │   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       ├── kustomization.yaml
│   │   │   │   │       ├── longhorn-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   │       └── longhorn-crd-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

    gitで変更されたファイルは次のようになります。

    Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   fleets/day2/eib-charts-upgrader/base/patches/job-patch.yaml
    modified:   fleets/day2/eib-charts-upgrader/base/secrets/kustomization.yaml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-VERSION.yaml
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-crd-VERSION.yaml

  7. Bundle Fleet用の`eib-charts-upgrader`を作成します。

    1. まず、Fleet自体に移動します。

      cd ./fleet-examples/fleets/day2/eib-charts-upgrader

    2. 次に、`targets.yaml`ファイルを作成します。

      cat > targets.yaml <<EOF
targets:
- clusterName: doc-example
EOF

    3. 次に、`fleet-cli`バイナリを使用してFleetをBundleに変換します。

      fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml

    4. 次に、`bundle.yaml`マシン上の`management cluster`を転送します。

  8. Rancher UIからBundleをデプロイします：

    day2 helm chart upgrade example 1
    図 33.1: Rancher UIからBundleをデプロイする
     

    ここから、*Read from File*を選択し、システム上の`bundle.yaml`ファイルを見つけます。

    これにより、RancherのUI内で`Bundle`が自動的に入力されます。

    ［Create］を選択します。

  9. デプロイが成功すると、Bundleは次のようになります：

    day2 helm chart upgrade example 2
    図 33.2: Bundleのデプロイに成功しました
     

`Bundle`のデプロイが成功した後、アップグレードの処理を監視するには：

  1. `Upgrade Pod`のログを確認します：

    day2 helm chart upgrade example 3 downstream

  2. 次に、helm-controllerによってアップグレード用に作成されたPodのログを確認します：

    1. Pod名は次のテンプレートになります - helm-install-longhorn-<random-suffix>

    2. Podは、`HelmChart`リソースがデプロイされたネームスペースに配置されます。今回の場合は`kube-system`です。

      day2 helm chart upgrade example 4 downstream
      図 33.3: 正常にアップグレードされたLonghornチャートのログ
       

  3. Rancherの`HelmCharts`セクション（More Resources → HelmCharts）に移動して、`HelmChart`のバージョンが更新されていることを確認します。チャートがデプロイされたネームスペースを選択します。この例では`kube-system`になります。

  4. 最後に、Longhorn Podが実行されていることを確認します。

上記の検証を行った後、Longhorn Helmチャートが`1.11.2`バージョンにアップグレードされたと判断して問題ありません。

33.1.6.2.3.4 サードパーティのGitOpsツールを使用したHelmチャートのアップグレード
 

Fleet以外のGitOpsワークフロー（例：Flux）でこのアップグレード手順を使用したいというユースケースがあるかもしれません。

アップグレード手順に必要なリソースを作成するには、generate-chart-upgrade-data.sh スクリプトを使用して、ユーザーが提供したデータで eib-charts-upgrader Fleet を設定できます。この方法の詳細については、33.1.6.2.3.2項 「アップグレード手順」を参照してください。

セットアップが完了したら、Kustomize を使用して、クラスターにデプロイ可能な完全に機能するソリューションを生成できます。

cd /foo/bar/fleets/day2/eib-charts-upgrader

kustomize build .

GitOps ワークフローにソリューションを含める場合は、fleet.yaml ファイルを削除し、残りの部分を有効な Kustomize セットアップとして使用できます。最初に generate-chart-upgrade-data.sh スクリプトを実行して、アップグレード先の Helm チャートのデータで Kustomize セットアップを設定できるようにすることを忘れないでください。

このワークフローの使用方法を理解するには、33.1.6.2.3.1項 「概要」 と 33.1.6.2.3.2項 「アップグレード手順」 を参照すると役立ちます。

パート VII トラブルシューティング

 

このセクションでは、SUSE Edgeのデプロイメントと運用に関する一般的な問題を診断および解決するためのガイダンスを提供します。コンポーネント固有のトラブルシューティング手順、主要なツール、関連するログの場所など、さまざまなトピックを扱います。

34 一般的なトラブルシューティングの原則

 

コンポーネント固有の問題に取り組む前に、以下の一般的な原則を考慮してください。

  • ログを確認する:ログは情報の主要なソースです。多くの場合、エラーは自己説明的であり、何が失敗したかについてのヒントが含まれています。

  • クロックを確認する:システム間でクロックに差異があると、あらゆる種類の異なるエラーにつながる可能性があります。クロックが同期されていることを確認してください。EIBは起動時にクロック同期を強制するように指示できます。OS時刻の設定 (第2章 「Edge Image Builderを使用したスタンドアロンクラスター」)を参照してください。

  • 起動の問題:システムが起動中に停止した場合は、最後に表示されたメッセージを記録してください。コンソール（物理的またはBMC経由）にアクセスして、起動メッセージを確認してください。

  • ネットワークの問題:ネットワークインタフェースの設定（ip a）、ルーティングテーブル（ip route）を確認し、他のノードや外部サービスとの接続性をテストしてください（ping、nc）。ファイアウォールのルールが必要なポートをブロックしていないことを確認してください。

  • コンポーネントの状態を確認する:Kubernetesリソースには`kubectl get`および`kubectl describe`を使用してください。特定のKubernetesネームスペースのイベントを確認するには、`kubectl get events --sort-by='.lastTimestamp' -n <namespace>`を使用してください。

  • サービスの状態を確認する:systemdサービスには`systemctl status <service>`を使用してください。

  • 構文の確認:ソフトウェアは、設定ファイルに対して特定の構造と構文を想定しています。例えばyamlファイルの場合、`yamllint`や同様のツールを使用して、適切な構文であることを確認してください。

  • 問題の切り分け:問題を特定のコンポーネントまたは階層（ネットワーク、ストレージ、OS、Kubernetes、Metal3、Ironicなど…​）に絞り込むようにしてください。

  • ドキュメント:詳細については、常に公式の SUSE Edgeドキュメントおよびアップストリームドキュメントを参照してください。

  • バージョン: SUSE Edgeは、さまざまなSUSEコンポーネントを対象に、独自の設計思想に基づいて徹底的にテストされたバージョンです。各SUSE Edgeリリースの各コンポーネントのバージョンは、 SUSE Edgeサポートマトリックスで確認できます。

  • 既知の問題:各SUSE Edgeリリースには、リリースノートに「既知の問題」セクションがあり、将来のリリースで修正される予定ですが、現在のリリースに影響を与える可能性のある問題に関する情報が記載されています。

35 Kiwiのトラブルシューティング

 

Kiwiは、Edge Image Builderで使用する更新されたSUSE Linux Microイメージを生成するために使用されます。

よくある問題
 

  • SL Microのバージョン不一致:ビルドホストのオペレーティングシステムバージョンは、ビルド対象のオペレーティングシステムバージョンと一致している必要があります（SL Micro 6.0ホスト → SL Micro 6.0イメージ）。

  • SELinuxがEnforcing状態:特定の制限により、現在Kiwiでイメージをビルドするには、一時的にSELinuxを無効にする必要があります。`getenforce`でSELinuxの状態を確認し、`setenforce 0`でビルドプロセスを実行する前に無効にしてください。

  • ビルドホストが登録されていません:ビルドプロセスでは、SUSE SCCからパッケージを取得するためにビルドホストのサブスクリプションを使用します。ホストが登録されていないと失敗します。

  • ループデバイスのテスト失敗:Kiwiビルドプロセスを初めて実行すると、開始直後に「ERROR:」で失敗します。「Early loop device test failed, please retry the container run.」というエラーは、基盤となるホストシステム上で作成されたループデバイスが、コンテナイメージ内で即座に認識されないことに起因する現象です。Kiwiビルドプロセスを再度実行すれば、問題なく進行するはずです。

  • 権限の不足:ビルドプロセスは、ルートユーザ（またはsudo経由）として実行されることを想定しています。

  • 権限が正しくありません:ビルドプロセスでは、コンテナの実行時に --privileged フラグが必要です。それが存在することを再確認してください。

ログ
 

  • ビルドコンテナログ:ビルドコンテナのログを確認してください。ログは、アーティファクトの保存に使用されたディレクトリに生成されます。必要な情報については、docker logsまたはpodman logsも確認してください。

  • 一時ビルドディレクトリ:Kiwiはビルドプロセス中に一時ディレクトリを作成します。メインの出力で不十分な場合は、これらの中間ログやアーティファクトを確認してください。

問題の対策の手順
 

  1. * build-image 出力の確認*:コンソール出力のエラーメッセージは、通常、非常に示唆に富んでいます。

  2. ビルド環境の確認:Kiwi自体に必要なすべての前提条件（例：docker/podman、SELinux、十分なディスク容量）が、Kiwiを実行しているマシンで満たされていることを確認してください。

  3. ビルドコンテナのログを確認:失敗したコンテナのログを確認して、より詳細なエラーがないか調べてください（上記を参照）。

  4. 定義ファイルの検証:カスタムKiwiイメージ定義ファイルを使用している場合は、ファイルに誤字や構文エラーがないか再確認してください。

注記
注記

Kiwiトラブルシューティングガイドを確認してください。

36 Edge Image Builder (EIB) のトラブルシューティング

 

EIBは、カスタムSUSE Edgeイメージの作成に使用されます。

よくある問題
 

  • SCCコードが間違っています:EIB定義ファイルで使用されているSCCコードが、SL Microのバージョンおよびアーキテクチャと一致していることを確認してください。

  • 依存関係が不足しています:ビルド環境内に不足しているパッケージやツールがないことを確認してください。

  • イメージサイズが正しくありません:rawイメージの場合、`diskSize`パラメーターが必要であり、これはイメージに含まれるイメージ、RPM、およびその他のアーティファクトに大きく依存します。

  • 権限:カスタム/ファイルディレクトリにスクリプトを保存する場合は、それらのファイルはcombustion時に利用可能になるだけでEIBによって変更は行われないため、実行権限があることを確認してください。

  • オペレーティングシステムのグループ依存関係:カスタムユーザーおよびグループでイメージを作成する場合、"`primaryGroup`"として設定されるグループは明示的に作成する必要があります。

  • オペレーティングシステムのユーザーのSSHキーにはホームフォルダーが必要です:SSHキーを持つユーザーでイメージを作成する場合、`createHomeDir=true`を使用してホームフォルダーも作成する必要があります。

  • Combustionの問題:EIBは、OSのカスタマイズおよびその他すべてのSUSE Edgeコンポーネントのデプロイメントをcombustionに依存しています。これには、custom/scriptsフォルダーに配置されるカスタムスクリプトも含まれます。combustion処理は`initrd`時に実行されるため、スクリプトが実行される時点ではシステムは完全に起動していないことに注意してください。

  • Podmanマシンのサイズ:EIBのヒントとコツのセクション (パートIV「ヒントとトラブルシューティング」)で説明されているように、Linux以外のオペレーティングシステムでEIBコンテナを実行するために、podmanマシンに十分なCPU/メモリがあることを確認してください。

  • 不適切なイメージ:使用しているベースイメージが、 `checksum`を検証することで適切にダウンロードされていることを確認してください。kiwi-builder (第26章 「Kiwiを使用して更新されたSUSE Linux Microイメージを構築する」)を使用してイメージをビルドしている場合は、プロセスによって生成されたsumファイルも確認してください。

ログ
 

  • EIB出力:`eib build`コマンドのコンソール出力は非常に重要です。

  • ビルドコンテナログ:ビルドコンテナのログを確認してください。ログは、アーティファクトの保存に使用されたディレクトリに生成されます。必要な情報については、`docker logs`または`podman logs`も確認してください。

    注記
    注記

    詳細については、 デバッグを参照してください。

  • 一時ビルドディレクトリ:EIBは、ビルドプロセス中に一時ディレクトリを作成します。メインの出力で不十分な場合は、これらの中間ログやアーティファクトを確認してください。

  • Combustionログ:EIBでビルドされたイメージが何らかの理由で起動しない場合は、ルートシェルが利用可能です。ホストコンソール（物理的、BMC経由など）に接続し、`journalctl -u combustion`でCombustionログを確認してください。また、エラーの根本原因を特定するために、`journalctl`を使用してオペレーティングシステムのログ全般を確認してください。

問題の対策の手順
 

  1. 出力`eib-build`の確認:コンソール出力のエラーメッセージは、通常、非常に重要な情報を示しています。

  2. ビルド環境の確認:EIB自体に必要なすべての前提条件（例：docker/podman、十分なディスク容量など）が、EIBを実行しているマシンで満たされていることを確認してください。

  3. ビルドコンテナのログを調査する:失敗したコンテナのログを確認し、より詳細なエラーがないか調べてください（上記を参照）。

  4. の設定`eib`を検証する: `eib`の設定ファイルに誤字がないか、またはソースファイルやビルドスクリプトへのパスが正しく指定されているかを再確認してください。

    • コンポーネントを個別にテストする:EIBビルドにカスタムスクリプトやステージが含まれている場合は、それらを個別に実行してエラー箇所を特定してください。

注記
注記

Edge Image Builderのデバッグを確認してください。

37 エッジネットワークのトラブルシューティング (NMC)

 

NMCはSL Micro EIBイメージに注入され、combustionを介して起動時にエッジホストのネットワークを設定します。また、検査プロセスの一環としてMetal3ワークフローでも実行されます。ホストの初回起動時やMetal3検査プロセスで問題が発生することがあります。

よくある問題
 

  • 初回起動時にホストが正常に起動できない:ネットワーク定義ファイルが不正な場合、combustionフェーズが失敗し、ホストがルートシェルをドロップすることがあります。

  • ファイルが正しく生成されない:ネットワークファイルが NMState形式と一致していることを確認してください。

  • ネットワークインタフェースが正しく設定されていない:ホストで使用されているネットワークインタフェースとMACアドレスが一致していることを確認してください。

  • ネットワークインタフェース名の不一致:SL Microはデフォルトで ネットワークインターフェースの予測可能な命名スキームを有効にしているため、`eth0`は存在せず、代わりに`enp2s0`のような他の命名スキームが使用されます。

ログ
 

  • Combustionログ:nmcはCombustion時に使用されるため、プロビジョニング中のホストで`journalctl -u combustion`を使用してCombustionログを確認してください。

問題の対策の手順
 

  1. yaml構文の検証: nmc設定ファイルはyamlファイルです。`yamllint`や同様のツールを使用して適切な構文であることを確認してください。

  2. nmcの手動実行:nmcはEIBコンテナの一部であるため、問題をデバッグするにはローカルのpodmanコマンドを使用できます。

    1. nmcファイルを保存するための一時フォルダーを作成してください。

      mkdir -p ${HOME}/tmp/foo

    2. その場所にnmcファイルを保存してください。

      ❯ tree --noreport ${HOME}/tmp/foo
/Users/johndoe/tmp/foo
├── host1.example.com.yaml
└── host2.example.com.yaml

    3. nmcをエントリーポイントとし、generateコマンドを指定してEIBコンテナを実行し、コンバッション時にnmcが行うのと同じタスクを実行してください：

      podman run -it --rm -v ${HOME}/tmp/foo:/tmp/foo:Z --entrypoint=/usr/bin/nmc registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 generate --config-dir /tmp/foo --output-dir /tmp/foo/

[2025-06-04T11:58:37Z INFO  nmc::generate_conf] Generating config from "/tmp/foo/host2.example.com.yaml"...
[2025-06-04T11:58:37Z INFO  nmc::generate_conf] Generating config from "/tmp/foo/host1.example.com.yaml"...
[2025-06-04T11:58:37Z INFO  nmc] Successfully generated and stored network config

    4. ログと、一時フォルダーに生成されるファイルを確認してください。

38 Phone-Homeシナリオのトラブルシューティング

 

Phone-homeシナリオでは、Elementalを使用して管理クラスターに接続し、EIBを使ってelemental-registrationビットを含むOSイメージを作成します。ホストの初回起動時、EIBビルドプロセス中、または管理クラスターへの登録を試行する際に問題が発生する可能性があります。

よくある問題
 

  • システムの登録に失敗:ノードがUIに登録されません。ホストが正常に起動しており、Rancherと通信でき、時計が同期されており、Elementalサービスが正常であることを確認してください。

  • システムのプロビジョニングに失敗:ノードは登録されていますが、プロビジョニングに失敗します。ホストがRancherと通信でき、時計が同期されており、Elementalサービスが正常であることを確認してください。

ログ
 

  • システムログ: journalctl

  • Elemental-system-agentログ: journalctl -u elemental-system-agent

  • K3s/RKE2ログ: journalctl -u k3s or journalctl -u rke2-server (または rke2-agent)

  • Elemental operatorポッド: kubectl logs -n cattle-elemental-system -l app=elemental-operator

問題の対策の手順
 

  1. ログの確認:Elemental operatorポッドのログを確認して、問題がないか調べます。ノードが起動している場合は、ホストのログを確認します。

  2. MachineRegistrationとTPMの確認:デフォルトでは、 認証にTPMが使用されますが、TPMがないホスト向けの代替手段もあります。

39 その他のコンポーネントのトラブルシューティング

 

その他の SUSE Edge コンポーネントのトラブルシューティングガイドについては、各公式ドキュメントを参照してください。

SUSE ナレッジベースも参照できます。

40 サポートのための診断情報の収集

 

SUSEサポートに問い合わせる際は、包括的な診断情報を提供することが不可欠です。

収集すべき重要な情報
 

  • 詳細な問題の説明:何が起きたのか、いつ起きたのか、何をしていたのか、期待される動作は何か、そして実際の動作は何か？

  • 再現手順:その問題を確実に再現できますか？再現できる場合は、正確な手順をリストアップしてください。

  • コンポーネントバージョン: SUSE Edge バージョン、コンポーネントバージョン（RKE2/K3、EIB、Metal3、Elementalなど）。

  • 関連ログ:

    • journalctl 出力（可能であればサービスでフィルタリングしたもの、または完全なブートログ）。

    • Kubernetesポッドログ（kubectl logs）。

    • Metal³/Elementalコンポーネントログ。

    • EIBビルドログおよびその他のログ

  • システム情報:

    • uname -a

    • df -h

    • ip a

    • /etc/os-release

  • 設定ファイル:Elemental、Metal3、EIBに関連する設定ファイル（helmチャートの値、configmapなど）。

  • Kubernetes情報:ノード、サービス、デプロイメントなど。

  • 影響を受けるKubernetesオブジェクト:BMH、MachineRegistrationなど。

収集方法
 

  • ログの場合:コマンドの出力をファイルにリダイレクトします（例: journalctl -u k3s > k3s_logs.txt）。

  • Kubernetesリソースの場合:詳細なYAML定義を取得するには、`kubectl get <resource> -o yaml > <resource_name>.yaml`を使用します。

  • システム情報の場合:上記にリストされているコマンドの出力を収集します。

  • SL Microの場合:`supportconfig`のサポートのためのシステム情報収集方法については、 SUSE Linux Micro Troubleshooting Guideのドキュメントを確認してください。

  • RKE2/Rancherの場合:https://www.suse.com/support/kb/doc/?id=000020191[The Rancher v2.x Linux log collector script]の記事を確認して、Rancher v2.x Linuxログ収集スクリプトを実行してください。

  • Edge (Nessie) の場合:Nessie 1.1.0は、SUSE Edge環境からログと設定データを収集するように設計された強力な診断ツールです。ホストシステムとKubernetesクラスターの両方から包括的な情報を収集するため、トラブルシューティングやサポートに非常に役立ちます。

    • Nessieには、Kubernetesモードとシステムモードという2つの「モード」があります。

      • SUSE Edgeクラスターからログを収集するには、（ローカルでkubeconfigファイルにアクセスできることを前提として）以下を実行します。

        podman run --rm --privileged \
  -v /etc/rancher/k3s/k3s.yaml:/etc/rancher/k3s/k3s.yaml:ro \
  -v /var/log/journal:/var/log/journal:ro \
  -v /run/systemd:/run/systemd:ro \
  -v /etc/machine-id:/etc/machine-id:ro \
  -v /tmp:/tmp \
  -e NESSIE_LOG_DIR="/tmp" \
  -e NESSIE_ZIP_DIR="/tmp" \
  registry.suse.com/edge/3.6/nessie:1.1.0
        注記
        注記

        必要に応じて`k3s.yaml/rke2.yaml`ファイルのパスを調整してください。詳細については、 Nessieを参照してください。 適切な権限がある場合は、非特権モードでこのコンテナを実行できるはずです（通常、k3s.yaml / `rke2-server.yaml`ファイルはルートが所有しています）。

      • 実際のオペレーティングシステムからシステムモードでログを収集するには、次を実行してください：

        podman run --rm --privileged \
  -v /var/log/journal:/var/log/journal:ro \
  -v /run/systemd:/run/systemd:ro \
  -v /etc/machine-id:/etc/machine-id:ro \
  -v /tmp:/tmp \
  -e NESSIE_LOG_DIR="/tmp" \
  -e NESSIE_ZIP_DIR="/tmp" \
  -e NESSIE_VERBOSE="1" \
  -e NESSIE_SKIP_POD_LOGS="true" \
  -e NESSIE_SKIP_K8S_CONFIGS="true" \
  -e NESSIE_SKIP_METRICS="true" \
  registry.suse.com/edge/3.6/nessie:1.1.0
        注記
        注記

        環境でNessieを実行する方法の詳細や情報については、必ず Nessieを確認してください。 同様に、適切な権限があれば、非特権モードでこのコンテナを実行できるはずです。

[技術サポートの連絡先]. SUSEサポートへの連絡方法の詳細については、 ハウツー: SUSE Technical Supportとの効果的な連携方法で入手可能な記事と、 SUSE Technical Support Handbookにあるサポートハンドブックを確認してください。

パート VIII 付録

 
  • 41 リリースノート

    • SUSE Edge 3.6は、エッジにおけるインフラストラクチャおよびクラウドネイティブアプリケーションのデプロイという独自の課題に対処するための、緊密に統合され、包括的に検証されたエンドツーエンドのソリューションです。その主な目的は、初期デプロイメントのイメージ構築、ノードのプロビジョニングとオンボーディング、アプリケーションのデプロイ、監視、ライフサイクル管理にわたって、独自の設計思想を持ちながらも非常に柔軟で、拡張性が高く、安全なプラットフォームを提供することです。

41 リリースノート

 

41.1 抽象データ型

 

SUSE Edge 3.6は、エッジにおけるインフラストラクチャおよびクラウドネイティブアプリケーションのデプロイという独自の課題に対処するための、緊密に統合され、包括的に検証されたエンドツーエンドのソリューションです。その主な目的は、初期デプロイメントのイメージ構築、ノードのプロビジョニングとオンボーディング、アプリケーションのデプロイ、監視、ライフサイクル管理にわたって、独自の設計思想を持ちながらも非常に柔軟で、拡張性が高く、安全なプラットフォームを提供することです。

このソリューションは、お客様の要件や期待が大きく異なるため、「万能な」エッジプラットフォームは存在しないという考えに基づいて設計されています。エッジデプロイメントは、大規模なスケーラビリティ、制限されたネットワーク可用性、物理的なスペースの制約、新しいセキュリティの脅威と攻撃ベクトル、ハードウェアアーキテクチャとシステムリソースの多様性、レガシーインフラストラクチャおよびアプリケーションとのデプロイとインターフェースの要件、そして寿命が長い顧客ソリューションなど、最も困難な問題のいくつかを解決し、継続的に進化させることを私たちに求めています。

SUSE Edgeは、安全で安定した認定済みのSUSE Linuxプラットフォームを提供してきた30年の歴史と、Rancherポートフォリオによる拡張性が高く機能豊富なKubernetes管理を提供してきた経験の両方と一貫して、ゼロから最高クラスのオープンソースソフトウェアに基づいて構築されています。SUSE Edgeは、これらの機能を基盤として、小売、医療、輸送、物流、電気通信、スマートマニュファクチャリング、産業用IoTなど、幅広い市場セグメントの要件に対処できる機能を提供します。

SUSE Edgeの製品サポートライフサイクルの更新に関する詳細については、Product Support Lifecycleを参照してください。

注記
注記

SUSE Telco CloudはSUSE Edgeの派生製品であり、電気通信のユースケースで見られる要件にプラットフォームが対応できるようにするための追加の最適化とコンポーネントを備えています。

41.2 バージョン情報

 

これらのリリースノートは、明示的に指定および説明されている場合を除き、すべてのアーキテクチャで同一であり、最新バージョンは、他のすべてのSUSE製品のリリースノートとともに、オンラインの https://www.suse.com/releasenotesで常に入手可能です。

項目は一度だけリストされますが、重要であり、複数のセクションに該当する場合は、複数の場所で参照されることがあります。リリースノートには通常、2つの連続するリリースの間に行われた変更のみが記載されます。以前の製品バージョンのリリースノートからの重要な項目が繰り返される場合があります。これらの項目を識別しやすくするために、その旨を記載した注記が含まれています。

ただし、繰り返される項目は便宜上提供されているに過ぎません。したがって、1つ以上のリリースをスキップする場合は、スキップしたリリースのリリースノートも確認してください。現在のリリースのリリースノートのみを読んでいると、システム動作に影響を与える可能性のある重要な変更を見逃す可能性があります。SUSE Edgeのバージョンはx.y.zとして定義されます。ここで「x」はメジャーバージョン、「y」はマイナーバージョン、「z」はパッチバージョン（「zストリーム」とも呼ばれます）を示します。SUSE Edgeの製品ライフサイクルは、特定のマイナーリリースに基づいて定義されます（例:）。「3.6」ですが、そのライフサイクルを通じて後続のパッチアップデートとともに出荷されます（例:）。"3.6.1".

注記
注記

SUSE Edgeのzストリームリリースは、バージョン管理されたスタックとして緊密に統合され、徹底的にテストされています。上記以外のバージョンへの個々のコンポーネントのアップグレードは、システムダウンタイムを引き起こす可能性があります。テストされていない構成でEdgeクラスターを実行することは可能ですが、推奨はされず、サポートチャネルを通じた解決に時間がかかる場合があります。

41.3 リリース 3.6.1

 

提供開始日:2026年6月26日

フルサポート終了日:2026年11月27日

メンテナンスサポート終了日:2028年5月27日

EOL:2028年5月28日

まとめ:SUSE Edge 3.6.1は、SUSE Edge 3.6リリースストリームにおける最初のz-streamリリースです。

41.3.1 新機能

 

41.3.2 バグ修正およびセキュリティ更新

 

41.3.3 既知の問題

 
警告
警告

新しいクラスターをデプロイする場合は、第26章 「Kiwiを使用して更新されたSUSE Linux Microイメージを構築する」 に従って最初に新しいイメージをビルドしてください。 これは、イメージに最新のセキュリティ修正およびバグ修正が含まれていることを確認するために、管理クラスターおよびダウンストリームクラスターに対して推奨されます。

  • Edge Image Builderを介してデプロイする場合、HelmChartConfigs マニフェストを kubernetes/manifests 設定ディレクトリに配置すると失敗する可能性があります。代わりに、EIBのos-filesインターフェースを使用して、HelmChartConfigs を /var/lib/rancher/{rke2/k3s}/server/manifests/ に配置することを推奨します。 これを行わないと、 #8357 RKE2 issueで説明されているように、初期起動時にノードが NotReady 状態のままになる可能性があります。

  • RKE2/K3s 1.34および1.35バージョンでは、CNI設定の保存に使用されるディレクトリ /etc/cni が、overlayfs に関連する特定の条件により、そこに書き込まれるファイルに関する通知を containerd にトリガーしない場合があります（ #8356 RKE2 issueを参照）。その結果、RKE2/K3sのデプロイメントがCNIの起動待ちでスタックし、RKE2/K3sノードが NotReady 状態のままになります。これは、ノードレベルで kubectl describe node <affected_node> を使用して確認できます。

Conditions:
  Type   Status  LastHeartbeatTime                LastTransitionTime               Reason           Message
  ----   ------  -----------------                ------------------               ------           -------
  Ready  False   Thu, 05 Jun 2025 17:41:28 +0000  Thu, 05 Jun 2025 14:38:16 +0000  KubeletNotReady  container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

回避策として、RKE2の起動前に /etc/cni ディレクトリにtmpfsボリュームをマウントすることができます。これにより、containerdが通知を見逃す原因となるoverlayfsの使用を回避でき、ノードが再起動され、ポッドのinitcontainersが再度実行されるたびに設定が書き直されるはずです。EIBを使用している場合、これは`04-tmpfs-cni.sh`スクリプトが`custom/scripts`ディレクトリ内にあり（ こちらで説明）、次のようになります。

#!/bin/bash
mkdir -p /etc/cni
mount -t tmpfs -o mode=0700,size=5M tmpfs /etc/cni
echo "tmpfs /etc/cni tmpfs defaults,size=5M,mode=0700 0 0" >> /etc/fstab

  • 現段階では、synce4lを介したSyncEおよびgpsdを介したGNSSを設定するための公式ドキュメントや例は提供されておらず、これらのトピックは今後のリリースで取り上げられる予定です。

  • 一部のコンテナリポジトリは現在IPv4経由でのみアクセス可能なため、IPv6のみのダウンストリームクラスターには、管理クラスター上のローカルレジストリが必要です。

41.3.4 コンポーネントのバージョン

 

以下の表は、3.6.1リリースを構成する個々のコンポーネントについて、バージョン、Helmチャートのバージョン（該当する場合）、およびバイナリ形式でリリースされたアーティファクトの取得元を説明しています。使用方法やデプロイメントの例については、関連するドキュメントに従ってください。

名前

バージョン

Helmチャートのバージョン

アーティファクトの場所 (URL/イメージ)

SUSE Linux Micro

6.2 (latest)

N/A

SUSE Linux Micro ダウンロードページ

SUSE Linux Micro

6.2 (latest)

N/A

チェックサムと署名は、 SUSE Linux Micro ダウンロードページからダウンロードできます。
SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
SL-Micro.x86_64-6.2-Base-RT-SelfInstall-GM.install.iso
SL-Micro.x86_64-6.2-Base-GM.raw.xz
SL-Micro.x86_64-6.2-Base-RT-GM.raw.xz

SUSE Multi-Linux Manager

5.1

N/A

SUSE Multi-Linux Manager ダウンロードページ

K3s

1.35.4

N/A

アップストリーム K3s リリース

RKE2

1.35.4

N/A

Upstream RKE2 Release

SUSE Rancher Prime

2.14.2

2.14.2

Rancher Prime Helm リポジトリ
https://prime.ribs.rancher.io/rancher/v2.14.2/rancher-images.txt[Rancher 2.14.2 Container Images]

SUSE Storage (Longhorn)

1.11.2

1.11.2

SUSE Storage Helm リポジトリ
https://apps.rancher.io/applications/suse-storage/components[SUSE Storage Container Images]

SUSE Security (NeuVector)

5.5.2

109.0.2+up2.10.2

Rancher Charts Helm リポジトリ
registry.rancher.com/rancher/neuvector-controller:5.5.2
registry.rancher.com/rancher/neuvector-enforcer:5.5.2
registry.suse.com/rancher/neuvector-compliance-config:1.0.12

Rancher Turtles プロバイダー (CAPI)

0.26.2

306.0.7+up0.26.2

registry.suse.com/edge/3.6/rancher-turtles-providers-chart:306.0.7+up0.26.2
registry.rancher.com/rancher/cluster-api-controller:v1.12.2
registry.rancher.com/rancher/turtles:v0.26.2
registry.suse.com/rancher/cluster-api-provider-rke2-bootstrap:v0.24.3
registry.suse.com/rancher/cluster-api-provider-rke2-controlplane:v0.24.3

Metal3s

0.15.0

306.0.29+up0.15.0

registry.suse.com/edge/3.6/metal3-chart:306.0.29+up0.15.0
registry.suse.com/edge/3.6/baremetal-operator:0.12.3.0
registry.suse.com/edge/3.6/ironic:35.0.0.2
registry.suse.com/edge/3.6/ironic-ipa-downloader:3.1.1
registry.suse.com/edge/3.6/ironic-python-agent:3.0.9

MetalLB

0.15.3

306.0.2+up0.15.3

registry.suse.com/edge/3.6/metallb-chart:306.0.2+up0.15.3
registry.suse.com/edge/3.6/metallb-controller:v0.15.3
registry.suse.com/edge/3.6/metallb-speaker:v0.15.3

Elemental

1.9.0

1.9.0

registry.suse.com/rancher/elemental-operator-chart:1.9.0
registry.suse.com/rancher/elemental-operator-crds-chart:1.9.0
registry.suse.com/rancher/elemental-operator:1.9.0

Elemental ダッシュボード拡張機能

3.0.1

3.0.1

Elemental 拡張機能 Helmチャート

Edge Image Builder

1.3.3.1

N/A

registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1

KubeVirt

1.7.0

306.0.2+up0.7.0

registry.suse.com/edge/3.6/kubevirt-chart:306.0.2+up0.7.0
registry.suse.com/suse/sles/15.7/virt-operator:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-api:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-controller:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-handler:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-launcher:1.7.0-150700.3.16.2

KubeVirt ダッシュボード拡張機能

1.3.3

306.0.4+up1.3.3

registry.suse.com/edge/3.6/kubevirt-dashboard-extension-chart:306.0.4+up1.3.3

Containerized Data Importer (CDI)

1.64.0

306.0.2+up0.7.0

registry.suse.com/edge/3.6/cdi-chart:306.0.2+up0.7.0
registry.suse.com/suse/sles/15.7/cdi-operator:1.64.0-150700.9.6.1
registry.suse.com/suse/sles/15.7/cdi-controller:1.64.0-150700.9.6.1
registry.suse.com/suse/sles/15.7/cdi-apiserver:1.64.0-150700.9.6.1
registry.suse.com/suse/sles/15.7/cdi-uploadproxy:1.64.0-150700.9.6.1

Endpoint Copier Operator

0.3.0

306.0.1+up0.3.0

registry.suse.com/edge/3.6/endpoint-copier-operator-chart:306.0.1+up0.3.0
registry.suse.com/edge/3.6/endpoint-copier-operator:0.3.0

SR-IOV Network Operator

1.6.0

306.0.4+up1.6.0

registry.suse.com/edge/3.6/sriov-network-operator-chart:306.0.4+up1.6.0
registry.suse.com/edge/3.6/sriov-crd-chart:306.0.4+up1.6.0

System Upgrade Controller

0.19.1

109.0.1

Rancher Charts Helm リポジトリ
registry.rancher.com/rancher/system-upgrade-controller:v0.19.1

Upgrade Controller

0.1.3

306.0.4+up0.1.3

registry.suse.com/edge/3.6/upgrade-controller-chart:306.0.4+up0.1.3
registry.suse.com/edge/3.6/upgrade-controller:0.1.3
registry.rancher.com/rancher/kubectl:v1.35.2
registry.suse.com/edge/3.6/release-manifest:3.6.1

SUSE Private Registry

1.1.1

1.1.1

oci://registry.suse.com/private-registry/private-registry-helm[SUSE Private Registry Helm リポジトリ]
registry.suse.com/private-registry/harbor-core:1.1.1-1.19
registry.suse.com/private-registry/harbor-jobservice:1.1.1-1.19
registry.suse.com/private-registry/harbor-portal:1.1.1-1.20
registry.suse.com/private-registry/harbor-registry:1.1.1-1.19
registry.suse.com/private-registry/harbor-registryctl:1.1.1-1.19
registry.suse.com/private-registry/harbor-trivy-adapter:1.1.1-1.24

Kiwi Builder

10.2.29.1

N/A

registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1

Cert-Manager

1.20.1

1.20.1

Jetstack Helmリポジトリ
quay.io/jetstack/cert-manager-controller:v1.20.1
quay.io/jetstack/cert-manager-webhook:v1.20.1
quay.io/jetstack/cert-manager-cainjector:v1.20.1

41.4 リリース 3.6.0

 

提供開始日:2026年5月27日

フルサポート終了日:2026年11月27日

メンテナンスサポート終了日:2028年5月27日

EOL:2028年5月28日

まとめ:SUSE Edge 3.6.0は、SUSE Edge 3.6リリースストリームにおける最初のリリースです。

41.4.1 新機能

 

  • Kubernetes 1.35.3およびRancher Prime 2.14.1に更新されました

  • SUSE Security (NeuVector) 5.5.1に更新されました NeuVectorリリースノート

  • SUSE Storage (Longhorn) 1.11.1に更新されました アップストリームLonghornリリースノート

  • Rancher Turtles (CAPI) 0.26.1に更新されました Rancher Turtlesドキュメント

  • MetalLB 0.15.3に更新されました アップストリームリリースノート

  • KubeVirt 1.7.0およびCDI (Containerized Data Importer) 1.64.0に更新されました

  • Elemental 1.9.0に更新されました Elementalリリースノート

  • Cert-Manager 1.20.1に更新されました アップストリームリリースノート

  • Metal3/IronicをIronic 35.0.0を含む0.15.0に更新しました

  • MetalLBのBGPモードはSUSE Edge 3.5ではテクノロジープレビューでしたが、現在は完全にサポートされています。

  • ダウンストリームデプロイメントにおけるPrecision Time Protocol（PTP）はSUSE Edge 3.5ではテクノロジープレビューでしたが、SyncEおよびGNSSのサポートとともに、現在は完全にサポートされています。

  • シングルスタックIPv6ダウンストリームクラスターのデプロイメントがサポートされるようになりました。ただし、これにはデュアルスタック管理クラスターが必要であることに注意してください（シングルスタック管理クラスターは引き続きテクノロジープレビューです）。

41.4.2 バグおよびセキュリティ更新

 

41.4.3 既知の問題

 
警告
警告

新しいクラスターをデプロイする場合は、第26章 「Kiwiを使用して更新されたSUSE Linux Microイメージを構築する」 に従って最初に新しいイメージをビルドしてください。 これは、イメージに最新のセキュリティ修正とバグ修正が含まれていることを確認するために、管理クラスターおよびダウンストリームクラスターに対して推奨されます。

  • Edge Image Builderを介してデプロイする場合、HelmChartConfigs マニフェストを`kubernetes/manifests`設定ディレクトリに配置すると失敗する可能性があります。代わりに、EIBのos-filesインターフェースを使用して、HelmChartConfigs を /var/lib/rancher/{rke2/k3s}/server/manifests/ に配置することを推奨します。 これを行わないと、 #8357 RKE2 issueで説明されているように、初期起動時にノードが NotReady 状態のままになる可能性があります。

  • RKE2/K3s 1.34および1.35バージョンでは、CNI設定の保存に使用されるディレクトリ /etc/cni が、overlayfs に関連する特定の条件により、そこに書き込まれるファイルに関する通知を containerd にトリガーしない場合があります（ #8356 RKE2 issueを参照）。その結果、RKE2/K3sのデプロイメントがCNIの起動待ちでスタックし、RKE2/K3sノードが NotReady 状態のままになります。これは、ノードレベルで kubectl describe node <affected_node> を使用して確認できます。

Conditions:
  Type   Status  LastHeartbeatTime                LastTransitionTime               Reason           Message
  ----   ------  -----------------                ------------------               ------           -------
  Ready  False   Thu, 05 Jun 2025 17:41:28 +0000  Thu, 05 Jun 2025 14:38:16 +0000  KubeletNotReady  container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

回避策として、RKE2の起動前に`/etc/cni`ディレクトリにtmpfsボリュームをマウントすることができます。これにより、containerdが通知を見逃す原因となるoverlayfsの使用を回避でき、ノードが再起動され、ポッドのinitcontainerが再度実行されるたびに設定が書き直されるはずです。EIBを使用している場合、これは 04-tmpfs-cni.sh ディレクトリ内の custom/scripts スクリプト（ こちらで説明）として実装でき、以下のようになります。

#!/bin/bash
mkdir -p /etc/cni
mount -t tmpfs -o mode=0700,size=5M tmpfs /etc/cni
echo "tmpfs /etc/cni tmpfs defaults,size=5M,mode=0700 0 0" >> /etc/fstab

  • 現段階では、synce4lを介したSyncEおよびgpsdを介したGNSSを設定するための公式ドキュメントや例は提供されておらず、これらのトピックは今後のリリースで取り上げられる予定です。

  • 一部のコンテナリポジトリは現在IPv4経由でのみアクセス可能なため、IPv6のみのダウンストリームクラスターには、管理クラスター上のローカルレジストリが必要です。

41.4.4 コンポーネントのバージョン

 

次の表は、3.6.0リリースを構成する個々のコンポーネントについて、バージョン、Helmチャートバージョン（該当する場合）、およびバイナリ形式でリリースされたアーティファクトの取得元を説明しています。使用方法やデプロイの例については、関連するドキュメントに従ってください。

名前

バージョン

Helmチャートのバージョン

アーティファクトの場所 (URL/イメージ)

SUSE Linux Micro

6.2 (latest)

N/A

SUSE Linux Micro ダウンロードページ

SUSE Linux Micro

6.2 (latest)

N/A

チェックサムと署名は、 SUSE Linux Micro ダウンロードページからダウンロードできます。
SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
SL-Micro.x86_64-6.2-Base-RT-SelfInstall-GM.install.iso
SL-Micro.x86_64-6.2-Base-GM.raw.xz
SL-Micro.x86_64-6.2-Base-RT-GM.raw.xz

SUSE Multi-Linux Manager

5.1

N/A

SUSE Multi-Linux Manager ダウンロードページ

K3s

1.35.3

N/A

アップストリーム K3s リリース

RKE2

1.35.3

N/A

Upstream RKE2 Release

SUSE Rancher Prime

2.14.1

2.14.1

Rancher Prime Helm リポジトリ
https://prime.ribs.rancher.io/rancher/v2.14.1/rancher-images.txt[Rancher 2.14.1 Container Images]

SUSE Storage (Longhorn)

1.11.1

1.11.1

SUSE Storage Helm リポジトリ
https://apps.rancher.io/applications/suse-storage/components[SUSE Storage Container Images]

SUSE Security (NeuVector)

5.5.1

109.0.1+up2.8.13

Rancher Charts Helm リポジトリ
registry.rancher.com/rancher/neuvector-controller:5.5.1
registry.rancher.com/rancher/neuvector-enforcer:5.5.1
registry.suse.com/rancher/neuvector-compliance-config:1.0.12

Rancher Turtles プロバイダー (CAPI)

0.26.1

306.0.6+up0.26.1

registry.suse.com/edge/3.6/rancher-turtles-providers-chart:306.0.6+up0.26.1
registry.rancher.com/rancher/cluster-api-controller:v1.12.2
registry.rancher.com/rancher/turtles:v0.26.1
registry.suse.com/rancher/cluster-api-provider-rke2-bootstrap:v0.24.3
registry.suse.com/rancher/cluster-api-provider-rke2-controlplane:v0.24.3

Metal3

0.15.0

306.0.26+up0.15.0

registry.suse.com/edge/3.6/metal3-chart:306.0.26+up0.15.0
registry.suse.com/edge/3.6/baremetal-operator:0.12.3.0
registry.suse.com/edge/3.6/ironic:35.0.0.1
registry.suse.com/edge/3.6/ironic-ipa-downloader:3.1.1
registry.suse.com/edge/3.6/ironic-python-agent:3.0.8

MetalLB

0.15.3

306.0.2+up0.15.3

registry.suse.com/edge/3.6/metallb-chart:306.0.2+up0.15.3
registry.suse.com/edge/3.6/metallb-controller:v0.15.3
registry.suse.com/edge/3.6/metallb-speaker:v0.15.3

Elemental

1.9.0

1.9.0

registry.suse.com/rancher/elemental-operator-chart:1.9.0
registry.suse.com/rancher/elemental-operator-crds-chart:1.9.0
registry.suse.com/rancher/elemental-operator:1.9.0

Elemental ダッシュボード拡張機能

3.0.1

3.0.1

Elemental 拡張機能 Helm チャート

Edge Image Builder

1.3.3.1

N/A

registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1

KubeVirt

1.7.0

306.0.2+up0.7.0

registry.suse.com/edge/3.6/kubevirt-chart:306.0.2+up0.7.0
registry.suse.com/suse/sles/15.7/virt-operator:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-api:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-controller:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-handler:1.7.0-150700.3.16.2
registry.suse.com/suse/sles/15.7/virt-launcher:1.7.0-150700.3.16.2

KubeVirt ダッシュボード拡張機能

1.3.3

306.0.4+up1.3.3

registry.suse.com/edge/3.6/kubevirt-dashboard-extension-chart:306.0.4+up1.3.3

Containerized Data Importer (CDI)

1.64.0

306.0.2+up0.7.0

registry.suse.com/edge/3.6/cdi-chart:306.0.2+up0.7.0
registry.suse.com/suse/sles/15.7/cdi-operator:1.64.0-150700.9.6.1
registry.suse.com/suse/sles/15.7/cdi-controller:1.64.0-150700.9.6.1
registry.suse.com/suse/sles/15.7/cdi-apiserver:1.64.0-150700.9.6.1
registry.suse.com/suse/sles/15.7/cdi-uploadproxy:1.64.0-150700.9.6.1

Endpoint Copier Operator

0.3.0

306.0.1+up0.3.0

registry.suse.com/edge/3.6/endpoint-copier-operator-chart:306.0.1+up0.3.0
registry.suse.com/edge/3.6/endpoint-copier-operator:0.3.0

SR-IOV Network Operator

1.6.0

306.0.4+up1.6.0

registry.suse.com/edge/3.6/sriov-network-operator-chart:306.0.4+up1.6.0
registry.suse.com/edge/3.6/sriov-crd-chart:306.0.4+up1.6.0

System Upgrade Controller

0.19.1

109.0.1

Rancher Charts Helm リポジトリ
registry.rancher.com/rancher/system-upgrade-controller:v0.19.1

Upgrade Controller

0.1.3

306.0.3+up0.1.3

registry.suse.com/edge/3.6/upgrade-controller-chart:306.0.3+up0.1.3
registry.suse.com/edge/3.6/upgrade-controller:0.1.3
registry.rancher.com/rancher/kubectl:v1.35.2
registry.suse.com/edge/3.6/release-manifest:3.6.0

SUSE Private Registry

1.1.1

1.1.1

oci://registry.suse.com/private-registry/private-registry-helm[SUSE Private Registry Helm リポジトリ]
registry.suse.com/private-registry/harbor-core:1.1.1-1.19
registry.suse.com/private-registry/harbor-jobservice:1.1.1-1.19
registry.suse.com/private-registry/harbor-portal:1.1.1-1.20
registry.suse.com/private-registry/harbor-registry:1.1.1-1.19
registry.suse.com/private-registry/harbor-registryctl:1.1.1-1.19
registry.suse.com/private-registry/harbor-trivy-adapter:1.1.1-1.24

Kiwi Builder

10.2.29.1

N/A

registry.suse.com/edge/3.6/kiwi-builder:10.2.29.1

Cert-Manager

1.20.1

1.20.1

Jetstack Helm リポジトリ
quay.io/jetstack/cert-manager-controller:v1.20.1
quay.io/jetstack/cert-manager-webhook:v1.20.1
quay.io/jetstack/cert-manager-cainjector:v1.20.1

41.5 削除された機能

 

特に記載がない限り、これらは3.6.0リリースおよびそれ以降のすべてのzストリームバージョンに適用されます。

  • Akriは以前のEdgeリリースにおいてテクノロジープレビューとして提供されていましたが、3.4.0以降は廃止されました。現在は製品から完全に削除されています。

41.6 技術プレビュー

 

特に記載がない限り、これらは3.6.0リリースおよびそれ以降のすべてのzストリームバージョンに適用されます。

  • シングルスタックIPv6管理クラスターのデプロイはテクノロジープレビューとして提供されており、標準的なサポート範囲の対象外です。

41.7 コンポーネントの検証

 

上記のコンポーネントは、ソフトウェア部品表（SBOM）データを使用して検証できます。例えば、以下のように`cosign`を使用します。

SUSE署名キーソースからSUSE Edgeコンテナの公開鍵をダウンロードします。

> cat key.pem
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7N0S2d8LFKW4WU43bq7Z
IZT537xlKe17OQEpYjNrdtqnSwA0/jLtK83m7bTzfYRK4wty/so0g3BGo+x6yDFt
SVXTPBqnYvabU/j7UKaybJtX3jc4SjaezeBqdi96h6yEslvg4VTZDpy6TFP5ZHxZ
A0fX6m5kU2/RYhGXItoeUmL5hZ+APYgYG4/455NBaZT2yOywJ6+1zRgpR0cRAekI
OZXl51k0ebsGV6ui/NGECO6MB5e3arAhszf8eHDE02FeNJw5cimXkgDh/1Lg3KpO
dvUNm0EPWvnkNYeMCKR+687QG0bXqSVyCbY6+HG/HLkeBWkv6Hn41oeTSLrjYVGa
T3zxPVQM726sami6pgZ5vULyOleQuKBZrlFhFLbFyXqv1/DokUqEppm2Y3xZQv77
fMNogapp0qYz+nE3wSK4UHPd9z+2bq5WEkQSalYxadyuqOzxqZgSoCNoX5iIuWte
Zf1RmHjiEndg/2UgxKUysVnyCpiWoGbalM4dnWE24102050Gj6M4B5fe73hbaRlf
NBqP+97uznnRlSl8FizhXzdzJiVPcRav1tDdRUyDE2XkNRXmGfD3aCmILhB27SOA
Lppkouw849PWBt9kDMvzelUYLpINYpHRi2+/eyhHNlufeyJ7e7d6N9VcvjR/6qWG
64iSkcF2DTW61CN5TrCe0k0CAwEAAQ==
-----END PUBLIC KEY-----

例えば`crane`を使用して、コンテナイメージのハッシュを検証します。

> crane digest registry.suse.com/edge/3.6/baremetal-operator:0.12.3.0 --platform linux/amd64
sha256:example-digest-placeholder
注記
注記

マルチアーキテクチャイメージの場合は、ダイジェストを取得する際にプラットフォームを指定する必要もあります。例: --platform linux/amd64 または --platform linux/arm64。これを行わないと、次のステップ (Error: no matching attestations) でエラーが発生します。

次のコマンドで確認します: cosign

> cosign verify-attestation --type spdxjson --key key.pem registry.suse.com/edge/3.6/baremetal-operator@sha256:example-digest-placeholder > /dev/null
#
Verification for registry.suse.com/edge/3.6/baremetal-operator@sha256:example-digest-placeholder --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

SUSE SBOMドキュメントに記載されている手順に従って、SBOMデータを抽出します。

> cosign verify-attestation --type spdxjson --key key.pem registry.suse.com/edge/3.6/baremetal-operator@sha256:example-digest-placeholder | jq '.payload | @base64d | fromjson | .predicate'

41.8 アップグレード手順

 

新しいリリースへのアップグレード方法の詳細については、パートVI「Day 2運用」を参照してください。

41.9 製品サポートライフサイクル

 

SUSE Edgeは、実績あるテクノロジーリーダーであるSUSEが提供する、受賞歴のあるサポートに支えられています。詳細については、 https://www.suse.com/lifecycleおよび https://www.suse.com/support/policy.htmlのサポートポリシーページを参照してください。サポートケースの起票方法、SUSEによる重大度レベルの分類方法、またはサポート範囲についてご質問がある場合は、 https://www.suse.com/support/handbook/のテクニカルサポートハンドブックを参照してください。

SUSE Edge \"3.6\" は24か月間のプロダクションサポートが提供され、最初の6か月間は「フルサポート」、その後の18か月間は「メンテナンスサポート」となります。 これらのサポートフェーズが終了すると、製品は「サービス終了」(EOL) となり、サポートは提供されなくなります。ライフサイクルフェーズの詳細については、以下の表を参照してください。

フルサポート (6か月)

フルサポート期間中は、緊急および選択された優先度の高いバグ修正がリリースされます。その他のすべてのパッチ (緊急ではないもの、機能強化、新機能) は、通常のリリーススケジュールに従ってリリースされます。

メンテナンスサポート (18か月)

この期間中は、重大な修正のみがパッチを通じてリリースされます。その他のバグ修正はSUSEの判断でリリースされる場合がありますが、期待はしないでください。

サービス終了 (EOL)

製品リリースがサービス終了日を迎えると、お客様は製品ライセンス契約の条件の範囲内で製品を引き続き使用できます。 SUSEのサポートプランは、サービス終了日（EOL）を過ぎた製品リリースには適用されません。

明記されていない限り、リストされているすべてのコンポーネントは一般提供（GA）されており、SUSEの標準的なサポート範囲に含まれます。一部のコンポーネントは「Technology Preview」としてリストされている場合があります。これは、SUSEがお客様に評価目的でGA前の機能へのアクセスを提供するものであり、標準的なサポートポリシーの対象外であり、本番環境での使用は推奨されません。SUSEは、Technology Previewコンポーネントに対する改善に関するフィードバックや提案を大いに歓迎しますが、お客様のニーズを満たさない場合や、当社が要求する成熟度に達しない場合、一般提供（GA）される前にTechnology Preview機能を廃止する権利を留保します。

SUSEは、時折、機能を廃止したり、API仕様を変更したりする場合があることにご留意ください。機能の廃止やAPI変更の理由には、機能が更新または新しい実装に置き換えられること、新しい機能セット、アップストリームテクノロジーが利用できなくなること、またはアップストリームコミュニティが互換性のない変更を導入したことなどが含まれます。これは特定のマイナーリリース（x.z）内では発生しないことを意図しており、すべてのz ストリームリリースはAPIの互換性と機能性を維持します。SUSEは、サービスの中断を最小限に抑えるため、リリースノート内で十分な通知期間をもって廃止の警告を提供し、回避策、提案、および緩和策を提供するよう努めます。

SUSE Edgeチームはコミュニティからのフィードバックも歓迎しており、問題は https://www.github.com/suse-edge内のそれぞれのリポジトリで提起できます。

41.10 ソースコードの入手

 

本SUSE製品には、GNU一般公衆利用許諾契約書（GPL）およびその他のさまざまなオープンソースに基づいてSUSEにライセンス供与された素材が含まれています。GPLでは、SUSEはGPLライセンス対象の素材に対応するソースコードを提供することが義務付けられており、SUSEはその他すべてのオープンソースの要件を遵守しています。そのため、SUSEはすべてのソースコードを利用可能にしており、一般的にSUSE Edge GitHubリポジトリ（ https://www.github.com/suse-edge）、依存コンポーネントについてはSUSE Rancher GitHubリポジトリ（ https://www.github.com/rancher）、特にSUSE Linux Microについては、ソースコードは https://www.suse.com/download/sle-microの「Medium 2」からダウンロードできます。

41.11 保証と著作権

 

SUSEは、本書の内容または使用に関していかなる表明も保証も行わず、特に、商業性および特定目的への適合性について、明示的か黙示的かを問わず、いかなる保証も否認します。さらに、SUSEは、本書をいつでも改訂またはその内容を変更する権利を留保し、何人に対しても当該の改訂または変更について通知する義務を負わないものとします。

さらに、SUSEは、すべてのソフトウェアについて、いかなる表明または保証も行わず、特に、ソフトウェアの商業性および特定目的への適合性について、明示的か黙示的かを問わず、いかなる保証も否認します。さらに、SUSEは、SUSE製ソフトウェアの一部または全部をいつでも変更する権利を留保し、何人に対しても当該の変更について通知する義務を負わないものとします。

本契約の下で提供される製品または技術情報はすべて、米国の輸出管理規定およびその他の国の輸出関連法規の制限を受けます。お客様は、すべての輸出管理規制を遵守し、成果物の輸出、再輸出、または輸入に必要なすべての許可または等級を取得することに同意するものとします。お客様は、現在の米国の輸出除外リストに掲載されている企業、および米国の輸出管理規定で指定された輸出禁止国またはテロリスト国に本製品を輸出または再輸出しないことに同意するものとします。お客様は、成果物を、禁止されている核兵器、ミサイル、または化学兵器・生物兵器の最終用途に使用しないことに同意するものとします。SUSEソフトウェアの輸出に関する詳細は、 https://www.suse.com/company/legal/を参照してください。SUSEは、必要な輸出許可の取得をお客様が怠った場合の責任は問われないものとします。

Copyright © 2024 SUSE LLC.

このリリースノートドキュメントは、Creative Commons Attribution-NoDerivatives 4.0 International License (CC-BY-ND-4.0) の下でライセンスされています。このドキュメントとともにライセンスのコピーを受け取っているはずです。そうでない場合は、 https://creativecommons.org/licenses/by-nd/4.0/を参照してください。

SUSEは、本書に記載されている製品に組み込まれている技術に関連する知的財産権を有しています。特に、これらの知的財産権には、 https://www.suse.com/company/legal/に記載されている1つまたは複数の米国特許、および米国ならびに他の国における1つまたは複数のその他の特許や出願中の特許（これらに限定されません）が含まれている場合があります。

SUSEの商標については、SUSEの商標およびサービスマークリスト (https://www.suse.com/company/legal/) を参照してください。サードパーティ各社とその製品の商標は、所有者であるそれぞれの会社に所属します。SUSEのブランド情報および使用要件については、 https://brand.suse.com/で公開されているガイドラインを参照してください。