【保存版】大規模ROSA 設定チートシート〜「運用は手放せても、この値は手放せない」〜

Posted at 2026-07-09

前に 「ROSAって結局どんな時に使うの？」 という採用判断の記事を書いた。あれは「使うか / 手放すか」の話。
この記事はその続き＝「使うと決めた後、実際に立てるときの設定値」
大規模（数十〜数百ノード級・マルチテナント）で本番投入するとき、インフラ/OpenShift勢に突っ込まれない値を先に固めるための実践チートシート。検証は OpenShift 4.18 系／現行 ROSA ドキュメント基準。

0. この記事の立ち位置：マネージドでも自分持ちの設定

前記事の結論は 「ROSAは運用を金で買うプラットフォーム」。コントロールプレーンの運用・アップグレード・障害対応は Red Hat SRE + AWS に手放せる。

でも、手放せない値が残る。それは──

AWS 側の設計（CIDR・IAM/STS・KMS・ネットワーク）で、
しかもインストール後に戻せないもの。

マネージドに預けても、ここだけは自分で正しく決めないとクラスタ再作成コースになる。責任共有モデルで言えば、**Red Hat/AWS に手放した運用の裏で「利用者側に残る設定」**にあたる部分。このチートシートは、その"マネージドでも自分持ちの設定"を設定値レベルで潰すためのもの。だから並び順は「戻せなさ」で決める。

優先度	分類	変更可否	失敗の代償
★★★	アーキ選定 / CIDR設計 / etcd暗号化	インストール後は不可	クラスタ再作成
★★	マシンプール / IAM・STS / Ingress・DNS / コスト設計	一部 day-2 で調整可	再構築 or 慎重な移行
★	ワークロード可用性 / クォータ / アップグレード運用	day-2 で調整可	運用でリカバリ可能

「★★★ を全部埋めてから rosa create cluster を叩く」が鉄則。

「ROSAって何？ / いつ使う？」は前記事に記載しました。ここでは採用は決まった前提で、設定値だけを扱う。

1. ★★★ アーキテクチャ選定（設定に効く差分だけ）

採用判断（HCP か Classic か、そもそも EKS か）は前記事の領分。ここでは設定値に直結する差分だけを押さえる。大規模は原則 HCP 前提で書く。

設定に効く観点	ROSA with HCP	ROSA Classic
自アカウントの最小ノード	worker 2 台〜	7〜9 台（master3 / worker3 / infra2〜3）
control plane ⇔ worker	AWS PrivateLink（別アカウント間）	VPC 内
machine pool と AZ	1 pool = 1 AZ 固定	pool 内でマルチ AZ 可
アップグレード単位	CP と pool を独立に実施可	クラスタ一体
Spot	非対応	専用 pool で対応
STS	必須	前提

設定への波及

HCP は 1 machine pool = 1 AZ。マルチ AZ にしたければ AZ ごとに pool を1本ずつ作る（→ 3章のオートスケーラ設計に直結）。
HCP × CMK は control plane が別アカウントなので、KMS キーポリシー設計が一手増える（→ 6章）。
Spot を大量に使う設計なら Classic か EKS を再検討（採用判断に差し戻し）。

2. ★★★ ネットワーク / CIDR 設計（最重要・変更不可）

machine / service / pod CIDR と host prefix はインストール後に一切変えられない。 マネージドでも自分持ちの設定の筆頭で、しかも AWS 側の設計。500 ノードに届く前に IP 枯渇で詰むのを防ぐ。

2-1. デフォルト値（起点）

項目	rosa フラグ	デフォルト	意味
Machine CIDR	`--machine-cidr`	`10.0.0.0/16`	ノード（EC2）が載る全サブネットを内包
Service CIDR	`--service-cidr`	`172.30.0.0/16`	ClusterIP Service 用
Pod CIDR	`--pod-cidr`	`10.128.0.0/14`	Pod オーバーレイ全体
Host Prefix	`--host-prefix`	`23`	1ノードに切る Pod サブネット（/23 = 510 IP/ノード）

CNI は OVN-Kubernetes が既定（旧 OpenShift SDN は現行リリースで廃止）。SDN 前提の runbook は OVN に読み替える。

2-2. Machine CIDR のサイジング（事故りやすい）

Machine CIDR は「クラスタが使う全マシンサブネットを内包する連続レンジ」。VPC 全体を /16 にしろという意味ではない。
HCP 最小：single-AZ = /25（128 IP）、multi-AZ = /24（256 IP）。これ未満はインストーラが弾く。
ROSA HCP の worker 上限は 500 台。目指すなら /23（512 IP）では足りない：
1. AZ ごとにサブネット分割 → 端数ロス
2. 各 IPv4 サブネットは AWS 予約で先頭・末尾の数個を消費
実務では machine 用に /22（1024 IP）以上。必ず OpenShift Network Calculator で検算する。

2-3. host prefix と Pod 数の関係

host prefix	Pod 用 IP/ノード	備考
`/23`（既定）	510	実質は maxPods=250、さらにリクエストが先に効く（→3章）
`/24`	254	高密度にしないなら十分
`/22`	1022	maxPods を上げる場合に

2-4. 全社ネットワークとの衝突回避

Pod / Service / Machine の各 CIDR を オンプレ・他 VPC・TGW 先・OVN 予約レンジと重複させない。
前記事でも触れた通り ネットワーク/IAM は「AWS の設計」として普通に考える。ここは OpenShift に丸投げできない。

2-5. サブネットタグ（LB連携で必須）

private サブネットに internal LB を出すなら、プリフライトで確認：

kubernetes.io/role/internal-elb = 1

3. ★★ マシンプール設計

3-1. インスタンス選定（コストは11章と一体で考える）

汎用 m5/m6i、コスト最適化なら Graviton（m6g 等 ARM） を評価。ただし Graviton で下がるのは EC2 側だけでライセンスは不変（→11章）。
用途別に pool を分ける：latency-sensitive な tier-1 と bursty なバッチを別 pool（別サイズ）にして noisy-neighbor を物理分離。

3-2. オートスケーリング

rosa create machinepool -c <cluster> \
  --name app-az-a \
  --instance-type m6i.2xlarge \
  --availability-zone <az-a> \
  --enable-autoscaling --min-replicas 3 --max-replicas 30 \
  --labels tier=app

HCP は 1 pool = 1 AZ。伸ばしたい AZ ごとに autoscaled pool を1本ずつ。
min は「プラットフォーム必須 + バッファ」を割らない値に。
autoscaler の勘所：Pending Pod が「その pool が足すノード形状に載らない」なら max を上げても伸びない。requests / affinity / instance type のどれかを直す。

3-3. 1ノードあたり最大 Pod 数（maxPods）— 250は上限であって目標ではない

出荷時デフォルトは maxPods = 250 / podsPerCore = 0（＝podsPerCore無効）。素の ROSA では 250 が唯一のカーネル側ノード上限。

ただし現実には 250 には届かない。先に効くのは：

リソースリクエスト（mem/CPU）が圧倒的に先に刺さる。 例：m5.2xlarge（8vCPU/32GiB）の Allocatable は実質 23〜24GiB 前後。アプリPodが平均 512Mi〜1Gi 要求なら 1ノード 25〜45 Pod 程度でスケジュール不能になり、250 の 1/5 以下で頭打ち。
ROSA は OVN-Kubernetes（Geneve オーバーレイ）なので、EKS + VPC CNI のような ENI/セカンダリIP 上限で Pod が刺さらない。 Pod IP は host-prefix（/23=510）から出るので、510 も 250 もリソースが尽きる前に表に出ない。

→ 250 は天井であって設計目標ではない。ノードあたり Pod 数は事実上リクエスト駆動。

チューニングは"下げる方向"が主。 大量の軽量 Pod で詰めると PLEG / conntrack / kubelet 負荷が上がり NotReady に振れ、blast-radius も広がる。安定重視で 110 前後（upstream K8s 推奨）に絞る運用がある。上げるのは稀で、Red Hat も「テスト上限を超えるな、Pod が要るならノードを足せ」。

# KubeletConfig 例：あえて maxPods を絞る（PLEG/blast-radius 対策）
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cap-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  kubeletConfig:
    maxPods: 110   # podsPerCore は既定 0（無効）。使うなら明示的に設定する

podsPerCore はデフォルト 0（無効）。上の CR で設定した場合に限り「maxPods と小さい方が効く」ルールが発動する（例 podsPerCore=10 なら 25コア未満で podsPerCore が上限）。素のクラスタの挙動ではない。

4. ★★ キャパシティプランニング（Allocatable の罠）

スケジューラが見るのは Capacity ではなく Allocatable（プラットフォーム予約を引いた後）。

計画上の目安（バージョン・インスタンス・機能で変動する概算）：system 予約 ≈ 4.76 GiB、必須クラスタサービス ≈ 3.8 GiB。
つまり 「32GiB クラスのノード」に 24Gi 要求の Pod が Pending になり得る。請求ではなくスケジューライベントに出る事故。
GiB と GB を混同しない：Gi/Mi は 2 のべき乗、G/M は 10 進。「32 GB インスタンス」＝ 32Gi ではない。
実クラスタでは oc describe node <node> の Allocatable を正とする。
結論：1ノードの Pod 数は maxPods（250）ではなく Allocatable ÷ 平均リクエストで決まる。 インスタンス選定は「maxPods に収まるか」ではなく「requests に対して Allocatable が何 Pod 分あるか」で考える。

oc describe node <node> | grep -A6 Allocatable

5. ★★ IAM / STS / OIDC

HCP は STS 前提（短命トークン、1時間以内で失効）。長期 IAM ユーザーキーは使わない。前記事で言う「AWS の作法」がそのまま要る領域。

5-1. ロールの2階建て

種類	役割	代表的な managed policy
account-wide roles	プロビジョニング・SRE サポートの土台	`ROSAInstallerPolicy` / `ROSASRESupportPolicy` / `ROSAWorkerInstancePolicy` ほか
operator-specific roles	Pod 単位（Ingress・EBS CSI 等）に OIDC 経由付与（IRSA）	`ROSAIngressOperatorPolicy` / `ROSAAmazonEBSCSIDriverOperatorPolicy` ほか

5-2. 大規模での定石

OIDC config は再利用可能な形で1つ作る（rosa create oidc-config --mode auto）。複数クラスタで使い回す。
kubeadmin は IdP 検証後に削除。外部 IdP（Azure AD / Okta 等）で MFA と RBAC を統一。
アプリの AWS アクセスは IRSA 一択。ServiceAccount ごとに最小権限ロール。trust の sub は system:serviceaccount:<ns>:<name> まで絞る（* や緩い StringLike 禁止）。

rosa list operator-roles --prefix <prefix>
rosa list idps -c <cluster>

6. ★★★ 暗号化（etcd / KMS / EBS）

6-1. etcd 暗号化の判断

etcd は 既定で AES ブロック暗号化済み。その上で KMS CMK による追加暗号化を選べる。
CMK etcd 暗号化はおよそ 20% の性能オーバーヘッド。要件が明確な場合だけ有効化（不要なら無効のまま推奨）。
インストール時のみ設定可（後付け不可）。

6-2. フラグの違い（混同注意）

フラグ	暗号化対象
`--kms-key-arn`	worker の root ボリューム / EBS
`--etcd-encryption` + `--etcd-encryption-kms-arn`	etcd データベース

rosa create cluster --sts --hosted-cp --mode auto \
  --cluster-name <name> --region <region> \
  --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 \
  --pod-cidr 10.128.0.0/14 --host-prefix 23 \
  --oidc-config-id $OIDC_ID --operator-roles-prefix $PREFIX \
  --kms-key-arn $KMS_ARN \
  --etcd-encryption --etcd-encryption-kms-arn $KMS_ARN

HCP × CMK の落とし穴：control plane が別アカウントにあるため、KMS キーポリシーに operator ロール（*-kube-system-kms-provider 等）を許可しないと worker が起動しない。キー作成とキーポリシー更新を必ずセットで。

6-3. ストレージ暗号化

新規は既定 gp3 StorageClass、PV は既定で暗号化。他 SC は暗号化設定時のみ。
イメージレジストリは S3（SSE-S3）で at-rest 暗号化済み。

7. ★★ Ingress / DNS / ロードバランサ

private を基本線に。規制・本番の internet-facing estate は private API + 限定 ingress。PrivateLink 経由で SRE 管理を private に保つ。
HCP の DNS は「公開 DNS 名 → VPC 内 private IP に解決」（RDS 等と同じ）。IP 直書き禁止、FQDN のみ。
IngressController を分離：プラットフォーム/CI 用とテナントアプリ用で別 IngressController、blast-radius を縮小。

Route TLS 終端の使い分け

Route 種別	終端位置	用途
`edge`	router で終端	一般 HTTPS
`reencrypt`	router 終端後、backend へ再暗号化	backend まで TLS
`passthrough`	Pod までクライアント TLS を貫通	mTLS 等。ALB で TLS 終端すると壊れる

証明書は cert-manager / External DNS Operator で GitOps 化（コンソール手作業を避ける）。前記事の「GitOps 前提で組む」がここにも効く。

8. ★★ セキュリティハードニング

SCC は restricted（restricted-v2）を基本。特権が要るなら privileged ではなく custom SCC。
securityContext 明示：allowPrivilegeEscalation: false / runAsNonRoot: true / readOnlyRootFilesystem: true / capabilities drop-all → 最小 add / seccompProfile: RuntimeDefault。
NetworkPolicy / EgressFirewall は OVN-Kubernetes 前提。既定は全 Pod 間疎通なので namespace 単位で default-deny。
外向きは EgressFirewall（FQDN/CIDR 許可）で exfiltration を防ぐ。
Compliance Operator（OpenSCAP）で CIS/PCI-DSS/FedRAMP を自動監査。HCP では worker 上で走らせる。
default SA を本番 Deployment に使わない。API を叩かない Pod は automountServiceAccountToken: false。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: <team-ns>
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

9. ★ ワークロード可用性（大規模で効く）

PDB の定番事故：replica 2 に minAvailable: 2 を張ると ノードドレインが永久に終わらず、アップグレードが止まる。原則 maxUnavailable: 1 を許容 or メンテ前に replica を増やす。
スプレッド：podTopologySpreadConstraints で hostname（ノード）と zone（AZ）に分散。容量不足を Pending で顕在化させたいなら DoNotSchedule。
ingress/gateway 系の高接続 Pod は 1ノード集中で conntrack/FD/エフェメラルポートを枯らす。最低3レプリカ + ノード/AZ 分散 + PDB。
probe：liveness と readiness を同一エンドポイントで使い回さない（負荷時に再起動ループ）。/livez と /readyz を分ける。
クォータ：各 project に ResourceQuota + LimitRange。全 container に requests/limits 必須化（Kyverno/Gatekeeper で強制）。事業部横断は ClusterResourceQuota。
JVM は CPU ベース HPA（memory を OS に即返却しないので memory HPA が効きにくい）。

10. ★ アップグレード戦略（HCP の強み）

HCP は CP → machine pool を段階的に上げられる。チームごとにメンテ窓が違う大規模で効く。
machine pool 更新は Node Surge（maxSurge で余剰ノードを先に用意 → 旧ノードを drain）。PDB と maxSurge が正しければ容量を落とさず更新。
更新前後で oc get clusteroperators の Degraded を潰す。

rosa list upgrade -c <cluster>
rosa upgrade cluster -c <cluster> --version <ver>     # CP を先に
rosa upgrade machinepool -c <cluster> <pool>          # pool を後で

11. ★★ コスト / ライセンス効率の設計レバー（"成功ペナルティ"を設定で殺す）

前記事で書いた pricing inversion / 成功ペナルティ（vCPU課金なので総vCPUを増やすとライセンスが比例で跳ねる）を、設定でどう効かせるか。ここが両記事の接続点。

11-1. 課金構造をもう一度、設定目線で

ROSA の worker サービスフィーは 4 vCPU あたり課金：

契約	目安（worker / 4vCPU）
オンデマンド	$1,500 / 年
1年コミット	$1,000 / 年
3年コミット	$667 / 年

EC2 実費は別。3年 HCP + EC2 Savings Plan で、オンデマンド Classic 比おおよそ 68% 減の試算も出ている。

11-2. 唯一効くレバー：vCPUあたりのワークロード密度

ライセンスは vCPU に比例する。だから コスト単価を下げるレバーは「同じ vCPU にどれだけ載せるか」＝ requests 適正化。

maxPods を上げても、大きいノードにしても、ライセンス単価は下がらない。 効くのは 3〜4章で見た「requests 駆動の密度」。過剰な requests を削って vCPU あたりの実効 Pod 数を上げるのが、実は最大のコスト施策。
requests が実測の 2〜3 倍で張られている、が大規模だと当たり前に起きる。VPA レコメンド / メトリクスで棚卸しすると、ノード台数（=vCPU=ライセンス）がそのまま減る。

11-3. Graviton は「EC2 側だけ」下がる

Graviton 化で下がるのは EC2 実費だけ。ライセンス（vCPU課金）は不変。
なので Graviton の判断は 「EC2 削減 vs ARM 対応の工数」で閉じる。ライセンス削減を期待して Graviton に寄せると読み違える。ARM 対応済みイメージなら素直に EC2 コストが浮く、で十分。

11-4. "成功ペナルティ"回避の実装ルール

高コア機への無闇な集約はライセンスを増やす。集約するなら「vCPU 総数を増やさず密度を上げる」方向（＝ requests 適正化）で。コア数を増やして詰めると、その分ライセンスが乗る。
定常 production pool は Savings Plan / コミットで握る。worker フィー（コミット）と EC2（Savings Plan）は別々に最適化する。
Spot は Classic pool のみ（HCP 非対応）。fault-tolerant なバッチはこちら。

11-5. 損益分岐の目安（前記事の"EKSとの天秤"を数式化）

ROSA上乗せ ≒ (workerフィー × vCPU規模) + ライセンス
純k8s(EKS)コスト ≒ CP実費($73/月/cluster) + 運用人件費 + アドオン構築工数

→ 「浮く人件費 > ROSA上乗せ」なら ROSA、逆なら EKS/自前

チームが薄いうちは ROSA が勝ちやすく、vCPU規模が大きく専任SREを常設できる体力が出ると EKS/自前が追い抜く、という交差が典型。前記事の「何を握って何を手放すか」が、ここで vCPU 規模の数字に落ちる。

12. 上限・クォータ早見表

項目	値 / 目安	備考
ROSA HCP worker 上限	500	machine CIDR は `/22`+
maxPods / ノード（既定）	250	実際はリクエストが先に効く
HCP 最小 machine CIDR	`/25`（1AZ）/ `/24`（multi-AZ）	下限強制
HCP 最小 worker	2	Classic は 7〜9
本番 AZ 数	3 以上	AZ ごとに autoscaled pool
worker サービスフィー	4vCPU あたり課金	コミットで削減
AWS サービスクォータ	VPC/EIP/ELB ルール等	設計レビュー時に増枠申請

13. インストール前チェックリスト（変更不可な値）

rosa create cluster の前に、以下を全部確定させる。

HCP か Classic か（Spot 要件なら再検討 → 前記事の採用判断へ）
Machine CIDR（500ノードなら /22+、Network Calculator で検算済み）
Service / Pod CIDR / host prefix（全社ネットワークと非重複）
host prefix と Pod 密度の整合（将来の requests 込み）
AZ 構成（3AZ、AZ ごとの pool 計画）
etcd 暗号化の要否（CMK なら 20% オーバーヘッド承知）
KMS：--kms-key-arn（EBS）と --etcd-encryption-kms-arn（etcd）を区別、キーポリシーに operator ロール許可
private / PrivateLink / zero-egress 方針
OIDC config を再利用可能な形で作成
account/operator roles を最小権限で
IMDSv2（--ec2-metadata-http-tokens required）の要否
vCPU 規模の見積り（ライセンス費 = "成功ペナルティ" を先に試算）
AWS Service Quotas 増枠申請

まとめ：手放していい運用の裏で、この値だけは握る

前記事の結論は「ROSAは運用を手放していい」だった。この記事はその裏面。

運用は手放せる。でも AWS 側の、戻せない値だけは自分で握らないといけない。

CIDR / host prefix — 500ノードを見据えて /22+、Network Calculator で検算
etcd / KMS — 要否とキーポリシーをインストール前に確定
IAM / STS — IRSA 最小権限、OIDC 再利用
コスト — ライセンスは vCPU 課金。単価を下げるレバーは requests 密度だけ。Graviton は EC2 側のみ
あとは day-2（マシンプール・クォータ・アップグレード）で調整可能

この順で潰せば、インフラ勢にも OpenShift 勢にも刺されにくく、かつ「運用を手放した分のコスト」も見える構成になる。

参考（一次情報を必ず当たること）

ROSA Best Practices and Recommendations（Red Hat Cloud Experts）
ROSA / OpenShift 公式ドキュメント（Architecture models / Data protection / Nodes / Networking）
OpenShift Network Calculator（CIDR 検算）
AWS ROSA User Guide（暗号化 / shared responsibility / service quotas）
前記事：「ROSAって結局どんな時に使うの？」（採用判断編）

本記事の数値は OpenShift 4.18 系／2026年時点のドキュメントに基づく。インストール後に変更不可な値は、必ず最新の公式ドキュメントと Network Calculator で再確認してから本番投入すること。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【保存版】大規模ROSA 設定チートシート 〜「運用は手放せても、この値は手放せない」〜