Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第4章 インベントリーファイルの設定
4.1. クラスターのインベントリーファイルのカスタマイズ
Ansible インベントリーファイルはクラスター内のホストについての詳細や OpenShift Container Platform インストールのクラスター設定の詳細を記述します。OpenShift Container Platform インストール Playbook は、ホストのセットに OpenShigt Container Platform をインストールする方法を判別するためにインベントリーファイルを読み取ります。
インベントリーファイルの形式についての詳細 (YAML 構文の基本事項を含む) については、Ansible ドキュメントを参照してください。
「ホストの準備」で説明されているように openshift-ansible RPM パッケージをインストールする場合、Ansible の依存関係は /etc/ansible/hosts のデフォルトの場所でファイルを作成します。ただし、ファイルは単純にデフォルトの Ansible のサンプルであり、OpenShift Container Platform 設定にとくに関連している変数はありません。OpenShift Container Platform を適切にインストールするには、ファイルのデフォルトの内容を、クラスターのトポロジーおよび要件に基づいて独自の設定に置き換える 必要があります。
以下のセクションでは、クラスターのインストール時にインベントリーファイルに設定するために一般的に使用される変数について説明します。説明されている Ansible 変数の多くはオプションの変数です。開発環境の場合は、必要な変数のデフォルト値を受け入れるだけで十分ですが、実稼働環境では、利用可能な各種のオプションを理解しておくことをお勧めします。
まず、いくつかの例のインベントリーファイルのサンプルを確認し、クラスターインストールの開始時に使用します。
イメージには更新を維持するためにバージョン番号ポリシーが必要です。詳細は『Architecture Guide』の「Image Version Tag Policy」のセクションを参照してください。
4.2. クラスター変数の設定
Ansible インストールの実行時に OpenShift Container Platform クラスター全体にグローバルに適用される環境変数を割り当てるには、必要な変数を /etc/ansible/hosts ファイルの [OSEv3:vars] セクションにそれぞれ単一行で指定します。以下は例になります。
[OSEv3:vars]
openshift_master_identity_providers=[{'name': 'htpasswd_auth',
'login': 'true', 'challenge': 'true',
'kind': 'HTPasswdPasswordIdentityProvider',}]
openshift_master_default_subdomain=apps.test.example.com
Ansible インベントリーファイルのパラメーター値に、#, { or } などの特殊文字が含まれている場合、値をダブルエスケープ (double-escape) する必要があります (値を単一と二重引用符で囲みます)。たとえば、mypasswordwith###hashsigns を変数 openshift_cloudprovider_openstack_password の値として使用し、これを Ansible ホストインベントリーファイルで openshift_cloudprovider_openstack_password='"mypasswordwith###hashsigns"' として宣言します。
以下の表は、クラスター全体に割り当てることのできる Ansible インストーラーで使用される変数について説明しています。
表4.1 一般的なクラスター変数
| 変数 | 目的 |
|---|---|
|
|
この変数はインストーラーで使用する SSH ユーザーを設定します。デフォルトは |
|
|
|
|
|
この変数は、 ログを
デバッグログのレベルについての詳細は、「ロギングレベルの設定」を参照してください。 |
|
|
クラスターノードでネットワークタイムプロトコル (NTP) を有効にするかどうか。デフォルトは 重要 クラスター内のマスターおよびノードが同期されなくなる状態を防ぐには、このパラメーターのデフォルト値を変更しないでください。 |
|
|
この変数は、インベントリーホストファイルの要件に基づいてパラメーターと任意の JSON 値を設定します。以下は例になります。 openshift_master_admission_plugin_config={"ClusterResourceOverride":{"configuration":{"apiVersion":"v1","kind":"ClusterResourceOverrideConfig","memoryRequestToLimitPercent":"25","cpuRequestToLimitPercent":"25","limitCPUToMemoryPercent":"200"}}}
|
|
|
この変数は API サービスの監査を有効にします。詳細は、「監査の設定」を参照してください。 |
|
|
この変数はクラスターのホスト名を上書きします。デフォルトはマスターのホスト名です。 |
|
|
この変数はクラスターのパブリックホスト名を上書きします。デフォルトはマスターのホスト名です。外部ロードバランサーを使用する場合は、外部ロードバランサーのアドレスを指定します。 例: openshift_master_cluster_public_hostname=openshift-ansible.public.example.com |
|
|
オプションです。この変数は複数マスターのデプロイ時の HA メソッドを定義します。 |
|
|
この変数は、アップグレード Playbook を直接実行する際に HA マスターのローリング再起動 (例: マスターは一度に 1 つずつ停止します) を有効にします。これはデフォルトで |
|
|
この変数は アイデンティティープロバイダーを設定します。デフォルト値は Deny Allです。サポートされているアイデンティティープロバイダーを使用する場合は OpenShift Container Platform がそれを使用するよう設定します。 |
|
|
これらの変数は、インストールの一部としてデプロイされるカスタム証明書を設定するために使用されます。詳細は、「カスタム証明書の設定」を参照してください。 |
|
| |
|
|
ホストされているルーターのカスタム証明書の場所を指定します。 |
|
|
自動生成されるレジストリー証明書の有効日数。デフォルトで |
|
|
自動生成される CA 証明書の有効日数。デフォルトで |
|
|
自動生成されるノード証明書の有効日数。デフォルトで |
|
|
自動生成されるマスター証明書の有効日数。デフォルトで |
|
|
自動生成される外部 etcd 証明書の有効日数。etcd CA、ピア、サーバー、クライアント証明書の有効性を管理します。デフォルトで |
|
|
|
|
|
これらの変数は OAuth 設定のセッションオプションのデフォルトを上書きします。詳細は「 セッションオプションの設定」を参照してください。 |
|
| |
|
| |
|
| |
|
|
マスター設定で |
|
|
ルーター Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は「ノードホストラベルの設定」を参照してください。 |
|
|
レジストリー Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は、「ノードホストラベルの設定」を参照してください。 |
|
|
この変数は、ブローカーが提供するテンプレートの 1 つ以上の namespace を指定することでテンプレートサービスブローカーを有効にします。 |
|
|
テンプレートサービスブローカー Pod を自動的にデプロイするためのデフォルトのノードセレクター。デフォルトで |
|
|
この変数は、Pod を配置する際にプロジェクトがデフォルトで使用するノードセレクターを上書きします。デフォルトのセレクターはマスター設定ファイルの |
|
|
OpenShift Container Platform は指定された追加レジストリーを docker 設定に追加します。これらは検索対象のレジストリーです。このレジストリーへのアクセスに必要なレジストリーが 例: openshift_docker_additional_registries=example.com:443 注記
クラスターを別のレジストリーを使用するように設定する必要がある場合は、 |
|
|
OpenShift Container Platform は指定された追加の非セキュアなレジストリーを docker 設定に追加します。それらのレジストリーの SSL (Secure Sockets Layer) は検証されません。ホスト名またはホストの IP アドレスに設定できます。 |
|
|
OpenShift Container Platform は指定されたブロック済みレジストリーを docker 設定に追加します。これは一覧表示されるレジストリーをブロックします。これを |
|
|
この変数は、マスター設定でクラスターメトリクスの |
|
|
この変数は AWS アベイラビリティーゾーン固有のクラスター識別子です。これを使用することで、複数のゾーンまたは複数のクラスターを持つ Amazon Web Service (AWS) での潜在的な問題を回避することができます。詳細は「AWS のクラスターへのラベル付け」を参照してください。 |
|
|
この変数を使用して、インストールまたは設定するコンテナーイメージタグを指定します。 |
|
|
この変数を使用して、インストールまたは設定する RPM バージョンを指定します。 |
クラスターのセットアップ後に openshift_image_tag または openshift_pkg_version 変数を変更する場合はアップグレードがトリガーされ、ダウンタイムが発生します。
-
openshift_image_tagが設定されている場合、この値は別のバージョンがインストールされている場合でもシステムコンテナー環境のすべてのホストに使用されます。 -
openshift_pkg_versionが設定されている場合、この値は別のバージョンがインストールされている場合でも RPM ベースの環境のすべてのホストに使用されます。
表4.2 ネットワーク変数
| 変数 | 目的 |
|---|---|
|
|
この変数は、公開されるルートに使用するデフォルトのサブドメインを上書きします。 |
|
|
この変数は、どの OpenShift SDN プラグインを Pod ネットワークに使用するかを設定します。デフォルトでは標準 SDN プラグインの |
|
|
この変数は SDN クラスターネットワーク CIDR ブロックを上書きします。これは、Pod IP の割り当て元のネットワークです。このネットワークブロックは非公開ブロックとし、Pod、ノード、またはマスターがアクセスする必要のある可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。デフォルトは |
|
|
この変数は、サービスを OpenShift Container Platform SDN 内で作成する際のサブネットを設定します。このネットワークブロックは非公開とし、Pod、ノード、またはマスターがアクセスする必要の可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。そうでない場合、インストールは失敗します。デフォルトは |
|
|
この変数は、OpenShift Container Platform SDN により Pod IP のホストサブネットごとに割り当てられるサイズを指定します。デフォルトは |
|
|
この変数は、使用するサービスプロキシーモードを指定します。 |
|
|
この変数は、デフォルトの SDN の代わりに flannel を代替ネットワーキングレイヤーとして有効にします。flannel を有効にする場合は、 |
|
|
OpenShift SDN プラグインを無効にするには、 |
4.3. デプロイメントタイプの設定
Playbook 全体で使用される各種デフォルト値とインストーラーによって使用されるロールは、デプロイメントタイプの設定 (通常は Ansible インベントリーファイルで定義されます) に基づいて決定されます。
OpenShift Container Platform バリアントをインストールするには、インベントリーファイルの [OSEv3:vars] セクションにある openshift_deployment_type パラメーターが openshift-enterprise に設定されていることを確認してください。
[OSEv3:vars] openshift_deployment_type=openshift-enterprise
4.4. ホスト変数の設定
Ansible のインストール時に環境変数をホストに割り当てるには、[masters] セクションまたは [nodes] セクションにホストを入力した後に /etc/ansible/hosts ファイルで必要な変数を指定します。以下は例を示しています。
[masters] ec2-52-6-179-239.compute-1.amazonaws.com openshift_public_hostname=ose3-master.public.example.com
以下の表は、Ansible インストーラーで使用され、個々のホストエントリーに割り当てることができる変数を示しています。
表4.3 ホスト変数
| 変数 | 目的 |
|---|---|
|
|
この変数は、システムのパブリックホスト名を上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。 |
|
|
この変数は、システムのパブリック IP アドレスを上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。 |
|
|
この変数は非推奨になっています。現在のノードラベルの設定方法については、「ノードグループおよびホストマッピングの定義」を参照してください。 |
|
|
この変数は、ノードに |
|
|
この変数は、/etc/sysconfig/docker 内に追加の
次に、Docker が "--log-driver json-file --log-opt max-size=1M --log-opt max-file=3" |
|
|
この変数は、ホストがスケジュール可能ノードとしてマークされているかどうか、つまり、新しい Pod を配置できるかどうかを設定します。マスターでのスケジュール可能性の設定を参照してください。 |
|
|
この変数は、Node Problem Detector をアクティブにするために使用されます。 |
4.5. ノードグループおよびホストマッピングの定義
OpenShift Container Platform 3.10 以降では、ノードの設定はマスターからブートストラップされるようになりました。ノードおよびサービスが起動されると、ノードは、kubeconfig および他のノード設定ファイルが存在するかどうかをクラスターに参加する前に確認します。存在しない場合には、ノードはマスターから設定をプルしてから、クラスターに参加します。
このプロセスが導入されることにより、管理者はノードホストごとに一意のノード設定を手動でメンテナンスする必要がなくなり、ノードホストの /etc/origin/node/node-config.yaml ファイルの内容がマスターから取得される ConfigMaps で提供されるようになりました。
4.5.1. ノードの ConfigMap
ノード設定の定義用の ConfigMap は openshift-node プロジェクトで利用できる状態でなければなりません。ConfigMap はノードラベルの信頼できる定義となり、以前の openshift_node_labels の値は事実上、無視されます。
デフォルトで、クラスターのインストール時にインストーラーは以下のデフォルト ConfigMap を作成します。
-
node-config-master -
node-config-infra -
node-config-compute
以下の ConfigMap も作成され、複数のロールにノードをラベル付けします。
-
node-config-all-in-one -
node-config-master-infra
ノードホストの /etc/origin/node/node-config.yaml ファイルには変更を加えないようにしてください。このファイルは、ノードが使用する ConfigMap に定義されている設定により上書きされます。
4.5.2. ノードグループの定義
最新の openshift-ansible パッケージのインストール後に、ノードグループ定義のデフォルトセットを /usr/share/ansible/openshift-ansible/roles/openshift_facts/defaults/main.yml ファイル内で YAML 形式で確認することができます。
openshift_node_groups: - name: node-config-master 1 labels: - 'node-role.kubernetes.io/master=true' 2 edits: [] 3 - name: node-config-infra labels: - 'node-role.kubernetes.io/infra=true' edits: [] - name: node-config-compute labels: - 'node-role.kubernetes.io/compute=true' edits: [] - name: node-config-master-infra labels: - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true' edits: [] - name: node-config-all-in-one labels: - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true,node-role.kubernetes.io/compute=true' edits: []
インベントリーファイルの [OSEv3:vars] グループに openshift_node_groups 変数が設定されていない場合には、上記で定義したデフォルト値が使用されます。ただし、これらのデフォルト値とは違う値を使用する場合には、インベントリーファイルに (任意の全ノードグループなどを含む) openshift_node_groups の構造全体を定義する必要があります。
openshift_node_groups の値はデフォルト値とマージされないので、YAML 定義を先に Python ディクショナリーに変換する必要があります。その後に、edits フィールドを使用して、キーと値のペアを指定して任意のノード設定変数に変更できます。
設定可能なノード変数に関する情報は、「Master and Node Configuration Files」を参照してください。
たとえば、インベントリーファイルの以下のエントリーは、node-config-master、node-config-infra および node-config-compute という名前のグループを定義します。
openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true']}]インベントリーファイルにエントリーを設定する場合、ノードグループの ConfigMap も設定できます。
-
node-config-computeをkubeletArguments.pods-per-coreを20に設定するために変更するなど、一覧を使用できます。
openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.pods-per-core','value': ['20']}]}]-
node-config-computeグループをkubeletに 2 つのパラメーターを追加するために変更するなど、複数のキーと値のペアを変更するために一覧を使用できます。
openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.experimental-allocatable-ignore-eviction','value': ['true']}, {'key': 'kubeletArguments.eviction-hard', 'value': ['memory.available<1Ki']}]}]-
node-config-computeグループをperFSGroupを512Miに設定するために変更するなど、ディクショナリーを値として使用することができます。
openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'volumeConfig.localQuota','value': {'perFSGroup':'512Mi'}}]}]
openshift_node_group.yml Playbook が実行されるたびに、edits フォールドで定義した変更により、関連の ConfigMap (この例では node-config-compute) が更新され、最終的にホスト上のノードの設定ファイルに影響を与えます。
4.5.3. ホストとノードグループのマッピング
どのノードホストにどの ConfigMap を使用するかについてのマッピングでは、インベントリーの [nodes] グループで定義されるすべてのホストが openshift_node_group_name 変数を使用して node group に割り当てられる必要があります。
ホストごとに openshift_node_group_name をノードグループに設定することは、デフォルトのノードグループ定義および ConfigMap を使用しているか、または独自の設定をカスタマイズしているかにかかわらず、すべてのクラスターインストールで必要です。
openshift_node_group_name の値は、各ノードを設定する ConfigMap を選択するために使用されます。以下は例になります。
[nodes] master[1:3].example.com openshift_node_group_name='node-config-master' infra-node1.example.com openshift_node_group_name='node-config-infra' infra-node2.example.com openshift_node_group_name='node-config-infra' node1.example.com openshift_node_group_name='node-config-compute' node2.example.com openshift_node_group_name='node-config-compute'
4.5.4. ノードホストラベル
ラベル は、クラスターインストール時にノードホストに割り当てることができます。これは、スケジューラー を使用して Pod のノードへの配置を判別するのに役立ちます。以前はノードラベルは openshift_node_labels 変数を使用して設定できましたが、OpenShift Container Platform 3.10 より、ノードホストに割り当てられたデフォルトラベルを変更する必要がある場合には、独自のカスタムノードホストを作成する必要があります。デフォルトノードグループの変更方法についての詳細は、「ノードグループ定義」を参照してください。
node-role.kubernetes.io/infra=true (このグループを使用するホストは 専用インフラストラクチャーノード とも呼ばれ、さらに「専用インフラストラクチャーノードの設定」で説明されています) 以外には、実際のラベル名および値は任意であり、クラスターの要件に基づいて適切とみなされる方法で割り当てることができます。
4.5.4.1. マスターでの Pod スケジュール可能性の設定
インストールプロセス時にマスターとして指定するすべてのホストは、マスターが OpenShift SDN の一部として設定されるようにノードとして設定される必要もあります。これらのホストのエントリーを [nodes] セクションに追加してこの設定を行う必要があります。
[nodes] master[1:3].example.com openshift_node_group_name='node-config-master'
インストール後にホストのスケジュール可能性を変更したい場合は、「ノードをスケジュール対象外 (Unschedulable) またはスケジュール対象 (Schedulable) としてマークする」を参照してください。
4.5.4.2. ノードでの Pod スケジュール可能性の設定
マスターはデフォルトでスケジュール対象ノードとしてマークされるため、デフォルトノードセレクターは、クラスターのインストール時にデフォルトで設定されます。デフォルトノードセレクターは、Pod を配置する際にデフォルトでプロジェクトが使用するノードを判別するためにマスター設定ファイルの projectConfig.defaultNodeSelector フィールドに定義されます。これは、osm_default_node_selector 変数を使用して上書きされない限り、node-role.kubernetes.io/compute=true に設定されます。
インストール時にデフォルトノードセレクターのnode-role.kubernetes.io/compute=true を受け入れる場合、クラスターで非マスターノードとして定義されているのが専用インフラストラクチャーノードだけでないことを確認してください。この場合、プロジェクトに対する Pod のスケジューリングの際にデフォルトノードセレクターに一致するnode-role.kubernetes.io/compute=true ラベル付きのノードが存在しないため、アプリケーション Pod はデプロイに失敗します。
インストール後に必要に応じてこの設定を調整する手順については、「クラスター全体でのデフォルトノードセレクターの設定」を参照してください。
4.5.4.3. 専用インフラストラクチャーノードの設定
実稼働環境では、レジストリー Pod とルーター Pod をユーザーアプリケーション用の Pod とは別に実行できる専用インフラストラクチャーノードを保持することを推奨します。
openshift_router_selector および openshift_registry_selector Ansible 設定は、レジストリー Pod とルーター Pod を配置する際に使用されるラベルセレクターを決定します。これらはデフォルトで node-role.kubernetes.io/infra=true に設定されます。
# default selectors for router and registry services # openshift_router_selector='node-role.kubernetes.io/infra=true' # openshift_registry_selector='node-role.kubernetes.io/infra=true'
レジストリーとルーターは、node-role.kubernetes.io/infra=true ラベルが付いた、専用インフラストラクチャーノードと見なされるノードホスト上でのみ実行できます。お使いの OpenShift Container Platform 環境に、node-role.kubernetes.io/infra=true ラベルが付いたノードホストが 1 つ以上存在することを確認してください。デフォルトの node-config-infra を使用してこのラベルを設定できます。
[nodes] infra-node1.example.com openshift_node_group_name='node-config-infra'
セレクター設定に一致するノードが [nodes] セクションにない場合、デフォルトのルーターとレジストリーはデプロイに失敗し、Pendingステータスになります。
レジストリーとルーターの管理に OpenShift Container Platform を使用しない場合は、以下のように Ansible 設定を行います。
openshift_hosted_manage_registry=false openshift_hosted_manage_router=false
デフォルトの registry.access.redhat.com 以外のイメージレジストリーを使用する場合は、/etc/ansible/hosts ファイルで 必要なレジストリーを指定する必要があります。
マスターでのスケジュール可能性の設定で説明されているように、マスターホストはデフォルトでスケジュール可能としてマークされます。マスターホストに node-role.kubernetes.io/infra=true ラベルを付けており、他に専用インフラストラクチャーノードがない場合、マスターホストはスケジュール対象としてマークされる必要もあります。そうでない場合には、レジストリーとルーター Pod をどこにも配置することができなくなります。
これを実行するには、デフォルトの node-config-master-infra ノードグループを使用できます。
[nodes] master.example.com openshift_node_group_name='node-config-master-infra'
4.6. マスター API ポートの設定
マスター API で使用するデフォルトのポートを設定するには、/etc/ansible/hosts ファイルに以下の変数を設定します。
表4.4 マスター API ポート
| 変数 | 目的 |
|---|---|
|
|
この変数は、OpenShift Container Platform API へのアクセスに使用するポート番号を設定します。 |
例:
openshift_master_api_port=3443
Web コンソールポート設定 (openshift_master_console_port) は、 API サーバーのポート (openshift_master_api_port) に一致している必要があります。
4.7. クラスターのプレインストールチェックの設定
プレインストールチェックは、openshift_health_checker Ansible ロールの一部として実行される診断タスクのセットです。OpenShift Container Platform の Ansible インストールの前に実行され、必要なインベントリー値が設定されていることを確認し、正常なインストールを妨げたり干渉したりする可能性があるホストの潜在的な問題を特定します。
以下の表は、OpenShift Container Platform のすべての Ansible インストールの前に実行される、使用可能なプレインストールチェックを示しています。
表4.5 プレインストールチェック
| チェック名 | 目的 |
|---|---|
|
|
このチェックでは、OpenShift Container Platform の特定のデプロイメントで推奨されるメモリー容量がホストにあることを確認します。デフォルト値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで |
|
|
このチェックは、etcd、マスター、およびノードホストに対してのみ実行され、OpenShift Container Platform インストールのマウントパスに十分なディスク領域が残っていることを確認します。推奨されるディスク値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで |
|
|
docker デーモン (ノードおよびシステムコンテナーのインストール) に依存するホストでのみ実行され、 docker の合計使用率がユーザー定義の上限を超えていないことを確認します。ユーザー定義の上限が設定されていない場合、docker の最大使用率のしきい値はデフォルトで使用可能な合計サイズの 90% になります。合計使用率のしきい値上限は、インベントリーファイルで変数を使用して設定できます。( |
|
|
docker デーモンが OpenShift Containe Platform でサポートされているストレージドライバーを使用していることを確認します。 |
|
|
OpenShift Container Platform インストールで必要なイメージがローカルで、またはホストマシン上の 1 つ以上の設定済みコンテナーイメージレジストリー で使用可能であることの確認を試行します。 |
|
|
|
|
|
OpenShift Container Platform の RPM インストールの前に実行され、現在のインストールに必要な RPM パッケージが利用可能であることを確認します。 |
|
|
|
特定のプレインストールチェックを無効にするには、カンマ区切りのチェック名の一覧を指定した変数 openshift_disable_check をインベントリーファイルに組み込みます。以下は例になります。
openshift_disable_check=memory_availability,disk_availability
既存のクラスターの診断用に実行するための類似のヘルスチェックセットが Ansible ベースのヘルスチェックに用意されています。また、「証明書の再デプロイ」には証明書の有効期限を確認するためのチェックセットもあります。
4.8. レジストリーの場所の設定
registry.access.redhat.com にあるデフォルト以外のイメージレジストリーを使用する場合は、必要なレジストリーを /etc/ansible/hosts ファイル内に指定します。
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true表4.6 レジストリー変数
| 変数 | 目的 |
|---|---|
|
|
別のイメージの場所に設定されます。 |
|
|
デフォルト以外のレジストリーを参照している場合は |
例:
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true4.9. レジストリールートの設定
ユーザーが OpenShift Container Platform クラスターの外部からイメージをプルして内部の Docker レジストリーにプッシュできるように、/etc/ansible/hosts ファイルにレジストリールートを設定します。デフォルトでは、レジストリールートは docker-registry-default.router.default.svc.cluster.local です。
表4.7 レジストリールート変数
| 変数 | 目的 |
|---|---|
|
|
必要なレジストリールートの値に設定します。ルートには、ルーターによって通信が管理されるインフラストラクチャーノードに解決される名前、またはデフォルトのアプリケーションサブドメインのワイルドカード値として設定したサブドメインのいずれかが含まれます。たとえば、 |
|
|
レジストリー証明書へのパスを設定します。証明書の場所の値を指定しない場合、証明書が生成されます。以下の証明書の場所を定義できます。
|
|
|
以下のいずれかの値に設定します。
|
例:
openshift_hosted_registry_routehost=<path>
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routecertificates= "{'certfile': '<path>/org-cert.pem', 'keyfile': '<path>/org-privkey.pem', 'cafile': '<path>/org-chain.pem'}"4.10. レジストリーコンソールの設定
デフォルト以外の Cockpit レジストリーコンソールイメージを使用する場合や、特定のバージョンのコンソールが必要な場合は、以下のように必要なレジストリーを /etc/ansible/hosts ファイル内に指定します。
openshift_cockpit_deployer_prefix=<registry_name>/<namespace>/ openshift_cockpit_deployer_version=<cockpit_image_tag>
表4.8 レジストリー変数
| 変数 | 目的 |
|---|---|
|
|
イメージが置かれるディレクトリーへの URL およびパスを指定します。パスの値は、 |
|
|
Cockpit イメージのバージョンを指定します。 |
例: イメージが registry.example.com/openshift3/registry-console にあり、バージョン 3.10.1 が必要な場合は、以下を入力します。
openshift_cockpit_deployer_prefix='registry.example.com/openshift3/' openshift_cockpit_deployer_version='3.10.1'
4.11. Red Hat Gluster Storage の永続ストレージの設定
Red Hat Gluster Storage は、OpenShift Container Platform の永続ストレージと動的プロビジョニングを提供するように設定でき、OpenShift Container Platform 内のコンテナー化ストレージ (コンバージドモード) としても、独自のノード上の非コンテナー化ストレージ (インデペンデントモード) としても使用できます。
追加情報と以下を含む例については、「Red Hat Gluster Storage を使用する永続ストレージ」を参照してください。
4.11.1. コンバージドモードの設定
具体的なホストの準備と前提条件については、コンバージドモードに関する考慮事項を参照してください。
インベントリーファイルの
[OSEv3:vars]セクションに次の変数を追加し、設定に合わせてそれらを調整します。[OSEv3:vars] ... openshift_storage_glusterfs_namespace=app-storage openshift_storage_glusterfs_storageclass=true openshift_storage_glusterfs_storageclass_default=false openshift_storage_glusterfs_block_deploy=true openshift_storage_glusterfs_block_host_vol_size=100 openshift_storage_glusterfs_block_storageclass=true openshift_storage_glusterfs_block_storageclass_default=false
[OSEv3:children]セクションにglusterfsを追加して、[glusterfs]グループを有効にします。[OSEv3:children] masters nodes glusterfs
GlusterFS ストレージをホストする各ストレージノードのエントリーを含む
[glusterfs]セクションを追加します。ノードごとに、glusterfs_devicesを GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスは、パーティションや LVM PV がないベアでなければなりません。変数は以下の形式で指定します。<hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
例:
[glusterfs] node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
[glusterfs]の下に一覧表示されているホストを[nodes]グループに追加します。[nodes] ... node11.example.com openshift_node_group_name="node-config-compute" node12.example.com openshift_node_group_name="node-config-compute" node13.example.com openshift_node_group_name="node-config-compute"
4.11.2. インデペンデントモードの設定
インベントリーファイルの
[OSEv3:vars]セクションに次の変数を追加し、設定に合わせてそれらを調整します。[OSEv3:vars] ... openshift_storage_glusterfs_namespace=app-storage openshift_storage_glusterfs_storageclass=true openshift_storage_glusterfs_storageclass_default=false openshift_storage_glusterfs_block_deploy=true openshift_storage_glusterfs_block_host_vol_size=100 openshift_storage_glusterfs_block_storageclass=true openshift_storage_glusterfs_block_storageclass_default=false openshift_storage_glusterfs_is_native=false openshift_storage_glusterfs_heketi_is_native=true openshift_storage_glusterfs_heketi_executor=ssh openshift_storage_glusterfs_heketi_ssh_port=22 openshift_storage_glusterfs_heketi_ssh_user=root openshift_storage_glusterfs_heketi_ssh_sudo=false openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"
[OSEv3:children]セクションにglusterfsを追加して、[glusterfs]グループを有効にします。[OSEv3:children] masters nodes glusterfs
GlusterFS ストレージをホストする各ストレージノードのエントリーを含む
[glusterfs]セクションを追加します。ノードごとに、glusterfs_devicesを GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくと も 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。また、glusterfs_ipをノードの IP アドレスに設定します。変数は以下の形式で指定します。<hostname_or_ip> glusterfs_ip=<ip_address> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
例:
[glusterfs] gluster1.example.com glusterfs_ip=192.168.10.11 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' gluster2.example.com glusterfs_ip=192.168.10.12 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' gluster3.example.com glusterfs_ip=192.168.10.13 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
4.12. OpenShift Container レジストリーの設定
統合された OpenShift Container レジストリー は、インストーラーを使用してデプロイできます。
4.12.1. レジストリーストレージの設定
レジストリーストレージのオプションが使用されていない場合、デフォルトの OpenShift Container レジストリーは一時的で、Pod が存在しなくなるとすべてのデータが失われます。
テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。
他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
通常インストーラー (advanced installer) を使用している場合にレジストリーストレージを有効にするには、以下のいくつかのオプションを選択できます。
オプション A: NFS ホストグループ
次の変数が設定されている場合、クラスターインストール時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に NFS ボリュームが作成されます。たとえば、次のオプションを使用した場合、ボリュームパスは /exports/registry になります。
[OSEv3:vars] openshift_hosted_registry_storage_kind=nfs openshift_hosted_registry_storage_access_modes=['ReadWriteMany'] openshift_hosted_registry_storage_nfs_directory=/exports openshift_hosted_registry_storage_nfs_options='*(rw,root_squash)' openshift_hosted_registry_storage_volume_name=registry openshift_hosted_registry_storage_volume_size=10Gi
オプション B: 外部 NFS ホスト
外部の NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。次のオプションを使用した場合、リモートボリュームパスは nfs.example.com:/exports/registry になります。
[OSEv3:vars] openshift_hosted_registry_storage_kind=nfs openshift_hosted_registry_storage_access_modes=['ReadWriteMany'] openshift_hosted_registry_storage_host=nfs.example.com openshift_hosted_registry_storage_nfs_directory=/exports openshift_hosted_registry_storage_volume_name=registry openshift_hosted_registry_storage_volume_size=10Gi
NFS を使用した OpenShift Container Platform のアップグレードまたはインストール
オプション C: OpenStack プラットフォーム
OpenStack ストレージ設定がすでに存在している必要があります。
[OSEv3:vars] openshift_hosted_registry_storage_kind=openstack openshift_hosted_registry_storage_access_modes=['ReadWriteOnce'] openshift_hosted_registry_storage_openstack_filesystem=ext4 openshift_hosted_registry_storage_openstack_volumeID=3a650b4f-c8c5-4e0a-8ca5-eaee11f16c57 openshift_hosted_registry_storage_volume_size=10Gi
オプション D: AWS または別の S3 ストレージソリューション
シンプルストレージソリューション (S3) バケットがすでに存在している必要があります。
[OSEv3:vars] #openshift_hosted_registry_storage_kind=object #openshift_hosted_registry_storage_provider=s3 #openshift_hosted_registry_storage_s3_accesskey=access_key_id #openshift_hosted_registry_storage_s3_secretkey=secret_access_key #openshift_hosted_registry_storage_s3_bucket=bucket_name #openshift_hosted_registry_storage_s3_region=bucket_region #openshift_hosted_registry_storage_s3_chunksize=26214400 #openshift_hosted_registry_storage_s3_rootdirectory=/registry #openshift_hosted_registry_pullthrough=true #openshift_hosted_registry_acceptschema2=true #openshift_hosted_registry_enforcequota=true
Minio や ExoScale などの別の S3 サービスを使用している場合は、リージョンエンドポイントパラメーターも追加します。
openshift_hosted_registry_storage_s3_regionendpoint=https://myendpoint.example.com/
オプション E: コンバージドモード
コンバージドモードの設定と同様に、Red Hat Gluster Storage はクラスターの初期インストール時に OpenShift Container レジストリーのストレージを提供するように設定できます。これにより、冗長で信頼性の高いレジストリーのストレージを確保できます。
具体的なホストの準備と前提条件については、コンバージドモードに関する考慮事項を参照してください。
インベントリーファイルの
[OSEv3:vars]セクションに次の変数を追加し、設定に合わせてそれらを調整します。[OSEv3:vars] ... openshift_hosted_registry_storage_kind=glusterfs 1 openshift_hosted_registry_storage_volume_size=5Gi openshift_hosted_registry_selector='node-role.kubernetes.io/infra=true'- 1
- 統合 OpenShift Container Registry をインフラストラクチャーノードで実行することが推奨されます。インフラストラクチャーノードは、OpenShift Container Platform クラスターのサービスを提供するために管理者がデプロイするアプリケーションを実行する専用ノードです。
[OSEv3:children]セクションにglusterfs_registryを追加して、[glusterfs_registry]グループを有効にします。[OSEv3:children] masters nodes glusterfs_registry
GlusterFS ストレージをホストする各ストレージノードのエントリーを含む
[glusterfs_registry]セクションを追加します。ノードごとに、glusterfs_devicesを GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は次の形式で指定します。<hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
例:
[glusterfs_registry] node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
[glusterfs_registry]の下に一覧表示されているホストを[nodes]グループに追加します。[nodes] ... node11.example.com openshift_node_group_name="node-config-infra" node12.example.com openshift_node_group_name="node-config-infra" node13.example.com openshift_node_group_name="node-config-infra"
オプション F: Google Compute Engine (GCE) 上の Google Cloud Storage (GCS) バケット
GCS バケットがすでに存在している必要があります。
[OSEv3:vars] openshift_hosted_registry_storage_provider=gcs openshift_hosted_registry_storage_gcs_bucket=bucket01 openshift_hosted_registry_storage_gcs_keyfile=test.key openshift_hosted_registry_storage_gcs_rootdirectory=/registry
オプション G: vSphere ボリュームおよび vSphere Cloud Provider (VCP)
vSphere Cloud Provider は、OpenShift Container Platform ノードでアクセスできるデータストアで設定される必要があります。
レジストリーに vSphere ボリュームを使用する場合、ストレージアクセスモードを ReadWriteOnce に設定し、レプリカ数を 1 に設定する必要があります。
[OSEv3:vars] openshift_hosted_registry_storage_kind=vsphere openshift_hosted_registry_storage_access_modes=['ReadWriteOnce'] openshift_hosted_registry_storage_annotations=['volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume'] openshift_hosted_registry_replicas=1
4.13. グローバルプロキシーオプションの設定
ホストが外部ホストに接続するために HTTP または HTTPS プロキシーを使用する必要がある場合は、プロキシーを使用するためにマスター、Docker、ビルドなどの多数のコンポーネントを設定する必要があります。ノードサービスは外部アクセスを必要としないマスター API にのみ接続するため、プロキシーを使用するように設定する必要はありません。
この設定を単純化するため、クラスターまたはホストレベルで次の Ansible 変数を指定し、これらの設定を環境全体に均一に適用することができます。
ビルド用のプロキシー環境の定義方法の詳細については、「グローバルビルドのデフォルトとオーバーライドの設定」を参照してください。
表4.9 クラスタープロキシー変数
| 変数 | 目的 |
|---|---|
|
|
この変数はマスターおよび Docker デーモンの |
|
|
この変数は、マスターおよび Docker デーモンの |
|
|
この変数は、マスターおよび Docker デーモンに |
|
|
このブール変数は、すべての定義済み OpenShift ホストの名前と |
|
|
この変数は、 |
|
|
この変数は、 |
|
|
この変数は、 |
|
|
この変数は、ビルド時に |
|
|
この変数は、ビルド時に |
4.14. ファイアウォールの設定
- デフォルトのファイアウォールを変更する場合は、不一致を防ぐために、クラスター内の各ホストが同じファイアウォールタイプを使用していることを確認してください。
- Atomic Host にインストールされた OpenShift Container Platform でファイアウォールを使用しないでください。ファイアウォールは Atomic Host ではサポートされていません。
iptables はデフォルトのファイアウォールですが、firewalld は新規インストールで推奨されるファイアウォールです。
OpenShift Container Platform は iptables をデフォルトのファイアウォールとして使用しますが、クラスターをインストールプロセス時に firewalld を使用するように設定できます。
iptables はデフォルトのファイアウォールであるため、OpenShift Container Platform は iptables を自動的に設定するように設計されています。ただし、iptables ルールが適切に設定されていない場合、iptables ルールによって OpenShift Container Platform が中断する可能性があります。 firewalld の利点の 1 つは、複数のオブジェクトでファイアウォールルールを安全に共有できることです。
firewalld を OpenShift Container Platform インストールのファイアウォールとして使用するには、インストール時に os_firewall_use_firewalld 変数を Ansible ホストファイルの設定変数の一覧に追加します。
[OSEv3:vars]
os_firewall_use_firewalld=True 1- 1
- この変数を
trueに設定することで、必要なポートが開き、ルールがデフォルトゾーンに追加されます。これにより、firewalld が適切に設定されていることを確認できます。
firewalld のデフォルトの設定オプションを使用する際には設定オプションが制限され、これらをオーバーライドすることはできません。たとえば、ストレージネットワークを複数ゾーンのインターフェースでセットアップすることができますが、ノードが通信に使用するインターフェースはデフォルトゾーンになければなりません。
4.15. セッションオプションの設定
OAuth 設定のセッションオプションはインベントリーファイルで設定できます。デフォルトで、Ansible は sessionSecretsFile を生成された認証および暗号化シークレットで設定し、1 つのマスターで生成されたセッションが他のマスターによって復号化されるようにできます。デフォルトの場所は /etc/origin/master/session-secrets.yaml であり、このファイルはすべてのマスターで削除された場合にのみ再作成されます。
openshift_master_session_name および openshift_master_session_max_seconds を使用してセッション名と最大秒数を設定できます。
openshift_master_session_name=ssn openshift_master_session_max_seconds=3600
設定されている場合、openshift_master_session_auth_secrets および openshift_master_encryption_secrets は同じ長さでなければなりません。
HMAC を使用したセッションの認証に使用される openshift_master_session_auth_secrets の場合、32 バイトまたは 64 バイトのシークレットを使用することを推奨します。
openshift_master_session_auth_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']
セッションの暗号化に使用される openshift_master_encryption_secrets の場合、シークレットの長さは AES-128、AES-192、または AES-256 を選択するできるようにそれぞれ 16、24、または 32 文字にする必要があります。
openshift_master_session_encryption_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']
4.16. カスタム証明書の設定
OpenShift Container Platform API のパブリックホスト名と Web コンソールのカスタム提供証明書は、クラスターのインストール時にデプロイでき、インベントリーファイルで設定できます。
カスタム証明書は、publicMasterURL に関連付けられたホスト名にのみ設定する必要があります。これは openshift_master_cluster_public_hostname を使用して設定できます。masterURL (openshift_master_cluster_hostname) に関連付けられたホスト名のカスタム提供証明書を使用すると、インフラストラクチャーコンポーネントが内部の masterURL ホストを使用してマスター API に接続しようとするので TLS エラーが生じます。
証明書とキーファイルのパスは、openshift_master_named_certificates クラスター変数を使用して設定できます。
openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "cafile": "/path/to/custom-ca1.crt"}]ファイルパスは、Ansible が実行されるシステムに対してローカルである必要があります。証明書はマスターホストにコピーされ、/etc/origin/master/named_certificates/ ディレクトリー内にデプロイされます。
Ansible は、証明書の Common Name と Subject Alternative Names を検出します。検出された名前は、openshift_master_named_certificates の設定時に "names" キーを指定して上書きできます。
openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "names": ["public-master-host.com"], "cafile": "/path/to/custom-ca1.crt"}]
openshift_master_named_certificates を使用して設定される証明書はマスターにキャッシュされます。つまり、別の証明書セットで Ansible を実行するたびに、以前にデプロイされたすべての証明書がマスターホストとマスターの設定ファイル内に残ることになります。
openshift_master_named_certificates を指定した値 (または値なし) で上書きする場合は、openshift_master_overwrite_named_certificates クラスター変数を指定します。
openshift_master_overwrite_named_certificates=true
さらに詳細の例が必要な場合には、次のクラスター変数をインベントリーファイルに追加することを検討してください。
openshift_master_cluster_method=native openshift_master_cluster_hostname=lb-internal.openshift.com openshift_master_cluster_public_hostname=custom.openshift.com
後続の Ansible 実行で証明書を上書きするには、以下を設定できます。
openshift_master_named_certificates=[{"certfile": "/root/STAR.openshift.com.crt", "keyfile": "/root/STAR.openshift.com.key", "names": ["custom.openshift.com"]}]
openshift_master_overwrite_named_certificates=true4.17. 証明書の有効性の設定
デフォルトで、etcd、マスター、kubelet の管理に使用される証明書は 2 から 5 年で有効期限切れになります。自動生成されるレジストリー、CA、ノードおよびマスター証明書の有効性 (有効期限が切れるまでの日数) は、以下の変数 (デフォルト値が表示されています) を使用してインストール時に設定できます。
[OSEv3:vars] openshift_hosted_registry_cert_expire_days=730 openshift_ca_cert_expire_days=1825 openshift_node_cert_expire_days=730 openshift_master_cert_expire_days=730 etcd_ca_default_days=1825
これらの値は、 Ansible のインストール後での 証明書の再デプロイ時にも使用されます。
4.18. クラスターメトリクスの設定
クラスターメトリクスは、自動的にデプロイされるように設定されていません。クラスターインストール時にクラスターメトリクスを有効にするには、以下を設定します。
[OSEv3:vars] openshift_metrics_install_metrics=true
メトリクスのパブリック URL は、クラスターのインストール時に openshift_metrics_hawkular_hostname Ansible 変数を使用して設定できます。デフォルト値は以下の通りです。
https://hawkular-metrics.{{openshift_master_default_subdomain}}/hawkular/metrics
この変数を変更する場合は、お使いのルーターからホスト名にアクセスできることを確認してください。
openshift_metrics_hawkular_hostname=hawkular-metrics.{{openshift_master_default_subdomain}}
アップストリームの Kubernetes ルールに応じて、eth0 のデフォルトインターフェースでのみメトリクスを収集できます。
メトリクスをデプロイするために openshift_master_default_subdomain 値を設定する必要があります。
4.18.1. メトリクスストレージの設定
メトリクスに永続ストレージを使用するには、openshift_metrics_cassandra_storage_type 変数を設定する必要があります。openshift_metrics_cassandra_storage_type が設定されていない場合、クラスターのメトリクスデータは emptyDir ボリュームに保存されます。このボリュームは、Cassandra Pod が終了すると削除されます。
テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、メトリクスストレージの Cassandra が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。
Cassandra は複数の独立したインスタンスにより冗長性を提供することを目的として設計されています。そのため、データディレクトリーに NFS または SAN を使用することは適切ではなく、推奨されていません。
ただし、他の NFS/SAN の実装ではこのコンポーネントのサポートやこのコンポーネントへのストレージの提供に関して問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS/SAN 実装ベンダーにお問い合わせください。
クラスターインストール時にクラスターメトリクスストレージを有効にするには、次の 3 つのオプションを選択できます。
オプション A: 動的
OpenShift Container Platform 環境がクラウドプロバイダーの動的ボリュームプロビジョニングをサポートする場合、以下の変数を使用します。
[OSEv3:vars] openshift_metrics_cassandra_storage_type=dynamic
gluster-storage および glusterfs-storage-block などのデフォルトで動的にプロビジョニングされたボリュームタイプが複数ある場合、変数でプロビジョニングされたボリュームタイプを指定できます。たとえば、openshift_logging_es_pvc_storage_class_name=glusterfs-storage-block openshift_metrics_cassandra_pvc_storage_class_name=glusterfs-storage-block のようになります。
動的プロビジョニングを有効または無効にするために DynamicProvisioningEnabled を使用する方法についての詳細は、「Volume Configuration」を参照してください。
オプション B: NFS ホストグループ
次の変数が設定されている場合、クラスターインストール時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に NFS ボリュームが作成されます。たとえば、次のオプションを使用した場合、ボリュームパスは /exports/metrics になります。
[OSEv3:vars] openshift_metrics_storage_kind=nfs openshift_metrics_storage_access_modes=['ReadWriteOnce'] openshift_metrics_storage_nfs_directory=/exports openshift_metrics_storage_nfs_options='*(rw,root_squash)' openshift_metrics_storage_volume_name=metrics openshift_metrics_storage_volume_size=10Gi
オプション C: 外部 NFS ホスト
外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。
[OSEv3:vars] openshift_metrics_storage_kind=nfs openshift_metrics_storage_access_modes=['ReadWriteOnce'] openshift_metrics_storage_host=nfs.example.com openshift_metrics_storage_nfs_directory=/exports openshift_metrics_storage_volume_name=metrics openshift_metrics_storage_volume_size=10Gi
以下のオプションを使用した場合、リモートボリュームのパスは nfs.example.com:/exports/metrics になります。
NFS を使用した OpenShift Container Platform のアップグレードまたはインストール
コアの OpenShift Container Platform コンポーネントでの NFS の使用は推奨されていません。NFS (および NFS プロトコル) を使用すると、OpenShift Container Platform インフラストラクチャーを構成するアプリケーションに必要な適切な整合性が確保されなくなるためです。
そのため、インストーラーおよび更新 Playbook には、コアインフラストラクチャーコンポーネントで NFS の使用を有効にするオプションが必要になります。
# Enable unsupported configurations, things that will yield a partially # functioning cluster but would not be supported for production use #openshift_enable_unsupported_configurations=false
クラスターのアップグレードまたはインストール時に以下のメッセージが表示される場合、追加の手順が必要になります。
TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}Ansible インベントリーファイルで、以下のパラメーターを指定します。
[OSEv3:vars] openshift_enable_unsupported_configurations=True
4.19. クラスターロギングの設定
クラスターロギングは、デフォルトで自動的にデプロイされるように設定されていません。クラスターインストール時にクラスターロギングを有効にするには、以下を設定します。
[OSEv3:vars] openshift_logging_install_logging=true
4.19.1. ロギングストレージの設定
ロギングに永続ストレージを使用するには、openshift_logging_es_pvc_dynamic 変数を設定する必要があります。openshift_logging_es_pvc_dynamic が設定されていない場合、クラスターのロギングデータは emptyDir ボリュームに保存されます。このボリュームは、Elasticsearch Pod が終了すると削除されます。
テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、ロギングストレージの ElasticSearch が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。
ElasticSearch はカスタム deletionPolicy を実装しないため、NFS ストレージをボリュームまたは永続ボリュームとして使用することは Elasticsearch ストレージではサポートされていません。Lucene および default deletionPolicy は NFS が指定しないファイルシステムの動作に依存します。データの破損およびその他の問題が発生する可能性があります。
他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
クラスターインストール時にクラスターロギングストレージを有効にするには、次の 3 つのオプションを選択できます。
オプション A: 動的
OpenShift Container Platform 環境がクラウドプロバイダーの動的ボリュームプロビジョニングをサポートする場合、以下の変数を使用します。
[OSEv3:vars] openshift_logging_es_pvc_dynamic=true
gluster-storage および glusterfs-storage-block などのデフォルトで動的にプロビジョニングされたボリュームタイプが複数ある場合、変数でプロビジョニングされたボリュームタイプを指定できます。たとえば、openshift_logging_es_pvc_storage_class_name=glusterfs-storage-block openshift_metrics_cassandra_pvc_storage_class_name=glusterfs-storage-block のようになります。
動的プロビジョニングを有効または無効にするために DynamicProvisioningEnabled を使用する方法についての詳細は、「Volume Configuration」を参照してください。
オプション B: NFS ホストグループ
以下の変数が設定されている場合、通常インストール (Advanced installation) 時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に NFS ボリュームが作成されます。たとえば、以下のオプションを使用した場合、ボリュームパスは /exports/logging になります。
[OSEv3:vars] openshift_logging_storage_kind=nfs openshift_logging_storage_access_modes=['ReadWriteOnce'] openshift_logging_storage_nfs_directory=/exports openshift_logging_storage_nfs_options='*(rw,root_squash)' openshift_logging_storage_volume_name=logging openshift_logging_storage_volume_size=10Gi
オプション C: 外部 NFS ホスト
外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。
[OSEv3:vars] openshift_logging_storage_kind=nfs openshift_logging_storage_access_modes=['ReadWriteOnce'] openshift_logging_storage_host=nfs.example.com openshift_logging_storage_nfs_directory=/exports openshift_logging_storage_volume_name=logging openshift_logging_storage_volume_size=10Gi
以下のオプションを使用した場合、リモートボリュームのパスは nfs.example.com:/exports/logging になります。
NFS を使用した OpenShift Container Platform のアップグレードまたはインストール
コアの OpenShift Container Platform コンポーネントでの NFS の使用は推奨されていません。NFS (および NFS プロトコル) を使用すると、OpenShift Container Platform インフラストラクチャーを構成するアプリケーションに必要な適切な整合性が確保されなくなるためです。
そのため、インストーラーおよび更新 Playbook には、コアインフラストラクチャーコンポーネントで NFS の使用を有効にするオプションが必要になります。
# Enable unsupported configurations, things that will yield a partially # functioning cluster but would not be supported for production use #openshift_enable_unsupported_configurations=false
クラスターのアップグレードまたはインストール時に以下のメッセージが表示される場合、追加の手順が必要になります。
TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}Ansible インベントリーファイルで、以下のパラメーターを指定します。
[OSEv3:vars] openshift_enable_unsupported_configurations=True
4.20. サービスカタログオプションのカスタマイズ
サービスカタログはインストール時にデフォルトで有効にされます。サービスブローカーを有効にすると、サービスブローカーをカタログで登録できます。サービスカタログが有効にされると、OpenShift Ansible Broker およびテンプレートサービスブローカーが共にインストールされます。詳細は、「OpenShift Ansible Broker の設定」および「テンプレートサービスブローカーの設定」を参照してください。サービスカタログを無効にする場合は、OpenShift Ansible Broker およびテンプレートサービスブローカーはインストールされません。
サービスカタログの自動デプロイメントを無効にするには、以下のクラスター変数をインベントリーファイルに設定します。
openshift_enable_service_catalog=false
独自のレジストリーを使用する場合、以下を追加する必要があります。
-
openshift_service_catalog_image_prefix: サービスカタログイメージをプルする際に、特定のプレフィックス (例:registry) の使用を強制的に実行します。(イメージ名までの) 詳細なレジストリー名を指定する必要があります。 -
openshift_service_catalog_image_version: サービスカタログイメージをプルする際に、特定のイメージバージョンの使用を強制的に実行します。
例:
openshift_service_catalog_image="docker-registry.default.example.com/openshift/ose-service-catalog:${version}"
openshift_service_catalog_image_prefix="docker-registry-default.example.com/openshift/ose-"
openshift_service_catalog_image_version="v3.9.30"
template_service_broker_selector={"role":"infra"}4.20.1. OpenShift Ansible Broker の設定
OpenShift Ansible Broker (OAB) は、インストール時にデフォルトで有効になります。
OAB をインストールしない場合は、インベントリーファイルで ansible_service_broker_install パラメーター値を false に設定します。
ansible_service_broker_install=false
表4.10 サービスブローカーのカスタマイズ変数
| 変数 | 目的 |
|---|---|
|
|
サービスカタログコンポートイメージのプレフィックスを指定します。 |
4.20.1.1. OpenShift Ansible Broker 用の永続ストレージの設定
OAB は、残りの OpenShift Container Platform クラスターが使用する etcd とは別に独自の etcd インスタンスをデプロイします。OAB の etcd インスタンスが機能するためには、永続ボリューム (PV) を使用する個別のストレージが必要です。使用可能な PV がない場合、etcd は PV の条件が満たされるまで待機します。OAB アプリケーションは、etcd インスタンスが使用可能になるまで CrashLoop 状態になります。
一部の Ansible Playbook Bundle (APB) でも、デプロイに専用の PV が必要になります。たとえば、APB の各データベースには 2 つのプランがあります。開発プランは一時的なストレージを使用し、PV を必要としませんが、実稼働プランは永続的であり、PV を必要とします。
| APB | PV が必要? |
|---|---|
|
postgresql-apb |
必要 (ただし実稼働プランの場合のみ必要) |
|
mysql-apb |
必要 (ただし実稼働プランの場合のみ必要) |
|
mariadb-apb |
必要 (ただし実稼働プランの場合のみ必要) |
|
mediawiki-apb |
必要 |
OAB の永続ストレージを設定するには、以下の手順を実行します。
以下の例では、NFS ホストを使用して必要な PV を提供しています。ただし、他の永続ストレージプロバイダーを代わりに使用することもできます。
インベントリーファイルの
[OSEv3:children]セクションにnfsを追加して、[nfs]グループを有効にします。[OSEv3:children] masters nodes nfs
[nfs]グループセクションを追加し、NFS ホストになるシステムのホスト名を追加します。[nfs] master1.example.com
[OSEv3:vars]セクションに以下を追加します。openshift_hosted_etcd_storage_kind=nfs openshift_hosted_etcd_storage_nfs_options="*(rw,root_squash,sync,no_wdelay)" openshift_hosted_etcd_storage_nfs_directory=/opt/osev3-etcd 1 openshift_hosted_etcd_storage_volume_name=etcd-vol2 2 openshift_hosted_etcd_storage_access_modes=["ReadWriteOnce"] openshift_hosted_etcd_storage_volume_size=1G openshift_hosted_etcd_storage_labels={'storage': 'etcd'}
これらの設定は、クラスターのインストール時に OAB の etcd インスタンスに割り当てられる永続ボリュームを作成します。
4.20.1.2. ローカルの APB 開発用の OpenShift Ansible Broker の設定
OpenShift Container レジストリーと OAB を組み合わせて APB 開発 を行うには、OAB がアクセスできるイメージのホワイトリストを定義する必要があります。ホワイトリストが定義されていない場合、ブローカーは APB を無視し、使用可能な APB がユーザーに表示されません。
デフォルトでは、ホワイトリストは空になっており、クラスター管理者がブローカーを設定するまでユーザーが APB イメージをブローカーに追加できないようになっています。-apb で終了するすべてのイメージをホワイトリスト化するには、以下の手順を実行します。
インベントリーファイルの
[OSEv3:vars]セクションに以下を追加します。ansible_service_broker_local_registry_whitelist=['.*-apb$']
4.20.2. テンプレートサービスブローカーの設定
テンプレートサービスブローカー (TSB) は、インストール時にデフォルトで有効になります。
TSB をインストールしない場合は、template_service_broker_install パラメーターの値を false に設定します。
template_service_broker_install=false
TSB を設定するには、テンプレートとイメージストリームをサービスカタログに読み込めるように 1 つ以上のプロジェクトをブローカーのソース namespace として定義する必要があります。インベントリーファイルの [OSEv3:vars] セクションで以下を変更して、必要なプロジェクトを設定します。
openshift_template_service_broker_namespaces=['openshift','myproject']
デフォルトでは、TSB は Pod のデプロイにノードセレクター {"node-role.kubernetes.io/infra":"true"} を使用します。インベントリーファイルの [OSEv3:vars] セクションに必要なノードセレクターを設定してこれを変更できます。
template_service_broker_selector={"node-role.kubernetes.io/infra":"true"}表4.11 テンプレートサービスブローカーのカスタマイズ変数
| 変数 | 目的 |
|---|---|
|
|
テンプレートサービスブローカーのコンポーネントイメージのプレフィックスを指定します。 |
|
|
Ansible サービスブローカーのコンポーネントイメージのプレフィックスを指定します。 |
4.21. Web コンソールのカスタマイズの設定
以下の Ansible 変数は、Web コンソールをカスタマイズするためのマスター設定オプションを設定します。これらのカスタマイズオプションの詳細については、「Web コンソールのカスタマイズ」を参照してください。
表4.12 Web コンソールのカスタマイズ変数
| 変数 | 目的 |
|---|---|
|
|
Web コンソールをインストールするかどうかを決定します。 |
|
|
Web コンソールイメージのプレフィックスを指定します。 |
|
|
Web コンソールの設定で |
|
|
Web コンソールの設定で |
|
|
Web コンソール設定で |
|
|
マスター設定で OAuth テンプレートを設定します。詳細については、「ログインページのカスタマイズ」を参照してください。値の例: |
|
|
マスター設定で |
|
|
マスター設定で |
|
|
アクティブでない状態が一定期間続いた後にユーザーを自動的にログアウトするように Web コンソールを設定します。5 以上の整数を指定する必要があります。この機能を無効にする場合は 0 を指定します。デフォルトは 0 (無効) です。 |
|
|
クラスターがオーバーコミット対応に設定されているかどうかを示すブール値。 |
