サポートコンソール開発者トライアルの開始お問い合わせ

OpenStack へのインストール

OpenShift Container Platform 4.12

OpenStack への OpenShift Container Platform のインストールする

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenStack に OpenShift Container Platform をインストールする方法を説明します。

第1章 OpenStack へのインストールの準備

Red Hat OpenStack Platform (RHOSP) に OpenShift Container Platform をインストールできます。

1.1. 前提条件

1.2. OpenStack に OpenShift Container Platform をインストールする方法の選択

OpenShift Container Platform をインストーラーまたは user-provisioned infrastructure にインストールすることができます。デフォルトのインストールタイプは、installer-provisioned infrastructure を使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform は、ユーザーがプロビジョニングするインスラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。

installer-provisioned installation および user-provisioned installation のプロセスの詳細は、インストールプロセス を参照してください。

1.2.1. installer-provisioned infrastructure へのクラスターのインストール

以下の方法のいずれかを使用して、OpenShift Container Platform インストールプログラムでプロビジョニングされる Red Hat OpenStack Platform (RHOSP) インフラストラクチャーに、クラスターをインストールできます。

  • カスタマイズによる OpenStack へのクラスターのインストール: カスタマイズされたクラスターを RHOSP にインストールできます。インストールプログラムは、インストールの段階で一部のカスタマイズを適用できるようにします。その他の多くのカスタマイズオプションは、インストール後 に利用できます。
  • Kuryr を使用した OpenStack へのクラスターのインストール: Kuryr SDN を使用する RHOSP にカスタマイズされた OpenShift Container Platform クラスターをインストールできます。Kuryr と OpenShift Container Platform の統合は主に、RHOSP の仮想マシンで実行する OpenShift Container Platform クラスター用に設計されました。Kuryr は、OpenShift Container Platform Pod を RHOSP SDN にプラグインしてネットワークのパフォーマンスを強化します。さらに、これは Pod と RHOSP 仮想インスタンス間の接続を可能にします。
  • ネットワークが制限された環境での OpenStack へのクラスターのインストール: インストールリリースコンテンツの内部ミラーを作成して、OpenShift Container Platform をネットワークが制限された環境またはネットワークの非接続環境で RHOSP にインストールできます。この方法を使用して、ソフトウェアコンポーネントを取得するためにアクティブなインターネット接続を必要としないクラスターをインストールできます。また、このインストール方法を使用して、クラスターが外部コンテンツに対する組織の制御の条件を満たすコンテナーイメージのみを使用するようにすることもできます。

1.2.2. user-provisioned infrastructure へのクラスターのインストール

以下の方法のいずれかを使用して、独自にプロビジョニングする RHOSP インフラストラクチャーにクラスターをインストールできます。

1.3. RHOSP エンドポイントをスキャンしてレガシー HTTPS 証明書を探す

OpenShift Container Platform 4.10 以降、HTTPS 証明書にはサブジェクト代替名 (SAN) フィールドが含まれている必要があります。次のスクリプトを実行して、Red Hat OpenStack Platform (RHOSP) カタログ内の各 HTTPS エンドポイントをスキャンし、CommonName フィールドのみを含むレガシー証明書を探します。

重要

OpenShift Container Platform は、インストールまたは更新の前に、基盤となる RHOSP インフラストラクチャーのレガシー証明書をチェックしません。提供されているスクリプトを使用して、これらの証明書をご自身で確認してください。クラスターをインストールまたは更新する前にレガシー証明書を更新しないと、クラスターが機能しなくなります。

前提条件

手順

  1. 次のスクリプトをマシンに保存します。 

    #!/usr/bin/env bash

set -Eeuo pipefail

declare catalog san
catalog="$(mktemp)"
san="$(mktemp)"
readonly catalog san

declare invalid=0

openstack catalog list --format json --column Name --column Endpoints \
	| jq -r '.[] | .Name as $name | .Endpoints[] | select(.interface=="public") | [$name, .interface, .url] | join(" ")' \
	| sort \
	> "$catalog"

while read -r name interface url; do
	# Ignore HTTP
	if [[ ${url#"http://"} != "$url" ]]; then
		continue
	fi

	# Remove the schema from the URL
	noschema=${url#"https://"}

	# If the schema was not HTTPS, error
	if [[ "$noschema" == "$url" ]]; then
		echo "ERROR (unknown schema): $name $interface $url"
		exit 2
	fi

	# Remove the path and only keep host and port
	noschema="${noschema%%/*}"
	host="${noschema%%:*}"
	port="${noschema##*:}"

	# Add the port if was implicit
	if [[ "$port" == "$host" ]]; then
		port='443'
	fi

	# Get the SAN fields
	openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null \
		| openssl x509 -noout -ext subjectAltName \
		> "$san"

	# openssl returns the empty string if no SAN is found.
	# If a SAN is found, openssl is expected to return something like:
	#
	#    X509v3 Subject Alternative Name:
	#        DNS:standalone, DNS:osp1, IP Address:192.168.2.1, IP Address:10.254.1.2
	if [[ "$(grep -c "Subject Alternative Name" "$san" || true)" -gt 0 ]]; then
		echo "PASS: $name $interface $url"
	else
		invalid=$((invalid+1))
		echo "INVALID: $name $interface $url"
	fi
done < "$catalog"

# clean up temporary files
rm "$catalog" "$san"

if [[ $invalid -gt 0 ]]; then
	echo "${invalid} legacy certificates were detected. Update your certificates to include a SAN field."
	exit 1
else
	echo "All HTTPS certificates for this cloud are valid."
fi
  2. スクリプトを実行します。
  3. スクリプトが INVALID と報告する証明書を、SAN フィールドを含む証明書に置き換えます。
重要

OpenShift Container Platform 4.10 をインストールする前、またはクラスターをそのバージョンに更新する前に、すべてのレガシー HTTPS 証明書を置き換える必要があります。レガシー証明書は、次のメッセージで拒否されます。 

x509: certificate relies on legacy Common Name field, use SANs instead

1.3.1. RHOSP エンドポイントをスキャンしてレガシー HTTPS 証明書を手動で探す

OpenShift Container Platform 4.10 以降、HTTPS 証明書にはサブジェクト代替名 (SAN) フィールドが含まれている必要があります。「レガシー HTTPS 証明書の RHOSP エンドポイントのスキャン」にリストされている前提条件ツールにアクセスできない場合は、次の手順を実行して、Red Hat OpenStack Platform (RHOSP) カタログ内の各 HTTPS エンドポイントをスキャンして、CommonName フィールドのみを含むレガシー証明書の RHOSP カタログで各 HTTPS エンドポイントをスキャンします。

重要

OpenShift Container Platform は、インストールまたは更新の前に、基盤となる RHOSP インフラストラクチャーのレガシー証明書をチェックしません。これらの証明書を自分で確認するには、次の手順を使用します。クラスターをインストールまたは更新する前にレガシー証明書を更新しないと、クラスターが機能しなくなります。

手順

  1. コマンドラインで次のコマンドを実行して、RHOSP パブリックエンドポイントの URL を表示します。 

    $ openstack catalog list

    コマンドが返す各 HTTPS エンドポイントの URL を記録します。

  2. 各パブリックエンドポイントについて、ホストとポートをメモします。

    ヒント

    スキーム、ポート、およびパスを削除して、エンドポイントのホストを決定します。

  3. エンドポイントごとに次のコマンドを実行して、証明書の SAN フィールドを抽出します。

    1. host 変数を設定します。 

      $ host=<host_name>

    2. port 変数を設定します。 

      $ port=<port_number>

      エンドポイントの URL にポートがない場合は、値 443 を使用します。

    3. 証明書の SAN フィールドを取得します。 

      $ openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null \
    | openssl x509 -noout -ext subjectAltName

      出力例

      X509v3 Subject Alternative Name:
    DNS:your.host.example.net

      各エンドポイントについて、前の例に似た出力を探します。エンドポイントの出力がない場合、そのエンドポイントの証明書は無効であるため、再発行する必要があります。

重要

OpenShift Container Platform 4.10 をインストールする前、またはクラスターをそのバージョンに更新する前に、すべてのレガシー HTTPS 証明書を置き換える必要があります。従来の証明書は拒否され、次のメッセージが表示されます。 

x509: certificate relies on legacy Common Name field, use SANs instead

第2章 Preparing to install a cluster that uses SR-IOV or OVS-DPDK on OpenStack

Single Root I/O Virtualization (SR-IOV) または Open vSwitch を使用する OpenShift Container Platform クラスターを Red Hat OpenStack Platform (RHOSP) に Data Plane Development Kit (OVS-DPDK) とともにインストールする前に、テクノロジーごとの要件を理解し、準備タスクを実行する必要があります。

2.1. SR-IOV または OVS-DPDK のいずれかを使用する RHOSP 上のクラスターの要件

デプロイメントで SR-IOV または OVS-DPDK を使用する場合は、次の要件を満たす必要があります。

  • RHOSP コンピュートノードは、Huge Page をサポートするフレーバーを使用する必要があります。

2.1.1. SR-IOV を使用する RHOSP 上のクラスターの要件

デプロイメントで Single Root I/O Virtualization (SR-IOV) を使用するには、次の要件を満たす必要があります。

  • Red Hat OpenStack Platform (RHOSP) SR-IOV デプロイメントを計画します。
  • OpenShift Container Platform は、使用する NIC をサポートする必要があります。サポートされている NIC のリストについては、「ネットワーキング」ドキュメントの「ハードウェアネットワーク」サブセクションにある「Single Root I/O Virtualization (SR-IOV) ハードウェアネットワークについて」を参照してください。

  • SR-IOV NIC がアタッチされるノードごとに、RHOSP クラスターに以下が必要です。

    • RHOSP クォータからの 1 インスタンス
    • マシンのサブネットにアタッチされた 1 つのポート
    • SR-IOV 仮想機能ごとに 1 つのポート
    • 少なくとも 16 GB のメモリー、4 つの vCPU および 25 GB のストレージ領域があるフレーバー

  • SR-IOV デプロイメントでは、多くの場合、専用の CPU や分離された CPU などのパフォーマンスの最適化が駆使されます。パフォーマンスを最大化するには、基礎となる RHOSP デプロイメントをこれらの最適化機能を使用するように設定してから、OpenShift Container Platform コンピュートマシンを最適化されたインフラストラクチャーで実行するように設定します。

2.1.2. OVS-DPDK を使用する RHOSP 上のクラスターの要件

デプロイメントで、Open vSwitch を Data Plane Development Kit (OVS-DPDK) とともに使用するには、以下の要件を満たす必要があります。

2.2. SR-IOV を使用するクラスターのインストールの準備

SR-IOV を使用するクラスターをインストールする前に、RHOSP を設定する必要があります。

2.2.1. コンピュートマシン用の SR-IOV ネットワークの作成

Red Hat OpenStack Platform (RHOSP) デプロイメントで Single Root I/O Virtualization (SR-IOV) をサポートする場合、コンピュートマシンを実行する SR-IOV ネットワークをプロビジョニングすることができます。

注記

以下の手順では、コンピュートマシンへの接続が可能な外部のフラットネットワークおよび外部の VLAN ベースのネットワークを作成します。RHOSP のデプロイメントによっては、ネットワークの他のタイプが必要になる場合があります。

前提条件

  • クラスターは SR-IOV をサポートしている。

    注記

    クラスターがサポートするかどうかが不明な場合は、OpenShift Container Platform SR-IOV ハードウェアネットワークに関するドキュメントを参照してください。

  • RHOSP デプロイメントの一部として、無線とアップリンクのプロバイダーネットワークを作成している。これらのネットワークを表すために radio および uplink の名前がすべてのコマンド例で使用されています。

手順

  1. コマンドラインで、無線の RHOSP ネットワークを作成します。 

    $ openstack network create radio --provider-physical-network radio --provider-network-type flat --external

  2. アップリンクの RHOSP ネットワークを作成します。 

    $ openstack network create uplink --provider-physical-network uplink --provider-network-type vlan --external

  3. 無線ネットワーク用のサブネットを作成します。 

    $ openstack subnet create --network radio --subnet-range <radio_network_subnet_range> radio

  4. アップリンクネットワーク用のサブネットを作成します。 

    $ openstack subnet create --network uplink --subnet-range <uplink_network_subnet_range> uplink

2.3. OVS-DPDK を使用するクラスターのインストールの準備

SR-IOV を使用するクラスターをインストールする前に、RHOSP を設定する必要があります。

インストール前のタスクを実行したら、最も関連性の高い OpenShift Container Platform on RHOSP のインストール手順に従ってクラスターをインストールします。次に、このページの「次のステップ」の下にあるタスクを実行します。

2.4. 次のステップ

第3章 カスタマイズによる OpenStack へのクラスターのインストール

OpenShift Container Platform バージョン 4.12 では、Red Hat OpenStack Platform (RHOSP) にカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に install-config.yaml でパラメーターを変更します。

3.1. 前提条件

3.2. OpenShift Container Platform を RHOSP にインストールするリソースのガイドライン

OpenShift Container Platform のインストールをサポートするために、Red Hat OpenStack Platform (RHOSP) クォータは以下の要件を満たす必要があります。

表3.1 RHOSP のデフォルトの OpenShift Container Platform クラスターに関する推奨リソース
リソース値

Floating IP アドレス

3

ポート

15

ルーター

1

サブネット

1

RAM

88 GB

vCPU

22

ボリュームストレージ

275 GB

インスタンス

7

セキュリティーグループ

3

セキュリティーグループルール

60

サーバーグループ

2 - 各マシンプールの追加のアベイラビリティーゾーンごとに 1 つ追加

クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。

重要

RHOSP オブジェクトストレージ (Swift) が利用可能で、swiftoperator ロールを持つユーザーアカウントによって操作されている場合、これは OpenShift Container Platform イメージレジストリーのデフォルトバックエンドとして使用されます。この場合、ボリュームストレージ要件は 175 GB です。Swift 領域要件は、イメージレジストリーのサイズによって異なります。

注記

デフォルトで、セキュリティーグループおよびセキュリティーグループルールのクォータは低く設定される可能性があります。問題が生じた場合には、管理者として openstack quota set --secgroups 3 --secgroup-rules 60 <project> を実行して値を増やします。

OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで構成されます。

3.2.1. コントロールプレーンマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコントロールプレーンマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

3.2.2. コンピュートマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコンピューティングマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 8 GB のメモリーと 2 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量
ヒント

コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。

3.2.3. ブートストラップマシン

インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。

ブートストラップマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

3.3. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

3.4. RHOSP での Swift の有効化

Swift は、swiftoperator ロールのあるユーザーアカウントによって操作されます。インストールプログラムを実行する前に、ロールをアカウントに追加します。

重要

Swift として知られる Red Hat OpenStack Platform (RHOSP) オブジェクトストレージサービス が利用可能な場合、OpenShift Container Platform はこれをイメージレジストリーストレージとして使用します。利用できない場合、インストールプログラムは Cinder として知られる RHOSP ブロックストレージサービスに依存します。

Swift が存在し、これを使用する必要がある場合は、Swift へのアクセスを有効にする必要があります。これが存在しない場合や使用する必要がない場合は、このセクションを省略してください。

重要

RHOSP 17 では、Ceph RGW の rgw_max_attr_size パラメーターが 256 文字に設定されます。この設定は、コンテナーイメージを OpenShift Container Platform レジストリーにアップロードする際に問題を引き起こします。rgw_max_attr_size の値は、1024 文字以上に設定する必要があります。

インストールする前に、RHOSP のデプロイメントがこの問題の影響を受けるかどうか確認してください。影響を受ける場合は、Ceph RGW を再設定します。

前提条件

  • ターゲット環境に RHOSP 管理者アカウントがあります。
  • Swift サービスがインストールされています。
  • Ceph RGW で、account in url オプションが有効化されています。

手順

RHOSP 上で Swift を有効にするには、以下を実行します。

  1. RHOSP CLI の管理者として、swiftoperator ロールを Swift にアクセスするアカウントに追加します。 

    $ openstack role add --user <user> --project <project> swiftoperator

RHOSP デプロイメントでは、イメージレジストリーに Swift を使用することができます。

3.5. RHOSP で実行されるクラスター上のカスタムストレージを使用したイメージレジストリーの設定

Red Hat OpenStack Platform (RHOSP) にクラスターをインストールした後に、特定のアベイラビリティーゾーンにある Cinder ボリュームをレジストリーストレージとして使用できます。

手順

  1. YAML ファイルを作成して、使用するストレージクラスとアベイラビリティーゾーンを指定します。以下に例を示します。 

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: custom-csi-storageclass
provisioner: cinder.csi.openstack.org
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  availability: <availability_zone_name>
    注記

    OpenShift Container Platform では、選択したアベイラビリティーゾーンが存在するかどうかは確認されません。設定を適用する前に、アベイラビリティーゾーンの名前を確認してください。

  2. コマンドラインから設定を適用します。 

    $ oc apply -f <storage_class_file_name>

    出力例

    storageclass.storage.k8s.io/custom-csi-storageclass created

  3. ストレージクラスと openshift-image-registry namespace を使用する永続ボリュームクレーム (PVC) を指定する YAML ファイルを作成します。以下に例を示します。 

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pvc-imageregistry
  namespace: openshift-image-registry 1
  annotations:
    imageregistry.openshift.io: "true"
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 100Gi 2
  storageClassName: <your_custom_storage_class> 3
    1
    openshift-image-registry namespace を入力します。この namespace により、クラスターイメージレジストリーオペレーターは PVC を使用できます。
    2
    オプション: ボリュームサイズを調整します。
    3
    作成されるストレージクラスの名前を入力します。

  4. コマンドラインから設定を適用します。 

    $ oc apply -f <pvc_file_name>

    出力例

    persistentvolumeclaim/csi-pvc-imageregistry created

  5. イメージレジストリー設定の元の永続ボリューム要求は、新しい要求に置き換えます。 

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --type 'json' -p='[{"op": "replace", "path": "/spec/storage/pvc/claim", "value": "csi-pvc-imageregistry"}]'

    出力例

    config.imageregistry.operator.openshift.io/cluster patched

    数分すると、設定が更新されます。

検証

レジストリーが定義したリソースを使用していることを確認するには、以下を実行します。

  1. PVC クレーム値が PVC 定義で指定した名前と同じであることを確認します。 

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

    出力例

    ...
status:
    ...
    managementState: Managed
    pvc:
      claim: csi-pvc-imageregistry
...

  2. PVC のステータスが Bound であることを確認します。 

    $ oc get pvc -n openshift-image-registry csi-pvc-imageregistry

    出力例

    NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS             AGE
csi-pvc-imageregistry  Bound    pvc-72a8f9c9-f462-11e8-b6b6-fa163e18b7b5   100Gi      RWO            custom-csi-storageclass  11m

3.6. 外部ネットワークアクセスの確認

OpenShift Container Platform インストールプロセスでは、外部ネットワークへのアクセスが必要です。外部ネットワーク値をこれに指定する必要があります。指定しない場合には、デプロイメントは失敗します。このプロセスを実行する前に、外部ルータータイプのネットワークが Red Hat OpenStack Platform (RHOSP) に存在することを確認します。

前提条件

手順

  1. RHOSP CLI を使用して、'External' ネットワークの名前と ID を確認します。 

    $ openstack network list --long -c ID -c Name -c "Router Type"

    出力例

    +--------------------------------------+----------------+-------------+
| ID                                   | Name           | Router Type |
+--------------------------------------+----------------+-------------+
| 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
+--------------------------------------+----------------+-------------+

外部ルータータイプのあるネットワークがネットワークリストに表示されます。1 つ以上のネットワークが表示されない場合は、デフォルトの Floating IP ネットワークの作成 および デフォルトのプロバイダーネットワークの作成 を参照してください。

重要

外部ネットワークの CIDR 範囲がデフォルトのネットワーク範囲のいずれかと重複している場合、インストールプロセスを開始する前に、install-config.yaml ファイルで一致するネットワーク範囲を変更する必要があります。

デフォルトのネットワーク範囲は以下のとおりです。

ネットワーク範囲

machineNetwork

10.0.0.0/16

serviceNetwork

172.30.0.0/16

clusterNetwork

10.128.0.0/14

警告

インストールプログラムにより同じ名前を持つ複数のネットワークが見つかる場合、それらのネットワークのいずれかがランダムに設定されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。

注記

Neutron トランクサービスプラグインが有効にされると、トランクポートがデフォルトで作成されます。詳細は、Neutron trunk port を参照してください。

3.7. インストールプログラムのパラメーターの定義

OpenShift Container Platform インストールプログラムは、clouds.yaml というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。

手順

  1. clouds.yaml ファイルを作成します。

    • RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに clouds.yaml ファイルを生成します。

      重要

      パスワードを必ず auth フィールドに追加してください。シークレットは、clouds.yaml の 別のファイル に保持できます。

    • RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。clouds.yaml の詳細は、RHOSP ドキュメントの Config files を参照してください。 

      clouds:
  shiftstack:
    auth:
      auth_url: http://10.10.14.42:5000/v3
      project_name: shiftstack
      username: <username>
      password: <password>
      user_domain_name: Default
      project_domain_name: Default
  dev-env:
    region_name: RegionOne
    auth:
      username: <username>
      password: <password>
      project_name: 'devonly'
      auth_url: 'https://10.10.14.22:5001/v2.0'

  2. RHOSP インストールでエンドポイント認証用に自己署名認証局 (CA) を使用する場合、以下を実行します。

    1. 認証局ファイルをマシンにコピーします。

    2. cacerts キーを clouds.yaml ファイルに追加します。この値は、CA 証明書への絶対的な root 以外によるアクセスが可能なパスである必要があります。 

      clouds:
  shiftstack:
    ...
    cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"
      ヒント

      カスタム CA 証明書を使用してインストーラーを実行した後に、cloud-provider-config キーマップの ca-cert.pem キーの値を編集して証明書を更新できます。コマンドラインで、以下を実行します。 

      $ oc edit configmap -n openshift-config cloud-provider-config

  3. clouds.yaml ファイルを以下の場所のいずれかに置きます。

    1. OS_CLIENT_CONFIG_FILE 環境変数の値
    2. 現行ディレクトリー
    3. Unix 固有のユーザー設定ディレクトリー (例: ~/.config/openstack/clouds.yaml)

    4. Unix 固有のサイト設定ディレクトリー (例: /etc/openstack/clouds.yaml)

      インストールプログラムはこの順序で clouds.yaml を検索します。

3.8. OpenStack Cloud Controller Manager のオプション設定

オプションで、クラスターの OpenStack Cloud Controller Manager (CCM) 設定を編集できます。この設定は、OpenShift Container Platform が Red Hat OpenStack Platform (RHOSP) と対話する方法を制御します。

設定パラメーターの完全なリストは、「OpenStack のインストール」ドキュメントの「OpenStack Cloud Controller Manager リファレンスガイド」を参照してください。

手順

  1. クラスター用に生成されたマニフェストファイルがない場合は、以下のコマンドを実行して生成します。 

    $ openshift-install --dir <destination_directory> create manifests

  2. テキストエディターで、cloud-provider 設定マニフェストファイルを開きます。以下に例を示します。 

    $ vi openshift/manifests/cloud-provider-config.yaml

  3. CCM リファレンスガイド に従ってオプションを変更します。

    負荷分散を Octavia に設定することは、Kuryr を使用しないクラスターでは一般的なケースです。以下に例を示します。 

    #...
[LoadBalancer]
use-octavia=true 1
lb-provider = "amphora" 2
floating-network-id="d3deb660-4190-40a3-91f1-37326fe6ec4a" 3
create-monitor = True 4
monitor-delay = 10s 5
monitor-timeout = 10s 6
monitor-max-retries = 1 7
#...
    1
    このプロパティーにより、Octavia の統合が有効になっています。
    2
    このプロパティーは、ロードバランサーが使用する Octavia プロバイダーを設定します。"ovn" または "amphora" を値として受け入れます。OVN の使用を選択する場合は、lb-method を SOURCE_IP_PORT。
    3
    このプロパティーは、複数の外部ネットワークをクラスターで使用する場合に必要です。クラウドプロバイダーは、ここで指定するネットワーク上に Floating IP アドレスを作成します。
    4
    このプロパティーは、クラウドプロバイダーが Octavia ロードバランサーのヘルスモニターを作成するかどうかを制御します。ヘルスモニターを作成するには、値を True に設定します。RHOSP 16.2 の時点で、この機能は Amphora プロバイダーでのみ利用できます。
    5
    このプロパティーは、監視されるエンドポイントの頻度を設定します。値は time.ParseDuration（） 形式である必要があります。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    6
    このプロパティーは、タイムアウトする前に監視要求が開く時間を設定します。値は time.ParseDuration（） 形式である必要があります。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    7
    このプロパティーは、ロードバランサーがオンラインとしてマークされる前に必要なモニタリング要求の数を定義します。値は整数でなければなりません。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    重要

    変更を保存する前に、ファイルが正しく構造化されていることを確認します。プロパティーが適切なセクションに置かれていないと、クラスターが失敗することがあります。

    重要

    .spec.externalTrafficPolicy プロパティーの値が Local に設定されたサービスを使用する場合は、create-monitor プロパティーの値を True に設定する必要があります。RHOSP 16.2 の OVN Octavia プロバイダーは、ヘルスモニターをサポートしません。そのため、lb-provider の値が "ovn" に設定されている場合、ETP パラメーターの値が Local に設定されたサービスは応答しない可能性があります。

    重要

    Kuryr を使用するインストールの場合、Kuryr は関連サービスを処理します。クラウドプロバイダーで Octavia の負荷分散を設定する必要はありません。

  4. 変更をファイルに保存し、インストールを続行します。

    ヒント

    インストーラーの実行後に、クラウドプロバイダー設定を更新できます。コマンドラインで、以下を実行します。 

    $ oc edit configmap -n openshift-config cloud-provider-config

    変更を保存した後、クラスターの再設定には多少時間がかかります。ノードが SchedulingDisabled のままの場合は、プロセスが完了します。

3.9. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。

  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

3.10. インストール設定ファイルの作成

Red Hat OpenStack Platform (RHOSP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
  • サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。 

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして openstack を選択します。
      3. クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
      4. OpenShift API への外部アクセスに使用する floating IP アドレスを指定します。
      5. コントロールプレーンノードに使用する少なくとも 16 GB の RAM とコンピュートノードに使用する 8 GB の RAM を持つ RHOSP フレーバーを指定します。
      6. クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
      7. クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
      8. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

関連情報

使用可能なパラメーターの詳細は、インストール設定パラメーター セクション を参照してください。

3.10.1. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。

  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。 

    apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port> 1
  httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
  noProxy: example.com 3
additionalTrustBundle: | 4
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
    5
    オプション： trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。
    注記

    インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

    注記

    インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。 

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

3.11. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

3.11.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表3.2 必須パラメーター
パラメーター説明値

apiVersion

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain と <metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata.name

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。文字列は 14 文字以上でなければなりません。

platform

インストールを実行する特定のプラットフォームの設定: alibabacloud、aws、baremetal、azure、gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}。platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

3.11.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

表3.3 ネットワークパラメーター
パラメーター説明値

networking

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking.networkType

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、全 Linux ネットワーク用の CNI プラグインです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNkubernetes です。

networking.clusterNetwork

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23

networking.clusterNetwork.cidr

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking.clusterNetwork.hostPrefix

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix が 23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking.serviceNetwork

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 

networking:
  serviceNetwork:
   - 172.30.0.0/16

networking.machineNetwork

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16

networking.machineNetwork.cidr

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

3.11.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表3.4 オプションのパラメーター
パラメーター説明値

additionalTrustBundle

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は None、v4.11、v4.12、vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

compute

コンピュートノードを設定するマシンの設定。

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute.hyperthreading

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute.name

compute を使用する場合に必須です。マシンプールの名前。

worker

compute.platform

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

compute.replicas

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane

コントロールプレーンを設定するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane.hyperthreading

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane.name

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane.platform

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

controlPlane.replicas

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを Mint、Passthrough または Manual に設定する必要があります。

Mint、Passthrough、Manual、または空の文字列 ("")。

fips

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、x86_64、ppc64le、および s390x アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources.source

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources.mirrors

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

3.11.4. 追加の Red Hat OpenStack Platform (RHOSP) 設定パラメーター

追加の RHOSP 設定パラメーターは以下の表で説明されています。

表3.5 追加の RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.rootVolume.size

コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

compute.platform.openstack.rootVolume.type

コンピュートマシンの場合、root のボリュームタイプです。

文字列 (例: performance)。

controlPlane.platform.openstack.rootVolume.size

コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

controlPlane.platform.openstack.rootVolume.type

コントロールプレーンマシンの場合、root ボリュームのタイプです。

文字列 (例: performance)。

platform.openstack.cloud

clouds.yaml ファイルのクラウドリストにある使用する RHOCP クラウドの名前。

文字列 (例: MyCloud)。

platform.openstack.externalNetwork

インストールに使用される RHOSP の外部ネットワーク名。

文字列 (例: external)。

platform.openstack.computeFlavor

コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。

このプロパティーは非推奨にされています。すべてのマシンプールのデフォルトとしてフレーバーを使用するには、これを platform.openstack.defaultMachinePlatform プロパティーで type キーの値として追加します。それぞれのマシンプールのフレーバー値を個別に設定することもできます。

文字列 (例: m1.xlarge)。

3.11.5. オプションの RHOSP 設定パラメーター

オプションの RHOSP 設定パラメーターは、以下の表で説明されています。

表3.6 オプションの RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.additionalNetworkIDs

コンピュートマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

compute.platform.openstack.additionalSecurityGroupIDs

コンピュートマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

compute.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

compute.platform.openstack.rootVolume.zones

コンピュートマシンの root ボリュームをインストールするアベイラビリティーゾーン。このパラメーターに値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列のリスト (例: ["zone-1", "zone-2"])。

compute.platform.openstack.serverGroupPolicy

プール内のコンピュートマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

controlPlane.platform.openstack.additionalNetworkIDs

コントロールプレーンマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

コントロールプレーンマシンに接続されている追加のネットワークも、ブートストラップノードに接続されています。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

controlPlane.platform.openstack.additionalSecurityGroupIDs

コントロールプレーンマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

controlPlane.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.rootVolume.zones

コントロールプレーンマシンの root ボリュームをインストールするアベイラビリティーゾーン。この値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列の一覧 (例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.serverGroupPolicy

プール内のコントロールプレーンマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

platform.openstack.clusterOSImage

インストールプログラムが RHCOS イメージをダウンロードする場所。

ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。

HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。

例: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d。この値は、既存の Glance イメージの名前にもなり得ます (例: my-rhcos)。

platform.openstack.clusterOSImageProperties

Glance のインストーラーでアップロードされた ClusterOSImage に追加するプロパティー。このプロパティーは、platform.openstack.clusterOSImage が既存の Glance イメージに設定されている場合は無視されます。

このプロパティーを使用し、ノードあたり 26 PV の RHOSP のデフォルト永続ボリューム (PV) の制限を超過することができます。制限を超えるには、hw_scsi_model プロパティーの値を virtio-scsi に設定し、hw_disk_bus の値を scsi に設定します。

このプロパティーを使用し、hw_qemu_guest_agent プロパティーを yes の値で追加して QEMU ゲストエージェントを有効にすることもできます。

キーと値の文字列のペアのリスト。例: ["hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi"]

platform.openstack.defaultMachinePlatform

デフォルトのマシンプールプラットフォームの設定。 

{
   "type": "ml.large",
   "rootVolume": {
      "size": 30,
      "type": "performance"
   }
}

platform.openstack.ingressFloatingIP

Ingress ポートに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.apiFloatingIP

API ロードバランサーに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.externalDNS

クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。

文字列としての IP アドレスのリスト。例: ["8.8.8.8", "192.168.1.12"]

platform.openstack.machinesSubnet

クラスターのノードが使用する RHOSP サブネットの UUID。ノードおよび仮想 IP (VIP) ポートがこのサブネットに作成されます。

networking.machineNetwork の最初の項目は machinesSubnet の値に一致する必要があります。

カスタムサブネットにデプロイする場合、OpenShift Container Platform インストーラーに外部 DNS サーバーを指定することはできません。代わりに、DNS を RHOSP のサブネットに追加 します。

文字列としての UUID。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

3.11.6. RHOSP デプロイメントでのカスタムサブネット

オプションで、選択する Red Hat OpenStack Platform (RHOSP) サブネットにクラスターをデプロイすることができます。サブネットの GUID は、install-config.yaml ファイルの platform.openstack.machinesSubnet の値として渡されます。

このサブネットはクラスターのプライマリーサブネットとして使用されます。デフォルトで、ノードおよびポートはこの上に作成されます。platform.openstack.machinesSubnet プロパティーの値をサブネットの UUID に設定すると、異なる RHOSP サブネットにノードおよびポートを作成することができます。

カスタムサブネットを使用して OpenShift Container Platform インストーラーを実行する前に、設定が以下の要件を満たしていることを確認してください。

  • platform.openstack.machinesSubnet で使用されるサブネットで DHCP が有効にされている。
  • platform.openstack.machinesSubnet の CIDR は networking.machineNetwork の CIDR に一致する。
  • インストールプログラムのユーザーには、固定 IP アドレスを持つポートなど、このネットワークでポートを作成するパーミッションがある。

カスタムサブネットを使用するクラスターには、以下の制限があります。

  • Floating IP アドレスを使用するクラスターをインストールする予定の場合には、platform.openstack.machinesSubnet サブネットを externalNetwork ネットワークに接続されているルーターに接続する必要があります。
  • platform.openstack.machinesSubnet の値が install-config.yaml ファイルに設定されている場合、インストールプログラムは RHOSP マシンのプライベートネットワークまたはサブネットを作成しません。
  • platform.openstack.externalDNS プロパティーは、カスタムサブネットと同時に使用することはできません。カスタムサブネットを使用するクラスターに DNS を追加するには、RHOSP ネットワークで DNS を設定します。
注記

デフォルトでは、API VIP は x.x.x.5 を取得し、Ingress VIP はネットワークの CIDR ブロックから x.x.x.7 を取得します。これらのデフォルト値を上書きするには、DHCP 割り当てプール外の platform.openstack.apiVIPs および platform.openstack.ingressVIPs の値を設定します。

重要

ネットワークの CIDR 範囲は、クラスターのインストール後に調整できません。Red Hat は、namespace ごとに作成される Pod の数を慎重に検討する必要があるため、クラスターのインストール時に範囲を決定するための直接的なガイダンスを提供していません。

3.11.7. ベアメタルマシンを使用したクラスターのデプロイ

クラスターでベアメタルマシンを使用する必要がある場合は、install-config.yaml ファイルを変更します。クラスターには、ベアメタル上でコントロールプレーンとコンピュートマシンの両方を実行させることも、コンピュートマシンのみを実行させることもできます。

ベアメタルコンピュートマシンは、Kuryr を使用するクラスターではサポートされません。

注記

install-config.yaml ファイルで、ベアメタルワーカーに使用する RHOSP ネットワークが Floating IP アドレスをサポートするかどうかが反映されていることを確認します。

前提条件

  • RHOSP Bare Metal サービス (Ironic) が有効になっており、RHOSP Compute API 経由でアクセスできる。
  • ベアメタルを RHOSP フレーバー として利用できる。
  • クラスターが 16.1.6 以降、16.2.4 未満の RHOSP バージョンで実行している場合は、メタデータサービスが OpenShift Container Platform ノード上のサービスで使用できなくなる 既知の問題 により、ベアメタルワーカーは機能しません。
  • RHOSP ネットワークが、仮想マシンとベアメタルサーバーの両方の接続をサポートしている。
  • 既存のネットワークにマシンをデプロイする場合、RHOSP サブネットがプロビジョニングされている。
  • インストーラーによってプロビジョニングされるネットワークにマシンをデプロイする場合、RHOSP Bare Metal サービス (Ironic) が、テナントネットワークで実行される Preboot eXecution Environment (PXE) ブートマシンをリッスンして通信することができる。
  • OpenShift Container Platform インストールプロセスの一環として、install-config.yaml ファイルを作成した。

手順

  1. install-config.yaml ファイルで、マシンのフレーバーを編集します。

    1. ベアメタルのコントロールプレーンマシンを使用する必要がある場合は、controlPlane.platform.openstack.type の値をベアメタルフレーバーに変更します。
    2. compute.platform.openstack.type の値をベアメタルフレーバーに変更します。

    3. 既存のネットワークにマシンをデプロイする場合は、platform.openstack.machinesSubnet の値をネットワークの RHOSP サブネット UUID に変更します。コントロールプレーンおよびコンピュートマシンは同じサブネットを使用する必要があります。

      ベアメタルの install-config.yaml のサンプルファイル

      controlPlane:
    platform:
      openstack:
        type: <bare_metal_control_plane_flavor> 1
...

compute:
  - architecture: amd64
    hyperthreading: Enabled
    name: worker
    platform:
      openstack:
        type: <bare_metal_compute_flavor> 2
    replicas: 3
...

platform:
    openstack:
      machinesSubnet: <subnet_UUID> 3
...

      1
      ベアメタルのコントロールプレーンマシンを使用する必要がある場合は、この値をベアメタルのフレーバーに変更します。
      2
      この値を、コンピュートマシンに使用するベアメタルのフレーバーに変更します。
      3
      既存のネットワークを使用する必要がある場合は、この値を RHOSP サブネットの UUID に変更します。

更新された install-config.yaml ファイルを使用してインストールプロセスを完了します。デプロイメント時に作成されるコンピュートマシンは、ファイルに追加したフレーバーを使用します。

注記

インストーラーは、ベアメタルマシンの起動中にタイムアウトする可能性があります。

インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。 

$ ./openshift-install wait-for install-complete --log-level debug

3.11.8. RHOSP プロバイダーネットワーク上のクラスターデプロイメント

プロバイダーネットワーク上のプライマリーネットワークインターフェイスを使用して、OpenShift Container Platform クラスターを Red Hat OpenStack Platform (RHOSP) にデプロイできます。プロバイダーネットワークは一般的に、インターネットへの到達に使用可能なパブリックネットワークに、プロジェクトが直接アクセスできるように使用します。ネットワーク作成プロセスの一環として、プロバイダーネットワークをプロジェクト間で共有することもできます。

RHOSP プロバイダーネットワークは、データセンター内の既存の物理ネットワークに直接マップします。RHOSP 管理者はこれらを作成する必要があります。

以下の例では、OpenShift Container Platform ワークロードはプロバイダーネットワークを使用してデータセンターに接続されます。

OpenStack 上の 4 つの OpenShift ワークロードを示す図。各ワークロードは、プロバイダーネットワークを使用して、NIC によって外部のデータセンターに接続されます。

プロバイダーネットワークにインストールされている OpenShift Container Platform クラスターは、テナントネットワークまたは Floating IP アドレスを必要としません。インストーラーは、インストール中にこれらのリソースを作成しません。

プロバイダーネットワークタイプの例には、フラット (タグなし) および VLAN (802.1Q タグ付き) が含まれます。

注記

クラスターは、ネットワークタイプが許可する限り多くのプロバイダーネットワーク接続をサポートできます。たとえば、VLAN ネットワークは、通常最大 4096 の接続をサポートします。

プロバイダーネットワークおよびテナントネットワークの詳細は、RHOSP のドキュメント を参照してください。

3.11.8.1. クラスターのインストールにおける RHOSP プロバイダーネットワーク要件

OpenShift Container Platform クラスターをインストールする前に、Red Hat OpenStack Platform (RHOSP) のデプロイメントおよびプロバイダーネットワークは、さまざまな条件を満たす必要があります。

  • RHOSP ネットワークサービス (Neutron) が有効化され、RHOSP ネットワーク API 経由でアクセス可能であること。
  • RHOSP ネットワークサービスでは、ポートセキュリティーと許可するアドレスペアの機能拡張が有効化 されていること。

  • プロバイダーネットワークは他のテナントと共有できます。

    ヒント

    --share フラグを指定して openstack network create コマンドを使用して、共有できるネットワークを作成します。

  • クラスターのインストールに使用する RHOSP プロジェクトは、プロバイダーネットワークと適切なサブネットを所有する必要があります。

    ヒント
    "openshift" という名前のプロジェクトのネットワークを作成するには、以下のコマンドを入力します。
    $ openstack network create --project openshift
    "openshift" という名前のプロジェクトのサブネットを作成するには、以下のコマンドを入力します。
    $ openstack subnet create --project openshift

    RHOSP でのネットワークの作成に関する詳細は、プロバイダーネットワークに関するドキュメント を参照してください。

    クラスターが admin ユーザーによって所有されている場合、そのユーザーとしてインストーラーを実行してネットワーク上でポートを作成する必要があります。

    重要

    プロバイダーネットワークは、クラスターの作成に使用される RHOSP プロジェクトによって所有されている必要があります。所有されていない場合は、RHOSP Compute サービス (Nova) はそのネットワークからポートを要求できません。

  • プロバイダーネットワークが、デフォルトで 169.254.169.254 である RHOSP メタデータサービスの IP アドレスに到達できることを確認します。

    RHOSP SDN とネットワークサービス設定によっては、サブネットを作成する際に、ルートを提供しなければならない場合があります。以下に例を示します。 

    $ openstack subnet create --dhcp --host-route destination=169.254.169.254/32,gateway=192.0.2.2 ...
  • オプション: ネットワークのセキュリティーを保護するには、単一のプロジェクトへのネットワークアクセスを制限する ロールベースのアクセス制御 (RBAC) ルールを作成します。
3.11.8.2. プロバイダーネットワークにプライマリーインターフェイスを持つクラスターのデプロイ

Red Hat OpenStack Platform (RHOSP) プロバイダーネットワーク上にプライマリーネットワークインターフェイスを持つ OpenShift Container Platform クラスターをデプロイすることができます。

前提条件

  • 「クラスターのインストールにおける RHOSP プロバイダーネットワーク要件」に記載されているとおりに、お使いの Red Hat OpenStack Platform (RHOSP) のデプロイメントが設定されています。

手順

  1. テキストエディターで install-config.yaml ファイルを開きます。
  2. platform.openstack.apiVIPs プロパティーの値を API VIP の IP アドレスに設定します。
  3. platform.openstack.ingressVIPs プロパティーの値を Ingress VIP の IP アドレスに設定します。
  4. platform.openstack.machinesSubnet プロパティーの値をプロバイダーネットワークサブネットの UUID に設定します。
  5. networking.machineNetwork.cidr プロパティーの値をプロバイダーネットワークサブネットの CIDR ブロックに設定します。
重要

platform.openstack.apiVIPs プロパティーおよび platform.openstack.ingressVIPs プロパティーはいずれも、networking.machineNetwork.cidr ブロックから割り当てられていない IP アドレスである必要があります。

RHOSP プロバイダーネットワークに依存するクラスターのインストール設定ファイルのセクション

        ...
        platform:
          openstack:
            apiVIPs: 1
              - 192.0.2.13
            ingressVIPs: 2
              - 192.0.2.23
            machinesSubnet: fa806b2f-ac49-4bce-b9db-124bc64209bf
            # ...
        networking:
          machineNetwork:
          - cidr: 192.0.2.0/24

1 2
OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。
警告

プライマリーネットワークインターフェイスにプロバイダーネットワークを使用している間は、platform.openstack.externalNetwork パラメーターまたは platform.openstack.externalDNS パラメーターを設定することはできません。

クラスターをデプロイする際に、インストーラーは install-config.yaml ファイルを使用してプロバイダーネットワークにクラスターをデプロイします。

ヒント

プロバイダーネットワークを含むネットワークを platform.openstack.additionalNetworkIDs リストに追加できます。

クラスターのデプロイ後に、Pod を追加のネットワークに接続することができます。詳細は、複数ネットワークについて を参照してください。

3.11.9. RHOSP のカスタマイズされた install-config.yaml ファイルのサンプル

このサンプル install-config.yaml は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。

重要

このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得する必要があります。 

apiVersion: v1
baseDomain: example.com
controlPlane:
  name: master
  platform: {}
  replicas: 3
compute:
- name: worker
  platform:
    openstack:
      type: ml.large
  replicas: 3
metadata:
  name: example
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
platform:
  openstack:
    cloud: mycloud
    externalNetwork: external
    computeFlavor: m1.xlarge
    apiFloatingIP: 128.0.0.1
fips: false
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

3.12. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64、ppc64le、および s390x アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。 

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。 

    $ cat ~/.ssh/id_ed25519.pub

  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。 

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。 

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

3.13. 環境へのアクセスの有効化

デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。

インストール時に Floating IP アドレス (FIP) を使用して OpenShift Container Platform API およびアプリケーションのアクセスを設定できます。FIP を設定せずにインストールを完了することもできますが、インストーラーは API またはアプリケーションを外部からアクセスする方法を設定しません。

3.13.1. floating IP アドレスを使用したアクセスの有効化

OpenShift Container Platform API およびクラスターアプリケーションへの外部アクセス用に Floating IP (FIP) アドレスを作成します。

手順

  1. Red Hat OpenStack Platform (RHOSP) CLI を使用して、API FIP を作成します。 

    $ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>

  2. Red Hat OpenStack Platform (RHOSP) CLI を使用して、apps (アプリ)、または Ingress、FIP を作成します。 

    $ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>

  3. API および Ingress FIP の DNS サーバーに、これらのパターンに準拠するレコードを追加します。 

    api.<cluster_name>.<base_domain>.  IN  A  <API_FIP>
*.apps.<cluster_name>.<base_domain>. IN  A <apps_FIP>
    注記

    DNS サーバーを制御していない場合は、次のようなクラスタードメイン名を /etc/hosts ファイルに追加することで、クラスターにアクセスできます。

    • <api_floating_ip> api.<cluster_name>.<base_domain>
    • <application_floating_ip> grafana-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> oauth-openshift.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
    • application_floating_ip integrated-oauth-server-openshift-authentication.apps.<cluster_name>.<base_domain>

    /etc/hosts ファイル内のクラスタードメイン名により、クラスターの Web コンソールおよび監視インターフェイスへのローカルアクセスが許可されます。kubectl または oc を使用することもできます。<application_floating_ip> を指す追加のエントリーを使用して、ユーザーアプリケーションにアクセスできます。このアクションにより、API およびアプリケーションは他のユーザーがアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

  4. FIP を、以下のパラメーターの値として install-config.yaml ファイルに追加します。

    • platform.openstack.ingressFloatingIP
    • platform.openstack.apiFloatingIP

これらの値を使用する場合には、install-config.yaml ファイルの platform.openstack.externalNetwork パラメーターの値として外部ネットワークを入力する必要もあります。

ヒント

Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。

3.13.2. Floating IP アドレスなしでのインストールの完了

Floating IP アドレスを指定せずに OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールすることができます。

install-config.yaml ファイルで以下のパラメーターを定義しないでください。

  • platform.openstack.ingressFloatingIP
  • platform.openstack.apiFloatingIP

外部ネットワークを提供できない場合は、platform.openstack.externalNetwork を空白のままにすることもできます。platform.openstack.externalNetwork の値を指定しない場合はルーターが作成されず、追加のアクションがない場合は、インストーラーは Glance からのイメージの取得に失敗します。外部接続を独自に設定する必要があります。

Floating IP アドレスまたは名前解決がないために、クラスター API に到達できないシステムからインストーラーを実行すると、インストールに失敗します。このような場合にインストールが失敗するのを防ぐために、プロキシーネットワークを使用するか、マシンと同じネットワークにあるシステムからインストーラーを実行できます。

注記

API および Ingress ポートの DNS レコードを作成して、名前解決を有効にできます。以下に例を示します。 

api.<cluster_name>.<base_domain>.  IN  A  <api_port_IP>
*.apps.<cluster_name>.<base_domain>. IN  A <ingress_port_IP>

DNS サーバーを制御しない場合は、/etc/hosts ファイルにレコードを追加できます。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

3.14. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。 

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
    --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

3.15. クラスターステータスの確認

インストール時またはインストール後に OpenShift Container Platform クラスターのステータスを確認することができます。

手順

  1. クラスター環境で、管理者の kubeconfig ファイルをエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。

  2. デプロイメント後に作成されたコントロールプレーンおよびコンピュートマシンを表示します。 

    $ oc get nodes

  3. クラスターのバージョンを表示します。 

    $ oc get clusterversion

  4. Operator のステータスを表示します。 

    $ oc get clusteroperator

  5. クラスター内のすべての実行中の Pod を表示します。 

    $ oc get pods -A

3.16. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。 

    $ oc whoami

    出力例

    system:admin

関連情報

3.17. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

3.18. 次のステップ

第4章 Kuryr を使用する OpenStack へのクラスターのインストール

重要

Kuryr は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、または削除された主な機能の最新の一覧については、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

OpenShift Container Platform バージョン 4.12 では、Kuryr SDN を使用する Red Hat OpenStack Platform (RHOSP) にカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に install-config.yaml でパラメーターを変更します。

4.1. 前提条件

4.2. Kuryr SDN について

重要

Kuryr は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧については、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

Kuryr は、Neutron および Octavia Red Hat OpenStack Platform (RHOSP) サービスを使用して Pod およびサービスのネットワークを提供する Container Network Interface (CNI) プラグインです。

Kuryr と OpenShift Container Platform の統合は主に、RHOSP の仮想マシンで実行する OpenShift Container Platform クラスター用に設計されました。Kuryr は、OpenShift Container Platform Pod を RHOSP SDN にプラグインしてネットワークのパフォーマンスを強化します。さらに、これは Pod と RHOSP 仮想インスタンス間の接続を可能にします。

Kuryr コンポーネントは openshift-kuryr namespace を使用して OpenShift Container Platform の Pod としてインストールされます。

  • kuryr-controller: master ノードにインストールされる単一のサービスインスタンスです。これは、OpenShift Container Platform で Deployment としてモデリングされます。
  • kuryr-cni: 各 OpenShift Container Platform ノードで Kuryr を CNI ドライバーとしてインストールし、設定するコンテナーです。これは、OpenShift Container Platform で DaemonSet オブジェクトとしてモデリングされます。

Kuryr コントローラーは OpenShift Container Platform API サーバーで Pod、サービスおよび namespace の作成、更新、および削除イベントについて監視します。これは、OpenShift Container Platform API 呼び出しを Neutron および Octavia の対応するオブジェクトにマップします。そのため、Neutron トランクポート機能を実装するすべてのネットワークソリューションを使用して、Kuryr 経由で OpenShift Container Platform をサポートすることができます。これには、Open vSwitch (OVS) および Open Virtual Network (OVN) などのオープンソースソリューションや Neutron と互換性のある市販の SDN が含まれます。

Kuryr は、カプセル化された RHOSP テナントネットワーク上の OpenShift Container Platform デプロイメントに使用することが推奨されています。これは、 RHOSP ネットワークでカプセル化された OpenShift Container Platform SDN を実行するなど、二重のカプセル化を防ぐために必要です。

プロバイダーネットワークまたはテナント VLAN を使用する場合は、二重のカプセル化を防ぐために Kuryr を使用する必要はありません。パフォーマンス上の利点はそれほど多くありません。ただし、設定によっては、Kuryr を使用して 2 つのオーバーレイが使用されないようにすることには利点がある場合があります。

Kuryr は、以下のすべての基準が true であるデプロイメントでは推奨されません。

  • RHOSP のバージョンが 16 よりも前のバージョンである。
  • デプロイメントで UDP サービスが使用されているか、少数のハイパーバイザーで多数の TCP サービスが使用されている。

または、以下を実行します。

  • ovn-octavia Octavia ドライバーが無効にされている。
  • デプロイメントで、少数のハイパーバイザーで多数の TCP サービスが使用されている。

4.3. Kuryr を使用して OpenShift Container Platform を RHOSP にインストールするためのリソースのガイドライン

Kuryr SDN を使用する場合、Pod、サービス、namespace およびネットワークポリシーは RHOSP クォータのリソースを使用します。これにより、最小要件が増加します。また、Kuryr にはデフォルトインストールに必要な要件以外の追加要件があります。

以下のクォータを使用してデフォルトのクラスターの最小要件を満たすようにします。

表4.1 Kuryr を使用する RHOSP のデフォルト OpenShift Container Platform クラスターについての推奨リソース
リソース値

Floating IP アドレス

3: LoadBalancer タイプに予想されるサービス数

ポート

1500: Pod ごとに 1 つ必要

ルーター

1

サブネット

250: namespace/プロジェクトごとに 1 つ必要

ネットワーク

250: namespace/プロジェクトごとに 1 つ必要

RAM

112 GB

vCPU

28

ボリュームストレージ

275 GB

インスタンス

7

セキュリティーグループ

250: サービスおよび NetworkPolicy ごとに 1 つ必要

セキュリティーグループルール

1000

サーバーグループ

2 - 各マシンプールの追加のアベイラビリティーゾーンごとに 1 つ追加

ロードバランサー

100: サービスごとに 1 つ必要

ロードバランサーリスナー

500: サービスで公開されるポートごとに 1 つ必要

ロードバランサーノード

500: サービスで公開されるポートごとに 1 つ必要

クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。

重要

RHOSP オブジェクトストレージ (Swift) が利用可能で、swiftoperator ロールを持つユーザーアカウントによって操作されている場合、これは OpenShift Container Platform イメージレジストリーのデフォルトバックエンドとして使用されます。この場合、ボリュームストレージ要件は 175 GB です。Swift 領域要件は、イメージレジストリーのサイズによって異なります。

重要

OVN Octavia ドライバーではなく Amphora ドライバーで Red Hat OpenStack Platform(RHOSP) バージョン 16 を使用している場合、セキュリティーグループはユーザープロジェクトではなくサービスアカウントに関連付けられます。

リソースを設定する際には、以下の点に注意してください。

  • 必要なポート数は Pod 数よりも大きくなる。Kuryr はポートプールを使用して、事前に作成済みのポートを Pod で使用できるようにし、Pod の起動時間を短縮します。
  • 各ネットワークポリシーは RHOSP セキュリティーグループにマップされ、NetworkPolicy 仕様によっては 1 つ以上のルールがセキュリティーグループに追加される。

  • 各サービスは RHOSP ロードバランサーにマップされる。クォータに必要なセキュリティーグループの数を見積もる場合には、この要件を考慮してください。

    RHOSP バージョン 15 以前のバージョン、または ovn-octavia driver を使用している場合、各ロードバランサーにはユーザープロジェクトと共にセキュリティーグループがあります。

  • クォータはロードバランサーのリソース (VM リソースなど) を考慮しませんが、RHOSP デプロイメントのサイズを決定する際にはこれらのリソースを考慮する必要があります。デフォルトのインストールには 50 を超えるロードバランサーが あり、クラスターはそれらのロードバランサーに対応できる必要があります。

    OVN Octavia ドライバーを有効にして RHOSP バージョン 16 を使用している場合は、1 つのロードバランサー仮想マシンのみが生成され、サービスは OVN フロー経由で負荷分散されます。

OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで設定されます。

Kuryr SDN を有効にするには、使用する環境が以下の要件を満たしている必要があります。

  • RHOSP 13+ を実行します。
  • オーバークラウドと Octavia を使用します。
  • Neutron トランクポートの拡張を使用します。
  • ML2/OVS Neutron ドライバーが ovs-hybrid の代わりに使用れる場合、openvswitch ファイアウォールドライバーを使用します。

4.3.1. クォータの拡大

Kuryr SDN を使用する場合、Pod、サービス、namespace、およびネットワークポリシーが使用する Red Hat OpenStack Platform (RHOSP) リソースに対応するためにクォータを引き上げる必要があります。

手順

  • 以下のコマンドを実行して、プロジェクトのクォータを増やします。 

    $ sudo openstack quota set --secgroups 250 --secgroup-rules 1000 --ports 1500 --subnets 250 --networks 250 <project>

4.3.2. Neutron の設定

Kuryr CNI は Neutron トランクの拡張を使用してコンテナーを Red Hat OpenStack Platform (RHOSP) SDN にプラグインします。したがって、Kuryr が適切に機能するには trunks 拡張を使用する必要があります。

さらにデフォルトの ML2/OVS Neutron ドライバーを使用する場合には、セキュリティーグループがトランクサブポートで実行され、Kuryr がネットワークポリシーを適切に処理できるように、ovs_hybrid ではなく openvswitch に設定される必要があります。

4.3.3. Octavia の設定

Kuryr SDN は Red Hat OpenStack Platform (RHOSP) の Octavia LBaaS を使用して OpenShift Container Platform サービスを実装します。したがって、Kuryr SDN を使用するように RHOSP に Octavia コンポーネントをインストールし、設定する必要があります。

Octavia を有効にするには、Octavia サービスを RHOSP オーバークラウドのインストール時に組み込むか、オーバークラウドがすでに存在する場合は Octavia サービスをアップグレードする必要があります。Octavia を有効にする以下の手順は、オーバークラウドのクリーンインストールまたはオーバークラウドの更新の両方に適用されます。

注記

以下の手順では、Octavia を使用する場合に RHOSP のデプロイメント 時に必要となる主な手順のみを説明します。また、レジストリーメソッド が変更されることにも留意してください。

以下の例では、ローカルレジストリーの方法を使用しています。

手順

  1. ローカルレジストリーを使用している場合、イメージをレジストリーにアップロードするためのテンプレートを作成します。以下に例を示します。 

    (undercloud) $ openstack overcloud container image prepare \
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \
--namespace=registry.access.redhat.com/rhosp13 \
--push-destination=<local-ip-from-undercloud.conf>:8787 \
--prefix=openstack- \
--tag-from-label {version}-{product-version} \
--output-env-file=/home/stack/templates/overcloud_images.yaml \
--output-images-file /home/stack/local_registry_images.yaml

  2. local_registry_images.yaml ファイルに Octavia イメージが含まれることを確認します。以下に例を示します。 

    ...
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-api:13.0-43
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-health-manager:13.0-45
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-housekeeping:13.0-45
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-worker:13.0-44
  push_destination: <local-ip-from-undercloud.conf>:8787
    注記

    Octavia コンテナーのバージョンは、インストールされている特定の RHOSP リリースによって異なります。

  3. コンテナーイメージを registry.redhat.io からアンダークラウドノードにプルします。 

    (undercloud) $ sudo openstack overcloud container image upload \
  --config-file  /home/stack/local_registry_images.yaml \
  --verbose

    これには、ネットワークおよびアンダークラウドディスクの速度に応じて多少の時間がかかる可能性があります。

  4. Octavia を使用してオーバークラウドをインストールまたは更新します。 

    $ openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \
  -e octavia_timeouts.yaml
    注記

    このコマンドには、Octavia に関連付けられたファイルのみが含まれます。これは、RHOSP の特定のインストールによって異なります。詳細は RHOSP のドキュメントを参照してください。Octavia インストールのカスタマイズについての詳細は、Octavia デプロイメントのプランニング を参照してください。

    注記

    Kuryr SDN を利用する際には、オーバークラウドのインストールに Neutron の trunk 拡張機能が必要です。これは、Director デプロイメントでデフォルトで有効にされます。Neutron バックエンドが ML2/OVS の場合、デフォルトの ovs-hybrid の代わりに openvswitch ファイアウォールを使用します。バックエンドが ML2/OVN の場合には変更の必要がありません。

4.3.3.1. Octavia OVN ドライバー

Octavia は Octavia API を使用して複数のプロバイダードライバーをサポートします。

利用可能なすべての Octavia プロバイダードライバーをコマンドラインで表示するには、以下を入力します。 

$ openstack loadbalancer provider list

出力例

+---------+-------------------------------------------------+
| name    | description                                     |
+---------+-------------------------------------------------+
| amphora | The Octavia Amphora driver.                     |
| octavia | Deprecated alias of the Octavia Amphora driver. |
| ovn     | Octavia OVN driver.                             |
+---------+-------------------------------------------------+

RHOSP バージョン 16 以降、Octavia OVN プロバイダードライバー (ovn) は RHOSP デプロイメントの OpenShift Container Platform でサポートされます。

ovn は、Octavia および OVN が提供する負荷分散用の統合ドライバーです。これは基本的な負荷分散機能をサポートし、OpenFlow ルールに基づいています。このドライバーは、OVN Neutron ML2 を使用するデプロイメント上の director により Octavia で自動的に有効にされます。

Amphora プロバイダードライバーがデフォルトのドライバーです。ただし、ovn が有効にされる場合には、Kuryr がこれを使用します。

Kuryr が Amphora の代わりに ovn を使用する場合は、以下の利点があります。

  • リソース要件が減少します。Kuryr は、各サービスにロードバランサーの仮想マシンを必要としません。
  • ネットワークレイテンシーが短縮されます。
  • サービスごとに仮想マシンを使用する代わりに、OpenFlow ルールを使用することで、サービスの作成速度が上がります。
  • Amphora 仮想マシンで集中管理されるのではなく、すべてのノードに分散負荷分散アクションが分散されます。

RHOSP クラウドがバージョン 13 から 16 にアップグレードした後に、クラスターを Octavia OVN ドライバーを使用するように設定 できます。

4.3.4. Kuryr を使用したインストールについての既知の制限

OpenShift Container Platform を Kuryr SDN で使用する場合、いくつかの既知の制限があります。

RHOSP の一般的な制限

OpenShift Container Platform を Kuryr SDN と共に使用する場合は、すべてのバージョンおよび環境に適用されるいくつかの制限があります。

  • NodePort タイプの Service オブジェクトはサポートされません。
  • OVN Octavia プロバイダーを使用するクラスターは、Service オブジェクトをサポートします。このオブジェクトについて、.spec.selector プロパティーは、Endpoints オブジェクトの .subsets.addresses プロパティーにノードまたは Pod のサブネットが含まれる場合は指定されません。
  • マシンが作成されるサブネットがルーターに接続されていない場合や、サブネットが接続されていても、ルーターに外部ゲートウェイが設定されていない場合、Kuryr はタイプが LoadBalancer の Service オブジェクトの Floating IP を作成できません。
  • Service オブジェクトで sessionAffinity=ClientIP プロパティーを設定しても効果はありません。Kuryr はこの設定をサポートしていません。
RHOSP バージョンの制限

OpenShift Container Platform を Kuryr SDN で使用する場合は、RHOSP バージョンに依存するいくつかの制限があります。

  • RHOSP の 16 よりも前のバージョンでは、デフォルトの Octavia ロードバランサードライバー (Amphora) を使用します。このドライバーでは、OpenShift Container Platform サービスごとに 1 つの Amphora ロードバランサー仮想マシンをデプロイする必要があります。サービス数が多すぎると、リソースが不足する可能性があります。

    OVN Octavia ドライバーが無効にされている以降のバージョンの RHOSP のデプロイメントでも Amphora ドライバーを使用します。この場合も、RHOSP の以前のバージョンと同じリソースに関する懸念事項を考慮する必要があります。

  • Kuryr SDN は、サービスによる自動解凍をサポートしていません。
RHOSP のアップグレードの制限

RHOSP のアップグレードプロセスにより、Octavia API が変更され、ロードバランサーに使用される Amphora イメージへのアップグレードが必要になる可能性があります。

API の変更に個別に対応できます。

Amphora イメージがアップグレードされると、RHOSP Operator は既存のロードバランサー仮想マシンを 2 つの方法で処理できます。

Operator が最初のオプションを選択する場合、フェイルオーバー時に短い時間のダウンタイムが生じる可能性があります。

Operator が 2 つ目のオプションを選択する場合、既存のロードバランサーは UDP リスナーなどのアップグレードされた Octavia API 機能をサポートしません。この場合、ユーザーはこれらの機能を使用するためにサービスを再作成する必要があります。

4.3.5. コントロールプレーンマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコントロールプレーンマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

4.3.6. コンピュートマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコンピューティングマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 8 GB のメモリーと 2 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量
ヒント

コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。

4.3.7. ブートストラップマシン

インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。

ブートストラップマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

4.4. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

4.5. RHOSP での Swift の有効化

Swift は、swiftoperator ロールのあるユーザーアカウントによって操作されます。インストールプログラムを実行する前に、ロールをアカウントに追加します。

重要

Swift として知られる Red Hat OpenStack Platform (RHOSP) オブジェクトストレージサービス が利用可能な場合、OpenShift Container Platform はこれをイメージレジストリーストレージとして使用します。利用できない場合、インストールプログラムは Cinder として知られる RHOSP ブロックストレージサービスに依存します。

Swift が存在し、これを使用する必要がある場合は、Swift へのアクセスを有効にする必要があります。これが存在しない場合や使用する必要がない場合は、このセクションを省略してください。

重要

RHOSP 17 では、Ceph RGW の rgw_max_attr_size パラメーターが 256 文字に設定されます。この設定は、コンテナーイメージを OpenShift Container Platform レジストリーにアップロードする際に問題を引き起こします。rgw_max_attr_size の値は、1024 文字以上に設定する必要があります。

インストールする前に、RHOSP のデプロイメントがこの問題の影響を受けるかどうか確認してください。影響を受ける場合は、Ceph RGW を再設定します。

前提条件

  • ターゲット環境に RHOSP 管理者アカウントがあります。
  • Swift サービスがインストールされています。
  • Ceph RGW で、account in url オプションが有効化されています。

手順

RHOSP 上で Swift を有効にするには、以下を実行します。

  1. RHOSP CLI の管理者として、swiftoperator ロールを Swift にアクセスするアカウントに追加します。 

    $ openstack role add --user <user> --project <project> swiftoperator

RHOSP デプロイメントでは、イメージレジストリーに Swift を使用することができます。

4.6. 外部ネットワークアクセスの確認

OpenShift Container Platform インストールプロセスでは、外部ネットワークへのアクセスが必要です。外部ネットワーク値をこれに指定する必要があります。指定しない場合には、デプロイメントは失敗します。このプロセスを実行する前に、外部ルータータイプのネットワークが Red Hat OpenStack Platform (RHOSP) に存在することを確認します。

前提条件

手順

  1. RHOSP CLI を使用して、'External' ネットワークの名前と ID を確認します。 

    $ openstack network list --long -c ID -c Name -c "Router Type"

    出力例

    +--------------------------------------+----------------+-------------+
| ID                                   | Name           | Router Type |
+--------------------------------------+----------------+-------------+
| 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
+--------------------------------------+----------------+-------------+

外部ルータータイプのあるネットワークがネットワークリストに表示されます。1 つ以上のネットワークが表示されない場合は、デフォルトの Floating IP ネットワークの作成 および デフォルトのプロバイダーネットワークの作成 を参照してください。

重要

外部ネットワークの CIDR 範囲がデフォルトのネットワーク範囲のいずれかと重複している場合、インストールプロセスを開始する前に、install-config.yaml ファイルで一致するネットワーク範囲を変更する必要があります。

デフォルトのネットワーク範囲は以下のとおりです。

ネットワーク範囲

machineNetwork

10.0.0.0/16

serviceNetwork

172.30.0.0/16

clusterNetwork

10.128.0.0/14

警告

インストールプログラムにより同じ名前を持つ複数のネットワークが見つかる場合、それらのネットワークのいずれかがランダムに設定されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。

注記

Neutron トランクサービスプラグインが有効にされると、トランクポートがデフォルトで作成されます。詳細は、Neutron trunk port を参照してください。

4.7. インストールプログラムのパラメーターの定義

OpenShift Container Platform インストールプログラムは、clouds.yaml というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。

手順

  1. clouds.yaml ファイルを作成します。

    • RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに clouds.yaml ファイルを生成します。

      重要

      パスワードを必ず auth フィールドに追加してください。シークレットは、clouds.yaml の 別のファイル に保持できます。

    • RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。clouds.yaml の詳細は、RHOSP ドキュメントの Config files を参照してください。 

      clouds:
  shiftstack:
    auth:
      auth_url: http://10.10.14.42:5000/v3
      project_name: shiftstack
      username: <username>
      password: <password>
      user_domain_name: Default
      project_domain_name: Default
  dev-env:
    region_name: RegionOne
    auth:
      username: <username>
      password: <password>
      project_name: 'devonly'
      auth_url: 'https://10.10.14.22:5001/v2.0'

  2. RHOSP インストールでエンドポイント認証用に自己署名認証局 (CA) を使用する場合、以下を実行します。

    1. 認証局ファイルをマシンにコピーします。

    2. cacerts キーを clouds.yaml ファイルに追加します。この値は、CA 証明書への絶対的な root 以外によるアクセスが可能なパスである必要があります。 

      clouds:
  shiftstack:
    ...
    cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"
      ヒント

      カスタム CA 証明書を使用してインストーラーを実行した後に、cloud-provider-config キーマップの ca-cert.pem キーの値を編集して証明書を更新できます。コマンドラインで、以下を実行します。 

      $ oc edit configmap -n openshift-config cloud-provider-config

  3. clouds.yaml ファイルを以下の場所のいずれかに置きます。

    1. OS_CLIENT_CONFIG_FILE 環境変数の値
    2. 現行ディレクトリー
    3. Unix 固有のユーザー設定ディレクトリー (例: ~/.config/openstack/clouds.yaml)

    4. Unix 固有のサイト設定ディレクトリー (例: /etc/openstack/clouds.yaml)

      インストールプログラムはこの順序で clouds.yaml を検索します。

4.8. OpenStack Cloud Controller Manager のオプション設定

オプションで、クラスターの OpenStack Cloud Controller Manager (CCM) 設定を編集できます。この設定は、OpenShift Container Platform が Red Hat OpenStack Platform (RHOSP) と対話する方法を制御します。

設定パラメーターの完全なリストは、「OpenStack のインストール」ドキュメントの「OpenStack Cloud Controller Manager リファレンスガイド」を参照してください。

手順

  1. クラスター用に生成されたマニフェストファイルがない場合は、以下のコマンドを実行して生成します。 

    $ openshift-install --dir <destination_directory> create manifests

  2. テキストエディターで、cloud-provider 設定マニフェストファイルを開きます。以下に例を示します。 

    $ vi openshift/manifests/cloud-provider-config.yaml

  3. CCM リファレンスガイド に従ってオプションを変更します。

    負荷分散を Octavia に設定することは、Kuryr を使用しないクラスターでは一般的なケースです。以下に例を示します。 

    #...
[LoadBalancer]
use-octavia=true 1
lb-provider = "amphora" 2
floating-network-id="d3deb660-4190-40a3-91f1-37326fe6ec4a" 3
create-monitor = True 4
monitor-delay = 10s 5
monitor-timeout = 10s 6
monitor-max-retries = 1 7
#...
    1
    このプロパティーにより、Octavia の統合が有効になっています。
    2
    このプロパティーは、ロードバランサーが使用する Octavia プロバイダーを設定します。"ovn" または "amphora" を値として受け入れます。OVN の使用を選択する場合は、lb-method を SOURCE_IP_PORT。
    3
    このプロパティーは、複数の外部ネットワークをクラスターで使用する場合に必要です。クラウドプロバイダーは、ここで指定するネットワーク上に Floating IP アドレスを作成します。
    4
    このプロパティーは、クラウドプロバイダーが Octavia ロードバランサーのヘルスモニターを作成するかどうかを制御します。ヘルスモニターを作成するには、値を True に設定します。RHOSP 16.2 の時点で、この機能は Amphora プロバイダーでのみ利用できます。
    5
    このプロパティーは、監視されるエンドポイントの頻度を設定します。値は time.ParseDuration（） 形式である必要があります。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    6
    このプロパティーは、タイムアウトする前に監視要求が開く時間を設定します。値は time.ParseDuration（） 形式である必要があります。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    7
    このプロパティーは、ロードバランサーがオンラインとしてマークされる前に必要なモニタリング要求の数を定義します。値は整数でなければなりません。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    重要

    変更を保存する前に、ファイルが正しく構造化されていることを確認します。プロパティーが適切なセクションに置かれていないと、クラスターが失敗することがあります。

    重要

    .spec.externalTrafficPolicy プロパティーの値が Local に設定されたサービスを使用する場合は、create-monitor プロパティーの値を True に設定する必要があります。RHOSP 16.2 の OVN Octavia プロバイダーは、ヘルスモニターをサポートしません。そのため、lb-provider の値が "ovn" に設定されている場合、ETP パラメーターの値が Local に設定されたサービスは応答しない可能性があります。

    重要

    Kuryr を使用するインストールの場合、Kuryr は関連サービスを処理します。クラウドプロバイダーで Octavia の負荷分散を設定する必要はありません。

  4. 変更をファイルに保存し、インストールを続行します。

    ヒント

    インストーラーの実行後に、クラウドプロバイダー設定を更新できます。コマンドラインで、以下を実行します。 

    $ oc edit configmap -n openshift-config cloud-provider-config

    変更を保存した後、クラスターの再設定には多少時間がかかります。ノードが SchedulingDisabled のままの場合は、プロセスが完了します。

4.9. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。

  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

4.10. インストール設定ファイルの作成

Red Hat OpenStack Platform (RHOSP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
  • サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。 

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして openstack を選択します。
      3. クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
      4. OpenShift API への外部アクセスに使用する floating IP アドレスを指定します。
      5. コントロールプレーンノードに使用する少なくとも 16 GB の RAM とコンピュートノードに使用する 8 GB の RAM を持つ RHOSP フレーバーを指定します。
      6. クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
      7. クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
      8. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

4.10.1. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

注記

Kuryr のインストールでは、HTTP プロキシーがデフォルト設定されます。

前提条件

  • Proxy オブジェクトを使用する制限付きネットワークで Kuryr をインストールする場合には、プロキシーはクラスターが使用するルーターとの応答が可能でなければなりません。root ユーザーとしてコマンドラインからプロキシー設定の静的ルートを追加するには、次のように入力します。 

    $ ip route add <cluster_network_cidr> via <installer_subnet_gateway>
  • 制限付きサブネットには、Kuryr が作成する Router リソースにリンクできるように定義され、使用可能なゲートウェイが必要です。
  • 既存の install-config.yaml ファイルがある。

  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。 

    apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port> 1
  httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
  noProxy: example.com 3
additionalTrustBundle: | 4
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
    5
    オプション： trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。
    注記

    インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

    注記

    インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。 

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

4.11. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

4.11.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表4.2 必須パラメーター
パラメーター説明値

apiVersion

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain と <metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata.name

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。文字列は 14 文字以上でなければなりません。

platform

インストールを実行する特定のプラットフォームの設定: alibabacloud、aws、baremetal、azure、gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}。platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

4.11.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

表4.3 ネットワークパラメーター
パラメーター説明値

networking

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking.networkType

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、全 Linux ネットワーク用の CNI プラグインです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNkubernetes です。

networking.clusterNetwork

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23

networking.clusterNetwork.cidr

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking.clusterNetwork.hostPrefix

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix が 23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking.serviceNetwork

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 

networking:
  serviceNetwork:
   - 172.30.0.0/16

networking.machineNetwork

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16

networking.machineNetwork.cidr

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

4.11.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表4.4 オプションのパラメーター
パラメーター説明値

additionalTrustBundle

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は None、v4.11、v4.12、vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

compute

コンピュートノードを設定するマシンの設定。

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute.hyperthreading

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute.name

compute を使用する場合に必須です。マシンプールの名前。

worker

compute.platform

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

compute.replicas

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane

コントロールプレーンを設定するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane.hyperthreading

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane.name

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane.platform

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

controlPlane.replicas

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを Mint、Passthrough または Manual に設定する必要があります。

Mint、Passthrough、Manual、または空の文字列 ("")。

fips

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、x86_64、ppc64le、および s390x アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources.source

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources.mirrors

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

4.11.4. 追加の Red Hat OpenStack Platform (RHOSP) 設定パラメーター

追加の RHOSP 設定パラメーターは以下の表で説明されています。

表4.5 追加の RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.rootVolume.size

コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

compute.platform.openstack.rootVolume.type

コンピュートマシンの場合、root のボリュームタイプです。

文字列 (例: performance)。

controlPlane.platform.openstack.rootVolume.size

コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

controlPlane.platform.openstack.rootVolume.type

コントロールプレーンマシンの場合、root ボリュームのタイプです。

文字列 (例: performance)。

platform.openstack.cloud

clouds.yaml ファイルのクラウドリストにある使用する RHOCP クラウドの名前。

文字列 (例: MyCloud)。

platform.openstack.externalNetwork

インストールに使用される RHOSP の外部ネットワーク名。

文字列 (例: external)。

platform.openstack.computeFlavor

コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。

このプロパティーは非推奨にされています。すべてのマシンプールのデフォルトとしてフレーバーを使用するには、これを platform.openstack.defaultMachinePlatform プロパティーで type キーの値として追加します。それぞれのマシンプールのフレーバー値を個別に設定することもできます。

文字列 (例: m1.xlarge)。

4.11.5. オプションの RHOSP 設定パラメーター

オプションの RHOSP 設定パラメーターは、以下の表で説明されています。

表4.6 オプションの RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.additionalNetworkIDs

コンピュートマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

compute.platform.openstack.additionalSecurityGroupIDs

コンピュートマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

compute.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

compute.platform.openstack.rootVolume.zones

コンピュートマシンの root ボリュームをインストールするアベイラビリティーゾーン。このパラメーターに値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列のリスト (例: ["zone-1", "zone-2"])。

compute.platform.openstack.serverGroupPolicy

プール内のコンピュートマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

controlPlane.platform.openstack.additionalNetworkIDs

コントロールプレーンマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

コントロールプレーンマシンに接続されている追加のネットワークも、ブートストラップノードに接続されています。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

controlPlane.platform.openstack.additionalSecurityGroupIDs

コントロールプレーンマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

controlPlane.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.rootVolume.zones

コントロールプレーンマシンの root ボリュームをインストールするアベイラビリティーゾーン。この値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列の一覧 (例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.serverGroupPolicy

プール内のコントロールプレーンマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

platform.openstack.clusterOSImage

インストールプログラムが RHCOS イメージをダウンロードする場所。

ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。

HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。

例: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d。この値は、既存の Glance イメージの名前にもなり得ます (例: my-rhcos)。

platform.openstack.clusterOSImageProperties

Glance のインストーラーでアップロードされた ClusterOSImage に追加するプロパティー。このプロパティーは、platform.openstack.clusterOSImage が既存の Glance イメージに設定されている場合は無視されます。

このプロパティーを使用し、ノードあたり 26 PV の RHOSP のデフォルト永続ボリューム (PV) の制限を超過することができます。制限を超えるには、hw_scsi_model プロパティーの値を virtio-scsi に設定し、hw_disk_bus の値を scsi に設定します。

このプロパティーを使用し、hw_qemu_guest_agent プロパティーを yes の値で追加して QEMU ゲストエージェントを有効にすることもできます。

キーと値の文字列のペアのリスト。例: ["hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi"]

platform.openstack.defaultMachinePlatform

デフォルトのマシンプールプラットフォームの設定。 

{
   "type": "ml.large",
   "rootVolume": {
      "size": 30,
      "type": "performance"
   }
}

platform.openstack.ingressFloatingIP

Ingress ポートに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.apiFloatingIP

API ロードバランサーに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.externalDNS

クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。

文字列としての IP アドレスのリスト。例: ["8.8.8.8", "192.168.1.12"]

platform.openstack.machinesSubnet

クラスターのノードが使用する RHOSP サブネットの UUID。ノードおよび仮想 IP (VIP) ポートがこのサブネットに作成されます。

networking.machineNetwork の最初の項目は machinesSubnet の値に一致する必要があります。

カスタムサブネットにデプロイする場合、OpenShift Container Platform インストーラーに外部 DNS サーバーを指定することはできません。代わりに、DNS を RHOSP のサブネットに追加 します。

文字列としての UUID。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

4.11.6. RHOSP デプロイメントでのカスタムサブネット

オプションで、選択する Red Hat OpenStack Platform (RHOSP) サブネットにクラスターをデプロイすることができます。サブネットの GUID は、install-config.yaml ファイルの platform.openstack.machinesSubnet の値として渡されます。

このサブネットはクラスターのプライマリーサブネットとして使用されます。デフォルトで、ノードおよびポートはこの上に作成されます。platform.openstack.machinesSubnet プロパティーの値をサブネットの UUID に設定すると、異なる RHOSP サブネットにノードおよびポートを作成することができます。

カスタムサブネットを使用して OpenShift Container Platform インストーラーを実行する前に、設定が以下の要件を満たしていることを確認してください。

  • platform.openstack.machinesSubnet で使用されるサブネットで DHCP が有効にされている。
  • platform.openstack.machinesSubnet の CIDR は networking.machineNetwork の CIDR に一致する。
  • インストールプログラムのユーザーには、固定 IP アドレスを持つポートなど、このネットワークでポートを作成するパーミッションがある。

カスタムサブネットを使用するクラスターには、以下の制限があります。

  • Floating IP アドレスを使用するクラスターをインストールする予定の場合には、platform.openstack.machinesSubnet サブネットを externalNetwork ネットワークに接続されているルーターに接続する必要があります。
  • platform.openstack.machinesSubnet の値が install-config.yaml ファイルに設定されている場合、インストールプログラムは RHOSP マシンのプライベートネットワークまたはサブネットを作成しません。
  • platform.openstack.externalDNS プロパティーは、カスタムサブネットと同時に使用することはできません。カスタムサブネットを使用するクラスターに DNS を追加するには、RHOSP ネットワークで DNS を設定します。
注記

デフォルトでは、API VIP は x.x.x.5 を取得し、Ingress VIP はネットワークの CIDR ブロックから x.x.x.7 を取得します。これらのデフォルト値を上書きするには、DHCP 割り当てプール外の platform.openstack.apiVIPs および platform.openstack.ingressVIPs の値を設定します。

重要

ネットワークの CIDR 範囲は、クラスターのインストール後に調整できません。Red Hat は、namespace ごとに作成される Pod の数を慎重に検討する必要があるため、クラスターのインストール時に範囲を決定するための直接的なガイダンスを提供していません。

4.11.7. Kuryr を使用した OpenStack のカスタマイズされた install-config.yaml ファイルのサンプル

デフォルトの OVN-Kubernetes ネットワークプラグインの代わりに Kuryr SDN を使用してデプロイするには、install-config.yaml ファイルを変更して、Kuryr を目的の network.networkType として含める必要があります。このサンプル install-config.yaml は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。

重要

このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得する必要があります。 

apiVersion: v1
baseDomain: example.com
controlPlane:
  name: master
  platform: {}
  replicas: 3
compute:
- name: worker
  platform:
    openstack:
      type: ml.large
  replicas: 3
metadata:
  name: example
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  serviceNetwork:
  - 172.30.0.0/16 1
  networkType: Kuryr 2
platform:
  openstack:
    cloud: mycloud
    externalNetwork: external
    computeFlavor: m1.xlarge
    apiFloatingIP: 128.0.0.1
    trunkSupport: true 3
    octaviaSupport: true 4
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
1
Amphora Octavia ドライバーは、ロードバランサーごとに 2 つのポートを作成します。そのため、インストーラーが作成するサービスサブネットは、serviceNetwork プロパティーの値として指定される CIDR のサイズは 2 倍になります。IP アドレスの競合を防ぐには、範囲をより広くする必要があります。
2
インストールするクラスターネットワークプラグイン。サポートされている値は、Kuryr、OVNKubernetes、および OpenShiftSDN です。デフォルトの値は OVNkubernetes です。
3 4
trunkSupport と octaviaSupport の両方はインストーラーによって自動的に検出されるため、それらを設定する必要はありません。ただし、ご使用の環境がこれらの両方の要件を満たさないと、Kuryr SDN は適切に機能しません。トランクは Pod を RHOSP ネットワークに接続するために必要であり、Octavia は OpenShift Container Platform サービスを作成するために必要です。

4.11.8. RHOSP プロバイダーネットワーク上のクラスターデプロイメント

プロバイダーネットワーク上のプライマリーネットワークインターフェイスを使用して、OpenShift Container Platform クラスターを Red Hat OpenStack Platform (RHOSP) にデプロイできます。プロバイダーネットワークは一般的に、インターネットへの到達に使用可能なパブリックネットワークに、プロジェクトが直接アクセスできるように使用します。ネットワーク作成プロセスの一環として、プロバイダーネットワークをプロジェクト間で共有することもできます。

RHOSP プロバイダーネットワークは、データセンター内の既存の物理ネットワークに直接マップします。RHOSP 管理者はこれらを作成する必要があります。

以下の例では、OpenShift Container Platform ワークロードはプロバイダーネットワークを使用してデータセンターに接続されます。

OpenStack 上の 4 つの OpenShift ワークロードを示す図。各ワークロードは、プロバイダーネットワークを使用して、NIC によって外部のデータセンターに接続されます。

プロバイダーネットワークにインストールされている OpenShift Container Platform クラスターは、テナントネットワークまたは Floating IP アドレスを必要としません。インストーラーは、インストール中にこれらのリソースを作成しません。

プロバイダーネットワークタイプの例には、フラット (タグなし) および VLAN (802.1Q タグ付き) が含まれます。

注記

クラスターは、ネットワークタイプが許可する限り多くのプロバイダーネットワーク接続をサポートできます。たとえば、VLAN ネットワークは、通常最大 4096 の接続をサポートします。

プロバイダーネットワークおよびテナントネットワークの詳細は、RHOSP のドキュメント を参照してください。

4.11.8.1. クラスターのインストールにおける RHOSP プロバイダーネットワーク要件

OpenShift Container Platform クラスターをインストールする前に、Red Hat OpenStack Platform (RHOSP) のデプロイメントおよびプロバイダーネットワークは、さまざまな条件を満たす必要があります。

  • RHOSP ネットワークサービス (Neutron) が有効化され、RHOSP ネットワーク API 経由でアクセス可能であること。
  • RHOSP ネットワークサービスでは、ポートセキュリティーと許可するアドレスペアの機能拡張が有効化 されていること。

  • プロバイダーネットワークは他のテナントと共有できます。

    ヒント

    --share フラグを指定して openstack network create コマンドを使用して、共有できるネットワークを作成します。

  • クラスターのインストールに使用する RHOSP プロジェクトは、プロバイダーネットワークと適切なサブネットを所有する必要があります。

    ヒント
    "openshift" という名前のプロジェクトのネットワークを作成するには、以下のコマンドを入力します。
    $ openstack network create --project openshift
    "openshift" という名前のプロジェクトのサブネットを作成するには、以下のコマンドを入力します。
    $ openstack subnet create --project openshift

    RHOSP でのネットワークの作成に関する詳細は、プロバイダーネットワークに関するドキュメント を参照してください。

    クラスターが admin ユーザーによって所有されている場合、そのユーザーとしてインストーラーを実行してネットワーク上でポートを作成する必要があります。

    重要

    プロバイダーネットワークは、クラスターの作成に使用される RHOSP プロジェクトによって所有されている必要があります。所有されていない場合は、RHOSP Compute サービス (Nova) はそのネットワークからポートを要求できません。

  • プロバイダーネットワークが、デフォルトで 169.254.169.254 である RHOSP メタデータサービスの IP アドレスに到達できることを確認します。

    RHOSP SDN とネットワークサービス設定によっては、サブネットを作成する際に、ルートを提供しなければならない場合があります。以下に例を示します。 

    $ openstack subnet create --dhcp --host-route destination=169.254.169.254/32,gateway=192.0.2.2 ...
  • オプション: ネットワークのセキュリティーを保護するには、単一のプロジェクトへのネットワークアクセスを制限する ロールベースのアクセス制御 (RBAC) ルールを作成します。
4.11.8.2. プロバイダーネットワークにプライマリーインターフェイスを持つクラスターのデプロイ

Red Hat OpenStack Platform (RHOSP) プロバイダーネットワーク上にプライマリーネットワークインターフェイスを持つ OpenShift Container Platform クラスターをデプロイすることができます。

前提条件

  • 「クラスターのインストールにおける RHOSP プロバイダーネットワーク要件」に記載されているとおりに、お使いの Red Hat OpenStack Platform (RHOSP) のデプロイメントが設定されています。

手順

  1. テキストエディターで install-config.yaml ファイルを開きます。
  2. platform.openstack.apiVIPs プロパティーの値を API VIP の IP アドレスに設定します。
  3. platform.openstack.ingressVIPs プロパティーの値を Ingress VIP の IP アドレスに設定します。
  4. platform.openstack.machinesSubnet プロパティーの値をプロバイダーネットワークサブネットの UUID に設定します。
  5. networking.machineNetwork.cidr プロパティーの値をプロバイダーネットワークサブネットの CIDR ブロックに設定します。
重要

platform.openstack.apiVIPs プロパティーおよび platform.openstack.ingressVIPs プロパティーはいずれも、networking.machineNetwork.cidr ブロックから割り当てられていない IP アドレスである必要があります。

RHOSP プロバイダーネットワークに依存するクラスターのインストール設定ファイルのセクション

        ...
        platform:
          openstack:
            apiVIPs: 1
              - 192.0.2.13
            ingressVIPs: 2
              - 192.0.2.23
            machinesSubnet: fa806b2f-ac49-4bce-b9db-124bc64209bf
            # ...
        networking:
          machineNetwork:
          - cidr: 192.0.2.0/24

1 2
OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。
警告

プライマリーネットワークインターフェイスにプロバイダーネットワークを使用している間は、platform.openstack.externalNetwork パラメーターまたは platform.openstack.externalDNS パラメーターを設定することはできません。

クラスターをデプロイする際に、インストーラーは install-config.yaml ファイルを使用してプロバイダーネットワークにクラスターをデプロイします。

ヒント

プロバイダーネットワークを含むネットワークを platform.openstack.additionalNetworkIDs リストに追加できます。

クラスターのデプロイ後に、Pod を追加のネットワークに接続することができます。詳細は、複数ネットワークについて を参照してください。

4.11.9. Kuryr ポートプール

Kuryr ポートプールでは、Pod 作成のスタンバイ状態の多数のポートを維持します。

ポートをスタンバイ状態に維持すると、Pod の作成時間が必要最小限に抑えることができます。ポートプールを使用しない場合には、Kuryr は Pod が作成または削除されるたびにポートの作成または削除を明示的に要求する必要があります。

Kuryr が使用する Neutron ポートは、namespace に関連付けられるサブネットに作成されます。これらの Pod ポートは、OpenShift Container Platform クラスターノードのプライマリーポートにサブポートとして追加されます。

Kuryr は namespace をそれぞれ、別のサブネットに保存するため、namespace-worker ペアごとに別個のポートプールが維持されます。

クラスターをインストールする前に、cluster-network-03-config.yml マニフェストファイルに以下のパラメーターを設定して、ポートプールの動作を設定できます。

  • enablePortPoolsPrepopulation パラメーターは、プールの事前入力を制御します。これにより、Pod 専用ネットワークを使用するように設定された最初の Pod が namespace に作成されたときに、Kuryr が Neutron ポートをプールに追加します。デフォルト値は false です。
  • poolMinPorts パラメーターは、プールに保持する空きポートの最小数です。デフォルト値は 1 です。

  • poolMaxPorts パラメーターは、プールに保持する空きポートの最大数です。値が 0 の場合は、上限が無効になります。これはデフォルト設定です。

    OpenStack ポートのクォータが低い場合や、Pod ネットワークで IP アドレスの数が限定されている場合には、このオプションを設定して、不要なポートが削除されるようにします。

  • poolBatchPorts パラメーターは、一度に作成可能な Neutron ポートの最大数を定義します。デフォルト値は 3 です。

4.11.10. インストール時の Kuryr ポートプールの調整

インストール時に、Pod 作成の速度や効率性を制御するために Kuryr で Red Hat OpenStack Platform (RHOSP) Neutron ポートを管理する方法を設定できます。

前提条件

  • install-config.yaml ファイルを作成して変更しておく。

手順

  1. コマンドラインからマニフェストファイルを作成します。 

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> については、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。

  2. cluster-network-03-config.yml という名前のファイルを <installation_directory>/manifests/ ディレクトリーに作成します。 

    $ touch <installation_directory>/manifests/cluster-network-03-config.yml 1
    1
    <installation_directory> については、クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。

    ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが manifests/ ディレクトリーに置かれます。 

    $ ls <installation_directory>/manifests/cluster-network-*

    出力例

    cluster-network-01-crd.yml
cluster-network-02-config.yml
cluster-network-03-config.yml

  3. エディターで cluster-network-03-config.yml ファイルを開き、必要な Cluster Network Operator 設定を記述するカスタムリソース (CR) を入力します。 

    $ oc edit networks.operator.openshift.io cluster

  4. 要件に合わせて設定を編集します。以下のファイルをサンプルとして紹介しています。 

    apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  defaultNetwork:
    type: Kuryr
    kuryrConfig:
      enablePortPoolsPrepopulation: false 1
      poolMinPorts: 1 2
      poolBatchPorts: 3 3
      poolMaxPorts: 5 4
      openstackServiceNetwork: 172.30.0.0/15 5
    1
    enablePortPoolsPrepopulation を true に設定すると、Pod のネットワーク上の最初の Pod が namespace に作成されたときに、Kuryr が新しい Neutron ポートを作成するようになります。この設定により、Neutron ポートのクォータが引き上げられますが、Pod の起動に必要となる時間を短縮できます。デフォルト値は false です。
    2
    Kuryr は、対象のプール内にある空きポートの数が poolMinPorts の値よりも少ない場合には、プールに新規ポートを作成します。デフォルト値は 1 です。
    3
    poolBatchPorts は、空きポートの数が poolMinPorts の値よりも少ない場合に作成される新規ポートの数を制御します。デフォルト値は 3 です。
    4
    プール内の空きポートの数が poolMaxPorts の値よりも多い場合に、Kuryr はその値と同じ数になるまでポートを削除します。この値を 0 に設定すると、この上限は無効になり、プールが縮小できないようにします。デフォルト値は 0 です。
    5
    openStackServiceNetwork パラメーターは、RHOSP Octavia の LoadBalancer に割り当てられるネットワークの CIDR 範囲を定義します。

    このパラメーターを Amphora ドライバーと併用する場合には、Octavia は、ロードバランサーごとに、このネットワークから IP アドレスを 2 つ (OpenShift 用に 1 つ、VRRP 接続用に 1 つ) 取得します。これらの IP アドレスは OpenShift Container Platform と Neutron でそれぞれ管理されるため、異なるプールから取得する必要があります。したがって、openStackServiceNetwork serviceNetwork の値の 2 倍になる必要があり、serviceNetwork の値は、openStackServiceNetwork で定義された範囲と完全に重複する必要があります。

    CNO は、このパラメーターの定義範囲から取得した VRRP IP アドレスが serviceNetwork パラメーターの定義範囲と重複しないことを検証します。

    このパラメーターが設定されていない場合には、CNO は serviceNetwork の拡張値を使用します。この値は、プリフィックスのサイズを 1 つずつ減らして決定します。

  5. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  6. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。

4.12. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64、ppc64le、および s390x アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。 

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。 

    $ cat ~/.ssh/id_ed25519.pub

  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。 

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。 

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

4.13. 環境へのアクセスの有効化

デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。

インストール時に Floating IP アドレス (FIP) を使用して OpenShift Container Platform API およびアプリケーションのアクセスを設定できます。FIP を設定せずにインストールを完了することもできますが、インストーラーは API またはアプリケーションを外部からアクセスする方法を設定しません。

4.13.1. floating IP アドレスを使用したアクセスの有効化

OpenShift Container Platform API およびクラスターアプリケーションへの外部アクセス用に Floating IP (FIP) アドレスを作成します。

手順

  1. Red Hat OpenStack Platform (RHOSP) CLI を使用して、API FIP を作成します。 

    $ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>

  2. Red Hat OpenStack Platform (RHOSP) CLI を使用して、apps (アプリ)、または Ingress、FIP を作成します。 

    $ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>

  3. API および Ingress FIP の DNS サーバーに、これらのパターンに準拠するレコードを追加します。 

    api.<cluster_name>.<base_domain>.  IN  A  <API_FIP>
*.apps.<cluster_name>.<base_domain>. IN  A <apps_FIP>
    注記

    DNS サーバーを制御していない場合は、次のようなクラスタードメイン名を /etc/hosts ファイルに追加することで、クラスターにアクセスできます。

    • <api_floating_ip> api.<cluster_name>.<base_domain>
    • <application_floating_ip> grafana-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> oauth-openshift.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
    • application_floating_ip integrated-oauth-server-openshift-authentication.apps.<cluster_name>.<base_domain>

    /etc/hosts ファイル内のクラスタードメイン名により、クラスターの Web コンソールおよび監視インターフェイスへのローカルアクセスが許可されます。kubectl または oc を使用することもできます。<application_floating_ip> を指す追加のエントリーを使用して、ユーザーアプリケーションにアクセスできます。このアクションにより、API およびアプリケーションは他のユーザーがアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

  4. FIP を、以下のパラメーターの値として install-config.yaml ファイルに追加します。

    • platform.openstack.ingressFloatingIP
    • platform.openstack.apiFloatingIP

これらの値を使用する場合には、install-config.yaml ファイルの platform.openstack.externalNetwork パラメーターの値として外部ネットワークを入力する必要もあります。

ヒント

Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。

4.13.2. Floating IP アドレスなしでのインストールの完了

Floating IP アドレスを指定せずに OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールすることができます。

install-config.yaml ファイルで以下のパラメーターを定義しないでください。

  • platform.openstack.ingressFloatingIP
  • platform.openstack.apiFloatingIP

外部ネットワークを提供できない場合は、platform.openstack.externalNetwork を空白のままにすることもできます。platform.openstack.externalNetwork の値を指定しない場合はルーターが作成されず、追加のアクションがない場合は、インストーラーは Glance からのイメージの取得に失敗します。外部接続を独自に設定する必要があります。

Floating IP アドレスまたは名前解決がないために、クラスター API に到達できないシステムからインストーラーを実行すると、インストールに失敗します。このような場合にインストールが失敗するのを防ぐために、プロキシーネットワークを使用するか、マシンと同じネットワークにあるシステムからインストーラーを実行できます。

注記

API および Ingress ポートの DNS レコードを作成して、名前解決を有効にできます。以下に例を示します。 

api.<cluster_name>.<base_domain>.  IN  A  <api_port_IP>
*.apps.<cluster_name>.<base_domain>. IN  A <ingress_port_IP>

DNS サーバーを制御しない場合は、/etc/hosts ファイルにレコードを追加できます。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

4.14. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。 

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
    --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

4.15. クラスターステータスの確認

インストール時またはインストール後に OpenShift Container Platform クラスターのステータスを確認することができます。

手順

  1. クラスター環境で、管理者の kubeconfig ファイルをエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。

  2. デプロイメント後に作成されたコントロールプレーンおよびコンピュートマシンを表示します。 

    $ oc get nodes

  3. クラスターのバージョンを表示します。 

    $ oc get clusterversion

  4. Operator のステータスを表示します。 

    $ oc get clusteroperator

  5. クラスター内のすべての実行中の Pod を表示します。 

    $ oc get pods -A

4.16. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。 

    $ oc whoami

    出力例

    system:admin

関連情報

4.17. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

4.18. 次のステップ

第5章 独自のインフラストラクチャーを使用した OpenStack へのクラスターのインストール

OpenShift Container Platform バージョン 4.12 では、ユーザーによってプロビジョニングされたインフラストラクチャーで実行される Red Hat OpenStack Platform (RHOSP) にクラスターをインストールできます。

独自のインフラストラクチャーを使用することで、クラスターを既存のインフラストラクチャーおよび変更と統合できます。このプロセスでは、installer-provisioned installation の場合よりも多くの手作業が必要になります。Nova サーバー、Neutron ポート、セキュリティーグループなどのすべての RHOSP リソースを作成する必要があるためです。ただし、Red Hat では、デプロイメントプロセスを支援する Ansible Playbook を提供しています。

5.1. 前提条件

5.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

5.3. OpenShift Container Platform を RHOSP にインストールするリソースのガイドライン

OpenShift Container Platform のインストールをサポートするために、Red Hat OpenStack Platform (RHOSP) クォータは以下の要件を満たす必要があります。

表5.1 RHOSP のデフォルトの OpenShift Container Platform クラスターに関する推奨リソース
リソース値

Floating IP アドレス

3

ポート

15

ルーター

1

サブネット

1

RAM

88 GB

vCPU

22

ボリュームストレージ

275 GB

インスタンス

7

セキュリティーグループ

3

セキュリティーグループルール

60

サーバーグループ

2 - 各マシンプールの追加のアベイラビリティーゾーンごとに 1 つ追加

クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。

重要

RHOSP オブジェクトストレージ (Swift) が利用可能で、swiftoperator ロールを持つユーザーアカウントによって操作されている場合、これは OpenShift Container Platform イメージレジストリーのデフォルトバックエンドとして使用されます。この場合、ボリュームストレージ要件は 175 GB です。Swift 領域要件は、イメージレジストリーのサイズによって異なります。

注記

デフォルトで、セキュリティーグループおよびセキュリティーグループルールのクォータは低く設定される可能性があります。問題が生じた場合には、管理者として openstack quota set --secgroups 3 --secgroup-rules 60 <project> を実行して値を増やします。

OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで構成されます。

5.3.1. コントロールプレーンマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコントロールプレーンマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

5.3.2. コンピュートマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコンピューティングマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 8 GB のメモリーと 2 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量
ヒント

コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。

5.3.3. ブートストラップマシン

インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。

ブートストラップマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

5.4. Playbook 依存関係のダウンロード

user-provisioned infrastructure でのインストールプロセスを単純化する Ansible Playbook には、複数の Python モジュールが必要です。インストーラーを実行するマシンで、モジュールのリポジトリーを追加し、それらをダウンロードします。

注記

この手順では、Red Hat Enterprise Linux (RHEL) 8 を使用していることを前提としています。

前提条件

  • Python 3 がマシンにインストールされている。

手順

  1. コマンドラインで、リポジトリーを追加します。

    1. Red Hat Subscription Manager に登録します。 

      $ sudo subscription-manager register # If not done already

    2. 最新のサブスクリプションデータをプルします。 

      $ sudo subscription-manager attach --pool=$YOUR_POOLID # If not done already

    3. 現在のリポジトリーを無効にします。 

      $ sudo subscription-manager repos --disable=* # If not done already

    4. 必要なリポジトリーを追加します。 

      $ sudo subscription-manager repos \
  --enable=rhel-8-for-x86_64-baseos-rpms \
  --enable=openstack-16-tools-for-rhel-8-x86_64-rpms \
  --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
  --enable=rhel-8-for-x86_64-appstream-rpms

  2. モジュールをインストールします。 

    $ sudo yum install python3-openstackclient ansible python3-openstacksdk python3-netaddr ansible-collections-openstack

  3. python コマンドが python3 を参照していることを確認します。 

    $ sudo alternatives --set python /usr/bin/python3

5.5. インストール Playbook のダウンロード

OpenShift Container Platform を独自の Red Hat OpenStack Platform (RHOSP) インフラストラクチャーにインストールするために使用できる Ansible Playbook をダウンロードします。

前提条件

  • curl コマンドラインツールがマシンで利用できる。

手順

  • Playbook を作業ディレクトリーにダウンロードするには、コマンドラインから以下のスクリプトを実行します。 

    $ xargs -n 1 curl -O <<< '
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/bootstrap.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/common.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/compute-nodes.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/control-plane.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/inventory.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/network.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/security-groups.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-bootstrap.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-compute-nodes.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-control-plane.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-load-balancers.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-network.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-security-groups.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-containers.yaml'

Playbook はマシンにダウンロードされます。

重要

インストールプロセス時に、Playbook を変更してデプロイメントを設定できます。

クラスターの有効期間中に、すべての Playbook を保持します。OpenShift Container Platform クラスターを RHOSP から削除するには Playbook が必要です。

重要

bootstrap.yaml、compute-nodes.yaml、control-plane.yaml、network.yaml、および security-groups.yaml ファイルに加えた編集内容は、down- の接頭辞が付けられた対応する Playbook に一致している必要があります。たとえば、bootstrap.yaml ファイルへの編集は、down-bootstrap.yaml ファイルにも反映される必要があります。両方のファイルを編集しない場合、サポートされるクラスターの削除プロセスは失敗します。

5.6. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。

  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

5.7. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64、ppc64le、および s390x アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。 

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。 

    $ cat ~/.ssh/id_ed25519.pub

  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。 

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。 

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

5.8. Red Hat Enterprise Linux CoreOS (RHCOS) イメージの作成

OpenShift Container Platform インストールプログラムでは、Red Hat Enterprise Linux CoreOS (RHCOS) イメージが Red Hat OpenStack Platform (RHOSP) クラスターに存在する必要があります。最新の RHCOS イメージを取得した後、RHOSP CLI を使用してこれをアップロードします。

前提条件

  • RHOSP CLI がインストールされています。

手順

  1. Red Hat カスタマーポータルの 製品ダウンロードページ にログインします。

  2. バージョン の下で、Red Hat Enterprise Linux (RHEL)8 用の OpenShift Container Platform 4.12 の最新リリースを選択します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

  3. Red Hat Enterprise Linux CoreOS (RHCOS) - OpenStack Image (QCOW) をダウンロードします。

  4. イメージを展開します。

    注記

    クラスターが使用する前に RHOSP イメージを圧縮解除する必要があります。ダウンロードしたファイルの名前に、.gz または .tgz などの圧縮拡張子が含まれていない場合があります。ファイルを圧縮するか、どのように圧縮するかを確認するには、コマンドラインで以下を入力します。 

    $ file <name_of_downloaded_file>

  5. ダウンロードしたイメージから、RHOSP CLI を使用して rhcos という名前のイメージをクラスターに作成します。 

    $ openstack image create --container-format=bare --disk-format=qcow2 --file rhcos-${RHCOS_VERSION}-openstack.qcow2 rhcos
    重要

    RHOSP 環境によっては、.raw または .qcow2 形式 のいずれかでイメージをアップロードできる場合があります。Ceph を使用する場合は、.raw 形式を使用する必要があります。

    警告

    インストールプログラムが同じ名前を持つ複数のイメージを見つける場合、それらのイメージのいずれかがランダムに選択されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。

RHOSP にイメージをアップロードした後は、インストールプログラムでイメージを利用できます。

5.9. 外部ネットワークアクセスの確認

OpenShift Container Platform インストールプロセスでは、外部ネットワークへのアクセスが必要です。外部ネットワーク値をこれに指定する必要があります。指定しない場合には、デプロイメントは失敗します。このプロセスを実行する前に、外部ルータータイプのネットワークが Red Hat OpenStack Platform (RHOSP) に存在することを確認します。

前提条件

手順

  1. RHOSP CLI を使用して、'External' ネットワークの名前と ID を確認します。 

    $ openstack network list --long -c ID -c Name -c "Router Type"

    出力例

    +--------------------------------------+----------------+-------------+
| ID                                   | Name           | Router Type |
+--------------------------------------+----------------+-------------+
| 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
+--------------------------------------+----------------+-------------+

外部ルータータイプのあるネットワークがネットワークリストに表示されます。1 つ以上のネットワークが表示されない場合は、デフォルトの Floating IP ネットワークの作成 および デフォルトのプロバイダーネットワークの作成 を参照してください。

注記

Neutron トランクサービスプラグインが有効にされると、トランクポートがデフォルトで作成されます。詳細は、Neutron trunk port を参照してください。

5.10. 環境へのアクセスの有効化

デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。

インストール時に Floating IP アドレス (FIP) を使用して OpenShift Container Platform API およびアプリケーションのアクセスを設定できます。FIP を設定せずにインストールを完了することもできますが、インストーラーは API またはアプリケーションを外部からアクセスする方法を設定しません。

5.10.1. floating IP アドレスを使用したアクセスの有効化

OpenShift Container Platform API、クラスターアプリケーション、およびブートストラッププロセスへの外部アクセス用に Floating IP (FIP) アドレスを作成します。

手順

  1. Red Hat OpenStack Platform (RHOSP) CLI を使用して、API FIP を作成します。 

    $ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>

  2. Red Hat OpenStack Platform (RHOSP) CLI を使用して、apps (アプリ)、または Ingress、FIP を作成します。 

    $ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>

  3. Red Hat OpenStack Platform (RHOSP) CLI を使用して、ブートストラップ FIP を作成します。 

    $ openstack floating ip create --description "bootstrap machine" <external_network>

  4. API および Ingress FIP の DNS サーバーに、これらのパターンに準拠するレコードを追加します。 

    api.<cluster_name>.<base_domain>.  IN  A  <API_FIP>
*.apps.<cluster_name>.<base_domain>. IN  A <apps_FIP>
    注記

    DNS サーバーを制御していない場合は、次のようなクラスタードメイン名を /etc/hosts ファイルに追加することで、クラスターにアクセスできます。

    • <api_floating_ip> api.<cluster_name>.<base_domain>
    • <application_floating_ip> grafana-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> oauth-openshift.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
    • application_floating_ip integrated-oauth-server-openshift-authentication.apps.<cluster_name>.<base_domain>

    /etc/hosts ファイル内のクラスタードメイン名により、クラスターの Web コンソールおよび監視インターフェイスへのローカルアクセスが許可されます。kubectl または oc を使用することもできます。<application_floating_ip> を指す追加のエントリーを使用して、ユーザーアプリケーションにアクセスできます。このアクションにより、API およびアプリケーションは他のユーザーがアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

  5. FIP を以下の変数の値として inventory.yaml ファイルに追加します。

    • os_api_fip
    • os_bootstrap_fip
    • os_ingress_fip

これらの値を使用する場合には、inventory.yaml ファイルの os_external_network 変数の値として外部ネットワークを入力する必要もあります。

ヒント

Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。

5.10.2. Floating IP アドレスなしでのインストールの完了

Floating IP アドレスを指定せずに OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールすることができます。

inventory.yaml ファイルで、以下の変数を定義しないでください。

  • os_api_fip
  • os_bootstrap_fip
  • os_ingress_fip

外部ネットワークを提供できない場合は、os_external_network を空白のままにすることもできます。os_external_network の値を指定しない場合はルーターが作成されず、追加のアクションがない場合は、インストーラーは Glance からのイメージの取得に失敗します。インストールプロセスで、ネットワークリソースを作成する際に、独自の外部接続を設定する必要があります。

Floating IP アドレスまたは名前解決がないために、クラスター API に到達できないシステムから wait-for コマンドでインストーラーを実行すると、インストールに失敗します。このような場合にインストールが失敗するのを防ぐために、プロキシーネットワークを使用するか、マシンと同じネットワークにあるシステムからインストーラーを実行できます。

注記

API および Ingress ポートの DNS レコードを作成して、名前解決を有効にできます。以下に例を示します。 

api.<cluster_name>.<base_domain>.  IN  A  <api_port_IP>
*.apps.<cluster_name>.<base_domain>. IN  A <ingress_port_IP>

DNS サーバーを制御しない場合は、/etc/hosts ファイルにレコードを追加できます。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

5.11. インストールプログラムのパラメーターの定義

OpenShift Container Platform インストールプログラムは、clouds.yaml というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。

手順

  1. clouds.yaml ファイルを作成します。

    • RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに clouds.yaml ファイルを生成します。

      重要

      パスワードを必ず auth フィールドに追加してください。シークレットは、clouds.yaml の 別のファイル に保持できます。

    • RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。clouds.yaml の詳細は、RHOSP ドキュメントの Config files を参照してください。 

      clouds:
  shiftstack:
    auth:
      auth_url: http://10.10.14.42:5000/v3
      project_name: shiftstack
      username: <username>
      password: <password>
      user_domain_name: Default
      project_domain_name: Default
  dev-env:
    region_name: RegionOne
    auth:
      username: <username>
      password: <password>
      project_name: 'devonly'
      auth_url: 'https://10.10.14.22:5001/v2.0'

  2. RHOSP インストールでエンドポイント認証用に自己署名認証局 (CA) を使用する場合、以下を実行します。

    1. 認証局ファイルをマシンにコピーします。

    2. cacerts キーを clouds.yaml ファイルに追加します。この値は、CA 証明書への絶対的な root 以外によるアクセスが可能なパスである必要があります。 

      clouds:
  shiftstack:
    ...
    cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"
      ヒント

      カスタム CA 証明書を使用してインストーラーを実行した後に、cloud-provider-config キーマップの ca-cert.pem キーの値を編集して証明書を更新できます。コマンドラインで、以下を実行します。 

      $ oc edit configmap -n openshift-config cloud-provider-config

  3. clouds.yaml ファイルを以下の場所のいずれかに置きます。

    1. OS_CLIENT_CONFIG_FILE 環境変数の値
    2. 現行ディレクトリー
    3. Unix 固有のユーザー設定ディレクトリー (例: ~/.config/openstack/clouds.yaml)

    4. Unix 固有のサイト設定ディレクトリー (例: /etc/openstack/clouds.yaml)

      インストールプログラムはこの順序で clouds.yaml を検索します。

5.12. インストール設定ファイルの作成

Red Hat OpenStack Platform (RHOSP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
  • サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。 

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして openstack を選択します。
      3. クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
      4. OpenShift API への外部アクセスに使用する floating IP アドレスを指定します。
      5. コントロールプレーンノードに使用する少なくとも 16 GB の RAM とコンピュートノードに使用する 8 GB の RAM を持つ RHOSP フレーバーを指定します。
      6. クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
      7. クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
      8. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

これで、指定したディレクトリーに install-config.yaml ファイルが作成されます。

5.13. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.13.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表5.2 必須パラメーター
パラメーター説明値

apiVersion

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain と <metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata.name

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。文字列は 14 文字以上でなければなりません。

platform

インストールを実行する特定のプラットフォームの設定: alibabacloud、aws、baremetal、azure、gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}。platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

5.13.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

表5.3 ネットワークパラメーター
パラメーター説明値

networking

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking.networkType

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、全 Linux ネットワーク用の CNI プラグインです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNkubernetes です。

networking.clusterNetwork

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23

networking.clusterNetwork.cidr

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking.clusterNetwork.hostPrefix

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix が 23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking.serviceNetwork

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 

networking:
  serviceNetwork:
   - 172.30.0.0/16

networking.machineNetwork

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16

networking.machineNetwork.cidr

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

5.13.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表5.4 オプションのパラメーター
パラメーター説明値

additionalTrustBundle

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は None、v4.11、v4.12、vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

compute

コンピュートノードを設定するマシンの設定。

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute.hyperthreading

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute.name

compute を使用する場合に必須です。マシンプールの名前。

worker

compute.platform

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

compute.replicas

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane

コントロールプレーンを設定するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane.hyperthreading

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane.name

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane.platform

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

controlPlane.replicas

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを Mint、Passthrough または Manual に設定する必要があります。

Mint、Passthrough、Manual、または空の文字列 ("")。

fips

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、x86_64、ppc64le、および s390x アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources.source

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources.mirrors

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

5.13.4. 追加の Red Hat OpenStack Platform (RHOSP) 設定パラメーター

追加の RHOSP 設定パラメーターは以下の表で説明されています。

表5.5 追加の RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.rootVolume.size

コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

compute.platform.openstack.rootVolume.type

コンピュートマシンの場合、root のボリュームタイプです。

文字列 (例: performance)。

controlPlane.platform.openstack.rootVolume.size

コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

controlPlane.platform.openstack.rootVolume.type

コントロールプレーンマシンの場合、root ボリュームのタイプです。

文字列 (例: performance)。

platform.openstack.cloud

clouds.yaml ファイルのクラウドリストにある使用する RHOCP クラウドの名前。

文字列 (例: MyCloud)。

platform.openstack.externalNetwork

インストールに使用される RHOSP の外部ネットワーク名。

文字列 (例: external)。

platform.openstack.computeFlavor

コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。

このプロパティーは非推奨にされています。すべてのマシンプールのデフォルトとしてフレーバーを使用するには、これを platform.openstack.defaultMachinePlatform プロパティーで type キーの値として追加します。それぞれのマシンプールのフレーバー値を個別に設定することもできます。

文字列 (例: m1.xlarge)。

5.13.5. オプションの RHOSP 設定パラメーター

オプションの RHOSP 設定パラメーターは、以下の表で説明されています。

表5.6 オプションの RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.additionalNetworkIDs

コンピュートマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

compute.platform.openstack.additionalSecurityGroupIDs

コンピュートマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

compute.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

compute.platform.openstack.rootVolume.zones

コンピュートマシンの root ボリュームをインストールするアベイラビリティーゾーン。このパラメーターに値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列のリスト (例: ["zone-1", "zone-2"])。

compute.platform.openstack.serverGroupPolicy

プール内のコンピュートマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

controlPlane.platform.openstack.additionalNetworkIDs

コントロールプレーンマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

コントロールプレーンマシンに接続されている追加のネットワークも、ブートストラップノードに接続されています。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

controlPlane.platform.openstack.additionalSecurityGroupIDs

コントロールプレーンマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

controlPlane.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.rootVolume.zones

コントロールプレーンマシンの root ボリュームをインストールするアベイラビリティーゾーン。この値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列の一覧 (例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.serverGroupPolicy

プール内のコントロールプレーンマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

platform.openstack.clusterOSImage

インストールプログラムが RHCOS イメージをダウンロードする場所。

ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。

HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。

例: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d。この値は、既存の Glance イメージの名前にもなり得ます (例: my-rhcos)。

platform.openstack.clusterOSImageProperties

Glance のインストーラーでアップロードされた ClusterOSImage に追加するプロパティー。このプロパティーは、platform.openstack.clusterOSImage が既存の Glance イメージに設定されている場合は無視されます。

このプロパティーを使用し、ノードあたり 26 PV の RHOSP のデフォルト永続ボリューム (PV) の制限を超過することができます。制限を超えるには、hw_scsi_model プロパティーの値を virtio-scsi に設定し、hw_disk_bus の値を scsi に設定します。

このプロパティーを使用し、hw_qemu_guest_agent プロパティーを yes の値で追加して QEMU ゲストエージェントを有効にすることもできます。

キーと値の文字列のペアのリスト。例: ["hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi"]

platform.openstack.defaultMachinePlatform

デフォルトのマシンプールプラットフォームの設定。 

{
   "type": "ml.large",
   "rootVolume": {
      "size": 30,
      "type": "performance"
   }
}

platform.openstack.ingressFloatingIP

Ingress ポートに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.apiFloatingIP

API ロードバランサーに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.externalDNS

クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。

文字列としての IP アドレスのリスト。例: ["8.8.8.8", "192.168.1.12"]

platform.openstack.machinesSubnet

クラスターのノードが使用する RHOSP サブネットの UUID。ノードおよび仮想 IP (VIP) ポートがこのサブネットに作成されます。

networking.machineNetwork の最初の項目は machinesSubnet の値に一致する必要があります。

カスタムサブネットにデプロイする場合、OpenShift Container Platform インストーラーに外部 DNS サーバーを指定することはできません。代わりに、DNS を RHOSP のサブネットに追加 します。

文字列としての UUID。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

5.13.6. RHOSP デプロイメントでのカスタムサブネット

オプションで、選択する Red Hat OpenStack Platform (RHOSP) サブネットにクラスターをデプロイすることができます。サブネットの GUID は、install-config.yaml ファイルの platform.openstack.machinesSubnet の値として渡されます。

このサブネットはクラスターのプライマリーサブネットとして使用されます。デフォルトで、ノードおよびポートはこの上に作成されます。platform.openstack.machinesSubnet プロパティーの値をサブネットの UUID に設定すると、異なる RHOSP サブネットにノードおよびポートを作成することができます。

カスタムサブネットを使用して OpenShift Container Platform インストーラーを実行する前に、設定が以下の要件を満たしていることを確認してください。

  • platform.openstack.machinesSubnet で使用されるサブネットで DHCP が有効にされている。
  • platform.openstack.machinesSubnet の CIDR は networking.machineNetwork の CIDR に一致する。
  • インストールプログラムのユーザーには、固定 IP アドレスを持つポートなど、このネットワークでポートを作成するパーミッションがある。

カスタムサブネットを使用するクラスターには、以下の制限があります。

  • Floating IP アドレスを使用するクラスターをインストールする予定の場合には、platform.openstack.machinesSubnet サブネットを externalNetwork ネットワークに接続されているルーターに接続する必要があります。
  • platform.openstack.machinesSubnet の値が install-config.yaml ファイルに設定されている場合、インストールプログラムは RHOSP マシンのプライベートネットワークまたはサブネットを作成しません。
  • platform.openstack.externalDNS プロパティーは、カスタムサブネットと同時に使用することはできません。カスタムサブネットを使用するクラスターに DNS を追加するには、RHOSP ネットワークで DNS を設定します。
注記

デフォルトでは、API VIP は x.x.x.5 を取得し、Ingress VIP はネットワークの CIDR ブロックから x.x.x.7 を取得します。これらのデフォルト値を上書きするには、DHCP 割り当てプール外の platform.openstack.apiVIPs および platform.openstack.ingressVIPs の値を設定します。

重要

ネットワークの CIDR 範囲は、クラスターのインストール後に調整できません。Red Hat は、namespace ごとに作成される Pod の数を慎重に検討する必要があるため、クラスターのインストール時に範囲を決定するための直接的なガイダンスを提供していません。

5.13.7. RHOSP のカスタマイズされた install-config.yaml ファイルのサンプル

このサンプル install-config.yaml は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。

重要

このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得する必要があります。 

apiVersion: v1
baseDomain: example.com
controlPlane:
  name: master
  platform: {}
  replicas: 3
compute:
- name: worker
  platform:
    openstack:
      type: ml.large
  replicas: 3
metadata:
  name: example
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
platform:
  openstack:
    cloud: mycloud
    externalNetwork: external
    computeFlavor: m1.xlarge
    apiFloatingIP: 128.0.0.1
fips: false
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

5.13.8. マシンのカスタムサブネットの設定

インストールプログラムがデフォルトで使用する IP 範囲は、OpenShift Container Platform のインストール時に作成する Neutron サブネットと一致しない可能性があります。必要な場合は、インストール設定ファイルを編集して、新規マシンの CIDR 値を更新します。

前提条件

  • OpenShift Container Platform インストールプログラムで生成された install-config.yaml ファイルがあります。

手順

  1. コマンドラインで、install-config.yaml が含まれるディレクトリーを参照します。

  2. そのディレクトリーからスクリプトを実行して install-config.yaml ファイルを編集するか、手動でファイルを更新します。

    • スクリプトを使用して値を設定するには、以下を実行します。 

      $ python -c '
import yaml;
path = "install-config.yaml";
data = yaml.safe_load(open(path));
data["networking"]["machineNetwork"] = [{"cidr": "192.168.0.0/18"}]; 1
open(path, "w").write(yaml.dump(data, default_flow_style=False))'
      1
      必要な Neutron サブネットに一致する値 (例: 192.0.2.0/24) を挿入します。
    • 値を手動で設定するには、ファイルを開き、networking.machineCIDR の値を必要な Neutron サブネットに一致する値に設定します。

5.13.9. コンピュートマシンプールを空にする

独自のインフラストラクチャーを使用するインストールを実行するには、インストール設定ファイルのコンピュートマシンの数をゼロに設定します。その後、これらのマシンを手動で作成します。

前提条件

  • OpenShift Container Platform インストールプログラムで生成された install-config.yaml ファイルがあります。

手順

  1. コマンドラインで、install-config.yaml が含まれるディレクトリーを参照します。

  2. そのディレクトリーからスクリプトを実行して install-config.yaml ファイルを編集するか、手動でファイルを更新します。

    • スクリプトを使用して値を設定するには、以下を実行します。 

      $ python -c '
import yaml;
path = "install-config.yaml";
data = yaml.safe_load(open(path));
data["compute"][0]["replicas"] = 0;
open(path, "w").write(yaml.dump(data, default_flow_style=False))'
    • 値を手動で設定するには、ファイルを開き、compute.<first entry>.replicas の値を 0 に設定します。

5.13.10. RHOSP プロバイダーネットワーク上のクラスターデプロイメント

プロバイダーネットワーク上のプライマリーネットワークインターフェイスを使用して、OpenShift Container Platform クラスターを Red Hat OpenStack Platform (RHOSP) にデプロイできます。プロバイダーネットワークは一般的に、インターネットへの到達に使用可能なパブリックネットワークに、プロジェクトが直接アクセスできるように使用します。ネットワーク作成プロセスの一環として、プロバイダーネットワークをプロジェクト間で共有することもできます。

RHOSP プロバイダーネットワークは、データセンター内の既存の物理ネットワークに直接マップします。RHOSP 管理者はこれらを作成する必要があります。

以下の例では、OpenShift Container Platform ワークロードはプロバイダーネットワークを使用してデータセンターに接続されます。

OpenStack 上の 4 つの OpenShift ワークロードを示す図。各ワークロードは、プロバイダーネットワークを使用して、NIC によって外部のデータセンターに接続されます。

プロバイダーネットワークにインストールされている OpenShift Container Platform クラスターは、テナントネットワークまたは Floating IP アドレスを必要としません。インストーラーは、インストール中にこれらのリソースを作成しません。

プロバイダーネットワークタイプの例には、フラット (タグなし) および VLAN (802.1Q タグ付き) が含まれます。

注記

クラスターは、ネットワークタイプが許可する限り多くのプロバイダーネットワーク接続をサポートできます。たとえば、VLAN ネットワークは、通常最大 4096 の接続をサポートします。

プロバイダーネットワークおよびテナントネットワークの詳細は、RHOSP のドキュメント を参照してください。

5.13.10.1. クラスターのインストールにおける RHOSP プロバイダーネットワーク要件

OpenShift Container Platform クラスターをインストールする前に、Red Hat OpenStack Platform (RHOSP) のデプロイメントおよびプロバイダーネットワークは、さまざまな条件を満たす必要があります。

  • RHOSP ネットワークサービス (Neutron) が有効化され、RHOSP ネットワーク API 経由でアクセス可能であること。
  • RHOSP ネットワークサービスでは、ポートセキュリティーと許可するアドレスペアの機能拡張が有効化 されていること。

  • プロバイダーネットワークは他のテナントと共有できます。

    ヒント

    --share フラグを指定して openstack network create コマンドを使用して、共有できるネットワークを作成します。

  • クラスターのインストールに使用する RHOSP プロジェクトは、プロバイダーネットワークと適切なサブネットを所有する必要があります。

    ヒント
    "openshift" という名前のプロジェクトのネットワークを作成するには、以下のコマンドを入力します。
    $ openstack network create --project openshift
    "openshift" という名前のプロジェクトのサブネットを作成するには、以下のコマンドを入力します。
    $ openstack subnet create --project openshift

    RHOSP でのネットワークの作成に関する詳細は、プロバイダーネットワークに関するドキュメント を参照してください。

    クラスターが admin ユーザーによって所有されている場合、そのユーザーとしてインストーラーを実行してネットワーク上でポートを作成する必要があります。

    重要

    プロバイダーネットワークは、クラスターの作成に使用される RHOSP プロジェクトによって所有されている必要があります。所有されていない場合は、RHOSP Compute サービス (Nova) はそのネットワークからポートを要求できません。

  • プロバイダーネットワークが、デフォルトで 169.254.169.254 である RHOSP メタデータサービスの IP アドレスに到達できることを確認します。

    RHOSP SDN とネットワークサービス設定によっては、サブネットを作成する際に、ルートを提供しなければならない場合があります。以下に例を示します。 

    $ openstack subnet create --dhcp --host-route destination=169.254.169.254/32,gateway=192.0.2.2 ...
  • オプション: ネットワークのセキュリティーを保護するには、単一のプロジェクトへのネットワークアクセスを制限する ロールベースのアクセス制御 (RBAC) ルールを作成します。
5.13.10.2. プロバイダーネットワークにプライマリーインターフェイスを持つクラスターのデプロイ

Red Hat OpenStack Platform (RHOSP) プロバイダーネットワーク上にプライマリーネットワークインターフェイスを持つ OpenShift Container Platform クラスターをデプロイすることができます。

前提条件

  • 「クラスターのインストールにおける RHOSP プロバイダーネットワーク要件」に記載されているとおりに、お使いの Red Hat OpenStack Platform (RHOSP) のデプロイメントが設定されています。

手順

  1. テキストエディターで install-config.yaml ファイルを開きます。
  2. platform.openstack.apiVIPs プロパティーの値を API VIP の IP アドレスに設定します。
  3. platform.openstack.ingressVIPs プロパティーの値を Ingress VIP の IP アドレスに設定します。
  4. platform.openstack.machinesSubnet プロパティーの値をプロバイダーネットワークサブネットの UUID に設定します。
  5. networking.machineNetwork.cidr プロパティーの値をプロバイダーネットワークサブネットの CIDR ブロックに設定します。
重要

platform.openstack.apiVIPs プロパティーおよび platform.openstack.ingressVIPs プロパティーはいずれも、networking.machineNetwork.cidr ブロックから割り当てられていない IP アドレスである必要があります。

RHOSP プロバイダーネットワークに依存するクラスターのインストール設定ファイルのセクション

        ...
        platform:
          openstack:
            apiVIPs: 1
              - 192.0.2.13
            ingressVIPs: 2
              - 192.0.2.23
            machinesSubnet: fa806b2f-ac49-4bce-b9db-124bc64209bf
            # ...
        networking:
          machineNetwork:
          - cidr: 192.0.2.0/24

1 2
OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。
警告

プライマリーネットワークインターフェイスにプロバイダーネットワークを使用している間は、platform.openstack.externalNetwork パラメーターまたは platform.openstack.externalDNS パラメーターを設定することはできません。

クラスターをデプロイする際に、インストーラーは install-config.yaml ファイルを使用してプロバイダーネットワークにクラスターをデプロイします。

ヒント

プロバイダーネットワークを含むネットワークを platform.openstack.additionalNetworkIDs リストに追加できます。

クラスターのデプロイ後に、Pod を追加のネットワークに接続することができます。詳細は、複数ネットワークについて を参照してください。

5.14. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。

重要
  • OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

前提条件

  • OpenShift Container Platform インストールプログラムを取得していること。
  • install-config.yaml インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。 

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> については、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。

  2. コントロールプレーンマシンおよびコンピュートマシンセットを定義する Kubernetes マニフェストファイルを削除します。 

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

    これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

    • コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。

  3. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。

  4. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。 

    $ ./openshift-install create ignition-configs --dir <installation_directory> 1
    1
    <installation_directory> には、同じインストールディレクトリーを指定します。

    Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。 

    .
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign

  5. メタデータファイルの infraID キーを環境変数としてエクスポートします。 

    $ export INFRA_ID=$(jq -r .infraID metadata.json)
ヒント

metadata.json から infraID キーを抽出し、作成するすべての RHOSP リソースの接頭辞として使用します。これを実行することで、同じプロジェクトで複数のデプロイメントを実行する際に名前の競合が発生しないようにします。

5.15. ブートストラップ Ignition ファイルの準備

OpenShift Container Platform インストールプロセスは、ブートストラップ Ignition 設定ファイルから作成されるブートストラップマシンに依存します。

ファイルを編集し、アップロードします。次に、Red Hat OpenStack Platform (RHOSP) がプライマリーファイルをダウンロードする際に使用するセカンダリーブートストラップ Ignition 設定ファイルを作成します。

前提条件

  • インストーラープログラムが生成するブートストラップ Ignition ファイル bootstrap.ign があります。

  • インストーラーのメタデータファイルのインフラストラクチャー ID は環境変数 ($INFRA_ID) として設定されます。

    • 変数が設定されていない場合は、Kubernetes マニフェストおよび Ignition 設定ファイルの作成 を参照してください。

  • HTTP(S) でアクセス可能な方法でブートストラップ Ignition ファイルを保存できます。

    • 記載された手順では RHOSP イメージサービス (Glance) を使用しますが、RHOSP ストレージサービス (Swift)、Amazon S3、内部 HTTP サーバー、またはアドホックの Nova サーバーを使用することもできます。

手順

  1. 以下の Python スクリプトを実行します。スクリプトはブートストラップ Ignition ファイルを変更して、ホスト名および利用可能な場合は、実行時の CA 証明書ファイルを設定します。 

    import base64
import json
import os

with open('bootstrap.ign', 'r') as f:
    ignition = json.load(f)

files = ignition['storage'].get('files', [])

infra_id = os.environ.get('INFRA_ID', 'openshift').encode()
hostname_b64 = base64.standard_b64encode(infra_id + b'-bootstrap\n').decode().strip()
files.append(
{
    'path': '/etc/hostname',
    'mode': 420,
    'contents': {
        'source': 'data:text/plain;charset=utf-8;base64,' + hostname_b64
    }
})

ca_cert_path = os.environ.get('OS_CACERT', '')
if ca_cert_path:
    with open(ca_cert_path, 'r') as f:
        ca_cert = f.read().encode()
        ca_cert_b64 = base64.standard_b64encode(ca_cert).decode().strip()

    files.append(
    {
        'path': '/opt/openshift/tls/cloud-ca-cert.pem',
        'mode': 420,
        'contents': {
            'source': 'data:text/plain;charset=utf-8;base64,' + ca_cert_b64
        }
    })

ignition['storage']['files'] = files;

with open('bootstrap.ign', 'w') as f:
    json.dump(ignition, f)

  2. RHOSP CLI を使用して、ブートストラップ Ignition ファイルを使用するイメージを作成します。 

    $ openstack image create --disk-format=raw --container-format=bare --file bootstrap.ign <image_name>

  3. イメージの詳細を取得します。 

    $ openstack image show <image_name>

    file 値をメモします。これは v2/images/<image_ID>/file パターンをベースとしています。

    注記

    作成したイメージがアクティブであることを確認します。

  4. イメージサービスのパブリックアドレスを取得します。 

    $ openstack catalog show image
  5. パブリックアドレスとイメージ file 値を組み合わせ、結果を保存場所として保存します。この場所は、<image_service_public_URL>/v2/images/<image_ID>/file パターンをベースとしています。

  6. 認証トークンを生成し、トークン ID を保存します。 

    $ openstack token issue -c id -f value

  7. $INFRA_ID-bootstrap-ignition.json というファイルに以下のコンテンツを挿入し、独自の値に一致するようにプレースホルダーを編集します。 

    {
  "ignition": {
    "config": {
      "merge": [{
        "source": "<storage_url>", 1
        "httpHeaders": [{
          "name": "X-Auth-Token", 2
          "value": "<token_ID>" 3
        }]
      }]
    },
    "security": {
      "tls": {
        "certificateAuthorities": [{
          "source": "data:text/plain;charset=utf-8;base64,<base64_encoded_certificate>" 4
        }]
      }
    },
    "version": "3.2.0"
  }
}
    1
    ignition.config.append.source の値をブートストラップ Ignition ファイルのストレージ URL に置き換えます。
    2
    httpHeaders の name を "X-Auth-Token" に設定します。
    3
    httpHeaders の value をトークンの ID に設定します。
    4
    ブートストラップ Ignition ファイルサーバーが自己署名証明書を使用する場合は、base64 でエンコードされた証明書を含めます。
  8. セカンダリー Ignition 設定ファイルを保存します。

ブートストラップ Ignition データはインストール時に RHOSP に渡されます。

警告

ブートストラップ Ignition ファイルには、clouds.yaml 認証情報などの機密情報が含まれます。これを安全な場所に保存し、インストールプロセスの完了後に削除します。

5.16. RHOSP でのコントロールプレーンの Ignition 設定ファイルの作成

独自のインフラストラクチャーを使用して OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールするには、コントロールプレーンの Ignition 設定ファイルが必要です。複数の設定ファイルを作成する必要があります。

注記

ブートストラップ Ignition 設定と同様に、各コントロールプレーンマシンのホスト名を明示的に定義する必要があります。

前提条件

  • インストールプログラムのメタデータファイルのインフラストラクチャー ID は環境変数 ($INFRA_ID) として設定されます。

    • 変数が設定されていない場合は、「Kubernetes マニフェストおよび Ignition 設定ファイルの作成」を参照してください。

手順

  • コマンドラインで、以下の Python スクリプトを実行します。 

    $ for index in $(seq 0 2); do
    MASTER_HOSTNAME="$INFRA_ID-master-$index\n"
    python -c "import base64, json, sys;
ignition = json.load(sys.stdin);
storage = ignition.get('storage', {});
files = storage.get('files', []);
files.append({'path': '/etc/hostname', 'mode': 420, 'contents': {'source': 'data:text/plain;charset=utf-8;base64,' + base64.standard_b64encode(b'$MASTER_HOSTNAME').decode().strip(), 'verification': {}}, 'filesystem': 'root'});
storage['files'] = files;
ignition['storage'] = storage
json.dump(ignition, sys.stdout)" <master.ign >"$INFRA_ID-master-$index-ignition.json"
done

    以下の 3 つのコントロールプレーン Ignition ファイルが作成されます。<INFRA_ID>-master-0-ignition.json、<INFRA_ID>-master-1-ignition.json、および <INFRA_ID>-master-2-ignition.json。

5.17. RHOSP でのネットワークリソースの作成

独自のインフラストラクチャーを使用する Red Hat OpenStack Platform (RHOSP) インストールの OpenShift Container Platform に必要なネットワークリソースを作成します。時間を節約するには、セキュリティーグループ、ネットワーク、サブネット、ルーター、およびポートを生成する指定された Ansible Playbook を実行します。

前提条件

  • Python 3 がマシンにインストールされている。
  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。

手順

  1. オプション: 外部ネットワークの値を inventory.yaml Playbook に追加します。

    inventory.yaml Ansible Playbook の外部ネットワーク値の例

    ...
      # The public network providing connectivity to the cluster. If not
      # provided, the cluster external connectivity must be provided in another
      # way.

      # Required for os_api_fip, os_ingress_fip, os_bootstrap_fip.
      os_external_network: 'external'
...

    重要

    inventory.yaml ファイルの os_external_network の値を指定しなかった場合は、仮想マシンが Glance および外部接続にアクセスできるようにする必要があります。

  2. オプション: 外部ネットワークおよび Floating IP (FIP) アドレスの値を inventory.yaml Playbook に追加します。

    inventory.yaml Ansible Playbook の FIP 値の例

    ...
      # OpenShift API floating IP address. If this value is non-empty, the
      # corresponding floating IP will be attached to the Control Plane to
      # serve the OpenShift API.
      os_api_fip: '203.0.113.23'

      # OpenShift Ingress floating IP address. If this value is non-empty, the
      # corresponding floating IP will be attached to the worker nodes to serve
      # the applications.
      os_ingress_fip: '203.0.113.19'

      # If this value is non-empty, the corresponding floating IP will be
      # attached to the bootstrap machine. This is needed for collecting logs
      # in case of install failure.
      os_bootstrap_fip: '203.0.113.20'

    重要

    os_api_fip および os_ingress_fip の値を定義しない場合、インストール後のネットワーク設定を実行する必要があります。

    os_bootstrap_fip の値を定義しない場合、インストーラーは失敗したインストールからデバッグ情報をダウンロードできません。

    詳細は、環境へのアクセスの有効化を参照してください。

  3. コマンドラインで、security-groups.yaml Playbook を実行してセキュリティーグループを作成します。 

    $ ansible-playbook -i inventory.yaml security-groups.yaml

  4. コマンドラインで、network.yaml Playbook を実行して、ネットワーク、サブネット、およびルーターを作成します。 

    $ ansible-playbook -i inventory.yaml network.yaml

  5. オプション: Nova サーバーが使用するデフォルトのリゾルバーを制御する必要がある場合は、RHOSP CLI コマンドを実行します。 

    $ openstack subnet set --dns-nameserver <server_1> --dns-nameserver <server_2> "$INFRA_ID-nodes"

オプションで、作成した inventory.yaml ファイルを使用してインストールをカスタマイズできます。たとえば、ベアメタルマシンを使用するクラスターをデプロイすることができます。

5.17.1. ベアメタルマシンを使用したクラスターのデプロイ

クラスターがベアメタルマシンを使用する必要がある場合は、inventory.yaml ファイルを変更します。クラスターには、ベアメタル上でコントロールプレーンとコンピュートマシンの両方を実行させることも、コンピュートマシンのみを実行させることもできます。

ベアメタルコンピュートマシンは、Kuryr を使用するクラスターではサポートされません。

注記

install-config.yaml ファイルで、ベアメタルワーカーに使用する RHOSP ネットワークが Floating IP アドレスをサポートするかどうかが反映されていることを確認します。

前提条件

  • RHOSP Bare Metal サービス (Ironic) が有効になっており、RHOSP Compute API 経由でアクセスできる。
  • ベアメタルを RHOSP フレーバー として利用できる。
  • クラスターが 16.1.6 以降、16.2.4 未満の RHOSP バージョンで実行している場合は、メタデータサービスが OpenShift Container Platform ノード上のサービスで使用できなくなる 既知の問題 により、ベアメタルワーカーは機能しません。
  • RHOSP ネットワークが、仮想マシンとベアメタルサーバーの両方の接続をサポートしている。
  • 既存のネットワークにマシンをデプロイする場合、RHOSP サブネットがプロビジョニングされている。
  • インストーラーによってプロビジョニングされるネットワークにマシンをデプロイする場合、RHOSP Bare Metal サービス (Ironic) が、テナントネットワークで実行される Preboot eXecution Environment (PXE) ブートマシンをリッスンして通信することができる。
  • inventory.yaml ファイルを OpenShift Container Platform インストールプロセスの一部として作成している。

手順

  1. inventory.yaml ファイルで、マシンのフレーバーを編集します。

    1. ベアメタルコントロールプレーンマシンを使用する場合は、os_flavor_master の値をベアメタルフレーバーに変更します。

    2. os_flavor_worker の値をベアメタルフレーバーに変更します。

      ベアメタルの inventory.yaml のサンプルファイル

      all:
  hosts:
    localhost:
      ansible_connection: local
      ansible_python_interpreter: "{{ansible_playbook_python}}"

      # User-provided values
      os_subnet_range: '10.0.0.0/16'
      os_flavor_master: 'my-bare-metal-flavor' 1
      os_flavor_worker: 'my-bare-metal-flavor' 2
      os_image_rhcos: 'rhcos'
      os_external_network: 'external'
...

      1
      ベアメタルのコントロールプレーンマシンを使用する必要がある場合は、この値をベアメタルのフレーバーに変更します。
      2
      この値を、コンピュートマシンに使用するベアメタルのフレーバーに変更します。

更新された inventory.yaml ファイルを使用してインストールプロセスを完了します。デプロイメント時に作成されるマシンは、ファイルに追加したフレーバーを使用します。

注記

インストーラーは、ベアメタルマシンの起動中にタイムアウトする可能性があります。

インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。 

$ ./openshift-install wait-for install-complete --log-level debug

5.18. RHOSP でのブートストラップマシンの作成

ブートストラップマシンを作成し、これに Red Hat OpenStack Platform (RHOSP) で実行するために必要なネットワークアクセスを付与します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • inventory.yaml、common.yaml、および bootstrap.yaml Ansible Playbook は共通ディレクトリーにある。
  • インストールプログラムが作成した metadata.json ファイルが Ansible Playbook と同じディレクトリーにあります。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。

  2. コマンドラインで、bootstrap.yaml Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml bootstrap.yaml

  3. ブートストラップサーバーがアクティブになった後に、ログを表示し、Ignition ファイルが受信されたことを確認します。 

    $ openstack console log show "$INFRA_ID-bootstrap"

5.19. RHOSP でのコントロールプレーンの作成

生成した Ignition 設定ファイルを使用して 3 つのコントロールプレーンマシンを作成します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • インストールプログラムのメタデータファイルのインフラストラクチャー ID は環境変数 ($INFRA_ID) として設定されます。
  • inventory.yaml、common.yaml、および control-plane.yaml Ansible Playbook は共通ディレクトリーにあります。
  • 「コントロールプレーンの Ignition 設定ファイルの作成」で作成された 3 つの Ignition ファイルがある。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。
  2. コントロールプレーン Ignition 設定ファイルが作業ディレクトリーにない場合、それらをここにコピーします。

  3. コマンドラインで、control-plane.yaml Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml control-plane.yaml

  4. 以下のコマンドを実行してブートストラッププロセスをモニターします。 

    $ openshift-install wait-for bootstrap-complete

    コントロールプレーンマシンが実行され、クラスターに参加していることを確認できるメッセージが表示されます。 

    INFO API v1.25.0 up
INFO Waiting up to 30m0s for bootstrapping to complete...
...
INFO It is now safe to remove the bootstrap resources

5.20. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。 

    $ oc whoami

    出力例

    system:admin

5.21. RHOSP からのブートストラップリソースの削除

不要になったブートストラップリソースを削除します。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • inventory.yaml、common.yaml、および down-bootstrap.yaml Ansible Playbook が共通ディレクトリーにある。

  • コントロールプレーンマシンが実行中である。

    • マシンのステータスが不明な場合は、「クラスターステータスの確認」を参照してください。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。

  2. コマンドラインで、down-bootstrap.yaml Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml down-bootstrap.yaml

ブートストラップポート、サーバー、および Floating IP アドレスが削除されます。

警告

ブートストラップ Ignition ファイル URL をまだ無効にしていない場合は、無効にしてください。

5.22. RHOSP でのコンピュートマシンの作成

コントロールプレーンの起動後、コンピュートマシンを作成します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • inventory.yaml、common.yaml、および compute-nodes.yaml Ansible Playbook が共通ディレクトリーにある。
  • インストールプログラムが作成した metadata.json ファイルが Ansible Playbook と同じディレクトリーにあります。
  • コントロールプレーンが有効である。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。

  2. コマンドラインで Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml compute-nodes.yaml

次のステップ

  • マシンの証明書署名要求を承認します。

5.23. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.25.0
master-1  Ready     master  63m  v1.25.0
master-2  Ready     master  64m  v1.25.0

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。 

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。 

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。 

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。 

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.25.0
master-1  Ready     master  73m  v1.25.0
master-2  Ready     master  74m  v1.25.0
worker-0  Ready     worker  11m  v1.25.0
worker-1  Ready     worker  11m  v1.25.0

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

5.24. インストールの正常な実行の確認

OpenShift Container Platform のインストールが完了していることを確認します。

前提条件

  • インストールプログラム (openshift-install) があります。

手順

  • コマンドラインで、以下を入力します。 

    $ openshift-install --log-level debug wait-for install-complete

プログラムはコンソール URL と管理者のログイン情報を出力します。

5.25. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

5.26. 次のステップ

第6章 独自のインフラストラクチャーでの Kuryr を使用する OpenStack へのクラスターのインストール

重要

Kuryr は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、または削除された主な機能の最新の一覧については、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

OpenShift Container Platform バージョン 4.12 では、ユーザーによってプロビジョニングされたインフラストラクチャーで実行される Red Hat OpenStack Platform (RHOSP) にクラスターをインストールできます。

独自のインフラストラクチャーを使用することで、クラスターを既存のインフラストラクチャーおよび変更と統合できます。このプロセスでは、installer-provisioned installation の場合よりも多くの手作業が必要になります。Nova サーバー、Neutron ポート、セキュリティーグループなどのすべての RHOSP リソースを作成する必要があるためです。ただし、Red Hat では、デプロイメントプロセスを支援する Ansible Playbook を提供しています。

6.1. 前提条件

6.2. Kuryr SDN について

重要

Kuryr は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧については、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

Kuryr は、Neutron および Octavia Red Hat OpenStack Platform (RHOSP) サービスを使用して Pod およびサービスのネットワークを提供する Container Network Interface (CNI) プラグインです。

Kuryr と OpenShift Container Platform の統合は主に、RHOSP の仮想マシンで実行する OpenShift Container Platform クラスター用に設計されました。Kuryr は、OpenShift Container Platform Pod を RHOSP SDN にプラグインしてネットワークのパフォーマンスを強化します。さらに、これは Pod と RHOSP 仮想インスタンス間の接続を可能にします。

Kuryr コンポーネントは openshift-kuryr namespace を使用して OpenShift Container Platform の Pod としてインストールされます。

  • kuryr-controller: master ノードにインストールされる単一のサービスインスタンスです。これは、OpenShift Container Platform で Deployment としてモデリングされます。
  • kuryr-cni: 各 OpenShift Container Platform ノードで Kuryr を CNI ドライバーとしてインストールし、設定するコンテナーです。これは、OpenShift Container Platform で DaemonSet オブジェクトとしてモデリングされます。

Kuryr コントローラーは OpenShift Container Platform API サーバーで Pod、サービスおよび namespace の作成、更新、および削除イベントについて監視します。これは、OpenShift Container Platform API 呼び出しを Neutron および Octavia の対応するオブジェクトにマップします。そのため、Neutron トランクポート機能を実装するすべてのネットワークソリューションを使用して、Kuryr 経由で OpenShift Container Platform をサポートすることができます。これには、Open vSwitch (OVS) および Open Virtual Network (OVN) などのオープンソースソリューションや Neutron と互換性のある市販の SDN が含まれます。

Kuryr は、カプセル化された RHOSP テナントネットワーク上の OpenShift Container Platform デプロイメントに使用することが推奨されています。これは、 RHOSP ネットワークでカプセル化された OpenShift Container Platform SDN を実行するなど、二重のカプセル化を防ぐために必要です。

プロバイダーネットワークまたはテナント VLAN を使用する場合は、二重のカプセル化を防ぐために Kuryr を使用する必要はありません。パフォーマンス上の利点はそれほど多くありません。ただし、設定によっては、Kuryr を使用して 2 つのオーバーレイが使用されないようにすることには利点がある場合があります。

Kuryr は、以下のすべての基準が true であるデプロイメントでは推奨されません。

  • RHOSP のバージョンが 16 よりも前のバージョンである。
  • デプロイメントで UDP サービスが使用されているか、少数のハイパーバイザーで多数の TCP サービスが使用されている。

または、以下を実行します。

  • ovn-octavia Octavia ドライバーが無効にされている。
  • デプロイメントで、少数のハイパーバイザーで多数の TCP サービスが使用されている。

6.3. Kuryr を使用して OpenShift Container Platform を RHOSP にインストールするためのリソースのガイドライン

Kuryr SDN を使用する場合、Pod、サービス、namespace およびネットワークポリシーは RHOSP クォータのリソースを使用します。これにより、最小要件が増加します。また、Kuryr にはデフォルトインストールに必要な要件以外の追加要件があります。

以下のクォータを使用してデフォルトのクラスターの最小要件を満たすようにします。

表6.1 Kuryr を使用する RHOSP のデフォルト OpenShift Container Platform クラスターについての推奨リソース
リソース値

Floating IP アドレス

3: LoadBalancer タイプに予想されるサービス数

ポート

1500: Pod ごとに 1 つ必要

ルーター

1

サブネット

250: namespace/プロジェクトごとに 1 つ必要

ネットワーク

250: namespace/プロジェクトごとに 1 つ必要

RAM

112 GB

vCPU

28

ボリュームストレージ

275 GB

インスタンス

7

セキュリティーグループ

250: サービスおよび NetworkPolicy ごとに 1 つ必要

セキュリティーグループルール

1000

サーバーグループ

2 - 各マシンプールの追加のアベイラビリティーゾーンごとに 1 つ追加

ロードバランサー

100: サービスごとに 1 つ必要

ロードバランサーリスナー

500: サービスで公開されるポートごとに 1 つ必要

ロードバランサーノード

500: サービスで公開されるポートごとに 1 つ必要

クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。

重要

RHOSP オブジェクトストレージ (Swift) が利用可能で、swiftoperator ロールを持つユーザーアカウントによって操作されている場合、これは OpenShift Container Platform イメージレジストリーのデフォルトバックエンドとして使用されます。この場合、ボリュームストレージ要件は 175 GB です。Swift 領域要件は、イメージレジストリーのサイズによって異なります。

重要

OVN Octavia ドライバーではなく Amphora ドライバーで Red Hat OpenStack Platform(RHOSP) バージョン 16 を使用している場合、セキュリティーグループはユーザープロジェクトではなくサービスアカウントに関連付けられます。

リソースを設定する際には、以下の点に注意してください。

  • 必要なポート数は Pod 数よりも大きくなる。Kuryr はポートプールを使用して、事前に作成済みのポートを Pod で使用できるようにし、Pod の起動時間を短縮します。
  • 各ネットワークポリシーは RHOSP セキュリティーグループにマップされ、NetworkPolicy 仕様によっては 1 つ以上のルールがセキュリティーグループに追加される。

  • 各サービスは RHOSP ロードバランサーにマップされる。クォータに必要なセキュリティーグループの数を見積もる場合には、この要件を考慮してください。

    RHOSP バージョン 15 以前のバージョン、または ovn-octavia driver を使用している場合、各ロードバランサーにはユーザープロジェクトと共にセキュリティーグループがあります。

  • クォータはロードバランサーのリソース (VM リソースなど) を考慮しませんが、RHOSP デプロイメントのサイズを決定する際にはこれらのリソースを考慮する必要があります。デフォルトのインストールには 50 を超えるロードバランサーが あり、クラスターはそれらのロードバランサーに対応できる必要があります。

    OVN Octavia ドライバーを有効にして RHOSP バージョン 16 を使用している場合は、1 つのロードバランサー仮想マシンのみが生成され、サービスは OVN フロー経由で負荷分散されます。

OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで設定されます。

Kuryr SDN を有効にするには、使用する環境が以下の要件を満たしている必要があります。

  • RHOSP 13+ を実行します。
  • オーバークラウドと Octavia を使用します。
  • Neutron トランクポートの拡張を使用します。
  • ML2/OVS Neutron ドライバーが ovs-hybrid の代わりに使用れる場合、openvswitch ファイアウォールドライバーを使用します。

6.3.1. クォータの拡大

Kuryr SDN を使用する場合、Pod、サービス、namespace、およびネットワークポリシーが使用する Red Hat OpenStack Platform (RHOSP) リソースに対応するためにクォータを引き上げる必要があります。

手順

  • 以下のコマンドを実行して、プロジェクトのクォータを増やします。 

    $ sudo openstack quota set --secgroups 250 --secgroup-rules 1000 --ports 1500 --subnets 250 --networks 250 <project>

6.3.2. Neutron の設定

Kuryr CNI は Neutron トランクの拡張を使用してコンテナーを Red Hat OpenStack Platform (RHOSP) SDN にプラグインします。したがって、Kuryr が適切に機能するには trunks 拡張を使用する必要があります。

さらにデフォルトの ML2/OVS Neutron ドライバーを使用する場合には、セキュリティーグループがトランクサブポートで実行され、Kuryr がネットワークポリシーを適切に処理できるように、ovs_hybrid ではなく openvswitch に設定される必要があります。

6.3.3. Octavia の設定

Kuryr SDN は Red Hat OpenStack Platform (RHOSP) の Octavia LBaaS を使用して OpenShift Container Platform サービスを実装します。したがって、Kuryr SDN を使用するように RHOSP に Octavia コンポーネントをインストールし、設定する必要があります。

Octavia を有効にするには、Octavia サービスを RHOSP オーバークラウドのインストール時に組み込むか、オーバークラウドがすでに存在する場合は Octavia サービスをアップグレードする必要があります。Octavia を有効にする以下の手順は、オーバークラウドのクリーンインストールまたはオーバークラウドの更新の両方に適用されます。

注記

以下の手順では、Octavia を使用する場合に RHOSP のデプロイメント 時に必要となる主な手順のみを説明します。また、レジストリーメソッド が変更されることにも留意してください。

以下の例では、ローカルレジストリーの方法を使用しています。

手順

  1. ローカルレジストリーを使用している場合、イメージをレジストリーにアップロードするためのテンプレートを作成します。以下に例を示します。 

    (undercloud) $ openstack overcloud container image prepare \
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \
--namespace=registry.access.redhat.com/rhosp13 \
--push-destination=<local-ip-from-undercloud.conf>:8787 \
--prefix=openstack- \
--tag-from-label {version}-{product-version} \
--output-env-file=/home/stack/templates/overcloud_images.yaml \
--output-images-file /home/stack/local_registry_images.yaml

  2. local_registry_images.yaml ファイルに Octavia イメージが含まれることを確認します。以下に例を示します。 

    ...
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-api:13.0-43
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-health-manager:13.0-45
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-housekeeping:13.0-45
  push_destination: <local-ip-from-undercloud.conf>:8787
- imagename: registry.access.redhat.com/rhosp13/openstack-octavia-worker:13.0-44
  push_destination: <local-ip-from-undercloud.conf>:8787
    注記

    Octavia コンテナーのバージョンは、インストールされている特定の RHOSP リリースによって異なります。

  3. コンテナーイメージを registry.redhat.io からアンダークラウドノードにプルします。 

    (undercloud) $ sudo openstack overcloud container image upload \
  --config-file  /home/stack/local_registry_images.yaml \
  --verbose

    これには、ネットワークおよびアンダークラウドディスクの速度に応じて多少の時間がかかる可能性があります。

  4. Octavia を使用してオーバークラウドをインストールまたは更新します。 

    $ openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \
  -e octavia_timeouts.yaml
    注記

    このコマンドには、Octavia に関連付けられたファイルのみが含まれます。これは、RHOSP の特定のインストールによって異なります。詳細は RHOSP のドキュメントを参照してください。Octavia インストールのカスタマイズについての詳細は、Octavia デプロイメントのプランニング を参照してください。

    注記

    Kuryr SDN を利用する際には、オーバークラウドのインストールに Neutron の trunk 拡張機能が必要です。これは、Director デプロイメントでデフォルトで有効にされます。Neutron バックエンドが ML2/OVS の場合、デフォルトの ovs-hybrid の代わりに openvswitch ファイアウォールを使用します。バックエンドが ML2/OVN の場合には変更の必要がありません。

6.3.3.1. Octavia OVN ドライバー

Octavia は Octavia API を使用して複数のプロバイダードライバーをサポートします。

利用可能なすべての Octavia プロバイダードライバーをコマンドラインで表示するには、以下を入力します。 

$ openstack loadbalancer provider list

出力例

+---------+-------------------------------------------------+
| name    | description                                     |
+---------+-------------------------------------------------+
| amphora | The Octavia Amphora driver.                     |
| octavia | Deprecated alias of the Octavia Amphora driver. |
| ovn     | Octavia OVN driver.                             |
+---------+-------------------------------------------------+

RHOSP バージョン 16 以降、Octavia OVN プロバイダードライバー (ovn) は RHOSP デプロイメントの OpenShift Container Platform でサポートされます。

ovn は、Octavia および OVN が提供する負荷分散用の統合ドライバーです。これは基本的な負荷分散機能をサポートし、OpenFlow ルールに基づいています。このドライバーは、OVN Neutron ML2 を使用するデプロイメント上の director により Octavia で自動的に有効にされます。

Amphora プロバイダードライバーがデフォルトのドライバーです。ただし、ovn が有効にされる場合には、Kuryr がこれを使用します。

Kuryr が Amphora の代わりに ovn を使用する場合は、以下の利点があります。

  • リソース要件が減少します。Kuryr は、各サービスにロードバランサーの仮想マシンを必要としません。
  • ネットワークレイテンシーが短縮されます。
  • サービスごとに仮想マシンを使用する代わりに、OpenFlow ルールを使用することで、サービスの作成速度が上がります。
  • Amphora 仮想マシンで集中管理されるのではなく、すべてのノードに分散負荷分散アクションが分散されます。

6.3.4. Kuryr を使用したインストールについての既知の制限

OpenShift Container Platform を Kuryr SDN で使用する場合、いくつかの既知の制限があります。

RHOSP の一般的な制限

OpenShift Container Platform を Kuryr SDN と共に使用する場合は、すべてのバージョンおよび環境に適用されるいくつかの制限があります。

  • NodePort タイプの Service オブジェクトはサポートされません。
  • OVN Octavia プロバイダーを使用するクラスターは、Service オブジェクトをサポートします。このオブジェクトについて、.spec.selector プロパティーは、Endpoints オブジェクトの .subsets.addresses プロパティーにノードまたは Pod のサブネットが含まれる場合は指定されません。
  • マシンが作成されるサブネットがルーターに接続されていない場合や、サブネットが接続されていても、ルーターに外部ゲートウェイが設定されていない場合、Kuryr はタイプが LoadBalancer の Service オブジェクトの Floating IP を作成できません。
  • Service オブジェクトで sessionAffinity=ClientIP プロパティーを設定しても効果はありません。Kuryr はこの設定をサポートしていません。
RHOSP バージョンの制限

OpenShift Container Platform を Kuryr SDN で使用する場合は、RHOSP バージョンに依存するいくつかの制限があります。

  • RHOSP の 16 よりも前のバージョンでは、デフォルトの Octavia ロードバランサードライバー (Amphora) を使用します。このドライバーでは、OpenShift Container Platform サービスごとに 1 つの Amphora ロードバランサー仮想マシンをデプロイする必要があります。サービス数が多すぎると、リソースが不足する可能性があります。

    OVN Octavia ドライバーが無効にされている以降のバージョンの RHOSP のデプロイメントでも Amphora ドライバーを使用します。この場合も、RHOSP の以前のバージョンと同じリソースに関する懸念事項を考慮する必要があります。

  • Kuryr SDN は、サービスによる自動解凍をサポートしていません。
RHOSP のアップグレードの制限

RHOSP のアップグレードプロセスにより、Octavia API が変更され、ロードバランサーに使用される Amphora イメージへのアップグレードが必要になる可能性があります。

API の変更に個別に対応できます。

Amphora イメージがアップグレードされると、RHOSP Operator は既存のロードバランサー仮想マシンを 2 つの方法で処理できます。

Operator が最初のオプションを選択する場合、フェイルオーバー時に短い時間のダウンタイムが生じる可能性があります。

Operator が 2 つ目のオプションを選択する場合、既存のロードバランサーは UDP リスナーなどのアップグレードされた Octavia API 機能をサポートしません。この場合、ユーザーはこれらの機能を使用するためにサービスを再作成する必要があります。

6.3.5. コントロールプレーンマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコントロールプレーンマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

6.3.6. コンピュートマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコンピューティングマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 8 GB のメモリーと 2 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量
ヒント

コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。

6.3.7. ブートストラップマシン

インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。

ブートストラップマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

6.4. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

6.5. Playbook 依存関係のダウンロード

user-provisioned infrastructure でのインストールプロセスを単純化する Ansible Playbook には、複数の Python モジュールが必要です。インストーラーを実行するマシンで、モジュールのリポジトリーを追加し、それらをダウンロードします。

注記

この手順では、Red Hat Enterprise Linux (RHEL) 8 を使用していることを前提としています。

前提条件

  • Python 3 がマシンにインストールされている。

手順

  1. コマンドラインで、リポジトリーを追加します。

    1. Red Hat Subscription Manager に登録します。 

      $ sudo subscription-manager register # If not done already

    2. 最新のサブスクリプションデータをプルします。 

      $ sudo subscription-manager attach --pool=$YOUR_POOLID # If not done already

    3. 現在のリポジトリーを無効にします。 

      $ sudo subscription-manager repos --disable=* # If not done already

    4. 必要なリポジトリーを追加します。 

      $ sudo subscription-manager repos \
  --enable=rhel-8-for-x86_64-baseos-rpms \
  --enable=openstack-16-tools-for-rhel-8-x86_64-rpms \
  --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
  --enable=rhel-8-for-x86_64-appstream-rpms

  2. モジュールをインストールします。 

    $ sudo yum install python3-openstackclient ansible python3-openstacksdk python3-netaddr ansible-collections-openstack

  3. python コマンドが python3 を参照していることを確認します。 

    $ sudo alternatives --set python /usr/bin/python3

6.6. インストール Playbook のダウンロード

OpenShift Container Platform を独自の Red Hat OpenStack Platform (RHOSP) インフラストラクチャーにインストールするために使用できる Ansible Playbook をダウンロードします。

前提条件

  • curl コマンドラインツールがマシンで利用できる。

手順

  • Playbook を作業ディレクトリーにダウンロードするには、コマンドラインから以下のスクリプトを実行します。 

    $ xargs -n 1 curl -O <<< '
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/bootstrap.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/common.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/compute-nodes.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/control-plane.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/inventory.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/network.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/security-groups.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-bootstrap.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-compute-nodes.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-control-plane.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-load-balancers.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-network.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-security-groups.yaml
        https://raw.githubusercontent.com/openshift/installer/release-4.12/upi/openstack/down-containers.yaml'

Playbook はマシンにダウンロードされます。

重要

インストールプロセス時に、Playbook を変更してデプロイメントを設定できます。

クラスターの有効期間中に、すべての Playbook を保持します。OpenShift Container Platform クラスターを RHOSP から削除するには Playbook が必要です。

重要

bootstrap.yaml、compute-nodes.yaml、control-plane.yaml、network.yaml、および security-groups.yaml ファイルに加えた編集内容は、down- の接頭辞が付けられた対応する Playbook に一致している必要があります。たとえば、bootstrap.yaml ファイルへの編集は、down-bootstrap.yaml ファイルにも反映される必要があります。両方のファイルを編集しない場合、サポートされるクラスターの削除プロセスは失敗します。

6.7. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。

  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

6.8. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64、ppc64le、および s390x アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。 

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。 

    $ cat ~/.ssh/id_ed25519.pub

  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。 

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。 

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

6.9. Red Hat Enterprise Linux CoreOS (RHCOS) イメージの作成

OpenShift Container Platform インストールプログラムでは、Red Hat Enterprise Linux CoreOS (RHCOS) イメージが Red Hat OpenStack Platform (RHOSP) クラスターに存在する必要があります。最新の RHCOS イメージを取得した後、RHOSP CLI を使用してこれをアップロードします。

前提条件

  • RHOSP CLI がインストールされています。

手順

  1. Red Hat カスタマーポータルの 製品ダウンロードページ にログインします。

  2. バージョン の下で、Red Hat Enterprise Linux (RHEL)8 用の OpenShift Container Platform 4.12 の最新リリースを選択します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

  3. Red Hat Enterprise Linux CoreOS (RHCOS) - OpenStack Image (QCOW) をダウンロードします。

  4. イメージを展開します。

    注記

    クラスターが使用する前に RHOSP イメージを圧縮解除する必要があります。ダウンロードしたファイルの名前に、.gz または .tgz などの圧縮拡張子が含まれていない場合があります。ファイルを圧縮するか、どのように圧縮するかを確認するには、コマンドラインで以下を入力します。 

    $ file <name_of_downloaded_file>

  5. ダウンロードしたイメージから、RHOSP CLI を使用して rhcos という名前のイメージをクラスターに作成します。 

    $ openstack image create --container-format=bare --disk-format=qcow2 --file rhcos-${RHCOS_VERSION}-openstack.qcow2 rhcos
    重要

    RHOSP 環境によっては、.raw または .qcow2 形式 のいずれかでイメージをアップロードできる場合があります。Ceph を使用する場合は、.raw 形式を使用する必要があります。

    警告

    インストールプログラムが同じ名前を持つ複数のイメージを見つける場合、それらのイメージのいずれかがランダムに選択されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。

RHOSP にイメージをアップロードした後は、インストールプログラムでイメージを利用できます。

6.10. 外部ネットワークアクセスの確認

OpenShift Container Platform インストールプロセスでは、外部ネットワークへのアクセスが必要です。外部ネットワーク値をこれに指定する必要があります。指定しない場合には、デプロイメントは失敗します。このプロセスを実行する前に、外部ルータータイプのネットワークが Red Hat OpenStack Platform (RHOSP) に存在することを確認します。

前提条件

手順

  1. RHOSP CLI を使用して、'External' ネットワークの名前と ID を確認します。 

    $ openstack network list --long -c ID -c Name -c "Router Type"

    出力例

    +--------------------------------------+----------------+-------------+
| ID                                   | Name           | Router Type |
+--------------------------------------+----------------+-------------+
| 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
+--------------------------------------+----------------+-------------+

外部ルータータイプのあるネットワークがネットワークリストに表示されます。1 つ以上のネットワークが表示されない場合は、デフォルトの Floating IP ネットワークの作成 および デフォルトのプロバイダーネットワークの作成 を参照してください。

注記

Neutron トランクサービスプラグインが有効にされると、トランクポートがデフォルトで作成されます。詳細は、Neutron trunk port を参照してください。

6.11. 環境へのアクセスの有効化

デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。

インストール時に Floating IP アドレス (FIP) を使用して OpenShift Container Platform API およびアプリケーションのアクセスを設定できます。FIP を設定せずにインストールを完了することもできますが、インストーラーは API またはアプリケーションを外部からアクセスする方法を設定しません。

6.11.1. floating IP アドレスを使用したアクセスの有効化

OpenShift Container Platform API、クラスターアプリケーション、およびブートストラッププロセスへの外部アクセス用に Floating IP (FIP) アドレスを作成します。

手順

  1. Red Hat OpenStack Platform (RHOSP) CLI を使用して、API FIP を作成します。 

    $ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>

  2. Red Hat OpenStack Platform (RHOSP) CLI を使用して、apps (アプリ)、または Ingress、FIP を作成します。 

    $ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>

  3. Red Hat OpenStack Platform (RHOSP) CLI を使用して、ブートストラップ FIP を作成します。 

    $ openstack floating ip create --description "bootstrap machine" <external_network>

  4. API および Ingress FIP の DNS サーバーに、これらのパターンに準拠するレコードを追加します。 

    api.<cluster_name>.<base_domain>.  IN  A  <API_FIP>
*.apps.<cluster_name>.<base_domain>. IN  A <apps_FIP>
    注記

    DNS サーバーを制御していない場合は、次のようなクラスタードメイン名を /etc/hosts ファイルに追加することで、クラスターにアクセスできます。

    • <api_floating_ip> api.<cluster_name>.<base_domain>
    • <application_floating_ip> grafana-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> oauth-openshift.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
    • application_floating_ip integrated-oauth-server-openshift-authentication.apps.<cluster_name>.<base_domain>

    /etc/hosts ファイル内のクラスタードメイン名により、クラスターの Web コンソールおよび監視インターフェイスへのローカルアクセスが許可されます。kubectl または oc を使用することもできます。<application_floating_ip> を指す追加のエントリーを使用して、ユーザーアプリケーションにアクセスできます。このアクションにより、API およびアプリケーションは他のユーザーがアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

  5. FIP を以下の変数の値として inventory.yaml ファイルに追加します。

    • os_api_fip
    • os_bootstrap_fip
    • os_ingress_fip

これらの値を使用する場合には、inventory.yaml ファイルの os_external_network 変数の値として外部ネットワークを入力する必要もあります。

ヒント

Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。

6.11.2. Floating IP アドレスなしでのインストールの完了

Floating IP アドレスを指定せずに OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールすることができます。

inventory.yaml ファイルで、以下の変数を定義しないでください。

  • os_api_fip
  • os_bootstrap_fip
  • os_ingress_fip

外部ネットワークを提供できない場合は、os_external_network を空白のままにすることもできます。os_external_network の値を指定しない場合はルーターが作成されず、追加のアクションがない場合は、インストーラーは Glance からのイメージの取得に失敗します。インストールプロセスで、ネットワークリソースを作成する際に、独自の外部接続を設定する必要があります。

Floating IP アドレスまたは名前解決がないために、クラスター API に到達できないシステムから wait-for コマンドでインストーラーを実行すると、インストールに失敗します。このような場合にインストールが失敗するのを防ぐために、プロキシーネットワークを使用するか、マシンと同じネットワークにあるシステムからインストーラーを実行できます。

注記

API および Ingress ポートの DNS レコードを作成して、名前解決を有効にできます。以下に例を示します。 

api.<cluster_name>.<base_domain>.  IN  A  <api_port_IP>
*.apps.<cluster_name>.<base_domain>. IN  A <ingress_port_IP>

DNS サーバーを制御しない場合は、/etc/hosts ファイルにレコードを追加できます。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

6.12. インストールプログラムのパラメーターの定義

OpenShift Container Platform インストールプログラムは、clouds.yaml というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。

手順

  1. clouds.yaml ファイルを作成します。

    • RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに clouds.yaml ファイルを生成します。

      重要

      パスワードを必ず auth フィールドに追加してください。シークレットは、clouds.yaml の 別のファイル に保持できます。

    • RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。clouds.yaml の詳細は、RHOSP ドキュメントの Config files を参照してください。 

      clouds:
  shiftstack:
    auth:
      auth_url: http://10.10.14.42:5000/v3
      project_name: shiftstack
      username: <username>
      password: <password>
      user_domain_name: Default
      project_domain_name: Default
  dev-env:
    region_name: RegionOne
    auth:
      username: <username>
      password: <password>
      project_name: 'devonly'
      auth_url: 'https://10.10.14.22:5001/v2.0'

  2. RHOSP インストールでエンドポイント認証用に自己署名認証局 (CA) を使用する場合、以下を実行します。

    1. 認証局ファイルをマシンにコピーします。

    2. cacerts キーを clouds.yaml ファイルに追加します。この値は、CA 証明書への絶対的な root 以外によるアクセスが可能なパスである必要があります。 

      clouds:
  shiftstack:
    ...
    cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"
      ヒント

      カスタム CA 証明書を使用してインストーラーを実行した後に、cloud-provider-config キーマップの ca-cert.pem キーの値を編集して証明書を更新できます。コマンドラインで、以下を実行します。 

      $ oc edit configmap -n openshift-config cloud-provider-config

  3. clouds.yaml ファイルを以下の場所のいずれかに置きます。

    1. OS_CLIENT_CONFIG_FILE 環境変数の値
    2. 現行ディレクトリー
    3. Unix 固有のユーザー設定ディレクトリー (例: ~/.config/openstack/clouds.yaml)

    4. Unix 固有のサイト設定ディレクトリー (例: /etc/openstack/clouds.yaml)

      インストールプログラムはこの順序で clouds.yaml を検索します。

6.13. インストール設定ファイルの作成

Red Hat OpenStack Platform (RHOSP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
  • サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。 

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして openstack を選択します。
      3. クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
      4. OpenShift API への外部アクセスに使用する floating IP アドレスを指定します。
      5. コントロールプレーンノードに使用する少なくとも 16 GB の RAM とコンピュートノードに使用する 8 GB の RAM を持つ RHOSP フレーバーを指定します。
      6. クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
      7. クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
      8. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

これで、指定したディレクトリーに install-config.yaml ファイルが作成されます。

6.14. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

6.14.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表6.2 必須パラメーター
パラメーター説明値

apiVersion

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain と <metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata.name

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。文字列は 14 文字以上でなければなりません。

platform

インストールを実行する特定のプラットフォームの設定: alibabacloud、aws、baremetal、azure、gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}。platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

6.14.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

表6.3 ネットワークパラメーター
パラメーター説明値

networking

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking.networkType

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、全 Linux ネットワーク用の CNI プラグインです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNkubernetes です。

networking.clusterNetwork

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23

networking.clusterNetwork.cidr

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking.clusterNetwork.hostPrefix

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix が 23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking.serviceNetwork

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 

networking:
  serviceNetwork:
   - 172.30.0.0/16

networking.machineNetwork

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16

networking.machineNetwork.cidr

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

6.14.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表6.4 オプションのパラメーター
パラメーター説明値

additionalTrustBundle

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は None、v4.11、v4.12、vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

compute

コンピュートノードを設定するマシンの設定。

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute.hyperthreading

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute.name

compute を使用する場合に必須です。マシンプールの名前。

worker

compute.platform

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

compute.replicas

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane

コントロールプレーンを設定するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane.hyperthreading

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane.name

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane.platform

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

controlPlane.replicas

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを Mint、Passthrough または Manual に設定する必要があります。

Mint、Passthrough、Manual、または空の文字列 ("")。

fips

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、x86_64、ppc64le、および s390x アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources.source

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources.mirrors

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

6.14.4. 追加の Red Hat OpenStack Platform (RHOSP) 設定パラメーター

追加の RHOSP 設定パラメーターは以下の表で説明されています。

表6.5 追加の RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.rootVolume.size

コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

compute.platform.openstack.rootVolume.type

コンピュートマシンの場合、root のボリュームタイプです。

文字列 (例: performance)。

controlPlane.platform.openstack.rootVolume.size

コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

controlPlane.platform.openstack.rootVolume.type

コントロールプレーンマシンの場合、root ボリュームのタイプです。

文字列 (例: performance)。

platform.openstack.cloud

clouds.yaml ファイルのクラウドリストにある使用する RHOCP クラウドの名前。

文字列 (例: MyCloud)。

platform.openstack.externalNetwork

インストールに使用される RHOSP の外部ネットワーク名。

文字列 (例: external)。

platform.openstack.computeFlavor

コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。

このプロパティーは非推奨にされています。すべてのマシンプールのデフォルトとしてフレーバーを使用するには、これを platform.openstack.defaultMachinePlatform プロパティーで type キーの値として追加します。それぞれのマシンプールのフレーバー値を個別に設定することもできます。

文字列 (例: m1.xlarge)。

6.14.5. オプションの RHOSP 設定パラメーター

オプションの RHOSP 設定パラメーターは、以下の表で説明されています。

表6.6 オプションの RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.additionalNetworkIDs

コンピュートマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

compute.platform.openstack.additionalSecurityGroupIDs

コンピュートマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

compute.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

compute.platform.openstack.rootVolume.zones

コンピュートマシンの root ボリュームをインストールするアベイラビリティーゾーン。このパラメーターに値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列のリスト (例: ["zone-1", "zone-2"])。

compute.platform.openstack.serverGroupPolicy

プール内のコンピュートマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

controlPlane.platform.openstack.additionalNetworkIDs

コントロールプレーンマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

コントロールプレーンマシンに接続されている追加のネットワークも、ブートストラップノードに接続されています。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

controlPlane.platform.openstack.additionalSecurityGroupIDs

コントロールプレーンマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

controlPlane.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.rootVolume.zones

コントロールプレーンマシンの root ボリュームをインストールするアベイラビリティーゾーン。この値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列の一覧 (例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.serverGroupPolicy

プール内のコントロールプレーンマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

platform.openstack.clusterOSImage

インストールプログラムが RHCOS イメージをダウンロードする場所。

ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。

HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。

例: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d。この値は、既存の Glance イメージの名前にもなり得ます (例: my-rhcos)。

platform.openstack.clusterOSImageProperties

Glance のインストーラーでアップロードされた ClusterOSImage に追加するプロパティー。このプロパティーは、platform.openstack.clusterOSImage が既存の Glance イメージに設定されている場合は無視されます。

このプロパティーを使用し、ノードあたり 26 PV の RHOSP のデフォルト永続ボリューム (PV) の制限を超過することができます。制限を超えるには、hw_scsi_model プロパティーの値を virtio-scsi に設定し、hw_disk_bus の値を scsi に設定します。

このプロパティーを使用し、hw_qemu_guest_agent プロパティーを yes の値で追加して QEMU ゲストエージェントを有効にすることもできます。

キーと値の文字列のペアのリスト。例: ["hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi"]

platform.openstack.defaultMachinePlatform

デフォルトのマシンプールプラットフォームの設定。 

{
   "type": "ml.large",
   "rootVolume": {
      "size": 30,
      "type": "performance"
   }
}

platform.openstack.ingressFloatingIP

Ingress ポートに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.apiFloatingIP

API ロードバランサーに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.externalDNS

クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。

文字列としての IP アドレスのリスト。例: ["8.8.8.8", "192.168.1.12"]

platform.openstack.machinesSubnet

クラスターのノードが使用する RHOSP サブネットの UUID。ノードおよび仮想 IP (VIP) ポートがこのサブネットに作成されます。

networking.machineNetwork の最初の項目は machinesSubnet の値に一致する必要があります。

カスタムサブネットにデプロイする場合、OpenShift Container Platform インストーラーに外部 DNS サーバーを指定することはできません。代わりに、DNS を RHOSP のサブネットに追加 します。

文字列としての UUID。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

6.14.6. RHOSP デプロイメントでのカスタムサブネット

オプションで、選択する Red Hat OpenStack Platform (RHOSP) サブネットにクラスターをデプロイすることができます。サブネットの GUID は、install-config.yaml ファイルの platform.openstack.machinesSubnet の値として渡されます。

このサブネットはクラスターのプライマリーサブネットとして使用されます。デフォルトで、ノードおよびポートはこの上に作成されます。platform.openstack.machinesSubnet プロパティーの値をサブネットの UUID に設定すると、異なる RHOSP サブネットにノードおよびポートを作成することができます。

カスタムサブネットを使用して OpenShift Container Platform インストーラーを実行する前に、設定が以下の要件を満たしていることを確認してください。

  • platform.openstack.machinesSubnet で使用されるサブネットで DHCP が有効にされている。
  • platform.openstack.machinesSubnet の CIDR は networking.machineNetwork の CIDR に一致する。
  • インストールプログラムのユーザーには、固定 IP アドレスを持つポートなど、このネットワークでポートを作成するパーミッションがある。

カスタムサブネットを使用するクラスターには、以下の制限があります。

  • Floating IP アドレスを使用するクラスターをインストールする予定の場合には、platform.openstack.machinesSubnet サブネットを externalNetwork ネットワークに接続されているルーターに接続する必要があります。
  • platform.openstack.machinesSubnet の値が install-config.yaml ファイルに設定されている場合、インストールプログラムは RHOSP マシンのプライベートネットワークまたはサブネットを作成しません。
  • platform.openstack.externalDNS プロパティーは、カスタムサブネットと同時に使用することはできません。カスタムサブネットを使用するクラスターに DNS を追加するには、RHOSP ネットワークで DNS を設定します。
注記

デフォルトでは、API VIP は x.x.x.5 を取得し、Ingress VIP はネットワークの CIDR ブロックから x.x.x.7 を取得します。これらのデフォルト値を上書きするには、DHCP 割り当てプール外の platform.openstack.apiVIPs および platform.openstack.ingressVIPs の値を設定します。

重要

ネットワークの CIDR 範囲は、クラスターのインストール後に調整できません。Red Hat は、namespace ごとに作成される Pod の数を慎重に検討する必要があるため、クラスターのインストール時に範囲を決定するための直接的なガイダンスを提供していません。

6.14.7. Kuryr を使用した OpenStack のカスタマイズされた install-config.yaml ファイルのサンプル

デフォルトの OVN-Kubernetes ネットワークプラグインの代わりに Kuryr SDN を使用してデプロイするには、install-config.yaml ファイルを変更して、Kuryr を目的の network.networkType として含める必要があります。このサンプル install-config.yaml は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。

重要

このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得する必要があります。 

apiVersion: v1
baseDomain: example.com
controlPlane:
  name: master
  platform: {}
  replicas: 3
compute:
- name: worker
  platform:
    openstack:
      type: ml.large
  replicas: 3
metadata:
  name: example
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  serviceNetwork:
  - 172.30.0.0/16 1
  networkType: Kuryr 2
platform:
  openstack:
    cloud: mycloud
    externalNetwork: external
    computeFlavor: m1.xlarge
    apiFloatingIP: 128.0.0.1
    trunkSupport: true 3
    octaviaSupport: true 4
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
1
Amphora Octavia ドライバーは、ロードバランサーごとに 2 つのポートを作成します。そのため、インストーラーが作成するサービスサブネットは、serviceNetwork プロパティーの値として指定される CIDR のサイズは 2 倍になります。IP アドレスの競合を防ぐには、範囲をより広くする必要があります。
2
インストールするクラスターネットワークプラグイン。サポートされている値は、Kuryr、OVNKubernetes、および OpenShiftSDN です。デフォルトの値は OVNkubernetes です。
3 4
trunkSupport と octaviaSupport の両方はインストーラーによって自動的に検出されるため、それらを設定する必要はありません。ただし、ご使用の環境がこれらの両方の要件を満たさないと、Kuryr SDN は適切に機能しません。トランクは Pod を RHOSP ネットワークに接続するために必要であり、Octavia は OpenShift Container Platform サービスを作成するために必要です。

6.14.8. RHOSP プロバイダーネットワーク上のクラスターデプロイメント

プロバイダーネットワーク上のプライマリーネットワークインターフェイスを使用して、OpenShift Container Platform クラスターを Red Hat OpenStack Platform (RHOSP) にデプロイできます。プロバイダーネットワークは一般的に、インターネットへの到達に使用可能なパブリックネットワークに、プロジェクトが直接アクセスできるように使用します。ネットワーク作成プロセスの一環として、プロバイダーネットワークをプロジェクト間で共有することもできます。

RHOSP プロバイダーネットワークは、データセンター内の既存の物理ネットワークに直接マップします。RHOSP 管理者はこれらを作成する必要があります。

以下の例では、OpenShift Container Platform ワークロードはプロバイダーネットワークを使用してデータセンターに接続されます。

OpenStack 上の 4 つの OpenShift ワークロードを示す図。各ワークロードは、プロバイダーネットワークを使用して、NIC によって外部のデータセンターに接続されます。

プロバイダーネットワークにインストールされている OpenShift Container Platform クラスターは、テナントネットワークまたは Floating IP アドレスを必要としません。インストーラーは、インストール中にこれらのリソースを作成しません。

プロバイダーネットワークタイプの例には、フラット (タグなし) および VLAN (802.1Q タグ付き) が含まれます。

注記

クラスターは、ネットワークタイプが許可する限り多くのプロバイダーネットワーク接続をサポートできます。たとえば、VLAN ネットワークは、通常最大 4096 の接続をサポートします。

プロバイダーネットワークおよびテナントネットワークの詳細は、RHOSP のドキュメント を参照してください。

6.14.8.1. クラスターのインストールにおける RHOSP プロバイダーネットワーク要件

OpenShift Container Platform クラスターをインストールする前に、Red Hat OpenStack Platform (RHOSP) のデプロイメントおよびプロバイダーネットワークは、さまざまな条件を満たす必要があります。

  • RHOSP ネットワークサービス (Neutron) が有効化され、RHOSP ネットワーク API 経由でアクセス可能であること。
  • RHOSP ネットワークサービスでは、ポートセキュリティーと許可するアドレスペアの機能拡張が有効化 されていること。

  • プロバイダーネットワークは他のテナントと共有できます。

    ヒント

    --share フラグを指定して openstack network create コマンドを使用して、共有できるネットワークを作成します。

  • クラスターのインストールに使用する RHOSP プロジェクトは、プロバイダーネットワークと適切なサブネットを所有する必要があります。

    ヒント
    "openshift" という名前のプロジェクトのネットワークを作成するには、以下のコマンドを入力します。
    $ openstack network create --project openshift
    "openshift" という名前のプロジェクトのサブネットを作成するには、以下のコマンドを入力します。
    $ openstack subnet create --project openshift

    RHOSP でのネットワークの作成に関する詳細は、プロバイダーネットワークに関するドキュメント を参照してください。

    クラスターが admin ユーザーによって所有されている場合、そのユーザーとしてインストーラーを実行してネットワーク上でポートを作成する必要があります。

    重要

    プロバイダーネットワークは、クラスターの作成に使用される RHOSP プロジェクトによって所有されている必要があります。所有されていない場合は、RHOSP Compute サービス (Nova) はそのネットワークからポートを要求できません。

  • プロバイダーネットワークが、デフォルトで 169.254.169.254 である RHOSP メタデータサービスの IP アドレスに到達できることを確認します。

    RHOSP SDN とネットワークサービス設定によっては、サブネットを作成する際に、ルートを提供しなければならない場合があります。以下に例を示します。 

    $ openstack subnet create --dhcp --host-route destination=169.254.169.254/32,gateway=192.0.2.2 ...
  • オプション: ネットワークのセキュリティーを保護するには、単一のプロジェクトへのネットワークアクセスを制限する ロールベースのアクセス制御 (RBAC) ルールを作成します。
6.14.8.2. プロバイダーネットワークにプライマリーインターフェイスを持つクラスターのデプロイ

Red Hat OpenStack Platform (RHOSP) プロバイダーネットワーク上にプライマリーネットワークインターフェイスを持つ OpenShift Container Platform クラスターをデプロイすることができます。

前提条件

  • 「クラスターのインストールにおける RHOSP プロバイダーネットワーク要件」に記載されているとおりに、お使いの Red Hat OpenStack Platform (RHOSP) のデプロイメントが設定されています。

手順

  1. テキストエディターで install-config.yaml ファイルを開きます。
  2. platform.openstack.apiVIPs プロパティーの値を API VIP の IP アドレスに設定します。
  3. platform.openstack.ingressVIPs プロパティーの値を Ingress VIP の IP アドレスに設定します。
  4. platform.openstack.machinesSubnet プロパティーの値をプロバイダーネットワークサブネットの UUID に設定します。
  5. networking.machineNetwork.cidr プロパティーの値をプロバイダーネットワークサブネットの CIDR ブロックに設定します。
重要

platform.openstack.apiVIPs プロパティーおよび platform.openstack.ingressVIPs プロパティーはいずれも、networking.machineNetwork.cidr ブロックから割り当てられていない IP アドレスである必要があります。

RHOSP プロバイダーネットワークに依存するクラスターのインストール設定ファイルのセクション

        ...
        platform:
          openstack:
            apiVIPs: 1
              - 192.0.2.13
            ingressVIPs: 2
              - 192.0.2.23
            machinesSubnet: fa806b2f-ac49-4bce-b9db-124bc64209bf
            # ...
        networking:
          machineNetwork:
          - cidr: 192.0.2.0/24

1 2
OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。
警告

プライマリーネットワークインターフェイスにプロバイダーネットワークを使用している間は、platform.openstack.externalNetwork パラメーターまたは platform.openstack.externalDNS パラメーターを設定することはできません。

クラスターをデプロイする際に、インストーラーは install-config.yaml ファイルを使用してプロバイダーネットワークにクラスターをデプロイします。

ヒント

プロバイダーネットワークを含むネットワークを platform.openstack.additionalNetworkIDs リストに追加できます。

クラスターのデプロイ後に、Pod を追加のネットワークに接続することができます。詳細は、複数ネットワークについて を参照してください。

6.14.9. Kuryr ポートプール

Kuryr ポートプールでは、Pod 作成のスタンバイ状態の多数のポートを維持します。

ポートをスタンバイ状態に維持すると、Pod の作成時間が必要最小限に抑えることができます。ポートプールを使用しない場合には、Kuryr は Pod が作成または削除されるたびにポートの作成または削除を明示的に要求する必要があります。

Kuryr が使用する Neutron ポートは、namespace に関連付けられるサブネットに作成されます。これらの Pod ポートは、OpenShift Container Platform クラスターノードのプライマリーポートにサブポートとして追加されます。

Kuryr は namespace をそれぞれ、別のサブネットに保存するため、namespace-worker ペアごとに別個のポートプールが維持されます。

クラスターをインストールする前に、cluster-network-03-config.yml マニフェストファイルに以下のパラメーターを設定して、ポートプールの動作を設定できます。

  • enablePortPoolsPrepopulation パラメーターは、プールの事前入力を制御します。これにより、Pod 専用ネットワークを使用するように設定された最初の Pod が namespace に作成されたときに、Kuryr が Neutron ポートをプールに追加します。デフォルト値は false です。
  • poolMinPorts パラメーターは、プールに保持する空きポートの最小数です。デフォルト値は 1 です。

  • poolMaxPorts パラメーターは、プールに保持する空きポートの最大数です。値が 0 の場合は、上限が無効になります。これはデフォルト設定です。

    OpenStack ポートのクォータが低い場合や、Pod ネットワークで IP アドレスの数が限定されている場合には、このオプションを設定して、不要なポートが削除されるようにします。

  • poolBatchPorts パラメーターは、一度に作成可能な Neutron ポートの最大数を定義します。デフォルト値は 3 です。

6.14.10. インストール時の Kuryr ポートプールの調整

インストール時に、Pod 作成の速度や効率性を制御するために Kuryr で Red Hat OpenStack Platform (RHOSP) Neutron ポートを管理する方法を設定できます。

前提条件

  • install-config.yaml ファイルを作成して変更しておく。

手順

  1. コマンドラインからマニフェストファイルを作成します。 

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> については、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。

  2. cluster-network-03-config.yml という名前のファイルを <installation_directory>/manifests/ ディレクトリーに作成します。 

    $ touch <installation_directory>/manifests/cluster-network-03-config.yml 1
    1
    <installation_directory> については、クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。

    ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが manifests/ ディレクトリーに置かれます。 

    $ ls <installation_directory>/manifests/cluster-network-*

    出力例

    cluster-network-01-crd.yml
cluster-network-02-config.yml
cluster-network-03-config.yml

  3. エディターで cluster-network-03-config.yml ファイルを開き、必要な Cluster Network Operator 設定を記述するカスタムリソース (CR) を入力します。 

    $ oc edit networks.operator.openshift.io cluster

  4. 要件に合わせて設定を編集します。以下のファイルをサンプルとして紹介しています。 

    apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  defaultNetwork:
    type: Kuryr
    kuryrConfig:
      enablePortPoolsPrepopulation: false 1
      poolMinPorts: 1 2
      poolBatchPorts: 3 3
      poolMaxPorts: 5 4
      openstackServiceNetwork: 172.30.0.0/15 5
    1
    enablePortPoolsPrepopulation を true に設定すると、Pod のネットワーク上の最初の Pod が namespace に作成されたときに、Kuryr が新しい Neutron ポートを作成するようになります。この設定により、Neutron ポートのクォータが引き上げられますが、Pod の起動に必要となる時間を短縮できます。デフォルト値は false です。
    2
    Kuryr は、対象のプール内にある空きポートの数が poolMinPorts の値よりも少ない場合には、プールに新規ポートを作成します。デフォルト値は 1 です。
    3
    poolBatchPorts は、空きポートの数が poolMinPorts の値よりも少ない場合に作成される新規ポートの数を制御します。デフォルト値は 3 です。
    4
    プール内の空きポートの数が poolMaxPorts の値よりも多い場合に、Kuryr はその値と同じ数になるまでポートを削除します。この値を 0 に設定すると、この上限は無効になり、プールが縮小できないようにします。デフォルト値は 0 です。
    5
    openStackServiceNetwork パラメーターは、RHOSP Octavia の LoadBalancer に割り当てられるネットワークの CIDR 範囲を定義します。

    このパラメーターを Amphora ドライバーと併用する場合には、Octavia は、ロードバランサーごとに、このネットワークから IP アドレスを 2 つ (OpenShift 用に 1 つ、VRRP 接続用に 1 つ) 取得します。これらの IP アドレスは OpenShift Container Platform と Neutron でそれぞれ管理されるため、異なるプールから取得する必要があります。したがって、openStackServiceNetwork serviceNetwork の値の 2 倍になる必要があり、serviceNetwork の値は、openStackServiceNetwork で定義された範囲と完全に重複する必要があります。

    CNO は、このパラメーターの定義範囲から取得した VRRP IP アドレスが serviceNetwork パラメーターの定義範囲と重複しないことを検証します。

    このパラメーターが設定されていない場合には、CNO は serviceNetwork の拡張値を使用します。この値は、プリフィックスのサイズを 1 つずつ減らして決定します。

  5. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  6. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。

6.14.11. マシンのカスタムサブネットの設定

インストールプログラムがデフォルトで使用する IP 範囲は、OpenShift Container Platform のインストール時に作成する Neutron サブネットと一致しない可能性があります。必要な場合は、インストール設定ファイルを編集して、新規マシンの CIDR 値を更新します。

前提条件

  • OpenShift Container Platform インストールプログラムで生成された install-config.yaml ファイルがあります。

手順

  1. コマンドラインで、install-config.yaml が含まれるディレクトリーを参照します。

  2. そのディレクトリーからスクリプトを実行して install-config.yaml ファイルを編集するか、手動でファイルを更新します。

    • スクリプトを使用して値を設定するには、以下を実行します。 

      $ python -c '
import yaml;
path = "install-config.yaml";
data = yaml.safe_load(open(path));
data["networking"]["machineNetwork"] = [{"cidr": "192.168.0.0/18"}]; 1
open(path, "w").write(yaml.dump(data, default_flow_style=False))'
      1
      必要な Neutron サブネットに一致する値 (例: 192.0.2.0/24) を挿入します。
    • 値を手動で設定するには、ファイルを開き、networking.machineCIDR の値を必要な Neutron サブネットに一致する値に設定します。

6.14.12. コンピュートマシンプールを空にする

独自のインフラストラクチャーを使用するインストールを実行するには、インストール設定ファイルのコンピュートマシンの数をゼロに設定します。その後、これらのマシンを手動で作成します。

前提条件

  • OpenShift Container Platform インストールプログラムで生成された install-config.yaml ファイルがあります。

手順

  1. コマンドラインで、install-config.yaml が含まれるディレクトリーを参照します。

  2. そのディレクトリーからスクリプトを実行して install-config.yaml ファイルを編集するか、手動でファイルを更新します。

    • スクリプトを使用して値を設定するには、以下を実行します。 

      $ python -c '
import yaml;
path = "install-config.yaml";
data = yaml.safe_load(open(path));
data["compute"][0]["replicas"] = 0;
open(path, "w").write(yaml.dump(data, default_flow_style=False))'
    • 値を手動で設定するには、ファイルを開き、compute.<first entry>.replicas の値を 0 に設定します。

6.14.13. ネットワークタイプの変更

デフォルトで、インストールプログラムは OpenShiftSDN ネットワークタイプを選択します。代わりに Kuryr を使用するには、プログラムが生成したインストール設定ファイルの値を変更します。

前提条件

  • OpenShift Container Platform インストールプログラムで生成された install-config.yaml ファイルがあります。

手順

  1. コマンドプロンプトで、install-config.yaml が含まれるディレクトリーを参照します。

  2. そのディレクトリーからスクリプトを実行して install-config.yaml ファイルを編集するか、手動でファイルを更新します。

    • スクリプトを使用して値を設定するには、以下を実行します。 

      $ python -c '
import yaml;
path = "install-config.yaml";
data = yaml.safe_load(open(path));
data["networking"]["networkType"] = "Kuryr";
open(path, "w").write(yaml.dump(data, default_flow_style=False))'
    • 値を手動で設定するには、ファイルを開き、networking.networkType を "Kuryr" に設定します。

6.15. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。

重要
  • OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

前提条件

  • OpenShift Container Platform インストールプログラムを取得していること。
  • install-config.yaml インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。 

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> については、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。

  2. コントロールプレーンマシンおよびコンピュートマシンセットを定義する Kubernetes マニフェストファイルを削除します。 

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

    これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

    • コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。

  3. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。

  4. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。 

    $ ./openshift-install create ignition-configs --dir <installation_directory> 1
    1
    <installation_directory> には、同じインストールディレクトリーを指定します。

    Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。 

    .
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign

  5. メタデータファイルの infraID キーを環境変数としてエクスポートします。 

    $ export INFRA_ID=$(jq -r .infraID metadata.json)
ヒント

metadata.json から infraID キーを抽出し、作成するすべての RHOSP リソースの接頭辞として使用します。これを実行することで、同じプロジェクトで複数のデプロイメントを実行する際に名前の競合が発生しないようにします。

6.16. ブートストラップ Ignition ファイルの準備

OpenShift Container Platform インストールプロセスは、ブートストラップ Ignition 設定ファイルから作成されるブートストラップマシンに依存します。

ファイルを編集し、アップロードします。次に、Red Hat OpenStack Platform (RHOSP) がプライマリーファイルをダウンロードする際に使用するセカンダリーブートストラップ Ignition 設定ファイルを作成します。

前提条件

  • インストーラープログラムが生成するブートストラップ Ignition ファイル bootstrap.ign があります。

  • インストーラーのメタデータファイルのインフラストラクチャー ID は環境変数 ($INFRA_ID) として設定されます。

    • 変数が設定されていない場合は、Kubernetes マニフェストおよび Ignition 設定ファイルの作成 を参照してください。

  • HTTP(S) でアクセス可能な方法でブートストラップ Ignition ファイルを保存できます。

    • 記載された手順では RHOSP イメージサービス (Glance) を使用しますが、RHOSP ストレージサービス (Swift)、Amazon S3、内部 HTTP サーバー、またはアドホックの Nova サーバーを使用することもできます。

手順

  1. 以下の Python スクリプトを実行します。スクリプトはブートストラップ Ignition ファイルを変更して、ホスト名および利用可能な場合は、実行時の CA 証明書ファイルを設定します。 

    import base64
import json
import os

with open('bootstrap.ign', 'r') as f:
    ignition = json.load(f)

files = ignition['storage'].get('files', [])

infra_id = os.environ.get('INFRA_ID', 'openshift').encode()
hostname_b64 = base64.standard_b64encode(infra_id + b'-bootstrap\n').decode().strip()
files.append(
{
    'path': '/etc/hostname',
    'mode': 420,
    'contents': {
        'source': 'data:text/plain;charset=utf-8;base64,' + hostname_b64
    }
})

ca_cert_path = os.environ.get('OS_CACERT', '')
if ca_cert_path:
    with open(ca_cert_path, 'r') as f:
        ca_cert = f.read().encode()
        ca_cert_b64 = base64.standard_b64encode(ca_cert).decode().strip()

    files.append(
    {
        'path': '/opt/openshift/tls/cloud-ca-cert.pem',
        'mode': 420,
        'contents': {
            'source': 'data:text/plain;charset=utf-8;base64,' + ca_cert_b64
        }
    })

ignition['storage']['files'] = files;

with open('bootstrap.ign', 'w') as f:
    json.dump(ignition, f)

  2. RHOSP CLI を使用して、ブートストラップ Ignition ファイルを使用するイメージを作成します。 

    $ openstack image create --disk-format=raw --container-format=bare --file bootstrap.ign <image_name>

  3. イメージの詳細を取得します。 

    $ openstack image show <image_name>

    file 値をメモします。これは v2/images/<image_ID>/file パターンをベースとしています。

    注記

    作成したイメージがアクティブであることを確認します。

  4. イメージサービスのパブリックアドレスを取得します。 

    $ openstack catalog show image
  5. パブリックアドレスとイメージ file 値を組み合わせ、結果を保存場所として保存します。この場所は、<image_service_public_URL>/v2/images/<image_ID>/file パターンをベースとしています。

  6. 認証トークンを生成し、トークン ID を保存します。 

    $ openstack token issue -c id -f value

  7. $INFRA_ID-bootstrap-ignition.json というファイルに以下のコンテンツを挿入し、独自の値に一致するようにプレースホルダーを編集します。 

    {
  "ignition": {
    "config": {
      "merge": [{
        "source": "<storage_url>", 1
        "httpHeaders": [{
          "name": "X-Auth-Token", 2
          "value": "<token_ID>" 3
        }]
      }]
    },
    "security": {
      "tls": {
        "certificateAuthorities": [{
          "source": "data:text/plain;charset=utf-8;base64,<base64_encoded_certificate>" 4
        }]
      }
    },
    "version": "3.2.0"
  }
}
    1
    ignition.config.append.source の値をブートストラップ Ignition ファイルのストレージ URL に置き換えます。
    2
    httpHeaders の name を "X-Auth-Token" に設定します。
    3
    httpHeaders の value をトークンの ID に設定します。
    4
    ブートストラップ Ignition ファイルサーバーが自己署名証明書を使用する場合は、base64 でエンコードされた証明書を含めます。
  8. セカンダリー Ignition 設定ファイルを保存します。

ブートストラップ Ignition データはインストール時に RHOSP に渡されます。

警告

ブートストラップ Ignition ファイルには、clouds.yaml 認証情報などの機密情報が含まれます。これを安全な場所に保存し、インストールプロセスの完了後に削除します。

6.17. RHOSP でのコントロールプレーンの Ignition 設定ファイルの作成

独自のインフラストラクチャーを使用して OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールするには、コントロールプレーンの Ignition 設定ファイルが必要です。複数の設定ファイルを作成する必要があります。

注記

ブートストラップ Ignition 設定と同様に、各コントロールプレーンマシンのホスト名を明示的に定義する必要があります。

前提条件

  • インストールプログラムのメタデータファイルのインフラストラクチャー ID は環境変数 ($INFRA_ID) として設定されます。

    • 変数が設定されていない場合は、「Kubernetes マニフェストおよび Ignition 設定ファイルの作成」を参照してください。

手順

  • コマンドラインで、以下の Python スクリプトを実行します。 

    $ for index in $(seq 0 2); do
    MASTER_HOSTNAME="$INFRA_ID-master-$index\n"
    python -c "import base64, json, sys;
ignition = json.load(sys.stdin);
storage = ignition.get('storage', {});
files = storage.get('files', []);
files.append({'path': '/etc/hostname', 'mode': 420, 'contents': {'source': 'data:text/plain;charset=utf-8;base64,' + base64.standard_b64encode(b'$MASTER_HOSTNAME').decode().strip(), 'verification': {}}, 'filesystem': 'root'});
storage['files'] = files;
ignition['storage'] = storage
json.dump(ignition, sys.stdout)" <master.ign >"$INFRA_ID-master-$index-ignition.json"
done

    以下の 3 つのコントロールプレーン Ignition ファイルが作成されます。<INFRA_ID>-master-0-ignition.json、<INFRA_ID>-master-1-ignition.json、および <INFRA_ID>-master-2-ignition.json。

6.18. RHOSP でのネットワークリソースの作成

独自のインフラストラクチャーを使用する Red Hat OpenStack Platform (RHOSP) インストールの OpenShift Container Platform に必要なネットワークリソースを作成します。時間を節約するには、セキュリティーグループ、ネットワーク、サブネット、ルーター、およびポートを生成する指定された Ansible Playbook を実行します。

前提条件

  • Python 3 がマシンにインストールされている。
  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。

手順

  1. オプション: 外部ネットワークの値を inventory.yaml Playbook に追加します。

    inventory.yaml Ansible Playbook の外部ネットワーク値の例

    ...
      # The public network providing connectivity to the cluster. If not
      # provided, the cluster external connectivity must be provided in another
      # way.

      # Required for os_api_fip, os_ingress_fip, os_bootstrap_fip.
      os_external_network: 'external'
...

    重要

    inventory.yaml ファイルの os_external_network の値を指定しなかった場合は、仮想マシンが Glance および外部接続にアクセスできるようにする必要があります。

  2. オプション: 外部ネットワークおよび Floating IP (FIP) アドレスの値を inventory.yaml Playbook に追加します。

    inventory.yaml Ansible Playbook の FIP 値の例

    ...
      # OpenShift API floating IP address. If this value is non-empty, the
      # corresponding floating IP will be attached to the Control Plane to
      # serve the OpenShift API.
      os_api_fip: '203.0.113.23'

      # OpenShift Ingress floating IP address. If this value is non-empty, the
      # corresponding floating IP will be attached to the worker nodes to serve
      # the applications.
      os_ingress_fip: '203.0.113.19'

      # If this value is non-empty, the corresponding floating IP will be
      # attached to the bootstrap machine. This is needed for collecting logs
      # in case of install failure.
      os_bootstrap_fip: '203.0.113.20'

    重要

    os_api_fip および os_ingress_fip の値を定義しない場合、インストール後のネットワーク設定を実行する必要があります。

    os_bootstrap_fip の値を定義しない場合、インストーラーは失敗したインストールからデバッグ情報をダウンロードできません。

    詳細は、環境へのアクセスの有効化を参照してください。

  3. コマンドラインで、security-groups.yaml Playbook を実行してセキュリティーグループを作成します。 

    $ ansible-playbook -i inventory.yaml security-groups.yaml

  4. コマンドラインで、network.yaml Playbook を実行して、ネットワーク、サブネット、およびルーターを作成します。 

    $ ansible-playbook -i inventory.yaml network.yaml

  5. オプション: Nova サーバーが使用するデフォルトのリゾルバーを制御する必要がある場合は、RHOSP CLI コマンドを実行します。 

    $ openstack subnet set --dns-nameserver <server_1> --dns-nameserver <server_2> "$INFRA_ID-nodes"

6.19. RHOSP でのブートストラップマシンの作成

ブートストラップマシンを作成し、これに Red Hat OpenStack Platform (RHOSP) で実行するために必要なネットワークアクセスを付与します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • inventory.yaml、common.yaml、および bootstrap.yaml Ansible Playbook は共通ディレクトリーにある。
  • インストールプログラムが作成した metadata.json ファイルが Ansible Playbook と同じディレクトリーにあります。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。

  2. コマンドラインで、bootstrap.yaml Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml bootstrap.yaml

  3. ブートストラップサーバーがアクティブになった後に、ログを表示し、Ignition ファイルが受信されたことを確認します。 

    $ openstack console log show "$INFRA_ID-bootstrap"

6.20. RHOSP でのコントロールプレーンの作成

生成した Ignition 設定ファイルを使用して 3 つのコントロールプレーンマシンを作成します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • インストールプログラムのメタデータファイルのインフラストラクチャー ID は環境変数 ($INFRA_ID) として設定されます。
  • inventory.yaml、common.yaml、および control-plane.yaml Ansible Playbook は共通ディレクトリーにあります。
  • 「コントロールプレーンの Ignition 設定ファイルの作成」で作成された 3 つの Ignition ファイルがある。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。
  2. コントロールプレーン Ignition 設定ファイルが作業ディレクトリーにない場合、それらをここにコピーします。

  3. コマンドラインで、control-plane.yaml Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml control-plane.yaml

  4. 以下のコマンドを実行してブートストラッププロセスをモニターします。 

    $ openshift-install wait-for bootstrap-complete

    コントロールプレーンマシンが実行され、クラスターに参加していることを確認できるメッセージが表示されます。 

    INFO API v1.25.0 up
INFO Waiting up to 30m0s for bootstrapping to complete...
...
INFO It is now safe to remove the bootstrap resources

6.21. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。 

    $ oc whoami

    出力例

    system:admin

6.22. RHOSP からのブートストラップリソースの削除

不要になったブートストラップリソースを削除します。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • inventory.yaml、common.yaml、および down-bootstrap.yaml Ansible Playbook が共通ディレクトリーにある。

  • コントロールプレーンマシンが実行中である。

    • マシンのステータスが不明な場合は、「クラスターステータスの確認」を参照してください。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。

  2. コマンドラインで、down-bootstrap.yaml Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml down-bootstrap.yaml

ブートストラップポート、サーバー、および Floating IP アドレスが削除されます。

警告

ブートストラップ Ignition ファイル URL をまだ無効にしていない場合は、無効にしてください。

6.23. RHOSP でのコンピュートマシンの作成

コントロールプレーンの起動後、コンピュートマシンを作成します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。

前提条件

  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • 「インストール Playbook のダウンロード」で Playbook をダウンロードしている。
  • inventory.yaml、common.yaml、および compute-nodes.yaml Ansible Playbook が共通ディレクトリーにある。
  • インストールプログラムが作成した metadata.json ファイルが Ansible Playbook と同じディレクトリーにあります。
  • コントロールプレーンが有効である。

手順

  1. コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。

  2. コマンドラインで Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml compute-nodes.yaml

次のステップ

  • マシンの証明書署名要求を承認します。

6.24. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.25.0
master-1  Ready     master  63m  v1.25.0
master-2  Ready     master  64m  v1.25.0

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。 

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。 

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。 

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。 

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.25.0
master-1  Ready     master  73m  v1.25.0
master-2  Ready     master  74m  v1.25.0
worker-0  Ready     worker  11m  v1.25.0
worker-1  Ready     worker  11m  v1.25.0

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

6.25. インストールの正常な実行の確認

OpenShift Container Platform のインストールが完了していることを確認します。

前提条件

  • インストールプログラム (openshift-install) があります。

手順

  • コマンドラインで、以下を入力します。 

    $ openshift-install --log-level debug wait-for install-complete

プログラムはコンソール URL と管理者のログイン情報を出力します。

6.26. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

6.27. 次のステップ

第7章 ネットワークが制限された環境での OpenStack へのクラスターのインストール

OpenShift Container Platform 4.12 では、インストールリリースコンテンツの内部ミラーを作成して、クラスターをネットワークが制限された環境で Red Hat OpenStack Platform (RHOSP) にインストールできます。

7.1. 前提条件

7.2. ネットワークが制限された環境でのインストールについて

OpenShift Container Platform 4.12 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。

クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。

ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。

7.2.1. その他の制限

ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。

  • ClusterVersion ステータスには Unable to retrieve available updates エラーが含まれます。
  • デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。

7.3. OpenShift Container Platform を RHOSP にインストールするリソースのガイドライン

OpenShift Container Platform のインストールをサポートするために、Red Hat OpenStack Platform (RHOSP) クォータは以下の要件を満たす必要があります。

表7.1 RHOSP のデフォルトの OpenShift Container Platform クラスターに関する推奨リソース
リソース値

Floating IP アドレス

3

ポート

15

ルーター

1

サブネット

1

RAM

88 GB

vCPU

22

ボリュームストレージ

275 GB

インスタンス

7

セキュリティーグループ

3

セキュリティーグループルール

60

サーバーグループ

2 - 各マシンプールの追加のアベイラビリティーゾーンごとに 1 つ追加

クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。

重要

RHOSP オブジェクトストレージ (Swift) が利用可能で、swiftoperator ロールを持つユーザーアカウントによって操作されている場合、これは OpenShift Container Platform イメージレジストリーのデフォルトバックエンドとして使用されます。この場合、ボリュームストレージ要件は 175 GB です。Swift 領域要件は、イメージレジストリーのサイズによって異なります。

注記

デフォルトで、セキュリティーグループおよびセキュリティーグループルールのクォータは低く設定される可能性があります。問題が生じた場合には、管理者として openstack quota set --secgroups 3 --secgroup-rules 60 <project> を実行して値を増やします。

OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで構成されます。

7.3.1. コントロールプレーンマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコントロールプレーンマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

7.3.2. コンピュートマシン

デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコンピューティングマシンを作成します。

それぞれのマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 8 GB のメモリーと 2 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量
ヒント

コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。

7.3.3. ブートストラップマシン

インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。

ブートストラップマシンには以下が必要です。

  • RHOSP クォータからのインスタンス
  • RHOSP クォータからのポート
  • 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
  • RHOSP クォータから少なくとも 100 GB のストレージ容量

7.4. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.12 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

7.5. RHOSP での Swift の有効化

Swift は、swiftoperator ロールのあるユーザーアカウントによって操作されます。インストールプログラムを実行する前に、ロールをアカウントに追加します。

重要

Swift として知られる Red Hat OpenStack Platform (RHOSP) オブジェクトストレージサービス が利用可能な場合、OpenShift Container Platform はこれをイメージレジストリーストレージとして使用します。利用できない場合、インストールプログラムは Cinder として知られる RHOSP ブロックストレージサービスに依存します。

Swift が存在し、これを使用する必要がある場合は、Swift へのアクセスを有効にする必要があります。これが存在しない場合や使用する必要がない場合は、このセクションを省略してください。

重要

RHOSP 17 では、Ceph RGW の rgw_max_attr_size パラメーターが 256 文字に設定されます。この設定は、コンテナーイメージを OpenShift Container Platform レジストリーにアップロードする際に問題を引き起こします。rgw_max_attr_size の値は、1024 文字以上に設定する必要があります。

インストールする前に、RHOSP のデプロイメントがこの問題の影響を受けるかどうか確認してください。影響を受ける場合は、Ceph RGW を再設定します。

前提条件

  • ターゲット環境に RHOSP 管理者アカウントがあります。
  • Swift サービスがインストールされています。
  • Ceph RGW で、account in url オプションが有効化されています。

手順

RHOSP 上で Swift を有効にするには、以下を実行します。

  1. RHOSP CLI の管理者として、swiftoperator ロールを Swift にアクセスするアカウントに追加します。 

    $ openstack role add --user <user> --project <project> swiftoperator

RHOSP デプロイメントでは、イメージレジストリーに Swift を使用することができます。

7.6. インストールプログラムのパラメーターの定義

OpenShift Container Platform インストールプログラムは、clouds.yaml というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。

手順

  1. clouds.yaml ファイルを作成します。

    • RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに clouds.yaml ファイルを生成します。

      重要

      パスワードを必ず auth フィールドに追加してください。シークレットは、clouds.yaml の 別のファイル に保持できます。

    • RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。clouds.yaml の詳細は、RHOSP ドキュメントの Config files を参照してください。 

      clouds:
  shiftstack:
    auth:
      auth_url: http://10.10.14.42:5000/v3
      project_name: shiftstack
      username: <username>
      password: <password>
      user_domain_name: Default
      project_domain_name: Default
  dev-env:
    region_name: RegionOne
    auth:
      username: <username>
      password: <password>
      project_name: 'devonly'
      auth_url: 'https://10.10.14.22:5001/v2.0'

  2. RHOSP インストールでエンドポイント認証用に自己署名認証局 (CA) を使用する場合、以下を実行します。

    1. 認証局ファイルをマシンにコピーします。

    2. cacerts キーを clouds.yaml ファイルに追加します。この値は、CA 証明書への絶対的な root 以外によるアクセスが可能なパスである必要があります。 

      clouds:
  shiftstack:
    ...
    cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"
      ヒント

      カスタム CA 証明書を使用してインストーラーを実行した後に、cloud-provider-config キーマップの ca-cert.pem キーの値を編集して証明書を更新できます。コマンドラインで、以下を実行します。 

      $ oc edit configmap -n openshift-config cloud-provider-config

  3. clouds.yaml ファイルを以下の場所のいずれかに置きます。

    1. OS_CLIENT_CONFIG_FILE 環境変数の値
    2. 現行ディレクトリー
    3. Unix 固有のユーザー設定ディレクトリー (例: ~/.config/openstack/clouds.yaml)

    4. Unix 固有のサイト設定ディレクトリー (例: /etc/openstack/clouds.yaml)

      インストールプログラムはこの順序で clouds.yaml を検索します。

7.7. OpenStack Cloud Controller Manager のオプション設定

オプションで、クラスターの OpenStack Cloud Controller Manager (CCM) 設定を編集できます。この設定は、OpenShift Container Platform が Red Hat OpenStack Platform (RHOSP) と対話する方法を制御します。

設定パラメーターの完全なリストは、「OpenStack のインストール」ドキュメントの「OpenStack Cloud Controller Manager リファレンスガイド」を参照してください。

手順

  1. クラスター用に生成されたマニフェストファイルがない場合は、以下のコマンドを実行して生成します。 

    $ openshift-install --dir <destination_directory> create manifests

  2. テキストエディターで、cloud-provider 設定マニフェストファイルを開きます。以下に例を示します。 

    $ vi openshift/manifests/cloud-provider-config.yaml

  3. CCM リファレンスガイド に従ってオプションを変更します。

    負荷分散を Octavia に設定することは、Kuryr を使用しないクラスターでは一般的なケースです。以下に例を示します。 

    #...
[LoadBalancer]
use-octavia=true 1
lb-provider = "amphora" 2
floating-network-id="d3deb660-4190-40a3-91f1-37326fe6ec4a" 3
create-monitor = True 4
monitor-delay = 10s 5
monitor-timeout = 10s 6
monitor-max-retries = 1 7
#...
    1
    このプロパティーにより、Octavia の統合が有効になっています。
    2
    このプロパティーは、ロードバランサーが使用する Octavia プロバイダーを設定します。"ovn" または "amphora" を値として受け入れます。OVN の使用を選択する場合は、lb-method を SOURCE_IP_PORT。
    3
    このプロパティーは、複数の外部ネットワークをクラスターで使用する場合に必要です。クラウドプロバイダーは、ここで指定するネットワーク上に Floating IP アドレスを作成します。
    4
    このプロパティーは、クラウドプロバイダーが Octavia ロードバランサーのヘルスモニターを作成するかどうかを制御します。ヘルスモニターを作成するには、値を True に設定します。RHOSP 16.2 の時点で、この機能は Amphora プロバイダーでのみ利用できます。
    5
    このプロパティーは、監視されるエンドポイントの頻度を設定します。値は time.ParseDuration（） 形式である必要があります。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    6
    このプロパティーは、タイムアウトする前に監視要求が開く時間を設定します。値は time.ParseDuration（） 形式である必要があります。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    7
    このプロパティーは、ロードバランサーがオンラインとしてマークされる前に必要なモニタリング要求の数を定義します。値は整数でなければなりません。このプロパティーは、create-monitor プロパティーの値が True の場合に必要です。
    重要

    変更を保存する前に、ファイルが正しく構造化されていることを確認します。プロパティーが適切なセクションに置かれていないと、クラスターが失敗することがあります。

    重要

    .spec.externalTrafficPolicy プロパティーの値が Local に設定されたサービスを使用する場合は、create-monitor プロパティーの値を True に設定する必要があります。RHOSP 16.2 の OVN Octavia プロバイダーは、ヘルスモニターをサポートしません。そのため、lb-provider の値が "ovn" に設定されている場合、ETP パラメーターの値が Local に設定されたサービスは応答しない可能性があります。

    重要

    Kuryr を使用するインストールの場合、Kuryr は関連サービスを処理します。クラウドプロバイダーで Octavia の負荷分散を設定する必要はありません。

  4. 変更をファイルに保存し、インストールを続行します。

    ヒント

    インストーラーの実行後に、クラウドプロバイダー設定を更新できます。コマンドラインで、以下を実行します。 

    $ oc edit configmap -n openshift-config cloud-provider-config

    変更を保存した後、クラスターの再設定には多少時間がかかります。ノードが SchedulingDisabled のままの場合は、プロセスが完了します。

7.8. ネットワークが制限されたインストール用の RHCOS イメージの作成

Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードし、OpenShift Container Platform をネットワークが制限された Red Hat OpenStack Platform (RHOSP) 環境にインストールします。

前提条件

  • OpenShift Container Platform インストールプログラムを取得します。ネットワークが制限されたインストールでは、プログラムはミラーレジストリースト上に置かれます。

手順

  1. Red Hat カスタマーポータルの 製品ダウンロードページ にログインします。

  2. バージョンの下で、RHEL8 用の OpenShift Container Platform 4.12 の最新リリースを選択します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

  3. Red Hat Enterprise Linux CoreOS (RHCOS) - OpenStack Image (QCOW) イメージをダウンロードします。

  4. イメージを展開します。

    注記

    クラスターが使用する前にイメージを圧縮解除する必要があります。ダウンロードしたファイルの名前に、.gz または .tgz などの圧縮拡張子が含まれていない場合があります。ファイルを圧縮するか、どのように圧縮するかを確認するには、コマンドラインで以下を入力します。 

    $ file <name_of_downloaded_file>

  5. 圧縮解除したイメージを、Glance などの bastion サーバーからアクセス可能な場所にアップロードします。以下に例を示します。 

    $ openstack image create --file rhcos-44.81.202003110027-0-openstack.x86_64.qcow2 --disk-format qcow2 rhcos-${RHCOS_VERSION}
    重要

    RHOSP 環境によっては、.raw または .qcow2 形式 のいずれかでイメージをアップロードできる場合があります。Ceph を使用する場合は、.raw 形式を使用する必要があります。

    警告

    インストールプログラムが同じ名前を持つ複数のイメージを見つける場合、それらのイメージのいずれかがランダムに選択されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。

これで、イメージが制限されたインストールで利用可能になります。OpenShift Container Platform デプロイメントで使用するイメージの名前または場所をメモします。

7.9. インストール設定ファイルの作成

Red Hat OpenStack Platform (RHOSP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
  • ミラーレジストリーの作成時に生成された imageContentSources 値を使用します。
  • ミラーレジストリーの証明書の内容を取得する。
  • Red Hat Enterprise Linux CoreOS (RHCOS) イメージを取得し、これをアクセス可能な場所にアップロードする。
  • サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。 

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして openstack を選択します。
      3. クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
      4. OpenShift API への外部アクセスに使用する floating IP アドレスを指定します。
      5. コントロールプレーンノードに使用する少なくとも 16 GB の RAM とコンピュートノードに使用する 8 GB の RAM を持つ RHOSP フレーバーを指定します。
      6. クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
      7. クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
      8. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。

  2. install-config.yaml ファイルで、platform.openstack.clusterOSImage の値をイメージの場所または名前に設定します。以下に例を示します。 

    platform:
  openstack:
      clusterOSImage: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d

  3. install-config.yaml ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。

    1. pullSecret の値を更新して、レジストリーの認証情報を追加します。 

      pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'

      <mirror_host_name> の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials> の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    2. additionalTrustBundle パラメーターおよび値を追加します。 

      additionalTrustBundle: |
  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----

      この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。

    3. 次の YAML の抜粋のようなイメージコンテンツリソースを追加します。 

      imageContentSources:
- mirrors:
  - <mirror_host_name>:5000/<repo_name>/release
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <mirror_host_name>:5000/<repo_name>/release
  source: registry.redhat.io/ocp/release

      これらの値には、ミラーレジストリーの作成時に記録された imageContentSources を使用します。

  4. 必要な install-config.yaml ファイルに他の変更を加えます。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。

  5. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

7.9.1. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

注記

Kuryr のインストールでは、HTTP プロキシーがデフォルト設定されます。

前提条件

  • Proxy オブジェクトを使用する制限付きネットワークで Kuryr をインストールする場合には、プロキシーはクラスターが使用するルーターとの応答が可能でなければなりません。root ユーザーとしてコマンドラインからプロキシー設定の静的ルートを追加するには、次のように入力します。 

    $ ip route add <cluster_network_cidr> via <installer_subnet_gateway>
  • 制限付きサブネットには、Kuryr が作成する Router リソースにリンクできるように定義され、使用可能なゲートウェイが必要です。
  • 既存の install-config.yaml ファイルがある。

  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。 

    apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port> 1
  httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
  noProxy: example.com 3
additionalTrustBundle: | 4
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
    5
    オプション： trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。
    注記

    インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

    注記

    インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。 

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

7.9.2. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

7.9.2.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表7.2 必須パラメーター
パラメーター説明値

apiVersion

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain と <metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata.name

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。文字列は 14 文字以上でなければなりません。

platform

インストールを実行する特定のプラットフォームの設定: alibabacloud、aws、baremetal、azure、gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}。platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}
7.9.2.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

表7.3 ネットワークパラメーター
パラメーター説明値

networking

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking.networkType

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、全 Linux ネットワーク用の CNI プラグインです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNkubernetes です。

networking.clusterNetwork

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23

networking.clusterNetwork.cidr

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking.clusterNetwork.hostPrefix

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix が 23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking.serviceNetwork

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 

networking:
  serviceNetwork:
   - 172.30.0.0/16

networking.machineNetwork

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。 

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16

networking.machineNetwork.cidr

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

7.9.2.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表7.4 オプションのパラメーター
パラメーター説明値

additionalTrustBundle

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は None、v4.11、v4.12、vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

compute

コンピュートノードを設定するマシンの設定。

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute.hyperthreading

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute.name

compute を使用する場合に必須です。マシンプールの名前。

worker

compute.platform

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

compute.replicas

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane

コントロールプレーンを設定するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane.hyperthreading

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane.name

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane.platform

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloud、aws、azure, gcp、ibmcloud、nutanix、openstack、ovirt、vsphere、または {}

controlPlane.replicas

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを Mint、Passthrough または Manual に設定する必要があります。

Mint、Passthrough、Manual、または空の文字列 ("")。

fips

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、x86_64、ppc64le、および s390x アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources.source

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources.mirrors

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

7.9.2.4. 追加の Red Hat OpenStack Platform (RHOSP) 設定パラメーター

追加の RHOSP 設定パラメーターは以下の表で説明されています。

表7.5 追加の RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.rootVolume.size

コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

compute.platform.openstack.rootVolume.type

コンピュートマシンの場合、root のボリュームタイプです。

文字列 (例: performance)。

controlPlane.platform.openstack.rootVolume.size

コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。

整数 (例: 30)。

controlPlane.platform.openstack.rootVolume.type

コントロールプレーンマシンの場合、root ボリュームのタイプです。

文字列 (例: performance)。

platform.openstack.cloud

clouds.yaml ファイルのクラウドリストにある使用する RHOCP クラウドの名前。

文字列 (例: MyCloud)。

platform.openstack.externalNetwork

インストールに使用される RHOSP の外部ネットワーク名。

文字列 (例: external)。

platform.openstack.computeFlavor

コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。

このプロパティーは非推奨にされています。すべてのマシンプールのデフォルトとしてフレーバーを使用するには、これを platform.openstack.defaultMachinePlatform プロパティーで type キーの値として追加します。それぞれのマシンプールのフレーバー値を個別に設定することもできます。

文字列 (例: m1.xlarge)。

7.9.2.5. オプションの RHOSP 設定パラメーター

オプションの RHOSP 設定パラメーターは、以下の表で説明されています。

表7.6 オプションの RHOSP パラメーター
パラメーター説明値

compute.platform.openstack.additionalNetworkIDs

コンピュートマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

compute.platform.openstack.additionalSecurityGroupIDs

コンピュートマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

compute.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

compute.platform.openstack.rootVolume.zones

コンピュートマシンの root ボリュームをインストールするアベイラビリティーゾーン。このパラメーターに値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列のリスト (例: ["zone-1", "zone-2"])。

compute.platform.openstack.serverGroupPolicy

プール内のコンピュートマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

controlPlane.platform.openstack.additionalNetworkIDs

コントロールプレーンマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。

コントロールプレーンマシンに接続されている追加のネットワークも、ブートストラップノードに接続されています。

文字列としての 1 つ以上の UUID のリスト。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

controlPlane.platform.openstack.additionalSecurityGroupIDs

コントロールプレーンマシンに関連付けられた追加のセキュリティーグループ。

文字列としての 1 つ以上の UUID のリスト。例: 7ee219f3-d2e9-48a1-96c2-e7429f1b0da7.

controlPlane.platform.openstack.zones

マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストールプログラムは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。

Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。

文字列のリスト(例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.rootVolume.zones

コントロールプレーンマシンの root ボリュームをインストールするアベイラビリティーゾーン。この値を設定しない場合、インストールプログラムはデフォルトのアベイラビリティーゾーンを選択します。

文字列の一覧 (例: ["zone-1", "zone-2"])。

controlPlane.platform.openstack.serverGroupPolicy

プール内のコントロールプレーンマシンを含むグループに適用するサーバーグループポリシー。作成後にサーバーグループのポリシーまたは所属を変更することはできません。サポートされているオプションには、anti-affinity、soft-affinity、および soft-anti-affinity が含まれます。デフォルト値は soft-anti-affinity です。

affinity ポリシーは移行を防止するため、RHOSP のアップグレードに影響します。affinity ポリシーはサポートされていません。

厳密な anti-affinity ポリシーを使用する場合は、インスタンスの移行中に追加の RHOSP ホストが必要です。

マシンプールに適用するサーバーグループポリシー。たとえば、soft-affinity。

platform.openstack.clusterOSImage

インストールプログラムが RHCOS イメージをダウンロードする場所。

ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。

HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。

例: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d。この値は、既存の Glance イメージの名前にもなり得ます (例: my-rhcos)。

platform.openstack.clusterOSImageProperties

Glance のインストーラーでアップロードされた ClusterOSImage に追加するプロパティー。このプロパティーは、platform.openstack.clusterOSImage が既存の Glance イメージに設定されている場合は無視されます。

このプロパティーを使用し、ノードあたり 26 PV の RHOSP のデフォルト永続ボリューム (PV) の制限を超過することができます。制限を超えるには、hw_scsi_model プロパティーの値を virtio-scsi に設定し、hw_disk_bus の値を scsi に設定します。

このプロパティーを使用し、hw_qemu_guest_agent プロパティーを yes の値で追加して QEMU ゲストエージェントを有効にすることもできます。

キーと値の文字列のペアのリスト。例: ["hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi"]

platform.openstack.defaultMachinePlatform

デフォルトのマシンプールプラットフォームの設定。 

{
   "type": "ml.large",
   "rootVolume": {
      "size": 30,
      "type": "performance"
   }
}

platform.openstack.ingressFloatingIP

Ingress ポートに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.apiFloatingIP

API ロードバランサーに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、platform.openstack.externalNetwork プロパティーも定義する必要があります。

IP アドレス (例: 128.0.0.1)。

platform.openstack.externalDNS

クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。

文字列としての IP アドレスのリスト。例: ["8.8.8.8", "192.168.1.12"]

platform.openstack.machinesSubnet

クラスターのノードが使用する RHOSP サブネットの UUID。ノードおよび仮想 IP (VIP) ポートがこのサブネットに作成されます。

networking.machineNetwork の最初の項目は machinesSubnet の値に一致する必要があります。

カスタムサブネットにデプロイする場合、OpenShift Container Platform インストーラーに外部 DNS サーバーを指定することはできません。代わりに、DNS を RHOSP のサブネットに追加 します。

文字列としての UUID。例: fa806b2f-ac49-4bce-b9db-124bc64209bf。

7.9.3. 制限された OpenStack インストールのカスタマイズされた install-config.yaml ファイルのサンプル

このサンプル install-config.yaml は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。

重要

このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得する必要があります。 

apiVersion: v1
baseDomain: example.com
controlPlane:
  name: master
  platform: {}
  replicas: 3
compute:
- name: worker
  platform:
    openstack:
      type: ml.large
  replicas: 3
metadata:
  name: example
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
platform:
  openstack:
    region: region1
    cloud: mycloud
    externalNetwork: external
    computeFlavor: m1.xlarge
    apiFloatingIP: 128.0.0.1
fips: false
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
additionalTrustBundle: |

  -----BEGIN CERTIFICATE-----

  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

  -----END CERTIFICATE-----

imageContentSources:
- mirrors:
  - <mirror_registry>/<repo_name>/release
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <mirror_registry>/<repo_name>/release
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

7.10. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64、ppc64le、および s390x アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。 

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。 

    $ cat ~/.ssh/id_ed25519.pub

  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。 

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。 

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

7.11. 環境へのアクセスの有効化

デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。

インストール時に Floating IP アドレス (FIP) を使用して OpenShift Container Platform API およびアプリケーションのアクセスを設定できます。FIP を設定せずにインストールを完了することもできますが、インストーラーは API またはアプリケーションを外部からアクセスする方法を設定しません。

7.11.1. floating IP アドレスを使用したアクセスの有効化

OpenShift Container Platform API およびクラスターアプリケーションへの外部アクセス用に Floating IP (FIP) アドレスを作成します。

手順

  1. Red Hat OpenStack Platform (RHOSP) CLI を使用して、API FIP を作成します。 

    $ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>

  2. Red Hat OpenStack Platform (RHOSP) CLI を使用して、apps (アプリ)、または Ingress、FIP を作成します。 

    $ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>

  3. API および Ingress FIP の DNS サーバーに、これらのパターンに準拠するレコードを追加します。 

    api.<cluster_name>.<base_domain>.  IN  A  <API_FIP>
*.apps.<cluster_name>.<base_domain>. IN  A <apps_FIP>
    注記

    DNS サーバーを制御していない場合は、次のようなクラスタードメイン名を /etc/hosts ファイルに追加することで、クラスターにアクセスできます。

    • <api_floating_ip> api.<cluster_name>.<base_domain>
    • <application_floating_ip> grafana-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> oauth-openshift.apps.<cluster_name>.<base_domain>
    • <application_floating_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
    • application_floating_ip integrated-oauth-server-openshift-authentication.apps.<cluster_name>.<base_domain>

    /etc/hosts ファイル内のクラスタードメイン名により、クラスターの Web コンソールおよび監視インターフェイスへのローカルアクセスが許可されます。kubectl または oc を使用することもできます。<application_floating_ip> を指す追加のエントリーを使用して、ユーザーアプリケーションにアクセスできます。このアクションにより、API およびアプリケーションは他のユーザーがアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

  4. FIP を、以下のパラメーターの値として install-config.yaml ファイルに追加します。

    • platform.openstack.ingressFloatingIP
    • platform.openstack.apiFloatingIP

これらの値を使用する場合には、install-config.yaml ファイルの platform.openstack.externalNetwork パラメーターの値として外部ネットワークを入力する必要もあります。

ヒント

Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。

7.11.2. Floating IP アドレスなしでのインストールの完了

Floating IP アドレスを指定せずに OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールすることができます。

install-config.yaml ファイルで以下のパラメーターを定義しないでください。

  • platform.openstack.ingressFloatingIP
  • platform.openstack.apiFloatingIP

外部ネットワークを提供できない場合は、platform.openstack.externalNetwork を空白のままにすることもできます。platform.openstack.externalNetwork の値を指定しない場合はルーターが作成されず、追加のアクションがない場合は、インストーラーは Glance からのイメージの取得に失敗します。外部接続を独自に設定する必要があります。

Floating IP アドレスまたは名前解決がないために、クラスター API に到達できないシステムからインストーラーを実行すると、インストールに失敗します。このような場合にインストールが失敗するのを防ぐために、プロキシーネットワークを使用するか、マシンと同じネットワークにあるシステムからインストーラーを実行できます。

注記

API および Ingress ポートの DNS レコードを作成して、名前解決を有効にできます。以下に例を示します。 

api.<cluster_name>.<base_domain>.  IN  A  <api_port_IP>
*.apps.<cluster_name>.<base_domain>. IN  A <ingress_port_IP>

DNS サーバーを制御しない場合は、/etc/hosts ファイルにレコードを追加できます。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

7.12. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。 

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
    --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

7.13. クラスターステータスの確認

インストール時またはインストール後に OpenShift Container Platform クラスターのステータスを確認することができます。

手順

  1. クラスター環境で、管理者の kubeconfig ファイルをエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。

  2. デプロイメント後に作成されたコントロールプレーンおよびコンピュートマシンを表示します。 

    $ oc get nodes

  3. クラスターのバージョンを表示します。 

    $ oc get clusterversion

  4. Operator のステータスを表示します。 

    $ oc get clusteroperator

  5. クラスター内のすべての実行中の Pod を表示します。 

    $ oc get pods -A

7.14. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。 

    $ oc whoami

    出力例

    system:admin

関連情報

7.15. デフォルトの OperatorHub カタログソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。

手順

  • disableAllDefaultSources: true を OperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。 

    $ oc patch OperatorHub cluster --type json \
    -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。

7.16. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

7.17. 次のステップ

第8章 OpenStack をインストールした後のネットワーク設定の設定

インストール後に、Red Hat OpenStack Platform (RHOSP) クラスター上の OpenShift Container Platform のネットワーク設定を設定できます。

8.1. Floating IP アドレスを使用したアプリケーションアクセスの設定

OpenShift Container Platform をインストールした後に、アプリケーションネットワークトラフィックを許可するように Red Hat OpenStack Platform (RHOSP) を設定します。

注記

インストール中に、install-config.yaml ファイルの platform.openstack.apiFloatingIP および platform.openstack.ingressFloatingIP に値を指定した場合、または inventory.yaml Playbook の os_api_fip および os_ingress_fip に値を指定した場合は、この手順を実行する必要はありません。Floating IP アドレスはすでに設定されています。

前提条件

  • OpenShift Container Platform クラスターがインストールされている必要があります。
  • OpenShift Container Platform の RHOSP へのインストールに関するドキュメントで説明されているように、Floating IP アドレスが有効にされます。

手順

OpenShift Container Platform クラスターをインストールした後に、Floating IP アドレスを Ingress ポートに割り当てます。

  1. ポートを表示します。 

    $ openstack port show <cluster_name>-<cluster_ID>-ingress-port

  2. ポートを IP アドレスに接続します。 

    $ openstack floating ip set --port <ingress_port_ID> <apps_FIP>

  3. *apps. のワイルドカード A レコードを DNS ファイルに追加します。 

    *.apps.<cluster_name>.<base_domain>  IN  A  <apps_FIP>
注記

DNS サーバーを制御せず、非実稼働環境でアプリケーションアクセスを有効にする必要がある場合は、これらのホスト名を /etc/hosts に追加できます。 

<apps_FIP> console-openshift-console.apps.<cluster name>.<base domain>
<apps_FIP> integrated-oauth-server-openshift-authentication.apps.<cluster name>.<base domain>
<apps_FIP> oauth-openshift.apps.<cluster name>.<base domain>
<apps_FIP> prometheus-k8s-openshift-monitoring.apps.<cluster name>.<base domain>
<apps_FIP> <app name>.apps.<cluster name>.<base domain>

8.2. OVS ハードウェアオフロードの有効化

Red Hat OpenStack Platform (RHOSP) で実行されるクラスターの場合、Open vSwitch(OVS) ハードウェアオフロードを有効にすることができます。

OVS は、大規模なマルチサーバーネットワークの仮想化を可能にするマルチレイヤー仮想スイッチです。

前提条件

  • Single-root Input/Output Virtualization (SR-IOV) 用に設定された RHOSP にクラスターをインストールしている。
  • SR-IOV Network Operator がクラスターにインストールされている。
  • クラスターに 2 つの hw-offload タイプの Virtual Function (VF) インターフェイスを作成している。
注記

アプリケーション層のゲートウェイフローは、OpenShift Container Platform バージョン 4.10、4.11、および 4.12 では機能しません。また、OpenShift Container Platform バージョン 4.13 のアプリケーション層のゲートウェイフローをオフロードすることはできません。

手順

  1. クラスターにある 2 つの hw-offload タイプの VF インターフェイスの SriovNetworkNodePolicy ポリシーを作成します。

    1 番目の Virtual Function インターフェイス

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy 1
metadata:
  name: "hwoffload9"
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    pfNames: 2
    - ens6
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: "hwoffload9"

    1
    SriovNetworkNodePolicy の値をここに挿入します。
    2
    どちらのインターフェイスにも Physical Function (PF) 名が含まれている必要があります。

    2 番目の Virtual Function インターフェイス

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy 1
metadata:
  name: "hwoffload10"
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    pfNames: 2
    - ens5
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: "hwoffload10"

    1
    SriovNetworkNodePolicy の値をここに挿入します。
    2
    どちらのインターフェイスにも Physical Function (PF) 名が含まれている必要があります。

  2. 2 つのインターフェイス用に NetworkAttachmentDefinition リソースを作成します。

    1 番目のインターフェイス用NetworkAttachmentDefinition リソース

    apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9
  name: hwoffload9
  namespace: default
spec:
    config: '{ "cniVersion":"0.3.1", "name":"hwoffload9","type":"host-device","device":"ens6"
    }'

    2 番目のインターフェイス用NetworkAttachmentDefinition リソース

    apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10
  name: hwoffload10
  namespace: default
spec:
    config: '{ "cniVersion":"0.3.1", "name":"hwoffload10","type":"host-device","device":"ens5"
    }'

  3. Pod で作成したインターフェイスを使用します。以下に例を示します。

    2 つの OVS オフロードインターフェイスを使用する Pod

    apiVersion: v1
kind: Pod
metadata:
  name: dpdk-testpmd
  namespace: default
  annotations:
    irq-load-balancing.crio.io: disable
    cpu-quota.crio.io: disable
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10
spec:
  restartPolicy: Never
  containers:
  - name: dpdk-testpmd
    image: quay.io/krister/centos8_nfv-container-dpdk-testpmd:latest

8.3. OVS ハードウェアオフロードネットワークの接続

Open vSwitch (OVS) ハードウェアオフロードネットワークをクラスターに接続できます。

前提条件

  • クラスターがインストールされ、実行されている。
  • クラスターで使用するために、Red Hat OpenStack Platform (RHOSP) で OVS ハードウェアオフロードネットワークをプロビジョニングしている。

手順

  1. 次のテンプレートから network.yaml という名前のファイルを作成します。 

    spec:
  additionalNetworks:
  - name: hwoffload1
    namespace: cnf
    rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "hwoffload1", "type": "host-device","pciBusId": "0000:00:05.0", "ipam": {}}' 1
    type: Raw

    ここでは、以下のようになります。

    pciBusId

    オフロードネットワークに接続されているデバイスを指定します。この値がわからない場合は、次のコマンドを実行してこの値を見つけることができます。 

    $ oc describe SriovNetworkNodeState -n openshift-sriov-network-operator

  2. コマンドラインから次のコマンドを入力して、ファイルを使用してクラスターにパッチを適用します。 

    $ oc apply -f network.yaml

8.4. RHOSP で Pod への IPv6 接続を有効にする

異なるノード上にある追加のネットワークを持つ Pod 間の IPv6 接続を有効にするには、サーバーの IPv6 ポートのポートセキュリティーを無効にします。ポートセキュリティーを無効にすると、Pod に割り当てられた IPv6 アドレスごとに許可されたアドレスペアを作成する必要がなくなり、セキュリティーグループのトラフィックが有効になります。

重要

次の IPv6 追加ネットワーク設定のみがサポートされています。

  • SLAAC とホストデバイス
  • SLAAC と MACVLAN
  • DHCP ステートレスおよびホストデバイス
  • DHCP ステートレスおよび MACVLAN

手順

  • コマンドラインで、次のコマンドを入力します。 

    $ openstack port set --no-security-group --disable-port-security <compute_ipv6_port> 1
    1 1
    コンピュートサーバーの IPv6 ポートを指定します。
    重要

    このコマンドは、ポートからセキュリティーグループを削除し、ポートセキュリティーを無効にします。トラフィックの制限は、ポートから完全に削除されます。

8.5. RHOSP で IPv6 接続を持つ Pod の作成

Pod の IPv6 接続を有効にして Pod に追加したら、セカンダリー IPv6 接続を持つ Pod を作成します。

手順

  1. IPv6 namespace とアノテーション k8s.v1.cni.cncf.io/networks: <additional_network_name> を使用する Pod を定義します。ここで、<additional_network_name は追加のネットワークの名前になります。たとえば、Deployment オブジェクトの一環として、以下を行います。 

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
  namespace: ipv6
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - hello-openshift
  replicas: 2
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
      annotations:
        k8s.v1.cni.cncf.io/networks: ipv6
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: hello-openshift
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        image: quay.io/openshift/origin-hello-openshift
        ports:
        - containerPort: 8080

  2. Pod を作成します。たとえば、コマンドラインで次のコマンドを入力します。 

    $ oc create -f <ipv6_enabled_resource> 1
    1
    リソース定義を含むファイルを指定します。

8.6. RHOSP 上の Pod への IPv6 接続の追加

Pod で IPv6 接続を有効にしたら、Container Network Interface (CNI) 設定を使用して Pod に接続を追加します。

手順

  1. Cluster Network Operator (CNO) を編集するには、次のコマンドを入力します。 

    $ oc edit networks.operator.openshift.io cluster

  2. spec フィールドで CNI 設定を指定します。たとえば、次の設定では、MACVLAN で SLAAC アドレスモードを使用します。 

    ...
spec:
  additionalNetworks:
  - name: ipv6
    namespace: ipv6 1
    rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "ipv6", "type": "macvlan", "master": "ens4"}' 2
    type: Raw
    1
    必ず同じ namespace に Pod を作成してください。
    2
    より多くのネットワークが設定されている場合、または別のカーネルドライバーが使用されている場合、ネットワークアタッチメントの "master" フィールドのインターフェイスは "ens4" とは異なる場合があります。
    注記

    ステートフルアドレスモードを使用している場合は、CNI 設定に IP アドレス管理 (IPAM) を含めます。

    Multus は DHCPv6 をサポートしていません。

  3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

検証

  • コマンドラインで、次のコマンドを入力します。 

    $ oc get network-attachment-definitions -A

    出力例

    NAMESPACE       NAME            AGE
ipv6            ipv6            21h

セカンダリー IPv6 接続を持つ Pod を作成できるようになりました。

第9章 OpenStack Cloud Controller Manager リファレンスガイド

9.1. OpenStack クラウドコントローラーマネージャー

OpenShift Container Platform 4.12 では、Red Hat OpenStack Platform (RHOSP) で実行されるクラスターが、従来の OpenStack クラウドプロバイダーから外部の OpenStack Cloud Controller Manager (CCM) に切り替えられました。これは、Kubernetes がツリー内の従来のクラウドプロバイダーから、Cloud Controller Manager を使用して実装される外部クラウドプロバイダーに移行したことに伴う変更です。

従来のクラウドプロバイダーのユーザー定義の設定を保持するために、移行プロセスの一環として、既存の設定が新しい設定にマップされます。openshift-config namespace で cloud-provider-config と呼ばれる設定を検索します。

注記

設定マップ名 cloud-provider-config は静的に設定されていません。これは、infrastructure/cluster CRD の spec.cloudConfig.name 値から派生します。

見つかった設定は、openshift-cloud-controller-manager namespace の cloud-conf config map に同期されます。

この同期の一環として、OpenStack CCM Operator は新しい config map を変更して、そのプロパティーが外部クラウドプロバイダーと互換性を持つようにします。ファイルは次の方法で変更されます。

  • [Global] secret-name、[Global] secret-namespace、[Global] kubeconfig-path オプションは削除されました。これらは、外部のクラウドプロバイダーには適用されません。
  • [Global] use-clouds、[Global] clouds-file、[Global] cloud オプションが追加されました。
  • [BlockStorage] セクション全体が削除されます。外部のクラウドプロバイダーは、ストレージ操作を実行しなくなりました。ブロックストレージの設定は、Cinder CSI ドライバーによって管理されます。

さらに、CCM Operator は多くのデフォルトオプションを適用します。これらのオプションの値は、次のように常にオーバーライドされます。 

[Global]
use-clouds = true
clouds-file = /etc/openstack/secret/clouds.yaml
cloud = openstack
...

[LoadBalancer]
use-octavia = true
enabled = true 1
1
ネットワークが Kuryr を使用するように設定されている場合、この値は false です。

cloud-value 値 /etc/openstack/secret/clouds.yaml は、openshift-cloud-controller-manager namespace の openstack-cloud-credentials 設定にマップされます。他の clouds.yaml ファイルと同様に、このファイルで RHOSP クラウドを変更できます。

9.2. OpenStack Cloud Controller Manager (CCM) 設定マップ

OpenStack CCM config map は、クラスターが RHOSP クラウドと対話する方法を定義します。デフォルトでは、この設定は openshift-cloud-controller-manager namespace にある cloud-conf config map の cloud.conf キーの下に保存されます。

重要

cloud-conf config map は、openshift-config namespace の cloud-provider-config config map から生成されます。

cloud-conf config map で記述されている設定を変更するには、cloud-provider-config config map を変更します。

この同期の一環として、CCM Operator はいくつかのオプションをオーバーライドします。詳細は、「RHOSP Cloud Controller Manager」を参照してください。

以下に例を示します。

cloud-conf config map の例

apiVersion: v1
data:
  cloud.conf: |
    [Global] 1
    secret-name = openstack-credentials
    secret-namespace = kube-system
    region = regionOne
    [LoadBalancer]
    use-octavia = True
kind: ConfigMap
metadata:
  creationTimestamp: "2022-12-20T17:01:08Z"
  name: cloud-conf
  namespace: openshift-cloud-controller-manager
  resourceVersion: "2519"
  uid: cbbeedaf-41ed-41c2-9f37-4885732d3677

1
config map を変更するのではなく、clouds.yaml ファイルを使用してグローバルオプションを設定します。

次のオプションが config map に存在します。特に明記されている場合を除き、RHOSP で実行されるクラスターには必須です。

9.2.1. ロードバランサー (オプション)

CCM は、Octavia を使用するデプロイメント用にいくつかのロードバランサーオプションをサポートしています。

注記

Neutron-LBaaS のサポートは廃止されました。

オプション説明

enabled

LoadBalancer タイプのサービス統合を有効にするかどうか。デフォルト値は true です。

floating-network-id

オプション: ロードバランサーの仮想 IP アドレス (VIP) のフローティング IP アドレスを作成するために使用される外部ネットワーク。クラウドに複数の外部ネットワークがある場合、このオプションを設定するか、ユーザーがサービスアノテーションで loadbalancer.openstack.org/floating-network-id を指定する必要があります。

floating-subnet-id

オプション: ロードバランサー VIP のフローティング IP アドレスを作成するために使用される外部ネットワークサブネット。サービスアノテーション loadbalancer.openstack.org/floating-subnet-id でオーバーライドできます。

floating-subnet

オプション: ロードバランサー VIP のフローティング IP アドレスを作成するために使用される外部ネットワークサブネットの名前パターン (~ で始まる場合はグロブまたは正規表現)。サービスアノテーション loadbalancer.openstack.org/floating-subnet でオーバーライドできます。複数のサブネットがパターンに一致する場合、使用可能な IP アドレスを持つ最初のサブネットが使用されます。

floating-subnet-tags

オプション: ロードバランサー VIP のフローティング IP アドレスを作成するために使用される外部ネットワークサブネットのタグ。サービスアノテーション loadbalancer.openstack.org/floating-subnet-tags でオーバーライドできます。複数のサブネットがこれらのタグに一致する場合、使用可能な IP アドレスを持つ最初のサブネットが使用されます。

RHOSP ネットワークが共有を無効にして設定されている場合 (たとえば、作成時に --no-share フラグが使用されている場合)、このオプションはサポートされません。このオプションを使用するには、共有するネットワークを設定します。

lb-method

ロードバランサープールの作成に使用される負荷分散アルゴリズム。Amphora プロバイダーの場合、値は ROUND_ROBIN、LEAST_CONNECTIONS、または SOURCE_IP です。デフォルト値は ROUND_ROBIN です。

OVN プロバイダーでは、SOURCE_IP_PORT アルゴリズムのみがサポートされています。

Amphora プロバイダの場合、LEAST_CONNECTIONS または SOURCE_IP メソッドを使用する場合、openshift-config namespace の cloud-provider-config config map で create-monitor オプションを true として設定します。また、ロードバランサータイプサービスの ETP:Local で、クライアントからサービスのエンドポイント接続でバランスアルゴリズムの実行ができるよう構成します。

lb-provider

オプション: amphora や octavia など、ロードバランサーのプロバイダーを指定するために使用されます。Amphora および Octavia プロバイダーのみがサポートされています。

lb-version

オプション: ロードバランサー API のバージョン。"v2" のみがサポートされています。

subnet-id

ロードバランサー VIP が作成されるネットワークサービスサブネットの ID。

network-id

ロードバランサーの仮想 IP が作成される Networking サービスのネットワークの ID。subnet-id が設定されている場合は不要です。

create-monitor

サービスロードバランサーのヘルスモニターを作成するかどうか。externalTrafficPolicy: Local を宣言するサービスには、ヘルスモニターが必要です。デフォルト値は false です。

ovn プロバイダーでバージョン 17 より前の RHOSP を使用する場合、このオプションはサポートされません。

monitor-delay

プローブがロードバランサーのメンバーに送信される間隔 (秒単位)。デフォルト値は 5 です。

monitor-max-retries

ロードバランサーメンバーの動作ステータスを ONLINE に変更するために必要なチェックの成功回数。有効な範囲は 1 ~ 10 で、デフォルト値は 1 です。

monitor-timeout

モニターがタイムアウトする前にバックエンドへの接続を待機する時間 (秒単位)。デフォルト値は 3 です。

internal-lb

フローティング IP アドレスなしで内部ロードバランサーを作成するかどうか。デフォルト値は false です。

LoadBalancerClass "ClassName"

これは、一連のオプションで構成される設定セクションです。

  • floating-network-id
  • floating-subnet-id
  • floating-subnet
  • floating-subnet-tags
  • network-id
  • subnet-id

これらのオプションの動作は、CCM 設定ファイルのロードバランサーセクションにある同じ名前のオプションの動作と同じです。

サービスアノテーション loadbalancer.openstack.org/class を指定することで ClassName 値を設定できます。

max-shared-lb

ロードバランサーを共有できるサービスの最大数。デフォルト値は 2 です。

9.2.2. Operator がオーバーライドするオプション

CCM Operator は、RHOSP の設定で認識できる次のオプションをオーバーライドします。自分で設定しないでください。これらは、情報提供のみを目的としてこのドキュメントに含まれています。

オプション説明

auth-url

RHOSP ID サービスの URL。たとえば、http://128.110.154.166/identity です。

os-endpoint-type

サービスカタログから使用するエンドポイントのタイプ。

username

Identity サービスのユーザー名。

password

Identity サービスのユーザーパスワード。

domain-id

Identity サービスのユーザードメイン ID。

domain-name

Identity サービスのユーザードメイン名。

tenant-id

Identity サービスのプロジェクト ID。Identity サービスアプリケーションの認証情報を使用している場合は、このオプションを未設定のままにします。

識別子 tenant を project に変更したバージョン 3 の Identity API では、tenant-id の値が API の project コンストラクトに自動的にマップされます。

tenant-name

Identity サービスのプロジェクト名。

tenant-domain-id

Identity サービスプロジェクトのドメイン ID。

tenant-domain-name

Identity サービスプロジェクトのドメイン名。

user-domain-id

Identity サービスのユーザードメイン ID。

user-domain-name

Identity サービスのユーザードメイン名。

use-clouds

clouds.yaml ファイルから認証認証情報をフェッチするかどうか。このセクションで設定されたオプションは、clouds.yaml ファイルから読み取られた値よりも優先されます。

CCM は、次の場所でファイルを検索します。

  1. clouds-file オプションの値。
  2. 環境変数 OS_CLIENT_CONFIG_FILE に格納されているファイルパス。
  3. ディレクトリー pkg/openstack。
  4. ディレクトリー ~/.config/openstack。
  5. ディレクトリー /etc/openstack。

clouds-file

clouds.yaml ファイルのファイルパス。use-clouds オプションが true に設定されている場合に使用されます。

cloud

使用する clouds.yaml ファイル内の名前付きクラウド。use-clouds オプションが true に設定されている場合に使用されます。

第10章 OpenStack でのクラスターのアンインストール

Red Hat OpenStack Platform (RHOSP) にデプロイしたクラスターを削除できます。

10.1. installer-provisioned infrastructure を使用するクラスターの削除

installer-provisioned infrastructure を使用するクラスターは、クラウドから削除できます。

注記

クラスターを AWS C2S Secret Region にデプロイした場合、インストールプログラムはクラスターの破棄をサポートしません。クラスターリソースは手動で削除する必要があります。

注記

アンインストール後に、とくにユーザーによってプロビジョニングされるインフラストラクチャー (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストールプログラムが作成しなかったリソース、またはインストールプログラムがアクセスできないリソースが存在する可能性があります。たとえば、一部の Google Cloud リソースには共有 VPC ホストプロジェクトで IAM パーミッション が必要になるか、削除する必要のあるヘルスチェック が使用されていない可能性があります。

前提条件

  • クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
  • クラスター作成時にインストールプログラムが生成したファイルがあります。

手順

  1. クラスターのインストールに使用したコンピューターで、インストールプログラムを含むディレクトリーに移動し、次のコマンドを実行します。 

    $ ./openshift-install destroy cluster \
--dir <installation_directory> --log-level info 1 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なる詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。
    注記

    クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある metadata.json ファイルが必要になります。

  2. オプション: <installation_directory> ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。

第11章 独自のインフラストラクチャーからの RHOSP のクラスターのアンインストール

user-provisioned infrastructure の Red Hat OpenStack Platform (RHOSP) にデプロイしたクラスターを削除することができます。

11.1. Playbook 依存関係のダウンロード

user-provisioned infrastructure での削除プロセスを簡素化する Ansible Playbook には、複数の Python モジュールが必要です。プロセスを実行するマシンで、モジュールのリポジトリーを追加し、それらをダウンロードします。

注記

この手順では、Red Hat Enterprise Linux (RHEL) 8 を使用していることを前提としています。

前提条件

  • Python 3 がマシンにインストールされている。

手順

  1. コマンドラインで、リポジトリーを追加します。

    1. Red Hat Subscription Manager に登録します。 

      $ sudo subscription-manager register # If not done already

    2. 最新のサブスクリプションデータをプルします。 

      $ sudo subscription-manager attach --pool=$YOUR_POOLID # If not done already

    3. 現在のリポジトリーを無効にします。 

      $ sudo subscription-manager repos --disable=* # If not done already

    4. 必要なリポジトリーを追加します。 

      $ sudo subscription-manager repos \
  --enable=rhel-8-for-x86_64-baseos-rpms \
  --enable=openstack-16-tools-for-rhel-8-x86_64-rpms \
  --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
  --enable=rhel-8-for-x86_64-appstream-rpms

  2. モジュールをインストールします。 

    $ sudo yum install python3-openstackclient ansible python3-openstacksdk

  3. python コマンドが python3 を参照していることを確認します。 

    $ sudo alternatives --set python /usr/bin/python3

11.2. 独自のインフラストラクチャーを使用する RHOSP からのクラスターの削除

独自のインフラストラクチャーを使用する Red Hat OpenStack Platform (RHOSP) の OpenShift Container Platform クラスターを削除できます。削除プロセスを迅速に完了するには、複数の Ansible Playbook を実行します。

前提条件

  • Python 3 がマシンにインストールされている。
  • 「Playbook 依存関係のダウンロード」でモジュールをダウンロードしている。
  • クラスターのインストールに使用した Playbook がある。
  • 対応するインストール Playbook に加えた変更を反映するように down- の接頭辞が付けられた Playbook を変更している。たとえば、bootstrap.yaml ファイルへの変更は down-bootstrap.yaml ファイルに反映されます。
  • すべての Playbook は共通ディレクトリーにある。

手順

  1. コマンドラインで、ダウンロードした Playbook を実行します。 

    $ ansible-playbook -i inventory.yaml  \
	down-bootstrap.yaml      \
	down-control-plane.yaml  \
	down-compute-nodes.yaml  \
	down-load-balancers.yaml \
	down-network.yaml        \
	down-security-groups.yaml
  2. OpenShift Container Platform インストールに対して加えた DNS レコードの変更を削除します。

OpenShift Container Platform はお使いのインフラストラクチャーから削除されます。

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.