OpenStack へのインストール
OpenShift Container Platform 4.3 OpenStack クラスターのインストール
概要
第1章 OpenStack へのインストール
1.1. カスタマイズによる OpenStack へのクラスターのインストール
OpenShift Container Platform バージョン 4.3 では、Red Hat OpenStack Platform (RHOSP) にカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に install-config.yaml
でパラメーターを変更します。
1.1.1. 前提条件
OpenShift Container Platform のインストールおよび更新プロセスについての詳細を確認します。
- OpenShift Container Platform 4.3 が Available platforms セクションの RHOSP バージョンと互換性があることを確認します。RHOSP サポートマトリックスの OpenShift Container Platform を参照して、プラットフォームのサポートを異なるバージョン間で比較することもできます。
- RHOSP でメタデータサービスが有効にされていること
1.1.2. OpenShift Container Platform を RHOSP にインストールするリソースのガイドライン
クォータは、Red Hat OpenStack Platform (RHOSP) で OpenShift Container Platform インストールプログラムを実行するために、以下の要件を満たす必要があります。
リソース | 値 |
---|---|
Floating IP アドレス | 2 |
ポート | 15 |
ルーター | 1 |
サブネット | 1 |
RAM | 112 GB |
vCPU | 28 |
ボリュームストレージ | 175 GB |
インスタンス | 7 |
セキュリティーグループ | 3 |
セキュリティーグループルール | 60 |
Swift コンテナー | 2 |
Swift オブジェクト | 1 |
Swift で利用可能な領域 | 10 MB 以上 |
Swift 領域要件は、ブートストラップ Ignition ファイルおよびイメージレジストリーのサイズによって異なります。
クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。
デフォルトで、セキュリティーグループおよびセキュリティーグループルールのクォータは低く設定される可能性があります。問題が生じた場合には、管理者として openstack quota set --secgroups 3 --secgroup-rules 60 <project>
を実行して値を増やします。
OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで構成されます。
1.1.2.1. コントロールプレーンおよびコンピュートマシン
デフォルトで、OpenShift Container Platform インストールプログラムは 3 つのコントロールプレーンおよびコンピュートマシンを使用します。
それぞれのマシンには以下が必要です。
- RHOSP クォータからのインスタンス
- RHOSP クォータからのポート
- 少なくとも 16 GB のメモリー、4 つの vCPU および 25 GB のストレージ領域があるフレーバー
コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。
1.1.2.2. ブートストラップマシン
インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。
ブートストラップマシンには以下が必要です。
- RHOSP クォータからのインスタンス
- RHOSP クォータからのポート
- 少なくとも 16 GB のメモリー、4 つの vCPU および 25 GB のストレージ領域があるフレーバー
インストールプログラムは、コントロールプレーンマシンの Ignition に認証局バンドルを渡すことはできません。そのため、エンドポイントが自己署名型の証明書を使用する場合には、ブートストラップマシンが Swift から Ignition 設定を取得できません。
1.1.3. OpenShift Container Platform のインターネットアクセスおよび Telemetry アクセス
OpenShift Container Platform 4.3 では、クラスターをインストールするためにインターネットアクセスが必要になります。クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される 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.4. OpenStack での Swift の有効化
Red Hat OpenStack Platform (RHOSP) 上の OpenShift Container Platform は RHOSP Object Storage (Swift) を使用して、ユーザー設定ファイルを保存し、これを提供します。
Swift は、swiftoperator
ロールのあるユーザーアカウントによって操作されます。
前提条件
- ターゲット環境の RHOSP 管理者アカウント
-
Ceph RGW では、
account in url
オプションが有効にされる必要があります。
手順
RHOSP 上で Swift を有効にするには、以下を実行します。
RHOSP CLI の管理者として、
swiftoperator
ロールを Swift にアクセスするアカウントに追加します。$ openstack role add --user <user> --project <project> swiftoperator
RHOSP のデプロイメントでは、Swift を使用してファイルを保存し、提供できるようになりました。
1.1.5. 外部ネットワークアクセスの確認
OpenShift Container Platform インストーラーでは、外部ネットワークへのアクセスが必要です。外部ネットワーク値をこれに指定する必要があります。指定しない場合には、デプロイメントは失敗します。インストーラーを実行する前に、外部ルータータイプのネットワークが Red Hat OpenStack Platform (RHOSP) に存在することを確認します。
前提条件
RHOSP では、
NeutronDhcpAgentDnsmasqDnsServers
パラメーターを DHP エージェントがインスタンスの DNS クエリーを転送できるように設定される必要があります。このパラメーターを設定する方法として、以下を実行できます。- テンプレートディレクトリーに新規の環境ファイルを作成します。
ファイルにパラメーター値を指定します。例:
parameter_defaults: NeutronDhcpAgentDnsmasqDnsServers: ['<DNS_server_address_1>','<DNS_server_address_2']
オーバークラウドデプロイコマンドに環境ファイルを組み込みます。例:
$ openstack overcloud deploy --templates -e neutron-dhcp-agent-dnsmasq-dns-servers.yaml ...
手順
RHOSP CLI を使用して、'External' ネットワークの名前と ID を確認します。
$ openstack network list --long -c ID -c Name -c "Router Type" +--------------------------------------+----------------+-------------+ | ID | Name | Router Type | +--------------------------------------+----------------+-------------+ | 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External | +--------------------------------------+----------------+-------------+
外部ルータータイプのあるネットワークがネットワーク一覧に表示されます。1 つ以上のネットワークが表示されない場合は、「Creating a default floating IP network」および「 Creating a default provider network」を参照してください。
外部ネットワークの CIDR 範囲がデフォルトのネットワーク範囲のいずれかと重複している場合、インストールプログラムを実行する前に、install-config.yaml
ファイルで一致するネットワーク範囲を変更する必要があります。
デフォルトのネットワーク範囲は以下のとおりです。
Network | 範囲 |
---|---|
machineCIDR | 10.0.0.0/16 |
serviceNetwork | 172.30.0.0/16 |
clusterNetwork | 10.128.0.0/14 |
インストールプログラムにより同じ名前を持つ複数のネットワークが見つかる場合、それらのネットワークのいずれかがランダムに設定されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。
Neutron トランクサービスプラグインが有効にされると、トランクポートがデフォルトで作成されます。詳細は、「Neutron trunk port」を参照してください。
1.1.6. インストールプログラムのパラメーターの定義
OpenShift Container Platform インストールプログラムは、clouds.yaml
というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。
手順
clouds.yaml
ファイルを作成します。RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに
clouds.yaml
ファイルを生成します。重要パスワードを必ず
auth
フィールドに追加してください。シークレットは、clouds.yaml
の別のファイルに保持できます。RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。
clouds.yaml
についての詳細は、RHOSP ドキュメントの「Config files」を参照してください。clouds: shiftstack: auth: auth_url: http://10.10.14.42:5000/v3 project_name: shiftstack username: shiftstack_user password: XXX user_domain_name: Default project_domain_name: Default dev-env: region_name: RegionOne auth: username: 'devuser' password: XXX project_name: 'devonly' auth_url: 'https://10.10.14.22:5001/v2.0'
生成するファイルを以下のいずれかの場所に置きます。
-
OS_CLIENT_CONFIG_FILE
環境変数の値 - 現行ディレクトリー
-
Unix 固有のユーザー設定ディレクトリー (例:
~/.config/openstack/clouds.yaml
) Unix 固有のサイト設定ディレクトリー (例:
/etc/openstack/clouds.yaml
)インストールプログラムはこの順序で
clouds.yaml
を検索します。
-
1.1.7. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。
前提条件
- Linux または macOS を使用するコンピューターからクラスターをインストールする必要があります。
- インストールプログラムをダウンロードするには、500 MB のローカルディスク領域が必要です。
手順
- Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターインストールの完了後は、インストールプログラムおよびインストールプログラムが作成するファイルの両方を保持する必要があります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。特定のクラウドプロバイダー用に記載された OpenShift Container Platform のアンインストール手順を完了して、クラスターを完全に削除する必要があります。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar xvf <installation_program>.tar.gz
-
Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから、インストールプルシークレットを
.txt
ファイルとしてダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.1.8. インストール設定ファイルの作成
Red Hat OpenStack Platform (RHOSP) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
install-config.yaml
ファイルを作成します。以下のコマンドを実行します。
$ ./openshift-install create install-config --dir=<installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして openstack を選択します。
- クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
- OpenShift API への外部アクセスに使用する Floating IP アドレスを指定します。
- コントロールプレーンおよびコンピュートノードに使用する 16 GB 以上の RAM で RHOSP フレーバーを指定します。
- クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
- クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
- Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから取得したプルシークレットを貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細については、「インストール設定パラメーター」セクションを参照してください。 install-config.yaml
ファイルをバックアップし、これを複数のクラスターをインストールするために使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
1.1.9. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、install-config.yaml
ファイルでこれらのパラメーターを変更することはできません。
パラメーター | 説明 | 値 |
---|---|---|
|
クラウドプロバイダーのベースドメイン。この値は、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
コントロールプレーンマシンをホストするためのクラウドプロバイダー。このパラメーターの値は |
|
|
ワーカーマシンをホストするためのクラウドプロバイダー。このパラメーターの値は |
|
| クラスターの名前。 |
|
| クラスターをデプロイするリージョン。 |
AWS の |
| Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する、Quay.io などの組み込まれた各種の認証局によって提供されるサービスで認証できます。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } } |
パラメーター | 説明 | 値 |
---|---|---|
| クラスターマシンにアクセスするために使用する SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
|
| FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。 |
|
| クラスターのユーザーに表示されるエンドポイントを公開する方法。 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
| プロビジョニングするコンピュートマシン(ワーカーマシンとしても知られる)の数。 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
| プロビジョニングするコントロールプレーンマシンの数。 |
|
パラメーター | 説明 | 値 |
---|---|---|
| コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。 |
整数 (例: |
| コンピュートマシンの場合、root のボリュームタイプです。 |
文字列 (例: |
| コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。 |
整数 (例: |
| コントロールプレーンマシンの場合、root ボリュームのタイプです。 |
文字列 (例: |
| RHOSP クラスターが作成されるリージョン。 |
文字列 (例: |
|
|
文字列 (例: |
| インストールに使用される RHOSP の外部ネットワーク名。 |
文字列 (例: |
| コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。 |
文字列 (例: |
| ロードバランサー API に関連付ける既存の Floating IP アドレス。 |
IP アドレス (例: |
パラメーター | 説明 | 値 |
---|---|---|
| クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。 |
IP アドレスの一覧 (文字列)。例: |
| デフォルトのマシンプールプラットフォームの設定。 |
{ "type": "ml.large", "rootVolume": { "size": 30, "type": "performance" } } |
| インストーラーが RHCOS イメージをダウンロードする場所。 ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。 | HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。
例:
この値は、既存の Glance イメージの名前にもなり得ます (例: |
1.1.9.1. RHOSP のカスタマイズされた install-config.yaml
ファイルのサンプル
このサンプル install-config.yaml
は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。
このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得する必要があります。
apiVersion: v1 baseDomain: example.com clusterID: os-test controlPlane: name: master platform: {} replicas: 3 compute: - name: worker platform: openstack: type: ml.large replicas: 3 metadata: name: example networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineCIDR: 10.0.0.0/16 serviceNetwork: - 172.30.0.0/16 networkType: OpenShiftSDN platform: openstack: region: region1 cloud: mycloud externalNetwork: external computeFlavor: m1.xlarge lbFloatingIP: 128.0.0.1 fips: false pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
1.1.10. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent
とインストールプログラムの両方に SSH キーを指定する必要があります。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core
としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core
ユーザーの ~/.ssh/authorized_keys
一覧に追加されます。
AWS キーペアなどのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t rsa -b 4096 -N '' \ -f <path>/<file_name> 1
- 1
~/.ssh/id_rsa
などの、SSH キーのパスおよびファイル名を指定します。既存の SSH キーは上書きされるため、指定しないでください。
このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。
ssh-agent
プロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)" Agent pid 31874
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.11. 環境へのアクセスの有効化
デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。
OpenShift Container Platform API を、Floating IP アドレスを使用/不使用でアクセス可能になるように設定できます。
1.1.11.1. Floating IP アドレスを使ったアクセスの有効化
OpenShift Container Platform API エンドポイントに 2 つのエンドポイントを割り当てることにより、これらのエンドポイントをアクセス可能にします。その内の 1 つは API ロードバランサー用で (lb FIP
)、もう 1 つは OpenShift Container Platform アプリケーション用 (apps FIP
) になります。
ロードバランサー FIP も install-config.yaml
ファイルで使用されます。
手順
Red Hat OpenStack Platform (RHOSP) CLI を使用して、新しい外部ネットワークを作成します。
$ openstack floating ip create <external network>
このパターンに準拠するレコードを DNS サーバーに追加します。
api.<cluster name>.<base domain> IN A <lb FIP>
注記DNS サーバーを制御しない場合は、代わりに
/etc/hosts
ファイルにレコードを追加します。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。
Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。
1.1.11.2. Floating IP アドレスを使用しないアクセスの有効化
Floating IP アドレスを使用できない場合でも、OpenShift Container Platform のインストールは終了できる可能性があります。ただし、インストールプラグラムは API アクセスを待機してタイムアウトする場合は失敗します。
インストールプログラムがタイムアウトすると、クラスターは初期化される可能性があります。ブートストラップ処理が開始されたら、これを完了する必要があります。ただし、デプロイ後にクラスターのネットワーク設定を編集する必要があります。
1.1.12. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
インストールプログラムを実行します。
$ ./openshift-install create cluster --dir=<installation_directory> \ 1 --log-level=info 2
注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。重要インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。最初の証明書のローテーションが正常に実行されるようにするには、クラスターを動作が低下していない状態で 24 時間実行し続ける必要があります。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
1.1.13. クラスターステータスの確認
インストール時またはインストール後に OpenShift Container Platform クラスターのステータスを確認するには、以下を実行します。
手順
クラスター環境で、管理者の kubeconfig ファイルをエクスポートします。
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。デプロイメント後に作成されたコントロールプレーンおよびコンピュートマシンを表示します。
$ oc get nodes
クラスターのバージョンを表示します。
$ oc get clusterversion
Operator のステータスを表示します。
$ oc get clusteroperator
クラスター内のすべての実行中の Pod を表示します。
$ oc get pods -A
1.1.14. クラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイします。
-
oc
CLI をインストールします。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami system:admin
1.1.15. Floating IP アドレスを使用したアプリケーションアクセスの設定
OpenShift Container Platform をインストールした後に、アプリケーションネットワークトラフィックを許可するように Red Hat OpenStack Platform (RHOSP) を設定します。
前提条件
- OpenShift Container Platform クラスターがインストールされている必要があります。
- 「環境へのアクセスの有効化」で説明されているように、Floating IP アドレスが有効化されています。
手順
OpenShift Container Platform クラスターをインストールした後に、Floating IP アドレスを Ingress ポートに割り当てます。
ポートを表示します。
$ openstack port show <cluster name>-<clusterID>-ingress-port
ポートを IP アドレスに接続します。
$ openstack floating ip set --port <ingress port ID> <apps FIP>
*apps.
のワイルドカードA
レコードを DNS ファイルに追加します。*.apps.<cluster name>.<base domain> IN A <apps FIP>
DNS サーバーを制御せず、非実稼働環境でアプリケーションアクセスを有効にする必要がある場合は、これらのホスト名を /etc/hosts
に追加できます。
<apps FIP> console-openshift-console.apps.<cluster name>.<base domain> <apps FIP> integrated-oauth-server-openshift-authentication.apps.<cluster name>.<base domain> <apps FIP> oauth-openshift.apps.<cluster name>.<base domain> <apps FIP> prometheus-k8s-openshift-monitoring.apps.<cluster name>.<base domain> <apps FIP> grafana-openshift-monitoring.apps.<cluster name>.<base domain> <apps FIP> <app name>.apps.<cluster name>.<base domain>
1.1.16. 次のステップ
- クラスターをカスタマイズします。
- 必要な場合は、リモートの健全性レポートをオプトアウトすることができます。
- ノードポートへの外部アクセスを有効にする必要がある場合は、NodePort を使用して Ingress クラスタートラフィックを設定 します。
1.2. Kuryr を使用する OpenStack へのクラスターのインストール
OpenShift Container Platform バージョン 4.3 では、Kuryr SDN を使用する Red Hat OpenStack Platform (RHOSP) にカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に install-config.yaml
でパラメーターを変更します。
1.2.1. 前提条件
OpenShift Container Platform のインストールおよび更新プロセスについての詳細を確認します。
- OpenShift Container Platform 4.3 が Available platforms セクションの RHOSP バージョンと互換性があることを確認します。RHOSP サポートマトリックスの OpenShift Container Platform を参照して、プラットフォームのサポートを異なるバージョン間で比較することもできます。
1.2.2. Kuryr SDN について
Kuryr は、Neutron および Octavia Red Hat OpenStack Platform (RHOSP) サービスを使用して Pod およびサービスのネットワークを提供する Container Network Interface (CNI) プラグインです。
Kuryr と OpenShift Container Platform の統合は主に、RHOSP の仮想マシンで実行する OpenShift Container Platform クラスター用に設計されました。Kuryr は、OpenShift Container Platform Pod を RHOSP SDN にプラグインしてネットワークのパフォーマンスを強化します。さらに、これは Pod と RHOSP 仮想インスタンス間の接続を可能にします。
Kuryr コンポーネントは openshift-kuryr
namespace を使用して OpenShift Container Platform の Pod としてインストールされます。
-
kuryr-controller
:master
ノードにインストールされる単一のサービスインスタンスです。これは、OpenShift Container Platform でDeployment
としてモデリングされます。 -
kuryr-cni
: 各 OpenShift Container Platform ノードで Kuryr を CNI ドライバーとしてインストールし、設定するコンテナーです。これは、OpenShift Container Platform でDaemonSet
としてモデリングされます。
Kuryr コントローラーは OpenShift API サーバーで Pod、サービスおよび namespace の作成、更新、および削除イベントについて監視します。これは、OpenShift Container Platform API 呼び出しを Neutron および Octavia の対応するオブジェクトにマップします。そのため、Neutron トランクポート機能を実装するすべてのネットワークソリューションを使用して、Kuryr 経由で OpenShift Container Platform をサポートすることができます。これには、Open vSwitch (OVS) および Open Virtual Network (OVN) などのオープンソースソリューションや Neutron と互換性のある市販の SDN が含まれます。
Kuryr は、カプセル化された RHOSP テナントネットワーク上の OpenShift Container Platform デプロイメントに使用することが推奨されています。これは、 RHOSP ネットワークでカプセル化された OpenShift Container Platform SDN を実行するなど、二重のカプセル化を防ぐために必要です。
以下の場合には Kuryr の使用は推奨されていません。
- プロバイダーネットワークまたはテナント VLAN を使用します。
- お使いのデプロイメントで、いくつかのハイパーバイザーで数多くのサービスを使用している。各 OpenShift サービスは、必要なロードバランサーをホストする OpenStack で Octavia Amphora 仮想マシンを作成します。
- UDP サービスが必要です。
1.2.3. Kuryr を使用して OpenShift Container Platform を RHOSP にインストールするためのリソースのガイドライン
Kuryr SDN を使用する場合、Pod、サービス、namespace およびネットワークポリシーは RHOSP クォータのリソースを使用します。これにより、最小要件が増加します。また、Kuryr にはデフォルトインストールに必要な要件以外の追加要件があります。
以下のクォータを使用してデフォルトのクラスターの最小要件を満たすようにします。
リソース | 値 |
---|---|
Floating IP アドレス | 3: LoadBalancer タイプに予想されるサービス数 |
ポート | 1500: Pod ごとに 1 つ必要 |
ルーター | 1 |
サブネット | 250: namespace/プロジェクトごとに 1 つ必要 |
ネットワーク | 250: namespace/プロジェクトごとに 1 つ必要 |
RAM | 112 GB |
vCPU | 28 |
ボリュームストレージ | 175 GB |
インスタンス | 7 |
セキュリティーグループ | 250: サービスおよび NetworkPolicy ごとに 1 つ必要 |
セキュリティーグループルール | 1000 |
Swift コンテナー | 2 |
Swift オブジェクト | 1 |
Swift で利用可能な領域 | 10 MB 以上 |
ロードバランサー | 100:サービスごとに 1 つ必要 |
ロードバランサーリスナー | 500:サービスで公開されるポートごとに 1 つ必要 |
ロードバランサーノード | 500:サービスで公開されるポートごとに 1 つ必要 |
クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。
リソースを設定する際には、以下の点に注意してください。
- 必要なポート数は Pod 数よりも大きくなる。Kuryr はポートプールを使用して、事前に作成済みのポートを Pod で使用できるようにし、Pod の起動時間を短縮します。
- 各 NetworkPolicy は RHOSP セキュリティーグループにマップされ、NetworkPolicy 仕様によっては 1 つ以上のルールがセキュリティーグループに追加される。
- 各サービスは RHOSP ロードバランサーにマップされる。各ロードバランサーにはユーザープロジェクトを含むセキュリティーグループがあるため、クォータに必要なセキュリティーグループの数を見積もる場合には、これを考慮に入れる必要があります。
- Swift 領域要件は、ブートストラップ Ignition ファイルおよびイメージレジストリーのサイズによって異なります。
- クォータはロードバランサーのリソース(VM リソースなど)を考慮しませんが、RHOSP デプロイメントのサイズを決定する際にはこれらのリソースを考慮する必要があります。デフォルトのインストールには 50 を超えるロードバランサーが あり、クラスターはそれらのロードバランサーに対応できる必要があります。
OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで構成されます。
Kuryr SDN を有効にするには、使用する環境が以下の要件を満たしている必要があります。
- RHOSP 13+ を実行します。
- オーバークラウドと Octavia を使用します。
- Neutron トランクポートの拡張を使用します。
-
ML2/OVS Neutron ドライバーが
ovs-hybrid
の代わりに使用れる場合、openvswitch
ファイアウォールドライバーを使用します。
1.2.3.1. クォータの拡大
Kuryr SDN を使用する場合、Pod、サービス、namespace、およびネットワークポリシーが使用する Red Hat OpenStack Platform (RHOSP) リソースに対応するためにクォータを引き上げる必要があります。
手順
以下のコマンドを実行して、プロジェクトのクォータを増やします。
$ sudo openstack quota set --secgroups 250 --secgroup-rules 1000 --ports 1500 --subnets 250 --networks 250 <project>
1.2.3.2. Neutron の設定
Kuryr CNI は Neutron トランクの拡張を使用してコンテナーを Red Hat OpenStack Platform (RHOSP) SDN にプラグインします。したがって、Kuryr が適切に機能するには trunks
拡張を使用する必要があります。
さらにデフォルトの ML2/OVS Neutron ドライバーを使用する場合には、セキュリティーグループがトランクサブポートで実行され、Kuryr がネットワークポリシーを適切に処理できるように、ovs_hybrid
ではなく openvswitch
に設定される必要があります。
1.2.3.3. Octavia の設定
Kuryr SDN は Red Hat OpenStack Platform (RHOSP) の Octavia LBaaS を使用して OpenShift Container Platform サービスを実装します。したがって、Kuryr SDN を使用するように RHOSP に Octavia コンポーネントをインストールし、設定する必要があります。
Octavia を有効にするには、Octavia サービスを RHOSP オーバークラウドのインストール時に組み込むか、またはオーバークラウドがすでに存在する場合は Octavia をアップグレードする必要があります。Octavia を有効にする以下の手順は、オーバークラウドのクリーンインストールまたはオーバークラウドの更新の両方に適用されます。
以下の手順では、Octavia を使用する場合に RHOSP のデプロイメント 時に必要となる主な手順のみを説明します。また、レジストリーメソッド が変更されることにも留意してください。
以下の例では、ローカルレジストリーの方法を使用しています。
手順
ローカルレジストリーを使用している場合、イメージをレジストリーにアップロードするためのテンプレートを作成します。以下は例になります。
(undercloud) $ openstack overcloud container image prepare \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ --namespace=registry.access.redhat.com/rhosp13 \ --push-destination=<local-ip-from-undercloud.conf>:8787 \ --prefix=openstack- \ --tag-from-label {version}-{release} \ --output-env-file=/home/stack/templates/overcloud_images.yaml \ --output-images-file /home/stack/local_registry_images.yaml
local_registry_images.yaml
ファイルに Octavia イメージが含まれることを確認します。以下は例になります。... - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-api:13.0-43 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-health-manager:13.0-45 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-housekeeping:13.0-45 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-worker:13.0-44 push_destination: <local-ip-from-undercloud.conf>:8787
注記Octavia コンテナーのバージョンは、インストールされている特定の RHOSP リリースによって異なります。
コンテナーイメージを registry.redhat.io からアンダークラウドノードにプルします。
(undercloud) $ sudo openstack overcloud container image upload \ --config-file /home/stack/local_registry_images.yaml \ --verbose
これには、ネットワークおよびアンダークラウドディスクの速度に応じて多少の時間がかかる可能性があります。
Octavia ロードバランサーは OpenShift API にアクセスするために使用されるため、それらのリスナーの接続のデフォルトタイムアウトを増やす必要があります。デフォルトのタイムアウトは 50 秒です。以下のファイルをオーバークラウドのデプロイコマンドに渡し、タイムアウトを 20 分に増やします。
(undercloud) $ cat octavia_timeouts.yaml parameter_defaults: OctaviaTimeoutClientData: 1200000 OctaviaTimeoutMemberData: 1200000
注記これは RHOSP 14+ では必要ありません。
Octavia を使用してオーバークラウドをインストールまたは更新します。
openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ -e octavia_timeouts.yaml
注記このコマンドには、Octavia に関連付けられたファイルのみが含まれます。これは、RHOSP の特定のインストールによって異なります。詳細は RHOSP のドキュメントを参照してください。Octavia インストールのカスタマイズについての詳細は、「Octavia デプロイメントのプランニング」を参照してください。
注記Kuryr SDN を利用する際には、オーバークラウドのインストールに Neutron の
trunk
拡張機能が必要です。これは、Director デプロイメントでデフォルトで有効にされます。Neutron バックエンドが ML2/OVS の場合、デフォルトのovs-hybrid
の代わりにopenvswitch
ファイアウォールを使用します。バックエンドが ML2/OVN の場合には変更の必要がありません。RHOSP バージョン 13 および 15 では、プロジェクトの作成後にプロジェクト ID を
octavia.conf
設定ファイルに追加します。トラフィックが Octavia ロードバランサーを通過する場合など、複数のサービス全体でネットワークポリシーを実行するには、Octavia がユーザープロジェクトで Amphora 仮想マシンセキュリティーグループを作成するようにする必要があります。
この変更により、必要な LoadBalancer セキュリティーグループがそのプロジェクトに属し、それらをサービスの分離を実行するように更新できます。
注記RHOSP バージョン 16 以降では、このタスクは必要ありません。
Octavia は、ロードバランサー VIP へのアクセスを制限する新しい ACL API を実装します。
プロジェクト ID を取得します。
$ openstack project show <project> +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | domain_id | default | | enabled | True | | id | PROJECT_ID | | is_domain | False | | name | *<project>* | | parent_id | default | | tags | [] | +-------------+----------------------------------+
プロジェクト ID をコントローラーの
octavia.conf
に追加します。オーバークラウドコントローラーを一覧表示します。
$ source stackrc # Undercloud credentials $ openstack server list +--------------------------------------+--------------+--------+-----------------------+----------------+------------+ │ | ID | Name | Status | Networks | Image | Flavor | │ +--------------------------------------+--------------+--------+-----------------------+----------------+------------+ │ | 6bef8e73-2ba5-4860-a0b1-3937f8ca7e01 | controller-0 | ACTIVE | ctlplane=192.168.24.8 | overcloud-full | controller | │ | dda3173a-ab26-47f8-a2dc-8473b4a67ab9 | compute-0 | ACTIVE | ctlplane=192.168.24.6 | overcloud-full | compute | │ +--------------------------------------+--------------+--------+-----------------------+----------------+------------+
コントローラーに対して SSH を実行します。
$ ssh heat-admin@192.168.24.8
octavia.conf
を編集して、プロジェクトを Amphora セキュリティーグループがユーザーのアカウントに設定されているプロジェクトの一覧に追加します。# List of project IDs that are allowed to have Load balancer security groups # belonging to them. amp_secgroup_allowed_projects = PROJECT_ID
新しい設定が読み込まれるように Octavia ワーカーを再起動します。
controller-0$ sudo docker restart octavia_worker
RHOSP 環境によっては、Octavia が UDP リスナーをサポートしない場合があります。つまり、Kuryr SDN が使用されている場合は UDP サービスはサポートされません。
1.2.3.4. Kuryr を使用したインストールについての既知の制限
OpenShift Container Platform を Kuryr SDN で使用する場合、いくつかの既知の制限があります。
1.2.3.4.1. RHOSP の一般的な制限
Kuryr SDN を使用する OpenShift Container Platform は NodePort サービスをサポートしません。
RHOSP リソースの制限
- Amphora ロードバランサー VM は、デフォルトの Octavia ロードバランサードライバー(Amphora ドライバー)を使用する OpenShift サービスごとにデプロイされます。サービス数が多すぎると、リソースが不足する可能性があります。
RHOSP バージョンの制限
OpenShift Container Platform を Kuryr SDN で使用する場合は、RHOSP バージョンに依存するいくつかの制限があります。
- バージョン 16 よりも前の Octavia RHOSP バージョンは UDP リスナーをサポートしません。そのため、OpenShift UDP サービスはサポートされません。
- バージョン 16 よりも前の Octavia RHOSP バージョンは、同じポートで複数のプロトコルをリッスンできません。TCP や UDP など、同じポートを異なるプロトコルに公開するサービスはサポートされません。
OVN Octavia ドライバーは、RHOSP バージョンで異なるプロトコルを使用するリスナーをサポートしません。
RHOSP 環境の制限
Kuryr SDN を使用する場合に、デプロイメント環境に依存する制限事項があります。
Octavia には UDP プロトコルおよび複数のリスナーのサポートがないため、Kuryr は Pod が以下の場合に DNS 解決に TCP を使用するように強制します。
- RHOSP のバージョンが 16 よりも古い
- OVN Octavia ドライバーが使用される
Go バージョン 1.12 以前では、CGO サポートが無効にされた状態でコンパイルされたアプリケーションは UDP のみを使用します。この場合、ネイティブの Go リゾルバーは、TCP が DNS 解決に強制的に実行されるかどうかを制御する、resolv.conf
の use-vc
オプションを認識しません。その結果、UDP は引き続き DNS 解決に使用されますが、これは失敗します。
TCP の強制を許可するには、環境変数 CGO_ENABLED
を 1
に設定 (例: CGO_ENABLED=1
) されている状態でアプリケーションをコンパイルするか、または変数がないことを確認します。
Go バージョン 1.13 以降では、UDP を使用した DNS 解決が失敗する場合に TCP が自動的に使用されます。
Alpine ベースのコンテナーを含む musl ベースのコンテナーは use-vc
オプションをサポートしません。
1.2.3.5. コントロールプレーンおよびコンピュートマシン
デフォルトで、OpenShift Container Platform インストールプログラムは 3 つのコントロールプレーンおよびコンピュートマシンを使用します。
それぞれのマシンには以下が必要です。
- RHOSP クォータからのインスタンス
- RHOSP クォータからのポート
- 少なくとも 16 GB のメモリー、4 つの vCPU および 25 GB のストレージ領域があるフレーバー
コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。
1.2.3.6. ブートストラップマシン
インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。
ブートストラップマシンには以下が必要です。
- RHOSP クォータからのインスタンス
- RHOSP クォータからのポート
- 少なくとも 16 GB のメモリー、4 つの vCPU および 25 GB のストレージ領域があるフレーバー
インストールプログラムは、コントロールプレーンマシンの Ignition に認証局バンドルを渡すことはできません。そのため、エンドポイントが自己署名型の証明書を使用する場合には、ブートストラップマシンが Swift から Ignition 設定を取得できません。
1.2.4. OpenShift Container Platform のインターネットアクセスおよび Telemetry アクセス
OpenShift Container Platform 4.3 では、クラスターをインストールするためにインターネットアクセスが必要になります。クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは Red Hat OpenShift Cluster Manager (OCM) に登録されます。
Red Hat OpenShift Cluster Manager インベントリーが Telemetry によって自動的に維持されるか、または OCM を手動で使用しているかのいずれによって正常であることを確認した後に、subscription watch を使用して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
インターネットへのアクセスは以下を実行するために必要です。
- Red Hat OpenShift Cluster Manager ページにアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.2.5. OpenStack での Swift の有効化
Red Hat OpenStack Platform (RHOSP) 上の OpenShift Container Platform は RHOSP Object Storage (Swift) を使用して、ユーザー設定ファイルを保存し、これを提供します。
Swift は、swiftoperator
ロールのあるユーザーアカウントによって操作されます。
前提条件
- ターゲット環境の RHOSP 管理者アカウント
-
Ceph RGW では、
account in url
オプションが有効にされる必要があります。
手順
RHOSP 上で Swift を有効にするには、以下を実行します。
RHOSP CLI の管理者として、
swiftoperator
ロールを Swift にアクセスするアカウントに追加します。$ openstack role add --user <user> --project <project> swiftoperator
RHOSP のデプロイメントでは、Swift を使用してファイルを保存し、提供できるようになりました。
1.2.6. 外部ネットワークアクセスの確認
OpenShift Container Platform インストーラーでは、外部ネットワークへのアクセスが必要です。外部ネットワーク値をこれに指定する必要があります。指定しない場合には、デプロイメントは失敗します。インストーラーを実行する前に、外部ルータータイプのネットワークが Red Hat OpenStack Platform (RHOSP) に存在することを確認します。
前提条件
RHOSP では、
NeutronDhcpAgentDnsmasqDnsServers
パラメーターを DHP エージェントがインスタンスの DNS クエリーを転送できるように設定される必要があります。このパラメーターを設定する方法として、以下を実行できます。- テンプレートディレクトリーに新規の環境ファイルを作成します。
ファイルにパラメーター値を指定します。例:
parameter_defaults: NeutronDhcpAgentDnsmasqDnsServers: ['<DNS_server_address_1>','<DNS_server_address_2']
オーバークラウドデプロイコマンドに環境ファイルを組み込みます。例:
$ openstack overcloud deploy --templates -e neutron-dhcp-agent-dnsmasq-dns-servers.yaml ...
手順
RHOSP CLI を使用して、'External' ネットワークの名前と ID を確認します。
$ openstack network list --long -c ID -c Name -c "Router Type" +--------------------------------------+----------------+-------------+ | ID | Name | Router Type | +--------------------------------------+----------------+-------------+ | 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External | +--------------------------------------+----------------+-------------+
外部ルータータイプのあるネットワークがネットワーク一覧に表示されます。1 つ以上のネットワークが表示されない場合は、「Creating a default floating IP network」および「 Creating a default provider network」を参照してください。
外部ネットワークの CIDR 範囲がデフォルトのネットワーク範囲のいずれかと重複している場合、インストールプログラムを実行する前に、install-config.yaml
ファイルで一致するネットワーク範囲を変更する必要があります。
デフォルトのネットワーク範囲は以下のとおりです。
Network | 範囲 |
---|---|
machineCIDR | 10.0.0.0/16 |
serviceNetwork | 172.30.0.0/16 |
clusterNetwork | 10.128.0.0/14 |
インストールプログラムにより同じ名前を持つ複数のネットワークが見つかる場合、それらのネットワークのいずれかがランダムに設定されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。
Neutron トランクサービスプラグインが有効にされると、トランクポートがデフォルトで作成されます。詳細は、「Neutron trunk port」を参照してください。
1.2.7. インストールプログラムのパラメーターの定義
OpenShift Container Platform インストールプログラムは、clouds.yaml
というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。
手順
clouds.yaml
ファイルを作成します。RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに
clouds.yaml
ファイルを生成します。重要パスワードを必ず
auth
フィールドに追加してください。シークレットは、clouds.yaml
の別のファイルに保持できます。RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。
clouds.yaml
についての詳細は、RHOSP ドキュメントの「Config files」を参照してください。clouds: shiftstack: auth: auth_url: http://10.10.14.42:5000/v3 project_name: shiftstack username: shiftstack_user password: XXX user_domain_name: Default project_domain_name: Default dev-env: region_name: RegionOne auth: username: 'devuser' password: XXX project_name: 'devonly' auth_url: 'https://10.10.14.22:5001/v2.0'
生成するファイルを以下のいずれかの場所に置きます。
-
OS_CLIENT_CONFIG_FILE
環境変数の値 - 現行ディレクトリー
-
Unix 固有のユーザー設定ディレクトリー (例:
~/.config/openstack/clouds.yaml
) Unix 固有のサイト設定ディレクトリー (例:
/etc/openstack/clouds.yaml
)インストールプログラムはこの順序で
clouds.yaml
を検索します。
-
1.2.8. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。
前提条件
- Linux または macOS を使用するコンピューターからクラスターをインストールする必要があります。
- インストールプログラムをダウンロードするには、500 MB のローカルディスク領域が必要です。
手順
- Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターインストールの完了後は、インストールプログラムおよびインストールプログラムが作成するファイルの両方を保持する必要があります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。特定のクラウドプロバイダー用に記載された OpenShift Container Platform のアンインストール手順を完了して、クラスターを完全に削除する必要があります。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar xvf <installation_program>.tar.gz
-
Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから、インストールプルシークレットを
.txt
ファイルとしてダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.2.9. インストール設定ファイルの作成
Red Hat OpenStack Platform (RHOSP) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
install-config.yaml
ファイルを作成します。以下のコマンドを実行します。
$ ./openshift-install create install-config --dir=<installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして openstack を選択します。
- クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
- OpenShift API への外部アクセスに使用する Floating IP アドレスを指定します。
- コントロールプレーンおよびコンピュートノードに使用する 16 GB 以上の RAM で RHOSP フレーバーを指定します。
- クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
- クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
- Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから取得したプルシークレットを貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細については、「インストール設定パラメーター」セクションを参照してください。 install-config.yaml
ファイルをバックアップし、これを複数のクラスターをインストールするために使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
1.2.10. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、install-config.yaml
ファイルでこれらのパラメーターを変更することはできません。
パラメーター | 説明 | 値 |
---|---|---|
|
クラウドプロバイダーのベースドメイン。この値は、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
コントロールプレーンマシンをホストするためのクラウドプロバイダー。このパラメーターの値は |
|
|
ワーカーマシンをホストするためのクラウドプロバイダー。このパラメーターの値は |
|
| クラスターの名前。 |
|
| クラスターをデプロイするリージョン。 |
AWS の |
| Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する、Quay.io などの組み込まれた各種の認証局によって提供されるサービスで認証できます。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } } |
パラメーター | 説明 | 値 |
---|---|---|
| クラスターマシンにアクセスするために使用する SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
|
| FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。 |
|
| クラスターのユーザーに表示されるエンドポイントを公開する方法。 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
| プロビジョニングするコンピュートマシン(ワーカーマシンとしても知られる)の数。 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
| プロビジョニングするコントロールプレーンマシンの数。 |
|
パラメーター | 説明 | 値 |
---|---|---|
| コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。 |
整数 (例: |
| コンピュートマシンの場合、root のボリュームタイプです。 |
文字列 (例: |
| コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。 |
整数 (例: |
| コントロールプレーンマシンの場合、root ボリュームのタイプです。 |
文字列 (例: |
| RHOSP クラスターが作成されるリージョン。 |
文字列 (例: |
|
|
文字列 (例: |
| インストールに使用される RHOSP の外部ネットワーク名。 |
文字列 (例: |
| コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。 |
文字列 (例: |
| ロードバランサー API に関連付ける既存の Floating IP アドレス。 |
IP アドレス (例: |
パラメーター | 説明 | 値 |
---|---|---|
| クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。 |
IP アドレスの一覧 (文字列)。例: |
| デフォルトのマシンプールプラットフォームの設定。 |
{ "type": "ml.large", "rootVolume": { "size": 30, "type": "performance" } } |
| インストーラーが RHCOS イメージをダウンロードする場所。 ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。 | HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。
例:
この値は、既存の Glance イメージの名前にもなり得ます (例: |
1.2.10.1. Kuryr を使用した OpenStack のカスタマイズされた install-config.yaml
ファイルのサンプル
デフォルトの OpenShift SDN ではなく Kuryr SDN を使用してデプロイするには、install-config.yaml
ファイルを変更して Kuryr
を必要な networking.networkType
として追加してから、デフォルトの OpenShift SDN インストール手順に進む必要があります。このサンプル install-config.yaml
は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。
このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得する必要があります。
apiVersion: v1 baseDomain: example.com clusterID: os-test controlPlane: name: master platform: {} replicas: 3 compute: - name: worker platform: openstack: type: ml.large replicas: 3 metadata: name: example networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineCIDR: 10.0.0.0/16 serviceNetwork: - 172.30.0.0/16 networkType: Kuryr platform: openstack: region: region1 cloud: mycloud externalNetwork: external computeFlavor: m1.xlarge lbFloatingIP: 128.0.0.1 trunkSupport: true octaviaSupport: true pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
trunkSupport
と octaviaSupport
の両方はインストーラーによって自動的に検出されるため、それらを設定する必要はありません。ただし、ご使用の環境がこれらの両方の要件を満たさないと、Kuryr SDN は適切に機能しません。トランクは Pod を RHOSP ネットワークに接続するために必要であり、Octavia は OpenShift サービスを作成するために必要です。
1.2.11. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent
とインストールプログラムの両方に SSH キーを指定する必要があります。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core
としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core
ユーザーの ~/.ssh/authorized_keys
一覧に追加されます。
AWS キーペアなどのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t rsa -b 4096 -N '' \ -f <path>/<file_name> 1
- 1
~/.ssh/id_rsa
などの、SSH キーのパスおよびファイル名を指定します。既存の SSH キーは上書きされるため、指定しないでください。
このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。
ssh-agent
プロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)" Agent pid 31874
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1 Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
- 1
~/.ssh/id_rsa
などの、SSH プライベートキーのパスおよびファイル名を指定します。
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
1.2.12. 環境へのアクセスの有効化
デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。
OpenShift Container Platform API を、Floating IP アドレスを使用/不使用でアクセス可能になるように設定できます。
1.2.12.1. Floating IP アドレスを使ったアクセスの有効化
OpenShift Container Platform API エンドポイントに 2 つのエンドポイントを割り当てることにより、これらのエンドポイントをアクセス可能にします。その内の 1 つは API ロードバランサー用で (lb FIP
)、もう 1 つは OpenShift Container Platform アプリケーション用 (apps FIP
) になります。
ロードバランサー FIP も install-config.yaml
ファイルで使用されます。
手順
Red Hat OpenStack Platform (RHOSP) CLI を使用して、新しい外部ネットワークを作成します。
$ openstack floating ip create <external network>
このパターンに準拠するレコードを DNS サーバーに追加します。
api.<cluster name>.<base domain> IN A <lb FIP>
注記DNS サーバーを制御しない場合は、代わりに
/etc/hosts
ファイルにレコードを追加します。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。
Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。
1.2.12.2. Floating IP アドレスを使用しないアクセスの有効化
Floating IP アドレスを使用できない場合でも、OpenShift Container Platform のインストールは終了できる可能性があります。ただし、インストールプラグラムは API アクセスを待機してタイムアウトする場合は失敗します。
インストールプログラムがタイムアウトすると、クラスターは初期化される可能性があります。ブートストラップ処理が開始されたら、これを完了する必要があります。ただし、デプロイ後にクラスターのネットワーク設定を編集する必要があります。
1.2.13. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
インストールプログラムを実行します。
$ ./openshift-install create cluster --dir=<installation_directory> \ 1 --log-level=info 2
注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。重要インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。最初の証明書のローテーションが正常に実行されるようにするには、クラスターを動作が低下していない状態で 24 時間実行し続ける必要があります。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
1.2.14. クラスターステータスの確認
インストール時またはインストール後に OpenShift Container Platform クラスターのステータスを確認するには、以下を実行します。
手順
クラスター環境で、管理者の kubeconfig ファイルをエクスポートします。
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。デプロイメント後に作成されたコントロールプレーンおよびコンピュートマシンを表示します。
$ oc get nodes
クラスターのバージョンを表示します。
$ oc get clusterversion
Operator のステータスを表示します。
$ oc get clusteroperator
クラスター内のすべての実行中の Pod を表示します。
$ oc get pods -A
1.2.15. クラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイします。
-
oc
CLI をインストールします。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami system:admin
1.2.16. Floating IP アドレスを使用したアプリケーションアクセスの設定
OpenShift Container Platform をインストールした後に、アプリケーションネットワークトラフィックを許可するように Red Hat OpenStack Platform (RHOSP) を設定します。
前提条件
- OpenShift Container Platform クラスターがインストールされている必要があります。
- 「環境へのアクセスの有効化」で説明されているように、Floating IP アドレスが有効化されています。
手順
OpenShift Container Platform クラスターをインストールした後に、Floating IP アドレスを Ingress ポートに割り当てます。
ポートを表示します。
$ openstack port show <cluster name>-<clusterID>-ingress-port
ポートを IP アドレスに接続します。
$ openstack floating ip set --port <ingress port ID> <apps FIP>
*apps.
のワイルドカードA
レコードを DNS ファイルに追加します。*.apps.<cluster name>.<base domain> IN A <apps FIP>
DNS サーバーを制御せず、非実稼働環境でアプリケーションアクセスを有効にする必要がある場合は、これらのホスト名を /etc/hosts
に追加できます。
<apps FIP> console-openshift-console.apps.<cluster name>.<base domain> <apps FIP> integrated-oauth-server-openshift-authentication.apps.<cluster name>.<base domain> <apps FIP> oauth-openshift.apps.<cluster name>.<base domain> <apps FIP> prometheus-k8s-openshift-monitoring.apps.<cluster name>.<base domain> <apps FIP> grafana-openshift-monitoring.apps.<cluster name>.<base domain> <apps FIP> <app name>.apps.<cluster name>.<base domain>
1.2.17. 次のステップ
- クラスターをカスタマイズします。
- 必要な場合は、リモートの健全性レポートをオプトアウトすることができます。
- ノードポートへの外部アクセスを有効にする必要がある場合は、NodePort を使用して Ingress クラスタートラフィックを設定 します。
1.3. OpenStack でのクラスターのアンインストール
Red Hat OpenStack Platform (RHOSP) にデプロイしたクラスターを削除できます。
1.3.1. インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの削除
インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターは、クラウドから削除できます。
前提条件
- クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
- クラスター作成時にインストールプログラムが生成したファイルがあります。
手順
クラスターをインストールするために使用したコンピューターから、以下のコマンドを実行します。
$ ./openshift-install destroy cluster \ --dir=<installation_directory> --log-level=info 1 2
注記クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある
metadata.json
ファイルが必要になります。-
オプション:
<installation_directory>
ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。