手動インストール用のエージェント・ベース・インストーラのOCIリソース
エージェントベースのインストーラを使用して、必要なOCIリソースを手動で作成し、OpenShift Container Platformクラスタをインストールします。
Terraformを使用してリソースをプロビジョニングする場合は、「Terraformを使用したエージェントベースのインストーラを使用したクラスタのインストール」の説明に従って、このトピックをスキップできます。
インフラストラクチャを構成するエージェントベースのインストーラ・ワークフローは、Red Hat Hybrid Cloud Consoleから始まります。ここでは、openshift-install
バイナリをダウンロードして、OCIでコンピュート・インスタンスをプロビジョニングするために必要な検出ISOイメージを作成します。バイナリをダウンロードするには、OpenShiftインストーラおよびCLIのダウンロード・ページを参照してください。
検出ISOイメージ(OCIでコンピュート・インスタンスをプロビジョニングするために使用)を生成する前に、OCIインフラストラクチャをプロビジョニングする必要があります。これには、OCIDs、VCN CIDR範囲、コントロール・プレーンとコンピュート・インスタンス数、およびagent-config.yaml
、install-config.yaml
およびopenshift/custom_manifest.yaml
エージェントベースのインストール・ファイルの作成に必要なその他の入力が含まれます。
イメージの生成後、OCIコンソールに切り替えて残りのインフラストラクチャをプロビジョニングし、クラスタ・デプロイメントを続行します。
エージェントベースのインストーラを使用する場合、「前提条件」トピックおよび次のインフラストラクチャ・コンポーネントで説明されているリソースが必要です。
- コンパートメント
- VCN
- ロード・バランサ
- ロード・バランサのDNSレコード
- クラスタのコンピュート・ノードのタグ・ネームスペースおよび定義済タグ
- クラスタのコンピュート・ノードのIAM動的グループ
- 動的グループのIAMポリシー
- OpenShift検出ISOイメージから作成された、コンピュート・インスタンス・プロビジョニングのカスタム・イメージ。
これらのリソースのほとんどは、検出ISOイメージを必要とするカスタム・コンピュート・イメージを除き、開始前に作成できます。
コンパートメント
コンパートメントを使用すると、クラウド・リソースを編成および分離できます。OpenShiftクラスタの新しいコンパートメントを作成することをお薦めします。詳細は、コンパートメントの作成を参照してください。
VCNおよびネットワーキング・リソース
OpenShiftコンピュート・ノード、ロード・バランサおよびその他のリソースは、OCI Virtual Cloud Network (VCN)を使用して接続します。VCNの作成手順は、VCNの作成を参照してください。
VCNおよび関連するネットワーキング・リソースをvirtual-network-family
集計リソース・タイプで管理するには、IAM権限が必要です。詳細は、リソースへのアクセスの管理を参照してください。ネットワーキングの権限については、「コア・サービス」の項で説明します。
オプションで、VCN内のネットワーク・セキュリティ・グループ(NSG)を使用してアクセスを制御できます。NSGを使用したネットワーク・トラフィックおよびアクセスの制御の詳細は、ネットワーク・セキュリティ・グループを参照してください。NSGは、他のOpenShfitインフラストラクチャ・リソースと同じコンパートメントにある必要があることに注意してください。
VCNおよびサブネットの構成の詳細は、GitHubのOCIのOpenShiftのTerraform定義済リソースのページを参照してください。特定のリソース定義については、shared_modulesディレクトリ内の関連フォルダにアクセスし、oci_core_vcn,
oci_core_internet_gateway
、oci_core_nat_gateway
、 oci_core_route_table
、 oci_core_subnet
およびoci_core_network_security_group
リソースを検索します。
ロード・バランサ
Red Hat OpenShiftクラスタには、2つのロード・バランサ(内部ネットワーク・トラフィック用と外部トラフィック用)が必要です。手順については、ロード・バランサの作成を参照してください。ロード・バランサ構成の概要は、GitHubのOCIのOpenShiftのTerraform定義済リソースのページを参照してください。特定のリソース定義については、shared_modulesディレクトリ内の関連フォルダにアクセスし、oci_load_balancer_load_balancer
、oci_load_balancer_backend_set
およびoci_load_balancer_listener
リソースを検索します。
内部Load Balancer
ポート | バックエンド・マシン(プール・メンバー) | Description |
---|---|---|
6443 | ブートストラップおよびコントロール・プレーン | Kubernetes APIサーバー |
22623 | ブートストラップおよびコントロール・プレーン | マシン構成サーバー |
22624 | ブートストラップおよびコントロール・プレーン | マシン構成サーバー |
APIロード・バランサ
Kubernetes APIサーバー・トラフィックに使用されます。パブリックまたはプライベートにできます。APIロード・バランサを構成するには、次の情報を使用します
ポート | バックエンド・マシン(プール・メンバー) | 説明 |
---|---|---|
6443 | ブートストラップ・ノードおよびコントロール・プレーン・ノード | Kubernetes APIサーバー・トラフィック(HTTPS) |
22624 | ブートストラップ・ノードおよびコントロール・プレーン・ノード | クラスタへの参加時にイグニッション構成をダウンロードするためにワーカー・ノードで使用されます。 |
新しいワーカー・ノードをクラスタに追加するには、ポート22624が必要です。外部(内部ではない) APIロード・バランサで正しくオープンおよびルーティングされていることを確認します。
アプリケーション・ロード・バランサ
ポート番号 | バックエンド・マシン(プール・メンバー) | 説明 |
---|---|---|
80 | イングレス・コントローラ・ポッドを実行しているノード(通常はコンピュート・ノードまたはワーカー・ノード) | HTTPトラフィック |
443 | イングレス・コントローラ・ポッドを実行しているノード(通常はコンピュート・ノードまたはワーカー・ノード) | HTTPSトラフィック |
ネットワークおよびセキュリティの要件に応じて、ロード・バランサをパブリックまたはプライベートに構成できます。
DNSレコード
内部および外部のOpenShiftネットワーク・トラフィックをルーティングするためのDNSレコードを作成します。ネットワークおよびセキュリティの要件に応じて、パブリックDNSゾーン、プライベートDNSゾーン、またはその両方を作成します。プライベートDNSゾーンは、Oracleネットワーク(VCNなど)内でのみ解決できます。パブリックDNSゾーンは外部アクセスを有効にします。
api.<cluster_name>.<base_domain>
api-int.<cluster_name>.<base_domain>
*.apps.<cluster_name>.<base_domain>
各DNSレコードは、同じパブリック・ロード・バランサIDとプライベート・ロード・バランサIDを参照する必要があります。
DNSゾーンの作成および管理の手順は、ゾーンを参照してください。
DNS構成の詳細は、GitHubの「OCI上のOpenShiftのTerraform定義リソース」ページを参照してください。特定のリソース定義については、shared_modulesディレクトリ内の関連フォルダにアクセスし、oci_dns_zone
およびoci_dns_rrset
リソースを検索します。
コンポーネント | 記録 | ロード・バランサ | 摘要 |
---|---|---|---|
Kubernetes API | api.<cluster_name>.<base_domain>. |
APIロード・バランサIPの使用 |
APIロード・バランサを識別するDNS A/AAAAまたはCNAMEレコードおよびDNS PTRレコード。 これらのレコードは、クラスタ外部のクライアント、およびクラスタ内のすべてのノードから解決できる必要があります。 |
Kubernetes API | api-int.<cluster_name>.<base_domain>. |
内部ロード・バランサIPの使用 |
APIロード・バランサを内部的に識別するためのDNS A/AAAAまたはCNAMEレコードおよびDNS PTRレコード。 これらのレコードは、クラスタ内のすべてのノードから解決できる必要があります。 |
アプリケーション・イングレス | *.apps.<cluster_name>.<base_domain>. |
アプリケーション・ロード・バランサIPの使用 |
アプリケーション・イングレス・ロード・バランサを参照するワイルドカードDNS A/AAAAまたはCNAMEレコード。 アプリケーション・イングレス・ロード・バランサは、イングレス・コントローラ・ポッドを実行するマシンをターゲットとします。イングレス・コントローラ・ポッドは、デフォルトでコンピュート・マシンで実行されます。 これらのレコードは、クラスタ外部のクライアント、およびクラスタ内のすべてのノードから解決できる必要があります。 たとえば、 |
定義されたタグ
すべてのコントロール・プレーンおよびコンピュート・ノードをグループ化および識別するには、定義済タグが必要です。
タグ付けサービスを使用して、2つのタグ・ネームスペースを作成し、OpenShiftクラスタの作成に使用するコンパートメントで必要なタグを定義します:
- タグ・ネームスペース:
openshift-tags
およびopenshift-{cluster_name}
- 定義済タグ名および値:
-
openshift-tags
の場合:openshift-resource
openshift-{cluster_name}
の場合:instance-role
:control_plane
またはcompute
(ノード・タイプによって異なります)boot-volume-type
:PARAVIRTUALIZED
またはISCSI
これらのタグは、プロビジョニング時にすべての関連リソースに適用する必要があります。詳細は、リソース属性タグを参照してください。
詳細は、タグおよびタグ・ネームスペースの概念を参照してください。
OCI上のOpenShiftに関する詳細な手順については、GitHubの「OCI上のOpenShiftのTerraform定義リソース」ページを参照してください。特定のリソース定義については、shared_modulesディレクトリ内の関連フォルダにアクセスし、oci_identity_tag_namespace
およびoci_identity_tag
リソースを検索します。
動的グループ
動的グループを使用すると、IAMポリシーを介してアクセス権を付与するために、Oracle Cloud Infrastructure (OCI)コンピュート・インスタンスを(ユーザー・グループと同様に)プリンシパル・アクターとしてグループ化できます。
これらの動的グループを参照するIAMポリシー(次の項を参照)を作成して、OCIリソースへのアクセスを制御できます。手順は、動的グループの管理を参照してください。動的グループ構成の詳細は、GitHubの「OCI上のOpenShiftのTerraform定義リソース」ページを参照してください。特定のリソース定義については、shared_modulesディレクトリの関連フォルダにアクセスし、次のリソースを検索します: oci_identity_dynamic_group
。
- 動的グループ名:
${var.cluster_name}_control_plane_nodes
- コンパートメント: クラスタ・コンパートメント
- 一致ルール:
all { instance.compartment.id = "${var.compartment_ocid}", tag.${var.op_openshift_tag_namespace}.${var.op_openshift_tag_instance_role}.value = "control_plane" }
動的グループ・ポリシー
OpenShiftコントロール・プレーン動的グループがクラスタの作成時にOCIリソースにアクセスおよび管理するには、3つのIAMポリシーが必要です。これらのIAMポリシーは、master
動的グループに必要です。手順については、動的グループの管理およびIAMポリシーの概要を参照してください。動的グループ・ポリシー構成の詳細は、GitHubの「OCI上のOpenShiftのTerraform定義リソース」ページを参照してください。特定のリソース定義については、shared_modulesディレクトリの関連フォルダにアクセスし、次のリソースを検索します: oci_identity_policy
。
- コントロール・プレーン・リソース・アクセス・ポリシー:このポリシーにより、コントロール・プレーン・ノーズはコア・インフラストラクチャ・リソースを管理できます。コントロール・プレーン・ノードの動的グループの名前は
${var.cluster_name}_control_plane_nodes
です- ポリシー名:
${var.cluster_name}_control_plane_nodes
- コンパートメント:クラスタ・コンパートメント
- ポリシー・ステートメント:
Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to manage volume-family in compartment id ${var.compartment_ocid} Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to manage instance-family in compartment id ${var.compartment_ocid} Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to manage security-lists in compartment id ${var.compartment_ocid} Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to use virtual-network-family in compartment id ${var.compartment_ocid} Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to manage load-balancers in compartment id ${var.compartment_ocid} Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to manage objects in compartment id ${var.compartment_ocid}
- ポリシー名:
- クラスタ・リソースのタグ付けアクセス・ポリシー:このポリシーは、
openshift-tags
ネームスペースを使用してクラスタ・リソースをタグ付けするためのコントロール・プレーン・ノードへのアクセス権を付与します。- ポリシー名: $
{var.cluster_name}_control_plane_nodes_tags
- コンパートメント: ルート・コンパートメント
- ポリシー・ステートメント:
Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to use tag-namespaces in tenancy
- ポリシー名: $
- (オプション)ネットワーキング・アクセス・ポリシー: このポリシーは、ネットワーキング・コンポーネントがクラスタ・インスタンスとは異なるコンパートメントにある場合にのみ必要です。
-
ポリシー名:
${var.cluster_name}_control_plane_nodes_networking_access_policy
- コンパートメント: ネットワーキング・コンパートメント
- ポリシー・ステートメント:
Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to manage security-lists in compartment id ${var.networking_compartment_ocid} Allow dynamic-group ${oci_identity_dynamic_group.openshift_control_plane_nodes.name} to manage virtual-network-family in compartment id ${var.networking_compartment_ocid}
-
OpenShiftコンテナ・プラットフォーム・インスタンスのカスタム・イメージ
エージェントベースのインストーラを使用してOpenShiftコンテナ・プラットフォームのクラスタ・ノードを作成するには、クラスタ・ノードの実行に必要なRed Hatソフトウェアを含むコンピュート・サービス・カスタム・イメージが必要です。このイメージを作成するには、次の手順を実行する必要があります:
- Red Hat Hybrid Cloud Consoleから入手可能な
openshift-install
バイナリを使用して、検出ISOイメージをローカルに作成します。手順については、Creating configuration files for installing a cluster on OCI (Red Hat documentation) (Red Hat documentation)を参照してください。 - 検出ISOイメージをOCIオブジェクト・ストレージにアップロードします。手順については、オブジェクト・ストレージ・バケットの作成およびバケットへのオブジェクト・ストレージ・オブジェクトのアップロードを参照してください。
- 検出ISOに基づいてコンピュート・サービスにカスタム・イメージを作成します。手順については、カスタム・イメージの管理を参照してください。
カスタム・イメージを作成する場合は、イメージに対してこのオプションが有効になっていないようにBIOS機能をクリアする必要があります。詳細は、「カスタム・イメージの管理」ドキュメントの「カスタム・イメージのイメージ機能の構成」を参照してください。
エージェント構成ファイル
エージェントベースのインストーラでは、検出ISOイメージを生成するためにエージェントベースのインストーラを使用できるように、編集する必要がある2つの構成ファイルが必要です。これらは、agent-config.yaml
およびinstall-config.yaml
ファイルです。詳細は、OCIにクラスタをインストールするための構成ファイルの作成(Red Hatのドキュメント)を参照してください。
agent-config.yaml
およびinstall-config.yaml
ファイルを作成した後、ローカルに保存します。ローカル・ディレクトリ構造は次のとおりです。
.
└── local_machine_work_directory/
├── agent-config.yaml
├── install-config.yaml
└── openshift /
├── manifest.yml
ファイアウォール構成
OpenShift Container Platformで必要なサイトへのアクセス権を付与するようにファイアウォールが構成されていることを確認します。OpenShiftコンテナ・プラットフォームに対するファイアウォールの許可リストの設定の詳細は、OpenShiftコンテナ・プラットフォーム用のファイアウォールの構成(Red Hatのドキュメント)を参照してください。
URL | ポート | 機能 |
---|---|---|
ghcr.io | 443 | Oracle Cloud Control Manager (CCM)およびContainer Storage Interface (CSI)のコンテナ・イメージを提供します。 |
registry.k8s.io | 443 | CCMおよびCSIのサポートするkubernetesコンテナ・イメージを提供します。 |