第1章 ベアメタルへのインストール
1.1. クラスターのベアメタルへのインストール
OpenShift Container Platform version 4.6 では、クラスターをプロビジョニングするベアメタルのインフラストラクチャーにインストールできます。
以下の手順に従って仮想化環境またはクラウド環境にクラスターをデプロイすることができますが、ベアメタルプラットフォーム以外の場合は追加の考慮事項に注意してください。このような環境で OpenShift Container Platform クラスターのインストールを試行する前に、Deploying OpenShift 4.x on non-tested platforms using the bare metal install method にある情報を確認してください。
1.1.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
ファイアウォールを使用する場合、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要があります。
注記プロキシーを設定する場合は、このサイト一覧も確認してください。
1.1.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.1.3. ユーザーによってプロビジョニングされるインフラストラクチャーでのクラスターのマシン要件
ユーザーによってプロビジョニングされるインフラストラクチャーを含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
1.1.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 テクノロジーの機能と制限 を参照してください。
1.1.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 サーバーとクロックを同期できます。
1.1.3.3. 最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | 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 |
- CPU 1 つ分は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = CPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
1.1.3.4. 証明書署名要求の管理
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
1.1.4. ユーザーによってプロビジョニングされるインフラストラクチャーの作成
ユーザーによってプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターをデプロイする前に、基礎となるインフラストラクチャーを作成する必要があります。
前提条件
- クラスターでサポートするインフラストラクチャーを作成する前に、OpenShift Container Platform 4.x のテスト済みインテグレーション ページを参照してください。
手順
- 各ノードに DHCP を設定するか、または静的 IP アドレスを設定します。
- 必要なロードバランサーをプロビジョニングします。
- マシンのポートを設定します。
- DNS を設定します。
- ネットワーク接続を確認します。
1.1.4.1. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs のネットワークがマシン設定サーバーから Ignition 設定をフェッチする必要があります。
初回の起動時に、Ignition 設定ファイルをダウンロードできるようネットワーク接続を確立するために、マシンには DHCP サーバーまたはその静的 IP アドレスが設定されている必要があります。
クラスターのマシンを長期間管理するために DHCP サーバーを使用することが推奨されています。DHCP サーバーが永続 IP アドレスおよびホスト名をクラスターマシンに提供するように設定されていることを確認します。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照することができます。
マシン間のネットワーク接続を、クラスターのコンポーネントが通信できるように設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
| プロトコル | ポート | 説明 |
|---|---|---|
| ICMP | 該当なし | ネットワーク到達性のテスト |
| TCP |
| メトリクス |
|
|
ホストレベルのサービス。 ポート | |
|
| Kubernetes が予約するデフォルトポート | |
|
| openshift-sdn | |
| UDP |
| VXLAN および Geneve |
|
| VXLAN および Geneve | |
|
|
ポート | |
| TCP/UDP |
| Kubernetes ノードポート |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| Kubernetes API |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| etcd サーバーおよびピアポート |
ネットワークトポロジー要件
クラスター用にプロビジョニングするインフラストラクチャーは、ネットワークトポロジーの以下の要件を満たす必要があります。
OpenShift Container Platform では、すべてのノードが、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するためにインターネットへの直接のアクセスが必要です。
ロードバランサー
OpenShift Container Platform をインストールする前に、以下の要件を満たす 2 つのロードバランサーをプロビジョニングする必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、API ルートの Server Name Indication (SNI) を有効にする必要があります。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表1.4 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyzエンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyzエンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyzの後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、Ingress ルートの Server Name Indication (SNI) を有効にする必要があります。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表1.5 アプリケーション 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 サーバーとクロックを同期できます。
関連情報
1.1.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>. の形式を取ります。
| コンポーネント | レコード | 説明 |
|---|---|---|
| Kubernetes API |
| DNS A/AAAA または CNAME レコード、および DNS PTR レコードを、コントロールプレーンマシンのロードバランサーを特定するために追加します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
|
| DNS A/AAAA または CNAME レコード、および DNS PTR レコードを、コントロールプレーンマシンのロードバランサーを特定するために追加します。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、 Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
| ルート |
| デフォルトでワーカーノードの Ingress ルーター Pod を実行するマシンをターゲットにするロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコードを追加します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| ブートストラップ |
| DNS A/AAAA または CNAME レコードおよび DNS PTR レコードを、ブートストラップマシンを特定するために追加します。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
| マスターホスト |
| コントロールプレーンノード (別名マスターノード) の各マシンを識別するための DNS A/AAAA または CNAME レコードと DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
| ワーカーホスト |
| DNS A/AAAA または CNAME レコードおよび DNS PTR レコードを、ワーカーノードの各マシンを特定するために追加します。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
nslookup <hostname> コマンドを使用して、名前解決を確認することができます。dig -x <ip_address> コマンドを使用して、PTR レコードの逆引き名前解決を確認できます。
BIND ゾーンファイルの以下の例は、名前解決の A レコードの例を示しています。この例の目的は、必要なレコードを表示することです。この例では、特定の名前解決サービスを選択するためのアドバイスを提供することを目的としていません。
例1.1 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.2 逆引きレコードの 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
1.1.5. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent とインストールプログラムの両方に SSH キーを指定する必要があります。このキーを使用してパブリッククラスターのブートストラップマシンにアクセスし、インストールの問題をトラブルシューティングできます。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core ユーザーの ~/.ssh/authorized_keys 一覧に追加されます。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている 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アルゴリズムを使用するキーを作成します。ssh-agentプロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
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.6. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.1.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.6 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
1.1.7.1. Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。
$ oc <command>
1.1.7.2. Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。
C:\> oc <command>
1.1.7.3. macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。
$ oc <command>
1.1.8. インストール設定ファイルの手動作成
ユーザーによってプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform のインストールでは、インストール設定ファイルを手動で生成します。
前提条件
- OpenShift Container Platform インストーラープログラムおよびクラスターのアクセストークンを取得します。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
以下の
install-config.yamlファイルテンプレートをカスタマイズし、これを<installation_directory>に保存します。注記この設定ファイル
install-config.yamlに名前を付ける必要があります。install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
1.1.8.1. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。
openshift-install コマンドは、パラメーターのフィールド名を検証しません。正しくない名前を指定すると、関連するファイルまたはオブジェクトは作成されず、エラーが報告されません。指定されたパラメーターのフィールド名が正しいことを確認します。
1.1.8.1.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
| 文字列 |
|
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
|
Kubernetes リソース | オブジェクト |
|
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
|
インストールの実行に使用する特定プラットフォームの設定: | オブジェクト |
|
| 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"
}
}
}
|
1.1.8.1.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
|
| インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) プラグイン。 |
|
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
|
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16 |
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16 |
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
1.1.8.1.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
|
| コンピュートノードを設定するマシンの設定。 | machine-pool オブジェクトの配列。詳細は、以下の Machine-pool の表を参照してください。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
|
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Red Hat Operatorのクラウド認証情報 Operatorを参照してください。 |
|
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
|
| 文字列 |
|
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
|
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
このパラメーターを 重要
フィールドの値が |
|
| クラスターマシンへのアクセスを認証するための単一または複数の SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 | 1 つ以上のキー。以下に例を示します。 sshKey: <key1> <key2> <key3> |
1.1.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
- それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、
hostPrefixが23に設定され、各ノードに指定のcidrから/23サブネットが割り当てられます (510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます)。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。 - 11
- サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
- 12
- プラットフォームを
noneに設定する必要があります。プラットフォーム用に追加のプラットフォーム設定変数を指定することはできません。 - 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 キーを指定します。
1.1.8.3. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
ベアメタルインストールでは、install-config.yaml ファイルの networking.machineNetwork[].cidr フィールドで指定される範囲にあるノード IP アドレスを割り当てない場合、それらを proxy.noProxy フィールドに含める必要があります。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター egress トラフィック (クラスターをホストするクラウドについてのクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-confignamespace にuser-ca-bundleという名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundleと少なくとも 1 つのプロキシー設定を指定した場合には、Proxyオブジェクトはtrusted CAフィールドでuser-ca-bundle設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCAパラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle設定マップを作成します。additionalTrustBundleフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpointsフィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
1.1.9. 3 ノードクラスターの設定
オプションで、ワーカーなしで OpenShift Container Platform に 3 ノードクラスターをインストールし、実行できます。これにより、クラスター管理者および開発者が開発、実稼働およびテストに使用するための小規模なリソース効率の高いクラスターが提供されます。
手順
install-config.yamlファイルを編集し、以下のcomputeスタンザに示されるようにコンピュートレプリカ (ワーカーレプリカとしても知られる) の数を0に設定します。compute: - name: worker platform: {} replicas: 0
1.1.10. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを作成するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターを作成するために後に使用されます。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yamlインストール設定ファイルを作成していること。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory> 1- 1
<installation_directory>については、作成したinstall-config.yamlファイルが含まれるインストールディレクトリーを指定します。
3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。
+
コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがワーカーノードになるためです。
<installation_directory>/manifests/cluster-scheduler-02-config.ymlKubernetes マニフェストファイルのmastersSchedulableパラメーターがfalseに設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.ymlファイルを開きます。 -
mastersSchedulableパラメーターを見つけ、これがfalseに設定されていることを確認します。 - ファイルを保存し、終了します。
-
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
関連情報
- kubelet 証明書のリカバリーに関する詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー を参照してください。
1.1.11. 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 セクターのディスクへのインストールをサポートします。
1.1.11.1. ISO イメージを使用した Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成
ユーザーによってプロビジョニングされるインフラストラクチャーにクラスターをインストールする前に、それが使用する RHCOS マシンを作成する必要があります。ISO イメージを使用してマシンを作成することができます。
前提条件
- クラスターの Ignition 設定ファイルを取得している。
- お使いのコンピューターからアクセスでき、作成するマシンからアクセスできる HTTP サーバーへのアクセスがある。
手順
インストールプログラムが作成したコントロールプレーン、コンピュート、およびブートストラップ Ignition 設定を HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
RHCOS イメージミラー ページからオペレーティングシステムのインスタンスをインストールするために優先される方法で必要な RHCOS イメージを取得します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。この手順には ISO イメージのみを使用します。RHCOS qcow2 イメージは、このインストールではサポートされません。
ISO ファイルの名前は以下の例のようになります。
rhcos-<version>-live.<architecture>.isoISO を使用し、RHCOS インストールを開始します。以下のインストールオプションのいずれかを使用します。
- ディスクに ISO イメージを書き込み、これを直接起動します。
- LOM インターフェイスで ISO リダイレクトを使用します。
-
ISO イメージを起動します。インストール起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに
coreos-installerコマンドを使用する必要があります。オプションを指定せず、中断なしでライブインストーラーを実行する場合、インストーラーはライブシステムのシェルプロンプトで起動し、RHCOS をディスクにインストールする準備が整います。 -
coreos-installerを実行する前に、ネットワークやディスクパーティションなどのさまざまな機能を設定する方法については、高度な RHCOS インストールの参照 セクションを参照してください。 coreos-installerコマンドを実行します。最低でも、ノードタイプの Ignition 設定ファイルの場所と、インストールするディスクの場所を特定する必要があります。以下は例です。$ sudo coreos-installer install \ --ignition-url=https://host/worker.ign /dev/sda- RHCOS のインストール後に、システムは再起動します。システムの再起動後、指定した Ignition 設定ファイルを適用します。
継続してクラスターの他のマシンを作成します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、クラスターのインストール前に少なくとも 2 つのコンピュートマシンを作成します。
1.1.11.2. PXE または iPXE ブートによる Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成
手動でプロビジョニングされる RHCOS ノードを使用するクラスターをインストールする前に、それが使用する RHCOS マシンを作成する必要があります。PXE または iPXE ブートを使用してマシンを作成することができます。
前提条件
- クラスターの Ignition 設定ファイルを取得している。
- 適切な PXE または iPXE インフラストラクチャーを設定していること。
- 使用しているコンピューターからアクセス可能な HTTP サーバーへのアクセスがあること。
手順
インストールプログラムが作成したマスター、ワーカーおよびブートストラップの Ignition 設定を HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
RHCOS イメージミラーページから RHCOS
kernel、initramfs、およびrootfsファイルを取得します。重要RHCOS アーティファクトは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのアーティファクトをダウンロードする必要があります。この手順で説明されている適切な
kernel、initramfs、および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
-
使用する起動方法に必要な追加ファイルをアップロードします。
-
従来の PXE の場合、
kernelおよびinitramfsファイルを TFTP サーバーとrootfsファイルを HTTP サーバーにアップロードします。 iPXE の場合、
kernel、initramfs、およびrootfsファイルを HTTP サーバーにアップロードします。重要インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
-
従来の PXE の場合、
- RHCOS のインストール後にマシンがローカルディスクから起動されるようにネットワークブートインフラストラクチャーを設定します。
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? を参照してください。
PXE UEFI を使用する場合は、以下の操作を実行します。
システムの起動に必要な
shimx64.efiandgrubx64.efiEFI バイナリーと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 サーバーにコピーします。
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? を参照してください。
クラスターのマシンの作成を続行します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、クラスターのインストール前に少なくとも 2 つのコンピュートマシンを作成します。
1.1.11.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 設定の使用に関連しています。
1.1.11.3.1. PXE および ISO インストールの高度なネットワークオプションの使用
OpenShift Container Platform ノードのネットワークはデフォルトで DHCP を使用して、必要な設定をすべて収集します。静的 IP アドレスを設定したり、ボンディングなどの特別な設定を行う場合は、以下のいずれかの方法で実行できます。
- ライブインストーラーの起動時に、特別なカーネルパラメーターを渡します。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
- ライブインストーラーのシェルプロンプトからネットワークを設定し、それらの設定をインストール済みシステムにコピーして、インストール済みシステムの初回起動時に有効になるようにします。
PXE または iPXE インストールを設定するには、以下のオプションのいずれかを使用します。
- 詳細の RHCOS インストールリファレンスの表を参照してください。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
ISO インストールを設定するには、以下の手順に従います。
手順
- ISO インストーラーを起動します。
-
ライブシステムシェルプロンプトから、
nmcliまたはnmtuiなどの利用可能な RHEL ツールを使用して、ライブシステムのネットワークを設定します。 coreos-installerコマンドを実行してシステムをインストールし、--copy-networkオプションを追加してネットワーク設定をコピーします。以下に例を示します。$ coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign /dev/sda重要--copy-networkオプションは、/etc/NetworkManager/system-connectionsにあるネットワーク設定のみをコピーします。特に、システムのホスト名はコピーされません。- インストール済みのシステムで再起動します。
1.1.11.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へのブート引数とオプションの両方があります。
1.1.11.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 パーティションを設定します。
手順
OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。
$ mkdir $HOME/clusterconfig
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 ...
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.1.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パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。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) システムをインストールできます。
1.1.11.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
1.1.11.3.3. Ignition 設定の特定
RHCOS の手動インストールを実行する場合、提供できる Ignition 設定には 2 つのタイプがあり、それぞれを提供する理由もそれぞれ異なります。
Permanent install Ignition config: すべての手動の RHCOS インストールは、
bootstrap.ign、master.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が無視されます。
1.1.11.3.3.1. RHCOS ISO への Ignition 設定の埋め込み
ライブインストール Ignition 設定を RHCOS ISO イメージに直接埋め込むことができます。ISO イメージが起動すると、埋め込み設定が自動的に適用されます。
手順
-
以下のイメージミラーページから
coreos-installerバイナリーをダウンロードします: https://mirror.openshift.com/pub/openshift-v4/clients/coreos-installer/latest/ RHCOS ISO イメージおよび Ignition 設定ファイルを取得し、それらを
/mntなどのアクセス可能なディレクトリーにコピーします。# cp rhcos-<version>-live.x86_64.iso bootstrap.ign /mnt/ # chmod 644 /mnt/rhcos-<version>-live.x86_64.iso
以下のコマンドを実行して 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.ign、master.ignおよびworker.ign) を埋め込むことはサポートされておらず、かつ推奨されていません。埋め込み 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
Ignition 設定を削除し、再利用できるように ISO をその初期状態に戻すには、以下を実行します。
# ./coreos-installer iso ignition remove /mnt/rhcos-<version>-live.x86_64.iso
別の Ignition 設定を ISO に埋め込むか、または ISO を初期状態で使用することができるようになりました。
1.1.11.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=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none nameserver=4.4.4.41 |
|
複数の |
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 |
|
オプション: 追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。 | デフォルトゲートウェイを設定するには、以下の手順に従います。 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 を設定し、静的 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=1.1.1.1 nameserver=8.8.8.8 |
|
オプション: 複数のネットワークインターフェイスを単一のインターフェイスにボンディングすることは、
|
DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを 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 で設定し、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 |
|
オプション:
注記 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 ライブインストーラーブートオプションを示しています。
| 引数 | 説明 |
|---|---|
|
|
必須。インストール先のシステムのブロックデバイス。 |
|
| オプション: インストール済みシステムに埋め込む Ignition 設定の URL。URL が指定されていない場合、Ignition 設定は埋め込まれません。 |
|
| オプション: インストール時に保存するパーティションのコンマ区切りのラベル。glob 形式のワイルドカードが許可されます。指定したパーティションは存在する必要はありません。 |
|
|
オプション: インストール時に保存するパーティションのコンマ区切りのインデックス。範囲 |
|
|
オプション: |
|
| オプション: 指定した RHCOS イメージをダウンロードし、インストールします。
|
|
| オプション: システムはインストール後に再起動しません。インストールが完了するとプロンプトが表示され、インストール時に生じる内容を検査できます。この引数は実稼働環境では使用できず、デバッグの目的でのみ使用することが意図されています。 |
|
|
オプション: RHCOS イメージがインストールされるプラットフォームの Ignition プラットフォーム ID。デフォルトは |
|
|
オプション: ライブ起動の Ignition 設定の URL。たとえば、これは |
ISO インストールの coreos-installer オプション
また、コマンドラインから coreos-installer コマンドを直接呼び出して RHCOS をインストールすることもできます。先の表のカーネル引数は、起動時に coreos-installer を自動的に呼び出すためのショートカットを提供しますが、シェルプロンプトから実行している場合は、同様の引数を coreos-installer に直接渡すことができます。
以下の表は、ライブインストール時にシェルプロンプトから coreos-installer コマンドに渡すことのできるオプションとサブコマンドを示しています。
| コマンドラインオプション | |
| オプション | 詳細 |
|
| イメージの URL を手動で指定します。 |
|
| ローカルイメージファイルを手動で指定します。 |
|
| ファイルから Ignition 設定を埋め込みます。 |
|
| URL から Ignition 設定を埋め込みます。 |
|
|
Ignition 設定の |
|
| Ignition プラットフォーム ID を上書きします。 |
|
| デフォルトのカーネル引数を追加します。 |
|
| デフォルトのカーネル引数を削除します。 |
|
| インストール環境からネットワーク設定をコピーします。 重要
|
|
|
|
|
| このラベル glob でパーティションを保存します。 |
|
| この数または範囲でパーティションを保存します。 |
|
| オフラインインストールを強制的に実行します。 |
|
| 署名の検証を省略します。 |
|
| HTTPS またはハッシュなしで Ignition URL を許可します。 |
|
|
ターゲット CPU アーキテクチャー。デフォルトは |
|
| エラー時のパーティションテーブルは消去しないでください。 |
|
| ヘルプ情報を表示します。 |
| コマンドライン引数 | |
| 引数 | 詳細 |
|
| 宛先デバイス。 |
| coreos-installer 組み込み Ignition コマンド | |
| コマンド | 詳細 |
|
| Ignition 設定を ISO イメージに埋め込みます。 |
|
| ISO イメージから埋め込まれた Ignition 設定を表示します。 |
|
| ISO イメージから埋め込まれた Ignition 設定を削除します。 |
| coreos-installer ISO Ignition options | |
| オプション | 詳細 |
|
| 既存の Ignition 設定を上書きします。 |
|
|
使用される Ignition 設定。デフォルトは |
|
| 新しい出力ファイルに ISO を書き込みます。 |
|
| ヘルプ情報を表示します。 |
| coreos-installer PXE Ignition commands | |
| コマンド | 詳細 |
| これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。 | |
|
| イメージに Ignition 設定をラップします。 |
|
| イメージでラップされた Ignition 設定を表示します。 |
|
|
|
| coreos-installer PXE Ignition オプション | |
| オプション | 詳細 |
|
|
使用される Ignition 設定。デフォルトは |
|
| 新しい出力ファイルに ISO を書き込みます。 |
|
| ヘルプ情報を表示します。 |
1.1.12. クラスターの作成
OpenShift Container Platform クラスターを作成するには、ブートストラッププロセスが、インストールプログラムで生成した Ignition 設定ファイルを使用してプロビジョニングしたマシンで完了するのを待機します。
前提条件
- クラスターに必要なインフラストラクチャーを作成する。
- インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
- Ignition 設定ファイルを使用して、クラスターの RHCOS マシンを作成済している。
- お使いのマシンでインターネットに直接アクセスできるか、または HTTP または HTTPS プロキシーが利用できる。
手順
ブートストラッププロセスをモニターします。
$ ./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.19.0 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources
Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、マシン自体を削除し、再フォーマットすることができます。
1.1.13. CLI の使用によるクラスターへのログイン
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI をインストールしていること。
手順
kubeadmin認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1- 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
1.1.14. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.19.0 master-1 Ready master 63m v1.19.0 master-2 Ready master 64m v1.19.0
出力には作成したすべてのマシンが一覧表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (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 が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pendingステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認されたら、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要です。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approverによって自動的に承認されます。注記ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec、oc rsh、およびoc logsコマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:nodeまたはsystem:adminグループのnode-bootstrapperサービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1- 1
<csr_name>は、現行の CSR の一覧からの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ 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 ...
残りの 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
すべてのクライアントおよびサーバーの 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ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
1.1.15. Operator の初期設定
コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。
前提条件
- コントロールプレーンが初期化されています。
手順
クラスターコンポーネントがオンラインになることを確認します。
$ watch -n5 oc get clusteroperators
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.6.0 True False False 3h56m cloud-credential 4.6.0 True False False 29h cluster-autoscaler 4.6.0 True False False 29h config-operator 4.6.0 True False False 6h39m console 4.6.0 True False False 3h59m csi-snapshot-controller 4.6.0 True False False 4h12m dns 4.6.0 True False False 4h15m etcd 4.6.0 True False False 29h image-registry 4.6.0 True False False 3h59m ingress 4.6.0 True False False 4h30m insights 4.6.0 True False False 29h kube-apiserver 4.6.0 True False False 29h kube-controller-manager 4.6.0 True False False 29h kube-scheduler 4.6.0 True False False 29h kube-storage-version-migrator 4.6.0 True False False 4h2m machine-api 4.6.0 True False False 29h machine-approver 4.6.0 True False False 6h34m machine-config 4.6.0 True False False 3h56m marketplace 4.6.0 True False False 4h2m monitoring 4.6.0 True False False 6h31m network 4.6.0 True False False 29h node-tuning 4.6.0 True False False 4h30m openshift-apiserver 4.6.0 True False False 3h56m openshift-controller-manager 4.6.0 True False False 4h36m openshift-samples 4.6.0 True False False 4h30m operator-lifecycle-manager 4.6.0 True False False 29h operator-lifecycle-manager-catalog 4.6.0 True False False 29h operator-lifecycle-manager-packageserver 4.6.0 True False False 3h59m service-ca 4.6.0 True False False 29h storage 4.6.0 True False False 4h30m
- 利用不可の Operator を設定します。
1.1.15.1. インストール時に削除されたイメージレジストリー
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift イメージレジストリー Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、イメージレジストリー Operator 設定を編集して managementState を Removed から 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.1.15.2. イメージレジストリーストレージの設定
イメージレジストリー Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定についての手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
1.1.15.2.1. ベアメタルおよび他の手動インストールの場合のレジストリーストレージの設定
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- ベアメタルなどの、手動でプロビジョニングされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードを使用するクラスター。
Red Hat OpenShift Container Storage などのクラスターのプロビジョニングされた永続ストレージ。
重要OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの
ReadWriteOnceアクセスをサポートします。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteManyアクセスが必要です。- 100Gi の容量が必要です。
手順
レジストリーをストレージを使用できるように設定するには、
configs.imageregistry/clusterリソースのspec.storage.pvcを変更します。注記共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。
レジストリー Pod がないことを確認します。
$ oc get pod -n openshift-image-registry
注記ストレージタイプが
emptyDIRの場合、レプリカ数が1を超えることはありません。レジストリー設定を確認します。
$ oc edit configs.imageregistry.operator.openshift.io
出力例
storage: pvc: claim:claimフィールドを空のままにし、image-registry-storagePVC の自動作成を可能にします。clusteroperatorステータスを確認します。$ oc get clusteroperator image-registry
イメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。
以下を実行します。
$ oc edit configs.imageregistry/cluster
次に、行を変更します。
managementState: Removed
次のように変更してください。
managementState: Managed
1.1.15.2.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.15.2.3. ブロックレジストリーストレージの設定
イメージレジストリーがクラスター管理者によるアップグレード時にブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。
ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。
手順
イメージレジストリーストレージをブロックストレージタイプとして設定するには、レジストリーが
Recreateロールアウトストラテジーを使用し、1 つの (1) レプリカのみで実行されるように、レジストリーにパッチを適用します。$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'- ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。
- 正しい PVC を参照するようにレジストリー設定を編集します。
1.1.16. ユーザーによってプロビジョニングされるインフラストラクチャーでのインストールの完了
Operator 設定の完了後に、提供するインフラストラクチャーでのクラスターのインストールを終了できます。
前提条件
- コントロールプレーンが初期化されています。
- Operator の初期設定を完了済みです。
手順
以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。
$ watch -n5 oc get clusteroperators
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.6.0 True False False 3h56m cloud-credential 4.6.0 True False False 29h cluster-autoscaler 4.6.0 True False False 29h config-operator 4.6.0 True False False 6h39m console 4.6.0 True False False 3h59m csi-snapshot-controller 4.6.0 True False False 4h12m dns 4.6.0 True False False 4h15m etcd 4.6.0 True False False 29h image-registry 4.6.0 True False False 3h59m ingress 4.6.0 True False False 4h30m insights 4.6.0 True False False 29h kube-apiserver 4.6.0 True False False 29h kube-controller-manager 4.6.0 True False False 29h kube-scheduler 4.6.0 True False False 29h kube-storage-version-migrator 4.6.0 True False False 4h2m machine-api 4.6.0 True False False 29h machine-approver 4.6.0 True False False 6h34m machine-config 4.6.0 True False False 3h56m marketplace 4.6.0 True False False 4h2m monitoring 4.6.0 True False False 6h31m network 4.6.0 True False False 29h node-tuning 4.6.0 True False False 4h30m openshift-apiserver 4.6.0 True False False 3h56m openshift-controller-manager 4.6.0 True False False 4h36m openshift-samples 4.6.0 True False False 4h30m operator-lifecycle-manager 4.6.0 True False False 29h operator-lifecycle-manager-catalog 4.6.0 True False False 29h operator-lifecycle-manager-packageserver 4.6.0 True False False 3h59m service-ca 4.6.0 True False False 29h storage 4.6.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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
Kubernetes API サーバーが Pod と通信していることを確認します。
すべての 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 ...
以下のコマンドを使用して、直前のコマンドの出力に一覧表示される Pod のログを表示します。
$ oc logs <pod_name> -n <namespace> 1- 1
- 直前のコマンドの出力にあるように、Pod 名および namespace を指定します。
Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。
1.1.17. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.6 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
1.1.18. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
- レジストリーをセットアップし、レジストリーストレージを設定します。
