Azure Red Hat OpenShift

解決する課題

• **OpenShift のエコシステム（開発者コンソール・統合 CI/CD・Operator・Source-to-Image）**をそのまま本番で使いたい
• OpenShift クラスターは欲しいが、コントロールプレーンやインフラの構築・保守・パッチ当ては自分でやりたくない
• オンプレや他クラウドの OpenShift 資産を移植性を保ったままクラウドへ移したい
• Microsoft と Red Hat の共同サポートという単一窓口でエンタープライズ運用を回したい
• 開発チームに **Kubernetes を意識させない開発者体験（Web コンソール・テンプレート・ビルド）**を提供したい
• ここまでの作り込みが不要で素の Kubernetes で十分なら AKS、運用を最小化したいだけなら Container Apps が候補になる

主要概念と用語

• OpenShift: Red Hat が提供する Kubernetes ディストリビューション。素の Kubernetes に開発者コンソール・CI/CD・認証・ルーティングなどを統合したもの
• コントロールプレーン: API サーバー・etcd・スケジューラなどの管理面。Microsoft と Red Hat が共同で運用し、利用者は直接保守しない
• ワーカーノード: 実際にコンテナを動かす VM。サイズや台数を利用者が指定し、ノード分の課金が発生する
• Project（プロジェクト）: OpenShift における名前空間の単位。Kubernetes の Namespace に追加の権限・ポリシー境界を重ねたもの
• Route（ルート）: アプリを外部公開する OpenShift 独自の仕組み。Kubernetes の Ingress に相当し、ホスト名や TLS 終端を管理する
• Source-to-Image（S2I）: ソースコードから直接コンテナイメージをビルドする仕組み。Dockerfile を書かずにビルドできる
• Operator / OperatorHub: アプリやミドルウェアの導入・運用を自動化する拡張。OperatorHub からカタログ的に導入できる
• OpenShift コンソール: クラスターとアプリを操作する統合 Web UI。開発者向けと管理者向けのビューを持つ
• 共同サポート: Microsoft と Red Hat が連携してインシデント対応を行う、単一窓口のサポート体制

仕様・制限・クォータ

• コントロールプレーンとインフラノードは Microsoft と Red Hat が管理し、課金はワーカーノード（VM）・ディスク・関連リソースに対して発生する
• クラスターには コントロールプレーンノード・インフラノード・ワーカーノードが含まれ、利用者が主に制御するのはワーカーノードの構成
• ワーカーノードは 可用性ゾーンに分散配置でき、ゾーン障害への耐性を高められる
• クラスター作成時に 最小ワーカーノード数などの要件があり、本番相当の冗長構成が前提となる
• OpenShift のバージョンにはサポート期間があり、定期的なアップグレードが前提。利用可能リージョンやノード数・コア数にはサブスクリプション/リージョン単位のクォータがあり、引き上げ申請が可能
• 具体的なバージョン番号・最小ノード数・クォータ値は変動するため、最新値は公式ドキュメントで確認する

内部の仕組み

Azure Red Hat OpenShift では、コントロールプレーン（API サーバー・etcd・スケジューラ）とインフラノードを Microsoft と Red Hat が共同で運用し、利用者は ワーカーノードの構成とアプリのデプロイに集中します。AKS が Kubernetes のコントロールプレーンをマネージドにするのに対し、こちらは OpenShift というディストリビューション全体をマネージドで提供する点が特徴です。

アプリの公開には Kubernetes の Service / Ingress に加えて Route が使え、ホスト名と TLS 終端を OpenShift が管理します。ビルドは Source-to-Image によってソースから直接イメージを生成でき、Dockerfile を書かずに開発者体験を簡素化できます。ミドルウェアやアプリの導入・運用は Operator で自動化し、OperatorHub からカタログ的に追加します。

認証は Entra ID などの ID プロバイダーと連携でき、認可は OpenShift の RBAC と Project 単位の境界で制御します。これらにより、開発者は Web コンソールから自分の Project にデプロイし、運用者はクラスター横断のポリシーを管理する、という役割分担を実現できます。

設計パターン / ベストプラクティス

• ワーカーノードを可用性ゾーンに分散し、レプリカ数や配置制約でゾーン障害に耐えられるようにする
• アプリは Project 単位で分離し、チームや環境（開発/本番）ごとに権限とリソースクォータを与える
• 外部公開は Route で一元管理し、ホスト名・TLS 終端・経路ポリシーを宣言的に扱う
• 状態はクラスター外（Azure Database / Cosmos DB / Blob / Cache for Redis）へ逃がし、Pod をステートレスに保つ
• イメージは Azure Container Registry（ACR） に置き、マネージド ID でパスワードレスにプル認証する
• ミドルウェア導入は Operator で標準化し、手作業の構成ドリフトを避ける
• ビルドは Source-to-Image や統合パイプラインで宣言的に管理し、再現性を確保する

運用・監視

• クラスターには Prometheus / Grafana ベースの監視と OpenShift コンソールが統合され、ノードと Pod のメトリクスを確認できる。Azure Monitor 連携でログ/メトリクスを集約することもできる
• クラスターのアップグレードは OpenShift のリリースチャネルに沿って実施し、コントロールプレーンとワーカーを段階的に更新する
• Pod が起動しない → イメージ取得権限（ACR とマネージド ID）、リソース要求量、ノードの空き容量、Project のクォータを確認する
• 外部からアクセスできない → Route の設定、ターゲットポート、TLS 終端、ネットワークポリシーを確認する
• インシデントは Microsoft と Red Hat の共同サポートへ単一窓口でエスカレーションできる

コスト

ノードを動かしている限り課金が続き、ARO は本番相当の冗長構成が前提で下限の規模が AKS より大きくなりがちです。OpenShift のエコシステムや既存資産が要件にないなら、AKS の方がコスト効率は高くなります。

セキュリティ

• 認証は Entra ID などの ID プロバイダーと連携し、認可は OpenShift RBAC と Project 単位の境界で最小権限を設計する
• ワークロードには マネージド ID を付与し、ACR・Key Vault・他リソースへ資格情報なしでアクセスする
• シークレットは Key Vault から注入し、イメージや環境変数への平文埋め込みを避ける
• ネットワークポリシーで Pod 間通信を制限し、必要なら API サーバーやクラスターをプライベート構成にしてインターネット露出を抑える
• イメージは ACR で脆弱性スキャンし、Microsoft Defender for Containers でランタイムの脅威を検知する
• OpenShift とノードは リリースチャネルに沿って定期的にアップグレードし、既知の脆弱性を放置しない

関連サービス・比較

ハンズオン / CLI例

# リソースグループと仮想ネットワークを準備
az group create --name demo-rg --location japaneast

az network vnet create \
  --resource-group demo-rg \
  --name aro-vnet \
  --address-prefixes 10.0.0.0/22

# コントロールプレーン用サブネットを作成
az network vnet subnet create \
  --resource-group demo-rg \
  --vnet-name aro-vnet \
  --name master-subnet \
  --address-prefixes 10.0.0.0/23

# ワーカー用サブネットを作成
az network vnet subnet create \
  --resource-group demo-rg \
  --vnet-name aro-vnet \
  --name worker-subnet \
  --address-prefixes 10.0.2.0/23

# Azure Red Hat OpenShift クラスターを作成
az aro create \
  --resource-group demo-rg \
  --name demo-aro \
  --vnet aro-vnet \
  --master-subnet master-subnet \
  --worker-subnet worker-subnet

# クラスターのコンソール URL を確認
az aro show \
  --resource-group demo-rg \
  --name demo-aro \
  --query consoleProfile.url -o tsv

# クラスター管理者の認証情報を取得（oc / コンソールのログイン用）
az aro list-credentials \
  --resource-group demo-rg \
  --name demo-aro