目次
Red Hat OpenShift Service on AWS(ROSA)完全ガイド v2.0(2026年最新対応)
エンタープライズ Kubernetes・フルマネージド・OpenShift コントロールプレーン・AWS ネイティブ統合プラットフォーム
Red Hat OpenShift Service on AWS(ROSA) は、「AWS 上でフルマネージドの Red Hat OpenShift(エンタープライズ Kubernetes)を実行するコンテナプラットフォームサービス」 である。AWS と Red Hat の共同サポートで Kubernetes API に OpenShift 固有機能(SecurityContextConstraints / OperatorHub / Tekton CI/CD / OpenShift Console)を統合。ROSA HCP(Hosted Control Plane)で コントロールプレーンを AWS が完全管理し、顧客は ワーカーノードのみを管理。2024年に HCP が標準化、2025-2026年に Capacity Reservations / Multi-AZ 自動化・テレコ向け拡張・AI/ML ワークロード最適化。
目次
- ドキュメントメタデータ
- 本質・課題・特徴
- このサービスを選ぶ理由
- アーキテクチャと設計原則
- コアコンポーネント
- デプロイメント方式
- 設定・操作の具体例
- OpenShift 固有機能
- AWS サービス統合
- セキュリティ・コンプライアンス
- 監視・オブザーバビリティ
- 類似サービス比較表
- ベストプラクティス
- トラブルシューティング
- 2025-2026 最新動向
- 学習リソース・参考文献
- 実装例・チェックリスト
- まとめ
ドキュメントメタデータ
- 最終更新: 2026-04-27
- バージョン: v2.0
- 対象者: Platform Engineer、DevOps Lead、Kubernetes Administrator、Cloud Architect
- 難易度: 中級~エンタープライズレベル
- 関連サービス: EC2、VPC、IAM Identity Center、CloudWatch、AWS PrivateLink、EKS(比較)
- 提供開始: 2022年(Classic)、2023年(HCP GA)、2025年に Capacity Reservations・Multi-AZ 自動化・AI/ML 最適化
本質・課題・特徴
本質
Red Hat OpenShift Service on AWS は 「AWS 上で OpenShift を完全マネージド実行する PaaS」 である:
- フルマネージド OpenShift:Kubernetes API + OpenShift 拡張(SCC / OperatorHub / Tekton)
- AWS / Red Hat 共同サポート:SLA 統合(99.95% 可用性)
- ROSA HCP(推奨):コントロールプレーンは AWS 管理、ワーカーのみ顧客管理(コスト削減 + 管理負荷軽減)
- IAM Identity Center 統合:SSO で複数 AWS アカウント・OpenShift アカウント統一管理
- Service Mesh・Developer Console 組み込み:Istio ベースの Service Mesh、Web IDE・CI/CD パイプライン統合
従来の課題
| 課題 | 従来方式(セルフマネージド OpenShift / EKS) | ROSA による解決 |
|---|---|---|
| Kubernetes 管理 | etcd / API Server / Scheduler 手動管理 | AWS が完全管理(パッチ・スケーリング自動) |
| アップグレード | クラスター再構築 / 長時間ダウンタイム | ローリングアップデート(無停止) |
| OpenShift ライセンス | Red Hat 別途契約 | ROSA 料金に含まれる |
| セキュリティポリシー | Pod Security Admission(標準 Kubernetes) | SCC(OpenShift 標準・より厳格) |
| Developer Experience | kubectl 主体 | OpenShift Console / Developer UI(充実) |
| マルチテナント管理 | 複数クラスター・別々に運用 | Namespace + RBAC で単一クラスター統合 |
| AWS 統合 | 手動設定(IAM Role / EBS PVC) | Operator で自動統合 |
| Cost Management | 手動追跡 | Cost Allocation Tag / OpenShift メトリクス統合 |
特徴
- ROSA HCP(推奨):コントロールプレーン AWS 管理(起動時間 10 分)vs Classic(40 分)
- SCC(SecurityContextConstraints):Pod のセキュリティコンテキストを厳格制御
- OperatorHub:1000+ 認定 Operator(データベース・メッシング・監視ツール)
- Tekton Pipelines:Cloud Native CI/CD(GitOps / ArgoCD / Jenkins Operator)
- OpenShift Service Mesh:Istio ベース(トラフィック管理・分散トレーシング・セキュリティポリシー)
- Developer Console:Web IDE・ビジュアルなリソース管理・CI/CD 統合
- IAM STS(Secure Token Service):OIDC ベースの短期 AWS 認証トークン
このサービスを選ぶ理由
ROSA が必須な理由
-
オンプレミスの OpenShift ワークロードの AWS 移行
- 既存 SCC ポリシー・Operator・アプリケーション設定をそのまま流用可能
- オンプレ→AWS への段階的 Lift & Shift(API 互換性 100%)
- Red Hat サポートで既存契約を継続利用
-
AWS / Red Hat 共同サポート
- Kubernetes 問題 → AWS サポート(インフラ層)
- OpenShift 機能 → Red Hat サポート(プラットフォーム層)
- 相互連携で問題解決時間短縮(SLA 統合)
-
エンタープライズセキュリティ機能
- SCC による Pod コンテキスト制御(金融・医療・政府機関で必須)
- OPA(Open Policy Agent)カスタムポリシー定義
- Network Policy + OpenShift Service Mesh による トレースト Zero セキュリティ
-
Developer Experience 重視
- OpenShift Web Console で GUI 管理(Kubernetes Dashboard より充実)
- Developer Catalog / Helm Chart / Operator による ワンクリックデプロイ
- Tekton パイプライン + ArgoCD による GitOps 統合
-
2025-2026 の拡張機能
- Capacity Reservations(大規模クラスター用)
- Multi-AZ 自動化
- AI/ML ワークロード最適化(GPU オートスケーリング)
- テレコ向け 5G / RAN ワークロード対応
具体的なユースケース
- 金融機関のマイクロサービス基盤:SCC による厳格なセキュリティポリシー / Tekton で PCI-DSS コンプライアンス
- Red Hat エコシステム企業:JBoss / AMQ / Fuse / Integration Platform on OpenShift
- 大規模 SaaS 企業:マルチテナント運用 / Red Hat サポート SLA で顧客 SLA 保証
- テレコ会社:5G RAN ワークロード・NFV 基盤(ROSA + OpenStack 統合)
- 自動車メーカー:Connected Car / IoT エッジ・中央管理(ROSA + IoT Greengrass 統合)
- 医療機関:HIPAA コンプライアンス・OpenShift + OPA ポリシー
アーキテクチャと設計原則
ROSA アーキテクチャ(HCP モード - 推奨):
┌──────────────────────────────────────────────────────────────┐
│ AWS 管理アカウント(Red Hat) │
├──────────────────────────────────────────────────────────────┤
│ コントロールプレーン(マルチ AZ): │
│ ┌──────────────────────────────────────────────────────────┐│
│ │ OpenShift API Server(3 レプリカ - マルチ AZ) ││
│ │ etcd(3 レプリカ - 暗号化・バックアップ自動) ││
│ │ OpenShift Scheduler / Controller Manager ││
│ │ Operator Lifecycle Manager / Cluster Update Service ││
│ └──────────────────────────────────────────────────────────┘│
│ ↓ │
│ AWS PrivateLink / Public API Endpoint │
└──────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ 顧客 VPC(カスタマー管理) │
├──────────────────────────────────────────────────────────────┤
│ VPC: 10.0.0.0/16 │
│ ├─ Private Subnet(AZ-a): 10.0.1.0/24 │
│ │ └─ Worker Node Pool 1(m5.xlarge × 3) │
│ ├─ Private Subnet(AZ-b): 10.0.2.0/24 │
│ │ └─ Worker Node Pool 2(m5.xlarge × 3) │
│ ├─ Private Subnet(AZ-c): 10.0.3.0/24 │
│ │ └─ Worker Node Pool 3(m5.xlarge × 3) │
│ │ │
│ ├─ Infra Node Pool(r5.2xlarge × 2) │
│ │ └─ OpenShift Router / Image Registry / Monitoring │
│ │ │
│ └─ Machine Operator / Cluster Autoscaler │
│ └─ Auto Scaling Group(min=3, max=20) │
│ │
│ セキュリティ: │
│ ├─ Security Group(インバウンド 443 HTTPS のみ) │
│ ├─ Network Policy(Kubernetes + Istio) │
│ ├─ KMS 暗号化(EBS / etcd) │
│ └─ IAM OIDC Provider(Pod → AWS API 認証) │
└──────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ データプレーン(Pod 実行) │
├──────────────────────────────────────────────────────────────┤
│ Namespace: openshift-* / kube-* / custom-apps │
│ ├─ Pod(アプリケーション) │
│ ├─ Service(Kubernetes / OpenShift Route) │
│ ├─ Persistent Volume(EBS / EFS / FSx) │
│ ├─ ConfigMap / Secret(暗号化) │
│ └─ RBAC / SCC(SecurityContextConstraints) │
│ │
│ Operator 管理: │
│ ├─ AWS Service Operator(DynamoDB / RDS / S3 統合) │
│ ├─ OpenShift Service Mesh Operator(Istio) │
│ ├─ OpenShift Pipelines Operator(Tekton) │
│ ├─ Developer Console Operator │
│ └─ Cluster Monitoring Operator(Prometheus / Grafana) │
└──────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ 監視・ログ・ネットワーク │
├──────────────────────────────────────────────────────────────┤
│ CloudWatch Logs(コンテナログ) │
│ CloudWatch Metrics(クラスタメトリクス) │
│ CloudTrail(API 監査ログ) │
│ AWS PrivateLink(オンプレ VPN 接続) │
└──────────────────────────────────────────────────────────────┘
コアコンポーネント
1. Cluster(クラスター)
ROSA クラスターは OpenShift エンタープライズプラットフォームの論理単位。
# ROSA HCP クラスターの作成
rosa create cluster \
--cluster-name my-rosa-cluster \
--sts \
--region ap-northeast-1 \
--version 4.17 \
--replicas 3 \
--compute-machine-type m5.xlarge \
--machine-cidr 10.0.0.0/16 \
--service-cidr 172.30.0.0/16 \
--pod-cidr 10.128.0.0/14 \
--hosted-cp \
--multi-az \
--subnet-ids subnet-xxxxx,subnet-yyyyy,subnet-zzzzz \
--yes
# クラスター情報の確認
rosa describe cluster --cluster my-rosa-cluster
# クラスターの削除(重要な操作)
rosa delete cluster --cluster my-rosa-cluster --yes
特徴:
- マルチ AZ(推奨): 3 つの AZ に分散(高可用性)
- バージョニング: 4.14 / 4.15 / 4.16 / 4.17 サポート(6 ヶ月毎リリース)
- STS ベース認証: IAM Role を使用(短期トークン・セキュア)
2. Machine Pool(ノードプール)
ワーカーノードを複数のプール(用途別)に分離。
# CPU ワーカーノードプール
rosa create machinepool \
--cluster my-rosa-cluster \
--name cpu-pool \
--instance-type m5.2xlarge \
--replicas 3 \
--autoscaling \
--min-replicas 3 \
--max-replicas 20 \
--labels node-type=cpu,workload=compute
# GPU ワーカーノードプール(AI/ML ワークロード)
rosa create machinepool \
--cluster my-rosa-cluster \
--name gpu-pool \
--instance-type g4dn.xlarge \
--replicas 2 \
--autoscaling \
--min-replicas 0 \
--max-replicas 8 \
--labels node-type=gpu,workload=ml
# Infra ノードプール(OpenShift コンポーネント用)
rosa create machinepool \
--cluster my-rosa-cluster \
--name infra-pool \
--instance-type r5.2xlarge \
--replicas 3 \
--labels node-type=infra
ノードプール戦略:
- CPU Pool: 標準ワークロード(Web アプリ / API)
- GPU Pool: AI/ML / データ処理(スケーリング:0~8)
- Infra Pool: OpenShift Router / Image Registry / Monitoring(予約)
- High Memory Pool: データベース / キャッシュ(必要に応じて)
3. Namespace(命名空間)
Kubernetes リソースの論理的なグループ化。RBAC + SCC で制御。
# Namespace の作成
oc create namespace production
# SCC を namespace にバインド
oc adm policy add-scc-to-group restricted-v2 system:serviceaccounts:production
# Namespace での リソースクォータ設定
cat << 'EOF' | oc apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
name: production-quota
namespace: production
spec:
hard:
requests.cpu: "100"
requests.memory: "200Gi"
limits.cpu: "200"
limits.memory: "400Gi"
pods: "500"
EOF
4. Route(OpenShift ルート)
Kubernetes Service を外部に公開する OpenShift 固有リソース(ALB / NLB の役割)。
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: my-app-route
namespace: production
spec:
host: my-app.example.com
to:
kind: Service
name: my-app-service
weight: 100
tls:
termination: edge
insecureEdgeTerminationPolicy: Redirect
wildcardPolicy: None
デプロイメント方式
1. ROSA with HCP(Hosted Control Plane - 推奨)
コントロールプレーンを AWS が完全管理。
メリット:
- 起動時間: 10 分(Classic: 40 分)
- コスト: コントロールプレーン EC2 / EBS 不要
- 管理負荷: 最小(パッチ自動・スケーリング自動)
- 可用性: 99.95% SLA
デメリット:
- カスタマイズ制限(API Server の詳細設定など)
- 早期リリース機能は Classic のみ
2. ROSA Classic(非推奨)
コントロールプレーンも顧客 VPC で実行。2026年4月時点で 新規クラスター不可。
メリット:
- 完全なカスタマイズ(Operator / API Server 設定)
- 標準 Kubernetes + OpenShift(制限なし)
デメリット:
- EC2 コントロールプレーン + EBS コスト増加
- 管理負荷増(パッチ適用・スケーリング手動)
- サポート廃止予定
OpenShift 固有機能
SecurityContextConstraints(SCC)
Pod のセキュリティコンテキストを厳格制御。
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name: custom-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegedContainer: false
allowPrivilegeEscalation: false
capabilities:
drop: [ALL]
fsGroup:
type: MustRunAs
readOnlyRootFilesystem: false
requiredDropCapabilities: [ALL]
runAsUser:
type: MustRunAsNonRoot
seLinuxContext:
type: MustRunAs
supplementalGroups:
type: MustRunAs
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret
OperatorHub(Operator 管理)
1000+ 認定 Operator をワンクリックインストール。
# AWS Service Operator のインストール
oc get operators -A
# OpenShift Service Mesh Operator のインストール
oc apply -f - << 'EOF'
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: servicemeshoperator
namespace: openshift-operators
spec:
channel: stable
installPlanApproval: Automatic
name: servicemeshoperator
source: redhat-operators
sourceNamespace: openshift-marketplace
EOF
Tekton Pipelines(CI/CD)
Cloud Native CI/CD パイプラインをコード化。
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: deploy-pipeline
namespace: production
spec:
params:
- name: git-repo
type: string
- name: image-tag
type: string
workspaces:
- name: source
tasks:
- name: clone
taskRef:
name: git-clone
params:
- name: url
value: $(params.git-repo)
workspaces:
- name: output
workspace: source
- name: build
runAfter: [clone]
taskRef:
name: buildah
params:
- name: IMAGE
value: quay.io/myorg/myapp:$(params.image-tag)
workspaces:
- name: source
workspace: source
- name: deploy
runAfter: [build]
taskRef:
name: openshift-client
params:
- name: ARGS
value: ["set", "image", "deployment/myapp", "myapp=quay.io/myorg/myapp:$(params.image-tag)"]
Developer Console
Web IDE + ビジュアルなリソース管理。
OpenShift Web Console(https://console.apps.xxxx.com)
├─ Administrator View
│ ├─ Cluster Overview(ノード数・CPU / メモリ使用率)
│ ├─ Workloads(Pod / Deployment / StatefulSet)
│ ├─ Storage(PVC / PV)
│ ├─ Networking(Route / Service / Network Policy)
│ └─ Administration(Node / Operator / RBAC)
│
└─ Developer View
├─ +Add(カタログからアプリ追加)
├─ Topology(Pod / Service 可視化)
├─ Builds(BuildConfig / ImageStream)
├─ Pipelines(Tekton パイプライン UI)
└─ Observability(ログ / メトリクス / トレース)
AWS サービス統合
IAM OIDC Provider(Pod → AWS API)
Pod から AWS リソース(S3 / DynamoDB / RDS)へ認証。
# ROSA OIDC Provider の設定
rosa create identity-provider \
--cluster my-rosa-cluster \
--type oidc \
--name aws
# IAM Role と OpenShift Service Account のバインド
rosa create iam-role \
--cluster my-rosa-cluster \
--name my-app-role \
--attach-managed-policy arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess \
--namespace production \
--service-account my-app-sa
AWS Service Operator
DynamoDB / RDS / S3 を OpenShift から直接管理。
apiVersion: dynamodb.services.k8s.aws/v1alpha1
kind: Table
metadata:
name: my-table
namespace: production
spec:
tableName: my-app-table
attributeDefinitions:
- attributeName: pk
attributeType: S
- attributeName: sk
attributeType: S
keySchema:
- attributeName: pk
keyType: HASH
- attributeName: sk
keyType: RANGE
billingMode: PAY_PER_REQUEST
CloudWatch Integration
クラスター監視を CloudWatch に統合。
# CloudWatch Container Insights の有効化
rosa create addon \
--cluster my-rosa-cluster \
--addon cloudwatch-container-insights
# CloudWatch Logs へのログストリーミング設定
oc create configmap cluster-logging-config \
-n openshift-logging \
--from-literal=fluent.conf=$(cat << 'EOF'
<source>
@type tail
path /var/log/containers/*/*.log
pos_file /var/log/fluentd.log.pos
tag kubernetes.*
read_from_head true
<parse>
@type json
time_format %Y-%m-%dT%H:%M:%S.%NZ
</parse>
</source>
<match **>
@type cloudwatch_logs
log_group_name /aws/rosa/cluster
log_stream_name $(hostname)
auto_create_stream true
</match>
EOF
)
セキュリティ・コンプライアンス
Network Policy(ネットワークセキュリティ)
Pod 間通信を制限。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend
namespace: production
spec:
podSelector:
matchLabels:
tier: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
tier: frontend
ports:
- protocol: TCP
port: 8080
OPA(Open Policy Agent)
クラスターポリシーをコード化。
# ファイアウォール: 特定ラベルのない Pod をブロック
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
not input.request.object.metadata.labels.owner
msg := sprintf("Pod must have 'owner' label; got labels: %v", [input.request.object.metadata.labels])
}
# イメージレジストリの強制
deny[msg] {
input.request.kind.kind == "Pod"
image := input.request.object.spec.containers[_].image
not startswith(image, "quay.io/")
msg := sprintf("Image must be from quay.io; got %v", [image])
}
KMS 暗号化(etcd / EBS)
クラスターデータを AWS KMS で暗号化。
# ROSA クラスター作成時に KMS を指定
rosa create cluster \
--cluster-name my-rosa-cluster \
--etcd-encryption-kms-arn arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx \
--yes
監視・オブザーバビリティ
Prometheus + Grafana(ビルトイン)
OpenShift Monitoring Operator が自動構築。
# Prometheus への接続
oc -n openshift-monitoring port-forward svc/prometheus-operated 9090:9090
# Grafana ダッシュボード確認
oc -n openshift-monitoring get secret grafana-admin-password -o jsonpath='{.data.GF_SECURITY_ADMIN_PASSWORD}' | base64 -d
OpenShift Service Mesh(分散トレーシング)
Istio ベースの トラフィック管理 + Jaeger トレーシング。
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
name: basic
namespace: istio-system
spec:
version: v2.4
addons:
jaeger:
install: {}
kiali:
enabled: true
prometheus:
enabled: true
類似サービス比較表
| 観点 | ROSA(OpenShift on AWS) | EKS(Kubernetes) | Self-Managed OpenShift | Azure Red Hat OpenShift |
|---|---|---|---|---|
| Kubernetes ディストリビューション | Red Hat OpenShift | Vanilla Kubernetes(CNCF) | Red Hat OpenShift | Red Hat OpenShift |
| 管理モデル | HCP = AWS 全管理(推奨) | AWS マネージド | セルフマネージド | Azure マネージド |
| コントロールプレーン | AWS / Red Hat 管理 | AWS 管理 | 顧客管理 | Azure 管理 |
| 初期セットアップ時間 | 10 分(HCP) | 20~30 分 | 1~2 週間 | 15 分 |
| GUI コンソール | OpenShift Web Console(充実) | Kubernetes Dashboard(基本的) | OpenShift Web Console | Kubernetes Dashboard |
| CI/CD 統合 | Tekton(ビルトイン) | なし(ArgoCD 等別途) | Tekton(ビルトイン) | なし |
| セキュリティコンテキスト | SCC(厳格) | PodSecurityPolicy / PodSecurityAdmission | SCC(厳格) | PodSecurityPolicy |
| OperatorHub | 1000+ 認定 Operator | Helm Chart(手動) | 1000+ 認定 Operator | Helm Chart |
| Service Mesh | Istio(ビルトイン) | Istio / Linkerd(別途) | Istio(ビルトイン) | Istio(別途) |
| サポート | AWS + Red Hat(共同) | AWS のみ | Red Hat のみ | Microsoft + Red Hat |
| 料金 | $0.03/vCPU/時間(HCP) | $73/月 + EC2 | ライセンス + 自社運用 | $0.026/vCPU/時間 |
| 適用事例 | Red Hat エコシステム・SCC 必須 | AWS ネイティブ・コスト重視 | マルチクラウド・完全制御 | Microsoft エコシステム |
ベストプラクティス
1. Namespace 設計
production
├─ Namespace: payment(決済システム)
│ ├─ SCC: restricted-v2(PCI-DSS 準拠)
│ ├─ Network Policy: ingress 限定
│ └─ Resource Quota: CPU 50 cores / Memory 100Gi
│
├─ Namespace: order(注文管理)
│ ├─ SCC: restricted-v2
│ ├─ Autoscaling: HPA(CPU 70%)
│ └─ Resource Quota: CPU 30 cores
│
├─ Namespace: analytics(分析)
│ ├─ SCC: restricted-v2(S3 アクセス許可)
│ ├─ GPU Node Affinity(g4dn.xlarge)
│ └─ Batch Job
│
└─ Namespace: monitoring
├─ Prometheus / Grafana
├─ Logging Stack(ELK / Loki)
└─ Alerting Rules
2. Machine Pool 戦略
CPU Pool(スタンダード)
├─ インスタンス: m5.xlarge × 10
├─ Autoscaling: 10~50
├─ スポット: 0%(安定性重視)
└─ ラベル: workload=web
GPU Pool(AI/ML)
├─ インスタンス: g4dn.xlarge
├─ Autoscaling: 0~8
├─ スポット: 80%(コスト最適化)
└─ ラベル: workload=ml
Memory Pool(データベース)
├─ インスタンス: r5.4xlarge
├─ 固定数: 3
├─ スポット: 0%
└─ ラベル: workload=database
3. GitOps(ArgoCD)統合
# ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/myorg/config-repo
targetRevision: main
path: apps/production/my-app
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
4. コスト最適化
施策 1: Capacity Reservations(予約) → 基盤ノードを AWS Capacity Reservations で確保(20~30% 割引)
施策 2: Spot インスタンス活用 → テスト / 分析ワークロードで スポット 80%(70% 割引)
施策 3: Auto Scaling(HPA + CA) → Horizontal Pod Autoscaler(CPU 70%)+ Cluster Autoscaler
施策 4: Reserved Instances → 1 年 / 3 年リザーブで 40~50% 割引
トラブルシューティング
| 症状 | 原因 | 解決策 |
|---|---|---|
| Pod Pending | Node リソース不足 / Node Affinity エラー | oc describe pod 確認 / Cluster Autoscaler トリガー |
| ImagePullBackOff | レジストリ認証エラー | imagePullSecret 確認 / quay.io クレデンシャル設定 |
| SCC エラー | Pod が SCC ポリシー違反 | oc explain pod.spec.securityContext で確認 / SCC バインド |
| Route アクセス失敗 | TLS 証明書エラー / ルーター設定 | oc get route -o yaml で hosts 確認 / TLS termination 確認 |
| Persistent Volume 未作成 | Storage Class 名前ミス / AWS リージョンエラー | oc get sc で確認 / AWS IAM 権限確認 |
| Service Mesh Injection 失敗 | Sidecar プロキシ注入設定エラー | Namespace ラベル istio-injection=enabled 確認 |
| API Server タイムアウト | API Server 負荷 / ネットワーク遅延 | oc debug node で確認 / API リクエスト最適化 |
2025-2026 最新動向
2025年拡張機能
-
Capacity Reservations 統合
- AWS Capacity Reservations と ROSA 統合(予約割引 20~30%)
-
Multi-AZ 自動化強化
- クラスター全体の Multi-AZ 展開が GUI から簡単設定
-
AI/ML ワークロード最適化
- GPU Auto Scaling(NVIDIA GPU Operator)統合
- SageMaker との直接連携
-
テレコ向け拡張
- 5G RAN / NFV ワークロード対応
- Real-time OS(RHEL RT)統合オプション
2026年の展望
-
マルチクラスター管理(Advanced Cluster Management)
- 複数 ROSA クラスター間のリソース共有・自動フェイルオーバー
-
エッジコンピューティング対応
- ROSA Edge(オンプレ / エッジデータセンター対応)
-
AI Assistant 統合
- Kubernetes / OpenShift インベリジェントな運用アドバイス
学習リソース・参考文献
- Red Hat OpenShift Service on AWS 公式ドキュメント
- Red Hat OpenShift Documentation
- ROSA with HCP 入門ガイド
- Diving into Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Planes (HCP)
- ROSA Capacity Reservations for Machine Learning
実装例・チェックリスト
デプロイメント前チェック
- [ ] AWS アカウント作成・IAM ロール設定完了
- [ ] AWS PrivateLink vs Public Endpoint を決定
- [ ] VPC / Subnet 設計(CIDR ブロック)完了
- [ ] ROSA HCP or Classic を決定(推奨: HCP)
- [ ] Machine Pool 戦略(CPU / GPU / Memory)決定
- [ ] Storage Class / PVC 戦略決定
- [ ] RBAC / SCC ポリシー定義
- [ ] 監視・ロギング戦略(CloudWatch / Prometheus 統合)決定
- [ ] バックアップ / DR 戦略立案
- [ ] セキュリティ:KMS / Network Policy / OPA ポリシー定義
運用チェック
- [ ] 日次:Pod / Node ヘルスチェック
- [ ] 週次:API Server ログ・エラー率分析
- [ ] 月次:ノードリソース使用率・スケーリング検証
- [ ] 四半期:Operator / アドオン更新確認
- [ ] 年次:OpenShift バージョンアップグレード(4.14 → 4.15 等)
まとめ
Red Hat OpenShift Service on AWS(ROSA)は 「AWS 上で OpenShift エンタープライズプラットフォームを完全マネージド実行するコンテナサービス」。HCP(Hosted Control Plane)で コントロールプレーンを AWS が管理し、顧客は ワーカーノードのみを管理する低運用負荷モデルを実現。SCC / OperatorHub / Tekton / OpenShift Service Mesh 等のエンタープライズ機能を提供し、AWS と Red Hat の共同サポートでミッションクリティカルなワークロードを安定運用。金融機関・テレコ・大規模 SaaS 企業のマイクロサービス基盤・エッジコンピューティング・AI/ML プラットフォームとして採用が加速している。