エッジコンピューティング
ネットワークエッジで OpenShift Container Platform クラスターを設定およびデプロイする
概要
第1章 ネットワークファーエッジの課題 リンクのコピーリンクがクリップボードにコピーされました!
エッジコンピューティングでは、地理的に離れた場所にある多数のサイトを管理する際に複雑な課題が生じます。ネットワークのファーエッジのサイトをプロビジョニングおよび管理するには、GitOps Zero Touch Provisioning (ZTP) を使用します。
1.1. ネットワークファーエッジの課題の解決 リンクのコピーリンクがクリップボードにコピーされました!
今日、サービスプロバイダーは、自社のインフラストラクチャーをネットワークのエッジにデプロイメントしたいと考えています。これには重大な課題があります。
- 多数のエッジサイトのデプロイメントを並行してどのように処理しますか?
- 非接続環境にサイトをデプロイメントする必要がある場合はどうなりますか?
- 大規模なクラスター群のライフサイクルをどのように管理していますか?
GitOps Zero Touch Provisioning (ZTP) と GitOps は、ベアメタル機器の宣言的なサイト定義と設定を使用してリモートエッジサイトを大規模にプロビジョニングできるようにすることで、これらの課題を解決します。テンプレートまたはオーバーレイ設定は、CNF ワークロードに必要な OpenShift Container Platform 機能をインストールします。インストールとアップグレードの全ライフサイクルは、GitOps ZTP パイプラインを通じて処理されます。
GitOps ZTP は、インフラストラクチャーのデプロイメントに GitOps を使用します。GitOps では、Git リポジトリーに格納されている宣言型 YAML ファイルとその他の定義済みパターンを使用します。Red Hat Advanced Cluster Management (RHACM) は、Git リポジトリーを使用してインフラストラクチャーのデプロイメントを推進します。
GitOps は、トレーサビリティ、ロールベースのアクセス制御 (RBAC)、および各サイトの望ましい状態に関する信頼できる唯一の情報源を提供します。スケーラビリティの問題は、Git の方法論と、Webhook を介したイベント駆動型操作によって対処されます。
GitOps ZTP パイプラインがエッジノードに配信する宣言的なサイト定義と設定のカスタムリソース (CR) を作成すると、GitOps ZTP ワークフローが開始します。
以下の図は、ファーエッジフレームワーク内で GitOps ZTP が機能する仕組みを示しています。
1.2. GitOps ZTP を使用したネットワークファーエッジでのクラスタープロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) は、単一のハブクラスターが多数のスポーククラスターを管理するハブアンドスポークアーキテクチャーでクラスターを管理します。RHACM を実行するハブクラスターは、GitOps Zero Touch Provisioning (ZTP) と、RHACM のインストール時にデプロイされるアシストサービスを使用して、マネージドクラスターをプロビジョニングおよびデプロイします。
アシストサービスは、ベアメタルで実行されるシングルノードクラスター、3 ノードクラスター、または標準クラスターで OpenShift Container Platform のプロビジョニングを処理します。
GitOps ZTP を使用して OpenShift Container Platform でベアメタルホストをプロビジョニングおよび維持する方法の概要は次のとおりです。
- RHACM を実行するハブクラスターは、OpenShift Container Platform リリースイメージをミラーリングする OpenShift イメージレジストリーを管理します。RHACM は、OpenShift イメージレジストリーを使用して、マネージドクラスターをプロビジョニングします。
- ベアメタルホストは、Git リポジトリーでバージョン管理された YAML 形式のインベントリーファイルで管理します。
- ホストをマネージドクラスターとしてプロビジョニングする準備を整え、RHACM とアシストサービスを使用してサイトにベアメタルホストをインストールします。
クラスターのインストールとデプロイは、最初のインストールフェーズと、その後の設定およびデプロイフェーズを含む 2 段階のプロセスです。次の図は、このワークフローを示しています。
1.3. SiteConfig リソースと RHACM を使用したマネージドクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) は、Git リポジトリー内の SiteConfig
カスタムリソース (CR) を使用して、OpenShift Container Platform クラスターのインストールプロセスを管理します。SiteConfig
CR には、インストールに必要なクラスター固有のパラメーターが含まれています。ユーザー定義の追加マニフェストを含む、インストール中に選択した設定 CR を適用するためのオプションがあります。
ZTP GitOps プラグインは、SiteConfig
CR を処理して、ハブクラスター上に CR コレクションを生成します。これにより、Red Hat Advanced Cluster Management (RHACM) のアシストサービスがトリガーされ、OpenShift Container Platform がベアメタルホストにインストールされます。ハブクラスターのこれらの CR で、インストールステータスとエラーメッセージを確認できます。
単一クラスターは、手動でプロビジョニングするか、GitOps ZTP を使用してバッチでプロビジョニングできます。
- 単一クラスターのプロビジョニング
-
単一の
SiteConfig
CR と、関連するインストールおよび設定 CR をクラスター用に作成し、それらをハブクラスターに適用して、クラスターのプロビジョニングを開始します。これは、より大きなスケールにデプロイする前に CR をテストするのに適した方法です。 - 多くのクラスターのプロビジョニング
-
Git リポジトリーで
SiteConfig
と関連する CR を定義することにより、最大 400 のバッチでマネージドクラスターをインストールします。ArgoCD はSiteConfig
CR を使用してサイトをデプロイします。RHACM ポリシージェネレーターはマニフェストを作成し、それらをハブクラスターに適用します。これにより、クラスターのプロビジョニングプロセスが開始されます。
SiteConfig v1 は、OpenShift Container Platform バージョン 4.18 以降では非推奨になります。ClusterInstance
カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。
SiteConfig Operator の詳細は、SiteConfig を参照してください。
1.4. ポリシーと PolicyGenTemplate リソースを使用したマネージドクラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) は、Red Hat Advanced Cluster Management (RHACM) を使用して、設定を適用するためのポリシーベースのガバナンスアプローチを使用してクラスターを設定します。
ポリシージェネレーターまたは PolicyGen
は、簡潔なテンプレートから RHACM ポリシーを作成できるようにする GitOps Operator のプラグインです。このツールは、複数の CR を 1 つのポリシーに組み合わせることができ、フリート内のクラスターのさまざまなサブセットに適用される複数のポリシーを生成できます。
スケーラビリティを確保し、クラスターのフリート全体で設定を管理する複雑さを軽減するには、できるだけ多くの共通性を持つ設定 CR を使用します。
- 可能であれば、フリート全体の共通ポリシーを使用して設定 CR を適用します。
- 次の優先事項は、クラスターの論理グループを作成して、グループポリシーの下で残りの設定を可能な限り管理することです。
- 設定が個々のサイトに固有のものである場合、ハブクラスターで RHACM テンプレートを使用して、サイト固有のデータを共通ポリシーまたはグループポリシーに挿入します。または、サイトに個別のサイトポリシーを適用します。
次の図は、ポリシージェネレーターがクラスターデプロイメントの設定フェーズで GitOps および RHACM と対話する方法を示しています。
クラスターの大規模なフリートの場合は、それらのクラスターの設定に高レベルの一貫性があるのが一般的です。
次の推奨されるポリシーの構造化では、設定 CR を組み合わせていくつかの目標を達成しています。
- 一般的な設定を一度説明すれば、フリートに適用できます。
- 維持および管理されるポリシーの数を最小限に抑えます。
- クラスターバリアントの一般的な設定の柔軟性をサポートします。
ポリシーのカテゴリー | 説明 |
---|---|
共通 |
共通カテゴリーに存在するポリシーは、フリート内のすべてのクラスターに適用されます。共通の |
グループ |
groups カテゴリーに存在するポリシーは、フリート内のクラスターのグループに適用されます。グループ |
サイト | sites カテゴリーに存在するポリシーが特定のクラスターに適用されます。どのクラスターでも、独自の特定のポリシーを維持できます。 |
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
第2章 GitOps ZTP 用のハブクラスターの準備 リンクのコピーリンクがクリップボードにコピーされました!
非接続環境で RHACM を使用するには、OpenShift Container Platform リリースイメージと必要な Operator イメージを含む Operator Lifecycle Manager (OLM) カタログをミラーリングするミラーレジストリーを作成します。OLM は Operator およびそれらの依存関係をクラスターで管理し、インストールし、アップグレードします。切断されたミラーホストを使用して、ベアメタルホストのプロビジョニングに使用される RHCOS ISO および RootFS ディスクイメージを提供することもできます。
2.1. 通信事業者 RAN DU 4.18 の検証済みソフトウェアコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
Red Hat telco RAN DU 4.18 ソリューションは、OpenShift Container Platform 管理クラスター用の次の Red Hat ソフトウェア製品を使用して検証されています。
コンポーネント | ソフトウェアバージョン |
---|---|
マネージドクラスターのバージョン | 4.18 |
Cluster Logging Operator | 6.11 |
Local Storage Operator | 4.18 |
OpenShift API for Data Protection (OADP) | 1.4 |
PTP Operator | 4.18 |
SR-IOV Operator | 4.18 |
SRIOV-FEC Operator | 2.10 |
Lifecycle Agent | 4.18 |
[1] この表は、調整された Cluster ロギング Operator バージョン 6.2 がリリースされると更新されます。
2.2. GitOps ZTP で推奨されるハブクラスター仕様とマネージドクラスターの制限 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) を使用すると、地理的に分散した地域やネットワークにある数千のクラスターを管理できます。Red Hat Performance and Scale ラボは、ラボ環境内の単一の Red Hat Advanced Cluster Management (RHACM) ハブクラスターから、より小さな DU プロファイルを使用して 3,500 個の仮想シングルノード OpenShift クラスター作成および管理することに成功しました。
実際の状況では、管理できるクラスター数のスケーリング制限は、ハブクラスターに影響を与えるさまざまな要因によって異なります。以下に例を示します。
- ハブクラスターのリソース
- 利用可能なハブクラスターのホストリソース (CPU、メモリー、ストレージ) は、ハブクラスターが管理できるクラスターの数を決定する重要な要素です。ハブクラスターに割り当てられるリソースが多いほど、対応できるマネージドクラスターの数も多くなります。
- ハブクラスターストレージ
- ハブクラスターホストのストレージ IOPS 評価と、ハブクラスターホストが NVMe ストレージを使用するかどうかは、ハブクラスターのパフォーマンスと管理できるクラスターの数に影響を与える可能性があります。
- ネットワーク帯域幅と遅延
- ハブクラスターとマネージドクラスター間のネットワーク接続が遅い、大きく遅延する場合、ハブクラスターによる複数クラスターの管理方法に影響を与える可能性があります。
- マネージドクラスターのサイズと複雑さ
- マネージドクラスターのサイズと複雑さも、ハブクラスターの容量に影響します。より多くのノード、namespace、リソースを備えた大規模なマネージドクラスターには、追加の処理リソースと管理リソースが必要です。同様に、RAN DU プロファイルや多様なワークロードなどの複雑な設定を持つクラスターは、ハブクラスターからより多くのリソースを必要とする可能性があります。
- 管理ポリシーの数
- ハブクラスターによって管理されるポリシーの数は、それらのポリシーにバインドされているマネージドクラスターの数に対してスケーリングされており、これらは管理できるクラスターの数を決定する重要な要素です。
- ワークロードのモニタリングと管理
- RHACM は、マネージドクラスターを継続的にモニタリングおよび管理します。ハブクラスター上で実行されるモニタリングおよび管理ワークロードの数と複雑さは、ハブクラスターの容量に影響を与える可能性があります。集中的なモニタリングや頻繁な調整操作には追加のリソースが必要となる場合があり、管理可能なクラスターの数が制限される可能性があります。
- RHACM のバージョンと設定
- RHACM のバージョンが異なると、パフォーマンス特性やリソース要件も異なる場合があります。さらに、同時リコンシリエーションの数やヘルスチェックの頻度などの RHACM 設定は、ハブクラスターのマネージドクラスター容量に影響を与える可能性があります。
次の代表的な設定とネットワーク仕様を使用して、独自の Hub クラスターとネットワーク仕様を開発します。
次のガイドラインは、社内のラボのベンチマークテストのみに基づいており、完全なベアメタルホストの仕様を表すものではありません。
要件 | 説明 |
---|---|
サーバーハードウェア | Dell PowerEdge R650 ラックサーバー 3 台 |
NVMe ハードディスク |
|
SSD ハードディスク |
|
適用された DU プロファイルポリシーの数 | 5 |
次のネットワーク仕様は、典型的な実際の RAN ネットワークを表しており、テスト中にスケールラボ環境に適用されます。
仕様 | 説明 |
---|---|
ラウンドトリップタイム (RTT) 遅延 | 50 ms |
パケットロス | 0.02% のパケットロス |
ネットワーク帯域幅の制限 | 20 Mbps |
2.3. 非接続環境での GitOps ZTP のインストール リンクのコピーリンクがクリップボードにコピーされました!
非接続環境のハブクラスターで Red Hat Advanced Cluster Management (RHACM)、Red Hat OpenShift GitOps、Topology Aware Lifecycle Manager (TALM) を使用して、複数のマネージドクラスターのデプロイを管理します。
前提条件
-
OpenShift Container Platform CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 クラスターで使用するために、切断されたミラーレジストリーを設定しました。
注記作成する非接続ミラーレジストリーには、ハブクラスターで実行されている TALM のバージョンと一致する TALM バックアップおよび事前キャッシュイメージのバージョンが含まれている必要があります。スポーククラスターは、切断されたミラーレジストリーでこれらのイメージを解決できる必要があります。
手順
- ハブクラスターに RHACM をインストールします。非接続環境での RHACM のインストール を参照してください。
- ハブクラスターに GitOps と TALM をインストールします。
2.4. RHCOS ISO および RootFS イメージの非接続ミラーホストへの追加 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) を使用して非接続環境にクラスターのインストールを開始する前に、最初に使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストする必要があります。切断されたミラーを使用して RHCOS イメージをホストします。
前提条件
- ネットワーク上で RHCOS イメージリソースをホストするように HTTP サーバーをデプロイして設定します。お使いのコンピューターから HTTP サーバーにアクセスでき、作成するマシンからもアクセスできる必要があります。
RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールするバージョン以下の最新バージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。ホストに RHCOS をインストールするには、ISO および RootFS イメージが必要です。RHCOS QCOW2 イメージは、このインストールタイプではサポートされません。
手順
- ミラーホストにログインします。
mirror.openshift.com から RHCOS ISO イメージおよび RootFS イメージを取得します。以下は例になります。
必要なイメージ名と OpenShift Container Platform のバージョンを環境変数としてエクスポートします。
export ISO_IMAGE_NAME=<iso_image_name>
$ export ISO_IMAGE_NAME=<iso_image_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ROOTFS_IMAGE_NAME=<rootfs_image_name>
$ export ROOTFS_IMAGE_NAME=<rootfs_image_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow export OCP_VERSION=<ocp_version>
$ export OCP_VERSION=<ocp_version>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なイメージをダウンロードします。
sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.18/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.18/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.18/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}
$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.18/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
イメージが正常にダウンロードされ、非接続ミラーホストで提供されることを確認します。以下に例を示します。
wget http://$(hostname)/${ISO_IMAGE_NAME}
$ wget http://$(hostname)/${ISO_IMAGE_NAME}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Saving to: rhcos-4.18.1-x86_64-live.x86_64.iso rhcos-4.18.1-x86_64-live.x86_64.iso- 11%[====> ] 10.01M 4.71MB/s
Saving to: rhcos-4.18.1-x86_64-live.x86_64.iso rhcos-4.18.1-x86_64-live.x86_64.iso- 11%[====> ] 10.01M 4.71MB/s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. アシストサービスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) は、アシストサービスを使用して OpenShift Container Platform クラスターをデプロイします。Red Hat Advanced Cluster Management (RHACM) で MultiClusterHub Operator を有効にすると、アシストサービスが自動的にデプロイされます。その後、すべての namespace を監視し、ミラーレジストリー HTTP サーバーでホストされている ISO および RootFS イメージへの参照を使用して、AgentServiceConfig
カスタムリソース (CR) を更新するように Provisioning
リソースを設定する必要があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 -
RHACM で
MultiClusterHub
が有効になっている。
手順
-
Provisioning
リソースを有効にして、すべての namespace を監視し、非接続環境のミラーを設定します。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。 spec.osImages
フィールドを更新するために、次のコマンドを実行してAgentServiceConfig
CR を開きます。oc edit AgentServiceConfig
$ oc edit AgentServiceConfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AgentServiceConfig
CR のspec.osImages
フィールドを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<host>
- ターゲットミラーレジストリー HTTP サーバーの完全修飾ドメイン名 (FQDN) を指定します。
<path>
- ターゲットミラーレジストリー上のイメージへのパスを指定します。
- エディターを保存して終了し、変更を適用します。
2.6. 切断されたミラーレジストリーを使用するためのハブクラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
非接続環境で切断されたミラーレジストリーを使用するようにハブクラスターを設定できます。
前提条件
- Red Hat Advanced Cluster Management (RHACM) 2.13 がインストールされた非接続環境のハブクラスターがある。
-
HTTP サーバーで
rootfs
およびiso
イメージをホストしている。OpenShift Container Platform イメージリポジトリーのミラーリング に関するガイダンスは、関連情報 セクションを参照してください。
HTTP サーバーに対して TLS を有効にする場合、ルート証明書がクライアントによって信頼された機関によって署名されていることを確認し、OpenShift Container Platform ハブおよびマネージドクラスターと HTTP サーバー間の信頼された証明書チェーンを検証する必要があります。信頼されていない証明書で設定されたサーバーを使用すると、イメージがイメージ作成サービスにダウンロードされなくなります。信頼されていない HTTPS サーバーの使用はサポートされていません。
手順
ミラーレジストリー設定を含む
ConfigMap
を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ConfigMap
namespace はmulticluster-engine
に設定する必要があります。- 2
- ミラーレジストリーの作成時に使用されるミラーレジストリーの証明書。
- 3
- ミラーレジストリーの設定ファイル。ミラーレジストリー設定は、検出イメージの
/etc/containers/registries.conf
ファイルにミラー情報を追加します。ミラー情報は、インストールプログラムに渡される際、install-config.yaml
ファイルのimageContentSources
セクションに保存されます。ハブクラスターで実行される Assisted Service Pod は、設定されたミラーレジストリーからコンテナーイメージをフェッチします。 - 4
- ミラーレジストリーの URL。ミラーレジストリーを設定する場合は、
oc adm release mirror
コマンドを実行して、imageContentSources
セクションの URL を使用する必要があります。詳細は、OpenShift Container Platform イメージリポジトリーのミラーリング セクションを参照してください。 - 5
registries.conf
ファイルで定義されるレジストリーは、レジストリーではなくリポジトリーによってスコープが指定される必要があります。この例では、quay.io/example-repository
リポジトリーとmirror1.registry.corp.com:5000/example-repository
リポジトリーの両方のスコープがexample-repository
リポジトリーにより指定されます。
これにより、以下のように
AgentServiceConfig
カスタムリソースのmirrorRegistryRef
が更新されます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターのインストール時には、有効な NTP サーバーが必要です。適切な NTP サーバーが使用可能であり、切断されたネットワークを介してインストール済みクラスターからアクセスできることを確認してください。
2.7. 非認証レジストリーを使用するためのハブクラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
非認証レジストリーを使用するようにハブクラスターを設定できます。非認証レジストリーは、イメージへのアクセスとダウンロードに認証を必要としません。
前提条件
- ハブクラスターがインストールおよび設定され、ハブクラスターに Red Hat Advanced Cluster Management (RHACM) がインストールされている。
- OpenShift Container Platform CLI (oc) がインストールされている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで使用するために非認証レジストリーを設定している。
手順
次のコマンドを実行して、
AgentServiceConfig
カスタムリソース (CR) を更新します。oc edit AgentServiceConfig agent
$ oc edit AgentServiceConfig agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CR に
unauthenticatedRegistries
フィールドを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 非認証レジストリーは、
AgentServiceConfig
リソースのspec.unauthenticatedRegistries
の下に一覧表示されます。このリストにあるレジストリーのエントリーは、スポーククラスターのインストールに使用されるプルシークレットに含める必要はありません。assisted-service
は、インストールに使用されるすべてのイメージレジストリーの認証情報がプルシークレットに含まれていることを確認して、プルシークレットを検証します。
ミラーレジストリーは自動的に無視リストに追加されるため、spec.unauthenticatedRegistries
の下に追加する必要はありません。ConfigMap
で PUBLIC_CONTAINER_REGISTRIES
環境変数を指定すると、デフォルト値が指定した値でオーバーライドされます。PUBLIC_CONTAINER_REGISTRIES
のデフォルトは quay.io および registry.svc.ci.openshift.org です。
検証
次のコマンドを実行して、ハブクラスターから新しく追加されたレジストリーにアクセスできることを確認します。
ハブクラスターへのデバッグシェルプロンプトを開きます。
oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、非認証レジストリーへのアクセスをテストします。
podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>
sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <unauthenticated_registry>
-
unauthenticated-image-registry.openshift-image-registry.svc:5000
などの新しいレジストリーです。
出力例
Login Succeeded!
Login Succeeded!
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8. ArgoCD を使用したハブクラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) を使用して、サイトごとに必要なインストールおよびポリシーカスタムリソース (CR) を生成する一連の ArgoCD アプリケーションでハブクラスターを設定できます。
Red Hat Advanced Cluster Management (RHACM) は SiteConfig
CR を使用して、ArgoCD の Day 1 マネージドクラスターインストール CR を生成します。各 ArgoCD アプリケーションは、最大 300 個の SiteConfig
CR を管理できます。
前提条件
- Red Hat Advanced Cluster Management (RHACM) と Red Hat OpenShift GitOps がインストールされた OpenShift Container Platform ハブクラスターがあります。
-
「GitOps ZTP サイト設定リポジトリーの準備」セクションで説明されているように、GitOps ZTP プラグインコンテナーから参照デプロイメントを抽出しました。参照デプロイメントを抽出すると、次の手順で参照される
out/argocd/deployment
ディレクトリーが作成されます。
手順
ArgoCD パイプライン設定を準備します。
- example ディレクトリーと同様にディレクトリー構造で Git リポジトリーを作成します。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。
ArgoCD UI を使用して、リポジトリーへのアクセスを設定します。Settings で以下を設定します。
-
リポジトリー: 接続情報を追加します。URL は
.git
などで終わっている必要があります。https://repo.example.com/repo.git
と認証情報を指定します。 - Certificates - 必要に応じて、リポジトリーのパブリック証明書を追加します。
-
リポジトリー: 接続情報を追加します。URL は
2 つの ArgoCD アプリケーション、
out/argocd/deployment/clusters-app.yaml
とout/argocd/deployment/policies-app.yaml
を、Git リポジトリーに基づいて修正します。-
Git リポジトリーを参照するように URL を更新します。URL は
.git
で終わります (例:https://repo.example.com/repo.git
)。 -
targetRevision
は、監視する Git リポジトリーブランチを示します。 -
path
は、それぞれSiteConfig
およびPolicyGenerator
またはPolicyGentemplate
CR へのパスを指定します。
-
Git リポジトリーを参照するように URL を更新します。URL は
GitOps ZTP プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に
out/argocd/deployment/
ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。RHACM バージョンに一致する
multicluster-operators-subscription
イメージを選択します。-
RHACM 2.8 および 2.9 の場合は、
registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version>
イメージを使用します。 -
RHACM 2.10 以降の場合は、
registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version>
イメージを使用します。
重要multicluster-operators-subscription
イメージのバージョンは、RHACM のバージョンと一致する必要があります。MCE 2.10 リリース以降、RHEL 9 はmulticluster-operators-subscription
イメージのベースイメージです。OpenShift Operator のライフサイクル の表「Platform Aligned Operators」の
[Expand for Operator list]
をクリックすると、OpenShift Container Platform でサポートされている Operator の完全なマトリックスが表示されます。-
RHACM 2.8 および 2.9 の場合は、
RHACM バージョンに一致する
multicluster-operators-subscription
イメージを使用して、out/argocd/deployment/argocd-openshift-gitops-patch.json
ファイルを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。
oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
$ oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHACM 2.7 以降では、マルチクラスターエンジンはデフォルトで
cluster-proxy-addon
機能を有効にします。次のパッチを適用して、cluster-proxy-addon
機能を無効にし、このアドオンに関連するハブクラスターとマネージド Pod を削除します。以下のコマンドを実行します。oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
$ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。
oc apply -k out/argocd/deployment
$ oc apply -k out/argocd/deployment
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 既存の ArgoCD アプリケーションがある場合は、次のコマンドを実行して、
Application
リソースにPrunePropagationPolicy=background
ポリシーが設定されていることを確認します。oc -n openshift-gitops get applications.argoproj.io \ clusters -o jsonpath='{.spec.syncPolicy.syncOptions}' |jq
$ oc -n openshift-gitops get applications.argoproj.io \ clusters -o jsonpath='{.spec.syncPolicy.syncOptions}' |jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存のポリシーの出力例
[ "CreateNamespace=true", "PrunePropagationPolicy=background", "RespectIgnoreDifferences=true" ]
[ "CreateNamespace=true", "PrunePropagationPolicy=background", "RespectIgnoreDifferences=true" ]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.syncPolicy.syncOption
フィールドにPrunePropagationPolicy
パラメーターが含まれていない場合、またはPrunePropagationPolicy
がforeground
値に設定されている場合は、Application
リソースでポリシーをbackground
に設定します。以下の例を参照してください。kind: Application spec: syncPolicy: syncOptions: - PrunePropagationPolicy=background
kind: Application spec: syncPolicy: syncOptions: - PrunePropagationPolicy=background
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
background
削除ポリシーを設定すると、ManagedCluster
CR とそれに関連付けられたすべてのリソースが削除されます。
2.9. GitOps ZTP サイト設定リポジトリーの準備 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) パイプラインを使用する前に、サイト設定データをホストする Git リポジトリーを準備する必要があります。
前提条件
- 必要なインストールおよびポリシーのカスタムリソース (CR) を生成するためのハブクラスター GitOps アプリケーションを設定している。
- GitOps ZTP を使用してマネージドクラスターをデプロイしている。
手順
SiteConfig
とPolicyGenerator
またはPolicyGentemplate
CR 用に個別のパスを持つディレクトリー構造を作成します。注記SiteConfig
とPolicyGenerator
またはPolicyGentemplate
CR を個別のディレクトリーに保存します。SiteConfig
ディレクトリーと、PolicyGenerator
またはPolicyGentemplate
ディレクトリーの両方に、そのディレクトリー内のファイルを明示的に含めるkustomization.yaml
ファイルが含まれている必要があります。以下のコマンドを使用して
ztp-site-generate
コンテナーイメージからargocd
ディレクトリーをエクスポートします。podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18
$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 extract /home/ztp --tar | tar x -C ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow out
ディレクトリーに以下のサブディレクトリーが含まれていることを確認します。-
out/extra-manifest
には、SiteConfig
が追加の manifestconfigMap
の生成に使用するソース CR ファイルが含まれます。 -
out/source-crs
には、PolicyGenerator
が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれています。 -
out/argocd/deployment
には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。 -
out/argocd/example
には、推奨される設定を表すSiteConfig
ファイルと、PolicyGenerator
またはPolicyGentemplate
ファイルのサンプルが含まれています。
-
-
out/source-crs
フォルダーとその内容をPolicyGenerator
またはPolicyGentemplate
ディレクトリーにコピーします。 out/extra-manifests ディレクトリーには、RAN DU クラスターの参照マニフェストが含まれています。
out/extra-manifests
ディレクトリーをSiteConfig
フォルダーにコピーします。このディレクトリーには、ztp-site-generate
コンテナーからの CR のみを含める必要があります。ユーザー提供の CR をここに追加しないでください。ユーザー提供の CR を使用する場合は、そのコンテンツ用に別のディレクトリーを作成する必要があります。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
PolicyGenTemplate
CR を使用してポリシーを管理およびデプロイし、クラスターを管理することは、OpenShift Container Platform の今後のリリースでは非推奨になります。Red Hat Advanced Cluster Management (RHACM) およびPolicyGenerator
CR を使用すると、同等の機能および改善された機能が利用できます。
-
ディレクトリー構造と
kustomization.yaml
ファイルをコミットし、Git リポジトリーにプッシュします。Git への最初のプッシュには、kustomization.yaml
ファイルが含まれている必要があります。
out/argocd/example
のディレクトリー構造は、Git リポジトリーの構造およびコンテンツの参照として使用します。この構造には、シングルノード、3 ノード、および標準クラスターの SiteConfig
と、PolicyGenerator
または PolicyGentemplate
参照 CR が含まれます。使用されていないクラスタータイプの参照を削除します。
すべてのクラスタータイプについて、次のことを行う必要があります。
-
source-crs
サブディレクトリーをacmpolicygenerator
またはpolicygentemplates
ディレクトリーに追加します。 -
extra-manifests
ディレクトリーをsiteconfig
ディレクトリーに追加します。
以下の例では、シングルノードクラスターのネットワークの CR のセットを説明しています。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
2.10. バージョンに依存しないように GitOps ZTP サイト設定リポジトリーを準備する リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP を使用して、OpenShift Container Platform のさまざまなバージョンを実行しているマネージドクラスターのソースカスタムリソース (CR) を管理できます。これは、ハブクラスター上で実行している OpenShift Container Platform のバージョンが、マネージドクラスター上で実行しているバージョンから独立している可能性があることを意味します。
次の手順では、クラスターポリシー管理に PolicyGentemplate
リソースではなく、PolicyGenerator
リソースを使用していることを前提としています。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
-
SiteConfig
CR とPolicyGenerator
CR の個別のパスを持つディレクトリー構造を作成します。 PolicyGenerator
ディレクトリー内に、使用可能にする OpenShift Container Platform バージョンごとにディレクトリーを作成します。バージョンごとに、次のリソースを作成します。-
そのディレクトリー内のファイルを明示的に含む
kustomization.yaml
ファイル source-crs
ディレクトリーには、ztp-site-generate
コンテナーからの参照 CR 設定ファイルが含まれます。ユーザー提供の CR を使用する場合は、CR 用に別のディレクトリーを作成する必要があります。
-
そのディレクトリー内のファイルを明示的に含む
/siteconfig
ディレクトリーに、使用可能にする OpenShift Container Platform バージョンごとにサブディレクトリーを作成します。バージョンごとに、コンテナーからコピーされる参照 CR 用のディレクトリーを少なくとも 1 つ作成します。ディレクトリーの名前や参照ディレクトリーの数に制限はありません。カスタムマニフェストを使用する場合は、個別のディレクトリーを作成する必要があります。次の例では、OpenShift Container Platform のさまざまなバージョンのユーザー提供のマニフェストと CR を使用した構造を説明します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 最上位の
kustomization
YAML ファイルを作成します。 - 2 7
- カスタム
/acmpolicygenerator
ディレクトリー内にバージョン固有のディレクトリーを作成します。 - 3 8
- バージョンごとに
kustomization.yaml
ファイルを作成します。 - 4 9
ztp-site-generate
コンテナーからの参照 CR を含めるために、バージョンごとにsource-crs
ディレクトリーを作成します。- 5 10
- ZTP コンテナーから展開されるポリシー CR の
reference-crs
ディレクトリーを作成します。 - 6 11
- オプション: ユーザー提供の CR 用に
custom-crs
ディレクトリーを作成します。 - 12 14
- カスタム
/siteconfig
ディレクトリー内にディレクトリーを作成し、ztp-site-generate
コンテナーからの追加のマニフェストを含めます。 - 13 15
- ユーザーによって提供されるマニフェストを保持するフォルダーを作成します。
注記前の例では、カスタム
/siteconfig
ディレクトリー内の各バージョンサブディレクトリーにはさらに 2 つのサブディレクトリーが含まれており、1 つはコンテナーからコピーされた参照マニフェストを含み、もう 1 つは提供するカスタムマニフェスト用です。これらのディレクトリーに割り当てられた名前は一例です。ユーザー提供の CR を使用する場合は、SiteConfig
CR のextraManifests.searchPaths
の下にリストされている最後のディレクトリーが、ユーザー提供の CR を含むディレクトリーである必要があります。SiteConfig
CR を編集して、作成したディレクトリーの検索パスを含めます。extraManifests.searchPaths
の下にリストされる最初のディレクトリーは、参照マニフェストを含むディレクトリーである必要があります。ディレクトリーがリストされている順序を考慮してください。ディレクトリーに同じ名前のファイルが含まれている場合は、最後のディレクトリーにあるファイルが優先されます。SiteConfig CR の例
extraManifests: searchPaths: - extra-manifest/ - custom-manifest/
extraManifests: searchPaths: - extra-manifest/
1 - custom-manifest/
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow トップレベルの
kustomization.yaml
ファイルを編集して、アクティブな OpenShift Container Platform バージョンを制御します。以下は、最上位レベルのkustomization.yaml
ファイルの例です。resources: - version_4.13 #- version_4.14
resources: - version_4.13
1 #- version_4.14
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.11. バックアップおよび復元用のハブクラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP を使用して、BareMetalHost
リソースをバックアップするための一連のポリシーを設定できます。これにより、障害が発生したハブクラスターからデータを回復し、Red Hat Advanced Cluster Management (RHACM) を使用して代替クラスターをデプロイできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
cluster.open-cluster-management.io/backup=cluster-activation
ラベルをinfraenvs.agent-install.openshift.io
ラベルの付いたすべてのBareMetalHost
リソースに追加するポリシーを作成します。ポリシーをBareMetalHostBackupPolicy.yaml
として保存します。以下の例では、
cluster.open-cluster-management.io/backup
ラベルを、infraenvs.agent-install.openshift.io
ラベルの付いたすべてのBareMetalHost
リソースに追加します。ポリシーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cluster.open-cluster-management.io/backup: cluster-activation
ラベルをBareMetalHost
リソースに適用すると、RHACM クラスターはそれらのリソースをバックアップします。ハブアクティベーションリソースを復元する際に、アクティブなクラスターが使用できなくなった場合は、BareMetalHost
リソースを復元できます。
以下のコマンドを実行してポリシーを適用します。
oc apply -f BareMetalHostBackupPolicy.yaml
$ oc apply -f BareMetalHostBackupPolicy.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行して、ラベル
infraenvs.agent-install.openshift.io
を持つすべてのBareMetalHost
リソースを検索します。oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io
$ oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE baremetal-ns baremetal-name false 50s
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE baremetal-ns baremetal-name false 50s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、ポリシーがラベル
cluster.open-cluster-management.io/backup=cluster-activation
をこれらのリソースすべてに適用していることを確認します。oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io,cluster.open-cluster-management.io/backup=cluster-activation
$ oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io,cluster.open-cluster-management.io/backup=cluster-activation
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE baremetal-ns baremetal-name false 50s
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE baremetal-ns baremetal-name false 50s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、前の手順と同じリストが表示されるはずです。このリストには、ラベル
infraenvs.agent-install.openshift.io
が付いたすべてのBareMetalHost
リソースが表示されています。これにより、infraenvs.agent-install.openshift.io
ラベルが付いたすべてのBareMetalHost
リソースに、cluster.open-cluster-management.io/backup: cluster-activation
ラベルも付いていることが確認されます。以下の例は、
infraenvs.agent-install.openshift.io
ラベルの付いたBareMetalHost
リソースを示しています。リソースには、ステップ 1 で作成したポリシーによって追加されたcluster.open-cluster-management.io/backup: cluster-activation
ラベルも必要です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Red Hat Advanced Cluster Management を使用して、マネージドクラスターを復元できるようになりました。
クラスターアクティベーションデータの復元の一環として BareMetalHosts
リソースを復元する場合、BareMetalHosts
ステータスを復元する必要があります。次の RHACM Restore
リソースの例では、BareMetalHosts
を含むアクティベーションリソースを復元し、BareMetalHosts
リソースのステータスも復元します。
第3章 GitOps ZTP の更新 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) インフラストラクチャーは、ハブクラスター、Red Hat Advanced Cluster Management (RHACM)、および OpenShift Container Platform マネージドクラスターとは別に更新できます。
新しいバージョンが利用可能になったら、Red Hat OpenShift GitOps Operator を更新できます。GitOps ZTP プラグインを更新するときは、参照設定で更新されたファイルを確認し、変更が要件を満たしていることを確認してください。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
3.1. GitOps ZTP 更新プロセスの概要 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの GitOps ZTP インフラストラクチャーを実行している、完全に機能するハブクラスターの GitOps Zero Touch Provisioning (ZTP) を更新できます。更新プロセスにより、マネージドクラスターへの影響が回避されます。
推奨コンテンツの追加など、ポリシー設定を変更すると、更新されたポリシーが作成され、マネージドクラスターにロールアウトして調整する必要があります。
GitOps ZTP インフラストラクチャーを更新するためのストラテジーの概要は次のとおりです。
-
既存のすべてのクラスターに
ztp-done
ラベルを付けます。 - ArgoCD アプリケーションを停止します。
- 新しい GitOps ZTP ツールをインストールします。
- Git リポジトリーで必要なコンテンツおよびオプションの変更を更新します。
- 必要な OpenShift Container Platform バージョンの ISO イメージのプルを有効にします。
- アプリケーション設定を更新して再起動します。
3.2. アップグレードの準備 リンクのコピーリンクがクリップボードにコピーされました!
次の手順を使用して、GitOps Zero Touch Provisioning (ZTP) アップグレードのためにサイトを準備します。
手順
- GitOps ZTP で使用するために Red Hat OpenShift GitOps を設定するために使用されるカスタムリソース (CR) を持つ GitOps ZTP コンテナーの最新バージョンを取得します。
次のコマンドを使用して、
argocd/deployment
ディレクトリーを抽出します。mkdir -p ./update
$ mkdir -p ./update
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 extract /home/ztp --tar | tar x -C ./update
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 extract /home/ztp --tar | tar x -C ./update
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /update
ディレクトリーには、次のサブディレクトリーが含まれています。-
update/extra-manifest
:SiteConfig
CR が追加のマニフェストconfigMap
を生成するために使用するソース CR ファイルが含まれています。 -
update/source-crs
:PolicyGenerator
またはPolicyGentemplate
CR が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれます。 -
update/argocd/deployment
には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。 -
update/argocd/example
: 推奨される設定を表すSiteConfig
と、PolicyGenerator
またはPolicyGentemplate
ファイルの例が含まれています。
-
clusters-app.yaml
ファイルおよびpolicies-app.yaml
ファイルを更新して、Git リポジトリーのアプリケーションおよび URL、ブランチ、およびパスを反映します。アップグレードにポリシーの廃止につながる変更が含まれている場合は、アップグレードを実行する前に、廃止されたポリシーを削除する必要があります。
/update
フォルダー内の設定およびデプロイソース CR と、フリートサイト CR を管理する Git リポジトリーとの間の変更を比較します。必要な変更をサイトリポジトリーに適用してプッシュします。重要GitOps ZTP を最新バージョンに更新するときは、
update/argocd/deployment
ディレクトリーからサイトリポジトリーに変更を適用する必要があります。古いバージョンのargocd/deployment/
ファイルは使用しないでください。
3.3. 既存クラスターのラベル付け リンクのコピーリンクがクリップボードにコピーされました!
既存のクラスターがツールの更新の影響を受けないようにするには、既存のすべてのマネージドクラスターに ztp-done
ラベルを付けます。
この手順は、Topology Aware Lifecycle Manager (TALM) でプロビジョニングされていないクラスターを更新する場合にのみ適用されます。TALM でプロビジョニングするクラスターには、自動的に ztp-done
というラベルが付けられます。
手順
local-cluster!=true
など、GitOps Zero Touch Provisioning (ZTP) でデプロイされたマネージドクラスターを一覧表示するラベルセレクターを見つけます。oc get managedcluster -l 'local-cluster!=true'
$ oc get managedcluster -l 'local-cluster!=true'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果のリストに、GitOps ZTP でデプロイされたすべてのマネージドクラスターが含まれていることを確認してから、そのセレクターを使用して
ztp-done
ラベルを追加します。oc label managedcluster -l 'local-cluster!=true' ztp-done=
$ oc label managedcluster -l 'local-cluster!=true' ztp-done=
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. 既存の GitOps ZTP アプリケーションの停止 リンクのコピーリンクがクリップボードにコピーされました!
既存のアプリケーションを削除すると、Git リポジトリー内の既存のコンテンツに対する変更は、ツールの新しいバージョンが利用可能になるまでロールアウトされません。
deployment
ディレクトリーからのアプリケーションファイルを使用します。アプリケーションにカスタム名を使用した場合は、まずこれらのファイルの名前を更新します。
手順
clusters
アプリケーションで非カスケード削除を実行して、生成されたすべてのリソースをそのまま残します。oc delete -f update/argocd/deployment/clusters-app.yaml
$ oc delete -f update/argocd/deployment/clusters-app.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow policies
アプリケーションでカスケード削除を実行して、以前のすべてのポリシーを削除します。oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge
$ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete -f update/argocd/deployment/policies-app.yaml
$ oc delete -f update/argocd/deployment/policies-app.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. Git リポジトリーに必要な変更 リンクのコピーリンクがクリップボードにコピーされました!
ztp-site-generate
コンテナーを以前のリリースの GitOps Zero Touch Provisioning (ZTP) から 4.10 以降にアップグレードする場合は、Git リポジトリーのコンテンツに関する追加の要件があります。これらの変更を反映するには、リポジトリー内の既存のコンテンツを更新する必要があります。
次の手順では、クラスターポリシー管理に PolicyGentemplate
リソースではなく、PolicyGenerator
リソースを使用していることを前提としています。
PolicyGenerator
ファイルに必要な変更を加えます。すべての
PolicyGenerator
ファイルは、ztp
という接頭辞が付いたNamespace
内に作成する必要があります。これにより、GitOps ZTP アプリケーションは、Red Hat Advanced Cluster Management (RHACM) が内部でポリシーを管理する方法と競合することなく、GitOps ZTP によって生成されたポリシー CR を管理できるようになります。kustomization.yaml
ファイルをリポジトリーに追加します。すべての
SiteConfig
およびPolicyGenerator
CR は、それぞれのディレクトリーツリーの下にあるkustomization.yaml
ファイルに含める必要があります。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記generator
セクションにリスト表示されているファイルには、SiteConfig
または{policy-gen-cr}
CR のいずれかのみが含まれている必要があります。既存の YAML ファイルにNamespace
などの他の CR が含まれている場合、これらの他の CR を別のファイルに取り出して、resources
セクションにリストする必要があります。PolicyGenerator
kustomization ファイルには、generator
セクション内のすべてのPolicyGenerator
YAML ファイルと、resources
セクションのNamespace
CR が含まれている必要があります。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
kustomization ファイルには、すべてのSiteConfig
YAML ファイルがgenerator
セクションおよびリソースの他の CR に含まれている必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pre-sync.yaml
ファイルおよびpost-sync.yaml
ファイルを削除します。OpenShift Container Platform 4.10 以降では、
pre-sync.yaml
およびpost-sync.yaml
ファイルは不要になりました。update/deployment/kustomization.yaml
CR は、ハブクラスターでのポリシーのデプロイを管理します。注記SiteConfig
ツリーと{policy-gen-cr}
ツリーの両方の下に、pre-sync.yaml
ファイルとpost-sync.yaml
ファイルのセットが存在します。推奨される変更の確認および組み込み
各リリースには、デプロイされたクラスターに適用される設定に推奨される追加の変更が含まれる場合があります。通常、これらの変更により、OpenShift プラットフォーム、追加機能、またはプラットフォームのチューニングが改善された CPU の使用率が低下します。
ネットワーク内のクラスターのタイプに適用可能なリファレンス
SiteConfig
およびPolicyGenerator
CR を確認します。これらの例は、GitOps ZTP コンテナーから抽出したargocd/example
ディレクトリーにあります。
3.6. 新規 GitOps ZTP アプリケーションのインストール リンクのコピーリンクがクリップボードにコピーされました!
展開した argocd/deployment
ディレクトリーを使用し、アプリケーションがサイトの Git リポジトリーをポイントすることを確認してから、deployment ディレクトリーの完全なコンテンツを適用します。ディレクトリーのすべての内容を適用すると、アプリケーションに必要なすべてのリソースが正しく設定されます。
手順
GitOps ZTP プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に
out/argocd/deployment/
ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。RHACM バージョンに一致する
multicluster-operators-subscription
イメージを選択します。-
RHACM 2.8 および 2.9 の場合は、
registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version>
イメージを使用します。 -
RHACM 2.10 以降の場合は、
registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version>
イメージを使用します。
重要multicluster-operators-subscription
イメージのバージョンは、RHACM のバージョンと一致する必要があります。MCE 2.10 リリース以降、RHEL 9 はmulticluster-operators-subscription
イメージのベースイメージです。OpenShift Operator のライフサイクル の表「Platform Aligned Operators」の
[Expand for Operator list]
をクリックすると、OpenShift Container Platform でサポートされている Operator の完全なマトリックスが表示されます。-
RHACM 2.8 および 2.9 の場合は、
RHACM バージョンに一致する
multicluster-operators-subscription
イメージを使用して、out/argocd/deployment/argocd-openshift-gitops-patch.json
ファイルを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。
oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
$ oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHACM 2.7 以降では、マルチクラスターエンジンはデフォルトで
cluster-proxy-addon
機能を有効にします。次のパッチを適用して、cluster-proxy-addon
機能を無効にし、このアドオンに関連するハブクラスターとマネージド Pod を削除します。以下のコマンドを実行します。oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
$ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。
oc apply -k out/argocd/deployment
$ oc apply -k out/argocd/deployment
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.7. 必要な OpenShift Container Platform バージョンの ISO イメージのプル リンクのコピーリンクがクリップボードにコピーされました!
必要な OpenShift Container Platform バージョンの ISO イメージをプルするには、ミラーレジストリー HTTP サーバーでホストされている必要な ISO および RootFS イメージへの参照を使用して AgentServiceConfig
カスタムリソース (CR) を更新します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 -
RHACM で
MultiClusterHub
が有効になっている。 - アシストサービスが有効になっている。
手順
spec.osImages
フィールドを更新するために、次のコマンドを実行してAgentServiceConfig
CR を開きます。oc edit AgentServiceConfig
$ oc edit AgentServiceConfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AgentServiceConfig
CR のspec.osImages
フィールドを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<host>
- ターゲットミラーレジストリー HTTP サーバーの完全修飾ドメイン名 (FQDN) を指定します。
<path>
- ターゲットミラーレジストリー上のイメージへのパスを指定します。
- エディターを保存して終了し、変更を適用します。
3.8. GitOps ZTP 設定の変更のロールアウト リンクのコピーリンクがクリップボードにコピーされました!
推奨される変更を実装したために設定の変更がアップグレードに含まれていた場合、アップグレードプロセスの結果、ハブクラスターの一連のポリシー CR が Non-Compliant
状態になります。GitOps Zero Touch Provisioning (ZTP) バージョン 4.10 以降の ztp-site-generate
コンテナーの場合、これらのポリシーは inform
モードに設定されており、ユーザーが追加の手順を実行しないとマネージドクラスターにプッシュされません。これにより、クラスターへの潜在的に破壊的な変更を、メンテナンスウィンドウなどでいつ変更が行われたか、および同時に更新されるクラスターの数に関して管理できるようになります。
変更をロールアウトするには、TALM ドキュメントの詳細に従って、1 つ以上の ClusterGroupUpgrade
CR を作成します。CR には、スポーククラスターにプッシュする Non-Compliant
ポリシーのリストと、更新に含めるクラスターのリストまたはセレクターが含まれている必要があります。
第4章 RHACM および SiteConfig リソースを使用したマネージドクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) を使用して OpenShift Container Platform クラスターを大規模にプロビジョニングするには、アシストサービスと、コア削減テクノロジーが有効になっている GitOps プラグインポリシージェネレーターを使用します。GitOps Zero Touch Provisioning (ZTP) パイプラインは、クラスターのインストールを実行します。GitOps ZTP は、非接続環境で使用できます。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
4.1. GitOps ZTP および Topology Aware Lifecycle Manager リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) は、Git に格納されたマニフェストからインストールと設定の CR を生成します。これらのアーティファクトは、Red Hat Advanced Cluster Management (RHACM)、アシストサービス、および Topology Aware Lifecycle Manager (TALM) が CR を使用してマネージドクラスターをインストールおよび設定する中央ハブクラスターに適用されます。GitOps ZTP パイプラインの設定フェーズでは、TALM を使用してクラスターに対する設定 CR の適用のオーケストレーションを行います。GitOps ZTP と TALM の間には、いくつかの重要な統合ポイントがあります。
- Inform ポリシー
-
デフォルトでは、GitOps ZTP は、
inform
の修復アクションですべてのポリシーを作成します。これらのポリシーにより、RHACM はポリシーに関連するクラスターのコンプライアンスステータスを報告しますが、必要な設定は適用されません。GitOps ZTP プロセスの中で OpenShift をインストールした後に、TALM は作成された各inform
ポリシーを確認し、これらのポリシーをターゲットのマネージドクラスターに適用します。これにより、設定がマネージドクラスターに適用されます。クラスターライフサイクルの GitOps ZTP フェーズ以外では、影響を受けるマネージドクラスターで変更をすぐにロールアウトするリスクなしに、ポリシーを変更できます。TALM を使用して、修復されたクラスターのタイミングとセットを制御できます。 - ClusterGroupUpgrade CR の自動作成
新しくデプロイされたクラスターの初期設定を自動化するために、TALM はハブクラスター上のすべての
ManagedCluster
CR の状態を監視します。新規に作成されたManagedCluster
CR を含むztp-done
ラベルを持たないManagedCluster
CR が適用されると、TALM は以下の特性でClusterGroupUpgrade
CR を自動的に作成します。-
ClusterGroupUpgrade
CR がztp-install
namespace に作成され、有効にされます。 -
ClusterGroupUpgrade
CR の名前はManagedCluster
CR と同じになります。 -
クラスターセレクターには、その
ManagedCluster
CR に関連付けられたクラスターのみが含まれます。 -
管理ポリシーのセットには、
ClusterGroupUpgrade
の作成時に RHACM がクラスターにバインドされているすべてのポリシーが含まれます。 - 事前キャッシュは無効です。
- タイムアウトを 4 時間 (240 分) に設定。
有効な
ClusterGroupUpgrade
の自動生成により、ユーザーの介入を必要としないゼロタッチのクラスター展開が可能になります。さらに、ztp-done
ラベルのないManagedCluster
に対してClusterGroupUpgrade
CR が自動的に作成されるため、そのクラスターのClusterGroupUpgrade
CR を削除するだけで失敗した GitOps ZTP インストールを再開できます。-
- Waves
PolicyGenerator
またはPolicyGentemplate
CR から生成された各ポリシーには、ztp-deploy-wave
アノテーションが含まれます。このアノテーションは、そのポリシーに含まれる各 CR と同じアノテーションに基づいています。wave アノテーションは、自動生成されたClusterGroupUpgrade
CR でポリシーを順序付けするために使用されます。wave アノテーションは、自動生成されたClusterGroupUpgrade
CR 以外には使用されません。注記同じポリシーのすべての CR には
ztp-deploy-wave
アノテーションに同じ設定が必要です。各 CR のこのアノテーションのデフォルト値は、PolicyGenerator
またはPolicyGentemplate
でオーバーライドできます。ソース CR の wave アノテーションは、ポリシーの wave アノテーションを判別し、設定するために使用されます。このアノテーションは、実行時に生成されるポリシーに含まれるビルドされる各 CR から削除されます。TALM は、wave アノテーションで指定された順序で設定ポリシーを適用します。TALM は、各ポリシーが準拠しているのを待ってから次のポリシーに移動します。各 CR の wave アノテーションは、それらの CR がクラスターに適用されるための前提条件を確実に考慮することが重要である。たとえば、Operator は Operator の設定前後にインストールする必要があります。同様に、Operator 用
CatalogSource
は、Operator 用サブスクリプションの前または同時にウェーブにインストールする必要があります。各 CR のデフォルトの波動値は、これらの前提条件を考慮したものです。複数の CR およびポリシーは同じアンブ番号を共有できます。ポリシーの数を少なくすることで、デプロイメントを高速化し、CPU 使用率を低減させることができます。多くの CR を比較的少なくするのがベストプラクティスです。
各ソース CR でデフォルトの wave 値を確認するには、ztp-site-generate
コンテナーイメージからデプロイメントした out/source-crs
ディレクトリーに対して以下のコマンドを実行します。
grep -r "ztp-deploy-wave" out/source-crs
$ grep -r "ztp-deploy-wave" out/source-crs
- フェーズラベル
ClusterGroupUpgrade
CR は自動的に作成され、そこには GitOps ZTP プロセスの開始時と終了時にManagedCluster
CR をラベルでアノテートするディレクティブが含まれています。インストール後に GitOps ZTP 設定が開始すると、
ManagedCluster
にztp-running
ラベルが適用されます。すべてのポリシーがクラスターに修復され、完全に準拠されると、TALM はztp-running
ラベルを削除し、ztp-done
ラベルを適用します。informDuValidator
ポリシーを使用するデプロイメントでは、クラスターが完全にアプリケーションをデプロイするための準備が整った時点でztp-done
ラベルが適用されます。これには、GitOps ZTP が適用された設定 CR の調整および影響がすべて含まれます。ztp-done
ラベルは、TALM によるClusterGroupUpgrade
CR の自動作成に影響します。クラスターの最初の GitOps ZTP インストール後は、このラベルを操作しないでください。- リンクされた CR
-
自動的に作成された
ClusterGroupUpgrade
CR には所有者の参照が、そこから派生したManagedCluster
として設定されます。この参照により、ManagedCluster
CR を削除すると、ClusterGroupUpgrade
のインスタンスがサポートされるリソースと共に削除されるようにします。
4.2. GitOps ZTP を使用したマネージドクラスターのデプロイの概要 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) は、GitOps Zero Touch Provisioning (ZTP) を使用して、シングルノード OpenShift Container Platform クラスター、3 ノードのクラスター、および標準クラスターをデプロイします。サイト設定データは、Git リポジトリーで OpenShift Container Platform カスタムリソース (CR) として管理します。GitOps ZTP は、宣言的な GitOps アプローチを使用して、一度開発すればどこにでもデプロイできるモデルを使用して、マネージドクラスターをデプロイします。
クラスターのデプロイメントには、以下が含まれます。
- ホストオペレーティングシステム (RHCOS) の空のサーバーへのインストール。
- OpenShift Container Platform のデプロイ
- クラスターポリシーおよびサイトサブスクリプションの作成
- サーバーオペレーティングシステムに必要なネットワーク設定を行う
- プロファイル Operator をデプロイし、パフォーマンスプロファイル、PTP、SR-IOV などの必要なソフトウェア関連の設定を実行します。
マネージドサイトのインストールプロセスの概要
マネージドサイトのカスタムリソース (CR) をハブクラスターに適用すると、次のアクションが自動的に実行されます。
- Discovery イメージの ISO ファイルが生成され、ターゲットホストで起動します。
- ISO ファイルがターゲットホストで正常に起動すると、ホストのハードウェア情報が RHACM にレポートされます。
- すべてのホストの検出後に、OpenShift Container Platform がインストールされます。
-
OpenShift Container Platform のインストールが完了すると、ハブは
klusterlet
サービスをターゲットクラスターにインストールします。 - 要求されたアドオンサービスがターゲットクラスターにインストールされている。
マネージドクラスターの Agent
CR がハブクラスター上に作成されると、検出イメージ ISO プロセスが完了します。
ターゲットのベアメタルホストは、vDU アプリケーションワークロードに推奨されるシングルノード OpenShift クラスター設定 に記載されているネットワーク、ファームウェア、およびハードウェアの要件を満たす必要があります。
4.3. マネージドベアメタルホストシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
マネージドベアメタルホストに必要な Secret
カスタムリソース (CR) をハブクラスターに追加します。GitOps Zero Touch Provisioning (ZTP) パイプラインが Baseboard Management Controller (BMC) にアクセスするためのシークレットと、アシストインストーラーサービスがレジストリーからクラスターインストールイメージを取得するためのシークレットが必要です。
シークレットは、SiteConfig
CR から名前で参照されます。namespace は SiteConfig
namespace と一致する必要があります。
手順
ホスト Baseboard Management Controller (BMC) の認証情報と、OpenShift およびすべてのアドオンクラスター Operator のインストールに必要なプルシークレットを含む YAML シークレットファイルを作成します。
-
example-sno-secret.yaml
への相対パスを、クラスターのインストールに使用するkustomization.yaml
ファイルに追加します。
4.4. GitOps ZTP を使用したインストール用の Discovery ISO カーネル引数の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) ワークフローは、マネージドベアメタルホストでの OpenShift Container Platform インストールプロセスの一部として Discovery ISO を使用します。InfraEnv
リソースを編集して、Discovery ISO のカーネル引数を指定できます。これは、特定の環境要件を持つクラスターのインストールに役立ちます。たとえば、Discovery ISO の rd.net.timeout.carrier
カーネル引数を設定して、クラスターの静的ネットワーク設定を容易にしたり、インストール中に root ファイルシステムをダウンロードする前に DHCP アドレスを受信したりできます。
OpenShift Container Platform 4.18 では、カーネル引数のみを追加できます。カーネル引数を置き換えたり削除したりすることはできません。
前提条件
- OpenShift CLI (oc) がインストールされている。
- cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
手順
InfraEnv
CR を作成し、spec.kernelArguments
仕様を編集してカーネル引数を設定します。次の YAML を
InfraEnv-example.yaml
ファイルに保存します。注記この例の
InfraEnv
CR は、SiteConfig
CR の値に基づいて入力される{{ .Cluster.ClusterName }}
などのテンプレート構文を使用します。SiteConfig
CR は、デプロイメント中にこれらのテンプレートの値を自動的に設定します。テンプレートを手動で編集しないでください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
InfraEnv-example.yaml
CR を、Git リポジトリー内のSiteConfig
CR と同じ場所にコミットし、変更をプッシュします。次の例は、サンプルの Git リポジトリー構造を示しています。~/example-ztp/install └── site-install ├── siteconfig-example.yaml ├── InfraEnv-example.yaml ...
~/example-ztp/install └── site-install ├── siteconfig-example.yaml ├── InfraEnv-example.yaml ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
CR のspec.clusters.crTemplates
仕様を編集して、Git リポジトリーのInfraEnv-example.yaml
CR を参照します。clusters: crTemplates: InfraEnv: "InfraEnv-example.yaml"
clusters: crTemplates: InfraEnv: "InfraEnv-example.yaml"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
CR をコミットおよびプッシュしてクラスターをデプロイする準備ができたら、ビルドパイプラインは Git リポジトリー内のカスタムInfraEnv-example
CR を使用して、カスタムカーネル引数を含むインフラストラクチャー環境を設定します。
検証
カーネル引数が適用されていることを確認するには、Discovery イメージが OpenShift Container Platform をインストールする準備ができていることを確認した後、インストールプロセスを開始する前にターゲットホストに SSH 接続します。その時点で、/proc/cmdline
ファイルで Discovery ISO のカーネル引数を表示できます。
ターゲットホストとの SSH セッションを開始します。
ssh -i /path/to/privatekey core@<host_name>
$ ssh -i /path/to/privatekey core@<host_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、システムのカーネル引数を表示します。
cat /proc/cmdline
$ cat /proc/cmdline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. SiteConfig と GitOps ZTP を使用したマネージドクラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
次の手順を使用して、SiteConfig
カスタムリソース (CR) と関連ファイルを作成し、GitOps Zero Touch Provisioning (ZTP) クラスターのデプロイメントを開始します。
SiteConfig v1 は、OpenShift Container Platform バージョン 4.18 以降では非推奨になります。ClusterInstance
カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。
SiteConfig Operator の詳細は、SiteConfig を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセスできる必要があり、ArgoCD アプリケーションのソースリポジトリーとして設定する必要があります。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。
注記ソースリポジトリーを作成するときは、
ztp-site-generate
コンテナーから抽出したargocd/deployment/argocd-openshift-gitops-patch.json
パッチファイルを使用して ArgoCD アプリケーションにパッチを適用してください。「ArgoCD を使用したハブクラスターの設定」を参照してください。マネージドクラスターをプロビジョニングする準備を整えるには、各ベアメタルホストごとに次のものが必要です。
- ネットワーク接続
- ネットワークには DNS が必要です。マネージドクラスターホストは、ハブクラスターから到達可能である必要があります。ハブクラスターとマネージドクラスターホストの間にレイヤー 3 接続が存在することを確認します。
- Baseboard Management Controller (BMC) の詳細
-
GitOps ZTP は、BMC のユーザー名とパスワードの詳細を使用して、クラスターのインストール中に BMC に接続します。GitOps ZTP プラグインは、サイトの Git リポジトリーの
SiteConfig
CR に基づいて、ハブクラスター上のManagedCluster
CR を管理します。ホストごとに個別のBMCSecret
CR を手動で作成します。
手順
ハブクラスターで必要なマネージドクラスターシークレットを作成します。これらのリソースは、クラスター名と一致する名前を持つネームスペースに存在する必要があります。たとえば、
out/argocd/example/siteconfig/example-sno.yaml
では、クラスター名と namespace がexample-sno
になっています。次のコマンドを実行して、クラスター namespace をエクスポートします。
export CLUSTERNS=example-sno
$ export CLUSTERNS=example-sno
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace を作成します。
oc create namespace $CLUSTERNS
$ oc create namespace $CLUSTERNS
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
マネージドクラスターのプルシークレットと BMC
Secret
CR を作成します。プルシークレットには、OpenShift Container Platform のインストールに必要なすべての認証情報と、必要なすべての Operator を含める必要があります。詳細は、「マネージドベアメタルホストシークレットの作成」を参照してください。注記シークレットは、名前で
SiteConfig
カスタムリソース (CR) から参照されます。namespace はSiteConfig
namespace と一致する必要があります。Git リポジトリーのローカルクローンに、クラスターの
SiteConfig
CR を作成します。out/argocd/example/siteconfig/
フォルダーから CR の適切な例を選択します。フォルダーには、シングルノード、3 ノード、標準クラスターのサンプルファイルが含まれます。-
example-sno.yaml
-
example-3node.yaml
-
example-standard.yaml
-
サンプルファイルのクラスターおよびホスト詳細を、必要なクラスタータイプに一致するように変更します。以下に例を示します。
シングルノード OpenShift SiteConfig CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。この例では、読みやすくするために、
installConfigOverrides
フィールドとignitionConfigOverride
フィールドが展開されています。注記ノードのデフォルトの
BareMetalHost
CR をオーバーライドするには、SiteConfig
CR のノードレベルのcrTemplates
フィールドでオーバーライド用の CR を参照できます。オーバーライド用のBareMetalHost
CR で、必ずargocd.argoproj.io/sync-wave: "3"
アノテーションを設定してください。-
out/argocd/extra-manifest
で extra-manifestMachineConfig
CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。 オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、Git リポジトリーに
sno-extra-manifest/
などのディレクトリーを作成し、このディレクトリーにカスタムマニフェストの CR を追加します。SiteConfig.yaml
がextraManifestPath
フィールドでこのディレクトリーを参照する場合、この参照ディレクトリーの CR はすべて、デフォルトの追加マニフェストセットに追加されます。crun OCI コンテナーランタイムの有効化クラスターのパフォーマンスを最適化するには、シングルノード OpenShift、追加のワーカーノードを備えたシングルノード OpenShift、3 ノード OpenShift、および標準クラスターのマスターノードとワーカーノードで crun を有効にします。
クラスターの再起動を回避するには、追加の Day 0 インストール時マニフェストとして
ContainerRuntimeConfig
CR で crun を有効にします。enable-crun-master.yaml
およびenable-crun-worker.yaml
CR ファイルは、ztp-site-generate
コンテナーから抽出できるout/source-crs/optional-extra-manifest/
フォルダーにあります。詳細は、「GitOps ZTP パイプラインでの追加インストールマニフェストのカスタマイズ」を参照してください。
-
out/argocd/example/siteconfig/kustomization.yaml
に示す例のように、generators
セクションのkustomization.yaml
ファイルにSiteConfig
CR を追加してください。 SiteConfig
CR と関連するkustomization.yaml
の変更を Git リポジトリーにコミットし、変更をプッシュします。ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。
検証
ノードのデプロイ後にカスタムのロールとラベルが適用されていることを確認します。
oc describe node example-node.example.com
$ oc describe node example-node.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
出力例
- 1
- カスタムラベルがノードに適用されます。
4.5.1. GitOps ZTP の高速プロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP の高速プロビジョニングは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
シングルノード OpenShift 用の GitOps ZTP の高速プロビジョニングを使用すると、クラスターのインストールにかかる時間を短縮できます。高速 ZTP は、ポリシーから派生した Day 2 マニフェストを早い段階で適用することで、インストールを高速化します。
GitOps ZTP の高速プロビジョニングは、Assisted Installer を使用してシングルノード OpenShift をインストールする場合にのみサポートされます。これ以外の場合は、このインストール方法は失敗します。
4.5.1.1. 高速 ZTP のアクティブ化 リンクのコピーリンクがクリップボードにコピーされました!
以下の例のように、spec.clusters.clusterLabels.accelerated-ztp
ラベルを使用して高速 ZTP をアクティブ化できます。
高速 ZTP SiteConfig
CR の例。
accelerated-ztp: full
を使用すると、高速化プロセスを完全に自動化できます。GitOps ZTP により、高速 GitOps ZTP ConfigMap
への参照を使用して AgentClusterInstall
リソースが更新され、TALM によってポリシーから抽出されたリソースと、高速 ZTP ジョブマニフェストが追加されます。
accelerated-ztp: partial
を使用すると、GitOps ZTP により、高速ジョブマニフェストは追加されませんが、次の kind
のクラスターインストール中に作成されたポリシーに基づくオブジェクトが追加されます。
-
PerformanceProfile.performance.openshift.io
-
Tuned.tuned.openshift.io
-
Namespace
-
CatalogSource.operators.coreos.com
-
ContainerRuntimeConfig.machineconfiguration.openshift.io
この部分的な高速化により、Performance Profile
、Tuned
、および ContainerRuntimeConfig
などの kind のリソースを適用するときに、ノードによって実行される再起動の回数を減らすことができます。TALM は、RHACM がクラスターのインポートを完了した後、標準の GitOps ZTP と同じフローに従って、ポリシーに基づく Operator サブスクリプションをインストールします。
高速 ZTP の利点は、デプロイメントの規模に応じて増大します。accelerated-ztp: full
を使用すると、多数のクラスターでより大きなメリットをもたらします。クラスターの数が少ない場合、インストール時間の短縮はそれほど大きくありません。完全な高速 ZTP では、スポーク上に namespace と完了したジョブが残るため、手動で削除する必要があります。
accelerated-ztp: partial
を使用する利点の 1 つは、ストック実装で問題が発生した場合やカスタム機能が必要な場合に、オンスポークジョブの機能をオーバーライドできることです。
4.5.1.2. 高速 ZTP のプロセス リンクのコピーリンクがクリップボードにコピーされました!
高速 ZTP は追加の ConfigMap
を使用して、スポーククラスターのポリシーに基づくリソースを作成します。標準の ConfigMap
には、GitOps ZTP ワークフローがクラスターのインストールをカスタマイズするために使用するマニフェストが含まれています。
TALM は accelerated-ztp
ラベルが設定されていることを検出後、2 番目の ConfigMap
を作成します。高速 ZTP の一部として、SiteConfig
ジェネレーターは、命名規則 <spoke-cluster-name>-aztp
を使用して、2 番目の ConfigMap
への参照を追加します。
TALM は 2 番目の ConfigMap
を作成した後、マネージドクラスターにバインドされているすべてのポリシーを検出し、GitOps ZTP プロファイル情報を抽出します。TALM は、GitOps ZTP プロファイル情報を <spoke-cluster-name>-aztp
ConfigMap
カスタムリソース (CR) に追加し、その CR をハブクラスター API に適用します。
4.5.2. GitOps ZTP および SiteConfig リソースを使用したシングルノード OpenShift クラスターの IPsec 暗号化の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP と Red Hat Advanced Cluster Management (RHACM) を使用してインストールするシングルノード OpenShift マネージドクラスターで IPsec 暗号化を有効にできます。マネージドクラスターと、マネージドクラスター外の IPsec エンドポイント間のトラフィックを暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべてのネットワークトラフィックが、Transport モードの IPsec で暗号化されます。
次の手順に従って、追加のワーカーノードを備えたシングルノード OpenShift クラスターの IPsec 暗号化を設定することもできます。シングルノード OpenShift クラスターおよび追加のワーカーノードを備えたシングルノード OpenShift クラスターの IPsec 暗号化を設定する際には、リソースの可用性が低いため、MachineConfig
カスタムリソース (CR) を使用することを推奨します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - マネージドクラスターに必要なインストールおよびポリシーカスタムリソース (CR) を生成するために、RHACM とハブクラスターを設定している。
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
-
butane
ユーティリティーバージョン 0.20.0 以降がインストールされている。 - IPsec エンドポイント用の PKCS#12 証明書と PEM 形式の CA 証明書がある。
手順
-
ztp-site-generate
コンテナーソースの最新バージョンを抽出し、カスタムサイト設定データを管理するリポジトリーとマージします。 クラスター内の IPsec を設定するために必要な値を使用して、
optional-extra-manifest/ipsec/ipsec-endpoint-config.yaml
を設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の証明書を
optional-extra-manifest/ipsec
フォルダーに追加します。-
left_server.p12
: IPsec エンドポイントの証明書バンドル ca.pem
: 証明書に署名した認証局証明書ファイルは、各ホストのネットワークセキュリティーサービス (NSS) データベースで必要です。これらのファイルは、後の手順で Butane 設定の一部としてインポートされます。
-
-
カスタムサイト設定データを保持する Git リポジトリーの
optional-extra-manifest/ipsec
フォルダーでシェルプロンプトを開きます。 必要な Butane および
MachineConfig
CR ファイルを生成するには、optional-extra-manifest/ipsec/build.sh
スクリプトを実行します。PKCS#12 証明書がパスワードで保護されている場合は、
-W
引数を設定します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カスタムサイト設定データを管理するリポジトリーに
custom-manifest/
フォルダーを作成します。enable-ipsec.yaml
および99-ipsec-*
YAML ファイルをディレクトリーに追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
CR で、extraManifests.searchPaths
フィールドにcustom-manifest/
ディレクトリーを追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
CR の変更と更新されたファイルを Git リポジトリーにコミットし、変更をプッシュしてマネージドクラスターをプロビジョニングし、IPsec 暗号化を設定します。Argo CD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。
クラスターのプロビジョニング中に、GitOps ZTP パイプラインが、
custom-manifest/
ディレクトリー内の CR を、extra-manifest/
ディレクトリーに保存されているデフォルトの追加マニフェストのセットに追加します。
検証
IPsec 暗号化の検証は、「IPsec 暗号化の検証」を参照してください。
4.5.3. GitOps ZTP および SiteConfig リソースを使用したマルチノードクラスターの IPsec 暗号化の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP と Red Hat Advanced Cluster Management (RHACM) を使用してインストールするマネージドマルチノードクラスターで、IPsec 暗号化を有効にできます。マネージドクラスターと、マネージドクラスター外の IPsec エンドポイント間のトラフィックを暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべてのネットワークトラフィックが、Transport モードの IPsec で暗号化されます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - マネージドクラスターに必要なインストールおよびポリシーカスタムリソース (CR) を生成するために、RHACM とハブクラスターを設定している。
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
-
butane
ユーティリティーバージョン 0.20.0 以降がインストールされている。 - IPsec エンドポイント用の PKCS#12 証明書と PEM 形式の CA 証明書がある。
- NMState Operator がインストールされている。
手順
-
ztp-site-generate
コンテナーソースの最新バージョンを抽出し、カスタムサイト設定データを管理するリポジトリーとマージします。 クラスター内の IPsec を設定するために必要な値を使用して、
optional-extra-manifest/ipsec/ipsec-config-policy.yaml
ファイルを設定します。IPsec 設定を作成するための
ConfigurationPolicy
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の証明書を
optional-extra-manifest/ipsec
フォルダーに追加します。-
left_server.p12
: IPsec エンドポイントの証明書バンドル ca.pem
: 証明書に署名した認証局証明書ファイルは、各ホストのネットワークセキュリティーサービス (NSS) データベースで必要です。これらのファイルは、後の手順で Butane 設定の一部としてインポートされます。
-
-
カスタムサイト設定データを保持する Git リポジトリーの
optional-extra-manifest/ipsec
フォルダーでシェルプロンプトを開きます。 optional-extra-manifest/ipsec/import-certs.sh
スクリプトを実行して、外部証明書をインポートするために必要な Butane およびMachineConfig
CR を生成します。PKCS#12 証明書がパスワードで保護されている場合は、
-W
引数を設定します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カスタムのサイト設定データを管理するリポジトリーに
custom-manifest/
フォルダーを作成し、enable-ipsec.yaml
および99-ipsec-*
YAML ファイルをディレクトリーに追加します。siteconfig
ディレクトリーの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
CR で、次の例のように、extraManifests.searchPaths
フィールドにcustom-manifest/
ディレクトリーを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
GitOps の
source-crs
ディレクトリーにipsec-config-policy.yaml
設定ポリシーファイルを格納し、PolicyGenerator
CR の 1 つでそのファイルを参照します。 SiteConfig
CR の変更と更新されたファイルを Git リポジトリーにコミットし、変更をプッシュしてマネージドクラスターをプロビジョニングし、IPsec 暗号化を設定します。Argo CD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。
クラスターのプロビジョニング中に、GitOps ZTP パイプラインが、
custom-manifest/
ディレクトリー内の CR を、extra-manifest/
ディレクトリーに保存されているデフォルトの追加マニフェストのセットに追加します。
検証
IPsec 暗号化の検証は、「IPsec 暗号化の検証」を参照してください。
4.5.4. IPsec 暗号化の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform マネージドクラスターで IPsec 暗号化が正常に適用されていることを確認できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - IPsec 暗号化が設定されている。
手順
次のコマンドを実行して、マネージドクラスターのデバッグ Pod を起動します。
oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、IPsec ポリシーがクラスターノードに適用されていることを確認します。
ip xfrm policy
sh-5.1# ip xfrm policy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、IPsec トンネルが起動し接続されていることを確認します。
ip xfrm state
sh-5.1# ip xfrm state
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、外部ホストサブネット内の既知の IP を ping します。たとえば、
ipsec/ipsec-endpoint-config.yaml
ファイルで設定したrightsubnet
範囲内の IP アドレスを ping します。ping 172.16.110.8
sh-5.1# ping 172.16.110.8
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
PING 172.16.110.8 (172.16.110.8) 56(84) bytes of data. 64 bytes from 172.16.110.8: icmp_seq=1 ttl=64 time=153 ms 64 bytes from 172.16.110.8: icmp_seq=2 ttl=64 time=155 ms
PING 172.16.110.8 (172.16.110.8) 56(84) bytes of data. 64 bytes from 172.16.110.8: icmp_seq=1 ttl=64 time=153 ms 64 bytes from 172.16.110.8: icmp_seq=2 ttl=64 time=155 ms
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.5. シングルノード OpenShift SiteConfig CR インストールリファレンス リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig CR フィールド | 説明 |
---|---|
|
|
|
|
|
サイト内のすべてのクラスターのハブクラスターで使用できるイメージセットを設定します。ハブクラスターでサポートされるバージョンの一覧を表示するには、 |
|
クラスターのインストール前に、 重要
|
|
個々のクラスターをデプロイするために使用されるクラスターイメージセットを指定します。定義されている場合、サイトレベルで |
|
定義した
たとえば、 |
|
オプション: |
| このフィールドを設定すると、Trusted Platform Module (TPM) と Platform Configuration Register (PCR) 保護によるディスク暗号化が有効になります。詳細は、「TPM と PCR の保護によるディスク暗号化について」を参照してください。 注記
|
|
ディスク暗号化タイプを |
| ディスク暗号化用の Platform Configuration Register (PCR) 保護を設定します。 |
| ディスク暗号化に使用する Platform Configuration Register (PCR) のリストを設定します。PCR レジスター 1 と 7 を使用する必要があります。 |
|
シングルノードの導入では、単一のホストを定義します。3 ノードのデプロイメントの場合、3 台のホストを定義します。標準のデプロイメントでは、 |
| マネージドクラスター内のノードのカスタムロールを指定します。これらは追加のロールであり、OpenShift Container Platform コンポーネントでは使用されず、ユーザーによってのみ使用されます。カスタムロールを追加すると、そのロールの特定の設定を参照するカスタムマシン設定プールに関連付けることができます。インストール中にカスタムラベルまたはロールを追加すると、デプロイメントプロセスがより効率的になり、インストール完了後に追加の再起動が必要なくなります。 |
|
オプション: コメントを解除して値を |
| ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。 |
| ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。 注記 ファーエッジ通信会社のユースケースでは、GitOps ZTP では仮想メディアの使用のみがサポートされます。 |
|
ホスト BMC 認証情報を使用して、別途作成した |
|
ホストのブートモードを |
|
導入するデバイスを指定します。再起動後も安定した識別子が推奨されます。たとえば、 |
| オプション: このフィールドを使用して、永続ストレージのパーティションを割り当てます。ディスク ID とサイズを特定のハードウェアに合わせて調整します。 |
| ノードのネットワーク設定を行います。 |
| ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つシングルノード OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。 |
4.6. GitOps ZTP によるホストファームウェア設定の管理 リンクのコピーリンクがクリップボードにコピーされました!
高いパフォーマンスと最適な効率を確保するには、ホストに正しいファームウェア設定が必要です。GitOps ZTP を使用すると、マネージドクラスターのカスタムのホストファームウェア設定をデプロイできます。
ラボ内で詳細なハードウェアプロファイルを使用してホストをチューニングし、要件に合わせてホストを最適化してください。満足のいくホストのチューニングが完了したら、ホストプロファイルを抽出し、GitOps ZTP リポジトリーに保存します。その後、ホストプロファイルを使用して、GitOps ZTP でデプロイするマネージドクラスターホストのファームウェア設定を指定します。
必要なハードウェアプロファイルは、マネージドクラスターのデプロイに使用する SiteConfig
カスタムリソース (CR) で指定します。GitOps ZTP パイプラインによって、ハブクラスターに適用される必要な HostFirmwareSettings
(HFS
) および BareMetalHost
(BMH
) CR が生成されます。
ホストのファームウェアプロファイルを管理する際には、次のベストプラクティスを使用してください。
- ハードウェアベンダーと協力して重要なファームウェア設定を特定する
- ハードウェアベンダーと協力して、最適なパフォーマンスと、デプロイされるホストプラットフォームとの互換性を確保するのに必要な、重要なホストファームウェア設定を特定してドキュメント化します。
- 類似するハードウェアプラットフォーム間で共通のファームウェア設定を使用する
- 可能であれば、類似するハードウェアプラットフォーム間で標準化されたホストファームウェア設定を使用して、デプロイ時の複雑さと潜在的なエラーを軽減します。
- ラボ環境でファームウェア設定をテストする
- 実稼働環境にデプロイする前に、制御されたラボ環境でホストファームウェア設定をテストし、ハードウェア、ファームウェア、ソフトウェアと設定の間に互換性があることを確認します。
- ソースコントロールでファームウェアプロファイルを管理する
- 変更を追跡し、一貫性を確保し、ベンダーとの協働を容易にするために、Git リポジトリーでホストのファームウェアプロファイルを管理します。
4.6.1. マネージドクラスターのホストファームウェアスキーマの取得 リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターのホストファームウェアスキーマを検出できます。ベアメタルホストのホストファームウェアスキーマには、Ironic API が返す情報が入力されます。この API は、ファームウェア設定タイプ、許容値、範囲、フラグなど、ホストのファームウェアインターフェイスに関する情報を返します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
Red Hat Advanced Cluster Management (RHACM) をインストールを完了し、
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - RHACM によって管理されるクラスターをプロビジョニングした。
手順
マネージドクラスターのホストファームウェアスキーマを検出します。以下のコマンドを実行します。
oc get firmwareschema -n <managed_cluster_namespace> -o yaml
$ oc get firmwareschema -n <managed_cluster_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.2. マネージドクラスターのホストファームウェア設定の取得 リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターのホストファームウェア設定を取得できます。これは、ホストファームウェアに変更をデプロイし、変更を監視して正常に適用されていることを確認する場合に便利です。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
Red Hat Advanced Cluster Management (RHACM) をインストールを完了し、
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - RHACM によって管理されるクラスターをプロビジョニングした。
手順
マネージドクラスターのホストファームウェア設定を取得します。以下のコマンドを実行します。
oc get hostfirmwaresettings -n <cluster_namespace> <node_name> -o yaml
$ oc get hostfirmwaresettings -n <cluster_namespace> <node_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: クラスターの
HostFirmwareSettings
(hfs
) カスタムリソースのステータスを確認します。oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="ChangeDetected")].status}'
$ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="ChangeDetected")].status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
True
True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: クラスターホストに無効なファームウェア設定がないか確認します。以下のコマンドを実行します。
oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="Valid")].status}'
$ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="Valid")].status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
False
False
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.3. GitOps ZTP を使用してユーザー定義のファームウェアをクラスターホストにデプロイする リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
カスタムリソース (CR) を設定し、クラスターホストのプロビジョニング中に適用するハードウェアプロファイルを含めることで、ユーザー定義のファームウェア設定をクラスターホストにデプロイできます。次のホストを対象に、適用するハードウェアプロファイルを設定できます。
- サイト全体のすべてのホスト
- 特定の条件を満たすクラスターホストのみ
- 個々のクラスターホスト
ホストのハードウェアプロファイルは、階層的に適用するように設定できます。クラスターレベルの設定は、サイト全体の設定をオーバーライドします。ノードレベルのプロファイルは、クラスターレベルの設定とサイト全体の設定をオーバーライドします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
Red Hat Advanced Cluster Management (RHACM) をインストールを完了し、
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - RHACM によって管理されるクラスターをプロビジョニングした。
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
適用するファームウェア設定を含むホストファームウェアプロファイルを作成します。たとえば、次の YAML ファイルを作成します。
host-firmware.profile
BootMode: Uefi LogicalProc: Enabled ProcVirtualization: Enabled
BootMode: Uefi LogicalProc: Enabled ProcVirtualization: Enabled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのプロビジョニング方法を定義するために使用する
kustomization.yaml
ファイルを基準として、ハードウェアプロファイルの YAML ファイルを保存します。次に例を示します。example-ztp/install └── site-install ├── siteconfig-example.yaml ├── kustomization.yaml └── host-firmware.profile
example-ztp/install └── site-install ├── siteconfig-example.yaml ├── kustomization.yaml └── host-firmware.profile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
CR を編集して、クラスターに適用するファームウェアプロファイルを含めます。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サイト全体のすべてのクラスターホストにハードウェアプロファイルを適用します。
注記可能な場合は、クラスターごとに 1 つの
SiteConfig
CR を使用してください。オプション: 特定のクラスター内のホストにハードウェアプロファイルを適用するには、
clusters.biosConfigRef.filePath
を適用するハードウェアプロファイルで更新します。以下に例を示します。clusters: - clusterName: "cluster-1" # ... biosConfigRef: filePath: "./host-firmware.profile"
clusters: - clusterName: "cluster-1" # ... biosConfigRef: filePath: "./host-firmware.profile"
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cluster-1
クラスター内のすべてのホストに適用されます。
オプション: クラスター内の特定のホストにハードウェアプロファイルを適用するには、
clusters.nodes.biosConfigRef.filePath
を、適用するハードウェアプロファイルで更新します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ファームウェアプロファイルをクラスター内の
compute-1.example.com
ホストに適用します。
SiteConfig
CR と関連するkustomization.yaml
の変更を Git リポジトリーにコミットし、変更をプッシュします。ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。
注記無効なファームウェア設定が検出された場合でも、クラスターのデプロイは続行されます。GitOps ZTP を使用して修正を適用するには、修正したハードウェアプロファイルを使用してクラスターを再デプロイしてください。
検証
マネージドクラスターのホストにファームウェア設定が適用されていることを確認します。たとえば、以下のコマンドを実行します。
oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="Valid")].status}'
$ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="Valid")].status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
True
True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7. マネージドクラスターのインストールの進行状況の監視 リンクのコピーリンクがクリップボードにコピーされました!
ArgoCD パイプラインは、SiteConfig
CR を使用してクラスター設定 CR を生成し、それをハブクラスターと同期します。ArgoCD ダッシュボードでこの同期の進捗をモニターできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
同期が完了すると、インストールは一般的に以下のように行われます。
Assisted Service Operator は OpenShift Container Platform をクラスターにインストールします。次のコマンドを実行して、RHACM ダッシュボードまたはコマンドラインからクラスターのインストールの進行状況を監視できます。
クラスター名をエクスポートします。
export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターの
AgentClusterInstall
CR をクエリーします。oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
$ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのインストールイベントを取得します。
curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'
$ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8. インストール CR の検証による GitOps ZTP のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
ArgoCD パイプラインは SiteConfig
と、PolicyGenerator
または PolicyGentemplate
カスタムリソース (CR) を使用して、クラスター設定 CR と Red Hat Advanced Cluster Management (RHACM) ポリシーを生成します。以下の手順に従って、このプロセス時に発生する可能性のある問題のトラブルシューティングを行います。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
インストール CR が作成されたことは、以下のコマンドで確認することができます。
oc get AgentClusterInstall -n <cluster_name>
$ oc get AgentClusterInstall -n <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オブジェクトが返されない場合は、以下の手順を使用して ArgoCD パイプラインフローを
SiteConfig
ファイルからインストール CR にトラブルシューティングします。ハブクラスターで
SiteConfig
CR を使用してManagedCluster
CR が生成されたことを確認します。oc get managedcluster
$ oc get managedcluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ManagedCluster
が見つからない場合は、clusters
アプリケーションが Git リポジトリーからハブクラスターへのファイルの同期に失敗したかどうかを確認します。oc get applications.argoproj.io -n openshift-gitops clusters -o yaml
$ oc get applications.argoproj.io -n openshift-gitops clusters -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターのエラーログを識別するには、
status.operationState.syncResult.resources
フィールドを調べます。たとえば、SiteConfig
CR のextraManifestPath
に無効な値が割り当てられると、次のようなエラーが生成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow より詳細な
SiteConfig
エラーを表示するには、次の手順を実行します。- Argo CD ダッシュボードで、Argo CD が同期しようとしている SiteConfig リソースをクリックします。
DESIRED MANIFEST タブをチェックして、
siteConfigError
フィールドを見つけます。siteConfigError: >- Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-1081291903: stat sno-extra-manifest: no such file or directory
siteConfigError: >- Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-1081291903: stat sno-extra-manifest: no such file or directory
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Status.Sync
フィールドを確認します。ログエラーがある場合、Status.Sync
フィールドはUnknown
エラーを示している可能性があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9. SuperMicro サーバー上で起動する GitOps ZTP 仮想メディアのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
SuperMicro X11 サーバーは、イメージが https
プロトコルを使用して提供される場合、仮想メディアのインストールをサポートしません。そのため、この環境のシングルノード OpenShift デプロイメントはターゲットノードで起動できません。この問題を回避するには、ハブクラスターにログインし、Provisioning
リソースで Transport Layer Security (TLS) を無効にします。これにより、イメージアドレスで https
スキームを使用している場合でも、イメージは TLS で提供されなくなります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
次のコマンドを実行して、
Provisioning
リソースの TLS を無効にします。oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'
$ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - シングルノード OpenShift クラスターをデプロイする手順を続行します。
4.10. GitOps ZTP パイプラインからのマネージドクラスターサイトの削除 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) パイプラインから、マネージドサイトと、関連するインストールおよび設定ポリシー CR を削除できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
-
kustomization.yaml
ファイルから、関連するSiteConfig
と、PolicyGenerator
またはPolicyGentemplate
ファイルを削除して、サイトと関連する CR を削除します。 次の
syncOptions
フィールドをSiteConfig
アプリケーションに追加します。kind: Application spec: syncPolicy: syncOptions: - PrunePropagationPolicy=background
kind: Application spec: syncPolicy: syncOptions: - PrunePropagationPolicy=background
Copy to Clipboard Copied! Toggle word wrap Toggle overflow GitOps ZTP パイプラインを再度実行すると、生成された CR は削除されます。
-
オプション: サイトを完全に削除する場合は、
SiteConfig
と、サイト固有のPolicyGenerator
またはPolicyGentemplate
ファイルも Git リポジトリーから削除する必要があります。 -
オプション: サイトを再デプロイする場合など、一時的にサイトを削除する場合は、
SiteConfig
とサイト固有のPolicyGenerator
またはPolicyGentemplate
CR を Git リポジトリーに残しておくことができます。
4.11. GitOps ZTP パイプラインからの古いコンテンツの削除 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
または PolicyGentemplate
設定の変更によってポリシーが古くなった場合 (ポリシーの名前を変更する場合など) は、次の手順を使用して古くなったポリシーを削除します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
-
影響を受ける
PolicyGenerator
またはPolicyGentemplate
ファイルを Git リポジトリーから削除し、コミットしてリモートリポジトリーにプッシュします。 - アプリケーションを介して変更が同期され、影響を受けるポリシーがハブクラスターから削除されるのを待ちます。
更新された
PolicyGenerator
またはPolicyGentemplate
ファイルを Git リポジトリーに再び追加し、コミットしてリモートリポジトリーにプッシュします。注記Git リポジトリーから GitOps Zero Touch Provisioning (ZTP) ポリシーを削除し、その結果としてハブクラスターからもポリシーが削除されても、マネージドクラスターの設定には影響しません。ポリシーとそのポリシーによって管理される CR は、マネージドクラスターに残ります。
オプション: 別の方法として、
PolicyGenerator
またはPolicyGentemplate
CR に変更を加えたことでポリシーが古くなった場合は、これらのポリシーをハブクラスターから手動で削除できます。ポリシーの削除は、RHACM コンソールから Governance タブを使用するか、以下のコマンドを使用して行うことができます。oc delete policy -n <namespace> <policy_name>
$ oc delete policy -n <namespace> <policy_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12. GitOps ZTP パイプラインの破棄 リンクのコピーリンクがクリップボードにコピーされました!
ArgoCD パイプラインと生成されたすべての GitOps Zero Touch Provisioning (ZTP) アーティファクトを削除できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
- ハブクラスターの Red Hat Advanced Cluster Management (RHACM) からすべてのクラスターを切り離します。
次のコマンドを使用して、
deployment
ディレクトリーのkustomization.yaml
ファイルを削除します。oc delete -k out/argocd/deployment
$ oc delete -k out/argocd/deployment
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更をコミットして、サイトリポジトリーにプッシュします。
第5章 GitOps ZTP を使用したシングルノード OpenShift クラスターの手動インストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) とアシストサービスを使用して、マネージドシングルノード OpenShift クラスターをデプロイできます。
複数のマネージドクラスターを作成する場合は、ZTP を使用したファーエッジサイトのデプロイメント で説明されている SiteConfig
メソッドを使用します。
ターゲットのベアメタルホストは、vDU アプリケーションワークロードの推奨クラスター設定 に記載されているネットワーク、ファームウェア、およびハードウェアの要件を満たす必要があります。
5.1. GitOps ZTP インストール CR と設定 CR の手動生成 リンクのコピーリンクがクリップボードにコピーされました!
ztp-site-generate
コンテナーの generator
エントリーポイントを使用して、SiteConfig
CR および PolicyGenerator
CR に基づいたクラスターのサイトのインストールと設定のカスタムリソース (CR) を生成します。
SiteConfig v1 は、OpenShift Container Platform バージョン 4.18 以降では非推奨になります。ClusterInstance
カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。
SiteConfig Operator の詳細は、SiteConfig を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
次のコマンドを実行して、出力フォルダーを作成します。
mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ztp-site-generate
コンテナーイメージからargocd
ディレクトリーをエクスポートします。podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 extract /home/ztp --tar | tar x -C ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./out
ディレクトリーには、out/argocd/example/
フォルダー内の参照PolicyGenerator
CR およびSiteConfig
CR があります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サイトインストール CR の出力フォルダーを作成します。
mkdir -p ./site-install
$ mkdir -p ./site-install
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストールするクラスタータイプのサンプル
SiteConfig
CR を変更します。example-sno.yaml
をsite-1-sno.yaml
にコピーし、インストールするサイトとベアメタルホストの詳細に一致するように CR を変更します。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ztp-site-generate
コンテナーのout/extra-manifest
ディレクトリーから参照 CR 設定ファイルを抽出したら、extraManifests.searchPaths
を使用して、それらのファイルを含む git ディレクトリーへのパスを含めることができます。これにより、GitOps ZTP パイプラインはクラスターのインストール中にこれらの CR ファイルを適用できるようになります。searchPaths
ディレクトリーを設定すると、GitOps ZTP パイプラインは、サイトのインストール中にztp-site-generate
コンテナーからマニフェストを取得しません。次のコマンドを実行して、変更された
SiteConfig
CRsite-1-sno.yaml
を処理し、Day 0 インストール CR を生成します。podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 generator install site-1-sno.yaml /output
$ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 generator install site-1-sno.yaml /output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
-E
オプションを使用して参照SiteConfig
CR を処理することにより、特定のクラスタータイプの Day 0MachineConfig
インストール CR のみを生成します。たとえば、以下のコマンドを実行します。MachineConfig
CR の出力フォルダーを作成します。mkdir -p ./site-machineconfig
$ mkdir -p ./site-machineconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfig
インストール CR を生成します。podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 generator install -E site-1-sno.yaml /output
$ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 generator install -E site-1-sno.yaml /output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
site-machineconfig └── site-1-sno ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
site-machineconfig └── site-1-sno ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
前の手順の参照
PolicyGenerator
CR を使用して、Day 2 設定 CR を生成してエクスポートします。以下のコマンドを実行します。Day 2 CR の出力フォルダーを作成します。
mkdir -p ./ref
$ mkdir -p ./ref
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Day 2 設定 CR を生成してエクスポートします。
podman run -it --rm -v `pwd`/out/argocd/example/acmpolicygenerator:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 generator config -N . /output
$ podman run -it --rm -v `pwd`/out/argocd/example/acmpolicygenerator:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 generator config -N . /output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、シングルノード OpenShift、3 ノードクラスター、および標準クラスター用のサンプルグループおよびサイト固有の
PolicyGenerator
CR を./ref
フォルダーに生成します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- クラスターのインストールに使用する CR のベースとして、生成された CR を使用します。「単一のマネージドクラスターのインストール」で説明されているように、インストール CR をハブクラスターに適用します。設定 CR は、クラスターのインストールが完了した後にクラスターに適用できます。
検証
ノードのデプロイ後にカスタムのロールとラベルが適用されていることを確認します。
oc describe node example-node.example.com
$ oc describe node example-node.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
出力例
- 1
- カスタムラベルがノードに適用されます。
5.2. マネージドベアメタルホストシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
マネージドベアメタルホストに必要な Secret
カスタムリソース (CR) をハブクラスターに追加します。GitOps Zero Touch Provisioning (ZTP) パイプラインが Baseboard Management Controller (BMC) にアクセスするためのシークレットと、アシストインストーラーサービスがレジストリーからクラスターインストールイメージを取得するためのシークレットが必要です。
シークレットは、SiteConfig
CR から名前で参照されます。namespace は SiteConfig
namespace と一致する必要があります。
手順
ホスト Baseboard Management Controller (BMC) の認証情報と、OpenShift およびすべてのアドオンクラスター Operator のインストールに必要なプルシークレットを含む YAML シークレットファイルを作成します。
-
example-sno-secret.yaml
への相対パスを、クラスターのインストールに使用するkustomization.yaml
ファイルに追加します。
5.3. GitOps ZTP を使用した手動インストール用の Discovery ISO カーネル引数の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) ワークフローは、マネージドベアメタルホストでの OpenShift Container Platform インストールプロセスの一部として Discovery ISO を使用します。InfraEnv
リソースを編集して、Discovery ISO のカーネル引数を指定できます。これは、特定の環境要件を持つクラスターのインストールに役立ちます。たとえば、Discovery ISO の rd.net.timeout.carrier
カーネル引数を設定して、クラスターの静的ネットワーク設定を容易にしたり、インストール中に root ファイルシステムをダウンロードする前に DHCP アドレスを受信したりできます。
OpenShift Container Platform 4.18 では、カーネル引数のみを追加できます。カーネル引数を置き換えたり削除したりすることはできません。
前提条件
- OpenShift CLI (oc) がインストールされている。
- cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
- インストールと設定カスタムリソース (CR) を手動で生成している。
手順
-
InfraEnv
CR のspec.kernelArguments
仕様を編集して、カーネル引数を設定します。
SiteConfig
CR は、Day-0 インストール CR の一部として InfraEnv
リソースを生成します。
検証
カーネル引数が適用されていることを確認するには、Discovery イメージが OpenShift Container Platform をインストールする準備ができていることを確認した後、インストールプロセスを開始する前にターゲットホストに SSH 接続します。その時点で、/proc/cmdline
ファイルで Discovery ISO のカーネル引数を表示できます。
ターゲットホストとの SSH セッションを開始します。
ssh -i /path/to/privatekey core@<host_name>
$ ssh -i /path/to/privatekey core@<host_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、システムのカーネル引数を表示します。
cat /proc/cmdline
$ cat /proc/cmdline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. 単一のマネージドクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
アシストサービスと Red Hat Advanced Cluster Management (RHACM) を使用して、単一のマネージドクラスターを手動でデプロイできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 -
ベースボード管理コントローラー (BMC)
Secret
とイメージプルシークレットSecret
カスタムリソース (CR) を作成しました。詳細は、「管理されたベアメタルホストシークレットの作成」を参照してください。 - ターゲットのベアメタルホストが、マネージドクラスターのネットワークとハードウェアの要件を満たしている。
手順
デプロイする特定のクラスターバージョンごとに
ClusterImageSet
を作成します (例:clusterImageSet-4.18.yaml
)。ClusterImageSet
のフォーマットは以下のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow clusterImageSet
CR を適用します。oc apply -f clusterImageSet-4.18.yaml
$ oc apply -f clusterImageSet-4.18.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-namespace.yaml
ファイルにNamespace
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Namespace
CR を適用します。oc apply -f cluster-namespace.yaml
$ oc apply -f cluster-namespace.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ztp-site-generate
コンテナーから抽出し、要件を満たすようにカスタマイズした、生成された day-0 CR を適用します。oc apply -R ./site-install/site-sno-1
$ oc apply -R ./site-install/site-sno-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. マネージドクラスターのインストールステータスの監視 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのステータスをチェックして、クラスターのプロビジョニングが正常に行われたことを確認します。
前提条件
-
すべてのカスタムリソースが設定およびプロビジョニングされ、プロビジョニングされ、マネージドクラスターのハブで
Agent
カスタムリソースが作成されます。
手順
マネージドクラスターのステータスを確認します。
oc get managedcluster
$ oc get managedcluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow True
はマネージドクラスターの準備が整っていることを示します。エージェントのステータスを確認します。
oc get agent -n <cluster_name>
$ oc get agent -n <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow describe
コマンドを使用して、エージェントの条件に関する詳細な説明を指定します。認識できるステータスには、BackendError
、InputError
、ValidationsFailing
、InstallationFailed
、およびAgentIsConnected
が含まれます。これらのステータスは、Agent
およびAgentClusterInstall
カスタムリソースに関連します。oc describe agent -n <cluster_name>
$ oc describe agent -n <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのプロビジョニングのステータスを確認します。
oc get agentclusterinstall -n <cluster_name>
$ oc get agentclusterinstall -n <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow describe
コマンドを使用して、クラスターのプロビジョニングステータスの詳細な説明を指定します。oc describe agentclusterinstall -n <cluster_name>
$ oc describe agentclusterinstall -n <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターのアドオンサービスのステータスを確認します。
oc get managedclusteraddon -n <cluster_name>
$ oc get managedclusteraddon -n <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターの
kubeconfig
ファイルの認証情報を取得します。oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig
$ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6. マネージドクラスターのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、マネージドクラスターで発生する可能性のあるインストール問題を診断します。
手順
マネージドクラスターのステータスを確認します。
oc get managedcluster
$ oc get managedcluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE SNO-cluster true True True 2d19h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE SNO-cluster true True True 2d19h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AVAILABLE
列のステータスがTrue
の場合、マネージドクラスターはハブによって管理されます。AVAILABLE
列のステータスがUnknown
の場合、マネージドクラスターはハブによって管理されていません。その他の情報を取得するには、以下の手順を使用します。AgentClusterInstall
インストールのステータスを確認します。oc get clusterdeployment -n <cluster_name>
$ oc get clusterdeployment -n <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME PLATFORM REGION CLUSTERTYPE INSTALLED INFRAID VERSION POWERSTATE AGE Sno0026 agent-baremetal false Initialized 2d14h
NAME PLATFORM REGION CLUSTERTYPE INSTALLED INFRAID VERSION POWERSTATE AGE Sno0026 agent-baremetal false Initialized 2d14h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow INSTALLED
列のステータスがfalse
の場合、インストールは失敗していました。インストールが失敗した場合は、以下のコマンドを実行して
AgentClusterInstall
リソースのステータスを確認します。oc describe agentclusterinstall -n <cluster_name> <cluster_name>
$ oc describe agentclusterinstall -n <cluster_name> <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エラーを解決し、クラスターをリセットします。
クラスターのマネージドクラスターリソースを削除します。
oc delete managedcluster <cluster_name>
$ oc delete managedcluster <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの namespace を削除します。
oc delete namespace <cluster_name>
$ oc delete namespace <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、このクラスター用に作成された namespace スコープのカスタムリソースがすべて削除されます。続行する前に、
ManagedCluster
CR の削除が完了するのを待つ必要があります。- マネージドクラスターのカスタムリソースを再作成します。
5.7. RHACM によって生成されたクラスターインストール CR リファレンス リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) は、サイトごとに SiteConfig
CR を使用して生成する特定のインストールカスタムリソース (CR) のセットを使用して、シングルノードクラスター、3 ノードクラスター、および標準クラスターに OpenShift Container Platform をデプロイすることをサポートします。
すべてのマネージドクラスターには独自の namespace があり、ManagedCluster
と ClusterImageSet
を除くすべてのインストール CR はその namespace の下にあります。ManagedCluster
と ClusterImageSet
は、ネームスペーススコープではなく、クラスタースコープです。namespace および CR 名はクラスター名に一致します。
次の表に、設定した SiteConfig
CR を使用してクラスターをインストールするときに RHACM アシストサービスによって自動的に適用されるインストール CR を示します。
CR | 説明 | 使用法 |
---|---|---|
| ターゲットのベアメタルホストの Baseboard Management Controller (BMC) の接続情報が含まれています。 | Redfish プロトコルを使用して、BMC へのアクセスを提供し、ターゲットサーバーで検出イメージをロードおよび開始します。 |
| ターゲットのベアメタルホストに OpenShift Container Platform をインストールするための情報が含まれています。 |
|
|
ネットワークやコントロールプレーンノードの数など、マネージドクラスター設定の詳細を指定します。インストールが完了すると、クラスター | マネージドクラスターの設定情報を指定し、クラスターのインストール時にステータスを指定します。 |
|
使用する |
マネージドクラスターの Discovery ISO を生成するために |
|
| マネージドクラスターの Kube API サーバーの静的 IP アドレスを設定します。 |
| ターゲットのベアメタルホストに関するハードウェア情報が含まれています。 | ターゲットマシンの検出イメージの起動時にハブ上に自動的に作成されます。 |
| クラスターがハブで管理されている場合は、インポートして知られている必要があります。この Kubernetes オブジェクトはそのインターフェイスを提供します。 | ハブは、このリソースを使用してマネージドクラスターのステータスを管理し、表示します。 |
|
|
|
|
ハブ上にある |
リソースを |
|
|
|
| リポジトリーおよびイメージ名などの OpenShift Container Platform イメージ情報が含まれます。 | OpenShift Container Platform イメージを提供するためにリソースに渡されます。 |
第6章 vDU アプリケーションのワークロードに推奨されるシングルノード OpenShift クラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の参照情報を使用して、仮想分散ユニット (vDU) アプリケーションをクラスターにデプロイするために必要なシングルノード OpenShift 設定を理解してください。設定には、高性能ワークロードのためのクラスターの最適化、ワークロードの分割の有効化、およびインストール後に必要な再起動の回数の最小化が含まれます。
6.1. OpenShift Container Platform で低レイテンシーのアプリケーションを実行する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、いくつかのテクノロジーと特殊なハードウェアデバイスを使用して、市販の (COTS) ハードウェアで実行するアプリケーションの低レイテンシー処理を可能にします。
- RHCOS のリアルタイムカーネル
- ワークロードが高レベルのプロセス決定で処理されるようにします。
- CPU の分離
- CPU スケジューリングの遅延を回避し、CPU 容量が一貫して利用可能な状態にします。
- NUMA 対応のトポロジー管理
- メモリーと Huge Page を CPU および PCI デバイスに合わせて、保証されたコンテナーメモリーと Huge Page を不均一メモリーアクセス (NUMA) ノードに固定します。すべての Quality of Service (QoS) クラスの Pod リソースは、同じ NUMA ノードに留まります。これにより、レイテンシーが短縮され、ノードのパフォーマンスが向上します。
- Huge Page のメモリー管理
- Huge Page サイズを使用すると、ページテーブルへのアクセスに必要なシステムリソースの量を減らすことで、システムパフォーマンスが向上します。
- PTP を使用した精度同期
- サブマイクロ秒の正確性を持つネットワーク内のノード間の同期を可能にします。
6.2. vDU アプリケーションワークロードに推奨されるクラスターホスト要件 リンクのコピーリンクがクリップボードにコピーされました!
vDU アプリケーションワークロードを実行するには、OpenShift Container Platform サービスおよび実稼働ワークロードを実行するのに十分なリソースを備えたベアメタルホストが必要です。
プロファイル | 仮想 CPU | メモリー | ストレージ |
---|---|---|---|
最低限 | 4 - 8 個の仮想 CPU | 32 GB のメモリー | 120 GB |
1 つの仮想 CPU は 1 つの物理コアに相当します。ただし、同時マルチスレッディング (SMT) またはハイパースレッディングを有効にする場合は、次の式を使用して、1 つの物理コアを表す仮想 CPU の数を計算してください。
- (コアあたりのスレッド数 x コア数) x ソケット数 = 仮想 CPU
仮想メディアを使用して起動する場合は、サーバーには Baseboard Management Controller (BMC) が必要です。
6.3. 低遅延と高パフォーマンスのためのホストファームウェアの設定 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルホストでは、ホストをプロビジョニングする前にファームウェアを設定する必要があります。ファームウェアの設定は、特定のハードウェアおよびインストールの特定の要件によって異なります。
手順
-
UEFI/BIOS Boot Mode を
UEFI
に設定します。 - ホスト起動シーケンスの順序で、ハードドライブ を設定します。
ハードウェアに特定のファームウェア設定を適用します。次の表は、Intel FlexRAN 4G および 5G baseband PHY リファレンスデザインに基づく、Intel Xeon Skylake サーバーおよびそれ以降のハードウェア世代の代表的なファームウェア設定を示しています。
重要ファームウェア設定は、実際のハードウェアおよびネットワークの要件によって異なります。以下の設定例は、説明のみを目的としています。
Expand 表6.2 ファームウェア設定のサンプル ファームウェア設定 設定 CPU Power and Performance Policy
パフォーマンス
Uncore Frequency Scaling
無効
Performance P-limit
無効
Enhanced Intel SpeedStep ® Tech
有効
Intel Configurable TDP
有効
Configurable TDP Level
レベル 2
Intel® Turbo Boost Technology
有効
Energy Efficient Turbo
無効
Hardware P-States
無効
Package C-State
C0/C1 の状態
C1E
無効
Processor C6
無効
ホストのファームウェアでグローバル SR-IOV および VT-d 設定を有効にします。これらの設定は、ベアメタル環境に関連します。
6.4. マネージドクラスターネットワークの接続の前提条件 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してマネージドクラスターをインストールおよびプロビジョニングするには、マネージドクラスターホストが次のネットワーク前提条件を満たしている必要があります。
- ハブクラスター内の GitOps ZTP コンテナーとターゲットベアメタルホストの Baseboard Management Controller (BMC) の間に双方向接続が必要です。
マネージドクラスターは、ハブホスト名と
*.apps
ホスト名の API ホスト名を解決して到達できる必要があります。ハブの API ホスト名と*.apps
ホスト名の例を次に示します。-
api.hub-cluster.internal.domain.com
-
console-openshift-console.apps.hub-cluster.internal.domain.com
-
ハブクラスターは、マネージドクラスターの API および
*.apps
ホスト名を解決して到達できる必要があります。マネージドクラスターの API ホスト名と*.apps
ホスト名の例を次に示します。-
api.sno-managed-cluster-1.internal.domain.com
-
console-openshift-console.apps.sno-managed-cluster-1.internal.domain.com
-
6.5. GitOps ZTP を使用したシングルノード OpenShift でのワークロードの分割 リンクのコピーリンクがクリップボードにコピーされました!
ワークロードのパーティショニングは、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を、予約された数のホスト CPU で実行するように設定します。
GitOps Zero Touch Provisioning (ZTP) を使用してワークロードパーティショニングを設定するには、クラスターのインストールに使用する SiteConfig
カスタムリソース (CR) の cpuPartitioningMode
フィールドを設定し、ホスト上で isolated
と reserved
CPU を設定する PerformanceProfile
CR を適用します。
SiteConfig
CR を設定すると、クラスターのインストール時にワークロードパーティショニングが有効になり、PerformanceProfile
CR を適用すると、reserved および isolated セットへの割り当てが設定されます。これらの手順は両方とも、クラスターのプロビジョニング中に異なるタイミングで実行されます。
SiteConfig
CR の cpuPartitioningMode
フィールドを使用したワークロードパーティショニングの設定は、OpenShift Container Platform 4.13 のテクノロジープレビュー機能です。
あるいは、SiteConfig
カスタムリソース (CR) の cpuset
フィールドと、グループ PolicyGenerator
または PolicyGentemplate
CR の reserved
フィールドを使用して、クラスター管理 CPU リソースを指定することもできます。GitOps ZTP パイプラインは、これらの値を使用して、シングルノード OpenShift クラスターを設定するワークロードパーティショニング MachineConfig
CR (cpuset
) および PerformanceProfile
CR (reserved
) の必須フィールドにデータを入力します。このメソッドは、OpenShift Container Platform 4.14 で一般公開された機能です。
ワークロードパーティショニング設定は、OpenShift Container Platform インフラストラクチャー Pod を reserved
CPU セットに固定します。systemd、CRI-O、kubelet などのプラットフォームサービスは、reserved
CPU セット上で実行されます。isolated
CPU セットは、コンテナーワークロードに排他的に割り当てられます。CPU を分離すると、同じノード上で実行されている他のアプリケーションと競合することなく、ワークロードが指定された CPU に確実にアクセスできるようになります。分離されていないすべての CPU を予約する必要があります。
reserved
CPU セットと isolated
CPU セットが重複しないようにしてください。
6.6. TPM と PCR の保護によるディスク暗号化について リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
カスタムリソース (CR) の diskEncryption
フィールドを使用して、Trusted Platform Module (TPM) と Platform Configuration Register (PCR) 保護によるディスク暗号化を設定できます。
TPM は、暗号鍵を保存し、システムのセキュリティー状態を評価するハードウェアコンポーネントです。TPM 内の PCR には、システムの現在のハードウェアおよびソフトウェア設定を表すハッシュ値が保存されます。次の PCR レジスターを使用して、ディスク暗号化の暗号鍵を保護できます。
- PCR 1
- Unified Extensible Firmware Interface (UEFI) の状態を表します。
- PCR 7
- セキュアブートの状態を表します。
TPM は、PCR 1 および PCR 7 に記録されているシステムの現在の状態に暗号鍵をリンクすることで、暗号鍵を保護します。dmcrypt
ユーティリティーが、このキーを使用してディスクを暗号化します。暗号鍵と想定される PCR レジスター間のバインディングは、必要に応じてアップグレード後に自動的に更新されます。
システムの起動プロセス中に、dmcrypt
ユーティリティーが TPM の PCR 値を使用してディスクのロックを解除します。現在の PCR 値が以前にリンクされた値と一致した場合、ロックの解除が成功します。PCR 値が一致しない場合、暗号鍵を解除することができず、ディスクが暗号化されたままアクセスできなくなります。
SiteConfig
CR の diskEncryption
フィールドを使用したディスク暗号化を設定は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
6.7. 推奨されるクラスターインストールマニフェスト リンクのコピーリンクがクリップボードにコピーされました!
ZTP パイプラインは、クラスターのインストール中に次のカスタムリソース (CR) を適用します。これらの設定 CR により、クラスターが vDU アプリケーションの実行に必要な機能とパフォーマンスの要件を満たしていることが保証されます。
クラスターデプロイメントに GitOps ZTP プラグインと SiteConfig
CR を使用する場合は、デフォルトで次の MachineConfig
CR が含まれます。
デフォルトで含まれる CR を変更するには、SiteConfig
の extraManifests
フィルターを使用します。詳細は、SiteConfig CR を使用した高度なマネージドクラスター設定 を参照してください。
6.7.1. ワークロードの分割 リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターには、ワークロードの分割が必要です。これにより、プラットフォームサービスの実行が許可されるコアが制限され、アプリケーションペイロードの CPU コアが最大化されます。
ワークロードの分割は、クラスターのインストール中にのみ有効にできます。インストール後にワークロードパーティショニングを無効にすることはできません。ただし、PerformanceProfile
CR を通じて、isolated セットと reserved セットに割り当てられた CPU のセットを変更できます。CPU 設定を変更すると、ノードが再起動します。
ワークロードパーティショニングを有効にするために cpuPartitioningMode
の使用に移行する場合は、クラスターのプロビジョニングに使用する /extra-manifest
フォルダーからワークロードパーティショニングの MachineConfig
CR を削除します。
ワークロードパーティショニング用に推奨される SiteConfig CR
設定
- 1
- クラスター内におけるすべてのノードのワークロードパーティショニングを設定するには、
cpuPartitioningMode
フィールドをAllNodes
に設定します。
検証
アプリケーションとクラスターシステムの CPU ピニングが正しいことを確認します。以下のコマンドを実行します。
マネージドクラスターへのリモートシェルプロンプトを開きます。
oc debug node/example-sno-1
$ oc debug node/example-sno-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift インフラストラクチャーアプリケーションの CPU ピニングが正しいことを確認します。
pgrep ovn | while read i; do taskset -cp $i; done
sh-4.4# pgrep ovn | while read i; do taskset -cp $i; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow システムアプリケーションの CPU ピニングが正しいことを確認します。
pgrep systemd | while read i; do taskset -cp $i; done
sh-4.4# pgrep systemd | while read i; do taskset -cp $i; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
pid 1's current affinity list: 0-1,52-53 pid 938's current affinity list: 0-1,52-53 pid 962's current affinity list: 0-1,52-53 pid 1197's current affinity list: 0-1,52-53
pid 1's current affinity list: 0-1,52-53 pid 938's current affinity list: 0-1,52-53 pid 962's current affinity list: 0-1,52-53 pid 1197's current affinity list: 0-1,52-53
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7.2. プラットフォーム管理フットプリントの削減 リンクのコピーリンクがクリップボードにコピーされました!
プラットフォームの全体的な管理フットプリントを削減するには、ホストオペレーティングシステムとは別の新しい namespace にすべての Kubernetes 固有のマウントポイントを配置する MachineConfig
カスタムリソース (CR) が必要です。次の base64 でエンコードされた MachineConfig
CR の例は、この設定を示しています。
推奨されるコンテナーマウント namespace 設定 (01-container-mount-ns-and-kubelet-conf-master.yaml
)
6.7.3. SCTP リンクのコピーリンクがクリップボードにコピーされました!
Stream Control Transmission Protocol (SCTP) は、RAN アプリケーションで使用される主要なプロトコルです。この MachineConfig
オブジェクトは、SCTP カーネルモジュールをノードに追加して、このプロトコルを有効にします。
推奨されるコントロールプレーンノードの SCTP 設定 (03-sctp-machine-config-master.yaml
)
推奨されるワーカーノードの SCTP 設定 (03-sctp-machine-config-worker.yaml
)
6.7.4. rcu_normal の設定 リンクのコピーリンクがクリップボードにコピーされました!
次の MachineConfig
CR は、システムの起動完了後に rcu_normal
を 1 に設定するようにシステムを設定します。これにより、vDU アプリケーションのカーネル遅延が改善されます。
ノードの起動完了後に rcu_expedited
を無効にするために推奨される設定 (08-set-rcu-normal-master.yaml
)
6.7.5. kdump による自動カーネルクラッシュダンプ リンクのコピーリンクがクリップボードにコピーされました!
kdump
は、カーネルがクラッシュしたときにカーネルクラッシュダンプを作成する Linux カーネル機能です。kdump
は、次の MachineConfig
CR で有効になっています。
コントロールプレーンノード用に推奨される kdump 設定 (06-kdump-master.yaml
)
kdump ワーカーノード用に推奨される設定 (06-kdump-worker.yaml
)
6.7.6. CRI-O キャッシュの自動ワイプを無効にする リンクのコピーリンクがクリップボードにコピーされました!
制御されていないホストのシャットダウンまたはクラスターの再起動の後、CRI-O は CRI-O キャッシュ全体を自動的に削除します。そのため、ノードの再起動時にはすべてのイメージがレジストリーからプルされます。これにより、許容できないほど復元に時間がかかったり、復元が失敗したりする可能性があります。GitOps ZTP を使用してインストールするシングルノード OpenShift クラスターでこの問題が発生しないようにするには、クラスターをインストールする際に CRI-O 削除キャッシュ機能を無効にします。
コントロールプレーンノードで CRI-O キャッシュワイプを無効にするために推奨される MachineConfig
CR (99-crio-disable-wipe-master.yaml
)
ワーカーノードで CRI-O キャッシュワイプを無効にするために推奨される MachineConfig
CR (99-crio-disable-wipe-worker.yaml
)
6.7.7. crun をデフォルトのコンテナーランタイムに設定 リンクのコピーリンクがクリップボードにコピーされました!
次の ContainerRuntimeConfig
カスタムリソース (CR) は、コントロールプレーンおよびワーカーノードのデフォルト OCI コンテナーランタイムとして crun を設定します。crun コンテナーランタイムは高速かつ軽量で、メモリーフットプリントも小さくなります。
パフォーマンスを最適化するには、シングルノード OpenShift、3 ノード OpenShift、および標準クラスターのコントロールプレーンとワーカーノードで crun を有効にします。CR 適用時にクラスターが再起動するのを回避するには、GitOps ZTP の追加の Day 0 インストール時マニフェストとして変更を適用します。
コントロールプレーンノード用に推奨される ContainerRuntimeConfig
(enable-crun-master.yaml
)
ワーカーノード用に推奨される ContainerRuntimeConfig
(enable-crun-worker.yaml
)
6.7.8. TPM と PCR の保護によるディスク暗号化の有効化 リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
カスタムリソース (CR) の diskEncryption
フィールドを使用して、Trusted Platform Module (TPM) と Platform Configuration Register (PCR) 保護によるディスク暗号化を設定できます。
SiteConfig
CR を設定すると、クラスターのインストール時にディスク暗号化が有効になります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - 「TPM と PCR の保護によるディスク暗号化について」セクションを確認した。
手順
SiteConfig
CR のspec.clusters.diskEncryption
フィールドを設定します。PCR の保護によるディスク暗号化を有効にする際に推奨される
SiteConfig
CR の設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、TPM と PCR の保護によるディスク暗号化が有効になっていることを確認します。
clevis luks list -d <disk_path>
$ clevis luks list -d <disk_path>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<disk_path>
は、ディスクへのパスに置き換えます。たとえば、/dev/sda4
です。
出力例
1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"1,7"}'
1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"1,7"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8. 推奨されるインストール後のクラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストールが完了すると、ZTP パイプラインは、DU ワークロードを実行するために必要な次のカスタムリソース (CR) を適用します。
GitOps ZTP v4.10 以前では、MachineConfig
CR を使用して UEFI セキュアブートを設定します。これは、GitOps ZTP v4.11 以降では不要になりました。v4.11 では、クラスターのインストールに使用する SiteConfig
CR の spec.clusters.nodes.bootMode
フィールドを更新することで、シングルノード OpenShift クラスターの UEFI セキュアブートを設定します。詳細は、SiteConfig および GitOps ZTP を使用したマネージドクラスターのデプロイ を参照してください。
6.8.1. Operator リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターには、次の Operator をインストールする必要があります。
- Local Storage Operator
- Logging Operator
- PTP Operator
- SR-IOV Network Operator
カスタム CatalogSource
CR を設定し、デフォルトの OperatorHub
設定を無効にし、インストールするクラスターからアクセスできる ImageContentSourcePolicy
ミラーレジストリーを設定する必要もあります。
推奨される Storage Operator namespace と Operator グループ設定 (StorageNS.yaml
、StorageOperGroup.yaml
)
推奨される Cluster Logging Operator namespace と Operator グループの設定 (ClusterLogNS.yaml
、ClusterLogOperGroup.yaml
)
推奨される PTP Operator namespace と Operator グループ設定 (PtpSubscriptionNS.yaml
、PtpSubscriptionOperGroup.yaml
)
推奨される SR-IOV Operator namespace と Operator グループ設定 (SriovSubscriptionNS.yaml
、SriovSubscriptionOperGroup.yaml
)
推奨される CatalogSource
設定 (DefaultCatsrc.yaml
)
推奨される ImageContentSourcePolicy
設定 (DisconnectedICSP.yaml
)
推奨される OperatorHub
設定 (OperatorHub.yaml
)
6.8.2. Operator のサブスクリプション リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターには、次の Subscription
CR が必要です。サブスクリプションは、次の Operator をダウンロードする場所を提供します。
- Local Storage Operator
- Logging Operator
- PTP Operator
- SR-IOV Network Operator
- SRIOV-FEC Operator
Operator サブスクリプションごとに、Operator の取得先であるチャネルを指定します。推奨チャンネルは stable
です。
Manual
更新または Automatic
更新を指定できます。Automatic
モードでは、Operator は、レジストリーで利用可能になると、チャネル内の最新バージョンに自動的に更新します。Manual
モードでは、新しい Operator バージョンは、明示的に承認された場合にのみインストールされます。
サブスクリプションには Manual
モードを使用します。これにより、スケジュールされたメンテナンス期間内に収まるように Operator の更新タイミングを制御できます。
推奨される Local Storage Operator サブスクリプション (StorageSubscription.yaml
)
推奨される SR-IOV Operator サブスクリプション (SriovSubscription.yaml
)
推奨される PTP Operator サブスクリプション (PtpSubscription.yaml
)
推奨される Cluster Logging Operator サブスクリプション (ClusterLogSubscription.yaml
)
6.8.3. クラスターのロギングとログ転送 リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターでは、デバッグのためにロギングとログ転送が必要です。次のカスタムリソース (CR) が必要です。
推奨される ClusterLogForwarder.yaml
spec.outputs.kafka.url
フィールドには、ログの転送先となる Kafka サーバーの URL を設定してください。
推奨される ClusterLogNS.yaml
推奨される ClusterLogOperGroup.yaml
推奨される ClusterLogServiceAccount.yaml
推奨される ClusterLogServiceAccountAuditBinding.yaml
推奨される ClusterLogServiceAccountInfrastructureBinding.yaml
推奨される ClusterLogSubscription.yaml
6.8.4. パフォーマンスプロファイル リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターでは、リアルタイムのホスト機能とサービスを使用するために Node Tuning Operator パフォーマンスプロファイルが必要です。
OpenShift Container Platform の以前のバージョンでは、Performance Addon Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。
次の PerformanceProfile
CR の例は、必要なシングルノード OpenShift クラスター設定を示しています。
推奨されるパフォーマンスプロファイル設定 (PerformanceProfile.yaml
)
PerformanceProfile CR フィールド | 説明 |
---|---|
|
|
|
|
| 分離された CPU を設定します。すべてのハイパースレッディングペアが一致していることを確認します。 重要 予約済みおよび分離された CPU プールは重複してはならず、いずれも使用可能なすべてのコア全体にわたる必要があります。考慮されていない CPU コアは、システムで未定義の動作を引き起こします。 |
| 予約済みの CPU を設定します。ワークロードの分割が有効になっている場合、システムプロセス、カーネルスレッド、およびシステムコンテナースレッドは、これらの CPU に制限されます。分離されていないすべての CPU を予約する必要があります。 |
|
|
|
リアルタイムカーネルを使用するには、 |
|
|
6.8.5. クラスター時間同期の設定 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンまたはワーカーノードに対して、1 回限りのシステム時間同期ジョブを実行します。
コントロールプレーンノード用に推奨される 1 回限りの時間同期 (99-sync-time-once-master.yaml
)
ワーカーノード用に推奨される 1 回限りの時間同期 (99-sync-time-once-worker.yaml
)
6.8.6. PTP リンクのコピーリンクがクリップボードにコピーされました!
シングルノード OpenShift クラスターは、ネットワーク時間同期に Precision Time Protocol (PTP) を使用します。次の PtpConfig
CR の例は、通常のクロック、境界クロック、およびグランドマスタークロックに必要な PTP 設定を示しています。適用する設定は、ノードのハードウェアとユースケースにより異なります。
推奨される PTP 通常クロック設定 (PtpConfigSlave.yaml
)
推奨される境界クロック設定 (PtpConfigBoundary.yaml
)
推奨される PTP Westport Channel e810 グランドマスタークロック設定 (PtpConfigGmWpc.yaml
)
次のオプションの PtpOperatorConfig
CR は、ノードの PTP イベントレポートを設定します。
推奨される PTP イベント設定 (PtpOperatorConfigForEvent.yaml
)
6.8.7. 拡張調整済みプロファイル リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターには、高性能ワークロードに必要な追加のパフォーマンスチューニング設定が必要です。次の Tuned
CR の例では、Tuned
プロファイルを拡張しています。
推奨される拡張 Tuned
プロファイル設定 (TunedPerformancePatch.yaml
)
調整された CR フィールド | 説明 |
---|---|
|
|
6.8.8. SR-IOV リンクのコピーリンクがクリップボードにコピーされました!
シングルルート I/O 仮想化 (SR-IOV) は、一般的にフロントホールネットワークとミッドホールネットワークを有効にするために使用されます。次の YAML の例では、シングルノード OpenShift クラスターの SR-IOV を設定します。
SriovNetwork
CR の設定は、特定のネットワークとインフラストラクチャーの要件によって異なります。
推奨される SriovOperatorConfig
CR 設定 (SriovOperatorConfig.yaml
)
SriovOperatorConfig CR フィールド | 説明 |
---|---|
|
以下に例を示します。 |
|
|
推奨される SriovNetwork
設定 (SriovNetwork.yaml
)
SriovNetwork CR フィールド | 説明 |
---|---|
|
|
推奨される SriovNetworkNodePolicy
CR 設定 (SriovNetworkNodePolicy.yaml
)
SriovNetworkNodePolicy CR フィールド | 説明 |
---|---|
|
|
| フロントホールネットワークに接続されているインターフェイスを指定します。 |
| フロントホールネットワークの VF の数を指定します。 |
| 物理機能の正確な名前は、ハードウェアと一致する必要があります。 |
推奨される SR-IOV カーネル設定 (07-sriov-related-kernel-args-master.yaml
)
6.8.9. Console Operator リンクのコピーリンクがクリップボードにコピーされました!
クラスターケイパビリティー機能を使用して、コンソールオペレーターがインストールされないようにします。ノードが一元的に管理されている場合は必要ありません。Operator を削除すると、アプリケーションのワークロードに追加の領域と容量ができます。
マネージドクラスターのインストール中に Console Operator を無効にするには、SiteConfig
カスタムリソース (CR) の spec.clusters.0.installConfigOverrides
フィールドで次のように設定します。
installConfigOverrides: "{\"capabilities\":{\"baselineCapabilitySet\": \"None\" }}"
installConfigOverrides: "{\"capabilities\":{\"baselineCapabilitySet\": \"None\" }}"
6.8.10. Alertmanager リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターでは、OpenShift Container Platform モニタリングコンポーネントによって消費される CPU リソースを削減する必要があります。以下の ConfigMap
カスタムリソース (CR) は Alertmanager を無効にします。
推奨されるクラスターモニタリング設定 (ReduceMonitoringFootprint.yaml
)
6.8.11. Operator Lifecycle Manager リンクのコピーリンクがクリップボードにコピーされました!
分散ユニットワークロードを実行するシングルノード OpenShift クラスターには、CPU リソースへの一貫したアクセスが必要です。Operator Lifecycle Manager (OLM) は定期的に Operator からパフォーマンスデータを収集するため、CPU 使用率が増加します。次の ConfigMap
カスタムリソース (CR) は、OLM によるオペレーターパフォーマンスデータの収集を無効にします。
推奨されるクラスター OLM 設定 (ReduceOLMFootprint.yaml
)
6.8.12. LVM Storage リンクのコピーリンクがクリップボードにコピーされました!
論理ボリュームマネージャー (LVM) ストレージを使用して、シングルノード OpenShift クラスター上にローカルストレージを動的にプロビジョニングできます。
シングルノード OpenShift の推奨ストレージソリューションは、Local Storage Operator です。LVM Storage も使用できますが、その場合は追加の CPU リソースを割り当てる必要があります。
次の YAML の例では、OpenShift Container Platform アプリケーションで使用できるようにノードのストレージを設定しています。
推奨される LVMCluster
設定 (StorageLVMCluster.yaml
)
LVMCluster CR フィールド | 説明 |
---|---|
| LVM Storage に使用されるディスクを設定します。ディスクが指定されていない場合、LVM Storage は指定されたシンプール内のすべての未使用ディスクを使用します。 |
6.8.13. ネットワーク診断 リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行するシングルノード OpenShift クラスターでは、これらの Pod によって作成される追加の負荷を軽減するために、Pod 間のネットワーク接続チェックが少なくて済みます。次のカスタムリソース (CR) は、これらのチェックを無効にします。
推奨されるネットワーク診断設定 (DisableSnoNetworkDiag.yaml
)
第7章 vDU アプリケーションワークロードのシングルノード OpenShift クラスターチューニングの検証 リンクのコピーリンクがクリップボードにコピーされました!
仮想化分散ユニット (vDU) アプリケーションをデプロイする前に、クラスターホストファームウェアおよびその他のさまざまなクラスター設定を調整および設定する必要があります。以下の情報を使用して、vDU ワークロードをサポートするためのクラスター設定を検証します。
7.1. vDU クラスターホストの推奨ファームウェア設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.18 で実行される vDU アプリケーションのクラスターホストファームウェアを設定するための基礎として、以下の表を使用してください。
次の表は、vDU クラスターホストファームウェア設定の一般的な推奨事項です。正確なファームウェア設定は、要件と特定のハードウェアプラットフォームによって異なります。ファームウェアの自動設定は、ゼロタッチプロビジョニングパイプラインでは処理されません。
ファームウェア設定 | 設定 | 説明 |
---|---|---|
HyperTransport (HT) | 有効 | HyperTransport (HT) バスは、AMD が開発したバス技術です。HT は、ホストメモリー内のコンポーネントと他のシステムペリフェラル間の高速リンクを提供します。 |
UEFI | 有効 | vDU ホストの UEFI からの起動を有効にします。 |
CPU Power and Performance Policy | パフォーマンス | CPU パワーとパフォーマンスポリシーを設定し、エネルギー効率よりもパフォーマンスを優先してシステムを最適化します。 |
Uncore Frequency Scaling | 無効 | Uncore Frequency Scaling を無効にして、CPU のコア以外の部分の電圧と周波数が個別に設定されるのを防ぎます。 |
Uncore Frequency | 最大 | キャッシュやメモリーコントローラーなど、CPU のコア以外の部分を可能な最大動作周波数に設定します。 |
Performance P-limit | 無効 | プロセッサーのアンコア周波数の調整を防ぐには、Performance P-limit を無効にします。 |
Enhanced Intel® SpeedStep Tech | 有効 | Enhanced Intel SpeedStep を有効にして、システムがプロセッサーの電圧とコア周波数を動的に調整できるようにし、ホストの消費電力と発熱を減らします。 |
Intel® Turbo Boost Technology | 有効 | Intel ベースの CPU で Turbo Boost Technology を有効にすると、プロセッサーコアが電力、電流、および温度の仕様制限を下回って動作している場合、自動的に定格動作周波数よりも高速に動作できるようにします。 |
Intel Configurable TDP | 有効 | CPU の Thermal Design Power (TDP) を有効にします。 |
Configurable TDP Level | レベル 2 | TDP レベルは、特定のパフォーマンス評価に必要な CPU 消費電力を設定します。TDP レベル 2 は、消費電力を犠牲にして、CPU を最も安定したパフォーマンスレベルに設定します。 |
Energy Efficient Turbo | 無効 | Energy Efficient Turbo を無効にして、プロセッサーがエネルギー効率ベースのポリシーを使用しないようにします。 |
Hardware P-States | 有効化または無効化 |
OS 制御の P-States を有効にして、省電力設定を許可します。 |
Package C-State | C0/C1 の状態 | C0 または C1 状態を使用して、プロセッサーを完全にアクティブな状態 (C0) に設定するか、ソフトウェアで実行されている CPU 内部クロックを停止します (C1)。 |
C1E | 無効 | CPU Enhanced Halt (C1E) は、Intel チップの省電力機能です。C1E を無効にすると、非アクティブ時にオペレーティングシステムが停止コマンドを CPU に送信することを防ぎます。 |
Processor C6 | 無効 | C6 節電は、アイドル状態の CPU コアとキャッシュを自動的に無効にする CPU 機能です。C6 を無効にすると、システムパフォーマンスが向上します。 |
Sub-NUMA Clustering | 無効 | サブ NUMA クラスタリングは、プロセッサーコア、キャッシュ、およびメモリーを複数の NUMA ドメインに分割します。このオプションを無効にすると、レイテンシーの影響を受けやすいワークロードのパフォーマンスが向上します。 |
ホストのファームウェアでグローバル SR-IOV および VT-d 設定を有効にします。これらの設定は、ベアメタル環境に関連します。
C-states
と OS 制御の P-States
の両方を有効にして、Pod ごとの電源管理を許可します。
7.2. vDU アプリケーションを実行するための推奨クラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
仮想化分散ユニット (vDU) アプリケーションを実行するクラスターには、高度に調整かつ最適化された設定が必要です。以下では、OpenShift Container Platform 4.18 クラスターで vDU ワークロードをサポートするために必要なさまざまな要素を説明します。
7.2.1. シングルノード OpenShift クラスター用の推奨クラスター MachineConfig CR リンクのコピーリンクがクリップボードにコピーされました!
ztp-site-generate
コンテナーから抽出した MachineConfig
カスタムリソース (CR) がクラスターに適用されていることを確認します。CR は、抽出した out/source-crs/extra-manifest/
フォルダーにあります。
ztp-site-generate
コンテナーからの次の MachineConfig
CR は、クラスターホストを設定します。
MachineConfig CR | 説明 |
---|---|
| コンテナーマウント namespace と kubelet 設定を設定します。 |
|
SCTP カーネルモジュールをロードします。これらの |
| クラスターの kdump クラッシュレポートを設定します。 |
| クラスターの SR-IOV カーネル引数を設定します。 |
|
クラスターの再起動後に |
| クラスター再起動後の自動 CRI-O キャッシュワイプを無効にします。 |
| Chrony サービスによるシステムクロックのワンタイムチェックと調整を設定します。 |
|
|
| クラスターのインストール時および RHACM クラスターポリシーの生成時に cgroups v1 を有効にします。 |
OpenShift Container Platform 4.14 以降では、SiteConfig
CR の cpuPartitioningMode
フィールドを使用してワークロードの分割を設定します。
7.2.2. 推奨されるクラスター Operator リンクのコピーリンクがクリップボードにコピーされました!
次の Operator は、仮想化分散ユニット (vDU) アプリケーションを実行するクラスターに必要であり、ベースライン参照設定の一部です。
- Node Tuning Operator (NTO)。NTO は、以前は Performance Addon Operator で提供されていた機能をパッケージ化し、現在は NTO の一部になっています。
- PTP Operator
- SR-IOV Network Operator
- Red Hat OpenShift Logging Operator
- Local Storage Operator
7.2.3. 推奨されるクラスターカーネル設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターでは常に、サポートされている最新のリアルタイムカーネルバージョンを使用してください。クラスターに次の設定を適用していることを確認します。
次の
additionalKernelArgs
がクラスターパフォーマンスプロファイルに設定されていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
hardwareTuning
フィールドで CPU 周波数を設定します。ハードウェアチューニングを使用して、予約済みコア CPU と分離コア CPU の CPU 周波数を調整できます。FlexRAN のようなアプリケーションの場合、ハードウェアベンダーは、デフォルトで提供される周波数よりも低い CPU 周波数で実行することを推奨しています。周波数を設定する前に、プロセッサー世代の最大周波数設定に関するハードウェアベンダーのガイドラインを参照することを強く推奨します。この例では、予約および分離された CPU の周波数を 2500 MHz に設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Tuned
CR のperformance-patch
プロファイルが、関連するPerformanceProfile
CR のisolated
CPU セットと一致する正しい CPU 分離セットを設定していることを確認します。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.4. リアルタイムカーネルバージョンの確認 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターでは常にリアルタイムカーネルの最新バージョンを使用してください。クラスターで使用されているカーネルバージョンが不明な場合は、次の手順で現在のリアルタイムカーネルバージョンとリリースバージョンを比較できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 -
podman
がインストールされている。
手順
次のコマンドを実行して、クラスターのバージョンを取得します。
OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')
$ OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リリースイメージの SHA 番号を取得します。
DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)
$ DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リリースイメージコンテナーを実行し、クラスターの現在のリリースにパッケージ化されているカーネルバージョンを抽出します。
podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'
$ podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
4.18.0-305.49.1.rt7.121.el8_4.x86_64
4.18.0-305.49.1.rt7.121.el8_4.x86_64
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、リリースに同梱されているデフォルトのリアルタイムカーネルバージョンです。
注記リアルタイムカーネルは、カーネルバージョンの文字列
.rt
で示されます。
検証
クラスターの現在のリリース用にリストされているカーネルバージョンが、クラスターで実行されている実際のリアルタイムカーネルと一致することを確認します。次のコマンドを実行して、実行中のリアルタイムカーネルバージョンを確認します。
クラスターノードへのリモートシェル接続を開きます。
oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リアルタイムカーネルバージョンを確認します。
uname -r
sh-4.4# uname -r
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
4.18.0-305.49.1.rt7.121.el8_4.x86_64
4.18.0-305.49.1.rt7.121.el8_4.x86_64
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3. 推奨されるクラスター設定が適用されていることの確認 リンクのコピーリンクがクリップボードにコピーされました!
クラスターが正しい設定で実行されていることを確認できます。以下の手順では、OpenShift Container Platform 4.18 クラスターに DU アプリケーションをデプロイするために必要なさまざまな設定を確認する方法を説明します。
前提条件
- クラスターをデプロイし、vDU ワークロード用に調整している。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
デフォルトの OperatorHub ソースが無効になっていることを確認します。以下のコマンドを実行します。
oc get operatorhub cluster -o yaml
$ oc get operatorhub cluster -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
spec: disableAllDefaultSources: true
spec: disableAllDefaultSources: true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、必要なすべての
CatalogSource
リソースにワークロードのパーティショニング (PreferredDuringScheduling
) のアノテーションが付けられていることを確認します。oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'
$ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
certified-operators -- {"effect": "PreferredDuringScheduling"} community-operators -- {"effect": "PreferredDuringScheduling"} ran-operators redhat-marketplace -- {"effect": "PreferredDuringScheduling"} redhat-operators -- {"effect": "PreferredDuringScheduling"}
certified-operators -- {"effect": "PreferredDuringScheduling"} community-operators -- {"effect": "PreferredDuringScheduling"} ran-operators
1 redhat-marketplace -- {"effect": "PreferredDuringScheduling"} redhat-operators -- {"effect": "PreferredDuringScheduling"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アノテーションが付けられていない
CatalogSource
リソースも返されます。この例では、ran-operators
CatalogSource
リソースにはアノテーションが付けられておらず、PreferredDuringScheduling
アノテーションがありません。
注記適切に設定された vDU クラスターでは、単一のアノテーション付きカタログソースのみがリスト表示されます。
該当するすべての OpenShift Container Platform Operator の namespace がワークロードのパーティショニング用にアノテーションされていることを確認します。これには、コア OpenShift Container Platform とともにインストールされたすべての Operator と、参照 DU チューニング設定に含まれる追加の Operator のセットが含まれます。以下のコマンドを実行します。
oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'
$ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
default -- openshift-apiserver -- management openshift-apiserver-operator -- management openshift-authentication -- management openshift-authentication-operator -- management
default -- openshift-apiserver -- management openshift-apiserver-operator -- management openshift-authentication -- management openshift-authentication-operator -- management
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要追加の Operator は、ワークロードパーティショニングのためにアノテーションを付けてはなりません。前のコマンドからの出力では、追加の Operator が
--
セパレーターの右側に値なしでリストされている必要があります。ClusterLogging
設定が正しいことを確認してください。以下のコマンドを実行します。適切な入力ログと出力ログが設定されていることを確認します。
oc get -n openshift-logging ClusterLogForwarder instance -o yaml
$ oc get -n openshift-logging ClusterLogForwarder instance -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow キュレーションスケジュールがアプリケーションに適していることを確認します。
oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml
$ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、Web コンソールが無効になっている (
managementState: Removed
) ことを確認します。oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"
$ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Removed
Removed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターノードで
chronyd
が無効になっていることを確認します。oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードで
chronyd
のステータスを確認します。chroot /host
sh-4.4# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl status chronyd
sh-4.4# systemctl status chronyd
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5)
● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow linuxptp-daemon
コンテナーへのリモートシェル接続と PTP Management Client (pmc
) ツールを使用して、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。次のコマンドを実行して、
$PTP_POD_NAME
変数にlinuxptp-daemon
Pod の名前を設定します。PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)
$ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、PTP デバイスの同期ステータスを確認します。
oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の
pmc
コマンドを実行して、PTP クロックのステータスを確認します。oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'
$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /var/run/ptp4l.0.config
の値に対応する予期されるmaster offset
値がlinuxptp-daemon-container
ログにあることを確認します。oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container
$ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset -1731092 s2 freq -1546242 delay 497 ptp4l[56020.390]: [ptp4l.1.config] master offset -2 s2 freq -5863 path delay 541 ptp4l[56020.390]: [ptp4l.0.config] master offset -8 s2 freq -10699 path delay 533
phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset -1731092 s2 freq -1546242 delay 497 ptp4l[56020.390]: [ptp4l.1.config] master offset -2 s2 freq -5863 path delay 541 ptp4l[56020.390]: [ptp4l.0.config] master offset -8 s2 freq -10699 path delay 533
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、SR-IOV 設定が正しいことを確認します。
SriovOperatorConfig
リソースのdisableDrain
値がtrue
に設定されていることを確認します。oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"
$ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
true
true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SriovNetworkNodeState
同期ステータスがSucceeded
であることを確認します。oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"
$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Succeeded
Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV 用に設定された各インターフェイスの下の仮想機能 (
Vfs
) の予想される数と設定が、.status.interfaces
フィールドに存在し、正しいことを確認します。以下に例を示します。oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml
$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターパフォーマンスプロファイルが正しいことを確認します。
cpu
セクションとhugepages
セクションは、ハードウェア設定によって異なります。以下のコマンドを実行します。oc get PerformanceProfile openshift-node-performance-profile -o yaml
$ oc get PerformanceProfile openshift-node-performance-profile -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記CPU 設定は、サーバーで使用可能なコアの数に依存し、ワークロードパーティショニングの設定に合わせる必要があります。
hugepages
の設定は、サーバーとアプリケーションに依存します。次のコマンドを実行して、
PerformanceProfile
がクラスターに正常に適用されたことを確認します。oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"
$ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Available -- True Upgradeable -- True Progressing -- False Degraded -- False
Available -- True Upgradeable -- True Progressing -- False Degraded -- False
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Tuned
パフォーマンスパッチの設定を確認します。oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml
$ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cmdline=nohz_full=
の cpu リストは、ハードウェア設定によって異なります。
次のコマンドを実行して、クラスターネットワーク診断が無効になっていることを確認します。
oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'
$ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
true
true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubelet
のハウスキーピング間隔が、遅い速度に調整されていることを確認します。これは、containerMountNS
マシン設定で設定されます。以下のコマンドを実行します。oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION
$ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Grafana と
alertManagerMain
が無効になっていること、および Prometheus の保持期間が 24 時間に設定されていることを確認します。oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"
$ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、Grafana および
alertManagerMain
ルートがクラスター内に見つからないことを確認します。oc get route -n openshift-monitoring alertmanager-main
$ oc get route -n openshift-monitoring alertmanager-main
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get route -n openshift-monitoring grafana
$ oc get route -n openshift-monitoring grafana
Copy to Clipboard Copied! Toggle word wrap Toggle overflow どちらのクエリーも
Error from server (NotFound)
メッセージを返す必要があります。
次のコマンドを実行して、
PerformanceProfile
、Tuned
performance-patch、ワークロードパーティショニング、およびカーネルコマンドライン引数のそれぞれにreserved
として割り当てられた CPU が少なくとも 4 つあることを確認します。oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"
$ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
0-3
0-3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ワークロードの要件によっては、追加の予約済み CPU の割り当てが必要になる場合があります。
第8章 SiteConfig リソースを使用した高度なマネージドクラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
カスタムリソース (CR) を使用して、インストール時にマネージドクラスターにカスタム機能と設定をデプロイできます。
SiteConfig v1 は、OpenShift Container Platform バージョン 4.18 以降では非推奨になります。ClusterInstance
カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。
SiteConfig Operator の詳細は、SiteConfig を参照してください。
8.1. GitOps ZTP パイプラインでの追加インストールマニフェストのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) パイプラインのインストールフェーズに追加するマニフェストセットを定義できます。これらのマニフェストは SiteConfig
カスタムリソース (CR) にリンクされ、インストール時にクラスターに適用されます。インストール時に MachineConfig
CR を含めると、インストール作業が効率的になります。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
- GitOps ZTP パイプラインがクラスターインストールのカスタマイズ使用する、追加のマニフェスト CR のセットを作成します。
カスタム
/siteconfig
ディレクトリーに、追加のマニフェスト用のサブディレクトリー/custom-manifest
を作成します。以下の例は、/custom-manifest
フォルダーを持つ/siteconfig
のサンプルを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記全体で使用されているサブディレクトリー名
/custom-manifest
および/extra-manifest
は、名前の例にすぎません。これらの名前を使用する必要はなく、これらのサブディレクトリーに名前を付ける方法に制限はありません。この例では、/extra-manifest
は、ztp-site-generate
コンテナーの/extra-manifest
の内容を保存する Git サブディレクトリーを指します。-
カスタムの追加マニフェスト CR を
siteconfig/custom-manifest
ディレクトリーに追加します。 SiteConfig
CR で、extraManifests.searchPaths
フィールドにディレクトリー名を入力します。例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
SiteConfig
、/extra-manifest
、および/custom-manifest
CR を保存し、サイト設定リポジトリーにプッシュします。
クラスターのプロビジョニング中に、GitOps ZTP パイプラインは、/custom-manifest
ディレクトリー内の CR を、extra-manifest/
に保存されている追加マニフェストのデフォルトのセットに追加します。
バージョン 4.14 以降、extraManifestPath
には非推奨の警告が表示されます。
extraManifestPath
は引き続きサポートされていますが、extraManifests.searchPaths
を使用することを推奨します。SiteConfig
ファイルで extraManifests.searchPaths
を定義すると、GitOps ZTP パイプラインはサイトのインストール中に ztp-site-generate
コンテナーからマニフェストを取得しません。
Siteconfig
CR で extraManifestPath
と extraManifests.searchPaths
の両方を定義した場合は、extraManifests.searchPaths
に定義された設定が優先されます。
/extra-manifest
の内容を ztp-site-generate
コンテナーから抽出し、GIT リポジトリーにプッシュすることを強く推奨します。
8.2. SiteConfig フィルターを使用したカスタムリソースのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
フィルターを使用すると、SiteConfig
カスタムリソース (CR) を簡単にカスタマイズして、GitOps Zero Touch Provisioning (ZTP) パイプラインのインストールフェーズで使用する他の CR を追加または除外できます。
SiteConfig
CR の inclusionDefault
値として include
または exclude
を指定し、さらに、含めたり除外したりする特定の extraManifest
RAN CR のリストを指定することもできます。inclusionDefault
を include
に設定すると、GitOps ZTP パイプラインはインストール中に /source-crs/extra-manifest
内のすべてのファイルを適用します。inclusionDefault
を exclude
に設定すると、その逆になります。
デフォルトで含まれている /source-crs/extra-manifest
フォルダーから個々の CR を除外できます。以下の例では、インストール時に /source-crs/extra-manifest/03-sctp-machine-config-worker.yaml
CR を除外するようにカスタムのシングルノード OpenShift SiteConfig
CR を設定します。
また、いくつかのオプションのフィルタリングシナリオも説明されています。
前提条件
- 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
GitOps ZTP パイプラインが
03-sctp-machine-config-worker.yaml
CR ファイルを適用しないようにするには、SiteConfig
CR で次の YAML を適用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow GitOps ZTP パイプラインは、インストール中に
03-sctp-machine-config-worker.yaml
CR をスキップします。/source-crs/extra-manifest
内の他のすべての CR が適用されます。SiteConfig
CR を保存し、変更をサイト設定リポジトリーにプッシュします。GitOps ZTP パイプラインは、
SiteConfig
フィルター命令に基づいて適用する CR を監視および調整します。オプション: クラスターのインストール中に GitOps ZTP パイプラインがすべての
/source-crs/extra-manifest
CR を適用しないようにするには、SiteConfig
CR で次の YAML を適用します。- clusterName: "site1-sno-du" extraManifests: filter: inclusionDefault: exclude
- clusterName: "site1-sno-du" extraManifests: filter: inclusionDefault: exclude
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: インストール中にすべての
/source-crs/extra-manifest
RAN CR を除外し、代わりにカスタム CR ファイルを含めるには、カスタムSiteConfig
CR を編集してカスタムマニフェストフォルダーとinclude
ファイルを設定します。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例は、カスタムフォルダー構造を示しています。
siteconfig ├── site1-sno-du.yaml └── user-custom-manifest └── custom-sctp-machine-config-worker.yaml
siteconfig ├── site1-sno-du.yaml └── user-custom-manifest └── custom-sctp-machine-config-worker.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3. SiteConfig CR を使用してノードを削除する リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
カスタムリソース (CR) を使用すると、ノードを削除して再プロビジョニングできます。この方法は、手動でノードを削除するよりも効率的です。
前提条件
- 必要なインストールおよびポリシー CR を生成するようにハブクラスターを設定している。
- カスタムサイト設定データを管理できる Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
SiteConfig
CR を更新してbmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true
アノテーションを追加し、変更を Git リポジトリーにプッシュします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
BareMetalHost
オブジェクトにアノテーションが付けられていることを確認します。oc get bmh -n <managed-cluster-namespace> <bmh-object> -ojsonpath='{.metadata}' | jq -r '.annotations["bmac.agent-install.openshift.io/remove-agent-and-node-on-delete"]'
oc get bmh -n <managed-cluster-namespace> <bmh-object> -ojsonpath='{.metadata}' | jq -r '.annotations["bmac.agent-install.openshift.io/remove-agent-and-node-on-delete"]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
true
true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
CR を更新してcrSuppression.BareMetalHost
アノテーションを含めることで、BareMetalHost
CR の生成を抑制します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
変更を Git リポジトリーにプッシュし、プロビジョニング解除が開始するまで待ちます。
BareMetalHost
CR のステータスがdeprovisioning
に変更されるはずです。BareMetalHost
のプロビジョニング解除が完了し、完全に削除されるまで待ちます。
検証
次のコマンドを実行して、ワーカーノードの
BareMetalHost
およびAgent
CR がハブクラスターから削除されていることを確認します。oc get bmh -n <cluster-ns>
$ oc get bmh -n <cluster-ns>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get agent -n <cluster-ns>
$ oc get agent -n <cluster-ns>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、スポーククラスターからノードレコードが削除されたことを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記シークレットを操作している場合は、シークレットを削除するのが早すぎると、ArgoCD が削除後に再同期を完了するためにシークレットを必要とするため、問題が発生する可能性があります。現在の ArgoCD 同期が完了したら、ノードのクリーンアップ後にのみシークレットを削除します。
次のステップ
ノードを再プロビジョニングするには、以前に SiteConfig
に追加された変更を削除し、変更を Git リポジトリーにプッシュして、同期が完了するまで待機します。これにより、ワーカーノードの BareMetalHost
CR が再生成され、ノードの再インストールがトリガーされます。
第9章 PolicyGenerator リソースを使用したクラスターポリシーの管理 リンクのコピーリンクがクリップボードにコピーされました!
9.1. PolicyGenerator リソースを使用したマネージドクラスターポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
適用された Policy
カスタムリソース (CR) は、プロビジョニングするマネージドクラスターを設定します。Red Hat Advanced Cluster Management (RHACM) が PolicyGenerator
CR を使用して、適用される Policy
CR を生成する方法をカスタマイズできます。
GitOps ZTP での PolicyGenerator リソースの使用は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
9.1.1. RHACM PolicyGenerator と PolicyGenTemplate リソースのパッチ適用の比較 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
カスタムリソース (CR) と PolicyGenTemplate
CR を GitOps ZTP で使用して、マネージドクラスターの RHACM ポリシーを生成できます
GitOps ZTP を使用して OpenShift Container Platform リソースにパッチを適用する場合、PolicyGenTemplate
CR よりも PolicyGenerator
CR を使用する方が利点があります。RHACM PolicyGenerator
API を使用すると、PolicyGenTemplate
リソースでは不可能な、リソースにパッチを適用する一般的な方法が提供されます。
PolicyGenerator
API は、Open Cluster Management 標準の一部ですが、PolicyGenTemplate
API はその一部ではありません。次の表では、PolicyGenerator
と PolicyGenTemplate
リソースのパッチ適用および配置ストラテジーの比較を説明します。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
PolicyGenerator のパッチ適用 | PolicyGenTemplate のパッチ適用 |
---|---|
リソースのマージには Kustomize ストラテジーマージを使用します。詳細は、Kustomize を使用した Kubernetes オブジェクトの宣言的管理 を参照してください。 | 変数をパッチで定義された値に置き換えることによって機能します。これは Kustomize マージストラテジーよりも柔軟性が低くなります。 |
|
|
パッチ適用のみに依存し、埋め込み変数の置換は必要ありません。 | パッチで定義された変数値を上書きします。 |
マージパッチ内のリストのマージはサポートされません。マージパッチ内のリストの置き換えはサポートされています。 | リストのマージと置換は制限付きでサポートされており、リスト内の 1 つのオブジェクトのみをマージできます。 |
現在、リソースのパッチ適用に OpenAPI 仕様 はサポートされていません。つまり、 | フィールドと値をパッチで定義された値に置き換えることによって機能します。 |
スキーマに従わないコンテンツをマージするには、パッチ内で |
ソース CR で定義されたフィールドと値を、パッチで定義された値 (例: |
参照ソース CR で定義された |
参照ソース CR で定義された |
9.1.2. PolicyGenerator CRD について リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
カスタムリソース定義 (CRD) は、PolicyGen
ポリシージェネレーターに、クラスター設定に含めるカスタムリソース (CR)、生成されたポリシーに CR を統合する方法、およびオーバーレイコンテンツで更新する必要がある CR 内の項目を指示します。
次の例は、ztp-site-generate
参照コンテナーから抽出された PolicyGenerator
CR (acm-common-du-ranGen.yaml
) を示しています。acm-common-du-ranGen.yaml
ファイルは、2 つの Red Hat Advanced Cluster Management (RHACM) ポリシーを定義します。ポリシーは、CR 内の policyName
の一意の値ごとに 1 つずつ、設定 CR のコレクションを管理します。acm-common-du-ranGen.yaml
は、policyDefaults.placement.labelSelector
セクションにリストされているラベルに基づいて、ポリシーをクラスターにバインドするための単一の配置バインディングと配置ルールを作成します。
PolicyGenerator CR の例 - acm-common-ranGen.yaml
PolicyGenerator
CR は、任意の数の CR を含めて構築できます。次の例の CR をハブクラスターに適用して、単一の CR を含むポリシーを生成します。
ソースファイル PtpConfigSlave.yaml
を例として使用すると、ファイルは PtpConfig
CR を定義します。PtpConfigSlave
サンプルの生成ポリシーは group-du-sno-config-policy
という名前です。生成された group-du-sno-config-policy
に定義される PtpConfig
CR は du-ptp-slave
という名前です。PtpConfigSlave.yaml
で定義された spec
は、du-ptp-slave
の下に、ソースファイルで定義された他の spec
項目と共に配置されます。
次の例は、group-du-sno-config-policy
CR を示しています。
9.1.3. PolicyGenerator CR をカスタマイズする際の推奨事項 リンクのコピーリンクがクリップボードにコピーされました!
サイト設定の PolicyGenerator
カスタムリソース (CR) をカスタマイズするときは、以下のベストプラクティスを考慮してください。
-
必要な数のポリシーを使用します。使用するポリシーが少ないほど、必要なリソースが少なくなります。追加のポリシーごとに、ハブクラスターとデプロイされたマネージドクラスターの CPU 負荷が増加します。CR は
PolicyGenerator
CR のpolicyName
フィールドに基づいてポリシーに統合されます。同じPolicyGenerator
内でpolicyName
の値が同じ CR は、シングルポリシーで管理されます。 -
非接続環境では、すべての Operator を含む単一のインデックスとしてレジストリーを設定することにより、すべての Operator に対して単一のカタログソースを使用します。マネージドクラスターに
CatalogSource
CR を追加するたびに、CPU 使用率が増加します。 -
MachineConfig
CR は、インストール時に適用されるようにSiteConfig
CR にextraManifests
として組み込む必要があります。これにより、クラスターがアプリケーションをデプロイする準備ができるまで全体的な時間がかかる可能性があります。 -
PolicyGenerator
CR は、チャネルフィールドをオーバーライドして、目的のバージョンを明示的に識別する必要があります。これにより、アップグレード時にソース CR が変更されても、生成されたサブスクリプションが更新されないようになります。
ハブクラスターで多数のスポーククラスターを管理する場合は、ポリシーの数を最小限に抑えてリソースの消費を減らします。
複数のコンフィギュレーション CR を 1 つまたは限られた数のポリシーにグループ化することは、ハブクラスター上のポリシーの総数を減らすための 1 つの方法です。サイト設定の管理に共通、グループ、サイトというポリシーの階層を使用する場合は、サイト固有の設定を 1 つのポリシーにまとめることが特に重要である。
9.1.4. RAN デプロイメント用の PolicyGenerator CR リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
カスタムリソース (CR) を使用し、GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してクラスターに適用される設定をカスタマイズします。PolicyGenerator
CR を使用すると、クラスター群の設定 CR のセットを管理するための 1 つ以上のポリシーを生成できます。PolicyGenerator
CR は、マネージド CR のセットを識別し、それらをポリシーにバンドルして、それらの CR をラップするポリシーをビルドし、ラベルバインディングルールを使用してポリシーをクラスターに関連付けます。
GitOps ZTP コンテナーから取得した参照設定は、RAN (Radio Access Network) 分散ユニット (DU) アプリケーションに典型的な厳しいパフォーマンスとリソース利用制約をクラスターが確実にサポートできるように、重要な機能とノードのチューニング設定のセットを提供するように設計されています。ベースライン設定の変更または省略は、機能の可用性、パフォーマンス、およびリソースの利用に影響を与える可能性があります。参照 PolicyGenerator
CR をベースに使用して、お客様のサイト要件に合わせた設定ファイルの階層を作成します。
RAN DU クラスター設定に定義されているベースライン PolicyGenerator
CR は、GitOps ZTP ztp-site-generate
コンテナーから抽出することが可能です。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。
PolicyGenerator
CR は、./out/argocd/example/acmpolicygenerator/
フォルダーにあります。参照アーキテクチャーには、common、group、および site 固有の設定 CR があります。各 PolicyGenerator
CR は、./out/source-crs
フォルダーにある他の CR を参照します。
以下で、RAN クラスター設定に関連する PolicyGenerator
CR を説明します。シングルノード、3 ノードのコンパクト、および標準のクラスター設定の違いに対応するために、グループ PolicyGenerator
CR にバリアントが提供されています。同様に、シングルノードクラスターとマルチノード (コンパクトまたはスタンダード) クラスターにも、サイト固有の設定バリエーションが提供されています。デプロイメントに関連するグループおよびサイト固有の設定バリアントを使用します。
PolicyGenerator CR | 説明 |
---|---|
| マルチノードクラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。 |
| シングルノード OpenShift クラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。 |
| マルチノードクラスターに適用される共通の RAN ポリシー設定のセットが含まれています。 |
| すべてのクラスターに適用される共通の RAN CR のセットが含まれています。これらの CR は、RAN の典型的なクラスター機能とベースラインクラスターのチューニングを提供する Operator のセットをサブスクライブします。 |
| 3 ノードクラスター用の RAN ポリシーのみが含まれています。 |
| シングルノードクラスター用の RAN ポリシーのみが含まれています。 |
| 標準的な 3 つのコントロールプレーンクラスターの RAN ポリシーが含まれています。 |
|
|
|
標準クラスターに必要なさまざまなポリシーを生成するために使用される |
|
シングルノード OpenShift クラスターに必要なさまざまなポリシーを生成するために使用される |
9.1.5. PolicyGenerator CR を使用したマネージドクラスターのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
次の手順を使用して、GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してプロビジョニングするマネージドクラスターに適用されるポリシーをカスタマイズします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
サイト固有の設定 CR 用の
PolicyGenerator
CR を作成します。-
out/argocd/example/acmpolicygenerator/
フォルダーから CR に適した例 (acm-example-sno-site.yaml
またはacm-example-multinode-site.yaml
など) を選択します。 サンプルファイルの
policyDefaults.placement.labelSelector
フィールドを、SiteConfig
CR に含まれるサイト固有のラベルと一致するように変更します。サンプルのSiteConfig
ファイルでは、サイト固有のラベルはsites: example-sno
です。注記PolicyGenerator
のpolicyDefaults.placement.labelSelector
フィールドで定義されているラベルが、関連するマネージドクラスターのSiteConfig
CR で定義されているラベルに対応していることを確認します。- サンプルファイルの内容を目的の設定に合わせて変更します。
-
オプション: クラスター群全体に適用される一般的な設定 CR の
PolicyGenerator
CR を作成します。-
out/argocd/example/acmpolicygenerator/
フォルダーから CR に適切な例 (acm-common-ranGen.yaml
など) を選択します。 - 必要な設定に合わせてサンプルファイルの内容を変更します。
-
オプション: クラスター群の特定のグループに適用されるグループ設定 CR の
PolicyGenerator
CR を作成します。オーバーレイド仕様ファイルの内容が必要な終了状態と一致することを確認します。参考までに、
out/source-crs
ディレクトリーには、PolicyGenerator テンプレートで含めたりオーバーレイしたりできる source-crs の完全なリストが含まれています。注記クラスターの特定の要件に応じて、クラスターのタイプごとに 1 つ以上のグループポリシーが必要になる場合があります。特に、サンプルのグループポリシーにはそれぞれ単一の
PerformancePolicy.yaml
ファイルがあり、それらのクラスターが同一のハードウェア設定で構成されている場合にのみ、クラスターのセット全体で共有できることを考慮すると、これが当てはまります。-
out/argocd/example/acmpolicygenerator/
フォルダーから CR に適切な例 (acm-group-du-sno-ranGen.yaml
など) を選択します。 - 必要な設定に合わせてサンプルファイルの内容を変更します。
-
-
オプション: GitOps ZTP のインストールとデプロイされたクラスターの設定が完了したときに通知するバリデーター通知ポリシー
PolicyGenerator
CR を作成します。詳細は、「バリデーター通知ポリシーの作成」を参照してください。 サンプルの
out/argocd/example/acmpolicygenerator//ns.yaml
ファイルと同様の YAML ファイルですべてのポリシー namespace を定義します。重要Namespace
CR をPolicyGenerator
CR と同じファイルに含めないでください。-
out/argocd/example/acmpolicygenerator/kustomization.yaml
に示されている例と同様に、PolicyGenerator
CR とNamespace
CR を、ジェネレーターセクションのkustomization.yaml
ファイルに追加します。 PolicyGenerator
CR、Namespace
CR、および関連するkustomization.yaml
ファイルを Git リポジトリーにコミットし、変更をプッシュします。ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。変更を
SiteConfig
CR とPolicyGenerator
CR に同時にプッシュできます。
9.1.6. マネージドクラスターポリシーのデプロイメントの進行状況の監視 リンクのコピーリンクがクリップボードにコピーされました!
ArgoCD パイプラインは、Git の PolicyGenerator
CR を使用して RHACM ポリシーを生成し、ハブクラスターに同期します。アシストサービスによってマネージドクラスターに OpenShift Container Platform がインストールされた後、マネージドクラスターのポリシー同期の進行状況を監視できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
Topology Aware Lifecycle Manager (TALM) は、クラスターにバインドされている設定ポリシーを適用します。
クラスターのインストールが完了し、クラスターが
Ready
になると、ran.openshift.io/ztp-deploy-wave
アノテーションで定義された順序付きポリシーのリストで、このクラスターに対応するClusterGroupUpgrade
CR が TALM により自動的に作成されます。クラスターのポリシーは、ClusterGroupUpgrade
CR に記載されている順序で適用されます。以下のコマンドを使用して、設定ポリシー調整のハイレベルの進捗を監視できます。
export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq
$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM ダッシュボードまたはコマンドラインを使用して、詳細なクラスターポリシーのコンプライアンスステータスを監視できます。
oc
を使用してポリシーのコンプライアンスを確認するには、次のコマンドを実行します。oc get policies -n $CLUSTER
$ oc get policies -n $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM Web コンソールからポリシーのステータスを確認するには、次のアクションを実行します。
- ガバナンス → ポリシーの検索 をクリックします。
- クラスターポリシーをクリックして、ステータスを確認します。
すべてのクラスターポリシーが準拠すると、クラスターの GitOps ZTP のインストールと設定が完了します。ztp-done
ラベルがクラスターに追加されます。
参照設定では、準拠する最終的なポリシーは、*-du-validator-policy
ポリシーで定義されたものです。このポリシーは、クラスターに準拠する場合、すべてのクラスター設定、Operator のインストール、および Operator 設定が完了します。
9.1.7. 設定ポリシー CR の生成の検証 リンクのコピーリンクがクリップボードにコピーされました!
Policy
カスタムリソース (CR) は、作成元の PolicyGenerator
と同じ namespace に生成されます。以下のコマンドを使用して示すように、ztp-common
、ztp-group
、または ztp-site
ベースのいずれであるかにかかわらず、PolicyGenerator
から生成されたすべてのポリシー CR に同じトラブルシューティングフローが適用されます。
export NS=<namespace>
$ export NS=<namespace>
oc get policy -n $NS
$ oc get policy -n $NS
予想される policy-wrapped CR のセットが表示されるはずです。
ポリシーの同期に失敗した場合は、以下のトラブルシューティング手順を使用します。
手順
ポリシーの詳細情報を表示するには、次のコマンドを実行します。
oc describe -n openshift-gitops application policies
$ oc describe -n openshift-gitops application policies
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Status: Conditions:
の有無を確認し、エラーログを表示します。たとえば、無効なsourceFile
エントリーをfileName:
に設定すると、以下次に示すエラーが生成されます。Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1 Type: ComparisonError
Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1 Type: ComparisonError
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Status: Sync:
をチェックします。Status: Conditions:
: でログエラーが発生した場合Status: Sync:
にUnknown
またはError
と表示されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Advanced Cluster Management (RHACM) が
ManagedCluster
オブジェクトにポリシーが適用されることを認識すると、ポリシー CR オブジェクトがクラスターネームスペースに適用されます。ポリシーがクラスターネームスペースにコピーされたかどうかを確認します。oc get policy -n $CLUSTER
$ oc get policy -n $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM は、適用可能なすべてのポリシーをクラスターの namespace にコピーします。コピーされたポリシー名の形式は、
<PolicyGenerator.Namespace>.<PolicyGenerator.Name>-<policyName>
です。クラスター namespace にコピーされないポリシーの配置ルールを確認します。これらのポリシーの
Placement
のmatchSelector
は、ManagedCluster
オブジェクトのラベルと一致する必要があります。oc get Placement -n $NS
$ oc get Placement -n $NS
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Placement
名は、以下のコマンドを使用して、不足しているポリシー (common、group、または site) に適した名前であることに注意してください。oc get Placement -n $NS <placement_rule_name> -o yaml
$ oc get Placement -n $NS <placement_rule_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - status-decisions にはクラスター名が含まれている必要があります。
-
spec の
matchSelector
の key-value ペアは、マネージドクラスター上のラベルと一致する必要があります。
以下のコマンドを使用して、
ManagedCluster
オブジェクトのラベルを確認します。oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
$ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、どのポリシーが準拠しているかを確認します。
oc get policy -n $CLUSTER
$ oc get policy -n $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Namespace
、OperatorGroup
、およびSubscription
ポリシーが準拠しているが Operator 設定ポリシーが該当しない場合、Operator はマネージドクラスターにインストールされていない可能性があります。このため、スポークに CRD がまだ適用されていないため、Operator 設定ポリシーの適用に失敗します。
9.1.8. ポリシー調整の再開 リンクのコピーリンクがクリップボードにコピーされました!
たとえば、ClusterGroupUpgrade
カスタムリソース (CR) がタイムアウトした場合など、予期しないコンプライアンスの問題が発生した場合は、ポリシー調整を再開できます。
手順
ClusterGroupUpgrade
CR は、管理クラスターの状態がReady
になった後に Topology Aware Lifecycle Manager によって namespaceztp-install
に生成されます。export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clustergroupupgrades -n ztp-install $CLUSTER
$ oc get clustergroupupgrades -n ztp-install $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 予期せぬ問題が発生し、設定されたタイムアウト (デフォルトは 4 時間) 内にポリシーが苦情にならなかった場合、
ClusterGroupUpgrade
CR のステータスはUpgradeTimedOut と
表示されます。oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow UpgradeTimedOut
状態のClusterGroupUpgrade
CR は、1 時間ごとにポリシー照合を自動的に再開します。ポリシーを変更した場合は、既存のClusterGroupUpgrade
CR を削除して再試行をすぐに開始できます。これにより、ポリシーをすぐに調整する新規ClusterGroupUpgrade
CR の自動作成がトリガーされます。oc delete clustergroupupgrades -n ztp-install $CLUSTER
$ oc delete clustergroupupgrades -n ztp-install $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ClusterGroupUpgrade
CR が UpgradeCompleted
ステータスで完了し、マネージドクラスターに ztp-done
ラベルが適用されている場合は、PolicyGenerator
を使用して追加の設定変更が可能な点に注意してください。既存の ClusterGroupUpgrade
CR を削除しても、TALM は新規 CR を生成しません。
この時点で、GitOps ZTP はクラスターとの対話を完了しました。それ以降の対話は更新として扱われ、ポリシーの修復のために新しい ClusterGroupUpgrade
CR が作成されます。
9.1.9. ポリシーを使用して適用済みマネージドクラスター CR を変更する リンクのコピーリンクがクリップボードにコピーされました!
ポリシーを使用して、マネージドクラスターにデプロイされたカスタムリソース (CR) からコンテンツを削除できます。
PolicyGenerator
CR から作成されたすべての Policy
CR は、complianceType
フィールドがデフォルトで musthave
に設定されています。マネージドクラスター上の CR には指定されたコンテンツがすべて含まれているため、コンテンツが削除されていない musthave
ポリシーは依然として準拠しています。この設定では、CR からコンテンツを削除すると、TALM はポリシーからコンテンツを削除しますが、そのコンテンツはマネージドクラスター上の CR からは削除されません。
complianceType
フィールドを mustonlyhave
に設定することで、ポリシーはクラスター上の CR がポリシーで指定されている内容と完全に一致するようにします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - RHACM を実行しているハブクラスターからマネージドクラスターをデプロイしている。
- ハブクラスターに Topology Aware Lifecycle Manager がインストールされている。
手順
影響を受ける CR から不要になったコンテンツを削除します。この例では、
SriovOperatorConfig
CR からdisableDrain: false
行が削除されました。CR の例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow acm-group-du-sno-ranGen.yaml
ファイルで、影響を受けるポリシーのcomplianceType
をmustonlyhave
に変更します。サンプル YAML
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ClusterGroupUpdates
CR を作成し、CR の変更を受け取る必要があるクラスターを指定します。ClusterGroupUpdates CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
ClusterGroupUpgrade
CR を作成します。oc create -f cgu-remove.yaml
$ oc create -f cgu-remove.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば適切なメンテナンス期間中などに変更を適用する準備が完了したら、次のコマンドを実行して
spec.enable
フィールドの値をtrue
に変更します。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行してポリシーのステータスを確認します。
oc get <kind> <changed_cr_name>
$ oc get <kind> <changed_cr_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーの
COMPLIANCE STATE
がCompliant
の場合、CR が更新され、不要なコンテンツが削除されたことを意味します。マネージドクラスターで次のコマンドを実行して、対象クラスターからポリシーが削除されたことを確認します。
oc get <kind> <changed_cr_name>
$ oc get <kind> <changed_cr_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果がない場合、CR はマネージドクラスターから削除されます。
9.1.10. GitOps ZTP インストール完了の表示 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) は、クラスターの GitOps ZTP インストールステータスを確認するプロセスを単純化します。GitOps ZTP ステータスは、クラスターのインストール、クラスター設定、GitOps ZTP 完了の 3 つのフェーズを遷移します。
- クラスターインストールフェーズ
-
クラスターのインストールフェーズは、
ManagedCluster
CR のManagedClusterJoined
およびManagedClusterAvailable
条件によって示されます。ManagedCluster
CR にこの条件がない場合や、条件がFalse
に設定されている場合、クラスターはインストールフェーズに残ります。インストールに関する追加情報は、AgentClusterInstall
およびClusterDeployment
CR から入手できます。詳細は、「GitOps ZTP のトラブルシューティング」を参照してください。 - クラスター設定フェーズ
-
クラスター設定フェーズは、クラスターの
ManagedCluster
CR に適用されるztp-running
ラベルで示されます。 - GitOps ZTP 完了
クラスターのインストールと設定は、GitOps ZTP 完了フェーズで実行されます。これは、
ztp-running
ラベルを削除し、ManagedCluster
CR にztp-done
ラベルを追加することで表示されます。ztp-done
ラベルは、設定が適用され、ベースライン DU 設定が完了したことを示しています。GitOps ZTP 完了状態への変更は、Red Hat Advanced Cluster Management (RHACM) バリデーター通知ポリシーの準拠状態が条件となります。このポリシーは、完了したインストールの既存の基準をキャプチャし、マネージドクラスターの GitOps ZTP プロビジョニングが完了したときにのみ、準拠した状態に移行することを検証するものです。
バリデータ通知ポリシーは、クラスターの設定が完全に適用され、Operator が初期化を完了したことを確認します。ポリシーは以下を検証します。
-
ターゲット
MachineConfigPool
には予想されるエントリーが含まれ、更新が完了しました。全ノードが利用可能で、低下することはありません。 -
SR-IOV Operator は、
syncStatus: Succeeded
の 1 つ以上のSriovNetworkNodeState
によって示されているように初期化を完了しています。 - PTP Operator デーモンセットが存在する。
-
ターゲット
9.2. PolicyGenerator リソースを使用した高度なマネージドクラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
CR を使用して、マネージドクラスターにカスタム機能をデプロイできます。
GitOps ZTP での PolicyGenerator リソースの使用は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
PolicyGenerator
リソースの詳細は、RHACM の Policy Generator のドキュメントを参照してください。
9.2.1. 追加の変更のクラスターへのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
基本の GitOps Zero Touch Provisioning (ZTP) パイプライン設定以外のクラスター設定を変更する必要がある場合、次の 3 つのオプションを実行できます。
- GitOps ZTP パイプラインの完了後に追加設定を適用する
- GitOps ZTP パイプラインのデプロイが完了すると、デプロイされたクラスターはアプリケーションのワークロードに対応できるようになります。この時点で、Operator を追加インストールし、お客様の要件に応じた設定を適用することができます。追加のコンフィギュレーションがプラットフォームのパフォーマンスや割り当てられた CPU バジェットに悪影響を与えないことを確認する。
- GitOps ZTP ライブラリーにコンテンツを追加する
- GitOps ZTP パイプラインでデプロイするベースソースのカスタムリソース (CR) は、必要に応じてカスタムコンテンツで拡張できます。
- クラスターインストール用の追加マニフェストの作成
- インストール時に余分なマニフェストが適用され、インストール作業を効率化することができます。
追加のソース CR を提供したり、既存のソース CR を変更したりすると、OpenShift Container Platform のパフォーマンスまたは CPU プロファイルに大きな影響を与える可能性があります。
9.2.2. PolicyGenerator CR を使用したソース CR コンテンツのオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
カスタムリソース (CR) を使用すると、ztp-site-generate
コンテナー内の GitOps プラグインで提供されるベースソース CR の上に追加の設定の詳細をオーバーレイできます。PolicyGenerator
CR は、ベース CR への論理的なマージまたはパッチと考えることができます。PolicyGenerator
CR を使用して、ベース CR のシングルフィールドを更新するか、ベース CR の内容全体をオーバーレイします。ベース CR にない値の更新やフィールドの挿入が可能です。
以下の手順の例では、acm-group-du-sno-ranGen.yaml
ファイルの PolicyGenerator
CR に基づいて、参照設定用に生成された PerformanceProfile
CR のフィールドを更新する方法を説明します。この手順を元に、PolicyGenerator
の他の部分をお客様のご要望に応じて変更してください。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。
手順
既存のコンテンツのベースラインソース CR を確認します。参照
PolicyGenerator
CR にリストされているソース CR を GitOps Zero Touch Provisioning (ZTP) コンテナーから抽出し、確認できます。/out
フォルダーを作成します。mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ソース CR を抽出します。
podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18.1 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18.1 extract /home/ztp --tar | tar x -C ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
./out/source-crs/PerformanceProfile.yaml
にあるベースラインPerformanceProfile
CR を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ソース CR のフィールドで
$...
を含むものは、PolicyGenerator
CR で提供されない場合、生成された CR から削除されます。acm-group-du-sno-ranGen.yaml
参照ファイル内のPerformanceProfile
のPolicyGenerator
エントリーを更新します。以下の例のPolicyGenerator
CR スタンザは、適切な CPU 仕様を指定し、hugepages
を設定して、globallyDisableIrqLoadBalancing
を false に設定する新しいフィールドを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git で
PolicyGenerator
変更をコミットし、GitOps ZTP argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。出力例
GitOps ZTP アプリケーションは、生成された
PerformanceProfile
CR を含む RHACM ポリシーを生成します。その CR の内容は、PolicyGenerator
のPerformanceProfile
エントリーのmetadata
およびspec
内容をソース CR にマージすることによって生成されます。作成される CR には以下のコンテンツが含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ztp-site-generate
コンテナーからデプロイメントした /source-crs
フォルダーでは、$
構文が暗示するテンプレート置換は使用されません。むしろ、policyGen
ツールが文字列の $
接頭辞を認識し、関連する PolicyGenerator
CR でそのフィールドの値を指定しない場合、そのフィールドは出力 CR から完全に省略されます。
例外として、/source-crs
YAML ファイル内の $mcp
変数は、PolicyGenerator
CR から mcp
の指定値で代用されます。たとえば、example/policygentemplates/acm-group-du-standard-ranGen.yaml
では、mcp
の値は worker
になります。
spec: bindingRules: group-du-standard: "" mcp: "worker"
spec:
bindingRules:
group-du-standard: ""
mcp: "worker"
policyGen
ツールは、$mcp
のインスタンスを出力 CR の worker
に置き換えます。
9.2.3. GitOps ZTP パイプラインへのカスタムコンテンツの追加 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP パイプラインに新しいコンテンツを追加するには、次の手順を実行します。
手順
-
PolicyGenerator
カスタムリソース (CR) のkustomization.yaml
ファイルが含まれるディレクトリーに、source-crs
という名前のサブディレクトリーを作成します。 次の例に示すように、ユーザー提供の CR を
source-crs
サブディレクトリーに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
source-crs
サブディレクトリーは、kustomization.yaml
ファイルと同じディレクトリーにある必要があります。
必要な
PolicyGenerator
CR を更新して、source-crs/custom-crs
およびsource-crs/elasticsearch
ディレクトリーに追加したコンテンツへの参照を含めます。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenerator
変更をコミットしてから、GitOps ZTP Argo CD ポリシーアプリケーションが監視する Git リポジトリーにプッシュします。 変更された
PolicyGenerator
を含めるようにClusterGroupUpgrade
CR を更新し、cgu-test.yaml
として保存します。次の例は、生成されたcgu-test.yaml
ファイルを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、更新された
ClusterGroupUpgrade
CR を適用します。oc apply -f cgu-test.yaml
$ oc apply -f cgu-test.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、更新が成功したことを確認します。
oc get cgu -A
$ oc get cgu -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.4. PolicyGenerator CR のポリシーコンプライアンス評価タイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
ハブクラスターにインストールされた Red Hat Advanced Cluster Management (RHACM) を使用して、マネージドクラスターが適用されたポリシーに準拠しているかどうかを監視および報告します。RHACM は、ポリシーテンプレートを使用して、定義済みのポリシーコントローラーとポリシーを適用します。ポリシーコントローラーは Kubernetes のカスタムリソース定義 (CRD) インスタンスです。
PolicyGenerator
カスタムリソース (CR) を使用して、デフォルトのポリシー評価間隔をオーバーライドできます。RHACM が適用されたクラスターポリシーを再評価する前に、ConfigurationPolicy
CR がポリシー準拠または非準拠の状態を維持できる期間を定義する期間設定を設定します。
GitOps Zero Touch Provisioning (ZTP) ポリシージェネレーターは、事前定義されたポリシー評価間隔で ConfigurationPolicy
CR ポリシーを生成します。noncompliant
状態のデフォルト値は 10 秒です。compliant
状態のデフォルト値は 10 分です。評価間隔を無効にするには、値を never
に設定します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
PolicyGenerator
CR 内のすべてのポリシーの評価間隔を設定するには、evaluationInterval
フィールドに適切なcompliant
とnoncompliant
値を設定します。以下に例を示します。policyDefaults: evaluationInterval: compliant: 30m noncompliant: 45s
policyDefaults: evaluationInterval: compliant: 30m noncompliant: 45s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記また、
compliant
フィールドとnoncompliant
フィールドをnever
に設定して、特定の準拠状態に達した後にポリシーの評価を停止することもできます。PolicyGenerator
CR 内の個々のポリシーオブジェクトの評価間隔を設定するには、evaluationInterval
フィールドを追加し、適切な値を設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git リポジトリー内の
PolicyGenerator
CR ファイルをコミットし、変更をプッシュします。
検証
マネージドスポーククラスターポリシーが予想される間隔で監視されていることを確認します。
-
マネージドクラスターで
cluster-admin
権限を持つユーザーとしてログインします。 open-cluster-management-agent-addon
namespace で実行されている Pod を取得します。以下のコマンドを実行します。oc get pods -n open-cluster-management-agent-addon
$ oc get pods -n open-cluster-management-agent-addon
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow config-policy-controller
Pod のログで、適用されたポリシーが予想される間隔で評価されていることを確認します。oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb
$ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}
2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.5. バリデーターインフォームポリシーを使用した GitOps ZTP クラスターデプロイメントの完了のシグナリング リンクのコピーリンクがクリップボードにコピーされました!
デプロイされたクラスターの GitOps Zero Touch Provisioning (ZTP) のインストールと設定が完了したときに通知するバリデーター通知ポリシーを作成します。このポリシーは、シングルノード OpenShift クラスター、3 ノードクラスター、および標準クラスターのデプロイメントに使用できます。
手順
ソースファイル
validatorCRs/informDuValidator.yaml
を含むスタンドアロンのPolicyGenerator
カスタムリソース (CR) を作成します。クラスタータイプごとにスタンドアロンPolicyGenerator
CR が 1 つだけ必要です。たとえば、次の CR は、シングルノード OpenShift クラスターにバリデータ通知ポリシーを適用します。シングルノードクラスターバリデーター通知ポリシー CR の例 (acm-group-du-sno-validator-ranGen.yaml)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git リポジトリー内の
PolicyGenerator
CR ファイルをコミットし、変更をプッシュします。
9.2.6. PolicyGenerator CR を使用した電源状態の設定 リンクのコピーリンクがクリップボードにコピーされました!
低レイテンシーで高パフォーマンスのエッジデプロイメントでは、C ステートと P ステートを無効にするか制限する必要があります。この設定では、CPU は一定の周波数 (通常は最大ターボ周波数) で実行されます。これにより、CPU が常に最大速度で実行され、高いパフォーマンスと低レイテンシーが実現されます。これにより、ワークロードのレイテンシーが最適化されます。ただし、これは最大の電力消費にもつながり、すべてのワークロードに必要ではない可能性があります。
ワークロードはクリティカルまたは非クリティカルとして分類できます。クリティカルなワークロードでは、高パフォーマンスと低レイテンシーのために C ステートと P ステートの設定を無効にする必要があります。クリティカルでないワークロードでは、C ステートと P ステートの設定を使用して、いくらかのレイテンシーとパフォーマンスを犠牲にします。GitOps Zero Touch Provisioning (ZTP) を使用して、次の 3 つの電源状態を設定できます。
- 高性能モードは、最大の消費電力で超低遅延を提供します。
- パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。
- 省電力は、消費電力の削減と遅延の増加のバランスをとります。
デフォルトの設定は、低遅延のパフォーマンスモードです。
PolicyGenerator
カスタムリソース (CR) を使用すると、ztp-site-generate
コンテナー内の GitOps プラグインで提供されるベースソース CR の上に追加の設定の詳細をオーバーレイできます。
acm-group-du-sno-ranGen.yaml
の PolicyGenerator
CR に基づいて、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新して、電源状態を設定します。
次の共通の前提条件は、3 つの電源状態すべての設定に適用されます。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。
- 「GitOps ZTP サイト設定リポジトリーの準備」で説明されている手順に従っている。
9.2.6.1. PolicyGenerator CR を使用したパフォーマンスモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って、acm-group-du-sno-ranGen.yaml
の PolicyGenerator
CR に基づき、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新して、パフォーマンスモードを設定します。
パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。
前提条件
- 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。
手順
パフォーマンスモードを設定するには、
out/argocd/example/acmpolicygenerator//
のacm-group-du-sno-ranGen.yaml
参照ファイルでPerformanceProfile
のPolicyGenerator
エントリーを以下のように更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenerator
変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
9.2.6.2. PolicyGenerator CR を使用した高パフォーマンスモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って、acm-group-du-sno-ranGen.yaml
の PolicyGenerator
CR に基づき、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新して、高パフォーマンスモードを設定します。
高パフォーマンスモードは、最大の消費電力で超低遅延を提供します。
前提条件
- 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。
手順
高パフォーマンスモードを設定するには、
out/argocd/example/acmpolicygenerator/
のacm-group-du-sno-ranGen.yaml
参照ファイルでPerformanceProfile
のPolicyGenerator
エントリーを次のように更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenerator
変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
9.2.6.3. PolicyGenerator CR を使用した省電力モードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って、acm-group-du-sno-ranGen.yaml
の PolicyGenerator
CR に基づき、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新して、省電力モードを設定します。
省電力モードは、消費電力の削減と遅延の増加のバランスをとります。
前提条件
- BIOS で C ステートと OS 制御の P ステートを有効化している。
手順
省電力モードを設定するには、
out/argocd/example/acmpolicygenerator/
のacm-group-du-sno-ranGen.yaml
参照ファイルでPerformanceProfile
のPolicyGenerator
エントリーを次のように更新します。追加のカーネル引数オブジェクトを使用して、省電力モード用に CPU ガバナーを設定することを推奨します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
schedutil
ガバナーが推奨されますが、ondemand
やpowersave
などの他のガバナーを使用することもできます。
-
Git で
PolicyGenerator
変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
検証
次のコマンドを使用して、識別されたノードのリストから、デプロイされたクラスター内のワーカーノードを選択します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、ノードにログインします。
oc debug node/<node-name>
$ oc debug node/<node-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <node-name>
を、電源状態を確認するノードの名前に置き換えます。/host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。次の例に示すように、ルートディレクトリーを/host
に変更すると、ホストの実行可能パスに含まれるバイナリーを実行できます。chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、適用された電源状態を確認します。
cat /proc/cmdline
# cat /proc/cmdline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
予想される出力
-
省電力モードの
intel_pstate=passive
。
9.2.6.4. 省電力の最大化 リンクのコピーリンクがクリップボードにコピーされました!
最大の CPU 周波数を制限して、最大の電力節約を実現することを推奨します。最大 CPU 周波数を制限せずに重要でないワークロード CPU で C ステートを有効にすると、重要な CPU の周波数が高くなるため、消費電力の節約の多くが無効になります。
sysfs
プラグインフィールドを更新し、リファレンス設定の TunedPerformancePatch
CR で max_perf_pct
に適切な値を設定することで、電力の節約を最大化します。acm-group-du-sno-ranGen.yaml
に基づくこの例では、最大 CPU 周波数を制限するための手順を説明します。
前提条件
- 「PolicyGenerator CR を使用した省電力モードの設定」の説明に従って、省電力モードを設定している。
手順
out/argocd/example/acmpolicygenerator/
のacm-group-du-sno-ranGen.yaml
参照ファイルで、TunedPerformancePatch
のPolicyGenerator
エントリーを更新します。電力を最大限に節約するには、次の例に示すようにmax_perf_pct
を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
max_perf_pct
は、cpufreq
ドライバーが設定できる最大周波数を、サポートされている最大 CPU 周波数のパーセンテージとして制御します。この値はすべての CPU に適用されます。サポートされている最大周波数は/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
で確認できます。開始点として、All Cores Turbo
周波数ですべての CPU を制限する割合を使用できます。All Cores Turbo
周波数は、コアがすべて使用されているときにすべてのコアが実行される周波数です。
注記省電力を最大化するには、より低い値を設定します。
max_perf_pct
の値を低く設定すると、最大 CPU 周波数が制限されるため、消費電力が削減されますが、パフォーマンスに影響を与える可能性もあります。さまざまな値を試し、システムのパフォーマンスと消費電力を監視して、ユースケースに最適な設定を見つけてください。-
Git で
PolicyGenerator
変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
9.2.7. PolicyGenerator CR を使用した LVM Storage の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) を使用して、デプロイするマネージドクラスターの論理ボリュームマネージャー (LVM) ストレージを設定できます。
HTTP トランスポートで PTP イベントまたはベアメタルハードウェアイベントを使用する場合、LVM Storage を使用してイベントサブスクリプションを永続化します。
分散ユニットでローカルボリュームを使用する永続ストレージには、Local Storage Operator を使用します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
新しいマネージドクラスターの LVM Storage を設定するには、
acm-common-ranGen.yaml
ファイルのpolicies.manifests
に次の YAML を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Storage LVMO サブスクリプションは非推奨になりました。OpenShift Container Platform の将来のリリースでは、ストレージ LVMO サブスクリプションは利用できなくなります。代わりに、Storage LVMS サブスクリプションを使用する必要があります。
OpenShift Container Platform 4.18 では、LVMO サブスクリプションの代わりに Storage LVMS サブスクリプションを使用できます。LVMS サブスクリプションでは、
acm-common-ranGen.yaml
ファイルを手動でオーバーライドする必要はありません。Storage LVMS サブスクリプションを使用するには、acm-common-ranGen.yaml
ファイルのpolicies.manifests
に次の YAML を追加します。- path: source-crs/StorageLVMSubscriptionNS.yaml - path: source-crs/StorageLVMSubscriptionOperGroup.yaml - path: source-crs/StorageLVMSubscription.yaml
- path: source-crs/StorageLVMSubscriptionNS.yaml - path: source-crs/StorageLVMSubscriptionOperGroup.yaml - path: source-crs/StorageLVMSubscription.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のグループまたは個々のサイト設定ファイルの
policies.manifests
にLVMCluster
CR を追加します。たとえば、acm-group-du-sno-ranGen.yaml
ファイルに以下を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定例では、OpenShift Container Platform がインストールされているディスクを除く、使用可能なすべてのデバイスを含むボリュームグループ (
vg1
) を作成します。シンプール論理ボリュームも作成されます。- 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
-
Git で
PolicyGenerator
の変更をコミットしてから、その変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して LVM Storage を新しいサイトにデプロイします。
9.2.8. PolicyGenerator CR を使用した PTP イベントの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP パイプラインを使用して、HTTP トランスポートを使用する PTP イベントを設定できます。
9.2.8.1. HTTP トランスポートを使用する PTP イベントの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイしたマネージドクラスター上で、HTTP トランスポートを使用する PTP イベントを設定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
要件に応じて、次の
PolicyGenerator
変更をacm-group-du-3node-ranGen.yaml
、acm-group-du-sno-ranGen.yaml
、またはacm-group-du-standard-ranGen.yaml
ファイルに適用します。policies.manifests
に、トランスポートホストを設定するPtpOperatorConfig
CR ファイルを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfig
リソースのtransportHost
フィールドを設定する必要はありません。PTP クロックの種類とインターフェイスに
linuxptp
とphc2sys
を設定します。たとえば、次の YAML をpolicies.manifests
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要件に応じて、
PtpConfigMaster.yaml
またはPtpConfigSlave.yaml
を指定できます。acm-group-du-sno-ranGen.yaml
またはacm-group-du-3node-ranGen.yaml
に基づいて設定する場合は、PtpConfigSlave.yaml
を使用します。 - 2
- デバイス固有のインターフェイス名。
- 3
- PTP 高速イベントを有効にするには、
.spec.sourceFiles.spec.profile
のptp4lOpts
に--summary_interval -4
値を追加する必要があります。 - 4
phc2sysOpts
の値が必要です。-m
はメッセージをstdout
に出力します。linuxptp-daemon
DaemonSet
はログを解析し、Prometheus メトリックを生成します。- 5
- オプション:
ptpClockThreshold
スタンザが存在しない場合は、ptpClockThreshold
フィールドにデフォルト値が使用されます。スタンザは、デフォルトのptpClockThreshold
値を示します。ptpClockThreshold
値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeout
は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUN
に変わるまでの時間値 (秒単位) です。maxOffsetThreshold
およびminOffsetThreshold
設定は、CLOCK_REALTIME
(phc2sys
) またはマスターオフセット (ptp4l
) の値と比較するナノ秒単位のオフセット値を設定します。ptp4l
またはphc2sys
のオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUN
に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKED
に設定されます。
- 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
- 変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して PTP 高速イベントを新規サイトにデプロイします。
9.2.9. イメージをローカルにキャッシュするための Image Registry Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、ローカルレジストリーを使用してイメージのキャッシュを管理します。エッジコンピューティングのユースケースでは、クラスターは集中型のイメージレジストリーと通信するときに帯域幅の制限を受けることが多く、イメージのダウンロード時間が長くなる可能性があります。
初期デプロイメント中はダウンロードに時間がかかることは避けられません。時間の経過とともに、予期しないシャットダウンが発生した場合に CRI-O が /var/lib/containers/storage
ディレクトリーを消去するリスクがあります。イメージのダウンロード時間が長い場合の対処方法として、GitOps Zero Touch Provisioning (ZTP) を使用してリモートマネージドクラスター上にローカルイメージレジストリーを作成できます。これは、クラスターをネットワークのファーエッジにデプロイするエッジコンピューティングシナリオで役立ちます。
GitOps ZTP を使用してローカルイメージレジストリーをセットアップする前に、リモートマネージドクラスターのインストールに使用する SiteConfig
CR でディスクパーティショニングを設定する必要があります。インストール後、PolicyGenerator
CR を使用してローカルイメージレジストリーを設定します。次に、GitOps ZTP パイプラインは永続ボリューム (PV) と永続ボリューム要求 (PVC) CR を作成し、imageregistry
設定にパッチを適用します。
ローカルイメージレジストリーは、ユーザーアプリケーションイメージにのみ使用でき、OpenShift Container Platform または Operator Lifecycle Manager Operator イメージには使用できません。
9.2.9.1. SiteConfig を使用したディスクパーティショニングの設定 リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
CR と GitOps Zero Touch Provisioning (ZTP) を使用して、マネージドクラスターのディスクパーティションを設定します。SiteConfig
CR のディスクパーティションの詳細は、基になるディスクと一致する必要があります。
この手順はインストール時に完了する必要があります。
前提条件
- Butane をインストールしている。
手順
storage.bu
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
storage.bu
を Ignition ファイルに変換します。butane storage.bu
$ butane storage.bu
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}
{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - JSON Pretty Print などのツールを使用して、出力を JSON 形式に変換します。
出力を
SiteConfig
CR の.spec.clusters.nodes.ignitionConfigOverride
フィールドにコピーします。例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記.spec.clusters.nodes.ignitionConfigOverride
フィールドが存在しない場合は、作成します。
検証
インストール中またはインストール後に、次のコマンドを実行して、ハブクラスターで
BareMetalHost
オブジェクトにアノテーションが表示されていることを確認します。oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]
$ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"
"{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストール後、シングルノード OpenShift ディスクのステータスを確認します。
次のコマンドを実行して、シングルノード OpenShift ノードでデバッグセッションを開始します。この手順は、
<node_name>-debug
というデバッグ Pod をインスタンス化します。oc debug node/my-sno-node
$ oc debug node/my-sno-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、デバッグシェル内で
/host
をルートディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。root ディレクトリーを/host
に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、使用可能なすべてのブロックデバイスに関する情報をリスト表示します。
lsblk
# lsblk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ファイルシステムのディスク領域の使用状況に関する情報を表示します。
df -h
# df -h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.9.2. PolicyGenerator CR を使用したイメージレジストリーの設定 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
(PGT) CR を使用して、イメージレジストリーを設定するために必要な CR を適用し、imageregistry
設定にパッチを適用します。
前提条件
- マネージドクラスターでディスクパーティションを設定しました。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - GitOps Zero Touch Provisioning (ZTP) で使用するカスタムサイト設定データを管理する Git リポジトリーを作成している。
手順
適切な
PolicyGenerator
CR で、ストレージクラス、永続ボリューム要求、永続ボリューム、およびイメージレジストリー設定を設定します。たとえば、個々のサイトを設定するには、次の YAML をacm-example-sno-site.yaml
ファイルに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要- fileName: ImageRegistryConfig.yaml
設定には、complianceType: mustonlyhave
を設定しないでください。これにより、レジストリー Pod のデプロイが失敗する可能性があります。-
Git で
PolicyGenerator
変更をコミットしてから、GitOps ZTP ArgoCD アプリケーションによって監視される Git リポジトリーにプッシュします。
検証
次の手順を使用して、マネージドクラスターのローカルイメージレジストリーに関するエラーをトラブルシューティングします。
マネージドクラスターにログインしているときに、レジストリーへのログインが成功したことを確認します。以下のコマンドを実行します。
マネージドクラスター名をエクスポートします。
cluster=<managed_cluster_name>
$ cluster=<managed_cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスター
kubeconfig
の詳細を取得します。oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
$ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター
kubeconfig
をダウンロードしてエクスポートします。oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
$ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - マネージドクラスターからイメージレジストリーへのアクセスを確認します。「レジストリーへのアクセス」を参照してください。
imageregistry.operator.openshift.io
グループインスタンスのConfig
CRD がエラーを報告していないことを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。oc get image.config.openshift.io cluster -o yaml
$ oc get image.config.openshift.io cluster -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターの
PersistentVolumeClaim
にデータが入力されていることを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。oc get pv image-registry-sc
$ oc get pv image-registry-sc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry*
Pod が実行中であり、openshift-image-registry
namespace にあることを確認します。oc get pods -n openshift-image-registry | grep registry*
$ oc get pods -n openshift-image-registry | grep registry*
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターのディスクパーティションが正しいことを確認します。
マネージドクラスターへのデバッグシェルを開きます。
oc debug node/sno-1.example.com
$ oc debug node/sno-1.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow lsblk
を実行して、ホストディスクパーティションを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/var/imageregistry
は、ディスクが正しくパーティショニングされていることを示します。
9.3. PolicyGenerator リソースと TALM を使用した非接続環境でのマネージドクラスターの更新 リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) を使用すると、GitOps Zero Touch Provisioning (ZTP) と Topology Aware Lifecycle Manager (TALM) を使用してデプロイしたマネージドクラスターのソフトウェアライフサイクルを管理できます。TALM は、Red Hat Advanced Cluster Management (RHACM) PolicyGenerator ポリシーを使用して、ターゲットクラスターに適用される変更を管理および制御します。
GitOps ZTP での PolicyGenerator リソースの使用は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
9.3.1. 非接続環境の設定 リンクのコピーリンクがクリップボードにコピーされました!
TALM は、プラットフォームと Operator の更新の両方を実行できます。
TALM を使用して非接続クラスターを更新する前に、ミラーレジストリーで更新するプラットフォームイメージおよび Operator イメージの両方をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。
プラットフォームの更新では、以下の手順を実行する必要があります。
必要な OpenShift Container Platform イメージリポジトリーをミラーリングします。「OpenShift Container Platform イメージリポジトリーのミラーリング」(関連情報のリンクを参照) の手順に従って、目的のプラットフォームイメージがミラーリングされていることを確認します。
imageContentSources.yaml
ファイルのimageContentSources
セクションの内容を保存します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ミラーリングされた目的のプラットフォームイメージのイメージシグネチャーを保存します。プラットフォームを更新するには、
PolicyGenerator
CR にイメージ署名を追加する必要があります。イメージ署名を取得するには、次の手順を実行します。以下のコマンドを実行して、目的の OpenShift Container Platform タグを指定します。
OCP_RELEASE_NUMBER=<release_version>
$ OCP_RELEASE_NUMBER=<release_version>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターのアーキテクチャーを指定します。
ARCHITECTURE=<cluster_architecture>
$ ARCHITECTURE=<cluster_architecture>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
x86_64
、aarch64
、s390x
、またはppc64le
など、クラスターのアーキテクチャーを指定します。
次のコマンドを実行して、Quay からリリースイメージダイジェストを取得します。
DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
$ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ダイジェストアルゴリズムを設定します。
DIGEST_ALGO="${DIGEST%%:*}"
$ DIGEST_ALGO="${DIGEST%%:*}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ダイジェスト署名を設定します。
DIGEST_ENCODED="${DIGEST#*:}"
$ DIGEST_ENCODED="${DIGEST#*:}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、mirror.openshift.com Web サイトからイメージ署名を取得します。
SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
$ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、イメージ署名を
checksum-<OCP_RELEASE_NUMBER>.yaml
ファイルに保存します。cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
$ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
更新グラフを準備します。更新グラフを準備するオプションは 2 つあります。
OpenShift Update Service を使用します。
ハブクラスターでグラフを設定する方法の詳細は、OpenShift Update Service の Operator のデプロイ および グラフデータ init コンテナーのビルド を参照してください。
アップストリームグラフのローカルコピーを作成します。マネージドクラスターにアクセスできる非接続環境の
http
またはhttps
サーバーで更新グラフをホストします。更新グラフをダウンロードするには、以下のコマンドを使用します。curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.18 -o ~/upgrade-graph_stable-4.18
$ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.18 -o ~/upgrade-graph_stable-4.18
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator の更新は、以下のタスクを実行する必要があります。
- Operator カタログをミラーリングします。「非接続クラスターで使用する Operator カタログのミラーリング」セクションの手順に従って、目的の Operator イメージがミラーリングされていることを確認します。
9.3.2. PolicyGenerator CR を使用したプラットフォーム更新の実行 リンクのコピーリンクがクリップボードにコピーされました!
TALM を使用してプラットフォームの更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新している。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
- 目的のイメージリポジトリーをミラーリングしている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
プラットフォーム更新用の
PolicyGenerator
CR を作成します。次の
PolicyGenerator
CR をdu-upgrade.yaml
ファイルに保存します。プラットフォーム更新のための
PolicyGenerator
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 更新をトリガーする
ClusterVersion
CR を示します。イメージの事前キャッシュには、channel
、upstream
、およびdesiredVersion
フィールドがすべて必要です。 - 2
ImageSignature.yaml
には、必要なリリースイメージのイメージ署名が含まれています。イメージ署名は、プラットフォーム更新を適用する前にイメージを検証するために使用されます。- 3
- 必要な OpenShift Container Platform イメージを含むミラーリポジトリーを表示します。「環境のセットアップ」セクションの手順に従って保存した
imageContentSources.yaml
ファイルからミラーを取得します。
PolicyGenerator
CR は 2 つのポリシーを生成します。-
du-upgrade-platform-upgrade-prep
ポリシーは、プラットフォームの更新の準備作業を行います。目的のリリースイメージシグネチャーのConfigMap
CR を作成し、ミラー化されたリリースイメージリポジトリーのイメージコンテンツソースを作成し、目的の更新チャネルと非接続環境でマネージドクラスターが到達可能な更新グラフを使用してクラスターバージョンを更新します。 -
du-upgrade-platform-upgrade
ポリシーは、プラットフォームのアップグレードを実行するために使用されます。
PolicyGenerator
CR の GitOps ZTP Git リポジトリーにあるkustomization.yaml
ファイルにdu-upgrade.yaml
ファイルの内容を追加し、変更を Git リポジトリーにプッシュします。ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。
以下のコマンドを実行して、作成したポリシーを確認します。
oc get policies -A | grep platform-upgrade
$ oc get policies -A | grep platform-upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.enable
フィールドをfalse
に設定して、プラットフォーム更新用のClusterGroupUpdate
CR を作成します。次の例に示すように、プラットフォーム更新
ClusterGroupUpdate
CR の内容を、du-upgrade-platform-upgrade-prep
ポリシーとdu-upgrade-platform-upgrade
ポリシーおよびターゲットクラスターとともに、cgu-platform-upgrade.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ClusterGroupUpdate
CR をハブクラスターに適用します。oc apply -f cgu-platform-upgrade.yml
$ oc apply -f cgu-platform-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: プラットフォームの更新用にイメージを事前キャッシュします。
次のコマンドを実行して、
ClusterGroupUpdate
CR で事前キャッシュを有効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新プロセスを監視し、事前キャッシュが完了するまで待ちます。ハブクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
$ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プラットフォームの更新を開始します。
次のコマンドを実行して、
cgu-platform-upgrade
ポリシーを有効にし、事前キャッシュを無効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3.3. PolicyGenerator CR を使用した Operator 更新の実行 リンクのコピーリンクがクリップボードにコピーされました!
TALM で Operator の更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新している。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
- 目的のインデックスイメージ、バンドルイメージ、およびバンドルイメージで参照されるすべての Operator イメージをミラーリングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
Operator 更新のために
PolicyGenerator
CR を更新します。du-upgrade.yaml
ファイルの次の追加コンテンツでdu-upgrade
PolicyGenerator
CR を更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必要な Operator イメージが含まれています。インデックスイメージが常に同じイメージ名とタグにプッシュされている場合、この変更は必要ありません。
- 2
- Operator Lifecycle Manager (OLM) が新しい Operator バージョンのインデックスイメージをポーリングする頻度を
registryPoll.interval
フィールドで設定します。y-stream および z-stream Operator の更新のために新しいインデックスイメージタグが常にプッシュされる場合、この変更は必要ありません。registryPoll.interval
フィールドを短い間隔に設定して更新を促進できますが、間隔を短くすると計算負荷が増加します。これに対処するために、更新が完了したら、registryPoll.interval
をデフォルト値に戻すことができます。 - 3
- カタログ接続の監視状態を表示します。
READY
値は、CatalogSource
ポリシーの準備が整っていることを保証し、インデックス Pod がプルされ、実行中であることを示します。このように、TALM は最新のポリシー準拠状態に基づいて Operator をアップグレードします。
この更新により、
redhat-operators-disconnected
というポリシーが生成されます。これは、必要な Operator イメージを含む新しいインデックスイメージでredhat-operators-disconnected
カタログソースを更新するためのポリシーです。注記Operator にイメージの事前キャッシュを使用する必要があり、
redhat-operators-disconnected
以外の別のカタログソースからの Operator がある場合は、次のタスクを実行する必要があります。- 別のカタログソースの新しいインデックスイメージまたはレジストリーポーリング間隔の更新を使用して、別のカタログソースポリシーを準備します。
- 異なるカタログソースからの目的の Operator に対して個別のサブスクリプションポリシーを準備します。
たとえば、目的の SRIOV-FEC Operator は、
certified-operators
カタログソースで入手できます。カタログソースと Operator サブスクリプションを更新するには、次の内容を追加して、2 つのポリシーdu-upgrade-fec-catsrc-policy
とdu-upgrade-subscriptions-fec-policy
を生成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 共通
PolicyGenerator
CR に指定されたサブスクリプションチャネルが存在する場合は削除します。GitOps ZTP イメージのデフォルトサブスクリプションチャネルが更新に使用されます。注記GitOps ZTP 4.18 を通じて適用される Operator のデフォルトチャネルは、
performance-addon-operator
以外はstable
です。OpenShift Container Platform 4.11 以降、performance-addon-operator
機能はnode-tuning-operator
に移動されました。4.10 リリースの場合、PAO のデフォルトチャネルはv4.10
です。共通のPolicyGenerator
CR でデフォルトのチャネルを指定することもできます。PolicyGenerator
CR の更新を GitOps ZTP Git リポジトリーにプッシュします。ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。
以下のコマンドを実行して、作成したポリシーを確認します。
oc get policies -A | grep -E "catsrc-policy|subscription"
$ oc get policies -A | grep -E "catsrc-policy|subscription"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator の更新を開始する前に、必要なカタログソースの更新を適用します。
operator-upgrade-prep
という名前のClusterGroupUpgrade
CR の内容をカタログソースポリシーと共に、ターゲットマネージドクラスターの内容をcgu-operator-upgrade-prep.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ポリシーをハブクラスターに適用します。
oc apply -f cgu-operator-upgrade-prep.yml
$ oc apply -f cgu-operator-upgrade-prep.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies -A | grep -E "catsrc-policy"
$ oc get policies -A | grep -E "catsrc-policy"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.enable
フィールドをfalse
に設定して、Operator 更新のClusterGroupUpgrade
CR を作成します。以下の例のように、Operator 更新
ClusterGroupUpgrade
CR の内容をdu-upgrade-operator-catsrc-policy
ポリシーで保存して、共通のPolicyGenerator
およびターゲットクラスターで作成されたサブスクリプションポリシーをcgu-operator-upgrade.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記1 つの
ClusterGroupUpgrade
CR は、ClusterGroupUpgrade
CR に含まれる 1 つのカタログソースからサブスクリプションポリシーで定義される必要な Operator のイメージのみを事前キャッシュできます。SRIOV-FEC Operator の例のように、目的の Operator が異なるカタログソースからのものである場合、別のClusterGroupUpgrade
CR をdu-upgrade-fec-catsrc-policy
およびdu-upgrade-subscriptions-fec-policy
ポリシーで作成する必要があります。SRIOV-FEC Operator イメージの事前キャッシュと更新。次のコマンドを実行して、
ClusterGroupUpgrade
CR をハブクラスターに適用します。oc apply -f cgu-operator-upgrade.yml
$ oc apply -f cgu-operator-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: Operator の更新用にイメージを事前キャッシュします。
イメージの事前キャッシュを開始する前に、以下のコマンドを実行して、サブスクリプションポリシーがこの時点で
NonCompliant
であることを確認します。oc get policy common-subscriptions-policy -n <policy_namespace>
$ oc get policy common-subscriptions-policy -n <policy_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
ClusterGroupUpgrade
CR で事前キャッシュを有効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
$ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。
oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq
$ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator の更新を開始します。
以下のコマンドを実行して
cgu-operator-upgrade
ClusterGroupUpgrade
CR を有効にし、事前キャッシュを無効にして Operator の更新を開始します。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3.4. PolicyGenerator CR を使用した Operator 更新の失敗のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
一部のシナリオでは、ポリシーのコンプライアンス状態が古いため、Topology Aware Lifecycle Manager (TALM) が Operator の更新を見逃す可能性があります。
カタログソースの更新後に Operator Lifecycle Manager (OLM) がサブスクリプションステータスを更新すると、時間がかかります。TALM が修復が必要かどうかを判断する間、サブスクリプションポリシーのステータスは準拠していると表示される場合があります。その結果、サブスクリプションポリシーで指定された Operator はアップグレードされません。
このシナリオを回避するには、別のカタログソース設定を PolicyGenerator
に追加し、更新が必要な Operator のサブスクリプションでこの設定を指定します。
手順
PolicyGenerator
リソースにカタログソース設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新が必要な Operator の新しい設定を指すように
Subscription
リソースを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
PolicyGenerator
リソースで定義した追加のカタログソース設定の名前を入力します。
9.3.5. プラットフォームと Operator の更新を一緒に実行する リンクのコピーリンクがクリップボードにコピーされました!
プラットフォームと Operator の更新を同時に実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新している。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
-
「プラットフォーム更新の実」および「Operator 更新の実行」セクションで説明されている手順に従って、更新用の
PolicyGenerator
CR を作成します。 プラットフォームの準備作業と Operator の更新を適用します。
プラットフォームの更新の準備作業、カタログソースの更新、およびターゲットクラスターのポリシーを含む
ClusterGroupUpgrade
CR の内容をcgu-platform-operator-upgrade-prep.yml
ファイルに保存します。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
cgu-platform-operator-upgrade-prep.yml
ファイルをハブクラスターに適用します。oc apply -f cgu-platform-operator-upgrade-prep.yml
$ oc apply -f cgu-platform-operator-upgrade-prep.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プラットフォーム用の
ClusterGroupUpdate
CR と、spec.enable
フィールドをfalse
に設定した Operator 更新を作成します。次の例に示すように、ポリシーとターゲットクラスターを含むプラットフォームと Operator の更新
ClusterGroupUpdate
CR の内容をcgu-platform-operator-upgrade.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
cgu-platform-operator-upgrade.yml
ファイルをハブクラスターに適用します。oc apply -f cgu-platform-operator-upgrade.yml
$ oc apply -f cgu-platform-operator-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: プラットフォームおよび Operator の更新用にイメージを事前キャッシュします。
以下のコマンドを実行して、
ClusterGroupUpgrade
CR で事前キャッシュを有効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
oc get jobs,pods -n openshift-talm-pre-cache
$ oc get jobs,pods -n openshift-talm-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。
oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
$ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プラットフォームおよび Operator の更新を開始します。
以下のコマンドを実行して、
cgu-du-upgrade
ClusterGroupUpgrade
CR がプラットフォームと Operator の更新を開始します。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記プラットフォームおよび Operator 更新の CR は、設定を
spec.enable: true
に設定して最初から作成できます。この場合、更新は事前キャッシュが完了した直後に開始し、CR を手動で有効にする必要はありません。事前キャッシュと更新の両方で、ポリシー、配置バインディング、配置ルール、マネージドクラスターアクション、マネージドクラスタービューなどの追加リソースが作成され、手順を完了することができます。
afterCompletion.deleteObjects
フィールドをtrue
に設定すると、更新の完了後にこれらのリソースがすべて削除されます。
9.3.6. PolicyGenerator CR を使用したデプロイされたクラスターからの Performance Addon Operator サブスクリプションの削除 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの OpenShift Container Platform では、Performance Addon Operator はアプリケーションの自動低レイテンシーパフォーマンスチューニングを提供していました。OpenShift Container Platform 4.11 以降では、これらの機能は Node Tuning Operator の一部です。
OpenShift Container Platform 4.11 以降を実行しているクラスターに Performance Addon Operator をインストールしないでください。OpenShift Container Platform 4.11 以降にアップグレードすると、Node Tuning Operator は Performance Addon Operator を自動的に削除します。
Operator の再インストールを防ぐために、Performance Addon Operator サブスクリプションを作成するポリシーを削除する必要があります。
参照 DU プロファイルには、PolicyGenerator
CR acm-common-ranGen.yaml
の Performance Addon Operator が含まれています。デプロイされたマネージドクラスターからサブスクリプションを削除するには、acm-common-ranGen.yaml
を更新する必要があります。
Performance Addon Operator 4.10.3-5 以降を OpenShift Container Platform 4.11 以降にインストールする場合、Performance Addon Operator はクラスターのバージョンを検出し、Node Tuning Operator 機能との干渉を避けるために自動的に休止状態になります。ただし、最高のパフォーマンスを確保するには、OpenShift Container Platform 4.11 クラスターから Performance Addon Operator を削除してください。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、ArgoCD のソースリポジトリーとして定義されている必要があります。
- OpenShift Container Platform 4.11 以降に更新します。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
acm-common-ranGen.yaml
ファイルの Performance Addon Operator namespace、Operator グループ、およびサブスクリプションのcomplianceType
をmustnothave
に変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。
common-subscriptions-policy
ポリシーのステータスがNon-Compliant
に変わります。 - Topology Aware Lifecycle Manager を使用して、ターゲットクラスターに変更を適用します。設定変更のロールアウトの詳細は、「関連情報」セクションを参照してください。
プロセスを監視します。ターゲットクラスターの
common-subscriptions-policy
ポリシーのステータスがCompliant
の場合、Performance Addon Operator はクラスターから削除されています。次のコマンドを実行して、common-subscriptions-policy
のステータスを取得します。oc get policy -n ztp-common common-subscriptions-policy
$ oc get policy -n ztp-common common-subscriptions-policy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
acm-common-ranGen.yaml
ファイルのpolicies.manifests
から、Performance Addon Operator namespace、Operator グループ、およびサブスクリプション CR を削除します。 - 変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。ポリシーは準拠したままです。
9.3.7. シングルノード OpenShift クラスター上の TALM を使用したユーザー指定のイメージの事前キャッシュ リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションをアップグレードする前に、アプリケーション固有のワークロードイメージをシングルノード OpenShift クラスターに事前キャッシュできます。
次のカスタムリソース (CR) を使用して、事前キャッシュジョブの設定オプションを指定できます。
-
PreCachingConfig
CR -
ClusterGroupUpgrade
CR
PreCachingConfig
CR のフィールドはすべてオプションです。
PreCachingConfig CR の例
- 1
- デフォルトでは、TALM は、マネージドクラスターのポリシーから
platformImage
、operatorsIndexes
、およびoperatorsPackagesAndChannels
フィールドに自動的に値を設定します。これらのフィールドのデフォルトの TALM 派生値をオーバーライドする値を指定できます。 - 2
- クラスター上で最低限必要なディスク容量を指定します。指定しない場合、TALM は OpenShift Container Platform イメージのデフォルト値を定義します。ディスク容量フィールドには、整数値とストレージユニットを含める必要があります。たとえば、
40 GiB
、200 MB
、1 TiB
です。 - 3
- イメージ名の一致に基づいて事前キャッシュから除外するイメージを指定します。
- 4
- 事前キャッシュする追加イメージのリストを指定します。
PreCachingConfig CR 参照を使用した ClusterGroupUpgrade CR の例
9.3.7.1. 事前キャッシュ用のカスタムリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
PreCachingConfig
CR は、ClusterGroupUpgrade
CR の前または同時に作成する必要があります。
事前キャッシュする追加イメージのリストを使用して
PreCachingConfig
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow preCaching
フィールドをtrue
に設定してClusterGroupUpgrade
CR を作成し、前の手順で作成したPreCachingConfig
CR を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告クラスターにイメージをインストールすると、それらを変更したり削除したりすることはできません。
イメージを事前キャッシュを開始する場合は、次のコマンドを実行して
ClusterGroupUpgrade
CR を適用します。oc apply -f cgu.yaml
$ oc apply -f cgu.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TALM は ClusterGroupUpgrade
CR を検証します。
この時点から、TALM 事前キャッシュワークフローを続行できます。
すべてのサイトが同時に事前キャッシュされます。
検証
次のコマンドを実行して、
ClusterUpgradeGroup
CR が適用されているハブクラスターの事前キャッシュステータスを確認します。oc get cgu <cgu_name> -n <cgu_namespace> -oyaml
$ oc get cgu <cgu_name> -n <cgu_namespace> -oyaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 事前キャッシュ設定は、管理ポリシーが存在するかどうかをチェックすることによって検証されます。
ClusterGroupUpgrade
およびPreCachingConfig
CR の設定が有効であると、次のステータスになります。有効な CR の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 無効な PreCachingConfig CR の例
Type: "PrecacheSpecValid" Status: False, Reason: "PrecacheSpecIncomplete" Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"
Type: "PrecacheSpecValid" Status: False, Reason: "PrecacheSpecIncomplete" Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターで次のコマンドを実行すると、事前キャッシュジョブを見つけることができます。
oc get jobs -n openshift-talo-pre-cache
$ oc get jobs -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 進行中の事前キャッシュジョブの例
NAME COMPLETIONS DURATION AGE pre-cache 0/1 1s 1s
NAME COMPLETIONS DURATION AGE pre-cache 0/1 1s 1s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、事前キャッシュジョブ用に作成された Pod のステータスを確認できます。
oc describe pod pre-cache -n openshift-talo-pre-cache
$ oc describe pod pre-cache -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 進行中の事前キャッシュジョブの例
Type Reason Age From Message Normal SuccesfulCreate 19s job-controller Created pod: pre-cache-abcd1
Type Reason Age From Message Normal SuccesfulCreate 19s job-controller Created pod: pre-cache-abcd1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行すると、ジョブのステータスに関するライブ更新を取得できます。
oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
$ oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 事前キャッシュジョブが正常に完了したことを確認するには、次のコマンドを実行します。
oc describe pod pre-cache -n openshift-talo-pre-cache
$ oc describe pod pre-cache -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 完了した事前キャッシュジョブの例
Type Reason Age From Message Normal SuccesfulCreate 5m19s job-controller Created pod: pre-cache-abcd1 Normal Completed 19s job-controller Job completed
Type Reason Age From Message Normal SuccesfulCreate 5m19s job-controller Created pod: pre-cache-abcd1 Normal Completed 19s job-controller Job completed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージがシングルノード OpenShift で正常に事前キャッシュされていることを確認するには、次の手順を実行します。
デバッグモードでノードに入ります。
oc debug node/cnfdf00.example.lab
$ oc debug node/cnfdf00.example.lab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow root を
host
に変更します。chroot /host/
$ chroot /host/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 目的のイメージを検索します。
sudo podman images | grep <operator_name>
$ sudo podman images | grep <operator_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3.8. GitOps ZTP 用に自動作成された ClusterGroupUpgrade CR について リンクのコピーリンクがクリップボードにコピーされました!
TALM には、ManagedClusterForCGU
と呼ばれるコントローラーがあります。このコントローラーは、ハブクラスター上で ManagedCluster
CR の Ready
状態を監視し、GitOps Zero Touch Provisioning (ZTP) の ClusterGroupUpgrade
CR を作成します。
ztp-done
ラベルが適用されていない Ready
状態のマネージドクラスターの場合、ManagedClusterForCGU
コントローラーは、ztp-install
namespace に ClusterGroupUpgrade
CR と、GitOps ZTP プロセス中に作成された関連する RHACM ポリシーを自動的に作成します。次に TALM は自動作成された ClusterGroupUpgrade
CR に一覧表示されている設定ポリシーのセットを修復し、設定 CR をマネージドクラスターにプッシュします。
クラスターが Ready
になった時点でマネージドクラスターのポリシーがない場合、ポリシーのない ClusterGroupUpgrade
CR が作成されます。ClusterGroupUpgrade
が完了すると、マネージドクラスターには ztp-done
というラベルが付けられます。そのマネージドクラスターに適用するポリシーがある場合は、2 日目の操作として ClusterGroupUpgrade
を手動で作成します。
GitOps ZTP 用に自動作成された ClusterGroupUpgrade
CR の例
第10章 PolicyGenTemplate リソースを使用したクラスターポリシーの管理 リンクのコピーリンクがクリップボードにコピーされました!
10.1. PolicyGenTemplate リソースを使用したマネージドクラスターポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
適用された Policy
カスタムリソース (CR) は、プロビジョニングするマネージドクラスターを設定します。Red Hat Advanced Cluster Management (RHACM) が PolicyGenTemplate
CR を使用して適用された Policy
CR を生成する方法をカスタマイズできます。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
10.1.1. PolicyGenTemplate CRD について リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenTemplate
カスタムリソース定義 (CRD) は、PolicyGen
ポリシージェネレーターに、どのカスタムリソース (CR) をクラスター設定に含めるか、CR を生成されたポリシーに結合する方法、およびこれらの CR 内のどのアイテムをオーバーレイコンテンツで更新する必要があるかを伝えます。
次の例は、ztp-site-generate
参照コンテナーから抽出された PolicyGenTemplate
CR (common-du-ranGen.yaml
) を示しています。common-du-ranGen.yaml
ファイルは、2 つの Red Hat Advanced Cluster Management (RHACM) ポリシーを定義します。ポリシーは、CR 内の policyName
の一意の値ごとに 1 つずつ、設定 CR のコレクションを管理します。common-du-ranGen.yaml
は、単一の配置バインディングと配置ルールを作成して、spec.bindingRules
セクションにリストされているラベルに基づいてポリシーをクラスターにバインドします。
PolicyGenTemplate CR の例 - common-ranGen.yaml
- 1
common: "true"
は、このラベルを持つすべてのクラスターにポリシーを適用します。- 2
sourceFiles
の下にリストされているファイルは、インストールされたクラスターの Operator ポリシーを作成します。- 3
DefaultCatsrc.yaml
は、切断されたレジストリーのカタログソースを設定します。- 4
policyName: "config-policy"
は、Operator サブスクリプションを設定します。OperatorHub
CR はデフォルトを無効にし、この CR はredhat-operators
を切断されたレジストリーを指すCatalogSource
CR に置き換えます。
PolicyGenTemplate
CR は、任意の数の組み込み CR で設定できます。次の例の CR をハブクラスターに適用して、単一の CR を含むポリシーを生成します。
ソースファイル PtpConfigSlave.yaml
を例として使用すると、ファイルは PtpConfig
CR を定義します。PtpConfigSlave
サンプルの生成ポリシーは group-du-sno-config-policy
という名前です。生成された group-du-sno-config-policy
に定義される PtpConfig
CR は du-ptp-slave
という名前です。PtpConfigSlave.yaml
で定義された spec
は、du-ptp-slave
の下に、ソースファイルで定義された他の spec
項目と共に配置されます。
次の例は、group-du-sno-config-policy
CR を示しています。
10.1.2. PolicyGenTemplate CR をカスタマイズする際の推奨事項 リンクのコピーリンクがクリップボードにコピーされました!
サイト設定の PolicyGenTemplate
カスタムリソース (CR) をカスタマイズするときは、次のベストプラクティスを考慮してください。
-
必要な数のポリシーを使用します。使用するポリシーが少ないほど、必要なリソースが少なくなります。追加のポリシーごとに、ハブクラスターとデプロイされたマネージドクラスターの CPU 負荷が増加します。CR は
PolicyGenTemplate
CR のpolicyName
フィールドに基づいてポリシーに統合されます。policyName
に同じ値を持つ同じPolicyGenTemplate
の CR は単一のポリシーで管理されます。 -
非接続環境では、すべての Operator を含む単一のインデックスとしてレジストリーを設定することにより、すべての Operator に対して単一のカタログソースを使用します。マネージドクラスターに
CatalogSource
CR を追加するたびに、CPU 使用率が増加します。 -
MachineConfig
CR は、インストール時に適用されるようにSiteConfig
CR にextraManifests
として組み込む必要があります。これにより、クラスターがアプリケーションをデプロイする準備ができるまで全体的な時間がかかる可能性があります。 -
PolicyGenTemplate
CR は、チャネルフィールドをオーバーライドして、目的のバージョンを明示的に識別する必要があります。これにより、アップグレード時にソース CR が変更されても、生成されたサブスクリプションが更新されないようになります。
ハブクラスターで多数のスポーククラスターを管理する場合は、ポリシーの数を最小限に抑えてリソースの消費を減らします。
複数のコンフィギュレーション CR を 1 つまたは限られた数のポリシーにグループ化することは、ハブクラスター上のポリシーの総数を減らすための 1 つの方法です。サイト設定の管理に common、group、および site というポリシーの階層を使用する場合は、サイト固有の設定を 1 つのポリシーにまとめることが特に重要です。
10.1.3. RAN デプロイメントの PolicyGenTemplate CR リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenTemplate
カスタムリソース (CR) を使用し、GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してクラスターに適用される設定をカスタマイズします。PolicyGenTemplate
CR を使用すると、クラスター群の設定 CR のセットを管理するための 1 つ以上のポリシーを生成できます。PolicyGenTemplate
CR は、マネージド CR のセットを識別し、それらをポリシーにバンドルして、それらの CR をラップするポリシーをビルドし、ラベルバインディングルールを使用してポリシーをクラスターに関連付けます。
GitOps ZTP コンテナーから取得した参照設定は、RAN (Radio Access Network) 分散ユニット (DU) アプリケーションに典型的な厳しいパフォーマンスとリソース利用制約をクラスターが確実にサポートできるように、重要な機能とノードのチューニング設定のセットを提供するように設計されています。ベースライン設定の変更または省略は、機能の可用性、パフォーマンス、およびリソースの利用に影響を与える可能性があります。参照 PolicyGenTemplate
CR をベースに、お客様のサイト要件に合わせた設定ファイルの階層を作成します。
RAN DU クラスター設定に定義されているベースライン PolicyGenTemplate
CR は、GitOps ZTP ztp-site-generate
コンテナーから抽出することが可能です。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。
PolicyGenTemplate
の CR は、./out/argocd/example/policygentemplates
フォルダーに格納されています。参照アーキテクチャーには、common、group、および site 固有の設定 CR があります。各 PolicyGenTemplate
CR は ./out/source-crs
フォルダーにある他の CR を参照します。
RAN クラスター設定に関連する PolicyGenTemplate
CR は以下で説明されています。バリアントは、シングルノード、3 ノードのコンパクト、および標準のクラスター設定の相違点に対応するために、グループ PolicyGenTemplate
CR に提供されます。同様に、シングルノードクラスターとマルチノード (コンパクトまたはスタンダード) クラスターにも、サイト固有の設定バリエーションが提供されています。デプロイメントに関連するグループおよびサイト固有の設定バリアントを使用します。
PolicyGenTemplate CR | 説明 |
---|---|
| マルチノードクラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。 |
| シングルノード OpenShift クラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。 |
| マルチノードクラスターに適用される共通の RAN ポリシー設定のセットが含まれています。 |
| すべてのクラスターに適用される共通の RAN CR のセットが含まれています。これらの CR は、RAN の典型的なクラスター機能とベースラインクラスターのチューニングを提供する Operator のセットをサブスクライブします。 |
| 3 ノードクラスター用の RAN ポリシーのみが含まれています。 |
| シングルノードクラスター用の RAN ポリシーのみが含まれています。 |
| 標準的な 3 つのコントロールプレーンクラスターの RAN ポリシーが含まれています。 |
|
|
|
標準クラスターに必要なさまざまなポリシーを生成するために使用される |
|
|
10.1.4. PolicyGenTemplate CR を使用したマネージドクラスターのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
次の手順を使用して、GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してプロビジョニングするマネージドクラスターに適用されるポリシーをカスタマイズします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
サイト固有の設定 CR の
PolicyGenTemplate
CR を作成します。-
CR の適切な例を
out/argocd/example/policygentemplates
フォルダーから選択します (example-sno-site.yaml
またはexample-multinode-site.yaml
)。 サンプルファイルの
spec.bindingRules
フィールドを、SiteConfig
CR に含まれるサイト固有のラベルと一致するように変更します。サンプルのSiteConfig
ファイルでは、サイト固有のラベルはsites: example-sno
です。注記PolicyGenTemplate
spec.bindingRules
フィールドで定義されているラベルが、関連するマネージドクラスターのSiteConfig
CR で定義されているラベルに対応していることを確認します。- サンプルファイルの内容を目的の設定に合わせて変更します。
-
CR の適切な例を
オプション: クラスターのフリート全体に適用される一般的な設定 CR の
PolicyGenTemplate
CR を作成します。-
out/argocd/example/policygentemplates
フォルダーから CR の適切な例を選択します (例:common-ranGen.yaml)
。 - 必要な設定に合わせてサンプルファイルの内容を変更します。
-
オプション: フリート内のクラスターの特定のグループに適用されるグループ設定 CR の
PolicyGenTemplate
CR を作成します。オーバーレイド仕様ファイルの内容が必要な終了状態と一致することを確認します。参考までに、
out/source-crs
ディレクトリーには、PolicyGenTemplate テンプレートで含めたりオーバーレイしたりできる source-crs の完全なリストが含まれています。注記クラスターの特定の要件に応じて、クラスターのタイプごとに 1 つ以上のグループポリシーが必要になる場合があります。特に、サンプルのグループポリシーにはそれぞれ単一の
PerformancePolicy.yaml
ファイルがあり、それらのクラスターが同一のハードウェア設定で構成されている場合にのみ、クラスターのセット全体で共有できることを考慮すると、これが当てはまります。-
out/argocd/example/policygentemplates
フォルダーから CR の適切な例を選択します (例:group-du-sno-ranGen.yaml
)。 - 必要な設定に合わせてサンプルファイルの内容を変更します。
-
-
オプション: GitOps ZTP のインストールとデプロイされたクラスターの設定が完了したときに通知するバリデータ通知ポリシー
PolicyGenTemplate
CR を作成します。詳細は、「バリデーター通知ポリシーの作成」を参照してください。 out/argocd/example/policygentemplates/ns.yaml
ファイルの例と同様の YAML ファイルで、すべてのポリシーの namespace を定義してください。重要Namespace
CR をPolicyGenTemplate
CR と同じファイルに含めないでください。-
out/argocd/example/policygentemplateskustomization.yaml
で示す例と同様に、PolicyGenTemplate
CR とNamespace
CR を、ジェネレーターセクションのkustomization.yaml
ファイルに追加します。 PolicyGenTemplate
CR、Namespace
CR、および関連するkustomization.yaml
ファイルを Git リポジトリーにコミットし、変更をプッシュします。ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。
SiteConfig
CR とPolicyGenTemplate
CR に同時に変更をプッシュすることができます。
10.1.5. マネージドクラスターポリシーのデプロイメントの進行状況の監視 リンクのコピーリンクがクリップボードにコピーされました!
ArgoCD パイプラインは、Git の PolicyGenTemplate
CR を使用して RHACM ポリシーを生成し、ハブクラスターに同期します。アシストサービスによってマネージドクラスターに OpenShift Container Platform がインストールされた後、マネージドクラスターのポリシー同期の進行状況を監視できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
Topology Aware Lifecycle Manager (TALM) は、クラスターにバインドされている設定ポリシーを適用します。
クラスターのインストールが完了し、クラスターが
Ready
になると、ran.openshift.io/ztp-deploy-wave
アノテーションで定義された順序付きポリシーのリストで、このクラスターに対応するClusterGroupUpgrade
CR が TALM により自動的に作成されます。クラスターのポリシーは、ClusterGroupUpgrade
CR に記載されている順序で適用されます。以下のコマンドを使用して、設定ポリシー調整のハイレベルの進捗を監視できます。
export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq
$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM ダッシュボードまたはコマンドラインを使用して、詳細なクラスターポリシーのコンプライアンスステータスを監視できます。
oc
を使用してポリシーのコンプライアンスを確認するには、次のコマンドを実行します。oc get policies -n $CLUSTER
$ oc get policies -n $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM Web コンソールからポリシーのステータスを確認するには、次のアクションを実行します。
- ガバナンス → ポリシーの検索 をクリックします。
- クラスターポリシーをクリックして、ステータスを確認します。
すべてのクラスターポリシーが準拠すると、クラスターの GitOps ZTP のインストールと設定が完了します。ztp-done
ラベルがクラスターに追加されます。
参照設定では、準拠する最終的なポリシーは、*-du-validator-policy
ポリシーで定義されたものです。このポリシーは、クラスターに準拠する場合、すべてのクラスター設定、Operator のインストール、および Operator 設定が完了します。
10.1.6. 設定ポリシー CR の生成の検証 リンクのコピーリンクがクリップボードにコピーされました!
Policy
カスタムリソース (CR) は、作成元の PolicyGenTemplate
と同じ namespace に生成されます。以下のコマンドを使用して示すように、ztp-common
、ztp-group
、または ztp-site
ベースのいずれであるかにかかわらず、PolicyGenTemplate
から生成されたすべてのポリシー CR に同じトラブルシューティングフローが適用されます。
export NS=<namespace>
$ export NS=<namespace>
oc get policy -n $NS
$ oc get policy -n $NS
予想される policy-wrapped CR のセットが表示されるはずです。
ポリシーの同期に失敗した場合は、以下のトラブルシューティング手順を使用します。
手順
ポリシーの詳細情報を表示するには、次のコマンドを実行します。
oc describe -n openshift-gitops application policies
$ oc describe -n openshift-gitops application policies
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Status: Conditions:
の有無を確認し、エラーログを表示します。たとえば、無効なsourceFile
エントリーをfileName:
に設定すると、以下次に示すエラーが生成されます。Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1 Type: ComparisonError
Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1 Type: ComparisonError
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Status: Sync:
をチェックします。Status: Conditions:
: でログエラーが発生した場合Status: Sync:
にUnknown
またはError
と表示されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Advanced Cluster Management (RHACM) が
ManagedCluster
オブジェクトにポリシーが適用されることを認識すると、ポリシー CR オブジェクトがクラスターネームスペースに適用されます。ポリシーがクラスターネームスペースにコピーされたかどうかを確認します。oc get policy -n $CLUSTER
$ oc get policy -n $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM は、適用可能なすべてのポリシーをクラスターの namespace にコピーします。コピーされたポリシー名の形式は、
<PolicyGenTemplate.Namespace>.<PolicyGenTemplate.Name>-<policyName>
です。クラスター namespace にコピーされないポリシーの配置ルールを確認します。これらのポリシーの
PlacementRule
のmatchSelector
、ManagedCluster
オブジェクトのラベルと一致する必要があります。oc get PlacementRule -n $NS
$ oc get PlacementRule -n $NS
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PlacementRule
名は、以下のコマンドを使用して、不足しているポリシー (common、group、または site) に適した名前であることに注意してください。oc get PlacementRule -n $NS <placement_rule_name> -o yaml
$ oc get PlacementRule -n $NS <placement_rule_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - status-decisions にはクラスター名が含まれている必要があります。
-
spec の
matchSelector
の key-value ペアは、マネージドクラスター上のラベルと一致する必要があります。
以下のコマンドを使用して、
ManagedCluster
オブジェクトのラベルを確認します。oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
$ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、どのポリシーが準拠しているかを確認します。
oc get policy -n $CLUSTER
$ oc get policy -n $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Namespace
、OperatorGroup
、およびSubscription
ポリシーが準拠しているが Operator 設定ポリシーが該当しない場合、Operator はマネージドクラスターにインストールされていない可能性があります。このため、スポークに CRD がまだ適用されていないため、Operator 設定ポリシーの適用に失敗します。
10.1.7. ポリシー調整の再開 リンクのコピーリンクがクリップボードにコピーされました!
たとえば、ClusterGroupUpgrade
カスタムリソース (CR) がタイムアウトした場合など、予期しないコンプライアンスの問題が発生した場合は、ポリシー調整を再開できます。
手順
ClusterGroupUpgrade
CR は、管理クラスターの状態がReady
になった後に Topology Aware Lifecycle Manager によって namespaceztp-install
に生成されます。export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clustergroupupgrades -n ztp-install $CLUSTER
$ oc get clustergroupupgrades -n ztp-install $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 予期せぬ問題が発生し、設定されたタイムアウト (デフォルトは 4 時間) 内にポリシーが苦情にならなかった場合、
ClusterGroupUpgrade
CR のステータスはUpgradeTimedOut と
表示されます。oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow UpgradeTimedOut
状態のClusterGroupUpgrade
CR は、1 時間ごとにポリシー照合を自動的に再開します。ポリシーを変更した場合は、既存のClusterGroupUpgrade
CR を削除して再試行をすぐに開始できます。これにより、ポリシーをすぐに調整する新規ClusterGroupUpgrade
CR の自動作成がトリガーされます。oc delete clustergroupupgrades -n ztp-install $CLUSTER
$ oc delete clustergroupupgrades -n ztp-install $CLUSTER
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ClusterGroupUpgrade
CR が UpgradeCompleted
ステータスで完了し、マネージドクラスターに ztp-done
ラベルが適用されている場合は、PolicyGenTemplate
を使用して追加の設定変更が可能な点に注意してください。既存の ClusterGroupUpgrade
CR を削除しても、TALM は新規 CR を生成しません。
この時点で、GitOps ZTP はクラスターとの対話を完了しました。それ以降の対話は更新として扱われ、ポリシーの修復のために新しい ClusterGroupUpgrade
CR が作成されます。
10.1.8. ポリシーを使用して適用済みマネージドクラスター CR を変更する リンクのコピーリンクがクリップボードにコピーされました!
ポリシーを使用して、マネージドクラスターにデプロイされたカスタムリソース (CR) からコンテンツを削除できます。
PolicyGenTemplate
CR から作成されたすべての Policy
CR は、complianceType
フィールドがデフォルトで musthave
に設定されています。マネージドクラスター上の CR には指定されたコンテンツがすべて含まれているため、コンテンツが削除されていない musthave
ポリシーは依然として準拠しています。この設定では、CR からコンテンツを削除すると、TALM はポリシーからコンテンツを削除しますが、そのコンテンツはマネージドクラスター上の CR からは削除されません。
complianceType
フィールドを mustonlyhave
に設定することで、ポリシーはクラスター上の CR がポリシーで指定されている内容と完全に一致するようにします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - RHACM を実行しているハブクラスターからマネージドクラスターをデプロイしている。
- ハブクラスターに Topology Aware Lifecycle Manager がインストールされている。
手順
影響を受ける CR から不要になったコンテンツを削除します。この例では、
SriovOperatorConfig
CR からdisableDrain: false
行が削除されました。CR の例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow group-du-sno-ranGen.yaml
ファイル内で、影響を受けるポリシーのcomplianceType
をmustonlyhave
に変更します。サンプル YAML
- fileName: SriovOperatorConfig.yaml policyName: "config-policy" complianceType: mustonlyhave
- fileName: SriovOperatorConfig.yaml policyName: "config-policy" complianceType: mustonlyhave
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ClusterGroupUpdates
CR を作成し、CR の変更を受け取る必要があるクラスターを指定します。ClusterGroupUpdates CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
ClusterGroupUpgrade
CR を作成します。oc create -f cgu-remove.yaml
$ oc create -f cgu-remove.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば適切なメンテナンス期間中などに変更を適用する準備が完了したら、次のコマンドを実行して
spec.enable
フィールドの値をtrue
に変更します。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行してポリシーのステータスを確認します。
oc get <kind> <changed_cr_name>
$ oc get <kind> <changed_cr_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーの
COMPLIANCE STATE
がCompliant
の場合、CR が更新され、不要なコンテンツが削除されたことを意味します。マネージドクラスターで次のコマンドを実行して、対象クラスターからポリシーが削除されたことを確認します。
oc get <kind> <changed_cr_name>
$ oc get <kind> <changed_cr_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果がない場合、CR はマネージドクラスターから削除されます。
10.1.9. GitOps ZTP インストール完了の表示 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) は、クラスターの GitOps ZTP インストールステータスを確認するプロセスを単純化します。GitOps ZTP ステータスは、クラスターのインストール、クラスター設定、GitOps ZTP 完了の 3 つのフェーズを遷移します。
- クラスターインストールフェーズ
-
クラスターのインストールフェーズは、
ManagedCluster
CR のManagedClusterJoined
およびManagedClusterAvailable
条件によって示されます。ManagedCluster
CR にこの条件がない場合や、条件がFalse
に設定されている場合、クラスターはインストールフェーズに残ります。インストールに関する追加情報は、AgentClusterInstall
およびClusterDeployment
CR から入手できます。詳細は、「GitOps ZTP のトラブルシューティング」を参照してください。 - クラスター設定フェーズ
-
クラスター設定フェーズは、クラスターの
ManagedCluster
CR に適用されるztp-running
ラベルで示されます。 - GitOps ZTP 完了
クラスターのインストールと設定は、GitOps ZTP 完了フェーズで実行されます。これは、
ztp-running
ラベルを削除し、ManagedCluster
CR にztp-done
ラベルを追加することで表示されます。ztp-done
ラベルは、設定が適用され、ベースライン DU 設定が完了したことを示しています。GitOps ZTP 完了状態への変更は、Red Hat Advanced Cluster Management (RHACM) バリデーター通知ポリシーの準拠状態が条件となります。このポリシーは、完了したインストールの既存の基準をキャプチャし、マネージドクラスターの GitOps ZTP プロビジョニングが完了したときにのみ、準拠した状態に移行することを検証するものです。
バリデータ通知ポリシーは、クラスターの設定が完全に適用され、Operator が初期化を完了したことを確認します。ポリシーは以下を検証します。
-
ターゲット
MachineConfigPool
には予想されるエントリーが含まれ、更新が完了しました。全ノードが利用可能で、低下することはありません。 -
SR-IOV Operator は、
syncStatus: Succeeded
の 1 つ以上のSriovNetworkNodeState
によって示されているように初期化を完了しています。 - PTP Operator デーモンセットが存在する。
-
ターゲット
10.2. PolicyGenTemplate リソースを使用した高度なマネージドクラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenTemplate
CR を使用して、マネージドクラスターにカスタム機能をデプロイできます。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
10.2.1. 追加の変更のクラスターへのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
基本の GitOps Zero Touch Provisioning (ZTP) パイプライン設定以外のクラスター設定を変更する必要がある場合、次の 3 つのオプションを実行できます。
- GitOps ZTP パイプラインの完了後に追加設定を適用する
- GitOps ZTP パイプラインのデプロイが完了すると、デプロイされたクラスターはアプリケーションのワークロードに対応できるようになります。この時点で、Operator を追加インストールし、お客様の要件に応じた設定を適用することができます。追加のコンフィギュレーションがプラットフォームのパフォーマンスや割り当てられた CPU バジェットに悪影響を与えないことを確認する。
- GitOps ZTP ライブラリーにコンテンツを追加する
- GitOps ZTP パイプラインでデプロイするベースソースのカスタムリソース (CR) は、必要に応じてカスタムコンテンツで拡張できます。
- クラスターインストール用の追加マニフェストの作成
- インストール時に余分なマニフェストが適用され、インストール作業を効率化することができます。
追加のソース CR を提供したり、既存のソース CR を変更したりすると、OpenShift Container Platform のパフォーマンスまたは CPU プロファイルに大きな影響を与える可能性があります。
10.2.2. PolicyGenTemplate CR を使用して、ソース CR の内容を上書きする。 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenTemplate
カスタムリソース (CR) を使用すると、ztp-site-generate
コンテナーの GitOps プラグインで提供されるベースソース CR の上に追加の設定の詳細をオーバーレイできます。PolicyGenTemplate
CR は、ベース CR の論理マージまたはパッチとして解釈できます。PolicyGenTemplate
CR を使用して、ベース CR の単一フィールドを更新するか、ベース CR の内容全体をオーバーレイします。ベース CR にない値の更新やフィールドの挿入が可能です。
以下の手順例では、group-du-sno-ranGen.yaml
ファイル内の PolicyGenTemplate
CR に基づいて、参照設定用に生成された PerformanceProfile
CR のフィールドを更新する方法を説明します。この手順を元に、PolicyGenTemplate
の他の部分をお客様のご要望に応じて変更してください。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。
手順
既存のコンテンツのベースラインソース CR を確認します。参照
PolicyGenTemplate
CR に記載されているソース CR を GitOps Zero Touch Provisioning (ZTP) コンテナーから抽出し、確認すできます。/out
フォルダーを作成します。mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ソース CR を抽出します。
podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18.1 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18.1 extract /home/ztp --tar | tar x -C ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
./out/source-crs/PerformanceProfile.yaml
にあるベースラインPerformanceProfile
CR を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ソース CR のフィールドで
$...
を含むものは、PolicyGenTemplate
CR で提供されない場合、生成された CR から削除されます。group-du-sno-ranGen.yaml
リファレンスファイルのPerformanceProfile
のPolicyGenTemplate
エントリーを更新します。次の例のPolicyGenTemplate
CR スタンザは、適切な CPU 仕様を提供し、hugepages
設定を設定し、globallyDisableIrqLoadBalancing
を false に設定する新しいフィールドを追加しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git で
PolicyGenTemplate
変更をコミットし、GitOps ZTP argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。出力例
GitOps ZTP アプリケーションは、生成された
PerformanceProfile
CR を含む RHACM ポリシーを生成します。この CR の内容は、PolicyGenTemplate
のPerformanceProfile
エントリーからmetadata
とspec
の内容をソース CR にマージすることで生成されます。作成される CR には以下のコンテンツが含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ztp-site-generate
コンテナーからデプロイメントした /source-crs
フォルダーでは、$
構文が暗示するテンプレート置換は使用されません。むしろ、policyGen
ツールが文字列の $
接頭辞を認識し、関連する PolicyGenTemplate
CR でそのフィールドの値を指定しない場合、そのフィールドは出力 CR から完全に省かれます。
例外として、/source-crs
YAML ファイル内の $mcp
変数は、PolicyGenTemplate
CR から mcp
の指定値で代用されます。たとえば、example/policygentemplates/group-du-standard-ranGen.yaml
では、mcp
の値は worker
となっています。
spec: bindingRules: group-du-standard: "" mcp: "worker"
spec:
bindingRules:
group-du-standard: ""
mcp: "worker"
policyGen
ツールは、$mcp
のインスタンスを出力 CR の worker
に置き換えます。
10.2.3. GitOps ZTP パイプラインへのカスタムコンテンツの追加 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP パイプラインに新しいコンテンツを追加するには、次の手順を実行します。
手順
-
PolicyGenTemplate
カスタムリソース (CR) のkustomization.yaml
ファイルが含まれるディレクトリーに、source-crs
という名前のサブディレクトリーを作成します。 次の例に示すように、ユーザー提供の CR を
source-crs
サブディレクトリーに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
source-crs
サブディレクトリーは、kustomization.yaml
ファイルと同じディレクトリーにある必要があります。
必要な
PolicyGenTemplate
CR を更新して、source-crs/custom-crs
およびsource-crs/elasticsearch
ディレクトリーに追加したコンテンツへの参照を含めます。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenTemplate
の変更をコミットし、GitOps ZTP Argo CD ポリシーアプリケーションが監視する Git リポジトリーにプッシュします。 ClusterGroupUpgrade
CR を更新して、変更されたPolicyGenTemplate
を含め、cgu-test.yaml
として保存します。次の例は、生成されたcgu-test.yaml
ファイルを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、更新された
ClusterGroupUpgrade
CR を適用します。oc apply -f cgu-test.yaml
$ oc apply -f cgu-test.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、更新が成功したことを確認します。
oc get cgu -A
$ oc get cgu -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2.4. PolicyGenTemplate CR のポリシーコンプライアンス評価タイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
ハブクラスターにインストールされた Red Hat Advanced Cluster Management (RHACM) を使用して、マネージドクラスターが適用されたポリシーに準拠しているかどうかを監視および報告します。RHACM は、ポリシーテンプレートを使用して、定義済みのポリシーコントローラーとポリシーを適用します。ポリシーコントローラーは Kubernetes のカスタムリソース定義 (CRD) インスタンスです。
デフォルトのポリシー評価間隔は、PolicyGenTemplate
カスタムリソース (CR) でオーバーライドできます。RHACM が適用されたクラスターポリシーを再評価する前に、ConfigurationPolicy
CR がポリシー準拠または非準拠の状態を維持できる期間を定義する期間設定を設定します。
GitOps Zero Touch Provisioning (ZTP) ポリシージェネレーターは、事前定義されたポリシー評価間隔で ConfigurationPolicy
CR ポリシーを生成します。noncompliant
状態のデフォルト値は 10 秒です。compliant
状態のデフォルト値は 10 分です。評価間隔を無効にするには、値を never
に設定します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
PolicyGenTemplate
CR 内のすべてのポリシーの評価間隔を設定するには、evaluationInterval
フィールドに適切なcompliant
値とnoncompliant
値を設定します。以下に例を示します。spec: evaluationInterval: compliant: 30m noncompliant: 20s
spec: evaluationInterval: compliant: 30m noncompliant: 20s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記また、
compliant
フィールドとnoncompliant
フィールドをnever
に設定して、特定の準拠状態に達した後にポリシーの評価を停止することもできます。PolicyGenTemplate
CR 内の個々のポリシーオブジェクトの評価間隔を設定するには、evaluationInterval
フィールドを追加し、適切な値を設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
PolicyGenTemplate
CR ファイルを Git リポジトリーにコミットし、変更をプッシュします。
検証
マネージドスポーククラスターポリシーが予想される間隔で監視されていることを確認します。
-
マネージドクラスターで
cluster-admin
権限を持つユーザーとしてログインします。 open-cluster-management-agent-addon
namespace で実行されている Pod を取得します。以下のコマンドを実行します。oc get pods -n open-cluster-management-agent-addon
$ oc get pods -n open-cluster-management-agent-addon
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow config-policy-controller
Pod のログで、適用されたポリシーが予想される間隔で評価されていることを確認します。oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb
$ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}
2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2.5. バリデーターインフォームポリシーを使用した GitOps ZTP クラスターデプロイメントの完了のシグナリング リンクのコピーリンクがクリップボードにコピーされました!
デプロイされたクラスターの GitOps Zero Touch Provisioning (ZTP) のインストールと設定が完了したときに通知するバリデーター通知ポリシーを作成します。このポリシーは、シングルノード OpenShift クラスター、3 ノードクラスター、および標準クラスターのデプロイメントに使用できます。
手順
ソースファイル
validatorCRs/informDuValidator.yaml
を含むスタンドアロンのPolicyGenTemplate
カスタムリソース (CR) を作成します。スタンドアロンPolicyGenTemplate
CR は、各クラスタータイプに 1 つだけ必要です。たとえば、次の CR は、シングルノード OpenShift クラスターにバリデータ通知ポリシーを適用します。シングルノードクラスターバリデータ通知ポリシー CR の例 (group-du-sno-validator-ranGen.yaml)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
{policy-gen-crs}
オブジェクトの名前。この名前は、placementBinding
、placementRule
、および要求されたnamespace
で作成されるpolicy
の一部としても使用されます。- 2
- この値は、
policy-gen-crs
グループで使用されるnamespace
と一致する必要があります。 - 3
bindingRules
で定義されたgroup-du-*
ラベルはSiteConfig
ファイルに存在している必要があります。- 4
bindingExcludedRules
で定義されたラベルは `ztp-done:` でなければなりません。ztp-done
ラベルは、Topology Aware Lifecycle Manager と調整するために使用されます。- 5
mcp
はソースファイルvalidatorCRs/informDuValidator.yaml
で使用されるMachineConfigPool
オブジェクトを定義する。これは、シングルノードの場合はmaster
であり、標準のクラスターデプロイメントの場合は 3 ノードクラスターデプロイメントおよびworker
である必要があります。- 6
- オプション: デフォルト値は
inform
です。 - 7
- この値は、生成された RHACM ポリシーの名前の一部として使用されます。シングルノードの例の生成されたバリデーターポリシーは
group-du-sno-validator-du-policy
という名前です。
-
PolicyGenTemplate
CR ファイルを Git リポジトリーにコミットし、変更をプッシュします。
10.2.6. PolicyGenTemplate CR を使用した電源状態の設定 リンクのコピーリンクがクリップボードにコピーされました!
低レイテンシーで高パフォーマンスのエッジデプロイメントでは、C ステートと P ステートを無効にするか制限する必要があります。この設定では、CPU は一定の周波数 (通常は最大ターボ周波数) で実行されます。これにより、CPU が常に最大速度で実行され、高いパフォーマンスと低レイテンシーが実現されます。これにより、ワークロードのレイテンシーが最適化されます。ただし、これは最大の電力消費にもつながり、すべてのワークロードに必要ではない可能性があります。
ワークロードはクリティカルまたは非クリティカルとして分類できます。クリティカルなワークロードでは、高パフォーマンスと低レイテンシーのために C ステートと P ステートの設定を無効にする必要があります。クリティカルでないワークロードでは、C ステートと P ステートの設定を使用して、いくらかのレイテンシーとパフォーマンスを犠牲にします。GitOps Zero Touch Provisioning (ZTP) を使用して、次の 3 つの電源状態を設定できます。
- 高性能モードは、最大の消費電力で超低遅延を提供します。
- パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。
- 省電力は、消費電力の削減と遅延の増加のバランスをとります。
デフォルトの設定は、低遅延のパフォーマンスモードです。
PolicyGenTemplate
カスタムリソース (CR) を使用すると、ztp-site-generate
コンテナーの GitOps プラグインで提供されるベースソース CR に追加の設定の詳細をオーバーレイできます。
group-du-sno-ranGen.yaml
の PolicyGenTemplate
CR に基づいて、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新して、電源状態を設定します。
次の共通の前提条件は、3 つの電源状態すべての設定に適用されます。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。
- 「GitOps ZTP サイト設定リポジトリーの準備」で説明されている手順に従っている。
10.2.6.1. PolicyGenTemplate CR を使用してパフォーマンスモードを設定する リンクのコピーリンクがクリップボードにコピーされました!
この例に従って group-du-sno-ranGen.yaml
の PolicyGenTemplate
CR に基づいて、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新してパフォーマンスモードを設定します。
パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。
前提条件
- 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。
手順
パフォーマンスモードを設定するには、
out/argocd/example/policygentemplates//
のgroup-du-sno-ranGen.yaml
参照ファイルでPerformanceProfile
のPolicyGenTemplate
エントリーを次のように更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenTemplate
変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
10.2.6.2. PolicyGenTemplate CR を使用した高パフォーマンスモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って group-du-sno-ranGen.yaml
の PolicyGenTemplate
CR に基づいて、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新して高パフォーマンスモードを設定します。
高パフォーマンスモードは、最大の消費電力で超低遅延を提供します。
前提条件
- 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。
手順
高パフォーマンスモードを設定するには、
out/argocd/example/policygentemplates/
のgroup-du-sno-ranGen.yaml
参照ファイル内でPerformanceProfile
のPolicyGenTemplate
エントリーを次のように更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenTemplate
変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
10.2.6.3. PolicyGenTemplate CR を使用した省電力モードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って group-du-sno-ranGen.yaml
の PolicyGenTemplate
CR に基づいて、参照設定用に生成された PerformanceProfile
CR の workloadHints
フィールドを更新して、省電力モードを設定します。
省電力モードは、消費電力の削減と遅延の増加のバランスをとります。
前提条件
- BIOS で C ステートと OS 制御の P ステートを有効化している。
手順
省電力モードを設定するには、
out/argocd/example/policygentemplates/
のgroup-du-sno-ranGen.yaml
参照ファイル内でPerformanceProfile
のPolicyGenTemplate
エントリーを次のように更新します。追加のカーネル引数オブジェクトを使用して、省電力モード用に CPU ガバナーを設定することを推奨します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
schedutil
ガバナーが推奨されますが、使用できる他のガバナーにはondemand
とpowersave
が含まれます。
-
Git で
PolicyGenTemplate
変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
検証
次のコマンドを使用して、識別されたノードのリストから、デプロイされたクラスター内のワーカーノードを選択します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、ノードにログインします。
oc debug node/<node-name>
$ oc debug node/<node-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <node-name>
を、電源状態を確認するノードの名前に置き換えます。/host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。次の例に示すように、ルートディレクトリーを/host
に変更すると、ホストの実行可能パスに含まれるバイナリーを実行できます。chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、適用された電源状態を確認します。
cat /proc/cmdline
# cat /proc/cmdline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
予想される出力
-
省電力モードの
intel_pstate=passive
。
10.2.6.4. 省電力の最大化 リンクのコピーリンクがクリップボードにコピーされました!
最大の CPU 周波数を制限して、最大の電力節約を実現することを推奨します。最大 CPU 周波数を制限せずに重要でないワークロード CPU で C ステートを有効にすると、重要な CPU の周波数が高くなるため、消費電力の節約の多くが無効になります。
sysfs
プラグインフィールドを更新し、リファレンス設定の TunedPerformancePatch
CR で max_perf_pct
に適切な値を設定することで、電力の節約を最大化します。group-du-sno-ranGen.yaml
に基づくこの例では、最大 CPU 周波数を制限するために従う手順を説明します。
前提条件
- 「PolicyGenTemplate CR を使用した省電力モードの設定」の説明に従って、省電力モードを設定している。
手順
out/argocd/example/policygentemplates/
のgroup-du-sno-ranGen.yaml
参照ファイルで、TunedPerformancePatch
のPolicyGenTemplate
エントリーを更新します。電力を最大限に節約するには、次の例に示すようにmax_perf_pct
を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
max_perf_pct
は、cpufreq
ドライバーが設定できる最大周波数を、サポートされている最大 CPU 周波数のパーセンテージとして制御します。この値はすべての CPU に適用されます。サポートされている最大周波数は/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
で確認できます。開始点として、All Cores Turbo
周波数ですべての CPU を制限する割合を使用できます。All Cores Turbo
周波数は、すべてのコアがすべて使用されているときに全コアが実行される周波数です。
注記省電力を最大化するには、より低い値を設定します。
max_perf_pct
の値を低く設定すると、最大 CPU 周波数が制限されるため、消費電力が削減されますが、パフォーマンスに影響を与える可能性もあります。さまざまな値を試し、システムのパフォーマンスと消費電力を監視して、ユースケースに最適な設定を見つけてください。-
Git で
PolicyGenTemplate
変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
10.2.7. PolicyGenTemplate CR を使用した LVM Storage の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) を使用して、デプロイするマネージドクラスターの論理ボリュームマネージャー (LVM) ストレージを設定できます。
HTTP トランスポートで PTP イベントまたはベアメタルハードウェアイベントを使用する場合、LVM Storage を使用してイベントサブスクリプションを永続化します。
分散ユニットでローカルボリュームを使用する永続ストレージには、Local Storage Operator を使用します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
新しいマネージドクラスター用に LVM Storage を設定するには、次の YAML を
common-ranGen.yaml
ファイルのspec.sourceFiles
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Storage LVMO サブスクリプションは非推奨になりました。OpenShift Container Platform の将来のリリースでは、ストレージ LVMO サブスクリプションは利用できなくなります。代わりに、Storage LVMS サブスクリプションを使用する必要があります。
OpenShift Container Platform 4.18 では、LVMO サブスクリプションの代わりに Storage LVMS サブスクリプションを使用できます。LVMS サブスクリプションでは、
common-ranGen.yaml
ファイルを手動で上書きする必要はありません。Storage LVMS サブスクリプションを使用するには、次の YAML をcommon-ranGen.yaml
ファイルのspec.sourceFiles
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のグループまたは個々のサイト設定ファイルの
spec.sourceFiles
にLVMCluster
CR を追加します。たとえば、group-du-sno-ranGen.yaml
ファイルに次を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定例では、OpenShift Container Platform がインストールされているディスクを除く、使用可能なすべてのデバイスを含むボリュームグループ (
vg1
) を作成します。シンプール論理ボリュームも作成されます。- 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
-
Git で
PolicyGenTemplate
の変更をコミットし、その変更をサイト設定リポジトリーにプッシュして、GitOps ZTP を使用して LVM Storage を新しいサイトにデプロイします。
10.2.8. PolicyGenTemplate CR を使用した PTP イベントの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP パイプラインを使用して、HTTP トランスポートを使用する PTP イベントを設定できます。
10.2.8.1. HTTP トランスポートを使用する PTP イベントの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイしたマネージドクラスター上で、HTTP トランスポートを使用する PTP イベントを設定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
要件に応じて、以下の
PolicyGenTemplate
の変更をgroup-du-3node-ranGen.yaml
、group-du-sno-ranGen.yaml
、またはgroup-du-standard-ranGen.yaml
ファイルに適用してください。spec.sourceFiles
で、トランスポートホストを設定するPtpOperatorConfig
CR ファイルを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfig
リソースのtransportHost
フィールドを設定する必要はありません。PTP クロックの種類とインターフェイスに
linuxptp
とphc2sys
を設定します。たとえば、次の YAML をspec.sourceFiles
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要件に応じて、
PtpConfigMaster.yaml
またはPtpConfigSlave.yaml
を指定できます。group-du-sno-ranGen.yaml
およびgroup-du-3node-ranGen.yaml
に基づいて設定する場合は、PtpConfigSlave.yaml
を使用します。 - 2
- デバイス固有のインターフェイス名。
- 3
- PTP 高速イベントを有効にするには、
.spec.sourceFiles.spec.profile
のptp4lOpts
に--summary_interval -4
値を追加する必要があります。 - 4
phc2sysOpts
の値が必要です。-m
はメッセージをstdout
に出力します。linuxptp-daemon
DaemonSet
はログを解析し、Prometheus メトリックを生成します。- 5
- オプション:
ptpClockThreshold
スタンザが存在しない場合は、ptpClockThreshold
フィールドにデフォルト値が使用されます。スタンザは、デフォルトのptpClockThreshold
値を示します。ptpClockThreshold
値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeout
は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUN
に変わるまでの時間値 (秒単位) です。maxOffsetThreshold
およびminOffsetThreshold
設定は、CLOCK_REALTIME
(phc2sys
) またはマスターオフセット (ptp4l
) の値と比較するナノ秒単位のオフセット値を設定します。ptp4l
またはphc2sys
のオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUN
に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKED
に設定されます。
- 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
- 変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して PTP 高速イベントを新規サイトにデプロイします。
10.2.9. イメージをローカルにキャッシュするための Image Registry Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、ローカルレジストリーを使用してイメージのキャッシュを管理します。エッジコンピューティングのユースケースでは、クラスターは集中型のイメージレジストリーと通信するときに帯域幅の制限を受けることが多く、イメージのダウンロード時間が長くなる可能性があります。
初期デプロイメント中はダウンロードに時間がかかることは避けられません。時間の経過とともに、予期しないシャットダウンが発生した場合に CRI-O が /var/lib/containers/storage
ディレクトリーを消去するリスクがあります。イメージのダウンロード時間が長い場合の対処方法として、GitOps Zero Touch Provisioning (ZTP) を使用してリモートマネージドクラスター上にローカルイメージレジストリーを作成できます。これは、クラスターをネットワークのファーエッジにデプロイするエッジコンピューティングシナリオで役立ちます。
GitOps ZTP を使用してローカルイメージレジストリーをセットアップする前に、リモートマネージドクラスターのインストールに使用する SiteConfig
CR でディスクパーティショニングを設定する必要があります。インストール後、PolicyGenTemplate
CR を使用してローカルイメージレジストリーを設定します。次に、GitOps ZTP パイプラインは永続ボリューム (PV) と永続ボリューム要求 (PVC) CR を作成し、imageregistry
設定にパッチを適用します。
ローカルイメージレジストリーは、ユーザーアプリケーションイメージにのみ使用でき、OpenShift Container Platform または Operator Lifecycle Manager Operator イメージには使用できません。
10.2.9.1. SiteConfig を使用したディスクパーティショニングの設定 リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
CR と GitOps Zero Touch Provisioning (ZTP) を使用して、マネージドクラスターのディスクパーティションを設定します。SiteConfig
CR のディスクパーティションの詳細は、基になるディスクと一致する必要があります。
この手順はインストール時に完了する必要があります。
前提条件
- Butane をインストールしている。
手順
storage.bu
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
storage.bu
を Ignition ファイルに変換します。butane storage.bu
$ butane storage.bu
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}
{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - JSON Pretty Print などのツールを使用して、出力を JSON 形式に変換します。
出力を
SiteConfig
CR の.spec.clusters.nodes.ignitionConfigOverride
フィールドにコピーします。例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記.spec.clusters.nodes.ignitionConfigOverride
フィールドが存在しない場合は、作成します。
検証
インストール中またはインストール後に、次のコマンドを実行して、ハブクラスターで
BareMetalHost
オブジェクトにアノテーションが表示されていることを確認します。oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]
$ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"
"{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストール後、シングルノード OpenShift ディスクのステータスを確認します。
次のコマンドを実行して、シングルノード OpenShift ノードでデバッグセッションを開始します。この手順は、
<node_name>-debug
というデバッグ Pod をインスタンス化します。oc debug node/my-sno-node
$ oc debug node/my-sno-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、デバッグシェル内で
/host
をルートディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。root ディレクトリーを/host
に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、使用可能なすべてのブロックデバイスに関する情報をリスト表示します。
lsblk
# lsblk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ファイルシステムのディスク領域の使用状況に関する情報を表示します。
df -h
# df -h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2.9.2. PolicyGenTemplate CR を使用してイメージレジストリーを設定する リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenTemplate
(PGT) CR を使用して、イメージレジストリーの設定に必要な CR を適用し、imageregistry
設定にパッチを適用します。
前提条件
- マネージドクラスターでディスクパーティションを設定しました。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - GitOps Zero Touch Provisioning (ZTP) で使用するカスタムサイト設定データを管理する Git リポジトリーを作成している。
手順
適切な
PolicyGenTemplate
CR で、ストレージクラス、永続ボリューム要求、永続ボリューム、およびイメージレジストリー設定を設定します。たとえば、個々のサイトを設定するには、次の YAML をファイルexample-sno-site.yaml
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要- fileName: ImageRegistryConfig.yaml
設定には、complianceType: mustonlyhave
を設定しないでください。これにより、レジストリー Pod のデプロイが失敗する可能性があります。-
Git で
PolicyGenTemplate
変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視される Git リポジトリーにプッシュします。
検証
次の手順を使用して、マネージドクラスターのローカルイメージレジストリーに関するエラーをトラブルシューティングします。
マネージドクラスターにログインしているときに、レジストリーへのログインが成功したことを確認します。以下のコマンドを実行します。
マネージドクラスター名をエクスポートします。
cluster=<managed_cluster_name>
$ cluster=<managed_cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスター
kubeconfig
の詳細を取得します。oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
$ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター
kubeconfig
をダウンロードしてエクスポートします。oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
$ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - マネージドクラスターからイメージレジストリーへのアクセスを確認します。「レジストリーへのアクセス」を参照してください。
imageregistry.operator.openshift.io
グループインスタンスのConfig
CRD がエラーを報告していないことを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。oc get image.config.openshift.io cluster -o yaml
$ oc get image.config.openshift.io cluster -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターの
PersistentVolumeClaim
にデータが入力されていることを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。oc get pv image-registry-sc
$ oc get pv image-registry-sc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry*
Pod が実行中であり、openshift-image-registry
namespace にあることを確認します。oc get pods -n openshift-image-registry | grep registry*
$ oc get pods -n openshift-image-registry | grep registry*
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターのディスクパーティションが正しいことを確認します。
マネージドクラスターへのデバッグシェルを開きます。
oc debug node/sno-1.example.com
$ oc debug node/sno-1.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow lsblk
を実行して、ホストディスクパーティションを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/var/imageregistry
は、ディスクが正しくパーティショニングされていることを示します。
10.3. PolicyGenTemplate リソースと TALM を使用した非接続環境でのマネージドクラスターの更新 リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) を使用すると、GitOps Zero Touch Provisioning (ZTP) と Topology Aware Lifecycle Manager (TALM) を使用してデプロイしたマネージドクラスターのソフトウェアライフサイクルを管理できます。TALM は、Red Hat Advanced Cluster Management (RHACM) PolicyGenTemplate ポリシーを使用して、ターゲットクラスターに適用される変更を管理および制御します。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
10.3.1. 非接続環境の設定 リンクのコピーリンクがクリップボードにコピーされました!
TALM は、プラットフォームと Operator の更新の両方を実行できます。
TALM を使用して非接続クラスターを更新する前に、ミラーレジストリーで更新するプラットフォームイメージおよび Operator イメージの両方をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。
プラットフォームの更新では、以下の手順を実行する必要があります。
必要な OpenShift Container Platform イメージリポジトリーをミラーリングします。「OpenShift Container Platform イメージリポジトリーのミラーリング」(関連情報のリンクを参照) の手順に従って、目的のプラットフォームイメージがミラーリングされていることを確認します。
imageContentSources.yaml
ファイルのimageContentSources
セクションの内容を保存します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ミラーリングされた目的のプラットフォームイメージのイメージシグネチャーを保存します。プラットフォームの更新のために、イメージ署名を
PolicyGenTemplate
CR に追加する必要があります。イメージ署名を取得するには、次の手順を実行します。以下のコマンドを実行して、目的の OpenShift Container Platform タグを指定します。
OCP_RELEASE_NUMBER=<release_version>
$ OCP_RELEASE_NUMBER=<release_version>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターのアーキテクチャーを指定します。
ARCHITECTURE=<cluster_architecture>
$ ARCHITECTURE=<cluster_architecture>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
x86_64
、aarch64
、s390x
、またはppc64le
など、クラスターのアーキテクチャーを指定します。
次のコマンドを実行して、Quay からリリースイメージダイジェストを取得します。
DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
$ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ダイジェストアルゴリズムを設定します。
DIGEST_ALGO="${DIGEST%%:*}"
$ DIGEST_ALGO="${DIGEST%%:*}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ダイジェスト署名を設定します。
DIGEST_ENCODED="${DIGEST#*:}"
$ DIGEST_ENCODED="${DIGEST#*:}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、mirror.openshift.com Web サイトからイメージ署名を取得します。
SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
$ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、イメージ署名を
checksum-<OCP_RELEASE_NUMBER>.yaml
ファイルに保存します。cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
$ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
更新グラフを準備します。更新グラフを準備するオプションは 2 つあります。
OpenShift Update Service を使用します。
ハブクラスターでグラフを設定する方法の詳細は、OpenShift Update Service の Operator のデプロイ および グラフデータ init コンテナーのビルド を参照してください。
アップストリームグラフのローカルコピーを作成します。マネージドクラスターにアクセスできる非接続環境の
http
またはhttps
サーバーで更新グラフをホストします。更新グラフをダウンロードするには、以下のコマンドを使用します。curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.18 -o ~/upgrade-graph_stable-4.18
$ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.18 -o ~/upgrade-graph_stable-4.18
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator の更新は、以下のタスクを実行する必要があります。
- Operator カタログをミラーリングします。「非接続クラスターで使用する Operator カタログのミラーリング」セクションの手順に従って、目的の Operator イメージがミラーリングされていることを確認します。
10.3.2. PolicyGenTemplate CR を使用したプラットフォーム更新の実行 リンクのコピーリンクがクリップボードにコピーされました!
TALM を使用してプラットフォームの更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新している。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
- 目的のイメージリポジトリーをミラーリングしている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
プラットフォーム更新用の
PolicyGenTemplate
CR を作成します。次の
PolicyGenTemplate
CR をdu-upgrade.yaml
ファイルに保存します。プラットフォーム更新の
PolicyGenTemplate
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ConfigMap
CR には、更新先の目的のリリースイメージの署名が含まれています。- 2
- 目的の OpenShift Container Platform リリースのイメージ署名を表示します。「環境のセットアップ」セクションの手順に従って保存した
checksum-${OCP_RELEASE_NUMBER}.yaml
ファイルから署名を取得します。 - 3
- 目的の OpenShift Container Platform イメージを含むミラーリポジトリーを表示します。「環境のセットアップ」セクションの手順に従って保存した
imageContentSources.yaml
ファイルからミラーを取得します。 - 4
- 更新をトリガーする
ClusterVersion
CR を示します。イメージの事前キャッシュには、channel
、upstream
、およびdesiredVersion
フィールドがすべて必要です。
PolicyGenTemplate
CR は 2 つのポリシーを生成します。-
du-upgrade-platform-upgrade-prep
ポリシーは、プラットフォームの更新の準備作業を行います。目的のリリースイメージシグネチャーのConfigMap
CR を作成し、ミラー化されたリリースイメージリポジトリーのイメージコンテンツソースを作成し、目的の更新チャネルと非接続環境でマネージドクラスターが到達可能な更新グラフを使用してクラスターバージョンを更新します。 -
du-upgrade-platform-upgrade
ポリシーは、プラットフォームのアップグレードを実行するために使用されます。
PolicyGenTemplate
CR の GitOps ZTP Git リポジトリーにあるkustomization.yaml
ファイルにdu-upgrade.yaml
ファイルの内容を追加し、変更を Git リポジトリーにプッシュします。ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。
以下のコマンドを実行して、作成したポリシーを確認します。
oc get policies -A | grep platform-upgrade
$ oc get policies -A | grep platform-upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.enable
フィールドをfalse
に設定して、プラットフォーム更新用のClusterGroupUpdate
CR を作成します。次の例に示すように、プラットフォーム更新
ClusterGroupUpdate
CR の内容を、du-upgrade-platform-upgrade-prep
ポリシーとdu-upgrade-platform-upgrade
ポリシーおよびターゲットクラスターとともに、cgu-platform-upgrade.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ClusterGroupUpdate
CR をハブクラスターに適用します。oc apply -f cgu-platform-upgrade.yml
$ oc apply -f cgu-platform-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: プラットフォームの更新用にイメージを事前キャッシュします。
次のコマンドを実行して、
ClusterGroupUpdate
CR で事前キャッシュを有効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新プロセスを監視し、事前キャッシュが完了するまで待ちます。ハブクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
$ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プラットフォームの更新を開始します。
次のコマンドを実行して、
cgu-platform-upgrade
ポリシーを有効にし、事前キャッシュを無効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3.3. PolicyGenTemplate CR を使用した Operator 更新の実行 リンクのコピーリンクがクリップボードにコピーされました!
TALM で Operator の更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新している。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
- 目的のインデックスイメージ、バンドルイメージ、およびバンドルイメージで参照されるすべての Operator イメージをミラーリングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
Operator の更新用に
PolicyGenTemplate
CR を更新します。du-upgrade.yaml
ファイルの次の追加コンテンツでdu-upgrade
PolicyGenTemplate
CR を更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インデックスイメージ URL には、必要な Operator イメージが含まれます。インデックスイメージが常に同じイメージ名とタグにプッシュされている場合、この変更は必要ありません。
- 2
- Operator Lifecycle Manager (OLM) が新しい Operator バージョンのインデックスイメージをポーリングする頻度を
registryPoll.interval
フィールドで設定します。y-stream および z-stream Operator の更新のために新しいインデックスイメージタグが常にプッシュされる場合、この変更は必要ありません。registryPoll.interval
フィールドを短い間隔に設定して更新を促進できますが、間隔を短くすると計算負荷が増加します。この動作に対処するには、更新が完了したらregistryPoll.interval
をデフォルト値に戻します。 - 3
- カタログ接続が最後に監視された状態。
READY
値は、CatalogSource
ポリシーの準備が整っていることを保証し、インデックス Pod がプルされ、実行中であることを示します。このように、TALM は最新のポリシー準拠状態に基づいて Operator をアップグレードします。
この更新により、
redhat-operators-disconnected
というポリシーが生成されます。これは、必要な Operator イメージを含む新しいインデックスイメージでredhat-operators-disconnected
カタログソースを更新するためのポリシーです。注記Operator にイメージの事前キャッシュを使用する必要があり、
redhat-operators-disconnected
以外の別のカタログソースからの Operator がある場合は、次のタスクを実行する必要があります。- 別のカタログソースの新しいインデックスイメージまたはレジストリーポーリング間隔の更新を使用して、別のカタログソースポリシーを準備します。
- 異なるカタログソースからの目的の Operator に対して個別のサブスクリプションポリシーを準備します。
たとえば、目的の SRIOV-FEC Operator は、
certified-operators
カタログソースで入手できます。カタログソースと Operator サブスクリプションを更新するには、次の内容を追加して、2 つのポリシーdu-upgrade-fec-catsrc-policy
とdu-upgrade-subscriptions-fec-policy
を生成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 共通の
PolicyGenTemplate
CR に指定されたサブスクリプションチャネルが存在する場合は、それらを削除します。GitOps ZTP イメージのデフォルトサブスクリプションチャネルが更新に使用されます。注記GitOps ZTP 4.18 を通じて適用される Operator のデフォルトチャネルは、
performance-addon-operator
以外はstable
です。OpenShift Container Platform 4.11 以降、performance-addon-operator
機能はnode-tuning-operator
に移動されました。4.10 リリースの場合、PAO のデフォルトチャネルはv4.10
です。共通のPolicyGenTemplate
CR でデフォルトのチャネルを指定することもできます。PolicyGenTemplate
CR の更新を GitOps ZTP Git リポジトリーにプッシュします。ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。
以下のコマンドを実行して、作成したポリシーを確認します。
oc get policies -A | grep -E "catsrc-policy|subscription"
$ oc get policies -A | grep -E "catsrc-policy|subscription"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator の更新を開始する前に、必要なカタログソースの更新を適用します。
operator-upgrade-prep
という名前のClusterGroupUpgrade
CR の内容をカタログソースポリシーと共に、ターゲットマネージドクラスターの内容をcgu-operator-upgrade-prep.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ポリシーをハブクラスターに適用します。
oc apply -f cgu-operator-upgrade-prep.yml
$ oc apply -f cgu-operator-upgrade-prep.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies -A | grep -E "catsrc-policy"
$ oc get policies -A | grep -E "catsrc-policy"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.enable
フィールドをfalse
に設定して、Operator 更新のClusterGroupUpgrade
CR を作成します。以下の例のように、Operator 更新
ClusterGroupUpgrade
CR の内容をdu-upgrade-operator-catsrc-policy
ポリシーで保存して、共通のPolicyGenTemplate
およびターゲットクラスターで作成されたサブスクリプションポリシーをcgu-operator-upgrade.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記1 つの
ClusterGroupUpgrade
CR は、ClusterGroupUpgrade
CR に含まれる 1 つのカタログソースからサブスクリプションポリシーで定義される必要な Operator のイメージのみを事前キャッシュできます。SRIOV-FEC Operator の例のように、目的の Operator が異なるカタログソースからのものである場合、別のClusterGroupUpgrade
CR をdu-upgrade-fec-catsrc-policy
およびdu-upgrade-subscriptions-fec-policy
ポリシーで作成する必要があります。SRIOV-FEC Operator イメージの事前キャッシュと更新。次のコマンドを実行して、
ClusterGroupUpgrade
CR をハブクラスターに適用します。oc apply -f cgu-operator-upgrade.yml
$ oc apply -f cgu-operator-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: Operator の更新用にイメージを事前キャッシュします。
イメージの事前キャッシュを開始する前に、以下のコマンドを実行して、サブスクリプションポリシーがこの時点で
NonCompliant
であることを確認します。oc get policy common-subscriptions-policy -n <policy_namespace>
$ oc get policy common-subscriptions-policy -n <policy_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
ClusterGroupUpgrade
CR で事前キャッシュを有効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
$ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。
oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq
$ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator の更新を開始します。
以下のコマンドを実行して
cgu-operator-upgrade
ClusterGroupUpgrade
CR を有効にし、事前キャッシュを無効にして Operator の更新を開始します。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3.4. PolicyGenTemplate CR を使用した Operator 更新の失敗のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
一部のシナリオでは、ポリシーのコンプライアンス状態が古いため、Topology Aware Lifecycle Manager (TALM) が Operator の更新を見逃す可能性があります。
カタログソースの更新後に Operator Lifecycle Manager (OLM) がサブスクリプションステータスを更新すると、時間がかかります。TALM が修復が必要かどうかを判断する間、サブスクリプションポリシーのステータスは準拠していると表示される場合があります。その結果、サブスクリプションポリシーで指定された Operator はアップグレードされません。
このシナリオを回避するには、別のカタログソース設定を PolicyGenTemplate
に追加し、更新が必要な Operator のサブスクリプションでこの設定を指定します。
手順
PolicyGenTemplate
リソースにカタログソース設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新が必要な Operator の新しい設定を指すように
Subscription
リソースを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
PolicyGenTemplate
リソースで定義した追加のカタログソース設定の名前を入力します。
10.3.5. プラットフォームと Operator の更新を一緒に実行する リンクのコピーリンクがクリップボードにコピーされました!
プラットフォームと Operator の更新を同時に実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新している。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
-
「プラットフォーム更新の実行」および「Operator 更新の実行」セクションで説明されている手順に従って、更新用の
PolicyGenTemplate
CR を作成します。 プラットフォームの準備作業と Operator の更新を適用します。
プラットフォームの更新の準備作業、カタログソースの更新、およびターゲットクラスターのポリシーを含む
ClusterGroupUpgrade
CR の内容をcgu-platform-operator-upgrade-prep.yml
ファイルに保存します。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
cgu-platform-operator-upgrade-prep.yml
ファイルをハブクラスターに適用します。oc apply -f cgu-platform-operator-upgrade-prep.yml
$ oc apply -f cgu-platform-operator-upgrade-prep.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プラットフォーム用の
ClusterGroupUpdate
CR と、spec.enable
フィールドをfalse
に設定した Operator 更新を作成します。次の例に示すように、ポリシーとターゲットクラスターを含むプラットフォームと Operator の更新
ClusterGroupUpdate
CR の内容をcgu-platform-operator-upgrade.yml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
cgu-platform-operator-upgrade.yml
ファイルをハブクラスターに適用します。oc apply -f cgu-platform-operator-upgrade.yml
$ oc apply -f cgu-platform-operator-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: プラットフォームおよび Operator の更新用にイメージを事前キャッシュします。
以下のコマンドを実行して、
ClusterGroupUpgrade
CR で事前キャッシュを有効にします。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
oc get jobs,pods -n openshift-talm-pre-cache
$ oc get jobs,pods -n openshift-talm-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。
oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
$ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プラットフォームおよび Operator の更新を開始します。
以下のコマンドを実行して、
cgu-du-upgrade
ClusterGroupUpgrade
CR がプラットフォームと Operator の更新を開始します。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記プラットフォームおよび Operator 更新の CR は、設定を
spec.enable: true
に設定して最初から作成できます。この場合、更新は事前キャッシュが完了した直後に開始し、CR を手動で有効にする必要はありません。事前キャッシュと更新の両方で、ポリシー、配置バインディング、配置ルール、マネージドクラスターアクション、マネージドクラスタービューなどの追加リソースが作成され、手順を完了することができます。
afterCompletion.deleteObjects
フィールドをtrue
に設定すると、更新の完了後にこれらのリソースがすべて削除されます。
10.3.6. PolicyGenTemplate CR を使用したデプロイされたクラスターからの Performance Addon Operator サブスクリプションの削除 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの OpenShift Container Platform では、Performance Addon Operator はアプリケーションの自動低レイテンシーパフォーマンスチューニングを提供していました。OpenShift Container Platform 4.11 以降では、これらの機能は Node Tuning Operator の一部です。
OpenShift Container Platform 4.11 以降を実行しているクラスターに Performance Addon Operator をインストールしないでください。OpenShift Container Platform 4.11 以降にアップグレードすると、Node Tuning Operator は Performance Addon Operator を自動的に削除します。
Operator の再インストールを防ぐために、Performance Addon Operator サブスクリプションを作成するポリシーを削除する必要があります。
参照 DU プロファイルには、PolicyGenTemplate
CR common-ranGen.yaml
に Performance Addon Operator が含まれています。デプロイされたマネージドクラスターからサブスクリプションを削除するには、common-ranGen.yaml
を更新する必要があります。
Performance Addon Operator 4.10.3-5 以降を OpenShift Container Platform 4.11 以降にインストールする場合、Performance Addon Operator はクラスターのバージョンを検出し、Node Tuning Operator 機能との干渉を避けるために自動的に休止状態になります。ただし、最高のパフォーマンスを確保するには、OpenShift Container Platform 4.11 クラスターから Performance Addon Operator を削除してください。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、ArgoCD のソースリポジトリーとして定義されている必要があります。
- OpenShift Container Platform 4.11 以降に更新します。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
common-ranGen.yaml
ファイルの Performance Addon Operator namespace、Operator グループ、およびサブスクリプションのcomplianceType
をmustnothave
に変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。
common-subscriptions-policy
ポリシーのステータスがNon-Compliant
に変わります。 - Topology Aware Lifecycle Manager を使用して、ターゲットクラスターに変更を適用します。設定変更のロールアウトの詳細は、「関連情報」セクションを参照してください。
プロセスを監視します。ターゲットクラスターの
common-subscriptions-policy
ポリシーのステータスがCompliant
の場合、Performance Addon Operator はクラスターから削除されています。次のコマンドを実行して、common-subscriptions-policy
のステータスを取得します。oc get policy -n ztp-common common-subscriptions-policy
$ oc get policy -n ztp-common common-subscriptions-policy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
common-ranGen.yaml
ファイルのspec.sourceFiles
から Performance Addon Operator namespace、Operator グループ、およびサブスクリプション CR を削除します。 - 変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。ポリシーは準拠したままです。
10.3.7. シングルノード OpenShift クラスター上の TALM を使用したユーザー指定のイメージの事前キャッシュ リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションをアップグレードする前に、アプリケーション固有のワークロードイメージをシングルノード OpenShift クラスターに事前キャッシュできます。
次のカスタムリソース (CR) を使用して、事前キャッシュジョブの設定オプションを指定できます。
-
PreCachingConfig
CR -
ClusterGroupUpgrade
CR
PreCachingConfig
CR のフィールドはすべてオプションです。
PreCachingConfig CR の例
- 1
- デフォルトでは、TALM は、マネージドクラスターのポリシーから
platformImage
、operatorsIndexes
、およびoperatorsPackagesAndChannels
フィールドに自動的に値を設定します。これらのフィールドのデフォルトの TALM 派生値をオーバーライドする値を指定できます。 - 2
- クラスター上で最低限必要なディスク容量を指定します。指定しない場合、TALM は OpenShift Container Platform イメージのデフォルト値を定義します。ディスク容量フィールドには、整数値とストレージユニットを含める必要があります。たとえば、
40 GiB
、200 MB
、1 TiB
です。 - 3
- イメージ名の一致に基づいて事前キャッシュから除外するイメージを指定します。
- 4
- 事前キャッシュする追加イメージのリストを指定します。
PreCachingConfig CR 参照を使用した ClusterGroupUpgrade CR の例
10.3.7.1. 事前キャッシュ用のカスタムリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
PreCachingConfig
CR は、ClusterGroupUpgrade
CR の前または同時に作成する必要があります。
事前キャッシュする追加イメージのリストを使用して
PreCachingConfig
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow preCaching
フィールドをtrue
に設定してClusterGroupUpgrade
CR を作成し、前の手順で作成したPreCachingConfig
CR を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告クラスターにイメージをインストールすると、それらを変更したり削除したりすることはできません。
イメージを事前キャッシュを開始する場合は、次のコマンドを実行して
ClusterGroupUpgrade
CR を適用します。oc apply -f cgu.yaml
$ oc apply -f cgu.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TALM は ClusterGroupUpgrade
CR を検証します。
この時点から、TALM 事前キャッシュワークフローを続行できます。
すべてのサイトが同時に事前キャッシュされます。
検証
次のコマンドを実行して、
ClusterUpgradeGroup
CR が適用されているハブクラスターの事前キャッシュステータスを確認します。oc get cgu <cgu_name> -n <cgu_namespace> -oyaml
$ oc get cgu <cgu_name> -n <cgu_namespace> -oyaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 事前キャッシュ設定は、管理ポリシーが存在するかどうかをチェックすることによって検証されます。
ClusterGroupUpgrade
およびPreCachingConfig
CR の設定が有効であると、次のステータスになります。有効な CR の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 無効な PreCachingConfig CR の例
Type: "PrecacheSpecValid" Status: False, Reason: "PrecacheSpecIncomplete" Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"
Type: "PrecacheSpecValid" Status: False, Reason: "PrecacheSpecIncomplete" Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターで次のコマンドを実行すると、事前キャッシュジョブを見つけることができます。
oc get jobs -n openshift-talo-pre-cache
$ oc get jobs -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 進行中の事前キャッシュジョブの例
NAME COMPLETIONS DURATION AGE pre-cache 0/1 1s 1s
NAME COMPLETIONS DURATION AGE pre-cache 0/1 1s 1s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、事前キャッシュジョブ用に作成された Pod のステータスを確認できます。
oc describe pod pre-cache -n openshift-talo-pre-cache
$ oc describe pod pre-cache -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 進行中の事前キャッシュジョブの例
Type Reason Age From Message Normal SuccesfulCreate 19s job-controller Created pod: pre-cache-abcd1
Type Reason Age From Message Normal SuccesfulCreate 19s job-controller Created pod: pre-cache-abcd1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行すると、ジョブのステータスに関するライブ更新を取得できます。
oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
$ oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 事前キャッシュジョブが正常に完了したことを確認するには、次のコマンドを実行します。
oc describe pod pre-cache -n openshift-talo-pre-cache
$ oc describe pod pre-cache -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 完了した事前キャッシュジョブの例
Type Reason Age From Message Normal SuccesfulCreate 5m19s job-controller Created pod: pre-cache-abcd1 Normal Completed 19s job-controller Job completed
Type Reason Age From Message Normal SuccesfulCreate 5m19s job-controller Created pod: pre-cache-abcd1 Normal Completed 19s job-controller Job completed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージがシングルノード OpenShift で正常に事前キャッシュされていることを確認するには、次の手順を実行します。
デバッグモードでノードに入ります。
oc debug node/cnfdf00.example.lab
$ oc debug node/cnfdf00.example.lab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow root を
host
に変更します。chroot /host/
$ chroot /host/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 目的のイメージを検索します。
sudo podman images | grep <operator_name>
$ sudo podman images | grep <operator_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3.8. GitOps ZTP 用に自動作成された ClusterGroupUpgrade CR について リンクのコピーリンクがクリップボードにコピーされました!
TALM には、ManagedClusterForCGU
と呼ばれるコントローラーがあります。このコントローラーは、ハブクラスター上で ManagedCluster
CR の Ready
状態を監視し、GitOps Zero Touch Provisioning (ZTP) の ClusterGroupUpgrade
CR を作成します。
ztp-done
ラベルが適用されていない Ready
状態のマネージドクラスターの場合、ManagedClusterForCGU
コントローラーは、ztp-install
namespace に ClusterGroupUpgrade
CR と、GitOps ZTP プロセス中に作成された関連する RHACM ポリシーを自動的に作成します。次に TALM は自動作成された ClusterGroupUpgrade
CR に一覧表示されている設定ポリシーのセットを修復し、設定 CR をマネージドクラスターにプッシュします。
クラスターが Ready
になった時点でマネージドクラスターのポリシーがない場合、ポリシーのない ClusterGroupUpgrade
CR が作成されます。ClusterGroupUpgrade
が完了すると、マネージドクラスターには ztp-done
というラベルが付けられます。そのマネージドクラスターに適用するポリシーがある場合は、2 日目の操作として ClusterGroupUpgrade
を手動で作成します。
GitOps ZTP 用に自動作成された ClusterGroupUpgrade
CR の例
第11章 PolicyGenerator または PolicyGenTemplate CR でのハブテンプレートの使用 リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager は、GitOps Zero Touch Provisioning (ZTP) で使用される設定ポリシーで、Red Hat Advanced Cluster Management (RHACM) ハブクラスターテンプレート機能をサポートします。
ハブ側のクラスターテンプレートを使用すると、ターゲットクラスターに合わせて動的にカスタマイズできる設定ポリシーを定義できます。これにより、設定は似ているが値が異なる多くのクラスターに対して個別のポリシーを作成する必要がなくなります。
ポリシーテンプレートは、ポリシーが定義されている namespace と同じ namespace に制限されています。これは、ハブテンプレートで参照されるオブジェクトを、ポリシーが作成されたのと同じ namespace に作成する必要があることを意味します。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
11.1. グループ PolicyGenerator または PolicyGentemplate CR でのグループとサイト設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
ハブテンプレートを使用して、マネージドクラスターに適用される生成済みポリシーにグループとサイトの値を入力することで、ConfigMap
CR でクラスターのフリート設定を管理できます。PolicyGenerator
または PolicyGentemplate
CR のサイトでハブテンプレートを使用すると、サイトごとにポリシー CR を作成する必要がなくなります。
ハードウェアの種類や地域などのユースケースに応じて、フリート内のクラスターをさまざまなカテゴリーにグループ化できます。各クラスターには、そのクラスターが属するグループ (複数可) に対応するラベルが必要です。各グループの設定値を異なる ConfigMap
CR で管理する場合は、ハブテンプレートを使用してグループ内のすべてのクラスターに変更を適用するために必要なグループポリシー CR は 1 つだけです。
次の例は、3 つの ConfigMap
CR と 1 つの PolicyGenerator
CR を使用して、ハードウェアタイプとリージョン別にグループ化されたクラスターに、サイト設定とグループ設定の両方を適用する方法を示しています。
ConfigMap
CR には、1 MiB のサイズ制限 (Kubernetes ドキュメント) があります。ConfigMap
CR の実際のサイズは、last-applied-configuration
アノテーションによってさらに制限されます。last-applied-configuration
制限を回避するには、次のアノテーションをテンプレート ConfigMap
に追加します。
argocd.argoproj.io/sync-options: Replace=true
argocd.argoproj.io/sync-options: Replace=true
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセスでき、GitOps ZTP ArgoCD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
グループとサイトの設定を含む 3 つの
ConfigMap
CR を作成します。group-hardware-types-configmap
という名前のConfigMap
CR を作成して、ハードウェア固有の設定を保持します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
argocd.argoproj.io/sync-options
アノテーションは、ConfigMap
のサイズが 1 MiB より大きい場合にのみ必要です。
group-zones-configmap
という名前のConfigMap
CR を作成して、地域設定を保持します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow site-data-configmap
という名前のConfigMap
CR を作成して、サイト固有の設定を保持します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記各
ConfigMap
CR は、PolicyGenerator
CR グループから生成されるポリシーと同じ namespace に存在する必要があります。-
Git で
ConfigMap
CR をコミットし、Argo CD アプリケーションが監視する Git リポジトリーにプッシュします。 ハードウェアタイプとリージョンラベルをクラスターに適用します。次のコマンドは、
du-sno-1-zone-1
という名前のシングルクラスターに適用され、"hardware-type": "hardware-type-1"
および"group-du-sno-zone": "zone-1"
のラベルが選択されます。oc patch managedclusters.cluster.open-cluster-management.io/du-sno-1-zone-1 --type merge -p '{"metadata":{"labels":{"hardware-type": "hardware-type-1", "group-du-sno-zone": "zone-1"}}}'
$ oc patch managedclusters.cluster.open-cluster-management.io/du-sno-1-zone-1 --type merge -p '{"metadata":{"labels":{"hardware-type": "hardware-type-1", "group-du-sno-zone": "zone-1"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要件に応じて、ハブテンプレートを使用して
ConfigMap
オブジェクトから必要なデータを取得するPolicyGenerator
またはPolicyGentemplate
CR グループを作成します。グループ
PolicyGenerator
CR を作成します。この例のPolicyGenerator
CR は、policyDefaults.placement
フィールドの下にリストされているラベルに一致するクラスターのロギング、VLAN ID、NIC、およびパフォーマンスプロファイルを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow グループ
PolicyGenTemplate
CR を作成します。例として挙げたこのPolicyGenTemplate
CR は、spec.bindingRules
の下にリストされているラベルに一致するクラスターのロギング、VLAN ID、NIC、およびパフォーマンスプロファイルを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記サイト固有の設定値を取得するには、
.ManagedClusterName
フィールドを使用します。これは、ターゲットマネージドクラスターの名前に設定されたテンプレートコンテキスト値です。グループ固有の設定を取得するには、
.ManagedClusterLabels
フィールドを使用します。これは、マネージドクラスターのラベルの値に設定されたテンプレートコンテキスト値です。PolicyGenerator
またはPolicyGentemplate
CR のサイトを Git でコミットし、ArgoCD アプリケーションによって監視される Git リポジトリーにプッシュします。注記参照された
ConfigMap
CR に対するその後の変更は、適用されたポリシーに自動的に同期されません。新しいConfigMap
の変更を手動で同期して、既存のPolicyGenerator
CR を更新する必要があります。「新しい ConfigMap の変更を既存の PolicyGenerator または PolicyGenTemplate CR に同期する」を参照してください。複数のクラスターに同じ
PolicyGenerator
またはPolicyGentemplate
CR を使用できます。設定に変更がある場合、各クラスターの設定とマネージドクラスターのラベルを保持するConfigMap
オブジェクトのみ変更する必要があります。
11.2. 新しい ConfigMap の変更を既存の PolicyGenerator または PolicyGentemplate CR に同期する リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 -
ハブクラスターテンプレートを使用して
ConfigMap
CR から情報を取得するPolicyGenerator
またはPolicyGentemplate
CR を作成している。
手順
-
ConfigMap
CR の内容を更新し、変更をハブクラスターに適用します。 更新された
ConfigMap
CR の内容をデプロイされたポリシーに同期するには、次のいずれかを実行します。オプション 1: 既存のポリシーを削除します。ArgoCD は
PolicyGenerator
またはPolicyGentemplate
CR を使用して、削除されたポリシーをすぐに再作成します。たとえば、以下のコマンドを実行します。oc delete policy <policy_name> -n <policy_namespace>
$ oc delete policy <policy_name> -n <policy_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション 2:
ConfigMap
を更新するたびに、特別なアノテーションpolicy.open-cluster-management.io/trigger-update
を異なる値でポリシーに適用します。以下に例を示します。oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"
$ oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記変更を有効にするには、更新されたポリシーを適用する必要があります。詳細は、再処理のための特別なアノテーション を参照してください。
オプション: 存在する場合は、ポリシーを含む
ClusterGroupUpdate
CR を削除します。以下に例を示します。oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>
$ oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新された
ConfigMap
の変更を適用するポリシーを含む新しいClusterGroupUpdate
CR を作成します。たとえば、次の YAML をファイルcgr-example.yaml
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新されたポリシーを適用します。
oc apply -f cgr-example.yaml
$ oc apply -f cgr-example.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第12章 Topology Aware Lifecycle Manager を使用したマネージドクラスターの更新 リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) を使用して、複数のクラスターのソフトウェアライフサイクルを管理できます。TALM は Red Hat Advanced Cluster Management (RHACM) ポリシーを使用して、ターゲットクラスター上で変更を実行します。
GitOps ZTP での PolicyGenerator リソースの使用は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
12.1. Topology Aware Lifecycle Manager の設定について リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) は、1 つまたは複数の OpenShift Container Platform クラスターに対する Red Hat Advanced Cluster Management (RHACM) ポリシーのデプロイメントを管理します。TALM を大規模なクラスターのネットワークで使用することにより、限られたバッチで段階的にポリシーをクラスターにデプロイメントすることができます。これにより、更新時のサービス中断の可能性を最小限に抑えることができます。TALM では、以下の動作を制御することができます。
- 更新のタイミング
- RHACM マネージドクラスター数
- ポリシーを適用するマネージドクラスターのサブセット
- クラスターの更新順序
- クラスターに修復されたポリシーのセット
- クラスターに修復されたポリシーの順序
- カナリアクラスターの割り当て
シングルノードの OpenShift の場合、Topology Aware Lifecycle Manager (TALM) は、帯域幅が制限されたクラスター用にイメージの事前キャッシュを提供します。
TALM は、OpenShift Container Platform y-stream および z-stream 更新のオーケストレーションをサポートし、y-streams および z-streams での day-two 操作をサポートします。
12.2. Topology Aware Lifecycle Manager で使用される管理ポリシー リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) は、クラスターの更新に RHACM ポリシーを使用します。
TALM は、remediationAction
フィールドが inform
に設定されているポリシー CR のロールアウトを管理するために使用できます。サポートされるユースケースには、以下が含まれます。
- ポリシー CR の手動ユーザー作成
-
PolicyGenerator
またはPolicyGentemplate
カスタムリソース定義 (CRD) から自動的に生成されたポリシー
手動承認で Operator 契約を更新するポリシーのために、TALM は、更新された Operator のインストールを承認する追加機能を提供します。
マネージドポリシーの詳細は、RHACM のドキュメントの ポリシーの概要 を参照してください。
12.3. Web コンソールを使用した Topology Aware Lifecycle Manager のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して Topology Aware Lifecycle Manager をインストールできます。
前提条件
- 最新バージョンの RHACM Operator をインストールしている。
- TALM に必要な RHACM 2.9 以降がある。
- 非接続のレジストリーでハブクラスターをセットアップしている。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
- 利用可能な Operator のリストから Topology Aware Lifecycle Manager を検索し、Install をクリックします。
- Installation mode ["All namespaces on the cluster (default)"] および Installed Namespace ("openshift-operators") のデフォルトの選択を維持し、Operator が適切にインストールされていることを確認します。
- Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators ページに移動します。
-
Operator が
All Namespaces
ネームスペースにインストールされ、そのステータスがSucceeded
であることを確認します。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators → Installed Operators ページに移動し、
Status
列でエラーまたは失敗の有無を確認します。 -
Workloads → Pods ページに移動し、問題を報告している
cluster-group-upgrades-controller-manager
Pod のコンテナーのログを確認します。
12.4. CLI を使用した Topology Aware Lifecycle Manager のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc
) を使用して Topology Aware Lifecycle Manager (TALM) をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 最新バージョンの RHACM Operator をインストールしている。
- TALM に必要な RHACM 2.9 以降がある。
- 非接続の registry でハブクラスターを設定します。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
Subscription
CR を作成します。Subscription
CR を定義し、YAML ファイルを保存します (例:talm-subscription.yaml
)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Subscription
CR を作成します。oc create -f talm-subscription.yaml
$ oc create -f talm-subscription.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
CSV リソースを調べて、インストールが成功したことを確認します。
oc get csv -n openshift-operators
$ oc get csv -n openshift-operators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE topology-aware-lifecycle-manager.4.18.x Topology Aware Lifecycle Manager 4.18.x Succeeded
NAME DISPLAY VERSION REPLACES PHASE topology-aware-lifecycle-manager.4.18.x Topology Aware Lifecycle Manager 4.18.x Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TALM が稼働していることを確認します。
oc get deploy -n openshift-operators
$ oc get deploy -n openshift-operators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE openshift-operators cluster-group-upgrades-controller-manager 1/1 1 1 14s
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE openshift-operators cluster-group-upgrades-controller-manager 1/1 1 1 14s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.5. ClusterGroupUpgrade CR リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) は、クラスターグループの ClusterGroupUpgrade
CR から修復計画を作成します。ClusterGroupUpgrade
CR で次の仕様を定義できます。
- グループのクラスター
-
ClusterGroupUpgrade
CR のブロック - 管理ポリシーの適用リスト
- 同時更新の数
- 適用可能なカナリア更新
- 更新前後に実行するアクション
- 更新タイミング
ClusterGroupUpgrade
CR の enable
フィールドを使用して、更新の開始時刻を制御できます。たとえば、メンテナンスウィンドウが 4 時間にスケジュールされている場合、enable
フィールドを false
に設定して ClusterGroupUpgrade
CR を準備できます。
次のように spec.remediationStrategy.timeout
設定を設定することで、タイムアウトを設定できます。
spec remediationStrategy: maxConcurrency: 1 timeout: 240
spec
remediationStrategy:
maxConcurrency: 1
timeout: 240
batchTimeoutAction
を使用して、クラスターの更新が失敗した場合にどうなるかを判断できます。continue
を指定して失敗したクラスターをスキップし、他のクラスターのアップグレードを続行するか、abort
を指定してすべてのクラスターのポリシー修復を停止することができます。タイムアウトが経過すると、TALM はすべての enforce
ポリシーを削除して、クラスターがそれ以上更新されないようにします。
変更を適用するには、enabled
フィールドを true
に設定します。
詳細は、「マネージドクラスターへの更新ポリシーの適用」セクションを参照してください。
TALM は指定されたクラスターへのポリシーの修復を通じて機能するため、ClusterGroupUpgrade
CR は多くの条件について true または false のステータスを報告できます。
TALM がクラスターの更新を完了した後、同じ ClusterGroupUpgrade
CR の制御下でクラスターが再度更新されることはありません。次の場合は、新しい ClusterGroupUpgrade
CR を作成する必要があります。
- クラスターを再度更新する必要がある場合
-
クラスターが更新後に
inform
ポリシーで非準拠に変更された場合
12.5.1. クラスターの選択 リンクのコピーリンクがクリップボードにコピーされました!
TALM は修復計画を作成し、次のフィールドに基づいてクラスターを選択します。
-
clusterLabelSelector
フィールドは、更新するクラスターのラベルを指定します。これは、k8s.io/apimachinery/pkg/apis/meta/v1
からの標準ラベルセレクターのリストで構成されます。リスト内の各セレクターは、ラベル値ペアまたはラベル式のいずれかを使用します。各セレクターからの一致は、clusterSelector
フィールドおよびcluster
フィールドからの一致と共に、クラスターの最終リストに追加されます。 -
clusters
フィールドは、更新するクラスターのリストを指定します。 -
canaries
フィールドは、カナリア更新のクラスターを指定します。 -
maxConcurrency
フィールドは、バッチで更新するクラスターの数を指定します。 -
actions
フィールドは、更新プロセスを開始するときに TALM が実行するbeforeEnable
アクションと、各クラスターのポリシー修復を完了するときに TALM が実行するafterCompletion
アクションを指定します。
clusters
、clusterLabelSelector
、および clusterSelector
フィールドを一緒に使用して、クラスターの結合リストを作成できます。
修復計画は、canaries
フィールドにリストされているクラスターから開始されます。各カナリアクラスターは、単一クラスターバッチを形成します。
有効な field
が false
に設定されたサンプル ClusterGroupUpgrade
CR
- 1
- 各クラスターのポリシー修復が完了したときに TALM が実行するアクションを指定します。
- 2
- 更新プロセスを開始するときに TALM が実行するアクションを指定します。
- 3
- 更新するクラスターの一覧を定義します。
- 4
enable
フィールドはfalse
に設定されています。- 5
- 修復するユーザー定義のポリシーセットを一覧表示します。
- 6
- クラスター更新の詳細を定義します。
- 7
- カナリア更新のクラスターを定義します。
- 8
- バッチの同時更新の最大数を定義します。修復バッチの数は、カナリアクラスターの数に加えて、カナリアクラスターを除くクラスターの数を
maxConcurrency
値で除算します。すべての管理ポリシーに準拠しているクラスターは、修復計画から除外されます。 - 9
- クラスターを選択するためのパラメーターを表示します。
- 10
- バッチがタイムアウトした場合の動作を制御します。可能な値は
abort
またはcontinue
です。指定しない場合、デフォルトはcontinue
です。 - 11
- 更新のステータスに関する情報を表示します。
- 12
ClustersSelected
条件は、選択されたすべてのクラスターが有効であることを示します。- 13
Validated
条件は、選択したすべてのクラスターが検証済みであることを示します。
カナリアクラスターの更新中に障害が発生すると、更新プロセスが停止します。
修復計画が正常に作成されたら、enable
フィールドを true
に設定できます。TALM は、指定された管理ポリシーを使用して、準拠していないクラスターの更新を開始します。
ClusterGroupUpgrade
CR の enable
フィールドが false
に設定されている場合にのみ、spec
フィールドを変更できます。
12.5.2. Validating リンクのコピーリンクがクリップボードにコピーされました!
TALM は、指定されたすべての管理ポリシーが使用可能で正しいことを確認し、Validated
条件を使用して、ステータスと理由を次のようにレポートします。
true
検証が完了しました。
false
ポリシーが見つからないか無効であるか、無効なプラットフォームイメージが指定されています。
12.5.3. 事前キャッシュ リンクのコピーリンクがクリップボードにコピーされました!
クラスターにはコンテナーイメージレジストリーにアクセスするための帯域幅が制限されるため、更新が完了する前にタイムアウトが発生する可能性があります。シングルノード OpenShift クラスターでは、事前キャッシュを使用して、これを回避できます。preCaching
フィールドを true
に設定して ClusterGroupUpgrade
CR を作成すると、コンテナーイメージの事前キャッシュが開始されます。TALM は、使用可能なディスク容量を OpenShift Container Platform イメージの推定サイズと比較して、十分な容量があることを確認します。クラスターに十分なスペースがない場合、TALM はそのクラスターの事前キャッシュをキャンセルし、そのクラスターのポリシーを修復しません。
TALM は PrecacheSpecValid
条件を使用して、次のようにステータス情報を報告します。
true
事前キャッシュの仕様は有効で一貫性があります。
false
事前キャッシュの仕様は不完全です。
TALM は PrecachingSucceeded
条件を使用して、次のようにステータス情報を報告します。
true
TALM は事前キャッシュプロセスを完了しました。いずれかのクラスターで事前キャッシュが失敗した場合、そのクラスターの更新は失敗しますが、他のすべてのクラスターの更新は続行されます。クラスターの事前キャッシュが失敗した場合は、メッセージで通知されます。
false
1 つ以上のクラスターで事前キャッシュがまだ進行中か、すべてのクラスターで失敗しました。
詳細は、「コンテナーイメージの事前キャッシュ機能の使用」セクションを参照してください。
12.5.4. クラスターの更新 リンクのコピーリンクがクリップボードにコピーされました!
TALM は、修復計画に従ってポリシーを適用します。以降のバッチに対するポリシーの適用は、現在のバッチのすべてのクラスターがすべての管理ポリシーに準拠した直後に開始されます。バッチがタイムアウトすると、TALM は次のバッチに移動します。バッチのタイムアウト値は、spec.timeout
フィールドは修復計画のバッチ数で除算されます。
TALM は Progressing
条件を使用して、ステータスと理由を次のように報告します。
true
TALM は準拠していないポリシーを修復しています。
false
更新は進行中ではありません。これには次の理由が考えられます。
- すべてのクラスターがすべての管理ポリシーに準拠している。
- ポリシーの修復に時間がかかりすぎたため、更新がタイムアウトした。
- CR のブロックがシステムにないか、まだ完了していない。
-
ClusterGroupUpgrade
CR が有効になっていない。
管理されたポリシーは、ClusterGroupUpgrade
CR の managedPolicies
フィールドに一覧表示される順序で適用されます。1 つの管理ポリシーが一度に指定されたクラスターに適用されます。クラスターが現在のポリシーに準拠している場合、次の管理ポリシーがクラスターに適用されます。
Progressing
状態の ClusterGroupUpgrade
CR の例
- 1
Progressing
フィールドは、TALM がポリシーの修復中であることを示しています。
12.5.5. 更新ステータス リンクのコピーリンクがクリップボードにコピーされました!
TALM は Succeeded
条件を使用して、ステータスと理由を次のようにレポートします。
true
すべてのクラスターは、指定された管理ポリシーに準拠しています。
false
修復に使用できるクラスターがないか、次のいずれかの理由でポリシーの修復に時間がかかりすぎたため、ポリシーの修復に失敗しました。
- 現在のバッチにカナリア更新が含まれており、バッチ内のクラスターがバッチタイムアウト内のすべての管理ポリシーに準拠していません。
-
クラスターは、
remediationStrategy
フィールドに指定されたtimeout
値内で管理ポリシーに準拠していませんでした。
Succeeded
状態の ClusterGroupUpgrade
CR の例
タイムアウト
状態の ClusterGroupUpgrade
CR の例
12.5.6. ClusterGroupUpgrade CR のブロック リンクのコピーリンクがクリップボードにコピーされました!
複数の ClusterGroupUpgrade
CR を作成して、それらの適用順序を制御できます。
たとえば、ClusterGroupUpgrade
CR A の開始をブロックする ClusterGroupUpgrade
CR C を作成する場合、ClusterGroupUpgrade
CR A は ClusterGroupUpgrade
CR C のステータスが UpgradeComplete
になるまで起動できません。
1 つの ClusterGroupUpgrade
CR には複数のブロッキング CR を含めることができます。この場合、現在の CR のアップグレードを開始する前に、すべてのブロッキング CR を完了する必要があります。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
ClusterGroupUpgrade
CR の内容をcgu-a.yaml
、cgu-b.yaml
、およびcgu-c.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ブロッキング CR を定義します。
cgu-c
が完了するまでcgu-a
の更新を開始できません。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cgu-a
が完了するまでcgu-b
の更新を開始できません。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cgu-c
の更新にはブロック CR がありません。TALM は、enable
フィールドがtrue
に設定されている場合にcgu-c
の更新を開始します。
関連する CR ごとに以下のコマンドを実行して
ClusterGroupUpgrade
CR を作成します。oc apply -f <name>.yaml
$ oc apply -f <name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 関連する各 CR について以下のコマンドを実行して、更新プロセスを開始します。
oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \ --type merge -p '{"spec":{"enable":true}}'
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \ --type merge -p '{"spec":{"enable":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例は、
enable
フィールドがtrue
に設定されているClusterGroupUpgrade
CR を示しています。ブロッキング CR のある
cgu-a
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ブロッキング CR のリストを表示します。
ブロッキング CR のある
cgu-b
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ブロッキング CR のリストを表示します。
CR をブロックする
cgu-c
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cgu-c
の更新にはブロック CR がありません。
12.6. マネージドクラスターでのポリシーの更新 リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) は、ClusterGroupUpgrade
カスタムリソース (CR) で指定されたクラスターの inform
ポリシーのセットを修復します。TALM は、PlacementBinding
CR の bindingOverrides.remediationAction
および subFilter
仕様を通じて Policy
CR の remediationAction
仕様を制御することで、inform
ポリシーを修復します。各ポリシーには、対応する独自の RHACM 配置ルールと RHACM 配置バインディングがあります。
1 つずつ、TALM は、現在のバッチから、適用可能な管理ポリシーに対応する配置ルールに各クラスターを追加します。クラスターがポリシーにすでに準拠している場合は、TALM は準拠するクラスターへのポリシーの適用を省略します。次に TALM は次のポリシーを非準拠クラスターに適用します。TALM がバッチで更新を完了すると、ポリシーに関連付けられた配置ルールからすべてのクラスターが削除されます。次に、次のバッチの更新が開始されます。
スポーククラスターの状態が RHACM に準拠している状態を報告しない場合、ハブクラスターの管理ポリシーには TALM が必要とするステータス情報がありません。TALM は、以下の方法でこれらのケースを処理します。
-
ポリシーの
status.compliant
フィールドがない場合、TALM はポリシーを無視してログエントリーを追加します。次に、TALM はポリシーのstatus.status
フィールドを確認し続けます。 -
ポリシーの
status.status
がない場合、TALM はエラーを生成します。 -
クラスターのコンプライアンスステータスがポリシーの
status.status
フィールドにない場合、TALM はそのクラスターをそのポリシーに準拠していないと見なします。
ClusterGroupUpgrade
CR の batchTimeoutAction
は、クラスターのアップグレードが失敗した場合にどうなるかを決定します。continue
を指定して失敗したクラスターをスキップし、他のクラスターのアップグレードを続行するか、abort
を指定してすべてのクラスターのポリシー修復を停止することができます。タイムアウトが経過すると、TALM は作成したすべてのリソースを削除し、クラスターにそれ以上の更新が行われないようにします。
アップグレードポリシーの例
RHACM のポリシーの詳細は、ポリシーの概要 を参照してください。
12.6.1. TALM を使用してインストールするマネージドクラスターの Operator サブスクリプションの設定 リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) は、Operator の Subscription
カスタムリソース (CR) に status.state.AtLatestKnown
フィールドが含まれている場合に限り、Operator のインストールプランを承認できます。
手順
Operator の
Subscription
CR に、status.state.AtLatestKnown
フィールドを追加します。Subscription CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
status.state: AtLatestKnown
フィールドは、Operator カタログから入手可能な Operator の最新バージョンに使用されます。
注記新しいバージョンの Operator がレジストリーで利用可能になると、関連するポリシーが非準拠になります。
-
ClusterGroupUpgrade
CR を使用して、変更したSubscription
ポリシーをマネージドクラスターに適用します。
12.6.2. マネージドクラスターへの更新ポリシーの適用 リンクのコピーリンクがクリップボードにコピーされました!
ポリシーを適用してマネージドクラスターを更新できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- TALM に必要な RHACM 2.9 以降がある。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
ClusterGroupUpgrade
CR の内容をcgu-1.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
ClusterGroupUpgrade
CR を作成します。oc create -f cgu-1.yaml
$ oc create -f cgu-1.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
ClusterGroupUpgrade
CR がハブクラスターに作成されていることを確認します。oc get cgu --all-namespaces
$ oc get cgu --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE STATE DETAILS default cgu-1 8m55 NotEnabled Not Enabled
NAMESPACE NAME AGE STATE DETAILS default cgu-1 8m55 NotEnabled Not Enabled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して更新のステータスを確認します。
oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq
$ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterGroupUpgrade
CR のspec.enable
フィールドはfalse
に設定されます。
以下のコマンドを実行して、
spec.enable
フィールドの値をtrue
に変更します。oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \ --patch '{"spec":{"enable":true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \ --patch '{"spec":{"enable":true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行して更新のステータスを確認します。
oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq
$ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 現在のバッチの更新の進捗を反映します。このコマンドを再度実行して、進捗に関する更新情報を取得します。
以下のコマンドを実行してポリシーのステータスを確認します。
oc get policies -A
oc get policies -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
現在のバッチからクラスターに適用された子ポリシーの場合、
spec.remediationAction
の値はenforce
に変更されます。 -
残りのクラスターの子ポリシーの場合、
spec.remedationAction
の値はinform
のままとなります。 -
バッチが完了すると、適用された子ポリシーの場合、
spec.remediationAction
の値はinform
に戻ります。
-
現在のバッチからクラスターに適用された子ポリシーの場合、
ポリシーに Operator サブスクリプションが含まれる場合、インストールの進捗をシングルノードクラスターで直接確認できます。
以下のコマンドを実行して、インストールの進捗を確認するシングルノードクラスターの
KUBECONFIG
ファイルをエクスポートします。export KUBECONFIG=<cluster_kubeconfig_absolute_path>
$ export KUBECONFIG=<cluster_kubeconfig_absolute_path>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シングルノードクラスターに存在するすべてのサブスクリプションを確認し、以下のコマンドを実行し、
ClusterGroupUpgrade
CR でインストールしようとしているポリシーを探します。oc get subs -A | grep -i <subscription_name>
$ oc get subs -A | grep -i <subscription_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-logging
ポリシーの出力例NAMESPACE NAME PACKAGE SOURCE CHANNEL openshift-logging cluster-logging cluster-logging redhat-operators stable
NAMESPACE NAME PACKAGE SOURCE CHANNEL openshift-logging cluster-logging cluster-logging redhat-operators stable
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
管理ポリシーの 1 つに
ClusterVersion
CR が含まれる場合は、スポーククラスターに対して以下のコマンドを実行して、現在のバッチでプラットフォーム更新のステータスを確認します。oc get clusterversion
$ oc get clusterversion
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.4.18.5 True True 43s Working towards 4.4.18.7: 71 of 735 done (9% complete)
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.4.18.5 True True 43s Working towards 4.4.18.7: 71 of 735 done (9% complete)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して Operator サブスクリプションを確認します。
oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"
$ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、必要なサブスクリプションに関連付けられているシングルノードのクラスターに存在するインストール計画を確認します。
oc get installplan -n <subscription_namespace>
$ oc get installplan -n <subscription_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-logging
Operator の出力例NAMESPACE NAME CSV APPROVAL APPROVED openshift-logging install-6khtw cluster-logging.5.3.3-4 Manual true
NAMESPACE NAME CSV APPROVAL APPROVED openshift-logging install-6khtw cluster-logging.5.3.3-4 Manual true
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール計画の
Approval
フィールドはManual
に設定されており、TALM がインストール計画を承認すると、Approved
フィールドはfalse
からtrue
に変わります。
注記TALM がサブスクリプションを含むポリシーを修復している場合、そのサブスクリプションに関連付けられているすべてのインストールプランが自動的に承認されます。オペレーターが最新の既知のバージョンに到達するために複数のインストールプランが必要な場合、TALM は複数のインストールプランを承認し、最終バージョンに到達するために 1 つ以上の中間バージョンをアップグレードします。
以下のコマンドを実行して、
ClusterGroupUpgrade
がインストールしているポリシーの Operator のクラスターサービスバージョンがSucceeded
フェーズに到達したかどうかを確認します。oc get csv -n <operator_namespace>
$ oc get csv -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Logging Operator の出力例
NAME DISPLAY VERSION REPLACES PHASE cluster-logging.5.4.2 Red Hat OpenShift Logging 5.4.2 Succeeded
NAME DISPLAY VERSION REPLACES PHASE cluster-logging.5.4.2 Red Hat OpenShift Logging 5.4.2 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.7. コンテナーイメージ事前キャッシュ機能の使用 リンクのコピーリンクがクリップボードにコピーされました!
シングルノード OpenShift クラスターでは、コンテナーイメージレジストリーにアクセスするための帯域幅が制限されている可能性があり、更新が完了する前に、タイムアウトが発生する可能性があります。
更新の時間は TALM によって設定されていません。手動アプリケーションまたは外部自動化により、更新の開始時に ClusterGroupUpgrade
CR を適用できます。
コンテナーイメージの事前キャッシュは、ClusterGroupUpgrade
CR で preCaching
フィールドが true
に設定されている場合に起動します。
TALM は PrecacheSpecValid
条件を使用して、次のようにステータス情報を報告します。
true
事前キャッシュの仕様は有効で一貫性があります。
false
事前キャッシュの仕様は不完全です。
TALM は PrecachingSucceeded
条件を使用して、次のようにステータス情報を報告します。
true
TALM は事前キャッシュプロセスを完了しました。いずれかのクラスターで事前キャッシュが失敗した場合、そのクラスターの更新は失敗しますが、他のすべてのクラスターの更新は続行されます。クラスターの事前キャッシュが失敗した場合は、メッセージで通知されます。
false
1 つ以上のクラスターで事前キャッシュがまだ進行中か、すべてのクラスターで失敗しました。
事前キャッシュプロセスに成功すると、ポリシーの修復を開始できます。修復アクションは、enable
フィールドが true
に設定されている場合に開始されます。クラスターで事前キャッシュエラーが発生した場合、そのクラスターのアップグレードは失敗します。アップグレードプロセスは、事前キャッシュが成功した他のすべてのクラスターに対して続行されます。
事前キャッシュプロセスは、以下のステータスにあります。
NotStarted
これは、すべてのクラスターが
ClusterGroupUpgrade
CR の最初の調整パスで自動的に割り当てられる初期状態です。この状態では、TALM は、以前の不完全な更新から残ったスポーククラスターの事前キャッシュの namespace およびハブビューリソースを削除します。次に TALM は、スポーク前の namespace の新規のManagedClusterView
リソースを作成し、PrecachePreparing
状態の削除を確認します。PreparingToStart
以前の不完全な更新からの残りのリソースを消去すると進行中です。
Starting
キャッシュ前のジョブの前提条件およびジョブが作成されます。
Active
ジョブは "Active" の状態です。
Succeeded
事前キャッシュジョブが成功しました。
PrecacheTimeout
アーティファクトの事前キャッシュは部分的に行われます。
UnrecoverableError
ジョブはゼロ以外の終了コードで終了します。
12.7.1. コンテナーイメージの事前キャッシュフィルターの使用 リンクのコピーリンクがクリップボードにコピーされました!
通常、事前キャッシュ機能は、クラスターが更新に必要とするよりも多くのイメージをダウンロードします。どの事前キャッシュイメージをクラスターにダウンロードするかを制御できます。これにより、ダウンロード時間が短縮され、帯域幅とストレージが節約されます。
次のコマンドを使用して、ダウンロードするすべてのイメージのリストを表示できます。
oc adm release info <ocp-version>
$ oc adm release info <ocp-version>
次の ConfigMap
の例は、excludePrecachePatterns
フィールドを使用してイメージを除外する方法を示しています。
- 1
- TALM は、ここにリストされているパターンのいずれかを含む名前を持つすべてのイメージを除外します。
12.7.2. 事前キャッシュでの ClusterGroupUpgrade CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
シングルノード OpenShift の場合は、事前キャッシュ機能により、更新が開始する前に、必要なコンテナーイメージをスポーククラスターに配置できます。
事前キャッシュの場合、TALM は ClusterGroupUpgrade
CR の spec.remediationStrategy.timeout
値を使用します。事前キャッシュジョブが完了するのに十分な時間を与える timeout
値を設定する必要があります。事前キャッシュの完了後に ClusterGroupUpgrade
CR を有効にすると、timeout
値を更新に適した期間に変更できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
clustergroupupgrades-group-du.yaml
ファイルでpreCaching
フィールドをtrue
に設定してClusterGroupUpgrade
CR の内容を保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
preCaching
フィールドはtrue
に設定されています。これにより、更新を開始する前に TALM がコンテナーイメージをプルできます。
事前キャッシュを開始する場合は、次のコマンドを実行して
ClusterGroupUpgrade
CR を適用します。oc apply -f clustergroupupgrades-group-du.yaml
$ oc apply -f clustergroupupgrades-group-du.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行して、
ClusterGroupUpgrade
CR がハブクラスターに存在するかどうかを確認します。oc get cgu -A
$ oc get cgu -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE STATE DETAILS ztp-group-du-sno du-upgrade-4918 10s InProgress Precaching is required and not done
NAMESPACE NAME AGE STATE DETAILS ztp-group-du-sno du-upgrade-4918 10s InProgress Precaching is required and not done
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- CR が作成されます。
以下のコマンドを実行して、事前キャッシュタスクのステータスを確認します。
oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'
$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 特定されたクラスターの一覧を表示します。
スポーククラスターで以下のコマンドを実行して、事前キャッシュジョブのステータスを確認します。
oc get jobs,pods -n openshift-talo-pre-cache
$ oc get jobs,pods -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME COMPLETIONS DURATION AGE job.batch/pre-cache 0/1 3m10s 3m10s NAME READY STATUS RESTARTS AGE pod/pre-cache--1-9bmlr 1/1 Running 0 3m10s
NAME COMPLETIONS DURATION AGE job.batch/pre-cache 0/1 3m10s 3m10s NAME READY STATUS RESTARTS AGE pod/pre-cache--1-9bmlr 1/1 Running 0 3m10s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
ClusterGroupUpgrade
CR のステータスを確認します。oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'
$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- キャッシュ前のタスクが実行されます。
12.8. Topology Aware Lifecycle Manager のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Topology Aware Lifecycle Manager (TALM) は、RHACM ポリシーを修復する OpenShift Container Platform Operator です。問題が発生した場合には、oc adm must-gather
コマンドを使用して詳細およびログを収集し、問題のデバッグ手順を行います。
関連トピックの詳細は、以下のドキュメントを参照してください。
- Red Hat Advanced Cluster Management for Kubernetes 2.4 Support Matrix
- Red Hat Advanced Cluster Management Troubleshooting
- 「Operator の問題のトラブルシューティング」セクション
12.8.1. 一般的なトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
以下の質問を確認して、問題の原因を特定できます。
適用する設定がサポートされているか ?
- RHACM と OpenShift Container Platform のバージョンと互換性があるか ?
- TALM および RHACM のバージョンと互換性があるか ?
問題の原因となる以下のコンポーネントはどれですか ?
ClusterGroupUpgrade
設定が機能するようにするには、以下を実行できます。
-
spec.enable
フィールドをfalse
に設定してClusterGroupUpgrade
CR を作成します。 - ステータスが更新され、トラブルシューティングの質問を確認するのを待ちます。
-
すべてが予想通りに機能する場合は、
ClusterGroupUpgrade
CR でspec.enable
フィールドをtrue
に設定します。
ClusterUpgradeGroup
CR で spec.enable
フィールドを true
に設定すると、更新手順が起動し、CR の spec
フィールドを編集することができなくなります。
12.8.2. ClusterUpgradeGroup CR を変更できません。 リンクのコピーリンクがクリップボードにコピーされました!
- 問題
-
更新を有効にした後に、
ClusterUpgradeGroup
CR を編集することはできません。 - 解決方法
以下の手順を実行して手順を再起動します。
以下のコマンドを実行して古い
ClusterGroupUpgrade
CR を削除します。oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>
$ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターおよびポリシーに関する既存の問題を確認し、修正します。
- すべてのクラスターがマネージドクラスターで、利用可能であることを確認します。
-
すべてのポリシーが存在し、
spec.remediationAction
フィールドがinform
に設定されていることを確認します。
正しい設定で新規の
ClusterGroupUpgrade
CR を作成します。oc apply -f <ClusterGroupUpgradeCR_YAML>
$ oc apply -f <ClusterGroupUpgradeCR_YAML>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.3. 管理ポリシー リンクのコピーリンクがクリップボードにコピーされました!
システムでの管理ポリシーの確認
- 問題
- システムで正しい管理ポリシーがあるかどうかをチェックする。
- 解決方法
以下のコマンドを実行します。
oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'
$ oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
["group-du-sno-validator-du-validator-policy", "policy2-common-nto-sub-policy", "policy3-common-ptp-sub-policy"]
["group-du-sno-validator-du-validator-policy", "policy2-common-nto-sub-policy", "policy3-common-ptp-sub-policy"]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
remediationAction モードの確認
- 問題
-
remediationAction
フィールドが、管理ポリシーのspec
でinform
に設定されているかどうかを確認する必要があります。 - 解決方法
以下のコマンドを実行します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ポリシーコンプライアンスの状態の確認
- 問題
- ポリシーのコンプライアンス状態を確認する。
- 解決方法
以下のコマンドを実行します。
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.4. クラスター リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターが存在するかどうかの確認
- 問題
-
ClusterGroupUpgrade
CR のクラスターがマネージドクラスターかどうかを確認します。 - 解決方法
以下のコマンドを実行します。
oc get managedclusters
$ oc get managedclusters
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.example.com:6443 True Unknown 13d spoke1 true https://api.spoke1.example.com:6443 True True 13d spoke3 true https://api.spoke3.example.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.example.com:6443 True Unknown 13d spoke1 true https://api.spoke1.example.com:6443 True True 13d spoke3 true https://api.spoke3.example.com:6443 True True 27h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、TALM マネージャーログを確認します。
以下のコマンドを実行して、TALM マネージャーの名前を取得します。
oc get pod -n openshift-operators
$ oc get pod -n openshift-operators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp 2/2 Running 0 45m
NAME READY STATUS RESTARTS AGE cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp 2/2 Running 0 45m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、TALM マネージャーログを確認します。
oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
$ oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"}
1 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- エラーメッセージには、クラスターがマネージドクラスターではないことが分かります。
マネージドクラスターが利用可能かどうかの確認
- 問題
-
ClusterGroupUpgrade
CR で指定されたマネージドクラスターが利用可能かどうかを確認する必要があります。 - 解決方法
以下のコマンドを実行します。
oc get managedclusters
$ oc get managedclusters
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.testlab.com:6443 True Unknown 13d spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.testlab.com:6443 True Unknown 13d spoke1 true https://api.spoke1.testlab.com:6443 True True 13d
1 spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
clusterLabelSelector のチェック
- 問題
-
ClusterGroupUpgrade
CR で指定されたclusterLabelSelector
フィールドが、マネージドクラスターの少なくとも 1 つと一致するか確認します。 - 解決方法
以下のコマンドを実行します。
oc get managedcluster --selector=upgrade=true
$ oc get managedcluster --selector=upgrade=true
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 更新するクラスターのラベルは
upgrade:true
です。
出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
カナリアクラスターが存在するかどうかの確認
- 問題
カナリアクラスターがクラスターのリストに存在するかどうかを確認します。
ClusterGroupUpgrade
CR の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 解決方法
以下のコマンドを実行します。
oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'
$ oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
["spoke1", "spoke3"]
["spoke1", "spoke3"]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、カナリアクラスターが
clusterLabelSelector
ラベルに一致するクラスターの一覧に存在するかどうかを確認します。oc get managedcluster --selector=upgrade=true
$ oc get managedcluster --selector=upgrade=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターは、spec.clusters
に存在し、spec.clusterLabelSelector
ラベルによって一致する場合もあります。
スポーククラスターでの事前キャッシュステータスの確認
スポーククラスターで以下のコマンドを実行して、事前キャッシュのステータスを確認します。
oc get jobs,pods -n openshift-talo-pre-cache
$ oc get jobs,pods -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.5. 修復ストラテジー リンクのコピーリンクがクリップボードにコピーされました!
remediationStrategy が ClusterGroupUpgrade CR に存在するかどうかの確認
- 問題
-
remediationStrategy
がClusterGroupUpgrade
CR に存在するかどうかを確認します。 - 解決方法
以下のコマンドを実行します。
oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'
$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{"maxConcurrency":2, "timeout":240}
{"maxConcurrency":2, "timeout":240}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ClusterGroupUpgrade CR に maxConcurrency が指定されているかどうかの確認
- 問題
-
maxConcurrency
がClusterGroupUpgrade
CR で指定されているかどうかを確認する必要があります。 - 解決方法
以下のコマンドを実行します。
oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'
$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
2
2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.6. Topology Aware Lifecycle Manager リンクのコピーリンクがクリップボードにコピーされました!
ClusterGroupUpgrade CR での条件メッセージおよびステータスの確認
- 問題
-
ClusterGroupUpgrade
CR のstatus.conditions
フィールドの値を確認する必要がある場合があります。 - 解決方法
以下のコマンドを実行します。
oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'
$ oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"Missing managed policies:[policyList]", "reason":"NotAllManagedPoliciesExist", "status":"False", "type":"Validated"}
{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"Missing managed policies:[policyList]", "reason":"NotAllManagedPoliciesExist", "status":"False", "type":"Validated"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
status.remediationPlan が計算されたかどうかの確認
- 問題
-
status.remediationPlan
が計算されているかどうかを確認します。 - 解決方法
以下のコマンドを実行します。
oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'
$ oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[["spoke2", "spoke3"]]
[["spoke2", "spoke3"]]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TALM マネージャーコンテナーのエラー
- 問題
- TALM のマネージャーコンテナーのログを確認する必要がある場合があります。
- 解決方法
以下のコマンドを実行します。
oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
$ oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"}
1 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- エラーを表示します。
ClusterGroupUpgrade
CR が完了した後、クラスターが一部のポリシーに準拠していない
- 問題
修復が必要かどうかを判断するために TALM が使用するポリシーコンプライアンスステータスは、まだすべてのクラスターで完全に更新されていません。これには次の理由が考えられます。
- ポリシーの作成または更新後、CGU の実行が早すぎました。
-
ポリシーの修復は、
ClusterGroupUpgrade
CR の後続のポリシーのコンプライアンスに影響します。
- 解決方法
-
同じ仕様で新しい
ClusterGroupUpdate
CR を作成して適用します。
GitOps ZTP ワークフローで自動作成された ClusterGroupUpgrade
CR に管理ポリシーがない
- 問題
-
クラスターが
Ready
になったときにマネージドクラスターのポリシーがない場合、ポリシーのないClusterGroupUpgrade
CR が自動作成されます。ClusterGroupUpgrade
CR が完了すると、マネージドクラスターにはztp-done
というラベルが付けられます。SiteConfig
リソースがプッシュされた後、必要な時間内にPolicyGenerator
またはPolicyGenTemplate
CR が Git リポジトリーにプッシュされなかった場合、クラスターがReady
になったときにターゲットクラスターで使用できるポリシーがなくなる可能性があります。 - 解決方法
-
適用するポリシーがハブクラスターで使用可能であることを確認してから、必要なポリシーを使用して
ClusterGroupUpgrade
CR を作成します。
ClusterGroupUpgrade
CR を手動で作成するか、自動作成を再度トリガーすることができます。ClusterGroupUpgrade
CR の自動作成をトリガーするには、クラスターから ztp-done
ラベルを削除し、以前に zip-install
namespace で作成された空の ClusterGroupUpgrade
CR を削除します。
事前キャッシュに失敗しました
- 問題
事前キャッシュは、次のいずれかの理由で失敗する場合があります。
- ノードに十分な空き容量がありません。
- 非接続環境では、事前キャッシュイメージが適切にミラーリングされていません。
- Pod の作成中に問題が発生しました。
- 解決方法
スペース不足のために事前キャッシュが失敗したかどうかを確認するには、ノードの事前キャッシュ Pod のログを確認します。
次のコマンドを使用して Pod の名前を見つけます。
oc get pods -n openshift-talo-pre-cache
$ oc get pods -n openshift-talo-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用してログをチェックし、エラーが容量不足に関連しているかどうかを確認します。
oc logs -n openshift-talo-pre-cache <pod name>
$ oc logs -n openshift-talo-pre-cache <pod name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ログがない場合は、次のコマンドを使用して Pod のステータスを確認します。
oc describe pod -n openshift-talo-pre-cache <pod name>
$ oc describe pod -n openshift-talo-pre-cache <pod name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod が存在しない場合は、次のコマンドを使用してジョブのステータスをチェックし、Pod を作成できなかった理由を確認します。
oc describe job -n openshift-talo-pre-cache pre-cache
$ oc describe job -n openshift-talo-pre-cache pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第13章 GitOps ZTP を使用したシングルノード OpenShift クラスターの拡張 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) を使用して、シングルノード OpenShift クラスターを拡張できます。シングルノード OpenShift クラスターにワーカーノードを追加すると、元のシングルノード OpenShift クラスターがコントロールプレーンノードのロールを保持します。ワーカーノードを追加しても、既存のシングルノード OpenShift クラスターのダウンタイムは必要ありません。
シングルノード OpenShift クラスターに追加できるワーカーノードの数に指定された制限はありませんが、追加のワーカーノード用にコントロールプレーンノードで予約されている CPU 割り当てを再評価する必要があります。
ワーカーノードでワークロードパーティショニングが必要な場合は、ノードをインストールする前に、ハブクラスターでマネージドクラスターポリシーをデプロイして修復する必要があります。そうすることで、GitOps ZTP ワークフローが MachineConfig
イグニッションファイルをワーカーノードに適用する前に、ワークロードパーティショニング MachineConfig
オブジェクトがレンダリングされ、worker
マシン設定プールに関連付けられます。
最初にポリシーを修復してから、ワーカーノードをインストールすることを推奨します。ワーカーノードのインストール後にワークロードパーティショニングマニフェストを作成する場合は、ノードを手動でドレインし、デーモンセットによって管理されるすべての Pod を削除する必要があります。管理デーモンセットが新しい Pod を作成すると、新しい Pod はワークロードパーティショニングプロセスを実行します。
GitOps ZTP を使用したシングルノード OpenShift クラスターへのワーカーノードの追加は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
13.1. PolicyGenerator または PolicyGenTemplate リソースを使用したワーカーノードへのプロファイルの適用 リンクのコピーリンクがクリップボードにコピーされました!
DU プロファイルを使用して、追加のワーカーノードを設定できます。
GitOps Zero Touch Provisioning (ZTP) の common、group、および site 固有の PolicyGenerator
リソースまたは PolicyGenTemplate
リソースを使用して、RAN 分散ユニット (DU) プロファイルをワーカーノードクラスターに適用できます。ArgoCD policies
アプリケーションにリンクされている GitOps ZTP パイプラインには、ztp-site-generate
コンテナーを抽出した場合に、関連する out/argocd/example
フォルダーで見つけることができる次の CR が含まれています。
- /acmpolicygenerator リソース
-
acm-common-ranGen.yaml
-
acm-group-du-sno-ranGen.yaml
-
acm-example-sno-site.yaml
-
ns.yaml
-
kustomization.yaml
-
- /policygentemplates リソース
-
common-ranGen.yaml
-
group-du-sno-ranGen.yaml
-
example-sno-site.yaml
-
ns.yaml
-
kustomization.yaml
-
ワーカーノードでの DU プロファイルの設定は、アップグレードと見なされます。アップグレードフローを開始するには、既存のポリシーを更新するか、追加のポリシーを作成する必要があります。次に、ClusterGroupUpgrade
CR を作成して、クラスターのグループ内のポリシーを調整する必要があります。
13.2. (オプション) PTP および SR-IOV デーモンセレクターの互換性の確保 リンクのコピーリンクがクリップボードにコピーされました!
DU プロファイルが GitOps Zero Touch Provisioning (ZTP) プラグインバージョン 4.11 以前を使用してデプロイされた場合、PTP および SR-IOV Operator は、master
というラベルの付いたノードにのみデーモンを配置するように設定されている可能性があります。この設定により、PTP および SR-IOV デーモンがワーカーノードで動作しなくなります。システムで PTP および SR-IOV デーモンノードセレクターが正しく設定されていない場合は、ワーカー DU プロファイル設定に進む前にデーモンを変更する必要があります。
手順
スポーククラスターの 1 つで PTP Operator のデーモンノードセレクター設定を確認します。
oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq
$ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PTP Operator の出力例
{"daemonNodeSelector":{"node-role.kubernetes.io/master":""}}
{"daemonNodeSelector":{"node-role.kubernetes.io/master":""}}
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ノードセレクターが
master
に設定されている場合、スポークは、変更が必要なバージョンの GitOps ZTP プラグインでデプロイされています。
スポーククラスターの 1 つで SR-IOV Operator のデーモンノードセレクター設定を確認します。
oc get sriovoperatorconfig/default -n \ openshift-sriov-network-operator -ojsonpath='{.spec}' | jq
$ oc get sriovoperatorconfig/default -n \ openshift-sriov-network-operator -ojsonpath='{.spec}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Operator の出力例
{"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true}
{"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true}
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ノードセレクターが
master
に設定されている場合、スポークは、変更が必要なバージョンの GitOps ZTP プラグインでデプロイされています。
グループポリシーで、次の
complianceType
およびspec
エントリーを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要daemonNodeSelector
フィールドを変更すると、一時的な PTP 同期が失われ、SR-IOV 接続が失われます。- Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
13.3. PTP および SR-IOV ノードセレクターの互換性 リンクのコピーリンクがクリップボードにコピーされました!
PTP 設定リソースと SR-IOV ネットワークノードポリシーは、ノードセレクターとして node-role.kubernetes.io/master: ""
を使用します。追加のワーカーノードの NIC 設定がコントロールプレーンノードと同じである場合、コントロールプレーンノードの設定に使用されたポリシーをワーカーノードに再利用できます。ただし、両方のノードタイプを選択するようにノードセレクターを変更する必要があります (たとえば、"node-role.kubernetes.io/worker"
ラベルを使用)。
13.4. PolicyGenerator CR を使用したワーカーノードポリシーのワーカーノードへの適用 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator
CR を使用してワーカーノードのポリシーを作成できます。
手順
以下の
PolicyGenerator
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 汎用の
MachineConfig
CR を使用して、ワーカーノードでワークロードパーティションを設定します。crio
およびkubelet
設定ファイルのコンテンツを生成できます。-
作成したポリシーテンプレートを、ArgoCD
policies
アプリケーションによってモニターされている Git リポジトリーに追加します。 -
ポリシーを
kustomization.yaml
ファイルに追加します。 - Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
新しいポリシーをスポーククラスターに修復するには、TALM カスタムリソースを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.5. PolicyGenTemplate CR を使用してワーカーノードポリシーをワーカーノードに適用する リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenTemplate
CR を使用してワーカーノードのポリシーを作成できます。
手順
次の
PolicyGenTemplate
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 汎用の
MachineConfig
CR を使用して、ワーカーノードでワークロードパーティションを設定します。crio
およびkubelet
設定ファイルのコンテンツを生成できます。-
作成したポリシーテンプレートを、ArgoCD
policies
アプリケーションによってモニターされている Git リポジトリーに追加します。 -
ポリシーを
kustomization.yaml
ファイルに追加します。 - Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
新しいポリシーをスポーククラスターに修復するには、TALM カスタムリソースを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.6. GitOps ZTP を使用してシングルノード OpenShift クラスターにワーカーノードを追加する リンクのコピーリンクがクリップボードにコピーされました!
1 つ以上のワーカーノードを既存のシングルノード OpenShift クラスターに追加して、クラスターで使用可能な CPU リソースを増やすことができます。
前提条件
- OpenShift Container Platform 4.11 以降のベアメタルハブクラスターに RHACM 2.6 以降をインストールして設定する
- ハブクラスターに Topology Aware Lifecycle Manager をインストールする
- ハブクラスターに Red Hat OpenShift GitOps をインストールする
-
GitOps ZTP
ztp-site-generate
コンテナーイメージバージョン 4.12 以降を使用する - GitOps ZTP を使用して管理対象のシングルノード OpenShift クラスターをデプロイする
- RHACM ドキュメントの説明に従って、中央インフラストラクチャー管理を設定する
-
内部 API エンドポイント
api-int.<cluster_name>.<base_domain>
を解決するようにクラスターにサービスを提供する DNS を設定する
手順
example-sno.yaml
SiteConfig
マニフェストを使用してクラスターをデプロイした場合は、新しいワーカーノードをspec.clusters['example-sno'].nodes
リストに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
ファイルのspec.nodes
セクションのbmcCredentialsName
フィールドで参照されるように、新しいホストの BMC 認証シークレットを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
ArgoCD
cluster
アプリケーションが同期すると、GitOps ZTP プラグインによって生成されたハブクラスターに 2 つの新しいマニフェストが表示されます。-
BareMetalHost
NMStateConfig
重要cpuset
フィールドは、ワーカーノードに対して設定しないでください。ワーカーノードのワークロードパーティショニングは、ノードのインストールが完了した後、管理ポリシーを通じて追加されます。
-
検証
インストールプロセスは、いくつかの方法でモニターできます。
次のコマンドを実行して、事前プロビジョニングイメージが作成されているかどうかを確認します。
oc get ppimg -n example-sno
$ oc get ppimg -n example-sno
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME READY REASON example-sno example-sno True ImageCreated example-sno example-node2 True ImageCreated
NAMESPACE NAME READY REASON example-sno example-sno True ImageCreated example-sno example-node2 True ImageCreated
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ベアメタルホストの状態を確認します。
oc get bmh -n example-sno
$ oc get bmh -n example-sno
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATE CONSUMER ONLINE ERROR AGE example-sno provisioned true 69m example-node2 provisioning true 4m50s
NAME STATE CONSUMER ONLINE ERROR AGE example-sno provisioned true 69m example-node2 provisioning true 4m50s
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
provisioning
ステータスは、インストールメディアからのノードの起動が進行中であることを示します。
インストールプロセスを継続的に監視します。
次のコマンドを実行して、エージェントのインストールプロセスを監視します。
oc get agent -n example-sno --watch
$ oc get agent -n example-sno --watch
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノードのインストールが完了すると、ワーカーノードの証明書が自動的に承認されます。この時点で、ワーカーは
ManagedClusterInfo
ステータスで表示されます。次のコマンドを実行して、ステータスを確認します。oc get managedclusterinfo/example-sno -n example-sno -o \ jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'
$ oc get managedclusterinfo/example-sno -n example-sno -o \ jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
example-sno [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""} example-node2 [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/worker":""}
example-sno [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""} example-node2 [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/worker":""}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第14章 シングルノード OpenShift デプロイメント用イメージの事前キャッシュ リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) ソリューションを使用して多数のクラスターをデプロイする、帯域幅が制限された環境では、OpenShift Container Platform のブートストラップとインストールに必要なすべてのイメージをダウンロードすることを避ける必要があります。リモートのシングルノード OpenShift サイトでは帯域幅が制限されているため、デプロイに時間がかかる場合があります。factory-precaching-cli ツールを使用すると、ZTP プロビジョニングのためにサーバーをリモートサイトに出荷する前にサーバーを事前にステージングできます。
factory-precaching-cli ツールは次のことを行います。
- 最小限の ISO の起動に必要な RHCOS rootfs イメージをダウンロードします。
-
data
というラベルの付いたインストールディスクからパーティションを作成します。 - ディスクを xfs でフォーマットします。
- ディスクの最後に GUID パーティションテーブル (GPT) データパーティションを作成します。パーティションのサイズはツールで設定できます。
- OpenShift Container Platform のインストールに必要なコンテナーイメージをコピーします。
- OpenShift Container Platform をインストールするために ZTP が必要とするコンテナーイメージをコピーします。
- オプション: Day-2 Operator をパーティションにコピーします。
factory-precaching-cli ツールは、テクノロジープレビュー機能専用です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
14.1. factory-precaching-cli ツールの入手 リンクのコピーリンクがクリップボードにコピーされました!
factory-precaching-cli ツールの Go バイナリーは、{rds-first} tools container image で公開されています。コンテナーイメージ内の factory-precaching-cli ツール Go バイナリーは、podman
を使用して RHCOS ライブイメージを実行しているサーバー上で実行されます。非接続環境で作業している場合、またはプライベートレジストリーがある場合は、そこにイメージをコピーして、イメージをサーバーにダウンロードできるようにする必要があります。
手順
次のコマンドを実行して、factory-precaching-cli ツールイメージをプルします。
podman pull quay.io/openshift-kni/telco-ran-tools:latest
# podman pull quay.io/openshift-kni/telco-ran-tools:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
ツールが利用可能であることを確認するには、factory-precaching-cli ツール Go バイナリーの現在のバージョンを照会します。
podman run quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli -v
# podman run quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli -v
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
factory-precaching-cli version 20221018.120852+main.feecf17
factory-precaching-cli version 20221018.120852+main.feecf17
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.2. ライブオペレーティングシステムイメージからの起動 リンクのコピーリンクがクリップボードにコピーされました!
factory-precaching-cli ツールを使用して、1 つのディスクしか使用できず、外部ディスクドライブをサーバーに接続できないサーバーを起動できます。
RHCOS では、ディスクが RHCOS イメージで書き込まれようとしているときに、ディスクが使用されていない必要があります。
サーバーハードウェアに応じて、次のいずれかの方法を使用して、空のサーバーに RHCOS ライブ ISO をマウントできます。
- Dell サーバーで Dell RACADM ツールを使用する。
- HP サーバーで HPONCFG ツールを使用する。
- Redfish BMC API を使用する。
マウント手順を自動化することを推奨します。手順を自動化するには、必要なイメージをプルして、ローカル HTTP サーバーでホストする必要があります。
前提条件
- ホストの電源を入れた。
- ホストへのネットワーク接続がある。
この例の手順では、Redfish BMC API を使用して RHCOS ライブ ISO をマウントします。
RHCOS ライブ ISO をマウントします。
仮想メディアのステータスを確認します。
curl --globoff -H "Content-Type: application/json" -H \ "Accept: application/json" -k -X GET --user ${username_password} \ https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1 | python -m json.tool
$ curl --globoff -H "Content-Type: application/json" -H \ "Accept: application/json" -k -X GET --user ${username_password} \ https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1 | python -m json.tool
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ISO ファイルを仮想メディアとしてマウントします。
curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Image": "http://[$HTTPd_IP]/RHCOS-live.iso"}' -X POST https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1/Actions/VirtualMedia.InsertMedia
$ curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Image": "http://[$HTTPd_IP]/RHCOS-live.iso"}' -X POST https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1/Actions/VirtualMedia.InsertMedia
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想メディアから 1 回起動するように起動順序を設定します。
curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Boot":{ "BootSourceOverrideEnabled": "Once", "BootSourceOverrideTarget": "Cd", "BootSourceOverrideMode": "UEFI"}}' -X PATCH https://$BMC_ADDRESS/redfish/v1/Systems/Self
$ curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Boot":{ "BootSourceOverrideEnabled": "Once", "BootSourceOverrideTarget": "Cd", "BootSourceOverrideMode": "UEFI"}}' -X PATCH https://$BMC_ADDRESS/redfish/v1/Systems/Self
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 再起動し、サーバーが仮想メディアから起動していることを確認します。
14.3. ディスクのパーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
完全な事前キャッシュプロセスを実行するには、ライブ ISO から起動し、コンテナーイメージから factory-precaching-cli ツールを使用して、必要なすべてのアーティファクトを分割および事前キャッシュする必要があります。
プロビジョニング中にオペレーティングシステム (RHCOS) がデバイスに書き込まれるときにディスクが使用されていてはならないため、ライブ ISO または RHCOS ライブ ISO が必要です。この手順で単一ディスクサーバーを有効にすることもできます。
前提条件
- パーティショニングされていないディスクがある。
-
quay.io/openshift-kni/telco-ran-tools:latest
イメージにアクセスできます。 - OpenShift Container Platform をインストールし、必要なイメージを事前キャッシュするのに十分なストレージがある。
手順
ディスクがクリアされていることを確認します。
lsblk
# lsblk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 93.8G 0 loop /run/ephemeral loop1 7:1 0 897.3M 1 loop /sysroot sr0 11:0 1 999M 0 rom /run/media/iso nvme0n1 259:1 0 1.5T 0 disk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 93.8G 0 loop /run/ephemeral loop1 7:1 0 897.3M 1 loop /sysroot sr0 11:0 1 999M 0 rom /run/media/iso nvme0n1 259:1 0 1.5T 0 disk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルシステム、RAID、またはパーティションテーブルの署名をデバイスから消去します。
wipefs -a /dev/nvme0n1
# wipefs -a /dev/nvme0n1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
/dev/nvme0n1: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 8 bytes were erased at offset 0x1749a955e00 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/nvme0n1: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 8 bytes were erased at offset 0x1749a955e00 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ディスクが空でない場合、ツールはデバイスのパーティション番号 1 を使用してアーティファクトを事前キャッシュするため、失敗します。
14.3.1. パーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
デバイスの準備ができたら、単一のパーティションと GPT パーティションテーブルを作成します。パーティションは自動的に data
としてラベル付けされ、デバイスの最後に作成されます。そうしないと、パーティションは coreos-installer
によって上書きされます。
coreos-installer
では、パーティションをデバイスの最後に作成し、data
としてラベル付けする必要があります。RHCOS イメージをディスクに書き込むときにパーティションを保存するには、両方の要件が必要です。
前提条件
-
ホストデバイスがフォーマットされているため、コンテナーは
privileged
として実行する必要があります。 -
コンテナー内でプロセスを実行できるように、
/dev
フォルダーをマウントする必要があります。
手順
次の例では、Day 2 Operator の DU プロファイルを事前キャッシュできるようにするため、パーティションのサイズは 250 GiB です。
コンテナーを
privileged
として実行し、ディスクをパーティショニングします。podman run -v /dev:/dev --privileged \ --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli partition \ -d /dev/nvme0n1 \ -s 250
# podman run -v /dev:/dev --privileged \ --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli partition \
1 -d /dev/nvme0n1 \
2 -s 250
3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow ストレージ情報を確認します。
lsblk
# lsblk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次の要件が満たされていることを確認する必要があります。
- デバイスには GPT パーティションテーブルがあります。
- パーティションは、デバイスの最新のセクターを使用します。
-
パーティションは
data
として正しくラベル付けされています。
ディスクのステータスを照会して、ディスクが期待どおりにパーティショニングされていることを確認します。
gdisk -l /dev/nvme0n1
# gdisk -l /dev/nvme0n1
出力例
14.3.2. パーティションのマウント リンクのコピーリンクがクリップボードにコピーされました!
ディスクが正しくパーティショニングされていることを確認したら、デバイスを /mnt
にマウントできます。
GitOps ZTP の準備中にそのマウントポイントが使用されるため、デバイスを /mnt
にマウントすることを推奨します。
パーティションが
xfs
としてフォーマットされていることを確認します。lsblk -f /dev/nvme0n1
# lsblk -f /dev/nvme0n1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 └─nvme0n1p1 xfs 1bee8ea4-d6cf-4339-b690-a76594794071
NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 └─nvme0n1p1 xfs 1bee8ea4-d6cf-4339-b690-a76594794071
Copy to Clipboard Copied! Toggle word wrap Toggle overflow パーティションをマウントします。
mount /dev/nvme0n1p1 /mnt/
# mount /dev/nvme0n1p1 /mnt/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
パーティションがマウントされていることを確認します。
lsblk
# lsblk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- RHCOS の
/mnt
フォルダーは/var/mnt
へのリンクであるため、マウントポイントは/var/mnt
です。
14.4. イメージのダウンロード リンクのコピーリンクがクリップボードにコピーされました!
factory-precaching-cli ツールを使用すると、パーティショニングされたサーバーに次のイメージをダウンロードできます。
- OpenShift Container Platform イメージ
- 5G RAN サイトの分散ユニット (DU) プロファイルに含まれる Operator イメージ
- 切断されたレジストリーからの Operator イメージ
使用可能な Operator イメージのリストは、OpenShift Container Platform リリースごとに異なる場合があります。
14.4.1. 並列ワーカーを使用したダウンロード リンクのコピーリンクがクリップボードにコピーされました!
factory-precaching-cli ツールは、並列ワーカーを使用して複数のイメージを同時にダウンロードします。--parallel
または -p
オプションを使用して、ワーカーの数を設定できます。デフォルトの数値は、サーバーで使用可能な CPU の 80% に設定されています。
ログインシェルが CPU のサブセットに制限されている可能性があります。その場合、コンテナーで使用できる CPU が減少します。この制限を取り除くには、コマンドの前に taskset 0xffffffff
を付けます。次に例を示します。
taskset 0xffffffff podman run --rm quay.io/openshift-kni/telco-ran-tools:latest factory-precaching-cli download --help
# taskset 0xffffffff podman run --rm quay.io/openshift-kni/telco-ran-tools:latest factory-precaching-cli download --help
14.4.2. OpenShift Container Platform イメージのダウンロードの準備 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform コンテナーイメージをダウンロードするには、マルチクラスターエンジンのバージョンを知る必要があります。--du-profile
フラグを使用する場合は、シングルノード OpenShift をプロビジョニングするハブクラスターで実行されている Red Hat Advanced Cluster Management (RHACM) のバージョンも指定する必要があります。
前提条件
- RHACM とマルチクラスターエンジン Operator がインストールされている。
- ストレージデバイスをパーティショニングしている。
- パーティショニングされたデバイスにイメージ用の十分なスペースがある。
- ベアメタルサーバーをインターネットに接続している。
- 有効なプルシークレットがあります。
手順
ハブクラスターで次のコマンドを実行して、RHACM バージョンとマルチクラスターエンジンバージョンを確認します。
oc get csv -A | grep -i advanced-cluster-management
$ oc get csv -A | grep -i advanced-cluster-management
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
open-cluster-management advanced-cluster-management.v2.6.3 Advanced Cluster Management for Kubernetes 2.6.3 advanced-cluster-management.v2.6.3 Succeeded
open-cluster-management advanced-cluster-management.v2.6.3 Advanced Cluster Management for Kubernetes 2.6.3 advanced-cluster-management.v2.6.3 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get csv -A | grep -i multicluster-engine
$ oc get csv -A | grep -i multicluster-engine
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
multicluster-engine cluster-group-upgrades-operator.v0.0.3 cluster-group-upgrades-operator 0.0.3 Pending multicluster-engine multicluster-engine.v2.1.4 multicluster engine for Kubernetes 2.1.4 multicluster-engine.v2.0.3 Succeeded multicluster-engine openshift-gitops-operator.v1.5.7 Red Hat OpenShift GitOps 1.5.7 openshift-gitops-operator.v1.5.6-0.1664915551.p Succeeded multicluster-engine openshift-pipelines-operator-rh.v1.6.4 Red Hat OpenShift Pipelines 1.6.4 openshift-pipelines-operator-rh.v1.6.3 Succeeded
multicluster-engine cluster-group-upgrades-operator.v0.0.3 cluster-group-upgrades-operator 0.0.3 Pending multicluster-engine multicluster-engine.v2.1.4 multicluster engine for Kubernetes 2.1.4 multicluster-engine.v2.0.3 Succeeded multicluster-engine openshift-gitops-operator.v1.5.7 Red Hat OpenShift GitOps 1.5.7 openshift-gitops-operator.v1.5.6-0.1664915551.p Succeeded multicluster-engine openshift-pipelines-operator-rh.v1.6.4 Red Hat OpenShift Pipelines 1.6.4 openshift-pipelines-operator-rh.v1.6.3 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナーレジストリーにアクセスするには、インストールするサーバーに有効なプルシークレットをコピーします。
.docker
フォルダーを作成します。mkdir /root/.docker
$ mkdir /root/.docker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow config.json
ファイルの有効なプルを、以前に作成した.docker/
フォルダーにコピーします。cp config.json /root/.docker/config.json
$ cp config.json /root/.docker/config.json
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/root/.docker/config.json
は、podman
がレジストリーのログイン認証情報をチェックするデフォルトのパスです。
別のレジストリーを使用して必要なアーティファクトをプルする場合は、適切なプルシークレットをコピーする必要があります。ローカルレジストリーが TLS を使用している場合は、レジストリーからの証明書も含める必要があります。
14.4.3. OpenShift Container Platform イメージのダウンロード リンクのコピーリンクがクリップボードにコピーされました!
factory-precaching-cli ツールを使用すると、特定の OpenShift Container Platform リリースをプロビジョニングするために必要なすべてのコンテナーイメージを事前キャッシュできます。
手順
次のコマンドを実行して、リリースを事前キャッシュします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
すべてのイメージがサーバーのターゲットフォルダーに圧縮されていることを確認します。
ls -l /mnt
$ ls -l /mnt
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/mnt
フォルダーにイメージを事前キャッシュしておくことを推奨します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.4.4. Operator イメージのダウンロード リンクのコピーリンクがクリップボードにコピーされました!
また、5G 無線アクセスネットワーク (RAN) 分散ユニット (DU) クラスター設定で使用される Day-2 Operator を事前キャッシュすることもできます。Day-2 Operator は、インストールされている OpenShift Container Platform のバージョンに依存します。
factory-precaching-cli ツールが RHACM およびマルチクラスターエンジン Operator の適切なコンテナーイメージを事前キャッシュできるように、--acm-version
および --mce-version
フラグを使用して、RHACM ハブおよびマルチクラスターエンジン Operator のバージョンを含める必要があります。
手順
Operator イメージを事前キャッシュします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.4.5. 非接続環境でのカスタムイメージの事前キャッシュ リンクのコピーリンクがクリップボードにコピーされました!
--generate-imageset
引数は、ImageSetConfiguration
カスタムリソース (CR) が生成された後に factory-precaching-cli ツールを停止します。これにより、イメージをダウンロードする前に ImageSetConfiguration
CR をカスタマイズできます。CR をカスタマイズしたら、--skip-imageset
引数を使用して、ImageSetConfiguration
CR で指定したイメージをダウンロードできます。
次の方法で ImageSetConfiguration
CR をカスタマイズできます。
- Operator と追加のイメージを追加
- Operator と追加のイメージを削除
- Operator とカタログソースをローカルまたは切断されたレジストリーに変更
手順
イメージを事前キャッシュします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- factory-precaching-cli ツールのダウンロード機能を指定します。
- 2
- OpenShift Container Platform リリースバージョンを定義します。
- 3
- RHACM バージョンを定義します。
- 4
- マルチクラスターエンジンのバージョンを定義します。
- 5
- ディスク上のイメージをダウンロードするフォルダーを定義します。
- 6
- オプション: 追加のイメージを保存するリポジトリーを定義します。これらのイメージはダウンロードされ、ディスクに事前キャッシュされます。
- 7
- DU 設定に含まれる Operator の事前キャッシュを指定します。
- 8
--generate-imageset
引数はImageSetConfiguration
CR のみを生成します。これにより、CR をカスタマイズできます。
出力例
Generated /mnt/imageset.yaml
Generated /mnt/imageset.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImageSetConfiguration CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CR でカタログリソースをカスタマイズします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルレジストリーまたは接続されていないレジストリーを使用してイメージをダウンロードする場合は、最初に、コンテンツの取得元のレジストリーの証明書を追加する必要があります。
エラーを回避するには、レジストリー証明書をサーバーにコピーします。
cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
# cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、証明書トラストストアを更新します。
update-ca-trust
# update-ca-trust
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストの
/etc/pki
フォルダーを factory-cli イメージにマウントします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- factory-precaching-cli ツールのダウンロード機能を指定します。
- 2
- OpenShift Container Platform リリースバージョンを定義します。
- 3
- RHACM バージョンを定義します。
- 4
- マルチクラスターエンジンのバージョンを定義します。
- 5
- ディスク上のイメージをダウンロードするフォルダーを定義します。
- 6
- オプション: 追加のイメージを保存するリポジトリーを定義します。これらのイメージはダウンロードされ、ディスクに事前キャッシュされます。
- 7
- DU 設定に含まれる Operator の事前キャッシュを指定します。
- 8
--skip-imageset
引数を使用すると、カスタマイズしたImageSetConfiguration
CR で指定したイメージをダウンロードできます。
新しい
imageSetConfiguration
CR を生成せずにイメージをダウンロードします。podman run -v /mnt:/mnt -v /root/.docker:/root/.docker --privileged --rm quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli download -r 4.18.0 \ --acm-version 2.6.3 --mce-version 2.1.4 -f /mnt \ --img quay.io/custom/repository \ --du-profile -s \ --skip-imageset
# podman run -v /mnt:/mnt -v /root/.docker:/root/.docker --privileged --rm quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli download -r 4.18.0 \ --acm-version 2.6.3 --mce-version 2.1.4 -f /mnt \ --img quay.io/custom/repository \ --du-profile -s \ --skip-imageset
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.5. GitOps ZTP でのイメージの事前キャッシュ リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig
マニフェストは、OpenShift クラスターをインストールおよび設定する方法を定義します。GitOps Zero Touch Provisioning (ZTP) プロビジョニングワークフローの場合、factory-precaching-cli ツールでは SiteConfig
マニフェストに次の追加フィールドが必要です。
-
clusters.ignitionConfigOverride
-
nodes.installerArgs
-
nodes.ignitionConfigOverride
SiteConfig v1 は、OpenShift Container Platform バージョン 4.18 以降では非推奨になります。ClusterInstance
カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。
SiteConfig Operator の詳細は、SiteConfig を参照してください。
追加フィールドを含む SiteConfig の例
14.5.1. clusters.ignitionConfigOverride フィールドについて リンクのコピーリンクがクリップボードにコピーされました!
clusters.ignitionConfigOverride
フィールドは、GitOps ZTP 検出段階で Ignition 形式の設定を追加します。この設定には、仮想メディアにマウントされた ISO の systemd
サービスが含まれます。これにより、スクリプトが検出 RHCOS ライブ ISO の一部となり、アシステッドインストーラー (AI) イメージのロードにスクリプトを使用できるようになります。
systemd
サービス-
systemd
サービスはvar-mnt.mount
とprecache-images.services
です。precache-images.service
は、var-mnt.mount
ユニットによって/var/mnt
にマウントされるディスクパーティションに依存します。このサービスは、extract-ai.sh
というスクリプトを呼び出します。 extract-ai.sh
-
extract-ai.sh
スクリプトは、必要なイメージをディスクパーティションからローカルコンテナーストレージに展開してロードします。スクリプトが正常に終了したら、イメージをローカルで使用できます。 agent-fix-bz1964591
-
agent-fix-bz1964591
スクリプトは、AI の問題の回避策です。AI がイメージを削除して、agent.service
がレジストリーからイメージを再度プルするように強制するのを防ぐために、agent-fix-bz1964591
スクリプトは、要求されたコンテナーイメージが存在するかどうかを確認します。
14.5.2. nodes.installerArgs フィールドについて リンクのコピーリンクがクリップボードにコピーされました!
nodes.installerArgs
フィールドでは、coreos-installer
ユーティリティーが RHCOS ライブ ISO をディスクに書き込む方法を設定できます。data
とラベル付けされたディスクパーティションを保存するよう指定する必要があります。これは、data
パーティションに保存されたアーティファクトが OpenShift Container Platform のインストール段階で必要になるためです。
追加のパラメーターは、ライブ RHCOS をディスクに書き込む coreos-installer
ユーティリティーに直接渡されます。次回の再起動時に、オペレーティングシステムはディスクから起動します。
coreos-installer
ユーティリティーには、いくつかのオプションを渡すことができます。
14.5.3. nodes.ignitionConfigOverride フィールドについて リンクのコピーリンクがクリップボードにコピーされました!
clusters.ignitionConfigOverride
と同様に、nodes.ignitionConfigOverride
フィールドを使用すると、Ignition 形式の設定を coreos-installer
ユーティリティーに追加できます。ただし、これを追加できるのは、OpenShift Container Platform のインストール段階です。RHCOS がディスクに書き込まれると、GitOps ZTP 検出 ISO に含まれる追加の設定は使用できなくなります。検出段階で、追加の設定はライブ OS のメモリーに保存されます。
この段階では、展開およびロードされたコンテナーイメージの数は、検出段階よりも多くなります。OpenShift Container Platform のリリースと、Day-2 Operators をインストールするかどうかによって、インストール時間は異なります。
インストール段階では、var-mnt.mount
および precache-ocp.services
systemd
サービスが使用されます。
precache-ocp.service
precache-ocp.service
は、var-mnt.mount
ユニットによって/var/mnt
にマウントされるディスクパーティションに依存します。precache-ocp.service
サービスは、extract-ocp.sh
というスクリプトを呼び出します。重要OpenShift Container Platform のインストール前にすべてのイメージを展開するには、
machine-config-daemon-pull.service
およびnodeip-configuration.service
サービスを実行する前にprecache-ocp.service
を実行する必要があります。extract-ocp.sh
-
extract-ocp.sh
スクリプトは、必要なイメージをディスクパーティションからローカルコンテナーストレージに展開してロードします。
SiteConfig
と、オプションの PolicyGenerator
または PolicyGenTemplate
カスタムリソース (CR) を Argo CD が監視している Git リポジトリーにコミットすると、CR をハブクラスターと同期して GitOps ZTP ワークフローを開始できます。
14.6. "Rendered catalog is invalid" エラーのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
ローカルまたは非接続レジストリーを使用してイメージをダウンロードすると、The rendered catalog is invalid
というエラーが表示される場合があります。これは、コンテンツの取得元である新しいレジストリーの証明書が不足していることを意味します。
factory-precaching-cli ツールイメージは、UBI RHEL イメージ上に構築されています。証明書のパスと場所は RHCOS でも同じです。
エラーの例
手順
レジストリー証明書をサーバーにコピーします。
cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
# cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書トラストストアを更新します。
update-ca-trust
# update-ca-trust
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストの
/etc/pki
フォルダーを factory-cli イメージにマウントします。podman run -v /mnt:/mnt -v /root/.docker:/root/.docker -v /etc/pki:/etc/pki --privileged -it --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli download -r 4.18.0 --acm-version 2.5.4 \ --mce-version 2.0.4 -f /mnt \--img quay.io/custom/repository
# podman run -v /mnt:/mnt -v /root/.docker:/root/.docker -v /etc/pki:/etc/pki --privileged -it --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli download -r 4.18.0 --acm-version 2.5.4 \ --mce-version 2.0.4 -f /mnt \--img quay.io/custom/repository --du-profile -s --skip-imageset
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第15章 シングルノード OpenShift クラスターのイメージベースアップグレード リンクのコピーリンクがクリップボードにコピーされました!
15.1. シングルノード OpenShift クラスターのイメージベースのアップグレードについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.14.13 以降では、Lifecycle Agent によって、シングルノード OpenShift クラスターのプラットフォームバージョンをアップグレードする別の方法が提供されます。イメージベースアップグレードは標準のアップグレード方法よりも高速で、OpenShift Container Platform <4.y> から <4.y+2>、<4.y.z> から <4.y.z+n> に直接アップグレードできます。
このアップグレード方法では、ターゲットのシングルノード OpenShift クラスターに新しい ostree
stateroot としてインストールされている専用のシードクラスターから生成された OCI イメージを使用します。シードクラスターは、ターゲットの OpenShift Container Platform バージョン、Day 2 Operator、およびすべてのターゲットクラスターに共通の設定を使用してデプロイされたシングルノード OpenShift クラスターです。
シードクラスターから生成されたシードイメージを使用して、シードクラスターと同じハードウェア、Day 2 Operator、およびクラスター設定の組み合わせを持つ任意のシングルノード OpenShift クラスター上のプラットフォームバージョンをアップグレードできます。
イメージベースアップグレードでは、クラスターが実行されているハードウェアプラットフォームに固有のカスタムイメージが使用されます。それぞれのハードウェアプラットフォームには、個別のシードイメージが必要です。
Lifecycle Agent は、参加しているクラスター上の 2 つのカスタムリソース (CR) を使用してアップグレードを行います。
-
シードクラスターでは、
SeedGenerator
CR によってシードイメージの生成が可能になります。この CR は、シードイメージをプッシュするリポジトリーを指定します。 -
ターゲットクラスターでは、
ImageBasedUpgrade
CR によって、ターゲットクラスターのアップグレード用のシードイメージとワークロードのバックアップ設定が指定されます。
SeedGenerator CR の例
ImageBasedUpgrade CR の例
- 1
ImageBasedUpgrade
CR のステージ。値は、Idle
、Prep
、Upgrade
、またはRollback
になります。- 2
- ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。
- 3
- オプション: ロールバックする時間枠 (秒単位)。最初の再起動後、この時間枠内にアップグレードが完了しないと、ロールバックが実行されます。定義されていないか
0
に設定されている場合は、デフォルト値の1800
秒 (30 分) が使用されます。 - 4
- オプション: アップグレード後に保持するカスタムカタログソースと、ターゲットクラスターに適用する、シードイメージに含まれていない追加のマニフェストを含む
ConfigMap
リソースのリスト。 - 5
- OADP の
Backup
およびRestore
CR を含むConfigMap
リソースのリスト。
15.1.1. イメージベースアップグレードの各ステージ リンクのコピーリンクがクリップボードにコピーされました!
シードクラスターでシードイメージを生成した後、ImageBasedUpgrade
CR で spec.stage
フィールドを以下のいずれかの値に設定することで、ターゲットクラスターのステージを移動できます。
-
Idle
-
Prep
-
Upgrade
-
Rollback
(オプション)
図15.1 イメージベースアップグレードの各ステージ
15.1.1.1. Idle ステージ リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent は、Operator が最初にデプロイされるときに、stage: Idle
に設定された ImageBasedUpgrade
CR を作成します。これはデフォルトのステージです。進行中のアップグレードはなく、クラスターは Prep
ステージに移行する準備ができています。
図15.2 Idle ステージからの移行
Idle
ステージに移行して、次のいずれかの手順も実行します。
- 正常なアップグレードを終了する
- ロールバックを終了する
-
Upgrade
ステージのピボット前フェーズまで、進行中のアップグレードをキャンセルする
Idle
ステージに移行すると、Lifecycle Agent によってリソースが確実にクリーンアップされるため、クラスターの再アップグレードへの準備が整います。
図15.3 Idle ステージへの移行
アップグレードをキャンセルするときに RHACM を使用する場合は、ターゲットのマネージドクラスターから import.open-cluster-management.io/disable-auto-import
アノテーションを削除して、クラスターの自動インポートを再度有効にする必要があります。
15.1.1.2. Prep ステージ リンクのコピーリンクがクリップボードにコピーされました!
このステージは、スケジュールされたメンテナンス期間の前に完了できます。
Prep
ステージでは、ImageBasedUpgrade
CR で以下のアップグレードの詳細を指定します。
- 使用するシードイメージ
- バックアップするリソース
- 適用する追加のマニフェストと、アップグレード後に保持するカスタムカタログソース (ある場合)
次に、指定した内容に基づいて、Lifecycle Agent は現在実行中のバージョンに影響を与えずにアップグレードの準備をします。このステージでは、Lifecycle Agent は、ターゲットクラスターが特定の条件を満たしているかどうかをチェックして、Upgrade
ステージに進む準備ができていることを確認します。Operator により、シードイメージが、シードイメージで指定された追加のコンテナーイメージとともに、ターゲットクラスターにプルされます。Lifecycle Agent は、コンテナーストレージディスクに十分な領域があるかどうかを確認します。必要に応じて、ディスク使用量が指定のしきい値を下回るまで、固定されていないイメージが Operator によって削除されます。コンテナーストレージディスクのクリーンアップを設定または無効にする方法の詳細は、「コンテナーストレージディスクの自動イメージクリーンアップの設定」を参照してください。
また、OADP Operator の Backup
および Restore
CR を使用して、バックアップリソースを準備します。これらの CR は、クラスターを再設定し、クラスターを RHACM に登録して、アプリケーションアーティファクトを復元するために Upgrade
ステージで使用されます。
OADP Operator に加えて、Lifecycle Agent は ostree
バージョン管理システムを使用してバックアップを作成します。これにより、アップグレードとロールバックの両方の後に、クラスターの完全な再設定が可能となります。
Prep
ステージが終了したら、Idle
ステージに移動してアップグレードプロセスをキャンセルするか、ImageBasedUpgrade
CR の Upgrade
ステージに移動してアップグレードを開始できます。アップグレードをキャンセルすると、Operator はクリーンアップ操作を実行します。
図15.4 Prep ステージからの移行
15.1.1.3. Upgrade ステージ リンクのコピーリンクがクリップボードにコピーされました!
Upgrade
ステージは 2 つのフェーズで構成されています。
- ピボット前
-
新しい stateroot にピボットする直前に、Lifecycle Agent は必要なクラスター固有のアーティファクトを収集し、新しい stateroot に保存します。
Prep
ステージで指定されたクラスターリソースのバックアップは、互換性のあるオブジェクトストレージソリューション上に作成されます。Lifecycle Agent は、ImageBasedUpgrade
CR のextraManifests
フィールドに指定された CR、またはターゲットクラスターにバインドされた ZTP ポリシーに記述されている CR をエクスポートします。ピボット前のフェーズが完了すると、Lifecycle Agent は新しい stateroot デプロイメントをデフォルトのブートエントリーとして設定し、ノードを再起動します。 - ピボット後
- 新しい stateroot から起動した後、Lifecycle Agent はシードイメージのクラスター暗号化も再生成します。これにより、同じシードイメージでアップグレードされた各シングルノード OpenShift クラスターに、一意で有効な暗号化オブジェクトが確保されます。次に、Operator は、ピボット前のフェーズで収集されたクラスター固有のアーティファクトを適用して、クラスターを再設定します。Operator は保存されたすべての CR を適用し、バックアップを復元します。
アップグレードが完了し、変更が正常に行われたら、Idle
ステージに移行してアップグレードを終了できます。
アップグレードを終了すると、元のリリースにロールバックすることはできません。
図15.5 Upgrade ステージからの移行
アップグレードをキャンセルする場合は、Upgrade
ステージのピボット前フェーズまではキャンセルできます。アップグレード後に問題が発生した場合は、Rollback
ステージに進んで手動でロールバックすることができます。
15.1.1.4. Rollback ステージ リンクのコピーリンクがクリップボードにコピーされました!
Rollback
ステージは、失敗時に手動または自動で開始できます。Rollback
ステージでは、Lifecycle Agent は元の ostree
stateroot デプロイメントをデフォルトとして設定します。その後、ノードは OpenShift Container Platform の以前のリリースとアプリケーション設定で再起動します。
ロールバック後に Idle
ステージに移行すると、Lifecycle Agent は失敗したアップグレードのトラブルシューティングに使用できるリソースをクリーンアップします。
指定された制限時間内にアップグレードが完了しない場合、Lifecycle Agent は自動ロールバックを開始します。自動ロールバックの詳細は、「Lifecycle Agent を使用した Rollback ステージへの移行」または「Lifecycle Agent と GitOps ZTP を使用した Rollback ステージへの移行」セクションを参照してください。
図15.6 Rollback ステージからの移行
15.1.2. イメージベースアップグレードのガイドライン リンクのコピーリンクがクリップボードにコピーされました!
イメージベースアップグレードを成功させるには、デプロイメントが特定の要件を満たしている必要があります。
イメージベースアップグレードを実行できるさまざまなデプロイメント方法があります。
- GitOps ZTP
- クラスターをデプロイおよび設定するには、GitOps Zero Touch Provisioning (ZTP) を使用します。
- 非 GitOps
- クラスターを手動でデプロイおよび設定します。
非接続環境でイメージベースアップグレードを実行できます。非接続環境でイメージをミラーリングする方法の詳細は、「非接続インストールのイメージのミラーリング」を参照してください。
15.1.2.1. コンポーネントの最小ソフトウェアバージョン リンクのコピーリンクがクリップボードにコピーされました!
デプロイメント方法に応じて、イメージベースアップグレードには次の最小ソフトウェアバージョンが必要です。
コンポーネント | ソフトウェアバージョン | 必須 |
---|---|---|
Lifecycle Agent | 4.16 | はい |
OADP Operator | 1.4.1 | はい |
マネージドクラスターのバージョン | 4.14.13 | はい |
ハブクラスターのバージョン | 4.16 | いいえ |
RHACM | 2.10.2 | いいえ |
GitOps ZTP プラグイン | 4.16 | GitOps ZTP デプロイメント方式のみ |
Red Hat OpenShift GitOps | 1.12 | GitOps ZTP デプロイメント方式のみ |
Topology Aware Lifecycle Manager (TALM) | 4.16 | GitOps ZTP デプロイメント方式のみ |
Local Storage Operator [1] | 4.14 | はい |
論理ボリュームマネージャー (LVM) ストレージ [1] | 4.14.2 | はい |
- 永続ストレージは、LVM Storage または Local Storage Operator のいずれかによって提供される必要があり、両方によって提供される必要はありません。
15.1.2.2. ハブクラスターのガイドライン リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) を使用している場合は、ハブクラスターは次の条件を満たしている必要があります。
- シードイメージに RHACM リソースが含まれないようにするには、シードイメージを生成する前に、オプションの RHACM アドオンをすべて無効にする必要があります。
- ターゲットのシングルノード OpenShift クラスターでイメージベースアップグレードを実行する前に、ハブクラスターを少なくともターゲットバージョンにアップグレードする必要があります。
15.1.2.3. シードイメージのガイドライン リンクのコピーリンクがクリップボードにコピーされました!
シードイメージは、同じハードウェアと同様の設定を持つシングルノードの OpenShift クラスターのセットを対象とします。つまり、シードクラスターは、次の項目についてターゲットクラスターの設定と一致する必要があります。
CPU トポロジー
- CPU コア数
- チューニング済みのパフォーマンス設定 (予約 CPU 数など)
-
ターゲットクラスターの
MachineConfig
リソース IP バージョン
注記このリリースではデュアルスタックネットワークはサポートされていません。
- Lifecycle Agent と OADP Operator を含む Day 2 Operator のセット
- 非接続レジストリー
- FIPS 設定
次の設定は、参加するクラスターで部分的に一致している必要があります。
- ターゲットクラスターにプロキシー設定がある場合、シードクラスターにもプロキシー設定が必要ですが、設定は同じである必要はありません。
-
参加するすべてのクラスターでは、コンテナーストレージ用のプライマリーディスク上に専用のパーティションが必要です。ただし、パーティションのサイズと開始は同じである必要はありません。
MachineConfig
CR 内のspec.config.storage.disks.partitions.label: varlibcontainers
ラベルのみが、シードクラスターとターゲットクラスターの両方で一致する必要があります。ディスクパーティションの作成方法の詳細は、「ostree stateroot 間の共有コンテナーパーティションの設定」または「GitOps ZTP を使用した場合の ostree stateroot 間の共有コンテナーパーティションの設定」を参照してください。
シードイメージに含める内容の詳細は、「シードイメージの設定」および「RAN DU プロファイルを使用したシードイメージの設定」を参照してください。
15.1.2.4. OADP バックアップおよび復元ガイドライン リンクのコピーリンクがクリップボードにコピーされました!
OADP Operator を使用すると、ConfigMap
オブジェクトにラップされた Backup
および Restore
CR を使用して、ターゲットクラスター上のアプリケーションをバックアップおよび復元できます。アプリケーションは、アップグレード後に復元できるように、OpenShift Container Platform の現行バージョンとターゲットバージョンで動作する必要があります。バックアップには、最初に作成されたリソースが含まれている必要があります。
次のリソースはバックアップから除外する必要があります。
-
pods
-
endpoints
-
controllerrevision
-
podmetrics
-
packagemanifest
-
replicaset
-
localvolume
(Local Storage Operator (LSO) を使用する場合)
シングルノード OpenShift には 2 つのローカルストレージ実装があります。
- Local Storage Operator (LSO)
-
Lifecycle Agent は、
localvolume
リソースとそれに関連付けられたStorageClass
リソースを含む、必要なアーティファクトを自動的にバックアップおよび復元します。アプリケーションBackup
CR でpersistentvolumes
リソースを除外する必要があります。 - LVM Storage
-
LVM Storage アーティファクトの
Backup
およびRestore
CR を作成する必要があります。アプリケーションBackup
CR にpersistentVolumes
リソースを含める必要があります。
イメージベースアップグレードの場合、特定のターゲットクラスターでは 1 つの Operator のみがサポートされます。
両方の Operator の場合、ImageBasedUpgrade
CR を介して Operator CR を追加のマニフェストとして適用しないでください。
永続ボリュームの内容は保存され、ピボット後も使用されます。DataProtectionApplication
CR を設定するときは、イメージベースアップグレード用に .spec.configuration.restic.enable
が false
に設定されていることを確認する必要があります。これにより、Container Storage Interface の統合が無効になります。
15.1.2.4.1. lca.openshift.io/apply-wave ガイドライン リンクのコピーリンクがクリップボードにコピーされました!
lca.openshift.io/apply-wave
アノテーションは、Backup
or Restore
CR の適用順序を決定します。アノテーションの値は文字列数値である必要があります。Backup
CR または Restore
CR で lca.openshift.io/apply-wave
アノテーションを定義すると、アノテーションの値に基づいて昇順に適用されます。アノテーションを定義しない場合は、それらが一緒に適用されます。
lca.openshift.io/apply-wave
アノテーションは、プラットフォームの Restore
CR (RHACM や LVM Storage アーティファクトなど) では、アプリケーションのアノテーションよりも数値的に低くする必要があります。これにより、アプリケーションの前にプラットフォームアーティファクトが復元されます。
アプリケーションにクラスタースコープのリソースが含まれている場合は、バックアップの範囲をアプリケーションによって作成された特定のクラスタースコープのリソースに設定するために、個別の Backup
CR と Restore
CR を作成する必要があります。クラスタースコープのリソースの Restore
CR は、残りのアプリケーションの Restore
CR の前に復元する必要があります。
15.1.2.4.2. lca.openshift.io/apply-label ガイドライン リンクのコピーリンクがクリップボードにコピーされました!
lca.openshift.io/apply-label
アノテーションを使用して、特定のリソースのみをバックアップできます。アノテーションで定義したリソースに基づいて、Lifecycle Agent は、Backup
CR の作成時に、指定されたリソースに lca.openshift.io/backup: <backup_name>
ラベルを適用し、labelSelector.matchLabels.lca.openshift.io/backup: <backup_name>
ラベルセレクターを追加します。
特定のリソースをバックアップするために lca.openshift.io/apply-label
アノテーションを使用するには、アノテーションにリストされているリソースも spec
セクションに含める必要があります。lca.openshift.io/apply-label
アノテーションが Backup
CR で使用される場合、spec
セクションで他のリソースタイプが指定されているかどうかに関係なく、アノテーションにリストされているリソースのみがバックアップされます。
CR の例:
- 1
- 値は、クラスタースコープのリソースの場合は
group/version/resource/name
形式、namespace スコープのリソースの場合はgroup/version/resource/namespace/name
形式のコンマ区切りのオブジェクトのリストである必要があり、関連するBackup
CR にアタッチされている必要があります。
15.1.2.5. 追加のマニフェストガイドライン リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent は、新しい stateroot デプロイメントで再起動した後、そしてアプリケーションアーティファクトを復元する前に、追加のマニフェストを使用してターゲットクラスターを復元します。
デプロイメント方法が異なると、追加のマニフェストを適用する方法も異なります。
- GitOps ZTP
lca.openshift.io/target-ocp-version: <target_ocp_version>
ラベルを使用して、ピボット後に Lifecycle Agent が抽出および適用する必要がある追加のマニフェストをマークします。ImageBasedUpgrade
CR のlca.openshift.io/target-ocp-version-manifest-count
アノテーションを使用して、lca.openshift.io/target-ocp-version
のラベルが付けられたマニフェストの数を指定できます。指定されている場合、Lifecycle Agent は、Prep ステージと Upgrade ステージで、ポリシーから抽出されたマニフェストの数がアノテーションで指定された数と一致することを確認します。lca.openshift.io/target-ocp-version-manifest-count アノテーションの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 非 Gitops
-
適用順序を決定するには、追加のマニフェストを
lca.openshift.io/apply-wave
アノテーションでマークします。ラベル付けされた追加マニフェストはConfigMap
オブジェクトにラップされ、ピボット後に Lifecycle Agent が使用するImageBasedUpgrade
CR で参照されます。
ターゲットクラスターがカスタムカタログソースを使用する場合は、正しいリリースバージョンを指す追加のマニフェストとしてそれらを含める必要があります。
以下の項目を追加マニフェストとして適用することはできません。
-
MachineConfig
オブジェクト - OLM Operator サブスクリプション
15.2. シングルノード OpenShift クラスターのイメージベースアップグレードの準備 リンクのコピーリンクがクリップボードにコピーされました!
15.2.2. イメージベースアップグレード用の Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent と OADP Operator をインストールして、アップグレードに向けてクラスターを準備します。
GitOps 以外の方法で OADP Operator をインストールするには、「OADP Operator のインストール」を参照してください。
15.2.2.1. CLI を使用した Lifecycle Agent のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc
) を使用して Lifecycle Agent をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
Lifecycle Agent 用の
Namespace
オブジェクトの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Namespace
CR を作成します。oc create -f <namespace_filename>.yaml
$ oc create -f <namespace_filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lifecycle Agent 用の
OperatorGroup
オブジェクトの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
OperatorGroup
CR を作成します。oc create -f <operatorgroup_filename>.yaml
$ oc create -f <operatorgroup_filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lifecycle Agent 用の
Subscription
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Subscription
CR を作成します。oc create -f <subscription_filename>.yaml
$ oc create -f <subscription_filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
インストールが成功したことを確認するには、次のコマンドを実行して CSV リソースを調べます。
oc get csv -n openshift-lifecycle-agent
$ oc get csv -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE lifecycle-agent.v4.18.0 Openshift Lifecycle Agent 4.18.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE lifecycle-agent.v4.18.0 Openshift Lifecycle Agent 4.18.0 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Lifecycle Agent が起動して実行されていることを確認します。
oc get deploy -n openshift-lifecycle-agent
$ oc get deploy -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE lifecycle-agent-controller-manager 1/1 1 1 14s
NAME READY UP-TO-DATE AVAILABLE AGE lifecycle-agent-controller-manager 1/1 1 1 14s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.2.2. Web コンソールを使用した Lifecycle Agent のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Lifecycle Agent をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
- 利用可能な Operator のリストから Lifecycle Agent を検索し、Install をクリックします。
- Install Operator ページの A specific namespace on the cluster の下で openshift-lifecycle-agent を選択します。
- Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators をクリックします。
Lifecycle Agent が、InstallSucceeded ステータス で openshift-lifecycle-agent プロジェクトにリストされていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator が正常にインストールされていない場合、以下を実行します。
- Operators → Installed Operators をクリックし、Operator Subscriptions タブおよび Install Plans タブの ステータス で障害やエラーがないか検査します。
- Workloads → Pods をクリックし、openshift-lifecycle-agent プロジェクト内の Pod のログを確認します。
15.2.2.3. GitOps ZTP を使用した Lifecycle Agent のインストール リンクのコピーリンクがクリップボードにコピーされました!
イメージベースアップグレードを実行するには、GitOps Zero Touch Provisioning (ZTP) を使用して Lifecycle Agent をインストールします。
手順
ztp-site-generate
コンテナーイメージから次の CR を抽出し、source-cr
ディレクトリーにプッシュします。LcaSubscriptionNS.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow LcaSubscriptionOperGroup.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow LcaSubscription.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリー構造の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 共通の
PolicyGenTemplate
に CR を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.2.4. GitOps ZTP を使用した OADP Operator のインストールと設定 リンクのコピーリンクがクリップボードにコピーされました!
アップグレードを開始する前に、GitOps ZTP を使用して OADP Operator をインストールして設定します。
手順
ztp-site-generate
コンテナーイメージから次の CR を抽出し、source-cr
ディレクトリーにプッシュします。OadpSubscriptionNS.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow OadpSubscriptionOperGroup.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow OadpSubscription.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow OadpOperatorStatus.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリー構造の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 共通の
PolicyGenTemplate
に CR を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲットクラスター専用の
DataProtectionApplication
CR と S3 シークレットを作成します。ztp-site-generate
コンテナーイメージから次の CR を抽出し、source-cr
ディレクトリーにプッシュします。OadpDataProtectionApplication.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 永続ボリュームの内容はアップグレード後に保持され、再利用されるため、イメージベースアップグレードでは
spec.configuration.restic.enable
フィールドをfalse
に設定する必要があります。 - 2 3
- バケットは、S3 バックエンドで作成されるバケット名を定義します。接頭辞は、バケット内に自動的に作成されるサブディレクトリーの名前を定義します。バケットと接頭辞の組み合わせは、それらの間の干渉を避けるために、各ターゲットクラスターごとに一意である必要があります。各ターゲットクラスターに一意のストレージディレクトリーを確保するには、Red Hat Advanced Cluster Management のハブテンプレート機能を使用できます (例:
prefix: {{hub .ManagedClusterName hub}}
)。
OadpSecret.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow OadpBackupStorageLocationStatus.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
BackupStorageLocation
リソースのname
の値は、<DataProtectionApplication.metadata.name>-<index>
というパターンに従う必要があります。<index>
は、DataProtectionApplication
リソースのspec.backupLocations
フィールド内の対応するbackupLocations
エントリーの位置を表します。位置は1
から始まります。OadpDataProtectionApplication.yaml
ファイルでDataProtectionApplication
リソースのmetadata.name
値が変更された場合は、それに応じてBackupStorageLocation
リソースのmetadata.name
フィールドを更新します。
OadpBackupStorageLocationStatus.yaml
CR は、OADP によって作成されたバックアップストレージの場所の可用性を確認します。オーバーライドを使用して、サイトの
PolicyGenTemplate
に CR を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- S3 ストレージバックエンドの認証情報を指定します。
- 2
OadpDataProtectionApplication
CR に複数のbackupLocations
エントリーが定義されている場合は、ステータス追跡のために、対応するOadpBackupStorageLocation
CR がそれぞれの場所に追加されていることを確認します。追加の各OadpBackupStorageLocation
CR の名前が、OadpBackupStorageLocationStatus.yaml
ファイルの例で説明されている正しいインデックスでオーバーライドされていることを確認してください。- 3
- S3 互換バケットの URL を指定します。
- 4 5
bucket
は、S3 バックエンドで作成されるバケット名を定義します。prefix
は、bucket
内に自動的に作成されるサブディレクトリーの名前を定義します。bucket
とprefix
の組み合わせは、それらの間の干渉を避けるために、各ターゲットクラスターごとに一意である必要があります。各ターゲットクラスターに一意のストレージディレクトリーを確保するには、Red Hat Advanced Cluster Management のハブテンプレート機能を使用できます (例:prefix: {{hub .ManagedClusterName hub}}
)。
15.2.3. Lifecycle Agent を使用したイメージベースアップグレード用のシードイメージの生成 リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent を使用して、SeedGenerator
カスタムリソース (CR) でシードイメージを生成します。
15.2.3.1. シードイメージの設定 リンクのコピーリンクがクリップボードにコピーされました!
シードイメージは、同じハードウェアと同様の設定を持つシングルノードの OpenShift クラスターのセットを対象とします。つまり、シードイメージには、シードクラスターがターゲットクラスターと共有するすべてのコンポーネントと設定が含まれている必要があります。したがって、シードクラスターから生成されたシードイメージには、クラスター固有の設定を含めることはできません。
次の表は、シードイメージに含めるべき、および含めるべきでないコンポーネント、リソース、設定を示しています。
Cluster configuration | シードイメージに含める |
---|---|
パフォーマンスプロファイル | はい |
ターゲットクラスターの | はい |
IP バージョン [1] | はい |
Lifecycle Agent と OADP Operator を含む Day 2 Operator のセット | はい |
切断されたレジストリー設定 [2] | はい |
有効なプロキシー設定 [3] | はい |
FIPS 設定 | はい |
ターゲットクラスターのサイズに一致する、コンテナーストレージ用のプライマリーディスク上の専用パーティション | はい |
ローカルボリューム
| いいえ |
OADP | いいえ |
- このリリースではデュアルスタックネットワークはサポートされていません。
- シードクラスターが非接続環境にインストールされている場合は、ターゲットクラスターも非接続環境にインストールする必要があります。
- プロキシー設定は、シードクラスターとターゲットクラスターの両方で有効または無効にする必要があります。ただし、クラスター上で設定されている複数のプロキシーサーバーが同じである必要はありません。
15.2.3.1.1. RAN DU プロファイルを使用したシードイメージの設定 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、RAN DU プロファイルを使用する際にシードイメージに含めるべき、および含めるべきでないコンポーネント、リソース、設定を示しています。
リソース | シードイメージに含める |
---|---|
Day 0 インストールの一部として適用されるすべての追加マニフェスト | はい |
すべての Day 2 Operator サブスクリプション | はい |
| はい |
| はい |
| はい |
| はい |
| はい |
|
☓ ( |
| いいえ |
| いいえ |
リソース | 追加マニフェストとして適用 |
---|---|
| はい 注記
DU プロファイルには Cluster Logging Operator が含まれますが、このプロファイルでは Cluster Logging Operator CR は設定または適用されません。ログ転送を有効にするには、追加のマニフェストとして |
| はい |
| はい |
| はい |
| はい |
| ターゲットクラスターのインターフェイスがシードクラスターと共通である場合は、それらをシードイメージに含めることができます。それ以外の場合は、追加のマニフェストとして適用します。 |
| namespace を含む設定がシードクラスターとターゲットクラスターの両方でまったく同じである場合は、それらをシードイメージに含めることができます。それ以外の場合は、追加のマニフェストとして適用します。 |
15.2.3.2. Lifecycle Agent を使用したシードイメージの生成 リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent を使用して、マネージドクラスターからシードイメージを生成します。Operator は、必要なシステム設定を確認し、シードイメージを生成する前に必要なシステムクリーンアップを実行して、イメージ生成を開始します。シードイメージの生成には、次のタスクが含まれます。
- クラスター Operator の停止
- シードイメージ設定の準備
-
シードイメージの生成および
SeedGenerator
CR で指定されたイメージリポジトリーへのシードイメージのプッシュ - クラスター Operator の復元
- 期限切れのシードクラスター証明書
- シードクラスター用の新しい証明書の生成
-
シードクラスター上の
SeedGenerator
CR の復元と更新
前提条件
- RHACM と multicluster engine for Kubernetes Operator はシードクラスターにインストールされていません。
- シードクラスターに共有コンテナーディレクトリーを設定した。
- シードクラスターに OADP Operator と Lifecycle Agent の最小バージョンをインストールした。
- シードクラスターに永続ボリュームが設定されていないことを確認する。
-
Local Storage Operator が使用されている場合は、シードクラスターに
LocalVolume
CR が存在しないことを確認する。 -
LVM ストレージが使用されている場合は、シードクラスターに
LVMCluster
CR が存在しないことを確認する。 -
OADP が使用されている場合は、シードクラスターに
DataProtectionApplication
CR が存在しないことを確認する。
手順
マネージドクラスターをハブからデタッチして、シードイメージに含まれてはならない RHACM 固有のリソースをシードクラスターから削除します。
次のコマンドを実行してシードクラスターを手動でデタッチします。
oc delete managedcluster sno-worker-example
$ oc delete managedcluster sno-worker-example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
マネージドクラスターが削除されるまで待機します。クラスターが削除されたら、適切な
SeedGenerator
CR を作成します。Lifecycle Agent は RHACM アーティファクトをクリーンアップします。
-
マネージドクラスターが削除されるまで待機します。クラスターが削除されたら、適切な
GitOps ZTP を使用している場合は、シードクラスターの
SiteConfig
CR をkustomization.yaml
から削除してクラスターをデタッチします。複数の
SiteConfig
CR を参照するkustomization.yaml
ファイルがある場合は、シードクラスターのSiteConfig
CR をkustomization.yaml
から削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 1 つの
SiteConfig
CR を参照するkustomization.yaml
がある場合は、シードクラスターのSiteConfig
CR をkustomization.yaml
から削除し、generators: {}
行を追加します。apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: {}
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: {}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git リポジトリーで
kustomization.yaml
の変更をコミットし、変更をリポジトリーにプッシュします。ArgoCD パイプラインは変更を検出し、マネージドクラスターを削除します。
シードイメージをレジストリーにプッシュできるように、
Secret
オブジェクトを作成します。次のコマンドを実行して認証ファイルを作成します。
MY_USER=myuserid AUTHFILE=/tmp/my-auth.json podman login --authfile ${AUTHFILE} -u ${MY_USER} quay.io/${MY_USER}
$ MY_USER=myuserid $ AUTHFILE=/tmp/my-auth.json $ podman login --authfile ${AUTHFILE} -u ${MY_USER} quay.io/${MY_USER}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow base64 -w 0 ${AUTHFILE} ; echo
$ base64 -w 0 ${AUTHFILE} ; echo
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力を、
openshift-lifecycle-agent
namespace のseedgen
という名前のSecret
YAML ファイルのseedAuth
フィールドにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Secret
を適用します。oc apply -f secretseedgenerator.yaml
$ oc apply -f secretseedgenerator.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
SeedGenerator
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してシードイメージを生成します。
oc apply -f seedgenerator.yaml
$ oc apply -f seedgenerator.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Lifecycle Agent がシードイメージを生成している間、クラスターが再起動し、API 機能が失われます。
SeedGenerator
CR を適用すると、kubelet
と CRI-O の操作が停止し、イメージ生成が開始されます。
より多くのシードイメージを生成する場合は、シードイメージを生成するバージョンで新しいシードクラスターをプロビジョニングする必要があります。
検証
クラスターが回復して使用可能になったら、次のコマンドを実行して
SeedGenerator
CR のステータスを確認できます。oc get seedgenerator -o yaml
$ oc get seedgenerator -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- シードイメージの生成が完了しました。
15.2.4. Lifecycle Agent を使用したイメージベースアップグレード用の ConfigMap オブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent では、イメージベースアップグレード用に処理するために、すべての OADP リソース、追加のマニフェスト、およびカスタムカタログソースが ConfigMap
オブジェクトにラップされている必要があります。
15.2.4.1. Lifecycle Agent を使用したイメージベースアップグレード用の OADP ConfigMap オブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
アップグレード中にリソースをバックアップおよび復元するために使用される OADP リソースを作成します。
前提条件
- 互換性のあるシードクラスターからシードイメージを生成した。
- OADP のバックアップおよび復元リソースを作成した。
- stateroot 間で共有されるコンテナーイメージ用に、ターゲットクラスターに個別のパーティションを作成した。詳細は、「イメージベースアップグレード用の共有コンテナーパーティションの設定」を参照してください。
- シードイメージで使用されるバージョンと互換性のあるバージョンの Lifecycle Agent をデプロイした。
-
OADP Operator、
DataProtectionApplication
CR、およびそのシークレットをターゲットクラスターにインストールした。 - S3 互換のストレージソリューションとすぐに使用できるバケットを作成し、適切な認証情報を設定した。詳細は、「OADP のインストールについて」を参照してください。
手順
OADP Operator がインストールされているのと同じ namespace (
openshift-adp
) に、プラットフォームアーティファクトの OADPBackup
CR およびRestore
CR を作成します。ターゲットクラスターが RHACM によって管理されている場合は、RHACM アーティファクトをバックアップおよび復元するために次の YAML ファイルを追加します。
RHACM 用の PlatformBackupRestore.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
multiclusterHub
CR に.spec.imagePullSecret
が定義されておらず、ハブクラスターのopen-cluster-management-agent
namespace にシークレットが存在しない場合は、v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials
を削除します。
LVM Storage を介してクラスター上に永続ボリュームを作成した場合は、LVM Storage アーティファクトに次の YAML ファイルを追加します。
LVM Storage 用の PlatformBackupRestoreLvms.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
lca.openshift.io/apply-wave
の値は、アプリケーションのRestore
CR で指定された値よりも低くする必要があります。
アップグレード後にアプリケーションを復元する必要がある場合は、
openshift-adp
namespace にアプリケーションの OADPBackup
CR およびRestore
CR を作成します。openshift-adp
namespace にクラスタースコープのアプリケーションアーティファクト用の OADP CR を作成します。LSO および LVM Storage のクラスタースコープアプリケーションアーティファクトの OADP CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace スコープのアプリケーションアーティファクト用の OADP CR を作成します。
LSO が使用される場合の OADP CR の namespace スコープのアプリケーションアーティファクトの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アプリケーションのカスタムリソースを定義します。
LVM Storage が使用されている場合の OADP CR namespace スコープのアプリケーションアーティファクトの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要アプリケーションの同じバージョンが、OpenShift Container Platform の現在のリリースとターゲットリリースの両方で機能する必要があります。
次のコマンドを実行して、OADP CR の
ConfigMap
オブジェクトを作成します。oc create configmap oadp-cm-example --from-file=example-oadp-resources.yaml=<path_to_oadp_crs> -n openshift-adp
$ oc create configmap oadp-cm-example --from-file=example-oadp-resources.yaml=<path_to_oadp_crs> -n openshift-adp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ImageBasedUpgrade
CR にパッチを適用します。oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"oadpContent": [{"name": "oadp-cm-example", "namespace": "openshift-adp"}]}}' \ --type=merge -n openshift-lifecycle-agent
$ oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"oadpContent": [{"name": "oadp-cm-example", "namespace": "openshift-adp"}]}}' \ --type=merge -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.4.2. Lifecycle Agent を使用したイメージベースアップグレード用の追加マニフェストの ConfigMap オブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
ターゲットクラスターに適用する追加のマニフェストを作成します。
複数のマニフェストを追加し、マニフェストを特定の順序で適用する必要がある場合は、マニフェストのファイル名の前に、必要な順序を表す数字を付ける必要があります。たとえば、00-namespace.yaml
、01-sriov-extra-manifest.yaml
などです。
手順
SR-IOV などの追加マニフェストを含む YAML ファイルを作成します。
SR-IOV リソースの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
ConfigMap
オブジェクトを作成します。oc create configmap example-extra-manifests-cm --from-file=example-extra-manifests.yaml=<path_to_extramanifest> -n openshift-lifecycle-agent
$ oc create configmap example-extra-manifests-cm --from-file=example-extra-manifests.yaml=<path_to_extramanifest> -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ImageBasedUpgrade
CR にパッチを適用します。oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"extraManifests": [{"name": "example-extra-manifests-cm", "namespace": "openshift-lifecycle-agent"}]}}' \ --type=merge -n openshift-lifecycle-agent
$ oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"extraManifests": [{"name": "example-extra-manifests-cm", "namespace": "openshift-lifecycle-agent"}]}}' \ --type=merge -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.4.3. Lifecycle Agent を使用したイメージベースのアップグレード用のカスタムカタログソースの ConfigMap オブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
カタログソースの ConfigMap
オブジェクトを生成し、それを ImageBasedUpgrade
CR の spec.extraManifest
フィールドに追加することで、アップグレード後もカスタムカタログソースを保持できます。カタログソースの詳細は、「カタログソース」を参照してください。
手順
CatalogSource
CR を含む YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
ConfigMap
オブジェクトを作成します。oc create configmap example-catalogsources-cm --from-file=example-catalogsources.yaml=<path_to_catalogsource_cr> -n openshift-lifecycle-agent
$ oc create configmap example-catalogsources-cm --from-file=example-catalogsources.yaml=<path_to_catalogsource_cr> -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ImageBasedUpgrade
CR にパッチを適用します。oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"extraManifests": [{"name": "example-catalogsources-cm", "namespace": "openshift-lifecycle-agent"}]}}' \ --type=merge -n openshift-lifecycle-agent
$ oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"extraManifests": [{"name": "example-catalogsources-cm", "namespace": "openshift-lifecycle-agent"}]}}' \ --type=merge -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.5. GitOps ZTP を使用した Lifecycle Agent によるイメージベースアップグレード用の ConfigMap オブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
イメージベースアップグレードに備えて、ConfigMap
オブジェクトにラップされた OADP リソース、追加のマニフェスト、カスタムカタログソースを作成します。
15.2.5.1. GitOps ZTP を使用したイメージベースアップグレード用の OADP リソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
アップグレード後にアプリケーションを復元できるように OADP リソースを準備します。
前提条件
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングした。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - 互換性のあるシードクラスターからシードイメージを生成した。
- stateroot 間で共有されるコンテナーイメージ用に、ターゲットクラスターに個別のパーティションを作成した。詳細は、「GitOps ZTP を使用した場合の ostree stateroot 間の共有コンテナーパーティションの設定」を参照してください。
- シードイメージで使用されるバージョンと互換性のあるバージョンの Lifecycle Agent をデプロイした。
-
OADP Operator、
DataProtectionApplication
CR、およびそのシークレットをターゲットクラスターにインストールした。 - S3 互換のストレージソリューションとすぐに使用できるバケットを作成し、適切な認証情報を設定した。詳細は、「GitOps ZTP を使用した OADP Operator のインストールと設定」を参照してください。
-
OADP
ConfigMap
を生成してクラスターにコピーできるように、OADPConfigMap
オブジェクト用のopenshift-adp
namespace が、すべてのマネージドクラスターとハブに存在する。
手順
ArgoCD ポリシーアプリケーションで使用する Git リポジトリーに次のディレクトリー構造が含まれていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow source-crs/ibu/PlatformBackupRestoreWithIBGU.yaml
ファイルは、ZTP コンテナーイメージで提供されます。PlatformBackupRestoreWithIBGU.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
multiclusterHub
CR に.spec.imagePullSecret
が定義されておらず、ハブクラスターのopen-cluster-management-agent
namespace にシークレットが存在しない場合は、v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials
を削除します。
注記マネージドクラスターでイメージベースのアップグレードを直接実行する場合は、
PlatformBackupRestore.yaml
ファイルを使用します。LVM Storage を使用して永続ボリュームを作成する場合は、ZTP コンテナーイメージで提供される
source-crs/ibu/PlatformBackupRestoreLvms.yaml
を使用して、LVM Storage リソースをバックアップできます。PlatformBackupRestoreLvms.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
lca.openshift.io/apply-wave
の値は、アプリケーションのRestore
CR で指定された値よりも低くする必要があります。
アップグレード後にアプリケーションを復元する必要がある場合は、
openshift-adp
namespace にアプリケーションの OADPBackup
CR およびRestore
CR を作成します。openshift-adp
namespace にクラスタースコープのアプリケーションアーティファクト用の OADP CR を作成します。LSO および LVM Storage のクラスタースコープアプリケーションアーティファクトの OADP CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace スコープのアプリケーションアーティファクト用の OADP CR を
source-crs/custom-crs
ディレクトリーに作成します。LSO が使用される場合の OADP CR の namespace スコープのアプリケーションアーティファクトの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アプリケーションのカスタムリソースを定義します。
LVM Storage が使用されている場合の OADP CR namespace スコープのアプリケーションアーティファクトの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要アプリケーションの同じバージョンが、OpenShift Container Platform の現在のリリースとターゲットリリースの両方で機能する必要があります。
次の内容を含む
kustomization.yaml
を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を Git リポジトリーにプッシュします。
15.2.5.2. GitOps ZTP を使用したイメージベースアップグレード用の追加マニフェストのラベル付け リンクのコピーリンクがクリップボードにコピーされました!
追加のマニフェストにラベルを付けて、Lifecycle Agent が lca.openshift.io/target-ocp-version: <target_version>
ラベルでラベル付けされたリソースを抽出できるようにします。
前提条件
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングした。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - 互換性のあるシードクラスターからシードイメージを生成した。
- stateroot 間で共有されるコンテナーイメージ用に、ターゲットクラスターに個別のパーティションを作成した。詳細は、「GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定」を参照してください。
- シードイメージで使用されるバージョンと互換性のあるバージョンの Lifecycle Agent をデプロイした。
手順
既存のサイトの
PolicyGenTemplate
CR で、必要な追加マニフェストにlca.openshift.io/target-ocp-version: <target_version>
ラベルを付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を Git リポジトリーにプッシュします。
15.2.6. コンテナーストレージディスクの自動イメージクリーンアップの設定 リンクのコピーリンクがクリップボードにコピーされました!
使用可能なストレージ領域の最小しきい値をアノテーションによって設定することで、Prep
ステージにおいて Lifecycle Agent が固定されていないイメージをクリーンアップするときの条件を設定します。デフォルトのコンテナーストレージディスク使用量のしきい値は 50% です。
Lifecycle Agent は、CRI-O に固定されているイメージや現在使用されているイメージを削除しません。Operator は、まずダングリング (dangling) 状態のイメージから削除するイメージを選択します。さらに、イメージの Created
タイムスタンプに基づいて最も古いイメージから新しいイメージの順に並べ替えることで、削除するイメージを選択します。
15.2.6.1. コンテナーストレージディスクの自動イメージクリーンアップの設定 リンクのコピーリンクがクリップボードにコピーされました!
アノテーションにより、使用可能なストレージ領域の最小しきい値を設定します。
前提条件
-
ImageBasedUpgrade
CR を作成した。
手順
次のコマンドを実行して、しきい値を 65% に増やします。
oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/disk-usage-threshold-percent='65'
$ oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/disk-usage-threshold-percent='65'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow (オプション) 次のコマンドを実行して、しきい値のオーバーライドを削除します。
oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/disk-usage-threshold-percent-
$ oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/disk-usage-threshold-percent-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.6.2. コンテナーストレージディスクの自動イメージクリーンアップの無効化 リンクのコピーリンクがクリップボードにコピーされました!
自動イメージクリーンアップのしきい値を無効にします。
手順
次のコマンドを実行して、自動イメージクリーンアップを無効にします。
oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/on-prep='Disabled'
$ oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/on-prep='Disabled'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow (オプション) 次のコマンドを実行して、自動イメージクリーンアップを再度有効にします。
oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/on-prep-
$ oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/on-prep-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3. Lifecycle Agent を使用したシングルノード OpenShift クラスターのイメージベースアップグレードの実行 リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent を使用して、シングルノード OpenShift クラスターのイメージベースアップグレードを手動で実行できます。
クラスターに Lifecycle Agent をデプロイすると、ImageBasedUpgrade
CR が自動的に作成されます。この CR を更新して、シードイメージのイメージリポジトリーを指定し、さまざまなステージを移動します。
15.3.1. Lifecycle Agent を使用したイメージベースアップグレードの Prep ステージへの移行 リンクのコピーリンクがクリップボードにコピーされました!
クラスターに Lifecycle Agent をデプロイすると、ImageBasedUpgrade
カスタムリソース (CR) が自動的に作成されます。
アップグレード中に必要なすべてのリソースを作成したら、Prep
ステージに進むことができます。詳細は、「Lifecycle Agent を使用したイメージベースアップグレード用の ConfigMap オブジェクトの作成」セクションを参照してください。
非接続環境で、シードクラスターのリリースイメージレジストリーがターゲットクラスターのリリースイメージレジストリーと異なる場合は、ImageDigestMirrorSet
(IDMS) リソースを作成して、別のミラーリングされるリポジトリーの場所を設定する必要があります。詳細は、「イメージレジストリーのリポジトリーミラーリングの設定」を参照してください。
次のコマンドを実行すると、シードイメージで使用されているリリースレジストリーを取得できます。
skopeo inspect docker://<imagename> | jq -r '.Labels."com.openshift.lifecycle-agent.seed_cluster_info" | fromjson | .release_registry'
$ skopeo inspect docker://<imagename> | jq -r '.Labels."com.openshift.lifecycle-agent.seed_cluster_info" | fromjson | .release_registry'
前提条件
- クラスターをバックアップおよび復元するためのリソースを作成している。
手順
ImageBasedUpgrade
CR にパッチが適用されていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ターゲットプラットフォームのバージョン。値はシードイメージのバージョンと一致する必要があります。
- 2
- ターゲットクラスターがシードイメージをプルできるリポジトリー。
- 3
- イメージがプライベートレジストリー内にある場合にコンテナーイメージをプルするための認証情報を含むシークレットへの参照。
- 4
- オプション: ロールバックする時間枠 (秒単位)。最初の再起動後、この時間枠内にアップグレードが完了しないと、ロールバックが実行されます。定義されていないか
0
に設定されている場合は、デフォルト値の1800
秒 (30 分) が使用されます。 - 5
- オプション: アップグレード後に保持するカスタムカタログソースと、ターゲットクラスターに適用する、シードイメージに含まれていない追加のマニフェストを含む
ConfigMap
リソースのリスト。 - 6
- OADP の
Backup
およびRestore
CR を含むConfigMap
リソースのリスト。
Prep
ステージを開始するには、次のコマンドを実行して、ImageBasedUpgrade
CR のstage
フィールドの値をPrep
に変更します。oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agent
$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OADP リソースと追加のマニフェストの
ConfigMap
オブジェクトを指定すると、Lifecycle Agent はPrep
ステージで指定されたConfigMap
オブジェクトを検証します。以下の問題が発生する可能性があります。-
Lifecycle Agent が
extraManifests
パラメーターに問題を検出した場合の検証警告またはエラー。 -
Lifecycle Agent が
oadpContent
パラメーターに問題を検出した場合の検証エラー。
検証警告は
Upgrade
ステージをブロックしませんが、アップグレードを続行しても安全かどうかを判断する必要があります。これらの警告 (CRD の欠落、namespace の欠落、またはドライランの失敗など) は、警告に関する詳細でPrep
ステージのstatus.conditions
とImageBasedUpgrade
CR のannotation
フィールドを更新します。検証警告の例
# ... metadata: annotations: extra-manifest.lca.openshift.io/validation-warning: '...' # ...
# ... metadata: annotations: extra-manifest.lca.openshift.io/validation-warning: '...' # ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ただし、
MachineConfig
または Operator マニフェストを追加マニフェストに追加するなどの検証エラーが発生すると、Prep
ステージが失敗し、Upgrade
ステージがブロックされます。検証に合格すると、クラスターは新しい
ostree
stateroot を作成します。これには、シードイメージのプルと展開、およびホストレベルのコマンドの実行が含まれます。最後に、必要なすべてのイメージがターゲットクラスターに事前キャッシュされます。-
Lifecycle Agent が
検証
次のコマンドを実行して、
ImageBasedUpgrade
CR のステータスを確認します。oc get ibu -o yaml
$ oc get ibu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.2. Lifecycle Agent を使用したイメージベースアップグレードの Upgrade ステージへの移行 リンクのコピーリンクがクリップボードにコピーされました!
シードイメージを生成し、Prep
ステージを完了したら、ターゲットクラスターをアップグレードできます。アップグレードプロセス中に、OADP Operator は OADP カスタムリソース (CR) で指定されたアーティファクトのバックアップを作成し、その後、Lifecycle Agent がクラスターをアップグレードします。
アップグレードが失敗または停止した場合は、自動ロールバックが開始されます。アップグレード後に問題が発生した場合は、手動でロールバックを開始できます。手動ロールバックの詳細は、「Lifecycle Agent を使用したイメージベースアップグレードの Rollback ステージへの移行」を参照してください。
前提条件
-
Prep
ステージを完了した。
手順
Upgrade
ステージに移動するには、次のコマンドを実行して、ImageBasedUpgrade
CR のstage
フィールドの値をUpgrade
に変更します。oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Upgrade"}}' --type=merge
$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Upgrade"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ImageBasedUpgrade
CR のステータスを確認します。oc get ibu -o yaml
$ oc get ibu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OADP Operator は、OADP
Backup
およびRestore
CR で指定されたデータのバックアップを作成し、ターゲットクラスターが再起動します。次のコマンドを実行して、CR のステータスを監視します。
oc get ibu -o yaml
$ oc get ibu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 正常にアップグレードされたら、次のコマンドを実行して、
ImageBasedUpgrade
CR のstage
フィールドの値をIdle
にパッチして、変更を終了します。oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge
$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要アップグレード後に
Idle
ステージに移行すると、変更をロールバックすることはできません。Lifecycle Agent は、アップグレードプロセス中に作成されたすべてのリソースを削除します。
- アップグレードが成功したら、OADP Operator とその設定ファイルを削除できます。詳細は、「クラスターからの Operator の削除」を参照してください。
検証
次のコマンドを実行して、
ImageBasedUpgrade
CR のステータスを確認します。oc get ibu -o yaml
$ oc get ibu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターの復元ステータスを確認します。
oc get restores -n openshift-adp -o custom-columns=NAME:.metadata.name,Status:.status.phase,Reason:.status.failureReason
$ oc get restores -n openshift-adp -o custom-columns=NAME:.metadata.name,Status:.status.phase,Reason:.status.failureReason
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME Status Reason acm-klusterlet Completed <none> apache-app Completed <none> localvolume Completed <none>
NAME Status Reason acm-klusterlet Completed <none>
1 apache-app Completed <none> localvolume Completed <none>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
acm-klusterlet
は RHACM 環境にのみ固有です。
15.3.3. Lifecycle Agent を使用したイメージベースアップグレードの Rollback ステージへの移行 リンクのコピーリンクがクリップボードにコピーされました!
再起動後、initMonitorTimeoutSeconds
フィールドに指定された時間枠内にアップグレードが完了しない場合は、自動ロールバックが開始されます。
ImageBasedUpgrade CR の例
- 1
- オプション: ロールバックする時間枠 (秒単位)。最初の再起動後、この時間枠内にアップグレードが完了しないと、ロールバックが実行されます。定義されていないか
0
に設定されている場合は、デフォルト値の1800
秒 (30 分) が使用されます。
アップグレード後に解決できない問題が発生した場合は、変更を手動でロールバックできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - 元の stateroot 上のコントロールプレーン証明書が有効であることを確認した。証明書の有効期限が切れている場合は、「コントロールプレーン証明書の期限切れの状態からのリカバリー」を参照してください。
手順
Rollback ステージに移行するには、次のコマンドを実行して、
ImageBasedUpgrade
CR のstage
フィールドの値をRollback
にパッチします。oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Rollback"}}' --type=merge
$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Rollback"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lifecycle Agent は、以前にインストールされたバージョンの OpenShift Container Platform を使用してクラスターを再起動し、アプリケーションを復元します。
正常に変更されたら、次のコマンドを実行して、
ImageBasedUpgrade
CR のstage
フィールドの値をIdle
にパッチして、ロールバックを終了します。oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge -n openshift-lifecycle-agent
$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告ロールバック後に
Idle
ステージに移行すると、Lifecycle Agent は失敗したアップグレードのトラブルシューティングに使用できるリソースをクリーンアップします。
15.3.4. Lifecycle Agent を使用したイメージベースアップグレードのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
問題の影響を受けるマネージドクラスターでトラブルシューティング手順を実行します。
ImageBasedGroupUpgrade
CR を使用してクラスターをアップグレードする場合は、マネージドクラスターでトラブルシューティングまたは復元手順を実行した後、lcm.openshift.io/ibgu-<stage>-completed
または lcm.openshift.io/ibgu-<stage>-failed
クラスターラベルが適切に更新されていることを確認してください。これにより、TALM がクラスターのイメージベースのアップグレードを引き続き管理できるようになります。
15.3.4.1. ログの収集 リンクのコピーリンクがクリップボードにコピーされました!
oc adm must-gather
CLI を使用して、デバッグとトラブルシューティングのための情報を収集できます。
手順
次のコマンドを実行して、Operator に関するデータを収集します。
oc adm must-gather \ --dest-dir=must-gather/tmp \ --image=$(oc -n openshift-lifecycle-agent get deployment.apps/lifecycle-agent-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name == "manager")].image}') \ --image=quay.io/konveyor/oadp-must-gather:latest \//
$ oc adm must-gather \ --dest-dir=must-gather/tmp \ --image=$(oc -n openshift-lifecycle-agent get deployment.apps/lifecycle-agent-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name == "manager")].image}') \ --image=quay.io/konveyor/oadp-must-gather:latest \//
1 --image=quay.io/openshift/origin-must-gather:latest
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.4.2. AbortFailed または FinalizeFailed エラー リンクのコピーリンクがクリップボードにコピーされました!
- 問題
最終ステージの間、または
Prep
ステージでプロセスを停止すると、Lifecycle Agent は次のリソースをクリーンアップします。- 不要になった stateroot
- リソースの事前キャッシュ
- OADP CR
-
ImageBasedUpgrade
CR
Lifecycle Agent が上記の手順を実行できない場合は、
AbortFailed
またはFinalizeFailed
状態に移行します。条件メッセージとログには、どの手順が失敗したかが表示されます。エラーメッセージの例
message: failed to delete all the backup CRs. Perform cleanup manually then add 'lca.openshift.io/manual-cleanup-done' annotation to ibu CR to transition back to Idle observedGeneration: 5 reason: AbortFailed status: "False" type: Idle
message: failed to delete all the backup CRs. Perform cleanup manually then add 'lca.openshift.io/manual-cleanup-done' annotation to ibu CR to transition back to Idle observedGeneration: 5 reason: AbortFailed status: "False" type: Idle
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 解決方法
- ログを調べて、失敗が発生した理由を特定します。
Lifecycle Agent にクリーンアップを再試行するように指示するには、
ImageBasedUpgrade
CR にlca.openshift.io/manual-cleanup-done
アノテーションを追加します。このアノテーションを確認した後、Lifecycle Agent はクリーンアップを再試行し、成功した場合は
ImageBasedUpgrade
ステージがIdle
に移行します。クリーンアップが再度失敗した場合は、リソースを手動でクリーンアップできます。
15.3.4.2.1. 手動での stateroot のクリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
- 問題
-
Lifecycle Agent は
Prep
ステージで停止し、新しい stateroot をクリーンアップします。アップグレードまたはロールバックが成功した後に終了すると、Lifecycle Agent は古い stateroot をクリーンアップします。この手順が失敗した場合は、ログを調べて失敗の原因を特定することを推奨します。 - 解決方法
次のコマンドを実行して、stateroot に既存のデプロイメントがあるか確認します。
ostree admin status
$ ostree admin status
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ある場合は、次のコマンドを実行して既存のデプロイメントをクリーンアップします。
ostree admin undeploy <index_of_deployment>
$ ostree admin undeploy <index_of_deployment>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow stateroot のすべてのデプロイメントをクリーンアップした後、次のコマンドを実行して stateroot ディレクトリーを消去します。
警告起動されたデプロイメントがこの stateroot にないことを確認します。
stateroot="<stateroot_to_delete>"
$ stateroot="<stateroot_to_delete>"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
$ unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.4.2.2. OADP リソースを手動でクリーンアップする リンクのコピーリンクがクリップボードにコピーされました!
- 問題
-
Lifecycle Agent と S3 バックエンド間の接続の問題により、OADP リソースの自動クリーンアップが失敗する可能性があります。接続を復元し、
lca.openshift.io/manual-cleanup-done
アノテーションを追加することで、Lifecycle Agent はバックアップリソースを正常にクリーンアップできます。 - 解決方法
次のコマンドを実行して、バックエンドの接続を確認します。
oc get backupstoragelocations.velero.io -n openshift-adp
$ oc get backupstoragelocations.velero.io -n openshift-adp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME PHASE LAST VALIDATED AGE DEFAULT dataprotectionapplication-1 Available 33s 8d true
NAME PHASE LAST VALIDATED AGE DEFAULT dataprotectionapplication-1 Available 33s 8d true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
すべてのバックアップリソースを削除してから、
lca.openshift.io/manual-cleanup-done
アノテーションをImageBasedUpgrade
CR に追加します。
15.3.4.3. LVM Storage ボリュームの内容が復元されない リンクのコピーリンクがクリップボードにコピーされました!
LVM Storage を使用して動的永続ボリュームストレージを提供する場合、LVM Storage が正しく設定されていないと、永続ボリュームの内容が復元されない可能性があります。
15.3.4.3.1. Backup CR に LVM Storage 関連のフィールドがない リンクのコピーリンクがクリップボードにコピーされました!
- 問題
Backup
CR に、永続ボリュームを復元するために必要なフィールドが欠落している可能性があります。以下を実行すると、アプリケーション Pod 内のイベントをチェックして、この問題が発生しているか確認できます。oc describe pod <your_app_name>
$ oc describe pod <your_app_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Backup CR に LVM Storage 関連のフィールドがないことを示す出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 解決方法
アプリケーション
Backup
CR にlogicalvolumes.topolvm.io
を含める必要があります。このリソースがない場合、アプリケーションは永続ボリューム要求と永続ボリュームマニフェストを正しく復元しますが、この永続ボリュームに関連付けられたlogicalvolume
はピボット後に適切に復元されません。Backup CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アプリケーションの永続ボリュームを復元するには、このセクションを次のように設定する必要があります。
15.3.4.3.2. Restore CR に LVM Storage 関連のフィールドがない リンクのコピーリンクがクリップボードにコピーされました!
- 問題
アプリケーションの予想されるリソースは復元されますが、アップグレード後に永続ボリュームの内容は保持されません。
ピボット前に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。
oc get pv,pvc,logicalvolumes.topolvm.io -A
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ピボット前の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ピボット後に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。
oc get pv,pvc,logicalvolumes.topolvm.io -A
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ピボット後の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 解決方法
この問題は、
logicalvolume
ステータスがRestore
CR に保存されないことが原因となっています。このステータスは、Velero がピボット後に保持する必要があるボリュームを参照する必要があるため重要です。アプリケーションのRestore
CR には、次のフィールドを含める必要があります。Restore CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.4.4. 失敗した Backup CR および Restore CR のデバッグ リンクのコピーリンクがクリップボードにコピーされました!
- 問題
- アーティファクトのバックアップまたは復元に失敗しました。
- 解決方法
Velero CLI ツールを使用して、
Backup
およびRestore
CR をデバッグし、ログを取得できます。Velero CLI ツールは、OpenShift CLI ツールよりも詳細な情報を提供します。次のコマンドを実行して、エラーを含む
Backup
CR を説明します。oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、エラーを含む
Restore
CR を説明します。oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、バックアップされたリソースをローカルディレクトリーにダウンロードします。
oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero backup download -n openshift-adp backup-acm-klusterlet -o ~/backup-acm-klusterlet.tar.gz
$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero backup download -n openshift-adp backup-acm-klusterlet -o ~/backup-acm-klusterlet.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4. GitOps ZTP を使用したシングルノード OpenShift クラスターのイメージベースアップグレードの実行 リンクのコピーリンクがクリップボードにコピーされました!
ハブクラスター上の 1 つのリソース、ImageBasedGroupUpgrade
カスタムリソース (CR) を使用して、すべてのステージを通じて、選択したマネージドクラスターのグループでイメージベースのアップグレードを管理できます。Topology Aware Lifecycle Manager (TALM) は、ImageBasedGroupUpgrade
CR を調整し、手動制御のアップグレードフローまたは完全に自動のアップグレードフローにより、定められたステージ遷移を完了するための基盤リソースを作成します。
イメージベースのアップグレードの詳細は、「シングルノード OpenShift クラスターのイメージベースのアップグレードについて」を参照してください。
15.4.1. ハブ上の ImageBasedGroupUpgrade CR を使用してイメージベースのアップグレードを大規模に管理する リンクのコピーリンクがクリップボードにコピーされました!
ImageBasedGroupUpgrade
CR は、ImageBasedUpgrade API
と ClusterGroupUpgrade
API を組み合わせたものです。たとえば、ImageBasedGroupUpgrade
API でも、ClusterGroupUpgrade
API と同じ方法で、クラスターの選択とロールアウトストラテジーを定義できます。ステージ遷移は ImageBasedUpgrade
API とは異なります。ImageBasedGroupUpgrade
API を使用すると、アクションとも呼ばれる複数のステージ遷移を、1 つのロールアウトストラテジーを共有する 1 つのステップに組み合わせることができます。
ImageBasedGroupUpgrade.yaml の例
- 1
- アップグレードするクラスター。
- 2
- ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。注記
ハブクラスターの
ImageBasedGroupUpgrade
リソースと同じ namespace にシードイメージプルシークレットを追加すると、そのシークレットがPrep
ステージのマニフェストリストに追加されます。シークレットは、openshift-lifecycle-agent
namespace 内の各スポーククラスターで再作成されます。 - 3
- オプション: シードイメージに含まれていない追加のマニフェストをターゲットクラスターに適用します。カスタムカタログソースの
ConfigMap
オブジェクトも適用します。 - 4
- OADP の
Backup
およびRestore
CR を含むConfigMap
リソース。 - 5
- アップグレードプランの詳細。
- 6
- バッチで更新するクラスターの数。
- 7
- アクションを完了するまでのタイムアウト制限 (分単位)。
15.4.1.1. サポートされているアクションの組み合わせ リンクのコピーリンクがクリップボードにコピーされました!
アクションは、選択されたクラスターグループのアップグレードプランの各ステップで TALM が実行する一連のステージ遷移です。ImageBasedGroupUpgrade
CR 内の action
エントリーは、それぞれ個別のステップです。1 つのステップに、同じロールアウトストラテジーを共有する 1 つ以上のアクションを含めます。アクションをステップに分けることで、各アクションのロールアウトストラテジーをより細かく制御できます。
これらのアクションは、アップグレードプラン内でさまざまな方法で組み合わせることができます。後続のステップは、後で追加することができます。プランにステップを追加する前に、前のステップが完了するか失敗するまで待機します。前のステップで失敗したクラスターに対して追加するステップの最初のアクションは、Abort
または Rollback
のどちらかである必要があります。
進行中のプランからアクションまたはステップを削除することはできません。
次の表にプランの例を示します。それぞれの例で、ロールアウトストラテジーに対する制御レベルが異なります。
プランの例 | 説明 |
---|---|
plan: - actions: ["Prep", "Upgrade", "FinalizeUpgrade"] rolloutStrategy: maxConcurrency: 200 timeout: 60
| すべてのアクションが同じストラテジーを共有しています。 |
| いくつかのアクションが同じストラテジーを共有しています。 |
| すべてのアクションに異なるストラテジーがあります。 |
クラスターは、いずれかのアクションに失敗すると、同じステップの残りのアクションをスキップします。
ImageBasedGroupUpgrade
API は次のアクションを受け入れます。
Prep
-
Prep
ステージに進み、アップグレードリソースの準備を開始します。 Upgrade
-
Upgrade
ステージに移行して、アップグレードを開始します。 FinalizeUpgrade
-
Idle
ステージに移行して、Upgrade
アクションを完了した特定のクラスターのアップグレードを確定します。 Rollback
-
Rollback
ステージに移行して、正常にアップグレードされたクラスターでのみロールバックを開始します。 FinalizeRollback
-
Idle
ステージに移行して、ロールバックを完了します。 AbortOnFailure
-
Idle
ステージに移行して、Prep
またはUpgrade
アクションに失敗した特定のクラスターのアップグレードをキャンセルします。 Abort
-
Idle
ステージに移行して、まだアップグレードされていないクラスターでのみ、進行中のアップグレードをキャンセルします。
次のアクションの組み合わせがサポートされています。角括弧のペアは、plan
セクションの 1 つのステップを表します。
-
["Prep"]
、["Abort"]
-
["Prep", "Upgrade", "FinalizeUpgrade"]
-
["Prep"]
、["AbortOnFailure"]
、["Upgrade"]
、["AbortOnFailure"]
、["FinalizeUpgrade"]
-
["Rollback", "FinalizeRollback"]
完全に新しい ImageBasedGroupUpgrade
CR から進行中のアップグレードを再開またはキャンセルする必要がある場合は、次のいずれかの組み合わせを使用します。
-
["Upgrade","FinalizeUpgrade"]
-
["FinalizeUpgrade"]
-
["FinalizeRollback"]
-
["Abort"]
-
["AbortOnFailure"]
15.4.1.2. クラスター選択のためのラベル付け リンクのコピーリンクがクリップボードにコピーされました!
最初のクラスターの選択には、spec.clusterLabelSelectors
フィールドを使用します。さらに、TALM が、最後のステージ遷移の結果に応じて、マネージドクラスターにラベルを付けます。
ステージが完了または失敗すると、関連するクラスターに TALM が次のラベルを付けます。
-
lcm.openshift.io/ibgu-<stage>-completed
-
lcm.openshift.io/ibgu-<stage>-failed
これらのクラスターラベルは、発生した問題をトラブルシューティングした後、クラスターのグループのアップグレードをキャンセルまたはロールバックするために使用します。
ImageBasedGroupUpgrade
CR を使用してクラスターをアップグレードする場合は、マネージドクラスターでトラブルシューティングまたは復元手順を実行した後、lcm.openshift.io/ibgu-<stage>-completed
または lcm.openshift.io/ibgu-<stage>-failed
クラスターラベルが適切に更新されていることを確認してください。これにより、TALM がクラスターのイメージベースのアップグレードを引き続き管理できるようになります。
たとえば、アップグレードが正常に完了したクラスターを除くすべてのマネージドクラスターのアップグレードをキャンセルする場合は、プランに Abort
アクションを追加できます。Abort
アクションは、ImageBasedUpgrade
CR を Idle
ステージに戻し、まだアップグレードされていないクラスターのアップグレードをキャンセルします。個別の Abort
アクションを追加すると、TALM が lcm.openshift.io/ibgu-upgrade-completed
ラベルを持つクラスターに対して Abort
アクションを実行しなくなります。
アップグレードが正常にキャンセルされるか完了すると、クラスターラベルが削除されます。
15.4.1.3. ステータスの監視 リンクのコピーリンクがクリップボードにコピーされました!
ImageBasedGroupUpgrade
CR は、すべてのクラスターの包括的なステータスレポートを 1 カ所に集約し、より優れた監視エクスペリエンスを実現します。監視できるアクションは次のとおりです。
status.clusters.completedActions
-
plan
セクションで定義されている完了したすべてのアクションを表示します。 status.clusters.currentAction
- 現在進行中のすべてのアクションを表示します。
status.clusters.failedActions
- 詳細なエラーメッセージとともに、失敗したすべてのアクションを表示します。
15.4.2. 複数のステップでマネージドクラスターのイメージベースのアップグレードを大規模に実行する リンクのコピーリンクがクリップボードにコピーされました!
アップグレードによってサービスが中断されるタイミングを適切に制御する必要があるユースケースの場合は、ImageBasedGroupUpgrade
CR を使用し、前のステップが完了した後にアクションを追加することで、マネージドクラスターのセットをアップグレードできます。前のステップの結果を評価した後、次のアップグレードステージに進むことも、手順全体の失敗したステップをトラブルシューティングすることもできます。
特定のアクションの組み合わせのみがサポートされています。これは サポートされているアクションの組み合わせ に記載されています。
前提条件
-
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 -
イメージベースのアップグレードで使用するリソースのポリシーと
ConfigMap
オブジェクトを作成した。 - ハブクラスターを介して、すべてのマネージドクラスターに Lifecycle Agent と OADP Operator をインストールした。
手順
ハブクラスターで、
ImageBasedGroupUpgrade
CR を含む YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アップグレードするクラスター。
- 2
- ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。注記
ハブクラスターの
ImageBasedGroupUpgrade
リソースと同じ namespace にシードイメージプルシークレットを追加すると、そのシークレットがPrep
ステージのマニフェストリストに追加されます。シークレットは、openshift-lifecycle-agent
namespace 内の各スポーククラスターで再作成されます。 - 3
- オプション: シードイメージに含まれていない追加のマニフェストをターゲットクラスターに適用します。カスタムカタログソースの
ConfigMap
オブジェクトも適用します。 - 4
- OADP の
Backup
およびRestore
CR を含むConfigMap
リソースのリスト。 - 5
- アップグレードプランの詳細。
ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで次のコマンドを実行して、ステータスの更新を監視します。
oc get ibgu -o yaml
$ oc get ibgu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のサンプルプランの出力は、始めは
Prep
ステージだけです。前のステップの結果に基づいて、このプランにアクションを追加してください。TALM により、アップグレードが成功したか失敗したかを示すラベルがクラスターに追加されます。たとえば、Prep
ステージに失敗したクラスターには、lcm.openshift.io/ibgu-prep-failed
が適用されます。失敗を調査した後、アップグレードプランに
AbortOnFailure
ステップを追加できます。このステップにより、lcm.openshift.io/ibgu-<action>-failed
というラベルの付いたクラスターがIdle
ステージに戻されます。選択されたクラスターのアップグレードに関連するリソースがすべて削除されます。オプション: 次のコマンドを実行して、既存の
ImageBasedGroupUpgrade
CR にAbortOnFailure
アクションを追加します。oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ステータスの更新の監視を継続します。
oc get ibgu -o yaml
$ oc get ibgu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、既存の
ImageBasedGroupUpgrade
CR にアクションを追加します。oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 次のコマンドを実行して、既存の
ImageBasedGroupUpgrade
CR にAbortOnFailure
アクションを追加します。oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ステータスの更新の監視を継続します。
oc get ibgu -o yaml
$ oc get ibgu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、既存の
ImageBasedGroupUpgrade
CR にアクションを追加します。oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["FinalizeUpgrade"], "rolloutStrategy": {"maxConcurrency": 10, "timeout": 3}}}]'
$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["FinalizeUpgrade"], "rolloutStrategy": {"maxConcurrency": 10, "timeout": 3}}}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行してステータスの更新を監視します。
oc get ibgu -o yaml
$ oc get ibgu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.3. 1 つのステップでマネージドクラスターのイメージベースのアップグレードを大規模に実行する リンクのコピーリンクがクリップボードにコピーされました!
サービスの中断が問題にならないユースケースの場合は、ImageBasedGroupUpgrade
CR を使用し、1 つのロールアウトストラテジーによって複数のアクションを 1 つのステップに組み合わせることで、マネージドクラスターのセットをアップグレードできます。ロールアウトストラテジーを 1 つにすると、アップグレード時間を短縮できます。ただし、アップグレードプランが完了した後でないと、失敗したクラスターのトラブルシューティングを行うことができません。
前提条件
-
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 -
イメージベースのアップグレードで使用するリソースのポリシーと
ConfigMap
オブジェクトを作成した。 - ハブクラスターを介して、すべてのマネージドクラスターに Lifecycle Agent と OADP Operator をインストールした。
手順
ハブクラスターで、
ImageBasedGroupUpgrade
CR を含む YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アップグレードするクラスター。
- 2
- ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。注記
ハブクラスターの
ImageBasedGroupUpgrade
リソースと同じ namespace にシードイメージプルシークレットを追加すると、そのシークレットがPrep
ステージのマニフェストリストに追加されます。シークレットは、openshift-lifecycle-agent
namespace 内の各スポーククラスターで再作成されます。 - 3
- オプション: シードイメージに含まれていない追加のマニフェストをターゲットクラスターに適用します。カスタムカタログソースの
ConfigMap
オブジェクトも適用します。 - 4
- OADP の
Backup
およびRestore
CR を含むConfigMap
リソース。 - 5
- アップグレードプランの詳細。
- 6
- バッチで更新するクラスターの数。
- 7
- アクションを完了するまでのタイムアウト制限 (分単位)。
ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行してステータスの更新を監視します。
oc get ibgu -o yaml
$ oc get ibgu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.4. マネージドクラスターのイメージベースのアップグレードを大規模にキャンセルする リンクのコピーリンクがクリップボードにコピーされました!
Prep
ステージを完了したマネージドクラスターのセットのアップグレードをキャンセルできます。
特定のアクションの組み合わせのみがサポートされています。これは サポートされているアクションの組み合わせ に記載されています。
前提条件
-
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
ハブクラスターで、
ImageBasedGroupUpgrade
CR を含む別の YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Prep
ステージを完了したすべてのマネージドクラスターが、Idle
ステージに戻ります。ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行してステータスの更新を監視します。
oc get ibgu -o yaml
$ oc get ibgu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.5. マネージドクラスターのイメージベースのアップグレードを大規模にロールバックする リンクのコピーリンクがクリップボードにコピーされました!
アップグレードが成功した後に解決できない問題が発生した場合は、管理対象クラスターのセットの変更をロールバックします。別の ImageBasedGroupUpgrade
CR を作成し、ロールバックするマネージドクラスターのセットを定義する必要があります。
特定のアクションの組み合わせのみがサポートされています。これは サポートされているアクションの組み合わせ に記載されています。
前提条件
-
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。
手順
ハブクラスターで、
ImageBasedGroupUpgrade
CR を含む別の YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 定義したラベルに一致するすべてのマネージドクラスターが、
Rollback
ステージに戻されます。その後Idle
ステージに移行してロールバックが完了します。
検証
次のコマンドを実行してステータスの更新を監視します。
oc get ibgu -o yaml
$ oc get ibgu -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.6. Lifecycle Agent を使用したイメージベースアップグレードのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
問題の影響を受けるマネージドクラスターでトラブルシューティング手順を実行します。
ImageBasedGroupUpgrade
CR を使用してクラスターをアップグレードする場合は、マネージドクラスターでトラブルシューティングまたは復元手順を実行した後、lcm.openshift.io/ibgu-<stage>-completed
または lcm.openshift.io/ibgu-<stage>-failed
クラスターラベルが適切に更新されていることを確認してください。これにより、TALM がクラスターのイメージベースのアップグレードを引き続き管理できるようになります。
15.4.6.1. ログの収集 リンクのコピーリンクがクリップボードにコピーされました!
oc adm must-gather
CLI を使用して、デバッグとトラブルシューティングのための情報を収集できます。
手順
次のコマンドを実行して、Operator に関するデータを収集します。
oc adm must-gather \ --dest-dir=must-gather/tmp \ --image=$(oc -n openshift-lifecycle-agent get deployment.apps/lifecycle-agent-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name == "manager")].image}') \ --image=quay.io/konveyor/oadp-must-gather:latest \//
$ oc adm must-gather \ --dest-dir=must-gather/tmp \ --image=$(oc -n openshift-lifecycle-agent get deployment.apps/lifecycle-agent-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name == "manager")].image}') \ --image=quay.io/konveyor/oadp-must-gather:latest \//
1 --image=quay.io/openshift/origin-must-gather:latest
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.6.2. AbortFailed または FinalizeFailed エラー リンクのコピーリンクがクリップボードにコピーされました!
- 問題
最終ステージの間、または
Prep
ステージでプロセスを停止すると、Lifecycle Agent は次のリソースをクリーンアップします。- 不要になった stateroot
- リソースの事前キャッシュ
- OADP CR
-
ImageBasedUpgrade
CR
Lifecycle Agent が上記の手順を実行できない場合は、
AbortFailed
またはFinalizeFailed
状態に移行します。条件メッセージとログには、どの手順が失敗したかが表示されます。エラーメッセージの例
message: failed to delete all the backup CRs. Perform cleanup manually then add 'lca.openshift.io/manual-cleanup-done' annotation to ibu CR to transition back to Idle observedGeneration: 5 reason: AbortFailed status: "False" type: Idle
message: failed to delete all the backup CRs. Perform cleanup manually then add 'lca.openshift.io/manual-cleanup-done' annotation to ibu CR to transition back to Idle observedGeneration: 5 reason: AbortFailed status: "False" type: Idle
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 解決方法
- ログを調べて、失敗が発生した理由を特定します。
Lifecycle Agent にクリーンアップを再試行するように指示するには、
ImageBasedUpgrade
CR にlca.openshift.io/manual-cleanup-done
アノテーションを追加します。このアノテーションを確認した後、Lifecycle Agent はクリーンアップを再試行し、成功した場合は
ImageBasedUpgrade
ステージがIdle
に移行します。クリーンアップが再度失敗した場合は、リソースを手動でクリーンアップできます。
15.4.6.2.1. 手動での stateroot のクリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
- 問題
-
Lifecycle Agent は
Prep
ステージで停止し、新しい stateroot をクリーンアップします。アップグレードまたはロールバックが成功した後に終了すると、Lifecycle Agent は古い stateroot をクリーンアップします。この手順が失敗した場合は、ログを調べて失敗の原因を特定することを推奨します。 - 解決方法
次のコマンドを実行して、stateroot に既存のデプロイメントがあるか確認します。
ostree admin status
$ ostree admin status
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ある場合は、次のコマンドを実行して既存のデプロイメントをクリーンアップします。
ostree admin undeploy <index_of_deployment>
$ ostree admin undeploy <index_of_deployment>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow stateroot のすべてのデプロイメントをクリーンアップした後、次のコマンドを実行して stateroot ディレクトリーを消去します。
警告起動されたデプロイメントがこの stateroot にないことを確認します。
stateroot="<stateroot_to_delete>"
$ stateroot="<stateroot_to_delete>"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
$ unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.6.2.2. OADP リソースを手動でクリーンアップする リンクのコピーリンクがクリップボードにコピーされました!
- 問題
-
Lifecycle Agent と S3 バックエンド間の接続の問題により、OADP リソースの自動クリーンアップが失敗する可能性があります。接続を復元し、
lca.openshift.io/manual-cleanup-done
アノテーションを追加することで、Lifecycle Agent はバックアップリソースを正常にクリーンアップできます。 - 解決方法
次のコマンドを実行して、バックエンドの接続を確認します。
oc get backupstoragelocations.velero.io -n openshift-adp
$ oc get backupstoragelocations.velero.io -n openshift-adp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME PHASE LAST VALIDATED AGE DEFAULT dataprotectionapplication-1 Available 33s 8d true
NAME PHASE LAST VALIDATED AGE DEFAULT dataprotectionapplication-1 Available 33s 8d true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
すべてのバックアップリソースを削除してから、
lca.openshift.io/manual-cleanup-done
アノテーションをImageBasedUpgrade
CR に追加します。
15.4.6.3. LVM Storage ボリュームの内容が復元されない リンクのコピーリンクがクリップボードにコピーされました!
LVM Storage を使用して動的永続ボリュームストレージを提供する場合、LVM Storage が正しく設定されていないと、永続ボリュームの内容が復元されない可能性があります。
15.4.6.3.1. Backup CR に LVM Storage 関連のフィールドがない リンクのコピーリンクがクリップボードにコピーされました!
- 問題
Backup
CR に、永続ボリュームを復元するために必要なフィールドが欠落している可能性があります。以下を実行すると、アプリケーション Pod 内のイベントをチェックして、この問題が発生しているか確認できます。oc describe pod <your_app_name>
$ oc describe pod <your_app_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Backup CR に LVM Storage 関連のフィールドがないことを示す出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 解決方法
アプリケーション
Backup
CR にlogicalvolumes.topolvm.io
を含める必要があります。このリソースがない場合、アプリケーションは永続ボリューム要求と永続ボリュームマニフェストを正しく復元しますが、この永続ボリュームに関連付けられたlogicalvolume
はピボット後に適切に復元されません。Backup CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アプリケーションの永続ボリュームを復元するには、このセクションを次のように設定する必要があります。
15.4.6.3.2. Restore CR に LVM Storage 関連のフィールドがない リンクのコピーリンクがクリップボードにコピーされました!
- 問題
アプリケーションの予想されるリソースは復元されますが、アップグレード後に永続ボリュームの内容は保持されません。
ピボット前に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。
oc get pv,pvc,logicalvolumes.topolvm.io -A
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ピボット前の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ピボット後に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。
oc get pv,pvc,logicalvolumes.topolvm.io -A
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ピボット後の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 解決方法
この問題は、
logicalvolume
ステータスがRestore
CR に保存されないことが原因となっています。このステータスは、Velero がピボット後に保持する必要があるボリュームを参照する必要があるため重要です。アプリケーションのRestore
CR には、次のフィールドを含める必要があります。Restore CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.6.4. 失敗した Backup CR および Restore CR のデバッグ リンクのコピーリンクがクリップボードにコピーされました!
- 問題
- アーティファクトのバックアップまたは復元に失敗しました。
- 解決方法
Velero CLI ツールを使用して、
Backup
およびRestore
CR をデバッグし、ログを取得できます。Velero CLI ツールは、OpenShift CLI ツールよりも詳細な情報を提供します。次のコマンドを実行して、エラーを含む
Backup
CR を説明します。oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、エラーを含む
Restore
CR を説明します。oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、バックアップされたリソースをローカルディレクトリーにダウンロードします。
oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero backup download -n openshift-adp backup-acm-klusterlet -o ~/backup-acm-klusterlet.tar.gz
$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero backup download -n openshift-adp backup-acm-klusterlet -o ~/backup-acm-klusterlet.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第16章 シングルノード OpenShift のイメージベースのインストール リンクのコピーリンクがクリップボードにコピーされました!
16.1. シングルノード OpenShift のイメージベースのインストールとデプロイメントについて リンクのコピーリンクがクリップボードにコピーされました!
イメージベースのインストールはインストールプロセスが合理化されているため、シングルノード OpenShift クラスターのデプロイメント時間が大幅に短縮されます。
この方法を使用すると、設定済みおよび検証済みのシングルノード OpenShift のインスタンスをターゲットホストにプリインストールできます。プリインストールされたホストは、最小限の介入で、非接続環境を含むネットワークのファーエッジで迅速に再設定してデプロイできます。
GitOps Zero Touch Provisioning (ZTP) とイメージベースのアプローチを使用してマネージドクラスターをデプロイするには、SiteConfig Operator を使用できます。詳細は、SiteConfig Operator を参照してください。
16.1.1. シングルノード OpenShift クラスターのイメージベースのインストールとデプロイの概要 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークのファーエッジにインフラストラクチャーをデプロイすることは、低帯域幅、高遅延、および非接続の環境を使用するサービスプロバイダーにとっては難しい課題です。また、シングルノード OpenShift クラスターをインストールしてデプロイするには、コストと時間がかかります。
イメージベースの方式でネットワークのファーエッジにシングルノード OpenShift クラスターをインストールおよびデプロイすると、インストール段階とデプロイ段階が分離され、このような課題が解消されます。
図16.1 マネージドシングルノード OpenShift クラスターのイメージベースのインストールとデプロイメントの概要
- イメージベースのインストール
- サービス拠点や工場などの中央サイトに、シングルノード OpenShift を搭載した複数のホストをプリインストールします。その後、これらのホストの基本設定を検証し、イメージベースの方式を活用して、1 つのライブインストール ISO を使用して再現可能な出荷時のインストールを大規模に実行します。
- イメージベースのデプロイ
- プリインストールされた検証済みのホストをリモートサイトに発送し、設定 ISO を使用して、わずか数分でクラスターを迅速に再設定してデプロイします。
SNO クラスターをプリインストールして設定する方法は 2 種類あります。
openshift-install
プログラムの使用-
シングルノード OpenShift クラスターの場合は、
openshift-install
プログラムのみを使用して、すべてのホストに共通するライブインストール ISO を手動で作成します。次に、プログラムを再度使用して、確実に一意のホストにするための設定 ISO を作成します。詳細は、「openshift-install プログラムを使用してマネージドシングルノード OpenShift をデプロイする」を参照してください。 - IBI Operator の使用
-
マネージドシングルノード OpenShift クラスターの場合、Image Based Install (IBI) Operator と
openshift-install
を使用して操作をスケールアップできます。プログラムはライブインストール ISO を作成し、その後 IBI Operator がホストごとに 1 つの設定 ISO を作成します。詳細は、「IBI Operator を使用してシングルノード OpenShift をデプロイする」を参照してください。
16.1.1.1. シングルノード OpenShift クラスターのイメージベースのインストール リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent を使用すると、シングルノード OpenShift クラスターのインスタンスをカプセル化する OCI コンテナーイメージを生成できます。このイメージは、ターゲットの OpenShift Container Platform バージョンで設定できる専用のクラスターに基づいて生成されます。
このイメージをライブインストール ISO で参照して、シングルノード OpenShift の設定済みおよび検証済みのインスタンスを、複数のホストに一貫してプリインストールできます。この方式を使用すると、工場やサービス拠点などの中央サイトでホストを準備してから、プリインストールされたホストをリモートサイトに出荷し、迅速に再設定してデプロイできます。ホストをプリインストールする手順は、openshift-install
プログラムのみを使用してホストをデプロイする場合も、IBI Operator を含むプログラムを使用してホストをデプロイする場合も同じです。
以下は、イメージベースのインストールプロセスの概要です。
- シングルノード OpenShift クラスターからイメージを生成します。
-
openshift-install
プログラムを使用して、シードイメージの URL とその他のインストールアーティファクトをライブインストール ISO に埋め込みます。 ライブインストール ISO を使用してホストを起動し、ホストをプリインストールします。
このプロセス中に、
openshift-install
プログラムが Red Hat Enterprise Linux CoreOS (RHCOS) をディスクにインストールし、生成したイメージをプルし、リリースコンテナーイメージをディスクに事前キャッシュします。- インストールが完了したら、ホストをリモートサイトに出荷し、迅速に再設定してデプロイできます。
16.1.1.2. シングルノード OpenShift クラスターのイメージベースのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
openshift-install
プログラムまたは IBI Operator を使用して、イメージベースのインストールによりプリインストールしたホストを設定およびデプロイできます。
- シングルノード OpenShift クラスターのデプロイメント
openshift-install
プログラムを使用してサイト固有の詳細を適用してターゲットホストを設定するには、次のリソースを作成する必要があります。-
install-config.yaml
インストールマニフェスト -
image-based-config.yaml
マニフェスト
openshift-install
プログラムは、これらのリソースを使用して設定 ISO を生成します。この設定 ISO をプリインストールされたターゲットホストにアタッチして、デプロイを完了します。-
- マネージドシングルノード OpenShift クラスターのデプロイメント
Red Hat Advanced Cluster Management (RHACM) と multicluster engine for Kubernetes Operator (MCE) は、ハブアンドスポークアーキテクチャーを使用して、複数のサイトをまたぐシングルノード OpenShift クラスターを管理およびデプロイします。このアプローチを使用すると、ハブクラスターはスポーククラスターを管理する中央コントロールプレーンとして機能します。この場合のスポーククラスターは、多くの場合ネットワークのファーエッジにデプロイされたリモートのシングルノード OpenShift クラスターです。
ハブクラスターで、イメージベースのデプロイメントで使用するサイト固有の設定リソースを定義できます。IBI Operator はこれらの設定リソースを使用して、プリインストールされたホストをリモートサイトで再設定し、そのホストをマネージドシングルノード OpenShift クラスターとしてデプロイします。このアプローチは、リモートサイトにおけるエンドツーエンドのインストールに多大な時間とコストがかかる、広範囲にわたる分散インフラストラクチャーを備えた通信プロバイダーやその他のサービスプロバイダーにとって特に有益です。
以下は、イメージベースのインストールによりプリインストールされたホストのイメージベースのデプロイメントプロセスの概要です。
- ハブクラスターで、プリインストールされたホストのサイト固有の設定リソースを定義します。
- これらのリソースをハブクラスターで適用します。これにより、デプロイメントプロセスが開始されます。
- IBI Operator は設定 ISO を作成します。
- IBI Operator は、設定 ISO がアタッチされたターゲットのプリインストール済みホストを起動します。
- ホストは設定 ISO をマウントし、再設定プロセスを開始します。
- 再設定が完了すると、シングルノード OpenShift クラスターの準備は完了します。
ホストはイメージベースのインストールを使用してすでにプリインストールされているため、技術者はわずか数分でホストを再設定してデプロイできます。
16.1.2. イメージベースのインストールとデプロイのコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
以下では、イメージベースのインストールとデプロイのコンポーネントを説明します。
- シードイメージ
- ターゲットの OpenShift Container Platform バージョンを備えた専用クラスターから生成された OCI コンテナーイメージ。
- シードクラスター
- シードイメージを作成するために使用され、ターゲットの OpenShift Container Platform バージョンでデプロイされる専用のシングルノード OpenShift クラスター。
- Lifecycle Agent
- シードイメージを生成します。
- Image Based Install (IBI) Operator
- IBI Operator は、マネージドクラスターのデプロイ時に、ハブクラスターでユーザーが定義したサイト固有のリソースから設定 ISO を作成し、ベアメタルプロビジョニングサービスを使用して、その設定 ISO をプリインストールされたホストにアタッチします。
openshift-install
プログラム- インストールおよび設定 ISO を作成し、シードイメージ URL をライブインストール ISO に埋め込みます。IBI Operator を使用しない場合は、設定 ISO をプリインストールされたホストにアタッチして、デプロイを完了する必要があります。
16.1.3. イメージベースのインストールとデプロイのクラスターに関するガイドライン リンクのコピーリンクがクリップボードにコピーされました!
イメージベースのインストールとデプロイを正常に行うために、次のガイドラインを参照してください。
16.1.3.1. クラスターに関するガイドライン リンクのコピーリンクがクリップボードにコピーされました!
- Red Hat Advanced Cluster Management (RHACM) を使用している場合は、シードイメージに RHACM リソースが含まれないように、シードイメージを生成する前に、オプションの RHACM アドオンをすべて無効にする必要があります。
16.1.3.2. シードクラスターに関するガイドライン リンクのコピーリンクがクリップボードにコピーされました!
- ネットワークのエッジにクラスターをデプロイするのにプロキシー設定が必要な場合は、プロキシー設定を備えたシードクラスターからシードイメージを作成する必要があります。2 つのプロキシー設定が同じである必要はありません。
-
シードクラスター内の
clusterNetwork
およびserviceNetwork
ネットワーク設定は、デプロイされたクラスターに保持されます。この設定は Lifecycle Agent によってシードイメージに埋め込まれます。後のイメージベースのインストールおよびデプロイプロセス中に、この設定を変更することはできません。 - シードクラスターで最大転送単位 (MTU) を設定する場合は、イメージベース設定 ISO の静的ネットワーク設定で同じ MTU 値を設定する必要があります。
-
シングルノード OpenShift シードクラスターには、イメージベースのインストール中にイメージを事前キャッシュするための共有
/var/lib/containers
ディレクトリーが必要です。詳細は、「ostree stateroot 間の共有コンテナーパーティションの設定」を参照してください。 シードイメージは、ターゲットのベアメタルホストと同じハードウェアを使用するシングルノード OpenShift クラスターから作成してください。シードクラスターが、次の項目についてターゲットクラスターの設定を反映している必要があります。
CPU トポロジー
- CPU アーキテクチャー
- CPU コア数
- チューニング済みのパフォーマンス設定 (予約 CPU 数など)
IP バージョン
注記このリリースではデュアルスタックネットワークはサポートされていません。
非接続レジストリー
注記ターゲットクラスターで非接続レジストリーを使用する場合、シードクラスターでも非接続レジストリーを使用する必要があります。レジストリーは同じものである必要はありません。
- FIPS 設定
16.1.4. イメージベースのインストールとデプロイのソフトウェアに関する前提条件 リンクのコピーリンクがクリップボードにコピーされました!
イメージベースのインストールとデプロイを行うには、以下の必須コンポーネントに次の最小ソフトウェアバージョンが必要です。
コンポーネント | ソフトウェアバージョン |
---|---|
マネージドクラスターのバージョン | 4.17 |
ハブクラスターのバージョン | 4.16 |
Red Hat Advanced Cluster Management (RHACM) | 2.12 |
Lifecycle Agent | 4.16 以降 |
Image Based Install Operator | 4.17 |
| 4.17 |
16.2. シングルノード OpenShift クラスターのイメージベースのインストールに向けた準備 リンクのコピーリンクがクリップボードにコピーされました!
シングルノード OpenShift クラスターのイメージベースのインストールを準備するには、次のタスクを完了する必要があります。
- Lifecycle Agent を使用してシードイメージを作成します。
- すべてのソフトウェアコンポーネントが必要なバージョンを満たしていることを確認します。詳細は、「イメージベースのインストールとデプロイのソフトウェアに関する前提条件」を参照してください。
16.2.1. Lifecycle Agent のインストール リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent を使用して、シードクラスターからシードイメージを生成します。Lifecycle Agent は、OpenShift CLI (oc
) または Web コンソールを使用してインストールできます。
16.2.1.1. CLI を使用した Lifecycle Agent のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc
) を使用して Lifecycle Agent をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
Lifecycle Agent 用の
Namespace
オブジェクトの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Namespace
CR を作成します。oc create -f <namespace_filename>.yaml
$ oc create -f <namespace_filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lifecycle Agent 用の
OperatorGroup
オブジェクトの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
OperatorGroup
CR を作成します。oc create -f <operatorgroup_filename>.yaml
$ oc create -f <operatorgroup_filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lifecycle Agent 用の
Subscription
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Subscription
CR を作成します。oc create -f <subscription_filename>.yaml
$ oc create -f <subscription_filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
インストールが成功したことを確認するには、次のコマンドを実行して CSV リソースを調べます。
oc get csv -n openshift-lifecycle-agent
$ oc get csv -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE lifecycle-agent.v4.18.0 Openshift Lifecycle Agent 4.18.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE lifecycle-agent.v4.18.0 Openshift Lifecycle Agent 4.18.0 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Lifecycle Agent が起動して実行されていることを確認します。
oc get deploy -n openshift-lifecycle-agent
$ oc get deploy -n openshift-lifecycle-agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE lifecycle-agent-controller-manager 1/1 1 1 14s
NAME READY UP-TO-DATE AVAILABLE AGE lifecycle-agent-controller-manager 1/1 1 1 14s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.2.1.2. Web コンソールを使用した Lifecycle Agent のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Lifecycle Agent をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
- 利用可能な Operator のリストから Lifecycle Agent を検索し、Install をクリックします。
- Install Operator ページの A specific namespace on the cluster の下で openshift-lifecycle-agent を選択します。
- Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators をクリックします。
Lifecycle Agent が、InstallSucceeded ステータス で openshift-lifecycle-agent プロジェクトにリストされていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator が正常にインストールされていない場合、以下を実行します。
- Operators → Installed Operators をクリックし、Operator Subscriptions タブおよび Install Plans タブの ステータス で障害やエラーがないか検査します。
- Workloads → Pods をクリックし、openshift-lifecycle-agent プロジェクト内の Pod のログを確認します。
16.2.3. シードイメージの設定 リンクのコピーリンクがクリップボードにコピーされました!
シードイメージは、ベアメタルホストと同じハードウェアを持ち、類似するターゲットクラスター設定を持つシングルノード OpenShift クラスターから作成できます。ただし、シードクラスターから生成されるシードイメージに、クラスター固有の設定を含めることはできません。
次の表は、シードイメージに含めるべき、および含めるべきでないコンポーネント、リソース、設定を示しています。
Cluster configuration | シードイメージに含める |
---|---|
パフォーマンスプロファイル | はい |
ターゲットクラスターの | はい |
IP バージョン [1] | はい |
Lifecycle Agent と OADP Operator を含む Day 2 Operator のセット | はい |
切断されたレジストリー設定 [2] | はい |
有効なプロキシー設定 [3] | はい |
FIPS 設定 | はい |
ターゲットクラスターのサイズに一致する、コンテナーストレージ用のプライマリーディスク上の専用パーティション | はい |
ローカルボリューム
| いいえ |
- このリリースではデュアルスタックネットワークはサポートされていません。
- シードクラスターが非接続環境にインストールされている場合は、ターゲットクラスターも非接続環境にインストールする必要があります。
- プロキシー設定は、シードクラスターとターゲットクラスターの両方で有効または無効にする必要があります。ただし、クラスター上で設定されている複数のプロキシーサーバーが同じである必要はありません。
16.2.3.1. RAN DU プロファイルを使用したシードイメージの設定 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、RAN DU プロファイルを使用する際にシードイメージに含めるべき、および含めるべきでないコンポーネント、リソース、設定を示しています。
リソース | シードイメージに含める |
---|---|
Day 0 インストールの一部として適用されるすべての追加マニフェスト | はい |
すべての Day 2 Operator サブスクリプション | はい |
| はい |
| はい |
| はい |
| はい |
| はい |
|
☓ ( |
| いいえ |
| いいえ |
次のリソースと設定のリストは、追加のマニフェストとして、または RHACM ポリシーを使用して適用できます。
-
ClusterLogForwarder.yaml
-
ReduceMonitoringFootprint.yaml
-
SriovFecClusterConfig.yaml
-
PtpOperatorConfigForEvent.yaml
-
DefaultCatsrc.yaml
-
PtpConfig.yaml
-
SriovNetwork.yaml
GitOps ZTP を使用している場合は、RHACM ポリシーを使用してこれらのリソースを有効にし、クラスターのライフサイクル全体に設定の変更を適用できるようにします。
16.2.4. Lifecycle Agent を使用したシードイメージの生成 リンクのコピーリンクがクリップボードにコピーされました!
Lifecycle Agent を使用して、マネージドクラスターからシードイメージを生成します。Operator は、必要なシステム設定を確認し、シードイメージを生成する前に必要なシステムクリーンアップを実行して、イメージ生成を開始します。シードイメージの生成には、次のタスクが含まれます。
- クラスター Operator の停止
- シードイメージ設定の準備
-
シードイメージの生成および
SeedGenerator
CR で指定されたイメージリポジトリーへのシードイメージのプッシュ - クラスター Operator の復元
- 期限切れのシードクラスター証明書
- シードクラスター用の新しい証明書の生成
-
シードクラスター上の
SeedGenerator
CR の復元と更新
前提条件
- RHACM と multicluster engine for Kubernetes Operator はシードクラスターにインストールされていません。
- シードクラスターに共有コンテナーディレクトリーを設定した。
- シードクラスターに OADP Operator と Lifecycle Agent の最小バージョンをインストールした。
- シードクラスターに永続ボリュームが設定されていないことを確認する。
-
Local Storage Operator が使用されている場合は、シードクラスターに
LocalVolume
CR が存在しないことを確認する。 -
LVM ストレージが使用されている場合は、シードクラスターに
LVMCluster
CR が存在しないことを確認する。 -
OADP が使用されている場合は、シードクラスターに
DataProtectionApplication
CR が存在しないことを確認する。
手順
マネージドクラスターをハブからデタッチして、シードイメージに含まれてはならない RHACM 固有のリソースをシードクラスターから削除します。
次のコマンドを実行してシードクラスターを手動でデタッチします。
oc delete managedcluster sno-worker-example
$ oc delete managedcluster sno-worker-example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
マネージドクラスターが削除されるまで待機します。クラスターが削除されたら、適切な
SeedGenerator
CR を作成します。Lifecycle Agent は RHACM アーティファクトをクリーンアップします。
-
マネージドクラスターが削除されるまで待機します。クラスターが削除されたら、適切な
GitOps ZTP を使用している場合は、シードクラスターの
SiteConfig
CR をkustomization.yaml
から削除してクラスターをデタッチします。複数の
SiteConfig
CR を参照するkustomization.yaml
ファイルがある場合は、シードクラスターのSiteConfig
CR をkustomization.yaml
から削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 1 つの
SiteConfig
CR を参照するkustomization.yaml
がある場合は、シードクラスターのSiteConfig
CR をkustomization.yaml
から削除し、generators: {}
行を追加します。apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: {}
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: {}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git リポジトリーで
kustomization.yaml
の変更をコミットし、変更をリポジトリーにプッシュします。ArgoCD パイプラインは変更を検出し、マネージドクラスターを削除します。
シードイメージをレジストリーにプッシュできるように、
Secret
オブジェクトを作成します。次のコマンドを実行して認証ファイルを作成します。
MY_USER=myuserid AUTHFILE=/tmp/my-auth.json podman login --authfile ${AUTHFILE} -u ${MY_USER} quay.io/${MY_USER}
$ MY_USER=myuserid $ AUTHFILE=/tmp/my-auth.json $ podman login --authfile ${AUTHFILE} -u ${MY_USER} quay.io/${MY_USER}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow base64 -w 0 ${AUTHFILE} ; echo
$ base64 -w 0 ${AUTHFILE} ; echo
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力を、
openshift-lifecycle-agent
namespace のseedgen
という名前のSecret
YAML ファイルのseedAuth
フィールドにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Secret
を適用します。oc apply -f secretseedgenerator.yaml
$ oc apply -f secretseedgenerator.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
SeedGenerator
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してシードイメージを生成します。
oc apply -f seedgenerator.yaml
$ oc apply -f seedgenerator.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Lifecycle Agent がシードイメージを生成している間、クラスターが再起動し、API 機能が失われます。
SeedGenerator
CR を適用すると、kubelet
と CRI-O の操作が停止し、イメージ生成が開始されます。
より多くのシードイメージを生成する場合は、シードイメージを生成するバージョンで新しいシードクラスターをプロビジョニングする必要があります。
検証
クラスターが回復して使用可能になったら、次のコマンドを実行して
SeedGenerator
CR のステータスを確認できます。oc get seedgenerator -o yaml
$ oc get seedgenerator -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- シードイメージの生成が完了しました。
16.3. イメージベースのインストールを使用したシングルノード OpenShift のプリインストール リンクのコピーリンクがクリップボードにコピーされました!
openshift-install
プログラムを使用して、ベアメタルホストにシングルノード OpenShift をプリインストールするためのライブインストール ISO を作成します。インストールプログラムのダウンロードの詳細は、「関連情報」セクションの「インストールプロセス」を参照してください。
インストールプログラムは、シードイメージの URL と、シードイメージのリリースバージョンやインストールプロセスに使用するディスクなどのその他の入力情報を受け取り、ライブインストール ISO を作成します。その後、ライブインストール ISO を使用してホストを起動し、プリインストールを開始できます。プリインストールが完了したら、最終的なサイト固有の設定とデプロイを行うために、ホストをリモートサイトに出荷できます。
以下は、イメージベースのインストールを使用してシングルノード OpenShift クラスターをプリインストールするための大まかな手順です。
- シードイメージを生成します。
-
openshift-install
インストールプログラムを使用してライブインストール ISO を作成します。 - ライブインストール ISO を使用してホストを起動し、ホストをプリインストールします。
16.3.1. シングルノード OpenShift のイメージベースインストール用のライブインストール ISO を作成する リンクのコピーリンクがクリップボードにコピーされました!
openshift-install
プログラムを使用して、シングルノード OpenShift のシードイメージの URL やその他のインストールアーティファクトをライブインストール ISO に埋め込むことができます。
image-based-installation-config.yaml
マニフェストの仕様の詳細は、「image-based-installation-config.yaml
マニフェストのリファレンス仕様」セクションを参照してください。
前提条件
- シングルノード OpenShift のシードクラスターからシードイメージを生成した。
-
openshift-install
プログラムをダウンロードした。openshift-install
プログラムのバージョンが、シードイメージ内の OpenShift Container Platform のバージョンと一致している。 - ターゲットホストが、シードイメージの URL と他のすべてのインストールアーティファクトにネットワークでアクセスできる。
-
静的ネットワークが必要な場合は、ライブインストール ISO を作成するホストに
nmstatectl
ライブラリーをインストールする必要があります。
手順
ライブインストール ISO を作成し、シングルノード OpenShift のシードイメージの URL とその他のインストールアーティファクトを埋め込みます。
次のコマンドを実行して作業ディレクトリーを作成します。
mkdir ibi-iso-workdir
$ mkdir ibi-iso-workdir
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ibi-iso-workdir
は、作業ディレクトリーの名前に置き換えます。
オプション:
ImageBasedInstallationConfig
リソースを設定するときにリファレンスとして使用するインストール設定テンプレートを作成します。openshift-install image-based create image-config-template --dir ibi-iso-workdir
$ openshift-install image-based create image-config-template --dir ibi-iso-workdir
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 作業ディレクトリーを指定しなかった場合、カレントディレクトリーが使用されます。
出力例
INFO Image-Config-Template created in: ibi-iso-workdir
INFO Image-Config-Template created in: ibi-iso-workdir
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、ターゲットディレクトリーに
image-based-installation-config.yaml
インストール設定テンプレートが作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストール設定ファイルを編集します。
image-based-installation-config.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してライブインストール ISO を作成します。
openshift-install image-based create image --dir ibi-iso-workdir
$ openshift-install image-based create image --dir ibi-iso-workdir
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Consuming Image-based Installation ISO Config from target directory INFO Creating Image-based Installation ISO with embedded ignition
INFO Consuming Image-based Installation ISO Config from target directory INFO Creating Image-based Installation ISO with embedded ignition
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
作業ディレクトリーで出力を確認します。
ibi-iso-workdir/ └── rhcos-ibi.iso
ibi-iso-workdir/ └── rhcos-ibi.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.3.1.1. ターゲットホスト上の追加パーティションの設定 リンクのコピーリンクがクリップボードにコピーされました!
インストール ISO は、イメージベースのインストールプロセス中に、/var/lib/containers
ディレクトリーのパーティションを作成します。
coreosInstallerArgs
仕様を使用すると、追加のパーティションを作成できます。たとえば、十分なストレージ容量を備えたハードディスクに、論理ボリュームマネージャー (LVM) ストレージなどのストレージオプション用の追加パーティションが必要になる場合があります。
/var/lib/containers
パーティションには、事前キャッシュされたイメージに十分なディスク領域を確保するために、少なくとも 500 GB が必要です。追加のパーティションを作成する際には、/var/lib/containers
のパーティションよりも大きい開始位置を指定する必要があります。
手順
image-based-installation-config.yaml
ファイルを編集して、追加のパーティションを設定します。image-based-installation-config.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールプロセス中にディスクのフォーマットをスキップするには、
true
を指定します。 - 2
- パーティションを保持するには、この引数を指定します。
- 3
- ライブインストール ISO には 5 つのパーティションが必要です。追加パーティションを保持するよう指定するには、5 より大きい数値を指定します。
- 4
- ターゲットホスト上のインストールディスクを指定します。
- 5
- パーティションのラベルを指定します。
- 6
- パーティションの番号を指定します。
- 7
- パーティションのサイズを MiB 単位で指定します。
- 8
- 追加パーティションのディスク上の開始位置を MiB 単位で指定します。
var/lib/containers
のパーティションよりも大きい開始位置を指定する必要があります。
検証
ライブインストール ISO を使用したホストのプリインストールが完了したら、ターゲットホストにログインし、次のコマンドを実行してパーティションを表示します。
lsblk
$ lsblk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.3.2. ライブインストール ISO をホストにプロビジョニングする リンクのコピーリンクがクリップボードにコピーされました!
任意の方法を使用して、rhcos-ibi.iso
ライブインストール ISO からターゲットのベアメタルホストを起動し、シングルノード OpenShift をプリインストールします。
検証
- ターゲットホストにログインします。
次のコマンドを実行してシステムログを表示します。
journalctl -b
$ journalctl -b
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.3.3. image-based-installation-config.yaml マニフェストのリファレンス仕様 リンクのコピーリンクがクリップボードにコピーされました!
以下では、image-based-installation-config.yaml
マニフェストの仕様を説明します。
openshift-install
プログラムは、image-based-installation-config.yaml
マニフェストを使用して、シングルノード OpenShift のイメージベースインストール用のライブインストール ISO を作成します。
仕様 | 型 | 説明 |
---|---|---|
|
| ISO 生成プロセスで使用するシードイメージを指定します。 |
|
|
シードイメージの OpenShift Container Platform リリースバージョンを指定します。シードイメージ内のリリースバージョンが、この |
|
| インストールプロセスに使用するディスクを指定します。
ディスクの検出順序は保証されていないため、複数のディスクを持つマシンでは、起動オプションによってディスクのカーネル名が変わる可能性があります。たとえば、 |
|
| 事前キャッシュプロセス中に使用するプルシークレットを指定します。プルシークレットには、コンテナーレジストリーからリリースペイロードイメージをプルするための認証情報を含めます。 シードイメージに個別のプライベートレジストリー認証が必要な場合は、プルシークレットに認証の詳細を追加してください。 |
仕様 | 型 | 説明 |
---|---|---|
|
|
インストールプロセスの完了後にホストをシャットダウンするかどうかを指定します。デフォルト値は |
|
|
|
|
|
注記 インストール ISO のパーティションラベルが、シードイメージのマシン設定で設定されているパーティションラベルと一致していることを確認する必要があります。パーティションラベルが異なる場合、ホストへのインストール中にパーティションのマウントが失敗します。詳細は、「ostree stateroot 間の共有コンテナーパーティションの設定」を参照してください。 |
|
|
|
|
|
インストールプロセスでは、ホスト上のディスクがフォーマットされます。このステップをスキップするには、この仕様を 'true' に設定します。デフォルトは |
|
| ホストのネットワーク設定を指定します。次に例を示します。
静的ネットワークが必要な場合は、ライブインストール ISO を作成するホストに 重要 インターフェイスの名前は、オペレーティングシステムに表示される実際の NIC 名と同じである必要があります。 |
|
| インストール ISO 生成中に使用するプロキシー設定を指定します。次に例を示します。 proxy: httpProxy: "http://proxy.example.com:8080" httpsProxy: "http://proxy.example.com:8080" noProxy: "no_proxy.example.com"
|
|
| リリースイメージコンテンツのソースまたはリポジトリーを指定します。次に例を示します。 imageDigestSources: - mirrors: - "registry.example.com:5000/ocp4/openshift4" source: "quay.io/openshift-release-dev/ocp-release"
|
|
|
PEM でエンコードされた X.509 証明書バンドルを指定します。インストールプログラムは、これをインストール ISO の |
|
| ホストへのアクセスを認証するための SSH 鍵を指定します。 |
|
| Ignition 設定のユーザーオーバーライドを含む JSON 文字列を指定します。この設定は、インストールプログラムによって生成される Ignition 設定ファイルとマージされます。この機能には、Ignition バージョン 3.2 以降が必要です。 |
|
|
カーネル引数とディスクパーティションオプションを設定するために使用できる |
16.4. シングルノード OpenShift クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
16.4.1. マネージドシングルノード OpenShift のイメージベースのデプロイメントについて リンクのコピーリンクがクリップボードにコピーされました!
イメージベースのインストールを使用してシングルノード OpenShift がプリインストールされたホストがリモートサイトに到達すると、技術者はわずか数分でホストを簡単に再設定してデプロイできます。
ハブアンドスポークアーキテクチャーを持つクラスターの場合、プリインストールされたホストのデプロイメントを完了するには、まず各ホストのハブクラスターでサイト固有の設定リソースを定義する必要があります。これらのリソースには、ベアメタルホストのプロパティー、認証の詳細、その他のデプロイメントおよびネットワーク情報などの設定情報が含まれています。
Image Based Install (IBI) Operator は、これらのリソースから設定 ISO を作成し、設定 ISO がアタッチされた状態でホストを起動します。ホストは設定 ISO をマウントし、再設定プロセスを実行します。再設定が完了すると、シングルノード OpenShift クラスターの準備は完了します。
ベアメタルホストごとに個別の設定リソースを作成する必要があります。
ハブアンドスポークアーキテクチャーを持つクラスターにプリインストールされたホストをデプロイするには、次の大まかな手順を参照してください。
- ハブクラスターに IBI Operator をインストールします。
- 各ホストのハブクラスターにサイト固有の設定リソースを作成します。
- IBI Operator はこれらのリソースから設定 ISO を作成し、設定 ISO がアタッチされた状態でターゲットホストを起動します。
- ホストは設定 ISO をマウントし、再設定プロセスを実行します。再設定が完了すると、シングルノード OpenShift クラスターの準備は完了します。
または、ハブクラスターを使用せずに、クラスターにプリインストールされたホストを手動でデプロイすることもできます。ImageBasedConfig
リソースとインストールマニフェストを定義し、それを openshift-install
インストールプログラムへの入力として提供する必要があります。詳細は、「openshift-install
プログラムを使用してシングルノード OpenShift クラスターをデプロイする」を参照してください。
16.4.1.1. Image Based Install Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Image Based Install (IBI) Operator は、ベアメタルホストにプリインストールされたシングルノード OpenShift のイメージベースデプロイメントワークフローの構成要素です。
IBI Operator は、MCE バージョン 2.7 以降の multicluster engine for Kubernetes Operator の構成要素です。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。 - Red Hat Advanced Cluster Management (RHACM) ハブクラスター、または multicluster engine for Kubernetes Operator をデプロイした。
- 「イメージベースのインストールのソフトウェア前提条件」セクションで、ソフトウェアコンポーネントの必要なバージョンを確認した。
手順
次のコマンドを実行して、
MultiClusterEngine
リソースのimage-based-install-operator
コンポーネントでenabled
仕様をtrue
に設定します。oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type json \ --patch '[{"op": "add", "path":"/spec/overrides/components/-", "value": {"name":"image-based-install-operator","enabled": true}}]'
$ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type json \ --patch '[{"op": "add", "path":"/spec/overrides/components/-", "value": {"name":"image-based-install-operator","enabled": true}}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、Image Based Install Operator Pod が実行されていることを確認します。
oc get pods -A | grep image-based
$ oc get pods -A | grep image-based
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
multicluster-engine image-based-install-operator-57fb8sc423-bxdj8 2/2 Running 0 5m
multicluster-engine image-based-install-operator-57fb8sc423-bxdj8 2/2 Running 0 5m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.4.1.2. IBI Operator を使用してマネージドシングルノード OpenShift クラスターをデプロイする リンクのコピーリンクがクリップボードにコピーされました!
ハブクラスターにサイト固有の設定リソースを作成し、プリインストールされたホストのイメージベースのデプロイメントを開始します。
ハブクラスターでこれらの設定リソースを作成すると、Image Based Install (IBI) Operator は設定 ISO を生成し、それをターゲットホストにアタッチしてサイト固有の設定プロセスを開始します。設定プロセスが完了すると、シングルノード OpenShift クラスターの準備は完了します。
ハブクラスターで設定する必要がある設定リソースの詳細は、「プリインストールされたホストのデプロイに仕様するクラスター設定リソース」を参照してください。
前提条件
- イメージベースのインストールを使用して、シングルノード OpenShift をホストにプリインストールした。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - Red Hat Advanced Cluster Management (RHACM) ハブクラスター、または multicluster engine for Kubernetes Operator (MCE) をデプロイした。
- ハブクラスターに IBI Operator をインストールした。
- プルリクエストを認証するためのプルシークレットを作成した。詳細は、「イメージプルシークレットの使用」を参照してください。
手順
次のコマンドを実行して、
ibi-ns
namespace を作成します。oc create namespace ibi-ns
$ oc create namespace ibi-ns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージレジストリーの
Secret
リソースを作成します。イメージレジストリーの
Secret
リソースを定義する YAML ファイルを作成します。secret-image-registry.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- base64 でエンコードされた認証情報の詳細を提供する必要があります。イメージプルシークレットの使用に関する詳細は、「関連情報」セクションを参照してください。
次のコマンドを実行して、イメージレジストリーの
Secret
リソースを作成します。oc create -f secret-image-registry.yaml
$ oc create -f secret-image-registry.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: ホストの静的ネットワークを設定します。
nmstate
形式の静的ネットワーク設定を含むSecret
リソースを作成します。host-network-config-secret.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Secret
リソースの名前を指定します。- 2
- 静的ネットワーク設定を
nmstate
形式で定義します。 - 3
- ホスト上のインターフェイスの名前を指定します。インターフェイスの名前は、オペレーティングシステムに表示される実際の NIC 名と同じである必要があります。NIC マッチングに MAC アドレスを使用するには、
identifier
フィールドをmac-address
に設定します。 - 4
nmstate
がインターフェイスに静的 IP アドレスを割り当てるようにするには、dhcp: false
を指定する必要があります。- 5
- システムがドメイン名を解決するために使用する 1 つ以上の DNS サーバーを指定します。
- 6
- この例のデフォルトルートは、
ens1f0
インターフェイスを介してネクストホップ IP アドレス192.168.200.254
に設定されています。
BareMetalHost
およびSecret
リソースを作成します。BareMetalHost
およびSecret
リソースを定義する YAML ファイルを作成します。ibi-bmh.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
BareMetalHost
リソースの名前を指定します。- 2
- ホストをオンラインにするかどうかを指定します。
- 3
- ホストのブート MAC アドレスを指定します。
- 4
- BMC アドレスを指定します。仮想メディアネットワークの起動をサポートするベアメタルホストドライバー (redfish-virtualmedia や idrac-virtualmedia など) のみを使用できます。
- 5
- ベアメタルホストの
Secret
リソースの名前を指定します。 - 6
- オプション: ホストに静的ネットワーク設定が必要な場合は、その設定を含む
Secret
リソースの名前を指定します。 - 7
- プロビジョニングサービスがディスク検査中にシードイメージなどのすべてのプリインストールアーティファクトを削除しないようにするには、
automatedCleaningMode:disabled
を指定する必要があります。 - 8
- ホストを、設定 ISO ではなくプリインストールされたディスクから起動できるようにするには、
externallyProvisioned: true
を指定する必要があります。 - 9
Secret
リソースの名前を指定します。- 10
- ユーザー名を指定します。
- 11
- パスワードを指定します。
次のコマンドを実行して、
BareMetalHost
およびSecret
リソースを作成します。oc create -f ibi-bmh.yaml
$ oc create -f ibi-bmh.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ClusterImageSet
リソースを作成します。ClusterImageSet
リソースを定義する YAML ファイルを作成します。ibi-cluster-image-set.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して
ClusterImageSet
リソースを作成します。oc apply -f ibi-cluster-image-set.yaml
$ oc apply -f ibi-cluster-image-set.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ImageClusterInstall
リソースを作成します。ImageClusterInstall
リソースを定義する YAML ファイルを作成します。ibi-image-cluster-install.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ImageClusterInstall
リソースの名前を指定します。- 2
- イメージベースのインストールのターゲットとなる
BareMetalHost
リソースを指定します。 - 3
- ターゲットホストのイメージベースのインストールに使用する
ClusterDeployment
リソースの名前を指定します。 - 4
- クラスターのホスト名を指定します。
- 5
- デプロイメントに使用するコンテナーリリースイメージを定義するために使用した
ClusterImageSet
リソースの名前を指定します。 - 6
- 外部ネットワークの公開 CIDR (Classless Inter-Domain Routing) を指定します。
- 7
- オプション: クラスターのデプロイメントに使用するプロキシーを指定します。
重要クラスターをデプロイするのにプロキシー設定が必要な場合は、次の手順を実行する必要があります。
- プロキシー設定を備えたシードクラスターからシードイメージを作成します。2 つのプロキシー設定が同じである必要はありません。
-
インストールマニフェストの
machineNetwork
フィールドを設定します。
次のコマンドを実行して、
ImageClusterInstall
リソースを作成します。oc create -f ibi-image-cluster-install.yaml
$ oc create -f ibi-image-cluster-install.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ClusterDeployment
リソースを作成します。ClusterDeployment
リソースを定義する YAML ファイルを作成します。ibi-cluster-deployment.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して
ClusterDeployment
リソースを作成します。oc apply -f ibi-cluster-deployment.yaml
$ oc apply -f ibi-cluster-deployment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ManagedCluster
リソースを作成します。ManagedCluster
リソースを定義する YAML ファイルを作成します。ibi-managed.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ManagedCluster
リソースを作成します。oc apply -f ibi-managed.yaml
$ oc apply -f ibi-managed.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、ターゲットホストのインストールの進行状況を監視するためにハブクラスター内の
ImageClusterInstall
のステータスを確認します。oc get imageclusterinstall
$ oc get imageclusterinstall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME REQUIREMENTSMET COMPLETED BAREMETALHOSTREF target-0 HostValidationSucceeded ClusterInstallationSucceeded ibi-bmh
NAME REQUIREMENTSMET COMPLETED BAREMETALHOSTREF target-0 HostValidationSucceeded ClusterInstallationSucceeded ibi-bmh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告ImageClusterInstall
リソースが削除された場合、IBI Operator はBareMetalHost
リソースを再度アタッチし、マシンを再起動します。インストールが完了したら、次のコマンドを実行して
kubeconfig
シークレットを取得し、マネージドクラスターにログインできます。oc extract secret/<cluster_name>-admin-kubeconfig -n <cluster_namespace> --to - > <directory>/<cluster_name>-kubeconfig
$ oc extract secret/<cluster_name>-admin-kubeconfig -n <cluster_namespace> --to - > <directory>/<cluster_name>-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<cluster_name>
はクラスターの名前です。 -
<cluster_namespace>
はクラスターの namespace です。 -
<directory>
はファイルを作成するディレクトリーです。
-
16.4.1.2.1. プリインストールされたホストのデプロイに使用するクラスター設定リソース リンクのコピーリンクがクリップボードにコピーされました!
リモートサイトでプリインストールされたホストのデプロイメントを完了するには、各ベアメタルホストのハブクラスターで次のサイト固有のクラスター設定リソースを設定する必要があります。
リソース | 説明 |
---|---|
| マネージドシングルノード OpenShift クラスターの namespace。 |
| プロビジョニングやハードウェア設定など、物理ホストとそのプロパティーを記述します。 |
ベアメタルホストの | ホスト BMC の認証情報。 |
ベアメタルホストの静的ネットワーク設定の | オプション: ターゲットホストの静的ネットワーク設定を記述します。 |
イメージレジストリーの |
イメージレジストリーの認証情報。イメージレジストリーのシークレットは、 |
| ベアメタルホスト、デプロイメント、およびイメージセットリソースを参照します。 |
| クラスターに使用するリリースイメージを記述します。 |
| ネットワーク、認証、プラットフォーム固有の設定を記述します。 |
| Red Hat Advanced Cluster Management (RHACM) が登録および管理できるようにするためのクラスター詳細を記述します。 |
| オプション: クラスターデプロイメントの追加設定を記述します。たとえば、クラスターサービスの信頼済み通信を確保するためにホストに信頼済み証明書のバンドルを追加する場合などです。 |
16.4.1.2.2. ImageClusterInstall リソース API 仕様 リンクのコピーリンクがクリップボードにコピーされました!
以下では、ImageClusterInstall
リソースの API 仕様を説明します。このリソースは、Image Based Install Operator のエンドポイントです。
仕様 | 型 | 説明 |
---|---|---|
|
|
デプロイメントのリリースイメージを定義する |
|
| クラスターのホスト名を指定します。 |
|
| ターゲットホストへの SSH アクセスを提供するには、SSH キーを指定します。 |
仕様 | 型 | 説明 |
---|---|---|
|
|
ターゲットホストのイメージベースのインストールに使用する |
|
|
デプロイメントが完了すると、クラスターにログインするための |
|
| リリースイメージコンテンツのソースまたはリポジトリーを指定します。次に例を示します。 imageDigestSources: - mirrors: - "registry.example.com:5000/ocp4/openshift4" source: "quay.io/openshift-release-dev/ocp-release"
|
|
|
ターゲットクラスターに適用する追加のマニフェストを含む |
|
|
クラスターのデプロイメントに使用する |
|
| 外部ネットワークの公開 CIDR (Classless Inter-Domain Routing) を指定します。 |
|
| クラスターのプロキシー設定を指定します。以下はその例です。 proxy: httpProxy: "http://proxy.example.com:8080" httpsProxy: "http://proxy.example.com:8080" noProxy: "no_proxy.example.com"
|
|
|
ホストの信頼済み証明書の新しいバンドルを含む |
16.4.1.3. 追加マニフェスト用の ConfigMap リソース リンクのコピーリンクがクリップボードにコピーされました!
オプションで ConfigMap
リソースを作成し、マネージドシングルノード OpenShift クラスターのイメージベースのデプロイメントで追加のマニフェストを定義できます。
ConfigMap
リソースを作成したら、ImageClusterInstall
リソースでそれを参照します。デプロイ中に、IBI Operator は追加のマニフェストをデプロイメントに含めます。
16.4.1.3.1. イメージベースのデプロイメントに追加マニフェストを追加するための ConfigMap リソースを作成する リンクのコピーリンクがクリップボードにコピーされました!
ConfigMap
リソースを使用して、シングルノード OpenShift クラスターのイメージベースのデプロイメントに追加のマニフェストを追加できます。
次の例では、Single Root I/O Virtualization (SR-IOV) ネットワークをデプロイに追加します。
追加マニフェストのファイル名は、必ず 30 文字以下にしてください。ファイル名が長いと、デプロイメントが失敗する可能性があります。
前提条件
- イメージベースのインストールを使用して、シングルノード OpenShift をホストにプリインストールした。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
SriovNetworkNodePolicy
およびSriovNetwork
リソースを作成します。リソースを定義する YAML ファイルを作成します。
sriov-extra-manifest.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ConfigMap
リソースを作成します。oc create configmap sr-iov-extra-manifest --from-file=sriov-extra-manifest.yaml -n ibi-ns
$ oc create configmap sr-iov-extra-manifest --from-file=sriov-extra-manifest.yaml -n ibi-ns
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ImageClusterInstall
リソースがある namespace を指定します。
出力例
configmap/sr-iov-extra-manifest created
configmap/sr-iov-extra-manifest created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記複数のマニフェストを追加し、マニフェストを特定の順序で適用する必要がある場合は、マニフェストのファイル名の前に、必要な順序を表す数字を付ける必要があります。たとえば、
00-namespace.yaml
、01-sriov-extra-manifest.yaml
などです。
ImageClusterInstall
リソースのspec.extraManifestsRefs
フィールドでConfigMap
リソースを参照します。#... spec: extraManifestsRefs: - name: sr-iov-extra-manifest #...
#... spec: extraManifestsRefs: - name: sr-iov-extra-manifest #...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.4.1.3.2. イメージベースのデプロイメントで CA バンドルを追加するための ConfigMap リソースを作成する リンクのコピーリンクがクリップボードにコピーされました!
クラスターサービスの信頼済み通信を確保するために、ConfigMap
リソースを使用してホストに認証局 (CA) バンドルを追加できます。
ConfigMap
リソースを作成したら、ImageClusterInstall
リソースの spec.caBundleRef
フィールドでそれを参照します。
前提条件
- イメージベースのインストールを使用して、シングルノード OpenShift をホストにプリインストールした。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
tls-ca-bundle.pem
という名前の CA バンドルファイルを作成します。tls-ca-bundle.pem
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
ConfigMap
オブジェクトを作成します。oc create configmap custom-ca --from-file=tls-ca-bundle.pem -n ibi-ns
$ oc create configmap custom-ca --from-file=tls-ca-bundle.pem -n ibi-ns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
custom-ca
は、ConfigMap
リソースの名前を指定します。 -
tls-ca-bundle.pem
は、ConfigMap
リソース内のdata
エントリーのキーを定義します。tls-ca-bundle.pem
キーを含むdata
エントリーを追加する必要があります。 ibi-ns
は、ImageClusterInstall
リソースがある namespace を指定します。出力例
configmap/custom-ca created
configmap/custom-ca created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
ImageClusterInstall
リソースのspec.caBundleRef
フィールドでConfigMap
リソースを参照します。#... spec: caBundleRef: name: custom-ca #...
#... spec: caBundleRef: name: custom-ca #...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.4.2. シングルノード OpenShift のイメージベースのデプロイについて リンクのコピーリンクがクリップボードにコピーされました!
openshift-install
プログラムを使用すると、設定 ISO を手動で生成できます。設定 ISO をプリインストールされたホストにアタッチして、デプロイを完了します。
16.4.2.1. openshift-install プログラムを使用したシングルノード OpenShift クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
openshift-install
プログラムを使用して、イメージベースのインストールでプリインストールしたホストを設定およびデプロイできます。サイト固有の詳細情報を使用してターゲットホストを設定するには、次のリソースを作成する必要があります。
-
install-config.yaml
インストールマニフェスト -
image-based-config.yaml
マニフェスト
openshift-install
プログラムは、これらのリソースを使用して設定 ISO を生成します。この設定 ISO をプリインストールされたターゲットホストにアタッチして、デプロイを完了します。
image-based-config.yaml
マニフェストの仕様の詳細は、「image-based-config.yaml マニフェストのリファレンス仕様」を参照してください。
前提条件
- イメージベースのインストールを使用して、シングルノード OpenShift をホストにプリインストールした。
-
最新バージョンの
openshift-install
プログラムをダウンロードした。 - プルリクエストを認証するためのプルシークレットを作成した。詳細は、「イメージプルシークレットの使用」を参照してください。
手順
次のコマンドを実行して作業ディレクトリーを作成します。
mkdir ibi-config-iso-workdir
$ mkdir ibi-config-iso-workdir
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ibi-config-iso-workdir
は、作業ディレクトリーの名前に置き換えます。
インストールマニフェストを作成します。
install-config
マニフェストを定義する YAML ファイルを作成します。install-config.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要クラスターをデプロイするのにプロキシー設定が必要な場合は、次の手順を実行する必要があります。
- プロキシー設定を備えたシードクラスターからシードイメージを作成します。2 つのプロキシー設定が同じである必要はありません。
-
インストールマニフェストの
machineNetwork
フィールドを設定します。
- ファイルを作業ディレクトリーに保存します。
オプション: 次のコマンドを実行して、作業ディレクトリーに設定テンプレートを作成します。
openshift-install image-based create config-template --dir ibi-config-iso-workdir/
$ openshift-install image-based create config-template --dir ibi-config-iso-workdir/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Config-Template created in: ibi-config-iso-workdir
INFO Config-Template created in: ibi-config-iso-workdir
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、作業ディレクトリーに
image-based-config.yaml
設定テンプレートが作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定ファイルを編集します。
image-based-config.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、作業ディレクトリーに設定 ISO を作成します。
openshift-install image-based create config-image --dir ibi-config-iso-workdir/
$ openshift-install image-based create config-image --dir ibi-config-iso-workdir/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Adding NMConnection file <ens1f0.nmconnection> INFO Consuming Install Config from target directory INFO Consuming Image-based Config ISO configuration from target directory INFO Config-Image created in: ibi-config-iso-workdir/auth
INFO Adding NMConnection file <ens1f0.nmconnection> INFO Consuming Install Config from target directory INFO Consuming Image-based Config ISO configuration from target directory INFO Config-Image created in: ibi-config-iso-workdir/auth
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 作業ディレクトリーで出力を確認します。
出力例
ibi-config-iso-workdir/ ├── auth │ ├── kubeadmin-password │ └── kubeconfig └── imagebasedconfig.iso
ibi-config-iso-workdir/ ├── auth │ ├── kubeadmin-password │ └── kubeconfig └── imagebasedconfig.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
任意の方法を使用して
imagebasedconfig.iso
をプリインストールされたホストにアタッチします。ホストを再起動して設定プロセスを完了し、クラスターをデプロイします。
検証
ホストで設定プロセスが完了したら、クラスターにアクセスしてそのステータスを確認します。
次のコマンドを実行して、
kubeconfig
環境変数を kubeconfig ファイルにエクスポートします。export KUBECONFIG=ibi-config-iso-workdir/auth/kubeconfig
$ export KUBECONFIG=ibi-config-iso-workdir/auth/kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターが応答していることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION node/sno-cluster-name.host.example.com Ready control-plane,master 5h15m v1.31.3
NAME STATUS ROLES AGE VERSION node/sno-cluster-name.host.example.com Ready control-plane,master 5h15m v1.31.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.4.2.1.1. image-based-config.yaml マニフェストのリファレンス仕様 リンクのコピーリンクがクリップボードにコピーされました!
以下では、image-based-config.yaml
マニフェストの仕様を説明します。
openshift-install
プログラムは、image-based-config.yaml
マニフェストを使用して、シングルノード OpenShift のイメージベースのデプロイ用にサイト固有の設定 ISO を作成します。
仕様 | 型 | 説明 |
---|---|---|
|
| シングルノード OpenShift クラスターのノードの名前を定義します。 |
仕様 | 型 | 説明 |
---|---|---|
|
| ホストのネットワーク設定を指定します。次に例を示します。
静的ネットワークが必要な場合は、ライブインストール ISO を作成するホストに 重要 インターフェイスの名前は、オペレーティングシステムに表示される実際の NIC 名と同じである必要があります。 |
|
| 全クラスターホストの NTP ソースのリストを指定します。これらの NTP ソースは、クラスター内の既存の NTP ソースに追加されます。NTP ソースのホスト名または IP アドレスを使用できます。 |
|
| シードクラスターのリリースイメージに使用したコンテナーイメージレジストリーを指定します。 |
|
| シングルノード OpenShift ノードのカスタムノードラベルを指定します。次に例を示します。 nodeLabels: node-role.kubernetes.io/edge: true environment: production
|
16.4.2.2. 追加マニフェストのリソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
必要に応じて、シングルノード OpenShift クラスターのイメージベースのデプロイに追加のリソースを定義できます。
追加リソースは、install-config.yaml
および image-based-config.yaml
マニフェストと同じ作業ディレクトリー内の extra-manifests
フォルダーに作成します。
extra-manifests
ディレクトリー内の追加リソースのファイル名は、必ず 30 文字以下にしてください。ファイル名が長いと、デプロイメントが失敗する可能性があります。
16.4.2.2.1. extra-manifests フォルダーにリソースを作成する リンクのコピーリンクがクリップボードにコピーされました!
作業ディレクトリーの extra-manifests
フォルダーにリソースを作成して、シングルノード OpenShift クラスターのイメージベースのデプロイにマニフェストをさらに追加できます。
次の例では、Single Root I/O Virtualization (SR-IOV) ネットワークをデプロイに追加します。
複数のマニフェストを追加し、マニフェストを特定の順序で適用する必要がある場合は、マニフェストのファイル名の前に、必要な順序を表す数字を付ける必要があります。たとえば、00-namespace.yaml
、01-sriov-extra-manifest.yaml
などです。
前提条件
-
install-config.yaml
およびimage-based-config.yaml
マニフェストを含む作業ディレクトリーを作成した。
手順
作業ディレクトリーに移動し、次のコマンドを実行して
extra-manifests
フォルダーを作成します。mkdir extra-manifests
$ mkdir extra-manifests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow extra-manifests
フォルダーにSriovNetworkNodePolicy
およびSriovNetwork
リソースを作成します。リソースを定義する YAML ファイルを作成します。
sriov-extra-manifest.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定 ISO を作成したら、作業ディレクトリーの
.openshift_install_state.json
ファイルで追加のマニフェストへの参照を確認できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第17章 通信事業者コア CNF クラスターの Day 2 オペレーション リンクのコピーリンクがクリップボードにコピーされました!
17.1. 通信事業者コア CNF クラスターの Day 2 オペレーション リンクのコピーリンクがクリップボードにコピーされました!
次の Day 2 オペレーションを使用して、通信事業者コア CNF クラスターを管理できます。
- 通信事業者コア CNF クラスターの更新
- クラスターの更新は、バグや潜在的なセキュリティーの脆弱性を確実に修正するうえで重要なタスクです。詳細は、通信事業者コア CNF クラスターの更新 を参照してください。
- 通信事業者コア CNF クラスターのトラブルシューティングとメンテナンス
- 高帯域幅のネットワークスループットが必要なベアメタル環境のメンテナンスとトラブルシューティングについては、通信事業者コア CNF クラスターのトラブルシューティングとメンテナンス を参照してください。
- 通信事業者コア CNF クラスターの可観測性
- OpenShift Container Platform では、プラットフォームとプラットフォーム上で実行されているワークロードから、パフォーマンスメトリクスやログなどの大量のデータが生成されます。管理者は、ツールを使用して利用可能なデータを収集および分析できます。詳細は、通信事業者コア CNF クラスターの可観測性 を参照してください。
- セキュリティー
- セキュリティー上の重要な考慮事項を遵守することで、通信事業者の環境における高帯域幅ネットワークデプロイメントのセキュリティーを強化できます。詳細は、セキュリティーの基本 を参照してください。
17.2. 通信事業者コア CNF クラスターのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
17.2.1. 通信事業者コア CNF クラスターの更新 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には、すべての偶数番号のリリースと EUS リリース間の更新パスに対する長期サポート (Extended Update Support (EUS)) があります。ある EUS バージョンから次の EUS バージョンに更新できます。y-stream バージョンと z-stream バージョン間で更新することも可能です。
17.2.1.1. 通信事業者コア CNF クラスターのクラスター更新 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの更新は、バグや潜在的なセキュリティーの脆弱性を確実に修正するうえで重要なタスクです。多くの場合、クラウドネイティブネットワーク機能 (CNF) の更新には、クラスターバージョンの更新時に提供されるプラットフォームの追加機能が必要になります。また、クラスタープラットフォームがサポート対象のバージョンになるように、クラスターを定期的に更新する必要があります。
EUS リリースを最新の状態に保ち、一部の重要な z-stream リリースにのみアップグレードすることで、更新により最新の状態に保つのに必要な労力を最小限に抑えることができます。
クラスターの更新パスは、クラスターのサイズとトポロジーによって異なります。ここで説明する更新手順は、3 ノードクラスターから、通信事業者スケールチームによって認定された最大規模のクラスターまで、ほとんどのクラスターに適用されます。これには、混合ワークロードクラスターのシナリオがいくつか含まれています。
説明する更新シナリオは次のとおりです。
- コントロールプレーンのみの更新
- y-stream の更新
- z-stream の更新
コントロールプレーンのみの更新は、以前は EUS から EUS への更新と呼ばれていました。コントロールプレーンのみの更新は、OpenShift Container Platform の偶数番号のマイナーバージョン間でのみ実行可能です。
17.2.2. 更新バージョン間のクラスター API バージョンの検証 リンクのコピーリンクがクリップボードにコピーされました!
API は、コンポーネントの更新に伴い、次第に変更されます。クラウドネイティブネットワーク機能 (CNF) API と更新されたクラスターバージョンの間に互換性があることを検証することが重要です。
17.2.2.1. OpenShift Container Platform API の互換性 リンクのコピーリンクがクリップボードにコピーされました!
新しい y-stream 更新の一部としてどの z-stream リリースに更新するかを検討するときは、移行元の z-stream バージョンにあるすべてのパッチが新しい z-stream バージョンにあることを確認する必要があります。更新後のバージョンに必要なパッチがすべて含まれていない場合、Kubernetes の組み込みの互換性が損なわれます。
たとえば、クラスターのバージョンが 4.15.32 の場合、4.15.32 に適用されているすべてのパッチを含む 4.16 z-stream リリースに更新する必要があります。
17.2.2.1.1. Kubernetes のバージョンスキューについて リンクのコピーリンクがクリップボードにコピーされました!
クラスター Operator は、それぞれ特定の API バージョンをサポートしています。Kubernetes API は時間とともに進化し、新しいバージョンが非推奨になったり、既存の API が変更されたりする可能性があります。これは "バージョンスキュー" と呼ばれます。API の変更は、新しいリリースごとに確認する必要があります。API には Operator の複数のリリース間で互換性がある場合もありますが、互換性は保証されていません。バージョンスキューから生じる問題を軽減するために、明確な更新ストラテジーに従ってください。
17.2.2.2. クラスターのバージョン更新パスの確認 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Container Platform Update Graph ツールを使用して、更新先の z-stream リリースに対してパスが有効かどうかを確認します。Red Hat テクニカルアカウントマネージャーに更新の確認を取り、更新パスが通信事業者の実装で有効であることを確認してください。
更新先の <4.y+1.z> または <4.y+2.z> バージョンは、更新元の <4.y.z> リリースと同じパッチレベルである必要があります。
OpenShift の更新プロセスでは、特定の <4.y.z> リリースに修正が存在する場合、更新先の <4.y+1.z> リリースにもその修正が存在する必要があります。
図17.1 バグ修正のバックポートと更新の図
OpenShift の開発には、リグレッションを防ぐ厳格なバックポートポリシーがあります。たとえば、バグは 4.15.z で修正する前に 4.16.z で修正する必要があります。そのため、更新の図では、マイナーバージョンが大きくても、時系列的に古いリリースへの更新 (4.15.24 から 4.16.2 への更新など) は許可されていません。
17.2.2.3. ターゲットリリースの選択 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Container Platform Update Graph または cincinnati-graph-data リポジトリー を使用して、どのリリースに更新するかを決定します。
17.2.2.3.1. 利用可能な z-stream 更新の確認 リンクのコピーリンクがクリップボードにコピーされました!
新しい z-stream リリースに更新する前に、利用可能なバージョンを確認する必要があります。
z-stream 更新を実行するときにチャネルを変更する必要はありません。
手順
利用可能な z-stream リリースを確認します。以下のコマンドを実行します。
oc adm upgrade
$ oc adm upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.2.3.2. コントロールプレーンのみの更新のチャネルを変更する リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンのみの更新では、チャネルを必要なバージョンに変更する必要があります。
z-stream 更新を実行するときにチャネルを変更する必要はありません。
手順
現在設定されている更新チャネルを特定します。
oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq
$ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{ "channel": "stable-4.14", "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75" }
{ "channel": "stable-4.14", "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75" }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新する新しいチャネルを参照するようにチャネルを変更します。
oc adm upgrade channel eus-4.16
$ oc adm upgrade channel eus-4.16
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新されたチャネルを確認します。
oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq
$ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{ "channel": "eus-4.16", "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75" }
{ "channel": "eus-4.16", "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75" }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.2.3.2.1. EUS から EUS への更新を早期に行うためにチャネルを変更する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の最新リリースへの更新パスは、マイナーリリースの最初の GA から 45 - 90 日が経過するまで、EUS チャネルでも stable チャネルでも利用できません。
新しいリリースへの更新のテストを開始する場合は、fast チャネルを使用できます。
手順
チャネルを
fast-<y+1>
に変更します。たとえば、以下のコマンドを実行します。oc adm upgrade channel fast-4.16
$ oc adm upgrade channel fast-4.16
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいチャネルの更新パスを確認します。以下のコマンドを実行します。
oc adm upgrade
$ oc adm upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新手順に従ってバージョン 4.16 にアップグレードします (バージョン 4.15 から <y+1>)。
注記fast チャネルを使用している場合でも、EUS リリース間でワーカーノードを一時停止したままにすることができます。
-
必要な <y+1> リリースに更新したら、チャネルを再度変更し、今度は
fast-<y+2>
に変更します。 - EUS 更新手順に従って、必要な <y+2> リリースに更新します。
17.2.2.3.3. y-stream 更新のチャネルの変更 リンクのコピーリンクがクリップボードにコピーされました!
y-stream 更新では、チャネルを次のリリースチャネルに変更します。
実稼働クラスターには、stable または EUS リリースチャネルを使用してください。
手順
更新チャネルを変更します。
oc adm upgrade channel stable-4.15
$ oc adm upgrade channel stable-4.15
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいチャネルの更新パスを確認します。以下のコマンドを実行します。
oc adm upgrade
$ oc adm upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.3. 通信事業者コアクラスタープラットフォームの更新準備 リンクのコピーリンクがクリップボードにコピーされました!
通常、通信事業者のクラスターはベアメタルハードウェア上で実行されます。多くの場合、重要なセキュリティー修正を適用したり、新しい機能を導入したり、OpenShift Container Platform の新しいリリースとの互換性を維持したりするために、ファームウェアを更新する必要があります。
17.2.3.1. ホストファームウェアが更新と互換性があることを確認する リンクのコピーリンクがクリップボードにコピーされました!
お客様がクラスターで実行するファームウェアバージョンの更新は、お客様の責任です。ホストファームウェアの更新は、OpenShift Container Platform の更新プロセスには含まれません。OpenShift Container Platform のバージョンと一緒にファームウェアを更新することは推奨されません。
ハードウェアベンダーは、ご使用のハードウェアに最新の認定済みファームウェアバージョンを適用することを推奨しています。通信事業者のユースケースでは、ファームウェアの更新を実稼働環境に適用する前に、必ずテスト環境で検証してください。ホストファームウェアが最適なものでないと、通信事業者の CNF ワークロードの高スループット特性に悪影響が及ぶ可能性があります。
新しいファームウェア更新を徹底的にテストして、OpenShift Container Platform の最新バージョンで期待どおりに動作することを確認してください。ターゲットの OpenShift Container Platform 更新バージョンを使用して最新のファームウェアバージョンをテストするのが理想的です。
17.2.3.2. レイヤード製品が更新と互換性があることを確認する リンクのコピーリンクがクリップボードにコピーされました!
更新を開始する前に、更新先の OpenShift Container Platform のバージョンですべてのレイヤード製品が動作することを確認します。通常、これにはすべての Operator が含まれます。
手順
クラスターに現在インストールされている Operator を確認します。たとえば、以下のコマンドを実行します。
oc get csv -A
$ oc get csv -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE gitlab-operator-kubernetes.v0.17.2 GitLab 0.17.2 gitlab-operator-kubernetes.v0.17.1 Succeeded openshift-operator-lifecycle-manager packageserver Package Server 0.19.0 Succeeded
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE gitlab-operator-kubernetes.v0.17.2 GitLab 0.17.2 gitlab-operator-kubernetes.v0.17.1 Succeeded openshift-operator-lifecycle-manager packageserver Package Server 0.19.0 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OLM を使用してインストールする Operator が更新先のバージョンと互換性があることを確認します。
Operator Lifecycle Manager (OLM) によってインストールされる Operator は、標準のクラスター Operator セットの一部ではありません。
Operator Update Information Checker を使用して、それぞれの y-stream 更新後に Operator を更新する必要があるかどうか、または次の EUS リリースに完全に更新されるまで待つことができるかどうかを確認してください。
ヒントOperator Update Information Checker を使用して、Operator の特定のリリースと互換性のある OpenShift Container Platform のバージョンを確認することもできます。
OLM 以外の方法でインストールする Operator が更新先のバージョンと互換性があることを確認します。
Red Hat によって直接サポートされていない、OLM によってインストールされるすべての Operator について、Operator ベンダーに問い合わせてリリースの互換性を確認してください。
- 一部の Operator は、OpenShift Container Platform の複数のリリースと互換性があります。クラスターの更新が完了するまで、Operator を更新する必要がない場合があります。詳細は、「ワーカーノードの更新」を参照してください。
- 最初の y-stream コントロールプレーンの更新を実行した後に Operator を更新する方法は、「すべての OLM Operator の更新」を参照してください。
17.2.3.3. 更新前にノードに MachineConfigPool ラベルを適用する リンクのコピーリンクがクリップボードにコピーされました!
約 8 - 10 個のノードをグループ化するために、MachineConfigPool
(mcp
) ノードラベルを準備します。mcp
グループを使用すると、クラスターの他の部分とは別にノードのグループを再起動できます。
mcp
ノードラベルを使用すると、更新プロセス中にノードセットを一時停止および一時停止解除して、任意のタイミングで更新と再起動を実行できます。
17.2.3.3.1. クラスター更新の段階的実施 リンクのコピーリンクがクリップボードにコピーされました!
更新中に問題が発生する場合があります。多くの場合、この問題はハードウェア障害やノードをリセットする必要性に関連しています。mcp
ノードラベルを使用すると、重要なタイミングで更新を一時停止し、一時停止および一時停止解除したノードを追跡しながら、段階的にノードを更新できます。問題が発生した場合は、一時停止状態でないノードを使用して、すべてのアプリケーション Pod を実行し続けるのに十分な数のノードが実行されていることを確認します。
17.2.3.3.2. ワーカーノードを MachineConfigPool グループに分割する リンクのコピーリンクがクリップボードにコピーされました!
ワーカーノードを mcp
グループに分割する方法は、クラスター内のノードの数やノードロールに割り当てるノードの数によって異なります。デフォルトでは、クラスター内の 2 つのロールは、コントロールプレーンとワーカーです。
通信事業者のワークロードを実行するクラスターでは、ワーカーノードを CNF コントロールプレーンのロールと CNF データプレーンのロール間でさらに分割できます。ワーカーノードをこれら 2 つのグループに分割する mcp
ロールラベルを追加します。
大規模なクラスターでは、CNF コントロールプレーンのロールに 100 個ほどのワーカーノードが含まれる場合があります。クラスター内のノード数に関係なく、各 MachineConfigPool
グループのノード数は、10 程度に抑えてください。これにより、一度に停止するノードの数を制御できます。複数の MachineConfigPool
グループを使用すると、同時に複数のグループを一時停止解除して更新を高速化したり、更新を 2 つ以上のメンテナンス期間に分けたりすることができます。
- 15 個のワーカーノードを持つクラスターの例
15 個のワーカーノードを持つクラスターを考えてみます。
- 10 個のワーカーノードは CNF コントロールプレーンノードです。
- 5 個のワーカーノードは CNF データプレーンノードです。
CNF コントロールプレーンのロールとデータプレーンワーカーノードのロールを、それぞれ少なくとも 2 つの
mcp
グループに分割します。ロールごとに 2 つのmcp
グループを用意することで、更新の影響を受けないノードのセットを 1 つ確保できます。- 6 つのワーカーノードを持つクラスターの例
6 つのワーカーノードを持つクラスターを考えてみましょう。
-
ワーカーノードを、それぞれ 2 つのノードからなる 3 つの
mcp
グループに分割します。
mcp
グループの 1 つをアップグレードします。CNF の互換性を検証できるように、更新したノードを 1 日間そのままにしておきます。その後、他の 4 つのノードの更新を完了します。-
ワーカーノードを、それぞれ 2 つのノードからなる 3 つの
mcp
グループの一時停止を解除するプロセスとペースは、CNF アプリケーションと設定によって決まります。
CNF Pod がクラスター内のノード間のスケジューリングに対応できる場合は、一度に複数の mcp
グループの一時停止を解除し、mcp
カスタムリソース (CR) の MaxUnavailable
を最大 50% に設定できます。これにより、mcp
グループ内の最大半数のノードを再起動して更新できます。
17.2.3.3.3. 設定されているクラスター MachineConfigPool ロールの確認 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内で現在設定されている MachineConfigPool
ロールを確認します。
手順
クラスター内で現在設定されている
mcp
グループを取得します。oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-bere83 True False False 3 3 3 0 25d worker rendered-worker-245c4f True False False 2 2 2 0 25d
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-bere83 True False False 3 3 3 0 25d worker rendered-worker-245c4f True False False 2 2 2 0 25d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mcp
ロールのリストをクラスター内のノードのリストと比較します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記mcp
グループの変更を適用すると、ノードロールが更新されます。ワーカーノードを
mcp
グループに分割する方法を決定します。
17.2.3.3.4. クラスターの MachineConfigPool グループの作成 リンクのコピーリンクがクリップボードにコピーされました!
mcp
グループの作成は 2 つのステップで行います。
-
クラスター内のノードに
mcp
ラベルを追加します。 -
ラベルに基づいてノードをまとめるクラスターに
mcp
CR を適用します。
手順
ノードにラベルを付けて、
mcp
グループに配置できるようにします。以下のコマンドを実行します。oc label node worker-0 node-role.kubernetes.io/mcp-1=
$ oc label node worker-0 node-role.kubernetes.io/mcp-1=
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node worker-1 node-role.kubernetes.io/mcp-2=
$ oc label node worker-1 node-role.kubernetes.io/mcp-2=
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mcp-1
およびmcp-2
ラベルをノードに適用します。以下に例を示します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの
mcp
CR としてラベルを適用する YAML カスタムリソース (CR) を作成します。次の YAML をmcps.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfigPool
リソースを作成します。oc apply -f mcps.yaml
$ oc apply -f mcps.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-2 created
machineconfigpool.machineconfiguration.openshift.io/mcp-2 created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
クラスターに MachineConfigPool
リソースが適用される様子を監視します。mcp
リソースを適用すると、ノードが新しいマシン設定プールに追加されます。これには数分かかります。
ノードは、mcp
グループに追加されている間は再起動しません。元のワーカーおよびマスター mcp
グループは変更されません。
新しい
mcp
リソースのステータスを確認します。oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-be3e83 True False False 3 3 3 0 25d mcp-1 rendered-mcp-1-2f4c4f False True True 1 0 0 0 10s mcp-2 rendered-mcp-2-2r4s1f False True True 1 0 0 0 10s worker rendered-worker-23fc4f False True True 0 0 0 2 25d
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-be3e83 True False False 3 3 3 0 25d mcp-1 rendered-mcp-1-2f4c4f False True True 1 0 0 0 10s mcp-2 rendered-mcp-2-2r4s1f False True True 1 0 0 0 10s worker rendered-worker-23fc4f False True True 0 0 0 2 25d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最終的に、リソースは完全に適用されます。
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-be3e83 True False False 3 3 3 0 25d mcp-1 rendered-mcp-1-2f4c4f True False False 1 1 1 0 7m33s mcp-2 rendered-mcp-2-2r4s1f True False False 1 1 1 0 51s worker rendered-worker-23fc4f True False False 0 0 0 0 25d
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-be3e83 True False False 3 3 3 0 25d mcp-1 rendered-mcp-1-2f4c4f True False False 1 1 1 0 7m33s mcp-2 rendered-mcp-2-2r4s1f True False False 1 1 1 0 51s worker rendered-worker-23fc4f True False False 0 0 0 0 25d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.3.4. 通信事業者のデプロイメント環境に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者の環境では、ほとんどのクラスターはインターネット非接続のネットワーク内にあります。このような環境でクラスターを更新するには、オフラインイメージリポジトリーを更新する必要があります。
17.2.3.5. クラスタープラットフォームの更新の準備 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを更新する前に、いくつかの基本的なチェックと検証を実行して、クラスターの更新の準備ができていることを確認します。
手順
次のコマンドを実行して、クラスター内に失敗した Pod や進行中の Pod がないことを確認します。
oc get pods -A | grep -E -vi 'complete|running'
$ oc get pods -A | grep -E -vi 'complete|running'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記保留中の状態の Pod がある場合は、このコマンドを複数回実行する必要がある場合があります。
クラスター内のすべてのノードが利用可能であることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのベアメタルノードがプロビジョニングされ、準備ができていることを確認します。
oc get bmh -n openshift-machine-api
$ oc get bmh -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
worker-1
ノードのプロビジョニング中にエラーが発生しています。
検証
すべてのクラスター Operator の準備ができていることを確認します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.4. 通信事業者コア CNF クラスター更新前の CNF Pod の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラウドネイティブネットワーク機能 (CNF) を開発するときは、Red Hat best practices for Kubernetes のガイダンスに従って、更新中にクラスターが Pod をスケジュールできるようにします。
Deployment
リソースを使用して、常に Pod をグループでデプロイしてください。Deployment
リソースは、単一障害点が生まれないように、利用可能なすべての Pod にワークロードを分散します。Deployment
リソースによって管理されている Pod が削除されると、新しい Pod が自動的にその代わりになります。
17.2.4.1. Pod Disruption Budget により CNF ワークロードを無停止で実行する リンクのコピーリンクがクリップボードにコピーされました!
適用する PodDisruptionBudget
カスタムリソース (CR) で Pod Disruption Budget を設定すると、デプロイメント内の Pod の最小数を設定して、CNF ワークロードを無停止で実行できます。この値を設定するときは注意してください。不適切に設定すると更新が失敗する可能性があります。
たとえば、デプロイメントに 4 つの Pod があり、Pod Disruption Budget を 4 に設定した場合、クラスタースケジューラーによって常に 4 つの Pod が実行され、Pod をスケールダウンできなくなります。
そうではなく、Pod Disruption Budget を 2 に設定し、4 つの Pod のうち 2 つをダウン状態としてスケジュールできるようにします。そうすれば、それらの Pod が配置されているワーカーノードを再起動できます。
Pod Disruption Budget を 2 に設定しても、更新中など、一定期間にわたりデプロイメントが 2 つの Pod のみで実行されるわけではありません。クラスタースケジューラーは、2 つの古い Pod を置き換える 2 つの新しい Pod を作成します。しかし、新しい Pod がオンラインになってから古い Pod が削除されるまでには、少し時間がかかります。
17.2.4.2. Pod が同じクラスターノード上で実行されないようにする リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes で高可用性を実現するには、クラスター内の別々のノードで重複したプロセスを実行する必要があります。これにより、1 つのノードが使用できなくなった場合でも、アプリケーションを引き続き実行できます。OpenShift Container Platform では、デプロイメント内の別々の Pod にプロセスを自動的に複製できます。デプロイメント内の Pod が同じクラスターノード上で実行されないようにするには、Pod
仕様でアンチアフィニティーを設定します。
更新時に Pod のアンチアフィニティーを設定すると、Pod がクラスター内のノード全体に均等に分散されるようになります。つまり、更新時にノードの再起動が容易になります。たとえば、ノード上に 1 つのデプロイメントの Pod が 4 つあり、Pod Disruption Budget が Pod を一度に 1 つだけ削除できるように設定されている場合、そのノードの再起動には 4 倍の時間がかかります。Pod のアンチアフィニティーを設定すると、Pod がクラスター全体に分散され、このような事態の発生が防止されます。
17.2.4.3. アプリケーションの liveness、readiness、および startup プローブ リンクのコピーリンクがクリップボードにコピーされました!
更新をスケジュールする前に、liveness、readiness、および startup プローブを使用して、ライブアプリケーションコンテナーの健全性をチェックできます。これらは、アプリケーションコンテナーの状態の保持に依存する Pod で使用するのに非常に便利なツールです。
- liveness ヘルスチェック
- コンテナーが実行中かどうかを確認します。コンテナーの liveness プローブが失敗した場合、Pod が再起動ポリシーに基づいて応答します。
- readiness プローブ
- コンテナーがサービス要求を受け入れる準備ができているかどうかを確認します。コンテナーの readiness プローブが失敗した場合、kubelet が利用可能なサービスエンドポイントのリストからコンテナーを削除します。
- startup プローブ
-
startup プローブは、コンテナー内のアプリケーションが起動しているかどうかを示します。その他のプローブはすべて、起動に成功するまで無効にされます。startup プローブが成功しない場合、kubelet がコンテナーを強制終了し、そのコンテナーが Pod の
restartPolicy
設定の対象となります。
17.2.5. 通信事業者コア CNF クラスターを更新する前の作業 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの更新を開始する前に、ワーカーノードを一時停止し、etcd データベースをバックアップし、最終的なクラスターのヘルスチェックを実行する必要があります。
17.2.5.1. 更新前のワーカーノードの一時停止 リンクのコピーリンクがクリップボードにコピーされました!
更新を開始する前に、ワーカーノードを一時停止する必要があります。次の例では、mcp-1
と mcp-2
という 2 つの mcp
グループがあります。パッチを適用して、これらの各 MachineConfigPool
グループの spec.paused
フィールドを true
にします。
手順
次のコマンドを実行して、
mcp
CR にパッチを適用し、ノードを一時停止し、それらのノードから Pod をドレインして削除します。oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":true}}'
$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch mcp/mcp-2 --type merge --patch '{"spec":{"paused":true}}'
$ oc patch mcp/mcp-2 --type merge --patch '{"spec":{"paused":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 一時停止した
mcp
グループのステータスを取得します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 true mcp-2 true
MCP Paused --- ------ master false mcp-1 true mcp-2 true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトのコントロールプレーンおよびワーカーの mcp
グループは、更新中に変更されません。
17.2.5.2. 更新を開始する前の etcd データベースのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
更新を開始する前に、etcd データベースをバックアップする必要があります。
17.2.5.2.1. etcd データのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。
単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 クラスター全体のプロキシーが有効になっているかどうかを確認している。
ヒントoc get proxy cluster -o yaml
の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy
、httpsProxy
、およびnoProxy
フィールドに値が設定されている場合に有効にされます。
手順
コントロールプレーンノードの root としてデバッグセッションを開始します。
oc debug --as-root node/<node_name>
$ oc debug --as-root node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デバッグシェルで root ディレクトリーを
/host
に変更します。chroot /host
sh-4.4# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、
NO_PROXY
、HTTP_PROXY
、およびHTTPS_PROXY
環境変数をエクスポートします。export HTTP_PROXY=http://<your_proxy.example.com>:8080
$ export HTTP_PROXY=http://<your_proxy.example.com>:8080
Copy to Clipboard Copied! Toggle word wrap Toggle overflow export HTTPS_PROXY=https://<your_proxy.example.com>:8080
$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
Copy to Clipboard Copied! Toggle word wrap Toggle overflow export NO_PROXY=<example.com>
$ export NO_PROXY=<example.com>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デバッグシェルで
cluster-backup.sh
スクリプトを実行し、バックアップの保存先となる場所を渡します。ヒントcluster-backup.sh
スクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot save
コマンドに関連するラッパーです。/usr/local/bin/cluster-backup.sh /home/core/assets/backup
sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup
Copy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトの出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、コントロールプレーンホストの
/home/core/assets/backup/
ディレクトリーにファイルが 2 つ作成されます。-
snapshot_<datetimestamp>.db
: このファイルは etcd スナップショットです。cluster-backup.sh
スクリプトで、その有効性を確認します。 static_kuberesources_<datetimestamp>.tar.gz
: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。注記etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。
etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。
-
17.2.5.2.2. シングル etcd バックアップの作成 リンクのコピーリンクがクリップボードにコピーされました!
次の手順でカスタムリソース (CR) を作成して適用することで、シングル etcd バックアップを作成します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) にアクセスできる。
手順
動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。
次の例のような内容で、
etcd-backup-pvc.yaml
という名前の永続ボリューム要求 (PVC) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
以下のコマンドを実行して PVC を適用します。
oc apply -f etcd-backup-pvc.yaml
$ oc apply -f etcd-backup-pvc.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、PVC が作成されたことを確認します。
oc get pvc
$ oc get pvc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE etcd-backup-pvc Bound 51s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE etcd-backup-pvc Bound 51s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記動的 PVC は、マウントされるまで
Pending
状態から遷移しません。次の例のような内容で、
etcd-single-backup.yaml
という名前の CR ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- バックアップを保存する PVC の名前。この値は、使用している環境に応じて調整してください。
CR を適用してシングルバックアップを開始します。
oc apply -f etcd-single-backup.yaml
$ oc apply -f etcd-single-backup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
動的にプロビジョニングされたストレージが利用できない場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。
次の内容で、
etcd-backup-local-storage.yaml
という名前のStorageClass
CR ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
StorageClass
CR を適用します。oc apply -f etcd-backup-local-storage.yaml
$ oc apply -f etcd-backup-local-storage.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような内容の
etcd-backup-pv-fs.yaml
という名前の PV を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、PV が作成されたことを確認します。
oc get pv
$ oc get pv
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE etcd-backup-pv-fs 100Gi RWO Retain Available etcd-backup-local-storage 10s
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE etcd-backup-pv-fs 100Gi RWO Retain Available etcd-backup-local-storage 10s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような内容で、
etcd-backup-pvc.yaml
という名前の PVC を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
以下のコマンドを実行して PVC を適用します。
oc apply -f etcd-backup-pvc.yaml
$ oc apply -f etcd-backup-pvc.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような内容で、
etcd-single-backup.yaml
という名前の CR ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- バックアップを保存する永続ボリューム要求 (PVC) の名前。この値は、使用している環境に応じて調整してください。
CR を適用してシングルバックアップを開始します。
oc apply -f etcd-single-backup.yaml
$ oc apply -f etcd-single-backup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.5.3. クラスターの健全性の確認 リンクのコピーリンクがクリップボードにコピーされました!
更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。
手順
次のコマンドを実行して、クラスター Operator のステータスを確認します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターノードのステータスを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 進行中の Pod や失敗した Pod がないことを確認します。次のコマンドを実行したときに、Pod が 1 つも返されないようにします。
oc get po -A | grep -E -iv 'running|complete'
$ oc get po -A | grep -E -iv 'running|complete'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.6. コントロールプレーンのみのクラスター更新の完了 リンクのコピーリンクがクリップボードにコピーされました!
次の手順に従って、コントロールプレーンのみのクラスター更新を実行し、更新が完了するまで監視します。
コントロールプレーンのみの更新は、以前は EUS から EUS への更新と呼ばれていました。コントロールプレーンのみの更新は、OpenShift Container Platform の偶数番号のマイナーバージョン間でのみ実行可能です。
17.2.6.1. コントロールプレーンのみまたは y-stream の更新の承認 リンクのコピーリンクがクリップボードにコピーされました!
4.11 以降のすべてのバージョンに更新する場合は、更新の続行を手動で承認する必要があります。
更新を承認する前に、更新先のバージョンで削除されている Kubernetes API を使用していないことを確認してください。たとえば、OpenShift Container Platform 4.17 では、API の削除はありません。詳細は、「Kubernetes API の削除」を参照してください。
前提条件
- クラスターで実行されているすべてのアプリケーションの API が、OpenShift Container Platform の次期 y-stream リリースと互換性があることを確認した。互換性の詳細は、「更新バージョン間のクラスター API バージョンの検証」を参照してください。
手順
次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。
oc adm upgrade
$ oc adm upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの更新が正常に完了しない場合は、
Reason
およびMessage
セクションに更新の失敗に関する詳細が表示されます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例は、Red Hat のナレッジベース記事 (Preparing to upgrade to OpenShift Container Platform 4.16) に、リリース間の API 互換性の検証に関する詳細が記載されています。
検証
次のコマンドを実行して更新を確認します。
oc get configmap admin-acks -n openshift-config -o json | jq .data
$ oc get configmap admin-acks -n openshift-config -o json | jq .data
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例では、コントロールプレーンのみの更新で、クラスターをバージョン 4.14 から 4.15 に更新してから、4.15 から 4.16 に更新します。
17.2.6.2. クラスターの更新の開始 リンクのコピーリンクがクリップボードにコピーされました!
ある y-stream リリースから次のリリースに更新する場合、中間の z-stream リリースにも互換性があることを確認する必要があります。
oc adm upgrade
コマンドを実行すると、更新先のリリースが実行可能なリリースであることを確認できます。oc adm upgrade
コマンドは、互換性のある更新リリースをリスト表示します。
手順
更新を開始します。
oc adm upgrade --to=4.15.33
$ oc adm upgrade --to=4.15.33
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要- コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
- y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
- z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。
出力例
Requested update to 4.15.33
Requested update to 4.15.33
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Requested update
値は、実際の更新に応じて変わります。
17.2.6.3. クラスターの更新の監視 リンクのコピーリンクがクリップボードにコピーされました!
更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。
手順
クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。
watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
更新中、この watch
コマンドは、一度に 1 つまたは複数のクラスター Operator を循環し、MESSAGE
列に Operator 更新のステータスを表示します。
クラスター Operator の更新プロセスが完了すると、各コントロールプレーンノードが 1 つずつ再起動します。
更新のこの部分で、クラスター Operator が再度更新中であることやデグレード状態であることを示すメッセージが報告されます。これは、ノードを再起動している間、コントロールプレーンノードがオフラインになるためです。
最後のコントロールプレーンノードの再起動が完了するとすぐに、更新されたクラスターのバージョンが表示されます。
コントロールプレーンの更新が完了すると、次のようなメッセージが表示されます。この例では、中間の y-stream リリースへの更新が完了したことを示しています。
17.2.6.4. OLM Operator の更新 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者の環境では、ソフトウェアを実稼働クラスターにロードする前に検査する必要があります。また、実稼働クラスターが非接続ネットワーク内で設定されるため、必ずしもインターネットに直接接続されているわけではありません。クラスターが非接続ネットワーク内にあるため、新しいバージョンをクラスターごとに管理できるように、インストール時に OpenShift Operator を手動で更新するように設定します。Operator を新しいバージョンに移行するには、次の手順を実行します。
手順
更新する必要がある Operator を確認します。
oc get installplan -A | grep -E 'APPROVED|false'
$ oc get installplan -A | grep -E 'APPROVED|false'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME CSV APPROVAL APPROVED metallb-system install-nwjnh metallb-operator.v4.16.0-202409202304 Manual false openshift-nmstate install-5r7wr kubernetes-nmstate-operator.4.16.0-202409251605 Manual false
NAMESPACE NAME CSV APPROVAL APPROVED metallb-system install-nwjnh metallb-operator.v4.16.0-202409202304 Manual false openshift-nmstate install-5r7wr kubernetes-nmstate-operator.4.16.0-202409251605 Manual false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの Operator の
InstallPlan
リソースにパッチを適用します。oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'
$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
installplan.operators.coreos.com/install-nwjnh patched
installplan.operators.coreos.com/install-nwjnh patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して namespace を監視します。
oc get all -n metallb-system
$ oc get all -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新が完了すると、必要な Pod が
Running
状態になり、必要なReplicaSet
リソースが準備完了になるはずです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Operator を再度更新する必要がないことを確認します。
oc get installplan -A | grep -E 'APPROVED|false'
$ oc get installplan -A | grep -E 'APPROVED|false'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は返されないはずです。
注記Operator によっては、最終バージョンの前にインストールする必要がある中間の z-stream リリースバージョンがあるため、更新を 2 回承認する必要がある場合があります。
17.2.6.4.1. 2 回目の y-stream 更新の実行 リンクのコピーリンクがクリップボードにコピーされました!
最初の y-stream 更新を完了したら、y-stream のコントロールプレーンのバージョンを新しい EUS バージョンに更新する必要があります。
手順
選択した <4.y.z> リリースが、適切な移行先チャネルとして現在もリスト表示されることを確認します。
oc adm upgrade
$ oc adm upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記新しい y-stream リリースの最初の GA 直後に更新すると、
oc adm upgrade
コマンドを実行したときに、利用可能な新しい y-stream リリースが表示されない場合があります。オプション: 推奨されない更新リリースの候補を表示します。以下のコマンドを実行します。
oc adm upgrade --include-not-recommended
$ oc adm upgrade --include-not-recommended
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例では、Microsoft Azure でホストされているクラスターに影響を与える可能性のある潜在的なエラーが示されています。ベアメタルクラスターのリスクは示されていません。
17.2.6.4.2. y-stream リリースの更新の承認 リンクのコピーリンクがクリップボードにコピーされました!
y-stream リリース間で移行する場合、更新を明示的に承認するために patch コマンドを実行する必要があります。oc adm upgrade
コマンドの出力に、実行する特定のコマンドを示す URL が表示されます。
更新を承認する前に、更新先のバージョンで削除されている Kubernetes API を使用していないことを確認してください。たとえば、OpenShift Container Platform 4.17 では、API の削除はありません。詳細は、「Kubernetes API の削除」を参照してください。
前提条件
- クラスターで実行されているすべてのアプリケーションの API が、OpenShift Container Platform の次期 y-stream リリースと互換性があることを確認した。互換性の詳細は、「更新バージョン間のクラスター API バージョンの検証」を参照してください。
手順
次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。
oc adm upgrade
$ oc adm upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの更新が正常に完了しない場合は、
Reason
およびMessage
セクションに更新の失敗に関する詳細が表示されます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例については、Red Hat のナレッジベース記事 (Preparing to upgrade to OpenShift Container Platform 4.16) に、リリース間の API 互換性の検証に関する詳細が記載されています。
検証
次のコマンドを実行して更新を確認します。
oc get configmap admin-acks -n openshift-config -o json | jq .data
$ oc get configmap admin-acks -n openshift-config -o json | jq .data
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例では、コントロールプレーンのみの更新で、クラスターをバージョン 4.14 から 4.15 に更新してから、4.15 から 4.16 に更新します。
17.2.6.5. y-stream コントロールプレーンの更新の開始 リンクのコピーリンクがクリップボードにコピーされました!
移行先の完全な新しいリリースを決定したら、oc adm upgrade –to=x.y.z
コマンドを実行できます。
手順
y-stream コントロールプレーンの更新を開始します。たとえば、以下のコマンドを実行します。
oc adm upgrade --to=4.16.14
$ oc adm upgrade --to=4.16.14
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Requested update to 4.16.14
Requested update to 4.16.14
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 移行先の z-stream リリースに、使用中のプラットフォーム以外のプラットフォームに関する問題がある場合があります。次の例は、Microsoft Azure でのクラスター更新の潜在的な問題を示しています。
oc adm upgrade --to=4.16.15
$ oc adm upgrade --to=4.16.15
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
error: the update 4.16.15 is not one of the recommended updates, but is available as a conditional update. To accept the Recommended=Unknown risk and to proceed with update use --allow-not-recommended. Reason: EvaluationFailed Message: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0 In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461
error: the update 4.16.15 is not one of the recommended updates, but is available as a conditional update. To accept the Recommended=Unknown risk and to proceed with update use --allow-not-recommended. Reason: EvaluationFailed Message: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0 In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例では、Microsoft Azure でホストされているクラスターに影響を与える可能性のある潜在的なエラーが示されています。ベアメタルクラスターのリスクは示されていません。
oc adm upgrade --to=4.16.15 --allow-not-recommended
$ oc adm upgrade --to=4.16.15 --allow-not-recommended
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
warning: with --allow-not-recommended you have accepted the risks with 4.14.11 and bypassed Recommended=Unknown EvaluationFailed: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0 In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461 Requested update to 4.16.15
warning: with --allow-not-recommended you have accepted the risks with 4.14.11 and bypassed Recommended=Unknown EvaluationFailed: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0 In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461 Requested update to 4.16.15
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.6.6. クラスター更新の 2 番目の部分を監視する リンクのコピーリンクがクリップボードにコピーされました!
クラスターの 2 番目の部分が <y+1> バージョンに更新される様子を監視します。
手順
<y+1> 更新の 2 番目の部分の進行状況を監視します。たとえば、4.15 から 4.16 への更新を監視するには、次のコマンドを実行します。
watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.15; oc get co | grep 4.16; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.15; oc get co | grep 4.16; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最のコ後ントロールプレーンノードが完了すると、クラスターのバージョンが新しい EUS リリースにすぐに更新されます。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.6.7. すべての OLM Operator の更新 リンクのコピーリンクがクリップボードにコピーされました!
複数バージョンのアップグレードの第 2 フェーズとして、すべての Operator を承認し、アップグレードするその他の Operator のインストールプランをさらに追加する必要があります。
「OLM Operator の更新」で説明されているのと同じ手順に従います。必要に応じて、OLM 以外の Operator も更新してください。
手順
クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。
watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新する必要がある Operator を確認します。
oc get installplan -A | grep -E 'APPROVED|false'
$ oc get installplan -A | grep -E 'APPROVED|false'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの Operator の
InstallPlan
リソースにパッチを適用します。oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'
$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して namespace を監視します。
oc get all -n metallb-system
$ oc get all -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新が完了すると、必要な Pod が
Running
状態になり、必要なReplicaSet
リソースが準備完了になるはずです。
検証
更新中、この watch
コマンドは、一度に 1 つまたは複数のクラスター Operator を循環し、MESSAGE
列に Operator 更新のステータスを表示します。
クラスター Operator の更新プロセスが完了すると、各コントロールプレーンノードが 1 つずつ再起動します。
更新のこの部分で、クラスター Operator が再度更新中であることやデグレード状態であることを示すメッセージが報告されます。これは、ノードを再起動している間、コントロールプレーンノードがオフラインになるためです。
17.2.6.8. ワーカーノードの更新 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンを更新した後、作成した適切な mcp
グループの一時停止を解除してワーカーノードをアップグレードします。mcp
グループの一時停止を解除すると、そのグループ内のワーカーノードのアップグレードプロセスが開始します。クラスター内の各ワーカーノードが再起動し、必要に応じて新しい EUS、y-stream、または z-stream バージョンにアップグレードされます。
コントロールプレーンのみのアップグレードの場合、ワーカーノードの更新時に、再起動が 1 回だけ必要になり、ワーカーノードが <y+2> リリースバージョンにジャンプします。これは、大規模なベアメタルクラスターのアップグレードにかかる時間を短縮するために追加された機能です。
この時点で保留することも可能です。ワーカーノードが <y-2> リリースであっても、新しい EUS リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。
mcp
グループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcp
グループのリストを取得します。oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一度にアップグレードする
mcp
グループの数を決定してください。これは、一度に停止できる CNF Pod の数、および Pod Disruption Budget とアンチアフィニティーの設定よって異なります。クラスター内のノードのリストを取得します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 一時停止中の
MachineConfigPool
グループを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 true mcp-2 true
MCP Paused --- ------ master false mcp-1 true mcp-2 true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MachineConfigPool
は、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。必要な
mcp
グループを一時停止解除して、アップグレードを開始します。oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'
$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な
mcp
グループが一時停止解除されていることを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 true
MCP Paused --- ------ master false mcp-1 false mcp-2 true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各
mcp
グループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.6.9. 新しく更新されたクラスターの健全性の確認 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。
手順
次のコマンドを実行してクラスターのバージョンを確認します。
oc get clusterversion
$ oc get clusterversion
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいクラスターバージョンが返され、
PROGRESSING
列にFalse
が返されるはずです。すべてのノードが準備完了であることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のすべてのノードが
Ready
ステータスで、同じバージョンを実行しているはずです。クラスター内に一時停止中の
mcp
リソースがないことを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 false
MCP Paused --- ------ master false mcp-1 false mcp-2 false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator が利用可能であることを確認します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator の
AVAILABLE
列にTrue
と報告されるはずです。すべての Pod が正常であることを確認します。
oc get po -A | grep -E -iv 'complete|running'
$ oc get po -A | grep -E -iv 'complete|running'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod は 1 つも返されないはずです。
注記更新後もまだ移行中の Pod がいくつか見られる場合があります。しばらくこれを監視して、すべての Pod がクリアされることを確認してください。
17.2.7. y-stream クラスターの更新の完了 リンクのコピーリンクがクリップボードにコピーされました!
次の手順に従って、y-stream クラスターの更新を実行し、更新が完了するまで監視します。y-stream 更新の完了は、コントロールプレーンのみの更新よりも簡単です。
17.2.7.1. コントロールプレーンのみまたは y-stream の更新の承認 リンクのコピーリンクがクリップボードにコピーされました!
4.11 以降のすべてのバージョンに更新する場合は、更新の続行を手動で承認する必要があります。
更新を承認する前に、更新先のバージョンで削除されている Kubernetes API を使用していないことを確認してください。たとえば、OpenShift Container Platform 4.17 では、API の削除はありません。詳細は、「Kubernetes API の削除」を参照してください。
前提条件
- クラスターで実行されているすべてのアプリケーションの API が、OpenShift Container Platform の次期 y-stream リリースと互換性があることを確認した。互換性の詳細は、「更新バージョン間のクラスター API バージョンの検証」を参照してください。
手順
次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。
oc adm upgrade
$ oc adm upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの更新が正常に完了しない場合は、
Reason
およびMessage
セクションに更新の失敗に関する詳細が表示されます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例については、Red Hat のナレッジベース記事 (Preparing to upgrade to OpenShift Container Platform 4.16) に、リリース間の API 互換性の検証に関する詳細が記載されています。
検証
次のコマンドを実行して更新を確認します。
oc get configmap admin-acks -n openshift-config -o json | jq .data
$ oc get configmap admin-acks -n openshift-config -o json | jq .data
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例では、コントロールプレーンのみの更新で、クラスターをバージョン 4.14 から 4.15 に更新してから、4.15 から 4.16 に更新します。
17.2.7.2. クラスターの更新の開始 リンクのコピーリンクがクリップボードにコピーされました!
ある y-stream リリースから次のリリースに更新する場合、中間の z-stream リリースにも互換性があることを確認する必要があります。
oc adm upgrade
コマンドを実行すると、更新先のリリースが実行可能なリリースであることを確認できます。oc adm upgrade
コマンドは、互換性のある更新リリースをリスト表示します。
手順
更新を開始します。
oc adm upgrade --to=4.15.33
$ oc adm upgrade --to=4.15.33
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要- コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
- y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
- z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。
出力例
Requested update to 4.15.33
Requested update to 4.15.33
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Requested update
値は、実際の更新に応じて変わります。
17.2.7.3. クラスターの更新の監視 リンクのコピーリンクがクリップボードにコピーされました!
更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。
手順
クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。
watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
更新中、この watch
コマンドは、一度に 1 つまたは複数のクラスター Operator を循環し、MESSAGE
列に Operator 更新のステータスを表示します。
クラスター Operator の更新プロセスが完了すると、各コントロールプレーンノードが 1 つずつ再起動します。
更新のこの部分で、クラスター Operator が再度更新中であることやデグレード状態であることを示すメッセージが報告されます。これは、ノードを再起動している間、コントロールプレーンノードがオフラインになるためです。
最後のコントロールプレーンノードの再起動が完了するとすぐに、更新されたクラスターのバージョンが表示されます。
コントロールプレーンの更新が完了すると、次のようなメッセージが表示されます。この例では、中間の y-stream リリースへの更新が完了したことを示しています。
17.2.7.4. OLM Operator の更新 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者の環境では、ソフトウェアを実稼働クラスターにロードする前に検査する必要があります。また、実稼働クラスターが非接続ネットワーク内で設定されるため、必ずしもインターネットに直接接続されているわけではありません。クラスターが非接続ネットワーク内にあるため、新しいバージョンをクラスターごとに管理できるように、インストール時に OpenShift Operator を手動で更新するように設定します。Operator を新しいバージョンに移行するには、次の手順を実行します。
手順
更新する必要がある Operator を確認します。
oc get installplan -A | grep -E 'APPROVED|false'
$ oc get installplan -A | grep -E 'APPROVED|false'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME CSV APPROVAL APPROVED metallb-system install-nwjnh metallb-operator.v4.16.0-202409202304 Manual false openshift-nmstate install-5r7wr kubernetes-nmstate-operator.4.16.0-202409251605 Manual false
NAMESPACE NAME CSV APPROVAL APPROVED metallb-system install-nwjnh metallb-operator.v4.16.0-202409202304 Manual false openshift-nmstate install-5r7wr kubernetes-nmstate-operator.4.16.0-202409251605 Manual false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの Operator の
InstallPlan
リソースにパッチを適用します。oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'
$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
installplan.operators.coreos.com/install-nwjnh patched
installplan.operators.coreos.com/install-nwjnh patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して namespace を監視します。
oc get all -n metallb-system
$ oc get all -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新が完了すると、必要な Pod が
Running
状態になり、必要なReplicaSet
リソースが準備完了になるはずです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Operator を再度更新する必要がないことを確認します。
oc get installplan -A | grep -E 'APPROVED|false'
$ oc get installplan -A | grep -E 'APPROVED|false'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は返されないはずです。
注記Operator によっては、最終バージョンの前にインストールする必要がある中間の z-stream リリースバージョンがあるため、更新を 2 回承認する必要がある場合があります。
17.2.7.5. ワーカーノードの更新 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンを更新した後、作成した適切な mcp
グループの一時停止を解除してワーカーノードをアップグレードします。mcp
グループの一時停止を解除すると、そのグループ内のワーカーノードのアップグレードプロセスが開始します。クラスター内の各ワーカーノードが再起動し、必要に応じて新しい EUS、y-stream、または z-stream バージョンにアップグレードされます。
コントロールプレーンのみのアップグレードの場合、ワーカーノードの更新時に、再起動が 1 回だけ必要になり、ワーカーノードが <y+2> リリースバージョンにジャンプします。これは、大規模なベアメタルクラスターのアップグレードにかかる時間を短縮するために追加された機能です。
この時点で保留することも可能です。ワーカーノードが <y-2> リリースであっても、新しい EUS リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。
mcp
グループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcp
グループのリストを取得します。oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一度にアップグレードする
mcp
グループの数を決定してください。これは、一度に停止できる CNF Pod の数、および Pod Disruption Budget とアンチアフィニティーの設定よって異なります。クラスター内のノードのリストを取得します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 一時停止中の
MachineConfigPool
グループを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 true mcp-2 true
MCP Paused --- ------ master false mcp-1 true mcp-2 true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MachineConfigPool
は、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。必要な
mcp
グループを一時停止解除して、アップグレードを開始します。oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'
$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な
mcp
グループが一時停止解除されていることを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 true
MCP Paused --- ------ master false mcp-1 false mcp-2 true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各
mcp
グループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.7.6. 新しく更新されたクラスターの健全性の確認 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。
手順
次のコマンドを実行してクラスターのバージョンを確認します。
oc get clusterversion
$ oc get clusterversion
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいクラスターバージョンが返され、
PROGRESSING
列にFalse
が返されるはずです。すべてのノードが準備完了であることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のすべてのノードが
Ready
ステータスで、同じバージョンを実行しているはずです。クラスター内に一時停止中の
mcp
リソースがないことを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 false
MCP Paused --- ------ master false mcp-1 false mcp-2 false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator が利用可能であることを確認します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator の
AVAILABLE
列にTrue
と報告されるはずです。すべての Pod が正常であることを確認します。
oc get po -A | grep -E -iv 'complete|running'
$ oc get po -A | grep -E -iv 'complete|running'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod は 1 つも返されないはずです。
注記更新後もまだ移行中の Pod がいくつか見られる場合があります。しばらくこれを監視して、すべての Pod がクリアされることを確認してください。
17.2.8. z-stream クラスターの更新の完了 リンクのコピーリンクがクリップボードにコピーされました!
次の手順に従って、z-stream クラスターの更新を実行し、更新が完了するまで監視します。z-stream 更新の完了は、コントロールプレーンのみの更新や y-stream 更新よりも簡単です。
17.2.8.1. クラスターの更新の開始 リンクのコピーリンクがクリップボードにコピーされました!
ある y-stream リリースから次のリリースに更新する場合、中間の z-stream リリースにも互換性があることを確認する必要があります。
oc adm upgrade
コマンドを実行すると、更新先のリリースが実行可能なリリースであることを確認できます。oc adm upgrade
コマンドは、互換性のある更新リリースをリスト表示します。
手順
更新を開始します。
oc adm upgrade --to=4.15.33
$ oc adm upgrade --to=4.15.33
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要- コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
- y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
- z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。
出力例
Requested update to 4.15.33
Requested update to 4.15.33
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Requested update
値は、実際の更新に応じて変わります。
17.2.8.2. ワーカーノードの更新 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンを更新した後、作成した適切な mcp
グループの一時停止を解除してワーカーノードをアップグレードします。mcp
グループの一時停止を解除すると、そのグループ内のワーカーノードのアップグレードプロセスが開始します。クラスター内の各ワーカーノードが再起動し、必要に応じて新しい EUS、y-stream、または z-stream バージョンにアップグレードされます。
コントロールプレーンのみのアップグレードの場合、ワーカーノードの更新時に、再起動が 1 回だけ必要になり、ワーカーノードが <y+2> リリースバージョンにジャンプします。これは、大規模なベアメタルクラスターのアップグレードにかかる時間を短縮するために追加された機能です。
この時点で保留することも可能です。ワーカーノードが <y-2> リリースであっても、新しい EUS リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。
mcp
グループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcp
グループのリストを取得します。oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一度にアップグレードする
mcp
グループの数を決定してください。これは、一度に停止できる CNF Pod の数、および Pod Disruption Budget とアンチアフィニティーの設定よって異なります。クラスター内のノードのリストを取得します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 一時停止中の
MachineConfigPool
グループを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 true mcp-2 true
MCP Paused --- ------ master false mcp-1 true mcp-2 true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MachineConfigPool
は、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。必要な
mcp
グループを一時停止解除して、アップグレードを開始します。oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'
$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な
mcp
グループが一時停止解除されていることを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 true
MCP Paused --- ------ master false mcp-1 false mcp-2 true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各
mcp
グループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.8.3. 新しく更新されたクラスターの健全性の確認 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。
手順
次のコマンドを実行してクラスターのバージョンを確認します。
oc get clusterversion
$ oc get clusterversion
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいクラスターバージョンが返され、
PROGRESSING
列にFalse
が返されるはずです。すべてのノードが準備完了であることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のすべてのノードが
Ready
ステータスで、同じバージョンを実行しているはずです。クラスター内に一時停止中の
mcp
リソースがないことを確認します。oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 false
MCP Paused --- ------ master false mcp-1 false mcp-2 false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator が利用可能であることを確認します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator の
AVAILABLE
列にTrue
と報告されるはずです。すべての Pod が正常であることを確認します。
oc get po -A | grep -E -iv 'complete|running'
$ oc get po -A | grep -E -iv 'complete|running'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod は 1 つも返されないはずです。
注記更新後もまだ移行中の Pod がいくつか見られる場合があります。しばらくこれを監視して、すべての Pod がクリアされることを確認してください。
17.3. 通信事業者コア CNF クラスターのトラブルシューティングとメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
17.3.1. 通信事業者コア CNF クラスターのトラブルシューティングとメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
トラブルシューティングとメンテナンスは週次のタスクであり、コンポーネントを更新する場合でも、問題を調査する場合でも、目標を達成するためのツールがなければ困難になる可能性があります。ツールや回答をどこでどのように検索するかを知ることも、課題の 1 つです。
高帯域幅のネットワークスループットが必要なベアメタル環境をメンテナンスおよびトラブルシューティングするには、次の手順を参照してください。
このトラブルシューティング情報は、OpenShift Container Platform の設定やクラウドネイティブネットワーク機能 (CNF) アプリケーションの開発に関する参考資料ではありません。
通信事業者の CNF アプリケーションの開発については、Red Hat Best Practices for Kubernetes を参照してください。
17.3.1.1. クラウドネイティブネットワーク機能 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者のクラウドネイティブネットワーク機能 (CNF) アプリケーションに OpenShift Container Platform の使用を開始する場合は、CNF を理解すると、発生する可能性のある問題を把握するのに役立ちます。
CNF とその進化の詳細は、VNF and CNF, what’s the difference? を参照してください。
17.3.1.2. サポート リンクのコピーリンクがクリップボードにコピーされました!
手順で問題が発生した場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルから、次のようにさまざまな方法でヘルプを見つけることができます。
- Red Hat 製品に関する記事やソリューションを対象とした Red Hat ナレッジベースの検索またはブラウズ。
- Red Hat サポートに対するサポートケースの送信。
- その他の製品ドキュメントへのアクセス。
デプロイメントの問題を特定するには、デバッグツールを使用するか、デプロイメントのヘルスエンドポイントを確認します。デプロイメントのデバッグまたは健全性情報の取得が完了したら、Red Hat ナレッジベースでソリューションを検索したり、サポートチケットを提出したりできます。
17.3.1.2.1. Red Hat ナレッジベースについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ナレッジベース は、お客様が Red Hat の製品やテクノロジーを最大限に活用できるようにするための豊富なコンテンツを提供します。Red Hat ナレッジベースは、Red Hat 製品のインストール、設定、および使用に関する記事、製品ドキュメント、および動画で構成されています。さらに、既知の問題に対する解決策を検索でき、それぞれに根本原因の簡潔な説明と修復手順が記載されています。
17.3.1.2.2. Red Hat ナレッジベースの検索 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の問題が発生した場合には、初期検索を実行して、解決策を Red Hat ナレッジベース内ですでに見つけることができるかどうかを確認できます。
前提条件
- Red Hat カスタマーポータルのアカウントがある。
手順
- Red Hat カスタマーポータル にログインします。
- Search をクリックします。
検索フィールドに、問題に関連する次のようなキーワードと文字列を入力します。
- OpenShift Container Platform コンポーネント (etcd など)
- 関連する手順 (installation など)
- 明示的な失敗に関連する警告、エラーメッセージ、およびその他の出力
- Enter キーをクリックします。
- オプション: OpenShift Container Platform 製品フィルターを選択します。
- オプション: Documentation コンテンツタイプフィルターを選択します。
17.3.1.2.3. サポートケースの送信 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。 - Red Hat カスタマーポータルのアカウントがある。
- Red Hat の Standard または Premium サブスクリプションがある。
手順
- Red Hat カスタマーポータルの Customer Support ページ にログインします。
- Get support をクリックします。
Customer Support ページの Cases タブで、以下を行います。
- オプション: 必要に応じて、事前に入力されたアカウントと所有者の詳細を変更します。
- 問題に該当するカテゴリー (Bug、Defect など) を選択し、Continue をクリックします。
以下の情報を入力します。
- Summary フィールドには、問題の簡潔で説明的な概要と、確認されている現象および予想される動作の詳細情報を入力します。
- Product ドロップダウンメニューから OpenShift Container Platform を選択します。
- Version ドロップダウンから 4.18 を選択します。
- Red Hat ナレッジベースで推奨されるソリューション一覧を確認してください。この一覧に上げられているソリューションは、報告しようとしている問題に適用される可能性があります。提案されている記事が問題に対応していない場合は、Continue をクリックします。
- 報告している問題に対する一致に基づいて推奨される Red Hat ナレッジベースソリューションの一覧が更新されることを確認してください。ケース作成プロセスでより多くの情報を提供すると、このリストの絞り込みが行われます。提案されている記事が問題に対応していない場合は、Continue をクリックします。
- アカウント情報が予想通りに表示されていることを確認し、そうでない場合は適宜修正します。
自動入力された OpenShift Container Platform クラスター ID が正しいことを確認します。正しくない場合は、クラスター ID を手動で取得します。
OpenShift Container Platform Web コンソールを使用してクラスター ID を手動で取得するには、以下を実行します。
- Home → Overview に移動します。
- Details セクションの Cluster ID フィールドで値を見つけます。
または、OpenShift Container Platform Web コンソールで新規サポートケースを作成し、クラスター ID を自動的に入力することができます。
- ツールバーから、(?)Help → Open Support Case に移動します。
- Cluster ID 値が自動的に入力されます。
OpenShift CLI (
oc
) を使用してクラスター ID を取得するには、以下のコマンドを実行します。oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プロンプトが表示されたら、以下の質問に回答し、Continue をクリックします。
- What are you experiencing? What are you expecting to happen?
- Define the value or impact to you or the business.
- Where are you experiencing this behavior? What environment?
- When does this behavior occur? Frequency? 繰り返し発生するのか。At certain times?
-
関連する診断データファイルをアップロードし、Continue をクリックします。まずは、
oc adm must-gather
コマンドを使用して収集されるデータと、そのコマンドによって収集されない問題に固有のデータを含めることが推奨されます。 - 関連するケース管理の詳細情報を入力し、Continue をクリックします。
- ケースの詳細をプレビューし、Submit をクリックします。
17.3.2. 一般的なトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
問題が発生した場合は、まず問題が発生している特定の領域を確認します。問題が発生する可能性のある領域を絞り込むには、次の 1 つ以上のタスクを完了します。
- クラスターのクエリー
- Pod ログの確認
- Pod のデバッグ
- イベントの確認
17.3.2.1. クラスターのクエリー リンクのコピーリンクがクリップボードにコピーされました!
潜在的な問題をより正確に発見できるように、クラスターに関する情報を取得します。
手順
次のコマンドを実行してプロジェクトに切り替えます。
oc project <project_name>
$ oc project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターのバージョン、クラスター Operator、およびその namespace 内のノードをクエリーします。
oc get clusterversion,clusteroperator,node
$ oc get clusterversion,clusteroperator,node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
詳細は、「oc get」および「Pod ステータスの確認」を参照してください。
17.3.2.2. Pod ログの確認 リンクのコピーリンクがクリップボードにコピーされました!
Pod からログを取得して、ログで問題を確認します。
手順
次のコマンドを実行して、Pod を一覧表示します。
oc get pod
$ oc get pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod ログファイルを確認します。
oc logs -n <namespace> busybox-1
$ oc logs -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
詳細は、「oc ログ」、「ロギング」、および「Pod およびコンテナーログの検査」を参照してください。
17.3.2.3. Pod に対する describe の実行 リンクのコピーリンクがクリップボードにコピーされました!
Pod に対して describe を実行すると、その Pod に関する情報が得られ、トラブルシューティングに役立ちます。Events
セクションに、Pod とその中のコンテナーに関する詳細情報が表示されます。
手順
次のコマンドを実行して Pod に関する情報を取得します。
oc describe pod -n <namespace> busybox-1
$ oc describe pod -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
詳細は、「oc describe」を参照してください。
17.3.2.4. イベントの確認 リンクのコピーリンクがクリップボードにコピーされました!
特定の namespace 内のイベントを確認すると、潜在的な問題を発見できます。
手順
次のコマンドを実行して、namespace 内のイベントを確認します。
oc get events -n <namespace> --sort-by=".metadata.creationTimestamp"
$ oc get events -n <namespace> --sort-by=".metadata.creationTimestamp"
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--sort-by=".metadata.creationTimestamp"
フラグを追加すると、最新のイベントが出力の最後に配置されます。
オプション: 指定した namespace 内のイベントで十分な情報が得られない場合は、次のコマンドを実行して、クエリーの対象をすべての namespace に拡張します。
oc get events -A --sort-by=".metadata.creationTimestamp"
$ oc get events -A --sort-by=".metadata.creationTimestamp"
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--sort-by=".metadata.creationTimestamp"
フラグを指定すると、最新のイベントが出力の最後に配置されます。
クラスターからのすべてのイベントの結果をフィルタリングするには、
grep
コマンドを使用できます。たとえば、エラーを探している場合、エラーは出力の 2 つの異なるセクション (TYPE
またはMESSAGE
セクション) に表示されることがあります。grep
コマンドを使用すると、error
やfailed
などのキーワードを検索できます。たとえば、次のコマンドを実行して、
warning
またはerror
を含むメッセージを検索します。oc get events -A | grep -Ei "warning|error"
$ oc get events -A | grep -Ei "warning|error"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE openshift 59s Warning FailedMount pod/openshift-1 MountVolume.SetUp failed for volume "v4-0-config-user-idp-0-file-data" : references non-existent secret key: test
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE openshift 59s Warning FailedMount pod/openshift-1 MountVolume.SetUp failed for volume "v4-0-config-user-idp-0-file-data" : references non-existent secret key: test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: イベントをクリーンアップして繰り返し発生しているイベントのみを表示するには、次のコマンドを実行して、関連する namespace 内のイベントを削除します。
oc delete events -n <namespace> --all
$ oc delete events -n <namespace> --all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
詳細は、「クラスターイベントの監視」を参照してください。
17.3.2.5. Pod への接続 リンクのコピーリンクがクリップボードにコピーされました!
oc rsh
コマンドを使用して、現在実行中の Pod に直接接続すると、その Pod のシェルを使用できます。
低レイテンシーのアプリケーションを実行する Pod では、oc rsh
コマンドを実行するとレイテンシーの問題が発生する可能性があります。oc rsh
コマンドは、oc debug
コマンドを使用してノードに接続できない場合にのみ使用してください。
手順
次のコマンドを実行して Pod に接続します。
oc rsh -n <namespace> busybox-1
$ oc rsh -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
詳細は、「oc rsh」および「実行中の Pod へのアクセス」を参照してください。
17.3.2.6. Pod のデバッグ リンクのコピーリンクがクリップボードにコピーされました!
場合によっては、実稼働環境の Pod を直接操作するのを避けたほうがよいこともあります。
実行中のトラフィックを妨げないようにするには、元の Pod のコピーであるセカンダリー Pod を使用します。セカンダリー Pod は元の Pod と同じコンポーネントを使用しますが、セカンダリー Pod には実行中のトラフィックがありません。
手順
次のコマンドを実行して、Pod を一覧表示します。
oc get pod
$ oc get pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して Pod をデバッグします。
oc debug -n <namespace> busybox-1
$ oc debug -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Starting pod/busybox-1-debug, command was: sleep 3600 Pod IP: 10.133.2.11
Starting pod/busybox-1-debug, command was: sleep 3600 Pod IP: 10.133.2.11
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シェルプロンプトが表示されない場合は、Enter キーを押します。
詳細は、「oc debug」および「root アクセスでのデバッグ Pod の起動」を参照してください。
17.3.2.7. Pod でのコマンドの実行 リンクのコピーリンクがクリップボードにコピーされました!
Pod に直接ログインせずに、Pod 上でコマンドまたはコマンドのセットを実行する場合は、oc exec -it
コマンドを使用できます。Pod を素早く操作して、Pod からプロセス情報や出力情報を取得できます。一般的な使用例としては、スクリプト内で oc exec -it
コマンドを実行して、レプリカセットまたはデプロイメント内の複数の Pod で同じコマンドを実行することが挙げられます。
低レイテンシーのアプリケーションを実行する Pod では、oc exec
コマンドによってレイテンシーの問題が発生する可能性があります。
手順
Pod にログインせずに Pod でコマンドを実行するには、次のコマンドを実行します。
oc exec -it <pod> -- <command>
$ oc exec -it <pod> -- <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
詳細は、「oc exec」および「コンテナー内でのリモートコマンドの実行」を参照してください。
17.3.3. クラスターのメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
通信事業者ネットワークでは、ベアメタルデプロイメントの性質上、特定の設定にさらに注意を払う必要があります。次のタスクを完了すると、より効果的にトラブルシューティングを行うことができます。
- 故障したハードウェアコンポーネントを監視する
- 定期的にクラスター Operator のステータスを確認する
ハードウェアの監視は、ハードウェアベンダーに問い合わせて、特定のハードウェアに適したログツールを見つけてください。
17.3.3.1. クラスター Operator の確認 リンクのコピーリンクがクリップボードにコピーされました!
問題を早期に発見するために、クラスター Operator のステータスを定期的に確認します。
手順
次のコマンドを実行して、クラスター Operator のステータスを確認します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3.3.2. 失敗した Pod の監視 リンクのコピーリンクがクリップボードにコピーされました!
トラブルシューティングの時間を短縮するには、クラスター内の障害が発生した Pod を定期的に監視します。
手順
失敗した Pod を監視するには、次のコマンドを実行します。
oc get po -A | grep -Eiv 'complete|running'
$ oc get po -A | grep -Eiv 'complete|running'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3.4. セキュリティー リンクのコピーリンクがクリップボードにコピーされました!
堅牢なクラスターセキュリティープロファイルを実装することは、回復力のある通信事業者ネットワークを構築する上で重要です。
17.3.4.1. 認証 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内にあるアイデンティティープロバイダーを特定します。サポートされているアイデンティティープロバイダーの詳細は、認証および認可 の「サポートされるアイデンティティープロバイダー」を参照してください。
どのプロバイダーが設定されているのかがわかったら、openshift-authentication
namespace を調べて、潜在的な問題があるかどうかを確認できます。
手順
次のコマンドを実行して、
openshift-authentication
namespace 内のイベントを確認します。oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
$ oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
openshift-authentication
namespace 内の Pod を確認します。oc get pod -n openshift-authentication
$ oc get pod -n openshift-authentication
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 詳細情報が必要な場合は、次のコマンドを実行して、実行中のいずれかの Pod のログを確認します。
oc logs -n openshift-authentication <pod_name>
$ oc logs -n openshift-authentication <pod_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3.5. 証明書のメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
継続的なクラスター認証を実現するには、証明書のメンテナンスが欠かせません。一部の証明書はクラスター管理者が手動で更新する必要がありますが、その他の証明書はクラスターによって自動的に更新されます。
以下のリソースを使用して、OpenShift Container Platform の証明書とその管理方法を確認してください。
17.3.5.1. 管理者が手動で管理する証明書 リンクのコピーリンクがクリップボードにコピーされました!
次の証明書は、クラスター管理者が更新する必要があります。
- プロキシー証明書
- ユーザーがプロビジョニングする API サーバー証明書
17.3.5.1.1. プロキシー証明書の管理 リンクのコピーリンクがクリップボードにコピーされました!
プロキシー証明書を使用すると、ユーザーは、Egress 接続を行うときにプラットフォームコンポーネントによって使用される 1 つ以上のカスタム認証局 (CA) 証明書を指定できます。
一部の CA には有効期限が設定されています。このような証明書は 2 年ごとに更新する必要がある場合があります。
要求される証明書を最初に設定しなかった場合は、いくつかの方法で証明書の有効期限を決定できます。ほとんどのクラウドネイティブネットワーク機能 (CNF) が使用する証明書は、ブラウザーベースの接続用に特別に設計されたものではありません。したがって、デプロイメントの ConfigMap
オブジェクトから証明書を取得する必要があります。
手順
有効期限を取得するには、証明書ファイルに対して次のコマンドを実行します。
openssl x509 -enddate -noout -in <cert_file_name>.pem
$ openssl x509 -enddate -noout -in <cert_file_name>.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プロキシー証明書を更新する方法と時期を確認する方法の詳細は、セキュリティーおよびコンプライアンス の「プロキシー証明書」を参照してください。
17.3.5.1.2. ユーザーがプロビジョニングする API サーバー証明書 リンクのコピーリンクがクリップボードにコピーされました!
API サーバーには、クラスター外部のクライアントから api.<cluster_name>.<base_domain>
でアクセスできます。クライアントに別のホスト名で API サーバーにアクセスさせたり、クラスター管理の認証局 (CA) 証明書をクライアントに配布せずに API サーバーにアクセスさせたりする必要が生じる場合があります。コンテンツを提供するときに API サーバーが使用するカスタムのデフォルト証明書を設定する必要があります。
詳細は、セキュリティーおよびコンプライアンス の「API サーバー用のユーザーがプロビジョニングする証明書」を参照してください。
17.3.5.2. クラスターによって管理される証明書 リンクのコピーリンクがクリップボードにコピーされました!
クラスターによって管理される証明書は、ログで問題が検出された場合にのみ確認する必要があります。次の証明書はクラスターによって自動的に管理されます。
- サービス CA 証明書
- ノード証明書
- ブートストラップ証明書
- etcd 証明書
- OLM 証明書
- Machine Config Operator 証明書
- モニタリングおよびクラスターロギング Operator コンポーネント証明書
- コントロールプレーンの証明書
- Ingress 証明書
17.3.5.2.1. etcd によって管理される証明書 リンクのコピーリンクがクリップボードにコピーされました!
etcd 証明書は、etcd メンバーのピア間の暗号化された通信と、暗号化されたクライアントトラフィックに使用されます。すべてのノードとすべてのサービス間の通信が最新であれば、証明書はクラスター内で自動的に更新されます。したがって、etcd 証明書の有効期限に近い特定期間中にクラスターがコンポーネント間の通信を失う可能性がある場合は、事前に証明書を更新することを推奨します。たとえば、ノードが異なるタイミングで再起動するため、アップグレード中に通信が失われる可能性があります。
次のコマンドを実行して、etcd 証明書を手動で更新できます。
for each in $(oc get secret -n openshift-etcd | grep "kubernetes.io/tls" | grep -e \ "etcd-peer\|etcd-serving" | awk '{print $1}'); do oc get secret $each -n openshift-etcd -o \ jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -noout -enddate; done
$ for each in $(oc get secret -n openshift-etcd | grep "kubernetes.io/tls" | grep -e \ "etcd-peer\|etcd-serving" | awk '{print $1}'); do oc get secret $each -n openshift-etcd -o \ jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -noout -enddate; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
etcd 証明書の更新の詳細は、Checking etcd certificate expiry in OpenShift 4 を参照してください。etcd 証明書の詳細は、セキュリティーおよびコンプライアンス の「etcd 証明書」を参照してください。
17.3.5.2.2. ノード証明書 リンクのコピーリンクがクリップボードにコピーされました!
ノード証明書は自己署名証明書です。つまり、クラスターによって署名され、ブートストラッププロセスによって生成された内部認証局 (CA) から発行されたものです。
クラスターがインストールされると、クラスターはノード証明書を自動的に更新します。
詳細は、セキュリティーおよびコンプライアンス の「ノード証明書」を参照してください。
17.3.5.2.3. サービス CA 証明書 リンクのコピーリンクがクリップボードにコピーされました!
service-ca
は、OpenShift Container Platform クラスターがデプロイされるときに自己署名認証局 (CA) を作成する Operator です。これにより、ユーザーは手動で証明書を作成せずに、デプロイメントに証明書を追加できます。サービス CA 証明書は自己署名証明書です。
詳細は、セキュリティーおよびコンプライアンス の「サービス CA 証明書」を参照してください。
17.3.6. Machine Config Operator リンクのコピーリンクがクリップボードにコピーされました!
Machine Config Operator は、クラスター管理者に有用な情報を提供し、ベアメタルホスト上で直接実行されているコンポーネントを制御します。
Machine Config Operator は、クラスター内の各ノードグループを区別し、コントロールプレーンノードとワーカーノードを異なる設定で実行できるようにします。これらのノードグループは、MachineConfigPool
(mcp
) グループと呼ばれるワーカー Pod またはアプリケーション Pod を実行します。同じマシン設定が、クラスター内のすべてのノードまたは 1 つの MCP にのみ適用されます。
通信事業者コアクラスターで MCP を適用する方法と理由の詳細は、更新前にノードに MachineConfigPool ラベルを適用する を参照してください。
Machine Config Operator についての詳細は、Machine Config Operator を参照してください。
17.3.6.1. Machine Config Operator の目的 リンクのコピーリンクがクリップボードにコピーされました!
Machine Config Operator (MCO) は、カーネルと kubelet 間にあるすべてのものを含む、Red Hat Enterprise Linux CoreOS (RHCOS) とコンテナーランタイムの設定と更新を管理および適用します。ほとんどの通信事業者はベアメタルハードウェア上で運用し、何らかのハードウェアアクセラレーターまたはカーネルの変更を使用しているため、RHCOS の管理は重要です。MCO は各ノードとそれに適用される内容を監視するため、マシン設定を RHCOS に手動で適用すると問題が発生する可能性があります。
このような細かいコンポーネントと、MCO がクラスターを効果的に管理するのにどのように役立つかを考慮する必要があります。
ワーカーノードまたはコントロールプレーンノードに対する変更は、すべて MCO を使用して実行する必要があります。RHCOS またはノードファイルを手動で変更しないでください。
17.3.6.2. 複数のマシン設定ファイルを同時に適用する リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のノードグループ (マシン設定プール (MCP) とも呼ばれます) のマシン設定を変更する必要がある場合、複数の異なるマシン設定ファイルを使用して変更を適用する必要があることがあります。マシン設定ファイルを適用するには、ノードを再起動する必要があります。各マシン設定ファイルがクラスターに適用されると、そのマシン設定ファイルの影響を受けるすべてのノードが再起動します。
マシン設定ファイルごとにノードが再起動するのを防ぐには、新しいマシン設定ファイルによって更新される各 MCP を一時停止して、すべての変更を同時に適用します。
手順
次のコマンドを実行して、影響を受ける MCP を一時停止します。
oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのマシン設定の変更をクラスターに適用したら、次のコマンドを実行します。
oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
これにより、MCP 内のノードが新しい設定で再起動できるようになります。
17.3.7. ベアメタルノードのメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
ノードに接続すると、一般的なトラブルシューティングを実行できます。ただし、場合によっては、特定のハードウェアコンポーネントに対してトラブルシューティングやメンテナンスのタスクを実行する必要があります。このセクションでは、ハードウェアのメンテナンスを実行するために必要なトピックを説明します。
17.3.7.1. クラスター内のベアメタルノードに接続する リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスターノードに接続すると、一般的なメンテナンスタスクを実行できます。
ホストオペレーティングシステムからクラスターノードを設定することは推奨されておらず、サポートもされていません。
ノードのトラブルシューティングを行う際には、次のタスクを実行できます。
- ノードからログを取得する
- デバッグを使用する
- SSH を使用してノードに接続する
SSH は、oc debug
コマンドを使用してノードに接続できない場合にのみ使用してください。
手順
次のコマンドを実行して、ノードからログを取得します。
oc adm node-logs <node_name> -u crio
$ oc adm node-logs <node_name> -u crio
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してデバッグを使用します。
oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。root ディレクトリーを/host
に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力
You are now logged in as root on the node
You are now logged in as root on the node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 次のコマンドを実行して、SSH を使用してノードに接続します。
ssh core@<node_name>
$ ssh core@<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3.7.2. クラスター内の Pod にアプリケーションを移動する リンクのコピーリンクがクリップボードにコピーされました!
計画的なハードウェアメンテナンスの場合、Pod のワークロードに影響を与えずに、アプリケーション Pod をクラスター内の他のノードに移動する方法を検討する必要があります。
手順
次のコマンドを実行して、ノードをスケジュール対象外としてマークします。
oc adm cordon <node_name>
$ oc adm cordon <node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ノードがスケジュール対象外の場合、そのノードで Pod をスケジュールすることはできません。詳細は、「ノードの操作」を参照してください。
CNF アプリケーションを移動する場合、アンチアフィニティーと Pod Disruption Budget 用に、クラスター内に十分な追加ワーカーノードがあるかどうかを事前に確認する必要がある場合があります。
17.3.7.3. DIMM メモリーの交換 リンクのコピーリンクがクリップボードにコピーされました!
デュアルインラインメモリーモジュール (DIMM) の問題が発生することがあるのは、サーバーの再起動後だけです。このような問題はログファイルで確認できます。
標準の再起動を実行してもサーバーが起動しない場合は、DIMM メモリーに障害があることを示すメッセージがコンソールに表示されます。その場合、障害のある DIMM を確認し、残りのメモリーが十分であれば再起動を続行できます。その後、障害のある DIMM を交換するためのメンテナンスウィンドウをスケジュールすることができます。
場合によっては、イベントログのメッセージにメモリーモジュールの不良が示されることがあります。このような場合は、サーバーを再起動する前にメモリーの交換をスケジュールすることができます。
17.3.7.4. ディスクの交換 リンクのコピーリンクがクリップボードにコピーされました!
ハードウェアまたはソフトウェアの Redundant Array of Independent Disks (RAID) を通じてノードにディスク冗長性が設定されていない場合は、次の点を確認する必要があります。
- ディスクに実行中の Pod イメージが含まれているかどうか
- ディスクに Pod の永続データが含まれているかどうか
詳細は、ストレージ の「OpenShift Container Platform ストレージの概要」を参照してください。
17.3.7.5. クラスターネットワークカードの交換 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークカードを交換すると、MAC アドレスが変更されます。MAC アドレスは、DHCP または SR-IOV Operator 設定、ルーター設定、ファイアウォールルール、またはアプリケーションのクラウドネイティブネットワーク機能 (CNF) 設定の一部である場合があります。ネットワークカードを交換した後、ノードをオンラインに戻す前に、これらの設定が最新であることを確認する必要があります。
ネットワーク内で MAC アドレスを変更するための具体的な手順が整備されていない場合は、ネットワーク管理者またはネットワークハードウェアベンダーに問い合わせてください。
17.4. 可観測性 リンクのコピーリンクがクリップボードにコピーされました!
17.4.1. 通信事業者コア CNF クラスターの可観測性 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、プラットフォームとプラットフォーム上で実行されているワークロードの両方から、パフォーマンスメトリクスやログなどの大量のデータが生成されます。管理者は、さまざまなツールを使用して、利用可能なすべてのデータを収集および分析できます。以下は、可観測性スタックを設定するシステムエンジニア、アーキテクト、および管理者向けのベストプラクティスの概要です。
特に明記のない限り、このドキュメントの内容はエッジデプロイメントとコアデプロイメントの両方を表しています。
17.4.1.1. モニタリングスタックについて リンクのコピーリンクがクリップボードにコピーされました!
モニタリングスタックは次のコンポーネントを使用します。
- Prometheus は、OpenShift Container Platform コンポーネントおよびワークロードからメトリクスを収集して分析します (そのように設定されている場合)。
- Alertmanager は、アラートのルーティング、グループ化、およびサイレンスを処理する Prometheus のコンポーネントです。
- Thanos はメトリクスの長期保存を処理します。
図17.2 OpenShift Container Platform モニタリングアーキテクチャー
シングルノード OpenShift クラスターの場合、クラスターは分析と保持のためにすべてのメトリクスをハブクラスターに送信するため、Alertmanager と Thanos を無効にする必要があります。
17.4.1.2. 主要なパフォーマンスメトリクス リンクのコピーリンクがクリップボードにコピーされました!
システムによっては、利用可能な測定値が数百種類ある場合があります。
注目すべき重要なメトリクスは次のとおりです。
-
etcd
応答時間 - API 応答時間
- Pod の再起動とスケジュール
- リソースの使用状況
- OVN の健全性
- クラスター Operator の全体的な健全性
原則として、あるメトリクスが重要であると判断した場合は、それに対するアラートを設定することを推奨します。
次のコマンドを実行すると、利用可能なメトリクスを確認できます。
oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk http://localhost:9090/api/v1/metadata | jq '.data
$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk http://localhost:9090/api/v1/metadata | jq '.data
17.4.1.2.1. PromQL のクエリー例 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、OpenShift Container Platform コンソールを使用してメトリクスクエリーブラウザーで調べることができるクエリーの一部を示しています。
コンソールの URL は https://<OpenShift Console FQDN>/monitoring/query-browser です。以下のコマンドを実行して、OpenShift Console FQDN を取得できます。
oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].host}'
$ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].host}'
メトリクス | Query |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
合計 |
|
メトリクス | Query |
---|---|
|
|
|
|
リーダー選出 |
|
ネットワークレイテンシー |
|
メトリクス | Query |
---|---|
デグレード状態の Operator |
|
クラスターあたりのデグレード状態の Operator 総数 |
|
17.4.1.2.2. メトリクスの保存に関する推奨事項 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Prometheus は保存されたメトリクスを永続ストレージにバックアップしません。Prometheus Pod を再起動すると、すべてのメトリクスデータが失われます。プラットフォームで使用可能なバックエンドストレージを使用するようにモニタリングスタックを設定する必要があります。Prometheus の高い IO 要求を満たすには、ローカルストレージを使用する必要があります。
通信事業者コアクラスターの場合、Prometheus の永続ストレージに Local Storage Operator を使用できます。
ブロック、ファイル、およびオブジェクトストレージ用の Ceph クラスターをデプロイする Red Hat OpenShift Data Foundation (ODF) も、通信事業者コアクラスターの候補として適しています。
RAN シングルノード OpenShift またはファーエッジクラスターのシステムリソース要件を低く抑えるには、モニタリングスタック用のバックエンドストレージをプロビジョニングしないでください。このようなクラスターは、すべてのメトリクスをハブクラスターに転送します。そこにサードパーティーのモニタリングプラットフォームをプロビジョニングできます。
17.4.1.3. エッジのモニタリング リンクのコピーリンクがクリップボードにコピーされました!
シングルノード OpenShift をエッジに配置することで、プラットフォームコンポーネントのフットプリントが最小限に抑えられます。次の手順は、モニタリングフットプリントが小さいシングルノード OpenShift ノードを設定する方法の例です。
前提条件
- Red Hat Advanced Cluster Management (RHACM) を使用する環境で、可観測性サービスが有効になっている。
- ハブクラスターで Red Hat OpenShift Data Foundation (ODF) が実行されている。
手順
次の例のように、
ConfigMap
CR を作成し、monitoringConfigMap.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow シングルノード OpenShift で、次のコマンドを実行して
ConfigMap
CR を適用します。oc apply -f monitoringConfigMap.yaml
$ oc apply -f monitoringConfigMap.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、
NameSpace
CR を作成し、monitoringNamespace.yaml
として保存します。apiVersion: v1 kind: Namespace metadata: name: open-cluster-management-observability
apiVersion: v1 kind: Namespace metadata: name: open-cluster-management-observability
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで、次のコマンドを実行して、ハブクラスターに
Namespace
CR を適用します。oc apply -f monitoringNamespace.yaml
$ oc apply -f monitoringNamespace.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、
ObjectBucketClaim
CR を作成し、monitoringObjectBucketClaim.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで、次のコマンドを実行して
ObjectBucketClaim
CR を適用します。oc apply -f monitoringObjectBucketClaim.yaml
$ oc apply -f monitoringObjectBucketClaim.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、
Secret
CR を作成し、monitoringSecret.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで、次のコマンドを実行して
Secret
CR を適用します。oc apply -f monitoringSecret.yaml
$ oc apply -f monitoringSecret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ハブクラスターから NooBaa サービスのキーとバックエンドバケット名を取得します。
NOOBAA_ACCESS_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
$ NOOBAA_ACCESS_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NOOBAA_SECRET_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
$ NOOBAA_SECRET_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OBJECT_BUCKET=$(oc get objectbucketclaim -n open-cluster-management-observability multi-cloud-observability -o json | jq -r .spec.bucketName)
$ OBJECT_BUCKET=$(oc get objectbucketclaim -n open-cluster-management-observability multi-cloud-observability -o json | jq -r .spec.bucketName)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、バケットストレージ用の
Secret
CR を作成し、monitoringBucketSecret.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで、次のコマンドを実行して
Secret
CR を適用します。oc apply -f monitoringBucketSecret.yaml
$ oc apply -f monitoringBucketSecret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、
MultiClusterObservability
CR を作成し、monitoringMultiClusterObservability.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで、次のコマンドを実行して
MultiClusterObservability
CR を適用します。oc apply -f monitoringMultiClusterObservability.yaml
$ oc apply -f monitoringMultiClusterObservability.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、namespace 内のルートと Pod を確認し、サービスがハブクラスターにデプロイされていることを確認します。
oc get routes,pods -n open-cluster-management-observability
$ oc get routes,pods -n open-cluster-management-observability
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- リスト表示される Grafana ルートからダッシュボードにアクセスできます。これを使用して、すべてのマネージドクラスターのメトリクスを表示できます。
Red Hat Advanced Cluster Management の可観測性の詳細は、可観測性 を参照してください。
17.4.1.4. アラート リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には多数のアラートルールが含まれています。ルールはリリースごとに変更される可能性があります。
17.4.1.4.1. デフォルトのアラートの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のすべてのアラートルールを確認するには、次の手順を使用します。
手順
クラスター内のすべてのアラートルールを確認するには、次のコマンドを実行します。
oc get cm -n openshift-monitoring prometheus-k8s-rulefiles-0 -o yaml
$ oc get cm -n openshift-monitoring prometheus-k8s-rulefiles-0 -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルールには説明を含めることができ、追加情報や軽減策へのリンクを提供できます。たとえば、
etcdHighFsyncDurations
のルールは次のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.1.4.2. アラート通知 リンクのコピーリンクがクリップボードにコピーされました!
アラートは OpenShift Container Platform コンソールで表示できますが、アラートを転送する外部レシーバーを設定することが管理者には推奨されます。OpenShift Container Platform は、次のレシーバータイプをサポートしています。
- PagerDuty: サードパーティーのインシデント対応プラットフォーム
- Webhook: POST リクエストを介してアラートを受信し、必要なアクションを実行できる任意の API エンドポイント
- Email: 指定されたアドレスにメールを送信する
- Slack: Slack チャネルまたは個々のユーザーに通知を送信する
17.4.1.5. ワークロードのモニタリング リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、OpenShift Container Platform はアプリケーションワークロードのメトリクスを収集しません。ワークロードメトリクスを収集するようにクラスターを設定できます。
前提条件
- クラスターのワークロードメトリクスを収集するためのエンドポイントを定義した。
手順
次の例のように、
ConfigMap
CR を作成し、monitoringConfigMap.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
true
に設定してワークロードのモニタリングを有効にします。
次のコマンドを実行して
ConfigMap
CR を適用します。oc apply -f monitoringConfigMap.yaml
$ oc apply -f monitoringConfigMap.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、
ServiceMonitor
CR を作成し、monitoringServiceMonitor.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ServiceMonitor
CR を適用します。oc apply -f monitoringServiceMonitor.yaml
$ oc apply -f monitoringServiceMonitor.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Prometheus はデフォルトでパス /metrics
をスクレイピングしますが、カスタムパスを定義することもできます。重要であると判断したメトリクスとともに、このエンドポイントをスクレイピング用に公開するかどうかは、アプリケーションのベンダー次第です。
17.4.1.5.1. ワークロードのアラートの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター上のユーザーワークロードに対するアラートを有効にできます。
手順
次の例のように、
ConfigMap
CR を作成し、monitoringConfigMap.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
true
に設定してワークロードのモニタリングを有効にします。
次のコマンドを実行して
ConfigMap
CR を適用します。oc apply -f monitoringConfigMap.yaml
$ oc apply -f monitoringConfigMap.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、アラートルール用の YAML ファイル (
monitoringAlertRule.yaml
) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してアラートルールを適用します。
oc apply -f monitoringAlertRule.yaml
$ oc apply -f monitoringAlertRule.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.5. セキュリティー リンクのコピーリンクがクリップボードにコピーされました!
17.5.1. セキュリティーの基礎 リンクのコピーリンクがクリップボードにコピーされました!
セキュリティーは、特にクラウドネイティブネットワーク機能 (CNF) を実行する場合、OpenShift Container Platform 上の通信事業者デプロイメントの重要な要素となります。
セキュリティー上の重要な考慮事項を遵守することで、通信事業者 (telco) 環境における高帯域幅ネットワークデプロイメントのセキュリティーを強化できます。このような標準やベストプラクティスを実装すると、通信事業者固有のユースケースにおけるセキュリティーを強化できます。
17.5.1.1. RBAC の概要 リンクのコピーリンクがクリップボードにコピーされました!
ロールベースアクセス制御 (RBAC) オブジェクトは、ユーザーがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。
これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、OpenShift Container Platform プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。
開発者はローカルロールとバインディングを使用して、プロジェクトにアクセスできるユーザーを制御できます。認可は認証とは異なる手順であることに注意してください。認証はアクションを実行するユーザーのアイデンティティーの判別により密接に関連しています。
認可は、次の認可オブジェクトを使用して管理されます。
- ルール
- 特定のオブジェクトに対して許可されるアクションのセットです。たとえば、ルールによって、ユーザーまたはサービスアカウントが Pod を作成できるかどうかを決定できます。各ルールで、API リソース、その API 内のリソース、および許可されるアクションを指定します。
- ロール
ユーザーまたはグループが実行できるアクションを定義するルールの集まりです。ルールを複数のユーザーまたはグループに関連付けたり、バインドしたりできます。ロールファイルに、そのロールに許可されるアクションおよびリソースを指定するルールを 1 つ以上含めることができます。
ロールは次のタイプに分類されます。
- クラスターロール: クラスターレベルでクラスターロールを定義できます。クラスターロールは 1 つの namespace に結び付けられません。ユーザー、グループ、またはサービスアカウントにクラスターロールをバインドすると、すべての namespace または特定の namespace に適用できます。
- プロジェクトロール: 特定の namespace 内にプロジェクトロールを作成できます。プロジェクトロールはその namespace にのみ適用されます。特定のユーザーに権限を割り当てて、ロールとロールバインディングをそのロールの namespace 内に作成することで、他の namespace に影響を与えないようにすることができます。
- バインディング
ロールを使用したユーザーやグループ間の関連付けです。ロールバインディングを作成すると、ロール内のルールを特定のユーザー ID またはグループと結び付けることができます。これにより、ロールとユーザーまたはグループが組み合わせられ、ユーザーまたはグループが実行できるアクションが定義されます。
注記ユーザーまたはグループには複数のロールをバインドできます。
RBAC の詳細は、「RBAC を使用した権限の定義および適用」を参照してください。
RBAC の運用上の考慮事項
運用上のオーバーヘッドを削減するには、複数のクラスターにわたって個々のユーザー ID を処理するのではなく、グループを通じてアクセスを管理することが重要です。組織レベルでグループを管理することで、アクセス制御を合理化し、組織全体の管理を簡素化できます。
17.5.1.2. セキュリティーアカウントの概要 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、コンポーネントが API に直接アクセスできるようにする OpenShift Container Platform アカウントです。サービスアカウントは各プロジェクトに存在する API オブジェクトです。サービスアカウントは、一般ユーザーの認証情報を共有せずに API アクセスをより柔軟に制御する方法を提供します。
サービスアカウントを使用すると、Pod にロールベースのアクセス制御 (RBAC) を適用できます。Pod やデプロイメントなどのワークロードにサービスアカウントを割り当てることで、さまざまなレジストリーからのプルなど、追加の権限を付与できます。これにより、より低い権限をサービスアカウントに割り当てて、そのアカウント配下で実行される Pod のセキュリティー関連のフットプリントを削減することもできます。
サービスアカウントの詳細は、「サービスアカウントの概要および作成」を参照してください。
17.5.1.3. アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
アイデンティティープロバイダーの設定は、クラスターでユーザーを設定する際の最初のステップです。アイデンティティープロバイダーを使用すると、組織レベルでグループを管理できます。
アイデンティティープロバイダーは、クラスターレベルではなく組織レベルで管理される特定のユーザーグループを取得できます。これにより、組織の確立されたプラクティスに準拠したグループにユーザーを追加したり、グループからユーザーを削除したりできます。
変更をクラスターに取り込むには、頻繁に実行される cron ジョブを設定する必要があります。
アイデンティティープロバイダーを使用すると、組織内の特定グループのアクセスレベルを管理できます。たとえば、アクセスレベルを管理するために、次の操作を実行できます。
-
クラスターレベルの権限を必要とするチームに
cluster-admin
ロールを割り当てる。 - アプリケーション管理者に、それぞれのプロジェクトのみを管理するための特定の権限を付与する。
-
運用チームに、クラスター全体の
view
アクセス権を提供し、変更を許可することなく、監視できるようにする。
アイデンティティープロバイダーの設定の詳細は、「アイデンティティープロバイダー設定について」を参照してください。
17.5.1.4. kubeadmin ユーザーを cluster-admin ユーザーに置き換える リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、すべてのクラスターに cluster-admin
権限を持つ kubeadmin
ユーザーが作成されます。クラスターのセキュリティーを強化するには、`kubeadmin` ユーザーを cluster-admin
ユーザーに置き換えてから、kubeadmin
ユーザーを無効にするか削除します。
前提条件
-
cluster-admin
権限を持つユーザーを作成した。 -
OpenShift CLI (
oc
) がインストールされている。 - セキュアに保存するための仮想 vault への管理アクセス権がある。
手順
-
htpasswd
アイデンティティープロバイダーを使用して、緊急用のcluster-admin
ユーザーを作成します。詳細は、「htpasswd 認証について」を参照してください。 次のコマンドを実行して、新しいユーザーに
cluster-admin
権限を割り当てます。oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>
$ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 緊急用ユーザーのアクセス権を検証します。
- 新しい緊急用ユーザーを使用してクラスターにログインします。
次のコマンドを実行して、ユーザーに
cluster-admin
権限があることを確認します。oc whoami
$ oc whoami
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に緊急用ユーザーの ID が表示されることを確認します。
緊急用ユーザーのパスワードまたは認証キーを仮想 vault にセキュアに保存します。
注記機密性の高い認証情報の保護に関する組織のベストプラクティスに従ってください。
次のコマンドを実行して、
kubeadmin
ユーザーを無効にするか削除し、セキュリティーリスクを軽減します。oc delete secrets kubeadmin -n kube-system
$ oc delete secrets kubeadmin -n kube-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.5.1.5. 通信事業者 CNF のセキュリティーに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者のワークロードは膨大な量の機密データを処理するため、高い信頼性が求められます。1 つのセキュリティー脆弱性が、クラスター全体に及ぶ広範な侵害につながる可能性があります。シングルノード OpenShift クラスター上で多数のコンポーネントが実行されている場合、侵害が拡大するのを防ぐために各コンポーネントを保護する必要があります。通信事業者のネットワークの信頼性を維持し、脆弱性を回避するには、すべてのコンポーネントを含むインフラストラクチャー全体のセキュリティーを確保することが不可欠です。
通信事業者にとっては、以下の主要なセキュリティー機能が欠かせません。
- Security Context Constraints (SCC): OpenShift クラスター内の Pod セキュリティーをきめ細かく制御します。
- Pod Security Admission (PSA): Kubernetes ネイティブの Pod セキュリティーコントロール。
- 暗号化: 高スループットのネットワーク環境でデータの機密性を確保します。
17.5.1.6. Kubernetes と OpenShift Container Platform における Pod セキュリティーの発展 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes では当初、Pod のセキュリティーが制限されていました。OpenShift Container Platform を Kubernetes と統合したときに、Red Hat は Security Context Constraints (SCC) によって Pod のセキュリティーを強化しました。同様の機能として、Kubernetes バージョン 1.3 で PodSecurityPolicy
(PSP) が導入されました。しかし、Kubernetes バージョン 1.21 で Pod Security Admission (PSA) が導入されたことにより、Kubernetes バージョン 1.25 で PSP は非推奨になりました。
PSA は、OpenShift Container Platform でも、バージョン 4.11 で利用可能になりました。PSA は、Pod のセキュリティーを強化しますが、通信事業者のユースケースに現在も必要な、SCC によって提供される一部の機能が欠けています。したがって、OpenShift Container Platform は引き続き PSA と SCC の両方をサポートしています。
17.5.1.7. CNF デプロイメントの主な領域 リンクのコピーリンクがクリップボードにコピーされました!
クラウドネイティブネットワーク機能 (CNF) のデプロイメントには、次の主な領域があります。
- コア
- CNF が初めてデプロイされたのは、ワイヤレスネットワークのコア領域でした。CNF をコアにデプロイするということは、通常、中央オフィスまたはデータセンターにサーバーのラックを配置することを意味します。これらのサーバーは、インターネットと無線アクセスネットワーク (RAN) の両方に接続されます。ただし、多くの場合、複数のセキュリティーファイアウォールの背後に配置され、インターネットから完全に遮断されていることもあります。このタイプのセットアップは、オフラインクラスターまたは非接続クラスターと呼ばれます。
- RAN
- CNF がコアネットワークで問題なくテストされ、効果的であることが確認されたところで、CNF を無線アクセスネットワーク (RAN) にデプロイすることが検討されました。RAN に CNF を導入するには、多数のサーバー (大規模なデプロイメントでは最大 100,000 台) が必要です。これらのサーバーは、携帯電話基地局の近くに設置されます。通常はシングルノード OpenShift クラスターとして実行され、高いスケーラビリティーを必要とします。
17.5.1.8. 通信事業者固有のインフラストラクチャー リンクのコピーリンクがクリップボードにコピーされました!
- ハードウェア要件
- 通信事業者のネットワークでは、クラスターは主にベアメタルハードウェア上に構築されます。その場合、仮想マシンを使用せずに、オペレーティングシステム (op-system-first) を物理マシンに直接インストールします。これにより、ネットワーク接続の複雑さが軽減され、レイテンシーが最小限に抑えられ、アプリケーションの CPU 使用率が最適化されます。
- ネットワーク要件
- 通信事業者のネットワークでは、標準的な IT ネットワークよりもはるかに大きな帯域幅が必要です。通信事業者のネットワークでは、大量のデータスループットを処理するために、通常、デュアルポート 25 GB 接続または 100 GB ネットワークインターフェイスカード (NIC) が使用されます。セキュリティーは極めて重要であり、機密性の高い個人データを保護するには、暗号化された接続とセキュアなエンドポイントが必要です。
17.5.1.9. ライフサイクル管理 リンクのコピーリンクがクリップボードにコピーされました!
セキュリティーを確保するには、アップグレードが重要です。脆弱性が発見された場合、その脆弱性は最新の z-stream リリースで修正されます。その後、この修正は下位の各 y-stream リリースに遡って導入され、サポート対象のすべてのバージョンにパッチが適用されます。パッチはサポート対象外になったリリースには適用されません。したがって、OpenShift Container Platform クラスターを定期的にアップグレードして、サポート対象のリリースを維持し、脆弱性から保護された状態を維持することが重要です。
ライフサイクル管理とアップグレードの詳細は、「通信事業者コア CNF クラスターのアップグレード」を参照してください。
17.5.1.10. ネットワーク機能から CNF への進化 リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク機能 (NF) は、独立して動作する専用のハードウェアデバイスである物理ネットワーク機能 (PNF) として初まりました。PNF は仮想ネットワーク機能 (VNF) へと徐々に進化しました。VNF は、PNF の機能を仮想化する一方で、CPU、メモリー、ストレージ、ネットワークなどのリソースを制御します。
テクノロジーがさらに進歩するにつれて、VNF はクラウドネイティブネットワーク機能 (CNF) に移行しました。CNF は軽量でセキュアかつスケーラブルなコンテナー内で実行されます。セキュリティーとパフォーマンスを強化するために、非 root での実行や最小限のホスト干渉など、厳格な制限が適用されます。
PNF は、干渉を受けることなく独立して動作するように、無制限の root アクセス権を持っていました。VNF への移行に伴い、リソースの使用が制御されるようになりましたが、プロセスは仮想マシン内で引き続き root として実行できました。一方、CNF は root アクセスを制限し、コンテナーの機能を制限して、他のコンテナーやホストオペレーティングシステムへの干渉を防ぎます。
CNF への移行における主な課題としては、次のものがあります。
- モノリシックなネットワーク機能を、コンテナー化されたより小さなプロセスに分割する。
- 非 root での実行や分離などのクラウドネイティブの原則に準拠しながら、通信業界グレードのパフォーマンスと信頼性を維持する。
17.5.2. ホストのセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
17.5.2.1. Red Hat Enterprise Linux CoreOS (RHCOS) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) は、いくつかの重要な点で Red Hat Enterprise Linux (RHEL) と異なります。詳細は、「RHCOS について」を参照してください。
通信事業の観点から見ると、大きな違いは、Machine Config Operator を通じて更新される rpm-ostree
の制御です。
RHCOS は、OpenShift Container Platform の Pod に使用されるものと同じイミュータブルな設計に準拠しています。これにより、クラスター全体でオペレーティングシステムの一貫性が維持されます。RHCOS アーキテクチャーの詳細は、「Red Hat Enterprise Linux CoreOS (RHCOS)」を参照してください。
セキュリティーを維持しながらホストを効果的に管理するには、可能な限り直接アクセスを避けてください。代わりに、次の方法を使用してホストを管理できます。
- デバッグ Pod
- 直接 SSH 接続
- コンソールアクセス
次の RHCOS セキュリティーメカニズムを確認してください。いずれもホストのセキュリティーを維持するために不可欠なものです。
- Linux 名前空間
- プロセスとリソースの分離を実現します。各コンテナーは、独自の名前空間内にプロセスとファイルを保持します。ユーザーがコンテナーの名前空間から脱出すると、ユーザーがホストオペレーティングシステムにアクセスできるようになり、セキュリティーが侵害される可能性があります。
- Security-Enhanced Linux (SELinux)
必須アクセス制御を適用し、プロセスによるファイルとディレクトリーへのアクセスを制限します。プロセスが制限を破ろうとした場合にファイルへの不正アクセスを防止することにより、セキュリティー層をさらに追加します。
SELinux は、明示的に許可されない限りすべてを拒否するというセキュリティーポリシーに従います。プロセスが許可なくファイルを変更またはアクセスしようとすると、SELinux はアクセスを拒否します。詳細は、SELinux の概要 を参照してください。
- Linux ケイパビリティー
- プロセスに特定の権限を細かいレベルで割り当てることで、フル root 権限の必要性を最小限に抑えます。詳細は、「Linux ケイパビリティー」を参照してください。
- コントロールグループ (cgroup)
- プロセスやコンテナーの CPU やメモリーなどのシステムリソースを割り当てて管理し、効率的な使用を実現します。OpenShift Container Platform 4.16 以降、cgroups には 2 つのバージョンがあります。デフォルトでは cgroup v2 が設定されます。
- CRI-O
- セキュリティー境界を適用し、コンテナーのワークロードを管理する軽量のコンテナーランタイムとして機能します。
17.5.2.2. コマンドラインからのホストへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
ホストの変更やアクセスすべきでない Pod へのアクセスを避けるために、ホストへの直接アクセスを制限する必要があります。ホストに直接アクセスする必要があるユーザーには、LDAP を使用した SSSD などの外部オーセンティケーターを使用してアクセスを管理することを推奨します。これにより、Machine Config Operator を通じてクラスター全体の一貫性を維持できます。
OpenShift Container Platform クラスターサーバーで root ID への直接アクセスを設定しないでください。
クラスター内のノードに接続するには、次の方法を使用できます。
- デバッグ Pod の使用
これは推奨されるノードへのアクセス方法です。ノードをデバッグまたは接続するには、次のコマンドを実行します。
oc debug node/<worker_node_name>
$ oc debug node/<worker_node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードに接続した後、次のコマンドを実行してルートファイルシステムにアクセスします。
chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、ノード上のデバッグ Pod 内で root アクセスが可能になります。詳細は、「root アクセスでのデバッグ Pod の起動」を参照してください。
- 直接 SSH 接続
root ユーザーの使用は避けてください。代わりに、コアユーザー ID (または独自の ID) を使用してください。SSH を使用してノードに接続するには、次のコマンドを実行します。
ssh core@<worker_node_name>
$ ssh core@<worker_node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要コアユーザー ID には、最初にクラスター内で
sudo
権限が付与されます。SSH を使用してノードに接続できない場合は、How to connect to OpenShift Container Platform 4.x Cluster nodes using SSH bastion pod を参照して、SSH 鍵をコアユーザーに追加してください。
SSH を使用してノードに接続した後、次のコマンドを実行して root シェルにアクセスします。
sudo -i
$ sudo -i
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - コンソールアクセス
コンソールがセキュアであることを確認してください。root ID による直接ログインを許可しないでください。代わりに個別の ID を使用します。
注記コンソールアクセスの保護に関する組織のベストプラクティスに従ってください。
17.5.2.3. Linux ケイパビリティー リンクのコピーリンクがクリップボードにコピーされました!
Linux ケイパビリティーは、プロセスがホストシステム上で実行できるアクションを定義するものです。デフォルトでは、セキュリティー対策が適用されない限り、いくつかのケイパビリティーが Pod に付与されます。これらのデフォルトのケイパビリティーは次のとおりです。
-
CHOWN
-
DAC_OVERRIDE
-
FSETID
-
FOWNER
-
SETGID
-
SETUID
-
SETPCAP
-
NET_BIND_SERVICE
-
KILL
Security Context Constraints (SCC) を設定することで、Pod に付与されるケイパビリティーを変更できます。
次のケイパビリティーを Pod に割り当てることはできません。
-
SYS_ADMIN
: 昇格された権限を付与する強力なケイパビリティー。このケイパビリティーを許可すると、セキュリティー境界が破られ、重大なセキュリティーリスクが生じる可能性があります。 -
NET_ADMIN
: SR-IOV ポートなどのネットワークを制御できます。ただし、最新のセットアップでは代替ソリューションに置き換えることができます。
Linux ケイパビリティーの詳細は、Linux capabilities man ページを参照してください。
17.5.3. Security Context Constraints リンクのコピーリンクがクリップボードにコピーされました!
RBAC リソースがユーザーアクセスを制御するのと同様の方法で、管理者は Security Context Constraints (SCC) を使用して Pod の権限を制御できます。この権限によって、Pod が実行できるアクションとアクセスできるリソースが決まります。SCC を使用すると、Pod が実行する必要がある一連の条件を定義できます。
Security Context Constraints を使用すると、管理者は次のセキュリティー制約を制御できます。
-
Pod が
allowPrivilegedContainer
フラグが付いた特権付きコンテナーを実行できるかどうか -
Pod が
allowPrivilegeEscalation
フラグで制約されているかどうか - コンテナーが要求できる機能
- ホストディレクトリーのボリュームとしての使用
- コンテナーの SELinux コンテキスト
- コンテナーのユーザー ID
- ホストの namespace とネットワークの使用
-
Pod ボリュームを所有する
FSGroup
の割り当て - 許可される補助グループの設定
- コンテナーが root ファイルシステムへの書き込みアクセスを必要とするかどうか
- ボリュームタイプの使用
-
許可される
seccomp
プロファイルの設定
デフォルトの SCC は、インストール中、および一部の Operator またはその他のコンポーネントをインストールするときに作成されます。クラスター管理者は、OpenShift CLI (oc
) を使用して独自の SCC を作成することもできます。
デフォルトの Security Context Constraints の詳細は、デフォルトの Security Context Constraints を参照してください。
デフォルトの SCC は変更しないでください。デフォルトの SCC をカスタマイズすると、プラットフォームの Pod をデプロイ時または OpenShift Container Platform のアップグレード時に問題が発生する可能性があります。さらに、一部のクラスターのアップグレード中にデフォルトの SCC 値がデフォルトにリセットされ、それらの SCC に対するすべてのカスタマイズが破棄されます。
デフォルトの SCC を変更する代わりに、必要に応じて独自の SCC を作成および変更します。詳細な手順は、Security Context Constraints の作成 を参照してください。
次の基本的な SCC を使用できます。
-
restricted
-
restricted-v2
restricted-v2
SCC は、新規インストールによって提供される最も制限の厳しい SCC であり、認証されたユーザーにデフォルトで使用されます。これは、Pod Security Admission (PSA) の制限と同等であり、オリジナルの restricted
SCC よりも制限が厳しいため、セキュリティーが強化されます。また、複数のリリースにわたってオリジナルの SCC から v2 に移行する際に有用です。最終的には、オリジナルの SCC は非推奨になります。したがって、restricted-v2
SCC を使用することを推奨します。
次のコマンドを実行すると、restricted-v2
SCC を調べることができます。
oc describe scc restricted-v2
$ oc describe scc restricted-v2
出力例
restricted-v2
SCC は、明示的に許可されているもの以外はすべて明示的に拒否します。次の設定により、許可されるケイパビリティーとセキュリティー制限が定義されます。
-
Default add capabilities:
<none>
に設定されています。つまり、デフォルトでは Pod にケイパビリティーが追加されません。 -
Required drop capabilities:
ALL
に設定されています。これにより、Pod のデフォルトの Linux ケイパビリティーがすべて削除されます。 -
Allowed capabilities:
NET_BIND_SERVICE
。Pod はこのケイパビリティーを要求できますが、デフォルトでは追加されません。 -
Allowed
seccomp
profiles:runtime/default
。
詳細は、Security Context Constraints の管理 を参照してください。
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.