検索

第1章 ベアメタルへのインストール

download PDF

1.1. クラスターのベアメタルへのインストール

OpenShift Container Platform バージョン 4.2 では、クラスターをプロビジョニングするベアメタルインフラストラクチャーにインストールできます。

重要

以下の手順に従って仮想化環境またはクラウド環境にクラスターをデプロイすることができますが、ベアメタルプラットフォーム以外の場合は追加の考慮事項に注意してください。このような環境で OpenShift Container Platform クラスターのインストールを試行する前に、「guidelines for deploying OpenShift Container Platform on non-tested platforms」にある情報を確認してください。

前提条件

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

OpenShift Container Platform 4.2 では、クラスターをインストールするためにインターネットアクセスが必要になります。クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される 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.1.2. ユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合のクラスターのマシン要件

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

1.1.2.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.1.2.2. ネットワーク接続の要件

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

1.1.2.3. 最小リソース要件

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

マシンOperating SystemvCPU仮想 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.4. 証明書署名要求の管理

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

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

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

前提条件

手順

  1. DHCP を設定します。
  2. 必要なロードバランサーをプロビジョニングします。
  3. マシンのポートを設定します。
  4. DNS を設定します。
  5. ネットワーク接続を確認します。

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

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

初回の起動時に、Ignition 設定ファイルをダウンロードできるようネットワーク接続を確立するために、マシンには DHCP サーバーが必要になります。

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

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

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

表1.1 すべてのマシンに対応するすべてのマシン
プロトコルポート説明

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 NodePort

表1.2 コントロールプレーンへのすべてのマシン
プロトコルポート説明

TCP

2379-2380

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

6443

Kubernetes API

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

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

重要

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

ロードバランサー

OpenShift Container Platform をインストールする前に、2 つの Layer 4 ロードバランサーをプロビジョニングする必要があります。API には 1 つのロードバランサーが必要で、デフォルトの Ingress コントローラーには、Ingress をアプリケーションに提供する 2 番目のロードバランサーが必要です。

ポートマシン内部外部説明

6443

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

x

x

Kubernetes API サーバー

22623

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

x

 

マシン設定サーバー

443

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

x

x

HTTPS トラフィック

80

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

x

x

HTTP トラフィック

注記

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

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

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

表1.3 必要な DNS レコード
Componentレコード説明

Kubernetes API

api.<cluster_name>.<base_domain>.

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

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

この DNS A/AAAA または CNAME レコードは、コントロールプレーンマシンのロードバランサーを参照する必要があります。このレコードは、クラスター内のすべてのノードで解決できる必要があります。

重要

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

Routes

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

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

etcd

etcd-<index>.<cluster_name>.<base_domain>.

OpenShift Container Platform では、各 etcd インスタンスの DNS A/AAAA レコードがインスタンスをホストするコントロールプレーンマシンを参照する必要があります。etcd インスタンスは <index> 値によって差別化されます。この値は 0 で始まり、n-1 で終了します。 ここで、n はクラスターのコントロールプレーンマシンの数です。DNS レコードはコントロールプレーンマシンのユニキャスト IPv4 アドレスに解決し、レコードはクラスター内のすべてのノードで解決可能である必要があります。

_etcd-server-ssl._tcp.<cluster_name>.<base_domain>.

それぞれのコントロールプレーンマシンについて、OpenShift Container Platform では、そのマシンに優先度 0、重み 10 およびポート 2380 の etcd サーバーの SRV DNS レコードも必要になります。3 つのコントロールプレーンマシンを使用するクラスターには以下のレコードが必要です。

# _service._proto.name.                            TTL    class SRV priority weight port target.
_etcd-server-ssl._tcp.<cluster_name>.<base_domain>.  86400 IN    SRV 0        10     2380 etcd-0.<cluster_name>.<base_domain>
_etcd-server-ssl._tcp.<cluster_name>.<base_domain>.  86400 IN    SRV 0        10     2380 etcd-1.<cluster_name>.<base_domain>
_etcd-server-ssl._tcp.<cluster_name>.<base_domain>.  86400 IN    SRV 0        10     2380 etcd-2.<cluster_name>.<base_domain>

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

クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent とインストールプログラムの両方に SSH キーを指定する必要があります。

注記

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

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

注記

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

手順

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

    $ ssh-keygen -t rsa -b 4096 -N '' \
        -f <path>/<file_name> 1
    1
    ~/.ssh/id_rsa などの、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.1.5. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールファイルを

ローカルコンピューターにダウンロードします。

前提条件

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

手順

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

    重要

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

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

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

1.1.6. CLI のインストール

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

重要

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

手順

  1. Red Hat OpenShift Cluster Manager サイトの Infrastructure Provider ページから、選択するインストールタイプのページに移動し、Download Command-line Tools をクリックします。
  2. オペレーティングシステムおよびアーキテクチャーのフォルダーをクリックしてから、圧縮されたファイルをクリックします。

    注記

    oc は Linux、Windows、または macOS にインストールできます。

  3. ファイルをファイルシステムに保存します。
  4. 圧縮ファイルを展開します。
  5. これを PATH にあるディレクトリーに配置します。

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

$ oc <command>

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

ユーザーによってプロビジョニングされるインフラストラクチャーを使用する 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.1.7.1. ベアメタルのサンプル 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 7
  replicas: 3 8
metadata:
  name: test 9
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 10
    hostPrefix: 23 11
  networkType: OpenShiftSDN
  serviceNetwork: 12
  - 172.30.0.0/16
platform:
  none: {} 13
pullSecret: '{"auths": ...}' 14
sshKey: 'ssh-ed25519 AAAA...' 15
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 5
controlPlane セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。
3 6 7
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

4
replicas パラメーターの値を 0 に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、ユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
8
クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
9
DNS レコードに指定したクラスター名。
10
Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用され、外部ネットワークから Pod にアクセスする必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
11
それぞれの個別ノードに割り当てるサブネットプレフィックスの長さ。たとえば、hostPrefix23 に設定され、各ノードに指定の cidr から /23 サブネットが割り当てられます (510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます)。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
12
サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
13
プラットフォームを noneに設定する必要があります。ベアメタルインフラストラクチャー用に追加のプラットフォーム設定変数を指定することはできません。
14
Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する、Quay.io などの組み込まれた各種の認証局によって提供されるサービスで認証できます。
15
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーのデフォルト SSH キーの公開部分。
注記

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

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

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

注記

ベアメタルインストールでは、install-config.yaml ファイルの networking.machineCIDR フィールドで指定される範囲にある IP アドレスをノードに割り当てない場合、それらを proxy.noProxy フィールドに含める必要があります。

前提条件

  • 既存の install-config.yaml ファイル。
  • クラスターがアクセスする必要のあるサイトを確認し、プロキシーをバイパスする必要があるかどうかを判別する。デフォルトで、すべてのクラスター egress トラフィック (クラスターをホストするクラウドについてのクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーオブジェクトの spec.noProxy フィールドにサイトを追加し、必要に応じてプロキシーをバイパスします。

    注記

    プロキシーオブジェクトの status.noProxy フィールドは、デフォルトでインスタンスメタデータエンドポイント (169.254.169.254) およびインストール設定の networking.machineCIDRnetworking.clusterNetwork.cidr、および networking.serviceNetwork フィールドの値で設定されます。

手順

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

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

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

  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

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

注記

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

1.1.8. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを作成するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

重要

インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。最初の証明書のローテーションが正常に実行されるようにするには、クラスターのインストールを完了し、クラスターを動作が低下していない状態で 24 時間実行し続ける必要があります。

前提条件

  • OpenShift Container Platform インストールプログラムを取得します。
  • install-config.yaml インストール設定ファイルを作成します。

手順

  1. クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir=<installation_directory> 1
    
    WARNING There are no compute nodes specified. The cluster will not fully initialize without compute nodes.
    INFO Consuming "Install Config" from target directory
    1
    <installation_directory> については、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。

    インストールプロセスの後の部分で独自のコンピュートマシンを作成するため、この警告を無視しても問題がありません。

  2. manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルを変更し、Pod がコントロールプレーンマシンにスケジュールされないようにします。

    1. manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、その値を False に設定します。
    3. ファイルを保存し、終了します。
    注記

    現時点では、Kubernetes の制限により、コントロールプレーンマシンで実行されるルーター Pod に Ingress ロードバランサーがアクセスすることができません。この手順は、OpenShift Container Platform の今後のマイナーバージョンで不要になる可能性があります。

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

    $ ./openshift-install create ignition-configs --dir=<installation_directory> 1
    1
    <installation_directory> については、同じインストールディレクトリーを指定します。

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

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

1.1.9. Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

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

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

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

前提条件

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

手順

  1. インストールプログラムが作成したコントロールプレーン、コンピュート、およびブートストラップ Ignition 設定を HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
  2. Red Hat カスタマーポータルの「製品のダウンロード」ページまたは「RRHCOS イメージミラー」ページからオペレーティングシステムのインスタンスをインストールするために優先される方法で必要な RHCOS イメージを取得します。

    重要

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

    ISO ファイルおよび RAW ディスクファイルをダウンロードする必要があります。これらのファイルの名前は以下の例のようになります。

    • ISO: rhcos-<version>-<architecture>-installer.iso
    • 圧縮された metal BIOS: rhcos-<version>-<architecture>-metal-bios.raw.gz
    • 圧縮された metal UEFI: rhcos-<version>-<architecture>-metal-uefi.raw.gz
  3. BIOS または UEFI RHCOS イメージファイルのいずれかを HTTP サーバーにアップロードし、その URL をメモします。
  4. ISO を使用し、RHCOS インストールを開始します。以下のインストールオプションのいずれかを使用します。

    • ディスクに ISO イメージを書き込み、これを直接起動します。
    • LOM インターフェースで ISO リダイレクトを使用します。
  5. インスタンスの起動後に、TAB または E キーを押してカーネルコマンドラインを編集します。
  6. パラメーターをカーネルコマンドラインに追加します。

    coreos.inst=yes
    coreos.inst.install_dev=sda 1
    coreos.inst.image_url=<image_URL> 2
    coreos.inst.ignition_url=http://example.com/config.ign 3
    1
    インストール先のシステムのブロックデバイスを指定します。
    2
    サーバーにアップロードした UEFI または BIOS イメージの URL を指定します。
    3
    このマシンタイプの Ignition 設定ファイルの URL を指定します。
  7. Enter を押してインストールを完了します。RHCOS のインストール後に、システムは再起動します。システムの再起動後、指定した Ignition 設定ファイルを適用します。
  8. 継続してクラスターのマシンを作成します。

    重要

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

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

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

前提条件

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

手順

  1. インストールプログラムが作成したマスター、ワーカーおよびブートストラップの Ignition 設定を HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
  2. Red Hat カスタマーポータルの「製品のダウンロード」ページまたは「RHCOS イメージミラー」ページから RHCOS ISO イメージ、圧縮されたメタル BIOS、kernel および initramfs ファイルを取得します。

    重要

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

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

    • ISO: rhcos-<version>-<architecture>-installer.iso
    • 圧縮された metal BIOS: rhcos-<version>-<architecture>-metal-bios.raw.gz
    • kernel: rhcos-<version>-<architecture>-installer-kernel
    • initramfs: rhcos-<version>-<architecture>-installer-initramfs.img
  3. 圧縮された metal BIOS ファイルおよび kernel および initramfs ファイルを HTTP サーバーにアップロードします。
  4. RHCOS のインストール後にマシンがローカルディスクから起動されるようにネットワークブートインフラストラクチャーを設定します。
  5. RHCOS イメージに PXE または iPXE インストールを設定します。

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

    • PXE の場合:

      DEFAULT pxeboot
      TIMEOUT 20
      PROMPT 0
      LABEL pxeboot
          KERNEL http://<HTTP_server>/rhcos-<version>-<architecture>-installer-kernel 1
          APPEND ip=dhcp rd.neednet=1 initrd=rhcos-<version>-<architecture>-installer-initramfs.img console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://<HTTP_server>/rhcos-<version>-<architecture>-metal-bios.raw.gz coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 2 3
      1
      HTTP サーバーにアップロードした kernel ファイルの場所を指定します。
      2
      複数の NIC を使用する場合、ip オプションに単一インターフェースを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
      3
      HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。initrd パラメーター値は initramfs ファイルの場所であり、coreos.inst.image_url パラメーター値は圧縮された metal BIOS ファイルの場所、および coreos.inst.ignition_url パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。
    • iPXEの場合:

      kernel  http://<HTTP_server>/rhcos-<version>-<architecture>-installer-kernel ip=dhcp rd.neednet=1 initrd=http://<HTTP_server>/rhcos-<version>-<architecture>-installer-initramfs.img console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://<HTTP_server>/rhcos-<version>-<architecture>-metal-bios.raw.gz coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 1 2
      initrd http://<HTTP_server>/rhcos-<version>-<architecture>-installer-initramfs.img 3
      boot
      1
      HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。kernel パラメーター値は kernel ファイルの場所であり、initrd パラメーター値は initramfs ファイルの場所、coreos.inst.image_url パラメーター値は圧縮された metal BIOS ファイルの場所、および coreos.inst.ignition_url パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。
      2
      複数の NIC を使用する場合、ip オプションに単一インターフェースを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
      3
      HTTP サーバーにアップロードした initramfs ファイルの場所を指定します。
  6. UEFI を使用する場合、ダウンロードした ISO に含まれている grub.conf ファイルを編集して以下のインストールオプションを組み込みます。

    menuentry 'Install Red Hat Enterprise Linux CoreOS' --class fedora --class gnu-linux --class gnu --class os {
    	linux /images/vmlinuz nomodeset rd.neednet=1 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://<HTTP_server>/rhcos-<version>-<architecture>-metal-uefi.raw.gz coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 1
    	initrd http://<HTTP_server>/rhcos-<version>-<architecture>-installer-initramfs.img 2
    }
    1
    coreos.inst.image_url パラメーター値には、HTTP サーバーにアップロードした圧縮された metal UEFI ファイルの場所を指定します。coreos.inst.ignition_url には、HTTP サーバーにアップロードしたブートストラップ Ingition 設定ファイルの場所を指定します。
    2
    HTTP サーバーにアップロードした initramfs ファイルの場所を指定します。
  7. 継続してクラスターのマシンを作成します。

    重要

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

1.1.10. クラスターの作成

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

前提条件

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

手順

  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:6443...
    INFO API v1.14.6+c4799753c up
    INFO Waiting up to 30m0s for the bootstrap-complete event...
    1
    <installation_directory> については、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、 info ではなく、warndebug、または error を指定します。

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

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

    重要

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

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

クラスター 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.1.12. マシンの CSR の承認

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

前提条件

  • マシンをクラスターに追加していること。

手順

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

    $ oc get nodes
    
    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.14.6+c4799753c
    master-1  Ready     master  63m  v1.14.6+c4799753c
    master-2  Ready     master  64m  v1.14.6+c4799753c
    worker-0  NotReady  worker  76s  v1.14.6+c4799753c
    worker-1  NotReady  worker  70s  v1.14.6+c4799753c

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

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr
    
    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...
    1
    クライアント要求の CSR。
    2
    サーバー要求の CSR。

    この例では、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

1.1.13. Operator の初期設定

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

前提条件

  • コントロールプレーンが初期化されていること。

手順

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

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

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

image-registry Operator が利用できない場合、そのストレージを設定する必要があります。実稼働クラスターに必要な PersistentVolume の設定方法と、実稼働用ではないクラスターにのみ使用できる空のディレクトリーをストレージの場所として設定する方法が表示されます。

1.1.13.1.1. ベアメタルの場合のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • ベアメタル上のクラスター。
  • Red Hat OpenShift Container Storage などのクラスターの永続ストレージをプロビジョニングします。プライベートイメージレジストリーをデプロイするには、ストレージで ReadWriteMany アクセスモードを指定する必要があります。
  • 容量は「100Gi」以上である。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。
  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry
    注記

    ストレージタイプが emptyDIR の場合、レプリカ数が 1 を超えることはありません。ストレージタイプが NFS で、レジストリー Pod を replica>1 を設定してスケールアップする必要がある場合、no_wdelay マウントオプションを有効にする必要があります。以下は例になります。

    # cat /etc/exports
    /mnt/data *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=0)
    sh-4.3# exportfs -rv
    exporting *:/mnt/data
  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io
    
    storage:
      pvc:
        claim:

    claim フィールドを空のままにし、 image-registry-storage PVC の自動作成を可能にします。

  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry
1.1.13.1.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

イメージレジストリー Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    イメージレジストリー Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

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

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

前提条件

  • コントロールプレーンが初期化されていること。
  • Operator の初期設定を完了していること。

手順

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

    $ watch -n5 oc get clusteroperators
    
    NAME                                 VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                       4.2.0     True        False         False      10m
    cloud-credential                     4.2.0     True        False         False      22m
    cluster-autoscaler                   4.2.0     True        False         False      21m
    console                              4.2.0     True        False         False      10m
    dns                                  4.2.0     True        False         False      21m
    image-registry                       4.2.0     True        False         False      16m
    ingress                              4.2.0     True        False         False      16m
    kube-apiserver                       4.2.0     True        False         False      19m
    kube-controller-manager              4.2.0     True        False         False      18m
    kube-scheduler                       4.2.0     True        False         False      22m
    machine-api                          4.2.0     True        False         False      22m
    machine-config                       4.2.0     True        False         False      18m
    marketplace                          4.2.0     True        False         False      18m
    monitoring                           4.2.0     True        False         False      18m
    network                              4.2.0     True        False         False      16m
    node-tuning                          4.2.0     True        False         False      21m
    openshift-apiserver                  4.2.0     True        False         False      21m
    openshift-controller-manager         4.2.0     True        False         False      17m
    openshift-samples                    4.2.0     True        False         False      14m
    operator-lifecycle-manager           4.2.0     True        False         False      21m
    operator-lifecycle-manager-catalog   4.2.0     True        False         False      21m
    service-ca                           4.2.0     True        False         False      21m
    service-catalog-apiserver            4.2.0     True        False         False      16m
    service-catalog-controller-manager   4.2.0     True        False         False      16m
    storage                              4.2.0     True        False         False      16m

    すべてのクラスター 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 時間実行し続ける必要があります。

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

次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.