19.4. Kuryr を使用する OpenStack へのクラスターのインストール

手順

1. ローカルレジストリーを使用している場合、イメージをレジストリーにアップロードするためのテンプレートを作成します。以下に例を示します。

   (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}-{product-version} \
   --output-env-file=/home/stack/templates/overcloud_images.yaml \
   --output-images-file /home/stack/local_registry_images.yaml

2. 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 リリースによって異なります。

3. コンテナーイメージを registry.redhat.io からアンダークラウドノードにプルします。

   (undercloud) $ sudo openstack overcloud container image upload \
     --config-file  /home/stack/local_registry_images.yaml \
     --verbose

   これには、ネットワークおよびアンダークラウドディスクの速度に応じて多少の時間がかかる可能性があります。

4. 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 の場合には変更の必要がありません。

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

   • Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
   • ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
   重要

   API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。

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

   表19.5 API ロードバランサー

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

   注記

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

2. Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。

   以下の条件を設定します。

   • Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
   • 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
   ヒント

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

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

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

   ポート	バックエンドマシン (プールメンバー)	内部	外部	説明
   443	デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。	X	X	HTTPS トラフィック
   80	デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。	X	X	HTTP トラフィック

   注記

   ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。

手順

1. 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-----
   additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5

   1

   クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。

   2

   クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。

   3

   プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。

   4

   指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。

   5

   オプション： trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。

   注記

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

   注記

   インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

   $ ./openshift-install wait-for install-complete --log-level debug

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

手順

1. コマンドラインからマニフェストファイルを作成します。

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

   1

   <installation_directory> については、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。

2. cluster-network-03-config.yml という名前のファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

   $ touch <installation_directory>/manifests/cluster-network-03-config.yml 1

   1

   <installation_directory> については、クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。

   ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが manifests/ ディレクトリーに置かれます。

   $ ls <installation_directory>/manifests/cluster-network-*

   出力例

   cluster-network-01-crd.yml
   cluster-network-02-config.yml
   cluster-network-03-config.yml

3. エディターで cluster-network-03-config.yml ファイルを開き、必要な Cluster Network Operator 設定を記述するカスタムリソース (CR) を入力します。

   $ oc edit networks.operator.openshift.io cluster

4. 要件に合わせて設定を編集します。以下のファイルをサンプルとして紹介しています。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     clusterNetwork:
     - cidr: 10.128.0.0/14
       hostPrefix: 23
     serviceNetwork:
     - 172.30.0.0/16
     defaultNetwork:
       type: Kuryr
       kuryrConfig:
         enablePortPoolsPrepopulation: false 1
         poolMinPorts: 1 2
         poolBatchPorts: 3 3
         poolMaxPorts: 5 4
         openstackServiceNetwork: 172.30.0.0/15 5

   1

   enablePortPoolsPrepopulation を true に設定すると、Pod のネットワーク上の最初の Pod が namespace に作成されたときに、Kuryr が新しい Neutron ポートを作成するようになります。この設定により、Neutron ポートのクォータが引き上げられますが、Pod の起動に必要となる時間を短縮できます。デフォルト値は false です。

   2

   Kuryr は、対象のプール内にある空きポートの数が poolMinPorts の値よりも少ない場合には、プールに新規ポートを作成します。デフォルト値は 1 です。

   3

   poolBatchPorts は、空きポートの数が poolMinPorts の値よりも少ない場合に作成される新規ポートの数を制御します。デフォルト値は 3 です。

   4

   プール内の空きポートの数が poolMaxPorts の値よりも多い場合に、Kuryr はその値と同じ数になるまでポートを削除します。この値を 0 に設定すると、この上限は無効になり、プールが縮小できないようにします。デフォルト値は 0 です。

   5

   openStackServiceNetwork パラメーターは、RHOSP Octavia の LoadBalancer に割り当てられるネットワークの CIDR 範囲を定義します。

   このパラメーターを Amphora ドライバーと併用する場合には、Octavia は、ロードバランサーごとに、このネットワークから IP アドレスを 2 つ (OpenShift 用に 1 つ、VRRP 接続用に 1 つ) 取得します。これらの IP アドレスは OpenShift Container Platform と Neutron でそれぞれ管理されるため、異なるプールから取得する必要があります。したがって、openStackServiceNetwork serviceNetwork の値の 2 倍になる必要があり、serviceNetwork の値は、openStackServiceNetwork で定義された範囲と完全に重複する必要があります。

   CNO は、このパラメーターの定義範囲から取得した VRRP IP アドレスが serviceNetwork パラメーターの定義範囲と重複しないことを検証します。

   このパラメーターが設定されていない場合には、CNO は serviceNetwork の拡張値を使用します。この値は、プリフィックスのサイズを 1 つずつ減らして決定します。

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

手順

1. Red Hat OpenStack Platform (RHOSP) CLI を使用して、API FIP を作成します。

   $ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>

2. Red Hat OpenStack Platform (RHOSP) CLI を使用して、apps (アプリ)、または Ingress、FIP を作成します。

   $ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>

3. API および Ingress FIP の DNS サーバーに、これらのパターンに準拠するレコードを追加します。

   api.<cluster_name>.<base_domain>.  IN  A  <API_FIP>
   *.apps.<cluster_name>.<base_domain>. IN  A <apps_FIP>

   注記

   DNS サーバーを制御していない場合は、次のようなクラスタードメイン名を /etc/hosts ファイルに追加することで、クラスターにアクセスできます。

   • <api_floating_ip> api.<cluster_name>.<base_domain>
   • <application_floating_ip> grafana-openshift-monitoring.apps.<cluster_name>.<base_domain>
   • <application_floating_ip> prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<base_domain>
   • <application_floating_ip> oauth-openshift.apps.<cluster_name>.<base_domain>
   • <application_floating_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
   • application_floating_ip integrated-oauth-server-openshift-authentication.apps.<cluster_name>.<base_domain>

   /etc/hosts ファイル内のクラスタードメイン名により、クラスターの Web コンソールおよび監視インターフェイスへのローカルアクセスが許可されます。kubectl または oc を使用することもできます。<application_floating_ip> を指す追加のエントリーを使用して、ユーザーアプリケーションにアクセスできます。このアクションにより、API およびアプリケーションは他のユーザーがアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。

4. FIP を、以下のパラメーターの値として install-config.yaml ファイルに追加します。

   • platform.openstack.ingressFloatingIP
   • platform.openstack.apiFloatingIP