1.2. ネットワークのカスタマイズによる vSphere へのクラスターのインストール

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

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

1.2.1. 前提条件

1.2.2. OpenShift Container Platform のインターネットアクセスおよび Telemetry アクセス

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

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

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

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

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

1.2.3. VMware vSphere インフラストラクチャーの要件

使用するコンポーネントの要件を満たす VMware vSphere バージョン 6 インスタンスに OpenShift Container Platform クラスターをインストールする必要があります。

表1.7 VMware コンポーネントのサポートされる vSphere の最小バージョン

コンポーネントサポートされる最小バージョン説明

ハイパーバイザー

vSphere 6.5 および HW バージョン 13

このバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。Red Hat Enterprise Linux 8 でサポートされるハイパーバイザーの一覧を参照してください。

ネットワーク (NSX-T)

vSphere 6.5U3 または vSphere 6.7U2 以降

OpenShift Container Platform には vSphere 6.5U3 または vSphere 6.7U2+ が必要です。VMware の NSX Container Plug-in (NCP) 3.0.2 は OpenShift Container Platform 4.4 および NSX-T 3.x+ で認定されています。

ストレージおよび In-tree ドライバー

vSphere 6.5 または vSphere 6.7

このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成し、vSphere CSI ドライバーが利用できない場合に使用できます。

ストレージおよび VSphere CSI ドライバー

vSphere 6.7U3 以降

このプラグインは、標準の Container Storage Interface を使用して vSphere ストレージを作成します。VSphere CSI ドライバーは、VMware によって提供され、サポートされます。

vSphere バージョン 6.5 インスタンスを使用している場合は、OpenShift Container Platform をインストールする前に 6.7U2 にアップグレードすることを検討してください。

重要

OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの「Edit Time Configuration for a Host」を参照してください。

重要
A limitation of using VPC is that the Storage Distributed Resource Scheduler (SDRS) is not supported. See link:https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/faqs.html[vSphere Storage for Kubernetes FAQs] in the VMware documentation.

1.2.4. 必要な vCenter アカウントの権限

OpenShift Container Platform クラスターを vCenter にインストールするには、クラスターに、必要なリソースの読み取りおよび作成権限を持つアカウントへのアクセスが必要になります。管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。

ユーザーが OpenShift Container Platform クラスターをインストールするには、以下の権限が必要です。

  • データストア

    • 領域の割り当て
  • フォルダー

    • フォルダーの作成
    • フォルダーの削除
  • vSphere タグ

    • すべての権限
  • ネットワーク

    • ネットワークの割り当て
  • リソース

    • 仮想マシンのリソースプールへの割り当て
  • プロファイル駆動型ストレージ

    • すべての権限
  • vApp

    • すべての権限
  • 仮想マシン

    • すべての権限

必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの「vSphere Permissions and User Management Tasks」を参照してください。

1.2.5. ユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合のクラスターのマシン要件

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

1.2.5.1. 必要なマシン

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

  • 1 つの一時的なブートストラップマシン
  • 3 つのコントロールプレーン、またはマスター、マシン
  • 少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。
注記

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

重要

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

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

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

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

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

1.2.5.3. 最小リソース要件

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

マシンオペレーティングシステムvCPU1仮想 RAMストレージ

ブートストラップ

RHCOS

4

16 GB

120 GB

コントロールプレーン

RHCOS

4

16 GB

120 GB

コンピュート

RHCOS または RHEL 7.6

2

8 GB

120 GB

1 1 物理コアは、ハイパースレッディングが有効な場合に 2 仮想 CPU を提供します。1 物理コアは、ハイパースレッディングが有効ではない場合に 1 vCPU を提供します。

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

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

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

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

前提条件

手順

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

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

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

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

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

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

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

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

プロトコルポート説明

ICMP

該当なし

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

TCP

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 ノードポート

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

プロトコルポート説明

TCP

2379-2380

etcd サーバー、ピア、およびメトリクスポート

6443

Kubernetes API

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

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

重要

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 ロードバランサーが適切に機能するには、セッション永続性は必要ありません。

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

    表1.10 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) を有効にする必要があります。
    • 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。

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

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

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

    443

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

    X

    X

    HTTPS トラフィック

    80

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

    X

    X

    HTTP トラフィック

ヒント

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

注記

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

Ethernet アダプターのハードウェアアドレス要件

クラスターの仮想マシンをプロビジョニングする場合、各仮想マシンに設定されたイーサネットインターフェースは VMware Organizationally Unique Identifier (OUI) 割り当て範囲から MAC アドレスを使用する必要があります。

  • 00:05:69:00:00:00 - 00:05:69:FF:FF:FF
  • 00:0c:29:00:00:00 - 00:0c:29:FF:FF:FF
  • 00:1c:14:00:00:00 - 00:1c:14:FF:FF:FF
  • 00:50:56:00:00:00 - 00:50:56:FF:FF:FF

VMware OUI 外の MAC アドレスが使用される場合、クラスターのインストールは成功しません。

1.2.6.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>. の形式を取ります。

表1.12 必要な 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 レコードの例を示しています。この例の目的は、必要なレコードを表示することです。この例では、特定の名前解決サービスを選択するためのアドバイスを提供することを目的としていません。

例1.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 レコードの例を示しています。

例1.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.ocp4.example.com.
5	IN	PTR	api-int.ocp4.ocp4.example.com.
;
11	IN	PTR	worker0.ocp4.example.com.
7	IN	PTR	worker1.ocp4.example.com.
;
;EOF

1.2.7. 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 キーが生成されます。

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

    $ eval "$(ssh-agent -s)"
    
    Agent pid 31874
  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 パブリックキーをインストールプログラムに指定します。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • Linux または macOS を使用するコンピューターからクラスターをインストールする必要があります。
  • インストールプログラムをダウンロードするには、500 MB のローカルディスク領域が必要です。

手順

  1. Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
  2. 選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。

    重要

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

    重要

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

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

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

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

ユーザーによってプロビジョニングされるインフラストラクチャーを使用する 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 ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

1.2.9.1. VMware vSphere のサンプル install-config.yaml ファイル

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

apiVersion: v1
baseDomain: example.com 1
compute:
- hyperthreading: Enabled 2 3
  name: worker
  replicas: 0 4
controlPlane:
  hyperthreading: Enabled 5 6
  name: master
  replicas: 3 7
metadata:
  name: test 8
platform:
  vsphere:
    vcenter: your.vcenter.server 9
    username: username 10
    password: password 11
    datacenter: datacenter 12
    defaultDatastore: datastore 13
fips: false 14
pullSecret: '{"auths": ...}' 15
sshKey: 'ssh-ed25519 AAAA...' 16
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 5
controlPlane セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。
3 6
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンで最低でも 8 CPU および 32 GB の RAM を使用する必要があります。

4
replicas パラメーターの値を 0 に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、ユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
7
クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
8
DNS レコードに指定したクラスター名。
9
vCenter サーバーの完全修飾ホスト名または IP アドレス。
10
サーバーにアクセスするユーザーの名前。このユーザーには、少なくとも vSphere の 静的または動的な永続ボリュームのプロビジョニング に必要なロールおよび権限がなければなりません。
11
vSphere ユーザーに関連付けられたパスワード。
12
vSphere データセンター。
13
使用するデフォルトの vSphere データストア。
14
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
15
Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
16
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーのデフォルト SSH キーの公開部分。
注記

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

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

クラスターのネットワーク設定パラメーターは install-config.yaml 設定ファイルで変更できます。以下の表では、これらのパラメーターについて説明しています。

注記

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

表1.13 必要なネットワークパラメーター

パラメーター説明

networking.networkType

デプロイするデフォルトの Container Network Interface (CNI)ネットワークプロバイダープラグイン。OpenShiftSDN プラグインのみが OpenShift Container Platform 4.4 でサポートされているプラグインです。

デフォルト値は OpenShiftSDN です。

networking.clusterNetwork[].cidr

Pod IP アドレスの割り当てに使用する IP アドレスのブロック。OpenShiftSDN ネットワークプラグインは複数のクラスターネットワークをサポートします。複数のクラスターネットワークのアドレスブロックには重複が許可されません。予想されるワークロードに適したサイズのアドレスプールを選択してください。

CIDR 形式の IP アドレスの割り当て。デフォルト値は 10.128.0.0/14 です。

networking.clusterNetwork[].hostPrefix

それぞれの個別ノードに割り当てるサブネットプレフィックスの長さ。たとえば、hostPrefix23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます (510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます)。

サブネットプレフィックス。デフォルト値は 23 です。

networking.serviceNetwork[]

サービスの IP アドレスのブロック。OpenShiftSDN は 1 つの serviceNetwork ブロックのみを許可します。このアドレスブロックは他のネットワークブロックと重複できません。

CIDR 形式の IP アドレスの割り当て。デフォルト値は 172.30.0.0/16 です。

networking.machineNetwork[].cidr

クラスターのインストール中に OpenShift Container Platform インストールプログラムによって使用されるノードに割り当てられる IP アドレスのブロック。このアドレスブロックは他のネットワークブロックと重複できません。複数の CIDR 範囲を指定できます。

CIDR 形式の IP アドレスの割り当て。デフォルト値は 10.0.0.0/16 です。

1.2.10. 高度なネットワーク設定パラメーターの変更

高度なネットワーク設定パラメーターは、クラスターのインストール前にのみ変更することができます。高度な設定のカスタマイズにより、クラスターを既存のネットワーク環境に統合させることができます。 これを実行するには、MTU または VXLAN ポートを指定し、kube-proxy 設定のカスタマイズを許可し、openshiftSDNConfig パラメーターに異なる mode を指定します。

重要

OpenShift Container Platform マニフェストファイルの直接の変更はサポートされていません。

前提条件

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

手順

  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 ファイルを開き、必要な Operator 設定を記述する CR を入力します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec: 1
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      serviceNetwork:
      - 172.30.0.0/16
      defaultNetwork:
        type: OpenShiftSDN
        openshiftSDNConfig:
          mode: NetworkPolicy
          mtu: 1450
          vxlanPort: 4789
    1
    spec パラメーターのパラメーターは例です。CR に Cluster Network Operator の設定を指定します。

    CNO は CR にパラメーターのデフォルト値を提供するため、変更が必要なパラメーターのみを指定する必要があります。

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

1.2.11. Cluster Network Operator (CNO) の設定

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

defaultNetwork パラメーターのパラメーター値を CNO CR に設定することにより、OpenShift Container Platform クラスターのクラスターネットワーク設定を指定できます。以下の CR は、CNO のデフォルト設定を表示し、設定可能なパラメーターと有効なパラメーターの値の両方について説明しています。

Cluster Network Operator CR

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork: 1
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork: 2
  - 172.30.0.0/16
  defaultNetwork: 3
    ...
  kubeProxyConfig: 4
    iptablesSyncPeriod: 30s 5
    proxyArguments:
      iptables-min-sync-period: 6
      - 0s

1 2
install-config.yaml ファイルに指定されます。
3
クラスターネットワークのデフォルトの Container Network Interface (CNI) ネットワークプロバイダーを設定します。
4
このオブジェクトのパラメーターは、kube-proxy 設定を指定します。パラメーターの値を指定しない場合、クラスターネットワーク Operator は表示されるデフォルトのパラメーター値を適用します。OVN-Kubernetes デフォルト CNI ネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。
5
iptables ルールの更新期間。デフォルト値は 30s です。有効なサフィックスには、sm、および h などが含まれ、これらについては、Go Package time ドキュメントで説明されています。
注記

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

6
iptables ルールを更新する前の最小期間。このパラメーターにより、更新の頻度が高くなり過ぎないようにできます。有効なサフィックスには、sm、および h などが含まれ、これらについては、Go Package time で説明されています。

1.2.11.1. OpenShift SDN デフォルト CNI ネットワークプロバイダーの設定パラメーター

以下の YAML オブジェクトは、OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーの設定パラメーターについて説明しています。

defaultNetwork:
  type: OpenShiftSDN 1
  openshiftSDNConfig: 2
    mode: NetworkPolicy 3
    mtu: 1450 4
    vxlanPort: 4789 5
1
install-config.yaml ファイルに指定されます。
2
OpenShift SDN 設定の一部を上書きする必要がある場合にのみ指定します。
3
OpenShift SDN のネットワーク分離モードを設定します。許可される値は MultitenantSubnet、または NetworkPolicy です。デフォルト値は NetworkPolicy です。
4
VXLAN オーバーレイネットワークの maximum transmission unit (MTU)。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも 50 小さくする必要があります。
5
すべての VXLAN パケットに使用するポート。デフォルト値は 4789 です。別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。

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

1.2.11.2. Cluster Network Operator の設定例

以下の例のように、CNO の完全な CR オブジェクトが表示されます。

Cluster Network Operator のサンプル CR

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: OpenShiftSDN
    openshiftSDNConfig:
      mode: NetworkPolicy
      mtu: 1450
      vxlanPort: 4789
  kubeProxyConfig:
    iptablesSyncPeriod: 30s
    proxyArguments:
      iptables-min-sync-period:
      - 0s

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

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

重要

インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターが再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR)を手動で承認する必要があります。詳細は、コントロールプレーン証明書からの回復 についてのドキュメントを参照してください。

前提条件

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

手順

  1. 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

1.2.13. vSphere での Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

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

前提条件

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

手順

  1. <installation_directory>/bootstrap.ign という名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。

    ブートストラップ Ignition 設定ファイルはサイズが大きすぎて vApp プロパティーに適さないため、これをホストする必要があります。

  2. ブートストラップノードの以下の二次的な Ignition 設定ファイルを、<installation_directory>/append-bootstrap.ign としてコンピューターに保存します。

    {
      "ignition": {
        "config": {
          "append": [
            {
              "source": "<bootstrap_ignition_config_url>", 1
              "verification": {}
            }
          ]
        },
        "timeouts": {},
        "version": "2.2.0"
      },
      "networkd": {},
      "passwd": {},
      "storage": {},
      "systemd": {}
    }
    1
    ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

    ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。

  3. マスター、ワーカー、および二次的なブートストラップ Ignition 設定ファイルを base64 エンコーディングに変換します。

    たとえば、Linux オペレーティングシステムを使用する場合、 base64 コマンドを使用してファイルをエンコードできます。

    $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64
    $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64
    $ base64 -w0 <installation_directory>/append-bootstrap.ign > <installation_directory>/append-bootstrap.64
    重要

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

  4. Red Hat カスタマーポータルの「製品のダウンロード」ページまたは「 RHCOS イメージミラー」ページから RHCOS OVA イメージを取得します。

    重要

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

    ファイル名には、rhcos-<version>-vmware.<architecture>.ova 形式の OpenShift Container Platform のバージョン番号が含まれます。

  5. vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。

    1. VMs and Templates ビューをクリックします。
    2. データセンターの名前を右クリックします。
    3. New FolderNew VM and Template Folder をクリックします。
    4. 表示されるウィンドウで、フォルダー名を入力します。フォルダー名は、install-config.yaml ファイルで指定したクラスター名と一致している必要があります。
  6. vSphere クライアントで、OVA イメージのテンプレートを作成します。

    注記

    以下の手順では、すべてのクラスターマシンに同じテンプレートを使用し、仮想マシンのプロビジョニングの際に該当するマシンタイプの Ignition 設定ファイルの場所を指定します。

    1. Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template をクリックします。
    2. Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
    3. Select a name and folder タブで、RHCOS などの Virtual machine name を設定し、vSphere クラスターの名前をクリックし、直前のステップで作成したフォルダーを選択します。
    4. Select a compute resource タブで、vSphere クラスターの名前をクリックします。
    5. Select storage タブで、仮想マシンのストレージオプションを設定します。

      • ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
      • install-config.yaml ファイルで指定したデータストアを選択します。
    6. Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。
    7. すべてのクラスターマシンタイプに同じテンプレートを使用する予定の場合、Customize template タブに値を指定しないでください。

      重要

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

  7. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

    1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
    2. Select a name and folder タブで、仮想マシンの名前を指定します。control-plane-0 または compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。
    3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
    4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
    5. オプション: Select storage タブで、ストレージオプションをカスタマイズします。
    6. Select clone options で、Customize this virtual machine’s hardware を選択します。
    7. Customize hardware タブで、VM OptionsAdvanced をクリックします。

      • オプション: クラスターのパフォーマンスに問題が生じる場合は、Latency Sensitivity 一覧から High を選択します。
      • Edit Configuration をクリックし、Configuration Parameters ウィンドウで Add Configuration Params をクリックします。以下のパラメーター名および値を定義します。

        • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードした Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
      • または、仮想マシンの電源を入れる前に vApp プロパティーを使用して追加します。

        • vCenter Server インベントリーから仮想マシンに移動します。
        • Configure タブで Settings を展開し、vAPP options を選択します。
        • スクロールダウンし、Properties の下で上記の設定を適用します。
    8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
    9. 設定を完了し、仮想マシンの電源をオンにします。
  8. 各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。

    重要

    この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。

1.2.14. vSphere での追加の Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

VMware vSphere でユーザーによってプロビジョニングされるインフラストラクチャーを使用するクラスターのコンピュートマシンを追加で作成できます。

前提条件

  • コンピュートマシンの base64 でエンコードされた Ignition ファイルを取得します。
  • クラスター用に作成した vSphere テンプレートにアクセスできる必要があります。

手順

  1. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

    1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
    2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。
    3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
    4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
    5. オプション: Select storage タブで、ストレージオプションをカスタマイズします。
    6. Select clone options で、Customize this virtual machine’s hardware を選択します。
    7. Customize hardware タブで、VM OptionsAdvanced をクリックします。

      • Latency Sensitivity 一覧から、High を選択します。
      • Edit Configuration をクリックし、Configuration Parameters ウィンドウで Add Configuration Params をクリックします。以下のパラメーター名および値を定義します。

        • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
    8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。また、ネットワークが複数利用可能な場合は、必ず Add network adapter に正しいネットワークを選択してください。
    9. 設定を完了し、仮想マシンの電源をオンにします。
  2. 継続してクラスター用の追加のコンピュートマシンを作成します。

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

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

重要

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

1.2.15.1. Linux への CLI のインストール

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

手順

  1. Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページに移動します。
  2. インフラストラクチャープロバイダーを選択し、(該当する場合は) インストールタイプを選択します。
  3. Command-line interface セクションで、ドロップダウンメニューの Linux を選択し、Download command-line tools をクリックします。
  4. アーカイブを展開します。

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

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

    $ echo $PATH

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

$ oc <command>

1.2.15.2. Windows での CLI のインストール

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

手順

  1. Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページに移動します。
  2. インフラストラクチャープロバイダーを選択し、(該当する場合は) インストールタイプを選択します。
  3. Command-line interface セクションで、ドロップダウンメニューの Windows を選択し、Download command-line tools をクリックします。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

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

C:\> oc <command>

1.2.15.3. macOS への CLI のインストール

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

手順

  1. Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページに移動します。
  2. インフラストラクチャープロバイダーを選択し、(該当する場合は) インストールタイプを選択します。
  3. Command-line interface セクションで、ドロップダウンメニューの MacOS を選択し、Download command-line tools をクリックします。
  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

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

    $ echo $PATH

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

$ oc <command>

1.2.16. クラスターの作成

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

前提条件

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

手順

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

    $ ./openshift-install --dir=<installation_directory> wait-for bootstrap-complete \ 1
        --log-level=info 2
    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com...
    INFO API v1.17.1 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、 info ではなく、warndebug、または error を指定します。

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

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

    重要

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

1.2.17. クラスターへのログイン

クラスター 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

1.2.18. マシンの証明書署名要求の承認

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

前提条件

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

手順

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

    # oc get nodes
    
    NAME                    STATUS   ROLES    AGE   VERSION
    master-01.example.com   Ready    master   40d   v1.17.1
    master-02.example.com   Ready    master   40d   v1.17.1
    master-03.example.com   Ready    master   40d   v1.17.1
    worker-01.example.com   Ready    worker   40d   v1.17.1
    worker-02.example.com   Ready    worker   40d   v1.17.1

    出力には作成したすべてのマシンが一覧表示されます。

  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 の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。kubelet 提供証明書の要求を自動的に承認する方法を実装する必要があります。

    • それらを個別に承認するには、それぞれの有効な 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
  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 ステータスに移行するまでに数分の時間がかかる場合があります。

追加情報

1.2.19. Operator の初期設定

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

前提条件

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

手順

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

    $ watch -n5 oc get clusteroperators
    
    NAME                                 VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                       4.4.0     True        False         False      69s
    cloud-credential                     4.4.0     True        False         False      12m
    cluster-autoscaler                   4.4.0     True        False         False      11m
    console                              4.4.0     True        False         False      46s
    dns                                  4.4.0     True        False         False      11m
    image-registry                       4.4.0     True        False         False      5m26s
    ingress                              4.4.0     True        False         False      5m36s
    kube-apiserver                       4.4.0     True        False         False      8m53s
    kube-controller-manager              4.4.0     True        False         False      7m24s
    kube-scheduler                       4.4.0     True        False         False      12m
    machine-api                          4.4.0     True        False         False      12m
    machine-config                       4.4.0     True        False         False      7m36s
    marketplace                          4.4.0     True        False         False      7m54m
    monitoring                           4.4.0     True        False         False      7h54s
    network                              4.4.0     True        False         False      5m9s
    node-tuning                          4.4.0     True        False         False      11m
    openshift-apiserver                  4.4.0     True        False         False      11m
    openshift-controller-manager         4.4.0     True        False         False      5m943s
    openshift-samples                    4.4.0     True        False         False      3m55s
    operator-lifecycle-manager           4.4.0     True        False         False      11m
    operator-lifecycle-manager-catalog   4.4.0     True        False         False      11m
    service-ca                           4.4.0     True        False         False      11m
    service-catalog-apiserver            4.4.0     True        False         False      5m26s
    service-catalog-controller-manager   4.4.0     True        False         False      5m25s
    storage                              4.4.0     True        False         False      5m30s
  2. 利用不可の Operator を設定します。

1.2.19.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 状態に更新してください。

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

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

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

正しい PVC を参照するようにレジストリーストレージを設定する方法については、「vSphere のレジストリーの設定」を参照してください。

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

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

前提条件

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

手順

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

    $ watch -n5 oc get clusteroperators
    
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.4.3     True        False         False      7m56s
    cloud-credential                           4.4.3     True        False         False      31m
    cluster-autoscaler                         4.4.3     True        False         False      16m
    console                                    4.4.3     True        False         False      10m
    csi-snapshot-controller                    4.4.3     True        False         False      16m
    dns                                        4.4.3     True        False         False      22m
    etcd                                       4.4.3     False       False         False      25s
    image-registry                             4.4.3     True        False         False      16m
    ingress                                    4.4.3     True        False         False      16m
    insights                                   4.4.3     True        False         False      17m
    kube-apiserver                             4.4.3     True        False         False      19m
    kube-controller-manager                    4.4.3     True        False         False      20m
    kube-scheduler                             4.4.3     True        False         False      20m
    kube-storage-version-migrator              4.4.3     True        False         False      16m
    machine-api                                4.4.3     True        False         False      22m
    machine-config                             4.4.3     True        False         False      22m
    marketplace                                4.4.3     True        False         False      16m
    monitoring                                 4.4.3     True        False         False      10m
    network                                    4.4.3     True        False         False      23m
    node-tuning                                4.4.3     True        False         False      23m
    openshift-apiserver                        4.4.3     True        False         False      17m
    openshift-controller-manager               4.4.3     True        False         False      15m
    openshift-samples                          4.4.3     True        False         False      16m
    operator-lifecycle-manager                 4.4.3     True        False         False      22m
    operator-lifecycle-manager-catalog         4.4.3     True        False         False      22m
    operator-lifecycle-manager-packageserver   4.4.3     True        False         False      18m
    service-ca                                 4.4.3     True        False         False      23m
    service-catalog-apiserver                  4.4.3     True        False         False      23m
    service-catalog-controller-manager         4.4.3     True        False         False      23m
    storage                                    4.4.3     True        False         False      17m

    すべてのクラスター Operator が AVAILABLE の場合、インストールを完了することができます。

  2. クラスターの完了をモニターします。

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

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

    重要

    インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターが再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR)を手動で承認する必要があります。詳細は、コントロールプレーン証明書からの回復 についてのドキュメントを参照してください。

  3. 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 サーバーはクラスターマシンと通信できます。

Adding compute machines to vSphere」に従い、クラスターのインストールの完了後に追加のコンピュートマシンを追加できます。

1.2.21. VMware vSphere ボリュームのバックアップ

OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限について参照してください。

手順

永続ボリュームのバックアップを作成すには、以下を実行します。

  1. 永続ボリュームを使用しているアプリケーションを停止します。
  2. 永続ボリュームのクローンを作成します。
  3. アプリケーションを再起動します。
  4. クローンを作成したボリュームのバックアップを作成します。
  5. クローンを作成したボリュームを削除します。

1.2.22. 次のステップ