ROSA デザインパターン v1.0

Red Hat が提供する AWS 上の OpenShift の Managed Service である ROSA (Red Hat OpenShift on AWS) の代表的なデザインパターンと、ネットワーク周りの設計で必要になる知識の解説を行っています。

※対象は ROSA HCP (Hosted Control Plane) のみで、一つ前のアーキテクチャーである ROSA Classic についてはカバーしていません。

Transcript

1. ROSA HCP Network デザイン・パターン Ver. 1.0 2026/04/02 Red Hat Cloud Service Solution Architect Yuhki Hanada
2. はじめに ROSA (Red Hat OpenShift on AWS) の構築は、Red Hat の OpenShift のバリエーションの中でも最も簡単な製品だ と思います。 またデフォルトで AWS Managed の IAM Policy を使用し、セキュリティ的にも強固な OpenShift が簡単に構築でき るようになっています。 一方で、実際のプロダクション環境にデプロイする場合は、様々な要件が発生し、ROSA の知識だけではなく AWS の ネットワークの知識や、証明書の知識などの様々な知識を考慮した上で設計する必要があり、ITインフラのフルスタッ クに近いナレッジが求められます。 この資料では、これまでの提案活動なかで、質問に回答するために作った資料や、社内でテストされたネットワーク構 成などを、できるだけグラフィカルに理解しやすいように、書き起こしまとめたものです。 また、このドキュメントの中でも、複数箇所で参照していますが、私を含む弊社の Cloud Expert が手を動かして実験 したドキュメント群が以下のサイトで公開されています。思い付いたアーキテクチャーで、実現可能か知りたいものが ある場合は、以下のサイトで併せて検索していただく事をおすすめいたします。 Managed OpenShift Tutorials https://cloud.redhat.com/experts/
3. AWS Cloud Public Cluster ROSA VPC AZ 1 AZ 2 AZ 3 NLB NAT Gateway NAT Gateway NAT Gateway Amazon Route 53 Internet Gateway Application users Developers / Admin users. Red Hat Managed Endpoint Private Link VPC End Point Service VPC End Point kubectl / oc Kubernetes API Server の Endpoint はインターネットに公開 User Controlplane • OpenShift (Kubernetes) API 用の エンドポイント • カスタマーアプリケーション の両方が、インターネットに公開 された構成 ・Public Cluster として作成した場合の構成。
4. AWS Cloud ユーザーアプリケーションのみをインターネットに公開 ROSA VPC AZ 1 AZ 2 AZ 3 NLB NAT Gateway NAT Gateway NAT Gateway Amazon Route 53 Internet Gateway Private Link VPC End Point Service VPC End Point Customer VPC Application users Developers / Admin users. Transit Gateway private subnet private subnet private subnet public subnet public subnet public subnet private subnet kubectl / oc Kubernetes API Server の Endpoint は VPC Endpint とし て作成され、インターネットに公 開されない。 User Controlplane Red Hat AWS Account User アプリケーション (OpenShift Console含む) の Endpoint は Public internet rosa 管理コマンドの内、rosa コマンドはインターネッ トアクセスを必要とする ・Public Cluster として作成した後、OpenShift (Kubernetes) API 用の Endpoint を Privateに変更
5. API Endpoint の Private / Public の切り替え 5 インターネット公開 / 内部公開を 切り替えられる インターネット公開 / 内部公開を 切り替えられる ユーザーアプリケーション用の Endpoint OpenShift (Kubernetes) API 用 の Endpoint HCC (Hybrid Cloud Console) から、作成後の構成の変更が可能
6. AWS Cloud ユーザーアプリケーションのみをインターネットに公開 ROSA VPC AZ 1 AZ 2 AZ 3 NLB NAT Gateway NAT Gateway NAT Gateway Amazon Route 53 Internet Gateway Private Link VPC End Point Service VPC End Point private subnet private subnet private subnet public subnet public subnet public subnet User Controlplane Red Hat Managed Endpoint インターネット向け Endpoint インターネット向け Endpoint 内向き Endpoint 内向き Endpoint 切り替え 切り替え kubectl / oc
7. AWS Cloud Private Cluster (Public Cluster として作成した後、全ての Endpoint を Privateに変更) ROSA VPC AZ 1 AZ 2 AZ 3 NLB NAT Gateway NAT Gateway NAT Gateway Amazon Route 53 Internet Gateway Private Link VPC End Point Service VPC End Point Customer VPC Application users Developers / Admin users. Transit Gateway private subnet private subnet private subnet public subnet public subnet public subnet private subnet kubectl / oc User Controlplane Red Hat AWS Account インストール時に Public Cluster として導入す る場合は、Public Subent / NAT Gateway は 必要 Kubernetes API Server の Endpoint は VPC Endpint とし て作成され、インターネットに 公開されない。 User アプリケーション (OpenShift Console含む) の Endpoint は Private internet rosa 管理コマンドの内、rosa コマンドはインターネッ トアクセスを常に必要と する ・テスト/ PoC目的では、Public Cluster としてインストールした方が使い勝手が良い。 ・後から Private に変更すれば、セキュリティを高めつつ、コンポーネントのアップーデートに必要なアウトバウンドのアクセス経路は維持される。
8. AWS Cloud Default Ingress Controller (NLB) + Second Ingress Controller (NLB) 例 ROSA VPC AZ 1 AZ 2 AZ 3 NLB(Default) NAT Gateway NAT Gateway NAT Gateway Amazon Route 53 Internet Gateway Private Link VPC End Point Service VPC End Point Customer VPC Application users Developers / Admin users. Transit Gateway private subnet private subnet private subnet public subnet public subnet public subnet private subnet kubectl / oc User Controlplane Red Hat AWS Account Kubernetes API Server の Endpoint は VPC Endpint として作成され、 インターネットに公開され ない。 internet rosa 管理コマンドの内、rosa コマンドはインターネッ トアクセスを必要とする NLB(Second) 外部公開用のアプリ用 の追加 Ingress Contrlller (NLB) デフォルトの Ingress Controller (NLB) 内部専用にする デフォルトの Ingress Controller は、 OpenShift Console と紐付いているため 、セキュリティのために外部非公開にす る ・ユーザーアプリケーションとOpenShift Console (GUI) は、同じ NLB (Default)を共有する。 ・OpenShift Console が紐付いてる NLB(Default) は Private にしてセキュアにしつつ、ユーザーアプリケーションは、別の NLB(追加 IngressController) でインター ネットに公開する。
9. Customer AWS Account ROSA Private Cluster ROSA VPC AZ 1 AZ 2 AZ 3 NLB Amazon Route 53 Private Link VPC End Point Red Hat Managed System Customer VPC Application users Developers / Admin users. Transit Gateway Internet Gateway internet internet への outbound は必要 (パッチ、バージョンアップなど) oc / kubectl Pod Pod Pod VPC End Point Service Red Hat AWS Account インストール時に Private Cluster として導入する 場合は、Public Subent / NAT Gateway は必要な い。 rosa ・初期状態から Private クラスターとしてインストールするので、ROSA VPC 内に Private Subnet が存在していない。 ・インストールやアップデート時のコンポーネントの取得のために、何らかのルートでインターネットアクセスを許可するか、Egress Lockdown構成を取る必用がある
10. Egress Lockdown 構成 AWS Cloud ROSA VPC AZ 1 AZ 2 AZ 3 NLB Amazon Route 53 Private Link Customer VPC Application users Developers / Admin users. Transit Gateway private subnet private subnet private subnet private subnet kubectl / oc Amazon Elastic Container Registry (Amazon ECR) Red Hat Managed System mirror-registry Day2: IDMS feature Operator Hub 上の 3rd Party Operator用の Registry Red Hat が提供するミラ ー・レジストリ ・OpenShift ・Operators by RedHat インストール用 / アップデート・コンポーネントの取得 Red Hat 提供のイメージの取得 Private Cluster と Network 構成は同じだが、Red Hat が提供するコンポーネントについては、AWS 内部にある Red Hat が管理する Registry から提供するため Internet アクセスは必要無い。 internet rosa 管理コマンドの内、rosa コマンドはインターネッ トアクセスを必要とする ROSA Private Cluster ・2025年2Qから新たに加わった機能。ROSAクラスタのインストール用/アップデート用イメージと、Operator Hub 上のRed Hat 提供 Operator はAWS内のECRから提 供される。 ・Operator Hub 上の 3rd Party の Operatorは、 mirror registry をユーザーが作成して対処する必要がある。
11. AWS Cloud Private Cluster Egress VPC ROSA VPC AZ 1 AZ 2 AZ 3 control plane NLB NAT Gateway Transit Gateway Amazon Route 53 Internet Gateway NAT Gateway private subnet private subnet private subnet public subnet public subnet private subnet private subnet TGW ENI TGW ENI TGW ENI TGW ENI TGW ENI コンテナはインターネット上の Repository から取得するため 、インターネットのアウトバウンドが必要。 デバックや、この後の拡張しすさを考えて、AWS ではしばし ばこのようなネットワーク構成が推奨される。機能として分離 させる事が必須ではない。 デフォルトでは、Install 用のパッケージや、アッ プデートなどを行うため、インターネットへのア クセスが必要になる。 ※ Install 時に Egress Lockdown オプションを使 うと、Red Hat 提供のパッケージについては、イ ンターネットへの直接アクセスは必要なくなる。 2AZ構成を取っているのは AZ の 冗長化のため。 ROSA Private Cluster ・ROSAクラスタのインストール用/アップデート用イメージと、Operator Hub の提供イメージなどを、インターネット経由で取得する場合の構成 ・Inbound のトラフィックは許可する必用はない。
12. AWS Cloud Private Cluster Egress VPC ROSA VPC AZ 1 AZ 2 AZ 3 control plane NLB NAT Gateway Transit Gateway Amazon Route 53 Internet Gateway NAT Gateway transit gateway subnet transit gateway subnet transit gateway subnet transit gateway subnet transit gateway subnet private subnet private subnet private subnet public subnet public subnet https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html ROSA の VPC にtransit gateway 用に専用にサブネットを作成。Transit Gateway 専用のサブネットはデバッグなどを考えたベストプラクティスとされている 。 TGW ENI TGW ENI TGW ENI TGW ENI TGW ENI Transit Gateway 用に専用に、小さなサブネット を作るのは、デバックなどを考えたベストプラク ティスとされる。(Network のトラフィックを流す ために必ず必要というわけではない） ROSA Private Cluster
13. AWS Cloud Private Cluster Egress VPC ROSA VPC AZ 1 AZ 2 AZ 3 control plane NLB Transit Gateway Amazon Route 53 Internet Gateway NAT Gateway transit gateway subnet transit gateway subnet transit gateway subnet transit gateway private subnet private subnet private subnet private subnet public subnet TGW ENI TGW ENI TGW ENI TGW ENI public subnet AWS Firewall Endpoint AWS Firewall を使用して、Outbound アク セス先を限定する事ができる。 AWSが組織で広く使用されている場合、この ような Firewall や Proxy が既に AWS環境内 に設置されている場合も多い。 AWS Network Firewall Frewall Rule Sets ROSA Private Cluster Egress VPC の中に、OutBound のアクセス先を制御するために AWS Firewall を導入。必用なアクセス先はドキュメントに記載されている。 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/prepare_your_environment/rosa-sts-aws-prereqs#rosa-hcp-firewall-prerequisites_rosa-sts-aws-prereqs
14. AWS Cloud Cluster Wide Proxy を使った Outbound トラフィック制御 Egress VPC ROSA VPC AZ 1 AZ 2 AZ 3 control plane (Red Hat VPC) NLB NAT Gateway Transit Gateway Amazon Route 53 Internet Gateway NAT Gateway transit gateway subnet transit gateway subnet transit gateway subnet transit gateway subnet transit gateway subnet private subnet private subnet private subnet public subnet public subnet TGW ENI TGW ENI TGW ENI TGW ENI TGW ENI private subnet private subnet TGW ENI TGW ENI HTTP または HTTPS プロキシのアドレスを指定してく ださい。 HTTPS プロキシを使用する場合は、プロキシの CA 証 明書を ROSA の信頼バンドルに追加する必要がありま す。（透過型プロキシを使用する場合も、信頼バンドル への CA 証明書の追加が必要です。） ROSA Private Cluster In this case, using two AZs for high availability HTTP Proxy を Outbound のトラフィック を制御するために設置。 Whitelist で ROSA や 3rd Party Operator が必要とするアクセスだけを許可する。 Egress VPC の中に、OutBound のアクセス先を制御するために Proxy Server を導入。必用なアクセス先はドキュメントに記載されている。 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/prepare_your_environment/rosa-sts-aws-prereqs#rosa-hcp-firewall-prerequisites_rosa-sts-aws-prereqs
15. AWS Cloud Public Cluster 例 (AWS Security Reference Architecture に沿った構成) Outbound VPC Inbound VPC ROSA VPC AZ 1 AZ 2 AZ 3 control plane NLB (2nd IngressController) NLB Transit Gateway Amazon Route 53 Firewall / Inspection VPC Gateway Load Balancer Internet Gateway Internet Gateway Firewall equipment NAT Gateway NAT Gateway Firewall equipment AZ 1 AZ 2 AZ 1 AZ 2 AZ 1 AZ 2 TGW ENI TGW ENI GWLB Endpoint GWLB Endpoint TGW ENI TGW ENI TGW ENI TGW ENI TGW ENI TGW ENI TGW ENI トラフィックを精査するための Firewall を置いた 専用の VPC インバウンド・トラフィック専用の VPC アウトバウンドの出口専用の VPC Akamai WAF AWS SRA https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference-architecture/network.html NLB
16. ROSA Outbound Traffic Requirement AWS firewall prerequisites デフォルト構成で Outbound で許可する必要があるドメインなどはドキュメントに記載があります。 Outbound を Proxy や Firewall で絞るためには、このガイドに沿った宛先を許可する必要があります。 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/prepare_your_environment/rosa-hcp- prereqs#rosa-hcp-firewall-prerequisites_rosa-hcp-prereqs • 2.9.1.1 Domains for installation packages and tools • 2.9.1.2 Domains for telemetry • 2.9.1.3 Domains for Amazon Web Services (AWS) APIs • 2.9.1.4 Domains for your workload • 2.9.1.5 Optional domains to enable third-party content • 2.9.1.6 Outbound firewall rules for the ROSA CLI for clusters with egress zero • 2.9.1.7 Outbound firewall rules from Red Hat Hybrid Cloud Console for clusters with egress zero 注: “Egress ロックダウン” と呼ばれる、ROSAを含む Red Hat 提供コンポーネントに関しては、AWS内の Red Hat Managed の ECR からダウンロード を行い、インターネットアクセス無しの Closed の環境を作成する方法もあります。
17. ROSA の IngressController とは？ NAT Gateway NLB (default) HTTP App1 Pod HTTP App2 Pod Router Pod Route Route HTTP(S) namespace namespace opensfhit-ingress [4] [3] [1] Service LoadBalancer NodePort ClusterIP Service ClusterIP Service ClusterIP apiVersion: operator.openshift.io/v1 kind: IngressController metadata: annotations: Owner: cloud-ingress-operator ingress.operator.openshift.io/auto-delete-load-balancer: "" creationTimestamp: "2022-06-06T03:51:42Z" finalizers: - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller generation: 6 name: default namespace: openshift-ingress-operator resourceVersion: "584329" uid: ed99f19c-699b-42c9-b2f5-35b3d7785555 …. • OpenShift で用意されている HTTP(S)アプリをクラスター 外に公開する仕組み。 • ROSA HCPの場合は、kind: IngressController を作成する とNLB や Route Pod が作られる (ROSA 導入時に “default” という名前の IngressController が作成される) • IngressController は追加で作成する事ができる。 • Router Pod は、kind: Route を参照してトラフィックを適 切なアプリにルーティングする。 IngressController HTTP(S) インターネット 公開 or 内部のみ
18. OpenShift Console と default の IngressController NAT Gateway NLB (default) OpenShift Console ユーザー APP Pod Router Pod Route Route openshift-console user namespace opensfhit-ingress [4] [3] [1] Service LoadBalancer NodePort ClusterIP Service ClusterIP Service ClusterIP IngressController HTTP(S) インターネット 公開 or 内部のみ ROSA 用 domain (console-openshift- console.[ROSAdomain]) NLB IP (abc.region.amazon.aws.com) Router Pod ユーザー・リクエスト (HOST header 値) (console-openshift-console.[ROSA domain]) ROSA 用 domain [userapp route名].[ROSAdomain] NLB IP (abc.region.amazon.aws.com) Router Pod User取得ドメイン (www.example.com) ユーザー・リクエスト (Host Header値) (www.example.com) OpenShnift Cosole Pod User Application Pod CNAME Route (console-openshift- console.[ROSA domain]) Route (www.example.com) ROSA では、Route の変更を許可され ていないので OpenShift Console につ いては 独自ドメインは使用できない。 OpenShift Console ユーザーアプリ 基本的にユーザーが変更して はいけないエリア A Record A Record NLB Target NLB Target OpenShift Console へのアクセスも、 ユーザーのアプリも同じ NLBを通過 ユーザーアプリは、Route を自由に設 定できるので、独自ドメインが利用で きる
19. CloudFront を使用した WAF 構成 AWS Cloud ROSA VPC AZ 1 AZ 2 AZ 3 NLB NAT Gateway NAT Gateway NAT Gateway Internet Gateway private subnet private subnet private subnet public subnet public subnet public subnet ROSA導入時に自動作成される default IngressController の NLB OpenShift Console ドメインと 紐付いているので、セキュリテ ィのために、外部非公開にする 。 OpenShift Console のドメイン は変更不可 / CNAME 不可のた め、WAFを設定できない。 第5章 チュートリアル: AWS WAF と Amazon CloudFront を使用した Red Hat OpenShift Service on AWS ワークロードの保護 https://docs.redhat.com/ja/documentation/red_hat_openshift_service _on_aws/4/html-single/tutorials/index#cloud-experts-using- cloudfront-and-waf NLB Amazon CloudFront 追加 IngressController を構成する NLB default の NLB と同じで ROSA(OpenShift) 上の複数のアプリケーシ ョンで共有が可能です。 ラベルを使って、default の IngressController と対象アプリを振り分 けます。 作成には独自ドメインが必要です。 この部分はインターネット通信 (NLBはインターネットに Open) WAF
20. CloudFront を使用した WAF 構成 + Cloud Front VPC Origin AWS Cloud ROSA VPC AZ 1 AZ 2 AZ 3 NLB (default) Internet Gateway private subnet private subnet private subnet Using a Private IngressController with CloudFront on a ROSA Cluster https://cloud.redhat.com/experts/rosa/nlb-cf-vpco/ Inner NLB 追加 IngressController を構成する NLB default の IngressController の NLB と同じで ROSA(OpenShift) 上 の複数のアプリケーションで共有が可能です。 ラベルを使って、default の IngressController と対象アプリを振り分 けます。 作成には独自ドメインが必要です。 Amazon CloudFront ROSA導入時に自動作成される default IngressController の NLB OpenShift Console のドメイン と紐付いているので、セキュリ ティのために、外部非公開にし ています。 OpenShift Console のドメイン は変更不可 / CNAME 不可のた め、WAFを設定できません。 Outer NLB (Origin) VPC Origin を使用するためには、Security Group を持った NLB が必 要ですが、IngressController の NLB は、Security Group を持たず 、後から追加もできません。そのため、前段に通常の NLB をデプロイ し、CloudFront の VPC Origin にします。 この部分は AWS のネットワーク WAF 開発者
21. “AWS Load Balancer Operator (ALBO)” を使用した ALB(+WAF) 構成 AWS Cloud ROSA VPC AZ 1 AZ 2 AZ 3 NLB NAT Gateway NAT Gateway NAT Gateway Internet Gateway private subnet private subnet private subnet public subnet public subnet public subnet ALB AWS WAF 第6章 チュートリアル: AWS WAF と AWS ALB を使用した Red Hat OpenShift Service on AWS ワークロードの保護 https://docs.redhat.com/ja/documentation/red_hat_opens hift_service_on_aws/4/html/tutorials/cloud-experts-using- alb-and-waf “AWS Load Balancer Operator” を使 用して ALB をデプロイします。 ALB一つにつき、ROSA (OpenShift) 上 のアプリケーションが一つだけ紐付きま す。ROSA の IngressController と違い 、アプリケーション間での共有はできま せん。 ROSA導入時に自動作成される default IngressController の NLB OpenShift Console のドメイン と紐付いているので、セキュリ ティのために、外部非公開にし ています。 OpenShift Console のドメイン は変更不可 / CNAME 不可のた め、WAFを設定できません。 App AWS Load Balancer Operator を使用する場合は、Application Pod 毎に専用の ALB がデプロイされます。 開発者 アプリ・ユーザー
22. Ingress Contrller を使用した NLB + ALB (WAF) 構成 AWS Cloud ROSA VPC AZ 1 AZ 2 AZ 3 NLB Internet Gateway private subnet private subnet private subnet NLB ROSA導入時に自動作成される default IngressController の NLB OpenShift Console のドメイン と紐付いているので、セキュリ ティのために、外部非公開にす る。 OpenShift Console のドメイン は変更不可 / CNAME 不可のた め、WAFを設定できない。 Adding a Private Ingress Controller and a Public ALB to a ROSA Cluster https://cloud.redhat.com/experts/rosa/private-ingress-controller- with-alb/ ALB AWS WAF ユーザーが手動で作製する ALB 追加で Deploy 可能な IngressController の NLB default の NLB と同じで ROSA(OpenShift) 上の複数のアプリケーシ ョンで共有が可能です。 ラベルを使って、default の IngressController と対象アプリを選択し ます。 作成には独自ドメインが必要です。 ROSA 標準の IngressController を使うため、複数のアプリケーシ ョンで、ALB と NLB を共有する事ができます。 開発者 アプリ・ユーザー
23. HTTP / TCP (non HTTP) アプリケーションの外部公開 – ROSA 標準の構成 CLB NAT Gateway Internet Gateway NLB (default) Service LoadBalancer Service LoadBalancer CLB tcp 9000 tcp 9001 HTTP App1 Pod HTTP App2 Pod Router Pod Route Route TCP(non HTTP) TCP(non HTTP) HTTP(S) namespace namespace namespace namespace opensfhit-ingress [4] [1] For HTTP(S) workload, the default NLB is shared among HTTP(S) applications. The incoming traffic is routed ro router pods whicht route the traffic to each pod based on HTTP host header. [2] CLB is deployed for each TCP(non HTTP) app. The CLB can’t be shared between different Pod applications. [3] With OpenShift, Router Pods posses pod ip addresses and use them to access Pods for better performance. [4] Two Router pods are deployed by default for redundancy [3] [2] [2] [1] Service LoadBalancer NodePort NodePort NodePort TCP App1 Pod Listen 9000 TCP App2 Pod Listen 9001 ClusterIP ClusterIP ClusterIP Service ClusterIP Service ClusterIP ROSA 標準の IngressController ROSA 標準では、”Service” Type=LoadBalancer に対して、 CLB が生成されます。
24. “AWS Load Balancer Operator” を使った HTTP(S)アプリケーション NAT Gateway Internet Gateway NLB (default) HTTP App Pod Router Pod Route HTTP(S) namespace opensfhit-ingress Service LoadBalancer NodePort ClusterIP Service ClusterIP ROSA 標準の NLB は、HTTP(S) ア プリケーション間で共用が可能です 。 ROSA 標準の IngressController を 使用した、HTTP(S) アプリケーショ ンは、Router Pod が Host ヘッダー を見て適切なアプリケーションにト ラフィックを ルーティングします。 AWS Load Balancer Operator を使う事で、ALBを使用したユーザーアプリケーションの公開が可能 ROSA 標準の IngressController HTTP App1 Pod Ingress namespace ALB HTTP(S) HTTP App2 Pod Ingress namespace HTTP(S) ALB NodePort NodePort Service NodePort Service NodePort ClusterIP ClusterIP AWS Load Balancer Operator を使 用して HTTPSアプリケーションをデ プロイした場合は、アプリケーショ ンに対して専用の ALB がデプロイさ れます。 “Service” type=LoadBalancer に annotation が必用です。
25. “AWS Load Balancer Operator” を使った TCPアプリケーション NLB NAT Gateway Internet Gateway NLB (default) Service LoadBalancer Service LoadBalancer NLB tcp 9000 tcp 9001 HTTP App1 Pod HTTP App2 Pod Router Pod Route Route TCP(non HTTP) TCP(non HTTP) HTTP(S) namespace namespace namespace namespace opensfhit-ingress [4] [1] HTTP(S) のアプリケーションには、default NLB が共通で使用されます。外部からのトラフィックは、router pod に送られ、HTTP Host ヘッダーを元に各アプリケーションにルートされます。 [2] TCP アプリケーション( 非HTTP) には、NLBがデプロイされます。一つの TCPアプリケーションに対して、一つのNLB がデプロイされます。アプリ間での共用はできません。 [3] OpenShift では、標準的な Kubernetes とは違い、Service 経由せずに直接 Pod のIPへトラフィックをルートします。これによって Peformace が向上すると言われています。 [4] Router Pod はデフォルトでは2つデプロイされています。 [3] [2] [2] [1] Service LoadBalancer NodePort NodePort NodePort TCP App1 Pod Listen 9000 TCP App2 Pod Listen 9001 ClusterIP ClusterIP ClusterIP Service ClusterIP Service ClusterIP ROSA default IngressController の NLB は、 HTTP(S)アプリケーション間で共用されます。 TCP アプリケーション用の NLB は、アプリケーション毎に専用 の NLB が使用されます。 TCP アプリケーション用の NLB は、アプリケーション毎に専用 の NLB が使用されます。 ROSA 標準の IngressController Router Pod が、Route の情報を元に トラフィックをルーティングします。
26. ネットワークは管理者が集中管理する(Shared VPC subnet ) ROSA Cluster Worker Nodes User AWS Account-A (Owner) User AWS Account-B (Participant) private subnet https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/install_rosa_with_hcp_clusters/rosa-hcp-shared-vpc-config AWS organization rosa create dns-domain rosa create oidc-config rosa create account-roles rosa create operator-roles rosa create cluster Resource Access Manager AWS Managed Policy VPC End Point Role Route53 Networkリソース は、Account A の AWS アカウ ントで、集中的に管理されます。 Network 関連の AWS Roles (AWS Account B の Role から AssumeRole を許可) ROSASharedVPCEndpointPolicy ROSASharedVPCRoute53Policy Route53 Role Installer Role Ingress Operator Cloud Credential Role ControlPlane Operator Cloud Credential Role AWS Managed Policy ROSA…..Policy ROSA…Policy ROSA…Policy VPC Endpoint Assume Role ROSA Cluster 作成関連の AWS Roles Network Resource の管理を、ROSA Cluster 作成用の AWS Account には渡さず、特定の AWS Account で一括管理したい 時に使用される構成です。 Resource Access Manager を使用して public network / private network を AWS Account B と共有 ROSA Cluster の Zone を作成
27. 基盤チームとCluster使用者で VPC分割する例 ROSA Cluster A Worker Nodes ROSA Service Account ( Red Hat SRE Managed ) User AWS Account-A User AWS Account-B ROSA Cluster A Hosted Controlplane AWS PrivateLink VPC Endpoint VPC Endpoint EC2 bastion B private subnet private subnet VPC Service Endpoint サポート用の踏み台 (oc コマンドの実行) private subnet EC2 bastion A https://docs.redhat.com/ja/documentation/red_hat_openshift_service_on_aws/4/html/install_rosa_with_hcp_clusters/rosa-additional-principals-overview_rosa-hcp-aws-private-creating-cluster 基盤チーム VPC (AWS Account –B) Cluster使用者 VPC (AWS Account –A) Red Hat SRE 管理 AWS Account (ユーザーからは不可視) 基盤チームは、Cluster の作成を、使用者の AWS Account に対して行う。クラスター作製後も、運用サポートとして ROSA Cluster の API にアクセスできるようにしておきたい。 クラスターを管理 Cluster の作成など は、AssumeRole にて行い、クラスタ ーを払い出す cluster 使用者は基本 的に、自力で運用を 行うが、必用に応じ て基盤チームのサポ ートを使用する。
28. 別の AWS Account から oc コマンドでクラスターを監視する例 ROSA Classic Cluster ROSA Classic Account 運用 AWS Account VPC Endpoint EC2 private subnet private subnet oc command で Cluster 監視 private subnet Red Hat SRE AWS Accont VPC Service Endpoint SRE PrivateLink 監視サーバー User Controlplane VPC Service Endpoint Red Hat SRE 管理 AWS Account ( ユーザーからは不可視) 監視製品が、oc コマンドを使用して Cluster を監視している。 oc コマンドは、監視サーバー上で実行され、かつ ROSA Cluster とは別の AWS Account に存在する。 Controlplane には、 PrivateLink 経由で アクセスできる
29. AWS Cloud プライベート・クラスター 疑似テスト環境例 Bastion VPC ROSA VPC NLB (Internal) NAT Gateway Transit Gateway Internet Gateway transit gateway subnet public subnet private subnet Browser terminal Bastion Server Amazon Route 53 疑似オンプレ環境 ROSA Cluster インストール用VPC ECR API Endpoint S3 endpoint ECR DKR Endpoint STS endpoint ROSA controlplane ROSA Cluster Internet (SSH portforward) ssh ssh 作業者 Private Cluster を作成し､テストしたい場合、プライベート・クラスターにアクセスするためのルートが必用になる。 踏み台サーバーを作成して、ssh の prtoforwarding で踏み台にアクセスする事ができる。
30. AWS Cloud プライベート・クラスター 疑似テスト環境例 Bastion VPC ROSA VPC NLB (Internal) Transit Gateway transit gateway subnet private subnet Browser terminal Bastion Server Amazon Route 53 疑似オンプレ環境 ROSA Cluster インストール用VPC 10.11.0.0/16 10.0.0.0/16 10.0.1.0/24 ECR API Endpoint S3 endpoint ECR DKR Endpoint STS endpoint ROSA controlplane ROSA Cluster Internet 作業者 AWS Client VPN Client VPN ENI AWS Client VPN Client Private Cluster を作成し､テストしたい場合、プライベート・クラスターにアクセスするためのルートが必用になる。 踏み台サーバーを作成して、AWS VPN を使用する事で、踏み台サーバーにアクセスする事ができる。
31. ROSA HCP Public Cluster IPアドレス要件例 (3AZ) /28 (16) ・全ての Subnet の IP アドレスの合計以上の VPC の IPアドレスのレンジが必要です。 ・各AWS Subnet は、5つの予約アドレスが必要になります。NAT Gateway は追加で IPアドレスを使用します。その他に Firewall 用の Subnet を VPC 内に設置するなど、要件によって必要なアドレス数は異なるため正確な最低要件は実際には環境依 存です。 /28 (16) /28 (16) /24 (256) /24 (256) /24 (256) public subnet private subnet private subnet private subnet NATGW public subnet NATGW public subnet NATGW Internet へのアウトバウンドのために必要 インターネットのアウトバウンドの経路が別にあ る（Transit Gateway経由など）のであれば、な くても良い。 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types AWS ではサブネットにつき、5つ のIPアドレスが予約される[1] ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) 一つの AZ は、167以 上(+5の AWS予約分) の IPレンジが必要。 prefix IPアドレス数 /20 4096 /21 2048 /22 1024 /23 512 /24 256 /25 128 /26 64 /27 32 /28 16 Private Subnet のアドレスレンジは、2026年4月現在でサポートされる最大数の 500 Compute Nodes を収用できる事を想定して設計して います。(Compute Node が少なければ、必要なアドレスを Compute Node 数に従って縮小する事も可能です。) VPCとして最低でも /22 (1024) が必要になる AZ1 AZ2 AZ3 ※/28 は AWSで作成できる最小 のサブネットです。
32. ROSA HCP Public Cluster IPアドレス最小要件 (3AZ) /28 (16) ・全ての Subnet の IP アドレスの合計以上の VPC の IPアドレスのレンジが必要です。 ・各AWS Subnet は、5つの予約アドレスが必要になります。NAT Gateway は追加で IPアドレスを使用します。その他に Firewall 用の Subnet を VPC 内に設置するなど、要件によって必要なアドレス数は異なるため正確な最低要件は実際には環境依存です。 /28 (16) /28 (16) /25 (128) /25 (128) /25 (128) public subnet private subnet private subnet private subnet NATGW public subnet NATGW public subnet NATGW Internet へのアウトバウンドのために必要 インターネットのアウトバウンドの経路が別にあ る（Transit Gateway経由など）のであれば、な くても良い。 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types [3] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/networking_overview/index#machine-cidr-description_cidr-range-definitions AWS ではサブネットにつき、5つ のIPアドレスが予約されます[1] ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 prefix IPアドレス数 /20 4096 /21 2048 /22 1024 /23 512 /24 256 /25 128 /26 64 /27 32 /28 16 ROSA最低要件 : Machine CIDR = /24 (256) [3] ※これ以下はインストーラーが動作しない 要件をクリアするために、/25 を各 AZ に割り当てる。 VPCとして最低でも /23 (512) が必要になる AZ1 AZ2 AZ3 ※/28 は AWSで作成できる最小 のサブネットです。
33. /25 (128) private subnet private subnet AZ1 AZ2 /25 (128) /28 (16) /28 (16) public subnet public subnet 2AZ 構成 private subnet AZ1 /25 (128) /28 (16) public subnet Single AZ 構成 VPCとして最低でも /23 (512) が必要になる ROSA最低要件 Machine CDIR = /24 (256) [3] ※これ以下はインストーラーが動作しない ROSA最低要件 Machine CIDR = /25(128) [3] Single AZ では最低要件が変わる VPCとして最低でも /24 (256) が必要になる ROSA HCP Public Clsuter IP アドレス最小要件 (2AZ / Single AZ) NATGW NATGW NATGW ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types [3] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/networking_overview/index#machine-cidr-description_cidr-range-definitions AWS ではサブネットにつき、5つ のIPアドレスが予約されます[1] AWS ではサブネットにつき、5つ のIPアドレスが予約されます[1]
34. 免責事項 • 内容については、実際の提案で使われたり検証されたものをベースに作成しています。 • チャートに全ての情報を載せる事ができないため、強調したい情報以外はやもをえず構成図から落としてい ます。複数の構成図を見比べる事で、詳細な部分まで理解が深まると思うので、お試し下さい。 • 製品の仕様や動きや予告なく変更になる事がありますので、あくまでこのドキュメント作成時点の情報であ るとご理解ください。例としてサポートされる Worker Node の最大数は、検証が進む度に増えていくので、 最大限必要な CIDR の大きさは変化している事があります。 • 内容には十分、注意しているつもりですが、もし間違い等を発見された場合は、yhanada@redhat.com ま でお知らせ下さい。 • ROSA + AWS の設計で頭を悩ませている方々の一助になれれば幸いです。
35. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat 35 Red Hat is the world’s leading provider of enterprise open source software solutions. Award- winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you