ROSAシリーズ第3回。
第1回：ROSAって結局どんな時に使うの？**（なぜ使うのか＝採用判断）
第2回：大規模ROSA 設定チートシート**（どう建てるか＝初期構築）
第3回：本記事（何に気をつけるか＝落とし穴）本記事は 筆者の武勇伝ではなく、Red Hat公式ドキュメント・ナレッジベース(KB)・AWS公式ドキュメントで「よくある問題」として文書化されている事象を収集・整理したものです。各項目に一次情報へのリンクを付けています。「公式がわざわざ書いている＝踏まれている」という視点で読んでください。
この記事の読み方
ROSAはマネージドサービスですが、マネージドが引き受けるのは「基盤の運用」までです。設定ミスや運用プロセスの不在は、マネージドでは解決されません。
以下、「変更できない」「止まる」「触れない」「守られていない」 の4カテゴリで整理します。
1. 変更できない ── インストール後に戻せない設定
1-1. CIDR / host prefix はインストール後に変更不可
何が問題か：machine / service / pod CIDR と host prefix は、クラスタ作成後に変更できません。後からノードを増やそうとしてIPが足りない、オンプレや他VPCとCIDRが重複していてVPCピアリングが張れない、といった事態になっても、クラスタを作り直す以外の手段がありません。
対策：
- 作成前に OpenShift Network Calculator で必ず検算する
- 全社ネットワーク（オンプレ / 他VPC / Transit Gateway先）と重複しないことをネットワーク担当と合意してから作成する
- 将来のノード数・Pod密度を見込んだレンジを取る（詳細は第2回記事）
📌 これは「気をつけよう」ではなく「作成前に確定させる」類の項目です。
1-2. カスタムKMSキーがデフォルトStorageClassに伝播しない
Red HatのKBに、カスタムKMSキーがデフォルトのStorageClassに反映されない事象が「よくある問題」として掲載されています。
📖 出典：Consolidated Troubleshooting Article ROSA 4.x (Red Hat KB) — "ROSA / OSD : Custom KMS key not propagated to default storage class"
対策：暗号化要件がある場合、デフォルトStorageClass任せにせず、PVの暗号化が意図通りか作成後に検証する。
2. 止まる ── アップグレードとノードdrainのブロック
2-1. PodDisruptionBudget(PDB) がノードdrainをブロックする ★最頻出
これはRed Hatが公式KBで複数記事にわたって文書化している、最も有名なハマりどころです。
何が起きるか：PDBの設定が不適切だと、クラスタ管理者がノードをdrainできなくなります。OSアップデートやアップグレードのためにノードを空にできず、処理が止まります。
Red Hat公式KBは、PDBが正しく設定されていないと、クラスタ管理者がOSアップデートのためにノードをdrainできなくなること、そして「PDBとreplicas=1の両方を持つ」構成がdrainブロックにつながることを明記しています。
📖 出典：Drain with PodDisruptionBudget blocks in OpenShift 4 (Red Hat KB Solution 4736031)
さらに、これがアップグレード失敗として現れるケースも文書化されています。Machine Config Operator(MCO)がdegradedになり、「failed to drain node after 1 hour」というエラーとともに、machine-config-controllerのログに "Cannot evict pod as it would violate the pod's disruption budget" が出る——という具体的な症状です。
典型的な地雷パターン：
# replicas と minAvailable が同数 → 1つもevictできない → drainが完了しない
spec:
replicas: 2
---
apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
minAvailable: 2 # ⚠️ replicas と同数
replicas=1 + PDB も同様にブロック要因になります。
検知方法：ALLOWED DISRUPTIONS が 0 のPDBは、drainをブロックする可能性が高いものとして精査対象です。
# 危険なPDBを洗い出す
oc get pdb -A
# ALLOWED DISRUPTIONS 列が 0 のものを確認する
対策：
- 単一replicaのDeploymentには、
minAvailableよりmaxUnavailableを使う方が安全（単一replica時に穏当に振る舞うため） - アップグレード前にPDBを棚卸しする手順をrunbookに入れる
- Helmチャートが無条件にPDBをデプロイしてくるケースもあるため、導入時に確認する
💡 補足：Kubernetes 1.31+ では
unhealthyPodEvictionPolicy: AlwaysAllowにより、不健全なPodをPDB違反でもevictできるようになっています。OpenShift自身のコンポーネントでも、この設定でdrainブロックを解消する修正が入っています（openshift/console-operator #1099）。
2-2. アップグレードは oc / Webコンソールからできない
何が起きるか：OpenShift Webコンソールや oc CLI からアップグレードしようとすると、admission webhook に拒否されます。
admission webhook "regular-user-validation.managed.openshift.io" denied the request:
Prevented from accessing Red Hat managed resources.
ROSAはManaged Upgrade Operatorがアップグレード前に各種チェックを実行するため、OpenShift Webコンソール経由のアップグレードはサポートされておらず、rosa CLI または OpenShift Cluster Manager コンソールからのみ管理できます。
対策：アップグレードは rosa CLI か OCM コンソールから。素のOpenShiftの手順書をそのまま持ち込まない。
2-3. サポート期限切れ → Limited support status
サポート対象外のバージョンになったクラスタは動作し続けますが、"Limited support" ステータスとなり、そのクラスタにSLAが適用されなくなります。
📖 出典：ROSA FAQ (Red Hat)
対策：アップグレードを定期イベントとしてスケジュールに固定する。「余裕ができたら」は来ません。
3. 触れない ── マネージドの境界にぶつかる
3-1. SRE管理リソースは変更できない（変更するとクラスタが不安定に）
Red Hat公式ドキュメントは、SRE-Pチームが管理・保護しているリソース群について、顧客はこれらのリソースを変更しようとすべきではない、変更するとクラスタが不安定になる可能性があると明記しています。これらは validating webhook（動的admission制御） によって保護されており、これを回避しようとする試みはクラスタの安定性とサポート可能性に影響し得ます。
📖 出典：ROSA managed resources (Red Hat Documentation)
3-2. MachineConfig の作成・変更はサポートされない
何が起きるか：MachineConfigを適用しようとすると、webhookに拒否されます。
OSD/ROSAではMachineConfigの作成・変更はサポートされておらず、そのためRHCOSノードへのカーネル拡張（kernel-devel、usbguard等）の追加もできません。infraノードがworkerノードとMachineConfigを共有しており、infraノードはSRE管理下にあるためです。
📖 出典：MachineConfigs in OSD/ROSA clusters (Red Hat KB Solution 6977697)
対策：移行の初期段階で確認すべき項目です。オンプレOpenShiftでMachineConfigやカーネルモジュールに依存していたワークロードは、ROSAでは動きません。移行検討時に洗い出す。
📌 これは「バグ」ではなく「マネージドに預けた代償」です。第1回記事で書いた**「何を手放して何を握るか」の選択の結果**として理解すべき項目。
4. 守られていない ── バックアップとDRの誤解
4-1. ★最重要：STSクラスタにはSRE管理のバックアップがない
これが本記事で最も重要な項目です。
Red Hat公式FAQに、明確にこう書かれています：
SRE管理のバックアップがあるのは非STSクラスタのみであり、つまり ROSA STSクラスタにはバックアップがありません。
📖 出典：ROSA FAQ (Red Hat) / ROSA Workshop FAQ
そして現在、ROSAはSTSが推奨・標準です。 つまり：
❌ 「マネージドだからSREがバックアップしてくれているはず」は誤りです。
何がSRE管理で、何が自分持ちか：
| 領域 | 誰が守るか |
|---|---|
| コントロールプレーン・etcd・APIサーバーの障害復旧 | Red Hat SRE |
| ノードの自己修復 | プラットフォーム |
| アプリケーションのデータ・PVのバックアップ | 利用者 |
| リストア手順の設計と検証 | 利用者 |
| マルチクラスタ／リージョン跨ぎのDR | 利用者 |
対策：
- OADP（OpenShift API for Data Protection / Velero ベース） 等でバックアップを自分で設計・実行する
- 公式ドキュメントにも Backing up and restoring your ROSA cluster の章が用意されています
- 「バックアップが取れている」と「リストアできる」は別の事実です。 リストアを検証していないバックアップは、存在しないのと同じです
💀 このカテゴリのハマり方は、障害が起きるまで気づかないのが最悪の点です。
5. その他、公式が「よくある問題」として挙げているもの
5-1. AWSサービスクォータ不足
AWS公式のROSAトラブルシューティングドキュメントは、ROSAを使うにはアカウントのサービスクォータの引き上げが必要な場合があること、そしてクォータはリージョンごとに異なるため、各リージョンで個別に確認する必要があることを挙げています。
📖 出典：Troubleshooting ROSA (AWS Documentation)
対策：カットオーバー直前ではなく、設計レビューの時点でクォータを確認し、必要なら増枠申請する。
5-2. IAMロールのリンク漏れ
Red Hat公式のトラブルシューティング章に、user-role IAMロールがAWSアカウントにリンクされていないためにクラスタ作成が失敗するケースが記載されています。原因として多いのは、Red Hat組織内の別のユーザーが ocm-role を作成していたケースで、その後クラスタを作ろうとする各ユーザーは自分の user-role を作る必要があります。
📖 出典：Troubleshooting (Red Hat OpenShift Service on AWS Documentation)
# ロールの状態を確認する
rosa list ocm-role
rosa list user-role
5-3. オフラインアクセストークンの失効
rosa CLIを使っていて api.openshift.com のオフラインアクセストークンが失効すると、エラーメッセージが表示されます。再認証が必要です。
📖 出典：Troubleshooting ROSA (AWS Documentation)
5-4. ドキュメントが2箇所に分かれていて迷う
これも公式が注意喚起しているポイントです。ROSAはRed Hat OpenShiftとAWSの統合プラットフォームであるため、複数のドキュメントサイトを行き来することになり、どこを見ればいいのか混乱しやすい——として、公式は次の使い分けを案内しています：
- AWSコンソールで管理するもの（アカウント詳細・課金）→ AWSのドキュメント
- クラスタ管理（cluster management）→ Red Hat Customer Portal のROSAドキュメント
📖 出典：How to troubleshoot errors in ROSA (Red Hat Hybrid Cloud)
地味ですが、公式がわざわざ書くくらいには迷うポイントです。
まとめ：マネージドが引き受けるもの / 引き受けないもの
本記事で拾った落とし穴を整理すると、境界線が見えてきます。
| ROSA(SRE)が引き受ける | 利用者が引き受ける |
|---|---|
| コントロールプレーン・etcdの運用と障害復旧 | CIDR等、変更不可な初期設計 |
| プラットフォームのアップグレード実行 | PDB設計（不適切だとdrainが止まる） |
| SRE管理リソースの保護・整合性維持 | MachineConfig非対応前提のワークロード設計 |
| ノードの自己修復 | アプリのデータバックアップとリストア検証 |
| 24/7の基盤監視 | AWSクォータ・IAMロールの整備 |
第1回記事で「ROSAは運用をお金で買うプラットフォーム」と書きましたが、その正確な範囲はこうです：
買えるのは「基盤運用の実行責任」。
初期設計のミスも、運用プロセスの不在も、お金では買えない。
ROSAは「夜中に叩き起こされるのがSREになる」サービスであって、「何も考えなくていい」サービスではありません。考えるべきことは減らない。考えるべき場所が変わるだけです。
チェックリスト
作成前・運用中に確認したい項目：
- CIDR / host prefix を Network Calculator で検算したか（作成後は変更不可）
- 全社ネットワークとCIDRが重複していないか
- AWSサービスクォータをリージョンごとに確認・増枠したか
-
ocm-role/user-roleのリンクは正しいか -
oc get pdb -Aで ALLOWED DISRUPTIONS = 0 のPDBがないか - Helmチャートが勝手にPDBを作っていないか
- MachineConfig / カーネル拡張に依存したワークロードがないか
- アプリのバックアップを自分で設計したか（STSクラスタにSRE管理バックアップは無い）
- リストアを実際に試したか
- アップグレードを定期スケジュールに組み込んだか（放置 → Limited support）
- カスタムKMSキーを使う場合、PVの暗号化が意図通りか検証したか
参考リンク（一次情報）
Red Hat 公式ドキュメント / KB
- ROSA managed resources（SRE管理リソース一覧）
- Drain with PodDisruptionBudget blocks in OpenShift 4 (Solution 4736031)
- PDB could cause Machine Config Operator to be degraded (Solution 4857671)
- MachineConfigs in OSD/ROSA clusters (Solution 6977697)
- ROSA upgrade via webconsole not allowed (Solution 7003004)
- Consolidated Troubleshooting Article ROSA 4.x (Article 7026675)
- ROSA FAQ
- How to troubleshoot errors in ROSA
AWS 公式ドキュメント
ツール
その他
- ROSA Workshop FAQ
- #rosa Slack community（Red Hat OpenShift Black Belts に相談できる）
シリーズ
- ROSAって結局どんな時に使うの？ — なぜ使うのか（採用判断）
- 大規模ROSA 設定チートシート — どう建てるか（初期構築）
- ROSAでよく報告されるハマりどころ集 — 何に気をつけるか（本記事）
※本記事は公開されている公式ドキュメント・ナレッジベースをもとに整理したものです。仕様・料金・サポートポリシーは変更されるため、実装時は必ず最新の公式ドキュメントを確認してください。