7.2. ネットワークのカスタマイズによるベアメタルへのクラスターのインストール

OpenShift Container Platform バージョン 4.7 では、カスタマイズされたネットワーク設定オプションでプロビジョニングするベアメタルインフラストラクチャーにクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。

大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。

7.2.1. 前提条件

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

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

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

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

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

7.2.3. ユーザーによってプロビジョニングされるインフラストラクチャーでのクラスターのマシン要件

ユーザーによってプロビジョニングされるインフラストラクチャーを含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。

7.2.3.1. 必要なマシン

最小の OpenShift Container Platform クラスターでは以下のホストが必要です。

  • 1 つの一時的なブートストラップマシン
  • 3 つのコントロールプレーン、またはマスター、マシン
  • 少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。3 ノードクラスターを実行している場合は、サポートされるのは、実行されるコンピュートマシンがゼロの場合です。1 つのコンピュートマシンの実行はサポートされていません。
注記

クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。

重要

クラスターの高可用性を維持するには、これらのクラスターマシンについて別個の物理ホストを使用します。

ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは Red Hat Enterprise Linux CoreOS (RHCOS) または Red Hat Enterprise Linux (RHEL) 7.9 のいずれかを選択できます。

RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。

7.2.3.2. ネットワーク接続の要件

すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs のネットワークがマシン設定サーバーから Ignition 設定ファイルをフェッチする必要があります。初回の起動時に、Ignition 設定ファイルをダウンロードできるようネットワーク接続を確立するために、マシンには DHCP サーバーまたはその静的 IP アドレスが設定されている必要になります。さらに、クラスター内の各 OpenShift Container Platform ノードは Network Time Protocol (NTP) サーバーにアクセスできる必要があります。DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。

7.2.3.3. 最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表7.13 最小リソース要件

マシンオペレーティングシステムCPU [1]RAMストレージIOPS [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS または RHEL 7.9

2

8 GB

100 GB

300

  1. CPU 1 つ分は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = CPU
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。

7.2.3.4. 証明書署名要求の管理

ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。

7.2.4. ユーザーによってプロビジョニングされるインフラストラクチャーの作成

ユーザーによってプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターをデプロイする前に、基礎となるインフラストラクチャーを作成する必要があります。

前提条件

手順

  1. 各ノードに DHCP を設定するか、または静的 IP アドレスを設定します。
  2. 必要なロードバランサーをプロビジョニングします。
  3. マシンのポートを設定します。
  4. DNS を設定します。
  5. ネットワーク接続を確認します。

7.2.4.1. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件

すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs のネットワークがマシン設定サーバーから Ignition 設定をフェッチする必要があります。

初回の起動時に、Ignition 設定ファイルをダウンロードできるようネットワーク接続を確立するために、マシンには DHCP サーバーまたはその静的 IP アドレスが設定されている必要があります。

クラスターのマシンを長期間管理するために DHCP サーバーを使用することが推奨されています。DHCP サーバーが永続 IP アドレスおよびホスト名をクラスターマシンに提供するように設定されていることを確認します。

Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照することができます。

マシン間のネットワーク接続を、クラスターのコンポーネントが通信できるように設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。

表7.14 すべてのマシンに対応するすべてのマシン

プロトコルポート説明

ICMP

該当なし

ネットワーク到達性のテスト

TCP

1936

メトリクス

9000-9999

ホストレベルのサービス。 ポート 9100-9101 のノードエクスポーター、ポート 9099 の Cluster Version Operator が含まれます。

10250-10259

Kubernetes が予約するデフォルトポート

10256

openshift-sdn

UDP

4789

VXLAN および Geneve

6081

VXLAN および Geneve

9000-9999

ポート 9100-9101 のノードエクスポーターを含む、ホストレベルのサービス。

TCP/UDP

30000-32767

Kubernetes ノードポート

表7.15 コントロールプレーンへのすべてのマシン

プロトコルポート説明

TCP

6443

Kubernetes API

表7.16 コントロールプレーンマシンへのコントロールプレーンマシン

プロトコルポート説明

TCP

2379-2380

etcd サーバーおよびピアポート

ネットワークトポロジー要件

クラスター用にプロビジョニングするインフラストラクチャーは、ネットワークトポロジーの以下の要件を満たす必要があります。

重要

OpenShift Container Platform では、すべてのノードが、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するためにインターネットへの直接のアクセスが必要です。

ロードバランサー

OpenShift Container Platform をインストールする前に、以下の要件を満たす 2 つのロードバランサーをプロビジョニングする必要があります。

  1. API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、API ルートの Server Name Indication (SNI) を有効にする必要があります。
    • ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
    重要

    API ロードバランサーのセッションの永続性は設定しないでください。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表7.17 API ロードバランサー

    ポートバックエンドマシン (プールメンバー)内部外部説明

    6443

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの /readyz エンドポイントを設定する必要があります。

    X

    X

    Kubernetes API サーバー

    22623

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。

    X

     

    マシン設定サーバー

    注記

    ロードバランサーは、API サーバーが /readyz エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。

  2. Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、Ingress ルートの Server Name Indication (SNI) を有効にする必要があります。
    • 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表7.18 アプリケーション Ingress ロードバランサー

    ポートバックエンドマシン (プールメンバー)内部外部説明

    443

    デフォルトで Ingress ルーター Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTPS トラフィック

    80

    デフォルトで Ingress ルーター Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTP トラフィック

ヒント

クライアントの実際の IP アドレスがロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。

注記

Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。コントロールプレーンの初期化後に Ingress ルーターを設定する必要があります。

NTP 設定

OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、またはクラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。

DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。

7.2.4.2. ユーザーによってプロビジョニングされるインフラストラクチャーの DNS 要件

DNS は、名前解決および逆引き名前解決に使用されます。DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。逆引きレコードは、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するために重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。

以下の DNS レコードは、ユーザーによってプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターに必要です。各レコードで、 <cluster_name> はクラスター名で、<base_domain> は、install-config.yaml ファイルに指定するクラスターのベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。

表7.19 必要な DNS レコード

コンポーネントレコード説明

Kubernetes API

api.<cluster_name>.<base_domain>.

DNS A/AAAA または CNAME レコード、および DNS PTR レコードを、コントロールプレーンマシンのロードバランサーを特定するために追加します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

api-int.<cluster_name>.<base_domain>.

DNS A/AAAA または CNAME レコード、および DNS PTR レコードを、コントロールプレーンマシンのロードバランサーを特定するために追加します。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。

重要

API サーバーは、 Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。

ルート

*.apps.<cluster_name>.<base_domain>.

デフォルトでワーカーノードの Ingress ルーター Pod を実行するマシンをターゲットにするロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコードを追加します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

ブートストラップ

bootstrap.<cluster_name>.<base_domain>.

DNS A/AAAA または CNAME レコードおよび DNS PTR レコードを、ブートストラップマシンを特定するために追加します。これらのレコードは、クラスター内のノードで解決できる必要があります。

マスターホスト

<master><n>.<cluster_name>.<base_domain>.

コントロールプレーンノード (別名マスターノード) の各マシンを識別するための DNS A/AAAA または CNAME レコードと DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。

ワーカーホスト

<worker><n>.<cluster_name>.<base_domain>.

DNS A/AAAA または CNAME レコードおよび DNS PTR レコードを、ワーカーノードの各マシンを特定するために追加します。これらのレコードは、クラスター内のノードで解決できる必要があります。

ヒント

nslookup <hostname> コマンドを使用して、名前解決を確認することができます。dig -x <ip_address> コマンドを使用して、PTR レコードの逆引き名前解決を確認できます。

BIND ゾーンファイルの以下の例は、名前解決の A レコードの例を示しています。この例の目的は、必要なレコードを表示することです。この例では、特定の名前解決サービスを選択するためのアドバイスを提供することを目的としていません。

例7.3 DNS ゾーンデータベースのサンプル

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1	IN	A	192.168.1.5
smtp	IN	A	192.168.1.5
;
helper	IN	A	192.168.1.5
helper.ocp4	IN	A	192.168.1.5
;
; The api identifies the IP of your load balancer.
api.ocp4		IN	A	192.168.1.5
api-int.ocp4		IN	A	192.168.1.5
;
; The wildcard also identifies the load balancer.
*.apps.ocp4		IN	A	192.168.1.5
;
; Create an entry for the bootstrap host.
bootstrap.ocp4	IN	A	192.168.1.96
;
; Create entries for the master hosts.
master0.ocp4		IN	A	192.168.1.97
master1.ocp4		IN	A	192.168.1.98
master2.ocp4		IN	A	192.168.1.99
;
; Create entries for the worker hosts.
worker0.ocp4		IN	A	192.168.1.11
worker1.ocp4		IN	A	192.168.1.7
;
;EOF

以下の BIND ゾーンファイルの例では、逆引き名前解決の PTR レコードの例を示しています。

例7.4 逆引きレコードの DNS ゾーンデータベースの例

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
; The syntax is "last octet" and the host must have an FQDN
; with a trailing dot.
97	IN	PTR	master0.ocp4.example.com.
98	IN	PTR	master1.ocp4.example.com.
99	IN	PTR	master2.ocp4.example.com.
;
96	IN	PTR	bootstrap.ocp4.example.com.
;
5	IN	PTR	api.ocp4.example.com.
5	IN	PTR	api-int.ocp4.example.com.
;
11	IN	PTR	worker0.ocp4.example.com.
7	IN	PTR	worker1.ocp4.example.com.
;
;EOF
注記

インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの場合、DNS レコードのみを追加する必要があります。

7.2.5. SSH プライベートキーの生成およびエージェントへの追加

クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent とインストールプログラムの両方に SSH キーを指定する必要があります。このキーを使用してパブリッククラスターのブートストラップマシンにアクセスし、インストールの問題をトラブルシューティングできます。

注記

実稼働環境では、障害復旧およびデバッグが必要です。

このキーを使用して、ユーザー core としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core ユーザーの ~/.ssh/authorized_keys 一覧に追加されます。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

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

    このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。

    注記

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

  2. ssh-agent プロセスをバックグラウンドタスクとして開始します。

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

    出力例

    Agent pid 31874

    注記

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

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

    $ ssh-add <path>/<file_name> 1

    出力例

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

    1
    ~/.ssh/id_rsa などの、SSH プライベートキーのパスおよびファイル名を指定します。

次のステップ

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

7.2.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 など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

7.2.7. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.7 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

7.2.7.1. Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.7 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. アーカイブを展開します。

    $ tar xvzf <file>
  5. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

$ oc <command>

7.2.7.2. Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.7 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

C:\> oc <command>

7.2.7.3. macOC への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.7 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

$ oc <command>

7.2.8. インストール設定ファイルの手動作成

ユーザーによってプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform のインストールでは、インストール設定ファイルを手動で生成します。

前提条件

  • OpenShift Container Platform インストーラープログラムおよびクラスターのアクセストークンを取得します。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

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

  2. 以下の install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイル install-config.yaml に名前を付ける必要があります。

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

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

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

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

注記

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

重要

openshift-install コマンドは、パラメーターのフィールド名を検証しません。正しくない名前を指定すると、関連するファイルまたはオブジェクトは作成されず、エラーが報告されません。指定されたパラメーターのフィールド名が正しいことを確認します。

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

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

表7.20 必須パラメーター

パラメーター説明

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 などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。

platform

インストールの実行に使用する特定プラットフォームの設定: awsbaremetalazureopenstackovirtvsphereplatform.<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.2.8.1.2. ネットワーク設定パラメーター

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

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

表7.21 ネットワークパラメーター

パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) プラグイン。

OpenShiftSDN または OVNKubernetes のいずれか。デフォルト値は OpenShiftSDN です。

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

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定される場合、各ノードに指定の 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.2.8.1.3. オプションの設定パラメーター

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

表7.22 オプションのパラメーター

パラメーター説明

additionalTrustBundle

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

文字列

compute

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

MachinePool オブジェクトの配列。詳細は、以下の Machine-pool の表を参照してください。

compute.architecture

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

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

awsazuregcpopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。詳細は、以下の Machine-pool の表を参照してください。

controlPlane.architecture

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

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

awsazuregcpopenstackovirtvsphere、または {}

controlPlane.replicas

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

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

credentialsMode

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

注記

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

MintPassthroughManual、または空の文字列 ("")。

fips

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

重要

FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、x86_64 アーキテクチャーの 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 キーを指定します。

1 つ以上のキー。以下に例を示します。

sshKey:
  <key1>
  <key2>
  <key3>

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

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、または必要なパラメーターの値を変更することができます。

apiVersion: v1
baseDomain: example.com 1
compute: 2
- hyperthreading: Enabled 3
  name: worker
  replicas: 0 4
controlPlane: 5
  hyperthreading: Enabled 6
  name: master
  replicas: 3 7
metadata:
  name: test 8
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 9
    hostPrefix: 23 10
  networkType: OpenShiftSDN
  serviceNetwork: 11
  - 172.30.0.0/16
platform:
  none: {} 12
fips: false 13
pullSecret: '{"auths": ...}' 14
sshKey: 'ssh-ed25519 AAAA...' 15
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 5
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
3 6
同時マルチスレッド (SMT) または hyperthreading を有効/無効にするかどうか。デフォルトでは、SMT はマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。SMT を無効にする場合、これをすべてのクラスターマシンで無効にする必要があります。これにはコントロールプレーンとコンピュートマシンの両方が含まれます。
注記

同時マルチスレッド (SMT) はデフォルトで有効になっています。SMT が BIOS 設定で有効になっていない場合は、hyperthreading パラメーターは効果がありません。

重要

BIOS または install-config.yaml であるかに関係なく hyperthreading を無効にする場合、容量計画においてマシンのパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

4
replicas パラメーターの値を 0 に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、ユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
7
クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
8
DNS レコードに指定したクラスター名。
9
Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。
注記

クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。

10
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定され、各ノードに指定の cidr から /23 サブネットが割り当てられます (510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます)。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
11
サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
12
プラットフォームを none に設定する必要があります。プラットフォーム用に追加のプラットフォーム設定変数を指定することはできません。
警告

Red Hat Virtualization は現在、oVirt プラットフォーム上にあるユーザーによってプロビジョニングされるインフラストラクチャーでのインストールをサポートしていません。そのため、プラットフォームを none に設定し、OpenShift Container Platform が各ノードをベアメタルノードとして、およびクラスターをベアメタルクラスターとして識別できるようにします。これは、任意のプラットフォームにクラスターをインストールする のと同じであり、次の制限があります。

  1. クラスタープロバイダーがないため、各マシンを手動で追加する必要があり、ノードスケーリング機能はありません。
  2. oVirt CSI ドライバーはインストールされず、CSI 機能はありません。
13
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、x86_64 アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。

14
Red Hat OpenShift Cluster Manager からのプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
15
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーのデフォルト SSH キーの公開部分。
注記

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

7.2.9. ネットワーク設定フェーズ

インストール前にクラスター設定を指定する場合、ネットワーク設定を変更する際に、インストール手順にはいくつかのフェーズがあります。

フェーズ 1

openshift-install create install-config コマンドを入力した後に、以下のことを実行します。install-config.yaml ファイルで、以下のネットワーク関連のフィールドをカスタマイズできます。

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork

    これらのフィールドの詳細は、インストール設定パラメーターを参照してください。

    注記

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

フェーズ 2
openshift-install create manifests コマンドを入力した後に、以下のことを実行します。高度なネットワーク設定を指定する必要がある場合、このフェーズで、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。

フェーズ 2 で、install-config.yaml ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 ではクラスターネットワークプロバイダーをさらにカスタマイズできます。

7.2.10. 高度なネットワーク設定の指定

高度な設定のカスタマイズを使用し、クラスターネットワークプロバイダーの追加設定を指定して、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルの変更はサポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了します。
  • クラスターの Ignition 設定ファイルを生成します。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    $ ./openshift-install create manifests --dir <installation_directory>

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    $ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
    EOF

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。
  3. エディターで cluster-network-03-config.yml ファイルを開き、以下の例のようにクラスターの高度なネットワーク設定を指定します。

    OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        openshiftSDNConfig:
          vxlanPort: 4800

    OVN-Kubernetes ネットワークプロバイダーを有効にします。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig: {}

  4. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。

7.2.11. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承し、これらのフィールドは変更できません。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
OpenShift SDN または OVN-Kubernetes などのクラスターネットワークプロバイダー。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプロバイダー設定を指定できます。

7.2.11.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表7.23 Cluster Network Operator 設定オブジェクト

フィールドタイプ説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定する一覧です。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

この値は読み取り専用であり、install-config.yaml ファイルに指定されます。

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

この値は読み取り専用であり、install-config.yaml ファイルに指定されます。

spec.defaultNetwork

object

クラスターネットワークの Container Network Interface (CNI) ネットワークプロバイダーを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表7.24 defaultNetwork オブジェクト

フィールドタイプ説明

type

string

OpenShiftSDN または OVNKubernetes のいずれか。クラスターネットワークプロバイダーはインストール時に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform はデフォルトで、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーを使用します。

openshiftSDNConfig

object

このオブジェクトは OpenShift SDN クラスターネットワークプロバイダーにのみ有効です。

ovnKubernetesConfig

object

このオブジェクトは OVN-Kubernetes クラスターネットワークプロバイダーにのみ有効です。

OpenShift SDN CNI クラスターネットワークプロバイダーの設定

以下の表は、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーの設定フィールドについて説明しています。

表7.25 openshiftSDNConfig オブジェクト

フィールドタイプ説明

mode

string

OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は NetworkPolicy です。

Multitenant および Subnet の値は、OpenShift Container Platform 3.x との後方互換性を維持するために利用できますが、その使用は推奨されていません。この値は、クラスターのインストール後は変更できません。

mtu

integer

VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 50 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1450 に設定する必要があります。

この値は、クラスターのインストール後は変更できません。

vxlanPort

integer

すべての VXLAN パケットに使用するポート。デフォルト値は 4789 です。この値は、クラスターのインストール後は変更できません。

別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。

Amazon Web Services (AWS) では、VXLAN にポート 9000 とポート 9999 間の代替ポートを選択できます。

OpenShift SDN 設定の例

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定

以下の表は OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定フィールドについて説明しています。

表7.26 ovnKubernetesConfig object

フィールドタイプ説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

この値は、クラスターのインストール後は変更できません。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 暗号化を有効にするために空のオブジェクトを指定します。この値は、クラスターのインストール後は変更できません。

OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig: {}

kubeProxyConfig オブジェクト設定

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表7.27 kubeProxyConfig オブジェクト

フィールドタイプ説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

7.2.12. Ignition 設定ファイルの作成

クラスターマシンは手動で起動する必要があるため、クラスターがマシンを作成するために必要な Ignition 設定ファイルを生成する必要があります。

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

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。

手順

  • Ignition 設定ファイルを取得します。

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

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

    以下のファイルはディレクトリーに生成されます。

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign

7.2.13. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始

OpenShift Container Platform を独自にプロビジョニングするベアメタルインフラストラクチャーにインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) をマシンにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプについて OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。

RHCOS をマシンにインストールするには、ISO イメージまたはネットワーク PXE ブートを使用する手順のいずれかを実行します。

注記

このインストールガイドに含まれるコンピュートノードのデプロイメント手順は、RHCOS 固有のものです。代わりに RHEL ベースのコンピュートノードのデプロイを選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピュートマシンの使用は非推奨となり、OpenShift Container Platform 4 の今後のリリースで削除される予定です。

以下の方法を使用して、ISO および PXE のインストール時に RHCOS を設定できます。

  • カーネル引数: カーネル引数を使用してインストール固有の情報を提供できます。たとえば、HTTP サーバーにアップロードした RHCOS インストールファイルの場所と、インストールするノードタイプの Ignition 設定ファイルの場所を指定できます。PXE インストールの場合、APPEND パラメーターを使用して、ライブインストーラーのカーネルに引数を渡すことができます。ISO インストールの場合は、ライブインストール起動プロセスを中断してカーネル引数を追加できます。いずれのインストールの場合でも、特殊な coreos.inst.* 引数を使用してライブインストーラーに指示を与えたり、標準のカーネルサービスをオンまたはオフにするために標準のインストールブート引数を使用したりできます。
  • Ignition 設定: OpenShift Container Platform Ignition 設定ファイル (*.ign) は、インストールするノードのタイプに固有のものです。RHCOS のインストール時にブートストラップ、コントロールプレーン、またはコンピュートノードの Ignition 設定ファイルの場所を渡して、初回起動時に有効にされるようにします。特別なケースでは、ライブシステムに渡すために個別の制限付き Ignition 設定を作成できます。この Ignition 設定は、インストールが正常に完了したことをプロビジョニングシステムに報告するなどの一連のタスクを実行する可能性があります。この特別な Ignition 設定は、インストール済みシステムの初回ブート時に適用される coreos-installer によって使用されます。標準のコントロールプレーンおよびコンピュートノードの Ignition 設定をライブ ISO に直接指定しないでください。
  • coreos-installer: ライブ ISO インストーラーをシェルプロンプトで起動できます。これにより、初回のブート前にさまざまな方法で永続的なシステムの準備を行うことができます。特に、coreos-installer コマンドを実行すると、追加するさまざまなアーティファクトを特定し、ディスクパーティションを使用し、ネットワークを設定できます。場合によっては、ライブシステムで機能を設定し、それらをインストールされたシステムにコピーできます。

ISO または PXE インストールを使用するかどうかは、状況によって異なります。PXE インストールには、利用可能な DHCP サービスとさらなる準備が必要ですが、インストールプロセスはさらに自動化することが可能です。ISO インストールは主に手動によるプロセスで、複数のマシンを設定する場合には使用しにくい可能性があります。

注記

OpenShift Container Platform 4.6 の時点で、RHCOS ISO およびその他のインストールアーティファクトは、4K セクターのディスクへのインストールをサポートします。

7.2.13.1. ISO イメージを使用した Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

ユーザーによってプロビジョニングされるインフラストラクチャーにクラスターをインストールする前に、それが使用する RHCOS マシンを作成する必要があります。ISO イメージを使用してマシンを作成することができます。

前提条件

  • クラスターの Ignition 設定ファイルを取得している。
  • お使いのコンピューターからアクセスでき、作成するマシンからアクセスできる HTTP サーバーへのアクセスがある。

手順

  1. インストールプログラムが作成したコントロールプレーン、コンピュート、およびブートストラップ Ignition 設定を HTTP サーバーにアップロードします。これらのファイルの URL をメモします。

    重要

    インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

  2. RHCOS イメージミラー ページからオペレーティングシステムのインスタンスをインストールするために優先される方法で必要な RHCOS イメージを取得します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。この手順には ISO イメージのみを使用します。RHCOS qcow2 イメージは、このインストールではサポートされません。

    ISO ファイルの名前は以下の例のようになります。

    rhcos-<version>-live.<architecture>.iso

  3. ISO を使用し、RHCOS インストールを開始します。以下のインストールオプションのいずれかを使用します。

    • ディスクに ISO イメージを書き込み、これを直接起動します。
    • LOM インターフェイスで ISO リダイレクトを使用します。
  4. ISO イメージを起動します。インストール起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに coreos-installer コマンドを使用する必要があります。オプションを指定せず、中断なしでライブインストーラーを実行する場合、インストーラーはライブシステムのシェルプロンプトで起動し、RHCOS をディスクにインストールする準備が整います。
  5. coreos-installer を実行する前に、ネットワークやディスクパーティションなどのさまざまな機能を設定する方法については、高度な RHCOS インストールの参照 セクションを参照してください。
  6. coreos-installer コマンドを実行します。最低でも、ノードタイプの Ignition 設定ファイルの場所と、インストールするディスクの場所を特定する必要があります。以下は例です。

    $ sudo coreos-installer install \
         --ignition-url=https://host/worker.ign /dev/sda
  7. RHCOS のインストール後に、システムは再起動します。システムの再起動後、指定した Ignition 設定ファイルを適用します。
  8. 継続してクラスターの他のマシンを作成します。

    重要

    この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、クラスターのインストール前に少なくとも 2 つのコンピュートマシンを作成します。

7.2.13.2. PXE または iPXE ブートによる Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

手動でプロビジョニングされる RHCOS ノードを使用するクラスターをインストールする前に、それが使用する RHCOS マシンを作成する必要があります。PXE または iPXE ブートを使用してマシンを作成することができます。

前提条件

  • クラスターの Ignition 設定ファイルを取得している。
  • 適切な PXE または iPXE インフラストラクチャーを設定していること。
  • 使用しているコンピューターからアクセス可能な HTTP サーバーへのアクセスがあること。

手順

  1. インストールプログラムが作成したマスター、ワーカーおよびブートストラップの Ignition 設定を HTTP サーバーにアップロードします。これらのファイルの URL をメモします。

    重要

    HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

  2. RHCOS イメージミラーページから RHCOS kernelinitramfs、および rootfs ファイルを取得します。

    重要

    RHCOS アーティファクトは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのアーティファクトをダウンロードする必要があります。この手順で説明されている適切な kernelinitramfs、および rootfs アーティファクトのみを使用します。RHCOS qcow2 イメージは、このインストールではサポートされません。

    ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。

    • kernel: rhcos-<version>-live-kernel-<architecture>
    • initramfs: rhcos-<version>-live-initramfs.<architecture>.img
    • rootfs: rhcos-<version>-live-rootfs.<architecture>.img
  3. 使用する起動方法に必要な追加ファイルをアップロードします。

    • 従来の PXE の場合、kernel および initramfs ファイルを TFTP サーバーと rootfs ファイルを HTTP サーバーにアップロードします。
    • iPXE の場合、kernelinitramfs、および rootfs ファイルを HTTP サーバーにアップロードします。

      重要

      インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

  4. RHCOS のインストール後にマシンがローカルディスクから起動されるようにネットワークブートインフラストラクチャーを設定します。
  5. RHCOS イメージに PXE または iPXE インストールを設定します。

    ご使用の環境についての以下の例で示されるメニューエントリーのいずれかを変更し、イメージおよび Ignition ファイルが適切にアクセスできることを確認します。

    • PXE の場合:

      DEFAULT pxeboot
      TIMEOUT 20
      PROMPT 0
      LABEL pxeboot
          KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
          APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 2 3
      1
      HTTP サーバーにアップロードしたライブ kernel ファイルの場所を指定します。URL は HTTP、TFTP、または FTP である必要があります。HTTPS および NFS はサポートされません。
      2
      複数の NIC を使用する場合、ip オプションに単一インターフェイスを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
      3
      HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。initrd パラメーター値は initramfs ファイルの場所であり、coreos.live.rootfs_url パラメーター値は rootfs ファイルの場所、また coreos.inst.ignition_url パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。APPEND 行にカーネル引数を追加して、ネットワークやその他の起動オプションを設定することもできます。
      注記

      この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、APPEND 行に 1 つ以上の console= 引数を追加します。たとえば、console=tty0 console=ttyS0 を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? を参照してください。

    • iPXE の場合:

      kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 1 2
      initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
      boot
      1
      HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。kernel パラメーター値は kernel ファイルの場所であり、initrd=main 引数は UEFI システムでの起動に必要であり、 coreos.live.rootfs_url パラメーター値は rootfs ファイルの場所であり、coreos.inst.ignition_url パラメーターはブートストラップ Ignition 設定ファイルの場所になります。
      2
      複数の NIC を使用する場合、ip オプションに単一インターフェイスを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
      3
      HTTP サーバーにアップロードした initramfs ファイルの場所を指定します。
      注記

      この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、kernel 行に console= 引数を 1 つ以上追加します。たとえば、console=tty0 console=ttyS0 を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? を参照してください。

  6. PXE UEFI を使用する場合は、以下の操作を実行します。

    1. システムの起動に必要な shimx64.efi and grubx64.efi EFI バイナリーと grub.cfg ファイルを指定します。

      • ホストに RHCOS ISO をマウントしてから、images/efiboot.img ファイルをマウントし、必要な EFI バイナリーを展開します。

        $ mkdir -p /mnt/iso
        $ mkdir -p /mnt/efiboot
        $ mount -o loop rhcos-installer.x86_64.iso /mnt/iso
        $ mount -o loop,ro /mnt/iso/images/efiboot.img /mnt/efiboot
      • efiboot.img マウントポイントから、EFI/redhat/shimx64.efi および EFI/redhat/grubx64.efi ファイルを TFTP サーバーにコピーします。

        $ cp /mnt/efiboot/EFI/redhat/shimx64.efi .
        $ cp /mnt/efiboot/EFI/redhat/grubx64.efi .
        $ umount /mnt/efiboot
        $ umount /mnt/iso
      • RHCOS ISO に含まれている EFI/redhat/grub.cfg ファイルを TFTP サーバーにコピーします。
    2. grub.cfg ファイルを編集し、以下のような引数を追加します。

      menuentry 'Install Red Hat Enterprise Linux CoreOS' --class fedora --class gnu-linux --class gnu --class os {
      	linuxefi rhcos-<version>-live-kernel-<architecture> coreos.inst.install_dev=/dev/sda coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
      	initrdefi rhcos-<version>-live-initramfs.<architecture>.img
      }

      詳細は以下のようになります。

      rhcos-<version>-live-kernel-<architecture>
      TFTP サーバーにアップロードした kernel ファイルを指定します。
      http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img
      HTTP サーバーにアップロードしたライブ rootfs イメージの場所を指定します。
      http://<HTTP_server>/bootstrap.ign
      HTTP サーバーにアップロードしたブートストラップ Ignition 設定ファイルの場所を指定します。
      rhcos-<version>-live-initramfs.<architecture>.img
      TFTP サーバーにアップロードした initramfs ファイルの場所を指定します。
      注記

      UEFI ブート用に PXE サーバーを設定する方法は、Red Hat ナレッジベースの記事 How to configure/setup a PXE server for Red Hat Enterprise Linux? を参照してください。

  7. クラスターのマシンの作成を続行します。

    重要

    この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、クラスターのインストール前に少なくとも 2 つのコンピュートマシンを作成します。

7.2.13.3. 高度な Red Hat Enterprise Linux CoreOS (RHCOS) インストール設定

OpenShift Container Platform 用の Red Hat Enterprise Linux CoreOS (RHCOS) ノードを手動でプロビジョニングする主な利点として、デフォルトの OpenShift Container Platform インストール方法では利用できない設定を実行できることがあります。本セクションでは、以下のような手法で実行できるいくつかの設定について説明します。

  • カーネル引数をライブインストーラーに渡す
  • ライブシステムからの coreos-installer の手動による実行
  • ISO への Ignition 設定の埋め込み

本セクションで説明されている手動の Red Hat Enterprise Linux CoreOS (RHCOS) インストールの高度な設定トピックは、ディスクパーティション設定、ネットワーク、および複数の異なる方法での Ignition 設定の使用に関連しています。

7.2.13.3.1. PXE および ISO インストールの高度なネットワークオプションの使用

OpenShift Container Platform ノードのネットワークはデフォルトで DHCP を使用して、必要な設定をすべて収集します。静的 IP アドレスを設定したり、ボンディングなどの特別な設定を行う場合は、以下のいずれかの方法で実行できます。

  • ライブインストーラーの起動時に、特別なカーネルパラメーターを渡します。
  • マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
  • ライブインストーラーのシェルプロンプトからネットワークを設定し、それらの設定をインストール済みシステムにコピーして、インストール済みシステムの初回起動時に有効になるようにします。

PXE または iPXE インストールを設定するには、以下のオプションのいずれかを使用します。

  • 詳細の RHCOS インストールリファレンスの表を参照してください。
  • マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。

ISO インストールを設定するには、以下の手順に従います。

手順

  1. ISO インストーラーを起動します。
  2. ライブシステムシェルプロンプトから、nmcli または nmtui などの利用可能な RHEL ツールを使用して、ライブシステムのネットワークを設定します。
  3. coreos-installer コマンドを実行してシステムをインストールし、--copy-network オプションを追加してネットワーク設定をコピーします。以下に例を示します。

    $ coreos-installer install --copy-network \
         --ignition-url=http://host/worker.ign /dev/sda
    重要

    --copy-network オプションは、/etc/NetworkManager/system-connections にあるネットワーク設定のみをコピーします。特に、システムのホスト名はコピーされません。

  4. インストール済みのシステムで再起動します。
7.2.13.3.2. ディスクパーティション設定

ディスクパーティションは、Red Hat Enterprise Linux CoreOS (RHCOS) のインストール時に OpenShift Container Platform クラスターノードに作成されます。特定のアーキテクチャーの各 RHCOS ノードは、デフォルトのパーティション設定が上書きされない限り、同じパーティションレイアウトを使用します。RHCOS のインストール時に、ルートファイルシステムのサイズが拡大し、ターゲットデバイスの残りの使用可能なスペースが使用されます。

ただし、以下は、OpenShift Container Platform ノードのインストール時に、デフォルトのパーティション設定を上書きするために介入が必要と思われる 2 つのケースになります。

  • 別個のパーティションの作成: 空のディスクへのグリーンフィールドインストールの場合は、別のストレージをパーティションに追加する必要がある場合があります。これは、/var または /var/lib/etcd などの /var のサブディレクトリー (両方ではない) を個別のパーティションとして作成する場合にのみ正式にサポートされます。

    重要

    Kubernetes は 2 つのファイルシステムパーティションのみをサポートします。元の設定に複数のパーティションを追加すると、Kubernetes はそれらをすべて監視できません。

  • 既存のパーティションの保持: ブラウンフィールドインストールで、既存のノードに OpenShift Container Platform を再インストールし、以前のオペレーティングシステムからのデータパーティションを維持する必要がある場合、既存のデータパーティションを保持できる coreos-installer へのブート引数とオプションの両方があります。
7.2.13.3.2.1. 個別の /var パーティションの作成

一般的に、OpenShift Container Platform のディスクパーティション設定は、インストーラーに任せる必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。

OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。

  • /var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。
  • /var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。
  • /var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。

/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。

/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定を作成して、別の /var パーティションを設定します。

手順

  1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

    $ mkdir $HOME/clusterconfig
  2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

    $ openshift-install create manifests --dir $HOME/clusterconfig
    ? SSH Public Key ...
    $ ls $HOME/clusterconfig/openshift/
    99_kubeadmin-password-secret.yaml
    99_openshift-cluster-api_master-machines-0.yaml
    99_openshift-cluster-api_master-machines-1.yaml
    99_openshift-cluster-api_master-machines-2.yaml
    ...
  3. MachineConfig オブジェクトを作成し、これを openshift ディレクトリーのファイルに追加します。たとえば、98-var-partition.yaml ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          disks:
          - device: /dev/<device_name> 1
            partitions:
            - label: var
              startMiB: <partition_start_offset> 2
              sizeMiB: <partition_size> 3
          filesystems:
            - device: /dev/disk/by-partlabel/var
              path: /var
              format: xfs
        systemd:
          units:
            - name: var.mount 4
              enabled: true
              contents: |
                [Unit]
                Before=local-fs.target
                [Mount]
                What=/dev/disk/by-partlabel/var
                Where=/var
                Options=defaults,prjquota 5
                [Install]
                WantedBy=local-fs.target
    1
    パーティションを設定する必要のあるディスクのストレージデバイス名。
    2
    データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
    3
    データパーティションのサイズ (メビバイト単位)。
    4
    マウントユニットの名前は、Where= ディレクティブで指定されたディレクトリーと一致する必要があります。たとえば、/var/lib/containers にマウントされているファイルシステムの場合、ユニットの名前は var-lib-containers.mount にする必要があります。
    5
    コンテナーストレージに使用されるファイルシステムでは、 prjquota マウントオプションを有効にする必要があります。
    注記

    個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

  4. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

    $ openshift-install create ignition-configs --dir $HOME/clusterconfig
    $ ls $HOME/clusterconfig/
    auth  bootstrap.ign  master.ign  metadata.json  worker.ign

Ignition 設定ファイルを ISO または PXE の手動インストール手順に入力として使用し、Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールできます。

7.2.13.3.2.2. 既存パーティションの保持

ISO インストールの場合は、インストーラーに 1 つ以上の既存パーティションを維持させる coreos-installer コマンドラインにオプションを追加することができます。PXE インストールの場合、APPEND coreos.inst.* オプションを追加してパーティションを保持できます。

保存したパーティションは、保持する必要があるデータパーティションを持つ既存の OpenShift Container Platform システムからのパーティションである可能性があります。以下にいくつかのヒントを紹介します。

  • 既存のパーティションを保存し、それらのパーティションが RHCOS の十分な領域を残さない場合、インストールは失敗します。この場合、保存したパーティションが破損することはありません。
  • パーティションラベルまたは番号のいずれかで保持する必要のあるディスクパーティションを特定します。

ISO インストールの場合:

この例では、パーティションラベルが data (data*) で始まるパーティションを保持します。

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
        --save-partlabel 'data*' /dev/sda

以下の例では、ディスク上の 6 番目のパーティションを保持する方法で coreos-installer を実行する方法を説明しています。

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
        --save-partindex 6 /dev/sda

この例では、パーティション 5 以上を保持します。

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign
        --save-partindex 5- /dev/sda

パーティションの保存が使用された以前の例では、coreos-installer はパーティションをすぐに再作成します。

PXE インストールの場合:

この APPEND オプションは、パーティションラベルが 'data' ('data*') で始まるパーティションを保持します。

coreos.inst.save_partlabel=data*

この APPEND オプションは、パーティション 5 以上を保持します。

coreos.inst.save_partindex=5-

この APPEND オプションは、パーティション 6 を保持します。

coreos.inst.save_partindex=6
7.2.13.3.3. Ignition 設定の特定

RHCOS の手動インストールを実行する場合、提供できる Ignition 設定には 2 つのタイプがあり、それぞれを提供する理由もそれぞれ異なります。

  • Permanent install Ignition config: すべての手動の RHCOS インストールは、bootstrap.ignmaster.ign、および worker.ign などの openshift-installer が生成した Ignition 設定ファイルのいずれかを渡し、インストールを実行する必要があります。

    重要

    これらのファイルを変更することは推奨されません。

    PXE インストールの場合、coreos.inst.ignition_url= オプションを使用して、APPEND 行に Ignition 設定を渡します。ISO インストールの場合、シェルプロンプトで ISO を起動した後に、--ignition-url= オプションを指定した coreos-installer コマンドラインで Ignition 設定を特定します。いずれの場合も、HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

  • Live install Ignition config: このタイプは手動で作成され、Red Hat でサポートされていないため、可能な場合は使用しないようにする必要があります。この方法では、Ignition 設定はライブインストールメディアに渡され、起動時にすぐに実行され、RHCOS システムのディスクへのインストール前後にセットアップタスクを実行します。この方法は、マシン設定を使用して実行できない高度なパーティション設定など、一度の適用後に再度適用する必要のないタスクの実行にのみ使用する必要があります。

    PXE または ISO ブートの場合、Ignition 設定を作成し、ignition.config.url= オプションに対して APPEND を実行し、 Ignition 設定の場所を特定できます。また、ignition.firstboot ignition.platform.id=metal も追加する必要があります。追加しない場合は、ignition.config.url が無視されます。

7.2.13.3.3.1. RHCOS ISO への Ignition 設定の埋め込み

ライブインストール Ignition 設定を RHCOS ISO イメージに直接埋め込むことができます。ISO イメージが起動すると、埋め込み設定が自動的に適用されます。

手順

  1. 以下のイメージミラーページから coreos-installer バイナリーをダウンロードします: https://mirror.openshift.com/pub/openshift-v4/clients/coreos-installer/latest/
  2. RHCOS ISO イメージおよび Ignition 設定ファイルを取得し、それらを /mnt などのアクセス可能なディレクトリーにコピーします。

    # cp rhcos-<version>-live.x86_64.iso bootstrap.ign /mnt/
    # chmod 644 /mnt/rhcos-<version>-live.x86_64.iso
  3. 以下のコマンドを実行して Ignition 設定を ISO に埋め込みます。

    # ./coreos-installer iso ignition embed -i /mnt/bootstrap.ign \
         /mnt/rhcos-<version>-live.x86_64.iso

    その ISO を使用して、指定されたライブインストール Ignition 設定を使用して RHCOS をインストールできるようになります。

    重要

    coreos-installer iso ignition embed を使用して、openshift-installer によって生成されるファイル (例: bootstrap.ignmaster.ign および worker.ign) を埋め込むことはサポートされておらず、かつ推奨されていません。

  4. 埋め込み Ignition 設定の内容を表示し、これをファイルに転送するには、以下を実行します。

    # ./coreos-installer iso ignition show /mnt/rhcos-<version>-live.x86_64.iso > mybootstrap.ign
    # diff -s bootstrap.ign mybootstrap.ign

    出力例

    Files bootstrap.ign and mybootstrap.ign are identical

  5. Ignition 設定を削除し、再利用できるように ISO をその初期状態に戻すには、以下を実行します。

    # ./coreos-installer iso ignition remove /mnt/rhcos-<version>-live.x86_64.iso

    別の Ignition 設定を ISO に埋め込むか、または ISO を初期状態で使用することができるようになりました。

7.2.13.3.4. 詳細の RHCOS インストールリファレンス

このセクションでは、Red Hat Enterprise Linux CoreOS (RHCOS) の手動インストールプロセスを変更できるようにするネットワーク設定および他の高度なオプションについて説明します。以下の表では、RHCOS ライブインストーラーおよび coreos-installer コマンドで使用できるカーネル引数およびコマンドラインのオプションを説明します。

RHCOS ブートプロンプトでのルーティングおよびボンディングのオプション

ISO イメージから RHCOS をインストールする場合、そのイメージを起動してノードのネットワークを設定する際に手動でカーネル引数を追加できます。ネットワークの引数が使用される場合、インストールはデフォルトで DHCP を使用するように設定されます。

重要

ネットワーク引数を追加する場合、rd.neednet=1 カーネル引数も追加する必要があります。

以下の表では、ライブ ISO インストールに ip=nameserver=、および bond= カーネル引数を使用する方法を説明します。

注記

順序は、カーネル引数の ip=nameserver=、および bond= を追加する場合に重要です。

ISO のルーティングおよびボンディングのオプション

以下の表は、Red Hat Enterprise Linux CoreOS (RHCOS) ノードのネットワーク設定の例を示しています。これらは、システムの起動時に dracut ツールに渡されるネットワークオプションです。dracut でサポートされるネットワークオプションの詳細は、man ページの dracut.cmdline を参照してください。

詳細

IP アドレスを設定するには、DHCP (ip=dhcp) を使用するか、または個別の静的 IP アドレス (ip=<host_ip>) を設定します。次に、各ノードの DNS サーバーの IP アドレス (nameserver=<dns_ip>) を特定します。この例では、以下を設定します。

  • ノードの IP アドレス: 10.10.10.2
  • ゲートウェイアドレス: 10.10.10.254
  • ネットワーク: 255.255.255.0
  • ホスト名: core0.example.com
  • DNS サーバーアドレス: 4.4.4.41
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41

複数の ip= エントリーを指定して、複数のネットワークインターフェイスを指定します。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

オプション: rd.route= value を設定して、追加のネットワークへのルートを設定できます。

追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。

デフォルトゲートウェイを設定するには、以下の手順に従います。

ip=::10.10.10.254::::

追加ネットワークのルートを設定するには、以下を実行します。

rd.route=20.20.20.0/24:20.20.20.254:enp2s0

2 つ以上のネットワークインターフェイスがあり、1 つのインターフェイスのみが使用される場合などに、1 つのインターフェイスで DHCP を無効にします。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none

複数のネットワークインターフェイスを持つシステムで、DHCP および静的 IP 設定を組み合わせることができます。

ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

オプション: vlan= パラメーターを使用して、個別のインターフェイスに VLAN を設定できます。

ネットワークインターフェイスに VLAN を設定し、静的 IP アドレスを使用するには、以下を実行します。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none
vlan=enp2s0.100:enp2s0

ネットワークインターフェイス上に VLAN を設定し、DHCP を使用するには、以下を行います。

ip=enp2s0.100:dhcp
vlan=enp2s0.100:enp2s0

各サーバーに nameserver= エントリーを追加して、複数の DNS サーバーを指定できます。

nameserver=1.1.1.1
nameserver=8.8.8.8

オプション: 複数のネットワークインターフェイスを単一のインターフェイスにボンディングすることは、bond= オプションを使用によってサポートされます。次の 2 つの例では、以下のようになります。

  • ボンディングされたインターフェイスを設定する構文は bond=name[:network_interfaces][:options] です。
  • name は、ボンディングデバイス名 (bond0) で、network_interfaces は物理 (イーサネット) インターフェイス (em1,em2) のコンマ区切り一覧を表します。options はボンディングオプションのコンマ区切りの一覧です。modinfo bonding を入力して、利用可能なオプションを表示します。
  • Bond= を使用してボンディングされたインターフェイスを作成する場合は、IP アドレスの割り当て方法とボンディングされたインターフェイスのその他の情報を指定する必要があります。

DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを dhcp に設定します。以下に例を示します。

bond=bond0:em1,em2:mode=active-backup
ip=bond0:dhcp

静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。

bond=bond0:em1,em2:mode=active-backup
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none

オプション: vlan= パラメーターを使用して、ボンディングされたインターフェイスに VLAN を設定できます。

ボンディングされたインターフェイスを VLAN で設定し、DHCP を使用するには、以下を行います。

ip=bond0.100:dhcp
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond0

ボンディングされたインターフェイスを VLAN で設定し、静的 IP アドレスを使用するには、以下を行います。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0.100:none
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond0

オプション: team= パラメーターを使用することで、ボンディングの代わりにネットワークチーミングを使用できます。この例では、以下のように設定されています。

  • チームインターフェイス設定の構文は team= name [:network_interfaces] です。

    name はチームデバイス名 (team0)、network_interfacesは物理 (イーサネット) インターフェイス (em1、em2) のコンマ区切りリストを表します。

注記

RHCOS が次のバージョンの RHEL に切り替わると、チーミングは非推奨になる予定です。詳細は、Red Hat ナレッジベースアーティクル libvirt-lxc を使用した Linux コンテナー (廃止) を参照してください。

ネットワークチームを設定する方法:

team=team0:em1,em2
ip=team0:dhcp
ISO または PXE インストールの coreos.inst ブートオプション

ほとんどの標準的なインストールブート引数をライブインストーラーに渡すことはできますが、RHCOS ライブインストーラーに固有の引数がいくつかあります。

  • ISO の場合、RHCOS インストーラーを中断してこれらのオプションを追加できます。
  • PXE または iPXE の場合、PXE カーネルを起動する前にこれらのオプションを APPEND 行に追加する必要があります。ライブの PXE インストールを中断することはできません。

以下の表は、ISO および PXE インストールの RHCOS ライブインストーラーブートオプションを示しています。

表7.28 coreos.inst ブートオプション

引数説明

coreos.inst.install_dev

必須。インストール先のシステムのブロックデバイス。sda は許可されていますが、 /dev/sda などの完全パスを使用することが推奨されます。

coreos.inst.ignition_url

オプション: インストール済みシステムに埋め込む Ignition 設定の URL。URL が指定されていない場合、Ignition 設定は埋め込まれません。

coreos.inst.save_partlabel

オプション: インストール時に保存するパーティションのコンマ区切りのラベル。glob 形式のワイルドカードが許可されます。指定したパーティションは存在する必要はありません。

coreos.inst.save_partindex

オプション: インストール時に保存するパーティションのコンマ区切りのインデックス。範囲 m-n は許可され、 m または n のいずれかを省略できます。指定したパーティションは存在する必要はありません。

coreos.inst.insecure

オプション: coreos.inst.image_url で署名なしと指定される OS イメージを許可します。

coreos.inst.image_url

オプション: 指定した RHCOS イメージをダウンロードし、インストールします。

  • この引数は実稼働環境では使用できず、デバッグの目的でのみ使用することが意図されています。
  • この引数は、ライブメディアに一致しないバージョンの RHCOS をインストールするために使用できますが、インストールするバージョンに一致するメディアを使用することが推奨されます。
  • coreos.inst.image_url を使用している場合は、coreos.inst.insecure も使用する必要があります。これは、ベアメタルメディアが OpenShift Container Platform について GPG で署名されていないためです。
  • HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

coreos.inst.skip_reboot

オプション: システムはインストール後に再起動しません。インストールが完了するとプロンプトが表示され、インストール時に生じる内容を検査できます。この引数は実稼働環境では使用できず、デバッグの目的でのみ使用することが意図されています。

coreos.inst.platform_id

オプション: RHCOS イメージがインストールされるプラットフォームの Ignition プラットフォーム ID。デフォルトは metal です。このオプションは、VMware などのクラウドプロバイダーから Ignition 設定を要求するかどうかを決定します。例: coreos.inst.platform_id=vmware

ignition.config.url

オプション: ライブ起動の Ignition 設定の URL。たとえば、これは coreos-installer の起動方法をカスタマイズしたり、インストール前後にコードを実行するために使用できます。これはインストール済みシステムの Ignition 設定である coreos.inst.ignition_url とは異なります。

ISO インストールの coreos-installer オプション

また、コマンドラインから coreos-installer コマンドを直接呼び出して RHCOS をインストールすることもできます。先の表のカーネル引数は、起動時に coreos-installer を自動的に呼び出すためのショートカットを提供しますが、シェルプロンプトから実行している場合は、同様の引数を coreos-installer に直接渡すことができます。

以下の表は、ライブインストール時にシェルプロンプトから coreos-installer コマンドに渡すことのできるオプションとサブコマンドを示しています。

表7.29 coreos-installer コマンドラインオプション、引数、およびサブコマンド

コマンドラインオプション

オプション

詳細

-u--image-url <url>

イメージの URL を手動で指定します。

-f--image-file <path>

ローカルイメージファイルを手動で指定します。

-i, --ignition-file <path>

ファイルから Ignition 設定を埋め込みます。

-I--ignition-url <URL>

URL から Ignition 設定を埋め込みます。

--ignition-hash <digest>

Ignition 設定の type-value をダイジェスト値を取得します。

-p--platform <name>

Ignition プラットフォーム ID を上書きします。

--append-karg <arg>…​

デフォルトのカーネル引数を追加します。

--delete-karg <arg>…​

デフォルトのカーネル引数を削除します。

-n--copy-network

インストール環境からネットワーク設定をコピーします。

重要

--copy-network オプションは、/etc/NetworkManager/system-connections にあるネットワーク設定のみをコピーします。特に、システムのホスト名はコピーされません。

--network-dir <path>

-n を指定して使用する場合。デフォルトは /etc/NetworkManager/system-connections/ です。

--save-partlabel <lx>..

このラベル glob でパーティションを保存します。

--save-partindex <id>…​

この数または範囲でパーティションを保存します。

--offline

オフラインインストールを強制的に実行します。

--insecure

署名の検証を省略します。

--insecure-ignition

HTTPS またはハッシュなしで Ignition URL を許可します。

--architecture <name>

ターゲット CPU アーキテクチャー。デフォルトは x86_64 です。

--preserve-on-error

エラー時のパーティションテーブルは消去しないでください。

-h--help

ヘルプ情報を表示します。

コマンドライン引数

引数

詳細

<device>

宛先デバイス。

coreos-installer 組み込み Ignition コマンド

コマンド

詳細

$ coreos-installer iso ignition embed <options> --ignition-file <file_path> <ISO_image>

Ignition 設定を ISO イメージに埋め込みます。

coreos-installer iso ignition show <options> <ISO_image>

ISO イメージから埋め込まれた Ignition 設定を表示します。

coreos-installer iso ignition remove <options> <ISO_image>

ISO イメージから埋め込まれた Ignition 設定を削除します。

coreos-installer ISO Ignition options

オプション

詳細

-f, --force

既存の Ignition 設定を上書きします。

-i--ignition-file <path>

使用される Ignition 設定。デフォルトは stdin です。

-o--output <path>

新しい出力ファイルに ISO を書き込みます。

-h--help

ヘルプ情報を表示します。

coreos-installer PXE Ignition commands

コマンド

詳細

これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。

coreos-installer pxe ignition wrap <options>

イメージに Ignition 設定をラップします。

coreos-installer pxe ignition unwrap <options> <image_name>

イメージでラップされた Ignition 設定を表示します。

coreos-installer pxe ignition unwrap <options> <initrd_name>

initrd イメージでラップされた Ignition 設定を表示します。

coreos-installer PXE Ignition オプション

オプション

詳細

-i--ignition-file <path>

使用される Ignition 設定。デフォルトは stdin です。

-o, --output <path>

新しい出力ファイルに ISO を書き込みます。

-h--help

ヘルプ情報を表示します。

7.2.13.4. bootupd を使用したブートローダーの更新

bootupd を使用してブートローダーを更新するには、RHCOS マシンに bootupd を手動でインストールするか、または有効にされた systemd ユニットでマシン設定を指定する必要があります。grubby またはその他のブートローダーツールとは異なり、bootupd はカーネル引数を渡すなどのカーネル領域の設定を管理しません。

bootupd のインストール後に、これを OpenShift Container Platform クラスターからリモート管理できます。

注記

BootHole の脆弱性からの保護などを目的として、bootupd は、ベアメタルまたは仮想化ハイパーバイザーのインストールでのみ使用することが推奨されます。

手動のインストール方法

bootctl コマンドラインツールを使用して、bootupd を手動でインストールできます。

  1. システムのステータスを検査します。

    # bootupctl status

    出力例

    Component EFI
      Installed: grub2-efi-x64-1:2.04-31.fc33.x86_64,shim-x64-15-8.x86_64
      Update: At latest version

  1. インストールされている bootupd なしで作成された RHCOS イメージには、明示的な導入フェーズが必要になります。

    システムのステータスが Adoptable の場合に、導入を実行します。

    # bootupctl adopt-and-update

    出力例

    Updated: grub2-efi-x64-1:2.04-31.fc33.x86_64,shim-x64-15-8.x86_64

  2. 更新が利用可能な場合は、更新を適用して、次回の再起動時に変更が有効になるようにします。

    # bootupctl update

    出力例

    Updated: grub2-efi-x64-1:2.04-31.fc33.x86_64,shim-x64-15-8.x86_64

マシン設定方法

bootupd を有効にするもう 1 つの方法としては、マシン設定を指定する方法があります。

  • 以下の例のように、有効にされた systemd ユニットでマシン設定ファイルを指定します。

    出力例

      variant: rhcos
      version: 1.1.0
      systemd:
        units:
          - name: custom-bootupd-auto.service
            enabled: true
            contents: |
              [Unit]
              Description=Bootupd automatic update
    
              [Service]
              ExecStart=/usr/bin/bootupctl update
              RemainAfterExit=yes
    
              [Install]
              WantedBy=multi-user.target

7.2.14. クラスターの作成

OpenShift Container Platform クラスターを作成するには、ブートストラッププロセスが、インストールプログラムで生成した Ignition 設定ファイルを使用してプロビジョニングしたマシンで完了するのを待機します。

前提条件

  • クラスターに必要なインフラストラクチャーを作成する。
  • インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
  • Ignition 設定ファイルを使用して、クラスターの RHCOS マシンを作成済している。
  • お使いのマシンでインターネットに直接アクセスできるか、または HTTP または HTTPS プロキシーが利用できる。

手順

  1. ブートストラッププロセスをモニターします。

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 1
        --log-level=info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    出力例

    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
    INFO API v1.20.0 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

    重要

    この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、マシン自体を削除し、再フォーマットすることができます。

7.2.15. 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.2.16. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.20.0
    master-1  Ready     master  63m  v1.20.0
    master-2  Ready     master  64m  v1.20.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 によって自動的に承認されます。

    注記

    ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc 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.20.0
    master-1  Ready     master  73m  v1.20.0
    master-2  Ready     master  74m  v1.20.0
    worker-0  Ready     worker  11m  v1.20.0
    worker-1  Ready     worker  11m  v1.20.0

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

7.2.17. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.7.0   True        False         False      3h56m
    baremetal                                  4.7.0   True        False         False      29h
    cloud-credential                           4.7.0   True        False         False      29h
    cluster-autoscaler                         4.7.0   True        False         False      29h
    config-operator                            4.7.0   True        False         False      6h39m
    console                                    4.7.0   True        False         False      3h59m
    csi-snapshot-controller                    4.7.0   True        False         False      4h12m
    dns                                        4.7.0   True        False         False      4h15m
    etcd                                       4.7.0   True        False         False      29h
    image-registry                             4.7.0   True        False         False      3h59m
    ingress                                    4.7.0   True        False         False      4h30m
    insights                                   4.7.0   True        False         False      29h
    kube-apiserver                             4.7.0   True        False         False      29h
    kube-controller-manager                    4.7.0   True        False         False      29h
    kube-scheduler                             4.7.0   True        False         False      29h
    kube-storage-version-migrator              4.7.0   True        False         False      4h2m
    machine-api                                4.7.0   True        False         False      29h
    machine-approver                           4.7.0   True        False         False      6h34m
    machine-config                             4.7.0   True        False         False      3h56m
    marketplace                                4.7.0   True        False         False      4h2m
    monitoring                                 4.7.0   True        False         False      6h31m
    network                                    4.7.0   True        False         False      29h
    node-tuning                                4.7.0   True        False         False      4h30m
    openshift-apiserver                        4.7.0   True        False         False      3h56m
    openshift-controller-manager               4.7.0   True        False         False      4h36m
    openshift-samples                          4.7.0   True        False         False      4h30m
    operator-lifecycle-manager                 4.7.0   True        False         False      29h
    operator-lifecycle-manager-catalog         4.7.0   True        False         False      29h
    operator-lifecycle-manager-packageserver   4.7.0   True        False         False      3h59m
    service-ca                                 4.7.0   True        False         False      29h
    storage                                    4.7.0   True        False         False      4h30m

  2. 利用不可の Operator を設定します。

7.2.17.1. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift イメージレジストリー Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、イメージレジストリー Operator 設定を編集して managementStateRemoved から Managed に切り替える必要があります。

注記

Prometheus コンソールは、以下のような ImageRegistryRemoved アラートを提供します。

"Image Registry has been removed.ImageStreamTags, BuildConfigs and DeploymentConfigs which reference ImageStreamTags may not work as expected.ストレージを設定して、configs.imageregistry.operator.openshift.io を編集して設定を Managed 状態に更新してください。

7.2.17.2. イメージレジストリーストレージの設定

イメージレジストリー Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定についての手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

7.2.17.3. ブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時にブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. イメージレジストリーストレージをブロックストレージタイプとして設定するには、レジストリーが Recreate ロールアウトストラテジーを使用し、1 つの (1) レプリカのみで実行されるように、レジストリーにパッチを適用します。

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。
  3. 正しい PVC を参照するようにレジストリー設定を編集します。

7.2.18. ユーザーによってプロビジョニングされるインフラストラクチャーでのインストールの完了

Operator 設定の完了後に、提供するインフラストラクチャーでのクラスターのインストールを終了できます。

前提条件

  • コントロールプレーンが初期化されています。
  • Operator の初期設定を完了済みです。

手順

  1. 以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.7.0   True        False         False      3h56m
    baremetal                                  4.7.0   True        False         False      29h
    cloud-credential                           4.7.0   True        False         False      29h
    cluster-autoscaler                         4.7.0   True        False         False      29h
    config-operator                            4.7.0   True        False         False      6h39m
    console                                    4.7.0   True        False         False      3h59m
    csi-snapshot-controller                    4.7.0   True        False         False      4h12m
    dns                                        4.7.0   True        False         False      4h15m
    etcd                                       4.7.0   True        False         False      29h
    image-registry                             4.7.0   True        False         False      3h59m
    ingress                                    4.7.0   True        False         False      4h30m
    insights                                   4.7.0   True        False         False      29h
    kube-apiserver                             4.7.0   True        False         False      29h
    kube-controller-manager                    4.7.0   True        False         False      29h
    kube-scheduler                             4.7.0   True        False         False      29h
    kube-storage-version-migrator              4.7.0   True        False         False      4h2m
    machine-api                                4.7.0   True        False         False      29h
    machine-approver                           4.7.0   True        False         False      6h34m
    machine-config                             4.7.0   True        False         False      3h56m
    marketplace                                4.7.0   True        False         False      4h2m
    monitoring                                 4.7.0   True        False         False      6h31m
    network                                    4.7.0   True        False         False      29h
    node-tuning                                4.7.0   True        False         False      4h30m
    openshift-apiserver                        4.7.0   True        False         False      3h56m
    openshift-controller-manager               4.7.0   True        False         False      4h36m
    openshift-samples                          4.7.0   True        False         False      4h30m
    operator-lifecycle-manager                 4.7.0   True        False         False      29h
    operator-lifecycle-manager-catalog         4.7.0   True        False         False      29h
    operator-lifecycle-manager-packageserver   4.7.0   True        False         False      3h59m
    service-ca                                 4.7.0   True        False         False      29h
    storage                                    4.7.0   True        False         False      4h30m

    あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 30m0s for the cluster to initialize...

    Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

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

    1. すべての Pod の一覧を表示するには、以下のコマンドを使用します。

      $ oc get pods --all-namespaces

      出力例

      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

    2. 以下のコマンドを使用して、直前のコマンドの出力に一覧表示される Pod のログを表示します。

      $ oc logs <pod_name> -n <namespace> 1
      1
      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

  3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

    詳細は、インストール後の設定 ドキュメントの RHCOS でのカーネル引数を使用したマルチパスの有効化について参照してください。

7.2.19. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.7 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

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

関連情報

7.2.20. 次のステップ