手動インストール用のエージェント・ベース・インストーラの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.yamlinstall-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_gatewayoci_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_balanceroci_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ロード・バランサで正しくオープンおよびルーティングされていることを確認します。

アプリケーション・ロード・バランサ

アプリケーション・イングレス・トラフィック(ユーザー・アプリケーション、OpenShift Webコンソールなど)に使用されます。パブリックまたはプライベートにできます。次の情報を使用して、アプリケーション・ロード・バランサを構成します。
ポート番号 バックエンド・マシン(プール・メンバー) 説明
80 イングレス・コントローラ・ポッドを実行しているノード(通常はコンピュート・ノードまたはワーカー・ノード) HTTPトラフィック
443 イングレス・コントローラ・ポッドを実行しているノード(通常はコンピュート・ノードまたはワーカー・ノード) HTTPSトラフィック
ノート

ネットワークおよびセキュリティの要件に応じて、ロード・バランサをパブリックまたはプライベートに構成できます。

DNSレコード

内部および外部のOpenShiftネットワーク・トラフィックをルーティングするためのDNSレコードを作成します。ネットワークおよびセキュリティの要件に応じて、パブリックDNSゾーン、プライベートDNSゾーン、またはその両方を作成します。プライベートDNSゾーンは、Oracleネットワーク(VCNなど)内でのみ解決できます。パブリックDNSゾーンは外部アクセスを有効にします。

ゾーンを作成したら、次のホスト名の 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レコード。

アプリケーション・イングレス・ロード・バランサは、イングレス・コントローラ・ポッドを実行するマシンをターゲットとします。イングレス・コントローラ・ポッドは、デフォルトでコンピュート・マシンで実行されます。

これらのレコードは、クラスタ外部のクライアント、およびクラスタ内のすべてのノードから解決できる必要があります。

たとえば、console-openshift-console.apps.<cluster_name>.<base_domain>は、OpenShiftコンテナ・プラットフォーム・コンソールへのワイルドカード・ルートとして使用されます。

定義されたタグ

すべてのコントロール・プレーンおよびコンピュート・ノードをグループ化および識別するには、定義済タグが必要です。

タグ付けサービスを使用して、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ソフトウェアを含むコンピュート・サービス・カスタム・イメージが必要です。このイメージを作成するには、次の手順を実行する必要があります:

  1. Red Hat Hybrid Cloud Consoleから入手可能なopenshift-installバイナリを使用して、検出ISOイメージをローカルに作成します。手順については、Creating configuration files for installing a cluster on OCI (Red Hat documentation) (Red Hat documentation)を参照してください。
  2. 検出ISOイメージをOCIオブジェクト・ストレージにアップロードします。手順については、オブジェクト・ストレージ・バケットの作成およびバケットへのオブジェクト・ストレージ・オブジェクトのアップロードを参照してください。
  3. 検出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を含めるように設定します。
URL ポート 機能
ghcr.io 443 Oracle Cloud Control Manager (CCM)およびContainer Storage Interface (CSI)のコンテナ・イメージを提供します。
registry.k8s.io 443 CCMおよびCSIのサポートするkubernetesコンテナ・イメージを提供します。