Rancher v2.15.0リリースノート翻訳
1. Rancher v2.15.0の変更点とアップグレード前の確認事項
Rancher v2.15.0では、Kubernetes v1.36への対応、Cluster API（CAPI）を利用したプロビジョニング機能の一般提供（GA）、ワークロード画面の刷新、モニタリングチャートの分離などが行われました。一方、Kubernetes v1.33のサポート終了や、Rancher App Chartの保持ポリシー変更など、既存環境の更新計画に関わる変更も含まれています。
この記事では、リリースノートに記載された変更から、Kubernetes基盤の管理・運用に関わるポイントを紹介します。v2.15.0はRancher v2系のマイナーリリースです。
1-1. 主な変更
| 分野 | 主な変更 | 確認する点 |
|---|---|---|
| Kubernetes | v1.36に対応し、v1.33のサポートを終了 | 管理対象クラスタのバージョン |
| プロビジョニング | v2provのネイティブCAPIインフラストラクチャプロバイダーがGA | 利用プロバイダー、権限、既知の問題 |
| ダッシュボード | ワークロード概要画面を刷新 | 利用者向け手順や画面案内 |
| Rancher App Chart | 「Rancher」リポジトリに保持ポリシーを導入 | 古いチャートバージョンへの依存 |
| モニタリング | 新規インストールでダッシュボード用チャートを分離 | Prometheus基盤と移行条件 |
| エアギャップ用イメージ | rancher-images.txtに含めるイメージを最適化 |
イメージ取得・tarball作成手順 |
2. Kubernetesバージョン、配布イメージ、Ingressの変更
2-1. Kubernetes v1.36への対応とv1.33のサポート終了
Rancher v2.15ではKubernetes v1.36がサポート対象に加わり、v1.33のサポートが終了しました。Rancher本体の更新を計画する際は、管理対象クラスタのKubernetesバージョンも確認し、v1.33を利用しているクラスタの移行方針を整理してください。
2-2. エアギャップ用イメージ一覧の最適化
rancher-images.txtには、対象のRancherリリースと互換性のあるKubernetesマイナーバージョンごとに、最新のパッチリリースが収録されるようになりました。リリース候補や置き換え済みの古いバージョンは一覧から除かれます。リリースノートでは、これによりエアギャップ環境向けイメージtarballのサイズを削減しつつ、system-agent-installerなどの関連イメージを最新の状態に保つと説明されています。
独自のイメージ取得・配布手順を利用している環境では、生成される一覧と必要なイメージを確認してください。
2-3. Ingressのパブリックエンドポイントアノテーション
Ingressに書き込むfield.cattle.io/publicEndpointsアノテーション数に上限が設けられました。カスタムドメインが多いワークロードで、Kubernetesのメタデータアノテーション上限である256 KBを超え、API検証エラーになる問題への対応です。
3. CAPIプロビジョニング
3-1. v2provのネイティブCAPIプロバイダーがGAに
Rancher v2.15では、V2プロビジョニングフレームワーク（v2prov）におけるネイティブCAPIインフラストラクチャプロバイダーのサポートが、テクニカルプレビューから一般提供（GA）に移行しました。また、CAPI v1.13.2に対応しました。
3-1-1. CAPIプロバイダーについてちょっと詳しく
CAPIでは、管理クラスター上のAPIリソースを使って、別のKubernetesクラスターの作成・構成を宣言的に管理します。CAPIのインフラストラクチャプロバイダーは、対象基盤のAPIを使って、クラスターを構成する仮想マシンやネットワークなどのインフラストラクチャリソースを作成・管理します。たとえばCAPAはAWS向け、CAPVはvSphere向けのプロバイダーです。
従来のv2provでは、ノードを作成するインフラストラクチャプロバイダーとしてRancher Node Driver（rancher/machine）を使っていました。CAPIプロバイダーを使う構成では、この担当をCAPAやCAPVなどに置き換えます。たとえばCAPAはAWS APIを通じて、クラスター用のインフラストラクチャを作成・管理します。
置き換わるのはインフラストラクチャを作成する部分です。Rancherは引き続き、v2provを通じてRKE2のブートストラップとコントロールプレーンを管理します。そのため、この構成では、CAPIプロバイダーが対象基盤上のインフラストラクチャを管理し、Rancherがその上で動くRKE2クラスターのプロビジョニングを管理します。
変更前：Rancher Node Driverを使う構成
図1. Rancher Node Driverが対象基盤のAPIを操作してインフラストラクチャを作成します。
変更後：ネイティブCAPIプロバイダーを使う構成
図2. CAPA／CAPVがインフラストラクチャを作成し、RancherはRKE2のブートストラップとコントロールプレーン管理を続けます。
クラスターとインフラストラクチャのリソースは、Rancher UIから作成する方法と、管理クラスターにマニフェストを適用する方法があります。UIを使う場合は、対象プロバイダーのインストールに加え、そのプロバイダー用のUI拡張が必要です。
利用にあたっては、プロバイダーが対象基盤を操作するための認証情報と、下流クラスターが基盤の機能を利用するためのクラウドプロバイダー設定を個別に確認します。たとえばCAPAではAWSの認証情報が必要です。また、下流クラスター側にもAWS Cloud Controller Managerなど、対象基盤に対応するKubernetesクラウドプロバイダーが必要です。
この構成には制約もあります。v2.15のドキュメントでは、WindowsワーカーノードとRancher UI経由のノードへのSSH接続はサポート対象外です。利用するCAPIプロバイダーの機能や前提条件も異なるため、採用する基盤の公式手順を確認してください。
3-2. UI操作で残る可能性があるリソース
リリースノートには、CAPIインフラストラクチャプロバイダーに関する既知の問題も記載されています。UIからCAPAやCAPVなどを使ってv2provクラスターを作成・編集すると、特定の障害条件で管理クラスターに未使用のインフラストラクチャリソースが残り、手動でのクリーンアップが必要になる場合があります。
CAPIを利用する場合は、対象プロバイダーとUI経由の操作を検証し、失敗時に残るリソースの確認方法も把握しておきます。
3-3. 権限とcloud-configの動作変更
Standard UserおよびCreate Clustersのグローバル権限では、fleet-default名前空間におけるCAPIインフラストラクチャオブジェクトの作成・更新が可能になりました。従来の権限設計を前提としている環境では、更新後に対象オブジェクトを操作できるユーザーを確認してください。
また、ネイティブCAPIプロバイダーを使うv2provでは、ブートストラップ用cloud-configがJinja形式で生成されるようになりました。通常のノードドライバーで使うユーザーデータには影響しないとリリースノートに記載されています。
4. Rancherダッシュボード
4-1. ワークロード概要画面の刷新
Rancherダッシュボードでは、従来の一体型ワークロード一覧に代わり、大規模環境向けの「Workloads Overview」画面が導入されました。リリースノートでは、ワークロード表示の性能とスケーラビリティに関する課題への対応とされています。
以下は、ワークロード概要画面の例です。
図3. Workloads Overview画面の表示例
画面操作を手順書や利用者向け資料に記載している場合は、新しい画面で表示や操作がどう変わるかを確認し、必要に応じて資料を更新してください。
5. Rancher App Chartの保持ポリシー
5-1. 保持対象と既存環境への影響
Rancherの「Apps」機能にある「Rancher」リポジトリでは、過去のチャートバージョンを累積して保持する方式から、直近7回のRancherマイナーリリースを対象とする方式に変わりました。リリースノートでは、直近7回は約2.5年分に相当すると説明されています。
v2.15はこのポリシーを適用する最初のリリースです。7リリースの範囲外で、かつ2年以上前のバージョンは、新しいリリースブランチでは利用できなくなります。
この変更によって既存環境のインストール済みアプリケーションが直ちに削除されるわけではありません。ただし、古いチャートを使うアプリケーションを更新する際に、今後のリリースブランチから該当バージョンを取得できない可能性があります。リリースノートでは、Rancher v2.15へのアップグレード前にアプリケーションを更新することを推奨しています。利用中のチャートバージョンと更新可否を確認してください。アップグレード後もアンインストールや更新版への置き換えは可能です。
6. モニタリングチャートの分離
6-1. 新規インストールで使うチャート
Rancher v2.15.0以降、新規のモニタリングインストールではrancher-monitoring-dashboardsチャートを使用します。既存デプロイメント向けに従来のrancher-monitoringチャートも維持されますが、新しいアップデートは提供されません。継続的な更新とサポートには、rancher-monitoring-dashboardsを利用します。
6-2. Prometheus基盤と移行時の前提
rancher-monitoring-dashboardsはGrafanaダッシュボードとRancher UI連携を提供しますが、Prometheusの実行基盤は含みません。外部のPrometheusスタックと組み合わせて利用します。導入時には従来のrancher-monitoringチャートをアンインストールし、Prometheus基盤を用意する必要があります。リリースノートでは、kube-prometheus-stackが最も簡単な構成として紹介されています。
既存環境から移行する場合は、現在のチャート構成と公式の移行手順を確認してから作業計画を立ててください。
7. 認証とRBAC
7-1. Azure ADのシングルログアウト
Azure AD認証プロバイダーでシングルログアウト（SLO）が利用できるようになりました。有効にすると、Rancherからログアウトした際にAzure ADのセッション終了エンドポイントへリダイレクトします。Azure US Governmentや中国のソブリンクラウド向けには、LogoutEndpointの上書きが用意されています。
オプションのLogoutAllForcedを設定すると、ユーザーがSSOログアウトを回避できないようにできます。
7-2. ローカル認証プロバイダーの非表示
外部認証プロバイダーが有効な環境では、hide-local-auth-providerフィーチャーフラグを使って、ローカルログイン画面やUIからのローカルユーザー管理を制限できます。このフラグはデフォルトで無効です。有効にした後も、緊急時のフォールバックに使う管理用ローカルアカウントのパスワード変更は許可されます。
認証経路を変更する場合は、通常時のログインだけでなく、緊急時の管理アクセスも確認してください。
7-3. GlobalRoleの名前空間ルール継承
GlobalRoleにinheritedNamespacedRulesが追加され、指定した名前空間のRBACルールを管理対象のダウンストリームクラスターへ伝播できるようになりました。対象の名前空間が存在しない場合、その時点ではルールは追加されません。後から名前空間が作成されると、コントローラーがルールを追加します。
このルールはダウンストリームクラスターに適用され、ローカル管理クラスターには適用されません。設定にはGlobalRoleのYAML編集またはAPIを使います。UIからの直接入力には対応していません。
8. Fleet、UIプラグイン、既知の問題
8-1. Rancher Backupsの表示に関する既知の問題
Rancher v2.15とKubernetes v1.36の組み合わせでは、Backupsチャートの問題により、Cluster ToolsにRancher Backupsが表示されない既知の問題があります。該当する構成を利用する場合は、バックアップ機能の導入・運用への影響を確認してください。
8-2. Fleet機能の将来の廃止予定
Fleetでは、今後のリリースでGitRepoRestrictionと認証なしWebhookのサポートを廃止する予定です。マルチテナント環境ではPolicyリソースを使い、Webhookではシークレットを設定する構成への移行が必要になります。これらはv2.15.0での即時削除ではなく、将来の廃止に向けた告知です。
8-3. EmberベースUIプラグインの削除
クラスターおよびノードドライバー向けのEmberベースUIプラグインは、v2.11.0からの非推奨期間を経て、v2.15.0でサポートが削除されました。該当するプラグインを利用している場合は、UI Extensions Frameworkへの移行が必要です。
9. AD FS利用環境での認証上の注意
9-1. アップグレード前に確認すること
AD FSを利用している環境では、Rancher v2.10.1以降へのアップグレードで認証に問題が発生し、手動対応が必要になる場合があります。リリースノートでは、AD FSのRelying Party Trustがメタデータから署名検証証明書を取得できないことが原因とされています。
対処方法として、フェデレーションメタデータから信頼情報を更新する方法と、署名検証証明書を直接追加する方法が示されています。アップグレード前に、利用中のAD FS構成とリリースノートの手順を確認してください。
10. アップグレード計画で確認する項目
10-1. 構成ごとの確認
v2.15.0への更新を計画する際は、少なくとも次の構成を確認してください。
- 管理対象クラスタのKubernetesバージョン。特にv1.33利用クラスタの移行方針。
- Rancher Appsで利用しているチャートのバージョンと更新可否。
- モニタリングのチャート構成、Prometheus基盤、新しいチャートへの移行条件。
- CAPI v2provの利用プロバイダー、権限範囲、失敗時に残るリソース。
- 認証方式と、ローカル管理アカウントを使う緊急時のアクセス手段。
- エアギャップ環境のイメージ一覧・取得・配布手順。
- Fleetの将来廃止予定機能や、削除されたEmberベースUIプラグインの利用状況。
- AD FSを利用している場合の認証上の注意。
CAPI v2provやモニタリングの移行では、既知の問題や前提条件を踏まえて検証環境で動作を確認し、その結果を更新計画に反映します。
11. まとめ
Rancher v2.15.0では、Kubernetes v1.36対応やCAPI v2provのGA化に加え、サポート対象、チャートの保持、モニタリング、認証・権限管理にも変更が入りました。更新前には、利用中の構成がどの変更の影響を受けるかを確認し、既知の問題や移行条件も含めて検証することが重要です。
Comments ()